Skip to main content
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
PDF

Un backend definisce la relazione tra Trident e un sistema di storage. Spiega a Trident come comunicare con quel sistema storage e come Trident dovrebbe eseguire il provisioning dei volumi da esso. Dopo l'installazione di Trident, il passaggio successivo consiste nella creazione di un backend. La TridentBackendConfig definizione risorsa personalizzata (CRD) ti consente di creare e gestire i backend Trident direttamente attraverso l'interfaccia di Kubernetes. Puoi farlo utilizzando kubectl o l'equivalente strumento CLI per la tua distribuzione Kubernetes.

TridentBackendConfig

TridentBackendConfig (tbc, , tbconfig tbackendconfig ) È un CRD in primo piano, con nome, che consente di gestire backend Trident utilizzando kubectl. Gli amministratori di Kubernetes e dello storage possono ora creare e gestire i backend direttamente attraverso l'interfaccia a riga di comando di Kubernetes senza richiedere un'utility a riga di comando dedicata (tridentctl).

Alla creazione di un TridentBackendConfig oggetto, si verifica quanto segue:

  • Trident crea automaticamente un backend in base alla configurazione fornita. Questo è rappresentato internamente come a TridentBackend (tbe, tridentbackend) CR.

  • Il TridentBackendConfig è associato in modo univoco a un TridentBackend creato da 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 Trident. Non è possibile modificarle. Se si desidera aggiornare i backend, modificare l' `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 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 I backend creati con tridentctl non hanno un oggetto associato TridentBackendConfig. È possibile scegliere di gestire tali backend con kubectl creando una TridentBackendConfig CR. Occorre prestare attenzione a specificare parametri di configurazione identici (come spec.backendName, , spec.storagePrefix, spec.storageDriverName e così via). Trident associa automaticamente il nuovo creato TridentBackendConfig al backend preesistente.

Panoramica dei passaggi

Per creare un nuovo backend utilizzando kubectl, eseguire le seguenti operazioni:

  1. Crea un "Kubernetes Secret". il segreto contiene le credenziali che Trident deve avere per comunicare con il cluster/servizio di archiviazione.

  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: 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-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 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 sul backend non sono presenti PVC (Persistent Volume Request), l'eliminazione di TridentBackendConfig comporterà l'eliminazione del back-end e della CR da parte di Trident TridentBackendConfig.

    • 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: Trident non è in grado di determinare lo stato o l'esistenza del backend associato al TridentBackendConfig CR. Ad esempio, se il server API non risponde o se manca il tridentbackends.trident.netapp.io CRD. 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 il backendName e il backendUUID del backend creato in risposta al TridentBackendConfig CR. Il lastOperationStatus campo rappresenta lo stato dell'ultima operazione del TridentBackendConfig CR, che può essere attivata dall'utente (ad esempio, un elemento modificato dall'utente in) o attivata da Trident (ad esempio, spec durante il riavvio di Trident). Può essere riuscito o non riuscito. phase Rappresenta lo stato della relazione tra TridentBackendConfig CR e backend. Nell'esempio precedente, phase ha il valore associato, il che significa che la TridentBackendConfig CR è associata 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".