Kubernetes 集群架构
Kubernetes 控制平面、节点组件、访问链路和生产集群基线说明。
Kubernetes 集群架构
Kubernetes 集群由控制平面和工作节点组成。控制平面保存和协调集群期望状态，工作节点负责运行 Pod。所有资源变更都通过 API Server 进入，再由控制器、调度器、kubelet 等组件逐步完成。
核心组件
| 组件 | 位置 | 作用 |
|---|---|---|
| API Server | 控制平面 | Kubernetes API 入口，负责认证、鉴权、准入和对象读写 |
| etcd | 控制平面 | 保存集群状态和资源对象 |
| Scheduler | 控制平面 | 为未调度 Pod 选择合适节点 |
| Controller Manager | 控制平面 | 运行控制器，让实际状态接近期望状态 |
| kubelet | 工作节点 | 管理本节点 Pod 生命周期 |
| containerd | 工作节点 | 容器运行时，负责镜像和容器 |
| kube-proxy | 工作节点 | 维护 Service 访问规则 |
| CNI | 工作节点 | 提供 Pod 网络能力 |
访问链路
用户、CI/CD、GitOps 控制器通常都访问 API Server：
kubectl / controller -> API Server -> etcd
创建 Deployment 后的典型链路：
- API Server 写入 Deployment 对象。
- Deployment Controller 创建 ReplicaSet。
- ReplicaSet Controller 创建 Pod。
- Scheduler 为 Pod 选择节点。
- kubelet 在目标节点拉取镜像并启动容器。
- kube-proxy / CNI 维护服务访问和 Pod 网络。
控制平面高可用
生产集群建议至少 3 个控制平面节点：
load balancer
├── apiserver-1
├── apiserver-2
└── apiserver-3
etcd
├── member-1
├── member-2
└── member-3
注意事项：
- etcd 建议奇数成员，常见为 3 或 5。
- API Server 前需要稳定的负载均衡地址。
- 控制平面节点需要低延迟、稳定磁盘和可靠时间同步。
- etcd 需要定期备份，并演练恢复流程。
Worker 节点基线
每个节点至少需要确认：
systemctl status kubelet
systemctl status containerd
crictl info
kubectl get node <node-name> -o wide
kubectl describe node <node-name>
重点关注：
- kubelet 是否 Ready。
- containerd 是否正常。
- CNI Pod 是否运行。
- 节点资源是否有
MemoryPressure、DiskPressure、PIDPressure。 - 节点标签、污点和角色是否符合规划。
生产基线
| 项目 | 建议 |
|---|---|
| 版本管理 | 固定 Kubernetes 次版本，升级前确认组件兼容 |
| 容器运行时 | 使用 containerd，cgroup driver 和 kubelet 保持一致 |
| 网络 | 明确 Pod CIDR、Service CIDR、CNI 插件和 NetworkPolicy 能力 |
| 权限 | 默认最小权限，禁止业务长期使用 cluster-admin |
| 日志 | 保留 kubelet、containerd、控制面组件和应用日志 |
| 监控 | 监控节点、Pod、API Server、etcd、CoreDNS、CNI |
| 备份 | 定期备份 etcd、关键 YAML、Helm values 和证书 |
常见架构问题
| 问题 | 排查方向 |
|---|---|
| API Server 慢 | 查看控制面负载、审计日志、etcd 延迟和请求量 |
| 节点 NotReady | 检查 kubelet、containerd、CNI、磁盘和网络 |
| Pod 无法调度 | 检查 Scheduler 事件、资源、污点、亲和性和 PVC |
| Service 不通 | 检查 EndpointSlice、kube-proxy、CNI 和 NetworkPolicy |
| DNS 异常 | 检查 CoreDNS、kube-dns Service、上游 DNS 和节点网络 |