一文“六问”带你吃透kubernetes架构原理

布满荆棘的人生 2024-03-23 13:24 76阅读 0赞

### kubernetes是什么，为什么上手这么难？ ###

Kubernetes是一个基于容器技术的分布式集群管理系统。它是谷歌在大规模应用容器技术方面数十年经验的实际成果。因此，支持大规模的集群管理承载着非常多的组件，分布式本身的复杂度非常高。

### Kubernetes到底有什么？ ###

接下来我们一步步来看看Kubernetes到底有什么？

首先，既然是分布式系统，那么肯定有多个Node节点（物理主机或者虚拟机），它们共同构成了一个分布式集群，而这些节点之间会有一个Master节点，统一管理Node节点。如图所示：

![89b62bdc738fbc4247f2242dd881252c.jpeg][]

### 问题1：Master节点和Worker节点如何通信？ ###

首先，当Master节点启动时，会运行一个Kube-apiserver进程，它提供了集群管理的API接口，是集群中各个功能模块之间进行数据交互和通信的中心枢纽，同时也提供了一个完善的集群安全机制。

在Node节点上，利用Kubernetes中的kubelet组件，每个Node节点上都会运行一个kubelet进程，负责向Master汇报本节点的运行状态，如Node节点注册、终止、定期健康报告等等，并接收来自Master的命令并创建相应的Pod。

在Kubernetes中，Pod是最基本的运行单元。它与Docker容器略有不同，因为Pod中可能包含一个或多个容器（可以是Docker容器），这些容器内部共享网络资源，即可以通过localhost相互访问。

关于如何在Pod中实现网络共享，每个Pod启动，内部都会启动一个pause容器（谷歌的image）。它使用默认的网络模式，其他容器的网络设置为它，完成网络共享问题。

如图所示：

![5d99930b5fa7cd6c4797ccb2f053c62a.jpeg][]

### 问题2：Master如何将Pod调度到指定的Node上？ ###

这项工作由Kube-scheduler完成。整个调度过程通过执行一系列复杂的算法，最终为每个Pod计算出一个最优的目标Node，这是由Kube-scheduler进程自动完成的。

最常见的是循环调度（RR）。当然也有可能我们需要将Pod调度到指定的Node上。我们可以通过将节点的标签（Label）与Pod的节点选择器属性进行匹配来达到指定的效果。

如图所示：

![85759239c36f8f22657c397bd9da2196.jpeg][]

### 问题3：各个节点和Pod的信息统一在哪里维护，谁来维护？ ###

从上面的Pod调度来看，我们必须有一个存储中心来存储每个节点的每个Pod的资源使用情况、健康状态和基本信息，这样Pod调度才能正常进行。

在Kubernetes中，etcd组件被用作高可用和一致的存储库。该组件可以内置在Kubernetes中，也可以外部构建供Kubernetes使用。

集群上的所有配置信息都存储在etcd中。考虑到各个组件的相对独立性和整体的可维护性，这些存储的数据的增删改查都是统一由Kube-apiserver来调用的，并且apiserver还提供了REST支持，不仅为各个内部组件提供服务但也向集群外的用户公开服务。

外部用户可以通过REST接口或kubectl命令行工具管理集群，该工具内部与apiserver通信。

如图所示：

![5661d34efbe7a53ff239c9890b08e1cd.jpeg][]

### 问题4：外部用户如何访问集群中运行的Pod？ ###

前面我们讲了外部用户如何管理Kubernetes，但我们更关心的是内部运行的Pod如何对外访问。

用过Docker的同学应该都知道，如果使用bridge模式，在创建容器的时候会分配一个虚拟IP，外部无法访问该IP。我们需要做一层端口映射，将容器中的端口映射到宿主机的端口Map并绑定，这样外部就可以通过访问宿主机的指定端口来访问容器内部的端口。

那么，Kubernetes的外部访问也是这样实现的吗？答案是否定的，Kubernetes中的情况更加复杂。因为上面说的Docker是单机模式，一个容器对外暴露一个服务。在分布式集群中，服务往往由多个应用提供，以分担访问压力，而这些应用可能分布在多个节点上，这就涉及到跨主机通信。

这里Kubernetes引入了Service的概念，将多个相同的Pod包装成一个完整的服务，对外提供服务。至于获取这些相同的Pod，每个Pod在启动时都会设置labels为attribute。

在服务中，我们传递选择器Selector，选择与整体服务具有相同Name标签属性的Pod，将服务信息通过Apiserver存储到etcd中，由Service Controller完成。同时在每个节点上启动一个kube-proxy进程，负责从服务地址到Pod地址的代理和负载均衡。

如图所示：

![d65bf9d6d6ce57fe7372be6f178fa30a.jpeg][]

### 问题5：Pod如何动态扩容和伸缩？ ###

既然我们知道服务是由Pod组成的，那么服务的扩展也意味着Pod的扩展。通俗地说，就是在需要的时候将Pod做多个副本，在不需要的时候将Pod缩减到指定的副本数。

在Kubernetes中，使用Replication Controller进行管理，为每个Pod设置一个预期的副本数。当实际副本数量不符合预期时，动态调整数量以达到预期值。所需值可以由我们手动更新，也可以由自动缩放代理更新。如图所示：

![b5a411fd01a252351b2824114aac55b8.jpeg][]

### 问题6：各个组件如何协同工作？ ###

最后说一下Kube-controller-manager进程的作用。我们知道ectd是作为集群数据的存储中心，而apiserver是用来管理数据中心，充当其他进程与数据中心通信的桥梁。

Service Controller和Replication Controller由Kube-controller-manager管理。作为一个守护进程，每个Controller都是一个控制回路，通过apiserver监控集群的共享状态，并尝试将实际状态中不符合预期的变化。关于Controller，管理器还包括Node Controller、ResourceQuota Controller、Namespace Controller等。

如图所示：

![4ef0eb71f1861348bd1c7525373e007c.jpeg][]

### 总结 ###

本文通过问答的方式不涉及任何深入的实现细节。从整体的角度，从概念上介绍了Kubernetes涉及的基本概念。相关用途包括：

*  Node
 *  Pod
 *  Label
 *  Selector
 *  Replication Controller
 *  Service Controller
 *  ResourceQuota Controller
 *  Namespace Controller
 *  Node Controller

与运行过程相关的是：

*  kube-apiserver
 *  kube-controller-manager
 *  kube-scheduler
 *  kubelet
 *  kube-proxy
 *  pause

[89b62bdc738fbc4247f2242dd881252c.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/96cea684753842eeb3816e8d31e91f64.png
[5d99930b5fa7cd6c4797ccb2f053c62a.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/8de2272f0e314346834ae0f4fe94f106.png
[85759239c36f8f22657c397bd9da2196.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/24d7b5ce8c544aa6bef2845885c91e02.png
[5661d34efbe7a53ff239c9890b08e1cd.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/524e058058ff4f01883dde5bb83a13ce.png
[d65bf9d6d6ce57fe7372be6f178fa30a.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/905aceb664c640de9acd23bf3a7f305e.png
[b5a411fd01a252351b2824114aac55b8.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/5d5ccfd310414377980e8ee8d9bf936e.png
[4ef0eb71f1861348bd1c7525373e007c.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/23/745d63844f5f4b99a623bb65516287c9.png