Wechseln Sie zwischen den Back-End-Managementoptionen
Erfahren Sie mehr über die verschiedenen Möglichkeiten für das Management von Back-Ends in Trident.
Optionen für das Management von Back-Ends
Mit der Einführung von TridentBackendConfig
, Administratoren haben jetzt zwei unterschiedliche Arten von Back-Ends zu verwalten. Dies stellt die folgenden Fragen:
-
Mit können Back-Ends erstellt werden
tridentctl
Gemanagt werden mitTridentBackendConfig
? -
Mit können Back-Ends erstellt werden
TridentBackendConfig
Gemanagt werden mittridentctl
?
Managen tridentctl
Back-Ends mit TridentBackendConfig
In diesem Abschnitt werden die Schritte aufgeführt, die für das Management von Back-Ends erforderlich sind, die mit erstellt wurden tridentctl
Erstellen Sie direkt über die Kubernetes Schnittstelle TridentBackendConfig
Objekte:
Dies gilt für die folgenden Szenarien:
-
Bereits vorhandene Back-Ends, die keine haben
TridentBackendConfig
Weil sie mit erstellt wurdentridentctl
. -
Neue Back-Ends, mit denen erstellt wurden
tridentctl
, Während andereTridentBackendConfig
Objekte sind vorhanden.
In beiden Szenarien sind Back-Ends weiterhin vorhanden, wobei Trident Volumes terminiert und darauf ausgeführt werden. Administratoren können hier eine von zwei Möglichkeiten wählen:
-
Fahren Sie mit der Verwendung fort
tridentctl
Um Back-Ends zu managen, die mit ihr erstellt wurden. -
Back-Ends werden mit erstellt
tridentctl
Zu einer neuenTridentBackendConfig
Objekt: Dies würde bedeuten, dass die Back-Ends mit gemanagt werdenkubectl
Und nichttridentctl
.
Um ein bereits vorhandenes Backend mit zu verwalten kubectl
, Sie müssen ein erstellen TridentBackendConfig
Das bindet an das vorhandene Backend. Hier eine Übersicht über die Funktionsweise:
-
Kubernetes Secret erstellen: Das Geheimnis enthält die Anmeldeinformationen, die Trident zur Kommunikation mit dem Storage-Cluster/Service benötigt.
-
Erstellen Sie ein
TridentBackendConfig
Objekt: Dies enthält Angaben zum Storage-Cluster/Service und verweist auf das im vorherigen Schritt erstellte Geheimnis. Es muss sorgfältig darauf achten, identische Konfigurationsparameter festzulegen (z. B.spec.backendName
,spec.storagePrefix
,spec.storageDriverName
, Und so weiter).spec.backendName
Muss auf den Namen des vorhandenen Backend eingestellt werden.
Schritt 0: Identifizieren Sie das Backend
Um ein zu erstellen TridentBackendConfig
Die an ein vorhandenes Backend bindet, müssen Sie die Backend-Konfiguration abrufen. In diesem Beispiel nehmen wir an, dass ein Backend mithilfe der folgenden JSON-Definition erstellt wurde:
tridentctl get backend ontap-nas-backend -n trident +---------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +---------------------+----------------+--------------------------------------+--------+---------+ | ontap-nas-backend | ontap-nas | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online | 25 | +---------------------+----------------+--------------------------------------+--------+---------+
cat ontap-nas-backend.json
{
"version": 1,
"storageDriverName": "ontap-nas",
"managementLIF": "10.10.10.1",
"dataLIF": "10.10.10.2",
"backendName": "ontap-nas-backend",
"svm": "trident_svm",
"username": "cluster-admin",
"password": "admin-password",
"defaults": {
"spaceReserve": "none",
"encryption": "false"
},
"labels": {
"store": "nas_store"
},
"region": "us_east_1",
"storage": [
{
"labels": {
"app": "msoffice",
"cost": "100"
},
"zone": "us_east_1a",
"defaults": {
"spaceReserve": "volume",
"encryption": "true",
"unixPermissions": "0755"
}
},
{
"labels": {
"app": "mysqldb",
"cost": "25"
},
"zone": "us_east_1d",
"defaults": {
"spaceReserve": "volume",
"encryption": "false",
"unixPermissions": "0775"
}
}
]
}
Schritt: Ein Kubernetes Secret erstellen
Erstellen Sie einen geheimen Schlüssel, der die Anmeldeinformationen für das Backend enthält, wie in diesem Beispiel gezeigt:
cat tbc-ontap-nas-backend-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: ontap-nas-backend-secret
type: Opaque
stringData:
username: cluster-admin
password: admin-password
kubectl create -f tbc-ontap-nas-backend-secret.yaml -n trident secret/backend-tbc-ontap-san-secret created
Schritt 2: Erstellen Sie ein TridentBackendConfig
CR
Im nächsten Schritt wird ein erstellt TridentBackendConfig
CR, das automatisch an die bereits vorhandene bindet ontap-nas-backend
(Wie in diesem Beispiel). Stellen Sie sicher, dass folgende Anforderungen erfüllt sind:
-
Der gleiche Backend-Name wird in definiert
spec.backendName
. -
Die Konfigurationsparameter sind mit dem ursprünglichen Back-End identisch.
-
Virtuelle Pools (falls vorhanden) müssen dieselbe Reihenfolge wie im ursprünglichen Backend beibehalten.
-
Anmeldedaten werden bei einem Kubernetes Secret und nicht im Klartext bereitgestellt.
In diesem Fall die TridentBackendConfig
Wird so aussehen:
cat backend-tbc-ontap-nas.yaml
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: tbc-ontap-nas-backend
spec:
version: 1
storageDriverName: ontap-nas
managementLIF: 10.10.10.1
dataLIF: 10.10.10.2
backendName: ontap-nas-backend
svm: trident_svm
credentials:
name: mysecret
defaults:
spaceReserve: none
encryption: 'false'
labels:
store: nas_store
region: us_east_1
storage:
- labels:
app: msoffice
cost: '100'
zone: us_east_1a
defaults:
spaceReserve: volume
encryption: 'true'
unixPermissions: '0755'
- labels:
app: mysqldb
cost: '25'
zone: us_east_1d
defaults:
spaceReserve: volume
encryption: 'false'
unixPermissions: '0775'
kubectl create -f backend-tbc-ontap-nas.yaml -n trident tridentbackendconfig.trident.netapp.io/tbc-ontap-nas-backend created
Schritt 3: Überprüfen Sie den Status des TridentBackendConfig
CR
Nach dem TridentBackendConfig
Wurde erstellt, seine Phase muss sein Bound
. Sie sollte außerdem den gleichen Backend-Namen und die gleiche UUID wie das vorhandene Backend widerspiegeln.
kubectl get tbc tbc-ontap-nas-backend -n trident NAME BACKEND NAME BACKEND UUID PHASE STATUS tbc-ontap-nas-backend ontap-nas-backend 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 Bound Success #confirm that no new backends were created (i.e., TridentBackendConfig did not end up creating a new backend) tridentctl get backend -n trident +---------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +---------------------+----------------+--------------------------------------+--------+---------+ | ontap-nas-backend | ontap-nas | 52f2eb10-e4c6-4160-99fc-96b3be5ab5d7 | online | 25 | +---------------------+----------------+--------------------------------------+--------+---------+
Das Backend wird nun vollständig mit dem verwaltet tbc-ontap-nas-backend
TridentBackendConfig
Objekt:
Managen TridentBackendConfig
Back-Ends mit tridentctl
`tridentctl` Kann zur Auflistung von Back-Ends verwendet werden, die mit erstellt wurden `TridentBackendConfig`. Darüber hinaus können Administratoren solche Back-Ends mithilfe von auch vollständig managen `tridentctl` Durch Löschen `TridentBackendConfig` Mit Sicherheit `spec.deletionPolicy` Ist auf festgelegt `retain`.
Schritt 0: Identifizieren Sie das Backend
Nehmen wir beispielsweise an, dass das folgende Backend mit erstellt wurde TridentBackendConfig
:
kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san delete tridentctl get backend ontap-san-backend -n trident +-------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +-------------------+----------------+--------------------------------------+--------+---------+ | ontap-san-backend | ontap-san | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online | 33 | +-------------------+----------------+--------------------------------------+--------+---------+
Von der Ausgabe, ist es gesehen, dass TridentBackendConfig
Wurde erfolgreich erstellt und ist an ein Backend gebunden [UUID des Backends beobachten].
Schritt 1: Bestätigen deletionPolicy
Ist auf festgelegt retain
Lassen Sie uns einen Blick auf den Wert von deletionPolicy
. Dies muss auf eingestellt werden retain
. Dadurch wird sichergestellt, dass beim Löschen eines TridentBackendConfig
CR die Backend-Definition weiterhin vorhanden ist und mit verwaltet werden kann tridentctl
.
kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san delete # Patch value of deletionPolicy to retain kubectl patch tbc backend-tbc-ontap-san --type=merge -p '{"spec":{"deletionPolicy":"retain"}}' -n trident tridentbackendconfig.trident.netapp.io/backend-tbc-ontap-san patched #Confirm the value of deletionPolicy kubectl get tbc backend-tbc-ontap-san -n trident -o wide NAME BACKEND NAME BACKEND UUID PHASE STATUS STORAGE DRIVER DELETION POLICY backend-tbc-ontap-san ontap-san-backend 81abcb27-ea63-49bb-b606-0a5315ac5f82 Bound Success ontap-san retain
|
Fahren Sie nur mit dem nächsten Schritt fort deletionPolicy Ist auf festgelegt retain .
|
Schritt 2: Löschen Sie den TridentBackendConfig
CR
Der letzte Schritt besteht darin, den zu löschen TridentBackendConfig
CR. Nach Bestätigung des deletionPolicy
Ist auf festgelegt retain
, Sie können mit der Löschung fortfahren:
kubectl delete tbc backend-tbc-ontap-san -n trident tridentbackendconfig.trident.netapp.io "backend-tbc-ontap-san" deleted tridentctl get backend ontap-san-backend -n trident +-------------------+----------------+--------------------------------------+--------+---------+ | NAME | STORAGE DRIVER | UUID | STATE | VOLUMES | +-------------------+----------------+--------------------------------------+--------+---------+ | ontap-san-backend | ontap-san | 81abcb27-ea63-49bb-b606-0a5315ac5f82 | online | 33 | +-------------------+----------------+--------------------------------------+--------+---------+
Beim Löschen des TridentBackendConfig
Objekts entfernt Trident es einfach, ohne das Backend selbst zu löschen.