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 上調度副本。

公眾號：黑客下午茶