企业官网建设流程全解析

算力中心这个词，听起来很硬核，但说白了就是一堆服务器堆在一起给业务跑容器的地方。而Kubernetes（简称K8s）在这堆服务器里扮演的角色，特别像一个“超级调度员”——它不生产算力，也不算业务逻辑，它只负责一件事：让每一个容器，都精准地落到最该落的那台机器上，并且保证它一直活着、随时能用。

很多朋友学K8s最大的障碍，是被那些抽象名词劝退：Pod、Node、Deployment、Service、etcd……每个词单看都能解释，合在一起就不知道谁在指挥谁。我自己从kubeadm init到把业务真正跑上生产环境，中间也经历过很长一段“会敲命令但不懂原理”的阶段。这篇文章不追新版本特性，也不铺概念全集，就顺着“超级调度员”这个视角，把K8s的调度机制、核心组件、一次Pod从提交到运行的完整生命周期讲透。适合刚入门想建立整体认知的朋友，也适合已经会部署但说不清调度逻辑的运维同学。

1. 算力中心的调度困境：为什么非要有K8s

1.1 没有调度员的日子：手工部署的三大痛点

在没有K8s之前，我们部署一个容器化应用是什么状态？服务器上装了Docker，把镜像拉下来，docker run一下，端口映射好，业务就跑起来了。单台机器、两三个容器的时候，这套流程完全够用。可真到了算力中心的规模——几十台节点、上千个容器、随时要扩容缩容——问题就全冒出来了。

第一个痛点是端口和资源冲突。你在一台机器上起了A容器占住8080，另一拨人又来部署B服务也想用8080，谁后到谁扑街。哪怕你们约定好端口段，总有人不按规矩来。资源也一样，CPU和内存是有限的，容器之间的资源争抢经常把宿主机打满。

第二个痛点是故障恢复靠人肉。某个容器crash了，监控告警响了，运维半夜爬起来重启。一台机器宕机了，上面所有容器全部哑火，你要手动把服务迁到别的机器上，运气好半小时，运气差要折腾一夜。这种“人肉调度”在故障面前永远慢半拍。

第三个痛点是发布和扩容的不可控。流量上来了，想加两个副本，你需要在几台机器上各跑一遍docker run，还要保证新实例的参数和旧的一致。灰度发布时，想把旧版本逐个替换成新版本，纯靠手工一个个停、起、等，根本没法标准化。

这就是K8s出现的根本原因：把“容器该跑在哪台机器上、怎么跑、挂了怎么处理”这件事，从人的经验里抽出来，变成一套有状态、有逻辑、能自动决策的调度系统。

1.2 “超级调度员”到底在调度什么

很多人对K8s的理解停留在“容器编排工具”，这个说法不够准确。K8s调度的核心单位不是容器，而是Pod。Pod是K8s里最小的调度单元，里面可以有一个或多个容器。这些容器共享网络命名空间、共享存储卷，就像一个房间里住着的几个室友，公用厨房和洗手间，必须待在同一个节点上。

调度员的工作，就是给每一个Pod找一个最合适的Node（工作节点）。这个“合适”不是随机选的，而是经过一套复杂的决策流程：Node的CPU和内存够不够？Pod要求的端口会不会冲突？有没有匹配的标签？有没有特殊的亲和性要求？在满足硬性条件的前提下，还要尽量做到负载均衡、资源利用率最高。

我习惯把K8s的调度比作高峰期出租车派单逻辑。乘客（Pod）要打车，平台（调度器）先筛掉距离太远、司机正在休息、车辆限行的选项，这些是“硬性过滤”；再从剩下可选车辆里选一个综合评价最高的，比如里程最短、路况最好、司机评分高，这些是“打分排序”。最终乘客上车，订单锁定。

理解了这个比喻，K8s的很多设计就顺理成章了：为什么Pod要绑定在Node上？因为车已经接单了，不能同时接下一单。为什么有亲和性和反亲和性？因为有时候你希望同一类Pod聚集在一起减少网络延迟，有时候又希望它们分散开避免单点故障。为什么有污点和容忍？因为有的Node是专用节点，等闲Pod不让停。

2. 拆开“超级调度员”的调度中枢：控制面与工作节点

2.1 控制面四件套：前台、记事本、调度经理与监工

K8s集群从物理角色上分两大部分：控制面（Control Plane）和工作节点（Worker Node）。控制面就是调度员的大脑，它由几个组件组成，各自分工明确。

第一个是kube-apiserver，它是整个集群的前台客服。所有组件、kubectl命令、大厂的各种二次开发系统，要操作集群都必须经过它。它负责接收请求、鉴权、把数据写入存储、并把变更实时推送给关心这些数据的组件。你可以不看别的组件，但一定要知道：所有交互都走apiserver，它是集群的入口，也是唯一入口。

第二个是etcd，它是集群的记事本。所有配置信息、期望状态、实际状态都存储在etcd里。它是一个独立的分布式键值数据库，保存着“集群想要变成什么样”以及“当前是什么样”。K8s的持久性和一致性，全靠etcd兜底。

第三个是kube-scheduler，这才是真正的调度经理。它负责监听新创建的Pod（实际上是通过apiserver的事件机制），然后执行刚才说的过滤、打分、绑定流程。当你执行kubectl apply提交一个Deployment后，真正决定Pod去哪台Node的，就是它。

第四个是kube-controller-manager，它是监工+纠察队。集群里有很多个Controller，比如Deployment Controller盯着你想要3个副本，现在只有2个，它就会去创建第3个；Node Controller发现某台Node失联，它会去清理上面的Pod。体现在期望状态和实际状态的差距，然后拼命抹平差距，这就是控制器的核心哲学。

我一直觉得，理解控制面这四个组件的关系，是搞懂K8s的门槛。你可以这样记：前台收单（apiserver）、本子记账（etcd）、调度经理派单（scheduler）、监工巡场纠偏（controller-manager）。

2.2 工作节点三剑客：管家、网络警察与容器引擎

工作节点是真正跑业务的地方，每个节点上一套标配，三个关键组件。

第一个是kubelet，这是节点上的管家。它直接与容器运行时打交道，负责启动Pod、监控Pod健康状态、向apiserver汇报。调度经理把Pod派给某台节点后，就是kubelet来“接单”并执行的。它还会定期向控制面报告心跳和资源使用情况，让调度器有据可依。

第二个是kube-proxy，它是节点上的网络警察。它负责维护节点的网络规则，实现Service（服务）的负载均衡和流量转发。简单说，当你访问一个Service的ClusterIP时，怎么把流量转发到后端的某个Pod上，就是kube-proxy干的活。它支持iptables和IPVS两种模式，生产环境我推荐IPVS，规则多了之后性能更稳定。

第三个是容器运行时（Container Runtime），比如containerd、CRI-O，老一点的环境还有Docker。它就是实际拉取镜像、创建容器、启停进程的引擎。K8s通过CRI（Container Runtime Interface）接口和运行时通信，好处是运行时解耦，你想换引擎不影响上层。

控制面和节点之间的协作方式是“声明式状态同步”：用户声明想要的最终状态（比如3个副本、端口8080、环境变量xx=yy），K8s就持续驱赶当前状态向期望状态靠拢，而不是“命令式地”一步步执行任务。这也是后来排障时很重要的一个思维转换——遇到K8s的问题，不要问“谁执行了这条命令”，要问“期望状态是什么、当前差在哪”。

3. 跟踪一个Pod的完整一生：从YAML到运行起来

3.1 提交、入库与监听的流转闭环

光讲概念太虚，我们直接跟踪一个Pod从提交到运行的完整流程。假设你写了这样一个最简单的Deployment YAML：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-demo spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi

你执行kubectl apply -f nginx.yaml之后，这条命令发往apiserver。apiserver先做鉴权，确认你有权限操作Deployment资源，然后把这份期望状态写入etcd。这一步完成后，apiserver会向集群里所有监听者广播“有新的Deployment被创建了”。

Deployment Controller收到这个事件，发现期望副本数3、当前副本数0，于是创建3个Pod对象。这3个Pod对象同样会写入etcd，并且触发新的事件。这时候，真正的“调度经理”kube-scheduler就动起来了——它专门监听那些nodeName字段为空（也就是还没被派发）的Pod。

调度完成后，scheduler会把“这个Pod应该跑在node-a上”的信息写回etcd，更新Pod的nodeName字段。这一更新，node-a上的kubelet立刻就能感知到，因为kubelet也在持续上报请求，盯着有没有指派给自己的Pod。

从用户操作到调度完成，整个流转链路是：kubectl → apiserver → etcd → scheduler → apiserver → etcd → kubelet。注意，scheduler不直接和kubelet通信，中间永远有apiserver在传话。这也是K8s设计的一个核心原则：组件之间不做点对点直连，全部通过apiserver中转。好处是架构清晰、易于扩展，坏处是apiserver容易成为性能瓶颈，生产环境一般要做高可用，而且etcd的访问压力要留意。

3.2 绑定之后：kubelet的“接单”与启动流程

kubelet发现有Pod派给自己之后，它并不直接启动容器，还要经历一个准备阶段：先检查Pod所需的存储卷、网络、镜像等资源是否就绪。比如Pod声明了emptyDir或hostPath，kubelet会先创建好对应目录；如果要挂ConfigMap或Secret，也要提前准备好。

然后是拉取镜像。kubelet通过CRI请求容器运行时，比如containerd，去拉取nginx:1.25。这里有个常见的坑：如果Pod设置了imagePullPolicy: IfNotPresent且节点上已有同名镜像，它就不会重新拉取，对于发版频繁的业务，建议明确设置imagePullPolicy: Always或者用带唯一tag的镜像地址，比如registry.internal.demo/nginx:build-20240115，否则很容易在灰度验证时拉出旧镜像。

镜像拉取完成后，容器运行时会创建Pod沙箱（pause容器），再启动业务容器。pause容器里“什么正事都不干”，但整个Pod的网络命名空间和Linux共享命名空间都由它持有。之后kubelet会定期通过容器运行时的RPC接口（比如exec探针、stats统计）检查容器的健康状态。

Pod真正运行起来后，kubelet还会把当前状态上报给apiserver，更新Pod对象的status字段。如果你在这时候执行kubectl get pods -o wide，看到Running状态，说明这一步已经走完了。

我建议每个运维同学都动手做一次这个实验：找一个小的Deployment，盯着kubectl describe pod的输出，你会清晰看到“Scheduled”、“Pulled”、“Created”、“Started”这几个事件的先后顺序。这个实验做一遍，比背十遍原理都管用。

4. 调度器在“想”什么：过滤、打分与绑定

4.1 过滤阶段：先把不合格的节点踢出去

你看懂了调度流程，就该问一句灵魂问题：调度器挑选Node时，到底依据什么？K8s的调度器把决策分成**过滤（Filtering）和打分（Scoring）**两个阶段。

过滤阶段是硬性门槛，不满足直接淘汰。我整理过几个最容易触发的过滤条件：

我给你举个资源过滤的例子。假设节点总内存8Gi，系统预留1Gi，已运行Pod声明了requests内存总和5Gi，那么这个节点可分配内存还剩2Gi。如果新Pod的requests内存是3Gi，调度器直接把这个Node从候选名单里剔除。注意，这里看的是requests不是limits，因为requests是调度时用来做资源预留判断的，limits只在运行时做硬性约束。很多人配置资源时只写limits不写requests，这是一个很危险的习惯，会导致调度器以为这个Pod不占资源，大量堆到同一台机器上，运行后却因为limits超卖把节点打爆。

4.2 打分阶段：优中选优的资源博弈

过滤之后剩下的Node都满足硬性条件，接下来进入打分阶段。调度器会为每个候选节点算一个综合分，分数越高越优先。最经典的默认打分之一是leastRequestedPriority的理念：尽可能往资源剩余量多、统一负载更低的节点上放，让集群整体负载趋于均衡。

还有几个影响打分的因素：nodeAffinity的软性匹配、Pod的preferred调度策略、镜像是否已经存在于节点本地（镜像已经在本地会加权重，避免重复拉取延迟）、Pod之间是否存在反亲和需要分散放置。

这里有个容易被忽略的点：调度器打分是基于“当前状态”而不是“未来状态”，而且多个Pod是逐个调度的。你一次性创建10个Pod，调度器在调度第1个时看到的是当前集群状态；调度完第1个后，第2个调度时节点剩余资源已经变了。所以当你发现10个Pod没有均匀分布在各节点时，可能是资源拓扑、Marvin网络插件跨节点通信等其他因素影响，不一定就是调度器“不均衡”。

我做过一次实验：集群里5台规格完全相同的节点，提交了5个requests完全相同的Pod，结果并没有每个节点分到一个，而是出现了一个节点分到2个、另一个节点空闲的情况。排查下来是因为Pod之间存在某个镜像拉取状态差异，以及打分时的软亲和策略。K8s的调度器从来不做“平均主义”，它只按算法给出当时最优解。想要控制分布，只能用反亲和性或者拓扑分布约束（topologySpreadConstraints）。

4.3 动手写一个nodeSelector与亲和性配置

光说不练假把式。在实际业务中，最常用的调度控制手段就是nodeSelector和亲和性。

nodeSelector的使用非常简单。先给节点打标签：

kubectl label node node-a disk=ssd kubectl label node node-b disk=hdd

然后在Pod模板里加：

spec: nodeSelector: disk: ssd

这个Pod就一定会被调度到带disk=ssd标签的节点上。nodeSelector只支持等值匹配，适合简单场景。

如果你需要更复杂的逻辑，比如“优先往某个区放，但放不下时可以放到另一个区”，那就得用nodeAffinity：

spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - zone-a preferredDuringSchedulingIgnoredDuringExecution: - weight: 80 preference: matchExpressions: - key: disk operator: In values: - ssd

这里的requiredDuringSchedulingIgnoredDuringExecution是硬性条件，preferredDuringSchedulingIgnoredDuringExecution是软性条件——它会折算成分数，但不能强留Pod。注意这两个字段的名字都带IgnoredDuringExecution，意思是Pod运行期间即使节点标签变了，也不会把已经运行的Pod赶走，只在调度阶段生效。想改变这个行为，就得用节点亲和性的新阶段，或者配合descheduler，那个是另一个话题了。

同理，Pod之间的亲和/反亲和用podAffinity和podAntiAffinity来控制。比如希望两个服务调度在同一台节点减少网络开销，或者希望将不同副本的Pod尽可能分散到不同节点保证高可用。生产环境最常见的需求就是：把同一Deployment的两个Replica分开到不同节点，避免一台机器挂了业务全没。这个需求用反亲和性一步到位。

5. 调度员的高阶操作：自愈、弹性与升级

5.1 控制循环：为什么Pod挂了会自动拉起

既然K8s叫“超级调度员”，它就不能只管“把Pod放上去”就撒手不管。它还得确保Pod活着。这背后是控制器（Controller）模式一级哲学：期望状态和实际状态的不断对齐。

K8s的Deployment、StatefulSet、DaemonSet这些高级负载对象，本质都是Controller，只不过它们的控制逻辑不同。以Deployment为例，控制器在启动后会用标签选择器筛选出属于它的Pod，实时统计数量。当某个Pod因为节点故障、资源耗尽、OOM Kill而消失时，控制器的定时同步循环（大约每10秒左右轮询一次，具体取决于--sync-period参数）就会检测到当前副本数少于期望值，触发创建新Pod的流程。

这个新Pod又会走一遍调度流程，被放到合适的节点上。这就是K8s“自愈”的最底层逻辑——并不是它奇迹般地会把坏的容器修复好，而是它能用一个新的Pod替换掉死掉的那个，让总量永远贴合期望值。

我早期排障时犯过的一个错误：业务反馈Pod挂在某个节点一直重启，我第一反应是上去敲docker logs看业务日志。实际上在K8s环境里，正确的排查姿势是先看Pod的restartPolicy（策略默认是Always），再看事件（kubectl describe pod），再看上一次容器的退出码（kubectl logs --previous）。重建的概念和修复的概念不要混在一起——K8s更擅长“重生”，而不是“治疗”。

5.2 HPA与节点伸缩：应对算力洪峰

算力中心最核心的一个诉求是弹性伸缩。这里要区分两个层面的伸缩：Pod副本数伸缩和节点数伸缩。

Pod副本数伸缩最常用的是HPA（HorizontalPodAutoscaler）。它的工作逻辑是：控制器定期采集Pod的平均CPU、内存使用率（或自定义指标，比如QPS、队列长度），超出设定的目标值就扩容副本数，低于目标值就缩容。

一个典型的HPA配置如下：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nginx-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-demo minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60

这里的averageUtilization: 60表示当Pod的平均CPU使用率达到60%时触发扩容。但要注意，HPA的扩缩容是有时间窗口的，默认扩容冷却--horizontal-pod-autoscaler-downscale-stabilization-window是5分钟，防止指标抖动导致频繁扩缩容。

节点级伸缩，云环境下一般配合cluster-autoscaler来做：节点资源不足，Pod调度不上去时，自动创建新的云主机加入集群；节点空闲时间过长，自动回收。这部分设计跟云厂商的API高度相关，不同环境下差异大，但底层逻辑一定是“看有没有Pending的Pod”。

**这里有一个常见的业务误解：**很多团队以为上了HPA就能保证“秒级扩容”，实际上HPA的默认指标采集间隔是15秒，控制器判断又是另一个周期，再加上扩容后应用启动时间、镜像拉取时间，整体感知往往是分钟级别的。真正要求秒级弹性的场景，还得靠提前预留资源或者用Serverless容器技术。

5.3 滚动更新与回滚：不中断业务换版本

业务发布是K8s另一个高频操作。执行

kubectl set image deployment/nginx-demo nginx=nginx:1.26

这条命令触发的就是Deployment的滚动更新。

Deployment Controller收到后，会创建一个新的ReplicaSet（不同版本的Pod集合），然后按照“先增加新版本副本，再减少旧版本副本”的策略平滑切换。默认配置下，它会先创建1个新Pod，等它Ready之后，删除1个旧Pod，再创建1个新Pod……如此反复，直到所有旧Pod被替换。关键参数有maxSurge（滚动中额外允许超出期望值的Pod数）和maxUnavailable（滚动中允许不可用的Pod数）。

对于发布来说，最核心的还有一件事：存活探针（livenessProbe）和就绪探针（readinessProbe）一定要配好。你告诉Deployment“新Pod已经就绪可以接流量”，靠的是readinessProbe通过了。如果没配这个探针，新Pod还没启动完成就被认为Ready了，流量打进来全挂，滚动的策略就会非常混乱。这是我在生产环境见过最多的事故根源——没有之一。

如果新版本有问题，回滚也一样简单：

kubectl rollout undo deployment/nginx-demo

它会根据Deployment维护的历史版本记录，恢复到上一个ReplicaSet的状态。为了保证回滚可用，不要在生产环境随意清理revisionHistoryLimit，默认保留10个历史版本是很有必要的。

6. 从零搭一个集群：kubeadm初始化实战与踩坑记录

6.1 初始化前的pre-flight检查

讲完原理，顺手分享一段真实部署经验。这里以kubeadm init初始化一个K8s v1.26.0集群为例，展示初始化过程的关键输出和注意事项。

kubeadm初始化时的日志很有意思，开头就是：

[init] Using Kubernetes version: v1.26.0 [preflight] Running pre-flight checks

preflight是正式干活前的一道“安全检查流水线”，它会逐项检查主机是否满足条件：是不是有剩余磁盘、内存是否达标、端口是否被占用、网络是否通、容器运行时是否装好，等等。任何一个检查项失败，初始化都会停下来，不会带病上路。

以v1.26.0为例，最常见的一个坑是cgroup driver不一致。如果容器运行时的cgroup driver是systemd，而kubelet配置用的是cgroupfs，kubelet和containerd之间会出现资源统计口径不一致，初始化时就会报错，运行后也会出现各种诡异问题。我的建议是：当前主流系统都在用systemd作为init进程，所有组件的cgroup driver统一配置为systemd，一笔都不用纠结。

另一个高频坑是swap未关闭。早期K8s版本默认要求关闭swap，否则kubelet无法启动。v1.26.0沿用这个策略，初始化preflight会明确返回失败信息：

[ERROR Swap]: running with swap on is not supported. Please disable swap

当时的我就踩过这个坑，后来在搭建新环境时，系统装完第一步就执行：

swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab

顺便再清一遍/etc/fstab里的swap挂载，不然重启后又回来了。

6.2 我踩过的坑与应对

初始化成功只是开始，后面还有更多坑等着你。我把自己实际踩过的几个典型问题列一下，供大家参考。

一是节点NotReady。这个问题十次有八次出在容器网络插件（CNI）没有装好。理论上K8s集群装完后，节点状态是NotReady，直到绕过了某个网络插件的配置才有好转。我用的最多的是Calico：

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26/manifests/calico.yaml

注意检查你选的版本和Kubernetes的兼容性。装完之后查看一下：

kubectl get pods -n kube-system kubectl get nodes

如果还是NotReady，用journalctl -u kubelet -f看kubelet日志，绝大多数是CNI的二进制或配置文件没生成全。

二是kube-proxy模式选择。v1.26.0默认还是iptables模式，Pod规模超过几百个后，ipset规则会变得非常多，节点上的转发延迟会明显上升。把模式切换成IPVS可以在大规模场景下获得更好的转发性能和规则维护效率。改法是在kube-proxy的ConfigMap里把mode改为ipvs，然后滚动更新kube-proxy的DaemonSet。

三是Pod调度不上去、一直Pending。我遇到过最气人的情况是：集群明明有资源，Pod就是Pending。排查顺序是：

kubectl describe pod xxx kubectl get events --sort-by=.metadata.creationTimestamp

大概率问题不出在调度器，而是镜像拉取失败、PVC无法挂载、或者节点有污点而没有对应容忍。记住这个顺序，不然后面排查会绕很多弯。

四是NodePort端口范围冲突。默认NodePort端口范围是30000-32767，如果业务需要更多端口段，或者想用低于30000的端口，要在apiserver上改--service-node-port-range参数。这属于初始化前就要想清楚的事，后期改起来要动控制面配置，稍微麻烦一些。

6.3 版本选择的经验

最后聊一下版本策略。我在生产环境选择K8s版本，倾向于选当前稳定分支的次新小版本，比如v1.26.x系列里选v1.26.0之后的补丁版本。因为.0版本往往带一些没那么严重但也不算少的bug，等社区发一个或两个补丁版本后采坑成本最低。

关于升级，也别跳太多版本。社区支持从一个次版本升到下一个次版本，比如v1.25升v1.26，v1.26升v1.27，尽量不要从v1.24直接跨到v1.26，中间步骤更容易碰上API版本移除、配置字段失效的问题。升级之前记得先备份etcd，这句话不是随便说说的。Kubernetes的升级过程本质上是控制面组件的替换和数据兼容性转换，etcd里存着整个集群的命根子，一旦升级过程中被误操作或网络震荡打断，没有备份裸跑的恢复成本那是相当心痛。

部署团队如果还在观望要不要上K8s，我的建议是：先拿一套不重要的中间件迁进去跑一个月，盯住集群的可观测性、告警链路是否完善，再看要不要扩展核心业务。别一上来就把所有服务一股脑塞进去，K8s能帮你管好工作负载，但前提是你已经建立了监控、日志、诊断这套配套体系的“行规”，不然集群对你来说就是一个庞大又沉默的黑洞。

我自己的体会是，K8s这套调度系统真正值的不是“能跑多少个容器”，而是把运维从“救火队员”变成“规则制定者”。你不需要再关心每台机器上跑着什么，你只需要定义好期望状态，剩下的交给调度员。这份从容，才是算力中心最贵的东西。