大家好，关于Kubernetes 多集群实践思考与探索很多朋友都还不太明白，今天小编就来为大家分享关于的知识，希望对各位有所帮助！
2.多云混合使用：
为避免被单一供应商锁定、不同集群的最新技术规划，或者出于成本考虑，企业选择多云架构。
3.业务流量突发：
一般情况下，用户使用自己的IDC集群来提供服务。当处理突发大流量时，将应用快速扩展到云集群，共同提供服务。需要公有云IaaS接入，计算节点可自动扩缩容。使用公有云作为备份资源池。该模式一般针对无状态服务，可以快速弹性扩展。主要针对密集使用CPU和内存较多的服务，如搜索、查询、计算等类型的服务。
4.业务高可用：
单个集群无法应对网络故障或数据中心故障导致的服务不可用。通常一个集群为主服务，另一个集群定期备份。或者一个集群主要负责读写，其他备份集群只读。如果主集群所在云出现问题，可以快速切换到备份集群。该模式可用于大数据量的存储服务，例如部署高可用的MySQL集群。一个集群负责读写，另外两个集群只读用于备份，并且可以自动切换主从。
5.异地多活：
数据实时同步，多个集群可同时读写。这种模式通常针对极其重要的数据，例如全球统一的用户账户信息。
6.地域亲和性：
虽然国内网速不断提高，但出于带宽成本考虑，同一呼叫链的服务网络距离越近越好。主、辅业务部署在同一区域，可有效降低带宽成本；而分而治之的方式还可以通过让应用服务于该区域的业务，有效缓解应用服务的压力。
二、多集群探索
2.1 社区在多集群上的探索
目前基于K8s的多集群项目如下：
1.Federation v1：
已被社区废弃。主要原因是v1的设计试图在K8s之上再构建一层Federation API，直接屏蔽了已经达成广泛共识的K8s API。这与云原生社区的发展理念是背道而驰的。
2.Federation v2：
已被社区废弃。它提供了一种可以将任何K8s API 类型转换为具有多个集群概念的联邦类型的方法，以及相应的控制器来推送这些联邦对象（Object）。它不像V1那样关心复杂的推送策略（V1的Federation Scheduler）。它只负责将这些对象分发到用户预先定义的集群中。这意味着Federation v2的主要设计目标实际上是将RBAC、策略和其他集群配置信息推送到多个集群。
3.Karmada：
参考了Kubernetes Federation v2的核心实践，融入了很多新技术，包括Kubernetes原生API支持、多级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务等发现等，并提供原生Kubernetes平滑演进路径。
4.Clusternet：
是一款开源云原生管控平台，结合多集群管理和跨集群应用编排，解决跨云、跨地域、跨可用区的集群管理问题。在项目规划阶段，针对未来混合云、分布式云和边缘计算场景进行设计，支持海量集群的接入和管理、应用分发、流量管理等。
5.OCM：
OCM是一个Kubernetes多集群平台开源项目，可以帮助您大大简化跨云/多云场景下的集群管理，无论这些集群托管在云端、部署在自建数据中心、或在边缘数据中心。 OCM提供的基本模型可以帮助我们同时了解单个集群内的容量，也可以跨多个集群编排资源/工作负载。同时，OCM还提供了一系列强大的扩展性，或者说addon-framework，来帮助我们集成CNCF生态中的其他项目。这些可扩展性还可以帮助我们在不侵入的情况下针对您的特定使用场景。手动扩展功能。
以上多集群项目主要功能是资源分配和调度，以及多云基础设施管理cluster-api、多集群检索Clusterpedia、多集群pod互操作submariner、多集群-ingress解决多集群问题集群入口、服务治理和流量调度Service Mesh，例如istio、cilium等网络组件实现的多集群mesh解决跨集群mesh网络管理，并结合存储相关项目实现跨集群存储管理和迁移。
2.2 vivo 在多集群上的探索
2.2.1 非联邦集群管理
非联邦多集群管理系统主要进行资源管理、运维管理和用户管理，提供导入K8s集群权限的功能，并通过统一的Web界面进行查看和管理。此类工具不会引入额外集群联邦的复杂性，保持各个集群的独立性，同时通过统一的Web界面查看多个集群的资源使用情况。它们支持通过Web界面创建Deployment、Service、负载均衡等，并将集成持续集成、持续交付、监控报警等功能。由于集群联邦技术仍在不断发展，大多数企业倾向于使用这种方法来运营和管理多集群Kubernetes 环境。目前vivo主要通过这种方式管理多个集群。
2.2.2 联邦集群管理
联邦集群主要是将资源联邦化，实现资源的统一管理和调度。随着K8s在数据中心的广泛使用，K8s已经成为基础设施管理的标准，不同区域的部署也变得非常普遍。例如，K8s运行在云上托管集群、企业自建数据中心的私有云、边缘计算等。越来越多的企业正在投资多集群管理项目。当然，联邦集群肯定会增加整体架构的复杂度，集群之间的状态同步也会增加控制平面的额外开销。尽管复杂性不断增加，但普遍存在的多集群拓扑带来了令人兴奋的新潜力。这种潜力超出了目前探索的跨多个集群的简单静态应用程序编排的范围。事实上，多集群拓扑对于跨不同位置编排应用程序和统一对基础设施的访问非常有用。除此之外，这带来了透明、快速地将应用程序从一个集群迁移到另一个集群的令人兴奋的可能性。在处理集群灾难或关键基础设施干预、扩展或布局优化时，移动工作负载是可行的。
vivo对联邦集群的探索主要包括以下四个方面：
资源分配与编排、弹性突发多集群调度、服务治理与流量调度
三、面向应用的多集群实践
云原生技术的发展就是要不断输出“事实标准软件”，而在这些事实标准之中，弹性、易用性应用程序的使用和可移植性这是它解决的三个基本问题。
应用的弹性：对于云产品的客户来说，相当于业务的可靠性和业务探索创新的敏捷性，体现了云计算创造的客户价值。应用程序弹性的另一个重点是快速部署、交付，以及在云上纵向扩展的能力。这就需要有完整的应用交付链路以及应用的云原生开发框架支持；易用性：为了更好地发挥应用的灵活性，随着微服务软件架构成为主流，需要通过技术手段考虑易用性，实现整个应用的全局治理，实现全局优化。这凸显了Service Mesh的服务能力；可移植性：实现多集群、混合云等无障碍迁移，以应用交付为中心的多集群管理，统一的云原生应用标准定义和规范，通用的应用托管和服务分发中心、基于Service Mesh的跨云应用治理能力，以及K8s原生、面向多集群的应用交付和管理系统将持续产生巨大价值。 vivo 目前主要通过结合Karmada 和CNCF 周边项目来探索上述挑战。
3.1 面向应用的多集群持续发布
3.1.1 应用发布
上图是一个面向应用的多集群持续发布架构。我们的主要工作如下：
管理和注册多个Kubernetes 集群并连接到Karmada。 Karmada负责多个集群的资源调度、编排和故障转移。容器平台统一管理K8s资源、Karmada策略和配置。 CICD平台对应用程序进行单元测试、安全测试、镜像编译等操作，配置应用程序的存储、密钥、环境变量、网络和资源等，最后连接容器平台的API生成K8s对象并统一交付。图片
实际管理一个应用程序实际上是非常复杂的。例如，特定场景需要就地升级、灰度发布。为了提供更灵活、更先进、更易用的应用发布能力，更好地满足应用发布的需求，我们最终选择使用Openkruise。比如上图中有一个游戏应用game-2408。涉及到configmap、secret、pv、pvc、service等K8s资源，openkruise的cloneset，自研的服务发现和访问资源，以及Karmada的PropagationPolicy和OverridePolicy等，都可以达到12种资源配置。例如，存储等资源按需申请、按需分配。为了有效管理这些资源和关系，目前主要通过关联数据库进行管理，通过CICD与容器平台的交互，记录应用发布的状态转变，实现应用滚动、灰度等发布能力可以实现可持续的出版能力。
为了方便问题定位以及K8s资源与Karmada资源的战略关系，目前Karmada策略命名约定如下：
它可以识别策略属于哪个工作负载，以避免策略重复。如果超过63个字符，需要添加工作负载类型策略名称，并且需要对资源名称进行哈希处理，其中xxx为非工作负载资源。遇到的问题总结：
一个资源无法被多个策略匹配，导致configmap、secret等公共资源无法再次分发到其他集群。多个集群串行发布。例如，集群B的控制权只有在集群A释放后才能释放。3.1.2 Openkruise资源解析
目前，vivo应用主要通过OpenKruise的Cloneset（无状态）和AdvancedStatefulset（有状态）控制器发布。 Kamrada目前只识别K8s的默认资源，其他资源需要开发资源解析。为了解决上述问题，Karmada引入了Resource Interpreter Webhook，通过从ResourceTemplate-ResourceBinding-Work-Resource这几个阶段介入，实现完整的自定义资源分发能力。
（1）InterpretReplica：这个钩子点发生在ResourceTemplate到ResourceBinding的过程中。对于具有副本功能的资源对象，例如类似Deployment的自定义资源，可以实现该接口来告诉Karmada对应资源的副本数量。
（2）ReviseReplica：这个钩子点发生在ResourceBinding到Work的过程中。对于具有副本功能的资源对象，需要根据Karmada发送的请求修改该对象的副本数量。 Karmada会通过调度策略计算每个集群所需的副本数量。您所需要做的就是将最终计算值分配给CR 对象。
（3）Retain：这个钩子点发生在从Work到Resource的过程中。对于成员集群中将单独更新规范内容的情况，您可以使用此钩子告诉Karmada 保留某些字段的内容。
（4）AggregateStatus：这个钩子点发生在ResourceBinding到ResourceTemplate的过程中。对于需要将状态信息聚合到资源模板中的资源类型，可以通过实现该接口来更新资源模板的状态信息。
3.2 面向应用的多集群弹性伸缩
3.2.1 弹性伸缩
跨集群HPA这里定义为FedHPA，它使用K8s原生的HPA。 Karmada控制平面使用FedHpaController实现跨集群弹性调度扩缩容。
FedHPA 流程：
用户创建HPA资源，例如指定工作负载、CPU上限、最小值和最大值。 FedController 开始计算clusterA 和clusterB 资源，在clusterA 和clusterB 中创建HPA，并按比例分配集群的min 和max。当集群clusterA 和clusterB 触发定义的CPU 资源限制时，clusterA 和clusterB 开始扩容。 Karmada控制平面中clusterA和clusterB的HPA工作对象的状态记录了集群扩展副本的状态。 FedHPAController 感知工作变化，获取每个集群中的真实副本数量，并开始更新调度资源RB 和控制平面中的工作负载副本数量。这样可以保证控制平面和成员集群的调度和副本数量一致，不会出现重复调度或副本不一致的情况。相反，当CPU流量减少时，就开始收缩，计算过程是一样的。同时，还增加了重新平衡资源的能力。当集群资源发生变化时，FedHPAController会计算集群资源总量、节点碎片情况以及是否可调度等，并重新分配每个集群HPA的min和max值，以保证扩容时有足够的资源。资源。3.2.2 定时伸缩
定时扩缩容是指在固定时间点进行应用扩容，以应对流量高峰期。 K8s本身没有这个概念。 CronHpa 资源在Karmada 控制平面中定义，并通过Karmada-scheduler 为多个集群统一调度。避免非联合集群在多个成员集群中创建多个cronhpa。定时功能是通过go-cron库实现的。
CronHpa进程：
用户根据业务需求创建CronHPA。定义膨胀时间和收缩时间。在扩展时间点，CronHPAController开始扩展工作负载。 Karmada-scheduler开始调度，开始根据每个集群的资源合理分配每个集群的副本数量。在收缩时间点，CronHPAController 开始收缩工作负载。3.2.3 手动和指定扩缩容
手动扩缩容过程：
用户指定工作负载来扩展或收缩容量。 Kamrada-scheduler开始调度，合理分配扩容或缩容值给各个集群。指定约简，这里使用了openkruise能力。例如，训练模型需要缩小一批性能较差的Pod。
指定收缩过程：
用户指定clusterA中工作负载下的某个pod进行缩容。它需要是
ScaleStrategy.PodsToDelete 指定Pod。 Karmada中需要实现Openkurise来实现该字段的资源解析，防止被控制面覆盖。并更新控制平面的工作负载副本和pp资源，保证副本数量与调度结果一致。成员集群的Openkruise开始删除指定的pod。您还可以尝试从Karmada 控制平面指定删除pod 和更改调度的结果，这样更合理，并且不需要添加Karmada 资源解析。
3.3 统一调度
3.3.1 多集群调度
Karmada多集群调度主要实现跨集群资源的合理分配和集群故障的快速迁移。如上图所示，主要是通过Karmada scheudler和模拟器的配合来实现。模拟器主要负责估算各个集群的资源。
工作负载调度流程：
用户定义的工作负载匹配策略生成RB资源。 doSchedulerBinding开始调度RB，通过预选和优化调度算法选择合适的集群。目前不进行资源计算，这与K8s的调度预选和优化不同。 selecClusters 根据过滤后的集群分配副本。这里有2种模式，主要根据用户配置的策略来选择。
a.静态调度器只计算所有资源的请求，不考虑调度规则。
b.动态调度程序在计算所有请求时也会考虑一些调度规则。最后计算分配给每个簇的副本数量并更新RB资源。调度完成后，其他控制器将基于RB进行进一步处理。故障调度：
例如，当集群A发生故障时，Karmada-scheduler将在一定条件下被触发重新调度。 Karmada-scheduler会将故障集群的资源调度到clusterB和clusterC。3.3.2 重调度
重调度的存在主要解决了下发到成员集群的应用程序没有真正运行的问题。出现这种情况的原因可能是集群资源不断变化。应用程序在被Karmada-scheduler多集群调度的时候可能可以满足，但是成员集群经过第二个这段时间之后就无法调度了。
重新安排流程：
过滤RB资源，发现RB调度不符合预期。开始重新安排工作量。经过预选、优化等过程后，调度结果再次进行分发。最后，工作负载的所有Pod 都被调度。3.3.3 单集群调度模拟器
当前社区的单集群调度估计器只是简单地模拟了四种调度算法。与实际的调度算法存在较大差距。目前网上有很多自研的调度算法，不同的集群需要配置不同的算法。这样，估计器的准确率就会下降，导致pod 在调度中挂起。可以优化单个集群的调度模拟器。
使用假客户端来模拟在线集群。假客户端启动k8s默认调度器和自研调度算法，并修改绑定接口。并配置到每个成员集群。 podRequest 请求各个集群调度模拟器运行真正的调度算法并计算调度结果。
3.4 灰度上线
3.4.1 应用迁移
对于通过非联合资源管理的应用程序，无法直接删除和创建它们。它们需要在用户不知情的情况下顺利迁移到Karmada 管理。
主要流程如下：
管理员通过容器平台将需要迁移的应用插入迁移白名单。用户通过cicd发布，容器平台会调用发布接口。 isKarmada模块将检查迁移列表，联邦化白名单中的资源，并访问Karmada管理。白名单中不保留原有的静态集群管理。该应用程序最终在用户不知情的情况下发布。保持两种管理方法并行存在。3.4.2 应用回滚
具备迁移应用程序的能力，并不能保证整个过程100%没有问题。这就需要应用回滚能力来提高用户迁移满意度。
回滚必要性总结：
应用发布迁移过程中出现未知错误，且短时间内无法恢复。避免阻塞应用的正常发布而需要回滚。应用程序被Karmada 接管后发生未知错误。需要避免，防止联邦后资源不可控，需要回滚。回滚流程：
管理员通过容器管理平台将需要回滚的应用从迁移白名单中删除。并注释应用程序对应的工作负载和关联资源。修改执行控制器源代码。 Execution-controller在最终调用update/create时发现了上面的注解，并没有处理。修改defaultInterpreter源码，发现上面的注解ReviseReplica并没有修改副本数量。这将阻止Karmada 控制平面和成员集群之间的连接。为什么这里不直接从Karmada 删除资源？主要目的是避免删除此类高风险操作，并方便后续恢复后重新连接Karmada。3.4.3 迁移策略
应用迁移Karmada 原则：
大家好，今天小编来为大家解答Kubernetes 多集群实践思考与探索这个问题，很多人还不知道，现在让我们一起来看看吧！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/6068.html
用户评论
最近在研究Kubernetes多集群部署，感觉这篇文章挺有启发.
有20位网友表示赞同！
想要深入了解K8s的多集群方案，看这篇51CTO的文章是个好主意。
有18位网友表示赞同！
写的好！分享一些实际案例能更直观一些。
有20位网友表示赞同！
作为一名新手，想学习一下多集群的实践经验，这篇文章看起来不错!
有8位网友表示赞同！
对K8s的多集群场景很感兴趣，这篇博客的内容应该能帮到我！
有10位网友表示赞同！
了解不同类型的K8s架构，文章里分享的想法很有价值。
有15位网友表示赞同！
感觉多集群部署确实会带来一些挑战，这篇文章或许能提供一些解决方案吧？
有6位网友表示赞同！
学习一下多集群实践的思考和探索，提升下水平。
有12位网友表示赞同！
K8s管理越来越复杂了，多集群场景要更加灵活的控制手段。
有11位网友表示赞同！
51CTO的文章质量一般不错，这个K8s的多集群实践很有深度。
有19位网友表示赞同！
想学习一些多集群部署的最佳实践，这篇文章看起来挺合适的.
有14位网友表示赞同！
Kubernetes生态在发展，多集群的应用场景也越来越广泛。
有12位网友表示赞同！
需要关注K8s容器编排工具的发展趋势，多集群架构很可能会成为主流。
有12位网友表示赞同！
多集群部署对资源管理和网络配置都有更高的要求。
有19位网友表示赞同！
看了标题，感觉这篇文章能帮我更好地理解多集群的复杂性。
有10位网友表示赞同！
K8s的多集群实践是个很有挑战性的议题，需要不断探索和改进
有7位网友表示赞同！
希望这篇文章能够分享一些实用的经验和工具，方便我们在实践中运用。
有17位网友表示赞同！
很多企业都开始采用多集群部署，这篇文章能提供一些有价值的参考？
有20位网友表示赞同！
对K8s的架构设计一直很感興趣，希望能从文章中得到一些新思路。
有17位网友表示赞同！