集群架构

Kubernetes 背后的架构概念。

Kubernetes 集群由控制平面和一组被称为节点的工作机器组成，这些工作机器运行容器化应用。每个集群至少需要一个工作节点才能运行 Pod。

工作节点托管构成应用工作负载的 Pod。控制平面管理集群中的工作节点和 Pod。在生产环境中，控制平面通常跨多台计算机运行，并且集群通常运行多个节点，提供容错能力和高可用性。

本文档概述了构建一个完整且可工作的 Kubernetes 集群所需的各种组件。

The control plane (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) and several nodes. Each node is running a kubelet and kube-proxy. — 图 1. Kubernetes 集群组件。

关于此架构

图 1 中的图示展示了 Kubernetes 集群的一个示例参考架构。组件的实际分布会根据特定的集群设置和要求而有所不同。

在图示中，每个节点都运行 kube-proxy 组件。你需要在每个节点上运行网络代理组件，以确保 Service API 和相关行为在你的集群网络上可用。然而，一些网络插件提供了自己的第三方代理实现。当你使用这类网络插件时，节点就不需要运行 kube-proxy。

控制平面组件

控制平面的组件负责做出关于集群的全局决策（例如调度），以及检测和响应集群事件（例如，当 Deployment 的 副本数 (replicas) 字段未满足时启动新的 Pod）。

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

kube-apiserver

API 服务器是 Kubernetes 控制平面的一个组件，它暴露了 Kubernetes API。API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。kube-apiserver 被设计为可以水平扩缩——也就是说，通过部署更多实例来扩缩。你可以运行多个 kube-apiserver 实例并在这些实例之间平衡流量。

etcd

一个一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后端存储。

如果你的 Kubernetes 集群使用 etcd 作为后端存储，请确保你为数据制定了备份计划。

你可以在 etcd 官方文档中找到关于 etcd 的深入信息。

kube-scheduler

控制平面组件，负责监视新创建的尚未分配节点的Pod，并为它们选择一个运行节点。

调度决策考虑的因素包括：单个和集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据本地性、工作负载间干扰以及截止期限。

kube-controller-manager

运行控制器进程的控制平面组件。

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

控制器有许多不同的类型。以下是一些示例：

节点控制器：负责注意节点何时宕机并做出响应。
Job 控制器：监视表示一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直到完成。
EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Services 和 Pods 之间的链接）。
ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

以上并非完整列表。

cloud-controller-manager

Kubernetes 组件，内嵌云提供商特定的控制逻辑。云控制器管理器允许你将集群链接到云提供商的 API，并将与云平台交互的组件与仅与集群交互的组件分离开来。

cloud-controller-manager 只运行特定于你的云提供商的控制器。如果你在自己的本地环境或自己 PC 的学习环境中运行 Kubernetes，则集群中没有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将几个逻辑上独立的控制回路组合成一个二进制文件，并作为单个进程运行。你可以水平扩缩（运行多个副本）以提高性能或帮助容忍故障。

以下控制器可能依赖于云提供商：

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

节点组件

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

kubelet

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

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

kube-proxy (可选)

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

kube-proxy 在节点上维护网络规则。这些网络规则允许来自集群内部或外部网络会话的网络通信到达你的 Pod。

如果操作系统提供了数据包过滤层并且可用，kube-proxy 会使用它。否则，kube-proxy 会自行转发流量。

如果你使用一个网络插件，它自己实现了 Service 的数据包转发，并提供了与 kube-proxy 等效的行为，那么你的集群节点上就不需要运行 kube-proxy。

容器运行时

一个基础组件，使 Kubernetes 能够有效运行容器。它负责管理 Kubernetes 环境中容器的执行和生命周期。

Kubernetes 支持多种容器运行时，例如 containerd、CRI-O，以及任何其他实现Kubernetes CRI (容器运行时接口) 的运行时。

插件

插件利用 Kubernetes 资源（DaemonSet、Deployment 等）来实现集群功能。由于它们提供的是集群级别的功能，因此插件的命名空间资源应位于 kube-system 命名空间内。

下面描述了一些选定的插件；有关可用插件的完整列表，请参阅插件。

DNS

虽然其他插件不是严格必需的，但所有 Kubernetes 集群都应该具有集群 DNS，因为许多示例都依赖于它。

集群 DNS 是一个 DNS 服务器，它在你环境中其他 DNS 服务器之外，为 Kubernetes Service 提供 DNS 记录。

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

Web UI (控制台)

控制台是用于 Kubernetes 集群的通用 Web UI。它允许用户管理和排查集群中运行的应用，以及集群本身的问题。

容器资源监控

容器资源监控将关于容器的通用时间序列指标记录到中央数据库中，并提供用于浏览这些数据的 UI。

集群级别日志记录

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

网络插件

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

架构变体

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

控制平面部署选项

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

传统部署: 控制平面组件直接运行在专用机器或虚拟机上，通常作为 systemd 服务进行管理。
静态 Pod: 控制平面组件作为静态 Pod 部署，由特定节点上的 kubelet 管理。这是 kubeadm 等工具常用的方法。
自托管: 控制平面本身作为 Pod 运行在 Kubernetes 集群中，由 Deployment 和 StatefulSet 或其他 Kubernetes 基本类型进行管理。
托管的 Kubernetes 服务: 云提供商通常会抽象出控制平面，将其组件作为其服务产品的一部分进行管理。

工作负载放置考量

工作负载的放置，包括控制平面组件，会根据集群规模、性能要求和运维策略而有所不同：

在较小或开发集群中，控制平面组件和用户工作负载可能运行在同一节点上。
较大的生产集群通常会为控制平面组件分配专用节点，将其与用户工作负载分开。
一些组织会在控制平面节点上运行关键插件或监控工具。

集群管理工具

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

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

定制和可扩展性

Kubernetes 架构允许进行显著的定制：

可以部署自定义调度器与默认的 Kubernetes 调度器一起工作，或完全替换它。
API 服务器可以通过 CustomResourceDefinition 和 API 聚合进行扩展。
云提供商可以使用 cloud-controller-manager 与 Kubernetes 进行深度集成。