深入理解容器集群管理系统Kubernetes(k8s)原理
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/246140ab0d0ef27909f4a33a0238013a.png)
前言
单机容器编排:
docker-compose
容器集群编排
docker swarm、mesos+marathon、kubernetes
应用编排:
ansible
一、Kubernetes 是什么?
- Kubernetes 是的缩写为:K8s这个缩写是因为 k 和 s 之间有八个字符的关系。
- Kubernetes 是一个
可移植的、可扩展的开源平台
,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
1.1 k8s的作用
用于自动部署、扩展和管理“容器化(containerized) 应用程序"的开源系统
。
可以理解成K8S是负责自动化运维管理多个容器化程序(比如Docker)的集群,是一个生态极其丰富的容器编排框架工具
。
1.2 k8s的由来
-
K8S由google的Borg系统(博格系统,google内部使用的大规模容器编排工具)作为原型,后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。
-
Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”。
官网: https://kubernetes.io
GitHub: https://github.com/kubernetes/kubernetes
二、为什么需要 Kubernetes,它能做什么?
容器是打包和运行应用程序的好方式
。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 来解决这些问题的方法! Kubernetes 为你提供了一个可弹性运行分布式系统的框架
。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
K8S是Google开源的容器集群管理系统,在Docker等容器技术的基础上,
为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,
提高了大规模容器集群管理的便捷性。
其主要功能如下:
1.使用 Docker 等容器技术对应用程序包装(package)、实例化(instantiate)、运行(run)。
2.以集群的方式运行、管理跨机器的容器。
3.解决 Docker 跨机器容器之间的通讯问题。
4.K8S 的自我修复机制使得容器集群总是运行在用户期望的状态。
三、Kubernetes的特性
1.弹性伸缩:使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性;业务低峰时回收资源,以最小成本运行服务。
伸缩——》扩容和缩容(节点 应用类型nginx)
弹性——》人为只要指定规则,满足条件时,就会自动触发 扩容或缩容的操作
2.自我修复:在节点故障时重新启动失败的容器,替换和重新部署,保证预期的副本数量;
杀死健康检查失败的容器,并且在未准备好之前不会处理客户端请求,确保线上服务不中断。
3.服务发现和负载均衡:K8S为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称),
并且负载均衡关联的所有容器,使得用户无需考虑容器IP问题。
4.自动发布(默认滚动发布模式)和回滚:K8S采用滚动策略更新应用,一个更新一个Pod,而不是同时删除所有的Pod,如果更新过程中出现问题,将回滚更改,确保升级不收影响业务。
5.集中化配置管理和密钥管理:管理机密数据和应用程序配置,而不需要把敏感数据暴露在镜像里,提高敏感数据安全性,并可以将一些常用的配置存储在K8S中,方便应用程序使用。
6.存储编排:支持外挂存储并对外挂存储资源进行编排,挂载外部存储系统,无论是来自本地存储,公有云(如:AWS),还是网络存储(如:NFS、Glusterfs、Ceph)都作为集群资源的一部分使用,极大提高存储使用灵活性。
7.任务批量处理运行:提供一次性任务,定时任务,满足批量数据处理和分析的场景。
Kubernetes 特点
- 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)
- 可扩展: 模块化, 插件化, 可挂载, 可组合
- 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展
- 快速部署应用,快速扩展应用
- 无缝对接新的应用功能
- 节省资源,优化硬件资源的使用
K8s解决了裸跑docker的若干痛点:
- 单机使用,无法有效集群
- 随着容器数量的上升,管理成本攀升
- 没有有效的容灾、自愈机制
- 没有预设编排模板,无法实现快速、大规模容器调度
- 没有统一的配置管理中心工具
- 没有容器生命周期的管理工具
- 没有图形化运维管理工具
四、Kubernetes架构
-
K8S 是属于
主从设备模型
(Master-Slave 架构),即有 Master 节点负责集群的调度、管理和运维,Slave 节点是集群中的运算工作负载节点。 -
在 K8S 中,主节点一般被称为 Master 节点,而从节点则被称为 Worker Node 节点,每个 Node 都会被 Master 分配一些工作负载。
-
Master 组件可以在群集中的任何计算机上运行,但建议 Master 节点占据一个独立的服务器。因为 Master 是整个集群的大脑,如果 Master 所在节点宕机或不可用,那么所有的控制命令都将失效。除了 Master,在 K8S 集群中的其他机器被称为 Worker Node 节点,当某个 Node 宕机时,其上的工作负载会被 Master 自动转移到其他节点上去。
组件 | 作用 |
---|---|
master节点 | |
apiserver | 所有服务的访问入口 |
controller-manager | 负责根据预设模板创建pod,维持pod等资源的副本期望数目 |
scheduler | 负责调度pod,通过预选策略、优选策略选择最合适的node节点分配pod |
etcd | 分布式键值对数据库,负责存储K8S集群的重要信息(持久化) |
work node节点 | |
Kubelet | 跟apiserver通信汇报当前node节点上的资源使用情况和状态,接受apiserver的指令跟容器引擎交互实现容器的生命周期管理 |
Kube-proxy | 在node节点上实现pod的网络代理,维护网络规则和四层负载均衡规则,负责写入规则到iptables或ipvs实现服务映射访问 |
容器运行时docker | 运行容器,负责本机的容器创建和管理工作 |
五、Kubernetes工作流程
- 1.首先运维人员使用kubectl命令行工具向API Server发送请求,API Server接收到请求后会写入到etcd中,API Server会让Controller-manager按照预设的模板去创建pod,Controller-manager通过 API Server读取etcd中用户的预设信息,再通过API Server去找 Scheduler可以为新创建的pod选择最适合的node节点。scheduler会通过API Server在Etcd存储中心根据存储的node节点元信息、剩余资源等,用预选策略和优选策略挑选最优的node节点
- 2.scheduler确定node节点后通过API Server交给这个Node节点上的kubelet进行pod资源的创建,kubelet调用容器引擎交互创建pod,同时将pod监控信息通过API server存储到etcd中
- 3.用户访问时,通过kube-proxy负载、转发,访问相应的pod
决定创建pod清单的是Controller-manager控制器,而kubelet、容器引擎都是干活的
六、kubernetes集群架构与组件
6.1 kubernetes 组件
K8S是属于主从设备模型(Master-slave 架构),即有Master 节点负责集群的调度、管理和运维,Slave 节点是集群中的运算工作负载节点。
在K8S中,主节点一般被称为Master 节点,而从节点则被称为Worker Node节点,每个Node都会被Master分配一些工作负载。
Master组件可以在群集中的任何计算机上运行,但建议Master节点占据一个独立的服务器。因为Master是整个集群的大脑,如果Master所在节点宕机或不可用,那么所有的控制命令都将失效。除了Master, 在K8S集群中的其他机器被称为Worker Node节点,当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上去。
6.1.1 master组件
master:集群的控制平面,负责集群的决策 ( 管理 )
①kube-apiserver
Kubernetes API,集群的统一入口
,各组件协调者,以**Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
用于暴露Kubernetes API,任何资源请求或调用操作都是通过kube-apiserver 提供的接口进行。以HTTP Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd 存储(相当于分布式数据库,以键值对方式存储)。
可以理解成API Server 是K8S的请求入口服务。API server负责接收K8S所有请求(来自UI界面或者CLI 命令行工具),然后根据用户的具体请求,去通知其他组件干活。可以说API server 是K8S集群架构的大脑。
②kube-controller-manager (控制器管理中心-定义资源类型)
运行管理控制器
,是k8s集群中处理常规任务的后台线程,是k8s集群里所有资源对象的自动化控制中心。- 在k8s集群中,
一个资源对应一个控制器
,而Controller manager 就是负责管理这些控制器的。
由一系列控制器组成,通过API Server监控整个集群的状态
,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态
.
控制器 | 功能 |
---|---|
NodeContrpller(节点控制器) | 负责在节点出现故障时发现和响应 |
Replication Controller ( 副本控制器) | 负责保证集群中一个RC (资源对象ReplicationController) |
Endpoints Controller (端点控制器) | 填充端点对象(即连接Services 和Pods) ,负责监听Service 和对应的Pod 副本的变化。可以理解端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的 endpoint |
Service Account & Token Controllers (服务帐户和令牌控制器) | 为新的命名空间创建默认帐户和API访问令牌 |
ResourceQuotaController(资源配额控制器) | 确保指定的资源对象在任何时候都不会超量占用系统物理资源 |
Namespace Controller (命名空间控制器) | 管理namespace的生命周期 |
Service Controller (服务控制器) | 属于K8S集群与外部的云平台之间的一个接口控制器 |
③kube-scheduler
- 根据调度算法(
预选/优选的策略
)为新创建的Pod选择一个Node节点,可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上 - 可以理解成K8S所有Node 节点的调度器。当用户要部署服务时,scheduler 会根据调度算法选择最合适的Node 节点来部署Pod.
- API Server 接收到请求创建一批Pod,API Server 会让Controller-manager 按照所预设的模板去创建Pod,Controller-manager 会通过API Server去找Scheduler为新创建的Pod选择最适合的Node 节点。比如运行这个Pod需要2C4G 的资源,Scheduler会通过预算策略在所有Node节点中挑选最优的。Node 节点中还剩多少资源是通过汇报给API Server 存储在etcd 里,API Server 会调用一个方法找到etcd 里所有Node节点的剩余资源,再对比Pod 所需要的资源,在所有Node 节点中查找哪些Node节点符合要求。
- 如果都符合,预算策略就交给优选策略处理,优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node 节点,并把Pod调度到这个Node节点上运行。
- controller manager会通过API Server通知kubelet去创建pod,然后通过kube-proxy中的service对外提供服务接口。(node组件)
④etcd(存储中心)
- 分布式键值存储系统(特性:服务自动发现)。用于保存集群状态数据,比如Pod、Service等对象信息
- k8s中仅API Server 才具备读写权限,其他组件必须通过API Server 的接口才能读写数据
PS:etcd V2版本:数据保存在内存中
v3版本:引入本地volume卷的持久化(可根据磁盘进行恢复),服务发现,分布式(方便扩容,缩容)
etcd是一种定时全量备份+持续增量备份的持久化方式,最后存储在磁盘中
但kubernetes 1.11版本前不支持v3,我用的事K8S 1.15
ETCD一般会做为3副本机制(奇数方式),分布在三台master上(也有的公司单独用服务器部署ETCD )
master:奇数的方式部署(多节点的时候)
⑤AUTH :认证模块
K8S 内部支持使用RBAC认证的方式进行认证
⑥cloud-controller-manager
- 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接集群到云提供商的应用编程接口中, 并把和该云平台交互的组件与只和您的集群交互的组件分离开。
- cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes,或者在本地计算机中运行学习环境, 所部署的环境中不需要云控制器管理器。
- 与 kube-controller-manager 类似,cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中,供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
**下面的控制器都包含对云平台驱动的依赖:**
– ● 节点控制器(Node Controller): 用于在节点终止响应后检查云提供商以确定节点是否已被删除
– ● 路由控制器(Route Controller): 用于在底层云基础架构中设置路由
– ● 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器
6.1.2 node组件
①kubelet
- kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如
创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等
工作。kubelet将每个Pod转换成一组容器
kubelet —》先和docker引擎进行交互—》docker容器(一组容器跑在Pod中)
②kube-proxy(四层)
- 在Node节点上
实现Pod网络代理,维护网络规则、pod之间通信和四层负载均衡工作
。默认会写入规则至iptables ,目前支持IPVS、同时还支持namespaces
对于七层的负载,k8s官方提供了一种解决方案;ingress-nginx
③docker或rocket
容器引擎,运行容器
6.1.3 整体流程
①使用kubectl命令的时候会先进行验证权限(AUTH)
②通过API-server 对容器云的资源进行操作
6.1.3.1 K8S 创建Pod 流程,相对详细版
kubectl 创建一个Pod(在提交时,转化为json格式)
1、首先经过auth认证(鉴权),然后传递给api-server进行处理
2、api-server 将请求信息提交给etcd
3、scheduler和controller-manager 会watch(监听) api-server ,监听请求
4、在scheduler 和controller-manager监听到请求后,scheduler 会提交给api-server一个list清单——》包含的是获取node节点信息
5、此时api-server就会向etcd获取后端node节点信息,获取到后,被scheduler watch到,然后进行预选优选进行打分,最后将结果给与
api-server
6、此时api-server也会被controller-manager watch(监听) controller-manager会根据请求创建Pod的配置信息(需求什么控制器)将
控制器资源给与api-server
7、此时api-server 会提交list清单给与对应节点的kubelet(代理)
8、kubelet代理通过K8S与容器的接口(例如containerd)进行交互,假设是docker容器,那么此时kubelet就会通过dockershim 以及runc
接口与docker的守护进程docker-server进行交互,来创建对应的容器,再生成对应的Pod
9、kubelet 同时会借助于metrics server 收集本节点的所有状态信息,然后再提交给api-server
10、最后api-server会提交list清单给与etcd来存储(最后api-server会将数据维护在etcd中)
简单版:
1、首先kubectl 转化为json后,向api-server 提交创建Pod请求
2、api-server将请求信息记录在etcd中
3、scheduler 监听api-server处理的请求,然后向api-server申请后端节点信息
4、api-server 从etcd中获取后端节点信息后,给与scheduler
5、scheduler 进行预选优选、打分,然后提交结果给api-server
6、controller-manager 监听api-server处理的请求信息,并将所需的控制器资源给与api-server
7、api-server 对接node节点的kubelet
8、kubelet调用资源创建pod,并将统计信息返回给api-server
9、api-server将信息记录在etcd中 以上结束
自己理解版本:
Kubectl相当于一个命令行,从这里创建一个pod,在提交的时候,转换为
json格式
,首先经过authentication认证(鉴权),然后传递给api-server,监听请求,然后api-server将请求的信息提交给数据库etcd,进行实时同步更新存储 Scheduler和controller-manager两个组件用来监听请求;scheduler里面有一个预选优选规则进行打分选举node节点
【node是一个存储空间,然后scheduler会根据算法去算空间大小,把空间大的,给api-server;api-server同时将这个信息存储到etcd里面】;controller-manager则是根据请求创建pod的配置信息将控制器资源给api-server,然后再放到etcd里面接着,kubelet与api-server直接对接,并根据刚刚etcd下面记载的分配的所有规则,去生成对应的pod;kubelet同时会借助于metrics server收集本节点的所有的信息状态,在提交给api-server并存储到etcd中
6.1.3.2 k8s 的pod删除的流程是什么?
命令行过来之后,通过json模式进来,然后
api把删除记录放到etcd里面
,然后是没有调度器的,然后controller-manager需要去回收指令,给与api
,然后由api去给kubelet回收指令,把主控制器进行回收,然后把pod删除,然后给kube-proxy返回给api,再由api记录到etcd里面,最终删除成功。
七、Kubernetes核心概念
Kubernetes包含多种类型的资源对象: Pod、 Label、 Service、 Replication Controller
等。
所有的资源对象都可以通过Kubernetes 提供的kubectl 工具进行增、删、改、查等操作,并将其保存在etcd 中持久化存储。
Kubernets其实是一个高度自动化的资源控制系统
,通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。
7.1 Pod
Pod是Kubernetes 创建或部署的最小/最简单的基本单位
,一个Pod代表集群上正在运行的一个进程。
可以把Pod理解成豌豆荚,而同一Pod内的每个容器是一颗颗豌豆。
一个Pod 由一个或多个容器组成
,Pod 中容器共享网络、存储和计算资源,在同一台Docker 主机上运行。
一个Pod里可以运行多个容器,又叫边车模式(SideCara) 模式
。而在生产环境中一 般都是单个容器或者具有强关联互补的多个容器组成一 个Pod。
同一个Pod 之间的容器可以通过localhost 互相访问,并且可以挂载Pod 内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问,也不能挂载其他Pod的数据卷。
Pod控制器
Pod控制器是Pod启动的一种模版,用来保证在K8S里启动的Pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等)
K8s内提供了众多的Pod控制器,常用的有以下几种:
(1)Deployment:无状态应用部署。Deployment 的作用是管理和控制Pod和ReplicaSet, 管控它们运行在用户期望的状态中。
(2)Replicaset: 确保预期的Pod 副本数量。Replicaset 的作用就是管理和控制Pod, 管控他们好好干活。但是,ReplicaSet 受控于Deployment。
可以理解成Deployment 就是总包工头,主要负责监督底下的工人Pod 干活,确保每时每刻有用户要求数量的Pod在工作。如果一旦发现某个工人Pod 不行了,就赶紧新拉一个Pod 过来替换它。而ReplicaSet 就是总包工头手下的小包工头。
从K8S使用者角度来看,用户会直接操作Deployment 部署服务,而当Deployment 被部署的时候,K8S 会自动生成要求的ReplicaSet和Pod
。用户只需要关心Deployment 而不操心ReplicaSet。
资源对象Replication Controller 是ReplicaSet 的前身,官方推荐用Deployment 取代Replication Controller 来部署服务。
(3)Daemonset: 确保所有节点运行同一类Pod,保证每 个节点上都有一个此类Pod运行,通常用于实现系统级后台任务。
(4)Statefulset: 有状态应用部署
(5)Job:一次性任务。 根据用户的设置,Job管理的Pod把任务成功完成就自动退出了。
(6)Cronjob: 周期性计划性任务
7.2 Label
- 标签,是K8S特色的管理方式,便于分类管理资源对象。
- Label可以附加到各种资源对象.上,例如Node、Pod、Service、 RC等,用于关联对象、查询和筛选。
- 一个Label 是一个key-value 的键值对,其中key 与value 由用户自己指定。
- 一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除。
- 可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多维度的资源分组管理功能。
- 与Label 类似的,还有Annotation (注释)
- 区别在于有效的标签值必须为63个字符或更少,并且必须为空或以字母数字字符( [a-z0-9A-Z])开头和结尾,中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制。
Label选择器(Label selector )
-
给某个资源对象定义一个Label,就相当于给它打了一个标签;随后可以通过标签选择器( Label selector) 查询和筛选拥有某些Label的资源对象。
-
标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。
7.3 Service
在K8s的集群里,虽然每个Pod会被分配一个单独的IP地址,但由于Pod是有生命周期的(它们可以被创建,而且销毁之后不会再启动),随时可能会因为业务的变更,导致这个IP地址也会随着Pod 的销毁而消失。
Service就是用来解决这个问题的核心概念。
K8S中的Service并不是我们常说的“服务"的含义,而更像是网关层,可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
Service作用于哪些Pod是通过标签选择器来定义的。
在K8S集群中,service 可以看作一组提供相同服务的Pod的对外访问接口。
客户端需要访问的服务就是service对象。每个service都有一个固定的虛拟ip
(这个ip也被称为Cluster IP) ,自动并且动态地绑定后端的Pod,
所有的网络请求直接访问Service 的虚拟ip,service会自动向后端做转发。
Service除了提供稳定的对外访问方式之外,还能起到负载均衡(Load Balance)
的功能,自动把请求流量分布到后端所有的服务.上,Service可以做到对客户
透明地进行水平扩展(scale)。
而实现service 这一功能的关键, 就是kube-proxy。
kube-proxy 运行在每个节点上,监听API Server 中服务对象的变化,
可通过以下三种流量调度模式:
userspace (废弃)、
iptables ( 濒临废弃)、
ipvs (推荐,性能最好)来实现网络的转发。
Service 是K8S服务的核心,屏蔽了服务细节,统一对外暴露服务接口
,真正做到了“微服务”。比如我们的一个服务A,部署了3个副本,也就是3个Pod;
对于用户来说,只需要关注一个Service 的入口就可以,而不需要操心究竞应该请求哪一个Pod。
优势非常明显: 一方 面外部用户不需要感知因为Pod. 上服务 的意外崩溃、K8S重新拉起Pod 而造成的IP变更,外部用户也不需要感知因升级、变更服务带来的Pod替换而造成的IP变化。
7.4 Ingress
Service主要负责K8S集群内部的网络拓扑,那么集群外部怎么访问集群内部呢?这个时候就需要Ingress 了。Ingress 是整个K8S集群的接入层,负责集群内外通讯。
Ingress是K8S 集群里工作在oSI网络参考模型下,第7层的应用,对外暴露的接口,典型的访问方式是http/https.
Service只能进行第四层的流量调度,表现形式是iptport。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
比如:客户端请求http://www. kgc。com:port —> Ingress —> Service —> Pod
7.5 Name
- 由于K8S内部,使用“资源”来定义每一种逻辑概念(功能),所以每种“资源”,都应该有自己的“名称”。
- “资源”有api 版本(apiversion) 、类别(kind) 、元数据(metadata) 、定义清单(spec) 、状态(status) 等配置信息。
- “名称”通常定义在“资源”的“元数据”信息里。在同一个namespace 空间中必须是唯一的。
7.6 Namespace
-
随着项目增多、人员增加、集群规模的扩大,需要一.种能够逻辑.上隔离K8S内各种“资源”的方法,这就是Namespace 。
-
Namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群组而诞生的。
-
不同Namespace 内的“资源”名称可以相同,相同Namespace 内的同种“资源”,“名称”不能相同。
-
合理的使用K8S的Namespace,可以使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览。
K8S里默认存在的Namespace 有: default、kube-system、kube-public等。
查询K8S里特定“资源”要带上相应的Namespace
总结
kubernetes的本质是 一组服务器集群,它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。目的是 实现资源管理的自动化
,主要提供了如下的主要功能:
自我修复:一旦某一个容器崩溃,能够在1秒中左右迅速启动新的容器
弹性伸缩:可以根据需要,自动对集群中正在运行的容器数量进行调整
服务发现:服务可以通过自动发现的形式找到它所依赖的服务
负载均衡:如果一个服务起动了多个容器,能够自动实现请求的负载均衡
版本回退:如果发现新发布的程序版本有问题,可以立即回退到原来的版本
存储编排:可以根据容器自身的需求自动创建存储卷
Kubernetes核心组件
Kubernetes Master是集群的主要控制单元,用于管理其工作负载并指导整个系统的通信。Kubernetes控制平面由各自的进程组成,每个组件都可以在单个主节点上运行,也可以在支持high-availability clusters的多个主节点上运行。
组件名称 | 作用 |
---|---|
etcd | 保存整个集群的状态 |
apiserver | 提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制 |
controller manager | 负责维护集群的状态,比如故障检测、自动扩展、滚动更新等 |
scheduler | 负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上 |
kubelet | 负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理 |
Container runtime | 负责镜像管理以及Pod和容器的真正运行(CRI) |
kube-proxy | 负责为Service提供cluster内部的服务发现和负载均衡 |