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