个人的网站建设的目的,宿城网站建设,做社交网站框架,如何用wordpress站群背景与动机
目前随着云原生技术和云市场的不断成熟#xff0c;越来越多的 IT 厂商开始投入到跨云多集群的怀抱当中。以下是 flexera 在 2023 年中关于云原生市场对多云多集群管理的接受程度的调查报告#xff08;http://info.flexera.com#xff09; 从 flexera 的报告中可…背景与动机
目前随着云原生技术和云市场的不断成熟越来越多的 IT 厂商开始投入到跨云多集群的怀抱当中。以下是 flexera 在 2023 年中关于云原生市场对多云多集群管理的接受程度的调查报告http://info.flexera.com 从 flexera 的报告中可以看出目前在整个云原生市场中已经有超过 87% 的企业正在同时使用多个云厂商的服务其中使用单一公有云和单一私有云的仅占13%。而其中使用了多云部署的厂商中则有 15% 的用户选择了多公有云或多私有云部署而采用了混合云部署的用户比例则达到了 72%。这些统计数据都从侧面反映了云原生技术和云市场的不断成熟未来将会是编程式多云管理服务的时代。 除了外部趋势以外单一集群下的局限性也成为了推动用户拥抱多云多集群管理的一个内在动力。单集群部署的局限性包括但不限于
单点故障难以容忍集群级别的故障小的集群联邦优于大的 K8s 集群单集群的边界限制例如一个 Node 默认只有 110 个 Pod一个集群最多容纳 5000 个 Node业务层面上的发展需要例如 Xline 本身作为一款跨集群的分布式键值存储....
Karmada 作为一款开源的多集群管理工具已经被 Shopee、DaoCloud 等公司应用在了生产环境中。但由于 Karmada 目前缺少对有状态应用管理的支持因此应用实践上主要还是以无状态应用的管理为主。 为了更好地应对未来多云多集群管理的趋势在多云多集群场景下更好地管理有状态应用Xline 和 Karmada 社区成立了工作小组共同推进 Karmada 对有状态应用管理的支持。 Karmada 管理有状态应用存在哪些挑战
要理解 Karmada 在多集群下管理有状态应用之前我们需要先回顾一下 K8s 在单集群下管理有状态应用的实现。 早在 2012 年的时候Randy Bias 就 “开放和可扩展云架构”进行了有影响力的演讲。在那次演讲中他提出了 “宠物模式”与 “家畜模式”。 这两种模式分别对应了应用的无状态和有状态。其中对于家畜模式而言他们不需要有特定的名字个体与个体之间也不存在本质的区别因此当其中的某个个体出现问题时我们往往可以直接使用另外一个个体来代替它。而对于宠物模式来讲每个个体都需要有一个特定的名字标识符每个个体都是独一无二的因此当其中的某个个体出现了问题时你需要进行特殊的照顾以便帮助它恢复健康。 而 K8s 在 1.5 版本中首次引入了 StatefulSet 这一 API 对象并在 1.9 版本中稳定可用的状态。目前已经被广泛应用于运行有状态应用。它为所管理的 Pod 提供了固定的 Pod 身份标识每个 Pod 的持久化存储以及 Pod 之间严格的启停顺序。 那么问题来了有状态的应用到底有哪些状态而 K8s 的 StatefulSet 又是如何初步解决有状态应用的状态问题 而在 Karmada 多集群场景下有状态的应用则带来了如下的问题
如何保证跨集群的多个应用实例能够有一个全局统一的启停顺序这对一些应用实例的 scale in/out 和滚动更新会带来影响。对于一个基于共识协议的分布式 KV 存储来讲scale 的过程需要经过 membership change其中会涉及到集群中 majority 修改的判定。如果缺少全局统一的顺序保证多个 member cluster 同时进行 scale out则会对共识协议达成共识的行为带来正确性上的影响如何保证跨集群的所有应用都有全局唯一的实例标识一个自然的解决方案便是将 member cluster id 一起纳入到实例标识当中如何解决跨集群的应用通信问题以及提供全局统一的网络标识。目前在我们的尝试和实践当中我们通过 submariner 来打通多个 member cluster 之间的网络通信。目前的实现方式上依赖了某个具体的网络插件如何解决跨集群的有状态应用的更新、以及扩缩容等常见的功能提供更细粒度的更新策略例如在 member cluster 中实现如 Partition Update 的功能 为了更好地解决上述提到的问题需要在 Karmada 上引入新的 Workload 来实现跨集群版本的 “StatefulSet”。 Xline 的一些早期尝试
由于目前 Karmada 社区对新 API 的很多实现细节还没有讨论清楚的前提下我们对 Xline 在 karmada 下的部署扩缩容和更新做了一些简单的探索与尝试。方案整体的架构如下 在整体架构上目前采用的是一个双层 Operator 的方式在 Karmada 的控制面上我们部署了一个 Karmada Xline Operator由它来负责对定义在 Karmada 上的一些 Xline 资源进行解释和拆分并将其下发到 member cluster 上。而 member cluster 上的 Xline Operator 在监测到对应的资源被创建出来之后则会进入到相应的 Reconcile 过程从而完成相应的操作。 部署
让我们先来看看在单集群下分布式应用集群的常见部署方法以 etcd operator 部署 etcd 集群为例。etcd-operator 部署 etcd 集群可以分为两个阶段
Bootstrap: 创建一个 etcd 的种子节点种子节点的 initial-cluster-state 为 new并制定了唯一的 initial-clsuter-tokenScale out在种子集群上执行 member add更新集群网络拓扑然后启动新的 etcd 节点新节点中的 initial-cluster 为更新后的网络拓扑并且 initial-cluster-state 为 existing
然而在跨集群场景下由于不同的 member cluster 中的 pod 启动顺序缺少全局统一的启动顺序不同 member cluster 下的 Xline Operator 会并发执行集群扩充操作这会对共识协议的成员变更过程带来不利的影响。而为了绕开上述问题Xline 采用了静态部署的方式具体过程如下图 首先用户需要先在 karmada 上定义好相应的资源来描述跨集群的 Xline 集群的集群拓扑。Karmada Xline Opeartor 在监测到资源被 apply 后会对资源进行解释和拆分将其转换为member cluster 上的 XlineCluster 这个 CR 并下发。XlineCluster 这个 CR 当中会包含当前 member cluster 应当创建的 replica 数量同时也会包含其他集群的 member cluster id 以及对应的 replica 数量。而 member cluster 上的 Xline Operator 在监测到 CR 的创建后会进入 Reconcile 的过程利用下发的集群拓扑结构生成整个 Xline 集群中其他节点的 dns name并启动 Xline 的 Pod。 在探索的早期静态部署的方式由于在部署过程中不涉及 membership change从而绕开了 Karmada 多集群下应用实例缺乏全局统一启动顺序的问题。但软件行业没有银弹静态部署也是如此它有如下的一些 trade off。下表是针对动态部署和静态部署在单集群与多集群场景下特点的对比 扩缩容
在 Karmada 下对有状态应用进行 scale in/out 具体可分为两种 水平 scale in/out —— 移除/增加一个 member cluster并在其上 scale in/out 节点
垂直 scale in/out —— 在原有的 member cluster 上进行 scale in/out
水平 scale out 如上图所示整体的过程如下
创建好对应的 member cluster配置好 submariner 网络并将其加入到 Karmada 中进行管理修改 Karmada 上的 Xline 资源在 member cluster 字段中添加新的记录 member4: 4 表示要在 member4上扩充 4 个 Xline 的 PodKarmada Xline Operator 会将资源进行拆分解释并下发到 member4 上member4 上的Xline Operator 在接收到相应资源后进入对应的 Reconcile 过程调用 Xline client 执行 member add达成共识后将新的 Xline Pod 启动起来重复上述过程直到 member4 上 Xline 的 replicas 达到指定数量
垂直 scale out 对于垂直 scale out其大致过程也如上图所示
修改 Karmada 上的 Xline 资源例如指定 member1 中的 Xline 的 Pod 从 3 扩充到 4Karmada Xline Operator 会将资源进行拆分解释并下发到 member1 上member1 上的 Xline Operator 在接收到资源修改通知后进入对应的 Reconcile 过程调用 Xline client 执行 member add达成共识后将新的 Xline Pod 启动起来重复上述过程直到 member1 上 Xline 的 replicas 达到指定数量 目前由于 scale in/out 不可避免地会涉及到 membership change 的过程而在 Karmada 下不同 member cluster 之间缺少必要的同步机制因此scale 的过程还是存在局限性一次水平 scale out 只能扩容一个集群一次垂直扩容也只能在某个指定的 member cluster 上进行。
滚动更新 对于滚动更新而言大致的过程如上图所示
用户修改 Karmada 上的 Xline 资源修改其中的 xline 镜像版本Karmada Xline Operator 会将资源进行拆分解释并下发到 member cluster 上member cluster 上的 Xline Operator 在监测到资源发生变化后会进入相应的 Reconcile 流程执行滚动更新操作。member cluster 上的更新流程和单集群上的更新没有区别。 目前主要支持的更新方式为默认的滚动更新但从实际的应用场景来看至少需要考虑以下两个问题
更新的过程当中会涉及旧 Xline 节点的停止和新 Xline 节点的启动需要有额外的机制来保证更新过程不会产生不可用的问题需要支持更多细粒度的更新策略例如 Partition Update。在多个 member cluster 中应当优先更新只有 follower 存在的集群并且在更新 leader 所在的 member cluster 时还应当将 leader 转移到更新好了的 member cluster 上以避免极端情况下leader 因为 Rolling update 而导致频繁下台的情况 总结
鉴于多云多集群管理的发展趋势以及 Xline 本身业务上的特性Karmada 社区和 Xline 社区目前成立了工作小组共同推动有状态应用在 Karmada 多集群下的管理。为了更优雅地解决 Karmada 多集群管理有状态应用的问题我们需要引入新的 Karmada workload。目前由于 Karmada 社区对于新的 workload 的实现细节还没有达成共识因此在早期的尝试阶段Xline 采用了两层的 Operator 方式通过 Karmada Xline Operator 对顶层资源进行解释和拆分并下发至 member cluster再由 member cluster 上的 Xline Operator 来对资源进行调谐。 通过这样的方式我们对在 Karmada 上部署 Xline 以及滚动更新做了一些早期的尝试与探索为未来新的 Karmada StatefulSet workload 的开发与设计做了一些前期的铺垫。 Xline社区会议
为了更全面地向大家介绍Xline的进展同时促进Xline社区的发展我们将于2024年3月29日北京时间晚上11:00召开Xline社区会议。 欢迎您届时登陆zoom观看直播:会议号: 813 0547 8985密码: 520159会议链接https://zoom.us/j/81305478985?pwdPsnbMGQy1ZqxYyd67cAkaGROfnIoQa.1
Xline于2023年6月加入CNCF 沙箱计划是一个用于元数据管理的分布式KV存储。Xline项目以Rust语言写就。感谢每一位参与的社区伙伴对Xline的帮助和支持也欢迎更多使用者和开发者参与体验和使用Xline。GitHub链接https://github.com/xline-kv/XlineXline官网www.xline.cloudXline Discord: https://discord.gg/mJdTjzfD
