如何看待云原生下的多活容灾

为什么业务容器化之后,多活容灾变得更具挑战?

  1. 不像之前使用CVM或者物理机部署时,业务容器化之后,底层资源的可控程度更弱,应用实例生命周期更短、变化更快,这就给业务做容灾部署带来了更大的难度。

  2. 除此之外,当前自研业务大部分都是面向Kubernetes集群进行编排的,业务需要感知Kubernetes集群和集群内的资源拓扑,然后再结合自己的容灾部署拓扑去选择合适的集群,配置合适的调度标签进行强有序的多活部署。当每个地域/可用区的集群数量很多时,这个动作也会变的较重。

  3. 有的云管平台,每个集群底层的资源拓扑并不是一层不变的,有些集群包含了多个Zone的资源,有些集群只有单个Zone的资源。有人会问,为什么我们不固化一个标准来建设集群,比如每个集群就只配置单个Zone的资源,或者每个集群都覆盖某个地域的所有Zone的资源。因为这两种集群资源模式都存在各自致命的问题:

  • 如果每个集群只配置单个Zone的资源,当每个Zone资源都是充足的情况下,这并不会有什么问题,但是当某个Zone出现资源不足时,业务紧急情况需要继续扩容,此时一定是允许一定比例的应用实例扩容到其他Zone,此时业务只能手动去找其他Zone的集群,对Workload进行扩容操作。如果业务在每个集群都配置了HPA,那么资源不足的那个Zone对应的集群的HPA将持续告警,无法自动扩容到其他Zone。

  • 如果每个集群都覆盖多个Zone的资源,那么业务只需要在单个集群部署就能实现多Zone容灾的需求,这需要容器平台提供单集群内多Zone拓扑分布比例的调度能力,比如应用A需要在广三、广四部署1:1的拓扑。Kubernetes 1.27 支持的”Topology Spread Constraints“ 这一Beta特性还不足以满足我们的场景,除了它需要升级Kubernetes集群版和配置的复杂度、使用心智负担之外,还不支持自定义各个Zone分布比例等场景。另外,这种集群最后一定会演变为超大规模的单集群,它的故障爆炸半径也非常大。

业务需要底层多活容灾部署,到底是业务自己去根据复杂的底层集群和资源拓扑去精细化构建,还是说应该由容器平台来完全兜底,并作为一种不对用户感知的默认的产品能力?

不同的业务场景对容灾的需求存在差异,所以底层PaaS平台需要提供不同的业务容灾部署策略,客户根据自己的容灾需求配置部署策略。应用托管平台根据客户配置的部署策略声明,进行自动化的Reconcile,包括首次部署业务时,以及遇到底层集群、可用区甚至地域级别的异常时,始终能保证客户的部署策略能最大化的得到满足。

所以,业务的容灾,是需要业务和应用托管平台都关注的事情,业务评估自己的容灾场景,平台提供对应的容灾部署能力。

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-23 06:54:02       168 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-23 06:54:02       185 阅读
  3. 在Django里面运行非项目文件

    2024-07-23 06:54:02       155 阅读
  4. Python语言-面向对象

    2024-07-23 06:54:02       169 阅读

热门阅读

  1. PyTorch 中的一个函数:torch.pow

    2024-07-23 06:54:02       30 阅读
  2. 图像处理 -- ISP调优(tuning)的步骤整理

    2024-07-23 06:54:02       29 阅读
  3. 时间和空间复杂度

    2024-07-23 06:54:02       31 阅读
  4. vivado IOBDELAY

    2024-07-23 06:54:02       33 阅读
  5. React/Vue项目解决跨域的方法

    2024-07-23 06:54:02       33 阅读
  6. 第五节shell脚本中的运行流程控制(3.2)

    2024-07-23 06:54:02       31 阅读
  7. 后端存储流程结构的思考

    2024-07-23 06:54:02       27 阅读
  8. 【DevOps系列】构建Devops系统

    2024-07-23 06:54:02       32 阅读