Créer un cluster privé

Cette page explique comment créer un cluster privé Google Kubernetes Engine (GKE), qui est un type de cluster de VPC natif. Dans un cluster privé, les nœuds ne disposent que d'adresses IP internes, ce qui signifie que les nœuds et les pods sont isolés par défaut d'Internet.

Les adresses IP internes des nœuds proviennent de la plage d'adresses IP principale du sous-réseau que vous choisissez pour le cluster. Les adresses IP des pods et les adresses IP de service proviennent de deux plages d'adresses IP secondaires du sous-réseau du même sous-réseau. Pour en savoir plus, consultez la section Plages d'adresses IP pour les clusters de VPC natif.

Les versions 1.14.2 et ultérieures de GKE sont compatibles avec toutes les plages d'adresses IP internes, y compris les plages privées (RFC 1918 et autres plages privées) et les plages d'adresses IP publiques utilisées en mode privé. Consultez la documentation VPC pour obtenir la liste des plages d'adresses IP internes valides.

Pour en savoir plus sur le fonctionnement des clusters privés, consultez la section Clusters privés.

Avant de commencer

Familiarisez-vous avec les exigences, restrictions et limitations avant de passer à l'étape suivante.

Avant de commencer, effectuez les tâches suivantes :

  • Assurez-vous d'avoir activé l'API Google Kubernetes Engine.
  • Activer l'API Google Kubernetes Engine
  • Assurez-vous d'avoir installé le SDK Cloud.
  • Configurez les paramètres de l'outil de ligne de commande gcloud par défaut pour votre projet en utilisant l'une des méthodes suivantes:
    • Utilisez gcloud init si vous souhaitez suivre les étapes de définition des paramètres par défaut du projet.
    • Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

    gcloud init

    1. Exécutez gcloud init et suivez les instructions :

      gcloud init

      Si vous utilisez SSH sur un serveur distant, utilisez l'option --console-only pour empêcher la commande d'ouvrir un navigateur :

      gcloud init --console-only
    2. Suivez les instructions pour autoriser l'outil gcloud à utiliser votre compte Google Cloud.
    3. Créez ou sélectionnez une configuration.
    4. Choisissez un projet Google Cloud.
    5. Choisissez une zone Compute Engine par défaut.
    6. Choisissez une région Compute Engine par défaut.

    gcloud config

    1. Définissez votre ID de projet par défaut :
      gcloud config set project PROJECT_ID
    2. Définissez votre région Compute Engine par défaut (par exemple, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Définissez votre zone Compute Engine par défaut (par exemple, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Mettez à jour gcloud vers la dernière version :
      gcloud components update

    En définissant des emplacements par défaut, vous pouvez éviter les erreurs dans l'outil gcloud, telles que les suivantes: One of [--zone, --region] must be supplied: Please specify location.

Créer un cluster privé sans accès client au point de terminaison public

Dans cette section, vous allez créer un cluster privé nommé private-cluster-0 comportant des nœuds privés et n'ayant pas accès au point de terminaison public.

gcloud

  • Pour les clusters Standard, exécutez la commande suivante :

    gcloud container clusters create private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --enable-private-endpoint \
        --master-ipv4-cidr 172.16.0.32/28
    
  • Pour les clusters Autopilot, exécutez la commande suivante :

    gcloud container clusters create-auto private-cluster-0 \
        --create-subnetwork name=my-subnet-0 \
        --enable-master-authorized-networks \
        --enable-private-nodes \
        --enable-private-endpoint
    

où :

  • --create-subnetwork name=my-subnet-0 force GKE à créer automatiquement un sous-réseau nommé my-subnet-0.
  • --enable-master-authorized-networks spécifie que l'accès au point de terminaison public est limité aux plages d'adresses IP que vous autorisez.
  • --enable-ip-alias rend le cluster VPC natif (non requis pour Autopilot).
  • --enable-private-nodes indique que les nœuds du cluster ne possèdent pas d'adresses IP externes.
  • --enable-private-endpoint indique que le cluster est géré à l'aide de l'adresse IP privée du point de terminaison de l'API du plan de contrôle.
  • --master-ipv4-cidr 172.16.0.32/28 spécifie une plage d'adresses IP internes pour le plan de contrôle (facultatif pour Autopilot). Ce paramètre est définitif pour le cluster. L'utilisation d'adresses IP internes 1918 non RFC est acceptée.

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Standard ou Autopilot, cliquez sur Configurer.

  4. Dans le champ Nom, saisissez my-subnet-0.

  5. Pour les clusters standards, dans le volet de navigation, sous Cluster, cliquez sur Mise en réseau.

  6. Sélectionnez la case d'option Cluster privé.

  7. Décochez la case Accéder au plan de contrôle à l'aide de son adresse IP externe.

  8. (Facultatif pour Autopilot) : Définissez la plage d'adresses IP du plan de contrôle sur 172.16.0.32/28.

  9. Laissez les paramètres Mise en réseau et Sous-réseau de nœud définis sur default. Cela force GKE à générer un sous-réseau pour votre cluster.

  10. Cliquez sur Create (Créer).

API

Pour créer un cluster sans plan de contrôle accessible publiquement, spécifiez le champ enablePrivateEndpoint: true dans la ressource privateClusterConfig.

À ce stade, les adresses IP ci-dessous sont les seules à avoir accès au plan de contrôle :

  • Plage principale de my-subnet-0
  • Plage secondaire utilisée pour les pods

Par exemple, supposons que vous ayez créé une VM dans la plage principale de my-subnet-0. Vous pouvez ensuite, sur cette VM, configurer kubectl pour utiliser l'adresse IP interne du plan de contrôle.

Si vous souhaitez accéder au plan de contrôle depuis l'extérieur de my-subnet-0, vous devez autoriser au moins une plage d'adresses pour pouvoir accéder au point de terminaison privé.

Supposons que votre VM se trouve dans le réseau par défaut, dans la même région que votre cluster, mais pas dans my-subnet-0.

Exemple :

  • my-subnet-0 : 10.0.0.0/22
  • Plage secondaire du pod : 10.52.0.0/14
  • Adresse de la VM : 10.128.0.3

Vous pouvez autoriser la VM à accéder au plan de contrôle à l'aide de la commande suivante :

gcloud container clusters update private-cluster-0 \
    --enable-master-authorized-networks \
    --master-authorized-networks 10.128.0.3/32

Créer un cluster privé avec accès limité au point de terminaison public

Lorsque vous créez un cluster privé à l'aide de cette configuration, vous pouvez choisir d'utiliser un sous-réseau généré automatiquement ou un sous-réseau personnalisé.

Utiliser un sous-réseau généré automatiquement

Dans cette section, vous allez créer un cluster nommé private-cluster-1 de sorte que GKE génère automatiquement un sous-réseau pour vos nœuds de cluster. L'accès privé à Google est activé sur le sous-réseau. Dans le sous-réseau, GKE crée automatiquement deux plages secondaires : une pour les pods et une pour les services.

Vous pouvez utiliser l'outil de ligne de commande gcloud ou l'API GKE.

gcloud

  • Pour les clusters Standard, exécutez la commande suivante :

    gcloud container clusters create private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.0/28
    
  • Pour les clusters Autopilot, exécutez la commande suivante :

    gcloud container clusters create-auto private-cluster-1 \
        --create-subnetwork name=my-subnet-1 \
        --enable-master-authorized-networks \
        --enable-private-nodes
    

où :

  • --create-subnetwork name=my-subnet-1 force GKE à créer automatiquement un sous-réseau nommé my-subnet-1.
  • --enable-master-authorized-networks spécifie que l'accès au point de terminaison public est limité aux plages d'adresses IP que vous autorisez.
  • --enable-ip-alias rend le cluster VPC natif (non requis pour Autopilot).
  • --enable-private-nodes indique que les nœuds du cluster ne possèdent pas d'adresses IP externes.
  • --master-ipv4-cidr 172.16.0.0/28 spécifie une plage d'adresses IP internes pour le plan de contrôle (facultatif pour Autopilot). Ce paramètre est définitif pour le cluster. L'utilisation d'adresses IP internes 1918 non RFC est acceptée.

API

Spécifiez le champ privateClusterConfig dans la ressource API Cluster :

{
  "name": "private-cluster-1",
  ...
  "ipAllocationPolicy": {
    "createSubnetwork": true,
  },
  ...
    "privateClusterConfig" {
      "enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
      "enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
      "masterIpv4CidrBlock": string # CIDR block for the cluster control plane
      "privateEndpoint": string # Output only
      "publicEndpoint": string # Output only
  }
}

À ce stade, les adresses IP ci-dessous sont les seules à avoir accès au plan de contrôle du cluster :

  • Plage principale de my-subnet-1
  • Plage secondaire utilisée pour les pods

Supposons que vous ayez un groupe de machines, en dehors de votre réseau VPC, dont les adresses se situent dans la plage 203.0.113.0/29. Vous pouvez autoriser ces machines à accéder au point de terminaison public en saisissant la commande suivante :

gcloud container clusters update private-cluster-1 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

Voici les seules adresses IP ayant accès au plan de contrôle :

  • Plage principale de my-subnet-1
  • Plage secondaire utilisée pour les pods
  • Les plages d'adresses que vous avez autorisées ; par exemple, 203.0.113.0/29.

Utiliser un sous-réseau personnalisé

Dans cette section, vous créez un cluster privé nommé private-cluster-2. Vous créez un réseau, my-net-0. Vous créez un sous-réseau, my-subnet-2, avec la plage principale 192.168.0.0/20, pour vos nœuds de cluster. Votre sous-réseau dispose de deux plages d'adresses secondaires : my-pods pour les adresses IP de pod et my-services pour les adresses IP de service.

gcloud

Créer un réseau

Commencez par créer un réseau pour votre cluster. La commande suivante crée un réseau, my-net-0 :

gcloud compute networks create my-net-0 \
    --subnet-mode custom

Créer un sous-réseau et des plages secondaires

Ensuite, créez un sous-réseau, my-subnet-2, dans le réseau my-net-0, avec les plages secondaires my-pods pour les pods et my-services pour les services :

gcloud compute networks subnets create my-subnet-2 \
    --network my-net-0 \
    --region us-central1 \
    --range 192.168.0.0/20 \
    --secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
    --enable-private-ip-google-access

Créer un cluster privé

Créez un cluster privé, private-cluster-2, en utilisant les plages réseau, sous-réseau et secondaire que vous avez créées.

  • Pour les clusters Standard, exécutez la commande suivante :

    gcloud container clusters create private-cluster-2 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes \
        --enable-ip-alias \
        --master-ipv4-cidr 172.16.0.16/28 \
        --no-enable-basic-auth \
        --no-issue-client-certificate
    
  • Pour les clusters Autopilot, exécutez la commande suivante :

    gcloud container clusters create-auto private-cluster-2 \
        --region us-central1 \
        --enable-master-authorized-networks \
        --network my-net-0 \
        --subnetwork my-subnet-2 \
        --cluster-secondary-range-name my-pods \
        --services-secondary-range-name my-services \
        --enable-private-nodes
    

Console

Créer un réseau, un sous-réseau et des plages secondaires

  1. Accédez à la page Réseaux VPC dans Cloud Console.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.

  3. Dans le champ Nom, saisissez my-net-0.

  4. Assurez-vous que le mode de création du sous-réseau est défini sur Personnalisé.

  5. Dans la section Nouveau sous-réseau, saisissez la valeur my-subnet-2 pour le champ Nom.

  6. Dans la liste déroulante Région, sélectionnez la région de votre choix.

  7. Dans Plage d'adresses IP, saisissez 192.168.0.0/20.

  8. Cliquez sur Créer une plage d'adresses IP secondaire. Dans Nom de la plage du sous-réseau, saisissez my-services, et dans Plage d'adresses IP secondaire, saisissez 10.0.32.0/20.

  9. Cliquez sur Ajouter une plage d'adresses IP. Dans Nom de plage du sous-réseau, saisissez my-pods, et dans Plage d'adresses IP secondaire, saisissez 10.4.0.0/14.

  10. Définissez Accès privé à Google sur Activé.

  11. Cliquez sur OK.

  12. Cliquez sur Créer.

Créer un cluster privé

Créez un cluster privé qui utilise votre sous-réseau :

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Standard ou Autopilot, cliquez sur Configurer.

  4. Dans le champ Nom, saisissez private-cluster-2.

  5. Pour les clusters standards, dans le volet de navigation, sous Cluster, cliquez sur Mise en réseau.

  6. Sélectionnez la case d'option Cluster privé.

  7. Pour que vous puissiez créer un plan de contrôle accessible à partir de plages d'adresses IP externes autorisées, la case Accéder au plan de contrôle à l'aide de son adresse IP externe doit rester cochée.

  8. (Facultatif pour Autopilot) Définissez le paramètre Plage d'adresses IP du plan de contrôle sur 172.16.0.16/28.

  9. Dans la liste déroulante Réseau, sélectionnez my-net-0.

  10. Dans le menu déroulant Sous-réseau de nœud, sélectionnez my-subnet-2.

  11. Décochez la case Créer automatiquement des plages secondaires.

  12. Dans la liste déroulante Plage CIDR secondaire du pod, sélectionnez my-pods.

  13. Dans la liste déroulante Plage CIDR secondaire des services, sélectionnez my-services.

  14. Cochez la case Activer les réseaux autorisés pour le plan de contrôle.

  15. Cliquez sur Create (Créer).

À ce stade, les adresses IP ci-dessous sont les seules à avoir accès au plan de contrôle :

  • Plage principale de my-subnet-2
  • Plage secondaire de my-pods

Supposons que vous ayez un groupe de machines, en dehors de my-net-0, dont les adresses sont comprises dans la plage 203.0.113.0/29. Vous pouvez autoriser ces machines à accéder au point de terminaison public en saisissant la commande suivante :

gcloud container clusters update private-cluster-2 \
    --enable-master-authorized-networks \
    --master-authorized-networks 203.0.113.0/29

À ce stade, les adresses IP ci-dessous sont les seules à avoir accès au plan de contrôle :

  • Plage principale de my-subnet-2
  • Plage secondaire de my-pods
  • Les plages d'adresses que vous avez autorisées ; par exemple, 203.0.113.0/29.

Accéder à un cluster privé via Cloud Shell

Le cluster privé que vous avez créé lors de l'exercice précédent, private-cluster-1, possède un point de terminaison public et les réseaux autorisés sont activés. Si vous souhaitez accéder au cluster via Cloud Shell, vous devez ajouter l'adresse IP publique de votre environnement Cloud Shell à la liste des réseaux autorisés du cluster.

Procédez comme suit :

  1. Dans la fenêtre de ligne de commande Cloud Shell, utilisez dig pour trouver l'adresse IP externe de votre environnement Cloud Shell :

    dig +short myip.opendns.com @resolver1.opendns.com
    
  2. Ajoutez l'adresse externe de votre environnement Cloud Shell à la liste des réseaux autorisés du cluster :

    gcloud container clusters update private-cluster-1 \
        --zone us-central1-c \
        --enable-master-authorized-networks \
        --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
    

    Remplacez l'élément suivant :

    • EXISTING_AUTH_NETS : votre liste existante de réseaux autorisés. Vous pouvez trouver ces réseaux dans la console ou en exécutant la commande suivante :

      gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
      
    • SHELL_IP : l'adresse IP externe de votre environnement Cloud Shell.

  3. Obtenez des identifiants afin de pouvoir utiliser kubectl pour accéder au cluster :

    gcloud container clusters get-credentials private-cluster-1 \
        --zone us-central1-a \
        --project PROJECT_ID
    

    Remplacez PROJECT_ID par l'ID du projet.

  4. Utilisez kubectl dans Cloud Shell pour accéder à votre cluster privé :

    kubectl get nodes
    

Créer un cluster privé disposant d'un accès illimité au point de terminaison public

Dans cette section, vous allez créer un cluster privé dans lequel n'importe quelle adresse IP peut accéder au plan de contrôle.

gcloud

  • Pour les clusters Standard, exécutez la commande suivante :

    gcloud container clusters create private-cluster-3 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-ip-alias \
        --enable-private-nodes \
        --master-ipv4-cidr 172.16.0.32/28
    
  • Pour les clusters Autopilot, exécutez la commande suivante :

    gcloud container clusters create-auto private-cluster-3 \
        --create-subnetwork name=my-subnet-3 \
        --no-enable-master-authorized-networks \
        --enable-private-nodes
    

où :

  • --create-subnetwork name=my-subnet-3 force GKE à créer automatiquement un sous-réseau nommé my-subnet-3.
  • --no-enable-master-authorized-networks désactive les réseaux autorisés pour le cluster.
  • --enable-ip-alias rend le cluster VPC natif (non requis pour Autopilot).
  • --enable-private-nodes indique que les nœuds du cluster ne possèdent pas d'adresses IP externes.
  • --master-ipv4-cidr 172.16.0.32/28 spécifie une plage d'adresses IP internes pour le plan de contrôle (facultatif pour Autopilot). Ce paramètre est définitif pour le cluster. L'utilisation d'adresses IP internes 1918 non RFC est acceptée.

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la section Standard ou Autopilot, cliquez sur Configurer.

  4. Dans le champ Nom, saisissez private-cluster-3.

  5. Pour les clusters standards, dans le volet de navigation, sous Cluster, cliquez sur Mise en réseau.

  6. Sélectionnez l'option Cluster privé

  7. La case Accéder au plan de contrôle à l'aide de son adresse IP externe doit rester cochée.

  8. (Facultatif pour Autopilot) Définissez le paramètre Plage d'adresses IP du plan de contrôle sur 172.16.0.32/28.

  9. Laissez les paramètres Mise en réseau et Sous-réseau de nœud définis sur default. Cela force GKE à générer un sous-réseau pour votre cluster.

  10. Décochez la case Activer les réseaux autorisés pour le plan de contrôle.

  11. Cliquez sur Create (Créer).

Autres configurations de cluster privé

Outre les configurations précédentes, vous pouvez exécuter des clusters privés avec les configurations suivantes.

Octroyer un accès Internet sortant aux nœuds privés

Pour fournir un accès Internet sortant à vos nœuds privés, utilisez Cloud NAT.

Créer un cluster privé dans un réseau VPC partagé

Pour apprendre à créer un cluster privé dans un réseau VPC partagé, consultez la page Créer un cluster privé dans un VPC partagé.

Déployer une application de conteneur Windows Server sur un cluster privé

Pour savoir comment déployer une application de conteneur Windows Server sur un cluster privé, reportez-vous à la documentation sur le pool de nœuds Windows.

Accéder au point de terminaison privé du plan de contrôle dans le monde entier

Le point de terminaison privé du plan de contrôle est mis en œuvre par un équilibreur de charge TCP/UDP interne dans le réseau VPC du plan de contrôle. Les clients internes ou connectés via des tunnels Cloud VPN et des rattachements de VLAN Cloud Interconnect peuvent accéder aux équilibreurs de charge TCP/UDP internes.

Par défaut, ces clients doivent se situer dans la même région que l'équilibreur de charge.

Lorsque vous activez l'accès mondial au plan de contrôle, l'équilibreur de charge TCP/UDP interne est accessible dans le monde entier. Ainsi, les VM clientes et les systèmes sur site peuvent se connecter au point de terminaison privé du plan de contrôle, en fonction de la configuration des réseaux autorisés, depuis n'importe quelle région.

Pour en savoir plus sur les équilibreurs de charge TCP/UDP internes et l'accès mondial, consultez la page Équilibreurs de charge internes et réseaux connectés.

Activer l'accès mondial au point de terminaison privé du plan de contrôle

Cette section ne s'applique qu'aux clusters créés en mode Standard.

Par défaut, l'accès mondial n'est pas activé pour le point de terminaison privé du plan de contrôle lorsque vous créez un cluster privé. Pour activer l'accès mondial au plan de contrôle, utilisez gcloud ou Google Cloud Console.

gcloud

Ajoutez l'option enable-master-global-access afin de créer un cluster privé pour lequel l'accès mondial au point de terminaison privé du plan de contrôle est activé :

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --enable-ip-alias \
    --master-ipv4-cidr=172.16.16.0/28 \
    --enable-master-global-access

Vous pouvez également activer l'accès mondial au point de terminaison privé du plan de contrôle pour un cluster privé existant :

gcloud container clusters update CLUSTER_NAME \
    --enable-master-global-access

Console

Pour créer un cluster privé avec accès mondial au plan de contrôle activé, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Saisissez un nom.

  4. Dans le volet de navigation, sous Cluster, cliquez sur Réseau.

  5. Sélectionner Cluster privé.

  6. Cochez la case Activer l'accès mondial au plan de contrôle.

  7. Configurez les autres champs selon vos besoins.

  8. Cliquez sur Create (Créer).

Pour activer l'accès mondial au plan de contrôle pour un cluster privé existant, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. À côté du cluster que vous souhaitez modifier, cliquez sur Actions, puis sur Modifier.

  3. Dans la section Mise en réseau, à côté de Réseaux autorisés pour le plan de contrôle, cliquez sur Modifier.

  4. Dans la boîte de dialogue Modifier les réseaux autorisés pour le plan de contrôle, cochez la case Activer les réseaux autorisés pour le plan de contrôle.

  5. Cliquez sur Save Changes (Enregistrer les modifications).

Vérifier l'accès mondial au point de terminaison privé du plan de contrôle

Vous pouvez vérifier que l'accès mondial au point de terminaison privé du plan de contrôle est activé en exécutant la commande suivante et en consultant son résultat.

gcloud container clusters describe CLUSTER_NAME

Le résultat inclut une section privateClusterConfig dans laquelle vous pouvez voir l'état de masterGlobalAccessConfig.

privateClusterConfig:
  enablePrivateNodes: true
  masterIpv4CidrBlock: 172.16.1.0/28
  peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
  privateEndpoint: 172.16.1.2
  publicEndpoint: 34.68.128.12
  masterGlobalAccessConfig:
    enabled: true

Se connecter au point de terminaison privé du plan de contrôle à partir de réseaux sur site

Lorsque vous créez un cluster privé GKE et désactivez le point de terminaison public du plan de contrôle, vous pouvez toujours vous connecter au point de terminaison privé du plan de contrôle à partir d'un réseau sur site à l'aide d'outils tels que kubectl. Cette section décrit les exigences de mise en réseau requises pour accéder au point de terminaison privé du plan de contrôle à partir d'un réseau sur site.

Le schéma suivant illustre un chemin de routage entre un réseau sur site et les nœuds du plan de contrôle GKE :

Schéma illustrant le routage entre un VPC sur site et un plan de contrôle de cluster

Pour vous connecter au point de terminaison privé d'un plan de contrôle à partir d'un réseau sur site, effectuez les tâches suivantes :

  1. Identifiez l'appairage entre le réseau VPC de votre cluster et le réseau VPC du plan de contrôle :

    gcloud container clusters describe CLUSTER_NAME
    

    Cette commande affiche en sortie le champ privateClusterConfig.peeringName du cluster. Il s'agit du nom de l'appairage entre votre cluster et le réseau VPC du plan de contrôle. Exemple :

    privateClusterConfig:
      enablePrivateNodes: true
      masterIpv4CidrBlock: 172.16.1.0/28
      peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
      privateEndpoint: 172.16.1.2
      publicEndpoint: 34.68.128.12
    
  2. Configurez le réseau VPC pour exporter ses routes personnalisées dans la relation d'appairage au réseau VPC du plan de contrôle. Le réseau VPC du plan de contrôle est déjà configuré pour importer des routes personnalisées. Cela permet au plan de contrôle de renvoyer des paquets aux ressources sur site.

    Mettez à jour la connexion d'appairage en activant l'exportation de routes personnalisées pour la connexion d'appairage que vous avez identifiée à l'étape précédente.

  3. Pour fournir un chemin d'accès du trafic depuis votre réseau sur site vers le réseau VPC du plan de contrôle, effectuez l'une des opérations suivantes :

    • Pour Cloud Interconnect et Cloud VPN : annoncez la plage CIDR du plan de contrôle à l'aide d'une annonce de routage personnalisée Cloud Router. Si l'accès mondial au plan de contrôle est désactivé, cette annonce de routage personnalisée doit se trouver sur une session BGP d'un routeur Cloud Router dans la même région que le cluster. Si l'accès mondial au plan de contrôle est activé, vous pouvez placer cette annonce de routage personnalisée sur un routeur Cloud Router dans n'importe quelle région. Pour plus d'informations, consultez la section Annoncer des plages d'adresses IP personnalisées.

    • Pour un tunnel VPN classique qui n'utilise pas le routage dynamique : vous devez configurer une route statique pour la plage CIDR du plan de contrôle dans vos routeurs sur site.

Éléments à prendre en compte pour les annonces de routage sur site

Les CIDR que votre réseau sur site annonce vers les routeurs cloud du réseau VPC de votre cluster doivent respecter les conditions suivantes :

  • Alors que le VPC de votre cluster accepte une route par défaut, le réseau VPC du plan de contrôle refuse toujours les routes avec une destination 0.0.0.0/0 (une route par défaut), car le réseau VPC du plan de contrôle dispose déjà d'une route par défaut locale et cette route locale est toujours prioritaire. Si votre routeur sur site annonce une route par défaut dans votre réseau VPC, il doit également annoncer des destinations sur site spécifiques afin que le plan de contrôle ait un chemin de retour vers le réseau sur site. Ces destinations plus spécifiques aboutissent à des routes dynamiques personnalisées plus spécifiques dans votre réseau VPC, et elles sont acceptées par le réseau VPC du plan de contrôle via l'appairage de réseaux VPC.

  • Lorsque le réseau VPC du plan de contrôle accepte d'autres routes larges, celles-ci interrompent la connectivité aux adresses IP publiques des API et des services Google. À titre d'exemple, vous ne devez pas annoncer de routes avec des destinations 0.0.0.0/1 et 128.0.0.0/1. Reportez-vous au point précédent pour obtenir une autre solution.

  • Soyez particulièrement attentif aux limites de Cloud Router, en particulier au nombre maximal de destinations uniques pour les routes apprises.

Désactiver l'exportation de routes personnalisées

Pour désactiver l'exportation de routes personnalisées à partir de votre VPC, procédez comme suit :

gcloud compute networks peerings update PEERING_NAME \
    --network VPC_NAME \
    --no-export-custom-routes

Remplacez l'élément suivant :

  • PEERING_NAME : valeur de privateClusterConfig.peeringName.
  • VPC_NAME : nom de votre VPC.

Pour trouver la valeur peeringName, reportez-vous à la première étape des instructions ci-dessus concernant l'activation de l'exportation de routes personnalisées.

Vérifier que les nœuds ne possèdent pas d'adresses IP externes

Après avoir créé un cluster privé, vérifiez que les nœuds du cluster ne possèdent pas d'adresses IP externes.

gcloud

Exécutez la commande suivante :

kubectl get nodes --output wide

La colonne EXTERNAL-IP du résultat est vide :

STATUS ... VERSION        EXTERNAL-IP  OS-IMAGE ...
Ready      v.8.7-gke.1                 Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google
Ready      v1.8.7-gke.1                Container-Optimized OS from Google

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster.

  3. Sur la page Clusters, cliquez sur l'onglet Nœuds.

  4. Sous Pools de nœuds, cliquez sur le nom du pool de nœuds.

  5. Sur la page Détails du pool de nœuds, sous Groupes d'instances, cliquez sur le nom de votre groupe d'instances. Par exemple, gke-private-cluster-0-default- pool-5c5add1f-grp.

  6. Dans la liste des instances, vérifiez que les vôtres ne disposent pas d'adresses IP externes.

Afficher le sous-réseau et les plages d'adresses secondaires du cluster

Après avoir créé un cluster privé, vous pouvez afficher le sous-réseau et les plages d’adresses secondaires que vous ou GKE avez provisionnés pour le cluster.

gcloud

Répertorier tous les sous-réseaux

Pour répertorier les sous-réseaux du réseau de votre cluster, exécutez la commande suivante :

gcloud compute networks subnets list \
    --network NETWORK_NAME

Remplacez NETWORK_NAME par le réseau du cluster privé. Si vous avez créé le cluster avec un sous-réseau créé automatiquement, utilisez default.

Dans le résultat de la commande, recherchez le nom du sous-réseau du cluster.

Afficher le sous-réseau du cluster

Obtenez des informations sur le sous-réseau créé automatiquement :

gcloud compute networks subnets describe SUBNET_NAME

Remplacez SUBNET_NAME par le nom du sous-réseau.

Le résultat comprend la plage d'adresses principale pour les nœuds (premier champ ipCidrRange) et les plages secondaires pour les pods et les services (sous secondaryIpRanges) :

...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
  rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
  rangeName: gke-private-cluster-1-services-163e3c97
...

Console

  1. Accédez à la page Réseaux VPC dans Cloud Console.

    Accéder aux réseaux VPC

  2. Cliquez sur le nom du sous-réseau. Par exemple, gke-private-cluster-0-subnet-163e3c97.

  3. Sous Plage d'adresses IP, vous pouvez voir la plage d'adresses principale du sous-réseau. c'est-à-dire celle utilisée pour les nœuds

  4. Sous Plages d'adresses IP secondaires, vous pouvez voir la plage d'adresses IP des pods et celle des services.

Afficher le point de terminaison d'un cluster privé

Vous pouvez afficher des points de terminaison de clusters privés à l'aide de l'outil gcloud ou de Cloud Console.

gcloud

Exécutez la commande suivante :

gcloud container clusters describe CLUSTER_NAME

Les points de terminaison privés et publics sont indiqués dans le résultat :

...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster.

  3. Dans l'onglet Détails, sous Paramètres de base du cluster, recherchez le champ Point de terminaison.

Extraire des images de conteneur d'un registre d'images

Dans un cluster privé, l'environnement d'exécution du conteneur peut extraire des images de conteneur de Artifact Registry. En revanche, il ne peut pas extraire des images d'un autre registre d'images de conteneur sur Internet. Cela s'explique par le fait que les nœuds d'un cluster privé ne possèdent pas d'adresses IP externes. Par conséquent, ils ne peuvent pas communiquer par défaut avec des services en dehors du réseau Google.

Les nœuds d'un cluster privé peuvent communiquer avec les services Google, tels que Artifact Registry, s'ils se trouvent sur un sous-réseau sur lequel l'accès privé à Google est activé.

Les commandes suivantes créent un objet Deployment qui extrait un exemple d'image d'un dépôt Artifact Registry appartenant à Google :

kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Ajouter des règles de pare-feu pour des cas d'utilisation spécifiques

Cette section explique comment ajouter une règle de pare-feu à un cluster privé. Par défaut, les règles de pare-feu limitent le plan de contrôle de cluster de sorte qu'il ne lance que des connexions TCP vers vos nœuds et pods sur les ports 443 (HTTPS) et 10250 (kubelet). Pour certaines fonctionnalités Kubernetes, vous devrez peut-être ajouter des règles de pare-feu pour autoriser l'accès sur des ports supplémentaires.

Les fonctionnalités de Kubernetes nécessitant des règles de pare-feu supplémentaires sont les suivantes :

L'ajout d'une règle de pare-feu autorise le trafic provenant du plan de contrôle de cluster vers tous les éléments suivants :

  • Port spécifié de chaque nœud (hostPort)
  • Port spécifié de chaque pod exécuté sur ces nœuds
  • Port spécifié de chaque service exécuté sur ces nœuds

Pour en savoir plus sur les règles de pare-feu, reportez-vous à la section Règles de pare-feu de la documentation de Cloud Load Balancing.

Pour ajouter une règle de pare-feu dans un cluster privé, vous devez enregistrer le bloc CIDR du plan de contrôle de cluster et la cible utilisée. Une fois l'enregistrement effectué, vous pouvez créer la règle.

Étape 1. Afficher le bloc CIDR du plan de contrôle

Vous avez besoin du bloc CIDR du plan de contrôle de cluster pour ajouter une règle de pare-feu.

gcloud

Exécutez la commande suivante :

gcloud container clusters describe CLUSTER_NAME

Remplacez CLUSTER_NAME par le nom de votre cluster privé.

Dans le résultat de la commande, notez la valeur du champ masterIpv4CidrBlock.

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster souhaité.

Dans l'onglet Détails, sous Mise en réseau, notez la valeur du champ Plage d'adresses du plan de contrôle.

Étape 2. Afficher les règles de pare-feu existantes

Vous devez spécifier la cible (dans ce cas, les nœuds de destination) utilisée par les règles de pare-feu existantes du cluster.

gcloud

Exécutez la commande suivante :

gcloud compute firewall-rules list \
    --filter 'name~^gke-CLUSTER_NAME' \
    --format 'table(
        name,
        network,
        direction,
        sourceRanges.list():label=SRC_RANGES,
        allowed[].map().firewall_rule().list():label=ALLOW,
        targetTags.list():label=TARGET_TAGS
    )'

Dans le résultat de la commande, notez la valeur du champ Targets.

Console

  1. Accédez à la page Pare-feu dans Cloud Console.

    Accéder à la page "Pare-feu"

  2. Dans le champ Filtrer le tableau, saisissez gke-CLUSTER_NAME.

Dans les résultats, notez la valeur du champ Cibles.

Étape 3. Ajouter une règle de pare-feu

gcloud

Exécutez la commande suivante :

gcloud compute firewall-rules create FIREWALL_RULE_NAME \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges MASTER_CIDR_BLOCK \
    --rules PROTOCOL:PORT \
    --target-tags TARGET

Remplacez l'élément suivant :

  • FIREWALL_RULE_NAME : nom choisi pour la règle de pare-feu.
  • MASTER_CIDR_BLOCK : bloc CIDR du plan de contrôle de cluster (masterIpv4CidrBlock) que vous avez collecté précédemment.
  • PROTOCOL:PORT : port souhaité et son protocole, tcp ou udp.
  • TARGET : valeur cible (Targets) que vous avez collectée précédemment.

Console

  1. Accédez à la page Pare-feu dans Cloud Console.

    Accéder à la page "Pare-feu"

  2. Cliquez sur Créer une règle de pare-feu.

  3. Dans la section Nom, saisissez le nom souhaité pour la règle de pare-feu.

  4. Dans la liste déroulante Réseau, sélectionnez le réseau approprié.

  5. Dans la section Sens du trafic, cliquez sur Entrée.

  6. Dans Action en cas de correspondance, cliquez sur Autoriser.

  7. Dans la liste déroulante Cibles, sélectionnez Tags cibles spécifiés.

  8. Dans le champ Tags cibles, saisissez la valeur cible que vous avez notée précédemment.

  9. Dans la liste déroulante Filtre source, sélectionnez Plages d'adresses IP.

  10. Sous Plages d'adresses IP sources, saisissez le bloc CIDR du plan de contrôle du cluster.

  11. Sous Protocoles et ports, cliquez surProtocoles et ports spécifiés, cochez la case correspondant au protocole approprié (tcp ou udp ) puis saisissez le numéro de port dans le champ du protocole.

  12. Cliquez sur Create (Créer).

Protéger un cluster privé avec VPC Service Controls

Pour renforcer la sécurité de vos clusters privés GKE, vous pouvez les protéger à l'aide de VPC Service Controls.

VPC Service Controls offre une sécurité supplémentaire pour vos clusters privés GKE afin de réduire le risque d'exfiltration des données. À l'aide de VPC Service Controls, vous pouvez ajouter des projets aux périmètres de service afin de protéger les ressources et les services des requêtes provenant de l'extérieur du périmètre.

Pour en savoir plus sur les périmètres de service, consultez la page Périmètres de service : détails et configuration.

Si vous utilisez Container Registry ou Artifact Registry avec votre cluster privé GKE, des étapes supplémentaires sont nécessaires pour utiliser ce cluster privé avec VPC Service Controls. Pour plus d'informations, reportez-vous à la page Configurer Container Registry ou Artifact Registry pour les clusters privés GKE.

Réutilisation d'appairage de VPC

Tous les clusters privés que vous créez après le 15 janvier 2020 réutilisent des connexions d'appairage de réseaux VPC.

Tous les clusters privés que vous avez créés avant le 15 janvier 2020 utilisent une connexion d'appairage de réseaux VPC unique. Chaque réseau VPC peut appairer jusqu'à 25 autres réseaux VPC, ce qui signifie que pour ces clusters, la limite est de 25 clusters privés au maximum par réseau (en supposant que les appairages ne sont pas utilisés à d'autres fins).

Cette fonctionnalité n'est pas rétroportée dans les versions précédentes. Pour activer la réutilisation de l'appairage du réseau VPC sur des clusters privés plus anciens, vous pouvez supprimer un cluster et le recréer. La mise à niveau d'un cluster ne lui permet pas de réutiliser une connexion d'appairage de réseaux VPC existante.

Chaque emplacement peut accepter jusqu'à 75 clusters privés, à condition que ceux-ci soient compatibles avec la réutilisation de l'appairage de réseaux VPC. Les zones et les régions sont considérées comme des emplacements distincts.

Par exemple, vous pouvez créer jusqu'à 75 clusters zonaux privés dans la zone us-east1-a et 75 clusters régionaux privés dans la zone us-east1. Cela s'applique également si vous utilisez des clusters privés dans un réseau VPC partagé. Le nombre maximal de connexions à un seul réseau VPC est de 25. Vous ne pouvez donc créer des clusters privés que pour 25 emplacements uniques.

La réutilisation de l'appairage de réseaux VPC ne s'applique qu'aux clusters situés au même emplacement, par exemple dans les clusters régionaux de la même région ou dans les clusters zonaux de la même zone. Vous pouvez disposer au maximum de quatre appairages de réseaux VPC par région si vous créez à la fois des clusters régionaux et des clusters zonaux dans toutes les zones de cette région.

Vous pouvez vérifier si votre cluster privé réutilise les connexions d'appairage de réseaux VPC à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

gcloud container clusters describe CLUSTER_NAME \
    --zone=ZONE_NAME \
    --format="value(privateClusterConfig.peeringName)"

Si votre cluster réutilise des connexions d'appairage de VPC, la sortie commence par gke-n. Exemple :gke-n34a117b968dee3b2221-93c6-40af-peer

Console

Vérifiez la ligne Appairage de VPC sur la page Détails du cluster. Si votre cluster réutilise des connexions d'appairage de VPC, la sortie commence par gke-n. Par exemple, gke-n34a117b968dee3b2221-93c6-40af-peer.

Effectuer un nettoyage

Une fois les tâches de cette page terminées, procédez comme suit pour supprimer les ressources afin d'éviter que des frais inutiles ne vous soient facturés sur votre compte :

Supprimer les clusters

gcloud

gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3

Console

  1. Accédez à la page Google Kubernetes Engine dans Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Sélectionnez chaque cluster.

  3. Cliquez sur Supprimer.

Supprimer le réseau

gcloud

gcloud compute networks delete my-net-0

Console

  1. Accédez à la page Réseaux VPC dans Cloud Console.

    Accéder aux réseaux VPC

  2. Dans la liste des réseaux, cliquez sur my-net-0.

  3. Sur la page Détails du réseau VPC, cliquez sur Supprimer le réseau VPC.

  4. Dans la boîte de dialogue Supprimer un réseau, cliquez sur Supprimer.

Exigences, restrictions et limitations

Les clusters privés s'accompagnent des exigences suivantes :

Les clusters privés comportent les restrictions suivantes :

  • Vous ne pouvez pas convertir un cluster non privé existant en cluster privé.
  • Pour les clusters exécutant des versions antérieures à 1.16.9 ou entre les versions 1.17.0 et 1.17.4, le plan de contrôle de cluster n'est pas accessible à partir des CIDR 172.17.0.0/16.
  • Pour les clusters exécutant des versions antérieures à 1.14.4, la plage d'adresses IP d'un plan de contrôle de cluster, d'un nœud, d'un pod ou d'un service ne peut pas chevaucher la plage 172.17.0.0/16.
  • Lorsque vous utilisez l'adresse IP 172.17.0.0/16 pour votre plage d'adresses IP de plan de contrôle, vous ne pouvez pas utiliser cette plage pour les adresses IP de nœuds, de pods ou de services. Cette restriction s'applique aux clusters zonaux exécutant les versions 1.14.4 ou ultérieures, et aux clusters régionaux exécutant les versions 1.16.9 à 1.17.0, ou 1.17.4 et ultérieures.
  • La suppression de l'appairage VPC entre le plan de contrôle de cluster et les nœuds de cluster, la suppression des règles de pare-feu autorisant le trafic entrant issu du plan de contrôle de cluster vers les nœuds sur le port 10250 ou la suppression de la route par défaut vers la passerelle Internet par défaut entraînent l'arrêt du fonctionnement d'un cluster privé. Si vous supprimez la route par défaut, vous devez vous assurer que le trafic vers les services Google nécessaires est bien routé. Pour plus d'informations, consultez la section Routage personnalisé.
  • Lorsque l'exportation de routes personnalisées est activée pour le VPC, la création de routes qui chevauchent les plages d'adresses IP Google peut interrompre votre cluster.
  • Vous pouvez ajouter jusqu'à 50 réseaux autorisés (blocs CIDR autorisés) dans un projet. Pour en savoir plus, consultez l'article Ajouter un réseau autorisé à un cluster existant.

Les clusters privés comportent les limitations suivantes :

  • La taille du bloc RFC 1918 pour le plan de contrôle de cluster doit être /28.
  • GKE peut détecter un chevauchement avec le bloc d'adresses du plan de contrôle de cluster, mais il ne peut pas détecter de chevauchement au sein d'un réseau VPC partagé.
  • Tous les nœuds d'un cluster privé sont créés sans adresse IP publique. Leur accès aux API et services de Google est limité. Pour fournir un accès Internet sortant à vos nœuds privés, utilisez Cloud NAT.
  • L'accès privé à Google est activé automatiquement lorsque vous créez un cluster privé, sauf si vous utilisez un VPC partagé. Vous ne devez pas désactiver l'accès privé à Google, sauf si vous utilisez la fonctionnalité NAT pour accéder à Internet.
  • Les clusters privés créés avant le 15 janvier 2020 sont soumis à une limite maximale de 25 clusters privés par réseau (en supposant que les appairages ne sont pas utilisés à d'autres fins). Consultez la page Réutilisation de l'appairage de VPC pour plus d'informations.
  • Chaque cluster privé nécessite une route d'appairage entre votre VPC et celui de Google, mais une seule opération d'appairage peut se produire à la fois. Si vous tentez de créer plusieurs clusters privés en même temps, le processus de création du cluster risque d'expirer. Pour éviter cela, créez des clusters privés en série afin que les routes d'appairage VPC existent déjà pour chaque cluster privé suivant. La tentative de création d'un seul cluster privé peut également expirer si des opérations sont en cours d'exécution sur votre VPC.
  • Si vous étendez la plage d'adresses IP principale d'un sous-réseau pour accepter des nœuds supplémentaires, vous devez ajouter la plage d'adresses IP principale du sous-réseau étendu à la liste des réseaux autorisés maîtres pour votre cluster. Si vous ne le faites pas, les règles de pare-feu d'autorisation d'entrée pertinentes pour le maître ne sont pas mises à jour et les nœuds créés dans l'espace d'adressage IP étendu ne pourront pas s'enregistrer auprès du maître. Cela peut la suppression et le remplacement continus de nouveaux nœuds et provoquer une panne. Cette panne peut se produire lors de l'exécution de mises à niveau du pool de nœuds ou lorsque les nœuds sont automatiquement remplacés à cause d'échecs de la vérification d'activité.
  • Ne créez pas de règles de pare-feu ni de règles de stratégies de pare-feu hiérarchiques ayant une priorité plus élevée que les règles de pare-feu créées automatiquement.

Dépannage

Dans les sections suivantes, nous expliquons comment résoudre les problèmes courants liés aux clusters privés.

Le cluster chevauche l'homologue actif

Symptômes

La tentative de création d'un cluster privé renvoie une erreur semblable à ce qui suit :

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
Causes probables

Vous avez choisi un CIDR de plan de contrôle chevauchant.

Solution

Supprimez et recréez le cluster avec un CIDR de plan de contrôle différent.

Impossible d'accéder au cluster

Symptômes

Après la création d'un cluster privé, une tentative d'exécution de commandes kubectl sur le cluster renvoie une erreur semblable à l'un des exemples suivants :

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.
Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
Causes probables

kubectl ne parvient pas à communiquer avec le plan de contrôle du cluster.

Solution

Vous devez ajouter des réseaux autorisés pour votre cluster afin d'autoriser les connexions au plan de contrôle de cluster depuis votre réseau.

Assurez-vous que l'accès mondial au point de terminaison privé du plan de contrôle est activé si les clients utilisent la commande kubectl d'une région différente du cluster. Pour en savoir plus, consultez la section Accéder au point de terminaison privé du plan de contrôle dans le monde entier.

Impossible de créer le cluster en raison de l'omission d'une option

Symptômes

gcloud container clusters create renvoie une erreur semblable à ce qui suit :

Cannot specify --enable-private-endpoint without --enable-private-nodes.
Causes probables

Vous n'avez pas spécifié un paramètre nécessaire.

Solution

Veillez à spécifier les paramètres nécessaires. Vous ne pouvez pas activer un point de terminaison privé pour le plan de contrôle de cluster sans activer également les nœuds privés.

Impossible de créer le cluster en raison du chevauchement du bloc CIDR IPv4

Symptômes

gcloud container clusters create renvoie une erreur semblable à ce qui suit :

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
Causes probables

Vous avez spécifié un bloc CIDR de plan de contrôle qui chevauche un sous-réseau existant dans votre VPC.

Solution

Spécifiez un bloc CIDR pour --master-ipv4-cidr qui ne chevauche pas un sous-réseau existant.

Impossible de créer le cluster en raison de l'utilisation de la plage de services par un autre cluster

Symptômes

La tentative de création d'un cluster privé renvoie une erreur semblable à ce qui suit :

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
Causes probables

Au choix :

  • Vous avez choisi une plage de services qui est toujours utilisée par un autre cluster, ou le cluster n'a pas été supprimé.
  • Un cluster utilisant cette plage de services a été supprimé, mais les métadonnées des plages secondaires n'ont pas été correctement supprimées. Les plages secondaires d'un cluster GKE sont enregistrées dans les métadonnées Compute Engine et doivent être supprimées une fois le cluster supprimé. Même lorsqu'un cluster est correctement supprimé, il est possible que les métadonnées ne le soient pas.
Solution

Procédez comme suit :

  • Vérifiez si la plage de services est utilisée par un cluster existant. Vous pouvez utiliser la commande gcloud container clusters list avec l'option filter pour rechercher le cluster. Si un cluster existant utilise les plages de services, vous devez le supprimer ou en créer une nouvelle.
  • Si la plage de services n'est pas utilisée par un cluster existant, supprimez manuellement l'entrée de métadonnées correspondant à la plage de services que vous souhaitez utiliser.

Impossible de créer le sous-réseau

Symptômes

Lorsque vous tentez de créer un cluster privé avec un sous-réseau automatique, ou de créer un sous-réseau personnalisé, vous pouvez rencontrer l'erreur suivante :

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.
Causes probables

La plage CIDR du plan de contrôle que vous avez spécifiée chevauche une autre plage d'adresses IP du cluster. Cela peut également se produire si vous avez récemment supprimé un cluster privé et que vous essayez de créer un autre cluster privé avec le même CIDR de plan de contrôle.

Solution

Essayez d’utiliser une autre plage CIDR.

Impossible d'extraire l'image du registre Docker Hub public

Symptômes

Un pod exécuté dans votre cluster affiche un avertissement dans kubectl describe :

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
Causes probables

Les nœuds d'un cluster privé ne possèdent pas d'adresses IP externes. Ils ne répondent donc pas aux conditions d'accès à Internet. Toutefois, les nœuds peuvent accéder aux API et services Google (y compris à Artifact Registry et Container Registry) si vous avez activé l'accès privé à Google et respecté les exigences relatives à la configuration réseau.

Solution

Utilisez l'une des solutions suivantes :

  • Copiez les images de votre cluster privé de Docker Hub vers Artifact Registry. Pour en savoir plus, consultez la page Migrer des conteneurs à partir d'un registre tiers.

  • GKE vérifie automatiquement mirror.gcr.io pour les copies mises en cache des images Docker Hub fréquemment utilisées.

  • Si vous devez extraire des images de Docker Hub ou d'un autre dépôt public, utilisez Cloud NAT ou un proxy basé sur une instance correspondant à la cible d'une route 0.0.0.0/0 statique.

Dépassement du délai d'une requête API déclenchant un webhook d'admission

Symptômes

Une requête API qui déclenche un webhook d'admission configuré pour utiliser un service avec un port cible autre que 443 dépasse le délai, ce qui entraîne l'échec de la requête :

Error from server (Timeout): request did not complete within requested timeout 30s
Causes probables

Par défaut, le pare-feu n'autorise pas les connexions TCP aux nœuds, sauf sur les ports 443 (HTTPS) et 10250 (kubelet). Un webhook d'admission qui tente de communiquer avec un pod sur un port autre que 443 échoue si aucune règle de pare-feu personnalisée n'autorise le trafic.

Solution

Ajoutez une règle de pare-feu pour votre cas d'utilisation spécifique.

Impossible de créer le cluster en raison de l'échec de la vérification de l'état

Symptômes

Une fois créé, un cluster privé se retrouve bloqué à l'étape de vérification de l'état et génère un message d'erreur semblable à l'un des messages suivants :

All cluster resources were brought up, but only 0 of 2 have registered.
All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
Causes probables

Parmi les suivantes :

  • Les nœuds de cluster ne peuvent pas télécharger les binaires requis depuis l'API Cloud Storage (storage.googleapis.com).
  • Des règles de pare-feu limitent le trafic de sortie.
  • Les autorisations IAM du VPC partagé sont incorrectes.
  • L'accès privé à Google nécessite la configuration du DNS pour *.gcr.io.
Solution

Utilisez l'une des solutions suivantes :

kubelet n'a pas réussi à créer le bac à sable de pod

Symptômes

Après la création d'un cluster privé, il génère une erreur semblable à l'une des suivantes :

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
Causes probables

Le pod calico-node ou netd ne peut pas atteindre *.gcr.io.

Solution

Utilisez l'une des solutions suivantes :

Nœuds de cluster privé créés, mais non associés au cluster

Souvent, lorsque vous utilisez des dispositifs de routage personnalisé et de réseau tiers sur le VPC utilisé par votre cluster privé, la route par défaut (0.0.0.0/0) est redirigée vers le dispositif au lieu de la passerelle Internet par défaut. Outre la connectivité du plan de contrôle, vous devez vous assurer que les destinations suivantes sont accessibles :

  • *.googleapis.com
  • *.gcr.io
  • gcr.io

Configurez l'accès privé à Google pour les trois domaines. Cette bonne pratique permet de démarrer les nouveaux nœuds et de les associer au cluster, tout en continuant à limiter le trafic Internet.

Étape suivante