Skip to main content
本製品の最新リリースがご利用いただけます。
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

kubectl を使用してバックエンドを作成します

共同作成者
PDF

バックエンドは、 Astra Trident とストレージシステムの関係を定義します。Trident がストレージシステムとの通信方法を Trident から指示し、 Astra Trident がボリュームをプロビジョニングする方法も解説します。Astra Trident のインストールが完了したら、次の手順でバックエンドを作成します。 TridentBackendConfig`Custom Resource Definition（CRD）を使用すると、Kubernetesインターフェイスから直接Tridentバックエンドを作成および管理できます。これは、またはKubernetesディストリビューション用の同等のCLIツールを使用して実行できます `kubectl。

TridentBackendConfig

TridentBackendConfig(tbc tbconfig、 tbackendconfig）は、を使用してAstra Tridentバックエンドを管理できるフロントエンドのネームスペースCRDです。 `kubectl`Kubernetes管理者やストレージ管理者は、Kubernetes CLIを使用して直接バックエンドを作成、管理できるようになりまし(`tridentctl`た。専用のコマンドラインユーティリティは必要ありません）。

オブジェクトを作成すると、 `TridentBackendConfig`次の処理が実行されます。

  • バックエンドは、指定した構成に基づいて Astra Trident によって自動的に作成されます。これは内部的には (tbe、 tridentbackend）CRとして表され `TridentBackend`ます。

  • は TridentBackendConfig、Astra Tridentで作成されたに一意にバインドされます TridentBackend。

それぞれが `TridentBackendConfig`との1対1のマッピングを保持し `TridentBackend`ます。前者はバックエンドを設計および設定するためにユーザーに提供されるインターフェイスです。後者はTridentが実際のバックエンドオブジェクトを表す方法です。

警告 `TridentBackend`CRSはAstra Tridentによって自動的に作成されます。これらは * 変更しないでください。バックエンドを更新するには、オブジェクトを変更し `TridentBackendConfig`ます。

CRの形式については、次の例を参照して `TridentBackendConfig`ください。

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`セクションには、CRで新たに導入されたフィールドと `deletionPolicy`フィールド `TridentBackendConfig`も含まれてい `credentials`ます。

  • credentials：このパラメータは必須フィールドで、ストレージシステム/サービスとの認証に使用するクレデンシャルが含まれます。ユーザが作成した Kubernetes Secret に設定されます。クレデンシャルをプレーンテキストで渡すことはできないため、エラーになります。

  • deletionPolicy：このフィールドは、が削除されたときの動作を定義します TridentBackendConfig。次の 2 つの値のいずれかを指定できます。

    • delete:これにより、CRと関連するバックエンドの両方が削除され `TridentBackendConfig`ます。これがデフォルト値です。

    • retain：CRが削除されても、 TridentBackendConfig`バックエンド定義は引き続き存在し、で管理できます。 `tridentctl`削除ポリシーをに設定する `retain`と、ユーザは以前のリリース（21.04より前のリリース）にダウングレードして、作成されたバックエンドを保持できます。このフィールドの値は、の作成後に更新できます `TridentBackendConfig。

メモ バックエンドの名前はを使用して設定され `spec.backendName`ます。指定しない場合、バックエンドの名前はオブジェクトの名前（metadata.name）に設定され `TridentBackendConfig`ます。を使用してバックエンド名を明示的に設定することをお勧めし `spec.backendName`ます。
ヒント で作成されたバックエンドに tridentctl`は、関連付けられたオブジェクトはありません `TridentBackendConfig。このようなバックエンドをで管理するには、 kubectl`CRを作成し `TridentBackendConfig`ます。同一の設定パラメータ（、、 `spec.storagePrefix spec.storageDriverName`など）を指定するように注意する必要があります `spec.backendName。Astra Tridentは、新しく作成されたを既存のバックエンドに自動的にバインドし `TridentBackendConfig`ます。

手順の概要

を使用して新しいバックエンドを作成するには kubectl、次の手順を実行します。

  1. を作成し "Kubernetes Secret"ます。シークレットには、Astra Tridentがストレージクラスタ/サービスと通信するために必要なクレデンシャルが含まれています。

  2. オブジェクトを作成し `TridentBackendConfig`ます。ストレージクラスタ / サービスの詳細を指定し、前の手順で作成したシークレットを参照します。

バックエンドを作成したら、を使用してそのステータスを確認し、追加の詳細情報を収集できます kubectl get tbc <tbc-name> -n <trident-namespace>。

手順 1 ： Kubernetes 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: t@Ax@7q(>

次の表に、各ストレージプラットフォームの Secret に含める必要があるフィールドをまとめます。

ストレージプラットフォームのシークレットフィールド概要 秘密 Field 概要の略

Azure NetApp Files

ClientID

アプリケーション登録からのクライアント ID

Cloud Volumes Service for GCP

private_key_id です

秘密鍵の ID 。CVS 管理者ロールを持つ GCP サービスアカウントの API キーの一部

Cloud Volumes Service for GCP

private_key を使用します

秘密鍵CVS 管理者ロールを持つ GCP サービスアカウントの API キーの一部

Element （ NetApp HCI / SolidFire ）

エンドポイント

テナントのクレデンシャルを使用する SolidFire クラスタの MVIP

ONTAP

ユーザ名

クラスタ / SVM に接続するためのユーザ名。クレデンシャルベースの認証に使用されます

ONTAP

パスワード

クラスタ / SVM に接続するためのパスワード。クレデンシャルベースの認証に使用されます

ONTAP

clientPrivateKey

クライアント秘密鍵の Base64 エンコード値。証明書ベースの認証に使用されます

ONTAP

chapUsername のコマンド

インバウンドユーザ名。useCHAP = true の場合は必須。および ontap-san-economy`の場合 `ontap-san

ONTAP

chapInitiatorSecret

CHAP イニシエータシークレット。useCHAP = true の場合は必須。および ontap-san-economy`の場合 `ontap-san

ONTAP

chapTargetUsername のコマンド

ターゲットユーザ名。useCHAP = true の場合は必須。および ontap-san-economy`の場合 `ontap-san

ONTAP

chapTargetInitiatorSecret

CHAP ターゲットイニシエータシークレット。useCHAP = true の場合は必須。および ontap-san-economy`の場合 `ontap-san

このステップで作成したシークレットは、次のステップで作成したオブジェクトのフィールド `TridentBackendConfig`で参照され `spec.credentials`ます。

ステップ2：CRを作成する TridentBackendConfig

これでCRを作成する準備ができ TridentBackendConfig`ました。この例では、ドライバを使用するバックエンドが `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：CRのステータスを確認する 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

バックエンドが正常に作成され、CRにバインドされまし `TridentBackendConfig`た。

フェーズには次のいずれかの値を指定できます。

  • Bound: TridentBackendConfig CRはバックエンドに関連付けられており、そのバックエンドにはCRのuidがセットされ `TridentBackendConfig`てい `configRef`ます。

  • Unbound:を使用して表されます ""。 `TridentBackendConfig`オブジェクトはバックエンドにバインドされていません。デフォルトでは、新しく作成されたすべての `TridentBackendConfig`CRSがこのフェーズになります。フェーズが変更された後、再度 Unbound に戻すことはできません。

  • Deleting：CR deletionPolicy`は `TridentBackendConfig`削除するように設定されています。CRが削除されると `TridentBackendConfig、CRは削除ステートに移行します。

    • バックエンドに永続的ボリューム要求（PVC）が存在しない場合は、を削除する `TridentBackendConfig`とAstra TridentでバックエンドとCRが削除され `TridentBackendConfig`ます。

    • バックエンドに 1 つ以上の PVC が存在する場合は、削除状態になります。 TridentBackendConfig`その後、CRは削除フェーズに入ります。バックエンドとは `TridentBackendConfig、すべてのPVCが削除された後にのみ削除されます。

  • Lost：CRに関連付けられているバックエンドが TridentBackendConfig`誤ってまたは故意に削除され、 `TridentBackendConfig`CRには削除されたバックエンドへの参照が残っています。 `TridentBackendConfig`CRは、値に関係なく削除できます `deletionPolicy。

  • Unknown：Astra Tridentは、CRに関連付けられたバックエンドの状態または存在を特定できません TridentBackendConfig。たとえば、APIサーバが応答していない場合やCRDが見つからない場合 `tridentbackends.trident.netapp.io`などです。これには介入が必要な場合があります

この段階では、バックエンドが正常に作成されます。など、追加で処理できる処理がいくつかあります"バックエンドの更新とバックエンドの削除"。

（オプション）手順 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`CRに応答して作成されたバックエンドの `TridentBackendConfig`とが `backendUUID`格納され `backendName`ます。 `lastOperationStatus`フィールドはCRの最後の処理のステータスを表し `TridentBackendConfig`ます。ユーザトリガー（でユーザが変更した場合など）、またはAstra Tridentによってトリガーされた（Astra Tridentの再起動時など）ことができます `spec。成功または失敗のいずれかです。 phase`CRとバックエンド間の関係のステータスを表します `TridentBackendConfig。上の例では、の phase`値がバインドされています。つまり、CRがバックエンドに関連付けられていることを意味します `TridentBackendConfig。

イベントログの詳細を取得するには、コマンドを実行し `kubectl -n trident describe tbc <tbc-cr-name>`ます。

警告 を使用して、関連付けられたオブジェクトを tridentctl`含むバックエンドを更新または削除することはできません `TridentBackendConfig。とを TridentBackendConfig`切り替える手順について説明します `tridentctl "こちらを参照してください"。