Gérer les clusters Kubernetes

Google Distributed Cloud (GDC) air-gapped vous permet de gérer vos clusters Kubernetes après leur création à l'aide de GKE sur GDC. Ce service vous permet de vous adapter à l'évolution des exigences de vos charges de travail de conteneurs et de gérer vos nœuds de cluster existants à l'aide des workflows suivants :

Ce document s'adresse aux administrateurs informatiques du groupe d'administrateurs de plate-forme, qui gèrent les charges de travail de conteneurs hébergées dans des clusters répartis sur plusieurs projets, et aux développeurs du groupe d'opérateurs d'applications, qui sont chargés de créer des charges de travail d'application dans un seul projet. Pour en savoir plus, consultez Audiences pour la documentation GDC sous air gap.

Avant de commencer

Pour effectuer les tâches décrites dans ce document, vous devez demander les autorisations nécessaires et préparer votre environnement.

Demander des rôles IAM

Vous devez disposer de rôles spécifiques pour obtenir les autorisations nécessaires à la maintenance de votre cluster Kubernetes. Les rôles dont vous avez besoin dépendent du type de cluster que vous utilisez : cluster partagé à portée d'organisation ou cluster standard à portée de projet. Pour en savoir plus, consultez Configurations de clusters Kubernetes.

Rôles de cluster partagés

Pour afficher et gérer votre cluster Kubernetes partagé et ses ressources, demandez à l'administrateur IAM de votre organisation de vous accorder les rôles suivants en fonction de la tâche à effectuer :

  • Créateur de projet (project-creator) : permet de créer ou d'afficher des ressources de projet. Ce rôle est nécessaire pour associer un cluster partagé à un projet.

  • Éditeur de projet (project-editor) : supprimez, mettez à jour ou affichez les ressources du projet. Ce rôle est nécessaire pour dissocier un cluster partagé d'un projet.

  • Lecteur de cluster utilisateur (user-cluster-viewer) : permet d'afficher le cluster partagé et ses ressources. Ce rôle permet d'accéder aux API du plan de gestion pour le cluster partagé hébergé dans le serveur d'API de gestion.

Ces rôles ne sont pas liés à un espace de noms de projet.

Rôles de cluster standards

Pour afficher votre cluster Kubernetes standard et ses ressources, demandez à l'administrateur IAM de votre projet de vous attribuer le rôle Lecteur de cluster standard (standard-cluster-viewer). Ce rôle permet d'accéder aux API du plan de gestion pour le cluster standard hébergé dans le serveur d'API de gestion.

Ce rôle est lié à l'espace de noms de votre projet.

Préparer votre environnement

Pour exécuter des commandes sur un cluster Kubernetes à l'aide de l'API, assurez-vous de disposer des ressources suivantes :

  • Recherchez le nom du cluster Kubernetes ou demandez-le à un membre du groupe d'administrateurs de la plate-forme.

  • Utilisez le nom du cluster Kubernetes pour remplacer CLUSTER_NAME dans ces instructions.

  • Connectez-vous et générez le fichier kubeconfig pour le serveur d'API de gestion.

  • Utilisez le chemin kubeconfig du serveur d'API de gestion pour remplacer MANAGEMENT_API_SERVER dans ces instructions.

Déplacer des clusters dans la hiérarchie des projets

Les projets permettent de regrouper logiquement les instances de service. Vous pouvez ajouter et supprimer des clusters Kubernetes partagés dans la hiérarchie des projets GDC pour regrouper vos services de manière appropriée. Vous ne pouvez pas déplacer les clusters standards dans la hiérarchie des projets, car ils ne sont associés qu'à un seul projet.

Associer un projet à un cluster partagé

Lorsque vous créez un cluster partagé à partir de la console GDC, vous devez associer au moins un projet avant de pouvoir y déployer des charges de travail de conteneur. Si vous devez ajouter des projets à un cluster existant, procédez comme suit :

Console

  1. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.
  2. Dans la liste des clusters, cliquez sur le nom du cluster pour ouvrir la page Détails du cluster.
  3. Sélectionnez Associer un projet.
  4. Dans la liste des projets disponibles, cliquez sur le nom du projet à associer au cluster.
  5. Cliquez sur Enregistrer.

API

  • Créez une ressource personnalisée ProjectBinding pour votre cluster :

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectBinding
metadata:
  name: CLUSTER_NAME-PROJECT_NAME
  namespace: platform
  labels:
    resourcemanager.gdc.goog/projectbinding-for-user-project: "true"
spec:
  clusterRef:
   name: CLUSTER_NAME
  selector:
    nameSelector:
      matchNames:
      - PROJECT_NAME
EOF

    Remplacez les éléments suivants :

    • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API zonal.
    • CLUSTER_NAME : nom du cluster.
    • PROJECT_NAME : nom du projet auquel associer le cluster. Chaque ressource ProjectBinding ne peut être mappée qu'à un seul cluster. Si un projet nécessite d'accéder à plusieurs clusters, un ProjectBinding unique doit être créé pour chaque cluster.

Terraform

  1. Dans un fichier de configuration Terraform, insérez l'extrait de code suivant pour créer la ressource personnalisée ProjectBinding :

    provider "kubernetes" {
  config_path = "MANAGEMENT_API_SERVER"
}

resource "kubernetes_manifest" "PROJECT_BINDING_RESOURCE_NAME" {
  manifest = {
    "apiVersion" = "resourcemanager.gdc.goog/v1"
    "kind" = "ProjectBinding"
    "metadata" = {
      "name" = "CLUSTER_NAME-PROJECT_NAME"
      "namespace" = "platform"
      "labels" = {
        "resourcemanager.gdc.goog/projectbinding-for-user-project" = "true"
      }
    }
    "spec" = {
      "clusterRef" = {
        "name" = "CLUSTER_NAME"
      }
      "selector" = {
        "nameSelector" = {
          "matchNames" = [
            "PROJECT_NAME",
          ]
        }
      }
    }
  }
}

    Remplacez les éléments suivants :

    • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API zonal.
    • PROJECT_BINDING_RESOURCE_NAME : nom de la ressource Terraform de la liaison de projet, par exemple CLUSTER_NAME-PROJECT_NAME-binding. Ce nom est utilisé par Terraform pour identifier l'association de votre projet, mais pas par GDC.
    • CLUSTER_NAME : nom du cluster. Chaque ressource ProjectBinding ne peut être mappée qu'à un seul cluster. Si un projet nécessite d'accéder à plusieurs clusters, un ProjectBinding unique doit être créé pour chaque cluster.
    • PROJECT_NAME : nom du projet auquel associer le compte. Chaque ressource ProjectBinding ne peut être mappée qu'à un seul cluster. Si un projet nécessite d'accéder à plusieurs clusters, un ProjectBinding unique doit être créé pour chaque cluster.

  2. Appliquez la nouvelle liaison de projet :

    terraform apply

Dissocier un projet d'un cluster partagé

Détacher un projet d'un cluster partagé peut entraîner des modifications importantes, comme la suppression des charges de travail en cours d'exécution dans le cluster. Assurez-vous de bien comprendre les conséquences avant de dissocier un projet d'un cluster partagé.

Pour dissocier un projet d'un cluster partagé existant, procédez comme suit :

Console

  1. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.
  2. Cliquez sur le cluster dans la liste des clusters pour ouvrir la page Détails du cluster.
  3. Cliquez sur Détacher pour dissocier le projet du cluster.

API

  • Supprimez la ressource ProjectBinding qui associe le projet et le cluster :

    kubectl --kubeconfig MANAGEMENT_API_SERVER delete projectbinding \
    CLUSTER_NAME-PROJECT_NAME -n platform

    Remplacez les éléments suivants :

    • MANAGEMENT_API_SERVER : chemin d'accès kubeconfig du serveur d'API zonal.
    • CLUSTER_NAME : nom du cluster.
    • PROJECT_NAME : nom du projet à dissocier du cluster.

Terraform

  • Supprimez la ressource de liaison de projet :

    terraform destroy -target kubernetes_manifest.PROJECT_BINDING_RESOURCE_NAME

    Remplacez PROJECT_BINDING_RESOURCE_NAME par le nom de la ressource Terraform de la liaison de projet à supprimer, par exemple CLUSTER_NAME-PROJECT_NAME-binding. Ce nom est utilisé par Terraform pour identifier l'association de votre projet, mais pas par GDC.

Afficher tous les clusters d'un projet ou d'une organisation

Vous pouvez afficher tous les clusters Kubernetes disponibles dans un projet ou une organisation, y compris leur état, leur version Kubernetes et d'autres informations.

Étant donné que les clusters Kubernetes sont des ressources zonales, vous ne pouvez lister les clusters que par zone.

Console

  1. Dans le sélecteur de projet, sélectionnez votre projet ou votre organisation.

    Les clusters standards sont limités au niveau du projet, tandis que les clusters partagés sont limités au niveau de l'organisation. Sélectionnez le champ d'application approprié pour afficher le type de cluster Kubernetes correspondant.

  2. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.

    Tous les clusters partagés disponibles dans l'organisation, ainsi que leur état et d'autres informations, s'affichent :

    Page &quot;Détails du cluster&quot; pour les états et autres informations de chaque cluster partagé dans l'organisation.

gdcloud

  • Affichez la liste des clusters Kubernetes disponibles dans la zone :

    gdcloud clusters list

    Le résultat ressemble à ce qui suit :

    CLUSTERREF.NAME   READINESS.STATE   TYPE   CURRENTVERSION.USERCLUSTERVERSION     CURRENTVERSION.SUPPORT.STATUS
user-vm-1         Ready             user   1.15.0-gdch.394225-1.28.15-gke.1200   In Support
user-vm-2         Ready             user   1.15.0-gdch.394225-1.29.12-gke.800    In Support

API

  • Affichez la liste des clusters Kubernetes disponibles dans la zone :

    kubectl get clusters.cluster.gdc.goog -n KUBERNETES_CLUSTER_NAMESPACE \
    --kubeconfig MANAGEMENT_API_SERVER

    Remplacez les éléments suivants :

    • MANAGEMENT_API_SERVER : chemin d'accès au fichier kubeconfig du serveur d'API zonal.
    • KUBERNETES_CLUSTER_NAMESPACE : espace de noms du cluster. Pour les clusters partagés, utilisez l'espace de noms platform. Pour les clusters standards, utilisez l'espace de noms du projet du cluster.

    Le résultat ressemble à ce qui suit :

    NAME        STATE     K8S VERSION
user-vm-1   Running   1.25.10-gke.2100
user-test   Running   1.26.5-gke.2100

Lister les versions Kubernetes disponibles pour un cluster

Vous pouvez lister les versions de Kubernetes disponibles dans votre zone GDC pour vérifier les fonctionnalités Kubernetes auxquelles vous pouvez accéder dans le cluster.

  • Répertoriez les versions de Kubernetes disponibles dans votre zone :

    kubectl get userclustermetadata.upgrade.private.gdc.goog \
    -o=custom-columns=K8S-VERSION:.spec.kubernetesVersion \
    --kubeconfig MANAGEMENT_API_SERVER

    Remplacez MANAGEMENT_API_SERVER par le fichier kubeconfig du serveur d'API zonal de votre cluster.

    La sortie ressemble à ceci :

    K8S-VERSION
1.25.10-gke.2100
1.26.5-gke.2100
1.27.4-gke.500

Afficher les propriétés modifiables

Pour chaque cluster Kubernetes, un ensemble de propriétés peuvent être modifiées après sa création. Vous ne pouvez modifier que les propriétés modifiables qui se trouvent dans le spec de la ressource personnalisée Cluster. Toutes les propriétés de spec ne peuvent pas être mises à jour une fois le cluster provisionné. Pour afficher ces propriétés modifiables, procédez comme suit :

Console

  1. Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.

  2. Dans la liste des clusters Kubernetes, cliquez sur le nom d'un cluster pour afficher ses propriétés.

  3. Les propriétés modifiables sont associées à une icône Modifier .

API

  • Consultez la liste des propriétés de la spécification Cluster et les valeurs valides correspondant à chaque propriété :

    kubectl explain clusters.cluster.gdc.goog.spec \
    --kubeconfig MANAGEMENT_API_SERVER

    Remplacez MANAGEMENT_API_SERVER par le chemin d'accès du fichier kubeconfig pour le serveur d'API zonal.

    Le résultat ressemble à ce qui suit :

    KIND:     Cluster
VERSION:  cluster.gdc.goog/v1

RESOURCE: spec <Object>

DESCRIPTION:
    <empty>

FIELDS:
  clusterNetwork    <Object>
    The cluster network configuration. If unset, the default configurations
    with pod and service CIDR sizes are used. Optional. Mutable.

  initialVersion    <Object>
    The GDC air-gapped version information of the user cluster during cluster creation.
    Optional. Default to use the latest applicable version. Immutable.

  loadBalancer  <Object>
    The load balancer configuration. If unset, the default configuration with
    the ingress service IP address size is used. Optional. Mutable.

  nodePools <[]Object>
    The list of node pools for the cluster worker nodes. Optional. Mutable.

  releaseChannel    <Object>
    The release channel a cluster is subscribed to. When a cluster is
    subscribed to a release channel, GDC maintains the cluster versions for
    users. Optional. Mutable.

    Mettez à jour ces paramètres à l'aide de la console GDC ou de CLI kubectl. Par exemple, vous pouvez redimensionner un pool de nœuds.

Étapes suivantes