k8s教程（21）-pod之容灾调度

原创

阿甘兄_ 2022-12-31 10:34:13 ©著作权

文章标签 kubernetes 容器化技术云原生 Pod 调度策略 文章分类 虚拟化云计算

©著作权归作者所有：来自51CTO博客作者阿甘兄_的原创作品，请联系作者获取转载授权，否则将追究法律责任

文章目录

01 引言
02 如何实现？
03 举例
04 文末

01 引言

声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记

我们可以将Pod的各种常规调度策略认为是将整个集群视为一个整体，然后进行 “打散或聚合” 的调度。

当我们的集群是为了容灾而建设的跨区域的多中心（多个Zone)集群，即集群中的节点位于不同区域的机房时，比如：

北京、上海、广州、武汉，要求每个中心的应用相互容灾备份，又能同时提供服务，此时最好的调度策略就是将需要容灾的应用均匀调度到各个中心，当某个中心出现问题时，又自动调度到其他中心均匀分布，

Pod的多中心均匀分布调度效果图如下所示（不管每个中心的Nod节点数量如何）：

k8s教程（21）-pod之容灾调度_云原生

02 如何实现？

用普通的基于Node标签选择的调度方式也可以实现上述效果，比如为每个
Zone都建立一个Deployment，Pod的副本总数除以Zone的数量就是每个分区的
Pod副本数量。但这样做有个问题：如果某个Zone失效，那么这个Zone的Pod就无法迁移到其他Zone。

另外，topology.kubernetes.io/zone就是Kubernetes默认支持的重要拓扑域之
一，那是否可以用Pod的亲和性调度来解决这个问题呢？不能，因为Pod的亲和性调度用于解决相关联的Pod的调度问题，不能保证被依赖的Pod被均匀调度到多个Zone。

为了满足这种容灾场景下的特殊调度需求，在Kubernetes1.16版本中首次引入Even Pod Spreading特性，用于通过topologyKey属性识别Zone，并通过设置新的参数topologySpreadConstraints来将Pod均匀调度到不同的Zone。

03 举例

举个例子，假如我们的集群被划分为多个Zone，我们有一个应用（对应的Pod标签为 app=foo)需要在每个Zone均匀调度以实现容灾，则可以定义YAML文件如下：

spec: 
topologySpreadConstraints:  
- maxSkew: 1
  whenUnsatisfiable: DoNotSchedule
  topologyKey: topology.kubernetes.io/zone
  selector:
    matchLabels:
      app: foo

在以上YAML定义中，关键的参数是maxSkew，用于指定Pod在各个Zone上调度时能容忍的最大不均衡数：

值越大，表示能接受的不均衡调度越大；
值越小，表示各个Zone的Pod数量分布越均匀。

为了理解maxSkew，我们需要先理解skew参数的计算公式：

skew[topo]=count[topo]-min(count[topo])

即每个拓扑区域的skew值都为该区域包括的目标Pod数量与整个拓扑区域最少Pod数量的差，而naxSkew就是最大的skew值。

假如在上面的例子中有3个拓扑区域，分别为Zone A、Zone B及Zone C，有3个目标Pod需要调度到这些拓扑区域，那么前两个毫无疑问会被调度到Zone A和Zone B，Even Pod Spreading调度效果如图所示：

k8s教程（21）-pod之容灾调度_kubernetes_02

那么，第3个Pod会被调度到哪里呢？我们可以手动计算每个Zone的skew：

首先计算出min(count[topo])是0，对应Zone C；
于是Zone A的skew=1-0=1，Zone B的skew=1-0=0，Zone C的skew=0-0=0，于是第3个Pod应该被放在Zone C，此时min(count[topo])的值就变成了1，而实际的maxSkew的值为0，符合预期设置；
如果我们把maxSkew设置为2，则在这种情况下，第3个Pod被放在
Zone A或Zone B都是符合要求的。