这是非云环境中Kubernetes的配置和运行系列的第五篇，本文将介绍Kubernetes主节点和工作节点的各个组件，包括控制器管理（Controller Manager）、API服务器、etcd、调度器（Scheduler）、Kubelet等。

主节点（Master）

主节点负责编排工作节点上运行容器的所有相关活动。其中，主节点调度和部署集群应用，采集工作节点和Pods的信息。

主节点配置模式

使用etcd节点的堆叠（Stacked）控制平台

此配置模式中，服务以容器方式运行，由kubeadm自动配置。

堆叠高可用集群模式的拓扑如下图所示。其中，集群节点由运行控制平台的kubeadm管理，分布式数据存储由etcd提供，并堆叠在集群上。

每个控制平台节点均运行api-server、调度器（scheduler）和controller-manager进程。api-server进程通过负载均衡器（在此，我们使用的负载均衡器是 HA Proxy））提供给工作节点使用，并创建etcd本地成员。本地成员只与运行在同一节点上的api-server进程通信。调度器和controller-manager进程也采用同样的机制。

这种拓扑实现了控制平台与etc成员在运行节点上的耦合。相比于外部etcd节点而言，该拓扑更易于建立、管理和复制。

但是，堆叠集群存在耦合失败的风险。如果一个节点宕机，就会丢失etcd成员和控制平台进程。对此需要增加冗余度，通过添加更多的控制平台降低此类风险。

因此我们建议，对于高可用集群，至少应运行三个堆叠控制平台节点。

图 kubeadm高可用拓扑：堆叠etcd模式

参考链接： https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

使用外部etcd节点的堆叠控制平台

在此配置模式中，服务以容器方式运行，由kubeadm部分配置。

使用外部etcd节点的高可用集群的拓扑如下图所示。其中，集群有运行控制平台的节点组成，由etcd提供的分布式数据存储集群独立于集群。

类似于堆叠etcd模式，在外部etcd模式的拓扑中，每个控制平台节点均运行api-server、调度器和controller-manager进程。其中，api-server进程通过负载均衡器提供给工作节点使用。但是，etcd成员运行在独立的机器上，每个etcd主机与每个控制平台节点的api-server通信。

这种拓扑实现了控制平台和etc成员的解耦。相对于堆叠高可用模式而言，控制平台和etc成员的宕机对集群冗余性的影响甚微。

但是相比于堆叠高可用模式，外部etcd模式所需的主机数量翻番。该模式最少需要三台控制平台节点主机、三台etcd节点主机。

图 kubeadm高可用拓扑：外部etcd模式

参考链接： https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/

使用外部etcd节点和控制平台服务

在此配置模式中，服务以独立进程方式运行，不使用kubeadm配置，而是手工配置。该模式更为灵活，但是在建立集群中需要更多的人工参与。

使用外部etcd节点的高可用集群控制平台的拓扑如下图所示。其中，集群有运行控制平台的节点组成，由etcd提供分布式数据存储独立于集群。

类似于使用外部etcd节点的堆叠控制平台，在该模式中每个控制平台节点均运行api-server、调度器和controller-manager进程。其中，api-server进程通过负载均衡器提供给工作节点使用。etcd成员运行在独立主机上，每个etcd主机与每个控制平台节点的api-server进程通信。

该模式在同一节点上以独立服务方式运行api-server、调度器和controller-manager进程，etcd采用单独节点运行。类似于堆叠高可用拓扑，该模式提供的高可用设置中，控制平台进程和etcd成员宕机的影响甚微，不会影响集群冗余度。

但是，相比于堆叠高可用模式，该模式所需的主机数量翻番。最少需要三台控制平台节点主机、三台etcd节点主机，并且各服务必须逐个手工安装和配置。

图：使用外部etcd服务的Kubernetes控制平台

所使用的方法

我们推荐使用etcd节点的堆叠控制平台拓扑配置。因为此配置所需的手工配置最少，使用的服务实例也最少，

各组件概述

kubeadm：提供kubeadm Init和join命令，是一种创建Kubernetes集群最佳实践的“捷径”。kubeadm操作建立并运行最小可用集群，命令在设计上考虑的是如何引导机器，而没有涉及如何配置机器。同样，如何安装各种适用的附加组件，例如Kubernetes仪表板、监视解决方案和一些特定于云的附加组件，也并不在kubeadm的考虑范围内。使用kubeadm可作为所有部署的基础，更轻松地创建一致的集群。
kubelet：运行在工作节点上的服务。kubelet读取Pod清单（Manifests）文件，确保清单文件所定义的容器已启动并处于运行状态。
etcd：一种高可用一致性键值存储，为Kubernets的所有集群节点提供后台存储。如果Kubernetes集群使用etcd作为后台存储，需确保对数据建立备份计划。
containerd：一种注重简单性、稳定性和可移植性的容器运行时。containerd以驻留进程方式运行在Linux/Windows上，负责获取和存储容器镜像、执行容器、提供网络访问等功能。在本系列教程中，我们使用的是Docker。
api-server：运行在主节点上，提供Kubernetes API。它是Kubernetes控制平台的前端，设计上考虑了水平扩展。也就是说，可通过部署更多api-server实例实现扩展。
controller-manager：位于运行控制器的主节点上。每个控制器逻辑上是一个独立的进程。但为了降低复杂性，所有控制器编译为同一个二进制程序，以单个进程运行。
调度器：运行在主节点上，监控新创建且未分配工作节点的Pod，选择运行Pod的工作节点。Pod调度所考虑因素包括：所需的独立和汇总资源量、硬件/软件/策略上的限制、亲和性和反亲和性（Affinity/Anti-Affinity）规范、数据本地性、工作负载间干扰和期限等。

图 Pod创建流程（图片来源 heptio.com）

kube-proxy：运行在集群中每个工作节点上的网络代理。kube-proxy负责转发请求，支持在一组后台函数间的TCP/UDP流转发和轮询转发。

DNS集群扩展：Kubernets DNS在集群上调度DNS Pod和服务，并配置kubelets支持单一容器使用DNS服务的IP去解析DNS名字。

集群中定义的每个服务（包括DNS服务器本身）将分配一个DNS名。默认情况下，客户Pod的DNS搜索Pod自身的命名空间以及集群的默认域名。下面的例子给出了很好的解释：

给定在Kubernetes命名空间“bar”中的服务“foo”。在该命名空间中运行的Pod，可以通过基本的DNS查询“foo”查找到该服务。在命名空间“quux”中运行的Pod，可以通过DNS查询“foo.bar”查找到该服务。
cni-plugin：是一类符合appc/CNI规范的网络插件。它支持运行在不同节点上的Pod间的互连，可灵活集成Overlay网络、完全第三层网络等不同类型网络解决方案
- Kubernetes和CNI的更多信息，可参考官方文档“ Network plugins”。

参考链接：

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
https://kubernetes.io/docs/reference/glossary/?fundamental=true
https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#introduction

工作节点（Worker）

工作节点是有效运行Kubernetes所管理容器的机器，或称为节点，其可以是物理节点，也可以是虚拟机。工作节点为实现被Kubernetes管理，必须安装Kubelet代理kube-proxy。工作节点与主节点的所有通信均通过kube-proxy，进而执行所有集群操作。

工作节点的配置模式

堆叠（Staked）工作节点

在这种配置模式中，服务以容器形式运行，由kubeadm自动配置。

堆叠工作节点的拓扑如下图所示。其中，每个节点均运行kubelet、kube-proxy、cni-plugins和containerd进程。

该模式下工作节点易于配置，只需要安装kubeadm、kubelet和containerd。kube-proxy和cni-plugin等组件将在工作节点加入集群时初始化，即在运行kubeadm join命令后。

该模式下，kube-proxy和cni-plugins作为容器运行。

工作节点服务

在这种配置模式中，服务以独立进程方式运行，需要手工配置，无需使用kubeadm。该模式更为灵活，但是增加了集群建立者的工作量。

工作节点服务的拓扑如下图所示。其中，每个节点均运行kubelet、kube-proxy、cni-plugins和containerd进程。每个服务需依次安装和配置。

该模式下，kube-proxy和cni-plugins作为独立服务运行。

所使用的方法

我们使用堆叠工作节点模式，因为这需要更少的配置工作。

组件

kubelet、kube-proxy、cni-plugins和containerd等组件在主节点和工作节点上具有相同的工作机制，具体定义如上。

原文链接：

Kubernetes Journey — Up and running out of the cloud — Master and Worker

创作场景

非云环境中 Kubernetes 的配置和运行：主节点和工作节点