化繁为简——深入探究 Kubernetes 组件

简介

几天前，我在我以前上的大学里做了一个关于 Kubernetes 及其组件的演讲。我妈妈说她很喜欢这个演讲，所以我把它写成了一篇博客文章。

许多软件工程师往往对任何与 Kubernetes 相关的东西避而不谈，即使他们可能每天都会用到它。乍一看，它似乎很复杂，就像一个全新的世界，需要深入探索。没错，确实如此，但在这篇博文中，我将介绍 Kubernetes 集群的所有主要组件，并通过一个示例解释它们的作用。

读完这篇博文后，您可能还不会成为 Kubernetes 专家，但您可能会对要寻找什么以及如何构建 Kubernetes 最初看起来混乱的结构有一个很好的了解。

Kubernetes 架构图片取自Kubernetes 网站

向我们表达您的支持🙏🏻

动图

在开始之前，如果您能为我们的仓库点赞，帮助我们将工具推向其他开发者，我们将不胜感激。我们的 GitHub 仓库地址是：  https://github.com/cyclops-ui/cyclops ⭐

成分

首先，我们可以将 Kubernetes 集群分为两部分：控制平面和工作节点。控制平面负责整个操作并控制集群的状态。我们稍后会解释这意味着什么。另一方面，我们的工作节点本质上只是一些计算机，它们会执行控制平面的指令。它们是集群的计算能力。我们在集群中运行的任何应用程序都将在这些节点上运行。

让我们进一步分解它。

控制平面

正如我们所说，控制平面确保我们的集群按预期运行。它通过与集群用户通信、调度工作负载、管理集群状态等来实现这一点。

控制平面由四个关键组件组成。它们本身很简单，但组合在一起却构成了一个复杂的系统。这些组件是：

• API
• ETCD
• 调度器
• 控制器管理器

控制平面组件可以在集群中的任何机器上运行，但通常运行在一组单独的机器上，这些机器通常称为主节点。这些机器不用于运行任何其他容器或应用程序，而是为 Kubernetes 控制平面保留。

API

Kubernetes API 充当集群的前端接口，允许用户与集群交互、定义所需状态以及执行创建、更新和删除资源等操作。

这是我们与集群的唯一连接点。此外，其他组件之间没有直接通信，所有通信都通过API 进行。

ETCD

ETCD 是 API 的数据库；就这么简单。当你告诉 Kubernetes 创建部署时，它会与所有其他已创建的资源一起存储在 ETCD 中。

ETCD 的一个特点是其键值存储以文件系统的形式组织。ETCD 的另一个重要功能是用户可以订阅事件并接收变更通知。例如，当新的 Pod 被创建时通知我。

调度器

顾名思义，调度程序决定 Pod 将在哪个节点上运行。它通过一组规则来实现这一点，你可以在Kubernetes 文档中阅读。这就是我之前说你不会成为专家，但你会知道该用 Google 做什么的意思 :)

调度程序订阅ETCD 中保存的所有新创建的 pod，但它只能与 API 通信以获取此更新。

当调度器发现一个 Pod 已创建时，它会计算在哪个工作节点上运行该 Pod。一旦确定下来，调度器就不会在任何机器上运行任何任务；它只是告诉 API 在特定节点上运行该 Pod。

控制器管理器

控制平面的最后一个组件是控制器管理器。我们可以把它看作集群的恒温器。它的工作是将集群的当前状态转换为所需状态。

这意味着它将在后台创建所有需要的资源来满足我们的需求并使我们的应用程序启动并运行。

它运行多个控制器进程，订阅 ETCD 上的变更，并编译成同一个二进制文件以便于部署。控制器管理器的角色以及这些控制器的功能将在后续博文中更详细地定义。

工作节点

现在我们已经了解了如何管理整个集群，让我们深入了解容器在哪里运行以及如何实现这一点。

Kubernetes 集群中的每个节点上都运行着 3 个组件。当然，集群中可以有多个节点，但每个节点都需要这三个组件来托管你的应用程序。

其中包括：

• 容器运行时
• 库贝莱特
• kube 代理

容器运行时

允许 Kubernetes 运行容器并管理节点上容器生命周期的组件是容器运行时。

支持多个容器运行时，如conatinerd、cri-o或其他符合 CRI 的运行时。

库贝莱特

另一个订阅 Pod 事件的组件是 Kubelet。每次 Pod 在节点上被调度时，运行在该节点上的 Kubelet 都会监听到该事件并启动所有已定义的容器。此外，Kubelet 还会执行健康检查，以确保一切按预期运行。

Kube 代理

Kubernetes 中的 KubeProxy 负责管理集群中 Pod 之间的网络连接，处理负载均衡和网络路由等任务。它通过维护网络规则并将服务抽象转化为可操作的网络策略，确保 Pod 之间的无缝通信。

从部署到运行容器

现在我们已经列出了 Kubernetes 集群中的所有组件及其作用，让我们来讲述一下 Kubernetes Deployment 如何成为集群中各个机器上运行的一组容器。

Pod、副本集和部署

简单回顾一下这三者之间的关系：Pods、Replicasets 和 Deployments。

在 Kubernetes 集群中，我们可以部署的最小单元是pod。我们将用它来定义容器。

最有可能的是，我们需要同一应用程序的几个实例，并且我们可以定义如何使用Replicaset来复制 Pod 。通过启动和终止 Pod，它可以确保我们拥有所需数量的 Pod。

太棒了，现在我们的应用程序已经复制完毕，但我们想推出新版本。我们必须拆除现有的 Pod/Replicaset 并创建新的。Deployment 可以自动执行此过程，让我们能够安全地推出新功能。

《致命魔术》

动图

现在我们已经了解了所有术语，并了解了所有 Kubernetes 组件及其作用，让我们看看将部署“应用”到 Kubernetes 集群时会发生什么。

假设我们已经创建了一个定义应用程序的文件（您可以在此处deployment.yaml看到如何执行此操作）并运行。现在将把我们的部署定义提交给我们集群的唯一接触点- Kubernetes API。kubectl apply -f deployment.yamlkubectl

我们的简单 API 会将部署存储在 ETCD 数据库中。每次将 Deployment 对象保存到 ETCD 中时，它都会通知 API 部署发生了变更，并通知所有订阅此事件的用户。

控制平面中有一个组件需要知道新的 Deployment 何时生成，那就是Controller Manager。当它收到新的 Deployment 消息时，它会根据 Deployment 的配置创建一个新的 Replicaset。为了创建这个 Replicaset，它会调用 API 并发送 create 请求。

创建 Replicaset 与创建 Deployment 非常相似。API 将接收一个 Replicaset 并创建它，然后将其存储到 ETCD 中。这将使 ETCD 告知 API 有人创建了 Replicaset，并将该信息传递给所有订阅的组件（也就是Controller Manager）。

当控制器管理器获悉新的 Replicaset 时，它将通过调用 API 创建用 Replicaset 定义的所有 Pod，然后将所有这些 Pod 存储到 ETCD 中。

正如我们所说，发生了很多事情，所以我们决定创建一个 GIF，以帮助您了解整个过程。

这里我们引入了 Scheduler，它订阅了 Pod 创建事件。每次它收到新的 Pod 消息时，都会决定在哪个节点上运行它。Scheduler 并不运行 Pod，而只是告诉 API它为 Pod 选择了哪个节点。然后，API 会保存该信息。

另一个监听 Pod 事件的组件是 Kubelet，它是 Kubernetes 集群中每个工作节点上运行的组件。每当 API 通知 Kubelet 调度程序决定在其节点上运行 Pod 时，Kubelet就会启动该 Pod 定义的所有容器。

终于，我们把配置变成了一个在机器上运行的应用程序！这是一个漫长的过程，涉及很多细节，但这或许是我最喜欢的部分了。

每个组件仅承担部署应用程序的一小部分责任，但它们共同解决了一个相当复杂的问题。

最后的想法

希望本文能帮助您了解 Kubernetes 组件，并揭开这个最流行的编排器的神秘面纱。我们鼓励您自行探索，因为我们乐于学习。

我们推荐一本学习 Kubernetes 的书，是 Marko Lukša 的《Kubernetes 实战》。这本书非常受欢迎，对 Kubernetes 的底层原理和使用方法进行了精彩的概述。