Pod在多可用区worker节点上的高可用部署

1、      需求分析

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

 

2、      效果图

3、      实现原理

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

 

4、      实现步骤

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

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

     Yaml文件示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  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

 

5、      注意问题（云盘）

因为云盘不能跨可用区挂载，若是有pod使用了存储卷，该pod须要被调度到与存储卷相同的可用区的机器上。

其余存储卷好比NAS，OSS是能够采用上述部署方式的。

原文连接 本文为云栖社区原创内容，未经容许不得转载。