Kubernetes 架构指南 | Linux 中国
使用 Kubernetes 来编排容器，这种描述说起来简单，但理解它的实际含义以及如何实现它完全是另外一回事。如果你正在运行或管理 Kubernetes 集群，那么你就会知道 Kubernetes 由一台称为 “控制平面” 的机器和许多其他 工作节点 机器组成。每种类型都有一个复杂但稳定的堆栈，这使编排成为可能，熟悉每个组件有助于理解它是如何工作的。
（Nived Velayudhan, CC BY-SA 4.0）
控制平面组件
Kubernetes 安装在一个称为“控制平面”的机器上，它会运行 Kubernetes 守护进程，并在启动容器和容器组时与之通信。下面介绍控制平面的各个组件。
etcd
etcd 是一种快速、分布式一致性键值存储器，用作 Kubernetes 对象数据的持久存储，如容器组、副本控制器、密钥和服务。etcd 是 Kubernetes 存储集群状态和元数据的唯一地方。唯一与 etcd 直连的组件是 Kubernetes API 服务器。其他所有组件都通过 API 服务器间接的从 etcd 读写数据。
etcd 还实现了一个监控功能，它提供了一个基于事件的接口，用于异步监控键的更改。一旦你更改了一个键，它的监控者就会收到通知。API 服务器组件严重依赖于此来获得通知，并将 etcd 变更至期望状态。
为什么 etcd 实例的数量应该是奇数？
你通常会运行三个、五个或七个 etcd 实例实现高可用（HA）环境，但这是为什么呢？因为 etcd 是分布式数据存储，可以水平扩展它，但你需要确保每个实例中的数据是一致的。因此，需要为系统当前状态达成共识，etcd 为此使用 RAFT 共识算法。
RAFT 算法需要经过选举（或仲裁）集群才能进入下一个状态。如果你只有两个 etcd 实例并且他们其中一个失败的话，那么 etcd 集群无法转换到新的状态，因为不存在过半这个概念。如果你有三个 etcd 实例，一个实例可能会失败，但仍有 2 个实例可用于进行选举。
API 服务器
API 服务器是 Kubernetes 中唯一直接与 etcd 交互的组件。Kubernetes 中的其他所有组件都必须通过 API 服务器来处理集群状态，包括客户端（kubectl）。API 服务器具有以下功能：
控制器管理器
在 Kubernetes 中，控制器持续监控集群状态，然后根据需要进行或请求更改。每个控制器都尝试将当前集群状态变更至期望状态。控制器至少跟踪一种 Kubernetes 资源类型，这些对象均有一个字段来表示期望的状态。
控制器示例：
控制器通过监控机制来获得变更通知。它们监视 API 服务器对资源的变更，对每次更改执行操作，无论是新建对象还是更新或删除现有对象。大多数时候，这些操作包括创建其他资源或更新监控的资源本身。不过，由于使用监控并不能保证控制器不会错过任何事件，它们还会定期执行一系列操作，确保没有错过任何事件。
控制器管理器还执行生命周期功能。例如命名空间创建和生命周期、事件垃圾收集、已终止容器组垃圾收集、级联删除垃圾收集 和节点垃圾收集。有关更多信息，参考 云控制器管理器。
调度器
调度器是一个将容器组分配给节点的控制平面进程。它会监视新创建没有分配节点的容器组。调度器会给每个发现的容器组分配运行它的最佳节点。
满足容器组调度要求的节点称为可调度节点。如果没有合适的节点，那么容器组会一直处于未调度状态，直到调度器可以安置它。一旦找到可调度节点，它就会运行一组函数来对节点进行评分，并选择得分最高的节点，然后它会告诉 API 服务器所选节点的信息。这个过程称为绑定。
节点的选择分为两步：
调度决策要考虑的因素包括：
调度器不会指示所选节点运行容器组。调度器所做的就是通过 API 服务器更新容器组定义。然后 API 服务器通过监控机制通知 kubelet 容器组已被调度，然后目标节点上的 kubelet 服务看到容器组被调度到它的节点，它创建并运行容器组。
工作节点组件
工作节点运行 kubelet 代理，这允许控制平面接纳它们来处理负载。与控制平面类似，工作节点使用几个不同的组件来实现这一点。以下部分描述了工作节点组件。
Kubelet
Kubelet 是一个运行在集群中每个节点上的代理，负责在工作节点上运行的所有事情。它确保容器在吊舱中运行。
kubelet服务的主要功能有：
服务代理
服务代理（kube-proxy）在每个节点上运行，确保一个容器组可以与另一个容器组通讯，一个节点可以与另一个节点对话，一个容器可以与另一个容器对话。它负责监视 API 服务器对服务和容器组定义的更改，以保持整个网络配置是最新的。当一项服务得到多个容器组的支持时，代理会在这些容器组之间执行负载平衡。
kube-proxy 之所以叫代理，是因为它最初实际上是一个代理服务器，用于接受连接并将它们代理到容器组。当前的实现是使用 iptables 规则将数据包重定向到随机选择的后端容器组，而无需通过实际的代理服务器。
关于它工作原理的高级视图：
容器运行时
容器运行时有两类：
容器运行时负责：
协同
系统级组件协同工作，确保 Kubernetes 集群的每个部分都能实现其目和执行其功能。当你深入编辑 YAML 文件 时，有时很难理解请求是如何在集群中通信的。现在你已经了解了各个部分是如何组合在一起的，你可以更好地理解 Kubernetes 内部发生了什么，这有助于诊断问题、维护健康的集群并优化你的工作流。
via: https://opensource.com/article/22/2/kubernetes-architecture
作者：Nived Velayudhan 选题：lujun9972 译者：MjSeven 校对：turbokernel
微信扫码关注该文公众号作者