文章目录
- Kubernetes 组件
- 1. 控制平面组件（Control Plane Components）
- 2. Node 组件
- 3. 相互工作关系
- 4. 控制主控节点
Kubernetes 组件
官方文档：https://kubernetes.io/zh/docs/concepts/overview/components/
在kubernetes官方文档中，我们可以看到这样一张架构图。
从图中可以看出一个完整的kubernetes集群包含了控制平面组件（Control Plane Components）和Node组件。
1. 控制平面组件（Control Plane Components）
控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件。包含：
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
- cloud-controller-manager
2. Node 组件
节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。包含：
- kubelet
- kube-proxy
这些组件的功能和作用，可以参考官方文档，我在之前的文章中也有说过。今天我们重点说一下在集群环境中，各个组件是怎样的关系，他们是如何相互工作的。
3. 相互工作关系
为了便于理解，我把这张图贴合实际做了一些附加说明，帮助大家理解。
门卫大爷（kube-proxy）是控制集群中的网络访问的，他们之间可以数据共享。秘书处（kube-apiserver）是控制集群之间交互访问的。
这里的总部基地就相当于控制节点（Master Node），各个分厂就相当于工作节点（Work Node）。我们给每一个组件赋予了相应的角色，那么在说他们之间相互工作的关系就比较好理解。
首先从图中我们需要获得以下几点信息：
- 无论是控制节点还是工作节点，都可以有kubelet
- 无论是控制节点还是工作节点，都可以有kube-proxy
- 无论是控制节点还是工作节点，都可以做具体的业务，比如造飞机在分厂可以做，总部也可以做，只是在实际中一般由分厂做。
前面的文章中我们说了各个组件的功能以及特点，他们如何协同工作呢？
我们通过一个故事来理解。
某一家大型公司有总部，也有两个分厂A和B。A厂的原本业务有造飞机，造火车和造轮船。B厂的原本业务有造飞机和造轮船。某一天A厂的厂长视察流水线，发现厂里目前不具备造火车的条件了，于是他把这个消息告诉了秘书处。秘书处接到了消息，把情况反映到了决策者那里，决策者得知消息后便说：A厂做不了，就让其他厂做吧，于是秘书处就把决策者的意思告诉了调度者，调度者日夜辛劳，算了算，可以让B厂去做，于是他告诉了秘书处，秘书处得到消息后，将这些信息全部归到了资料库中，然后告诉了厂长B，于是厂长B在B厂启动了造火车的业务。
前面的文章中我们也说了kube-proxy提供网络代理，负载均衡，在这里怎么理解呢？
某一天，应用1（造飞机）流水线上的工人想看看造轮船的流水线，那么他就找到了门卫大爷，想从他那里了解到从哪里可以看造轮船的流水线，于是门卫大爷告诉他，咱们A厂里就有，而且B厂里也有，于是流水线上的工人就按照门卫大爷说的选择了一个厂的流水线进行了参观。当然厂里的人可以问门卫大爷，如果是厂外的人，也需要问门卫大爷。
说的这些都是在一个集群内部的情况，如果需要集群之外的资源等，就可以用外联部（cloud-controller-manager）来获取。
4. 控制主控节点
通过上面的故事，我们了解了各个组件之间相互配合工作的过程。在实际工作中，我们还会发现总部（Master Node）其实更像是一个傀儡。
程序员可以通过命令对总部（Master）进行控制，比如kubectl create deploy myapp --image=tomcat等。完成我们想要的效果以满足业务需求。当然组件之间工作的关系流程等等还是我们上面故事讲到的情形。
