Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Création de systèmes back-end avec kubectl

Contributeurs
PDF

Un back-end définit la relation entre Trident et un système de stockage. Il explique à Trident comment communiquer avec ce système de stockage et comment Trident doit provisionner les volumes à partir de celui-ci. Une fois Trident installé, l'étape suivante consiste à créer un back-end. La TridentBackendConfig définition personnalisée des ressources (CRD) vous permet de créer et de gérer des systèmes back-end Trident directement via l'interface Kubernetes. Pour cela, vous pouvez utiliser kubectl ou l'outil CLI équivalent pour votre distribution Kubernetes.

TridentBackendConfig

TridentBackendConfig (tbc, tbconfig, tbackendconfig) Est un système CRD front-end, qui vous permet de gérer des systèmes Trident back-end à l'aide de kubectl. Kubernetes et les administrateurs du stockage peuvent désormais créer et gérer des systèmes back-end directement via l'interface de ligne de commande Kubernetes sans avoir besoin d'un utilitaire de ligne de commande dédié (tridentctl).

Lors de la création d'un TridentBackendConfig objet :

  • Un back-end est créé automatiquement par Trident en fonction de la configuration que vous fournissez. Ceci est représenté en interne sous la forme d'une TridentBackend CR(tbe , tridentbackend).

  • Le TridentBackendConfig est lié de manière unique à un TridentBackend qui a été créé par Trident.

Chacun TridentBackendConfig gère un mappage un-à-un avec un TridentBackend. La première est l'interface fournie à l'utilisateur pour concevoir et configurer les systèmes back-end, tandis que Trident représente l'objet back-end réel.

Avertissement TridentBackend Les CRS sont créés automatiquement par Trident. Vous ne devez pas les modifier. Si vous souhaitez effectuer des mises à jour vers des systèmes back-end, modifiez l'objet pour procéder TridentBackendConfig à cette opération.

Reportez-vous à l'exemple suivant pour connaître le format du 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

Vous pouvez également consulter les exemples de la "programme d'installation trident" répertoire des exemples de configuration pour la plate-forme/le service de stockage souhaité.

Le spec il prend des paramètres de configuration spécifiques au back-end. Dans cet exemple, le back-end utilise le ontap-san pilote de stockage et utilise les paramètres de configuration qui sont présentés ici. Pour obtenir la liste des options de configuration du pilote de stockage souhaité, reportez-vous au "informations de configuration backend pour votre pilote de stockage".

Le spec la section inclut également credentials et deletionPolicy les champs qui viennent d'être introduits dans le TridentBackendConfig CR :

  • credentials: Ce paramètre est un champ obligatoire et contient les informations d'identification utilisées pour s'authentifier auprès du système/service de stockage. Cette configuration est définie sur un code secret Kubernetes créé par l'utilisateur. Les informations d'identification ne peuvent pas être transmises en texte brut et entraînent une erreur.

  • deletionPolicy: Ce champ définit ce qui doit se produire lorsque TridentBackendConfig est supprimé. Il peut prendre l'une des deux valeurs possibles :

    • delete: Cela entraîne la suppression des deux TridentBackendConfig CR et le back-end associé. Il s'agit de la valeur par défaut.

    • retain: Lorsqu'un TridentBackendConfig La demande de modification est supprimée, la définition de l'arrière-plan est toujours présente et peut être gérée avec tridentctl. Définition de la stratégie de suppression sur retain permet aux utilisateurs de revenir à une version antérieure (avant la version 21.04) et de conserver les systèmes back-end créés. La valeur de ce champ peut être mise à jour après un TridentBackendConfig est créé.

Remarque Le nom d'un backend est défini à l'aide de spec.backendName. S'il n'est pas spécifié, le nom du back-end est défini sur le nom du TridentBackendConfig objet (metadata.name). Il est recommandé de définir explicitement les noms backend à l'aide de spec.backendName.
Astuce Les systèmes back-end créés avec tridentctl n'ont pas d'objet associé TridentBackendConfig. Vous pouvez choisir de gérer ces systèmes back-end avec kubectl en créant une TridentBackendConfig demande de modification. Veillez à spécifier des paramètres de configuration identiques (tels que spec.backendName, , , spec.storagePrefix spec.storageDriverName etc.). Trident lie automatiquement le nouveau système créé TridentBackendConfig avec le système back-end existant.

Présentation des étapes

Pour créer un nouveau back-end à l'aide de kubectl, vous devez effectuer les opérations suivantes :

  1. Créer un "Le secret de Kubernetes". le secret contient les informations d'identification dont Trident a besoin pour communiquer avec le cluster/service de stockage.

  2. Créer un TridentBackendConfig objet. Elle contient des informations spécifiques sur le cluster/service de stockage et fait référence au secret créé à l'étape précédente.

Après avoir créé un back-end, vous pouvez observer son état en utilisant kubectl get tbc <tbc-name> -n <trident-namespace> et recueillez des détails supplémentaires.

Étape 1 : créez un code secret Kubernetes

Créez un secret qui contient les informations d'identification d'accès pour le back-end. Ce point est unique à chaque service/plateforme de stockage. Voici un exemple :

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(>

Ce tableau récapitule les champs à inclure dans le Secret pour chaque plate-forme de stockage :

Description des champs secrets de la plate-forme de stockage Secret Description des champs

Azure NetApp Files

ID client

ID client d'un enregistrement d'application

Cloud Volumes Service pour GCP

id_clé_privée

ID de la clé privée. Partie de la clé API pour le compte de service GCP avec le rôle d'administrateur CVS

Cloud Volumes Service pour GCP

clé_privée

Clé privée. Partie de la clé API pour le compte de service GCP avec le rôle d'administrateur CVS

Element (NetApp HCI/SolidFire)

Point final

MVIP pour le cluster SolidFire avec les identifiants de locataire

ONTAP

nom d'utilisateur

Nom d'utilisateur pour la connexion au cluster/SVM. Utilisé pour l'authentification basée sur les identifiants

ONTAP

mot de passe

Mot de passe pour la connexion au cluster/SVM. Utilisé pour l'authentification basée sur les identifiants

ONTAP

ClientPrivateKey

Valeur encodée en Base64 de la clé privée du client. Utilisé pour l'authentification basée sur des certificats

ONTAP

ChapUsername

Nom d'utilisateur entrant. Requis si useCHAP=vrai. Pour ontap-san et ontap-san-economy

ONTAP

Chapeau InitiatorSecret

Secret de l'initiateur CHAP. Requis si useCHAP=vrai. Pour ontap-san et ontap-san-economy

ONTAP

ChapTargetUsername

Nom d'utilisateur cible. Requis si useCHAP=vrai. Pour ontap-san et ontap-san-economy

ONTAP

ChapTargetInitiatorSecret

Secret de l'initiateur cible CHAP. Requis si useCHAP=vrai. Pour ontap-san et ontap-san-economy

Le secret créé dans cette étape sera référencé dans le spec.credentials champ du TridentBackendConfig objet créé à l'étape suivante.

Étape 2 : créez le TridentBackendConfig CR

Vous êtes maintenant prêt à créer votre TridentBackendConfig CR. Dans cet exemple, un back-end qui utilise le ontap-san le pilote est créé à l'aide du TridentBackendConfig objet illustré ci-dessous :

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

Étape 3 : vérifier l'état du TridentBackendConfig CR

Maintenant que vous avez créé le TridentBackendConfig CR, vous pouvez vérifier l'état. Voir l'exemple suivant :

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 back-end a été créé avec succès et lié au TridentBackendConfig CR.

La phase peut prendre l'une des valeurs suivantes :

  • Bound: Le TridentBackendConfig La demande de modification est associée à un back-end, et ce backend contient configRef réglez sur TridentBackendConfig ID de CR.

  • Unbound: Représenté en utilisant "". Le TridentBackendConfig l'objet n'est pas lié à un back-end. Tout nouveau TridentBackendConfig Les CRS sont dans cette phase par défaut. Une fois la phase modifiée, elle ne peut plus revenir à Unbound.

  • Deleting: Le TridentBackendConfig CR deletionPolicy a été configuré pour supprimer. Lorsque le TridentBackendConfig La demande de modification est supprimée, elle passe à l'état Suppression.

    • Si aucune demande de volume persistant n'existe sur le back-end, la suppression du entraîne la suppression de Trident, TridentBackendConfig ainsi que de la TridentBackendConfig demande de modification.

    • Si un ou plusieurs ESV sont présents sur le back-end, il passe à l'état de suppression. Le TridentBackendConfig La CR entre ensuite la phase de suppression. Le back-end et TridentBackendConfig Sont supprimés uniquement après la suppression de tous les ESV.

  • Lost: Le back-end associé à l' TridentBackendConfig Le CR a été accidentellement ou délibérément supprimé et le TridentBackendConfig La CR a toujours une référence au back-end supprimé. Le TridentBackendConfig La CR peut toujours être supprimée, quel que soit le deletionPolicy valeur.

  • Unknown: Trident n'est pas en mesure de déterminer l'état ou l'existence du back-end associé à la TridentBackendConfig CR. Par exemple, si le serveur d'API ne répond pas ou si le tridentbackends.trident.netapp.io CRD est manquant. Cela peut nécessiter une intervention.

À ce stade, un système back-end est créé avec succès ! Plusieurs opérations peuvent également être traitées, par exemple "mises à jour du système back-end et suppressions".

(Facultatif) étape 4 : pour plus de détails

Vous pouvez exécuter la commande suivante pour obtenir plus d'informations sur votre système back-end :

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

En outre, vous pouvez également obtenir un vidage YAML/JSON de 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 Contient le backendName et le backendUUID du back-end créé en réponse à la TridentBackendConfig demande de modification. Le lastOperationStatus champ représente l'état de la dernière opération de la TridentBackendConfig CR, qui peut être déclenchée par l'utilisateur (par exemple, l'utilisateur a modifié quelque chose dans spec) ou déclenchée par Trident (par exemple, lors d'un redémarrage de Trident). Il peut s'agir d'un succès ou d'un échec. phase Représente l'état de la relation entre la TridentBackendConfig CR et le back-end. Dans l'exemple ci-dessus, phase a la valeur liée, ce qui signifie que la TridentBackendConfig CR est associée au back-end.

Vous pouvez exécuter le kubectl -n trident describe tbc <tbc-cr-name> commande pour obtenir des détails sur les journaux d'événements.

Avertissement Vous ne pouvez pas mettre à jour ou supprimer un backend qui contient un associé TridentBackendConfig objet utilisant tridentctl. Pour comprendre les étapes de passage d'un à l'autre tridentctl et TridentBackendConfig, "voir ici".