Récupérer des informations sur un cluster

Ce document explique comment récupérer des informations importantes sur la configuration et les identifiants de vos clusters existants à l'aide de la commande bmctl get. Ces informations peuvent être utiles pour résoudre les problèmes liés au cluster.

Obtenir les détails de configuration d'un cluster

Après avoir créé des clusters d'administrateur, hybrides, autonomes ou d'utilisateur à l'aide de la commande bmctl get config,

exécutez la commande suivante pour récupérer toutes les ressources personnalisées d'un cluster autogéré, tel qu'un cluster d'administrateur :

bmctl get config --cluster CLUSTER_NAME  --kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster cible.

  • ADMIN_KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Exécutez la commande suivante pour récupérer toutes les ressources personnalisées d'un cluster d'utilisateur :

Notez que bmctl accepte l'utilisation de --kubeconfig comme alias de l'option --admin-kubeconfig.

bmctl get config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster d'utilisateur cible

  • ADMIN_KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Dans les deux cas, les ressources personnalisées sont écrites dans le fichier YAML bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP.yaml. L'élément TIMESTAMP figurant dans le nom du fichier indique la date et l'heure de création du fichier.

Le fichier YAML généré par la commande bmctl get config ressemble à ce qui suit :

---
apiVersion: v1
kind: Namespace
metadata:
 name: cluster-admin1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
 name: admin1
 namespace: cluster-admin1
spec:
 clusterNetwork:
   services:
     cidrBlocks:
     - 10.96.0.0/20
   pods:
     cidrBlocks:
     - 192.168.0.0/16
 controlPlane:
   nodePoolSpec:
     nodes:
     - address: 172.18.0.13
 loadBalancer:
   mode: bundled
   ports:
     controlPlaneLBPort: 6443
   vips:
     controlPlaneVIP: 172.18.0.254
 storage:
   lvpShare:
     path: /mnt/localpv-share/
     storageclassname: standard
     numpvundersharedpath: 5
   lvpNodeMounts:
     path: /mnt/localpv-disk
     storageclassname: node-disk
 authentication:
   oidc:
     issuerURL: https://accounts.google.com
     kubectlRedirectURL: http://localhost:9879/callback
     clientID: 611080206796-9qq355g2q1coed5t78ckfmm1c6ini3et.apps.googleusercontent.com
     clientSecret: FTPbx3INYJcxBSQhMRlbk3tX
     username: email
     scopes: email
     extraParams: prompt=consent,access_type=offline
 clusterOperations:
   projectID: baremetal-test
   location: us-central1
 type: admin
 anthosBareMetalVersion: 0.0.0
 bypassPreflightCheck: false
 nodeConfig:
   containerRuntime: docker
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
 name: nodepool1
 namespace: cluster-admin1
spec:
 clusterName: admin1
 nodes:
 - address: 172.18.0.9

Obtenir les identifiants d'un cluster

Exécutez la commande bmctl get credentials pour récupérer les identifiants d'un cluster d'utilisateur donné.

Exécutez la commande suivante pour récupérer toutes les ressources personnalisées d'un cluster d'utilisateur :

Notez que bmctl accepte l'utilisation de --kubeconfig comme alias de l'option --admin-kubeconfig.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster d'utilisateur cible

  • ADMIN_KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Dans les deux cas, les identifiants du cluster sont écrits dans le fichier bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. L'élément TIMESTAMP figurant dans le nom du fichier indique la date et l'heure de création du fichier.

Comme ce fichier contient les identifiants d'authentification de votre cluster, vous devez le stocker dans un emplacement sécurisé avec accès limité.