如何對(duì) StatefulSet 進(jìn)行“滾動(dòng)更新”（rolling update）？

你只要修改 StatefulSet 的 Pod 模板，就會(huì)自動(dòng)觸發(fā)“滾動(dòng)更新”:

kubectl patch statefulset mysql --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"mysql:5.7.23"}]'

在這里，我使用了 kubectl patch 命令。它的意思是，以“補(bǔ)丁”的方式（JSON 格式的）修改一個(gè) API 對(duì)象的指定字段，也就是我在后面指定的“spec/template/spec/containers/0/image”。

這樣，StatefulSet Controller 就會(huì)按照與 Pod 編號(hào)相反的順序，從最后一個(gè) Pod 開(kāi)始，逐一更新這個(gè) StatefulSet 管理的每個(gè) Pod。而如果更新發(fā)生了錯(cuò)誤，這次“滾動(dòng)更新”就會(huì)停止。此外，StatefulSet 的“滾動(dòng)更新”還允許我們進(jìn)行更精細(xì)的控制，比如金絲雀發(fā)布（Canary Deploy）或者灰度發(fā)布，這意味著應(yīng)用的多個(gè)實(shí)例中被指定的一部分不會(huì)被更新到最新的版本。

這個(gè)字段，正是 StatefulSet 的 spec.updateStrategy.rollingUpdate 的 partition 字段。

比如，現(xiàn)在我將前面這個(gè) StatefulSet 的 partition 字段設(shè)置為 2：

kubectl patch statefulset mysql -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'

其中，kubectl patch 命令后面的參數(shù)（JSON 格式的），就是 partition 字段在 API 對(duì)象里的路徑。所以，上述操作等同于直接使用 kubectl edit 命令，打開(kāi)這個(gè)對(duì)象，把 partition 字段修改為 2。

這樣，我就指定了當(dāng) Pod 模板發(fā)生變化的時(shí)候，比如 MySQL 鏡像更新到 5.7.23，那么只有序號(hào)大于或者等于 2 的 Pod 會(huì)被更新到這個(gè)版本。并且，如果你刪除或者重啟了序號(hào)小于 2 的 Pod，等它再次啟動(dòng)后，也會(huì)保持原先的 5.7.2 版本，絕不會(huì)被升級(jí)到 5.7.23 版本。

下面重點(diǎn)講解一個(gè)\知識(shí)點(diǎn)：DaemonSet

顧名思義，DaemonSet 的主要作用，是讓你在 Kubernetes 集群里，運(yùn)行一個(gè) Daemon Pod。 所以，這個(gè) Pod 有如下三個(gè)特征：

• 這個(gè) Pod 運(yùn)行在 Kubernetes 集群里的每一個(gè)節(jié)點(diǎn)（Node）上；
• 每個(gè)節(jié)點(diǎn)上只有一個(gè)這樣的 Pod 實(shí)例；
• 當(dāng)有新的節(jié)點(diǎn)加入 Kubernetes 集群后，該 Pod 會(huì)自動(dòng)地在新節(jié)點(diǎn)上被創(chuàng)建出來(lái)；而當(dāng)舊節(jié)點(diǎn)被刪除后，它上面的 Pod 也相應(yīng)地會(huì)被回收掉。

這個(gè)機(jī)制聽(tīng)起來(lái)很簡(jiǎn)單，但 Daemon Pod 的意義確實(shí)是非常重要的

列舉幾個(gè)例子：

• 各種網(wǎng)絡(luò)插件的 Agent 組件，都必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上，用來(lái)處理這個(gè)節(jié)點(diǎn)上的容器網(wǎng)絡(luò)；
• 各種存儲(chǔ)插件的 Agent 組件，也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上，用來(lái)在這個(gè)節(jié)點(diǎn)上掛載遠(yuǎn)程存儲(chǔ)目錄，操作容器的 Volume 目錄；
• 各種監(jiān)控組件和日志組件，也必須運(yùn)行在每一個(gè)節(jié)點(diǎn)上，負(fù)責(zé)這個(gè)節(jié)點(diǎn)上的監(jiān)控信息和日志搜集。

更重要的是，跟其他編排對(duì)象不一樣，DaemonSet 開(kāi)始運(yùn)行的時(shí)機(jī)，很多時(shí)候比整個(gè) Kubernetes 集群出現(xiàn)的時(shí)機(jī)都要早。

這個(gè)乍一聽(tīng)起來(lái)可能有點(diǎn)兒奇怪。但其實(shí)你來(lái)想一下：如果這個(gè) DaemonSet 正是一個(gè)網(wǎng)絡(luò)插件的 Agent 組件呢？

這個(gè)時(shí)候，整個(gè) Kubernetes 集群里還沒(méi)有可用的容器網(wǎng)絡(luò)，所有 Worker 節(jié)點(diǎn)的狀態(tài)都是 NotReady（NetworkReady=false）。這種情況下，普通的 Pod 肯定不能運(yùn)行在這個(gè)集群上。所以，這也就意味著 DaemonSet 的設(shè)計(jì)，必須要有某種“過(guò)人之處”才行。

API 對(duì)象的定義

為了弄清楚 DaemonSet 的工作原理，我們還是按照老規(guī)矩，先從它的 API 對(duì)象的定義說(shuō)起。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: k8s.gcr.io/fluentd-elasticsearch:1.20
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

這個(gè) DaemonSet，管理的是一個(gè) fluentd-elasticsearch 鏡像的 Pod。這個(gè)鏡像的功能非常實(shí)用：通過(guò) fluentd 將 Docker 容器里的日志轉(zhuǎn)發(fā)到 ElasticSearch 中。

可以看到，DaemonSet 跟 Deployment 其實(shí)非常相似，只不過(guò)是沒(méi)有 replicas 字段；它也使用 selector 選擇管理所有攜帶了 name=fluentd-elasticsearch 標(biāo)簽的 Pod。

而這些 Pod 的模板，也是用 template 字段定義的。在這個(gè)字段中，我們定義了一個(gè)使用 fluentd-elasticsearch:1.20 鏡像的容器，而且這個(gè)容器掛載了兩個(gè) hostPath 類型的 Volume，分別對(duì)應(yīng)宿主機(jī)的 /var/log 目錄和 /var/lib/docker/containers 目錄。

顯然，fluentd 啟動(dòng)之后，它會(huì)從這兩個(gè)目錄里搜集日志信息，并轉(zhuǎn)發(fā)給 ElasticSearch 保存。這樣，我們通過(guò) ElasticSearch 就可以很方便地檢索這些日志了。

需要注意的是，Docker 容器里應(yīng)用的日志，默認(rèn)會(huì)保存在宿主機(jī)的 /var/lib/docker/containers/{{. 容器 ID}}/{{. 容器 ID}}-json.log 文件里，所以這個(gè)目錄正是 fluentd 的搜集目標(biāo)。

那么，DaemonSet 又是如何保證每個(gè) Node 上有且只有一個(gè)被管理的 Pod 呢？

顯然，這是一個(gè)典型的“控制器模型”能夠處理的問(wèn)題。

DaemonSet Controller，首先從 Etcd 里獲取所有的 Node 列表，然后遍歷所有的 Node。這時(shí)，它就可以很容易地去檢查，當(dāng)前這個(gè) Node 上是不是有一個(gè)攜帶了 name=fluentd-elasticsearch 標(biāo)簽的 Pod 在運(yùn)行。

而檢查的結(jié)果，可能有這么三種情況：

沒(méi)有這種 Pod，那么就意味著要在這個(gè) Node 上創(chuàng)建這樣一個(gè) Pod；

有這種 Pod，但是數(shù)量大于 1，那就說(shuō)明要把多余的 Pod 從這個(gè) Node 上刪除掉；

正好只有一個(gè)這種 Pod，那說(shuō)明這個(gè)節(jié)點(diǎn)是正常的。

其中，刪除節(jié)點(diǎn)（Node）上多余的 Pod 非常簡(jiǎn)單，直接調(diào)用 Kubernetes API 就可以了。

如何在指定的 Node 上創(chuàng)建新 Pod 呢？

如果你已經(jīng)熟悉了 Pod API 對(duì)象的話，那一定可以立刻說(shuō)出答案：用 nodeSelector，選擇 Node 的名字即可。

不過(guò)，在 Kubernetes 項(xiàng)目里，nodeSelector 其實(shí)已經(jīng)是一個(gè)將要被廢棄的字段了。因?yàn)?，現(xiàn)在有了一個(gè)新的、功能更完善的字段可以代替它，即：nodeAffinity。我來(lái)舉個(gè)例子：

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: metadata.name
            operator: In
            values:
            - node-geektime

在這個(gè) Pod 里，我聲明了一個(gè) spec.affinity 字段，然后定義了一個(gè) nodeAffinity。其中，spec.affinity 字段，是 Pod 里跟調(diào)度相關(guān)的一個(gè)字段。關(guān)于它的完整內(nèi)容，我會(huì)在講解調(diào)度策略的時(shí)候再詳細(xì)闡述。

nodeAffinity 含義

而在這里，我定義的 nodeAffinity 的含義是：

requiredDuringSchedulingIgnoredDuringExecution：它的意思是說(shuō)，這個(gè) nodeAffinity 必須在每次調(diào)度的時(shí)候予以考慮。同時(shí)，這也意味著你可以設(shè)置在某些情況下不考慮這個(gè) nodeAffinity；

這個(gè) Pod，將來(lái)只允許運(yùn)行在“metadata.name”是“node-geektime”的節(jié)點(diǎn)上。

在這里，你應(yīng)該注意到 nodeAffinity 的定義，可以支持更加豐富的語(yǔ)法，比如 operator: In（即：部分匹配；如果你定義 operator: Equal，就是完全匹配），這也正是 nodeAffinity 會(huì)取代 nodeSelector 的原因之一。

所以，我們的 DaemonSet Controller 會(huì)在創(chuàng)建 Pod 的時(shí)候，自動(dòng)在這個(gè) Pod 的 API 對(duì)象里，加上這樣一個(gè) nodeAffinity 定義。其中，需要綁定的節(jié)點(diǎn)名字，正是當(dāng)前正在遍歷的這個(gè) Node。

當(dāng)然，DaemonSet 并不需要修改用戶提交的 YAML 文件里的 Pod 模板，而是在向 Kubernetes 發(fā)起請(qǐng)求之前，直接修改根據(jù)模板生成的 Pod 對(duì)象。這個(gè)思路，也正是我在前面講解 Pod 對(duì)象時(shí)介紹過(guò)的。

此外，DaemonSet 還會(huì)給這個(gè) Pod 自動(dòng)加上另外一個(gè)與調(diào)度相關(guān)的字段，叫作 tolerations。這個(gè)字段意味著這個(gè) Pod，會(huì)“容忍”（Toleration）某些 Node 的“污點(diǎn)”（Taint）。

而 DaemonSet 自動(dòng)加上的 tolerations 字段，格式如下所示：

apiVersion: v1
kind: Pod
metadata:
  name: with-toleration
spec:
  tolerations:
  - key: node.kubernetes.io/unschedulable
    operator: Exists
    effect: NoSchedule

這個(gè) Toleration 的含義是：“容忍”所有被標(biāo)記為 unschedulable“污點(diǎn)”的 Node；“容忍”的效果是允許調(diào)度。

而在正常情況下，被標(biāo)記了 unschedulable“污點(diǎn)”的 Node，是不會(huì)有任何 Pod 被調(diào)度上去的（effect: NoSchedule）?？墒牵珼aemonSet 自動(dòng)地給被管理的 Pod 加上了這個(gè)特殊的 Toleration，就使得這些 Pod 可以忽略這個(gè)限制，繼而保證每個(gè)節(jié)點(diǎn)上都會(huì)被調(diào)度一個(gè) Pod。當(dāng)然，如果這個(gè)節(jié)點(diǎn)有故障的話，這個(gè) Pod 可能會(huì)啟動(dòng)失敗，而 DaemonSet 則會(huì)始終嘗試下去，直到 Pod 啟動(dòng)成功。

這時(shí)，你應(yīng)該可以猜到，我在前面介紹到的DaemonSet 的“過(guò)人之處”，其實(shí)就是依靠 Toleration 實(shí)現(xiàn)的。

假如當(dāng)前 DaemonSet 管理的，是一個(gè)網(wǎng)絡(luò)插件的 Agent Pod，那么你就必須在這個(gè) DaemonSet 的 YAML 文件里，給它的 Pod 模板加上一個(gè)能夠“容忍”node.kubernetes.io/network-unavailable“污點(diǎn)”的 Toleration。正如下面這個(gè)例子所示：

...
template:
    metadata:
      labels:
        name: network-plugin-agent
    spec:
      tolerations:
      - key: node.kubernetes.io/network-unavailable
        operator: Exists
        effect: NoSchedule

在 Kubernetes 項(xiàng)目中，當(dāng)一個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)插件尚未安裝時(shí)，這個(gè)節(jié)點(diǎn)就會(huì)被自動(dòng)加上名為node.kubernetes.io/network-unavailable的“污點(diǎn)”。

而通過(guò)這樣一個(gè) Toleration，調(diào)度器在調(diào)度這個(gè) Pod 的時(shí)候，就會(huì)忽略當(dāng)前節(jié)點(diǎn)上的“污點(diǎn)”，從而成功地將網(wǎng)絡(luò)插件的 Agent 組件調(diào)度到這臺(tái)機(jī)器上啟動(dòng)起來(lái)。

這種機(jī)制，正是我們?cè)诓渴?Kubernetes 集群的時(shí)候，能夠先部署 Kubernetes 本身、再部署網(wǎng)絡(luò)插件的根本原因：因?yàn)楫?dāng)時(shí)我們所創(chuàng)建的 Weave 的 YAML，實(shí)際上就是一個(gè) DaemonSet。

至此，通過(guò)上面這些內(nèi)容，你應(yīng)該能夠明白，DaemonSet 其實(shí)是一個(gè)非常簡(jiǎn)單的控制器。在它的控制循環(huán)中，只需要遍歷所有節(jié)點(diǎn)，然后根據(jù)節(jié)點(diǎn)上是否有被管理 Pod 的情況，來(lái)決定是否要?jiǎng)?chuàng)建或者刪除一個(gè) Pod。

只不過(guò)，在創(chuàng)建每個(gè) Pod 的時(shí)候，DaemonSet 會(huì)自動(dòng)給這個(gè) Pod 加上一個(gè) nodeAffinity，從而保證這個(gè) Pod 只會(huì)在指定節(jié)點(diǎn)上啟動(dòng)。同時(shí)，它還會(huì)自動(dòng)給這個(gè) Pod 加上一個(gè) Toleration，從而忽略節(jié)點(diǎn)的 unschedulable“污點(diǎn)”。

當(dāng)然，你也可以在 Pod 模板里加上更多種類的 Toleration，從而利用 DaemonSet 實(shí)現(xiàn)自己的目的。比如，在這個(gè) fluentd-elasticsearch DaemonSet 里，我就給它加上了這樣的 Toleration：

tolerations:
- key: node-role.kubernetes.io/master
  effect: NoSchedule

這是因?yàn)樵谀J(rèn)情況下，Kubernetes 集群不允許用戶在 Master 節(jié)點(diǎn)部署 Pod。因?yàn)?，Master 節(jié)點(diǎn)默認(rèn)攜帶了一個(gè)叫作node-role.kubernetes.io/master的“污點(diǎn)”。所以，為了能在 Master 節(jié)點(diǎn)上部署 DaemonSet 的 Pod，我就必須讓這個(gè) Pod“容忍”這個(gè)“污點(diǎn)”。

以上就是k8s編排之DaemonSet知識(shí)點(diǎn)詳解的詳細(xì)內(nèi)容，更多關(guān)于k8s編排DaemonSet的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論