Longhorn 企業級雲原生分散式容器儲存-券(Volume)和節點(Node)

內容來源於官方 Longhorn 1.1.2 英文技術手冊。

系列

• Longhorn 是什麼?
• Longhorn 雲原生分散式塊儲存解決方案設計架構和概念
• Longhorn 企業級雲原生容器儲存解決方案-部署篇

建立 Longhorn 卷

在本教程中，您將學習如何建立與 Longhorn 卷對應的持久卷 (PV) 和持久卷宣告 (PVC) 的 Kubernetes 持久儲存資源。您將使用 kubectl 為使用 Longhorn 儲存類(storage class)的工作負載動態配置儲存。

本節假設您瞭解 Kubernetes 持久儲存(persistent storage)的工作原理。有關更多資訊，請參閱 Kubernetes 文件。

使用 kubectl 建立 Longhorn 卷

首先，您將建立一個 Longhorn StorageClass。Longhorn StorageClass 包含用於配置持久卷的引數。

接下來，建立引用 StorageClass 的 PersistentVolumeClaim。 最後，PersistentVolumeClaim 作為卷掛載在 Pod 中。

部署 Pod 時，Kubernetes master 會檢查 PersistentVolumeClaim 以確保可以滿足資源請求。如果儲存可用，Kubernetes master 將建立 Longhorn 卷並將其繫結到 Pod。

1. 使用以下命令建立一個名為 longhorn 的 StorageClass：

   kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/examples/storageclass.yaml
   

   建立了以下示例 StorageClass：

   kind: StorageClass
   apiVersion: storage.k8s.io/v1
   metadata:
     name: longhorn
   provisioner: driver.longhorn.io
   allowVolumeExpansion: true
   parameters:
     numberOfReplicas: "3"
     staleReplicaTimeout: "2880" # 48 hours in minutes
     fromBackup: ""
   #  diskSelector: "ssd,fast"
   #  nodeSelector: "storage,fast"
   #  recurringJobs: '[{"name":"snap", "task":"snapshot", "cron":"*/1 * * * *", "retain":1},
   #                   {"name":"backup", "task":"backup", "cron":"*/2 * * * *", "retain":1,
   #                    "labels": {"interval":"2m"}}]'
   

2. 通過執行以下命令建立一個使用 Longhorn 卷的 Pod：

   kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/examples/pod_with_pvc.yaml
   

   一個名為 volume-test 的 Pod 和一個名為 longhorn-volv-pvc 的 PersistentVolumeClaim 被啟動。PersistentVolumeClaim 引用 Longhorn StorageClass：

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: longhorn-volv-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: longhorn
     resources:
       requests:
         storage: 2Gi
   

   PersistentVolumeClaim 作為卷掛載在 Pod 中：

   apiVersion: v1
   kind: Pod
   metadata:
     name: volume-test
     namespace: default
   spec:
     containers:
     - name: volume-test
       image: nginx:stable-alpine
       imagePullPolicy: IfNotPresent
       volumeMounts:
       - name: volv
         mountPath: /data
       ports:
       - containerPort: 80
     volumes:
     - name: volv
       persistentVolumeClaim:
         claimName: longhorn-volv-pvc
   

在沒有 Kubernetes StorageClass 的情況下將工作負載繫結到 PV

可以使用 Longhorn StorageClass 將工作負載繫結到 PV，而無需在 Kubernetes 中建立 StorageClass 物件。

由於 Storage Class 也是一個用於將 PVC 與 PV 匹配的欄位，它不必由 Provisioner 建立，您可以使用自定義 StorageClass 名稱手動建立 PV，然後建立要求相同 StorageClass 的 PVC 名稱。

當 PVC 請求不作為 Kubernetes 資源存在的 StorageClass 時，Kubernetes 會嘗試將您的 PVC 繫結到具有相同 StorageClass 名稱的 PV。
StorageClass 將用作查詢匹配 PV 的標籤，並且僅使用標有 StorageClass 名稱的現有 PV。

如果 PVC 命名一個 StorageClass，Kubernetes 將：

1. 查詢標籤與 StorageClass 匹配的現有 PV
2. 查詢現有的 StorageClass Kubernetes 資源。 如果 StorageClass 存在，它將用於建立 PV。

使用 Longhorn UI 建立 Longhorn 卷

由於 Longhorn 卷在建立 PV/PVC 時已經存在，因此不需要 StorageClass 來動態配置 Longhorn 卷。 但是，欄位 storageClassName 應該在 PVC/PV 中設定，以用於 PVC 邊界目的(bounding purpose)。並且使用者無需建立相關的 StorageClass 物件。

預設情況下，Longhorn 建立的 PV/PVC 的 StorageClass 是 longhorn-static。使用者可以根據需要在 Setting - General - Default Longhorn Static StorageClass Name 中進行修改。

使用者需要手動刪除 Longhorn 建立的 PVC 和 PV。

為現有 Longhorn 卷建立 PV/PVC

現在使用者可以通過我們的 Longhorn UI 為現有的 Longhorn 卷建立 PV/PVC。
新建立的 pod 只能使用分離的卷。

刪除 Longhorn 卷

完成使用 Longhorn 捲進行儲存後，有多種方法可以刪除該卷，具體取決於您使用該卷的方式。

通過 Kubernetes 刪除卷

Note: 此方法僅適用於卷由 StorageClass 供應(provisioned)且 Longhorn 卷的 PersistentVolume 將其回收策略(Reclaim Policy)設定為刪除(Delete)的情況。

您可以通過 Kubernetes 刪除卷，方法是刪除使用已發放的 Longhorn 卷的 PersistentVolumeClaim。這將導致 Kubernetes 清理 PersistentVolume，然後刪除 Longhorn 中的卷。

通過 Longhorn 刪除卷

所有 Longhorn 卷，無論它們是如何建立的，都可以通過 Longhorn UI 刪除。

要刪除單個卷，請轉到 UI 中的 Volume 頁面。在 Operation 下拉選單下，選擇 Delete。在刪除卷之前，系統會提示您確認。

要同時刪除多個卷，您可以在 Volume 頁面勾選多個卷，然後選擇頂部的 Delete。

Note: 如果 Longhorn 檢測到某個卷繫結到 PersistentVolume 或 PersistentVolumeClaim，那麼一旦您刪除該卷，這些資源也將被刪除。在繼續刪除之前，您將在 UI 中收到警告。Longhorn 還會在刪除附加捲時發出警告，因為它可能正在使用中。

節點空間使用

在本節中，您將更好地瞭解 Longhorn UI 呈現的空間使用(space usage)資訊。

整個叢集空間使用情況

在 Dashboard 頁面，Longhorn 會顯示叢集空間使用資訊：

Schedulable: 可用於 Longhorn 卷排程的實際空間(actual space)。

Reserved: 為其他應用程式和系統保留的空間(space reserved)。

Used: Longhorn、系統和其他應用程式已使用的實際空間(space reserved)。

Disabled: 不允許排程 Longhorn 卷的磁碟/節點(disks/nodes)的總空間。

每個節點的空間使用

在 Node 頁面，Longhorn 會顯示每個節點的空間分配(space allocation)、排程(schedule)和使用資訊(usage info)：

Size 列：Longhorn 卷可以使用的最大實際可用空間(max actual available space)。 它等於節點的總磁碟空間減去保留空間。

Allocated 列：左邊的數字是卷排程(volume scheduling)已使用的大小，並不代表該空間已被用於 Longhorn 卷資料儲存。正確的數字是卷排程的 max 大小，它是 Size 乘以 Storage Over Provisioning Percentage 的結果。(在上圖中，Storage Over Provisioning Percentage 是 500。）因此，這兩個數字之間的差異（我們稱之為可分配空間allocable space）決定了卷副本是否可以排程到這個節點。

Used列：左邊部分表示該節點當前使用的空間。整個條形表示節點的總空間。

注意，當 Storage Over Provisioning Percentage 設定為大於 100 的值時，可分配空間可能會大於節點的實際可用空間。
如果卷使用率高，卷快照中會儲存大量歷史資料，請注意小心為這個設定使用一個大的值。

卷大小

在本節中，您將更好地理解與卷大小相關的概念。

卷 Size

• 這是您在建立卷時設定的內容，我們將在本文件中將其稱為 nominal size 以避免歧義。
• 由於卷本身只是 Kubernetes 中的一個 CRD 物件，並且資料儲存在每個副本中，因此這實際上是每個副本的 nominal size。
• 我們將此欄位稱為 "nominal size" 的原因是 Longhorn 副本使用 sparse files(稀疏檔案) 來儲存資料，該值是稀疏檔案的表觀大小（它們可以擴充套件到的最大大小）。每個副本使用的實際大小不等於這個 nominal size。
• 基於此 nominal size，副本將被安排到在卷建立期間具有足夠可分配空間的那些節點。
• nominal size 的值決定了卷正在使用時的最大可用空間。換句話說，卷持有的當前活動資料大小不能大於其 nominal size。

卷 Actual Size

• actual size 表示每個副本在對應節點上使用的實際空間。
• 由於快照中儲存的所有歷史資料和活動資料都將計算為實際大小，因此最終值可以大於 nominal size。
• 只有在卷執行時才會顯示實際大小。

一個有助於理解卷 Size 和卷 Actual size 的例子：

在這裡，我們將有一個示例來解釋在一堆 I/O 和快照(snapshot)相關操作之後卷 size 和 actual size 如何變化。

插圖表示 一個副本(one replica) 的檔案組織。卷頭(volume head)和快照(snapshots)實際上是我們上面提到的稀疏檔案(sparse files)。

1. 建立一個 5Gi 卷，然後將其掛載到節點上。如 Figure 1 所示。
   • 對於這個空卷(empty volume)，名義上的 size 是 5Gi，而 actual size 幾乎是 0。
   • 卷中有一些元資訊，因此 actual size 不完全是 0。
2. 在卷掛載點寫入 2Gi 資料（data#1）並建立快照（snapshot#1）。請參見插圖中的 Figure 2。
   • 現在 data#1 儲存在 snapshot#1 中，actual size 為 2Gi。

3. 從掛載點刪除 data#1。
   • data#1 刪除的真相是 data#1 在檔案系統級別(the filesystem level)中被標記為已刪除（例如 ext4 中的 inode 刪除）。由於 Longhorn 在塊級執行，不瞭解檔案系統，因此刪除後不會釋放儲存 data#1 的磁碟塊/空間(blocks/space)。
   • data#1 檔案系統級別刪除資訊儲存在當前卷頭(volume head)檔案中。對於 snapshot#1，data#1 仍然保留為歷史資料。
   • actual size 仍然是 2Gi。

4. 在卷掛載中寫入 4Gi 資料（data#2），然後再拍攝一張快照（snapshot#2）。請參見插圖中的 Figure 3。
   • 現在 actual size 為 6Gi，大於 nominal size。
   • 在塊級別的 2 個快照之間存在重疊（參見 Figure 3 中的 2 個快照），因為 data#1 在 snapshot#2 中被標記為已刪除，因此檔案系統會重新使用該空間。

5. 刪除 snapshot#1 並等待快照清除完成。 請參見插圖中的 Figure 4。
   • 這裡 Longhorn 實際上將 snapshot#1 與 snapshot#2 合併。
   • 對於合併期間的重疊部分，較新的資料（data#2）將保留在塊中。然後刪除一些歷史資料，體積縮小（示例中從 6.1Gi 到 4.65Gi）。

檢視使用卷的工作負載

現在，使用者可以識別現有 Longhorn 持久卷 (PV) 的當前工作負載或工作負載歷史記錄，以及它們繫結到持久卷宣告 (PVC) 的歷史記錄。

從 Longhorn UI，轉到 Volume 選項卡。 每個 Longhorn 卷都列在頁面上。
Attached To 列顯示使用卷的 workload 的名稱。如果單擊 workload name，您將能夠看到更多詳細資訊，包括 workload type、pod name 和 status。

Longhorn 卷詳細資訊頁面上也提供了工作負載資訊。要檢視詳細資訊，請單擊卷名稱：

State: attached
...
Namespace:default
PVC Name:longhorn-volv-pvc
PV Name:pvc-0edf00f3-1d67-4783-bbce-27d4458f6db7
PV Status:Bound
Pod Name:teststatefulset-0
Pod Status:Running
Workload Name:teststatefulset
Workload Type:StatefulSet

歷史

在 workload 不再使用 Longhorn volume 後，卷詳細資訊頁面會顯示最近使用過該卷的工作負載的歷史狀態：

Pod 上次使用時間：幾秒前
...
Last Pod Name: teststatefulset-0
Last Workload Name: teststatefulset
Last Workload Type: Statefulset

如果設定了這些欄位，它們表示當前沒有工作負載正在使用此卷。

當 PVC 不再繫結到卷時，將顯示以下狀態：

Last time bound with PVC:a few seconds ago
Last time used by Pod:32 minutes ago
Last Namespace:default
Last Bounded PVC Name:longhorn-volv-pvc

如果設定了 Last time bound with PVC 欄位，則表示當前該卷沒有繫結 PVC。相關欄位將顯示使用此卷的最新工作負載。

儲存標籤

概述

儲存標籤(storage tag)功能只允許使用某些節點或磁碟來儲存 Longhorn 卷資料。
例如，對效能敏感的資料只能使用可以標記為 fast、ssd 或 nvme 的高效能磁碟，或者只能使用標記為 baremetal 的高效能節點。

此功能同時支援磁碟(Disk)和節點(Node)。

設定

可以使用 Longhorn UI 設定標籤：

1. Node -> Select one node -> Edit Node and Disks
2. 單擊 +New Node Tag 或 +New Disk Tag 去新增新標籤。

節點(Node)或磁碟(Disk)上的所有現有計劃副本(scheduled replica)都不會受到新標籤的影響。

用法

當為一個卷指定多個標籤時，磁碟和節點（磁碟所屬的）必須具有所有指定的標籤才能使用。

UI

建立卷時，請在 UI 中指定磁碟標記(disk tag)和節點標記(node tag)。

Kubernetes

使用 Kubernetes StorageClass 設定來指定標籤。

例如：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-fast
provisioner: driver.longhorn.io
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "480" # 8 hours in minutes
  diskSelector: "ssd"
  nodeSelector: "storage,fast"

歷史

• Original feature request
• Available since v0.6.0

卷擴容

卷分兩個階段擴充套件。首先，Longhorn 擴充套件前端（塊裝置），然後擴充套件檔案系統。

為了防止前端擴充套件受到意外資料讀寫(R/W)的干擾，Longhorn 僅支援離線擴充套件。detached(分離)的卷將自動附加到具有維護模式的隨機節點。

擴容(expansion)期間不允許重建(rebuilding)和新增(adding)副本，並且在重建或新增副本時不允許擴容。

如果卷沒有通過 CSI 介面擴充套件（例如：對於 Kubernetes 早於 v1.16），則對應的 PVC 和 PV 的容量不會改變。

前置條件

• Longhorn 版本必須是 v0.8.0 或更高版本。
• 要擴充套件的卷必須處於 detached(分離) 狀態。

展開 Longhorn 卷

有兩種方法可以擴充套件 Longhorn volume：使用 PersistentVolumeClaim (PVC) 和使用 Longhorn UI。

如果您使用的是 Kubernetes v1.14 或 v1.15，則只能使用 Longhorn UI 擴充套件卷。

通過 PVC

此方法僅適用於：

• Kubernetes 版本 v1.16 或更高版本。
• PVC 由 Kubernetes 使用 Longhorn StorageClass 動態配置。
• 相關 StorageClass 中的欄位 allowVolumeExpansion 應為 true。

如果可以，建議使用這種方法，因為 PVC 和 PV 會自動更新，擴充套件後一切都保持一致。

用法：找到 Longhorn volume 對應的 PVC，然後修改請求的 PVC 的 spec.resources.requests.storage：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"longhorn-simple-pvc","namespace":"default"},"spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"1Gi"}},"storageClassName":"longhorn"}}
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
    volume.beta.kubernetes.io/storage-provisioner: driver.longhorn.io
  creationTimestamp: "2019-12-21T01:36:16Z"
  finalizers:
  - kubernetes.io/pvc-protection
  name: longhorn-simple-pvc
  namespace: default
  resourceVersion: "162431"
  selfLink: /api/v1/namespaces/default/persistentvolumeclaims/longhorn-simple-pvc
  uid: 0467ae73-22a5-4eba-803e-464cc0b9d975
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: longhorn
  volumeMode: Filesystem
  volumeName: pvc-0467ae73-22a5-4eba-803e-464cc0b9d975
status:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 1Gi
  phase: Bound

通過 Longhorn UI

如果你的 Kubernetes 版本是 v1.14 或者 v1.15，這種方式是 Longhorn volume 擴容的唯一選擇。

使用方法：在 Longhorn UI 的卷頁面，單擊卷的 Expand。

檔案系統擴充套件

只有在以下情況下，Longhorn 才會嘗試擴充套件檔案系統:

• 擴充套件的大小應大於當前大小。
• Longhorn volume 中有一個 Linux filesystem。
• Longhorn volume 中使用的檔案系統如下：
  • ext4
  • XFS
• Longhorn 卷使用塊裝置前端。

處理卷恢復

如果將卷恢復為較小尺寸的快照，則卷的前端仍保持擴充套件後的尺寸。但檔案系統大小將與恢復快照的大小相同。在這種情況下，您需要手動處理檔案系統：

1. 將卷附加到隨機節點。

2. 登入對應節點，對檔案系統進行擴容。

   如果檔案系統是 ext4，則可能需要在手動調整檔案系統大小之前 mounted 和 umounted 卷。
   否則，執行 resize2fs 可能會導致錯誤：

   resize2fs: Superblock checksum does not match superblock while trying to open ......
   Couldn't find valid filesystem superblock.
   

   按照以下步驟調整檔案系統的大小：

   mount /dev/longhorn/<volume name> <arbitrary mount directory>
   umount /dev/longhorn/<volume name>
   mount /dev/longhorn/<volume name> <arbitrary mount directory>
   resize2fs /dev/longhorn/<volume name>
   umount /dev/longhorn/<volume name>
   

3. 如果檔案系統是 xfs，可以直接掛載，然後擴充套件檔案系統。

   mount /dev/longhorn/<volume name> <arbitrary mount directory>
   xfs_growfs <the mount directory>
   umount /dev/longhorn/<volume name>
   

驅逐禁用磁碟或節點上的副本

Longhorn 支援自動驅逐(auto eviction)，用於將所選禁用磁碟或節點上的副本驅逐到其他合適的磁碟和節點。 同時，在驅逐期間保持相同級別的高可用性。

Note: 此驅逐功能只能在所選磁碟或節點已禁用排程時啟用。並且在驅逐期間，無法重新啟用所選磁碟或節點進行排程。

Note: 此驅逐功能適用於已附加(Attached)和已分離(Detached)的卷。如果卷是“分離的(Detached)”，Longhorn 將在驅逐前自動附加它，並在驅逐完成後自動分離它。

預設情況下，磁碟或節點的 Eviction Requested 為 false。為了在逐出期間保持相同級別的高可用性，Longhorn 僅在每個卷的副本重建成功後逐出一個副本。

選擇要驅逐的磁碟或節點

要驅逐節點的磁碟，

1. 前往 Node 選項卡，選擇節點之一，然後在下拉選單中選擇 Edit Node and Disks。
2. 確保磁碟已禁用排程並將 Scheduling 設定為 Disable。
3. 將 Eviction Requested 設定為 true 並儲存。

要驅逐節點，

1. 前往 Node 選項卡，選擇節點之一，然後在下拉選單中選擇 Edit Node。
2. 確保節點已禁用排程並將 Scheduling 設定為 Disable。
3. 將 Eviction Requested 設定為 true，然後儲存。

取消磁碟或節點驅逐

要取消對磁碟或節點的驅逐，請將相應的 Eviction Requested 並設定為 false。

檢查驅逐狀態

一旦驅逐成功，所選磁碟或節點上的 Replicas 數量應減少為 0。

如果您單擊 Replicas 編號，它將顯示此磁碟上的副本名稱(replica name)。
當您點選 replica name 時，Longhorn UI 會將網頁重定向到相應的 volume page ，並顯示 volume status。
如果有任何錯誤，例如：no space，或找不到另一個 schedulable disk（排程失敗），將顯示錯誤。所有錯誤都將記錄在事件日誌中。

如果在驅逐期間發生任何錯誤，驅逐將被暫停，直到新空間被清除或被取消。如果取消驅逐，所選磁碟或節點上的剩餘副本將保留在磁碟或節點上。

多磁碟支援

Longhorn 支援在節點上使用多個磁碟來儲存卷資料。

預設情況下，主機上的 /var/lib/longhorn 將用於儲存卷資料。您可以通過新增新磁碟來避免使用預設目錄，然後禁用 /var/lib/longhorn 的排程。

新增磁碟

要為節點新增新磁碟，請轉到 Node 選項卡，選擇其中一個節點，然後在下拉選單中選擇 Edit Disks。

要新增任何其他磁碟，您需要：

1. 將主機上的磁碟掛載到某個目錄。
2. 將掛載磁碟的路徑新增到節點的磁碟列表中。

Longhorn 將自動檢測有關磁碟的儲存資訊（例如，最大空間maximum space、可用空間available space），並在可能容納卷的情況下開始對其進行排程。不允許現有磁碟裝載的路徑。

可以保留一定數量的磁碟空間來阻止 Longhorn 使用它。它可以在磁碟的 Space Reserved 欄位中設定。對於節點上的非專用儲存磁碟很有用。

當可用計算資源不足時，kubelet 需要保持節點穩定性。這在處理不可壓縮的計算資源（例如記憶體或磁碟空間）時尤為重要。
如果這些資源耗盡，節點就會變得不穩定。為了避免 kubelet 排程多個卷後出現磁碟壓力(Disk pressure)問題，
預設情況下，Longhorn 預留了 30% 的根磁碟空間（/var/lib/longhorn）以保證節點穩定性。

Note:
由於 Longhorn 使用 filesystem ID 來檢測同一檔案系統的重複掛載，因此您不能在同一節點上新增與現有磁碟具有相同 filesystem ID 的磁碟。
詳情請見 https://github.com/longhorn/longhorn/issues/2477

為節點上的磁碟使用替代路徑

如果不想在節點上使用磁碟的原始掛載路徑(original mount path)，可以使用 mount --bind 為磁碟建立備用/別名(alternative/alias)路徑，
然後與 Longhorn 一起使用。請注意，軟連結 ln -s 將不起作用，因為它不會在 pod 內正確填充。

Longhorn 將使用 path 識別磁碟，因此使用者需要確保在節點重新啟動時正確安裝了備用路徑(alternative path)，例如：通過將它新增到 fstab。

移除磁碟

節點和磁碟可以從未來的排程中排除。請注意，如果為節點禁用了排程，則任何排程的儲存空間都不會自動釋放。

要刪除磁碟，需要滿足兩個條件：

• 必須禁用磁碟排程
• 沒有使用該磁碟的現有副本，包括任何處於錯誤狀態的副本。

一旦滿足這兩個條件，就應該允許您移除磁碟。

配置

有兩個全域性設定會影響卷的排程。

• StorageOverProvisioningPercentage 定義了 ScheduledStorage / (MaximumStorage - ReservedStorage) 的上限。預設值為 500(%)。 這意味著我們可以在 200 GiB 磁碟上安排總共 750 GiB Longhorn volumes，併為根檔案系統預留 50G。因為通常人們不會使用卷中的大量資料，我們將卷儲存為稀疏檔案(sparse files)。
• StorageMinimalAvailablePercentage 定義何時不能為磁碟安排更多卷。預設值為 10(%)。 MaximumStorage * StorageMinimalAvailablePercentage / 100 和 MaximumStorage - ReservedStorage 之間的較大值將用於確定磁碟是否執行不足並且無法安排更多卷。

請注意，目前無法保證空間卷使用不會超過 StorageMinimalAvailablePercentage，因為：

1. Longhorn 卷可以大於指定的大小，因為快照包含卷的舊狀態。
2. 預設情況下，Longhorn 會過度配置(over-provisioning)。

節點維護指南

本節介紹如何處理節點的計劃維護(planned maintenance)。

• 更新 Node OS 或 Container Runtime
• 更新 Kubernetes
• 移除磁碟
• 移除節點

更新 Node OS 或 Container Runtime

1. 封鎖節點。Longhorn 將在 Kubernetes 節點被封鎖時自動禁用節點排程。

2. 清空節點以將工作負載移動到其他地方。

   您將需要使用 --ignore-daemonsets 選項來清空節點，因為 Longhorn 部署了一些守護程式，例如 Longhorn manager、Longhorn CSI plugin、engine image。

   節點上的副本程式將在此階段停止。節點上的副本將顯示為 Failed。

    注意：預設情況下，如果節點上有一個卷的最後一個健康副本，
    Longhorn 將阻止節點完成 Drain 操作，
    以保護最後一個副本並防止工作負載中斷。
    您可以覆蓋設定中的行為，或者驅逐在清空之前將副本複製到其他節點。
   

   節點上的引擎程式會隨 Pod 一起遷移到其他節點。

    注意：如果節點上存在非 Kubernetes 建立的卷，Lognhorn 將阻止節點完成 Drain 操作，以防止潛在的工作負載中斷。
   

   drain 完成後，節點上應該沒有引擎或副本程式在執行。兩個例項管理器仍將在節點上執行，但它們是無狀態的，不會中斷現有工作負載。

    注意：通常您不需要在 drain 操作之前驅逐副本，只要您在其他節點上有健康的副本即可。一旦節點重新上線並解除封鎖，副本就可以在以後重複使用。
   

3. 執行必要的維護，包括關閉或重新啟動節點。

4. 解開(Uncordon)節點。Longhorn 會自動重新啟用節點排程。

   如果節點上存在現有副本，Longhorn 可能會使用這些副本來加快重建過程。
   您可以設定 Replica Replenishment Wait Interval setting 以自定義 Longhorn 應等待潛在可重用副本可用的時間。

更新 Kubernetes

按照官方 Kubernetes 升級文件 進行操作。

• 如果 Longhorn 安裝為 Rancher catalog app，請按照 Rancher 的 Kubernetes 升級指南 升級 Kubernetes。

移除磁碟

要移除磁碟：

1. 禁用磁碟排程。
2. 驅逐磁碟上的所有副本。
3. 刪除磁碟。

重用節點名稱

如果您使用相同的節點名稱替換了節點，則這些步驟也適用。
一旦新節點啟動，Longhorn 將識別出磁碟是不同的。
如果新節點使用與前一個節點相同的名稱，您需要先移除原始磁碟，然後將它們新增回新節點。

刪除節點

要刪除節點：

1. 禁用磁碟排程。

2. 驅逐節點上的所有副本。

3. 分離節點上的所有卷。

   如果節點已清空，則所有工作負載都應已遷移到另一個節點。

   如果還有任何其他卷保持連線，請在繼續之前分離它們。

4. 使用 Node 選項卡中的 Delete 從 Longhorn 中刪除節點。

   或者，使用以下命令從 Kubernetes 中刪除節點：

    kubectl delete node <node-name>
   

5. Longhorn 會自動從叢集中刪除該節點。

分離卷

關閉所有使用 Longhorn 卷的 Kubernetes Pod 以分離卷。實現此目標的最簡單方法是刪除所有工作負載，然後在升級後重新建立它們。如果這是不可取的，則可能會暫停某些工作負載。

在本節中，您將瞭解如何修改每個工作負載以關閉其 pod。

Deployment

使用 kubectl edit deploy/<name> 編輯 deployment。

設定 .spec.replicas 為 0.

StatefulSet

使用 kubectl edit statefulset/<name> 編輯 statefulset。

Set .spec.replicas to 0.

DaemonSet

無法暫停此工作負載。

使用 kubectl delete ds/<name> 刪除 daemonset。

Pod

使用 kubectl delete pod/<name> 刪除 pod。

無法掛起(suspend)不受 workload controller 管理的 pod。

CronJob

使用 kubectl edit cronjob/<name> 編輯 cronjob。

設定 .spec.suspend 為 true。

等待任何當前正在執行的作業(jobs)完成，或通過刪除相關 pod 來終止它們。

Job

考慮允許單次執行作業(single-run job)完成。

否則，使用 kubectl delete job/<name> 刪除 job。

ReplicaSet

使用 kubectl edit replicaset/<name> 編輯 replicaset。

設定 .spec.replicas 為 0.

ReplicationController

使用 kubectl edit rc/<name> 編輯 replicationcontroller。

設定 .spec.replicas 為 0。

等待 Kubernetes 使用的卷完成分離。

然後從 Longhorn UI 分離所有剩餘的卷。這些卷很可能是通過 Longhorn UI 或 REST API 在 Kubernetes 之外建立(created)和附加(attached)的。

排程

在本節中，您將瞭解 Longhorn 如何根據多種因素排程副本。

排程策略

Longhorn 的排程策略有兩個階段。如果前一階段得到滿足，排程器只會進入下一階段。否則，排程將失敗。

如果設定了任何標籤以便選擇進行排程，則在選擇節點或磁碟時，節點標籤和磁碟標籤必須匹配。

第一階段是 node and zone selection stage(節點和區域選擇階段)。 Longhorn 將根據 Replica Node Level Soft Anti-Affinity 和 Replica Zone Level Soft Anti-Affinity 設定過濾節點和區域。

第二階段是disk selection stage(磁碟選擇階段)。 Longhorn 將根據 Storage Minimal Available Percentage、Storage Over Provisioning Percentage 以及其他與磁碟相關的因素（例如請求的磁碟空間）篩選滿足第一階段的磁碟 .

節點和區域選擇階段

首先，如果可能，Longhorn 將始終嘗試在具有新區域的新節點上安排新副本。在此上下文中，"new" 表示卷的副本尚未排程到區域或節點，"existing" 是指節點或區域已經排程了副本。

這時候，如果 Replica Node Level Soft Anti-Affinity 和 Replica Zone Level Soft Anti-Affinity 設定都沒有勾選，並且如果沒有新節點有新的 zone，Longhorn 不會排程副本。

然後，Longhorn 將尋找具有現有區域的新節點。如果可能，它將在具有現有區域的新節點上排程新副本。

此時，如果沒有勾選 Replica Node Level Soft Anti-Affinity，勾選了 Replica Zone Level Soft Anti-Affinity，且沒有具有現有分割槽的新節點，Longhorn 不會排程副本。

最後，Longhorn 將查詢具有現有區域的現有節點來排程新副本。此時需要勾選 Replica Node Level Soft Anti-Affinity 和 Replica Zone Level Soft Anti-Affinity。

磁碟選擇階段

一旦滿足節點和區域階段，Longhorn 將決定是否可以在節點的磁碟上排程副本。Longhorn 將檢查所選節點上具有匹配標籤的可用磁碟、總磁碟空間和可用磁碟空間。

例如，在節點和區域階段之後，Longhorn 發現 Node A 滿足將副本排程到節點的要求。Longhorn 將檢查此節點上的所有可用磁碟。

假設此節點有兩個磁碟：可用空間為 1 GB 的 Disk X 和可用空間為 2 GB 的 Disk Y。
並且要排程的 replica Longhorn 需要 1 GB。在預設的 Storage Minimal Available Percentage(儲存最小可用百分比) 為 25 的情況下，
如果此 Disk Y 與磁碟標籤匹配，Longhorn 只能在 Disk Y 上排程副本，否則 Longhorn 將在此副本選擇上返回失敗。
但是如果 Storage Minimal Available Percentage 設定為 0，並且 Disk X 也匹配磁碟標籤，Longhorn 可以在 Disk X 上排程副本。

公眾號：黑客下午茶