下载掌阅APP，畅读海量书库
立即打开
【必知必会】了解Kubernetes的架构及Kubernetes组件的作用。
为了使大家能够理解Kubernetes的架构，先以虚拟化架构来说明，如图3-1所示。
在VMware vSphere虚拟化环境里，ESXi是专门用来运行虚拟机的，为了统一管理、统一调度这些ESXi及里面的虚拟机，我们需要安装一台vCenter。这台vCenter作为一个控制台，通过vSphere Client或vSphere Web Client连接到vCenter上，然后就可以对整个虚拟化架构进行管理了。
Kubernetes的架构和这种虚拟化环境的架构是类似的，如图3-2所示。
图3-1 虚拟化架构
图3-2 Kubernetes的架构
这里的Master就相当于vSphere里的vCenter，是一个控制台，也叫作Control Plane Node（控制平面节点）。这里的Worker（工作节点）相当于vSphere里的ESXi，是专门用于运行Pod（容器）的。
前面讲到Docker直接管理容器，在K8s环境里直接管理的是Pod。Pod翻译成中文叫作“豆荚”，豆荚里有豌豆。豌豆藤上结的是一颗颗的豆荚而不是一粒粒的豌豆，即豌豆藤上管理的最小单位是豆荚。豌豆藤是Kubernetes，豆荚是Pod，豌豆是容器，即Kubernetes里最小的调度单位是Pod。一个Pod里可以有多个容器，一般情况下我们只会在Pod里设计一个容器。因为Pod里有各种策略、各种网络设置，所以更方便我们去管理，如图3-3所示。
图3-3 Pod和容器的关系
在Kubernetes里，我们不需要再使用docker run这种方式去创建容器了，Kubernetes会创建出一个个“豆荚”，即Pod。
客户端先要连接到Master上的APIServer,APIServer对客户端进行验证。验证通过之后，客户端发送一个创建Pod的请求，由调度器kube-scheduler决定这个Pod到底是在哪台Worker上创建，然后kube-scheduler会把这个决定的结果告诉kube-apiserver，之后kube-apiserver会给对应的Worker上的Kubelet发送请求。
对应Worker上的Kubelet收到kube-apiserver的请求之后，由Kubelet给runtime发送创建容器的请求，此时runtime会创建两个容器：一个是普通容器，另一个是Pause容器。这里需要注意的是，从Kubernetes的视角看是一个Pod，但从runtime的视角看其实是两个容器。
可以看到，Kubelet其实就是runtime的一个客户端，不过从Kubernetes v1.24开始就不再使用Docker作为runtime了，具体的大家可以通过https://www.rhce.cc/3749.html了解。
下面介绍Kubernetes的常见组件，如图3-4所示。
图3-4 Kubernetes的常见组件
Pod里的Pause容器用于建立网络Pod里的网络空间、进程空间等。Pod里的业务容器才是最终对外提供服务的，但是我们不会直接访问Pod，而是建立一个负载均衡器，然后由负载均衡器把流量转发到Pod上。这个负载均衡器叫作Service（简称SVC），就类似于我们给10086打电话，然后10086会把用户请求转发给后端的话务员。
负责把SVC的流量转发给后端Pod的组件叫作kube-proxy，这个kube-proxy利用iptables或ipvs把SVC的流量转发给后端的Pod，默认使用的是iptables。
Master上运行的组件及作用如表3-1所示。
表3-1 Master上运行的组件及作用
下面的组件是在所有节点上都有的，如表3-2所示。
表3-2 Worker上运行的组件及作用
续表
前面讲的Docker，都是在单主机上配置的，不同主机的容器要是想互相通信，可以通过端口映射，也可以通过安装Calico网络来实现。而K8s环境是多主机的，Pod可能会分布在不同的机器上，为了让这些Pod能顺利地互相通信，需要在K8s环境里安装Calico网络。
在整个环境里还需要数据库，这个数据库是Etcd，用于保存整个Kubernetes上的配置。
