Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

使用 kubectl 创建后端

贡献者
PDF

后端用于定义Trident与存储系统之间的关系。它会告诉Trident如何与该存储系统通信、以及Trident如何从该存储系统配置卷。安装Trident后、下一步是创建后端。 TridentBackendConfig`通过自定义资源定义(CRD)、您可以直接通过Kubednetes界面创建和管理Trident后端。您可以使用或对Kubornetes分发等效的命令行界面工具来执行此操作 `kubectl。

TridentBackendConfig

TridentBackendConfig(tbc tbconfig、、 tbackendconfig)是一个前端，具有名称节奏的CRD，使您可以使用管理Trident后端 kubectl。现在，Kubbernetes和存储管理员可以直接通过Kubbernetes CLI创建和管理后端，而无需专用的命令行实用程序(tridentctl)。

创建 TridentBackendConfig 对象时，将发生以下情况：

  • Trident会根据您提供的配置自动创建后端。这在内部表示为 TridentBackend (tbe， tridentbackend) CR。

  • TridentBackendConfig`唯一绑定到由Trident创建的 `TridentBackend。

每个 TridentBackendConfig 都与 TridentBackend 保持一对一映射。前者是为用户提供的用于设计和配置后端的接口；后者是 Trident 表示实际后端对象的方式。

警告 TridentBackend`CRS由Trident自动创建。您 * 不应 * 修改它们。如果要更新后端、请通过修改对象来执行此操作 `TridentBackendConfig。

有关 TridentBackendConfig CR 的格式，请参见以下示例：

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

您还可以查看中的示例 "Trident 安装程序" 所需存储平台 / 服务的示例配置目录。

。 spec 获取后端特定的配置参数。在此示例中、后端使用 ontap-san 存储驱动程序、并使用此处所示的配置参数。有关所需存储驱动程序的配置选项列表、请参阅 "存储驱动程序的后端配置信息"。

sPec 部分还包括 credentials 和 deletionPolicy 字段，这些字段在 TridentBackendConfig CR 中新增：

  • credentials ：此参数为必填字段，包含用于向存储系统 / 服务进行身份验证的凭据。此密码设置为用户创建的 Kubernetes Secret 。凭据不能以纯文本形式传递，因此会导致错误。

  • deeltionPolicy ：此字段定义删除 TridentBackendConfig 时应发生的情况。它可以采用以下两种可能值之一：

    • delete ：这将同时删除 TridentBackendConfig CR 和关联后端。这是默认值。

    • retain ：删除 TrdentBackendConfig CR 后，后端定义仍存在，可使用 tridentctl 进行管理。将删除策略设置为 retain 允许用户降级到早期版本（ 21.04 之前）并保留创建的后端。创建 TridentBackendConfig 后，可以更新此字段的值。

备注 后端名称使用 sPec.backendName 设置。如果未指定，则后端的名称将设置为 TridentBackendConfig 对象的名称（ metadata.name ）。建议使用 sPec.backendName 显式设置后端名称。
提示 使用创建的后端 tridentctl`没有关联 `TridentBackendConfig`对象。您可以通过创建CR来 `TridentBackendConfig`选择使用管理此类后端 `kubectl。必须注意指定相同的配置参数(如 spec.backendName、、 spec.storagePrefix spec.storageDriverName`等)。Trident将自动将新创建的与已有的后端绑定 `TridentBackendConfig。

步骤概述

要使用 kubectl 创建新后端，应执行以下操作：

  1. 创建 "Kubernetes 机密"。此密钥包含Trident与存储集群/服务通信所需的凭据。

  2. 创建 TridentBackendConfig 对象。其中包含有关存储集群 / 服务的详细信息，并引用了上一步中创建的密钥。

创建后端后，您可以使用 kubectl get tbc <tbc-name> -n <trident 命名空间 > 来观察其状态，并收集其他详细信息。

第 1 步：创建 Kubernetes 机密

创建一个机密，其中包含后端的访问凭据。这是每个存储服务 / 平台所特有的。以下是一个示例：

kubectl -n trident create -f backend-tbc-ontap-san-secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-san-secret
type: Opaque
stringData:
  username: cluster-admin
  password: t@Ax@7q(>

下表汇总了每个存储平台的机密中必须包含的字段：

存储平台机密字段问题描述 机密 字段问题描述

Azure NetApp Files

clientId

应用程序注册中的客户端 ID

适用于 GCP 的 Cloud Volumes Service

private_key_id

专用密钥的 ID 。具有 CVS 管理员角色的 GCP 服务帐户的 API 密钥的一部分

适用于 GCP 的 Cloud Volumes Service

private_key

专用密钥。具有 CVS 管理员角色的 GCP 服务帐户的 API 密钥的一部分

Element （ NetApp HCI/SolidFire ）

端点

使用租户凭据的 SolidFire 集群的 MVIP

ONTAP

username

用于连接到集群 /SVM 的用户名。用于基于凭据的身份验证

ONTAP

password

连接到集群 /SVM 的密码。用于基于凭据的身份验证

ONTAP

客户端权限密钥

客户端专用密钥的 Base64 编码值。用于基于证书的身份验证

ONTAP

用户名

入站用户名。如果 useCHAP=true ，则为必需项。适用于 ontap-san 和 ontap-san-economy.

ONTAP

chapInitiatorSecret

CHAP 启动程序密钥。如果 useCHAP=true ，则为必需项。适用于 ontap-san 和 ontap-san-economy.

ONTAP

chapTargetUsername

目标用户名。如果 useCHAP=true ，则为必需项。适用于 ontap-san 和 ontap-san-economy.

ONTAP

chapTargetInitiatorSecret

CHAP 目标启动程序密钥。如果 useCHAP=true ，则为必需项。适用于 ontap-san 和 ontap-san-economy.

在下一步中创建的 TrdentBackendConfig 对象的 sPec.credentials 字段将引用此步骤中创建的机密。

第2步：创建 TridentBackendConfig CR

现在，您可以创建 TridentBackendConfig CR 了。在此示例中，使用 TriventBackendConfig 对象创建使用` ontap-san `驱动程序的后端，如下所示：

kubectl -n trident create -f backend-tbc-ontap-san.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-san
spec:
  version: 1
  backendName: ontap-san-backend
  storageDriverName: ontap-san
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  svm: trident_svm
  credentials:
    name: backend-tbc-ontap-san-secret

第3步：验证的状态 TridentBackendConfig CR

现在，您已创建 TridentBackendConfig CR ，可以验证状态。请参见以下示例：

kubectl -n trident get tbc backend-tbc-ontap-san
NAME                    BACKEND NAME          BACKEND UUID                           PHASE   STATUS
backend-tbc-ontap-san   ontap-san-backend     8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success

已成功创建后端并将其绑定到 TridentBackendConfig CR 。

阶段可以采用以下值之一：

  • Bound： TridentBackendConfig CR与后端关联、后端包含 configRef 设置为 TridentBackendConfig CR的uid。

  • Unbound ：使用 ` ""` 表示。TridentBackendConfig 对象未绑定到后端。默认情况下，所有新创建的 TridentBackendConfig CRS 均处于此阶段。此阶段发生更改后，它将无法再次还原为 "Unbound （已取消绑定） " 。

  • Deleting： TridentBackendConfig CR deletionPolicy 已设置为delete。当 TridentBackendConfig CR将被删除、它将过渡到Deleting状态。

    • 如果后端不存在永久性卷请求(PVC)、则删除 TridentBackendConfig`将导致Trident删除后端以及CR。 `TridentBackendConfig

    • 如果后端存在一个或多个 PVC ，则会进入删除状态。TridentBackendConfig CR 随后也会进入删除阶段。只有在删除所有 PVC 后，才会删除后端和 TridentBackendConfig 。

  • Lost ：与 TridentBackendConfig CR 关联的后端被意外或故意删除， TridentBackendConfig CR 仍引用已删除的后端。无论 detionPolicy 值如何，仍可删除 TridentBackendConfig CR 。

  • Unknown：Trident无法确定与CR关联的后端的状态或是否存在 TridentBackendConfig。例如、如果API服务器未响应或 `tridentbackends.trident.netapp.io`缺少CRD。这可能需要干预。

在此阶段，已成功创建后端！此外，还可以处理多个操作，例如 "后端更新和后端删除"。

（可选）第 4 步：获取更多详细信息

您可以运行以下命令来获取有关后端的详细信息：

kubectl -n trident get tbc backend-tbc-ontap-san -o wide
NAME                    BACKEND NAME        BACKEND UUID                           PHASE   STATUS    STORAGE DRIVER   DELETION POLICY
backend-tbc-ontap-san   ontap-san-backend   8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8   Bound   Success   ontap-san        delete

此外，您还可以获取 YAML/JSON 转储 TridentBackendConfig 。

kubectl -n trident get tbc backend-tbc-ontap-san -o yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  creationTimestamp: "2021-04-21T20:45:11Z"
  finalizers:
  - trident.netapp.io
  generation: 1
  name: backend-tbc-ontap-san
  namespace: trident
  resourceVersion: "947143"
  uid: 35b9d777-109f-43d5-8077-c74a4559d09c
spec:
  backendName: ontap-san-backend
  credentials:
    name: backend-tbc-ontap-san-secret
  managementLIF: 10.0.0.1
  dataLIF: 10.0.0.2
  storageDriverName: ontap-san
  svm: trident_svm
  version: 1
status:
  backendInfo:
    backendName: ontap-san-backend
    backendUUID: 8d24fce7-6f60-4d4a-8ef6-bab2699e6ab8
  deletionPolicy: delete
  lastOperationStatus: Success
  message: Backend 'ontap-san-backend' created
  phase: Bound

backendInfo`包含 `backendName`响应CR而创建的后端的 `TridentBackendConfig`和 `backendUUID。 lastOperationStatus`字段表示CR的上次操作状态，可以是用户触发的操作(例如，用户在中更改了某些内容)，也可以是Trident触发的操作 `TridentBackendConfig(例如， spec`在Trident重新启动期间)。可以是成功、也可以是失败。 `phase`表示CR和后端之间关系的状态 `TridentBackendConfig。在上面的示例中、 `phase`具有绑定值、这意味着 `TridentBackendConfig`CR与后端关联。

您可以运行 kubectl -n trident describe tbc <tbc-cr-name> 命令来获取事件日志的详细信息。

警告 您不能使用 tridentctl 更新或删除包含关联的 TridentBackendConfig 对象的后端。要了解在 tridentctl 和 TridentBackendConfig 之间切换所涉及的步骤， "请参见此处"。