中国联合网络通信有限公司软件研究院云原生平台研发面经——求职精灵（finsight.work）

自我介绍控制在 1 分半以内，用「身份—方向—证据—动机」四段推进。第一段一句话交代学校、专业、届别；第二段讲主攻方向（如云计算与容器化），点名 Docker、Kubernetes、Linux 运维、CI/CD 这几个关键词，让面试官知道可以往哪问；第三段给证据，用一段实习或项目说明你真的动过手，例如「在 XX 公司做容器化迁移，负责 K8s 集群维护和流水线搭建，把发布耗时从 30 分钟压到 8 分钟」；第四段收口到岗位动机，说明为什么是联通软研院、为什么是平台研发。注意别把简历念一遍，面试官手里有简历，你要给的是「我擅长什么 + 凭什么」。最后留一个钩子，比如「容器网络这块我踩过不少坑」，引导对方往你准备好的方向问。

按「公司岗位—具体工作—量化结果—踩坑收获」四段讲，重点是第三、四段。工作内容要落到可验证的动作：Docker 镜像构建与瘦身、K8s 集群扩容、CI/CD 流水线搭建、容器化应用迁移、巡检与告警脚本开发。结果尽量量化，比如节点扩容后单集群承载 Pod 数提升多少、发布频率从每周一次变成每天多次、故障平均恢复时间缩短多少。收获分三层说：技术层是搞懂了容器网络与调度的真实约束，业务层是理解了平台稳定性对业务的影响，协作层是与开发、运维、网络团队对接时怎么把需求翻译成配置。最后主动交代一个坑，例如「一开始把 requests 设得过大导致调度失败」，再说明怎么定位、怎么改——面试官往往就是顺着这个坑继续追问的。

先给岗位定义，再说能力要求，最后落到自己的匹配点。定义部分：这个岗位在软研院属于平台研发，负责容器云平台的建设与运维，涵盖 Docker 与 K8s 集群管理、CI/CD 流水线、自动化运维与故障排查，服务对象是全集团的业务系统，所以「稳定」是第一优先级。能力要求部分：扎实的 Linux 基础（进程、网络、文件系统）、容器与编排原理、网络知识（尤其 Overlay 与 Service 转发）、以及写脚本和排查问题的能力。匹配部分：把自己的实习内容对应上去，说明哪些是已经做过的、哪些是知道原理但缺实战的——坦诚列出短板反而加分，因为面试官接下来很可能就问你短板那块。结尾可以补一句对岗位价值的理解：平台研发不直接产出业务功能，但决定了业务能多快、多稳地上线。

核心是三件套：Namespace、Cgroups、UnionFS（联合文件系统），分别解决「看得见」「用多少」「怎么存」三个问题。Namespace 负责隔离视图，Docker 常用的是 PID、NET、MNT、UTS、IPC、USER 六种，让容器里的进程以为自己独占一台机器；其中 NET namespace 是容器网络的基础，每个容器有自己的网卡、IP、路由表。Cgroups 负责资源限制与统计，控制 CPU shares/quota、内存上限、IO 权重、进程数，v2 版本统一成单一层级树，是「容器不会把宿主机吃垮」的保障。UnionFS（早期 AUFS，现在多为 overlay2）负责镜像分层，多个只读层叠加成一个可写视图，写时复制（CoW）让同一基础镜像被上百个容器共享而不重复占用磁盘。此外还要提一句 runc/libcontainer 负责真正调用 clone、unshare、pivot_root 这些系统调用完成创建——面试官常在这里追问「Docker 本身只是个 CLI 和 API 外壳」。

按「创建—运行—存储—网络」四段讲。创建：docker run 后 Docker Daemon 通过 containerd 调用 runc，runc 执行 clone 创建新进程并设置 Namespace、写 Cgroups 限制、pivot_root 切换根文件系统，进程退出后 runc 就退出，容器生命周期由 containerd/shim 托管。运行：容器本质是宿主机上一个被隔离的普通进程，所以 ps 能看到、top 能算到，杀掉 1 号进程容器就结束——这点跟虚拟机有本质区别。存储：镜像由多个只读层组成，容器启动时在最上面加一个可写层，写文件触发 CoW；需要持久化的数据用 Volume 或 Bind Mount 绕过可写层。网络：默认 bridge 模式下，Docker 创建 docker0 网桥，每个容器一对 veth pair，一端在容器内当 eth0，一端挂在网桥上，出网靠 iptables MASQUERADE 做 NAT，端口映射靠 DNAT。能把这四段讲完整，基本就覆盖了面试官想要的「原理 + 实现」。

按四个层次拆：Pod 内容器之间、同节点 Pod 之间、跨节点 Pod 之间、Pod 与 Service 之间。第一层最简单，同一 Pod 内的容器共享同一个网络 Namespace，共用 IP 和端口空间，直接 localhost 通信，靠的是 pause 容器持有网络命名空间。第二层走本机网桥，容器 veth 挂在 cni0/docker0 上，同网段直接二层转发，不经过网关。第三层依赖 CNI 插件，Flannel 的 VXLAN 模式是把原始报文封进 UDP 再发到对端 VTEP 解封装，Calico 的 BGP 模式则是对外宣告 Pod 网段、靠路由直达，性能更好但对底层网络有要求。第四层是 Service：ClusterIP 是虚拟 IP，由 kube-proxy 在节点上生成 iptables 规则（或 IPVS 规则）做 DNAT，把访问 VIP 的包改写成某个 Endpoints 的 Pod IP，因此 Service 本身没有进程在监听，ping 不通但 TCP 能通。回答时最好顺手画一下数据包路径，比背概念有说服力。

Flannel 是最早一批 CNI 插件，解决的问题是「让不同节点上的 Pod 拿到不冲突的 IP，并且能互相直达」。它由 flanneld 进程负责，启动时向 etcd 或 API Server 申请本节点的 Pod 网段（默认 /24），并把分配结果写到节点注解里，同时维护一张节点到网段的映射表。核心是三种后端：VXLAN（默认，通用性最好）、host-gw（把对端节点当下一跳写进路由表，纯路由无封装，性能接近原生但要求所有节点二层互通）、UDP（用户态封装，性能差，基本只在调试或受限网络下用）。以 VXLAN 为例走一遍：Pod A 发包，目的 IP 是另一节点 Pod 的地址，命中节点上的路由表，下一跳指向 flannel.1 这个 VTEP 设备；flannel.1 查 FDB 表得到对端 VTEP 的 MAC，再查 ARP/邻居表得到对端节点 IP，把原始以太帧封进 VXLAN 头、外套 UDP（8472）与节点 IP 头，通过物理网卡发出；对端节点收到后剥掉外层，按 VNI 交给 flannel.1，再查路由送到目标 Pod。追问常问「VXLAN 的 MTU 要注意什么」——封装多出约 50 字节，所以要调小 Pod 网卡 MTU 或开物理网卡 jumbo frame，否则大包会被静默丢弃。

List-Watch 是 K8s 里各组件与 API Server 保持状态同步的统一模式，本质是「先全量、后增量」的客户端缓存机制。List 阶段：组件启动时带 resourceVersion 发起一次全量拉取，拿到当前所有对象以及一个版本号，写入本地 informer 的缓存（Store）。Watch 阶段：以这个 resourceVersion 为起点建立长连接（HTTP chunked），API Server 之后每个对象的 ADDED/MODIFIED/DELETED 事件都会推给客户端，客户端只更新缓存并触发注册的回调（EventHandler）。这样做的好处是减少对 API Server 的轮询压力、事件延迟低。断线时有两种恢复路径：如果 resourceVersion 还在 etcd 的历史窗口内，就从断点续 watch；如果太旧（默认 5 分钟）会返回 410 Gone，客户端必须重新 List 一次全量。典型链路可以串起来讲：用户提交 Pod → API Server 写入 etcd → Scheduler 通过 watch 感知到未绑定的 Pod，调度后更新 nodeName → kubelet watch 到属于自己的 Pod，调用 CRI 起容器，再回写 status。这条链讲清楚，机制就说透了。

别只报菜名，按排障场景组织更有说服力。进程与负载：top/htop 看整体，ps -ef 与 ps -aux 定位进程，pidstat 看单进程 CPU 与 IO，kill -9 慎用，先 kill -15 给进程收尾机会。磁盘与文件：df -h 看分区占用，du -sh * 找大目录，lsof +L1 找被删除但未释放的文件（磁盘满的经典坑），find 按时间与大小筛。网络：ss -lntp 替代 netstat 看监听端口，ip addr / ip route 看地址与路由，tcpdump 抓包，curl -v 验证连通，nslookup/dig 查 DNS。文本处理：grep -rn 定位日志，awk 做列统计（如 awk '{print $1}' access.log | sort | uniq -c | sort -rn | head），sed 做替换，tail -f 跟日志。系统信息：free -h、uptime、vmstat 1、dmesg 看内核 OOM 记录。答完最好补一个真实场景，比如「容器频繁 OOMKilled，我用 dmesg 确认是 cgroup 内存超限而不是节点内存不足」，这样才显得是干过活的。

三层结构：先承认必要性，再讲效率观，最后给边界。第一层，平台研发有很强的运维属性，变更窗口、故障处理、版本上线这些场景确实需要在下班后或夜间投入，这个心理准备要有，别一上来就说「我不接受加班」。第二层，讲清楚自己更看重「有效投入」——把重复劳动自动化掉才是平台岗的正解，可以举实习里的例子：写了个巡检脚本把每天半小时的人工检查变成自动告警，这类优化比单纯延长工时更有价值。第三层给边界，说明自己会在关键节点顶上，但反对长期低效的「陪坐」，表达方式要留余地，可以说「我更希望用计划和优先级把紧急情况减少」。运营商体系节奏相对稳定，但也有集采、大版本、节假日保障等高峰期，回答里体现「知道什么时候会忙」会显得做过功课。最后落到团队：愿意为了项目整体进度配合，不以个人作息为由拖团队。

反问是最后一次展示专业度的机会，问题要落在「技术栈—团队—成长」三个方向，避开薪资福利（等 HR 面再谈）。可以问：团队目前容器云平台的技术栈是怎样的，是自建 K8s 还是基于联通云？平台侧当前最头疼的问题是哪类，是集群规模、多租户隔离还是发布效率？校招生进来第一年会从哪类任务切入，有没有导师带？这几个问题都在传递一个信息——你已经在用平台研发的视角思考问题。禁忌问题：加班多不多（换成「团队的发布节奏是怎样的」）、能不能转岗、面试表现如何（当场问结果会让面试官为难）。准备 3 个问题，现场按面试官的风格挑 1—2 个问，留一个做备选，问完记得用一句话收尾，比如「谢谢，这些信息对我判断很关键」，把主动权交回去。