Karmada v1.6 发布！跨集群弹性伸缩

举报
云容器大未来 发表于 2023/06/16 17:08:45 2023/06/16
【摘要】 Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。在最新发布的v1.6版本中，Karmada新增了应用跨集群弹性伸缩的能力，将单集群HPA的能力扩展到多集群，从此应用不仅能够跨集群部署以提高可用性。

作者：华为云云原生团队

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。

图片

在最新发布的v1.6版本中，Karmada新增了应用跨集群弹性伸缩的能力，将单集群HPA的能力扩展到多集群，从此应用不仅能够跨集群部署以提高可用性，还可以根据业务流量在多个集群中同时实现动态伸缩。

本版本其他新增特性：

  • 在集群（级）故障迁移基础上，新增了应用（级）故障迁移能力，用户可以为每个应用配置故障探测逻辑以及迁移策略，应用故障后可以被迁移到其他集群。
  • 定义了云提供商需要实现的多集群 Ingress 共享接口，通过实现接口，控制器可以以可插拔的方式与任意云提供商的进行集成，使 Karmada 能够使用并管理云上的 LoadBalancer 服务。
  • 提供了Karmada Operator来管理Karmada的安装部署、升级和卸载。相较于已有的CLI和Helm chart安装部署方式，Karmada Operator通过声明式API语义来提供Karmada全生命周期管理和运维。
  • 进一步增强了CRD资源的支持，Karmada资源解释器中内置了知名项目（包括 Argo Workflow、Flux CD、Kyverno、OpenKruise）的CRD解析逻辑，从此用户在Karmada中使用这些项目时可以免去或减轻配置负担。
  • 提供 Karmada 在线演示平台，可让用户在云上快速体验核心功能。


新特性概览

FederatedHPA

在多云多集群的场景下，为了满足跨集群业务的弹性伸缩需求，Karmada 提供了 FederatedHPA， 解决如下场景难题：

  • 无法统筹多个集群的资源，跨集群弹性伸缩业务；

  • 多个子集群HPA分散管理，冗余且复杂度较高，无法统一高效配置和管理；

  • 如单集群扩容发生故障，无法在其他集群扩容实例，存在断服风险；

  • 无法统一限制多个集群资源使用量，以限制某业务的资源消耗和费用消耗。

图片

FederatedHPA工作原理和单集群的HPA相似，Karmada 通过聚合多个子集群的监控指标来决策副本的伸缩，PropagationPolicy 或 ClusterPropagationPolicy 中的调度策略，伸缩的副本能够应用到多个集群中。

Karmada FederatedHPA API 语义与单集群HPA非常类似。以下是根据CPU使用率弹性伸缩Deployment的示例：

apiVersion: autoscaling.karmada.io/v1alpha1
kind: FederatedHPA
metadata:
  name: nginx-fhpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 40
---
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member1
        - member2
    replicaScheduling:
      replicaDivisionPreference: Weighted
      replicaSchedulingType: Divided
      weightPreference:
        dynamicWeight: AvailableReplicas

上面的示例配置期望跨集群业务的平均CPU负载维持在40%，如果CPU负载为超过40%，扩容的实例数将按 member1，member2集群中 的可用资源拆分调度，实现跨集群扩容。

关于 FederatedHPA 的更多信息，请参考：https://karmada.io/docs/next/userguide/autoscaling/federatedhpa


应用的故障迁移

在多云架构的众多优势中，故障迁移无疑是其中重要的一环，当一家云供应商出现故障时，企业希望能使用另一家云供应商承接服务，实现服务的平稳不中断。尤其是对于无状态的计算任务而言，多云间的故障迁移有着广阔的应用场景。

Karmada关注应用在多集群的高可用部署，积极探索多云环境下的故障迁移，并从集群和应用两个视角来思考这一问题。从集群的视角出发，控制面的故障往往会引发以集群为维度的故障域的不可用，在Karmada中，当集群发生故障或是用户不希望在某个集群上继续运行工作负载时，集群状态将被标记为不可用，并被添加上相应地污点。Taint-manager检测到集群故障后，会从这些故障集群中驱逐工作负载，被驱逐的工作负载将被调度至其他适合的集群，从而达成故障迁移的目的。

然而，某些集群的变化只会影响到特定的应用，对于那些未受影响的应用，我们希望他们维持现状，例如，在一个在离线服务混合部署的集群中，管理员通过抢占式调度在多个集群中部署计算任务，当集群资源紧缺时，原本正常运行的低优先级任务被抢占，长时间无法正常运行。此时，应用无法在集群内进行自我修复。用户希望尝试将其迁移到另一个集群，同时不影响运行正常的在线服务。
图片
Karmada从应用的视角出发，提供了应用的跨集群故障迁移能力，用户可以在PropagationPolicy/ClusterPropagationPolicy中配置迁移规则，实现应用处于不健康的状态时的跨集群故障迁移。应用的健康状态可以基于Karmada的资源解释器框架自定义配置。下面我们给出一个配置应用的故障迁移的例子： 
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: nginx-propagation
spec:
 failover:
   application:
     decisionConditions:
       tolerationSeconds: 120
     purgeMode: Never
 resourceSelectors:
   - apiVersion: apps/v1
     kind: Deployment
     name: nginx
 placement:
   clusterAffinity:
     clusterNames:
       - member1
       - member2
       - member3
   spreadConstraints:
     - maxGroups: 1
       minGroups: 1
       spreadByField: cluster

上面的例子配置期望在备选的集群范围中选择一个最优集群，如果应用处于不健康的状态持续120s后，Karmada会自动将该应用迁移至另一个可选的集群中。

关于应用的故障迁移的更多信息，请参考：

https://karmada.io/docs/next/userguide/failover/application-failover


MCI Provider

为了实现多集群的统一流量入口，我们在 MulitClusterIngress API 的基础上，提供了 MultiClusterIngress 对象的共享接口。用户可以通过实现这些接口，将 MultiClusterIngress 后端 Service 的 Pod 地址注册到云提供商的 LoadBalancer 服务上。此外，用户还可以在 MultiClusterIngress 对象上定义各种策略，如蓝绿发布、金丝雀发布等。

让我们以用户的角度来看待这个处理流程：

首先，运维人员在 Karmada 控制面上部署了一组应用，其中包括两个不同版本的 Service（v1 和 v2），并创建了分发策略，将这些应用分发到成员集群 A 和 B 中。

接下来，运维人员在 Karmada 控制面上创建了 MultiClusterIngress 资源，并将这两个版本的 Service 设置为其后端multicluster-cloud-provider-xxx 是某一云提供商在引入 multicluster-cloud-provider 仓库后的具体实现，它会监听 MultiClusterIngress 资源的创建或更新，并将其后端服务的 IP 地址注册到 LoadBalancer 实例中。

最后，当一切就绪后，用户可以通过不同的域名访问 LoadBalancer，将请求转发到不同版本的 Pod 中。用户可以在 MultiClusterIngress 上设置不同的策略，以实现多种七层访问策略。

图片
MultiCluserIngress 共享接口仓库地址：https://github.com/karmada-io/multicluster-cloud-provider


Karmada Operator

Karmada Operator是一个用于安装、升级和删除Karmada实例的组件。它建立在基本的Karmada资源和控制器概念之上，提供了便利的方式在全局集群之上集中式管理多个Karmada实例的生命周期。使用Operator，用户可以通过使用自定义资源在本地集群或者远端集群上管理自己的Karmada实例。
用户可以通过Helm charts或者YAML等方式安装karmada-operator组件，并提交Karmada CR来安装一个Karmada实例。下面给出了一个在test命名空间下安装Karmada的例子，配置采用默认值。 
kubectl get po -n test
karmada-demo-aggregated-apiserver-587bc5c697-v27vb      1/1     Running   0          12s
karmada-demo-apiserver-55968d9f8c-mp8hf                 1/1     Running   0          35s
karmada-demo-controller-manager-64455f7fd4-stls6        1/1     Running   0          5s
karmada-demo-etcd-0                                     1/1     Running   0          37s
karmada-demo-kube-controller-manager-584f978bbd-fftwq   1/1     Running   0          5s
karmada-demo-scheduler-6d77b7547-hgz8n                  1/1     Running   0          5s
karmada-demo-webhook-6f5944f5d8-bpkqz                   1/1     Running   0          5s

关于karmada-operator的更多信息请参考：https://github.com/karmada-io/karmada/blob/master/operator/README.md


内置支持知名项目CRD资源

Karmada对CRD提供了深度支持的能力，通过资源解释器框架，Karmada允许用户自定义任意资源的解析逻辑，在之前的版本中，资源解释器框架内置了Kubernetes常用资源的解释逻辑，本版本中资源解释器构建了内置第三方开源项目CRD的能力，并内置了Argo Workflow、Flux CD、Kyverno、OpenKruise项目的多个CRD，从此用户在Karmada中使用这些项目时可以免去或减轻配置负担。

Karmada在线演示平台

为了帮助用户更快的体验  Karmada，在 1.6 版本周期内，我们借助 killercoda，在线上提供了4个核心场景供用户快速体验，包括：

  • 利用 CLI，在 K8s 集群中安装 Karmada，并加入子集群实现统一管理。
  • 利用复制策略分发工作负载，实现业务高可用跨集群部署。
  • 利用拆分策略分发工作负载，实现业务高可用跨集群部署。
  • 模拟集群故障，体验优雅迁移，保障业务连续性。

体验链接请查看：https://killercoda.com/karmada

版本升级

Karmada v1.6 版本 API兼容v1.5版本 API，v1.5版本的用户仍然可以平滑升级到v1.6版本。可参考升级文档：https://karmada.io/docs/next/administrator/upgrading/v1.5-v1.6


致谢贡献者

Karmada v1.6 版本包含了来自42位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：

贡献者GitHub ID: 

  • @7sunarni @liangyuanpeng@sunbinnnnn @a7i@lifeiguanchen @tedli @bhavyastar@lixingchenDaoCloud@Vacant2333  
  • @callmeoldprince@lonelyCZ@WenchuanZhao@calvin0327 @LronDC @whitewindmills @chaunceyjiang@lxtywypc@WulixuanS  
  • @duanmengkk@mkloveyy@wzshiming @fredgate@my-git9 @xigang @HassanTanveer@neteric @XiShanYongYe-Chang 
  • @helen-frank @Nikko-Adrian-Pacleb@yanfeng1992 @ibalajiarun@niuyueyang1996@yanggangtony@ikaven1024@Poor12 
  • @yike21@jwcesign@RainbowMango@zach593@learner0810@realnumber666@zishen                                       

                                      

参考链接 

Release Notes：https://github.com/karmada-io/karmada/releases/tag/v1.6.0

FederatedHPA使用文档：https://karmada.io/docs/next/userguide/autoscaling/federatedhpa

FederatedHPA设计文档：https://github.com/karmada-io/karmada/blob/master/docs/proposals/hpa/federatedhpa-v2.md

应用的故障迁移：https://karmada.io/docs/next/userguide/failover/application-failover

Karmada Operator：https://github.com/karmada-io/karmada/blob/master/operator/README.md

Karmada 1.6升级文档：https://karmada.io/docs/next/administrator/upgrading/v1.5-v1.6


附：Karmada社区技术交流地址

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

评论（0）

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

全部回复

上滑加载中

设置昵称

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

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

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

确认 取消

加入云驻计划，成为创作者

  • 华为云周边好礼
  • 免费体验产品
  • 特殊身份标识
  • 线下官方门票
  • 内部专家零距离
  • 与10000+优质创作者共同成长
立即加入