kubernetes 编排
There would probably be thousands of articles about K8s to date. You may ask — What would this story be about then? :) This story would be all about my appreciation for the architecture and system design of Kubernetes.
迄今为止，可能会有成千上万篇有关K8的文章。 您可能会问-那么这个故事会是什么？ :)这个故事就是我对Kubernetes的体系结构和系统设计的赞赏。
All the people that have started the k8s journey would have figured out the components of the master plane and the worker plane. Less do we know about
所有开始k8s旅程的人都应该知道主飞机和工人飞机的组成部分。 我们了解的很少
- What the system design looks like? 系统设计是什么样的？
- How do the components interact with each other? 组件之间如何相互作用？
- What kind of message exchange happens? 发生什么样的消息交换？
- The sequence of events that would happen to complete an action (against the cluster)? 完成动作(针对集群)将发生的事件顺序？
Answers to these questions has helped me understand k8s better. K8s master plane components are setup in a “Hub and Spoke” model. This would resonate well with architects and networking people. The “API server and the etcd data store” form the hub of the master plane. The controller manager (deployment controller, replica controller) and scheduler form the spokes. How does this setup work?
这些问题的答案帮助我更好地了解了k8。 K8的主平面组件以“ 轮毂和轮辐”模型设置。 这将与架构师和网络人员产生共鸣。 “ API服务器和etcd数据存储”构成了主平面的集线器。 控制器管理器(部署控制器，副本控制器)和调度程序构成分支。 此设置如何工作？
The spoke components do not directly interact with each other. Any message exchange would happen through the API server & etcd. This makes the flow of events inside k8s a well designed choreography (explained in detail in the next section). If you had to visualize the setup,
辐条组件不会直接相互影响 。 任何消息交换都将通过API服务器＆etcd进行。 这使k8s内部的事件流成为精心设计的编排 (在下一节中详细说明)。 如果您必须可视化设置，
Getting back to the part why I call this a nicely designed choreography, each component has a clearly established responsibility inside K8s.
回到为什么我称其为精心设计的舞蹈的一部分，每个组件在K8内部都有明确的职责。
- The execution of the tasks of any component would start when an event that the component has subscribed to is published 发布组件已订阅的事件时，将开始执行任何组件的任务
Components after completing their work (business logic in k8s world) would then perform a REST call to the API server. The API server is a powerful component that exposes REST APIs in a lot of well separated namespaces ( each namespace housing the APIs of a specific component or functionality)
完成工作(k8s世界中的业务逻辑)后，组件将对API服务器执行REST调用 。 API服务器是一个功能强大的组件，它在许多相互独立的命名空间中公开REST API(每个命名空间均包含特定组件或功能的API)
- The page mentioned below(not the latest version but is a “wealth of information”) provides a clear picture of all the API endpoints, their definitions and additional details of the parameters of the k8s apis. What if you had a swagger file of the APIs exposed from the api server ?? 下面提到的页面(不是最新版本，而是“信息财富”)提供了所有API端点，它们的定义以及k8s api参数的其他详细信息的清晰图片。 如果您有从api服务器公开的API的大文件怎么办？
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#-strong-api-overview-strong-
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#-strong-api-overview-strong-
4. The API server would now act on the https api call and after processing the request would create another event for the downstream components. This flow keeps going until the intended action is completed.
4. API服务器现在将对https api调用起作用，在处理请求之后，将为下游组件创建另一个事件。 该流程将继续进行，直到完成预期的操作为止。
Take a look at this diagram and you would know why I used the terms “Choreography” and “Hub and Spoke” . These are sequence of actions that take place when a “Pod Deployment” is executed.
看一下这张图，您会知道为什么我使用术语“编排”和“枢纽和辐条”。 这些是执行“ Pod Deployment ”时发生的一系列动作。
Majority of the actions in k8s work based on a timed notification mechanism called “watch”. When we think of any notification mechanism, there would of course be subscribers and publishers. You should have by now inferred that the Hub component (API server and etcd store)acts as the publisher and the spoke components, the subscribers.
k8中的大多数动作都基于一种称为“ 监视 ”的定时通知机制进行工作。 当我们想到任何通知机制时，当然会有订阅者和发布者。 您现在应该已经推断出集线器组件(API服务器和etcd存储)充当发布者，而分支组件充当订阅者。
When you execute a yaml template ( through deployment pipelines or from the command line), the following actions are executed
当您执行yaml模板(通过部署管道或从命令行)时，将执行以下操作
- The yaml is converted to json and sent to the api server yaml转换为json并发送到api服务器
the api server (after validating the payload) would now save the requested deployment settings to the etcd database ( this is the first step in creating the “desired state” of the cluster
api服务器(在验证有效负载之后)现在将请求的部署设置保存到etcd数据库中(这是创建集群“ 所需状态 ”的第一步
- the etcd database creates an event for the key-value data for the cluster resource that got added/updated/deleted. The consumer of this is the API sever etcd数据库为添加/更新/删除的集群资源的键值数据创建一个事件。 使用者是API服务器
The API server in addition to hosting the REST backend also has the “watch” mechanism built into it. Now the events would be sent to the other components by the “ClientGo” component (watch the video linked to from the next section)
API服务器除了托管REST后端外，还内置了“监视”机制。 现在，事件将通过“ ClientGo ”组件发送到其他组件(观看下一部分链接的视频)
- The controllers on receiving the events perform a sequence of operations ( displayed in the diagram shown below). Interesting part of this step is the the system design of the controller. You will appreciate the simplicity and beauty of it too! 接收事件的控制器执行一系列操作(如下图所示)。 该步骤有趣的部分是控制器的系统设计。 您还将欣赏它的简单性和美感！
The controllers after completing their defined tasks, send an update back to the API server. This is saved in the etcd as an update version. The controllers in each step help in getting the “actual state towards the desired state”
控制器在完成定义的任务后，将更新发送回API服务器。 这作为更新版本保存在etcd中。 每个步骤中的控制器都有助于使“ 实际状态朝着期望的状态 ”
You can get a picture of the details of the watch mechanism, flow of events and the system design of controllers from this video. An amazing one in my opinion
您可以从该视频中获得监视机制，事件流和控制器的系统设计的详细信息。 我认为这是一个了不起的人
The Life of a Kubernetes Watch Event — Wenjia Zhang & Haowei Cai, Google
Kubernetes观看事件的生活-张文佳＆蔡浩伟，Google
Among the plenty of things that you would learn from this design (take time to digest the information in the video), one “design decision” that is worth a mention is that — The controllers are “Level based systems” and not “Edge based systems”
您将从该设计中学到的很多知识(花一些时间来消化视频中的信息)，其中一个值得一提的“ 设计决策 ”是：控制器是“ 基于级别的系统 ”而不是“ 基于边缘的”系统 ”
Not intending to duplicate any information, I urge you to read this amazing article — resources and controller
不想重复任何信息，我敦促您阅读这篇精彩的文章- 资源和控制器
Emphasis is on the design decision though. The controller does not work on the events that it receives. Events work just as a change notification source.Reconciliation is performed using the data in the “Local Cache”. This is the reason that the local cache is kept updated with every change that happens in the current state of the system that is of interest to the listening controller.
重点在于设计决策。 控制器无法处理收到的事件。 事件就像更改通知源一样工作。对帐使用“本地缓存”中的数据执行。 这就是本地缓存会随着侦听控制器感兴趣的系统当前状态中发生的每个更改而保持更新的原因。
An excerpt from the same amazing article about the watch action( point of interest of each component in the sequence). You can correlate this with the second diagram (sequence) in this article.
摘自同一篇关于钟表动作的惊人文章的摘录(序列中每个组件的兴趣点)。 您可以将此与本文中的第二个图表(序列)相关联。
- Deployment Controller watches Deployments + ReplicaSets (+ Pods) Deployment Controller监视部署+副本集(+容器)
- ReplicaSet Controller watches ReplicaSets + Pods ReplicaSet Controller手表ReplicaSets + Pod
- Scheduler (Controller) watches Pods 调度程序(控制器)监视Pod
- Node (Controller) watches Pods (+ Secrets + ConfigMaps) 节点(控制器)监视Pods(+机密+ ConfigMap)
That was all the feel good information I wanted to share with my fellow enthusiasts. Hope you enjoyed this one too.
这就是我想与我的发烧友分享的所有很好的信息。 希望你也喜欢这个。
附加参考 (Additional Reference)
https://medium.com/@tsuyoshiushio/kubernetes-in-three-diagrams-6aba8432541c
https://medium.com/@tsuyoshiushio/kubernetes-in-three-diagrams-6aba8432541c
翻译自: https://medium.com/swlh/choreography-inside-kubernetes-aa5fcf69ac65
kubernetes 编排
693
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
