这篇文章是我对 Kubernetes 架构的理解。
而不是解释架构 的不同组件包括每个组件的功能。
我们将采用 Kubernetes 功能并打破其实现，以了解它如何与 Kubernetes 系统组件交互。
所以，是的，一些 K8s 基础知识的工作知识，例如创建部署和服务，是一个加分项。
在开始之前，我想让你知道这篇文章是尽我所知写的，我会随着我对它的深入了解而更新它。
我的 K8s 之旅始于 2020 年，当时我在 space-cloud（一种帮助您开发、部署和保护应用程序的开源工具）担任开发人员。当时，决定支持 Kubernetes 进行部署并放弃对 docker 的支持。
作为 space-cloud 的创始工程师，我被告知要学习 Kubernetes。所以我开始了解 Kubernetes 的内容、原因和方式。
我还记得我第一次动手 Kubernetes 的经验是使用 minikube 创建一个 K8s 集群，其中我创建了一个 nginx 部署并使用 NodePort 服务将其公开。在本练习结束时，我能够查看ngnix在[localhost:8080](
但是，Kubernetes 对我来说仍然是一个黑匣子。我不知道什么是部署，什么是节点端口服务，也不知道为什么 Kubernetes 需要 8GB 的内存来运行一个 nginx 容器，我敢打赌，对于很多人来说，它是一个黑匣子。
因此，我们将揭开这个黑匣子的神秘面纱，它具有每个 Kubernetes 新手都已经看到或至少听说过的功能。
我说的是部署应用程序。
这是通过图像表示的部署过程的快速概述（要阅读图像，请遵循以红色突出显示的数字指示器）。这就是我们将在本文中深入学习的内容。请记住这张图片；我们将在本文中大量提及它。
当您kubectl create deployment --image nginx在终端上运行命令时。在后台，kubectl 向服务器发出 HTTP 请求。而响应这个请求的服务器被称为——我们的api-server第一个 Kubernetes 系统组件。
暴露 Kubernetes REST API 以供消费的程序，该组件还负责整个系统的身份验证和授权
以下是针对每个请求（无论是外部请求还是内部请求）采取的操作：
除了处理 API 请求，它还处理 Kubernetes 集群的操作活动，例如
在我们的例子中，我们请求创建 nginx 部署资源。身份验证成功后，API 服务器将部署资源对象存储在数据存储中，并将适当的 HTTP 状态代码发送回客户端。
假设您仔细观察到 API 服务器与持久数据存储进行通信。它是我们架构中的第二个组件ETCD.
分布式、一致且高可用的键值存储用于存储集群数据。
这里没有什么花哨的；Kubernetes 使用ETCD 作为存储资源对象的数据库。
除了 ETCD 提供的基本 CRUD 操作。ETCD 的一个独特主张是提供有关其键发生变化的事件。此功能由 Kubernetes 通过 watch API 公开。在接下来的部分中，您将看到不同的 Kubernetes 组件如何利用 watch API。
我们还没有对位于 ETCD 存储中的 nginx 部署对象采取任何操作。是时候使用我们的下一个组件controller manager.
对提交给 API 服务器的 Kubernetes 类型执行操作的程序。
每个 Kubernetes 种类/资源（部署、服务等）都需要被理解，并且某些实体必须采取适当的行动。该实体称为controller.
从技术上讲，controllerjust 监视特定 Kubernetes 资源（部署、服务等）中的更改，使用由 Kubernetes 公开的监视 APIapi-server在称为控制循环的永无止境的 for 循环中。每当控制器收到有关资源更改的通知时，它都会采取适当的措施来确保资源的当前状态与期望的状态相匹配。
单个如何controller-manager能够处理多个 Kubernetes 资源？
controller-manager二进制文件包含许多这样的资源controllers来对 K8s 资源采取行动。例如：
所以在我们的例子中，我们创建了一个新的 nginx 部署对象。控制器管理器中的部署控制器被通知新的部署对象；控制器通过比较所需状态（我们通过 CLI 命令指定它）和当前状态（当前正在运行什么？）来采取行动。由于没有现有的部署，它决定创建一个新的部署。
从技术上讲，Kubernetes 中的部署由资源组成：
所以部署控制器告诉api-server创建副本集和 pod 资源。伟大的！
正如我所说，该 pod 资源在 Kubernetes 中运行容器。但是谁来决定容器应该在哪个节点上运行呢？由于 Kubernetes 是一个多节点系统，因此必须有人决定容器将在哪里运行。
这就是scheduler组件出现的地方。
监视没有分配工作节点的新创建的 pod 的程序会选择一个工作节点供它们运行。
但是工作节点的选择会涉及什么？
选择过程涉及许多阶段，但重要的是：
1.过滤
该状态的目标是过滤掉由于某种原因无法托管 pod 的工作节点；在这个阶段结束时，我们有了可以调度 pod 的节点。
不托管的原因：
在此阶段结束时，根据可调度节点列表的长度，可能会出现以下情况：
2. 计分
此阶段旨在根据服务器规则为可调度节点分配分数。在这个阶段结束时，选择得分最高的节点进行 Pod 的调度。
用于评估的规则示例：
这就是 ascheduler在高水平上所做的事情。
到目前为止，我们只决定了关于我们的nginx部署做什么和如何做。但我实际上并没有采取任何行动来运行容器。
因此可以观察到，我们所看到的动作的任何组成部分都是集群的大脑，它具有整个集群的决策能力。
在 Kubernetes 架构中，决策组件称为主节点和执行决策的组件称为工作节点。
如您所见，我们的nginx部署在其旅程中与主节点进行了交互。是时候前往最终目的地了。
啊，终于，我们在运行容器方面取得了一些进展。那么谁在工作节点中运行我们的容器呢？答案是 Kubelet。
监视分配给工作节点（本身）的 pod 并确保 pod 规范中指定的容器在节点上运行的程序
在内部，kubelet 使用许多底层技术来运行容器，例如：
所有这些低级技术都需要单独的文章；如果您想要单独的文章，请在下方评论。但这里有一张概览图。
最后，在kubelet组件的帮助下，我们的nginx容器运行成功了。
我们所学知识的概括图。
我们还没有讨论 2 个主要的 Kubernetes 组件：
我将单独写一篇文章，解释 Kubernetes 中 HTTP 请求的历程。
| 留言与评论（共有 0 条评论） “” |
