Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Back-Ends mit kubectl erstellen

Beitragende
PDFs

Ein Backend definiert die Beziehung zwischen Astra Trident und einem Storage-System. Er erzählt Astra Trident, wie man mit diesem Storage-System kommuniziert und wie Astra Trident Volumes darauf bereitstellen sollte. Nach der Installation von Astra Trident ist der nächste Schritt die Erstellung eines Backend. Der TridentBackendConfig Mit Custom Resource Definition (CRD) können Sie Trident Back-Ends direkt über die Kubernetes Schnittstelle erstellen und managen. Dies können Sie mit tun kubectl Oder das vergleichbare CLI Tool für Ihre Kubernetes Distribution.

TridentBackendConfig

TridentBackendConfig (tbc, tbconfig, tbackendconfig) Ist ein Front-End, Namensvetter CRD, mit dem Sie Astra Trident Back-Ends mit verwalten können kubectl. Kubernetes- und Storage-Administratoren können Back-Ends jetzt direkt über die Kubernetes-CLI erstellen und managen, ohne dass ein dediziertes Dienstprogramm für die Befehlszeilenschnittstelle erforderlich ist (tridentctl).

Bei der Erstellung eines TridentBackendConfig Objekt, geschieht Folgendes:

  • Ein Back-End wird automatisch von Astra Trident auf Basis der von Ihnen zu erstellenden Konfiguration erstellt. Dies wird intern als A dargestellt TridentBackend (tbe, tridentbackend) CR.

  • Der TridentBackendConfig Ist eindeutig an A gebunden TridentBackend Das wurde von Astra Trident entwickelt.

Beide TridentBackendConfig Pflegt eine 1:1-Zuordnung mit einem TridentBackend. Die erstere Schnittstelle, die dem Benutzer zum Design und zur Konfiguration von Back-Ends zur Verfügung gestellt wird. Letztere ist, wie Trident das tatsächliche Backend-Objekt darstellt.

Warnung TridentBackend CRS werden automatisch von Astra Trident erstellt. Sie sollten diese nicht ändern. Wenn Sie an Back-Ends Aktualisierungen vornehmen möchten, ändern Sie das TridentBackendConfig Objekt:

Im folgenden Beispiel finden Sie Informationen zum Format des 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

Sie können sich auch die Beispiele im ansehen "trident-Installationsprogramm" Verzeichnis für Beispielkonfigurationen für die gewünschte Speicherplattform/den gewünschten Service.

Der spec Nimmt Back-End-spezifische Konfigurationsparameter ein. In diesem Beispiel verwendet das Backend ontap-san Speichertreiber und verwendet die hier tabellarischen Konfigurationsparameter. Eine Liste der Konfigurationsoptionen für den gewünschten Speichertreiber finden Sie unter "Back-End-Konfigurationsinformationen für Ihren Speichertreiber".

Der spec Abschnitt enthält auch credentials Und deletionPolicy Felder, die neu in den eingeführt werden TridentBackendConfig CR:

  • credentials: Dieser Parameter ist ein Pflichtfeld und enthält die Anmeldeinformationen, die zur Authentifizierung mit dem Speichersystem/Service verwendet werden. Dies ist auf ein vom Benutzer erstelltes Kubernetes Secret festgelegt. Die Anmeldeinformationen können nicht im Klartext weitergegeben werden und führen zu einem Fehler.

  • deletionPolicy: Dieses Feld definiert, was passieren soll, wenn der TridentBackendConfig Wird gelöscht. Es kann einen von zwei möglichen Werten annehmen:

    • delete: Dies führt zur Löschung beider TridentBackendConfig CR und das zugehörige Backend. Dies ist der Standardwert.

    • retain: Wenn a TridentBackendConfig CR wird gelöscht, die Backend-Definition ist weiterhin vorhanden und kann mit verwaltet werden tridentctl. Einstellen der Löschrichtlinie auf retain Benutzer können ein Downgrade auf eine frühere Version (vor 21.04) durchführen und die erstellten Back-Ends behalten. Der Wert für dieses Feld kann nach einem aktualisiert werden TridentBackendConfig Wird erstellt.

Hinweis Der Name eines Backend wird mit festgelegt spec.backendName. Wenn nicht angegeben, wird der Name des Backend auf den Namen des gesetzt TridentBackendConfig Objekt (metadata.name). Es wird empfohlen, mit explizit Back-End-Namen festzulegen spec.backendName.
Tipp Back-Ends, die mit erstellt wurden tridentctl Ist nicht zugeordnet TridentBackendConfig Objekt: Sie können solche Back-Ends mit verwalten kubectl Durch Erstellen von A TridentBackendConfig CR. Es muss sorgfältig darauf achten, identische Konfigurationsparameter festzulegen (z. B. spec.backendName, spec.storagePrefix, spec.storageDriverName, Und so weiter). Astra Trident bindet automatisch die neu erstellte TridentBackendConfig Mit dem bereits vorhandenen Backend.

Schritte im Überblick

Um ein neues Backend mit zu erstellen kubectl, Sie sollten Folgendes tun:

  1. Erstellen Sie ein "Kubernetes Secret". Das Geheimnis enthält die Zugangsdaten, die Astra Trident zur Kommunikation mit dem Storage-Cluster/Service benötigt.

  2. Erstellen Sie ein TridentBackendConfig Objekt: Dies enthält Angaben zum Storage-Cluster/Service und verweist auf das im vorherigen Schritt erstellte Geheimnis.

Nachdem Sie ein Backend erstellt haben, können Sie den Status mit beobachten kubectl get tbc <tbc-name> -n <trident-namespace> Und sammeln Sie weitere Details.

Schritt: Ein Kubernetes Secret erstellen

Erstellen Sie einen geheimen Schlüssel, der die Anmeldedaten für den Zugriff für das Backend enthält. Dies ist nur bei jedem Storage Service/jeder Plattform möglich. Hier ein Beispiel:

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(>

In dieser Tabelle sind die Felder zusammengefasst, die für jede Speicherplattform im Secret enthalten sein müssen:

Beschreibung der geheimen Felder der Speicherplattform Geheim Feldbeschreibung

Azure NetApp Dateien

Client-ID

Die Client-ID aus einer App-Registrierung

Cloud Volumes Service für GCP

Private_Schlüssel_id

ID des privaten Schlüssels. Teil des API-Schlüssels für GCP-Servicekonto mit CVS-Administratorrolle

Cloud Volumes Service für GCP

Privater_Schlüssel

Privater Schlüssel. Teil des API-Schlüssels für GCP-Servicekonto mit CVS-Administratorrolle

Element (NetApp HCI/SolidFire)

Endpunkt

MVIP für den SolidFire-Cluster mit Mandanten-Anmeldedaten

ONTAP

Benutzername

Benutzername für die Verbindung mit dem Cluster/SVM. Wird für die Anmeldeinformationsbasierte Authentifizierung verwendet

ONTAP

Passwort

Passwort für die Verbindung mit dem Cluster/SVM Wird für die Anmeldeinformationsbasierte Authentifizierung verwendet

ONTAP

KundenPrivateKey

Base64-kodierte Wert des privaten Client-Schlüssels. Wird für die zertifikatbasierte Authentifizierung verwendet

ONTAP

ChapUsername

Eingehender Benutzername. Erforderlich, wenn usCHAP=true verwendet wird. Für ontap-san Und ontap-san-economy

ONTAP

ChapInitiatorSecret

CHAP-Initiatorschlüssel. Erforderlich, wenn usCHAP=true verwendet wird. Für ontap-san Und ontap-san-economy

ONTAP

ChapTargetBenutzername

Zielbenutzername. Erforderlich, wenn usCHAP=true verwendet wird. Für ontap-san Und ontap-san-economy

ONTAP

ChapTargetInitiatorSecret

Schlüssel für CHAP-Zielinitiator. Erforderlich, wenn usCHAP=true verwendet wird. Für ontap-san Und ontap-san-economy

Auf das in diesem Schritt erstellte Geheimnis wird im verwiesen spec.credentials Feld von TridentBackendConfig Objekt, das im nächsten Schritt erstellt wird.

Schritt 2: Erstellen Sie die TridentBackendConfig CR

Sie sind jetzt bereit, Ihre zu erstellen TridentBackendConfig CR. In diesem Beispiel wird ein Backend verwendet, das den verwendet ontap-san Treiber wird mithilfe des erstellt TridentBackendConfig Unten gezeigte Objekte:

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

Schritt 3: Überprüfen Sie den Status des TridentBackendConfig CR

Nun, da Sie die erstellt haben TridentBackendConfig CR, Sie können den Status überprüfen. Das folgende Beispiel zeigt:

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

Ein Back-End wurde erfolgreich erstellt und an das gebunden TridentBackendConfig CR.

Die Phase kann einen der folgenden Werte annehmen:

  • Bound: Das TridentBackendConfig CR ist mit einem Backend verknüpft, und dieses Backend enthält configRef Auf einstellen TridentBackendConfig CR-UID.

  • Unbound: Dargestellt mit "". Der TridentBackendConfig Objekt ist nicht an ein Backend gebunden. Neu erstellt TridentBackendConfig CRS befinden sich standardmäßig in dieser Phase. Wenn die Phase sich ändert, kann sie nicht wieder auf Unbound zurückgesetzt werden.

  • Deleting: Das TridentBackendConfig CR deletionPolicy Wurde auf Löschen festgelegt. Wenn der TridentBackendConfig CR wird gelöscht und wechselt in den Löschzustand.

    • Wenn im Backend keine PVCs (Persistent Volume Claims) vorhanden sind, löschen Sie den TridentBackendConfig Wird dazu führen, dass Astra Trident das Backend sowie das löscht TridentBackendConfig CR.

    • Wenn ein oder mehrere VES im Backend vorhanden sind, wechselt es in den Löschzustand. Der TridentBackendConfig Anschließend wechselt CR in die Löschphase. Das Backend und TridentBackendConfig Werden erst gelöscht, nachdem alle PVCs gelöscht wurden.

  • Lost: Das Backend, das mit dem verbunden ist TridentBackendConfig CR wurde versehentlich oder absichtlich gelöscht und das TridentBackendConfig CR hat noch einen Verweis auf das gelöschte Backend. Der TridentBackendConfig CR kann weiterhin unabhängig vom gelöscht werden deletionPolicy Wert:

  • Unknown: Astra Trident kann den Zustand oder die Existenz des mit dem verbundenen Backend nicht bestimmen TridentBackendConfig CR. Beispiel: Wenn der API-Server nicht antwortet oder wenn der tridentbackends.trident.netapp.io CRD fehlt. Dies kann Eingriffe erfordern.

In dieser Phase wird erfolgreich ein Backend erstellt! Es gibt mehrere Operationen, die zusätzlich gehandhabt werden können, wie z. B. "Back-End-Updates und Löschungen am Back-End".

(Optional) Schritt 4: Weitere Informationen

Sie können den folgenden Befehl ausführen, um weitere Informationen über Ihr Backend zu erhalten:

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

Zusätzlich können Sie auch einen YAML/JSON Dump von erhalten 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 Enthält backendName Und das backendUUID Des Back-End, das als Antwort auf das erstellt wurde TridentBackendConfig CR. Der lastOperationStatus Feld gibt den Status des letzten Vorgangs des an TridentBackendConfig CR, der vom Benutzer ausgelöst werden kann (z. B. hat der Benutzer etwas in geändert spec) Oder ausgelöst durch Astra Trident (z. B. während Astra Trident Neustart). Er kann entweder erfolgreich oder fehlgeschlagen sein. phase Stellt den Status der Beziehung zwischen dem dar TridentBackendConfig CR und das Backend. Im obigen Beispiel phase Hat den Wert gebunden, was bedeutet, dass der TridentBackendConfig CR ist mit dem Backend verknüpft.

Sie können die ausführen kubectl -n trident describe tbc <tbc-cr-name> Befehl, um Details zu den Ereignisprotokollen zu erhalten.

Warnung Sie können ein Back-End, das einen zugeordneten enthält, nicht aktualisieren oder löschen TridentBackendConfig Objekt wird verwendet tridentctl. Um die Schritte zu verstehen, die mit dem Wechsel zwischen verbunden sind tridentctl Und TridentBackendConfig, "Sehen Sie hier".