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

使用 kubectl 创建后端

02/26/2026

后端定义 Trident 与存储系统之间的关系。它告诉 Trident 如何与该存储系统进行通信，以及 Trident 应如何从中配置卷。安装 Trident 后，下一步是创建后端。 TridentBackendConfig 自定义资源定义 (CRD) 使您能够直接通过 Kubernetes 界面创建和管理 Trident 后端。您可以通过使用 kubectl 或为您的 Kubernetes 发行版使用等效的 CLI 工具来完成此操作。

`TridentBackendConfig`

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

创建 TridentBackendConfig 对象后，会发生以下情况：

Trident 将根据您提供的配置自动创建后端。这在内部表示为 TridentBackend (tbe, tridentbackend) CR。
TridentBackendConfig`唯一绑定到由 Trident 创建的 `TridentBackend。

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

TridentBackend CR 由 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-installer" 目录中的示例，了解所需存储平台/服务的示例配置。

`spec` 需要特定于后端的配置参数。在此示例中，后端使用  `ontap-san` 存储驱动程序，并使用此处列出的配置参数。有关所需存储驱动程序的配置选项列表，请参阅 link:backends.html["您的存储驱动程序的后端配置信息"^]。

`spec` 部分还包括  `credentials` 和  `deletionPolicy` 字段，这些字段是在  `TridentBackendConfig` CR 中新引入的：

credentials：此参数为必填字段，包含用于对存储系统/服务进行身份验证的凭据。这将设置为用户创建的 Kubernetes Secret。凭据无法以纯文本形式传递，将导致错误。
deletionPolicy：此字段定义删除 TridentBackendConfig 时应执行的操作。它可以采用以下两种可能的值之一：
- delete：这将导致 TridentBackendConfig CR 和相关后端都被删除。这是默认值。
- retain：删除 TridentBackendConfig CR 时，后端定义仍将存在，可以使用 tridentctl 进行管理。将删除策略设置为 retain 允许用户降级到较早版本（21.04 之前）并保留创建的后端。此字段的值可以在创建 TridentBackendConfig 后更新。

后端名称使用 spec.backendName 设置。如果未指定，则后端的名称将设置为 TridentBackendConfig 对象的名称（metadata.name）。建议使用 spec.backendName 显式设置后端名称。

使用 tridentctl`创建的后端没有关联的 `TridentBackendConfig`对象。你可以通过创建 `TridentBackendConfig CR，选择用 kubectl`来管理这些后端。必须注意指定相同的配置参数（如 `spec.backendName、 spec.storagePrefix、 `spec.storageDriverName`等）。Trident 会自动将新创建的 `TridentBackendConfig`与已有的后端绑定。

步骤概述

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

创建 "Kubernetes Secret"。密钥包含 Trident 与存储集群/服务通信所需的凭据。
创建 TridentBackendConfig 对象。其中包含有关存储集群/服务的详细信息，并引用上一步中创建的密码。

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

步骤 1：创建 Kubernetes Secret

创建一个包含后端访问凭据的 Secret。这对于每个存储服务/平台都是独一无二的。下面是一个示例：

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: password

下表总结了每个存储平台的 Secret 中必须包含的字段：

存储平台 Secret 字段描述密钥字段说明

存储平台 Secret 字段描述	密钥	字段说明
Azure NetApp Files	clientID	来自应用注册的客户端 ID
Element（NetApp HCI/SolidFire）	端点	具有租户凭据的 SolidFire 集群的 MVIP
ONTAP	用户名	连接到集群/SVM 的用户名。用于基于凭据的身份验证
ONTAP	password	连接到集群/SVM 的密码。用于基于凭据的身份验证
ONTAP	clientPrivateKey	客户端私钥的 Base64 编码值。用于基于证书的身份验证
ONTAP	chapUsername	入站用户名。如果 useCHAP=true，则为必需。对于 ontap-san`和 `ontap-san-economy
ONTAP	chapInitiatorSecret	CHAP initiator secret。如果 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

Azure NetApp Files

clientID

来自应用注册的客户端 ID

Element（NetApp HCI/SolidFire）

端点

具有租户凭据的 SolidFire 集群的 MVIP

ONTAP

用户名

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

ONTAP

password

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

ONTAP

clientPrivateKey

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

ONTAP

chapUsername

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

ONTAP

chapInitiatorSecret

CHAP initiator secret。如果 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

在此步骤中创建的 Secret 将在下一步创建的 TridentBackendConfig 对象的 spec.credentials 字段中被引用。

步骤 2：创建 `TridentBackendConfig` CR

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

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。

Phase 可以采用以下其中一个值：

Bound： TridentBackendConfig CR 与后端相关联，该后端包含 configRef`设置为 `TridentBackendConfig CR 的 uid。
Unbound：使用 "" 表示。 TridentBackendConfig 对象未绑定到后端。默认情况下，所有新创建的 TridentBackendConfig CR 都处于此阶段。阶段变更后，无法再次还原为未绑定状态。
Deleting： TridentBackendConfig CR deletionPolicy 已设置为删除。删除 TridentBackendConfig CR 后，它将转换到"删除"状态。
- 如果后端上不存在持久卷声明（PVC），则删除 TridentBackendConfig`将导致 Trident 删除后端和 `TridentBackendConfig CR。
- 如果后端存在一个或多个 PVC，则会进入删除状态。 TridentBackendConfig CR 随后也进入删除阶段。只有在删除所有 PVC 后，才会删除后端和 TridentBackendConfig。
Lost：与 TridentBackendConfig CR 关联的后端被意外或故意删除，而 TridentBackendConfig CR 仍然引用已删除的后端。无论 TridentBackendConfig`值如何， `deletionPolicy CR 仍然可以被删除。
Unknown：Trident 无法确定与 TridentBackendConfig CR 关联的后端的状态或存在。例如，如果 API 服务器没有响应或 tridentbackends.trident.netapp.io CRD 丢失。这可能需要干预。

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

(可选) 步骤 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

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

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 和 backendUUID，这些是响应 TridentBackendConfig CR 创建的后端信息。 lastOperationStatus 字段表示 TridentBackendConfig CR 最后一次操作的状态，该操作可以由用户触发（例如，用户在 spec 中进行了更改）或由 Trident 触发（例如，在 Trident 重启期间）。它可以是 Success 或 Failed。 phase 表示 TridentBackendConfig CR 与后端之间关系的状态。在上面的示例中， phase 的值为 Bound，这意味着 TridentBackendConfig CR 已与后端关联。

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

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

使用 kubectl 创建后端

Creating your file...

TridentBackendConfig

步骤概述

步骤 1：创建 Kubernetes Secret

步骤 2：创建 TridentBackendConfig CR

第 3 步：验证 TridentBackendConfig CR 的状态

(可选) 步骤 4：获取更多详细信息

`TridentBackendConfig`

步骤 2：创建 `TridentBackendConfig` CR

第 3 步：验证 `TridentBackendConfig` CR 的状态