【Kubernetes】（二）k8s基础—— k8s集群架构

作用：运行各类控制器，持续对比集群 “期望状态” 与 “实际状态”，自动修复偏差。
核心子控制器：
- Endpoint 控制器：维护 Service 与 Pod 的关联（自动更新 Endpoints 对象）。
- Node 控制器：监控 Node 健康状态，标记故障节点并驱逐其上的 Pod；
- ReplicaSet 控制器：确保 Pod 副本数符合预期；

（5） Cloud Controller Manager（可选）

作用：对接云服务商（如 AWS、阿里云）的基础设施，管理负载均衡器（Service 类为 LoadBalancer 时）、存储卷（如云盘挂载）、节点生命周期（如自动发现新节点）。
场景：仅在云环境中需要，自建集群可省略。

2.2 节点组件（Node Components）：工作节点的 “基础设施”

节点组件是运行在每个工作节点（Worker Node）上的核心进程，负责管理本地 Pod、与控制平面通信、实现网络 / 存储功能，是 Pod 运行的基础：

（1）kubelet

作用：节点的 “管家”，是控制平面与节点之间的 “桥梁”，负责管理节点上的 Pod 生命周期
核心功能：
- 管理 Pod 与节点的存储卷挂载（如 PV/PVC 对应的本地路径）。
- 向控制平面上报节点状态（如资源使用率、是否 Ready）和 Pod 状态（如 Running、Pending）；
- 执行 Pod 的健康检查（Liveness Probe、Readiness Probe、Startup Probe），异常时按重启策略处理；
- 监听 API Server 下发的 Pod 调度指令，调用容器运行时启动 / 停止 Pod 中的容器；
- 运行方式：以系统服务（如 systemd 服务）形式运行，节点启动时优先启动（需先于所有 Pod）。

（2） kube-proxy

作用：实现 Service 的网络代理功能，确保 Pod 之间、外部与 Pod 之间的通信。
核心功能：
- 实现 NodePort 类型 Service 的端口映射（节点端口→Service 端口）。
- 支持 Service 负载均衡（默认轮询），自动剔除不健康的 Pod（基于 Endpoints 状态）；
- 维护节点上的网络规则（如 iptables 或 ipvs），将 Service 的虚拟 IP（ClusterIP）流量转发到后端 Pod；
- 运行方式：通常以 DaemonSet 形式部署为 Pod（每个节点一个副本），依赖节点网络配置。

（3）容器运行时（Container Runtime）

作用：负责容器的实际创建、运行、销毁，是 Pod 中容器的 “运行引擎”。
常见实现：
- Docker：需配合 cri-dockerd 适配器（因 Docker 本身不直接支持 CRI）。
- CRI-O：专为 Kubernetes 设计的轻量级运行时，直接兼容 CRI；
- containerd：Kubernetes 推荐的默认运行时，轻量且符合 CRI（容器运行时接口）；
- 核心功能：接收 kubelet 指令（通过 CRI 接口），拉取镜像、创建容器（调用底层 runc），实现资源隔离（CPU / 内存限制）。
- 运行方式：以系统服务（如 containerd.service）形式运行，直接与操作系统内核交互（如通过 cgroups 限制资源）。

（4） CNI 网络插件（容器网络接口）

作用：为 Pod 配置网络（分配 IP、设置路由），实现跨节点 Pod 通信，是 Kubernetes 网络模型的核心。
常见方案：
- Cilium：基于 eBPF 的高性能网络，支持 L7 流量控制和服务网格功能。
- Flannel：简单的 overlay 网络（如 VXLAN），适合入门场景；
- Calico：基于 BGP 的三层网络，支持网络策略（NetworkPolicy），性能优异；
- 核心功能：为每个 Pod 分配唯一 IP（从节点的 PodCIDR 网段），配置 Pod 与节点的网络链路（如 veth 对），实现跨节点通信（隧道或路由）。
- 运行方式：通常以 DaemonSet 形式部署（如 calico-node Pod），由 kubelet 通过 /etc/cni/net.d 配置文件调用。

（5） CSI 节点插件（可选，容器存储接口）

作用：配合控制平面的 CSI 控制器，实现存储卷在节点上的挂载与管理，为 Pod 提供持久化存储。
核心功能：将远程存储（如 Ceph、云盘）或本地存储（如 hostPath）挂载到 Pod 的挂载点，处理卷的格式化、权限设置。
运行方式：以 DaemonSet 形式部署（如 csi-node-driver），每个节点一个副本，与 kubelet 和容器运行时协同工作。

2.3 附加组件：扩展集群功能的 “支撑系统”

这些组件负责网络通信、存储管理、流量路由、监控告警等 “支撑性” 工作，是集群功能完整的关键：

（1）服务网格（Service Mesh）

作用：管理服务间的通信（流量路由、熔断、限流、可观测性），无需修改业务代码。
代表方案：Istio（通过 Sidecar 代理注入 Pod，实现微服务治理）。

（2）可观测性系统

监控：
- Prometheus：采集节点、Pod、Service 的 metrics（如 CPU 使用率、请求延迟）；
- Grafana：可视化监控指标，生成大盘。
日志：
- Fluentd + Elasticsearch + Kibana（EFK）：采集 Pod 日志，支持检索与分析；
- Loki：轻量级日志系统，与 Prometheus 无缝集成。
告警：
- Alertmanager：基于 Prometheus 规则发送告警（邮件、Slack 等）。

（3）Ingress 控制器

作用：统一管理外部流量入口，通过域名路由到不同 Service。
常见方案：Nginx Ingress Controller、HAProxy Ingress、Traefik。

（4）命令行工具与 UI

kubectl：官方命令行工具，与 API Server 交互；
Kubernetes Dashboard：Web 界面，可视化管理集群（需单独部署）。

（5）批处理与 CI/CD 组件

Job/CronJob：管理一次性或定时任务（如数据备份、CI 构建）；
ArgoCD/FluxCD：实现 GitOps 风格的持续部署（自动同步代码仓库与集群状态）。

总结

Kubernetes 集群的架构是 “核心 + 扩展” 的协同体系：

控制平面（API Server、etcd、Scheduler 等）是 “决策中枢”，负责全局管理与调度；
节点组件（kubelet、kube-proxy、容器运行时等）是 “执行载体”，支撑 Pod 运行与节点级资源管理；
附加组件（服务网格、可观测性系统等）是 “功能扩展”，增强集群的网络、存储、运维能力。

三者协同工作，使 Kubernetes 成为一个功能完整的 “分布式系统运行框架”，能够支撑从简单应用到复杂微服务的全生命周期管理。

码道开发者社区

码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践

更多推荐

AI 已经能直接改设计稿了:Windows部署Penpot，接入Codex MCP实测

码道开发者社区

【AI 业务流架构师】AI 业务流架构师方法论：Agentic AI 范式转移与业务编排思维

2026 年，Anthropic CEO Dario Amodei 在 Code with Claude 大会上的一个判断广为流传：一个人运营一家十亿美元级公司的概率是 70%–80%。这句话听起来像科幻小说的设定，但它背后是一个正在发生的结构性变化——AI 把"执行"的成本压到了历史低点，同时把"编排"的价值推到了前台。这意味着我们需要一套新的思考框架，来回答两个问题：一个人如何拥有一个公司的产