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

这是非云环境中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