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

使用 kubectl 创建后端

贡献者
PDF

后端定义了 Astra Trident 与存储系统之间的关系。它告诉 Astra Trident 如何与该存储系统进行通信，以及 Astra Trident 如何从该存储系统配置卷。安装 Astra Trident 后，下一步是创建后端。使用 TridentBackendConfig Custom Resource Definition （ CRD ），您可以直接通过 Kubernetes 界面创建和管理 Trident 后端。为此，您可以对 Kubernetes 分发版使用 kubectl 或等效的命令行界面工具。

TridentBackendConfig

TridentBackendConfig （tbc ， tbconfig ， tbackendconfig ）是一个前端命名的 CRD ，可用于使用 kubectl 管理 Astra Trident 后端。现在， Kubernetes 和存储管理员可以直接通过 Kubernetes 命令行界面创建和管理后端，而无需专用命令行实用程序（tridentctl ）。

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

  • Astra Trident 会根据您提供的配置自动创建后端。此值在内部表示为 TridentBackend （tbe ， tridentbackend ） CR 。

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

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

警告 TridentBackend CRS 由 Astra 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 对象。您可以通过创建 TridentBackendConfig CR ，选择使用 kubectl 来管理此类后端。必须注意指定相同的配置参数（例如 sPec.backendName ， sPec.storagePrefix ， sPec.storageDriverName 等）。Astra Trident 会自动将新创建的 TridentBackendConfig 与已有的后端绑定。

步骤概述

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

  1. 创建 "Kubernetes 机密"。此密钥包含 Astra 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

适用于 AWS 的 Cloud Volumes Service

apiKey

CVS 帐户 API 密钥

适用于 AWS 的 Cloud Volumes Service

secretKey

CVS 帐户密钥

适用于 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 ： The TridentBackendConfig CR 's deletionPolicy was set to delete.删除 TridentBackendConfig CR 后，它将过渡到 Deleting 状态。

    • 如果后端不存在永久性卷请求（ PVC ），则删除 TridentBackendConfig 将导致 Astra Trident 删除后端以及 TridentBackendConfig CR 。

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

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

  • 未知 ： Astra Trident 无法确定与 TridentBackendConfig CR 关联的后端的状态或存在。例如，如果 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 包含为响应 TridentBackendConfig CR 而创建的后端的 backendName 和 backendUUID 。lastOperationStatus 字段表示 TridentBackendConfig CR 的上次操作状态，该操作可以是用户触发的（例如，用户在 sPec 中更改了某个内容），也可以是由 Astra Trident 触发的（例如，在 Astra Trident 重新启动期间）。可以是成功，也可以是失败。phase 表示 TridentBackendConfig CR 与后端之间关系的状态。在上面的示例中， phase 的值为 bound ，这意味着 TridentBackendConfig CR 与后端关联。

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

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