Kubernetes 架构详解及实战示例
Kubernetes 已成为容器编排领域的行业标准，但其复杂的架构常常让新手望而生畏。本指南通过结合实例的 Kubernetes 架构详解，逐一剖析每个组件，展示它们如何在生产环境中协同工作，实现应用程序的自动化部署、扩缩容和管理。
你将学到什么
学完本指南后，你将理解 Kubernetes 集群组件如何交互以可靠地运行容器化应用，并能识别每个控制平面和工作节点组件的角色。你将能够通过一个具体示例，完整解释从用户提交部署到应用可用的整个请求流程。
工作原理：分层架构与现实类比
将 Kubernetes 集群想象成一家航运公司。控制平面是公司总部，由管理者制定战略决策。工作节点则是实际运载集装箱的货船。船上的每个集装箱就是一个 Pod，即 Kubernetes 中最小的可部署单元。
控制平面：集群的大脑
控制平面负责管理集群状态并协调所有活动。它由以下几个关键组件构成：
kube-apiserver 扮演前台的角色——所有与集群的通信都通过此组件进行。当你运行 kubectl 命令时，API 服务器会验证你的请求、校验其合法性，并更新存储在 etcd 中的集群状态。etcd 是一个分布式键值存储系统，作为 Kubernetes 所有集群数据的后端存储。
kube-scheduler 负责监控新创建的、尚未分配节点的 Pod。它会根据资源需求、约束条件和策略，智能地选择最合适的工作节点。例如，如果你请求一个需要 GPU 的 Pod，调度器只会考虑具备 GPU 资源的节点。
kube-controller-manager 运行着一组控制器，持续监控集群状态并进行修正。节点控制器检测节点是否宕机，任务控制器管理一次性任务，端点切片控制器则将服务与 Pod 连接起来。
工作节点：应用运行的地方
每个工作节点运行三个核心组件：
kubelet 是主要的节点代理，确保容器按照规范在 Pod 中运行。它从 API 服务器接收 Pod 规范，并管理容器运行时来启动和监控这些容器。
kube-proxy 维护网络规则，允许从集群内部或外部与 Pod 通信。它通过数据包过滤规则将流量转发到正确的 Pod，从而实现服务概念。
容器运行时（如 containerd 或 CRI-O）是实际负责运行容器的软件。
实战示例：部署一个 Web 应用
让我们追踪部署 Nginx Web 服务器的完整流程：
- 你编写一个 Deployment YAML 文件，指定 3 个 Nginx 容器副本。
- 使用
kubectl apply -f deployment.yaml提交该文件。请求到达 API 服务器。 - API 服务器验证你的身份，并将期望状态存储在 etcd 中。
- 调度器检测到未调度的 Pod，并将它们分配给具有可用容量的工作节点。
- 在每个被分配的工作节点上，kubelet 接收 Pod 规范，并指示容器运行时拉取 Nginx 镜像并启动容器。
- 控制器管理器持续验证 3 个副本是否在运行，如果某个 Pod 失败，它会创建一个替代 Pod。
- 创建一个服务来暴露应用，kube-proxy 配置网络规则，使流量能够到达 Pod。
为什么这很重要
Kubernetes 的架构赋予了组织从根本上改变软件部署和管理方式的能力：
自我修复：如果容器崩溃或节点无响应，控制器会自动在健康节点上替换失败的 Pod，最大限度地减少停机时间。
水平扩缩容：水平 Pod 自动扩缩器可以根据 CPU 利用率或自定义指标自动调整 Pod 副本数量，使应用无需人工干预即可应对流量高峰。
滚动更新与回滚：部署支持零停机更新。你可以逐步用新版本替换旧 Pod，如果出现问题，可以立即回滚。
资源效率：调度器优化 Pod 在节点间的放置，提高资源利用率并降低基础设施成本。
数据一览
| 指标 | 详情 |
|---|---|
| 初始发布 | Kubernetes 1.0 于 2015 年 7 月 21 日发布 |
| 控制平面节点 | 生产集群通常运行 3 个控制平面节点以实现高可用性 |
| 工作节点 | 大型集群可超过 1,000 个工作节点 |
| 每个节点的默认 Pod 数 | 默认最多 110 个（可配置） |
| API 请求延迟 | 在调优良好的集群中，第 99 百分位通常低于 1 秒 |
| etcd | 在 NVMe 存储上每秒可处理约 10,000 次写入 |
常见误区与事实
| 误区 | 事实 |
|---|---|
| "Kubernetes 直接在节点上运行容器。" | Kubernetes 从不直接运行容器——它们始终在 Pod 内运行，Pod 是最小的可部署单元，包含网络和存储。 |
| "API 服务器是单点故障。" | kube-apiserver 设计为通过部署多个实例并负载均衡来实现水平扩展。 |
| "所有 Kubernetes 集群都必须运行 kube-proxy。" | 网络插件可以实现自己的服务代理，在这种情况下 kube-proxy 是可选的。 |
| "Pod 应该始终只包含一个容器。" | Pod 可以包含多个紧密耦合的容器，它们共享网络和存储，例如 Web 服务器和日志记录容器。 |
| "etcd 数据对集群运行不重要。" | etcd 是所有集群数据的后端存储，你必须为其制定备份计划。 |
你应该如何运用这些知识
要有效使用 Kubernetes 架构：
- 如果你是新手，从托管 Kubernetes 开始——像 GKE、EKS 或 AKS 这样的服务抽象了控制平面管理，让你可以专注于应用。
- 学会阅读核心资源的 YAML 清单：Pod、Deployment、Service 和 ConfigMap。这些是你日常使用的基本构建块。
- 使用 kubectl 的 describe 和 logs 命令进行故障排除——理解组件如何通信将帮助你更快地诊断问题。
- 始终在 Deployment 清单中指定资源请求和限制。这有助于调度器做出最佳放置决策，并防止资源匮乏。
- 在了解基本架构后，探索网络策略以保护 Pod 之间的通信。
常见问题解答
Deployment 和 Service 有什么区别？ Deployment 管理 Pod 副本的生命周期——它确保指定数量的相同 Pod 在运行，并处理更新和回滚。Service 提供稳定的网络端点来访问这些 Pod，而 Pod 是临时的，随时可能被替换。
为什么 Kubernetes 需要 etcd？ etcd 作为 Kubernetes 的主要数据存储，一致且持久地存储所有集群状态信息，包括哪些 Pod 在运行、存在哪些服务以及配置数据。没有 etcd，集群就没有关于其期望状态和实际状态的"真相来源"。
如果工作节点宕机会发生什么？ 节点控制器会检测到节点不可用（通常在超时后）。然后调度器会将故障节点上运行的所有 Pod 重新调度到其他健康节点，以维持所需的副本数量。
Service 如何将流量路由到 Pod？ Service 维护一组端点——即与其标签选择器匹配的 Pod 的 IP 地址。每个节点上的 kube-proxy 会编程网络规则（iptables 或 IPVS），将发往 Service 虚拟 IP 的流量重定向到这些端点，从而在 Pod 之间提供负载均衡。
Job 和 CronJob 有什么区别？ Job 创建一个或多个 Pod 并确保它们成功终止——用于一次性任务，如运行数据库备份。CronJob 按重复计划创建 Job，适用于定期维护任务，如每日日志清理。
来源
- Kubernetes 官方文档 – 集群架构
- SLAC 国家加速器实验室 Kubernetes 培训文档
- KodeKloud Kubernetes 入门笔记
- LabEx Kubernetes 教程与指南
- Kubernetes 综合指南（GitHub）
— Editorial Team
暂无评论。