企业官网建设流程全解析

1. 从“一堆机器”到“一个集群”的关键一跃

接触K8s（Kubernetes）的人经常会遇到一道坎：单看每个组件的文档都认识，但合在一起就懵了——apiserver 是干嘛的？etcd 存了什么？kubelet 和 kube-proxy 都在节点上跑，不都是“agent”吗，为啥要分两个？如果你也有这种感觉，这篇文章就是写给你看的。

先说清楚要聊的这件事本身。K8s 架构的底层逻辑，一句话就能概括：把“管理集群的大脑”和“真正干活的手脚”彻底分开。控制平面（Control Plane）负责做决策——调度、状态维护、故障响应；工作节点（Worker Node）负责执行——运行容器、维护运行时状态、处理访问流量。两者之间通过 API 通信，这套机制就是 K8s 被称为“云原生操作系统”的根本原因。

这套架构解决的核心问题是什么？其实就是把分布式系统的运维复杂度做了一次“集中化抽象”。打个比方，你有个 100 台机器的集群，如果靠 SSH 登录每台机器去装容器、配网络、盯监控，那基本就是原始人生活。K8s 做的事，是让你通过一条kubectl命令行，就能对整个集群“发号施令”，而具体每台机器怎么执行、执行得怎么样，全由控制平面去调度、去监督、去纠偏。

适合谁来读这篇文章？两类人：

• 刚学完docker run、docker compose，想知道“上生产环境之后容器多了怎么管”的开发者；
• 已经在用 K8s 做一些基本部署（Deployment、Service），但遇到问题（比如 Pod 一直 Pending、节点 NotReady）时只能搜谷歌、没法从根因推理的运维同学。

我尽量用大白话把这些组件的协作机制讲透，尤其是一些细节——比如为什么 etcd 不能丢、为什么 kubelet 上报状态会出现“延迟”、为什么 Service 的负载均衡在 iptables 模式下有性能坑——这些都是实战中真正会绊倒人的地方。

2. 集群整体架构的设计思路：为什么非要分“大脑”和“手脚”

2.1 控制平面与工作节点：一张拓扑图理清全部角色

一个标准 K8s 集群，按角色分两大类节点，这是理解一切的基础：

这两类节点之间是严格的“命令—执行”关系。控制平面不会直接去操作容器，它只做三件事：

1. 维护集群期望状态（写入 etcd）；
2. 监听实际状态（通过各组件上报）；
3. 当期望状态和实际状态不一致时，发出调整指令。

工作节点上的 kubelet 则是那个“唯一对接控制平面”的本地代理。控制平面下达的指令（比如“在你这台机器上启动一个 Nginx 容器”），最终只有 kubelet 能理解和执行。而 kube-proxy 则承担了另一件核心事：把访问 Service 的流量按规则转发到后端的某个 Pod 上，它不是跑业务容器的，它是流量转发的“守门员”。

2.2 为什么这套架构能扛住生产环境

很多人第一次接触这个架构时会觉得啰嗦——做个容器编排而已，为啥搞五个控制面组件？这不显得很重吗？

重量是有原因的。生产环境最大的噩梦不是“功能做不出来”，而是“节点挂了、网络断了、状态不一致了”之后整个集群雪崩。K8s 把每个职责单独拆成一个组件，本质上是在做故障隔离。apiserver 挂了不会影响已运行容器继续工作（但调度会停摆）；etcd 短暂不可用不会导致现有 Pod 被杀掉；controller-manager 重启也不会破坏集群的已有状态。

这套“组件各司其职、状态单独存储、通过 API 通信”的设计，让大规模生产集群在局部故障时不至于整体瘫痪。用生活化类比来说：前台的客服（apiserver）只负责接单派单，档案管理员（etcd）只负责存档，调度员（scheduler）只负责安排工位，监工（controller-manager）只负责盯进度，底下的工人（kubelet）只负责干自己厂区的活——哪一环出了问题，替换哪一环，而不会让整条流水线停摆。

2.3 理解这套架构的“第一性原理”：声明式 API

想真正读懂 K8s 架构，绕不开的一个概念是“声明式 API”。它的意思是：你只需要告诉集群“我要什么”（期望状态），而不需要告诉它“怎么做到”（具体步骤）。比如你写一个 Deployment YAML，里面说“我要 3 个副本、镜像是 Nginx:1.25”，K8s 就负责自己琢磨怎么拉镜像、怎么调度到节点、怎么保持 3 个存活。

这个理念贯穿了所有组件的设计。控制平面各组件之间的协作，本质上都是围绕“期望状态”和“实际状态”的对比来驱动的。这也是为什么 K8s 的学习曲线这么陡峭——因为你得改变自己的思维模式，从“命令机器做事”切换到“告诉机器要什么结果”。理解了这一点，再看后续控制平面各组件如何各司其职，就会顺理成章得多。

3. 控制平面四个组件逐个拆解：集群的“大脑”内部长什么样

前面把架构整体逻辑理清楚了，接下来把目光聚焦到控制平面本身。它部署在 Master 节点上（生产环境通常至少 3 个 Master 做高可用），由四兄弟组成：etcd、kube-apiserver、kube-scheduler、kube-controller-manager。这四个组件各管一摊，配合不好就会闹出大乱子。

3.1 etcd：整个集群的“唯一事实来源”

如果说 K8s 集群里只能留一件东西，那必须是 etcd。它是什么？一个分布式的、强一致性的 key-value 存储数据库。整个集群的所有状态——Pod 在哪个节点、Service 的 IP 是多少、Deployment 的期望副本数是多少、ConfigMap 的内容是什么——全存这里面。

为什么强调“强一致性”？因为 K8s 的控制平面是多个副本并行运行的（生产环境至少 3 个 Master），如果几个 Master 各自为政、看到的状态不一致，那整个集群就乱了套。etcd 通过Raft 共识算法保证多个节点的数据永远一致——写入操作需要大多数节点确认才会返回成功。这就是为什么它被称为“唯一事实来源”。

实操中有个特别重要的提示：etcd 挂掉不等于集群立即不可用，但集群的所有变更操作（部署新应用、扩容、改动配置）都会停摆。已运行的 Pod 会继续跑，可如果某台 Worker 上的 Pod 崩了，控制平面无法调度新 Pod 去替换它，这本质上是一个慢慢“失血”的过程。所以备份 etcd 是运维的必修课：

# 示例：etcd 快照备份（3 个 Master 上的任意一台执行即可） ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

恢复时用etcdctl snapshot restore命令，把快照恢复到新数据目录再启动服务。我踩过的一个坑是：恢复时忘记先停掉所有 Master 上的 apiserver 和 controller-manager，结果等它们重新连接 etcd 后发现数据是旧的，马上触发了一波“状态回滚”，把正在跑的 Deployment 副本数打回原形。无论如何，恢复 etcd 前必须先停控制面组件。

3.2 kube-apiserver：整个集群的“唯一大门”

apiserver 是集群里唯一对外提供服务的组件，也是唯一操作 etcd 的组件。这意味着什么？所有读操作、写操作、鉴权操作、审计操作，都必须经过它。

为什么其他组件（比如 scheduler 想更新 Pod 的节点绑定信息）不能直接连 etcd 改数据？因为如果把直接写 etcd 的口子放开，集群的并发一致性就失控了。apiserver 是那个“绕不开的总闸”，它在收到每个请求时都要做三件事：

1. 认证（Authentication）——你是谁？
2. 授权（Authorization）——你能做什么？
3. 准入控制（Admission Control）——这个请求合不合规？（比如是否设置了资源请求、镜像是否来自允许的仓库）

有意思的是，apiserver 本身就是个“无状态”的服务。它不保存任何数据，所有数据都放 etcd 里，自己只负责“转发和校验”。这意味着你可以随便水平扩容 apiserver，前面加个负载均衡即可，它自己对集群状态完全没有记忆负担。

操作上建议：生产环境的 apiserver 千万别用默认的--bind-address=0.0.0.0直接裸奔。至少开启 HTTPS、配置客户端证书认证、在云环境挂内部负载均衡器。另外审计日志（--audit-log-path）也建议打开，排查“谁改了这 Deployment”时特别有用——生产环境出事故时，审计日志是最后的还原手段。

3.3 kube-scheduler：集群的“调度大脑”

scheduler 负责的事听起来单：为每一个新创建的 Pod（更准确说是未被调度到节点的 Pod）找到一个合适的节点。但“合适”两个字背后是非常复杂的决策。

调度分两步走。第一步是过滤（Filtering）——把不满足硬性条件的节点剔除。比如 Pod 要求的 CPU 是 2 核，节点只剩 1.5 核可用，就淘汰；Pod 声明了要nodeSelector指向某标签，不匹配的节点直接出局。第二步是打分（Scoring）——在通过过滤的节点里选最优。打分规则很多，包括资源最均衡原则（尽量分散）、亲和性规则、镜像本地是否已有等。

我用一个虚拟案例来说明调度的实际过程：假设集群里有两台 Worker 节点，A 节点 8C16G、已跑 3 个 Pod，B 节点 4C8G、空闲。现在来了一个要求 4C8G 的 Pod，过滤阶段淘汰了 B（资源不够），A 胜出——哪怕 A 已经有点忙，它仍然是唯一能满足资源要求的选择。而如果再来一个 1C2G 的小 Pod，调度器会倾向于把它放到 B，因为 B 的资源更多，打分更高。

实操中大家最爱问的一个问题是：能不能让某个 Pod 一定调度到某台机器上？可以，用nodeSelector、nodeAffinity或taint/toleration组合。但注意：调度器是“尽力而为”，不是“保证永远”。如果节点状态变化导致 Pod 必须迁移，调度器会重新决策。生产环境千万别把命脉放在“永远调度到某台机器”上，那是反模式。

3.4 kube-controller-manager：集群的“监工团队”

controller-manager 是控制平面里组件数量最多的一个，它内部其实是几十个“控制器”的集合。每个控制器负责一种资源的状态收敛。核心的几个：

• Deployment Controller：负责维持 Deployment 的期望副本数，通过控制 ReplicaSet 来管理 Pod；
• Node Controller：持续检查节点健康状态，发现节点失联超过阈值就标记为 NotReady，并在超时后驱逐该节点上的 Pod；
• Endpoints Controller：维护 Service 的后端 Pod IP 列表（Endpoints），有新 Pod 上线或旧 Pod 下线，它负责同步更新。

控制器的运作模式一句话就能概括：观察（Observe）→ 决策（Diff）→ 执行（Act）。它会反复对比“期望状态（来自 etcd）”和“实际状态（来自观察）”，发现不一致就发出调整指令。直到两者一致，这个过程才停止。

这就是“自愈”的本质。比如 Deployment 期望副本数是 3，某个 Pod 因为 OOM 被杀了，Deployment Controller 很快会发现——期望 3、实际 2，差 1，于是立即创建新 Pod 补位。如果没人观察这个差异，那么少了就少了，集群会一直残缺地运转下去。

4. 工作节点的“三驾马车”：kubelet、kube-proxy 与容器运行时

控制平面管的是“决策”，真正动手干活的其实就三样：容器运行时、kubelet、kube-proxy。这三兄弟跑在每一个 Worker 节点上，共同构成“手脚”的执行层。但它们的角色依然有精细的划分，先交代清楚再逐个展开：

• 容器运行时负责底层跑容器；
• kubelet 是控制平面派到节点上的“监工代表”；
• kube-proxy 是流量进出的“交通警察”。

4.1 容器运行时：真正让容器“跑起来”的东西

容器运行时（Container Runtime）是实际创建和运行容器进程的软件。早期 K8s 直接用 Docker，后来因为 Docker 太重（多了很多 K8s 用不到的抽象层），社区推动了 CRI（Container Runtime Interface）标准化，现在主流是containerd，它也兼容运行 Docker 镜像。

这个组件有个关键点：它只负责“启动和停止容器”，不负责“决定在哪个节点启动”。运行时的职责边界非常清晰——你给它一个镜像、一组参数，它就创建容器；你叫它停，它就停。

51CTO：很多朋友会问“我的 Pod 一直 CrashLoopBackOff，是不是容器运行时的问题？”大概率不是，更可能是应用本身启动失败或健康检查配置错了。要排查时先看这一步：kubectl logs <pod-name>看业务日志，kubectl describe pod <pod-name>看容器状态和退出码。如果退出码是 137，说明被杀；如果 1，说明应用自己异常退出——这俩查的方向完全不同。

4.2 kubelet：控制平面在节点上的“全权代表”

kubelet 是工作节点上唯一主动跟控制平面通信的组件。它干这些事：

• 通过 apiserver 监听分配给本节点的 Pod，拿到规格（PodSpec）后调用容器运行时创建容器；
• 周期性上报节点状态（CPU、内存、磁盘）和 Pod 状态（Running、Ready、Waiting）；
• 执行存活探针（Liveness Probe）和就绪探针（Readiness Probe），探针失败可能导致容器被重启或从 Service 摘除；
• 管理 Pod 生命周期：创建、重启、销毁、清理。

kubelet 上报周期非常关键，最常用的参数：

有一个非常常见的坑藏在上面表格的第二行。kubelet 自己 10 秒更新一次本地节点状态，但向 apiserver 推送的频率默认是 5 分钟。这就是为什么你会发现某台节点已经 CPU 100% 了，但控制面板上还显示 Healthy。不是监控失效，是上报频率设置的粒度问题。要缩短监控延迟，需要主动调整--node-status-report-frequency并给 controller-manager 传--node-monitor-period配合。

实操中用kubectl describe node能看到的Ready状态，其实就是 controller-manager 的 Node Controller 基于 kubelet 上报数据判断的。如果 kubelet 失联超过 40 秒（默认配置），Node Controller 开始标记 NotReady，再过 5 分钟，Pod 会被驱逐并在其他节点重建。理解这个时间线，对排查“节点负载高了为什么没人管”特别有帮助。

4.3 kube-proxy：Service 流量的“交通警察”

kube-proxy 不运行任何容器，它的职责是把访问 Service 的流量转发到后端 Pod。实现方式有三种：

• userspace 模式（已废弃）：性能太差，用户态转发；
• iptables 模式（默认）：通过 Linux 内核的 iptables 规则做 DNAT 转发；
• IPVS 模式（生产推荐）：通过内核 IPVS 模块做负载均衡，比 iptables 链更高效。

为什么说 iptables 模式在大规模集群有坑？因为 iptables 规则是链式的，每增加一个 Service，规则链就会变长；更新规则时是整体更新，集群里有几百个 Service 时，每次变更都可能让 node 的 CPU 瞬时飙升，这就是传说中的 “iptables 规则风暴”。IPVS 模式用的是 hash 表，天然避免了链式查找的性能退化，更新也快得多。

如果要在生产环境开 IPVS 模式，推荐配置：

# kube-proxy 配置 ConfigMap 片段 apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: ipvs ipvs: scheduler: rr # 轮询调度 excludeCIDRs: - "169.254.0.0/16" # 排除链路本地地址

一个容易忽略的细节：kube-proxy 的规则是基于Endpoints来更新的。当你新部署了 3 个 Nginx 副本并暴露成 Service 后，kube-proxy 通过 apiserver 监听 Endpoints 变化，然后在内核上同步相应的转发规则。这个过程有延迟——从 Pod 创建到 Service 访问生效，通常有几百毫秒到几秒的窗口期。如果你写了自动化脚本去“立即”访问刚创建的 Service，偶尔会碰到 503，就是这个原因。

5. 一次请求的完整旅程：从 YAML 提交到容器运行的全链路拆解

前四节把所有组件都单独讲了一遍，现在我把它们串起来，模拟一个真实场景：你创建一个 Deployment，要求在集群里跑 3 个 Nginx 副本。这一路上，“大脑”和“手脚”是怎么配合工作的？

5.1 阶段一：提交 YAML，apiserver 完成校验与存储

你在终端执行：

kubectl apply -f deploy-nginx.yaml

这条命令首先把请求发给了 apiserver（通过 kubeconfig 里的地址）。apiserver 做鉴权、准入控制，确认你有权限创建 Deployment，然后把它转为内部对象（Deployment），写入 etcd。此时集群里只有一个“期望状态”的数据记录，还没有任何容器被拉起。

注意：这个阶段 apiserver 写的是 Deployment 对象本身，不是直接写 Pod。控制平面组件会基于 Deployment 往下拆解。

5.2 阶段二：控制器发现差异，创建 ReplicaSet 和 Pod

controller-manager 里的 Deployment Controller 一直在监听 Deployment 的变化。它发现 etcd 里新增了一个期望副本数为 3 的 Deployment，于是创建了一个 ReplicaSet（副本控制器）。接着 ReplicaSet 控制器发现期望 3、当前 0，于是通过 apiserver 创建 3 个 Pod 对象。这些 Pod 对象一开始的nodeName是空的——意味着还没被调度。

这个阶段还有个小循环：Pod 会被自动加上各种标签（比如pod-template-hash），这是为了 ReplicaSet 能精确管理自己创建的 Pod，而不会误伤别的 ReplicaSet 管理的 Pod。

5.3 阶段三：scheduler 发现未绑定 Pod，选节点

kube-scheduler 通过 apiserver 持续监听那些nodeName为空的 Pod。一旦发现，它进入调度流程：先过滤出满足资源要求的节点集合，再打分发牌，选中最优节点后，通过 apiserver 更新 Pod 的nodeName字段。

这个更新动作的关键细节：scheduler 本身不会通知任何节点“你要接客了”，它只是把 Pod 的 nodeName 写上。真正通知节点的是 apiserver——kubelet 自己通过watch 机制监听到“有 Pod 被分配到我这里”。

5.4 阶段四：kubelet 从“告知”到“执行”

对应节点上的 kubelet 持续 watch apiserver，发现一个nodeName等于自己的新 Pod，执行以下步骤：

1. 创建 Pod 的沙箱环境（pause 容器）；
2. 拉取镜像（如果是本地没有的镜像）；
3. 创建主容器，挂载存储卷、配置网络；
4. 执行 postStart 钩子（如果有）；
5. 周期性上报 Pod 状态给 apiserver。

当容器成功启动且通过就绪探针（如果配了的话），Pod 状态变成Running and Ready。这一步完成，控制平面会把 Pod 的 IP 加入对应 Service 的 Endpoints 列表（如果有匹配的 Service）。

5.5 阶段五：kube-proxy 更新转发规则，服务开始对外可用

Endpoints Controller 发现 Pod Ready 后有新的 IP 加入，会更新 Endpoints 对象。kube-proxy 监听到这个变化，在节点上更新 iptables/IPVS 规则。从此刻起，访问 Service 的流量就能被转发到这个新的 Pod 上了。

整个流程的时间线大致是：apply（毫秒级）→ apiserver 写入 etcd（毫秒级）→ controller-manager 创建 RS/RS 创建 Pod（秒级）→ scheduler 调度（秒级）→ kubelet 拉镜像创建容器（看镜像大小，几秒到几分钟）→ kube-proxy 更新规则（几百毫秒）。如果镜像很大，前端“创建了 Service 但访问 503”的窗口期就会比较长——这是新手最容易误判成网络故障的地方。

6. 集群协作中的常见“翻车”现场与排查思路

组件拆完、流程串完，我挑三个实战中最常遇到的问题，把排查思路也一并写出来。这些坑都不是疑难杂症，但几乎每个用 K8s 的人都踩过。

6.1 Pod 一直 Pending：不是“没人管”，是“没人能管”

Pending 说明 Pod 一直在调度器面前排队，但就是选不出节点。这时候先别慌，运行：

kubectl describe pod <pod-name>

重点看 Events 区。最常见的三种原因：

• 资源不足：0/2 nodes are available: 2 Insufficient cpu——节点 CPU/内存不够。解决方案是看节点可用资源（kubectl describe node），决定扩容节点还是调低 Pod 的资源请求（requests）。
• 节点亲和性不满足：0/2 nodes are available: 2 node(s) didn't match node selector——检查 Pod 的 nodeSelector/nodeAffinity 和节点的标签（kubectl get nodes --show-labels）。
• 污点（Taint）挡住了：0/2 nodes are available: 2 node(s) had untolerated taint——节点打了 taint，Pod 没写对应的 toleration，调度器直接跳过该节点。

排查 Pending 的黄金原则：describe 永远比看日志优先，因为调度事件是写进 Events 里的。

6.2 kubelet 报错，节点变 NotReady：先看进程，再看日志

节点 NotReady 是最让人毛骨悚然的告警（一是影响面大，二是原因多样）。我习惯按以下顺序排查：

1. 是否进程挂了：systemctl status kubelet，不活跃就journalctl -u kubelet -f看启动日志；
2. 是否 apiserver 通信断了：kubelet 和 apiserver 之间有证书过期、网络分区的可能，日志通常会有refused、timeout等关键词；
3. 是否是磁盘压力（DiskPressure）：kubelet 上报节点 DiskPressure 后会自动驱逐 Pod。看kubectl describe node的条件（Conditions）区，如果是这种情况，需要清理磁盘，而不是重启 kubelet。

真实案例：某次我把节点的 /var/lib/kubelet 所在磁盘塞满到 98%，kubelet 直接把节点标记为 Pressure，并要求驱逐部分 Pod。清掉日志文件后，节点自动恢复正常。这个过程 kubelet 本身没“挂”，它只是执行了自我保护机制。

如果单台节点出现NetworkUnavailable条件，多半是 CNI 网络插件（如 Calico、Flannel）出问题，而不是 kubelet 的锅。这时候排查顺序应该是 Pod 网络组件 → 节点网络基础 → kubelet。

6.3 Service 访问不通：从 Endpoints 到 kube-proxy 层层查

Service 建了，Pod 也 Running，但 curl Service IP 就是不通。排查思路：

# 第一步：看 Endpoints 有没有后端 kubectl get endpoints <service-name>

Endpoints 为空，说明 Pod 的 Ready 状态没有同步到 Endpoints 控制器。重点查：Pod 的就绪探针是否配置错误导致一直非 Ready；Pod 的 label 是否和 Service 的 selector 匹配不上。

Endpoints 正常但访问仍然失败，下一步是：

# 查看 kube-proxy 生成的规则 iptables -t nat -L -n | grep <service-ip> # 或者如果用了 IPVS ipvsadm -L -n

常见问题包括：kube-proxy 所在容器没权限更新规则、节点内核模块没加载（IPVS 模式需要ip_vs、ip_vs_rr等模块）、Service 的类型弄成了 ClusterIP 且你从外部访问它（外部要访问得用 NodePort 或 LoadBalancer）。

我还遇到过一次很典型的坑：集群里有两个 Service 名字相同但 namespace 不同，某个节点的 DNS（CoreDNS）缓存导致解析到的地址不对——排查半天才发现是 DNS 缓存问题，而不是 K8s 资源本身的问题。凡是涉及 Service 域名访问失败的，CoreDNS 的状态也得查一查（kubectl get pods -n kube-system | grep coredns）。

7. 笔记、思考与几个值得深挖的方向

写完这些，我个人的体会是：K8s 这套架构真正的精华不在某个具体组件的功能，而在它如何通过“分离职责 + 声明式 API + 状态对比”这三板斧，把一个极度复杂的分布式系统变得可控。日常工作中你会发现，理解了组件之间的分工和通信逻辑，排查问题时的思路会清晰很多，而不是靠背命令、抄 StackOverflow 答案。

最后分享一个我自己摸索出来的实用习惯：把每个集群的组件配置和版本号写成一份清单，记录 apiserver、controller-manager、scheduler、kubelet 的关键参数（比如 node-status-report-frequency、iptables 模式还是 IPVS 模式）。出问题时第一时间对照这份清单，往往能更快定位到坑。这套架构看着复杂，但只要理解了“大脑管决策、手脚管执行”这一层，剩下的细节就是一个一个填坑而已。