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

公众号：黑客下午茶