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

2020 年 8 月 23 日

非云环境中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”。


参考链接:



工作节点(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


2020 年 8 月 23 日 10:001192

评论

发布
暂无评论
发现更多内容

Flag: 给自己定个小目标

Fen9Pi

个人感悟

影调:光影交响曲

北风

摄影 风光 影调 光影 人像

英特尔十代酷睿携手机械革命X3-S 纵享顺畅游戏之巅

飞天鱼2017

什么是深度强化学习?

华章IT

学习 智能体

第九周作业

Geek_a327d3

直播平台在贝壳找房中的实践与运用

陈威威

架构 分层架构 直播 分层思维 多元场景应用

零基础建网站必备技能,看这一篇就够了

北柯

程序语言 网站搭建 编程网站

如何设计一个优秀的组件

Lee Chen

前端进阶训练营

女博士年薪156万入职华为!网友:实力演绎美貌与智慧并存

程序员生活志

华为 少年天才

详解GaussDB(for MySQL)服务:复制策略与可用性分析

华为云开发者社区

数据 路径 可用性 华为云 GaussDB

【DevOps】Jenkins持续集成流水线(中)

Man

DevOps jenkins CI/CD JACOCO FINDBUG

环信大学:模型的边界!

环信

原创 | 使用JPA实现DDD持久化- O:对象的世界(2/3)

编程道与术

Java hibernate DDD JDBC jpa

NIO的组成有哪些——奈学

奈学教育

nio

如果不懂编程,请看这里!!!

代码制造者

学习 编程 低代码 零代码

.net core快速开发平台,learun自主工作流引擎设计规范

力软.net/java开发平台

信创舆情一线--工信部开展网络安全技术应用试点示范工作

统小信uos

【译】代码中如何写出更有意义的命名

Jackey

代码质量

Week09作业

熊威

百度大脑人脸离线识别SDK升级盘点,Linux ARM版本上线

百度大脑

人工智能 人脸识别 百度大脑 sdk

EasyDL的数据集、模型与代码的版本管理:灵活管理效率提升

百度大脑

人工智能 模型训练 百度大脑

计算之美(1/12)

我的偶像是木子

数据结构 算法

日入斗金,稳赚不赔?小心泛滥网络的兼职刷单让你钱尽财空

360安全卫士

微服务架构下的核心话题 (二):微服务架构的设计原则和核心话题

xcbeyond

架构 微服务 设计原则

为Z3 Air-赋能,十代酷睿引领游戏5GHz新时代!

飞天鱼2017

如何将FastDFS存储数据平滑迁移至XSKY对象存储?

XSKY融合存储

打造高转化率网站不得不遵循的3条规范

姜奋斗

网站架构 网站 网站搭建 高转化率 转化

当百度遇上新基建:开放是基本原则 做智能时代的赋能者

百度大脑

人工智能 百度 AI 新基建 百度大脑

对于容器技术的看法

倾心煎蛋

Gitlab 部署配置

wong

gitlab

华为云的研究成果又双叒叕被MICCAI收录了!

华为云开发者社区

学习 AI 计算机视觉 医疗 华为云

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