Kubernetes 集群架构

Kubernetes 集群由一个控制平面和一系列称为节点（Node）的工作机器组成，在这些节点上运行容器化的应用。一个集群至少需要一个 worker 节点来运行 Pod。

worker 节点负责托管应用的工作负载 Pod，控制平面负责管理集群中的所有 worker 节点和 pod。在生产环境中，控制平面通常跨多台计算机运行，且一个集群中通常运行多个节点，从而保障系统的容错性和可用性。

文章概述了 Kubernetes 的整体架构，并对架构中的组件进行扼要介绍。

• 上图展示了 Kubernetes 集群的参考示例架构。架构中的具体组件会因具体需求有不同的设置。

• 上图中的节点中默认运行 kube-proxy 组件，需要在每个节点上对该组件进行网络配置，以确保服务应用程序接口（Service API）及其相关功能在集群网络中可用。不过，有些网络插件提供了它们自己的第三方代理实现方式。在使用这类网络插件时，节点就无需运行 kube-proxy 组件了。

控制平面组件

控制平面中的组件负责对集群做出全局决策（例如，资源调度），以及检测和响应集群事件（例如，当 Deployment 的 replicas 字段不满足时启动新的 pod ）。

控制平面组件可以在集群中的任何计算机上运行。但是，为简单起见，安装脚本通常在同一台机器上启动所有控制平面组件，并且不会在此机器上运行用户容器。有关跨多台计算机运行的控制平面的示例，请参阅使用 kubeadm 创建高可用性集群。

kube-apiserver

API 服务是 kubernetes 控制平面的一个组件，作为 Kubernetes 控制平面的前端，用来公布 Kubernetes API，并处理服务请求。

kube-apiserver 是 Kubernetes API 服务的一个主要实现。kube-apiserver 被设计为可水平伸缩的，也就是说，可以通过部署多个实例，来平衡实例之间的访问流量。

etcd

高一致性和高可用性的键值对存储，用作 Kubernetes 所有集群数据的后台数据库。

在使用 etcd 作为 Kubernetes 集群的后台存储时，应该制定相应的数据备份计划。

kube-scheduler

kube-scheduler 组件监听没有分配节点的新创建 Pod，为其选择一个节点来运行。

调度决策的因素有：单个 Pod 和 Pod 集合的资源要求、硬件/软件/策略约束、亲和性¹和反亲和性²规范、数据位置、工作负载间干扰和最后时限。

kube-controller-manager

一个运行 controller³ 进程的控制平面组件。

从逻辑上讲，每个控制器都是一个独立的进程。为了降低复杂性，它们都被编译成一个独立的二进制文件，并在单个进程中运行。

控制器有许多不同类型，包括但不限于以下类型：

• 节点控制器：负责在节点宕机时进行通知和响应。
• Job 控制器：监视代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直到完成。
• EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）。
• ServiceAccount 控制器：为新命名空间创建默认 ServiceAccount。

cloud-controller-manager

Kubernetes 的控制平面组件，嵌入了特定于云平台的控制逻辑。云控制器管理器允许用户将集群链接到云供应商的 API，并将与该云平台交互的组件与集群交互组件解耦。

cloud-controller-manager 运行的控制器特定于云供应商提供的云平台。如果在本地 PC 内的学习环境中运行 Kubernetes，则集群不需要启动云控制器管理器组件。

与 kube-controller-manager 一样，cloud-controller-manager 将几个逻辑上独立的控制循环打包成一个二进制文件，作为单个进程运行。可以水平扩展（运行多个副本）以提高性能和提升故障容忍度⁴。

下列控制器中可能会包含对云供应商的依赖：

• 节点控制器：用于检查确定节点在停止响应后，云供应商以是否从云中删除节点
• 路由控制器：用于在底层云基础设施中设置路由
• 服务控制器：用于创建、更新和删除云供应商负载均衡器

节点组件

Node 组件在每个节点上运行，维护正在运行的 Pod 并提供 Kubernetes 运行时环境。

kubelet

在集群中的每个节点上运行的代理。它确保容器在 Pod 中运行。

kubelet 采用一组通过各种机制提供的 PodSpec，并确保这些 PodSpec 中描述的容器正在运行且健康。kubelet 不管理不是由 Kubernetes 创建的容器。

kebe-proxy（可选）

kube-proxy 是一个网络代理，运行在集群中的每个节点上，实现了 Kubernetes Service⁵ 的一部分。

kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络连接 Pod 进行网络通信。

在操作系统数据包过滤层有效的情况下，kube-proxy 使用操作系统的数据包过滤层⁵，否则，kube-proxy 会对流量本身进行转发。

如果在集群中已经使用了网络插件，且插件本身实现了 Services 的数据转发，提供与 kube-proxy 等效的行为，那么就无须在集群节点上运行 kube-proxy 组件。

容器运行时

保障 Kubernetes 能够有效运行容器的基本组件。它负责管理 Kubernetes 环境中容器的执行和生命周期。

Kubernetes 支持容器运行时，例如containerd、CRI-O 以及 Kubernetes CRI （Container RuntimeInterface）⁶ 的任何其他实现。

插件

插件使用 Kubernetes 资源（DaemonSet、Deployment 等）来实现集群功能。由于这些插件提供的是集群级别的功能，所以插件的命名空间资源属于 kube-system 命名空间。

下文列举常用插件，有关可用插件的扩展列表，请参阅 Addons。

DNS

DNS 插件不是必须使用，但是建议每个 Kubernetes 集群都应该有集群 DNS，大多数实例都依赖于它。

集群 DNS 是一个 DNS 服务器，除了环境中的其他 DNS 服务器之外，它还为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器会自动将此 DNS 服务器包含在其 DNS 搜索中。

Web UI（Dashboard）

Dashboard 是适用于 Kubernetes 集群的基于 Web 的通用 UI。它允许用户管理集群中运行的应用程序以及集群本身，并对其进行故障排除。

容器资源监控

容器资源监控（Container Resource Monitoring） 在中央数据库中记录有关容器的通用时间序列指标，并提供用于浏览这些数据的 UI。

集群级日志输出

集群级日志记录机制负责将容器日志保存到具有搜索/浏览界面的中央日志存储中。

网络插件

网络插件是实现容器网络接口 （CNI） 规范的软件组件。它们负责为 Pod 分配 IP 地址，并使它们能够在集群内相互通信。

架构变体

虽然 Kubernetes 的核心组件保持一致，但它们的部署和管理方式可能会有所不同。了解这些变化对于设计和维护满足特定运营需求的 Kubernetes 集群至关重要。

控制平面部署选项

控制平面组件可以通过多种方式进行部署：

传统部署

控制平面组件直接在专用机器或 VM 上运行，通常作为 systemd 服务进行管理。

静态 Pod

控制平面组件部署为静态 Pod，由特定节点上的 kubelet 管理。这是 kubeadm 等工具常用的方法。

自托管

控制平面在 Kubernetes 集群本身中作为 Pod 运行，由 Deployments 和 StatefulSets 或其他 Kubernetes 原语管理。

托管 Kubernetes 服务

云供应商通常会抽象出控制平面，将其组件作为其服务产品的一部分进行管理。

工作负载调度说明

工作负载（包括控制平面组件）的调度可能因集群大小、性能要求和操作策略而异：

• 在较小的集群或开发集群中，控制平面组件和用户工作负载可能在同一节点上运行。
• 较大的生产集群通常将特定节点专用于控制平面组件，将它们与用户工作负载分开。
• 一些组织在控制平面节点上运行关键的附加组件或监控工具。

集群管理工具

kubeadm、kops 和 Kubespray 等工具提供了不同的方法来部署和管理集群，每种方法都有自己的组件布局和管理方法。

Kubernetes 架构的灵活性使组织能够根据特定需求定制其集群，平衡运营复杂性、性能和管理开销等因素。

定制和可扩展性

Kubernetes 架构允许进行重大定制：

• 可以部署自定义调度程序以与默认 Kubernetes 调度程序一起使用，也可以完全替换它。
• API 服务器可以通过 CustomResourceDefinitions 和 API 聚合进行扩展。
• 云供应商可以使用 cloud-controller-manager 与 Kubernetes 深度集成。

Kubernetes 架构的灵活性使组织能够根据特定需求定制其集群，平衡运营复杂性、性能和管理开销等因素。

链接

• Kubernetes Cluster Architecture
• 使用 kubeadm 创建高可用性集群
• kube-apiserver
• Kubernetes etcd 集群运维
• etcd 官方文档
• controller
• kubelet
• Service
• kube-proxy
• Kubernetes Addons
• 集群 DNS
• Dashboard
• 容器资源监控（Container Resource Monitoring）
• 集群级日志记录
• 网络插件

---

1. 在 Kubernetes（k8s）中，亲和性是一种调度策略，用于定义 Pod 更倾向于被调度到哪些节点或者与其他 Pod 部署在相近的位置。它允许基于节点的标签（Label）和 Pod 的标签来指定调度规则，使 Pod 能够根据特定的条件被放置在合适的节点上。 ↩︎

2. 与亲和性相反，反亲和性是一种调度策略，用于确保 Pod 不会被调度到某些节点或者不会与某些 Pod 部署在相近的位置。它主要用于高可用（HA）和故障隔离等场景，避免单点故障或者资源竞争等问题。 ↩︎

3. 在K8S中，controller 是一种控制循环机制，它会持续监控集群的状态，将实际状态与期望状态进行对比，并自动采取措施（如创建、更新或删除资源）来使实际状态向期望状态收敛。 ↩︎

4. 在 Kubernetes（K8S）中，故障容忍度（Fault Tolerance）是指系统（主要是指由 Kubernetes 管理的容器化应用集群）能够在部分组件（如节点、Pod 等）出现故障的情况下，依然可以提供服务，维持应用程序的正常运行，并且尽可能减少对用户的影响。它是衡量系统可靠性和可用性的一个重要指标。 ↩︎

5. 操作系统数据包过滤层是网络安全防护体系中的一个关键部分，位于操作系统的网络协议栈中，主要功能是对进出计算机系统的网络数据包进行检查和过滤。它是一种基于规则的防火墙技术，通过设定一系列规则来允许或禁止数据包的通过。 ↩︎ ↩︎

6. Kubernetes CRI（Container Runtime Interface）是Kubernetes与容器运行时之间的接口标准，它解耦了Kubernetes和容器运行时（如Docker、containerd等），使得Kubernetes可以通过统一的接口来管理不同的容器运行时，方便更换容器运行时并确保容器生命周期管理等操作的一致性。 ↩︎