Karmada,你了解多少?【与云原生的故事】

举报
nukinsan 发表于 2022/05/18 22:07:39 2022/05/18
【摘要】 Karmada结合了华为云多云容器平台MCP以及Kubernetes Federation核心实践,并融入了众多新技术:包括Kubernetes原生API支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等,并且提供原生Kubernetes平滑演进路径,让基于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 支持,并且 CNICSI 在其整体的功能视图中,对 CI/CD 有整体上的规划与考虑,所以工行最终决定投入到该项目中,与华为在内的一系列伙伴共建该项目并回馈到社区中。

3、Karmada技术架构



Karmada 控制平面由以下几个组件组成:

  • API 服务器(Karmada API Server
  • 控制管理器(Karmada Controller Manager
  • 调度器 (Karmada Scheduler)

Karmada通过独立的API 服务器(Karmada API Server)提供与其他组件进行通信的 REST 接口,包含Kubernetes原生APIKarmada扩展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 外部客户端几乎无需改造

支持PullPush模式分发,适配多种场景,尤其在大规模集群数量场景下,使用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在它整体功能视图里,包括上层的应用、对IstioMashCI/CD等都有整体规划上的考虑。因此基于整体思路,它的功能与我们非常契合,工行也决定投入到这个项目中来,跟华为和我们很多的项目伙伴共建Karmada项目,并把它回馈到我们社区整体。

7、未来展望


7.1、未来展望1-跨集群伸缩

跨集群伸缩现在也是在Karmada规划当中,现在我们可能还是需要解决一些问题:


  1. 考虑它跨集群伸缩和子集群伸缩之间的关系,因为现在往往我们上层业务应用配置的是单个集群伸缩的策略,那么整体跨集群的策略与子集群伸缩策略都配置时,它们之间的关系,到底是上层整体去做管理,还是有优先级,这可能是我们后面需要考虑的。
  2. 跨集群伸缩和跨集群调度间的关系,我觉得整体上还是以一个调度器为准。我的一个Multi-cluster仅仅负责伸缩的部分,比如到达了多少CPU、多少的内存,比如说70% -80%的时候去进行伸缩,伸缩到多少个,具体的调度还是由整体scheduler去进行。
  3. 需要汇聚各个集群的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 

 

 

 

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。