采用多层故障保障机制，确保同一业务的不同实例会均衡分发到两地三中心的不同资源域，确保单个存储、单个集群甚至单个数据中心发生故障时，不会影响业务的整体可用性。
园区级故障（应用层调度）- > 机房级故障（PaaS自动调度）- > 设备级故障（PaaS自动调度）
在故障情况下，云平台通过容器重启及自动漂移，实现故障的自动恢复。
在整体的容器云实践下来，也遇到了一些问题，其中比较突出的就是一个PaaS层容器层的一个多集群的现状，k8s集群的总数由于种类多、业务场景非常的广泛，包括要支持不同GUP的设备，包括说我们的中间件数据库对底层的一些容器网络、容器存储的需求是不同的，势必会产生一些不同的解决方案，不同的业务场景就需要不同的集群；受到k8s本身的一个性能限制，每个集群都有node数量的上限；业务的扩展整体上是非常快的，包括一些传统的应用在源源不断的切入到k8s中；故障域分区多，以两地三中心的架构，至少有3个DC，每个DC内部还有不同的网络区域通过防火墙进行隔离，这样一个倍乘关系中间就会产生很多集群故障域的分布，基于以上几点目前k8s集群的总数已经接近数十个了，还是比较大的，而且任就在不断的扩张的一个过程中。
当前的一个现状，我们现有的解决方案还是依靠于我们容器云的云管平台，通过云管平台去纳管和运维一些多k8s集群；上层的业务应用需要自主取选择包括偏好、网络区域等对应的具体某一个k8s集群，选择后通过内部的故障域进行自动打散的一个调度。
现有的解决方案对于上层应用还是暴露出一些非常多的问题：
- 1、对上层应用来说，在具有业务峰值的时候自动伸缩能力，但是这个自动伸缩现在只是在集群内部的，没有一个整体的跨集群的自动伸缩的能力；
- 2、跨集群的自动调度能力，应用需要自主去选择；、
- 3、基于第二点导致的第三点，对上层的应用，整体集群是不透明的，实际上应用可能需求仅仅是需要去选择故障域，需要选择一些特殊的设备，但是并不需要去选择具体的一个k8s集群，这一层应该是对他透明的；
- 4、整体上没有一个集群故障层面的自动迁移能力，还是主要依靠于我们整体两地三中心的架构上的一个副本的冗余，那么这一块在故障自动化恢复的高可用能力是有缺失的；
优化架构选型
对这些现状定下一些目标，总共分成了五个模块：
- 1、集群管理部分，希望整体的多云多集群的解决方案能够具有一些基本的管理功能（包括集群的多生命周期管理、统一的一个api）；
- 2、资源管理部分，整体需要一个对k8s的一个本身资源对象的支持，包括是有一个资源重写的一个功能（overwrite差异化的子集群的一些配置），获得到资源的对象的状态；
- 3、整体夸集群的调度何自动伸缩能力；
- 4、容灾方面，跨集群的自动恢复吗，整个解决的管理面的一个解决方案跟运行的业务的服务集群应该是解耦的；
- 5、具有可扩展性，业务场景非常多，包括不同的业务调度能力，包括一些其他的能力，而且希望具有一定的社区支持度，希望是一个开源项目（企业内部自主可控、不希望花费更多的能力）；
技术架构
Karmada 已经开源，是一个比较合理的整体架构。
- 1、类k8s的形式部署，包括有api-server、controller-manager等，对已经拥有存量的k8s集群来说改造成本是比较小的，只要在上面部署一个管理集群就可以了；
- 2、karmada-controller-manager管理包括policy、binding、works等多种CRD资源作为管理端的资源对象，但是他没有嵌入到源生的我们想要部署的应用资源对象；
- 3、karmada仅仅管理说在集群间的调度，譬如deploment只关心部署到哪一个子集群并不关心在这个子集群中具体的一个分配，子集群自身的分配也是高度自治的；
karmada resource 如何分发？
- 1、集群要注册到karmada；
- 2、定义resource template；
- 3、制定分发策略；
- 4、制定overwride策略；
Propagation 机制：首先定义一个Propagation policy 策略，选择一个cluster no.1，需要这条策略到底匹配到哪些k8s的resource template，匹配的就是我们定义了一个namespace为default一个nginx的一个对deploment，支持cluster一个亲和性。
Work 机制：当Propagation binding产生A、B、C三个集群，通过找到这三个集群，binding controller 就会工作产生基于resource template以及绑定关系去产生了一个具体的works的一个对象，整体就是具体子集群中的一个resource封装。
