Passare da un'opzione di gestione back-end all'altra
Scopri i diversi modi di gestire i backend in Trident.
Opzioni per la gestione dei backend
Con l'introduzione di TridentBackendConfig
, gli amministratori dispongono ora di due metodi unici per gestire i back-end. Questo pone le seguenti domande:
-
È possibile creare backend utilizzando
tridentctl
essere gestito conTridentBackendConfig
? -
È possibile creare backend utilizzando
TridentBackendConfig
essere gestito contridentctl
?
Gestire tridentctl
backend con TridentBackendConfig
In questa sezione vengono descritte le procedure necessarie per gestire i backend creati con tridentctl
Direttamente attraverso l'interfaccia Kubernetes creando TridentBackendConfig
oggetti.
Questo si applica ai seguenti scenari:
-
Backend preesistenti, che non hanno un
TridentBackendConfig
perché sono stati creati contridentctl
. -
Nuovi backend creati con
tridentctl
, mentre altriTridentBackendConfig
esistono oggetti.
In entrambi gli scenari, i backend continueranno a essere presenti, con Trident che pianifica i volumi e li utilizza. Gli amministratori possono scegliere tra due opzioni:
-
Continuare a utilizzare
tridentctl
per gestire i back-end creati utilizzando l'it. -
Collegare i backend creati con
tridentctl
a un nuovoTridentBackendConfig
oggetto. In questo modo, i backend verranno gestiti utilizzandokubectl
e nontridentctl
.
Per gestire un backend preesistente utilizzando kubectl
, sarà necessario creare un TridentBackendConfig
che si collega al back-end esistente. Ecco una panoramica sul funzionamento di questo sistema:
-
Crea un Kubernetes Secret. Il segreto contiene le credenziali di cui Trident ha bisogno per comunicare con il cluster/servizio di archiviazione.
-
Creare un
TridentBackendConfig
oggetto. Contiene specifiche relative al cluster/servizio di storage e fa riferimento al segreto creato nel passaggio precedente. È necessario specificare parametri di configurazione identici (ad esempiospec.backendName
,spec.storagePrefix
,spec.storageDriverName`e così via). `spec.backendName
deve essere impostato sul nome del backend esistente.
Fase 0: Identificare il backend
Per creare un TridentBackendConfig
che si collega a un backend esistente, sarà necessario ottenere la configurazione del backend. In questo esempio, supponiamo che sia stato creato un backend utilizzando la seguente definizione JSON:
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"
}
}
]
}
Fase 1: Creare un Kubernetes Secret
Creare un Segreto contenente le credenziali per il backend, come illustrato in questo esempio:
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
Fase 2: Creare un TridentBackendConfig
CR
Il passaggio successivo consiste nella creazione di un TridentBackendConfig
CR che si associerà automaticamente al preesistente ontap-nas-backend
(come in questo esempio). Assicurarsi che siano soddisfatti i seguenti requisiti:
-
Lo stesso nome backend viene definito in
spec.backendName
. -
I parametri di configurazione sono identici al backend originale.
-
I pool virtuali (se presenti) devono mantenere lo stesso ordine del backend originale.
-
Le credenziali vengono fornite attraverso un Kubernetes Secret e non in testo normale.
In questo caso, il TridentBackendConfig
avrà un aspetto simile al seguente:
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
Fase 3: Verificare lo stato di TridentBackendConfig
CR
Dopo il TridentBackendConfig
è stato creato, la sua fase deve essere Bound
. Deve inoltre riflettere lo stesso nome e UUID del backend esistente.
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 | +---------------------+----------------+--------------------------------------+--------+---------+
Il back-end verrà ora completamente gestito utilizzando tbc-ontap-nas-backend
TridentBackendConfig
oggetto.
Gestire TridentBackendConfig
backend con tridentctl
`tridentctl` può essere utilizzato per elencare i backend creati con `TridentBackendConfig`. Inoltre, gli amministratori possono anche scegliere di gestire completamente tali backend attraverso `tridentctl` eliminando `TridentBackendConfig` e assicurandosi `spec.deletionPolicy` è impostato su `retain`.
Fase 0: Identificare il backend
Ad esempio, supponiamo che il seguente backend sia stato creato utilizzando 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 | +-------------------+----------------+--------------------------------------+--------+---------+
Dall'output, si vede che TridentBackendConfig
È stato creato correttamente ed è associato a un backend [osservare l'UUID del backend].
Fase 1: Confermare deletionPolicy
è impostato su retain
Diamo un'occhiata al valore di deletionPolicy
. Questo deve essere impostato su retain
. In questo modo, quando si elimina un TridentBackendConfig
CR, la definizione di backend sarà ancora presente e potrà essere gestita con 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
|
Non passare alla fase successiva a meno che deletionPolicy è impostato su retain .
|
Fase 2: Eliminare TridentBackendConfig
CR
Il passaggio finale consiste nell'eliminare TridentBackendConfig
CR. Dopo la conferma di deletionPolicy
è impostato su retain
, è possibile procedere con l'eliminazione:
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 | +-------------------+----------------+--------------------------------------+--------+---------+
All'eliminazione dell' `TridentBackendConfig`oggetto, Trident lo rimuove semplicemente senza eliminare effettivamente il backend stesso.