Crea backend con kubectl
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 unTridentBackend
Creato 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 l’elenco delle opzioni di configurazione per il driver di storage desiderato, consultare "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 quandoTridentBackendConfig
viene cancellato. Può assumere uno dei due valori possibili:-
delete
: Questo comporta l’eliminazione di entrambiTridentBackendConfig
CR e il backend associato. Questo è il valore predefinito. -
retain
: Quando unTridentBackendConfig
La CR viene eliminata, la definizione di back-end rimane presente e può essere gestita contridentctl
. Impostazione del criterio di eliminazione suretain
consente 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 unTridentBackendConfig
viene 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
TridentBackendConfig
oggetto. 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 AWS |
ApiKey |
Chiave API dell’account CVS |
Cloud Volumes Service per AWS |
SecretKey |
Chiave segreta dell’account CVS |
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
: IlTridentBackendConfig
CR è associato a un backend e contiene tale backendconfigRef
impostare suTridentBackendConfig
L’uid di CR. -
Unbound
: Rappresentato utilizzando""
. IlTridentBackendConfig
l’oggetto non è associato a un backend. Tutti creati di recenteTridentBackendConfig
I CRS sono in questa fase per impostazione predefinita. Una volta modificata la fase, non sarà più possibile tornare a Unbound. -
Deleting
: IlTridentBackendConfig
CRdeletionPolicy
è stato impostato per l’eliminazione. Quando ilTridentBackendConfig
La CR viene eliminata, passa allo stato di eliminazione.-
Se non sono presenti richieste di rimborso di volumi persistenti (PVC) sul back-end, eliminare il
TridentBackendConfig
In questo modo Astra Trident elimina il backend e ilTridentBackendConfig
CR. -
Se uno o più PVC sono presenti sul backend, passa a uno stato di eliminazione. Il
TridentBackendConfig
Successivamente, la CR entra anche nella fase di eliminazione. Il backend e.TridentBackendConfig
Vengono eliminati solo dopo l’eliminazione di tutti i PVC.
-
-
Lost
: Il backend associato aTridentBackendConfig
La CR è stata eliminata accidentalmente o deliberatamente e ilTridentBackendConfig
CR ha ancora un riferimento al backend cancellato. IlTridentBackendConfig
La CR può comunque essere eliminata indipendentemente dadeletionPolicy
valore. -
Unknown
: Astra Trident non è in grado di determinare lo stato o l’esistenza del backend associato aTridentBackendConfig
CR. Ad esempio, se il server API non risponde o setridentbackends.trident.netapp.io
CRD 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".
|