Helm Kubernetes 包管理器 DaemonSet

這裡寫自定義目錄标題

• Helm Kubernetes 包管理器
• • 軟體簡介
• 什麼是 DaemonSet
• • 簡介
  • nodeAffinity
  • • 場景
    • 案例
    • 作用
  • Toleration
  • • 場景
    • 案例
    • 作用
  • ControllerRevision
  • • 概念
    • 復原原理
    • 總結

Helm Kubernetes 包管理器

軟體簡介

Helm 幫助您管理 Kubernetes 應用程式 ——Helm Charts 幫助您定義、安裝和更新最複雜的 Kubernetes 應用程式。

Helm 可以使用 Charts 啟動 Kubernetes 叢集, 提供可用的工作流:

• 一個 Redis 叢集
• 一個 Postgres 資料庫
• 一個 HAProxy 邊界負載均衡

特性:

• 查找并使用流行的軟體, 将其打包為 Helm Charts, 以便在 Kubernetes 中運作
• 以 Helm Charts 的形式共享您自己的應用程式
• 為您的 Kubernetes 應用程式建立可複制的建構
• 智能地管理您的 Kubernetes 清單檔案
• 管理 Helm 包的發行版
• Chart 是 Kubernetes 的單元, Helm 的架構參考 Homebrew。

安裝:

• Homebrew 使用者使用 brew install kubernetes-helm.
• Chocolatey 使用者使用 choco install kubernetes-helm.
• Scoop 使用者使用 scoop install helm.
• GoFish 使用者使用 gofish install helm.
• Snap 使用者使用 sudo snap install helm --classic.

什麼是 DaemonSet

簡介

DaemonSet 的主要作用, 是在 Kubernetes 叢集裡, 運作一個

Daemon Pod

。 DaemonSet 隻管理 Pod 對象, 然後通過 nodeAffinity 和 Toleration 這兩個排程器的小功能, 保證了每個節點上有且隻有一個 Pod。

是以, 這個 Pod 有如下三個特征:

• 這個 Pod 運作在 Kubernetes 叢集裡的每一個節點(Node)上。
• 每個節點上隻有一個這樣的 Pod 執行個體。
• 當有新的節點加入 Kubernetes 叢集後, 該 Pod 會自動地在新節點上被建立出來。
• 當舊節點被删除後, 它上面的 Pod 也相應地會被回收掉。

Daemon Pod

的意義确實是非常重要的。比如的作用:

• 網絡插件的 Agent 元件, 都必須運作在每一個節點上, 用來處理這個節點上的容器網絡。
• 存儲插件的 Agent 元件, 也必須運作在每一個節點上, 用來在這個節點上挂載遠端存儲目錄, 操作容器的 Volume 目錄。
• 監控元件和日志元件, 也必須運作在每一個節點上, 負責這個節點上的監控資訊和日志搜集。

nodeAffinity

我們的 DaemonSet Controller 會在建立 Pod 的時候, 自動在這個 Pod 的 API 對象裡, 加上這樣一個 nodeAffinity 定義。

場景

在這個 Pod 裡, 聲明了一個 spec.affinity 字段, 然後定義了一個 nodeAffinity。其中, spec.affinity 字段, 是 Pod 裡跟排程相關的一個字段。

案例

比如我們建立如下的一個 YAML 檔案:

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

關于上面參數的具體含義:

• requiredDuringSchedulingIgnoredDuringExecution

  這個代表 nodeAffinity 必須在每次排程的時候予以考慮, 同時, 這也意味着可以設定在某些情況下不考慮這個 nodeAffinity;

• 這個 Pod, 将來隻允許運作在"metadata.name"是"demo-node"的節點上。

作用

在 nodeAffinity 的定義處, 可以支援更加豐富的文法, 比如 operator: In(即: 部分比對)。

我們的 DaemonSet Controller 會在建立 Pod 的時候, 自動在這個 Pod 的 API 對象裡, 加上這樣一個 nodeAffinity 定義。

Toleration

場景

DaemonSet 還會給這個 Pod 自動加上另外一個與排程相關的字段, 叫作 tolerations。這個字段意味着這個 Pod, 會"容忍"(Toleration)某些 Node 的"污點"(Taint)。

案例

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

在正常情況下, 被标記了 unschedulable"污點"的 Node, 是不會有任何 Pod 被排程上去的(effect: NoSchedule)。可是, DaemonSet 自動地給被管理的 Pod 加上了這個特殊的 Toleration, 就使得這些 Pod 可以忽略這個限制, 繼而保證每個節點上都會被排程一個 Pod。

當然, 如果這個節點有故障的話, 這個 Pod 可能會啟動失敗, 而 DaemonSet 則會始終嘗試下去, 直到 Pod 啟動成功。

作用

通過這樣一個 Toleration, 排程器在排程這個 Pod 的時候, 就會忽略目前節點上的"污點", 進而成功地将網絡插件的 Agent 元件排程到這台機器上啟動起來。

這種機制, 正是我們在部署 Kubernetes 叢集的時候, 能夠先部署 Kubernetes 本身、再部署網絡插件的根本原因: 因為當時我們所建立的 Weave 的 YAML, 實際上就是一個 DaemonSet。

ControllerRevision

DaemonSet 使用 ControllerRevision, 來儲存和管理自己對應的"版本"。在 Kubernetes 項目裡, ControllerRevision 其實是一個通用的版本管理對象。這樣, Kubernetes 項目就巧妙地避免了每種控制器都要維護一套備援的代碼和邏輯的問題。

概念

Kubernetes v1.7 之後添加了一個 API 對象, 名叫 ControllerRevision, 專門用來記錄某種 Controller 對象的版本。

ControllerRevision 對象, 實際上是在 Data 字段儲存了該版本對應的完整的 DaemonSet 的 API 對象。并且, 在 Annotation 字段儲存了建立這個對象所使用的 kubectl 指令。

復原原理

現在 DaemonSet Controller 就可以使用這個曆史 API 對象, 對現有的 DaemonSet 做一次 PATCH 操作(等價于執行一次 kubectl apply -f “舊的 DaemonSet 對象”), 進而把這個 DaemonSet"更新"到一個舊版本。

這也是為什麼, 在執行完這次復原完成後, 會發現, DaemonSet 的 Revision 并不會從 Revision=2 退回到 1, 而是會增加成 Revision=3。這是因為, 一個新的 ControllerRevision 被建立了出來。

總結

DaemonSet 其實就是依靠 nodeAffinity 和 Toleration 實作的。這是一種不需要增加設計結構, 而直接使用标簽等方式完成的 Daemon 程序。這樣的結構非常符合 Kubernetes 的控制器模式, 一切皆對象。