Karmada 多云容器编排引擎支持多调度组,助力成本优化
摘要:Karmada 社区也在持续关注云成本的管理,在最近发布的 v1.5 版本中,支持用户在分发策略 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群调度组,实现将业务调度到成本更低的集群组中去。
本文分享自华为云社区《Karmada 多云容器编排引擎支持多调度组,助力成本优化!》,作者:华为云云原生团队
根据 Flexera 最新发布的《2023 年云现状调查报告》,在受访的750家企业中,使用多云的企业比例高达87%:
在使用多云的受访者中,排在前两位的多云挑战分别是:孤立在不同云上的应用程序和云之间的灾难恢复/故障切换。在所有组织中,最常用的多云工具是安全工具,紧随其后的是成本优化(Finops)工具。
此外,云成本的管理取代了安全性话题,成为当下云使用者面临的首要问题:
Karmada 社区也在持续关注云成本的管理,在最近发布的 v1.5 版本中,支持用户在分发策略 PropagationPolicy/ClusterPropagationPolicy 中设置多个集群调度组,实现将业务调度到成本更低的集群组中去。
多调度组
Karmada 的PropagationPolicy 支持声明单组集群,即.spec.placement.clusterAffinity,其 YAML 配置示例为:
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinitiy: - clusterNames: - member1 - member2
Karmada v1.5 版本中,clusterAffinity 向 karmada-scheduler 提供一组候选集群,karmada-scheduler 根据相关限制(例如 spreadConstraint,插件过滤等)在候选集群之间做出调度决策,调度结果要么成功,要么失败。多调度组支持用户设置ClusterAffinities字段,在 PropagationPolicy 中声明多组集群,karmada-scheduler 可以依次来评估每个 clusterAffinity,进而做出决策。此功能允许 Karmada 调度程序在集群故障时首先将应用程序调度到低成本集群组,或将应用程序从主集群迁移到备份集群。
// Placement represents the rule for select clusters. type Placement struct { // ClusterAffinities 表示对 ClusterAffinityTerm 指示的多个集群组的调度限制。 // 调度程序将按照这些组在规范中出现的顺序逐个评估,不满足调度限制的组将被忽略, // 这意味着除非该组中的所有集群也属于下一个组(同一集群可以属于多个组), // 否则将不会选择此组中的所有集群。 // 如果没有一个组满足调度限制,则调度失败,这意味着不会选择集群。 // 注:ClusterAffinities 不能与 ClusterAffinity 共存。 // 如果未同时设置 ClusterAffinities 和 ClusterAffinity,则任何集群都可以作为调度候选集群。 // // +optional ClusterAffinities []ClusterAffinityTerm `json:"clusterAffinities,omitempty"` } // ClusterAffinityTerm selects a set of cluster. type ClusterAffinityTerm struct { // AffinityName 是集群组的名称. // +required AffinityName string `json:"affinityName"` ClusterAffinity `json:",inline"` }
云成本管理使用场景
用户可以使用多调度组来进行云成本的管理,例如:本地数据中心中的私有集群是主集群组,集群提供商提供的托管集群可以是辅助集群组,因此,Karmada 调度程序更愿意将工作负载调度到主集群组,只有在主集群组不满足限制(如缺乏资源)的情况下,才会考虑辅助集群组。下面我们给出一个针对成本优化进行调度的例子:
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: local-clusters clusterNames: - local-member1 - local-member2 - affinityName: cloud-clusters clusterNames: - huawei-member1 - huawei-member2
上面例子中配置有本地集群组(local-clusters)和云上集群组(cloud-clusters)共两个集群组,Karmada 在调度 Deployment/nginx 时,会优先尝试调度到本地集群组中的集群,如果失败(如缺乏资源),则继续选择云上集群组,从而实现在本地集群资源足够时,优先选择成本更低的本地集群的目标。
容灾与迁移场景
对于灾难恢复场景,系统管理员也可以定义主集群组和备份集群组,工作负载将首先调度到主集群组,当主集群组中的集群发生故障(如数据中心断电)时,Karmada 调度程序可以将工作负载迁移到备份集群组。
apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: nginx spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: nginx placement: clusterAffinities: - affinityName: primary-cluster clusterNames: - member1 - affinityName: backup-cluster clusterNames: - member2
上面的例子通过配置主集群组(primary-cluster)和备份集群组(backup-cluster),在调度 Deployment/nginx 时,如果主集群组满足要求,会调度到主集群组中的 member1 集群,当member1 集群故障时,调度器按顺序匹配新集群组,从而将业务迁移到备份集群组中的member2 上,这样就达成了容灾的目的。
总结
支持多调度组设置为用户提供了更丰富的多集群资源分发策略选择,Karmada 后续也会继续探索云成本的管理,大家有任何感兴趣的想法,都欢迎大家来 Karmada 社区进行讨论与分享。
附:Karmada社区交流地址
项目地址:https://github.com/karmada-io/karmada
Slack地址:https://slack.cncf.io/

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
加密邮件服务 Proton Mail 推出开源密码管理器
Proton 是欧洲核子研究中心(CERN)的科学家于 2013 年在瑞士日内瓦创立的,其最知名的应该就是电子邮件服务 Proton Mail,主打端到端加密、安全和隐私保护。日前他们推出了一个新产品 —— 开源密码管理器 Proton Pass。 Proton Pass 是 Proton 社区很多用户都希望增加的服务,同样使用了端到端的加密技术来安全地存储用户数据。Proton Pass 与一些密码管理器最大的不同在于,它不仅对密码字段进行加密,而且还对诸如用户名、电话、URL,甚至注释部分所包含的数据进行加密。 Proton 的创始人兼首席执行官在博客中写道: 这一点很重要,因为看似无害的信息(如保存的 URL,许多密码管理器都没有加密)也可以被用来创建一个关于你的详细档案。即使攻击者实际上无法访问你的账户,但如果他们可以看到你在某些网站中创建了账户,他们也会对你这个人有很多了解。 因为解密数据需要用户密钥,而加密操作又是在用户设备本地进行的,即使是 Proton 也无法访问你存储在密码库中的信息,甚至 Proton 的服务器遭到入侵,用户的数据也应该是安全的。 Proton Pa...
- 下一篇
即时通讯系统为什么选择GaussDB(for Redis)?
摘要:如果你需要一款稳定可靠的高性能企业级KV数据库,不妨试试GaussDB(for Redis)。 每当网络上爆出热点新闻,混迹于各个社交媒体的小伙伴们全都开启了讨论模式。一条消息的产生是如何在群聊中传递的呢?让我们一起来探索即时通讯系统(IM)的原理。 IM系统架构的原理 当你在群聊“相亲相爱一家人”中,发送了一条“我找到女朋友了,今天带回家吃饭”,你自然是希望全家人都收到你的喜讯,为你女朋友的到来分头准备。那么正常的流程应该是这样:遍历群成员、查询每个成员的在线状态、如果小伙伴们在线则实时进行推送,如果小伙伴们不在线则暂存至离线库待上线后主动拉取。 这种模式就是传统的IM架构,由于发送成功的消息不会落入离线库,因此聊天记录多端漫游无法实现。如果在线用户推送发生异常,会导致个别人员丢失关键发言,错失重要信息。为了保证消息存储的可靠性,我们对IM系统架构进行了优化,不管成员是否在线都要先把消息和发送对象存储起来,再进行推送。流程变成:遍历群成员、为群聊的每一个人对应的消息队列都存一份消息、查询每个成员的在线状态、对在线成员进行推送。这就是所谓的写扩散模型。 这里显然还存在一个问题,我...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2全家桶,快速入门学习开发网站教程
- MySQL8.0.19开启GTID主从同步CentOS8
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,7,8上安装Nginx,支持https2.0的开启