Karmada,你了解多少?【与云原生的故事】
本文主要内容如下:
- 概述
- Karmada主要功能
- Karmada技术架构
- Karmada优势
- Karmada分发流程
- Karmada应用场景
- 未来展望
1、概述
1.1、背景
随着企业业务的快速发展,多云也逐步成为数据中心建设的基础架构,多区域容灾与多活、大规模多集群管理、跨云弹性与迁移等场景推动云原生多云相关技术的快速发展。 然而,在实际的生产落地过程中,云原生的多云仍面临如下挑战:
- 集群繁多的重复劳动:运维工程师需要应对繁琐的集群配置、不同云厂商集群间的管理差异以及碎片化的API访问入口等问题;
- 业务过度分散的维护难题:应用在各集群的差异化配置繁琐;业务跨云访问以及集群间的应用同步难以管理;
- 集群的边界限制:应用的可用性受限于集群;资源调度、弹性伸缩受限于集群;
- 厂商绑定:业务部署的黏性问题,缺少自动化故障迁移;缺少中立的开源多云容器编排项目。
1.2、Karmada产生
为了解决云原生多云存在的问题,Karmada结合华为云多云容器平台MCP以及Kubernetes Federation核心实践,并融入了众多新技术:包括Kubernetes原生API支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等,并且提供原生Kubernetes平滑演进路径,让基于Karmada的多云方案无缝融入云原生技术生态,为企业提供从单集群到多云架构的平滑演进方案。
2、Karmada主要功能
Karmada 整体的功能视图如下图所示:
Karmada 相当契合我们工作中的实现目标要求,具有整体的集群生命周期管理、集群注册,包括多集群的伸缩、调度、统一的 API、底层的标准 API 支持,并且 CNI、CSI 在其整体的功能视图中,对 CI/CD 有整体上的规划与考虑,所以工行最终决定投入到该项目中,与华为在内的一系列伙伴共建该项目并回馈到社区中。
3、Karmada技术架构
Karmada 控制平面由以下几个组件组成:
- API 服务器(Karmada API Server)
- 控制管理器(Karmada Controller Manager )
- 调度器 (Karmada Scheduler)
Karmada通过独立的API 服务器(Karmada API Server)提供与其他组件进行通信的 REST 接口,包含Kubernetes原生API及Karmada扩展API,而Karmada 控制管理器根据用户创建的 API 对象执行操作, Karmada 调度器则实现应用在多集群中的调度。
Karmada 控制器运行各种控制器,控制器监视Karmada 的对象,然后与底层集群的 API 服务器通信,对Kubernetes资源进行全生命周期管理。
集群控制器:聚焦集群管理,将 Kubernetes 集群附加到 Karmada,通过创建集群对象管理集群的生命周期。
策略控制器:实现PropagationPolicy对象的生命周期。根据 PropagationPolicy中的resourceSelector 匹配对应Kubernetes资源对象,并为创建ResourceBinding以进行应用多集群调度。
绑定控制器:实现 ResourceBinding 对象的生命周期,根据调度器的角度结果,为每个调度到目标集群的对应资源创建Work 对象;
执行控制器:负责work对象与成员集群中实际资源对象的状态同步。
4、Karmada技术优势
Karmada 的优势分为以下四点。
资源调度
- 自定义跨集群调度策略。
- 对上层应用透明。
- 支持两种资源绑定调度。
容灾
- 动态 binding 调整。
- 按照集群标签或故障域自动分发资源对象。
集群管理
- 支持集群注册。
- 全生命周期管理。
- 统一标准的 API。
资源管理
- 支持 k8s 原生对象。
- works 支持子集群资源部署状态获取。
- 资源对象分发既支持 pull 也支持 push 方式。
5、Karmada分发流程
5.1、资源分发流程
Karmada Resources 分发流程示意图如下图所示:
Karmada Resources 分发流程如下:
- 第一步,集群注册到 Karmada。
- 第二步,定义 Resource Template。
- 第三步,制定分发策略 Propagation Policy。
- 第四步,制定 Override 策略。
- 第五步,看 Karmada 干活。
5.2、Propagation 机制
Propagation 机制分发如下:
Propagation Policy 信息配置
- 集群亲和性。
- 集群容忍。
- 按集群标签、故障域分发。
5.3、Work 机制
具体的 Work 分发机制如下图所示:
6、Karmada应用场景
6.1、通过Karmada实现分布式云容器应用管理入口
Karmada是华为云今年开源的云原生多云容器编排项目,沉淀了众多企业在多云管理领域的丰富经验,可构建无限可扩展的容器资源池,让开发者像使用单个K8s集群一样使用多云。目前Karmada已正式捐赠给云原生计算基金会CNCF,也是CNCF首个多云/多集群容器编排项目。Karmada 项目的加入,将CNCF 的云原生版图进一步扩展至分布式云领域。
自该项目发布以来,社区中的很多伙伴也共同参与项目开发,如今已经运行在很多生产环境当中。工商银行作为发起单位之一目前已经依托Karmada对其容器云管平台进行了全面升级,并且深度参与到Karmada的设计与研发中,在实践过程中也总结了Karmada的优势,主要有资源调度、容灾、集群管理、资源管理四大类,而以下几点在真实落地过程中会显得尤其突出:
支持多种资源绑定调度,保证了业务节点所需的K8s资源能够同时调度,大大提升了资源发放的实时性
支持K8s原生对象,保证了大量 K8s 外部客户端几乎无需改造
支持Pull和Push模式分发,适配多种场景,尤其在大规模集群数量场景下,使用pull模式减轻 Karmada 控制平面的性能压力。
6.2、Karmada | 工商银行多k8s集群管理及容灾实践
在容器云方面,工行的金融云成效也是非常大的,首先体现在它的入云规模大,截至目前应用平台云容器规模超20万,业务容器占到55,000个左右,整体的一些核心业务都已入容器云内部。除了在同业的入云规模最大之外,我们的业务场景涉及非常广泛,一些核心的应用,核心的银行业务系统,包括个人金融体系的账户,快捷支付、线上渠道、纪念币预约等,这些核心的业务应用也已容器化部署;另外,我们的一些核心技术支撑类应用如MySQL,还有一些中间件以及微服务框架,这一类核心支撑类应用也已入云;此外,一些新技术领域,包括物联网、人工智能、大数据等。
当越来越多的核心业务应用入云之后,对我们最大的挑战是容灾以及高可用,在这方面我们也做了很多实践:
1)云平台支持多层次故障保护机制,确保同一业务的不同实例会均衡分发到两地三中心的不同资源域,确保单个存储、单个集群甚至单个数据中心发生故障时,不会影响业务的整体可用性。
2)在故障情况下,云平台通过容器重启及自动漂移,实现故障的自动恢复。
在整体容器云实践下,我们也遇到了一些问题,其中比较突出的是 pass层容器层的多集群的现状。现在工行内部整体的k8s总数,k8s集群的总数已近百个,主要的原因有4个:
1)集群种类多:刚刚也说了我们的业务场景非常的广泛,比如GPU要有不同支持GPU的设备,一些中间件,数据库它对底层的网络容器存储的需求是不同的,那势必会产生不同的解决方案,因此我们需要为不同的业务场景定制不同集群。
2)受到k8s本身性能的限制,包括scheduler、 etcd 、API server等一些性能瓶颈,每一个集群也有它数量的上限。
3)业务扩展非常快。
4)故障域分区多,我们两地三中心的架构至少有三个DC,每个DC内部还有不同的网络区域,通过防火墙进行隔离, 这样的倍乘关系,中间就会产生很多集群故障域的分布。
基于以上4点,针对当前的现状,我们现有的解决方案还是依靠容器云的云管平台,通过云管平台管理这些多k8s集群,另外上层的业务应用需要自主选择它的集群,包括它需要的偏好、网络、区域等,去选择它具体的某一个k8s集群。在选择到k8s集群之后,我们内部是通过故障率进行自动打散的调度。
但现有的解决方案对上层应用还是暴露出非常多的问题:
1)对上层应用来说,它可能上了容器云比较关心的一个部分,就是我们具有在业务峰值的过程中自动伸缩的能力,但自动伸缩现在只是在集群内部,没有整体的跨集群自动伸缩的能力。
2)无跨集群自动调度能力,包括调度的能力可能都是在集群内部,应用需要自主的选择具体的集群
3)集群对上层用户不透明
4)无跨集群故障自动迁移能力。我们还是主要依靠两地三中心架构上副本的冗余,那么在故障恢复的自动化恢复过程中,这一块的高可用能力是有缺失的。
业界多集群管理方案及选型
基于目前的现状,我们定下了一些目标,对业界的一些方案进行整体的技术选型,总共分为5个模块:
当时我们和华为交流到了多集群管理的一个现状以及痛点,包括对社区联邦类项目的讨论,我们双方也非常希望能够在这方面革新,下图为Karmada的功能视图:
从它整体功能视图及规划来看,和我们上文提到的目标非常契合,它有集群整体的生命周期管理、集群注册、多集群伸缩、多集群调度、整体统一的API、底层标准API支持,它都是CNI/CSI在它整体功能视图里,包括上层的应用、对Istio、Mash、CI/CD等都有整体规划上的考虑。因此基于整体思路,它的功能与我们非常契合,工行也决定投入到这个项目中来,跟华为和我们很多的项目伙伴共建Karmada项目,并把它回馈到我们社区整体。
7、未来展望
7.1、未来展望1-跨集群伸缩
跨集群伸缩现在也是在Karmada规划当中,现在我们可能还是需要解决一些问题:
- 考虑它跨集群伸缩和子集群伸缩之间的关系,因为现在往往我们上层业务应用配置的是单个集群伸缩的策略,那么整体跨集群的策略与子集群伸缩策略都配置时,它们之间的关系,到底是上层整体去做管理,还是有优先级,这可能是我们后面需要考虑的。
- 跨集群伸缩和跨集群调度间的关系,我觉得整体上还是以一个调度器为准。我的一个Multi-cluster仅仅负责伸缩的部分,比如到达了多少CPU、多少的内存,比如说70% -80%的时候去进行伸缩,伸缩到多少个,具体的调度还是由整体scheduler去进行。
- 需要汇聚各个集群的metric,包括可能有一些性能瓶颈,它整体的工作模式,是需要我们后续去考虑的。
7.2、未来展望2-跨集群调度
对于跨集群调度方面,Karmada已经支持了上文提到的故障域打算、应用偏好、权重对比。但是我们希望它也能够根据集群的资源与量去进行调度,这样不会产生各个子集群当中资源不均衡的状态。虽然它暂时是没有实现的,但它的一个CRD叫cluster, cluster有一个状态信息,这个状态信息里面会去收集node ready的状态, node上剩余的Allocatable,就是CPU内存的剩余信息。其实有了这些信息之后,我们再做自定义调度,完全是规划中的一个事情。
整体的调度设计完之后,当调度 deployment A时,它是因为偏好的设置调度到cluster 1; deployment B因为一个故障域打散,它可能调度到了cluster 123三个集群;deployment C也是一个故障域打散,但是因为资源余量的原因,它多余的pod被调度到了cluster 2这样一个集群。
【与云原生的故事】有奖征文火热进行中:https://bbs.huaweicloud.com/blogs/345260
- 点赞
- 收藏
- 关注作者
评论(0)