一、为什么大厂面试都在问 K8s云原生已经成为互联网公司的基础设施Kubernetes 也从早期的“加分项”变成后端、运维、平台研发岗位的“默认能力”。大厂面试不会只问“K8s 是什么”而是会沿着一条主线层层追问Pod 为什么是调度的最小单位Service 怎样实现稳定访问一个请求从 Ingress 到业务 Pod 的全链路是什么。理解这些问题的本质才能在面试中从“背概念”切换到“讲原理”。本文按面试出现频率和深度从基础概念、核心对象、调度、网络、存储、安全到故障排查系统梳理大厂 K8s 面试的高频考点。建议先建立整体地图再针对目标岗位深入细节。全文提纲K8s 基础概念与架构Pod最小调度单元控制器与工作负载Service 与集群网络存储与持久化调度、资源与弹性安全与权限故障排查与高频追问总结与面试准备建议二、K8s 基础概念与架构2.1 什么是 KubernetesKubernetes 是一个开源的容器编排平台负责容器化应用的自动部署、弹性伸缩、滚动更新、服务发现和故障自愈。它把一组机器抽象成统一的资源池让应用声明“期望状态”由控制面持续调谐使实际状态不断逼近期望状态。面试时建议用一句话先给出定位K8s 是容器编排系统核心是“声明式管理 控制器调谐”而不是简单说“管理 Docker 的工具”。2.2 Master/Worker 架构K8s 集群分为控制平面和计算节点两部分。控制平面负责全局决策和状态管理计算节点负责真正运行业务负载。组件所属平面核心职责kube-apiserver控制平面所有操作的统一入口暴露 REST API负责认证、鉴权、准入控制etcd控制平面分布式 KV 存储保存集群全部状态和配置kube-scheduler控制平面负责 Pod 调度为新 Pod 选择合适节点kube-controller-manager控制平面运行各类控制器维持副本数、节点状态、服务账号等期望状态kubelet计算节点接收 Pod 定义管理容器生命周期向 apiserver 上报节点状态kube-proxy计算节点维护节点网络规则实现 Service 流量转发Container Runtime计算节点通过 CRI 提供容器运行环境如 containerd、CRI-O2.3 声明式 API 与控制循环用户通过 YAML 或 JSON 描述期望状态提交给 apiserver 后写入 etcd。各类控制器通过 watch 机制感知对象变化比较“期望状态”与“实际状态”并执行调谐动作。这个调谐过程通常被称为Reconcile Loop。可以这样回答控制面永远不关心“具体某一步怎么执行”只关心“当前是不是期望的样子”如果不一致就调整。这种思想也延伸到 Operator 和 GitOps。三、Pod最小调度单元3.1 Pod 的设计原因Pod 是一组共享网络命名空间、IPC 命名空间和存储卷的容器集合。把容器作为最小单元会导致共享资源和生命周期绑定困难因此 K8s 用 Pod 把关系紧密的容器组合起来。常见追问为什么不直接调度容器核心原因是有些容器天生需要共享 localhost、共享文件卷或强生命周期绑定例如业务容器和日志 sidecar、业务容器和 localhost 流量代理。Pod 让这些容器“同生共死、同时调度”。3.2 Pod 生命周期Pod 的主要阶段包括 Pending、Running、Succeeded、Failed、Unknown。需要注意的是Pod Phase 描述的是整体状态不等于容器状态一个 Running 的 Pod 内部可能仍有容器处于重启中。3.3 Init 容器与 SidecarInit 容器在业务容器启动前顺序执行常用于初始化配置、等待依赖就绪、修改权限等。Sidecar 则与主容器并行运行承担日志采集、代理转发、监控等增强能力。面试时可以用“初始化任务”和“持续伴随任务”来区分二者。一个常见考点是Init 容器执行成功后才会启动主容器如果 Init 容器反复失败Pod 会一直无法进入 Running。3.4 健康检查探针用途失败后的处理livenessProbe判断容器是否存活失败后按重启策略重启容器readinessProbe判断容器是否能接收流量失败后从 Service 后端摘除不重启容器startupProbe保护启动较慢的应用成功前禁用其他探针避免误杀四、控制器与工作负载4.1 ReplicaSet 与 DeploymentReplicaSet 保证任意时刻有指定数量的 Pod 副本在运行Deployment 在 ReplicaSet 之上提供声明式更新、回滚和扩缩容能力。平时讨论的“应用版本升级”本质上由 Deployment 创建新 ReplicaSet 并逐步切换流量。滚动更新的核心流程是创建新 ReplicaSet按maxSurge增加新 Pod按maxUnavailable减少旧 Pod最终新 ReplicaSet 完全接管。4.2 StatefulSetStatefulSet 适用于有状态应用为每个 Pod 提供稳定的网络标识和持久存储。它按序号创建 Pod如mysql-0、mysql-1并配合无头 Service 让客户端按固定 DNS 访问特定实例。面试高频题Deployment 和 StatefulSet 的区别。要点是稳定身份、部署顺序、持久卷绑定方式和更新策略不同。4.3 DaemonSetDaemonSet 保证每个节点运行一个 Pod 副本常用于日志采集、节点监控和网络组件。新增节点时会自动补充 Pod。4.4 Job 与 CronJobJob 保证任务执行到指定成功次数才结束CronJob 在 Job 之上增加定时触发能力。遇到批处理、数据清洗、定时备份、报表生成等一次性或周期性任务时优先选择 Job 和 CronJob而不是让 Deployment 常驻。Job 需要重点理解restartPolicy、backoffLimit和completions的含义CronJob 还要关注schedule、startingDeadlineSeconds和concurrencyPolicy避免任务重复执行或错过调度窗口。五、Service 与集群网络5.1 为什么需要 ServicePod IP 会随重建而改变直接依赖 Pod IP 会让客户端频繁失效。Service 通过一组 Label Selector 选中后端 Pod并提供一个稳定的虚拟 IP 和 DNS 名称实现负载均衡和服务发现。面试高频题Service 和 Pod 是什么关系可以这样回答Service 是“稳定的访问入口”Pod 是“背后可替换的实例”二者通过标签选择器解耦。5.2 Service 类型类型访问范围典型场景ClusterIP集群内部服务间调用默认类型NodePort节点 IP 固定端口临时暴露、测试、简单外部访问LoadBalancer云厂商负载均衡器生产环境对外暴露ExternalNameDNS CNAME指向集群外部服务5.3 kube-proxy 与转发模式kube-proxy 负责在节点上维护 Service 的转发规则。早期常用 iptables 模式通过规则链实现 DNAT规则少时性能尚可当 Service 数量很大时IPVS 模式基于内核 LVS 实现哈希查找性能更好并支持多种负载均衡算法。追问点iptables 是逐条链匹配规则多了会有性能问题IPVS 使用哈希表更适合大规模集群。5.4 Ingress 与 Ingress ControllerService 主要解决四层流量转发当需要基于域名、路径做七层路由、TLS 终止、灰度发布时使用 Ingress。Ingress 只是路由规则对象真正处理流量的是 Ingress Controller如 ingress-nginx、Traefik。面试常用链路客户端请求经过 DNS 解析到负载均衡器再由 Ingress Controller 根据 Host 和 Path 路由到 Service最终到达后端 Pod。六、存储与持久化6.1 Volume、PV 与 PVC容器文件系统是临时的Pod 重启后数据可能丢失。K8s 通过 Volume 挂载共享存储。为了把存储供给和使用解耦引入 PV持久卷由管理员准备和 PVC持久卷声明由用户申请控制器会按容量、访问模式等条件完成绑定。访问模式常见有 ReadWriteOnce、ReadOnlyMany、ReadWriteMany绑定时要关注存储后端是否支持对应模式。6.2 StorageClass 与动态供给手动创建 PV 管理成本高StorageClass 可以按需动态创建存储例如基于云盘或 NFS Provisioner。PVC 指定storageClassName后Provisioner 会自动创建匹配的 PV实现存储即取即用。6.3 ConfigMap 与 SecretConfigMap 保存非敏感配置Secret 保存密码、Token、证书等敏感信息。两者都可以通过环境变量、命令行参数或 volume 挂载注入 Pod。ConfigMap 更新后通过 volume 挂载的文件通常会定时刷新但环境变量方式不会自动更新。七、调度、资源与弹性7.1 调度基本流程kube-scheduler 监听尚未绑定节点的 Pod先经过过滤阶段选出可运行节点再经过打分阶段选出最优节点最后完成节点绑定。过滤主要看资源是否满足、节点是否健康、污点和容忍是否匹配打分主要看资源均衡、亲和性等。7.2 亲和性、污点与容忍nodeSelector 只能做简单相等匹配亲和性支持更丰富的调度偏好。nodeAffinity 约束 Pod 倾向哪些节点podAffinity 和 podAntiAffinity 让 Pod 之间靠近或远离。污点给节点打标记只有带有匹配容忍的 Pod 才能调度上去常用于资源隔离和专用节点。7.3 资源请求与限制requests 是调度依据limits 是容器可用资源上限。CPU 是可压缩资源超限会被节流内存是不可压缩资源超限会被 OOMKill。根据 requests 和 limits 的设置Pod 被分为 Guaranteed、Burstable、BestEffort 三种 QoS节点资源紧张时 BestEffort 最先被驱逐。7.4 HPA 与集群弹性HPA 根据 CPU、内存或自定义指标自动调整 Deployment 副本数VPA 调整 Pod 的 requests 和 limitsCluster Autoscaler 在节点资源不足时自动扩容节点。三者分工不同HPA 管副本数、VPA 管资源规格、CA 管节点数量。八、安全与权限8.1 RBACRBAC 通过 Role 和 ClusterRole 定义权限集合再通过 RoleBinding 和 ClusterRoleBinding 把权限授予用户、组或 ServiceAccount。Role 是命名空间级ClusterRole 是集群级。面试时要能说清 verbs、resources、apiGroups 三个要素。8.2 ServiceAccount 与 SecurityContextPod 运行时默认挂载命名空间下的 default ServiceAccount其 Token 用于访问 apiserver。SecurityContext 可以在 Pod 或容器级别设置运行用户、特权模式、只读根文件系统、capabilities 等帮助实现最小权限原则。8.3 NetworkPolicyK8s 默认 Pod 之间网络互通NetworkPolicy 基于 podSelector、namespaceSelector、ipBlock 定义允许的入站和出站流量实现东西向流量的最小化访问控制。它需要 CNI 插件支持如 Calico、Cilium。九、故障排查与高频追问9.1 排查主线和常用命令排查顺序通常是kubectl get -o wide看状态kubectl describe看事件kubectl logs看日志必要时kubectl exec进入容器验证。要把这条主线熟记避免面试时只会说“看日志”。状态常见原因排查方向Pending资源不足、镜像拉取慢、污点不匹配describe 看 events检查节点资源和污点CrashLoopBackOff应用启动失败、探针配置不当logs 看启动错误检查命令和环境变量ImagePullBackOff镜像名称错误、仓库鉴权失败检查 image 地址和 imagePullSecretsTerminating 卡住finalizer 未完成、进程不响应 SIGTERM检查 finalizer 和 terminationGracePeriodSeconds9.2 PID 1 与优雅退出容器停止时 kubelet 先发 SIGTERM超过terminationGracePeriodSeconds后再发 SIGKILL。如果容器内 PID 1 是 shell可能无法正确向子进程转发信号导致优雅退出失效建议使用 exec 形式启动或借助 init 系统处理信号。9.3 面试高频追问清单一个 Pod 创建后从提交到运行的完整流程是什么Service 的 ClusterIP 是真实网卡上的 IP 吗为什么 ping 不通Deployment 滚动更新期间流量会不会中断为什么同样的镜像在本地能跑在 K8s 里启动就失败节点 NotReady、Pod 被驱逐要如何定位十、总结与面试准备建议K8s 面试的底层逻辑不是考察 YAML 记忆力而是考察对“声明式状态、控制器调谐、稳定网络入口、调度决策、存储解耦和安全边界”的理解程度。回答时建议先给结论再展开机制最后落到故障表现或最佳实践。准备顺序建议先把 Pod、Deployment、Service、Ingress、PV/PVC、RBAC 这条主线吃透再补充调度、探针、污点容忍和排障命令遇到不确定的问题可以主动说明“实际生产中我会先看 events 和 logs 来定位”展现排查思路。