容器云系列之Kubernetes基本架构介绍

K8S是开源的容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理，有助于运维人员进行资源的自动化管理和利用率最大化。本文是基于张建锋老师容器技术培训关于K8S的有关总结和整理，以加深学习了解。

1、K8S基本架构介绍

Kubernetes简称K8S，是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理，目的是实现资源管理的自动化以及跨数据中心的资源利用率最大化。官方的描述如下：

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.

K8S能够在开发、测试以及运维监控在内的各个环节进行部署。在K8S中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，这些细节都不需要运维人员去进行复杂的手工配置和处理。

1.1 K8S的集群管理能力

容器是打包和运行应用程序的好方式，在生产环境中，运维人员需要管理运行应用程序的容器，并确保不会停机，这些可以通过K8S来实现。K8S的核心功能是自动化运维管理多个容器化程序，提供了一个可弹性运行分布式系统的框架，满足扩展要求、故障转移、部署模式等要求。因此具备以下集群管理能力：

多层次的安全防护和准入机制
多租户应用支撑能力：基于容器对应用运行环境的资源配置要求自动部署应用容器
透明的服务注册和服务发现机制：K8S可以使用DNS名称或自己的IP地址公开容器，
内建的智能负载均衡器：如果进入容器的流量很大，K8S可以负载均衡并分配网络流量，从而使部署稳定
强大的故障发现和自我修复能力：当容器失败时，会对容器进行重启，当所部署的 Node 节点有问题时，会对容器进行重新部署和重新调度，当容器未通过监控检查时，会关闭此容器直到容器正常运行时，才会对外提供服务
服务滚动升级和在线扩容能力：可以根据应用的变化，对应用容器运行的应用，进行一次性或批量式更新
可扩展的资源自动调度机制：通过简单的命令、用户UI界面或基于CPU等资源使用情况，对应用容器进行规模扩大或规模剪裁
多粒度的资源配额管理能力：K8S允许指定每个容器所需CPU和内存（RAM）。当容器指定了资源请求时，K8S可以做出更好的决策来管理容器的资源
批任务处理：提供一次性任务，定时任务；满足批量数据处理和分析的场景

1.2 K8S整体架构及组件介绍

K8S是属于主从Master-Slave架构，主节点一般被称为Master Node，而从节点则被称为Worker Node或者Node，Master Node负责核心的调度、管理和运维，Worker Node则执行用户的程序。每个Node对应一台实体服务器，同一个集群中可以有多个Master Node和Worker Node，所以的Nodes构成了K8S集群。

Master Node：主控节点，管理整个集群，是客户端和集群之间的联络点。API服务管理、跟进组件健康状态、优化调度工作负载、组件通信联络，一般是3台Master主机。
- API Server：K8S的请求入口服务。API Server负责接收K8S所有请求（来自 UI 界面或者 CLI 命令行工具），然后，API Server根据用户的具体请求，去通知其他组件干活
- Kubectl：命令行工具
- ETCD：K8S的存储服务，是一个分布式的一个存储系统，提供高可用性、严格数据一致性的非关系型数据库，具有共享配置、服务发现、分布式等特点，常被用于构建服务发现系统。API Server中所需要的这些原信息都被放置在etcd中，etcd本身是一个高可用系统，通过etcd保证整个Kubernetes的Master组件的高可用性。
- Control Manager：K8S 所有Worker Node的监控器。Controller Manager有很多具体的Controller，包括 Node Controller、Service Controller、Volume Controller等。Controller负责监控和调整在Worker Node上部署的服务的状态，比如用户要求A服务部署2个副本，那么当其中一个服务挂了的时候，Controller会马上调整，让Scheduler再选择一个Worker Node重新部署服务。
- Scheduler：K8S所有Worker Node的调度器。当用户要部署服务时，Scheduler会选择最合适的Worker Node（服务器）来部署。
Worker Node：工作节点，执行具体的工作任务。Node主要接收来自Master的工作指令、创建或销毁Pod对象、调整网络规则和转发路由流量
- Kubelet：Worker Node的监视器，以及与Master Node的通讯器。Kubelet是Master Node安插在Worker Node上的“眼线”，它会定期向Worker Node汇报自己Node上运行的服务的状态，并接受来自Master Node的指示采取调整措施。
- Pod：可以在K8S中创建和管理的、最小的可部署的计算单元。与Pod里容器打交道，每个Pod下有多个容器
- Kube-proxy：K8S的网络代理。Kube-Proxy负责Node在K8S的网络通讯、以及对外部网络流量的负载均衡
- Container Runtime：Worker Node的运行环境，即安装了容器化所需的软件环境确保容器化程序能够跑起来，比如Docker Engine

1.2.1 ETCD介绍

Etcd是基于Raft开发的分布式key-value键值数据存储系统，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。

在K8S中Etcd有以下特性：

是K8S服务发现，集群状态存储以及其配置的基石
存储集群的配置数据和展现整个集群在某一时间点的状态
Etcd以集群部署，节点间通信是通过Raft算法处理
在生产环境中，集群包含至少3个节点
基于Go语言实现，只被API Server访问

1.2.2 API server

APIserver整个系统的数据总线和数据中心，主要有以下功能：

集群各个功能模块之间数据交互和通信的中心枢纽，提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
提供HTTP Rest接口，提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
资源配额控制的入口，K8S各类资源对象(Pod、RC、Service等)的增删改查及Watch

K8S通过kube-apiserver这个进程提供服务，该进程运行在单个k8s-master节点上。默认有两个端口：本地端口8080和安全端口6443。API Server可以通过curl、kubectl proxy和kubectl客户端的方式进行访问。

1.2.3 Control Manager

Controller Manager是集群内部的管理控制中心，由kube-controller-manager和cloud-controller-manager组成，是Kubernetes的大脑，它通过apiserver监控整个集群的状态，并确保集群处于预期的工作状态。kube-controller-manager通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时,会尝试将系统状态修复到“期望状态”。K8S本质是将运行的环境达到期望的状态，Control Manager主要管理集群内以下资源：

Node、Pod副本
服务端点(Endpoint)
命名空间(Namespace)
服务账号(ServiceAccount)
资源定额(ResourceQuota)

上图中Deployment controller监视API Server中的Deployments，ReplicaSet controller监控API Server中的ReplicaSets。

1.2.4 Scheduler

kube-scheduler 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点。
Scheduler调度要充分考虑诸多因素，包括：公平调度、资源高效利用、QoS、affinity和anti-affinity、数据本地化、内部负载干扰以及deadlines。从 v1.8 开始，kube-scheduler 支持定义 Pod 的优先级，从而保证高优先级的 Pod 优先调度。并从 v1.11 开始默认开启。因此scheduler 在调度时分为两个阶段：

predicate：过滤不符合条件的节点
priority：优先级排序，选择优先级最高的节点

如上图所示，左边的Pod只能调度到gpu=true标签的Node，右边的Pod没有这种限制，可以调度到任何一个Node上。

1.2.5 Kubelet

每个Node上都运行一个kubelet服务进程，接收并执行 master 发来的指令，管理Pod及Pod中的容器。每个kubelet进程会在API Server上注册节点自身信息，定期向master节点汇报节点的资源使用情况，并通过cAdvisor监控节点和容器的资源，比如每个节点中容器的CPU、内存和网络使用情况。

节点管理：主要是节点自注册和节点状态更新，Kubelet在启动时通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接收到新消息后，将信息写入etcd
POD管理：通过apiserver获取pod清单及创建pod的过程，如果发现本地的Pod被修改，则Kubelet会做出相应的修改，比如删除Pod中某个容器时，则通过Docker Client删除该容器。如果发现删除本节点的Pod，则删除相应的Pod，并通过Docker Client删除Pod中的容器
容器健康检查：Kubelet定期调用容器中的LivenessProbe探针来诊断容器的健康状况
cAdvisor资源监控：Kubelet通过cAdvisor获取其所在节点及容器的数据
kubelet 驱逐：Kubelet会监控资源的使用情况，并使用驱逐机制防止计算和存储资源耗尽。在驱逐时，Kubelet 将Pod的所有容器停止，并将PodPhase设置为Failed

上图表示Kubelet创建POD的流程，具体包括以下：

1）获取Pod进行准入检查

准入检查主要包含两个关键的控制器：驱逐管理与预选检查。驱逐管理主要是根据当前的资源压力，检测对应的Pod是否容忍当前的资源压力；预选检查则是根据当前活跃的容器和当前节点的信息来检查是否满足当前Pod的基础运行环境，例如亲和性检查，同时如果当前的Pod的优先级特别高或者是静态Pod，则会尝试为其进行资源抢占，会按照QOS等级逐级来进行抢占从而满足其运行环境

2）创建事件管道与容器管理主线程

kubelet接收到一个新创建的Pod首先会为其创建一个事件管道，并且启动一个容器管理的主线程消费管道里面的事件，并且会基于最后同步时间来等待当前kubelet中最新发生的事件(从本地的podCache中获取)，如果是一个新建的Pod，则主要是通过PLEG中更新时间操作，广播的默认空状态来作为最新的状态

3）同步最新状态

当从本地的podCache中获取到最新的状态信息和从事件源获取的Pod信息后，会结合当前当前statusManager和probeManager里面的Pod里面的容器状态来更新，从而获取当前感知到的最新的Pod状态

4）准入控制检查

之前的准入检查是Pod运行的资源硬性限制的检查，而这里的准入检查则是软状态即容器运行时和版本的一些软件运行环境检查，如果这里检查失败，则会讲对应的容器状态设置为Blocked

5）更新容器状态

在通过准入检查之后，会调用statusManager来进行POd最新状态的同步，此处可能会同步给apiserver

6）Cgroup配置

在更新完成状态之后会启动一个PodCOntainerManager主要作用则是为对应的Pod根据其QOS等级来进行Cgroup配置的更新

7）Pod基础运行环境准备

接下来kubelet会为Pod的创建准备基础的环境，包括Pod数据目录的创建、镜像秘钥的获取、等待volume挂载完成等操作创建Pod的数据目录主要是创建 Pod运行所需要的Pod、插件、Volume目录，并且会通过Pod配置的镜像拉取秘钥生成秘钥信息，到此kubelet创建容器的工作就已经基本完成

1.2.6 Kube-proxy

Kube-proxy是为了解决外部网络能够访问跨机器集群中容器提供的应用服务而设计的，它运行在每个Node上，支持提供TCP/UDP sockets。Proxy主要从etcd获取Services和Endpoints的配置信息，然后根据配置信息在Node上启动一个Proxy的进程并监听相应的服务端口。当外部请求发生时，Proxy会根据Load Balancer将请求分发到后端正确的容器处理，实现网络代理和负载均衡。

kube-proxy监听API server中service和endpoint的变化情况，并通过 userspace、iptables、ipvs 或 winuserspace 等 proxier 来为服务配置负载均衡。

1.3 K8S工作原理

Controller-manager定时检测ReplicaSet的状态
1. Kubectl向API-server发起创建ReplicaSet请求
2. API-server向ETCD提交创建ReplicaSet
3. ETCD上报事件“ReplicaSet Created”到API-server
4. API-server再将事件“ReplicaSet Created”上报到controller-manager
5. Controller-manager向API-server发送创建Pod请求
6. API-server向ETCD提交创建Pod
Scheduler定时检测Pod的状态，监测未调度的Pod进行多策略调度
1. 当ETCD创建完Pod后，会上报事件“Pod Created”到API-server
2. API-server再将事件“Pod Created”返回给Scheduler
3. Scheduler会向API-server发送更新的Pod按照调度结果绑定Node
4. API-server再向ETCD中更新Pod情况
Kubelet会定时检测调度到本节点的Pod
1. 当ETCD向API-server上报事件“节点中绑定的Pod已经更新”
2. API-server再把事件“节点中绑定的Pod已经更新”返回给Kubelet

参考资料：

容器技术培训，张建锋老师
https://kubernetes.io/zh/docs
https://blog.csdn.net/Tencent_TEG/article/details/111877836
https://blog.csdn.net/weixin_45537987/article/details/107556796

转载请注明原文地址：https://blog.csdn.net/solihawk/article/details/124573597
文章会同步在公众号“牧羊人的方向”更新，感兴趣的可以关注公众号，谢谢！