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

使用kubecl建立後端

貢獻者

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

TridentBackendConfig

「TridentBackendConfig」(「tbc」、「tbconfig」、「tbackendconfig」)是前端、名稱為CRD、可讓您使用「kubectl」來管理Astra Trident後端。Kubernetes與儲存管理員現在可以直接透過Kubernetes CLI建立及管理後端、而不需要使用專屬的命令列公用程式(「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安裝程式" 所需儲存平台/服務的範例組態目錄。

「show」會採用後端特定的組態參數。在此範例中、後端使用「ONTAP-san」儲存驅動程式、並使用此處表格列出的組態參數。如需所需儲存驅動程式的組態選項清單、請參閱 "儲存驅動程式的後端組態資訊"

在《TridentBackendConfig》(CRR)中新推出的「sPEC」一節也包含「認證」和「刪除原則」欄位:

  • 「認證資料」:此參數為必填欄位、包含用於驗證儲存系統/服務的認證資料。此設定為使用者建立的Kubernetes Secret。認證資料無法以純文字格式傳遞、因此會產生錯誤。

  • 「刪除原則」:此欄位可定義刪除「TridentBackendConfig」時應發生的情況。可能需要兩種可能的值之一:

    • 「刪除」:這會同時刪除「TridentBackendConfig」和相關後端。這是預設值。

    • 「保留」:刪除「TridentBackendConfig」(TridentBackendConfig)CR時、後端定義仍會存在、並可使用「tridentctl」進行管理。將刪除原則設為「保留」可讓使用者降級至較早版本(21.04之前)、並保留建立的後端。此欄位的值可在建立「TridentBackendConfig」之後更新。

附註 後端名稱是使用「sPEC.backendName」來設定。如果未指定、則會將後端名稱設為「TridentBackendConfig」物件(metadata.name)的名稱。建議使用「sPEC.backendName」明確設定後端名稱。
提示 使用「tridentctl」建立的後端沒有關聯的「TridentBackendConfig」物件。您可以建立「TridentBackendConfig」(TridentBackendConfig)的CR、選擇以「kubectl」管理這類後端。必須謹慎指定相同的組態參數(例如「s.pec.backendName」、「sec.storagePrefix」、「sPEec.storageDriverName」等)。Astra Trident會自動將新建立的「TridentBackendConfig」連結至預先存在的後端。

步驟總覽

若要使用「kubecll」建立新的後端、您應該執行下列動作:

  1. 建立 "Kubernetes機密"。此機密包含Astra Trident與儲存叢集/服務通訊所需的認證資料。

  2. 建立「TridentBackendConfig」物件。其中包含有關儲存叢集/服務的詳細資訊、並參考上一步建立的機密。

建立後端之後、您可以使用「kubecl 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金鑰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經濟」

ONTAP

chapInitiator機密

CHAP啟動器密碼。如果useCHAP=true則需要。適用於「ONTAP-SAN」和「ONTAP-san經濟」

ONTAP

chapTargetUsername

目標使用者名稱。如果useCHAP=true則需要。適用於「ONTAP-SAN」和「ONTAP-san經濟」

ONTAP

chapTargetInitiator機密

CHAP目標啟動器機密。如果useCHAP=true則需要。適用於「ONTAP-SAN」和「ONTAP-san經濟」

在此步驟中建立的機密會參照下一步所建立之「TridentBackendConfig」物件的「sapec.ecent」欄位。

步驟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」(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。

階段可以採用下列其中一個值:

  • 「綁定」:「TridentBackendConfig」CR與後端相關聯、後端包含「configRef」設定為「TridentBackendConfig」的CR uid。

  • 《Unbound》:使用「」表示。「TridentBackendConfig」物件不會繫結至後端。根據預設、所有新建立的「TridentBackendConfig」CRS均處於此階段。階段變更之後、就無法再恢復為Unbound(未綁定)。

  • 「刪除」:「TridentBackendConfig」的「刪除原則」已設定為刪除。刪除「TridentBackendConfig」CR時、它會轉換為「刪除」狀態。

    • 如果後端不存在持續磁碟區宣告(PVCS)、刪除「TridentBackendConfig」(TridentBackendConfig)會導致Astra Trident刪除後端、以及刪除「TridentBackendConfig」(TridentBackendConfig)。

    • 如果後端上有一個或多個PVCS、則會進入刪除狀態。隨後、「TridentBackendConfig」CR也會進入刪除階段。只有刪除所有的PVCS之後、才會刪除後端和「TridentBackendConfig」。

  • 「遺失」:與「TridentBackendConfig」CR相關的後端意外或刻意刪除、而「TridentBackendConfig」CR仍有刪除後端的參考資料。無論「刪除原則」值為何、「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

此外、您也可以取得「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》(backendInfo)包含了針對「TridentBackendConfig」(TridentBackendConfig)的CR而建立的後端「backendName」(背端名稱)和「backendUUID」(背端UUID)。「lastoperationStatus」欄位代表上次執行的「TridentBackendConfig」(TridentBackendConfig)CR狀態、可由使用者觸發(例如、使用者在「show」中變更內容)、或由Astra Trident觸發(例如、Astra Trident重新啟動期間)。可能是「成功」或「失敗」。「階段」代表「TridentBackendConfig」與後端之間的關係狀態。在上述範例中、「階段」具有界限值、這表示「TridentBackendConfig」CR與後端相關聯。

您可以執行「kubeclt -n triident描述tbc <tbc-cr-name>」命令、以取得事件記錄的詳細資料。

警告 您無法使用「tridentctl」來更新或刪除包含相關「TridentBackendConfig」物件的後端。若要瞭解在「tridentctl」和「TridentBackendConfig」之間切換的步驟、 "請參閱此處"