Skip to main content
Une version plus récente de ce produit est disponible.
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 système back-end définit la relation entre Astra Trident et un système de stockage. Il explique à Astra Trident comment communiquer avec ce système de stockage et comment Astra Trident doit provisionner des volumes à partir de celui-ci. Après l'installation d'Astra Trident, l'étape suivante consiste à créer un système 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 frontend et namespaces qui vous permet de gérer les systèmes back-end Astra Trident à 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, les événements suivants se produisent :

  • Un système back-end est créé automatiquement par Astra 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 système TridentBackendConfig est lié de manière unique à un TridentBackend qui a été créé par Astra Trident.

Chacun TridentBackendConfig gère un mappage un-à-un avec un TridentBackend. le premier est l'interface fournie à l'utilisateur pour concevoir et configurer des systèmes back-end ; le second est la façon dont Trident représente l'objet back-end réel.

Avertissement TridentBackend Les services CRS sont créés automatiquement par Astra 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 de TridentBackendConfig la 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 configuration de la plate-forme/du service de stockage souhaité dans le "programme d'installation trident" répertoire.

`spec`Prend en charge les paramètres de configuration spécifiques au back-end. Dans cet exemple, le back-end utilise le `ontap-san` pilote de stockage et les paramètres de configuration qui sont tabulés ici. Pour obtenir la liste des options de configuration du pilote de stockage souhaité, reportez-vous au link:backends.html["informations de configuration backend pour votre pilote de stockage"^].

La spec section inclut également credentials les champs et deletionPolicy, qui sont récemment introduits dans la TridentBackendConfig CR :

  • credentials: Ce paramètre est un champ obligatoire qui 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 le TridentBackendConfig est supprimé. Il peut prendre l'une des deux valeurs possibles :

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

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

Remarque Le nom d'un backend est défini à l'aide de spec.backendName. S'il n'est pas spécifié, le nom du backend est défini sur le nom de TridentBackendConfig l'objet (metadata.name). Il est recommandé de définir explicitement les noms de back-end à 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.). ASTRA Trident lie automatiquement le nouveau système créé TridentBackendConfig avec le back-end pré-existant.

Présentation des étapes

Pour créer un nouveau back-end à l'aide de kubectl, procédez comme suit :

  1. Créer un "Le secret de Kubernetes". le secret contient les informations d'identification dont Astra 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 backend, vous pouvez observer son état en utilisant et en kubectl get tbc <tbc-name> -n <trident-namespace> rassemblant 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éé à cette étape sera référencé dans le spec.credentials champ de l' `TridentBackendConfig`objet créé à l'étape suivante.

Étape 2 : créer la TridentBackendConfig CR

Vous êtes maintenant prêt à créer votre TridentBackendConfig CR. Dans cet exemple, un back-end qui utilise le ontap-san pilote est créé à l'aide de l' `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éé la TridentBackendConfig demande de modification, vous pouvez vérifier son é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é à la TridentBackendConfig demande de modification.

La phase peut prendre l'une des valeurs suivantes :

  • Bound: La TridentBackendConfig CR est associée à un back-end, et ce back-end contient configRef défini sur l'uid de la TridentBackendConfig CR.

  • Unbound: Représenté à l'aide de "". L' TridentBackendConfig`objet n'est pas lié à un backend. Par défaut, toutes les demandes de modification nouvellement créées `TridentBackendConfig sont dans cette phase. Une fois la phase modifiée, elle ne peut plus revenir à Unbound.

  • Deleting: La TridentBackendConfig demande de modification deletionPolicy a été définie sur supprimer. Lorsque la TridentBackendConfig CR 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 d'Astra Trident, TridentBackendConfig le back-end ainsi que la TridentBackendConfig demande de remboursement.

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

  • Lost: Le back-end associé à la TridentBackendConfig CR a été accidentellement ou délibérément supprimé et la TridentBackendConfig CR a toujours une référence au back-end supprimé. La TridentBackendConfig demande de modification peut toujours être supprimée quelle que soit la deletionPolicy valeur.

  • Unknown: Astra Trident n'est pas en mesure de déterminer l'état ou l'existence du back-end associé au 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 gérées, telles que "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 indique le statut de la dernière opération de TridentBackendConfig la demande de modification, qui peut être déclenchée par l'utilisateur (par exemple, lors du redémarrage d'Astra Trident par l'utilisateur spec) ou par Astra 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 kubectl -n trident describe tbc <tbc-cr-name> la commande pour obtenir des détails sur les journaux d'événements.

Avertissement Vous ne pouvez pas mettre à jour ou supprimer un back-end contenant un objet associé à TridentBackendConfig l'aide de tridentctl. Pour comprendre les étapes impliquées dans le passage entre tridentctl et TridentBackendConfig, "voir ici".