集群架构

Kubernetes 背后的架构概念。

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

worker 节点托管作为应用程序工作负载组件的 Pod。控制平面管理集群中的 worker 节点和 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 的深入信息。

kube-scheduler

控制平面组件，用于监视新创建的、没有分配节点的 Pod，并为其选择要运行的节点。

调度决策考虑的因素包括：个人和集体资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据局部性、工作负载间的干扰和截止日期。

kube-controller-manager

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

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

有许多不同类型的控制器。其中一些示例是

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

以上不是详尽的列表。

cloud-controller-manager

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

cloud-controller-manager 仅运行特定于云提供商的控制器。如果您在自己的场所或在自己的 PC 内的学习环境中运行 Kubernetes，则该集群没有云控制器管理器。

与 kube-controller-manager 类似，cloud-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 (仪表盘)

仪表盘是 Kubernetes 集群的通用、基于 Web 的 UI。它允许用户管理和排除集群中运行的应用程序以及集群本身。

容器资源监控

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

集群级日志记录

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

网络插件

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

架构变体

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

控制平面部署选项

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

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

工作负载放置注意事项

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

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

集群管理工具

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

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

定制和可扩展性

Kubernetes 架构允许进行大量的定制

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