一、 需求分析

当前kubernetes集群中的worker节点可以支持添加多可用区中的ECS，这种部署方式的目的是可以让一个应用的多个pod(至少两个)能够分布在不同的可用区，起码不能分布在同一个可用区，已达到高可用或者同城灾备的部署。

二、 效果图

三、 实现原理

为了实现上述的效果，kubernetes提供了pod的亲和性和反亲和性来保证pod在节点级别，可用区级别的高可用部署；具体的值为topologyKey：failure-domain.beta.kubernetes.io/zone。

四、 实现步骤

在ACK上创建完集群后，不论从哪个可用区添加节点，都会对该节点打上对应的可用区标签，比如，一个节点是属于北京可用区a的，那么在加入到kubernetes集群后，该节点上会有一个这样的标签：failure-domain.beta.kubernetes.io/zone: cn-beijing-a。

在有了上述标签后，对应用进行多可用区部署时，我们就可以使用一下yaml文件来使不同的pod分配到不同的可用区。

Yaml文件示例：

apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "failure-domain.beta.kubernetes.io/zone" containers: - name: redis-server image: redis:3.2-alpine

上面yaml文件中的podAntiAffinity:部分规定了node的反亲和性，并且由于使用了topologyKey: "failure-domain.beta.kubernetes.io/zone"，如果failure-domain.beta.kubernetes.io/zone这个key有三种value，比如cn-beijing-a，cn-beijing-b，cn-beijing-c；那么pod会被分配在这三个不同的可用区。并且由于使用了preferredDuringSchedulingIgnoredDuringExecution，所以如果pod个数大于可用区个数的话，pod会尽可能的放在不同的可用区，最后会出现多出来的pod会与原有pod在同一个可用区。

上面的使用方式还有很多种，包括node级别的，详细请参考：https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

由于云盘不能跨可用区挂载，如果有pod使用了存储卷，该pod需要被调度到与存储卷相同的可用区的机器上。

其他存储卷比如NAS，OSS是可以采用上述部署方式的。

作者：朱延生