mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Xingyu Wang
parent
3dd00a7287
commit
dec4e58648
@ -0,0 +1,72 @@
|
||||
[#]: subject: "A visual map of a Kubernetes deployment"
|
||||
[#]: via: "https://opensource.com/article/22/3/visual-map-kubernetes-deployment"
|
||||
[#]: author: "Nived Velayudhan https://opensource.com/users/nivedv"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "wxy"
|
||||
[#]: reviewer: "wxy"
|
||||
[#]: publisher: "wxy"
|
||||
[#]: url: "https://linux.cn/article-14317-1.html"
|
||||
|
||||
Kubernetes 部署的可视化地图
|
||||
======
|
||||
|
||||
> 通过查看创建一个吊舱或一个部署时的 10 个步骤，可以更好地了解 Kubernetes。
|
||||
|
||||
|
||||
|
||||
当你在 Kubernetes 上使用容器时，你经常把应用程序组合在一个<ruby>吊舱<rt>pod</rt></ruby>中。当你把一个容器或一个吊舱发布到生产环境中时，它被称为一个<ruby>部署<rt>deployment</rt></ruby>。如果你每天甚至每周都在使用 Kubernetes，你可能已经这样做过几百次了，但你有没有想过，当你创建一个吊舱或一个部署时到底会发生什么？
|
||||
|
||||
我发现在高层次上了解事件链条是有帮助的。当然，你不一定要理解它。即使你不知道为什么，它仍然在工作。我不打算列出每一件发生的小事，但我的目标是涵盖所有重要的事情。
|
||||
|
||||
这里有一张 Kubernetes 不同组件如何互动的视觉地图。
|
||||
|
||||
![吊舱链条][2]
|
||||
|
||||
你可能注意到，在上图中，我没有包括 etcd。API 服务器是唯一能够直接与 etcd 对话的组件，而且只有它能够对 etcd 进行修改。因此，你可以认为 etcd 在这张图中存在于（隐藏的）API 服务器后面。
|
||||
|
||||
另外，我在这里只讲到了两个主要的控制器（<ruby>部署控制器<rt>Deployment controller</rt></ruby>和<ruby>复制集控制器<rt>ReplicaSet controller</rt></ruby>）。其他的控制器的工作方式类似。
|
||||
|
||||
下面的步骤描述了当你执行 `kubectl create` 命令时会发生什么。
|
||||
|
||||
### 步骤 1 ###
|
||||
|
||||
当你使用 `kubectl create` 命令时，一个 HTTP POST 请求被发送到 API 服务器，其中包含部署清单。API 服务器将其存储在 etcd 数据存储中，并返回一个响应给 `kubectl`。
|
||||
|
||||
### 步骤 2 和 3 ###
|
||||
|
||||
API 服务器有一个观察机制，所有观察它的客户都会得到通知。客户端通过打开与 API 服务器的 HTTP 连接来观察变化，API 服务器会流式地发出通知。其中一个客户端是部署控制器。部署控制器检测到一个<ruby>部署<rt>Deployment</rt></ruby>对象，它用部署的当前规格创建一个<ruby>复制集<rt>ReplicaSet</rt></ruby>。该资源被送回 API 服务器，并存储在 etcd 数据存储中。
|
||||
|
||||
### 步骤 4 和 5 ###
|
||||
|
||||
与上一步类似，所有观察者都会收到关于 API 服务器中的变化的通知。这一次，复制集控制器会接收这一变化。该控制器了解所需的副本数量和对象规格中定义的吊舱选择器，创建吊舱资源，并将这些信息送回 API 服务器，存储在 etcd 数据存储中。
|
||||
|
||||
### 步骤 6 和 7 ###
|
||||
|
||||
Kubernetes 现在拥有运行吊舱所需的所有信息，但吊舱应该在哪个节点上运行？<ruby>调度器<rt>Scheduler</rt></ruby>观察那些还没有分配到节点的吊舱，并开始对所有节点进行过滤和排序，以选择最佳节点来运行吊舱。一旦节点被选中，该信息将被添加到吊舱规格中。而且它被送回 API 服务器并存储在 etcd 数据存储中。
|
||||
|
||||
### 步骤 8、9 和 10 ###
|
||||
|
||||
到目前为止的所有步骤都发生在<ruby>控制平面<rt>control plane</rt></ruby>本身。<ruby>工作节点<rt>worker node</rt></ruby>还没有做任何工作。不过，吊舱的创建并不是由控制平面处理的。相反，在所有节点上运行的 `kubelet` 服务观察 API 服务器中的吊舱规格，以确定它是否需要创建任何吊舱。在调度器选择的节点上运行的 kubelet 服务获得吊舱规格，并指示工作节点上的容器运行时创建容器。这时就会下载一个容器镜像（如果它还不存在的话），容器就会实际开始运行。
|
||||
|
||||
### 理解 Kubernetes 的部署
|
||||
|
||||
对这个一般流程的理解可以帮助你理解 Kubernetes 中的许多事件。考虑一下 Kubernetes 中的<ruby>守护进程集<rt>DaemonSet</rt></ruby>或<ruby>状态集<rt>StatefulSet</rt></ruby>。除了使用不同的控制器外，吊舱的创建过程是一样的。
|
||||
|
||||
课后作业：如果部署被修改为有三个应用程序的副本，导致创建吊舱的事件链条会是什么样子？你可以参考图表或列出的步骤，但你肯定有你需要弄清楚的知识。知识就是力量，你现在有了了解 Kubernetes 的一个重要组成部分。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/3/visual-map-kubernetes-deployment
|
||||
|
||||
作者：[Nived Velayudhan][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/nivedv
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software)
|
||||
[2]: https://opensource.com/sites/default/files/uploads/pod-chain_0.png (Pod chain)
|
||||
[3]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
@ -1,63 +0,0 @@
|
||||
[#]: subject: "A visual map of a Kubernetes deployment"
|
||||
[#]: via: "https://opensource.com/article/22/3/visual-map-kubernetes-deployment"
|
||||
[#]: author: "Nived Velayudhan https://opensource.com/users/nivedv"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
A visual map of a Kubernetes deployment
|
||||
======
|
||||
Gain a better understanding of Kubernetes by looking at the 10 steps
|
||||
that take place when you create a pod or a deployment.
|
||||
![Parts, modules, containers for software][1]
|
||||
|
||||
When you work with containers on Kubernetes, you often group applications together in a pod. When you launch a container or a pod into production, it's called a _deployment_. If you're using Kubernetes daily or even just weekly, you've probably done it hundreds of times, but have you thought about what exactly happens when you create a pod or a deployment?
|
||||
|
||||
I find it helpful to have an understanding of the chain of events on a high level. You don't have to understand it, of course. It still works even when you don't know why. I don't intend to list each and every little thing that happens, but I aim to cover all of the important ones.
|
||||
|
||||
Here's a visual map of how the different components of Kubernetes interact:
|
||||
|
||||
![Pod chain][2]
|
||||
|
||||
(Nived Velayudhan and Seth Kenlon, [CC BY-SA 4.0][3])
|
||||
|
||||
You may notice in the diagram above that I haven't included etcd. The API server is the only component that can directly talk to etcd, and only it can make changes to it. So you can assume that etcd exists (hidden) behind the API server in this diagram.
|
||||
|
||||
Also, I'm talking about only two main controllers (Deployment and ReplicaSet) here. Others would also work similarly.
|
||||
|
||||
The steps below describe what happens when you execute the `kubectl create` command:
|
||||
|
||||
**Step 1:** When you use the `kubectl create` command, an HTTP POST request gets sent to the API server, which contains the deployment manifest. The API server stores this in the etcd data store and returns a response to the kubectl.
|
||||
|
||||
**Steps 2 and 3:** The API server has a watch mechanism and all the clients watching this get notified. A client watches for changes by opening an HTTP connection to the API server, which streams notifications. One of those clients is the Deployment controller. The Deployment controller detects a Deployment object, and it creates a ReplicaSet with the current specification of the Deployment. This resource gets sent back to the API server, which stores it in the etcd datastore.
|
||||
|
||||
**Steps 4 and 5:** Similar to the previous step, all watchers get notified about the change made in the API server—this time the ReplicaSet Controller picks up the change. The controller understands the desired replica counts and the pod selectors defined in the object specification, creates the pod resources, and sends this information back to the API server, storing it in the etcd datastore.
|
||||
|
||||
**Steps 6 and 7:** Kubernetes now has all the information it needs to run the pod, but which node should the pods run on? The scheduler watches for pods that don't have a node assigned to them yet, and starts its process of filtering and ranking all nodes to choose the best node to run the pod on. Once the node is selected, that information gets added to the pod specification. And it gets sent back to the API server and stored in the etcd datastore.
|
||||
|
||||
**Steps 8, 9, and 10:** All the steps until now occur in the control plane itself. The worker node has yet to do any work. The pod's creation isn't handled by the control plane, though. Instead, the kubelet service running on all the nodes watches for the pod specification in the API server to determine whether it needs to create any pods. The kubelet service running on the node selected by the scheduler gets the pod specification and instructs the container runtime in the worker node to create the container. This is when a container image gets downloaded (if it's not already present) and the container actually starts running.
|
||||
|
||||
### Understanding Kubernetes deployments
|
||||
|
||||
Gaining an understanding of this general flow can help you understand many events in Kubernetes. Consider a DemonSet or StatefulSet in Kubernetes. Apart from using different controllers, the pod creation process remains the same.
|
||||
|
||||
Ask yourself this: If the deployment gets modified to have three replicas of an app, what would the chain of events that lead to the creation of the pods look like? You can refer to the diagram or the listed steps, but you definitely have the knowledge you need to figure it out. Knowledge is power, and you now have an important component for understanding Kubernetes.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/22/3/visual-map-kubernetes-deployment
|
||||
|
||||
作者：[Nived Velayudhan][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/nivedv
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/containers_modules_networking_hardware_parts.png?itok=rPpVj92- (Parts, modules, containers for software)
|
||||
[2]: https://opensource.com/sites/default/files/uploads/pod-chain_0.png (Pod chain)
|
||||
[3]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
Loading…
Reference in New Issue
Block a user