DZone>云计算专区>Kubernetes中的部署创建之旅
Kubernetes中的部署创建之旅
我们将采取一个Kubernetes功能，并打破它的实现，以了解它如何与Kubernetes系统组件互动。
-
Sep. 07, 22 - Cloud Zone- 观点
喜欢 (1)
评论
保存
鸣叫
2.32K浏览次数
加入DZone社区，获得完整的会员体验。
这篇文章是我对Kubernetes架构的理解。
而不是解释架构 中的不同组件，包括每个组件的功能是什么。
我们将采取一个Kubernetes功能，并打破其实现，以了解它与Kubernetes系统组件的互动。
因此，是的，对K8s基础知识有一些工作上的了解，如创建部署和服务，是一个加分项。
在开始之前，我想让你知道，这篇文章是根据我的知识所写的，当我对它有更多的了解时，我将更新它。
与Kubernetes的最初互动
我的K8s之旅始于2020年，当时我在space-cloud（一个帮助你开发、部署和保护应用程序的开源工具）担任开发人员。当时，我们决定支持Kubernetes的部署，并放弃对docker的支持。
作为space-cloud的创始工程师，我被告知要学习Kubernetes。于是我开始学习Kubernetes的内容、原因和方法。
我还记得我第一次亲身体验Kubernetes是使用minikube创建一个K8s集群，其中我创建了一个nginx部署，并使用NodePort服务将其暴露出来。在这个练习结束时，我能够查看运行在[localhost:8080](<http://localhost:8080>) 的ngnix 默认网页。
但是，Kubernetes对我来说仍然是一个黑盒子。我不知道什么是部署，什么是节点端口服务，也不知道为什么Kubernetes要用8GB的内存来运行nginx容器，我打赌对很多人来说，这也是一个黑箱。
因此，我们将用每个刚接触Kubernetes的人都在行动中见过或至少听说过的功能来揭开这个黑盒子的神秘面纱。
我说的是部署一个应用程序。
部署资源的旅程
下面是一个通过图像表示的部署历程的快速概述（阅读图像时，请按照红色突出的数字指标进行）。这就是我们将在本文中深入学习的内容。请记住这个图像；我们将在本文中经常提到它。
当你在终端上运行kubectl create deployment --image nginx 命令时。在引擎盖下，kubectl向服务器发射了一个HTTP请求。而响应这个请求的服务器被称为api-server- 我们的第一个Kubernetes系统组件。
API服务器
一个暴露Kubernetes REST API供消费的程序，这个组件也负责整个系统的认证和授权
以下是对每一个请求所采取的行动，不管是外部的还是内部的。
除了处理API请求，它还处理Kubernetes集群的操作活动，例如
- 工作节点的注册。
在我们的案例中，我们已经请求创建nginx部署资源。认证成功后，API服务器将把部署资源对象存储在数据存储中，并向客户端发回一个适当的HTTP状态代码。
假设你仔细观察，API-服务器与一个持久的数据存储进行对话。它是我们的架构中的第二个组件ETCD.
ETCD存储
一个分布式的、一致的、高可用的键值存储被用来存储集群数据。
这里没有什么花哨的东西；Kubernetes将ETCD 作为一个数据库来存储资源对象。
除了ETCD提供的基本CRUD操作之外。ETCD的一个独特主张是为其键值发生的变化提供事件。这个功能是由Kubernetes通过watch API公开的。在接下来的章节中，你将看到不同的Kubernetes组件是如何利用watch API的。
我们还没有对停留在ETCD仓库中的nginx部署对象采取任何行动。现在是时候用我们的下一个组件，即controller manager.
控制器管理器
一个对提交给API服务器的Kubernetes种类进行操作的程序。
每个Kubernetes种类/资源（部署、服务等）都需要被理解，并且必须由某个实体采取适当的行动。这个实体被称为controller 。
从技术上讲，controller 只是在一个被称为控制循环的永无止境的for循环中，使用api-server 所暴露的watch API来观察特定Kubernetes资源（部署、服务等）的变化。每当控制器收到关于资源变化的通知时，它就会采取适当的行动，以确保资源的当前状态与预期状态相匹配。
一个controller-manager ，如何能够处理多个Kubernetes资源？
controller-manager 二进制文件包括许多这样的资源controllers ，对K8s资源采取行动。比如说
- 节点控制器
- 部署控制器
- 服务控制器
- 命名空间控制器等。
所以在我们的案例中，我们创建了一个新的nginx部署对象。控制器管理器中的部署控制器被告知新的部署对象；控制器通过比较所需的状态（我们通过CLI命令指定）和当前的状态（当前正在运行什么？）由于没有现有的部署，它决定创建一个新的部署。
从技术上讲，Kubernetes中的部署是由资源组成的。
- **Pods。**这是一个逻辑分组，用于运行多个容器。
- **复制集。**确保规格中指定的副本（pod的副本）在任何特定时间都在运行。
因此，部署控制器告诉api-server ，以创建一个副本集和荚资源。很好！就像我说的，那个pod资源正在运行。
正如我所说，该pod资源在Kubernetes内运行容器。但谁来决定容器应该在哪个节点上运行？由于Kubernetes是一个多节点系统，必须有人来决定容器将在哪里运行。
这就是scheduler 组件出现的地方。
调度器
一个观察新创建的没有指定工作节点的pod的程序，为它们选择一个工作节点来运行。
但是，选择工作节点的过程是怎样的呢？
在选择过程中涉及许多阶段，但重要的阶段是。
1.筛选
这个状态的目标是过滤掉由于某种原因不能托管pod的工作节点；在这个阶段结束时，我们有可以安排pod的节点。
不能托管的原因。
-
污点和容忍度
-
CPU和内存请求
-
节点选择器
-
在这个阶段结束时，根据可调度节点列表的长度，会出现以下情况。
- 长度等于0：那么，pod将保持待定，直到这个条件被补救。
- 长度等于1：调度可以发生，不需要任何行动。
- 长度大于1：它将进入调度的下一个阶段。
2.计分
这个阶段的目的是根据服务器规则给可调度节点分配分数。在这个阶段结束时，得分最高的节点被选为Pod的调度。
用于评估的规则实例。
- 节点亲和力和反亲和力
- 节点是否已经有一个容器镜像？
- 较低的工作负载利用率会给你一个较高的结果。
- 这就是
scheduler在高层次上的作用。
直到现在，我们只决定了关于我们的nginx 部署，该做什么和怎么做。但我还没有采取任何实际行动来运行容器。
因此，可以观察到，无论什么组件，我们都将其视为集群的大脑，它具有整个集群的决策能力。
在Kubernetes架构中，被称为Master Node的决策组件和被称为Worker Node的执行决策的组件之间是分开的**。**
正如你所看到的，我们的nginx 部署在其旅程中已经与主节点进行了互动。现在是去最终目的地的时候了。
啊，终于，我们在运行容器方面有了一些进展。那么，谁在工作节点上运行我们的容器呢？答案是Kubelet。
Kubelet
一个观察分配给工作节点（本身）的pod的程序，确保pod规格中指定的容器在节点上运行
在内部，Kubelet使用了许多运行容器的低级技术，例如。
- 容器运行时接口
- 容器运行时（容器、docker、podman等）。
- 运行
所有这些底层技术都需要单独写一篇文章；如果你想单独写一篇文章，请在下面评论。但这里有一个快速的图片供大家参考。
最后，在kubelet 组件的帮助下，我们的nginx 容器成功运行了。
结束语
我们所学到的内容的概括图。
我们还没有讨论Kubernetes的两个主要组件。
- 云控制管理器
- Kube Proxy
我将单独写一篇文章，解释Kubernetes中HTTP请求的过程。
Kubernetes
DZone贡献者所表达的观点是他们自己的。
DZone上的热门文章
评论
