Longhorn 企业级云原生容器存储解决方案-部署篇

为少

发布于 2021-08-26 14:38:04

2K0

发布于 2021-08-26 14:38:04

文章被收录于专栏：黑客下午茶黑客下午茶

内容来源于官方 Longhorn 1.1.2 英文技术手册。

系列

安装

Longhorn 可以通过多种方式安装在 Kubernetes 集群上：

Rancher catalog app
kubectl
Helm

安装要求

安装 Longhorn 的 Kubernetes 集群中的每个节点都必须满足以下要求：

与 Kubernetes 兼容的容器运行时（Docker v1.13+、containerd v1.3.7+ 等）
Kubernetes v1.16+.
- 推荐 Kubernetes v1.17+
open-iscsi 已安装，并且 iscsid 守护程序正在所有节点上运行。这是必要的，因为 Longhorn 依赖主机上的 iscsiadm 为 Kubernetes 提供持久卷。
RWX support 要求每个节点都安装 NFSv4 client。
主机文件系统支持 file extents 功能来存储数据。目前我们支持：
- ext4
- XFS
curl, findmnt, grep, awk, blkid, lsblk 必须安装。
Mount propagation 必须启用。

Longhorn workloads 必须能够以 root 身份运行才能正确部署和操作 Longhorn。

操作系统(`OS`)/发行版(`Distro`)特定配置

Google Kubernetes Engine (GKE) Longhorn 需要一些额外的设置才能正常运行。
K3s clusters 需要一些额外的设置。
RKE clusters with CoreOS 需要 csi-on-rke-and-coreos

使用 Environment Check Script

我们编写了一个脚本来帮助您收集有关这些因素的足够信息。

注意在运行 env check 脚本之前，可能需要在本地安装 jq。

运行脚本：

curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/scripts/environment_check.sh | bash

结果示例：

daemonset.apps/longhorn-environment-check created
waiting for pods to become ready (0/3)
all pods ready (3/3)

  MountPropagation is enabled!

cleaning up...
daemonset.apps "longhorn-environment-check" deleted
clean up complete

Pod 安全策略

从 v1.0.2 开始，Longhorn 附带了默认的 Pod 安全策略，该策略将为 Longhorn 提供必要的权限以使其能够正常运行。

Longhorn 无需特殊配置即可在启用了 Pod 安全策略的集群上正常工作。

注意 Mount Propagation

如果您的 Kubernetes 集群是由 Rancher v2.0.7+ 或更高版本提供的，则默认启用 MountPropagation 功能。

如果 MountPropagation 被禁用，Base Image 功能将被禁用。

安装 open-iscsi

用于安装 open-iscsi 的命令因 Linux 发行版而异。

对于 GKE，我们建议使用 Ubuntu 作为 guest OS image，因为它已经包含 open-iscsi。

您可能需要编辑 cluster security group(集群安全组) 以允许 SSH 访问。

对于 SUSE 和 openSUSE，请使用以下命令：

zypper install open-iscsi

对于 Debian 和 Ubuntu，请使用以下命令：

apt-get install open-iscsi

对于带有 EKS Kubernetes Worker AMI with AmazonLinux2 image 的 RHEL、CentOS 和 EKS，请使用以下命令：

yum install iscsi-initiator-utils

我们还提供了一个 iscsi 安装程序，使用户可以更轻松地自动安装 open-iscsi：

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/deploy/prerequisite/longhorn-iscsi-installation.yaml

部署完成后，运行以下命令来检查安装程序的 pod 状态：

kubectl get pod | grep longhorn-iscsi-installation
longhorn-iscsi-installation-49hd7   1/1     Running   0          21m
longhorn-iscsi-installation-pzb7r   1/1     Running   0          39m

也可以通过以下命令查看日志，查看安装结果：

kubectl logs longhorn-iscsi-installation-pzb7r -c iscsi-installation
...
Installed:
  iscsi-initiator-utils.x86_64 0:6.2.0.874-7.amzn2

Dependency Installed:
  iscsi-initiator-utils-iscsiuio.x86_64 0:6.2.0.874-7.amzn2

Complete!
Created symlink from /etc/systemd/system/multi-user.target.wants/iscsid.service to /usr/lib/systemd/system/iscsid.service.
iscsi install successfully

安装 NFSv4 client

用于安装 NFSv4 client 的命令因 Linux 发行版而异。

对于 Debian 和 Ubuntu，请使用以下命令：

apt-get install nfs-common

对于带有 EKS Kubernetes Worker AMI with AmazonLinux2 image 的 RHEL、CentOS 和 EKS，请使用以下命令：

yum install nfs-utils

我们还提供了一个 nfs 安装程序，使用户可以更轻松地自动安装 nfs-client：

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/deploy/prerequisite/longhorn-nfs-installation.yaml

部署完成后，运行以下命令来检查安装程序的 pod 状态：

kubectl get pod | grep longhorn-nfs-installation
NAME                                  READY   STATUS    RESTARTS   AGE
longhorn-nfs-installation-t2v9v   1/1     Running   0          143m
longhorn-nfs-installation-7nphm   1/1     Running   0          143m

也可以通过以下命令查看日志，查看安装结果：

kubectl logs longhorn-nfs-installation-t2v9v -c nfs-installation
...
nfs install successfully

检查 Kubernetes 版本

使用以下命令检查您的 Kubernetes 服务器版本

kubectl version

结果：

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.3", GitCommit:"1e11e4a2108024935ecfcb2912226cedeafd99df", GitTreeState:"clean", BuildDate:"2020-10-14T12:50:19Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.4", GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea", GitTreeState:"clean", BuildDate:"2020-03-12T20:55:23Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Server Version 应该是 v1.16 或更高版本。

作为 Rancher Catalog App 安装

通过 Rancher catalog 安装 Longhorn 的好处之一是 Rancher 为 Longhorn UI 提供身份验证。

如果有新版本的 Longhorn 可用，您将在 Catalog Apps 屏幕上看到 Upgrade Available 标志。您可以单击 Upgrade 按钮升级 Longhorn manager。

安装

可选：我们建议为 Longhorn 创建一个新项目，例如 Storage。
导航到您将安装 Longhorn 的 cluster 和 project。

3. 导航到 Catalog Apps 屏幕。

4. 在 catalog 中找到 Longhorn 项目并单击它。

5. 可选：自定义默认设置。6. 单击 Launch。 Longhorn 将安装在 longhorn-system 命名空间中。

现在 Longhorn 已经安装好了。

7. 单击 index.html 链接导航到 Longhorn 仪表板。

成功安装 Longhorn 后，您可以通过导航到 Catalog Apps 屏幕来访问 Longhorn UI。

使用 Kubectl 安装

安装 Longhorn

使用以下命令在任何 Kubernetes 集群上安装 Longhorn：

监视安装进度的一种方法是观察在 longhorn-system 命名空间中创建的 pod：

检查部署是否成功：

要启用对 Longhorn UI 的访问，您需要设置一个 Ingress controller。默认情况下不启用对 Longhorn UI 的身份验证。

已部署资源列表

以下项目将部署到 Kubernetes：

Namespace: longhorn-system

所有 Longhorn bits 都将作用于这个命名空间。

ServiceAccount: longhorn-service-account

Service account 是在 longhorn-system 命名空间中创建的。

ClusterRole: longhorn-role

此角色将有权访问：

In apiextension.k8s.io (All verbs)
- customresourcedefinitions
In core (All verbs)
- /status
- /logs
- pods
- events
- persistentVolumes
- persistentVolumeClaims
- nodes
- proxy/nodes
- secrets
- services
- endpoints
- configMaps
In core
- namespaces (get, list)
In apps (All Verbs)
- daemonsets
- statefulSets
- deployments
In batch (All Verbs)
- jobs
- cronjobs
In storage.k8s.io (All verbs)
- storageclasses
- volumeattachments
- csinodes
- csidrivers
In coordination.k8s.io
- leases

ClusterRoleBinding: longhorn-bind

这将 longhorn-role 连接到 longhorn-system 命名空间中的 longhorn-service-account。

CustomResourceDefinitions

将安装以下 CustomResourceDefinitions

In longhorn.io
- engines
- replicas
- settings
- volumes
- engineimages
- nodes
- instancemanagers

Kubernetes API 对象

一个具有默认设置 config map
longhorn-manager DaemonSet
longhorn-backend service 在内部将 longhorn-manager DaemonSet 暴露给 Kubernetes
longhorn-ui Deployment
longhorn-frontend service 在内部将 longhorn-ui 暴露给 Kubernetes
longhorn-driver-deployer 部署 CSI driver
longhorn StorageClass

使用 Helm 安装

安装 Helm 的注意事项

有关安装 Helm 的帮助，请参阅官方文档。

如果您使用的是 3.0 版之前的 Helm 版本，则需要使用基于角色的访问控制 (RBAC) 在 Kubernetes 集群中安装 Tiller。

安装 Longhorn

添加 Longhorn Helm 存储库：

从存储库中获取最新 charts：

在 longhorn-system 命名空间中安装 Longhorn。要使用 Helm 2 安装 Longhorn，请使用以下命令：

要使用 Helm 3 安装 Longhorn，请使用以下命令：

要确认部署成功，请运行：

结果应如下所示：

要启用对 Longhorn UI 的访问，您需要设置一个 Ingress controller。默认情况下不启用对 Longhorn UI 的身份验证。

访问 UI

访问和身份验证的先决条件

这些说明假定已安装 Longhorn。

如果您安装了 Longhorn YAML 清单，则需要设置 Ingress controller 以允许外部流量进入集群，并且默认情况下不会启用身份验证。这适用于 Helm 和 kubectl 安装。

如果 Longhorn 安装为 Rancher catalog app，Rancher 会自动为您创建一个具有访问控制（rancher-proxy）的 Ingress controller。

访问 Longhorn UI

在您的 Kubernetes 集群中安装 Longhorn 后，您可以访问 UI dashboard。

获取 Longhorn 的对外 service IP：

对于 Longhorn v0.8.0，输出应如下所示，并且使用 longhorn-frontend 的 CLUSTER-IP 访问 Longhorn UI：

在上面的例子中，IP 是 10.20.245.110。

在浏览器中导航到 longhorn-frontend 的 IP。

使用基本身份验证 (nginx) 创建 Ingress

如果您使用 kubectl 或 Helm 在 Kubernetes 集群上安装 Longhorn，则需要创建一个 Ingress 以允许外部流量到达 Longhorn UI。

默认情况下，kubectl 和 Helm 安装未启用身份验证。在这些步骤中，您将学习如何使用 nginx ingress controller 的 annotations 创建具有基本身份验证的 Ingress。

创建一个基本的认证文件 auth。生成的文件命名为 auth 很重要（实际上 - secret 有一个 key data.auth），否则 Ingress 返回 503。

创建一个 secret：

创建一个 Ingress 清单 longhorn-ingress.yml :

创建 Ingress:

e.g.:

$ USER=foo; PASSWORD=bar; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth
$ cat auth
foo:$apr1$FnyKCYKb$6IP2C45fZxMcoLwkOwf7k0

$ kubectl -n longhorn-system create secret generic basic-auth --from-file=auth
secret/basic-auth created
$ kubectl -n longhorn-system get secret basic-auth -o yaml
apiVersion: v1
data:
  auth: Zm9vOiRhcHIxJEZueUtDWUtiJDZJUDJDNDVmWnhNY29Md2tPd2Y3azAK
kind: Secret
metadata:
  creationTimestamp: "2020-05-29T10:10:16Z"
  name: basic-auth
  namespace: longhorn-system
  resourceVersion: "2168509"
  selfLink: /api/v1/namespaces/longhorn-system/secrets/basic-auth
  uid: 9f66233f-b12f-4204-9c9d-5bcaca794bb7
type: Opaque

$ echo "
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: longhorn-ingress
  namespace: longhorn-system
  annotations:
    # type of authentication
    nginx.ingress.kubernetes.io/auth-type: basic
    # prevent the controller from redirecting (308) to HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: 'false'
    # name of the secret that contains the user/password definitions
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    # message to display with an appropriate context why the authentication is required
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required '
spec:
  rules:
  - http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: longhorn-frontend
            port:
              number: 80
" | kubectl -n longhorn-system create -f -
ingress.networking.k8s.io/longhorn-ingress created

$ kubectl -n longhorn-system get ingress
NAME               HOSTS   ADDRESS                                     PORTS   AGE
longhorn-ingress   *       45.79.165.114,66.228.45.37,97.107.142.125   80      2m7s

$ curl -v http://97.107.142.125/
*   Trying 97.107.142.125...
* TCP_NODELAY set
* Connected to 97.107.142.125 (97.107.142.125) port 80 (#0)
> GET / HTTP/1.1
> Host: 97.107.142.125
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Server: openresty/1.15.8.1
< Date: Fri, 29 May 2020 11:47:33 GMT
< Content-Type: text/html
< Content-Length: 185
< Connection: keep-alive
< WWW-Authenticate: Basic realm="Authentication Required"
<
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>openresty/1.15.8.1</center>
</body>
</html>
* Connection #0 to host 97.107.142.125 left intact
* Closing connection 0

$ curl -v http://97.107.142.125/ -u foo:bar
*   Trying 97.107.142.125...
* TCP_NODELAY set
* Connected to 97.107.142.125 (97.107.142.125) port 80 (#0)
* Server auth using Basic with user 'foo'
> GET / HTTP/1.1
> Host: 97.107.142.125
> Authorization: Basic Zm9vOmJhcg==
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Fri, 29 May 2020 11:51:27 GMT
< Content-Type: text/html
< Content-Length: 1118
< Last-Modified: Thu, 28 May 2020 00:39:41 GMT
< ETag: "5ecf084d-3fd"
< Cache-Control: max-age=0
<
<!DOCTYPE html>
<html lang="en">
......

`AWS EKS Kubernetes` 集群的附加步骤

您将需要创建一个 ELB（弹性负载均衡器）以将 nginx Ingress controller 公开到 Internet。可能需要支付额外费用。

根据 nginx ingress controller documentation 创建必须的资源。
按照 ingress-nginx/deploy/#aws 步骤创建 ELB。

References

https://kubernetes.github.io/ingress-nginx/

升级

在这里，我们介绍了如何从所有以前的版本升级到最新的 Longhorn。

升级 Longhorn

升级过程通常有两个步骤：首先将 Longhorn manager 升级到最新版本，然后使用最新的 Longhorn manager 手动将 Longhorn engine 升级到最新版本。

1. 升级 Longhorn manager

要从 v1.1.x 升级，请参阅 longhorn-manager。

2. 手动升级 Longhorn Engine

Longhorn Manager 升级后，Longhorn Engine 也需要使用 Longhorn UI 进行升级。

3. 自动升级 Longhorn Engine

从 Longhorn v1.1.1 开始，我们提供了一个选项来帮助您自动升级引擎。

Note: Longhorn v1.1.0 和 v1.1.1 中提供的实例管理器镜像 v1_20201216 中存在一个错误，该错误可能导致具有数百个卷的大集群中的死锁(deadlock)。在longhorn/issues/2697查看更多详细信息。 Longhorn v1.1.2 附带一个新的实例管理器镜像 v1_20210621，它修复了死锁，但卷的引擎(engine)/副本(replica)进程不会从旧的实例管理器迁移到新的实例管理器，直到下一次分离(detached)/附加(attached)卷。Longhorn 这样做是因为我们不想中断卷的数据平面。如果您在旧实例管理器中遇到死锁，请按照issues/2697#issuecomment-879374809的恢复步骤操作

升级 Longhorn Manager

从 `v1.1.x` 升级

我们只支持从 v1.1.x 升级到 v1.1.2。其他版本请先升级到 v1.1.x。

支持从 v1.1.x 到 v1.1.2 的 Engine 实时升级。

对于 Longhorn 作为 Rancher app 安装时的 airgap 升级，您需要修改镜像名称并删除 registry URL 部分。

例如，Longhorn images 部分中的镜像 registry.example.com/longhorn/longhorn-manager:v1.1.2 更改为 longhorn/longhorn-manager:v1.1.2。

准备升级

如果 Longhorn 是使用 Helm Chart 安装的，或者是作为 Rancher catalog app 安装的，请检查以确保默认 StorageClass 中的参数未更改。更改默认 StorageClass 的参数可能会导致 chart 升级失败。如果要重新配置 StorageClass 中的参数，可以复制默认 StorageClass 的配置以创建另一个 StorageClass。

The current default StorageClass has the following parameters:

    parameters:
      numberOfReplicas: <user specified replica count, 3 by default>
      staleReplicaTimeout: "30"
      fromBackup: ""
      baseImage: ""

升级

先决条件：始终在升级前备份卷。如果出现任何问题，您可以使用备份恢复卷。

要使用 kubectl 升级，请运行以下命令：

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.2/deploy/longhorn.yaml

要使用 Helm 升级，请运行以下命令：

helm upgrade longhorn ./longhorn/chart

在 Rancher 2.1 或更新版本管理的 Kubernetes 集群上，升级 catalog app longhorn-system 的步骤与安装步骤类似。

然后等待所有 pod 开始运行并且 Longhorn UI 工作。例如：

$ kubectl -n longhorn-system get pod
NAME                                        READY   STATUS    RESTARTS   AGE
csi-attacher-78bf9b9898-mb7jt               1/1     Running   1          3m11s
csi-attacher-78bf9b9898-n2224               1/1     Running   1          3m11s
csi-attacher-78bf9b9898-rhv6m               1/1     Running   1          3m11s
csi-provisioner-8599d5bf97-dr5n4            1/1     Running   1          2m58s
csi-provisioner-8599d5bf97-drzn9            1/1     Running   1          2m58s
csi-provisioner-8599d5bf97-rz5fj            1/1     Running   1          2m58s
csi-resizer-586665f745-5bkcm                1/1     Running   0          2m49s
csi-resizer-586665f745-vgqx8                1/1     Running   0          2m49s
csi-resizer-586665f745-wdvdg                1/1     Running   0          2m49s
engine-image-ei-62c02f63-bjfkp              1/1     Running   0          14m
engine-image-ei-62c02f63-nk2jr              1/1     Running   0          14m
engine-image-ei-62c02f63-pjtgg              1/1     Running   0          14m
engine-image-ei-ac045a0d-9bbb8              1/1     Running   0          3m46s
engine-image-ei-ac045a0d-cqvv2              1/1     Running   0          3m46s
engine-image-ei-ac045a0d-wzmhv              1/1     Running   0          3m46s
instance-manager-e-4deb2a16                 1/1     Running   0          3m23s
instance-manager-e-5526b121                 1/1     Running   0          3m28s
instance-manager-e-eff765b6                 1/1     Running   0          2m59s
instance-manager-r-3b70b0db                 1/1     Running   0          3m27s
instance-manager-r-4f7d629a                 1/1     Running   0          3m22s
instance-manager-r-bbcf4f17                 1/1     Running   0          2m58s
longhorn-csi-plugin-bkgjj                   2/2     Running   0          2m39s
longhorn-csi-plugin-tjhhq                   2/2     Running   0          2m39s
longhorn-csi-plugin-zslp6                   2/2     Running   0          2m39s
longhorn-driver-deployer-75b6bf4d6d-d4hcv   1/1     Running   0          3m57s
longhorn-manager-4j77v                      1/1     Running   0          3m53s
longhorn-manager-cwm5z                      1/1     Running   0          3m50s
longhorn-manager-w7scb                      1/1     Running   0          3m50s
longhorn-ui-8fcd9fdd-qpknp                  1/1     Running   0          3m56s

升级后

为避免现有卷崩溃，以及从已弃用的设置 Guaranteed Engine CPU 切换到 the new instance manager CPU reservation mechanism(预留机制)， Longhorn 将在升级期间根据已弃用的设置值从每个节点自动设置 Engine Manager CPU Request 和 Replica Manager CPU Request。然后，新的全局实例管理器 CPU 设置 Guaranteed Engine Manager CPU 和 Guaranteed Replica Manager CPU 将不会生效。您可能需要检查新机制和设置说明，以查看是否需要进行任何调整。

故障排除

Error: `"longhorn" is invalid: provisioner: Forbidden: updates to provisioner are forbidden.`

这意味着对默认 storageClass 进行了一些修改，您需要在升级前清理旧的。

要清理已弃用的 StorageClass，请运行以下命令：

手动升级 Longhorn Engine

在本节中，您将学习如何从 Longhorn UI 手动升级 Longhorn Engine。

先决条件

在升级 Longhorn engine 镜像之前，请务必进行备份。

在升级 Longhorn engine 之前升级 Longhorn manager。

Note: Longhorn v1.1.0 和 v1.1.1 中提供的实例管理器镜像 v1_20201216 中存在一个错误，该错误可能导致具有数百个卷的大集群中的死锁(deadlock)。在longhorn/issues/2697查看更多详细信息。 Longhorn v1.1.2 附带一个新的实例管理器镜像 v1_20210621，它修复了死锁，但卷的引擎/副本(engine/replica)进程不会从旧的实例管理器迁移到新的实例管理器，直到下一次分离/附加(detached/attached)卷。Longhorn 这样做是因为我们不想中断卷的数据平面。为了减少引擎/副本(engine/replica)进程仍在旧实例管理器中时发生死锁的机会，您应该小批量升级卷的引擎，例如，一次升级 2 或 3 个卷。

离线升级

如果无法进行实时升级，或者卷处于降级状态，请执行以下步骤：

按照 相关 workloads 的 detach procedure 进行。
使用批量选择选择所有卷。单击批量操作按钮 Upgrade Engine，在列表中选择可用的 engine 镜像。这是此版本管理器附带的默认引擎。
恢复所有 workloads。任何不属于 Kubernetes workload 的卷都必须从 Longhorn UI 附加。

实时升级

从 v1.1.x 升级到 v1.1.2 支持实时升级。

iSCSI 前端不支持实时升级。

实时升级应该只对健康的卷进行。

选择要升级的卷。
单击下拉菜单中的 Upgrade Engine。
选择要升级到的 engine 镜像。
1. 通常它是列表中唯一的 engine 镜像，因为 UI 从列表中排除当前镜像。
单击 OK。

在实时升级期间，用户会暂时看到双倍数量的副本(replicas)。升级完成后，用户应该看到与之前相同数量的副本(replicas)，并且应该更新卷的 Engine Image 字段。

请注意，实时升级后，Rancher 或 Kubernetes 仍会显示 engine 的旧版本镜像和副本(replicas)的新版本。这是预期的。如果您在 Volume Detail 页面中看到新版本的镜像列为卷镜像，则升级成功。

清理旧镜像

完成所有镜像的升级后，从 Longhorn UI 中选择 Settings/Engine Image。现在您应该能够删除非默认镜像。

自动升级 Longhorn Engine

从 Longhorn v1.1.1 开始，我们提供了一个选项，可以帮助您在升级 Longhorn manager 后自动将 Longhorn 卷升级到新的默认引擎版本。此功能减少了升级 Longhorn 时必须做的手动工作量。有一些相关的概念此功能如下所示：

1. 每个节点限制设置的并发自动引擎升级

这是一个设置，用于控制在升级 Longhorn manager 后，Longhorn 如何自动将卷的引擎升级到新的默认引擎镜像。此设置的值指定允许每个节点同时升级到默认引擎镜像的最大引擎数量。如果该值为 0，则 Longhorn 不会自动将卷的引擎升级到默认版本。该值越大，引擎升级过程完成得越快。

但是，为该设置提供更大的值会在引擎升级过程中消耗更多节点的 CPU 和内存。我们建议将该值设置为 3，以便为错误留出一些空间，但不要因升级失败过多而使系统不堪重负。

2. Longhorn 在不同体积条件下的行为。

在以下情况下，假设 concurrent automatic engine upgrade per node limit(并发自动引擎升级每节点限制)设置大于 0。

附加卷如果卷处于附加状态并且健康，Longhorn 会自动将卷的引擎实时升级到新的默认引擎镜像。
分离卷 Longhorn 自动对分离的卷进行离线升级。
容灾卷 Longhorn 不会自动将 disaster recovery volumes 升级到新的默认引擎镜像，因为它会触发灾难恢复卷的完全恢复。完全恢复可能会影响系统中其他正在运行的 Longhorn 卷的性能。因此，Longhorn 由您决定何时是手动升级灾难恢复卷引擎的好时机（例如，当系统空闲时或在维护期间）。但是，当您激活容灾卷时，它会被激活然后分离。此时，Longhorn 会自动对卷进行脱机升级，类似于分离卷的情况。

3. 如果升级失败会怎样？

如果卷升级引擎失败，卷 spec 中的引擎镜像将保持与卷状态中的引擎镜像不同。Longhorn 将不断重试升级，直到成功。

如果每个节点无法升级的卷太多（即超过 concurrent automatic engine upgrade per node limit(每个节点的并发自动引擎升级限制)设置），Longhorn 将停止升级该节点上的卷。

卸载 Longhorn

在本节中，您将学习如何卸载 Longhorn。

先决条件
从 Rancher UI 卸载 Longhorn
使用 Helm 卸载 Longhorn
使用 kubectl 卸载 Longhorn
故障排除

先决条件

为了防止对 Kubernetes 集群造成损坏，我们建议删除所有使用 Longhorn 卷（PersistentVolume、PersistentVolumeClaim、StorageClass、Deployment、StatefulSet、DaemonSet 等）的 Kubernetes 工作负载。

从 Rancher UI 卸载 Longhorn

从 Rancher UI，导航到 Catalog Apps 选项卡并删除 Longhorn app。

使用 Helm 卸载 Longhorn

运行此命令：

helm uninstall longhorn -n longhorn-system

使用 kubectl 卸载 Longhorn

创建卸载 job 以从系统中清除 CRDs 并等待成功：

示例输出：

删除剩余的组件：

Tip: 如果您先尝试 kubectl delete -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/deploy/longhorn.yaml 并卡在那里，请按 Ctrl C 然后运行 kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v{{< current-version >}}/uninstall/uninstall.yaml 也可以帮你移除 Longhorn。最后，不要忘记清理剩余的组件。

故障排除

我从 Rancher UI 中删除了 Longhorn 应用程序，而不是按照卸载程序进行操作

重新部署（相同版本）Longhorn App。按照上面的卸载程序进行操作。

CRDs 的问题

如果您的 CRD 实例或 CRD 本身由于某种原因无法删除，请运行以下命令进行清理。注意：这将清除所有 Longhorn 状态！

# Delete CRD finalizers, instances and definitions
for crd in $(kubectl get crd -o jsonpath={.items[*].metadata.name} | tr ' ' '\n' | grep longhorn.rancher.io); do
  kubectl -n ${NAMESPACE} get $crd -o yaml | sed "s/\- longhorn.rancher.io//g" | kubectl apply -f -
  kubectl -n ${NAMESPACE} delete $crd --all
  kubectl delete crd/$crd
done

卷可以从 UI 附加/分离，但 Kubernetes Pod/StatefulSet 等不能使用它

检查卷插件目录是否设置正确。除非用户明确设置，否则会自动检测到它。注意：FlexVolume 插件自 Longhorn v0.8.0 起已弃用，不应再使用。

默认情况下，Kubernetes 使用 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/，如官方文档所述。

一些供应商出于各种原因选择更改目录。例如，GKE 使用 /home/kubernetes/flexvolume 代替。

用户可以通过在主机上运行 ps aux|grep kubelet 并检查 --volume-plugin-dir 参数来找到正确的目录。如果没有，将使用默认的 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/。

本文参与腾讯云自媒体分享计划，分享自微信公众号。

原始发表：2021-08-18，如有侵权请联系 cloudcommunity@tencent.com 删除

kubernetes

本文分享自黑客下午茶微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

kubernetes