2. Kubernetes集群架构回顾：Master节点、Worker节点、kubelet、kube-proxy、容器运行时接口(CRI)的关系
在深入容器运行时节点扩容之前，必须重新梳理Kubernetes集群的核心架构。节点扩容的本质是向集群添加新的Worker节点，而这一过程能否成功，取决于Master节点、Worker节点上的关键组件以及容器运行时接口(CRI)之间的协作是否顺畅。本节将拆解这些组件的关系，为后续的容量规划与资源调度奠定基础。
2.1 集群两级节点：Master与Worker
Kubernetes集群采用主从架构，所有节点分为两类：
| 节点角色 | 核心职责 | 关键组件 | 扩容关注点 |
|---|---|---|---|
| Master节点 | 集群控制面，负责调度、状态维护、API服务 | kube-apiserver, etcd, kube-scheduler, kube-controller-manager | 控制面容量、etcd性能、调度器吞吐 |
| Worker节点 | 运行用户容器，承载实际工作负载 | kubelet, kube-proxy, 容器运行时(CRI) | 节点资源(CPU/内存/磁盘)、容器运行时版本、网络连通性 |
关键认知：节点扩容主要面向Worker节点。Master节点通常采用固定数量的高可用部署（如3或5节点），不随业务负载动态扩缩。
2.2 核心组件关系图
下图展示了Master节点与Worker节点之间的通信链路，以及kubelet、kube-proxy、容器运行时(CRI)在Worker节点上的协作关系：
2.3 kubelet：节点代理与Pod生命周期管理者
kubelet是运行在每个Worker节点上的主要节点代理，它负责：
- 节点注册：向kube-apiserver注册节点信息（主机名、IP、资源容量）。
- Pod管理：监听来自apiserver的Pod绑定指令，确保Pod中的容器处于运行状态。
- 健康检查：执行存活探针(livenessProbe)和就绪探针(readinessProbe)。
- 资源上报：定期向Master报告节点资源使用情况（CPU、内存、磁盘、PID）。
扩容关联：新节点加入集群时，kubelet必须成功完成自注册。如果kubelet无法连接apiserver或证书校验失败，节点将处于
NotReady 状态，无法调度Pod。
2.4 kube-proxy：网络代理与Service规则
kube-proxy负责实现Kubernetes Service的网络代理功能，运行在每个Worker节点上：
| 模式 | 实现方式 | 性能特点 | 扩容影响 |
|---|---|---|---|
| iptables | Linux内核Netfilter规则 | 规则量大时性能下降，更新延迟 | 大规模集群需关注规则数量 |
| IPVS | 内核态L4负载均衡 | 高性能，支持更多调度算法 | 推荐用于大规模集群扩容 |
| userspace | 用户态代理（已弃用） | 性能差，仅用于早期版本 | 不推荐 |
注意：节点扩容后，kube-proxy需要在新节点上正确配置并同步所有Service的规则。如果kube-proxy异常，新节点上的Pod将无法通过Service ClusterIP访问。
2.5 容器运行时接口(CRI)：kubelet与容器引擎的桥梁
CRI是Kubernetes定义的一组gRPC接口，用于解耦kubelet与具体的容器运行时实现。kubelet通过CRI调用容器运行时的API来创建、启动、停止容器。
2.5.1 CRI的核心接口
// RuntimeService：管理Pod和容器的生命周期
rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse);
rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse);
rpc StartContainer(StartContainerRequest) returns (StartContainerResponse);
rpc StopContainer(StopContainerRequest) returns (StopContainerResponse);
rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse);
// ImageService：管理容器镜像
rpc PullImage(PullImageRequest) returns (PullImageResponse);
rpc ListImages(ListImagesRequest) returns (ListImagesResponse);
rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse);2.5.2 主流CRI实现对比
| 容器运行时 | CRI实现方式 | 镜像格式 | 扩容优势 | 注意事项 |
|---|---|---|---|---|
| containerd | 内置CRI插件（原生） | OCI标准 | 轻量、启动快、资源占用低 | 需确保版本 ≥ 1.6 |
| CRI-O | 原生CRI实现 | OCI标准 | 专为Kubernetes优化，无额外功能 | 社区活跃度需关注 |
| Docker (dockershim) | 通过dockershim适配（已弃用） | Docker镜像格式 | 历史兼容性好 | Kubernetes 1.24+已移除 |
最佳实践：在节点扩容时，建议统一所有Worker节点的容器运行时版本。混合使用不同版本的containerd或CRI-O可能导致Pod调度行为不一致，增加排障难度。
2.6 组件协作流程：从Pod调度到容器运行
当用户通过Deployment创建Pod时，各组件按以下顺序协作：
- kube-apiserver 接收创建Pod的请求，将Pod对象写入 etcd。
- kube-scheduler 通过apiserver监听未调度的Pod，根据节点资源、亲和性等策略选择一个Worker节点。
- kubelet 在选中的Worker节点上监听到Pod绑定信息，调用 CRI 接口创建Pod沙箱和容器。
- 容器运行时 拉取镜像、创建容器进程，并将状态通过CRI返回给kubelet。
- kube-proxy 在节点上更新iptables/IPVS规则，确保Service流量能到达新Pod。
扩容验证：新节点加入后，可以通过以下命令快速验证组件状态：
# 检查节点状态
kubectl get nodes
# 检查kubelet日志
journalctl -u kubelet -f
# 检查容器运行时健康
crictl info
# 检查kube-proxy规则
iptables-save | grep KUBE2.7 架构关系总结
Master节点与Worker节点通过kube-apiserver进行双向通信。Worker节点上的kubelet是核心代理，它通过CRI与容器运行时交互，通过kube-proxy实现网络规则。节点扩容的成功与否，取决于这三个组件在新节点上是否正确安装、配置并成功注册到集群控制面。