開發十年，就只剩下這套架構體系了！ >>>   

一、      需求分析

當前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/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

五、      注意問題（雲盤）

    由於雲盤不能跨可用區掛載，如果有pod使用了儲存卷，該pod需要被排程到與儲存卷相同的可用區的機器上。

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

相關推薦