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

系列

目錄

  • 資料區域性性

    • 資料區域性性設定
    • 如何為卷設定資料區域性性
      • 更改預設全域性設定
      • 使用 Longhorn UI 更改單個卷的資料位置
      • 使用 StorageClass 為單個卷設定資料區域性性
  • 意外分離後恢復卷
  • 使用 Longhorn 處理節點故障
    • 當 Kubernetes 節點出現故障時會發生什麼
    • 節點宕機時的 Longhorn Pod 刪除策略
      • 卷附件恢復策略

        • 卷附件恢復策略never （Kubernetes 預設）
        • 卷附件恢復策略 wait （Longhorn 預設）
        • 卷附件恢復策略 immediate
    • 當發生故障的 Kubernetes 節點恢復時會發生什麼

資料區域性性

資料區域性性設定(data locality setting)旨在在以下情況下啟用：只要有可能，至少應在與使用該卷的 pod 相同的節點上排程 Longhorn 卷的一個副本。我們將擁有本地副本的特性稱為具有 data locality。

例如，當叢集的網路不好時，資料區域性性(data locality)會很有用，因為擁有本地副本會增加捲的可用性。

資料區域性性(data locality)對於分散式應用程式（例如資料庫）也很有用，其中在應用程式級別而不是卷級別實現高可用性。在這種情況下，每個 Pod 只需要一個卷，因此每個卷都應該與使用它的 Pod 排程在同一節點上。此外，卷排程的預設 Longhorn 行為可能會導致分散式應用程式出現問題。問題是，如果一個 Pod 有兩個副本，並且每個 Pod 副本都有一個卷，Longhorn 不知道這些卷具有相同的資料，不應排程在同一個節點上。因此 Longhorn 可以在同一節點上排程相同的副本，從而阻止它們為工作負載提供高可用性。

當資料區域性性被禁用時，Longhorn 卷可以由叢集中任何節點上的副本支援，並由執行在叢集中任何節點上的 pod 訪問。

資料區域性性設定

Longhorn 目前支援兩種 data locality 設定模式：

  • disabled. 這是預設選項。在與附加捲（工作負載）相同的節點上可能有也可能沒有副本。

  • best-effort. 此選項指示 Longhorn 嘗試將副本保留在與附加捲（工作負載）相同的節點上。Longhorn 不會停止該卷，即使它由於環境限制而無法將副本保留在附加捲（工作負載）的本地，例如：磁碟空間不足、磁碟標籤不相容等。

如何為卷設定資料區域性性

可以通過三種方式為 Longhorn 卷設定 data locality：

更改預設全域性設定

您可以在 Longhorn UI 設定中更改 data locality 的全域性預設設定。

全域性設定僅用作預設值，類似於副本計數(replica count)。

它不會更改任何現有卷的設定。

當建立卷時未指定(data locality)，Longhorn 將使用全域性預設設定來確定卷的 data locality。

使用 Longhorn UI 更改單個卷的資料位置

您可以使用 Longhorn UI 在建立卷時設定 data locality。

您還可以在 volume detail 頁面中更改卷建立後的 data locality setting。

使用 StorageClass 為單個卷設定資料區域性性

Longhorn 還將 data locality setting 公開為 StorageClass 中的引數。

您可以使用指定的 data locality setting 建立 StorageClass，然後使用 StorageClass 建立 PVC。

例如，下面的 YAML 檔案定義了一個 StorageClass，它告訴 Longhorn CSI driver 將 data locality 設定為 best-effort：

kind: StorageClass

apiVersion: storage.k8s.io/v1

metadata:

  name: hyper-converged

provisioner: driver.longhorn.io

allowVolumeExpansion: true

parameters:

  numberOfReplicas: "2"

  dataLocality: "best-effort"

  staleReplicaTimeout: "2880" # 48 hours in minutes

  fromBackup: ""

意外分離後恢復卷

當發生意外分離(unexpected detachment)時，可能發生在 Kubernetes upgrade、Docker reboot或網路斷開連線期間，如果 pod 由控制器管理（例如：deployment、statefulset、daemonset 等），Longhorn 會自動刪除工作負載 pod。通過刪除 pod，它的控制器會重新啟動 pod，Kubernetes 處理卷重新附加(reattachment)和重新掛載(remount)。

如果您不希望 Longhorn 自動刪除 workload pod，您可以在 Longhorn UI 的設定 Automatically Delete Workload Pod when The Volume Is Detached Unexpectedly(卷意外分離時自動刪除工作負載 Pod) 中進行設定。

對於沒有控制器的 Pod，Longhorn 不會刪除它們，因為如果 Longhorn 刪除，則沒有人會重新啟動它們。

要恢復意外分離的卷，您必須手動刪除並重新建立沒有控制器的 pod。

使用 Longhorn 處理節點故障

當 Kubernetes 節點出現故障時會發生什麼

本節旨在告知使用者節點故障(node failure)期間會發生什麼以及恢復期間會發生什麼。

一分鐘後，kubectl get nodes 將報告失敗節點的 NotReady。

大約五分鐘後，NotReady 節點上的所有 Pod 的狀態將更改為 Unknown 或 NodeLost。

StatefulSets 具有穩定的 identity，因此 Kubernetes 不會為使用者強制刪除 pod。

請參閱有關強制刪除 StatefulSet 的官方 Kubernetes 文件。

Deployments 沒有穩定的 identity，但是對於 Read-Write-Once 型別的儲存，由於它不能同時附加到兩個節點，Kubernetes 建立的新 pod 將無法啟動，因為 RWO 卷仍連線到舊 pod，位於丟失的節點上。

在這兩種情況下，Kubernetes 都會自動驅逐丟失節點上的 pod（為 pod 設定刪除時間戳），然後嘗試用舊卷重新建立一個新的卷。

因為被驅逐的 pod 會卡在 Terminating 狀態，並且附加的卷不能被釋放/重用(released/reused)，如果沒有管理(admin)或儲存(storage)軟體的干預，新的 pod 將卡在 ContainerCreating 狀態。

節點宕機時的 Longhorn Pod 刪除策略

Longhorn 提供了一個選項來幫助使用者在宕機的節點上自動強制刪除 StatefulSet/Deployment 的終止 pod。

強制刪除後，Kubernetes 將分離 Longhorn 卷並在新節點上啟動替換 pod。

您可以在 Longhorn UI 或 Settings reference 的 Settings 選項卡中的 Pod Deletion Policy When Node is Down(節點宕機時的 Pod 刪除策略)中找到有關設定選項的更多詳細資訊。

卷附件恢復策略

如果您決定強制刪除 pod（手動或在 Longhorn 的幫助下），Kubernetes 將需要大約 6 分鐘的時間來刪除與 Pod 關聯的 VolumeAttachment 物件，然後最終將卷與丟失的節點分離並允許它由新 pod 使用。

這 6 分鐘的時間段在 Kubernetes 中是硬編碼的：如果丟失節點上的 pod 被強制刪除，則相關卷將無法正確解除安裝。然後 Kubernetes 會等待這個固定的超時時間直接清理 VolumeAttachment 物件。

為了解決這個問題，我們提供了 3 種不同的卷附件恢復策略。

卷附件恢復策略never （Kubernetes 預設）

Longhorn 不會從故障節點恢復 Volume Attachment，這與 Kubernetes 的預設行為一致。

使用者需要強制刪除終止的 pod，此時 Longhorn 將從故障節點恢復 Volume Attachment。

然後允許掛起的替換 pod(replacement pod)在請求的卷可用的情況下正確啟動。

卷附件恢復策略 wait （Longhorn 預設）

Longhorn 將等待恢復 Volume Attachment，直到所有終止 pod(terminating pod)刪除寬限期過去。

由於此時需要節點 kubelet 刪除 Pod，並且 Pod 仍然可用，我們可以得出結論，故障節點 Kubelet 無法刪除 Pod。

此時 Longhorn 將從故障節點恢復 Volume Attachment。

然後允許掛起的替換 pod(replacement pod) 在請求的卷可用的情況下正確啟動。

卷附件恢復策略 immediate

只要有待處理的替換 Pod(replacement pod) 可用，Longhorn 就會從故障節點恢復 Volume Attachment。

然後允許掛起的替換 pod(replacement pod)在請求的卷可用的情況下正確啟動。

當發生故障的 Kubernetes 節點恢復時會發生什麼

如果節點在故障後 5 到 6 分鐘內重新聯機，Kubernetes 將重新啟動 Pod、解除安裝(unmount)和重新安裝(re-mount)卷，而無需重新附加捲(re-attaching)和 VolumeAttachment 清理。

因為卷引擎(volume engines)會在節點宕機後關閉，所以這種直接重新安裝將不起作用，因為該裝置不再存在於節點上。

在這種情況下，Longhorn 將分離並重新附加捲以恢復卷引擎，以便 pod 可以安全地重新掛載/重用卷(remount/reuse)。

如果節點在故障後 5-6 分鐘內沒有重新上線，Kubernetes 將嘗試基於 pod eviction 機制刪除所有無法訪問的 pod，這些 pod 將處於 Terminating 狀態。有關詳細資訊，請參閱 pod eviction timeout。

然後，如果故障節點稍後恢復，Kubernetes 將重新啟動那些終止的 pod，分離卷(detach the volumes)，等待舊的 VolumeAttachment 清理，並重用重新附加和重新掛載(re-attach & re-mount)卷。通常這些步驟可能需要 1 ~ 7 分鐘。

在這種情況下，分離(detaching)和重新附加(re-attaching)操作已經包含在 Kubernetes 恢復過程中。因此不需要額外的操作，Longhorn 卷將在上述步驟後可用。

對於上述所有恢復場景，Longhorn 將通過 Kubernetes 的關聯(association)自動處理這些步驟。

公眾號：黑客下午茶