Kubernetes 多集群思考、实践和探索
内容提要
运维派是国内最早的IT运维技术社区，提供多集群多活建设、混合云建设、多集群生命周期管理、多集群应用分发部署、多集群监控告警等内容。Federation v1和v2是多集群项目，Karmada是基于它们开发的，提供多云和混合云场景下的多集群应用程序管理。多集群落地实践包括应用部署、监控告警、南北流量管理和东西流量管理。多集群应用迁移需要备份和资源充足，可以使用Velero工具备份，然后迁移rollout、service和ingress对象。
延伸解读
多集群建设的核心驱动力
文章指出多集群建设主要出于三个目的：多活建设提高业务可用性，避免单集群或单数据中心故障导致业务中断；混合云建设引入公有云弹性资源应对大促节假日的资源洪峰；控制故障爆炸半径。这些驱动力反映了企业从单集群向多集群演进的实际需求，也提示读者在规划多集群时需明确自身目标，是侧重容灾、弹性还是隔离。
联邦方案演进与选型启示
Federation v1因基于Annotation分发资源导致API臃肿，且对多版本集群API兼容性差而被弃用；Federation v2改用CRD和Controller，通过FederatedTypeConfig、Placement和Overrides实现资源分发，但RSP功能有限且已被社区废弃。Karmada继承两者概念，使用kube-apiserver作为API Server，支持任意资源，并通过PropagationPolicy和OverridePolicy控制分发。读者可从中了解联邦技术的迭代逻辑，为选
非联邦落地实践的关键点
文章提到实际落地采用非联邦方式，依赖现有自动化运维平台和发布系统扩展多集群支持。监控方面需修改Prometheus配置，添加集群唯一标识并配置远端写入；南北流量通过外层Nginx反向代理各集群Ingress Node，权重根据Pod数量自动调整；东西流量通过Calico BGP拉平网络，服务发现使用Nacos。这些实践表明，多集群落地不一定依赖联邦方案，结合现有工具链改造同样可行。
多集群应用迁移的注意事项
迁移前需确保所有集群已通过Velero备份到统一S3桶，并检查目标集群资源是否充足。若资源不足，需考虑降级方案，如迁移副本数减半、优先迁移核心服务。迁移过程涉及rollout、service、ingress对象的创建与源集群资源的删除，并同步更新元数据。文章提供的伪代码展示了迁移流程，但读者需注意实际迁移中可能遇到的资源竞争、数据一致性和回滚策略等问题。
Q&A
为什么需要多集群架构？
多集群架构可以提高业务应用的可用性，避免单个集群或数据中心故障导致业务不可用，并利用公有云资源应对业务高峰。
Federation v2与v1有什么区别？
Federation v2通过CRD和Controller替代了v1的Annotation方式，改进了资源分发，避免了v1的兼容性问题。
Karmada是什么？
Karmada是基于Kubernetes Federation开发的项目，旨在为多云和混合云场景下的多集群应用程序管理提供自动化解决方案。
如何进行多集群应用迁移？
多集群应用迁移需要备份资源并确保目标集群资源充足，推荐使用Velero工具进行备份，然后迁移rollout、service和ingress对象。
多集群监控告警需要注意什么？
多集群监控告警需修改Prometheus配置，确保适应多集群环境，并添加集群唯一标识。
南北流量和东西流量管理的区别是什么？
南北流量管理通过Nginx反向代理实现，而东西流量管理则通过Calico BGP进行网络连接。
