Note di rilascio
Crea backend con kubectl
Suggerisci modifiche
PDF
Un backend definisce la relazione tra Astra Trident e un sistema storage. Spiega ad Astra Trident come comunicare con quel sistema storage e come Astra Trident dovrebbe eseguire il provisioning dei volumi da esso. Dopo aver installato Astra Trident, il passo successivo è quello di creare un backend. Il TridentBackendConfig Custom Resource Definition (CRD) consente di creare e gestire backend Trident direttamente attraverso l'interfaccia Kubernetes. Per eseguire questa operazione, utilizzare kubectl O il tool CLI equivalente per la distribuzione Kubernetes.
TridentBackendConfig
TridentBackendConfig (tbc, tbconfig, tbackendconfig) È un CRD front-end, namespace, che consente di gestire i backend Astra Trident utilizzando kubectl. Kubernetes e gli amministratori dello storage possono ora creare e gestire i backend direttamente attraverso la CLI di Kubernetes senza richiedere un'utility a riga di comando dedicata (tridentctl).
Alla creazione di un TridentBackendConfig oggetto, si verifica quanto segue:
-
Astra Trident crea automaticamente un backend in base alla configurazione che fornisci. Questo è rappresentato internamente come a.
TridentBackend(tbe,tridentbackend) CR. -
Il
TridentBackendConfigè vincolato in modo univoco a unTridentBackendCreato da Astra Trident.
Ciascuno TridentBackendConfig mantiene una mappatura uno a uno con un TridentBackend. Il primo è l'interfaccia fornita all'utente per progettare e configurare i backend; il secondo è il modo in cui Trident rappresenta l'oggetto backend effettivo.
|
TridentBackend I CRS vengono creati automaticamente da Astra Trident. Non è possibile modificarle. Se si desidera aggiornare i backend, modificare il TridentBackendConfig oggetto.
|
Vedere l'esempio seguente per il formato di 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
È inoltre possibile esaminare gli esempi in "trident-installer" directory per configurazioni di esempio per la piattaforma/servizio di storage desiderato.
Il spec utilizza parametri di configurazione specifici per il back-end. In questo esempio, il backend utilizza ontap-san storage driver e utilizza i parametri di configurazione riportati in tabella. Per un elenco delle opzioni di configurazione del driver di archiviazione desiderato, consultare la "informazioni di configurazione back-end per il driver di storage".
Il spec la sezione include anche credentials e. deletionPolicy i campi, che sono stati introdotti di recente in TridentBackendConfig CR:
-
credentials: Questo parametro è un campo obbligatorio e contiene le credenziali utilizzate per l'autenticazione con il sistema/servizio di storage. Questo è impostato su un Kubernetes Secret creato dall'utente. Le credenziali non possono essere passate in testo normale e si verificherà un errore. -
deletionPolicy: Questo campo definisce cosa deve accadere quandoTridentBackendConfigviene cancellato. Può assumere uno dei due valori possibili:-
delete: Questo comporta l'eliminazione di entrambiTridentBackendConfigCR e il backend associato. Questo è il valore predefinito. -
retain: Quando unTridentBackendConfigLa CR viene eliminata, la definizione di back-end rimane presente e può essere gestita contridentctl. Impostazione del criterio di eliminazione suretainconsente agli utenti di eseguire il downgrade a una release precedente (precedente alla 21.04) e conservare i backend creati. Il valore di questo campo può essere aggiornato dopo unTridentBackendConfigviene creato.
-
|
Il nome di un backend viene impostato utilizzando spec.backendName. Se non specificato, il nome del backend viene impostato sul nome di TridentBackendConfig oggetto (metadata.name). Si consiglia di impostare esplicitamente i nomi backend utilizzando spec.backendName.
|
|
Backend creati con tridentctl non hanno un associato TridentBackendConfig oggetto. È possibile scegliere di gestire tali backend con kubectl creando un TridentBackendConfig CR. È necessario specificare parametri di configurazione identici (ad esempio spec.backendName, spec.storagePrefix, spec.storageDriverName`e così via). Astra Trident eseguirà automaticamente il binding del nuovo `TridentBackendConfig con il backend preesistente.
|
Panoramica dei passaggi
Per creare un nuovo backend utilizzando kubectl, eseguire le seguenti operazioni:
-
Creare un "Kubernetes Secret". Il segreto contiene le credenziali che Astra Trident deve comunicare con il cluster/servizio di storage.
-
Creare un
TridentBackendConfigoggetto. Contiene specifiche relative al cluster/servizio di storage e fa riferimento al segreto creato nel passaggio precedente.
Dopo aver creato un backend, è possibile osservarne lo stato utilizzando kubectl get tbc <tbc-name> -n <trident-namespace> e raccogliere ulteriori dettagli.
Fase 1: Creare un Kubernetes Secret
Creare un segreto contenente le credenziali di accesso per il backend. Si tratta di una caratteristica esclusiva di ogni piattaforma/servizio di storage. Ecco un esempio:
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(>
Questa tabella riassume i campi che devono essere inclusi nel Secret per ciascuna piattaforma di storage:
| Descrizione dei campi segreti della piattaforma di storage | Segreto | Descrizione dei campi |
|---|---|---|
Azure NetApp Files |
ID cliente |
L'ID client dalla registrazione di un'applicazione |
Cloud Volumes Service per GCP |
id_chiave_privata |
ID della chiave privata. Parte della chiave API per l'account di servizio GCP con ruolo di amministratore CVS |
Cloud Volumes Service per GCP |
private_key |
Chiave privata. Parte della chiave API per l'account di servizio GCP con ruolo di amministratore CVS |
Elemento (NetApp HCI/SolidFire) |
Endpoint |
MVIP per il cluster SolidFire con credenziali tenant |
ONTAP |
nome utente |
Nome utente per la connessione al cluster/SVM. Utilizzato per l'autenticazione basata su credenziali |
ONTAP |
password |
Password per la connessione al cluster/SVM. Utilizzato per l'autenticazione basata su credenziali |
ONTAP |
ClientPrivateKey |
Valore codificato in base64 della chiave privata del client. Utilizzato per l'autenticazione basata su certificato |
ONTAP |
ChapNomeUtente |
Nome utente inbound. Obbligatorio se useCHAP=true. Per |
ONTAP |
ChapInitialatorSecret |
Segreto iniziatore CHAP. Obbligatorio se useCHAP=true. Per |
ONTAP |
ChapTargetNomeUtente |
Nome utente di destinazione. Obbligatorio se useCHAP=true. Per |
ONTAP |
ChapTargetInitialatorSecret |
CHAP target Initiator secret. Obbligatorio se useCHAP=true. Per |
Il Segreto creato in questo passaggio verrà indicato in spec.credentials campo di TridentBackendConfig oggetto creato nel passaggio successivo.
Fase 2: Creare TridentBackendConfig CR
A questo punto, è possibile creare il TridentBackendConfig CR. In questo esempio, un backend che utilizza ontap-san il driver viene creato utilizzando TridentBackendConfig oggetto mostrato di seguito:
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
Fase 3: Verificare lo stato di TridentBackendConfig CR
Ora che è stato creato il TridentBackendConfig CR, è possibile verificare lo stato. Vedere il seguente esempio:
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
Un backend è stato creato e associato a TridentBackendConfig CR.
La fase può assumere uno dei seguenti valori:
-
Bound: IlTridentBackendConfigCR è associato a un backend e contiene tale backendconfigRefimpostare suTridentBackendConfigUid di CR. -
Unbound: Rappresentato utilizzando"". IlTridentBackendConfigl'oggetto non è associato a un backend. Tutti creati di recenteTridentBackendConfigI CRS sono in questa fase per impostazione predefinita. Una volta modificata la fase, non sarà più possibile tornare a Unbound. -
Deleting: IlTridentBackendConfigCRdeletionPolicyè stato impostato per l'eliminazione. Quando ilTridentBackendConfigLa CR viene eliminata, passa allo stato di eliminazione.-
Se non sono presenti richieste di rimborso di volumi persistenti (PVC) sul back-end, eliminare il
TridentBackendConfigIn questo modo Astra Trident elimina il backend e ilTridentBackendConfigCR. -
Se uno o più PVC sono presenti sul backend, passa a uno stato di eliminazione. Il
TridentBackendConfigSuccessivamente, la CR entra anche nella fase di eliminazione. Il backend e.TridentBackendConfigVengono eliminati solo dopo l'eliminazione di tutti i PVC.
-
-
Lost: Il backend associato aTridentBackendConfigLa CR è stata eliminata accidentalmente o deliberatamente e ilTridentBackendConfigCR ha ancora un riferimento al backend cancellato. IlTridentBackendConfigLa CR può comunque essere eliminata indipendentemente dadeletionPolicyvalore. -
Unknown: Astra Trident non è in grado di determinare lo stato o l'esistenza del backend associato aTridentBackendConfigCR. Ad esempio, se il server API non risponde o setridentbackends.trident.netapp.ioCRD mancante. Ciò potrebbe richiedere l'intervento dell'utente.
In questa fase, viene creato un backend. È possibile gestire anche diverse operazioni, ad esempio "aggiornamenti back-end ed eliminazioni back-end".
(Facoltativo) fase 4: Ulteriori informazioni
È possibile eseguire il seguente comando per ottenere ulteriori informazioni sul backend:
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
Inoltre, è possibile ottenere un dump YAML/JSON di 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 contiene backendName e a. backendUUID del back-end creato in risposta a TridentBackendConfig CR. Il lastOperationStatus il campo rappresenta lo stato dell'ultima operazione di TridentBackendConfig CR, che può essere attivato dall'utente (ad esempio, l'utente ha modificato qualcosa in spec) O attivato da Astra Trident (ad esempio, durante il riavvio di Astra Trident). Può essere Success (riuscito) o Failed (non riuscito). phase rappresenta lo stato della relazione tra TridentBackendConfig CR e il back-end. Nell'esempio precedente, phase Ha il valore associato, il che significa che il TridentBackendConfig CR è associato al backend.
È possibile eseguire kubectl -n trident describe tbc <tbc-cr-name> per ottenere i dettagli dei registri degli eventi.
|
|
Non è possibile aggiornare o eliminare un backend che contiene un associato TridentBackendConfig utilizzo di oggetti tridentctl. Comprendere le fasi necessarie per passare da un'operazione all'altra tridentctl e. TridentBackendConfig, "vedi qui".
|