引言
Cloud Native
分布式云多集群业务场景
Cloud Native
分布式云多集群因其灵活、可扩展性和地理分布等优势，被众多企业作为弹性需求、成本控制等方面的解决方案。其业务场景主要集中在如下几个方面：
弹性需求、资源成本
当企业的业务量呈现波动性，并且波动在不可预测的时候，比如电商网站在节假日或促销期间流量激增，一般在有本地 IDC 的情况下，同时利用公有云资源进行快速的弹性扩展，以满足峰值需求，而在业务低谷期收缩资源，从而节约成本。
业务跨国、多地分布
跨国公司可能需要在全球范围内快速部署应用和服务，同时遵守不同地区的数据主权法规。会结合本地私有云和全球分布的公有云资源快速扩展部署业务，满足业务连续性和合规要求。
数据保护、安全合规
企业可以将关键数据和系统在私有云和公有云之间做备份，利用公有云的地理冗余特性实现灾难恢复策略，增强业务连续性。同时在金融、医疗等行业，数据的存储位置和处理可能受到严格监管。需要在特定地理位置部署服务，确保数据合规性。
容灾备份、高可用性
在不同区域或环境中的多个集群中部署服务副本，一旦某个区域集群出现故障，流量可以迅速转移到其他正常运行的区域集群，确保服务连续性。
分布式云多集群监控的痛点
Cloud Native
监控数据碎片化
由于集群分布在不同的地域和环境中，传统的监控方式往往需要为每个集群单独安装数据采集，导致监控数据分散在多个平台上，难以形成全局视图，增加了统一数据分析和故障排查的难度。
运维效率低下
运维人员需要频繁切换监控界面，分别查看每个集群的状态 ，其中因为环境不一、区域不一也会增加查询成本，而无法直观地从整体上把握系统的健康状况。这种割裂的监控方式大大降低了运维效率，增加了误判和遗漏风险。
告警策略不统一
每个独立集群可能设置不同的告警阈值和通知策略，这不仅增加了管理复杂度，还可能导致告警风暴或重要事件被忽视，影响故障响应速度和质量。
升级和维护成本高
每个集群的监控系统独立升级和维护，不仅操作重复，而且新功能或补丁的部署难以做到统一和增加了技术债务。同时云上云下集群采集组件管控、升级方式不统一，会额外增加维护成本。
构建统一的监控方案
Cloud Native
阿里云可观测监控 Prometheus 版通过提供聚合实例，为构建跨越分布式云集群的统一监控需求提供了解决方案。概括来说主要分两个部分：
其一，鉴于分布式云多集群往往具备多集群、多地域乃至多云等特点，呈现出较高的异构性和复杂性，使用分布式云容器平台 ACK One 纳管不同环境集群，构建统一的云上运维管控能力，屏蔽不同环境下集群管控差异；
其二，在 ACK One 集群中使用统一的管控能力安装 Prometheus 采集组件并上报数据到云上，并通过 Prometheus 聚合实例提供统一监控视图。这样，在阿里云上为用户提供集群统一的监控、运维体验，解决了企业客户在使用分布式云多集群面临的监控痛点。该方案按照如下两个场景介绍：
场景一: 将云下（或三方云） K8s 集群监控迁到云上
方案流程
1）集群纳管： 使用 ACK One 注册集群对本地数据中心、三方公共云集群进行云上纳管 [ 1] ，使得该场景各环境 K8s 集群在云上运维管理层面得到一致的使用体验。
接入方式
步骤二：将目标集群纳管到注册集群。
接入效果
场景二 : 云上云下分布式多集群统一监控
方案流程
1）将监控统一迁到云上： 当您在云下或三方公共云上有 K8s 集群时，如场景一中描述的方案，先将监控能力统一搬迁到云上。至此，不同供应商、不同地域的各个 K8s 集群均可以使用阿里云可观测监控 Prometheus 版统一运维监控体验。
接入方式
