集群架构

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

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

本文档概述了构成一个完整且可工作的 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 对象（提供 Service 和 Pod 之间的链接）。
• ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

以上并非详尽列表。

云控制器管理器

一个 Kubernetes 控制平面 组件，它嵌入了云特定的控制逻辑。云控制器管理器让你将集群链接到云提供商的 API，并将与该云平台交互的组件与仅与集群交互的组件分离。

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

与 kube-controller-manager 一样，云控制器管理器将几个逻辑上独立的控制循环组合成一个你作为单个进程运行的二进制文件。你可以水平扩展（运行多个副本）以提高性能或帮助容忍故障。

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

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

---

节点组件

节点组件在每个节点上运行，维护运行中的 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 服务提供 DNS 记录。

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

Web UI (仪表板)

仪表板 是一个通用的、基于 Web 的 Kubernetes 集群 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 服务器可以通过 CustomResourceDefinitions 和 API Aggregation 进行扩展。
• 云提供商可以使用云控制器管理器与 Kubernetes 深度集成。

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

下一步

了解更多信息：

• 节点 以及它们与控制平面的通信。
• Kubernetes 控制器。
• Kubernetes 的默认调度器 kube-scheduler。
• Etcd 的官方文档。
• Kubernetes 中的几种容器运行时。
• 使用 cloud-controller-manager 与云提供商集成。
• kubectl 命令。