Kubernetes架构指南

了解Kubernetes架构的不同组件是如何组合在一起的，这样你就可以更好地诊断问题，维护健康的集群，并优化工作流程。

你可以使用Kubernetes编排容器。这听上去很简单，但理解这实际上意味着什么，以及如何完成完全是另一回事。如果你正在运行或管理Kubernetes集群，那么你知道Kubernetes由一台指定为控制平面的计算机和许多其他指定为工作节点的计算机组成。每一个都有一个复杂但强大的堆栈，使编排成为可能，熟悉每个组件有助于理解它们是如何工作的。

控制平面组件

你把Kubernetes安装在一个叫作控制平面的机器上。它运行Kubernetes守护程序，在启动容器和pod时与之通信。以下介绍控制平面组件。

etcd

etcd是一种快速、分布式、一致的键值存储，用作持久存储Kubernetes对象数据（如pod、复制控制器、秘密和服务）的后备存储。etcd是Kubernetes存储集群状态和元数据的唯一地方。与etcd直接对话的唯一组件是Kubernetes API服务器。所有其他组件通过API服务器间接向etcd读写数据。

etcd还实现了一个监视功能，它提供了一个基于事件的接口，用于异步监视密钥的更改。一旦你更改了一个密钥，监视器就会得到通知。API服务器组件严重依赖于此来获得通知，并将etcd的当前状态迁移到所需状态。

为什么etcd实例的数量应该是奇数？

在高可用性（HA）环境中，通常会有三个、五个或七个etcd实例运行，但为什么呢？因为etcd是一个分布式数据存储。可以横向扩展，但也需要确保每个实例中的数据是一致的，为此，系统需要就状态达成共识。etcd为此使用RAFT共识算法。

该算法需要多数（或仲裁）才能使集群进入下一个状态。如果只有两个ectd实例，且其中任何一个都失败，etcd集群将无法转换到新状态，因为不存在多数。如果有三个ectd实例，一个实例可能会失败，但仍有大多数实例可用于达到仲裁。

API服务器

API服务器是Kubernetes中唯一直接与etcd交互的组件。Kubernetes中的所有其他组件必须通过API服务器才能与集群状态一起工作，包括客户端（kubectl）。API服务器具有以下功能：

——提供在etcd中存储对象的一致方式。

——对这些对象执行验证，这样客户端就不会存储配置不当的对象（如果直接写入etcd数据存储，可能会发生这种情况）。

——提供RESTful API来创建、更新、修改或删除资源。

——提供乐观并发锁定，因此在并发更新的情况下，其他客户端永远不会覆盖对对象的更改。

——对客户端发送的请求执行身份验证和授权。它使用插件提取客户端的用户名、用户ID、用户所属的组，并确定经过身份验证的用户是否可以对请求的资源执行请求的操作。

——如果请求试图创建、修改或删除资源，则负责许可控制。例如，AlwaysPubllimages、DefaultStorageClass和ResourceQuota。

——实现一种监视机制（类似于etcd），以便客户端监视更改。这允许调度器和控制器管理器等组件以松耦合的方式与API服务器交互。

控制器管理器

在Kubernetes中，控制器是监视集群状态的控制循环，然后在需要时进行更改或请求更改。每个控制器都会尝试将当前集群状态移近所需状态。控制器跟踪至少一种Kubernetes资源类型，这些对象有一个表示所需状态的spec字段。

控制器示例：

——Replication Manager（用于ReplicationController资源的控制器）

——复制集、守护程序集和作业控制器

——部署控制器

——状态集控制器

——节点控制器

——服务控制器

——端点控制器

——命名空间控制器

——持久卷控制器

控制器使用监视机制获得更改通知。它们监视API服务器对资源的更改，并对每次更改执行操作，无论是创建新对象还是更新或删除现有对象。大多数情况下，这些操作包括创建其他资源或更新监视的资源本身。尽管如此，因为使用监视并不能保证控制器不会错过一个事件，它们也会定期执行重新列出操作，以确保没有错过任何事情。

Controller Manager还执行生命周期功能，如命名空间创建和生命周期、事件垃圾收集、终止的pod垃圾收集、级联删除垃圾收集和节点垃圾收集。

调度器

调度器是一个控制平面进程，将pod分配给节点。它监视新创建的没有分配节点的pod。对于调度器发现的每一个pod，调度器将负责找到该pod运行的最佳节点。

满足pod调度要求的节点称为可行节点。如果没有合适的节点，pod将保持未调度状态，直到调度器可以放置它。一旦找到一个可行的节点，它就会运行一组函数对节点进行评分，并选择得分最高的节点。然后，它将所选节点通知API服务器。这个过程称为绑定。

节点的选择分为两步：

——筛选所有节点的列表，以获得可接受节点的列表，你可以将pod安排到这些节点（例如，PodFitsResources筛选器检查候选节点是否有足够的可用资源来满足pod的特定资源请求）。

——对从第一步获得的节点列表进行评分，并对它们进行排序，以选择最佳节点。如果多个节点得分最高，循环过程可以确保pod在所有节点上均匀部署。

调度决策考虑的因素包括：

——pod是否请求硬件/软件资源？节点是否报告内存或磁盘压力状况？

——节点是否具有与pod规范中的节点选择器匹配的标签？

——如果pod请求绑定到特定的主机端口，该端口可用吗？

——pod能容忍节点的污染吗？

——pod是否指定节点关联规则或反关联规则？

调度器不会指示所选节点运行pod。调度器只需通过API服务器更新pod定义。API服务器通知kubelet pod已通过监视机制调度。然后目标节点上的kubelet服务看到pod被调度到其节点，它创建并运行pod的容器。

工作节点组件

Worker节点运行kubelet代理，这允许它们被控制平面用来处理作业。与控制平面类似，工作节点使用几个不同的组件来实现这一点。以下介绍工作节点组件。

kubelet

kubelet是在集群中的每个节点上运行的代理，负责在工作节点上运行的所有内容。它确保容器在pod中运行。

kubelet服务的主要功能是：

——通过在API服务器中创建节点资源来注册它正在运行的节点。

——持续监控API服务器，以查看已调度到节点的pod。

——使用配置好的容器运行时启动pod的容器。

——持续监控正在运行的容器，并向API服务器报告它们的状态、事件和资源消耗。

——运行容器活性探测，当探针失败时重新启动容器，当容器的pod从API服务器上删除时终止容器（通知服务器pod终止）。

服务代理

服务代理（kube-proxy）在每个节点上运行，确保一个pod可以与另一个pod对话，一个节点可以与另一个节点对话，以及一个容器可以与另一个容器对话。它负责监视API服务器上服务和pod定义的更改，以保持整个网络配置是最新的。当一个服务得到多个pod的支持时，代理在这些pod之间执行负载均衡。

kube-proxy之所以得名，是因为它最初是一个实际的代理服务器，用于接受连接并将其代理到pod。当前的实现使用iptables规则将数据包重定向到随机选择的后端pod，而不通过实际的代理服务器。

关于其工作原理的高级视图：

——创建服务时，会立即分配虚拟IP地址。

——API服务器通知在工作节点上运行的kube-proxy存在新服务。

——每个kube-proxy通过设置iptables规则使服务可寻址，确保拦截每个服务IP/端口对，并将目标地址修改为支持服务的pod之一。

——监视API服务器对服务或其端点对象的更改。

容器运行时

有两类容器运行时：

——较低级别的容器运行时：它们关注于运行容器，并为容器设置命名空间和cgroup。

——更高级别的容器运行时（容器引擎）：它们关注格式、解包、管理、镜像共享，并为开发人员提供API。

容器运行时负责：

——从镜像注册表中提取所需的容器镜像（如果在本地不可用）。

——将镜像提取到一个写时拷贝文件系统上，并覆盖所有容器层，以创建一个合并的文件系统。

——准备容器挂载点。

——设置容器镜像中的元数据，如覆盖CMD、用户输入中的ENTRYPOINT，并设置SECCOMP规则，确保容器按预期运行。

——修改内核，将隔离（如进程、网络和文件系统）分配给该容器。

——提醒内核分配一些资源限制，如CPU或内存限制。

——将系统调用（syscall）传递给内核以启动容器。

——确保SElinux/AppArmor设置正确。

一起工作

系统级组件协同工作，以确保Kubernetes集群的每个部分都能实现其目的并执行其功能。有时（当你深入编辑一个YAML文件时），理解你的请求在集群中是如何被传达的可能会让你不知所措。现在，有了一张各部分如何组合在一起的视图，你可以更好地了解Kubernetes内部发生了什么，这有助于你诊断问题，维护健康的集群，并优化工作流程。

转自：Docker中文社区