2. K8s 核心架构回顾：Master 节点组件、Worker 节点组件、Pod 与容器运行时、网络模型 (CNI)
在进行容量调优之前，必须对 Kubernetes 的核心架构有清晰的认识。容量瓶颈往往隐藏在组件交互的边界上。本章从 Master 节点、Worker 节点、Pod 与运行时、网络模型四个维度，梳理关键组件及其职责。
2.1 Master 节点组件
Master 节点是集群的控制平面，负责全局决策和状态管理。其组件的高可用与性能直接决定集群的调度效率和稳定性。
| 组件 | 核心职责 | 容量关注点 |
|---|---|---|
| kube-apiserver | 所有组件交互的网关，提供 RESTful API，负责认证、授权、准入控制 | 请求吞吐量、etcd 读写延迟、连接数 |
| etcd | 分布式键值存储，保存集群所有状态数据 | 磁盘 IOPS、存储容量、网络延迟、快照大小 |
| kube-scheduler | 监听未调度的 Pod，根据资源需求和策略绑定到合适节点 | 调度队列深度、节点过滤/打分耗时 |
| kube-controller-manager | 运行各类控制器（如 Node Controller、Deployment Controller） | 控制器循环频率、资源缓存大小 |
容量调优提示： kube-apiserver 是请求入口，建议配置
--max-requests-inflight 和 --max-mutating-requests-inflight 参数防止过载；etcd 建议使用 SSD 并定期压缩历史版本（--auto-compaction-retention）。
2.2 Worker 节点组件
Worker 节点承载实际工作负载。每个节点上运行三个核心代理组件，它们之间的协作效率决定了 Pod 的生命周期管理质量。
- kubelet：节点上的主要代理，负责管理 Pod 生命周期、健康检查、资源上报。容量瓶颈通常出现在 Pod 密度过高时的状态同步延迟。
- kube-proxy：维护节点上的网络规则，实现 Service 的负载均衡。iptables 模式在大规模 Service 下规则更新慢，IPVS 模式性能更优。
- 容器运行时（Container Runtime）：负责拉取镜像、启动/停止容器。常见运行时包括 containerd、CRI-O。
常见误区： 很多团队只关注 Master 组件的高可用，却忽略 Worker 节点上 kubelet 的
--max-pods 限制。当节点 Pod 数量超过阈值时，kubelet 会拒绝创建新 Pod，导致调度失败。
2.3 Pod 与容器运行时
Pod 是 Kubernetes 中最小的调度单元，一个 Pod 内可包含一个或多个容器，共享网络命名空间和存储卷。容器运行时通过 CRI（Container Runtime Interface）与 kubelet 交互。
| 概念 | 说明 | 容量影响 |
|---|---|---|
| Pod 资源请求（Requests） | 调度时保证的最小资源量 | 决定节点可调度 Pod 数量 |
| Pod 资源限制（Limits） | 容器可使用的资源上限 | 影响 CPU 压缩和 OOM 风险 |
| 容器运行时镜像层 | 镜像分层存储，共享基础层 | 磁盘空间占用、拉取时间 |
| Pod 生命周期钩子 | PostStart / PreStop | 优雅终止时长影响滚动更新速度 |
# 查看节点上容器运行时信息
kubectl get nodes -o wide
# 检查 kubelet 配置中的 maxPods
kubectl describe node <node-name> | grep -i pods2.4 网络模型 (CNI)
Kubernetes 网络模型要求每个 Pod 拥有独立的 IP，且 Pod 之间可以直接通信，无需 NAT。CNI（Container Network Interface）插件负责实现这一模型。
常见 CNI 插件对比：
| CNI 插件 | 网络模式 | 性能特点 | 适用场景 |
|---|---|---|---|
| Calico | BGP / VXLAN | 原生 BGP 性能高，VXLAN 封装有开销 | 大规模集群、网络策略严格 |
| Flannel | VXLAN / host-gw | 简单易用，host-gw 模式性能好 | 中小规模、快速部署 |
| Cilium | eBPF | 极高吞吐，低延迟，可观测性强 | 高性能需求、安全敏感 |
| Weave | fastdp / weave | 加密通信，跨云支持好 | 多云/混合云场景 |
容量调优关键： CNI 插件的选择直接影响网络吞吐和延迟。在容量规划时，需评估 Pod 间通信的带宽需求，避免 VXLAN 封装带来的额外 CPU 开销。建议使用 eBPF 或 host-gw 模式减少网络栈层次。
2.5 组件交互流程总结
理解组件间的数据流有助于定位容量瓶颈。以下是一个 Pod 创建请求的典型流程：
- 用户通过
kubectl或 API 调用向 kube-apiserver 提交 Pod 定义。 - apiserver 将 Pod 对象写入 etcd 持久化。
- kube-scheduler 通过 watch 机制获取未调度的 Pod，执行过滤和打分，选择最优节点。
- 调度结果写回 apiserver，apiserver 更新 etcd。
- kubelet 在目标节点上监听到新的绑定信息，调用 容器运行时 启动 Pod 内的容器。
- kube-proxy 更新节点上的网络规则，确保 Service 流量能到达新 Pod。
- CNI 插件 为 Pod 分配 IP 并配置网络接口。