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. Le TridentBackendConfig La définition de ressource personnalisée (CRD) vous permet de créer et de gérer des systèmes back-end Trident directement via l'interface Kubernetes. Vous pouvez le faire en utilisant kubectl Ou l'outil CLI équivalent pour votre distribution Kubernetes.

TridentBackendConfig

TridentBackendConfig (tbc, tbconfig, tbackendconfig) Est un CRD au rythme de noms qui vous permet de gérer les systèmes back-end Astra Trident à l'aide de kubectl. Avec Kubernetes et les administrateurs de stockage, il est désormais possible de créer et de gérer des systèmes back-end directement via la CLI Kubernetes sans avoir besoin d'un utilitaire de ligne de commande dédié (tridentctl).

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

  • Un système back-end est créé automatiquement par Astra Trident en fonction de la configuration que vous fournissez. Il est représenté en interne en tant que TridentBackend (tbe, tridentbackend) CR.

  • Le TridentBackendConfig est lié de manière unique à un TridentBackend Créé par Astra 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 ASTRA Trident crée automatiquement des CRS. Vous ne devez pas les modifier. Si vous voulez effectuer des mises à jour vers les systèmes back-end, modifiez le TridentBackendConfig objet.

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 pour le pilote de stockage souhaité, reportez-vous à la section "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 Systèmes back-end créés avec tridentctl n'avez pas de lien associé TridentBackendConfig objet. Vous avez la possibilité de choisir de gérer de tels systèmes back-end avec kubectl en créant un TridentBackendConfig CR. Vous devez veiller à spécifier des paramètres de configuration identiques (par exemple spec.backendName, spec.storagePrefix, spec.storageDriverName, etc.). Astra Trident lie automatiquement le nouveau produit TridentBackendConfig avec le 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 est qu'Astra Trident doit 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 AWS

ApiKey

Clé API de compte CVS

Cloud Volumes Service pour AWS

SecretKey

Clé secrète compte CVS

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 L’uid 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, supprimez le TridentBackendConfig Il en résultera la suppression du système back-end et du système Astra Trident TridentBackendConfig CR.

    • 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: 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 tridentbackends.trident.netapp.io CRD manquant. Cela peut nécessiter l'intervention de l'utilisateur.

À 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 à TridentBackendConfig CR. Le lastOperationStatus champ représente l'état de la dernière opération du TridentBackendConfig CR, qui peut être déclenché par l'utilisateur (par exemple, l'utilisateur a modifié quelque chose dans spec) Ou déclenché par Astra Trident (par exemple lors du redémarrage d'Astra Trident). Il peut être réussi ou échoué. phase représente l'état de la relation entre TridentBackendConfig CR et le backend. Dans l'exemple ci-dessus, phase A la valeur limitée, ce qui signifie que le TridentBackendConfig CR est associé 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".