蚊章汇 - Nived Velayudhan
type: channel
link: https://linuxcn.bwsl.wang/author/1627/
description: Nived Velayudhan
items: Kubernetes 架构指南
items: Kubernetes 部署的可视化地图

Kubernetes 架构指南
type: item
date: 2022-07-03T18:51:40+08:00
description: 了解 Kubernetes 架构中不同组件是如何组合在一起的，这样你就可以更好地排查问题、维护一个健康的集群，以及优化工作流。使用 Kubernetes 来编排容器，这种描述说起来简单，但理解它的实际含义以及如何实现它完全是另外一回事。如果你正在运行或管理 Kubernetes 集群，那么你就会知道 Kubernetes 由一台称为 “ 控制平面 control plane ” 的机器和许多其他 工作节点 worker node 机器组成。每种类型都有一个复杂但稳定的堆栈，这使编排成为可能，熟悉每个组件有助于理解它是如何工作的。（Nived Velayudhan, CC BY-SA 4.0）控制平面组件Kubernetes 安装在一个称为“ 控制平面 control plane ”的机器上，它会运行 Kubernetes 守护进程，并在启动容器和 容器组 pod 时与之通信。下面介绍控制平面的各个组件。etcdetcd 是一种快速、分布式一致性键值存储器，用作 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 服务器具有以下功能：提供在 etcd 中存储对象的一致方式。执行验证对象，防止客户端存储配置不正确的对象（如果它们直接写入 etcd 数据存储，可能会发生这种情况）。提供 RESTful API 来创建、更新、修改或删除资源。提供 乐观并发锁，在发生更新时，其他客户端永远不会有机会重写对象。对客户端发送的请求进行身份验证和授权。它使用插件提取客户端的用户名、ID、所属组，并确定通过身份验证的用户是否可以对请求的资源执行请求的操作。如果请求试图创建、修改或删除资源，则负责 权限控制。例如，AlwaysPullImages、DefaultStorageClass 和 ResourceQuota。实现了一种监控机制（类似于 etcd），用户客户端监控更改。这允许调度器和控制器管理器等组件以松耦合的方式与 API 服务器交互。控制器管理器在 Kubernetes 中，控制器持续监控集群状态，然后根据需要进行或请求更改。每个控制器都尝试将当前集群状态变更至期望状态。控制器至少跟踪一种 Kubernetes 资源类型，这些对象均有一个字段来表示期望的状态。控制器示例：副本管理器（管理 副本控制器 ReplicationController 资源的控制器） 副本集 ReplicaSet 、守护进程集DaemonSet 和任务控制器部署控制器有状态负载控制器节点控制器服务控制器接入点控制器命名空间控制器 持久卷 PersistentVolume 控制器控制器通过监控机制来获得变更通知。它们监视 API 服务器对资源的变更，对每次更改执行操作，无论是新建对象还是更新或删除现有对象。大多数时候，这些操作包括创建其他资源或更新监控的资源本身。不过，由于使用监控并不能保证控制器不会错过任何事件，它们还会定期执行一系列操作，确保没有错过任何事件。控制器管理器还执行生命周期功能。例如命名空间创建和生命周期、事件垃圾收集、已终止容器组垃圾收集、级联删除垃圾收集 和节点垃圾收集。有关更多信息，参考 云控制器管理器。调度器调度器是一个将容器组分配给节点的控制平面进程。它会监视新创建没有分配节点的容器组。调度器会给每个发现的容器组分配运行它的最佳节点。满足容器组调度要求的节点称为可调度节点。如…

Kubernetes 部署的可视化地图
type: item
date: 2022-03-01T17:58:09+08:00
description: 通过查看创建一个吊舱或一个部署时的 10 个步骤，可以更好地了解 Kubernetes。当你在 Kubernetes 上使用容器时，你经常把应用程序组合在一个 吊舱 pod 中。当你把一个容器或一个吊舱发布到生产环境中时，它被称为一个 部署 deployment 。如果你每天甚至每周都在使用 Kubernetes，你可能已经这样做过几百次了，但你有没有想过，当你创建一个吊舱或一个部署时到底会发生什么？我发现在高层次上了解事件链条是有帮助的。当然，你不一定要理解它。即使你不知道为什么，它仍然在工作。我不打算列出每一件发生的小事，但我的目标是涵盖所有重要的事情。这里有一张 Kubernetes 不同组件如何互动的视觉地图。你可能注意到，在上图中，我没有包括 etcd。API 服务器是唯一能够直接与 etcd 对话的组件，而且只有它能够对 etcd 进行修改。因此，你可以认为 etcd 在这张图中存在于（隐藏的）API 服务器后面。另外，我在这里只讲到了两个主要的控制器（ 部署控制器 Deployment controller 和 复制集控制器 ReplicaSet controller ）。其他的控制器的工作方式类似。下面的步骤描述了当你执行 kubectl create 命令时会发生什么。步骤 1当你使用 kubectl create 命令时，一个 HTTP POST 请求被发送到 API 服务器，其中包含部署清单。API 服务器将其存储在 etcd 数据存储中，并返回一个响应给 kubectl。步骤 2 和 3API 服务器有一个观察机制，所有观察它的客户都会得到通知。客户端通过打开与 API 服务器的 HTTP 连接来观察变化，API 服务器会流式地发出通知。其中一个客户端是部署控制器。部署控制器检测到一个 部署 Deployment 对象，它用部署的当前规格创建一个 复制集 ReplicaSet 。该资源被送回 API 服务器，并存储在 etcd 数据存储中。步骤 4 和 5与上一步类似，所有观察者都会收到关于 API 服务器中的变化的通知。这一次，复制集控制器会接收这一变化。该控制器了解所需的副本数量和对象规格中定义的吊舱选择器，创建吊舱资源，并将这些信息送回 API 服务器，存储在 etcd 数据存储中。步骤 6 和 7Kubernetes 现在拥有运行吊舱所需的所有信息，但吊舱应该在哪个节点上运行？ 调度器 Scheduler 观察那些还没有分配到节点的吊舱，并开始对所有节点进行过滤和排序，以选择最佳节点来运行吊舱。一旦节点被选中，该信息将被添加到吊舱规格中。而且它被送回 API 服务器并存储在 etcd 数据存储中。步骤 8、9 和 10到目前为止的所有步骤都发生在 控制平面 control plane 本身。 工作节点 worker node 还没有做任何工作。不过，吊舱的创建并不是由控制平面处理的。相反，在所有节点上运行的 kubelet 服务观察 API 服务器中的吊舱规格，以确定它是否需要创建任何吊舱。在调度器选择的节点上运行的 kubelet 服务获得吊舱规格，并指示工作节点上的容器运行时创建容器。这时就会下载一个容器镜像（如果它还不存在的话），容器就会实际开始运行。理解 Kubernetes 的部署对这个一般流程的理解可以帮助你理解 Kubernetes 中的许多事件。考虑一下 Kubernetes 中的 守护进程集 DaemonSet 或 状态集 StatefulSet 。除了使用不同的控制器外，吊舱的创建过程是一样的。课后作业：如果部署被修改为有三个应用程序的副本，导致创建吊舱的事件链条会是什么样子？你可以参考图表或列出的步骤，但你肯定有你需要弄清楚的知识。知识就是力量，你现在有了了解 Kubernetes 的一个重要组成部分。via: https://opensource.com/article/22/3/visual-map-kubernetes-deployment作者：Nived Velayudhan 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出