Kubernetes 核心概念面试：Pod、Deployment、Service 深度拆解

本章专攻 K8s 三大高频面试题：Pod 生命周期（基础排障）、Deployment 策略（发布核心）、Service 类型（网络入口）。掌握 定义→原理→场景→注意 框架，能让你面对任何追问都从容不迫。

🎯 公司侧重点图鉴

  • 大厂（侧重调度与网络）： 深挖 kube-scheduler 算法、Calico/Cilium 网络性能、IPTABLES vs IPVS 原理、大规模集群 etcd 优化。
  • 创业公司（侧重集群运维）： 侧重集群搭建（kubeadm）、基础 YAML 编写、日志监控（ELK/Prometheus）、日常排障（CrashLoopBackOff、Node NotReady）。
K8s 核心概念回答框架 1. 定义 本质是什么 2. 原理 底层机制是什么 3. 场景 典型适用场所 4. 注意 生产高频避坑

📇 问答卡片 1：Pod 生命周期

面试问题：详细描述 Pod 从创建到销毁的生命周期，并说明常见状态转换的原因。

面试官考察点：基础深度、容器运行时理解、排障思维逻辑。

回答框架：

  • 定义： Pod 是 K8s 的最小调度和资源单位，包含一个或多个容器。
  • 原理： 状态机由 Pending（调度）→ Running（运行）→ Succeeded/Failed（结束）。kubelet 通过 CRI 接口监控容器状态更新 PodStatus。
  • 场景： 单容器单体应用、Sidecar 模式（如日志收集）、Job 批处理任务。
  • 注意： CrashLoopBackOff 需看日志和资源；Init 容器会阻塞 Pod 状态；需配置 preStop 和 terminationGracePeriodSeconds 实现优雅关闭。

示例回答：Pod 生命周期核心由 Pending、Running、Succeeded/Failed 构成。原理依赖 kubelet 与运行时（如 containerd）交互更新阶段状态。生产环境中，CrashLoopBackOff 是高频问题，需要快速定位 Liveness 探针失败或 OOMKilled。我会强调就绪探针对服务可用性的联动保障。

可能追问：Init 容器异常如何排查？Pod 原地重启与重建的区别？什么是 Pod 的拓扑约束？

⚠️ 避坑提醒：不要只背诵状态名词。关键要结合 kubectl describe pod 的 Events 和 Conditions 字段来解释状态转换背后的原因（如容器运行时拉镜像失败、CNI 网络配置延迟）。

📇 问答卡片 2：Deployment 更新策略

面试问题：Deployment 滚动更新算法如何实现？如何保证发布零中断？

面试官考察点：发布策略、声明式思想、回滚机制、可用性保障。

回答框架：

  • 定义： 声明式管理应用副本，驱动实际状态向期望状态迁移。
  • 原理： 核心是 ReplicaSet 控制器 + MaxSurge/MaxUnavailable 参数。新旧 RS 逐步扩缩容，配合就绪探针切换流量。
  • 场景： 无状态微服务发布、回滚到历史版本、批量更新环境变量。
  • 注意： 默认无金丝雀/蓝绿能力，需搭配 Service Mesh；就绪探针务必准确；设置 ProgressDeadlineSeconds 防止更新卡死。

示例回答：Deployment 通过控制新旧 ReplicaSet 扩缩容实现滚动更新。我会设置 maxSurge=25%、maxUnavailable=25%，并配合 httpGet 就绪探针。项目里关键点是通过 preStop 钩子结合优雅宽限期，确保旧 Pod 在流量切完后才销毁，实现零中断发布。

可能追问：金丝雀发布如何实现？回滚策略和保留历史个数？maxSurge=0 时怎么工作？

⚠️ 避坑提醒：不要混淆 Deployment（无状态）和 StatefulSet（有状态）的更新策略。Deployment 默认是滚动，StatefulSet 默认是 OnDelete 或 Partition 灰度。大厂面试不会停留在 YAML 编写，会深究控制器循环和 Informer 机制。

📇 问答卡片 3：Service 类型

面试问题：对比 ClusterIP、NodePort、LoadBalancer 的核心区别及适用场景。

面试官考察点：网络模型、服务发现、云原生流量暴露思路。

回答框架：

  • 定义： 将一组 Pod 抽象为逻辑服务，提供稳定的访问入口。
  • 原理： kube-proxy 通过 iptables 或 IPVS 写转发规则，ClusterIP 是虚拟 IP，NodePort 基于 DNAT 暴露宿主机端口。
  • 场景： ClusterIP（内部微服务互调）、NodePort（四层 UDP 或临时调试）、LoadBalancer（对接云 LB / 对外暴露）。
  • 注意： ExternalTrafficPolicy 影响源 IP 保留；Headless Service（ClusterIP = None）用于 StatefulSet 状态感知。

示例回答：ClusterIP 用于集群内通信，NodePort 映射节点端口，LoadBalancer 对接公有云负载均衡器。内部微服务全走 ClusterIP，外部流量统一使用 Nginx Ingress。大厂生产环境禁用 NodePort 直通业务，倾向 LB + Ingress 集中管控，并开启 ExternalTrafficPolicy: Local 保留客户端来源 IP。

可能追问：iptables 与 IPVS 模式区别？Headless Service 如何与 StatefulSet 配合？Service 拓扑感知（Topology Aware Hints）怎么用？

⚠️ 避坑提醒：回答要区分“云上”和“自建”。云上选 LoadBalancer/AWS NLB，自建选 Keepalived + MetalLB。不要无脑推 NodePort，需说明其安全风险（节点 IP 暴露、端口冲突）。大厂面试必须能画出 kube-proxy 到 Pod 的网络路径图。

📌 项目案例模板：云原生容器调度平台建设与大规模迁移

项目名称 基于 Kubernetes 的微服务容器化与高可用实践
业务背景 500+ 微服务从虚拟机迁移至 Kubernetes，解决资源利用率低（平均 CPU 利用率 < 15%）、环境不统一、发布效率低等问题。
规模指标 3000+ Pods，80+ 物理节点（2000+ 核），日均构建发布 150 次，100+ 微服务已接入 Service Mesh。
技术栈 Kubernetes v1.24（kubeadm 部署）、Calico（eBPF 模式）、Prometheus + Grafana + AlertManager、Rook（Ceph 持久化）、Jenkins CI/CD、Harbor。
核心难点 1) etcd 大集群性能瓶颈（高负载下读写延迟抖动）。2) 跨宿主机容器网络延迟（East-West 流量占比 70%）。3) 有状态应用（MySQL/Redis）容器化后高可用与数据持久化保障。
面试高频追问 1) 单集群最大 Pod 数量瓶颈在哪？如何破局（多集群/Node 分区）？
2) CNI 方案对比选择（Flannel 简单、Calico 策略丰富、Cilium eBPF 高性能）。
3) K8s 证书过期处理流程（更新 kubelet/kubeconfig 证书）。
4) 如何实现 Pod 优雅终止和流量平滑迁移（preStop + Readiness + PDB）？
可迁移回答话术 “在该项目中，我们通过 拓扑约束 + Pod 反亲和性 解决跨 AZ 高可用；针对网络性能，启用 Calico eBPF 模式 将延迟降低 40%；面对大流量发布，采用 HPA + PDB + preStop 钩子 组合拳，确保零中断无损发布。” 此模板可直接套用任何“容器化改造”或“K8s 优化”类问题。
← 上一章 📖 返回目录 下一章 →