企业官网建设流程全解析

一、为什么大厂面试都在问 K8s

云原生已经成为互联网公司的基础设施，Kubernetes 也从早期的“加分项”变成后端、运维、平台研发岗位的“默认能力”。大厂面试不会只问“K8s 是什么”，而是会沿着一条主线层层追问：

• Pod 为什么是调度的最小单位；

• Service 怎样实现稳定访问；

• 一个请求从 Ingress 到业务 Pod 的全链路是什么。

理解这些问题的本质，才能在面试中从“背概念”切换到“讲原理”。

本文按面试出现频率和深度，从基础概念、核心对象、调度、网络、存储、安全到故障排查，系统梳理大厂 K8s 面试的高频考点。建议先建立整体地图，再针对目标岗位深入细节。

全文提纲：

1. K8s 基础概念与架构

2. Pod：最小调度单元

3. 控制器与工作负载

4. Service 与集群网络

5. 存储与持久化

6. 调度、资源与弹性

7. 安全与权限

8. 故障排查与高频追问

9. 总结与面试准备建议

二、K8s 基础概念与架构

2.1 什么是 Kubernetes

Kubernetes 是一个开源的容器编排平台，负责容器化应用的自动部署、弹性伸缩、滚动更新、服务发现和故障自愈。它把一组机器抽象成统一的资源池，让应用声明“期望状态”，由控制面持续调谐，使实际状态不断逼近期望状态。

面试时建议用一句话先给出定位：K8s 是容器编排系统，核心是“声明式管理 + 控制器调谐”，而不是简单说“管理 Docker 的工具”。

2.2 Master/Worker 架构

K8s 集群分为控制平面和计算节点两部分。控制平面负责全局决策和状态管理，计算节点负责真正运行业务负载。

2.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 容器与 Sidecar

Init 容器在业务容器启动前顺序执行，常用于初始化配置、等待依赖就绪、修改权限等。Sidecar 则与主容器并行运行，承担日志采集、代理转发、监控等增强能力。面试时可以用“初始化任务”和“持续伴随任务”来区分二者。

一个常见考点是：Init 容器执行成功后才会启动主容器；如果 Init 容器反复失败，Pod 会一直无法进入 Running。

3.4 健康检查

四、控制器与工作负载

4.1 ReplicaSet 与 Deployment

ReplicaSet 保证任意时刻有指定数量的 Pod 副本在运行；Deployment 在 ReplicaSet 之上提供声明式更新、回滚和扩缩容能力。平时讨论的“应用版本升级”，本质上由 Deployment 创建新 ReplicaSet 并逐步切换流量。

滚动更新的核心流程是：创建新 ReplicaSet，按maxSurge增加新 Pod，按maxUnavailable减少旧 Pod，最终新 ReplicaSet 完全接管。

4.2 StatefulSet

StatefulSet 适用于有状态应用，为每个 Pod 提供稳定的网络标识和持久存储。它按序号创建 Pod，如mysql-0、mysql-1，并配合无头 Service 让客户端按固定 DNS 访问特定实例。

面试高频题：Deployment 和 StatefulSet 的区别。要点是稳定身份、部署顺序、持久卷绑定方式和更新策略不同。

4.3 DaemonSet

DaemonSet 保证每个节点运行一个 Pod 副本，常用于日志采集、节点监控和网络组件。新增节点时会自动补充 Pod。

4.4 Job 与 CronJob

Job 保证任务执行到指定成功次数才结束；CronJob 在 Job 之上增加定时触发能力。遇到批处理、数据清洗、定时备份、报表生成等一次性或周期性任务时，优先选择 Job 和 CronJob，而不是让 Deployment 常驻。

Job 需要重点理解restartPolicy、backoffLimit和completions的含义；CronJob 还要关注schedule、startingDeadlineSeconds和concurrencyPolicy，避免任务重复执行或错过调度窗口。

五、Service 与集群网络

5.1 为什么需要 Service

Pod IP 会随重建而改变，直接依赖 Pod IP 会让客户端频繁失效。Service 通过一组 Label Selector 选中后端 Pod，并提供一个稳定的虚拟 IP 和 DNS 名称，实现负载均衡和服务发现。

面试高频题：Service 和 Pod 是什么关系？

可以这样回答：Service 是“稳定的访问入口”，Pod 是“背后可替换的实例”，二者通过标签选择器解耦。

5.2 Service 类型

5.3 kube-proxy 与转发模式

kube-proxy 负责在节点上维护 Service 的转发规则。早期常用 iptables 模式，通过规则链实现 DNAT，规则少时性能尚可；当 Service 数量很大时，IPVS 模式基于内核 LVS 实现哈希查找，性能更好，并支持多种负载均衡算法。

追问点：iptables 是逐条链匹配，规则多了会有性能问题；IPVS 使用哈希表，更适合大规模集群。

5.4 Ingress 与 Ingress Controller

Service 主要解决四层流量转发；当需要基于域名、路径做七层路由、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 与 Secret

ConfigMap 保存非敏感配置，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 和 limits；Cluster Autoscaler 在节点资源不足时自动扩容节点。

三者分工不同：HPA 管副本数、VPA 管资源规格、CA 管节点数量。

八、安全与权限

8.1 RBAC

RBAC 通过 Role 和 ClusterRole 定义权限集合，再通过 RoleBinding 和 ClusterRoleBinding 把权限授予用户、组或 ServiceAccount。

Role 是命名空间级，ClusterRole 是集群级。面试时要能说清 verbs、resources、apiGroups 三个要素。

8.2 ServiceAccount 与 SecurityContext

Pod 运行时默认挂载命名空间下的 default ServiceAccount，其 Token 用于访问 apiserver。

SecurityContext 可以在 Pod 或容器级别设置运行用户、特权模式、只读根文件系统、capabilities 等，帮助实现最小权限原则。

8.3 NetworkPolicy

K8s 默认 Pod 之间网络互通，NetworkPolicy 基于 podSelector、namespaceSelector、ipBlock 定义允许的入站和出站流量，实现东西向流量的最小化访问控制。

它需要 CNI 插件支持，如 Calico、Cilium。

九、故障排查与高频追问

9.1 排查主线和常用命令

排查顺序通常是：

1. kubectl get -o wide看状态；

2. kubectl describe看事件；

3. kubectl logs看日志；

4. 必要时kubectl exec进入容器验证。

要把这条主线熟记，避免面试时只会说“看日志”。

9.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 记忆力，而是考察对“声明式状态、控制器调谐、稳定网络入口、调度决策、存储解耦和安全边界”的理解程度。

回答时建议先给结论，再展开机制，最后落到故障表现或最佳实践。

准备顺序建议：

1. 先把 Pod、Deployment、Service、Ingress、PV/PVC、RBAC 这条主线吃透；

2. 再补充调度、探针、污点容忍和排障命令；

3. 遇到不确定的问题，可以主动说明“实际生产中我会先看 events 和 logs 来定位”，展现排查思路。