K8S集群自动化运维方案.docx

上传人:牧羊曲112 文档编号:4885768 上传时间:2023-05-21 格式:DOCX 页数:14 大小:162.65KB
返回 下载 相关 举报
K8S集群自动化运维方案.docx_第1页
第1页 / 共14页
K8S集群自动化运维方案.docx_第2页
第2页 / 共14页
K8S集群自动化运维方案.docx_第3页
第3页 / 共14页
K8S集群自动化运维方案.docx_第4页
第4页 / 共14页
K8S集群自动化运维方案.docx_第5页
第5页 / 共14页
亲,该文档总共14页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《K8S集群自动化运维方案.docx》由会员分享,可在线阅读,更多相关《K8S集群自动化运维方案.docx(14页珍藏版)》请在三一办公上搜索。

1、K8S集群自动化运维方案目录一.K8S 前序知识3二项目景6三技术实现方案8四,总结14大规模Kubernetes集群主要体现在几十个Kubernetes集群,十万级别的KubernetesWorker节点。蚂蚁金服使用Operator的模式去运维Kubernetes集群,能便捷、自动化的 管理 Kubernetes 集群生命周期,做到Kubernetes as a Service。本文分享了自动化运维大规模Kubernetes集群的实践经历,比较适合Kubernetes爱好者, Kubernetes架构师,以及PE/SRE阅读。一, K8S前序知识1. Kubernetes架构介绍此章节简单

2、介绍了 Kubernetes集群的架构,主要是面向刚学习 Kubernetes的同学,对于 熟悉Kubernetes的同学,此章节可以跳过。如上图,一个Kubernete集群由Master节点和Worker节点组成。在一个高可用 Kubernetes集群下面,Master节点一般为3台,在它们上面需 要运行 Kubernetes Master 组件。Kubernetes Master 组件包括 etcd、Apsierver、Scheduler 和 Controller-Manager。每个Master组件一般都是3个实例,以保证它们的高可用。Master 节点使用Static Pod方式启动M

3、aster组件,即将每个组件的Pod描述文件放入Master节 点的指定目录,Kubelet会在启动时将它们读取,并以Static Pod方式启动。Kubernetes Worker节点为Kubernetes集群提供调度资源和应用运行环境,即所有的Pod (可以理解为应用的一个个最小化部署单元)都运行在 Worker节点上。一个 Worker节点将 Pod 运行上去需要一些 on-host 软件,包括:kubelet、Runtime Service ( docker、pouch等实现方案)、CNI插件等。2. Operator 介绍我们在这里将用很少的篇幅向刚学习 Kubernetes的同学介

4、绍一下Operator。如果期望获得 更详细的解读,请参考coreos上关于Operator的介绍。一个Operator实际上是为了解决某个复杂应用在 Kubernetes的自动化部署、恢复。有了 Operator,用户只需要向 Kubernetes Apiserver 提交一个 CRD Resource( yaml 或者 JSON, 一个CRD Resource其实就是对应一个应用实例,CRD Resource用于描述这个应用实例的 配置),Operator就会根据用户的需求去完成这个应用实例的初始化,在应用某个模块发生 故障时,Operator也会做出自动恢复功能。Operator是用代码

5、运维应用最好的实践之一。Kubernetesetcd CRD etcd CRDwatchname: x-cicdspec:3name: y-eicd;x-etedupseriet cd-operator比如我们有一个etcd-operator ,我们只需要用户根据需求向 Kubernetes Apiserer提交如 下的CRD Resource , etcd-operator就能初始化完成一个etcd集群:apiVersion: kind: EtcdClustermetadata:name: xxx-etcd-clusterspec:size: 5其中,上面的Spec.Size=5代表了我们需

6、要一个由5个etcd节点组成的etcd集群。etcd-operator会根据上面的配置,初始化完成etcd集群。相应的,如果你又需要另一个 3 节点的etcd集群,你只需要提交新的一个Spec.Size=3的CRD Resource即可。二、项目背景在蚂蚁金服,我们面临着需要运维几十个Kubernetes集群,以及十万级别以上的Kubernetes Worker节点的难题。我们将运维Kubernetes的工作拆分两部分:运维 Kubernetes 集群的 Master 组件(etcd、Apiserver、controller-manager、scheduler等);运维 Kubernetes

7、Worker 节点。我们总结了这两部分运维的难点:难点 1 :运维 Kubernetes 集群 Master 角色.如何快速新建、下线一个Kubernetes集群(初始化、删除 Master角色)?由于蚂蚁业务 的快速增长,我们随时面临着需要在新机房新建、下线一个Kubernetes集群;CI和测试也有快速新建、删除一个Kubernetes集群的需求。如何管理几十个Kubernetes集群Master组件版本。比如我们需要升级某几个 Kubernetes 集群的 Apiserver、Scheduler 等组件。如何自动化处理几十个Kubernetes集群Master组件发生的故障?如何能获取几

8、十个Kubernetes集群Master组件的统一视图?我们希望有一个统一的接口, 一下就能获取每个Kubernetes集群Master角色的版本、状态等信息。难点2 :运维Kubernetes Worker节点如何快速上线、下线Kubernetes Worker节点?上线时,我们需要保证Kubernetes Worker 节点所需要的on-host软件版本、配置正确。如何升级十万级别的Kubernetes Worker节点上的on-host软件?如我们需要将所有 Work 节点的docker、cni版本升级到某个版本。如何优雅的执行灰度发布Kubernetes Worker节点上的软件包?在

9、on-host软件新版本上 线前,我们需要对它做小范围的灰度发布,即挑选N台Worker节点发布新版本软件包,执行验证,最后根据验证结果决定是否全规模的发布新版本,或者回滚这个灰度发布。如何自动化处理十万级别的Kubernetes Worker节点可能出现的on-host软件故障?比如 要是dockerkubelet发生panic,我们是否能自动化得处理?三、技术实现方案在实现方案的选择上,我们使用了 Kube-on-Kube-Operator和Node-Operator组合的方 式来解决上述的难题:首先,我们需要借助工具,使用Kubernetes官方提供的方案(Static Pod方式)部署

10、“Kubernetes元集群(后面简称元集群)到元集群”的Master节点上。然后,我们将Kube-on-Kube-Operator部署到Kubernetes元集群。我们将一个 Kubernetes集群所需的一系列Master组件当成一个复杂的应用。当我们需要一个“Kubernetes业务集群(后面简称业务集群),我们只需要向元集群 Apiserver提交用于 描述“Kubernetes业务集群的Cluster CRD Resource (下文会介绍我们如何设计 CRD 结构),Kube-on-Kube-Operator 就为我们准备好了一可以工作的“Kubernetes 业务 集群(业务集群

11、”Master组件都已经Ready,需要扩容Worker节点)。勺詹M吧之后我们在Kubernetes 业务集群上,部署上 Node-Operator o Node-Operator负责 Worker节点的生命周期。当我们需要扩容一个 Worker节点,我们只需要提交描述 Worker 节点的元数据(IP、Hostname、机器运维登录方式等)的 Machine CRD Resource (下文 会介绍我们如何设计CRD结构),Node-Operator就会将Worker节点初始化完成,并成 功加入到 Kubernetes业务集群中。业井堡机1节点-,kubelet pouch元集群曲新篇奇i

12、蜡心节食 (,元攻群Wcrhtr节点jTf.JSHTMa&tar 节由些剃岫Mar节点 ;jT. St Worker 节点 Jkube-on-kube-opefatornode-operatornode-operatornode-operatoretodpiswer.etc.etcd,apisever,etc.kubeletpouchku be let. pouchkublpr.pochj-ajrn 1勺元集群只用于管理所有业务集群”所需的 Master组件。业务集群”是真正提供给业务方运行Pod的Kubernetes集群。也就说,在蚂蚁金服我们只有一个元集群,在这个元集群”中,我们使用Kub

13、e-on-Kube-Operator自动化管理了蚂蚁金服所有的Kubernetes业务集群的Master组件。当然,元集群”也会部署 Node-Operator ,用于元集群”Worker节点的上下线,元集群”的Worker节点也是各个业务集群”的 Master节点。与1. Kube-on-Kube-OperatorKube-on-Kube-Operator 用于 Watch Cluster CRD Resource 的变更,将Cluster所描述表示的Kubernetes业务集群的所有Master组件达到最终状态。如下图,是元集群”和它所管理的两个Kubernetes业务集群”的最终状态:C

14、luster CRD的定义包含如下一些信息:业务集群部署模式:分为标准生产和最小化。标准生产提供Master组件都是3个副本的部署,最小化则都是1个副本的部署;业务集群Master节点NodeSelector ,即表示如何在元集群内如何选择业务集群 Master节 点. / I业务集群各Master组件版本、自定义参数等;业务集群所使用的etcd启动配置,主要涉及etcd data volume的设置,有ClaimTemplate 和VolumeSource两种模式:使用ClaimTemplate模式,即使PVC来初始化etcd volume ;使用VolumeSource模式,即使用Volu

15、meSource所表示的volume来挂载etcd volume ;业务集群Master组件证书过期时间:Master组件所使用kubeconfig中的证书都有过期时 间以保证安全性,而Kube-on-Kube-Operator会在证书过期时自动完成滚动证书、Master 组件重新加载证书等操作。业务集群额外用户kubeconfig :即为额外用户”提供的用户名和组名,签出证书,并生成 kubeconfig保存在元集群Secret中供读取。业务集群状态:这部分信息不需要用户提交,而是由 Kube-on-Kube-Operator自动生成, 用户反馈这个业务集群的状态,参考 Pod.Status

16、。一个业务集群的Master组件部署实际是元集群中的一系列Resource组成,即包括 Deployment s Secret s Pod、PVC等组合使用。各 Master组件所需要的部署 Resource如 下: Apiserver : 个Deployment即可,因为Apiserver是无状态应用,副本数和 Cluster CRD 描述的一致即可。除此之外,需要为 Apiserver创建两个Service :a. 向同个业务集群的其它Master组件提供服务的Service 建议使用元集群内的 Headless Service。b. 向Kubelet、外部组件提供服务的Service建议

17、使用机房DNS RR Service (需要自己实现 Service Controller)。 etcd :每个etcd实例(标准化部署是3个实例,最小化是1个实例)都建议单独使用Pod + PV + PVC + Headless Service 部署。每个 etcd 实例的 peer id 为对应的 Headless Service 域名。当某个etcd实例发生故障时,需要手动删除掉故障对应实例的Pod, Kube-on-Kube-Operator watch 到 etcd Pod 的减少,会重新建立 Pod,并执彳亍 Remove old member (被删除的Pod ), Add ne

18、w member (新建的Pod )操作,但是peer id还是 保持一致的。 Controller-Manager :个 Deployment 即可,因为 Controller-Manager 是无状态应用。 副本数和Cluster CRD描述的一致即可。 Scheduler :个 Deployment 即可,因为 Scheduler 是无状态应用。副本数和 Cluster CRD 描述的一致即可。Kube-on-Kube-Operator除了能够部署上述的Master组件之外,还能维护任何扩展组件, 如kube-proxy、kube-dns等。只需要用户提供扩展组件部署模板和扩展插件版本,

19、 Kube-on-Kube-Operator能渲染出部署Resource,并保持这些部署 Resource到最终态。 由于篇幅原因,我们这里不再赘述。2. Node-Operator6与袖学吧Node-Operator 用于 Watch Machine CRD Resource 的变更,将Machine所描述表示 的Worker节点上的on-host软件(docker、kubelet、cni )达到最终态,最终能让Machine 所对应的Node在Kubernetes集群中达到Ready”状态。架构图如下:Machine CRD的定义包含如下一些信息:机器元数据:IP、Hostname、IDC

20、等;机器运维SSH登录方式和登录秘钥:如最常见的SSH Key如果Machine是阿里云的ECS , 那么登录方式和登录秘钥是阿里云提供的 SSH接口和对应的鉴权信息等;各个on-host软件版本和自定义参数; Machine状态:这部分信息不需要用户提交,而是由Node-Operator生成,表示这个机器的当前状态,参考Pod.Status。Node-Operator用 Watch Machine对应Node的状态,当发生一些能处理的 Condition (比如kubelet运行中进程消失了)时,Node-Operator会做出恢复处理;Node-Operator 会 Watch Clust

21、erPackageVersion CRD 的变更,这个 CRD 表示整个 Kubernetes 集群 kubelet、docker 等组件的默认版本,Node-Operator 会根据 ClusterPackageVersion 描 述的信息,控制各个节点的kubelet、docker等组件的版本;Node-Operator还支持控制 某些组件灰度发布到某些节点中,用户只要提交描述这个灰度发布的CRD到Apiserver,Node-Operator会有序的执行灰度发布,并将发布状态反馈到CRD中。由于篇幅原因,我们不再赘述。四、总结在运维大规模Kubernetes集群的实践中,我们摈弃了传统的模式,使用了 Operator模式 和面向Apiserver编程。Kubernetes集群的上下线、升级实现了 Kubernetes as a Service,就像向云厂商买一个服务一样简单。而 Worker节点的运维,使用Operator模 式能够让我们统一管理元数据,自动化初始化、恢复 Worker节点所需组件。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号