Gérer les clusters Kubernetes

Partagé Standard

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 grâce aux workflows suivants :

Associer et dissocier des clusters partagés à des projets : associez et dissociez votre cluster partagé à plusieurs projets après la création du cluster pour modifier le champ d'application des charges de travail de votre cluster partagé.
Afficher les clusters de votre organisation : listez les clusters de votre organisation pour suivre ce qui est disponible pour vos charges de travail de conteneurs.
Lister les versions de Kubernetes : affichez la version de Kubernetes de votre cluster pour connaître les capacités du cluster correspondant aux dernières versions de Kubernetes.
Afficher les propriétés de cluster modifiables : affichez les propriétés que vous pouvez modifier dans la définition de la ressource personnalisée Cluster.

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'applications 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 disposer des ressources et des rôles suivants :

Pour afficher et gérer les pools de nœuds dans un cluster Kubernetes partagé, demandez à votre administrateur IAM de l'organisation de vous accorder les rôles suivants :
- Administrateur de cluster d'utilisateur (user-cluster-admin)
- Lecteur de nœuds de cluster d'utilisateur (user-cluster-node-viewer)
Ces rôles ne sont pas liés à un espace de noms de projet.
Pour afficher et gérer les pools de nœuds dans un cluster Kubernetes standard, demandez à votre administrateur IAM de l'organisation de vous accorder le rôle Administrateur de cluster standard (standard-cluster-admin). Ce rôle est lié à l'espace de noms de votre projet.
Pour exécuter des commandes sur un cluster Kubernetes, assurez-vous de disposer des ressources suivantes :
- Recherchez le nom du cluster Kubernetes ou demandez-le à un membre du groupe des administrateurs de la plate-forme.
- Connectez-vous et générez le fichier kubeconfig pour le cluster Kubernetes si vous n'en avez pas.
- Utilisez le chemin kubeconfig du cluster Kubernetes pour remplacer KUBERNETES_CLUSTER_KUBECONFIG dans ces instructions.
Pour exécuter des commandes sur le serveur d'API zonal, générez le fichier kubeconfig du serveur d'API zonal qui héberge votre cluster. Pour en savoir plus, consultez Se connecter. Définissez la variable d'environnement MANAGEMENT_API_SERVER sur le chemin d'accès à kubeconfig.

Déplacer des clusters dans la hiérarchie de projet

Les projets permettent de regrouper logiquement les instances de service. Vous pouvez ajouter et supprimer des clusters Kubernetes partagés de la hiérarchie de 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 limité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

Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.
Dans la liste des clusters, cliquez sur le nom du cluster pour ouvrir la page Détails du cluster.
Sélectionnez Associer un projet.
Dans la liste des projets disponibles, cliquez sur le nom du projet à associer au cluster.
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 associé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

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. Il n'est pas utilisé par GDC.
- CLUSTER_NAME : nom du cluster. Chaque ressource ProjectBinding ne peut être associé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 service. Chaque ressource ProjectBinding ne peut être associée qu'à un seul cluster. Si un projet nécessite d'accéder à plusieurs clusters, un ProjectBinding unique doit être créé pour chaque cluster.
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 exécutées 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

Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.
Cliquez sur le cluster dans la liste des clusters pour ouvrir la page Détails du cluster.
Cliquez sur Détacher pour détacher 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. Il n'est pas utilisé par GDC.

Afficher tous les clusters d'une organisation

Vous pouvez afficher tous les clusters Kubernetes disponibles dans 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

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 :

gdcloud

Répertoriez les clusters partagés disponibles dans une organisation pour une zone donnée :

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

Listez les clusters Kubernetes disponibles dans une organisation pour une zone donnée :
```
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 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 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

Dans le menu de navigation, sélectionnez Kubernetes Engine > Clusters.
Dans la liste des clusters Kubernetes, cliquez sur le nom d'un cluster pour afficher ses propriétés.
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.

Gérer les clusters Kubernetes Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Avant de commencer

Déplacer des clusters dans la hiérarchie de projet

Associer un projet à un cluster partagé

Console

API

Terraform

Dissocier un projet d'un cluster partagé

Console

API

Terraform

Afficher tous les clusters d'une organisation

Console

gdcloud

API

Lister les versions Kubernetes disponibles pour un cluster

Afficher les propriétés modifiables

Console

API

Étapes suivantes

Gérer les clusters Kubernetes