互联网技术 / 互联网资讯 · 2024年3月21日 0

解析Kubernetes容器平台的架构

1.KubeRnetes容器平台架构解读

解析Kubernetes容器平台的架构

KubeRnetes是一个开源容器编排平台,管理大规模分布式容器化软件应用,是云计算发展演进的一次彻底革命性的突破。KubeRnetes是谷歌的第三代容器管理系统,是BoRg独特的控制器和OMega灵活的调度器的组合。KubeRnetes中的应用被打包成与环境完全分离的容器镜像,并且自动配置应用并维护跟踪资源分配。

KubeRnetes是以应用为中心的技术架构与思想理念,向下屏蔽基础设施差异,实现底层基础资源统一调度及编排;向上通过容器镜像标准化应用,实现应用负载自动化部署;中间通过KubeRnetes通用的编排能力,开放API以及自定义CRD扩展能力,打造云原生操作系统能力,形成云计算新界面;助力研发团队快速构建标准化、弹性高可靠、松耦合、易管理维护的应用系统,提升交付效率,降低运维复杂度。KubeRnetes在技术架构方面具备三个能力:

敏捷的弹性伸缩能力:不同于虚拟机分钟级的弹性伸缩响应,容器应用可实现秒级甚至毫秒级的弹性伸缩响应;

智能的服务故障自愈能力:容器应用具有极强的自愈能力,可实现应用故障的自动摘除与重构;

大规模的复制分发能力:容器应用标准化的交付制品,可实现跨平台、跨区域,云边一体规模化复制分发部署能力。

1.1.KubeRnetes整体架构

解析Kubernetes容器平台的架构

KubeRnetes是典型的主从分布式架构,由集中式管理节点(Master Node),分布式的工作节点(WoRkeR Node)组成以及辅助工具组成。

集中式管理节点,对集群进行调度管理,有四大核心组件:

API SeRveR:承担集群的网关,实现统一认证鉴权对外服务,同时也是管理Node/Pod资源代理通道;

ScheduleR:资源调度器,除了KubeRnetes默认的调度器,也支持自定义调度器;

ETCD:集群状态统一存储,与ZookeepeR类似的key-value存储;

ContRolleR MangeR:控制管理器实现自愈、扩容、应用生命周期管理、服务发现、路由、服务绑定等能力;KubeRnetes默认提供Replication ContRolleR、Node ContRolleR、NaMespace ContRolleR、SeRvice ContRolleR、Endpoints ContRolleR、PeRsistent ContRolleR、DaeMonSet ContRolleR等控制器。

分布式的工作节点,工作节点运行业务应用容器;默认会运行三大核心组件:

Kubelet:与管理节点通信并触发指令执行,管理驱动网络,存储及容器运行时;

Kube Proxy:通过DNS实现服务发现,借助IPtables规则引导访问至服务IP,并将重定向至正确的后端应用,实现高可用负载均衡能力;

ContAIneR RuntiMe:容器运行时。为了扩展KubeRnetes平台适配能力,同时也标准化整个生态,通过CNI与CSI标准规范网络及存储的扩展;通过CRI与OCI标准规范容器镜像及容器运行时的扩展;目前CRI支持的容器运行时有dockeR、Rkt、cRi-o、fRankti、kata-contAIneRs和cleaR-contAIneRs等。

辅助工具,主要是辅助集群管理及网络扩展:

kubectl通过API SeRveR进行交互,实现集群管理的命令行工具;

DashBOARd 是KubeRnetes的web用户管理监控界面;

CoRe DNS是可扩展的DNS服务器,实现集群服务发现能力。

1.2.KubeRnetes核心理念

1.2.1.POD容器组,KubeRnetes最小调度单元

解析Kubernetes容器平台的架构

Pod是KubeRnetes的最小调度及资源分配单元,Pod之间相互隔离,通常情况一个Pod只建议运行一个容器,当某些容器之间关系非常紧密(Tightly coupled),可以运行在同一Pod运行多个容器方便一起调度管理。一个Pod就是一个应用运行实例,通过同时运行多个Pod来实现应用横向扩展能力。Pod本身没有自恢复能力,当调度或运行失败时,需要管理节点的ContRolleR根绝配置触发实现Pod重启、重建或迁移等操作。

解析Kubernetes容器平台的架构

从Pod启动过程来看,Pod容器主要是Pause ContAIneR,InIT ContAIneR以及app ContAIneR三种类型容器组成:

Pause ContAIneR:又叫InfRa ContAIneR,Pod通过Pause ContAIneR实现Pod多个容器网络共享,Pause ContAIneR最先启动并绑定Pod唯一IP地址与各种网络资源,其他容器通过加入Pause ContAIneR的NetwoRk naMespace来实现网络共享。Pause是C语言实现,镜像非常小只有700KB左右,并且永远处于Pause(暂停)状态;官方镜像是gcR.io/Google_contAIneRs/pause-AMD64:3.0,同时也支持自定义。

InIT ContAIneR:Pod中可以自定义一个或者多个InIT ContAIneR,按照顺序依次启动,在应用ContAIneR之前启动并执行一些辅助任务,比如执行脚本、拷贝文件到共享目录、日志收集、应用监控等。将辅助功能与主业务容器解耦,实现独立发布和能力重用。除了不支持ReadineSS Probe,其他与特性与普通容器保持一致。

app ContAIneR:Pod真正承接业务的ContAIneR,一般情况会独立运行,如果是有微服务治理等需求会搭配SidecaR ContAIneR一起运行。在InIT ContAIneR启动完成之后,app ContAIneR会并行启动,但是需要等待所有app ContAIneR处于就绪状态,整个Pod才算启动成功。

从POD的资源隔离来看,Pod容器主要由linux提供的NaMespace和CgRoup能力实现的,NaMespace实现进程间隔离,CgRoup实现进程资源控制;其中NaMespace由iPC 、uts 、net 、Mnt 、pid 各种资源空间联合组成。

1.2.2.VoluMe存储卷,KubeRnetes复杂的存储架构

解析Kubernetes容器平台的架构

存储非常重要关键,同时也是生态与技术都比较复杂的领域,就linux、window两个生态支持的文件系统就多达20+。对于KubeRnete存储架构设计一直在持续演进完善,为了尽可能多地兼容各种存储平台,KubeRnetes以in-tRee plugin的形式默认对接很多不同类型的存储系统;同时也支持基于FlexVoluMe和CSI插件以out-of-tRee plugin来实现自定义存储服务。

对KubeRnetes存储,主要有应用的基本配置文件读取、密码密钥管理;应用的存储状态、数据存取,不同应用间数据共享等三大使用场景。目前KubeRnetes支持的VoluMe plugins如下表:

TeMp

EpheRMeRal(Local)

PeRsistent(NetwoRked)

OtheRs

EMpty DiR

host Path

GIT Repo

Local

SecRet

ConfigMap

DownwaRdAPI

AWS ElasticBlockSTore(EBS)

GCE PeRsistent Disk

AzuRe Data Disk

AzuRe file STorage

vSpheRe

Ceph FS and RBD

GlUSteRFS

iSCSI

CindeR

Dell EMC ScalelO

Flex VoluMe

ContAIneR STorage lnteRfACE(CSI,new in vl.9)

EMpty DiR:生命周期与Pod保持一致,当Pod删除后eMptyDiR中的数据也会被自动清除。当前eMptyDiR支持的类型有内存、大页内存、Node节点上Pod所在的文件系统。

ConfigMap:主要是承担配置中心,用于存储应用的配置数据,比如SpRingboot应用PropeRties配置文件数据,但是空间大小限制在1MB内。

SecRet:功能与ConfigMap类似,用于存储应用的敏感数据,比如数据密码、Token、证书等,可以与ConfigMap联合使用,同样空间大小限制在1MB内。

hostPath:将Node节点本地文件系统路径映射到pod容器中使用。与eMptyDiR不同之处就是Pod删除后,hostPath中的数据KubeRnetes根据用户的配置,可以不被清除。

In-tRee网络存储:网络存储跟随Pod的生命周期,通过存储插件对接不同类型存储;其中FlexVoluMe虽然允许自定义开发驱动来挂载卷到集群Node节点上供Pod使用,但生命周期与pod同步。

PeRsistentVoluMeClAIM网络存储:具有独立的生命周期,可以通过存储的out-tRee插件对接不同类型存储。当前支持的存储插件类型有FlexVoluMe与CSI。

引入PV、PVC、STorageClaSS之后,资源管控更加灵活,团队职责更加明确,研发人员只需考虑存储需求(IO、容量、访问模式等),不需要关注底层存储细节;底层复杂的细节都由专业的集群管理与存储管理员来完成。

CSI是KubeRnetes 1.9版本开始引入,建立一套标准的存储管理接口,通过该接口为容器提供存储服务。从而实现KubeRnetes平台与存储服务驱动完全解耦。CSI主要包含CSI ContRolleR SeRveR与CSI Node SeRveR两个部分,ContRolleR SeRveR主要实现创建、删除、挂载、卸载等控制功能;Node SeRveR主要实现的是Node节点上的 Mount、unMount的操作。

1.2.3.IngReSS与SeRvice,百花齐放的KubeRnetes网络

解析Kubernetes容器平台的架构

KubeRnetes 容器网络非常复杂,涉及的概念也比较多,比如Pod网络,SeRvice网络,ClUSteR IP,NodePoRt,loadbalanceR和IngReSS等,为此将KubeRnetes 的网络参考TCP/IP协议栈抽象为四层:

第0层:Node节点网络比较简单,就是保证KubeRnetes 节点(物理或虚拟机)之间能够正常IP寻址和互通的网络,一般由底层(公有云或数据中心)网络基础设施支持。

第1层:Pod是KubeRnetes的最小调度单元,Pod网络就是确保KubeRnetes集群中所有Pod(包括同一节点及不同节点上的Pod),逻辑上在同一个平面网络内,能够相互IP寻址和通信的网络。是容器网络最复杂部分,通过各种容器网络插件满足不同网络需求,通过CNI标准化及开放网络自定义能力。

第3层:虽然单个Pod都有IP,但是与Pod生命周期一致,为了解决一组相同Pod统一稳定的访问地址,并且