容器平台架构师高阶面试宝典 - 第4节
容器网络与存储面试
本章聚焦容器平台架构师在网络模型（CNI）与存储方案（CSI）方向的面试考点。面试官侧重考察你对 Kubernetes 网络插件原理、容器间通信机制、持久化存储选型及故障排查的深度理解。以下内容以结构化问答和真实项目模板呈现，助你快速构建面试应答体系。
面试问答卡片
Q1：解释 Kubernetes 网络模型中的 Pod 间通信原理，并对比 Calico 与 Flannel 的实现差异。
面试官考察点： 是否理解 K8s 网络基本要求（Pod IP 互通、Service 抽象），能否从 CNI 层面分析不同实现的转发路径与性能差异。
回答框架： K8s 网络模型要求所有 Pod 无需 NAT 直接通信 → 底层依赖 CNI 实现。Calico 使用 BGP 实现三层路由，直接通过宿主机路由转发，性能高但需网络设备支持；Flannel 默认使用 VXLAN 封装（Overlay），三层隧道，适配性广但性能略低。选型时需考虑网络规模与物理环境。
示例回答： “K8s 网络模型要求 Pod 间 IP 可达且无需 NAT。Calico 基于 BGP 做三层路由，数据直接经过宿主机路由表转发，延迟低，适合大规模生产；Flannel 默认 VXLAN 封装，将二层帧封装在 UDP 中，环境要求低但 CPU 开销增加。我个人更倾向在物理网络支持 BGP 时首选 Calico，否则用 Flannel+隧道。”
可能追问： Calico 的 IPIP 模式与 BGP 模式区别？如何排 Pod 网络不通？
避坑提醒： 不要只说概念，要给出具体技术细节（如 VXLAN 的 VTEP、BGP 的 AS 号配置）。
Q2：你在生产环境中如何设计容器持久化存储方案？说说 PV、PVC、StorageClass 的关系。
面试官考察点： 是否理解 K8s 存储抽象层，能否结合 CSI 驱动规划存储动态供应与静态供应，考察对 stateful 应用（如数据库）的存储运维经验。
回答框架： 分层设计：StorageClass 定义后端存储（如 AWS EBS、Ceph RBD）与回收策略 → PVC 声明存储需求 → PV 绑定实际存储资源。生产常用动态 Provision 避免手动创建 PV。对于有状态应用，建议 StatefulSet + 动态 PVC 模板，配合 PVC 保留策略。
示例回答： “我们为日志系统使用 Ceph CSI 动态供应，创建 StorageClass 设置 reclaimPolicy: Delete，PVC 自动生成 RBD 块设备。同时为 MySQL 集群采用 StatefulSet + volumeClaimTemplates，每个 Pod 独立 PVC。注意为关键数据设置 StorageClass 的 allowVolumeExpansion: true，以便在线扩容。”
可能追问： 如何实现跨 AZ 存储卷迁移？PV 的状态变化（Available→Bound→Released）如何处理？
避坑提醒： 避免回答“全用默认 StorageClass”；一定要说明回收策略与备份/快照的关系。
Q3：当 Pod 访问外部服务出现网络延迟激增，如何定位是 CNI 插件问题还是应用层问题？
面试官考察点： 排障思路是否系统，能否熟练使用网络工具（tcpdump、iftop、conntrack）以及 K8s 网络调试容器（如 netshoot）。
回答框架： 四步法：① 在 Pod 内部及宿主机分别 ping 目标 IP，判断延迟点（Pod内延迟 vs 宿主机延迟）；② 若宿主机正常，则问题可能在 CNI 网络策略或容器网卡（veth pair）→ 用 tcpdump 抓包分析；③ 若宿主机也高延迟，则排查宿主机网络（如 conntrack 表满、iptables 规则冲突）；④ 最后检查外部 DNS 解析与 Service 负载均衡。
示例回答： “先在 Pod 内执行 ping -c 10 <目标IP>，同时在宿主机上 ping 同 IP，记录延迟对比。如果 Pod 内延迟高而宿主机正常，我会进入 Pod 的 netns 用 tcpdump 过滤包，或者用 netshoot 容器携带 mtr 工具测试路径。曾遇到 Flannel VXLAN 的 MTU 不一致导致 UDP 包分片，调整 MTU 后解决。”
可能追问： 如何查看 conntrack 表？你怎么评估 CNI 插件的性能？
避坑提醒： 不要跳过宿主机对比直接怀疑 CNI；避免空谈“重启Pod”，面试官期望系统性排障。
项目案例：云原生容器平台存储网络一体化落地
| 项目名称 | 云原生容器平台存储网络一体化落地 (Storage-Net Convergence) |
| 业务背景 | 金融级 SaaS 平台，拆解原有虚拟机部署，将 200+ 微服务迁移至 K8s，其中 60 个有状态服务（数据库、消息队列）需要持久化存储。 |
| 规模指标 | 10 个集群（生产+灰度）、1000+ 节点、10W+ Pod 运行、存储总量 200TB+、日网络流量 500TB+。 |
| 技术栈 | Kubernetes v1.24 / Cilium (CNI, eBPF) / Longhorn (CSI) / Rancher / Prometheus + Grafana / Ceph (备份)。 |
| 核心难点 | ① Cilium 与老系统 iptables 规则冲突；② Longhorn 块设备在多节点并发写入时延迟抖动；③ 存储卷跨 AZ 迁移时数据一致性保障。 |
| 面试高频追问 | 如何设计 Cilium NetworkPolicy 以兼容原有安全组？Longhorn 的 Engine/Replica 架构如何实现高可用？存储卷扩容如何不影响在线业务？ |
| 可迁移回答话术 | “在金融级场景中，我采用 Cilium 的 eBPF 替代 iptables 转发，配合 Hubble 观测网络流量；存储选型 Longhorn 因其原生 CSI 支持与快照能力。核心经验：分层压测（Pod 内→宿主机→上游设备），先解决网络抖动的 MTU 问题，再优化存储的 IO 队列。” |