Skip to main content
È disponibile una versione più recente di questo prodotto.
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Crea backend con kubectl

Collaboratori netapp-aruldeepa netapp-mwallis juliantap
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 un TridentBackend 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.

Attenzione 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 quando TridentBackendConfig viene cancellato. Può assumere uno dei due valori possibili:

    • delete: Questo comporta l'eliminazione di entrambi TridentBackendConfig CR e il backend associato. Questo è il valore predefinito.

    • retain: Quando un TridentBackendConfig La CR viene eliminata, la definizione di back-end rimane presente e può essere gestita con tridentctl. Impostazione del criterio di eliminazione su retain 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 un TridentBackendConfig viene creato.

Nota 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.
Suggerimento 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:

  1. Creare un "Kubernetes Secret". Il segreto contiene le credenziali che Astra Trident deve comunicare con il cluster/servizio di storage.

  2. 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: password

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-san e. ontap-san-economy

ONTAP

ChapInitialatorSecret

Segreto iniziatore CHAP. Obbligatorio se useCHAP=true. Per ontap-san e. ontap-san-economy

ONTAP

ChapTargetNomeUtente

Nome utente di destinazione. Obbligatorio se useCHAP=true. Per ontap-san e. ontap-san-economy

ONTAP

ChapTargetInitialatorSecret

CHAP target Initiator secret. Obbligatorio se useCHAP=true. Per ontap-san e. ontap-san-economy

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: Il TridentBackendConfig CR è associato a un backend e contiene tale backend configRef impostare su TridentBackendConfig L'uid di CR.

  • Unbound: Rappresentato utilizzando "". Il TridentBackendConfig l'oggetto non è associato a un backend. Tutti creati di recente TridentBackendConfig I CRS sono in questa fase per impostazione predefinita. Una volta modificata la fase, non sarà più possibile tornare a Unbound.

  • Deleting: Il TridentBackendConfig CR deletionPolicy è stato impostato per l'eliminazione. Quando il TridentBackendConfig 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 il TridentBackendConfig 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 a TridentBackendConfig La CR è stata eliminata accidentalmente o deliberatamente e il TridentBackendConfig CR ha ancora un riferimento al backend cancellato. Il TridentBackendConfig La CR può comunque essere eliminata indipendentemente da deletionPolicy valore.

  • Unknown: Astra Trident non è in grado di determinare lo stato o l'esistenza del backend associato a TridentBackendConfig CR. Ad esempio, se il server API non risponde o se tridentbackends.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.

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