本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

使用kubecl建立後端

01/30/2023 貢獻者

後端定義了Astra Trident與儲存系統之間的關係。它告訴Astra Trident如何與該儲存系統通訊、以及Astra Trident如何從該儲存系統配置磁碟區。安裝Astra Trident之後、下一步是建立後端。。 TridentBackendConfig 自訂資源定義（CRD）可讓您直接透過Kubernetes介面建立及管理Trident後端。您可以使用執行此作業 kubectl 或相當於Kubernetes發佈版本的CLI工具。

`TridentBackendConfig`

TridentBackendConfig (tbc、 tbconfig、 tbackendconfig）是前端、命名式CRD、可讓您使用管理Astra Trident後端 kubectl。Kubernetes與儲存管理員現在可以直接透過Kubernetes CLI建立及管理後端、而無需使用專屬的命令列公用程式 (tridentctl）。

建立時 TridentBackendConfig 物件：

Astra Trident會根據您提供的組態自動建立後端。這會在內部顯示為 TridentBackend (tbe、 tridentbackend）CR.
。 TridentBackendConfig 唯一綁定到 TridentBackend 這是由Astra Trident所建立。

每個 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。認證資料無法以純文字格式傳遞、因此會產生錯誤。
deletionPolicy：此欄位可定義在下列情況下應發生的情況 TridentBackendConfig 已刪除。可能需要兩種可能的值之一：
- delete：這會導致兩者都被刪除 TridentBackendConfig 和相關後端。這是預設值。
- retain：當 TridentBackendConfig 刪除CR後、後端定義仍會顯示、並可透過進行管理 tridentctl。將刪除原則設定為 retain 可讓使用者降級至較早版本（21.04之前）、並保留建立的後端。此欄位的值可在之後更新 TridentBackendConfig 已建立。

後端名稱是使用設定 spec.backendName。如果未指定、則會將後端名稱設為的名稱 TridentBackendConfig 物件（metadata.name）。建議使用明確設定後端名稱 spec.backendName。

以建立的後端 tridentctl 沒有關聯的 TridentBackendConfig 物件：您可以選擇使用來管理此類後端 kubectl 建立 TridentBackendConfig CR.必須謹慎指定相同的組態參數（例如 spec.backendName、 spec.storagePrefix、 spec.storageDriverName`等）。Astra Trident會自動連結新建立的 `TridentBackendConfig 使用預先存在的後端。

步驟總覽

若要使用建立新的後端 kubectl、您應該執行下列步驟：

建立 "Kubernetes機密"。此機密包含Astra Trident與儲存叢集/服務通訊所需的認證資料。
建立 TridentBackendConfig 物件：其中包含有關儲存叢集/服務的詳細資訊、並參考上一步建立的機密。

建立後端之後、您可以使用觀察其狀態 kubectl get tbc <tbc-name> -n <trident-namespace> 並收集其他詳細資料。

步驟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金鑰ID	私密金鑰的ID。GCP服務帳戶API金鑰的一部分、具有CVS管理員角色
適用於 GCP Cloud Volumes Service	Private金鑰	私密金鑰：GCP服務帳戶API金鑰的一部分、具有CVS管理員角色
元素（NetApp HCI / SolidFire）	端點	MVIP、適用於SolidFire 採用租戶認證的不含用戶身分證明的叢集
ONTAP	使用者名稱	連線至叢集/ SVM的使用者名稱。用於認證型驗證
ONTAP	密碼	連線至叢集/ SVM的密碼。用於認證型驗證
ONTAP	用戶端權限金鑰	用戶端私密金鑰的Base64編碼值。用於憑證型驗證
ONTAP	chap使用者名稱	傳入使用者名稱。如果useCHAP=true則需要。適用於 `ontap-san` 和 `ontap-san-economy`
ONTAP	chapInitiator機密	CHAP啟動器密碼。如果useCHAP=true則需要。適用於 `ontap-san` 和 `ontap-san-economy`
ONTAP	chapTargetUsername	目標使用者名稱。如果useCHAP=true則需要。適用於 `ontap-san` 和 `ontap-san-economy`
ONTAP	chapTargetInitiator機密	CHAP目標啟動器機密。如果useCHAP=true則需要。適用於 `ontap-san` 和 `ontap-san-economy`

Azure NetApp Files

ClientID

應用程式註冊的用戶端ID

適用於 GCP Cloud Volumes Service

Private金鑰ID

私密金鑰的ID。GCP服務帳戶API金鑰的一部分、具有CVS管理員角色

適用於 GCP Cloud Volumes Service

Private金鑰

私密金鑰：GCP服務帳戶API金鑰的一部分、具有CVS管理員角色

元素（NetApp HCI / SolidFire）

端點

MVIP、適用於SolidFire 採用租戶認證的不含用戶身分證明的叢集

ONTAP

使用者名稱

連線至叢集/ SVM的使用者名稱。用於認證型驗證

ONTAP

密碼

連線至叢集/ SVM的密碼。用於認證型驗證

ONTAP

用戶端權限金鑰

用戶端私密金鑰的Base64編碼值。用於憑證型驗證

ONTAP

chap使用者名稱

傳入使用者名稱。如果useCHAP=true則需要。適用於 ontap-san 和 ontap-san-economy

ONTAP

chapInitiator機密

CHAP啟動器密碼。如果useCHAP=true則需要。適用於 ontap-san 和 ontap-san-economy

ONTAP

chapTargetUsername

目標使用者名稱。如果useCHAP=true則需要。適用於 ontap-san 和 ontap-san-economy

ONTAP

chapTargetInitiator機密

CHAP目標啟動器機密。如果useCHAP=true則需要。適用於 ontap-san 和 ontap-san-economy

在此步驟中建立的機密將會在中參考 spec.credentials 的欄位 TridentBackendConfig 下一步建立的物件。

步驟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 您可以驗證狀態。請參閱下列範例：

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 請參閱 deletionPolicy 已設定為刪除。當 TridentBackendConfig 系統會刪除CR、並轉換為「刪除」狀態。
- 如果後端上不存在持續磁碟區宣告（PVCS）、請刪除 TridentBackendConfig 將導致Astra Trident刪除後端及 TridentBackendConfig CR.
- 如果後端上有一個或多個PVCS、則會進入刪除狀態。。 TridentBackendConfig 接著、CR也會進入刪除階段。後端和 TridentBackendConfig 僅在刪除所有PVCS之後才會刪除。
Lost：與關聯的後端 TridentBackendConfig 意外或蓄意刪除及 TridentBackendConfig CR仍有已刪除後端的參考資料。。 TridentBackendConfig 無論使用何種方法、仍可刪除CR deletionPolicy 價值。
Unknown：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 包含 backendName 和 backendUUID 為回應所建立的後端 TridentBackendConfig CR.。 lastOperationStatus 欄位代表的上次作業狀態 TridentBackendConfig 可由使用者觸發的CR（例如、使用者在中變更了內容 spec）或由Astra Trident觸發（例如、在Astra Trident重新啟動期間）。可能是「成功」或「失敗」。 phase 表示之間關係的狀態 TridentBackendConfig 和後端。在上述範例中、 phase 具有綁定的值、這表示 TridentBackendConfig CR與後端相關聯。

您可以執行 kubectl -n trident describe tbc <tbc-cr-name> 命令以取得事件記錄的詳細資料。

您無法更新或刪除包含相關聯的後端 TridentBackendConfig 物件使用 tridentctl。瞭解切換的步驟 tridentctl 和 TridentBackendConfig、 "請參閱此處"。

使用kubecl建立後端

Creating your file...

TridentBackendConfig

步驟總覽

步驟1：建立Kubernetes機密

步驟2：建立 TridentBackendConfig CR

步驟3：確認的狀態 TridentBackendConfig CR

（選用）步驟4：取得更多詳細資料

`TridentBackendConfig`

步驟2：建立 `TridentBackendConfig` CR

步驟3：確認的狀態 `TridentBackendConfig` CR