容器集群管理系统Kubernetes
容器集群管理系统Kubernetes是管理容器的编排工具,可以快速的配置。
目录
一、Kubernetes概述
二、Kubernetes作用
三、Kubernetes的特性
四、Kubernetes架构
五、Kubernetes工作流程
六、kubernetes集群架构与组件
七、Kubernetes核心概念
八、总结
一、Kubernetes概述
1.Kubernetes简介
Kubernetes 是的缩写为:K8s这个缩写是因为 k 和 s 之间有八个字符的关系。
Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。 Kubernetes 的服务、支持和工具广泛可用。
2.k8s的作用
用于自动部署、扩展和管理“容器化(containerized) 应用程序"的开源系统
。
可以理解成K8S是负责自动化运维管理多个容器化程序(比如Docker)的集群,是一个生态极其丰富的容器编排框架工具
。
3.k8s的背景
-
-
K8S由google的Borg系统(博格系统,google内部使用的大规模容器编排工具)作为原型,后经Go语言延用Borg的思路重写并捐献给CNCF基金会开源。
-
Kubernetes 这个名字源于希腊语,意为“舵手”或“飞行员”。
-
二、Kubernetes功能
1.Kubernetes功能
容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 来解决这些问题的方法! Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
1 2 3 4 5 6 7 8 9 | K8S是Google开源的容器集群管理系统,在Docker等容器技术的基础上, 为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能, 提高了大规模容器集群管理的便捷性。 其主要功能如下: 1.使用 Docker 等容器技术对应用程序包装(package)、实例化(instantiate)、运行(run)。 2.以集群的方式运行、管理跨机器的容器。 3.解决 Docker 跨机器容器之间的通讯问题。 4.K8S 的自我修复机制使得容器集群总是运行在用户期望的状态。 |
三、Kubernetes的特性
1.Kubernetes的特性
1.弹性伸缩:使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例,保证应用业务高峰并发时的高可用性;业务低峰时回收资源,以最小成本运行服务。
1 2 | 伸缩——》扩容和缩容(节点 应用类型nginx) 弹性——》人为只要指定规则,满足条件时,就会自动触发 扩容或缩容的操作 |
2.自我修复:在节点故障时重新启动失败的容器,替换和重新部署,保证预期的副本数量;
杀死健康检查失败的容器,并且在未准备好之前不会处理客户端请求,确保线上服务不中断。
3.服务发现和负载均衡:K8S为多个容器提供一个统一访问入口(内部IP地址和一个DNS名称),
并且负载均衡关联的所有容器,使得用户无需考虑容器IP问题。
4.自动发布(默认滚动发布模式)和回滚:K8S采用滚动策略更新应用,一个更新一个Pod,而不是同时删除所有的Pod,如果更新过程中出现问题,将回滚更改,确保升级不收影响业务。
5.集中化配置管理和密钥管理:管理机密数据和应用程序配置,而不需要把敏感数据暴露在镜像里,提高敏感数据安全性,并可以将一些常用的配置存储在K8S中,方便应用程序使用。
6.存储编排:支持外挂存储并对外挂存储资源进行编排,挂载外部存储系统,无论是来自本地存储,公有云(如:AWS),还是网络存储(如:NFS、Glusterfs、Ceph)都作为集群资源的一部分使用,极大提高存储使用灵活性。
7.任务批量处理运行:提供一次性任务,定时任务,满足批量数据处理和分析的场景。
2.Kubernetes 特点
- 可移植: 支持公有云,私有云,混合云,多重云(multi-cloud)
- 可扩展: 模块化, 插件化, 可挂载, 可组合
- 自动化: 自动部署,自动重启,自动复制,自动伸缩/扩展
- 快速部署应用,快速扩展应用
- 无缝对接新的应用功能
- 节省资源,优化硬件资源的使用
3.K8s解决了裸跑docker问题
- 单机使用,无法有效集群
- 随着容器数量的上升,管理成本攀升
- 没有有效的容灾、自愈机制
- 没有预设编排模板,无法实现快速、大规模容器调度
- 没有统一的配置管理中心工具
- 没有容器生命周期的管理工具
- 没有图形化运维管理工具
四、Kubernetes架构
1.Kubernetes架构
K8S 是属于主从设备模型(Master-Slave 架构),即有 Master 节点负责集群的调度、管理和运维,Slave 节点是集群中的运算工作负载节点。
在 K8S 中,主节点一般被称为 Master 节点,而从节点则被称为 Worker Node 节点,每个 Node 都会被 Master 分配一些工作负载。
Master 组件可以在群集中的任何计算机上运行,但建议 Master 节点占据一个独立的服务器。因为 Master 是整个集群的大脑,如果 Master 所在节点宕机或不可用,那么所有的控制命令都将失效。除了 Master,在 K8S 集群中的其他机器被称为 Worker Node 节点,当某个 Node 宕机时,其上的工作负载会被 Master 自动转移到其他节点上去。
五、Kubernetes工作流程
1 2 3 | 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集群架构与组件
1.kubernetes 组件
K8S是属于主从设备模型(Master-slave 架构),即有Master 节点负责集群的调度、管理和运维,Slave 节点是集群中的运算工作负载节点。
在K8S中,主节点一般被称为Master 节点,而从节点则被称为Worker Node节点,每个Node都会被Master分配一些工作负载。
Master组件可以在群集中的任何计算机上运行,但建议Master节点占据一个独立的服务器。因为Master是整个集群的大脑,如果Master所在节点宕机或不可用,那么所有的控制命令都将失效。除了Master, 在K8S集群中的其他机器被称为Worker Node节点,当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上去。
2.master组件
master:集群的控制平面,负责集群的决策 ( 管理 )
①kube-apiserver
Kubernetes API,集群的统一入口,各组件协调者,以**Restful API提供接口服务,所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。
1 2 | 用于暴露Kubernetes API,任何资源请求或调用操作都是通过kube-apiserver 提供的接口进行。以HTTP Restful API提供接口服务,<br>所有对象资源的增删改查和监听操作都交给API Server 处理后再提交给Etcd 存储(相当于分布式数据库,以键值对方式存储)。 可以理解成API Server 是K8S的请求入口服务。API server负责接收K8S所有请求(来自UI界面或者CLI 命令行工具),然后根据用户的具体请求,<br>去通知其他组件干活。可以说API server 是K8S集群架构的大脑。 |
②kube-controller-manager
运行管理控制器,是k8s集群中处理常规任务的后台线程,是k8s集群里所有资源对象的自动化控制中心。
在k8s集群中,一个资源对应一个控制器,而Controller manager 就是负责管理这些控制器的。
由一系列控制器组成,通过API Server监控整个集群的状态,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态.
③kube-scheduler
- 根据调度算法(
预选/优选的策略
)为新创建的Pod选择一个Node节点,可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上 - 可以理解成K8S所有Node 节点的调度器。当用户要部署服务时,scheduler 会根据调度算法选择最合适的Node 节点来部署Pod.
1 2 3 | API Server 接收到请求创建一批Pod,API Server 会让Controller-manager 按照所预设的模板去创建Pod,Controller-manager <br>会通过API Server去找Scheduler为新创建的Pod选择最适合的Node 节点。比如运行这个Pod需要2C4G 的资源,Scheduler会通过预算策略在所有Node节点中挑选最优的。<br>Node 节点中还剩多少资源是通过汇报给API Server 存储在etcd 里,API Server 会调用一个方法找到etcd 里所有Node节点的剩余资源,再对比Pod 所需要的资源,<br>在所有Node 节点中查找哪些Node节点符合要求。 如果都符合,预算策略就交给优选策略处理,优选策略再通过CPU的负载、内存的剩余量等因素选择最合适的Node 节点,并把Pod调度到这个Node节点上运行。 controller manager会通过API Server通知kubelet去创建pod,然后通过kube-proxy中的service对外提供服务接口。(node组件) |
④etcd(存储中心)
- 分布式键值存储系统(特性:服务自动发现)。用于保存集群状态数据,比如Pod、Service等对象信息
- k8s中仅API Server 才具备读写权限,其他组件必须通过API Server 的接口才能读写数据
1 2 3 4 5 6 | 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 将若干逻辑上独立的 控制回路组合到同一个可执行文件中,供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。
1 2 3 4 | **下面的控制器都包含对云平台驱动的依赖:** – ● 节点控制器(Node Controller): 用于在节点终止响应后检查云提供商以确定节点是否已被删除 – ● 路由控制器(Route Controller): 用于在底层云基础架构中设置路由 – ● 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器 |
3.node组件
①kubelet
- kubelet是Master在Node节点上的Agent,管理本机运行容器的生命周期,比如
创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等
工作。kubelet将每个Pod转换成一组容器
1 | kubelet —》先和docker引擎进行交互—》docker容器(一组容器跑在Pod中) |
②kube-proxy(四层)
- 在Node节点上
实现Pod网络代理,维护网络规则、pod之间通信和四层负载均衡工作
。默认会写入规则至iptables ,目前支持IPVS、同时还支持namespaces
对于七层的负载,k8s官方提供了一种解决方案;ingress-nginx
③docker或rocket
容器引擎,运行容器
4.K8S 创建Pod 流程,相对详细版
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | 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 2 3 4 5 6 7 8 9 10 11 12 13 14 | 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中) |
5.k8s 的pod删除的流程
1 | 命令行过来之后,通过json模式进来,然后api把删除记录放到etcd里面,然后是没有调度器的,然后controller-manager需要去回收指令,给与api,<br>然后由api去给kubelet回收指令,把主控制器进行回收,然后把pod删除,然后给kube-proxy返回给api,再由api记录到etcd里面,最终删除成功。 |
七、Kubernetes核心概念
1.Kubernetes包含多种类型的资源对象
Kubernetes包含多种类型的资源对象: Pod、 Label、 Service、 Replication Controller 等。
所有的资源对象都可以通过Kubernetes 提供的kubectl 工具进行增、删、改、查等操作,并将其保存在etcd 中持久化存储。
Kubernets其实是一个高度自动化的资源控制系统,通过跟踪对比etcd存储里保存的资源期望状态与当前环境中的实际资源状态的差异,来实现自动控制和自动纠错等高级功能。
2. Pod
(1)Pod简介
Pod是Kubernetes 创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。
可以把Pod理解成豌豆荚,而同一Pod内的每个容器是一颗颗豌豆。
一个Pod 由一个或多个容器组成,Pod 中容器共享网络、存储和计算资源,在同一台Docker 主机上运行。
一个Pod里可以运行多个容器,又叫边车模式(SideCara) 模式。而在生产环境中一 般都是单个容器或者具有强关联互补的多个容器组成一 个Pod。
同一个Pod 之间的容器可以通过localhost 互相访问,并且可以挂载Pod 内所有的数据卷;但是不同的Pod之间的容器不能用localhost访问,也不能挂载其他Pod的数据卷。
(2)Pod控制器
1 | Pod控制器是Pod启动的一种模版,用来保证在K8S里启动的Pod应始终按照用户的预期运行(副本数、生命周期、健康状态检查等) |
(3)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: 周期性计划性任务
(4)Deployment和ReplicaSet
3.Label
标签,是K8S特色的管理方式,便于分类管理资源对象。
Label可以附加到各种资源对象.上,例如Node、Pod、Service、 RC等,用于关联对象、查询和筛选。
一个Label 是一个key-value 的键值对,其中key 与value 由用户自己指定。
一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象中,也可以在对象创建后动态添加或者删除。
可以通过给指定的资源对象捆绑一个或多个不同的Label,来实现多维度的资源分组管理功能。
与Label 类似的,还有Annotation (注释)
区别在于有效的标签值必须为63个字符或更少,并且必须为空或以字母数字字符( [a-z0-9A-Z])开头和结尾,中间可以包含横杠(-)、下划线(_)、点(.)和字母或数字。注释值则没有字符长度限制。
(1)Label选择器(Label selector )
-
给某个资源对象定义一个Label,就相当于给它打了一个标签;随后可以通过标签选择器( Label selector) 查询和筛选拥有某些Label的资源对象。
-
标签选择器目前有两种:基于等值关系(等于、不等于)和基于集合关系(属于、不属于、存在)。
4.Service
在K8s的集群里,虽然每个Pod会被分配一个单独的IP地址,但由于Pod是有生命周期的(它们可以被创建,而且销毁之后不会再启动),随时可能会因为业务的变更,导致这个IP地址也会随着Pod 的销毁而消失。
Service就是用来解决这个问题的核心概念。
K8S中的Service并不是我们常说的“服务"的含义,而更像是网关层,可以看作一组提供相同服务的Pod的对外访问接口、流量均衡器。
(1)Service作用于哪些Pod是通过标签选择器来定义的
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | 在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变化。
5.Ingress
Service主要负责K8S集群内部的网络拓扑,那么集群外部怎么访问集群内部呢?这个时候就需要Ingress 了。Ingress 是整个K8S集群的接入层,负责集群内外通讯。
Ingress是K8S 集群里工作在oSI网络参考模型下,第7层的应用,对外暴露的接口,典型的访问方式是http/https.
Service只能进行第四层的流量调度,表现形式是iptport。 Ingress 则可以调度不同业务域、不同URL访问路径的业务流量。
比如:客户端请求http://www. kgc。com:port —> Ingress —> Service —> Pod
6.Name
由于K8S内部,使用“资源”来定义每一种逻辑概念(功能),所以每种“资源”,都应该有自己的“名称”。
“资源”有api 版本(apiversion) 、类别(kind) 、元数据(metadata) 、定义清单(spec) 、状态(status) 等配置信息。
“名称”通常定义在“资源”的“元数据”信息里。在同一个namespace 空间中必须是唯一的。
7.Namespace
随着项目增多、人员增加、集群规模的扩大,需要一.种能够逻辑.上隔离K8S内各种“资源”的方法,这就是Namespace 。
Namespace是为了把一个K8S集群划分为若干个资源不可共享的虚拟集群组而诞生的。
不同Namespace 内的“资源”名称可以相同,相同Namespace 内的同种“资源”,“名称”不能相同。
合理的使用K8S的Namespace,可以使得集群管理员能够更好的对交付到K8S里的服务进行分类管理和浏览。
1 2 | K8S里默认存在的Namespace 有: default 、kube-system、kube- public 等。 查询K8S里特定“资源”要带上相应的Namespace |
八、总结
kubernetes的本质是 一组服务器集群,它可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理。目的是 实现资源管理的自动化,
主要提供了如下的主要功能
1 2 3 4 5 6 | 自我修复:一旦某一个容器崩溃,能够在1秒中左右迅速启动新的容器 弹性伸缩:可以根据需要,自动对集群中正在运行的容器数量进行调整 服务发现:服务可以通过自动发现的形式找到它所依赖的服务 负载均衡:如果一个服务起动了多个容器,能够自动实现请求的负载均衡 版本回退:如果发现新发布的程序版本有问题,可以立即回退到原来的版本 存储编排:可以根据容器自身的需求自动创建存储卷 |
Kubernetes核心组件
Kubernetes Master是集群的主要控制单元,用于管理其工作负载并指导整个系统的通信。Kubernetes控制平面由各自的进程组成,每个组件都可以在单个主节点上运行,也可以在支持high-availability clusters的多个主节点上运行。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 地球OL攻略 —— 某应届生求职总结
· 提示词工程——AI应用必不可少的技术
· Open-Sora 2.0 重磅开源!
· 周边上新:园子的第一款马克杯温暖上架