第3章 Kubernetes核心概念与原理深度解析
本章聚焦面试中最高频的核心概念：Pod、Service、Deployment、Ingress。面试官常通过追问原理来验证你对容器编排的深层理解，而非仅停留在“会用”层面。掌握每个组件的设计意图、协作关系及典型异常场景，是获得高分的关键。
面试问答卡（3个高频考点）
📌 问题1：Pod 与容器是什么关系？Pod 在 Kubernetes 中为何是最小调度单位？
面试官考察点：验证你是否理解 Pod 的设计意义（网络/IP共享、存储卷共享、Sidecar模式），而非仅知道“Pod里可以放多个容器”。
回答框架：概念区分 → 设计原因（共享网络/IP/存储） → 典型模式（Sidecar/Adapter） → 对比传统部署。
示例回答：“Pod 是 Kubernetes 中创建、调度的最小单位，它可以包含一个或多个容器。所有共享同一个 Network Namespace 和存储卷，彼此通过 localhost 通信。这一设计解决了多进程间共享网络与存储的诉求，典型的如 Sidecar 模式将日志收集、代理等辅助容器与主容器打包。”
可能追问：“如果 Pod 中的某个容器崩溃了，整个 Pod 会怎样？”“为什么不用一组直接耦合的容器而用 Pod？”
⚠️ 避坑提醒：不要将 Pod 等价于容器。强调“Pod 是调度单元，容器是运行单元”；避免遗漏共享网络栈带来的端口冲突风险。
📌 问题2：Service 如何实现服务发现与负载均衡？ClusterIP、NodePort、LoadBalancer 三种类型区别是什么？
面试官考察点：考核你对网络模型的理解（kube-proxy、iptables/IPVS）、以及不同场景下的选型能力。
回答框架：Service 抽象作用 → 代理机制（kube-proxy） → 三种类型特点与选择 → 流量转发路径（iptables规则链）。
示例回答：“Service 通过标签选择器关联一组 Pod，后端的 Endpoint 对象动态管理 Pod IP。kube-proxy 利用 iptables 或 IPVS 实现负载均衡。ClusterIP 仅集群内访问；NodePort 在每台节点上开端口；LoadBalancer 依赖云厂商创建外部负载均衡器。实际生产常用 ClusterIP+Ingress 或 LoadBalancer。”
可能追问：“Headless Service 有什么用？”“当 Service 后端 Pod 数量变化时，iptables 规则如何更新？”
⚠️ 避坑提醒：不要只说“Service 提供稳定 IP”，还需说明对 Pod 重启后 IP 变化如何屏蔽。NodePort 端口范围默认 30000-32767，不要记错。
📌 问题3：Deployment 如何实现滚动更新和回滚？更新策略参数 (maxSurge / maxUnavailable) 的作用是什么？
面试官考察点：检验你对控制器模式、ReplicaSet 管理、滚动更新安全性的实际理解。
回答框架：Deployment 是什么 → 底层 ReplicaSet 关系 → 滚动更新过程（创建新 RS，逐步调整副本） → 参数配置（maxSurge、maxUnavailable） → 回滚原理（RevisionHistoryLimit）。
示例回答：“Deployment 通过 ReplicaSet 管理 Pod 副本。更新时创建新 RS，逐步增加新 Pod 同时删除旧 Pod，由 maxSurge（最多超出的实例数）和 maxUnavailable（最多不可用实例数）控制速率。回滚时直接切换到旧 RS 版本，保留历史版本数量由 revisionHistoryLimit 控制。”
可能追问：“如果新的 Pod 一直处于 CrashLoopBackOff，滚动更新会停止吗？”“如何实现金丝雀发布？”
⚠️ 避坑提醒：不要忘记提及 ReplicaSet 作为中间层；默认策略是 RollingUpdate，但状态检查依赖于 Readiness Probe，配置不当会导致流量中断。
项目案例模板
| 维度 | 内容 |
|---|---|
| 项目名称 | 微服务全容器化迁移与统一网关接入 |
| 业务背景 | 某电商平台从传统 VM 部署迁移至 Kubernetes，并建立统一的 Ingress 网关用于流量治理。 |
| 规模指标 | 30+ 微服务，200+ Pod，每日千万级请求；跨 3 个可用区部署。 |
| 技术栈 | Kubernetes 1.24 + Nginx Ingress Controller + Calico CNI + Prometheus |
| 核心难点 | ① 存量有状态服务（Redis、MySQL）迁移方案；② Ingress 路由规则杂乱，路径冲突频发；③ 滚动更新时服务短暂不可用。 |
| 面试高频追问 | “你们如何处理有状态服务在 Kubernetes 中的高可用？”“Ingress 限流和鉴权如何实现？”“出现了集群 DNS 解析延迟，怎么排查？” |
| 可迁移回答话术 | “有状态服务我们用 StatefulSet + 本地存储或 HostPath，并通过 Headless Service 实现稳定 DNS 解析。Ingress 层面我们在 controller 层配置全局限流中间件，同时利用 Annotation 按路由设置限流阈值。DNS 延迟问题通过调整 CoreDNS 的本地缓存、以及部署 node-local-dns 延迟从秒级降到毫秒级。” |
学习建议：本章所有概念均可在 kubectl explain 中查看详细 API 字段。面试前务必亲手部署一个包含 Deployment + Service + Ingress 的完整应用，并模拟滚动更新和回滚操作，加深对参数影响的实际体验。