下载掌阅APP，畅读海量书库
立即打开
Kubernetes是典型的主从式架构，如图1-4所示，其管理者称为Control Plane（控制平面），被管理者称为Node（节点）。Control Plane在逻辑上只有1个，它负责管理所有的Node和Kubernetes object；Node可以有多个，它负责管理自身节点的资源和Pod。
Control Plane是新统一的术语，Kubernetes之前使用的术语是Master，直到2020年1月26日之后，Kubernetes官方才将Master统称为Control Plane。
图1-4 Kubernetes架构图
Control Plane是集群管理者，它的终极目标就是使得用户创建的各种Kubernetes object按照其配置所描述的状态运行。Control Plane既要对节点进行统一管理，又要调度资源并操作Pod，以满足Kubernetes object对象运行的需求。Control Plane并不像Linux内核是一个单一的实体，它由多个组件组合而成，每个组件是一个独立运行的进程。Control Plane组件可以在群集中的任何机器上运行。为了简单起见，启动脚本通常会在同一台计算机上启动所有Control Plane组件，按照之前的称呼习惯，本书把该计算机称之为Master节点或管理节点。Control Plane各个组件的描述如下。
考虑到可用性，在生产环境中，Control Plane中的每个组件通常以集群方式运行，可以参考第六章构建高可用的Control Plane。
1.kube-apiserver
kube-apiserver提供Kubernetes的API接口，它是Kubernetes的门户，客户端或者其他应用访问Kubernetes，都必须通过kube-apiserver。kube-apiserver以Web服务的方式提供API接口，而Web服务又有多种实现方案，kube-apiserver采用的是REST方案。因此，我们都要使用REST操作来同kube-apiserver交互。
客户端和kube-apiserver之间的通信，以及Kubernetes内部组件同kube-apiserver之间的通信，使用的都是REST操作。
kube-apiserver是一个进程，在管理节点上运行以下命令来查看该进程。
很多情况下，kube-apiserver会封装在容器中运行，而且还会注册Pod。
kube-apiserver支持水平扩展，可以运行多个kube-apiserver，而且kube-apiserver是无状态的，可以方便地实现负载均衡和高可用。
2.etcd
etcd是一个开源的KV数据库，KV是“Key Value”的缩写，中文翻译为键值对，它是一种数据的表示方式，其中，Key是数据的身份标识，Value是数据本身的内容。etcd可以提供一致性和高可用的数据存储服务， Kubernetes使用etcd来存储集群数据 ，也正是看中了这些特性。etcd以集群方式运行，节点间通过一致性算法来确保数据的一致性，从而确保数据访问的性能、正确性和可用性。etcd集群规模最小可以是1个节点，不建议在生产实践中这么用，etcd集群节点数至少应为3或是更大的奇数，选取奇数是便于etcd集群节点一次投票就选出leader。
etcd运行时也是一个独立的进程，运行下面的命令查看该进程。
很多时候，etcd会封装在容器中运行，使用以下命令查看容器中etcd的版本，其中eb0bb8cd101c是etcd容器的ID，“etcd--version”则是查看etcd版本的命令。
可以访问https://etcd.io/docs/v3.4.0/获取更多etcd的详细信息。
3.kube-scheduler
kube-scheduler用于分配一个Node（节点）来运行新创建的Pod。kube-scheduler在选择Node时，会综合考虑多种因素，例如：个人和集体的资源需求、硬件\软件\策略约束、数据局部性、内部负载干扰性等。
可以配置多个kube-scheduler同时运行，以确保其可用性。
kube-scheduler运行时也是一个独立的进程，在管理节点上运行下面的命令查看该进程。
很多情况下，kube-scheduler会封装在容器中运行，而且还会注册Pod。
4.controller-manger
1.2.7节中介绍了Controller的概念，Controller使得某一类指定的Kubernetes object按照配置所描述的状态来运行。从逻辑上讲，每个Controller应以独立的进程来运行，但考虑到效率和管理等诸多因素，Kubernetes将这些内置Controller合并到了一个进程之中，这个进程就是controller-manager（该控制器又称为kube-controller-manager）。controller-manager内包含了Node Controller、Replication Controller和Endpoints Controller等，有关这些Controller的功能描述，可以参考官方文档链接https://kubernetes.io/docs/concepts/overview/components/上的说明。
在管理节点上查看controller-manager进程，命令如下。
查看controller-manager所在的容器，命令如下。
查看controller-manager所在的Pod的命令如下。该Pod是kubeadm init时启动的静态（static）Pod，kubeadm是Kubernetes官方推出的快速部署Kubernetes集群工具，其思路是将Kubernetes相关服务容器化以简化部署。controller-manager注册成静态Pod后，该节点的kubelet进程会一直监控该静态Pod，如果controller-manager不可用，kubelet就会在该节点重启该Pod。
在运行“kubeadm init”时可以观察到Control Plane下的apiserver、controller-manager和scheduler都注册成了静态Pod，以此实现服务的高可用。这也是为什么停止Control Plane容器要先Kill掉kubelet的原因。
5.cloud-controller-manager
cloud-controller-manager是一个同底层云服务提供商交互的控制器。如果把Kubernetes部署在云上，Kubernetes同云上节点打交道的方式，会和之前直接同服务器（虚拟机）打交道的方式有所不同，因此需要专门的云服务控制器与之交互，而且不同的云服务提供商其云服务控制器也不同。这些特定的云服务控制器最初内置在kube-controller-manager，由于云服务提供商有很多，而且它们的接口也在不断迭代发展，这就会给版本一致性、兼容性、灵活性和更新等带来一系列问题。
为此，Kubernetes尝试将云服务控制器的功能进行抽象，然后从kube-controller-manager中抽取出来，放置到外部由各个云服务提供商来维护，同时制定统一的接口约束，由云服务提供商来做适配。这个抽取出来的部分就是cloud-controller-manager，cloud-controller-manager可以和任何满足接口约束条件的云服务提供商的代码相结合，形成一个在外部独立运行的控制器。
访问下面的链接获取cloud-controller-manager更多详细信息：
https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/。
Node（节点）接受Control Plane的管理，并负责本机Pod的启动和维护。Node有四个重要的组件：kube-proxy、kubelet、容器运行环境和Pod，具体说明如下。
1.kube-proxy
kube-proxy是Node的网络代理，它用来维护Node的网络规则，这些规则可以使得集群内外的网络会话可以同本Node的Pod进行通信。
kube-proxy是一个独立的进程，在每个Node上查看kube-proxy，命令如下。
kube-proxy通常也会封装在容器中运行，并且以作为静态Pod注册到本机所在的kubelet，这样，一旦kubelet监控到该Pod不可用，就会在本机再启动一个Pod来恢复kube-proxy的运行。
Node节点的组件在Master节点上也会存在。
2.kubelet
kubelet是节点代理（Node agent），kubelet运行后会注册到Kubernetes，在Kubernetes中所看到的各个Node就是各个kubelet注册的结果。kubelet接受Control Plane发送的指令，如启动Pod，然后负责具体执行指令。
3.Container Runtime
Container Runtime是容器运行时，是负责运行容器的软件和库的集合。因为Pod是一组容器的集合，Pod在Node上运行，因此Node上必须要部署容器运行时。Kubernetes目前支持的容器运行时有：Docker、containerd和CRI-O等，并且提供了一个统一的容器运行时接口（Kuernetes CRI）供其他容器运行环境接入。以Docker为例，如果选择Docker作为容器运行时，那么在每个Node节点上都要安装Docker。
4.Pod
严格意义上Pod并不是Node组件，它只是Node管理的对象。但是因为它的地位特殊，Node（甚至整个Kubernetes集群）都是围绕着Pod服务的，因此，在此处再次强调：Pod是一组相关容器的集合，这些容器共享Pod内部相同的网络和存储，容器间互相协作对外提供服务。kubelet接收“Control Plane”的指令，来完成Pod的操作；而Pod中容器的操作，则是由kubelet发起，交由容器运行时环境具体完成的；此外，kube-proxy还会设置相关的网络规则，以实现Pod同集群内外应用的网络通信；Pod创建好后，kubelet还会监控Pod状态，确保其正常运行。
Kubernetes除了Control Plane和Node这两大组件之外，还有很多的Addons（插件）用于Kubernetes功能的扩展。例如，DNS插件可以为Kubernetes提供域名服务；Dashboard（用户界面）提供Kubernetes集群的Web UI界面，从而实现图形化的集群管理；容器资源监控和集群日志等插件，这些插件也是基于Kubernetes object（Deployment等）来实现的，它们以集群方式运行，为Kubernetes提供服务。
参考下面的链接获取插件的更多详细信息https://kubernetes.io/docs/concepts/cluster-administration/addons/。
kubectl是一个命令，是用户同Kubernetes交互的工具。用户要对Kubernetes做任何操作，获取任何信息，都通过kubectl来完成。后续会介绍kubectl的典型使用，更多详细的信息，可以参考链接https://kubernetes.io/docs/reference/kubectl/overview/。