Skip to main content
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 Trident und einem Storage-System. Er erzählt Trident, wie man mit diesem Storage-System kommuniziert und wie Trident Volumes daraus bereitstellen sollte. Nach der Installation von Trident wird im nächsten Schritt ein Backend erstellt. Mit der TridentBackendConfig CRD-Definition (Custom Resource Definition) können Sie Trident Back-Ends direkt über die Kubernetes-Schnittstelle erstellen und managen. Sie können dies mit kubectl oder mit dem entsprechenden CLI-Tool für Ihre Kubernetes-Distribution tun.

TridentBackendConfig

TridentBackendConfig (tbc, tbconfig, tbackendconfig) Ist ein Frontend, namested CRD, das Ihnen ermöglicht, Trident-Backends mit verwalten kubectl. Kubernetes- und Storage-Administratoren können jetzt Back-Ends direkt über die Kubernetes-CLI erstellen und managen(tridentctl, ohne dass ein dediziertes Befehlszeilendienstprogramm erforderlich ist ).

Bei der Erstellung eines TridentBackendConfig Objekt, geschieht Folgendes:

  • Basierend auf der von Ihnen bereitgestellten Konfiguration wird von Trident automatisch ein Backend erstellt. Dies wird intern als (tbe, tridentbackend) CR dargestellt TridentBackend.

  • Das TridentBackendConfig ist eindeutig an ein gebunden TridentBackend, das von Trident erstellt wurde.

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 Trident erstellt. Sie sollten diese nicht ändern. Wenn Sie Änderungen an Back-Ends 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 im "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, haben kein zugeordnetes TridentBackendConfig Objekt. Sie können diese Back-Ends mit verwalten kubectl, indem Sie ein CR erstellen TridentBackendConfig. Es ist darauf zu achten, identische Konfigurationsparameter anzugeben (z. B. spec.backendName, , spec.storagePrefix spec.storageDriverName und so weiter). Trident bindet das neu erstellte mit dem bereits vorhandenen Backend automatisch TridentBackendConfig.

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 Anmeldeinformationen, die Trident benötigt, um mit dem Speicher-Cluster/Service zu kommunizieren.

  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 auf dem Backend keine Persistent Volume Claims (PVCs) vorhanden sind, führt das Löschen des TridentBackendConfig dazu, dass Trident das Backend sowie den CR löscht TridentBackendConfig.

    • 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: Trident kann den Status oder die Existenz des mit dem CR verknüpften Backends nicht bestimmen TridentBackendConfig. Beispiel: Wenn der API-Server nicht reagiert oder die 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 die backendName und die backendUUID des Backends, das als Antwort auf den CR erstellt wurde TridentBackendConfig. Das lastOperationStatus Feld stellt den Status des letzten Vorgangs des CR dar TridentBackendConfig, der vom Benutzer ausgelöst werden kann (z. B. Benutzer hat etwas in geändert spec) oder durch Trident ausgelöst (z. B. beim Neustart von Trident). Es kann entweder erfolgreich oder fehlgeschlagen sein. phase Stellt den Status der Beziehung zwischen dem CR und dem Backend dar TridentBackendConfig. Im obigen Beispiel phase hat der Wert gebunden, was bedeutet, dass der TridentBackendConfig CR mit dem Backend verknüpft ist.

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".