Kubernetes平台工程师面试宝典 - 第4节

## 章节导入 Kubernetes 核心概念是面试的**必考点**，各大厂（字节、阿里、腾讯、美团）通常从 **“基础概念 + 场景辨析”** 两个维度考察。 面试官希望看到你不仅知道“Pod 是什么”，更能讲清 **Deployment、Service、Ingress、ConfigMap 如何协同**，以及**为什么这样设计**。 本章围绕 **5 个核心资源**，提炼出 **3 个高频面试问答卡片**，覆盖底层原理、实际用法、常见陷阱。 --- ## 公司侧重点 & 面试官画像 | 公司类型 | 侧重点 | 典型问题 | |---------|--------|----------| | 字节跳动 | 大规模集群的 Pod 调度、资源管理、ConfigMap 热更新 | “1000 个 Pod 同时重启，ConfigMap 更新会怎样？” | | 阿里巴巴 | 多集群、Service 网络、Ingress 流量治理 | “Deployment 滚动更新时，Service 如何保证流量不中断？” | | 腾讯 | 容器化迁移、传统架构适配 | “请你设计一个业务迁移到 K8s 的 Pod 配置方案” | | 美团 | 稳定性、故障排查 | “Pod 一直 Pending 怎么排查？跟哪些资源有关？” | **面试官画像**： 多为 3~5 年经验的 SRE / 平台架构师，**重视逻辑清晰 + 原理深度**，不喜欢“背文档”。他们更关注你能否用**一句话讲清本质**，以及**遇到异常如何分层定位**。 --- ## 核心概念关系图（回答框架） > **面试回答框架**：先一句话定义资源，再说**它解决了什么问题**，最后给出**实际场景举例 + 一句话避坑**。 --- ## 问答卡片 1：Pod ### 面试问题 **“Pod 是 K8s 中最小的调度单元，请解释 Pod 的设计理念，并举例说明什么时候需要在一个 Pod 里运行多个容器？”** ### 考察点 - 是否理解 Pod 的**网络/存储共享**模型 - 对 **Sidecar 模式** 的实战认知 - 区分“一个 Pod 多个容器”与“多个 Pod”的决策依据 ### 回答框架 1. **本质**：Pod 是共享网络命名空间（IP+端口）和存储卷的容器集合。 2. **多容器场景**：主容器 + 辅助容器（日志收集、代理、配置更新器）。 3. **决策标准**：两个容器是否需要**同时调度、共享生命周期、通过 localhost 通信**？是则放一个 Pod。 ### 简短示例回答 > “Pod 是容器集合单元，内部容器共享网络和存储。例如在 Istio 中，业务容器 + Envoy Sidecar 共享网络，Envoy 拦截进出流量实现服务治理。如果不需要共享生命周期，应该使用多个 Pod。” ### 可能追问 - “Pod 的 pause 容器是什么作用？” - “Pod 终止时，容器终止顺序是怎样的？” - “如何保证 Pod 在节点故障时自动恢复？” ### 避坑提醒 --- ## 问答卡片 2：Deployment & Service ### 面试问题 **“Deployment 滚动更新时，如何确保 Service 流量不中断？请说明 Deployment 的 maxSurge / maxUnavailable 参数设计和 Service 就绪探针的关系。”** ### 考察点 - 是否理解 **Deployment 滚动更新 + Service 负载均衡** 的协作机制 - 就绪探针（readinessProbe）的作用 - maxSurge / maxUnavailable 对流量中断的影响 ### 回答框架 1. **核心**：Deployment 用 **ReplicaSet** 控制新旧 Pod 数量，Service 只将流量转发给 **Ready** 的 Pod。 2. **关键参数**：`maxSurge`（可超过期望数的 Pod 数）和 `maxUnavailable`（最大不可用数）。 3. **就绪探针**：新 Pod 必须通过 readinessProbe 才会加入 Service Endpoint。 4. **不断流保证**：保证 `maxUnavailable` = 0 或 `maxSurge` > 0，且每一步都保留足够 Ready Pod。 ### 简短示例回答 > “设置 `maxSurge: 25%`、`maxUnavailable: 25%`，加上 readinessProbe 检测 `/healthz`。滚动更新时先启动新 Pod，待其就绪后再停止旧 Pod，Service 自动切换，流量不中断。” ### 可能追问 - “如果 readinessProbe 返回失败，Deployment 会怎么办？” - “Deployment 回滚时，Service 需要做什么？” - “Headless Service 什么时候用？” ### 避坑提醒 --- ## 问答卡片 3：Ingress & ConfigMap ### 面试问题 **“Ingress 和 Service 有什么区别？当配置下发到 Pod 后，ConfigMap 如何实现热更新？热更新有哪些限制？”** ### 考察点 - Ingress 是 **七层** 路由，Service 是 **四层** 流量分发 - ConfigMap 热更新机制（挂载 vs 环境变量） - 热更新的局限性和风险 ### 回答框架 1. **Ingress vs Service**：Service 提供集群内或 NodePort 的 L4 转发；Ingress 是 L7 入口控制器，基于域名/path 路由到不同 Service。 2. **ConfigMap 热更新**： - 通过 **Volume 挂载**：更新 ConfigMap 后，Pod 内文件自动同步（有延时～10s）。 - 通过 **环境变量**：**不支持热更新**，需要重建 Pod。 3. **限制**：应用本身需要监控文件变化或支持 reload；同步延迟导致短暂不一致。 ### 简短示例回答 > “Ingress 是七层反向代理，比如 NGINX Ingress Controller 根据 `Host: api.example.com` 路由到内部 Service。ConfigMap 挂载为卷时，更新后 Pod 内符号链接更新，但应用需要自行监听文件变化，如 Nginx 可配合 `reload`。环境变量方式无法热更新，必须 rollout restart。” ### 可能追问 - “ConfigMap 的同步延迟来源是什么（kubelet 缓存周期）？” - “Ingress 的 annotation 可以配置哪些高级功能（限流、重写路径）？” - “ConfigMap 和 Secret 的区别是什么？” ### 避坑提醒 --- ## 本章小结 | 核心资源 | 一句话本质 | 面试高频考点 | |---------|-----------|-------------| | **Pod** | 共享网络/存储的容器组 | Sidecar 模式、pause 容器、生命周期 | | **Deployment** | 声明式管理 Pod 副本与滚动更新 | maxSurge/maxUnavailable、回滚策略 | | **Service** | 稳定的四层访问入口 | 标签选择器、ClusterIP/NodePort/LB | | **Ingress** | 七层域名/路径路由 | 与 Service 关系、Controller 选型 | | **ConfigMap** | 注入配置到 Pod | 热更新机制（挂载 vs 环境变量） | > **准备方向**： > - 动手写一个 YAML，能解释每个字段含义。 > - 准备 2-3 个真实踩坑经历（如 ConfigMap 热更新不生效、滚动更新时 readinessProbe 超时）。 > - 对比不同云厂商 Ingress Controller（ALB Ingress vs NGINX Ingress vs Istio Gateway）。