第2章 Kubernetes核心概念高频问答
本章聚焦 Pod、Deployment、Service、Ingress 四大核心资源的面试高频问题。大厂面试不仅考察定义，更关注你能否清晰阐述资源之间的关系、工作原理、典型场景及常见坑点。下面通过回答框架图、对比表和问答卡片，帮助你建立结构化的应答思维。
核心资源对比表
| 资源 | 功能定位 | API 版本 | 关键字段 | 常见面试点 |
|---|---|---|---|---|
| Pod | 最小调度单元，包含一个或多个容器 | v1 | containers, volumes, restartPolicy | 生命周期、探针、资源限制 |
| Deployment | 声明式管理 Pod 副本，支持滚动更新和回滚 | apps/v1 | replicas, strategy, revisionHistoryLimit | 更新策略、回滚机制、副本管理 |
| Service | Pod 稳定的网络访问入口，提供负载均衡 | v1 | type, selector, ports, clusterIP | Service 类型、DNS 解析、Endpoint 更新机制 |
| Ingress | 7 层 HTTP/HTTPS 路由，暴露集群外部服务 | networking.k8s.io/v1 | rules, tls, ingressClassName, annotations | Ingress Controller 实现、host 路由、TLS 配置 |
问答1：Pod 的生命周期是如何管理的？
🎯 面试官考察点
验证对 Pod 状态机、重启策略、探针（Probe）及 Pod 终态的理解深度，是否清楚异常场景下的处理流程。
🧠 回答框架
1. 状态流转：Pending → Running → Succeeded/Failed 等。
2. 重启策略：Always/OnFailure/Never 对 Pod 行为的影响。
3. 探针：liveness/readiness/startup 的作用与配置要点。
4. 终止流程：preStop hook、terminationGracePeriodSeconds。
💬 示例回答（80字）
“Pod 生命周期包括 Pending（调度）、Running（运行）、Failed（失败）等状态。kubelet 根据 restartPolicy 决定是否重启容器。通过 livenessProbe 检测容器是否存活，readinessProbe 控制 Service 流量接入。终止时执行 preStop hook，等待 grace period 后发送 SIGTERM。”
（适合面试中口述，清晰覆盖全流程）
🔍 可能追问
• 如何让 Pod 优雅退出？
• Pod 处于 CrashLoopBackOff 时你会排查哪些日志？
• startupProbe 和 livenessProbe 的区别是什么？
问答2：Deployment 的滚动更新策略如何配置？如何实现零停机发布？
🎯 面试官考察点
考察对 Deployment 更新模型（RollingUpdate vs Recreate）、maxSurge/maxUnavailable 含义、HPA 联动、版本控制（revisionHistory）以及金丝雀/蓝绿部署的扩展理解。
🧠 回答框架
1. 更新策略：strategy.type = RollingUpdate 或 Recreate。
2. 参数：maxSurge（超出期望副本数上限）和 maxUnavailable（不可用副本数上限）控制速率。
3. 回滚：kubectl rollout undo，保留 history 数量由 revisionHistoryLimit 决定。
4. 零停机要点：readinessProbe 保证新 Pod 就绪后再切换流量；配合 PodDisruptionBudget（PDB）避免中断。
💬 示例回答（90字）
“Deployment 默认使用 RollingUpdate 策略。通过 maxSurge=25% 和 maxUnavailable=25% 控制更新速率，确保不中断服务。新 Pod 创建后等待 readinessProbe 通过才加入 Service。若新版异常，执行 kubectl rollout undo 快速回滚。结合 PDB 可进一步提升稳定性。”
（体现策略参数和实际落地）
🔍 可能追问
• Deployment 更新过程中旧的 ReplicaSet 是否会被删除？
• 如何实现分批发布（金丝雀）？
• 回滚时如何控制回滚版本？
问答3：Service 和 Ingress 有什么区别？如何选择？
🎯 面试官考察点
辨析 Service 四种类型（ClusterIP/NodePort/LoadBalancer/ExternalName）与 Ingress 的定位差异，理解四层 vs 七层、集群内部 vs 外部流量、负载均衡粒度、成本与扩展性。
🧠 回答框架
1. 层次：Service 四层（TCP/UDP），Ingress 七层（HTTP/HTTPS）。
2. 功能：Service 提供稳定 VIP 和 DNS，供集群内部或外部访问；Ingress 提供基于 host/path 的路由、TLS 终结、虚拟主机。
3. 实现依赖：Service 是 Kubernetes 内置资源，Ingress 需要 Ingress Controller（如 Nginx/ALB）。
4. 选择场景：简单端口暴露用 NodePort/LoadBalancer；复杂 HTTP 路由用 Ingress。
💬 示例回答（100字）
“Service 是四层抽象，提供 ClusterIP/NodePort/LoadBalancer 三种外部访问方式，适合 TCP/UDP 流量。Ingress 工作在七层，依赖 Ingress Controller，能根据域名和路径分发 HTTP 请求、管理 SSL 证书、实现虚拟主机。若只需暴露单个端口，用 NodePort 即可；若需基于 host 路由多个服务，选 Ingress。”
（对比清晰，点出核心差异和实际选型）
🔍 可能追问
• 同一个 Service 可以同时使用 NodePort 和 LoadBalancer 吗？
• Ingress 如何实现灰度发布（基于 Header/Cookie）？
• ClusterIP 模式的 Service 如何通过 DNS 被 Pod 解析？
高频追问路径示例：Pod 相关问题
• 字节跳动/阿里：热衷于追问 Pod 资源限制与 QoS 等级对调度的影响，以及 Deployment 滚动更新时如何保证流量无损。
• 腾讯/美团：关注 Ingress 多环境路由策略、Service 的流量拓扑（Topology Aware Routing）、以及 StatefulSet 与 Deployment 的选择依据。
• Google/CoreOS 系：偏好从底层实现问起，例如 kube-proxy 的 iptables 模式 vs IPVS 模式、EndpointSlice 演进等。