Configurer des clusters avec un VPC partagé

Autopilot Standard

---

Ce guide explique comment créer deux clusters Google Kubernetes Engine (GKE) situés dans des projets distincts mais utilisant un VPC partagé. Pour obtenir des informations générales sur la mise en réseau GKE, consultez la page intitulée Présentation du réseau.

Les exemples de ce guide configurent l'infrastructure d'une application Web à deux niveaux, comme décrit dans la page Présentation du VPC partagé.

Pourquoi utiliser un VPC partagé avec GKE ?

Avec le VPC partagé, vous désignez un projet en tant que projet hôte et vous lui associez un ou plusieurs projets de service. Vous créez des réseaux, des sous-réseaux, des plages d'adresses secondaires, des règles de pare-feu et d'autres ressources réseau dans le projet hôte. Ensuite, vous partagez certains sous-réseaux, y compris les plages secondaires, avec les projets de service. Les composants exécutés dans un projet de service peuvent utiliser le VPC partagé pour communiquer avec les composants exécutés dans les autres projets de service.

Vous pouvez utiliser le VPC partagé avec des clusters Autopilot avec des clusters zonaux et régionaux standards.

Les clusters standards qui utilisent un VPC partagé ne peuvent pas utiliser les anciens réseaux, et le routage du trafic de VPC natif doit être activé. Les clusters Autopilot activent toujours le routage du trafic VPC natif.

Vous pouvez configurer le VPC partagé lorsque vous créez un nouveau cluster. GKE n'autorise pas la conversion de clusters existants vers le modèle de VPC partagé.

Avec le VPC partagé, certains quotas et limites s'appliquent. Par exemple, il existe un quota pour le nombre de réseaux au sein d'un projet et une limite sur le nombre de projets de service pouvant être associés à un projet hôte. Pour plus de détails, consultez les Quotas et limites.

Avant de commencer

Avant de commencer à configurer un cluster avec un VPC partagé :

• Assurez-vous de disposer d'une organisationGoogle Cloud .
• Assurez-vous que votre organisation dispose de trois projetsGoogle Cloud .
• Assurez-vous de bien maîtriser les concepts liés aux VPC partagés, y compris les différents rôles de gestion de l'authentification et des accès (IAM) utilisés par le VPC partagé. Les tâches décrites dans ce guide doivent être effectuées par un administrateur de VPC partagé.
• Assurez-vous de bien comprendre les contraintes liées aux règles d'administration applicables à votre organisation, votre dossier ou vos projets. Un administrateur des règles d'administration peut avoir défini des contraintes restreignant quels projets sont autorisés à être des projets hôtes de VPC partagé ou quels sous-réseaux peuvent être partagés. Pour plus d'informations, reportez-vous aux contraintes relatives aux règles d'administration.

Avant d'effectuer les exercices de ce guide :

• Choisissez l'un de vos projets comme projet hôte.
• Choisissez deux de vos projets comme projets de service.

Chaque projet possède un nom, un identifiant et un numéro. Dans certains cas, le nom et l'identifiant sont identiques. Ce guide utilise les noms descriptifs et les espaces réservés suivants pour faire référence à vos projets :

Nom descriptif	Espace réservé de l'ID du projet	Espace réservé du numéro de projet
Votre projet hôte	HOST_PROJECT_ID	HOST_PROJECT_NUM
Votre premier projet de service	SERVICE_PROJECT_1_ID	SERVICE_PROJECT_1_NUM
Votre deuxième projet de service	SERVICE_PROJECT_2_ID	SERVICE_PROJECT_2_NUM

Remarque: Les termes "premier" et "deuxième" projet de service ne font pas nécessairement référence à un ordre. Ces termes servent uniquement à distinguer les deux projets entre eux.

Trouver les identifiants et numéros de vos projets

Vous pouvez trouver l'ID et les numéros de votre projet à l'aide de la gcloud CLI ou de la console Google Cloud .

Console

1. Accédez à la page Accueil de la console Google Cloud .

   Accéder à la page Accueil

2. Dans le sélecteur de projet, choisissez le projet que vous avez désigné comme projet hôte.

3. Sous Informations sur le projet, vous pouvez voir le nom du projet, son ID et son numéro. Prenez note de l'ID et du numéro pour les utiliser plus tard.

4. Répétez ces étapes pour chacun des projets jouant le rôle de projets de service.

gcloud

Répertoriez vos projets à l'aide de la commande suivante :

gcloud projects list

Le résultat affiche les noms, identifiants et numéros de vos projets. Notez l'ID et le numéro pour les utiliser plus tard :

PROJECT_ID        NAME        PROJECT_NUMBER
host-123          host        1027xxxxxxxx
srv-1-456         srv-1       4964xxxxxxxx
srv-2-789         srv-2       4559xxxxxxxx

Activer l'API GKE dans vos projets

Avant d'effectuer les exercices donnés dans ce guide, assurez-vous que l'API GKE est activée dans chacun de vos trois projets. Activer l'API dans un projet crée un compte de service GKE pour le projet. Pour effectuer les autres tâches de ce guide, chacun de vos projets doit disposer d'un compte de service GKE.

Vous pouvez activer l'API GKE à l'aide de la console Google Cloud ou de Google Cloud CLI.

Console

1. Accédez à la page API et services de la console Google Cloud .

   Accéder aux API et services

2. Dans le sélecteur de projet, choisissez le projet que vous avez désigné comme projet hôte.

3. Si Kubernetes Engine API figure dans la liste des API, elle est déjà activée et vous n'avez rien à faire. Si elle ne figure pas dans la liste, cliquez sur Activer les API et les services. Recherchez Kubernetes Engine API. Cliquez sur la fiche API Kubernetes Engine, puis sur Activer.

4. Répétez ces étapes pour chacun des projets que vous avez désignés comme projet de service. Chaque opération peut prendre un certain temps.

gcloud

Activez l'API GKE pour vos trois projets. Chaque opération peut prendre un certain temps :

gcloud services enable container.googleapis.com --project HOST_PROJECT_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_1_ID
gcloud services enable container.googleapis.com --project SERVICE_PROJECT_2_ID

Créer un réseau et deux sous-réseaux

Dans cette section, vous allez effectuer les tâches suivantes :

1. Dans votre projet hôte, créez un réseau nommé shared-net.
2. Créez deux sous-réseaux nommés tier-1 et tier-2.
3. Pour chaque sous-réseau, créez deux plages d'adresses secondaires : une pour les services et une pour les pods.

Remarque : Les plages d'adresses secondaires pour les pods, les services et les nœuds ne doivent pas chevaucher la plage 172.17.0.0/16 et doivent respecter les valeurs par défaut et les limites pour les tailles de plage.

Console

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

   Accéder aux réseaux VPC

2. Dans le sélecteur de projet, choisissez votre projet hôte.

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

4. Dans le champ Nom, saisissez shared-net.

5. Dans Mode de création du sous-réseau, sélectionnez Personnalisé.

6. Dans la zone Nouveau sous-réseau, saisissez la valeur tier-1 pour le champ Nom.

7. Dans le champ Région, sélectionnez une région.

8. Dans Type de pile IP, sélectionnez IPv4 (single-stack).

9. Dans Plage IPv4, saisissez 10.0.4.0/22.

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

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

12. Cliquez sur Ajouter un sous-réseau.

13. Dans le champ Nom, saisissez tier-2.

14. Pour Région, sélectionnez la même région que celle sélectionnée pour le sous-réseau précédent.

15. Dans Plage IPv4, saisissez 172.16.4.0/22.

16. Cliquez sur Créer une plage IPv4 secondaire. Dans Nom de la plage du sous-réseau, saisissez tier-2-services, et dans Plage d'adresses IPv4 secondaire, saisissez 172.16.16.0/20.

17. Cliquez sur Ajouter une plage d'adresses IP. Dans Nom de la plage du sous-réseau, saisissez tier-2-pods, et dans Plage d'adresses IPv4 secondaire, saisissez 172.20.0.0/14.

18. Cliquez sur Créer.

gcloud

Dans votre projet hôte, créez un réseau nommé shared-net :

gcloud compute networks create shared-net \
    --subnet-mode custom \
    --project HOST_PROJECT_ID

Dans votre nouveau réseau, créez un sous-réseau nommé tier-1 :

gcloud compute networks subnets create tier-1 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 10.0.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-1-services=10.0.32.0/20,tier-1-pods=10.4.0.0/14

Créez un autre sous-réseau nommé tier-2 :

gcloud compute networks subnets create tier-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --range 172.16.4.0/22 \
    --region COMPUTE_REGION \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

Remplacez COMPUTE_REGION par une région Compute Engine.

Déterminer les noms des comptes de service dans vos projets de service

Vous travaillez avec deux projets de service, chacun d'eux possédant plusieurs comptes de service. Cette section concerne vos comptes de service GKE et vos comptes de service des API Google. Vous avez besoin des noms de ces comptes de service pour la section suivante.

Le tableau suivant répertorie les noms des comptes de service GKE et des API Google dans vos deux projets de service :

Type de compte de service	Nom du compte de service
GKE	[e-mail]
	[e-mail]
API Google	[e-mail]
	[e-mail]

Activer le VPC partagé et attribuer des rôles

Pour effectuer les tâches de cette section, assurez-vous que votre organisation a défini un rôle d'administrateur de VPC partagé.

Dans cette section, vous allez effectuer les tâches suivantes :

1. Dans votre projet hôte, activez le VPC partagé.
2. Associez vos deux projets de service au projet hôte.
3. Attribuez les rôles IAM appropriés aux comptes de service appartenant à vos projets de service :
   • Dans votre premier projet de service, attribuez à deux comptes de service le rôle Compute Network User sur le sous-réseau tier-1 de votre projet hôte.
   • Dans votre deuxième projet de service, attribuez à deux comptes de service le rôle Compute Network User sur le sous-réseau tier-2 de votre projet hôte.

Console

Procédez comme suit pour activer le VPC partagé, associer des projets de service et attribuer des rôles :

1. Accédez à la page VPC partagé de la console Google Cloud .

   Accéder à la page "VPC partagé"

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Cliquez sur Configurer un VPC partagé. L'écran Activer le projet hôte s'affiche.

4. Cliquez sur Enregistrer et continuer. La page Sélectionner des sous-réseaux s'affiche.

5. Sous Mode de partage, sélectionnez Sous-réseaux individuels.

6. Sous Sous-réseaux à partager, cochez les éléments tier-1 et tier-2. Décochez toutes les autres cases.

7. Cliquez sur Continuer. La page Autoriser s'affiche.

8. Sous Associer les projets de service, cochez votre premier et votre deuxième projets de service. Décochez toutes les autres cases sous Associer les projets de service.

9. Sous Accès à Kubernetes Engine, cochez la case Activé.

10. Cliquez sur Enregistrer. Une nouvelle page s'affiche.

11. Sous Autorisations sur les sous-réseaux individuels, cochez tier-1.

12. Dans le volet de droite, supprimez tous les comptes de service appartenant à votre deuxième projet de service. Autrement dit, supprimez tous les comptes de service dont le nom contient SERVICE_PROJECT_2_NUM.

13. Dans le volet de droite, recherchez les noms des comptes de service GKE et des API Google appartenant à votre premier projet de service. Ces deux noms de compte de service doivent apparaître dans la liste. Si l'un de ces éléments manque, saisissez le nom du compte de service sous Ajouter des membres puis cliquez sur Ajouter.

14. Dans le volet central, sous Autorisations sur les sous-réseaux individuels, cochez le sous-réseau tier-2 et décochez tier-1.

15. Dans le volet de droite, supprimez tous les comptes de service appartenant à votre premier projet de service. Autrement dit, supprimez tous les comptes de service dont le nom contient SERVICE_PROJECT_1_NUM.

16. Dans le volet de droite, recherchez les noms des comptes de service GKE et des API Google appartenant à votre deuxième projet de service. Ces deux noms de compte de service doivent apparaître dans la liste. Si l'un de ces éléments manque, saisissez le nom du compte de service sous Ajouter des membres, puis cliquez sur Ajouter.

gcloud

1. Activez le VPC partagé dans votre projet hôte. La commande que vous utilisez dépend du rôle d'administration requis dont vous disposez.

   Si vous avez le rôle d'Administrateur de VPC partagé au niveau de l'organisation :

   gcloud compute shared-vpc enable HOST_PROJECT_ID
   

   Si vous avez le rôle d'administrateur de VPC partagé au niveau du dossier :

   gcloud beta compute shared-vpc enable HOST_PROJECT_ID
   

2. Associez votre premier projet de service à votre projet hôte :

   gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_1_ID \
       --host-project HOST_PROJECT_ID
   

3. Associez votre deuxième projet de service à votre projet hôte :

   gcloud compute shared-vpc associated-projects add SERVICE_PROJECT_2_ID \
       --host-project HOST_PROJECT_ID
   

4. Obtenez la stratégie IAM pour le sous-réseau tier-1 :

   gcloud compute networks subnets get-iam-policy tier-1 \
      --project HOST_PROJECT_ID \
      --region COMPUTE_REGION
   

   Le résultat contient un champ etag. Notez la valeur etag.

5. Créez un fichier nommé tier-1-policy.yaml ayant le contenu suivant :

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Remplacez ETAG_STRING par la valeur etag que vous avez notée précédemment.

6. Définissez la stratégie IAM pour le sous-réseau tier-1 :

   gcloud compute networks subnets set-iam-policy tier-1 \
       tier-1-policy.yaml \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

7. Obtenez la stratégie IAM pour le sous-réseau tier-2 :

   gcloud compute networks subnets get-iam-policy tier-2 \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

   Le résultat contient un champ etag. Notez la valeur etag.

8. Créez un fichier nommé tier-2-policy.yaml ayant le contenu suivant :

   bindings:
   - members:
     - serviceAccount:[e-mail]
     - serviceAccount:[e-mail]
     role: roles/compute.networkUser
   etag: ETAG_STRING
   

   Remplacez ETAG_STRING par la valeur etag que vous avez notée précédemment.

9. Définissez la stratégie IAM pour le sous-réseau tier-2 :

   gcloud compute networks subnets set-iam-policy tier-2 \
       tier-2-policy.yaml \
       --project HOST_PROJECT_ID \
       --region COMPUTE_REGION
   

Gérer les ressources de pare-feu

Si vous souhaitez qu'un cluster GKE dans un projet de service crée et gère les ressources de pare-feu de votre projet hôte, le compte de service GKE du projet de service doit disposer des autorisations IAM appropriées en utilisant l'une des stratégies suivantes :

Remarque: Pour suivre les bonnes pratiques de sécurité, choisissez une approche plus précise. Attribuer au compte de service GKE du projet de service le rôle d'administrateur de sécurité Compute lui accordera plus d'autorisations IAM que sont nécessaire pour les besoins de ce guide.

• Accordez au compte de service GKE du projet de service le rôle Compute Security Admin pour le projet hôte.

Console

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Sélectionnez le projet hôte.

3. Cliquez sur Accorder l'accès, puis saisissez le compte compte principal du projet de service, c'est-à-dire le compte de service GKE, [e-mail].

4. Sélectionnez le rôle Compute Security Admin dans la liste déroulante.

5. Cliquez sur Enregistrer.

gcloud

Accordez au compte de service GKE du projet de service le rôle Compute Security Admin pour le projet hôte.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
    --member=serviceAccount:[e-mail] \
    --role=roles/compute.securityAdmin

Remplacez les éléments suivants :

• HOST_PROJECT_ID: ID du projet hôte de VPC partagé
• SERVICE_PROJECT_NUM: ID du projet de service contenant le compte de service GKE

• Pour une approche plus précise,créez un rôle IAM personnalisé qui n'inclut que les autorisations suivantes : compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update etcompute.firewalls.delete. Accordez au compte de service GKE du projet de service ce rôle personnalisé pour le projet hôte.

Console

Créez un rôle personnalisé dans le projet hôte contenant les autorisations IAM mentionnées précédemment:

1. Dans la console Google Cloud , accédez à la page Rôles.

   Accéder à la page Rôles

2. Dans la liste déroulante située en haut de la page, sélectionnez le projet hôte.

3. Cliquez sur Créer un rôle.

4. Saisissez un titre, une description, un ID et une étape de lancement du rôle. Une fois le rôle créé, vous ne pouvez plus modifier son nom.

5. Cliquez sur Ajouter des autorisations.

6. Filtrez sur compute.networks et sélectionnez les autorisations IAM mentionnées ci-dessus.

7. Une fois toutes les autorisations requises sélectionnées, cliquez sur Ajouter.

8. Cliquez sur Créer.

Accordez au compte de service GKE du projet de service le rôle personnalisé nouvellement créé dans le projet hôte:

1. Dans la console Google Cloud , accédez à la page IAM.

   Accéder à IAM

2. Sélectionnez le projet hôte.

3. Cliquez sur Accorder l'accès, puis saisissez le compte de service GKE du projet de service principal, [e-mail].

4. Filtrez le champ Title (Titre) du rôle personnalisé nouvellement créé et sélectionnez-le.

5. Cliquez sur Enregistrer.

gcloud

1. Créez un rôle personnalisé dans le projet hôte contenant les autorisations IAM mentionnées précédemment :

   gcloud iam roles create ROLE_ID \
       --title="ROLE_TITLE" \
       --description="ROLE_DESCRIPTION" \
       --stage=LAUNCH_STAGE \
       --permissions=compute.networks.updatePolicy,compute.firewalls.list,compute.firewalls.get,compute.firewalls.create,compute.firewalls.update,compute.firewalls.delete \
       --project=HOST_PROJECT_ID
   

2. Accordez au compte de service GKE du projet de service le rôle personnalisé nouvellement créé dans le projet hôte:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
   

   Remplacez les éléments suivants :

   • ROLE_ID : nom du rôle, tel que gkeFirewallAdmin.
   • ROLE_TITLE est un titre convivial pour le rôle, par exemple GKE Firewall Admin.
   • ROLE_DESCRIPTION est une brève description du rôle, par exemple GKE service account FW permissions.
   • LAUNCH_STAGE: étape de lancement du rôle dans son cycle de vie, telle que ALPHA, BETA ou GA
   • HOST_PROJECT_ID: ID du projet hôte de VPC partagé
   • SERVICE_PROJECT_NUM: ID du projet de service contenant le compte de service GKE

Si vous disposez de clusters dans plusieurs projets de service, vous devez choisir l'une des stratégies et la répéter pour le compte de service GKE de chaque projet de service.

Remarque : Si vous utilisez Ingress pour les équilibreurs de charge d'application internes, le contrôleur d'Ingress ne crée pas de règle de pare-feu pour autoriser les connexions à partir des proxys d'équilibreur de charge dans le sous-réseau proxy. Vous devez créer cette règle de pare-feu manuellement. Cependant, le contrôleur Ingress crée des règles de pare-feu pour autoriser les vérifications de l'état d'Ingress via Google Cloud .

Récapitulatif des rôles attribués dans les sous-réseaux

Voici un récapitulatif des rôles attribués sur les sous-réseaux :

Compte de service	Rôle	Sous-réseau
[e-mail]	Utilisateur de réseau Compute	tier-1
[e-mail]	Utilisateur de réseau Compute	tier-1
[e-mail]	Utilisateur de réseau Compute	tier-2
[e-mail]	Utilisateur de réseau Compute	Niveau 2

Vérifier l'accès à GKE

Lorsque vous associez un projet de service, l'activation de l'accès à GKE attribue au compte de service GKE du projet de service les autorisations nécessaires pour effectuer des opérations de gestion du réseau dans le projet hôte.

GKE attribue automatiquement le rôle suivant dans le projet hôte lorsque vous activez l'accès à GKE :

Membre	Rôle	Ressource
[e-mail]	Utilisateur de l'agent de service hôte	Compte de service GKE dans le projet hôte

Toutefois, vous devez ajouter manuellement l'autorisation IAM Compute Network User au compte de service GKE du projet de service pour accéder au réseau hôte.

Membre	Rôle	Ressource
[e-mail]	Utilisateur de réseau Compute	Sous-réseau spécifique ou ensemble du projet hôte

Si un projet de service a été associé sans que l'accès à GKE ait été activé, en supposant que l'API GKE ait déjà été activée dans le projet hôte et le projet de service, vous pouvez attribuer manuellement les autorisations au compte de service GKE du projet de service en ajoutant les liaisons de rôle IAM suivantes dans le projet hôte :

Membre	Rôle	Ressource
[e-mail]	Utilisateur de réseau Compute	Sous-réseau spécifique ou ensemble du projet hôte
[e-mail]	Utilisateur de l'agent de service hôte	Compte de service GKE dans le projet hôte

Attribuer le rôle Utilisateur de l'agent de service hôte

Le compte de service GKE de chaque projet de service doit comporter une liaison pour le rôle Utilisateur de l'agent de service hôte dans le projet hôte. Le compte de service GKE se présente sous la forme suivante :

[e-mail]

où SERVICE_PROJECT_NUM est le numéro de votre projet de service.

Cette liaison permet au compte de service GKE du projet de service d'effectuer des opérations de gestion du réseau dans le projet hôte, comme s'il s'agissait du compte de service GKE du projet hôte. Ce rôle ne peut être attribué qu'au compte de service GKE d'un projet de service.

Console

Si vous avez utilisé la console Google Cloud , vous n'avez pas à attribuer explicitement le rôle d'utilisateur de l'agent de service hôte. Cela s'est fait automatiquement lorsque vous avez utilisé la console Google Cloud pour associer des projets de service à votre projet hôte.

gcloud

1. Pour votre premier projet, attribuez le rôle d'utilisateur de l'agent de service hôte au compte de service GKE du projet. Ce rôle est attribué dans votre projet hôte :

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Pour votre deuxième projet, attribuez le rôle d'utilisateur de l'agent de service hôte au compte de service GKE du projet. Ce rôle est attribué dans votre projet hôte :

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Vérifier les sous-réseaux utilisables et les plages d'adresses IP secondaires

Lorsque vous créez un cluster, vous devez spécifier un sous-réseau ainsi que les plages d'adresses IP secondaires à utiliser pour les pods et les services du cluster. Une plage d'adresses IP peut être indisponible pour diverses raisons. Que vous utilisiez la console Google Cloud ou gcloud CLI pour créer le cluster, vous devez spécifier des plages d'adresses IP utilisables.

Une plage d'adresses IP est utilisable pour les services du nouveau cluster si elle n'est pas déjà utilisée. La plage d'adresses IP que vous spécifiez pour les pods du nouveau cluster peut être soit une plage inutilisée, soit une plage partagée avec les pods de vos autres clusters. Les plages d'adresses IP créées et gérées par GKE ne peuvent pas être utilisées par votre cluster.

Vous pouvez répertorier les sous-réseaux et plages d'adresses IP secondaires utilisables d'un projet à l'aide de gcloud CLI.

gcloud

gcloud container subnets list-usable \
    --project SERVICE_PROJECT_ID \
    --network-project HOST_PROJECT_ID

Remplacez SERVICE_PROJECT_ID par l'ID du projet de service.

Si vous omettez les options --project et --network-project, la commande gcloud CLI se sert du projet par défaut de votre configuration active. Du fait que le projet hôte et le projet réseau sont distincts, vous devez spécifier l'une ou les deux options --project et --network-project.

Le résultat ressemble à ce qui suit :

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-2
RANGE: 172.16.4.0/22

SECONDARY_RANGE_NAME: tier-2-services
IP_CIDR_RANGE: 172.20.0.0/14
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-2-pods
IP_CIDR_RANGE: 172.16.16.0/20
STATUS: usable for pods or services

PROJECT: xpn-host
REGION: REGION_NAME
NETWORK: shared-net
SUBNET: tier-1
RANGE: 10.0.4.0/22

SECONDARY_RANGE_NAME: tier-1-services
IP_CIDR_RANGE: 10.0.32.0/20
STATUS: usable for pods or services

SECONDARY_RANGE_NAME: tier-1-pods
IP_CIDR_RANGE: 10.4.0.0/14
STATUS: usable for pods or services

La commande list-usable renvoie une liste vide dans les situations suivantes :

• Lorsque le compte de service GKE du projet de service n'a pas le rôle d'utilisateur de l'agent de service hôte pour le projet hôte
• Lorsque le compte de service GKE du projet hôte n'existe pas (par exemple, si vous avez supprimé ce compte accidentellement).
• Lorsque l'API GKE n'est pas activée dans le projet hôte, cela implique que le compte de service GKE dans le projet hôte est manquant.

Pour en savoir plus, consultez la section Dépannage.

Limites des plages d'adresses IP secondaires

Vous pouvez créer 30 plages secondaires au sein d'un sous-réseau donné. Pour chaque cluster, vous avez besoin de deux plages secondaires : une pour les pods et une pour les services.

Remarque : La plage principale et la plage secondaire dédiée aux pods peuvent être partagées entre les clusters, mais cette configuration n'est pas recommandée.

Créer un cluster dans votre premier projet de service

Pour créer un cluster dans votre premier projet de service, procédez comme suit à l'aide de gcloud CLI ou de la console Google Cloud .

Console

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

   Accéder à Google Kubernetes Engine

2. Dans le sélecteur de projet, choisissez votre premier projet de service.

3. Cliquez sur Créer.

4. Dans la section "Autopilot" ou "Standard", cliquez sur Configurer.

5. Dans le champ Nom, saisissez tier-1-cluster.

6. Dans la liste déroulante Région, sélectionnez la même région que celle utilisée pour les sous-réseaux.

7. Dans le volet de navigation, cliquez sur Mise en réseau.

8. Sous Mise en réseau du cluster, sélectionnez shared-net.

9. Pour le Sous-réseau de nœud, sélectionnez tier-1.

10. Sous Options de mise en réseau avancées, sélectionnez tier-1-pods pour Plage d'adresses par défaut des pods dans le cluster.

11. Pour la Plage d'adresses des services, sélectionnez tier-1-services.

12. Cliquez sur Créer.

13. Une fois la création terminée, dans la liste des clusters, cliquez sur tier-1-cluster.

14. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

15. Sous Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez inspecter.

16. Sous Groupes d'instances, cliquez sur le nom du groupe d'instances que vous souhaitez inspecter. Par exemple : gke-tier-1-cluster-default-pool-5c5add1f-grp.

17. Dans la liste des instances, vérifiez que les adresses IP internes de vos nœuds se trouvent bien dans la plage principale du sous-réseau tier-1 : 10.0.4.0/22.

gcloud

Créez un cluster nommé tier-1-cluster dans votre premier projet de service :

gcloud container clusters create-auto tier-1-cluster \
    --project=SERVICE_PROJECT_1_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-1 \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services

Remplacez CONTROL_PLANE_LOCATION par la région Compute Engine du plan de contrôle de votre cluster.

Une fois la création terminée, vérifiez que les nœuds de votre cluster se trouvent bien dans la plage principale du sous-réseau tier-1 : 10.0.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_1_ID

Le résultat de cette commande affiche les adresses IP internes des nœuds :

NAME                    ZONE           ... INTERNAL_IP
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.2
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.3
gke-tier-1-cluster-...  ZONE_NAME      ... 10.0.4.4

Créer un cluster dans votre deuxième projet de service

Pour créer un cluster dans votre deuxième projet de service, procédez comme suit à l'aide de gcloud CLI ou de la console Google Cloud .

Console

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

   Accéder à Google Kubernetes Engine

2. Dans le sélecteur de projet, choisissez votre deuxième projet de service.

3. Cliquez sur Créer.

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

5. Dans le champ Nom, saisissez tier-2-cluster.

6. Dans la liste déroulante Région, sélectionnez la même région que celle utilisée pour les sous-réseaux.

7. Dans le volet de navigation, cliquez sur Mise en réseau.

8. Pour le Réseau, sélectionnez shared-net.

9. Pour le Sous-réseau de nœud, sélectionnez tier-2.

10. Pour la Plage d'adresses par défaut des pods dans le cluster, sélectionnez tier-2-pods.

11. Pour la Plage d'adresses du service, sélectionnez tier-2-services.

12. Cliquez sur Créer.

13. Une fois la création terminée, dans la liste des clusters, cliquez sur tier-2-cluster.

14. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

15. Sous Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez inspecter.

16. Sous Groupes d'instances, cliquez sur le nom du groupe d'instances que vous souhaitez inspecter. Par exemple, gke-tier-2-cluster-default-pool-5c5add1f-grp.

17. Dans la liste des instances, vérifiez que les adresses IP internes de vos nœuds se trouvent bien dans la plage principale du sous-réseau tier-2 : 172.16.4.0/22.

gcloud

Créez un cluster nommé tier-2-cluster dans votre deuxième projet de service :

gcloud container clusters create-auto tier-2-cluster \
    --project=SERVICE_PROJECT_2_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/tier-2 \
    --cluster-secondary-range-name=tier-2-pods \
    --services-secondary-range-name=tier-2-services

Une fois la création terminée, vérifiez que les nœuds de votre cluster se trouvent bien dans la plage principale du sous-réseau tier-2 : 172.16.4.0/22.

gcloud compute instances list --project SERVICE_PROJECT_2_ID

Le résultat de cette commande affiche les adresses IP internes des nœuds :

NAME                    ZONE           ... INTERNAL_IP
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.2
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.3
gke-tier-2-cluster-...  ZONE_NAME      ... 172.16.4.4

Remarque : Lors des mises à niveau des clusters GKE, GKE ajoute automatiquement des entrées de métadonnées au niveau du projet, telles que google_compute_project_metadata, pour suivre l'utilisation de la plage d'adresses IP secondaires. Pour obtenir des informations et des conseils sur la gestion de ces métadonnées avec des outils Infrastructure as Code (IaC), consultez Métadonnées de projet pour les plages d'adresses IP secondaires.

Créer des règles de pare-feu

Pour autoriser le trafic dans le réseau et entre les clusters du réseau, vous devez créer des règles de pare-feu. Les sections suivantes expliquent comment créer et mettre à jour des règles de pare-feu :

• Créer une règle de pare-feu pour autoriser la connexion SSH à un nœud : montre comment créer une règle de pare-feu qui active le trafic en dehors des clusters à l'aide de SSH.

• Mettre à jour la règle de pare-feu pour envoyer une requête ping entre les nœuds : montre comment mettre à jour la règle de pare-feu pour autoriser le trafic ICMP entre les clusters.

  Le trafic SSH et ICMP est utilisé comme exemple. Vous devez créer des règles de pare-feu qui répondent aux exigences de mise en réseau de votre application spécifique.

Remarque : Les administrateurs de VPC partagé sont chargés de créer des règles de pare-feu dans le réseau VPC partagé.

Créer une règle de pare-feu pour autoriser la connexion SSH à un nœud

Dans votre projet hôte, créez une règle de pare-feu pour le réseau shared-net. Autorisez le trafic à entrer sur le port TCP 22, ce qui vous permet de vous connecter à vos nœuds de cluster à l'aide de SSH.

Console

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

   Accéder à la page "Pare-feu"

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Dans le menu Réseau VPC, cliquez sur Créer une règle de pare-feu.

4. Dans le champ Nom, saisissez my-shared-net-rule.

5. Pour le Réseau, sélectionnez shared-net.

6. Pour le Sens du trafic, sélectionnez Entrée.

7. Pour l'option Action en cas de correspondance, sélectionnez Autoriser.

8. Pour les Cibles, sélectionnez Toutes les instances du réseau.

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

10. Dans le champ Plages d'adresses IP sources, saisissez 0.0.0.0/0.

11. Dans Protocoles et ports, sélectionnez Protocoles et ports spécifiés. Dans la zone de texte, saisissez tcp:22.

12. Cliquez sur Créer.

gcloud

Créez une règle de pare-feu pour votre réseau partagé :

gcloud compute firewall-rules create my-shared-net-rule \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --direction INGRESS \
    --allow tcp:22

Se connecter à un nœud à l'aide de SSH

Après avoir créé la règle de pare-feu autorisant le trafic entrant sur le port TCP 22, connectez-vous au nœud à l'aide de SSH.

Console

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

   Accéder à Google Kubernetes Engine

2. Dans le sélecteur de projet, choisissez votre premier projet de service.

3. Cliquez sur tier-1-cluster.

4. Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.

5. Sous Pools de nœuds, cliquez sur le nom de votre pool de nœuds.

6. Sous Groupes d'instances, cliquez sur le nom de votre groupe d'instances. Exemple : gke-tier-1-cluster-default-pool-faf87d48-grp.

7. Dans la liste des instances, notez les adresses IP internes des nœuds. Ces adresses se situent dans la plage 10.0.4.0/22.

8. Pour l'un de vos nœuds, cliquez sur SSH. Cette opération réussit car SSH utilise le port TCP 22, autorisé par votre règle de pare-feu.

gcloud

Répertoriez les nœuds de votre premier projet de service :

gcloud compute instances list --project SERVICE_PROJECT_1_ID

Le résultat de la commande inclut les noms des nœuds de votre cluster :

NAME                                           ...
gke-tier-1-cluster-default-pool-faf87d48-3mf8  ...
gke-tier-1-cluster-default-pool-faf87d48-q17k  ...
gke-tier-1-cluster-default-pool-faf87d48-x9rk  ...

Connectez-vous à l'un de vos nœuds à l'aide de SSH:

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone COMPUTE_ZONE

Remplacez les éléments suivants :

• NODE_NAME: nom de l'un de vos nœuds.
• COMPUTE_ZONE: nom d'une zone Compute Engine dans la région.

Mettre à jour la règle de pare-feu pour autoriser le trafic entre les nœuds

1. Dans votre fenêtre de ligne de commande SSH, démarrez CoreOS Toolbox :

   /usr/bin/toolbox
   

2. Dans l'interface système de la boîte à outils, envoyez une requête ping à l'un des autres nœuds du même cluster. Exemple :

   ping 10.0.4.4
   

   La commande ping réussit, car votre nœud et l'autre nœud sont tous deux situés dans la plage 10.0.4.0/22.

3. Essayez maintenant d'envoyer une requête ping à l'un des nœuds du cluster hébergé dans votre autre projet de service. Exemple :

   ping 172.16.4.3
   

   Cette fois, la commande ping échoue car votre règle de pare-feu n'autorise pas le trafic ICMP (Internet Control Message Protocol).

4. À une invite de commande ordinaire (pas l'interface système de la boîte à outils), mettez à jour votre règle de pare-feu pour autoriser ICMP :

   gcloud compute firewall-rules update my-shared-net-rule \
       --project HOST_PROJECT_ID \
       --allow tcp:22,icmp
   

5. Dans l'interface système de la boîte à outils, envoyez une nouvelle requête ping au nœud cible. Exemple :

   ping 172.16.4.3
   

   Cette fois, la commande ping réussit.

Créer des règles de pare-feu supplémentaires

Vous pouvez créer des règles de pare-feu supplémentaires pour autoriser la communication entre les nœuds, les pods et les services de vos clusters.

Ainsi, la règle suivante autorise le trafic à entrer dans tier-1-cluster à partir de n'importe quel nœud, pod ou service, sur tout port TCP ou UDP :

gcloud compute firewall-rules create my-shared-net-rule-2 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 10.0.4.0/22,10.4.0.0/14,10.0.32.0/20

La règle suivante autorise le trafic à entrer dans tier-2-cluster depuis n'importe quel nœud, pod ou service, sur tout port TCP ou UDP.

gcloud compute firewall-rules create my-shared-net-rule-3 \
    --project HOST_PROJECT_ID \
    --network shared-net \
    --allow tcp,udp \
    --direction INGRESS \
    --source-ranges 172.16.4.0/22,172.20.0.0/14,172.16.16.0/20

Kubernetes tentera également de créer et de gérer des ressources de pare-feu lorsque c'est nécessaire, par exemple lorsque vous créez un service d'équilibrage de charge. Si Kubernetes se trouve dans l'impossibilité de modifier les règles du pare-feu en raison d'un problème d'autorisation, un événement Kubernetes sera déclenché pour vous guider dans la procédure à suivre pour apporter les modifications.

Si vous souhaitez autoriser Kubernetes à modifier les règles de pare-feu, consultez la section Gérer les ressources de pare-feu.

Pour les équilibreurs de charge d'entrée, si Kubernetes ne peut pas modifier les règles du pare-feu en raison d'autorisations insuffisantes, un événement firewallXPNError est diffusé régulièrement (avec un délai de quelques minutes entre les diffusions). Dans GLBC 1.4 et ses versions ultérieures, vous pouvez désactiver l'événement firewallXPNError en ajoutant l'annotation networking.gke.io/suppress-firewall-xpn-error: "true" à la ressource d'entrée. Vous pouvez toujours supprimer cette annotation pour réactiver l'événement.

Créer un cluster basé sur l'appairage de réseaux VPC dans un VPC partagé

Vous pouvez utiliser le VPC partagé avec des clusters basés sur l'appairage de réseaux VPC.

Vous devez pour cela accorder les autorisations suivantes sur le projet hôte au compte utilisateur ou au compte de service utilisé pour créer le cluster :

• compute.networks.get

• compute.networks.updatePeering

Vous devez également vous assurer que la plage d'adresses IP du plan de contrôle ne chevauche pas les autres plages réservées du réseau partagé.

Dans cette section, vous créez un cluster de VPC natif nommé cluster-vpc dans un réseau VPC partagé prédéfini.

Console

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

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

4. Dans le champ Nom, saisissez cluster-vpc.

5. Dans le volet de navigation, cliquez sur Mise en réseau.

6. Sélectionner Cluster privé.

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

8. Dans la liste déroulante Réseau, sélectionnez le réseau VPC que vous avez créé précédemment.

9. Dans la liste déroulante Sous-réseau de nœud, sélectionnez le sous-réseau partagé que vous avez créé précédemment.

10. Configurez le cluster selon vos besoins.

11. Cliquez sur Créer.

gcloud

Exécutez la commande suivante pour créer un cluster nommé cluster-vpc dans un VPC partagé prédéfini :

gcloud container clusters create-auto private-cluster-vpc \
    --project=PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --network=projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork=SHARED_SUBNETWORK \
    --cluster-secondary-range-name=tier-1-pods \
    --services-secondary-range-name=tier-1-services \
    --enable-private-nodes \
    --master-ipv4-cidr=172.16.0.0/28

Réserver des adresses IP

Vous pouvez réserver les adresses IP internes et externes de vos clusters de VPC partagés. Assurez-vous que les adresses IP sont réservées dans le projet de service.

Pour les adresses IP internes, vous devez fournir le sous-réseau auquel l'adresse IP appartient. Pour réserver une adresse IP pour plusieurs projets, utilisez l'URL complète de la ressource afin d'identifier le sous-réseau.

Pour réserver une adresse IP interne, utilisez la commande suivante dans la Google Cloud CLI :

gcloud compute addresses create RESERVED_IP_NAME \
    --region=COMPUTE_REGION \
    --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNETWORK_NAME \
    --addresses=IP_ADDRESS \
    --project=SERVICE_PROJECT_ID

Pour appeler cette commande, vous devez ajouter l'autorisation compute.subnetworks.use au sous-réseau. Vous pouvez attribuer à l'appelant un rôle compute.networkUser sur le sous-réseau ou lui attribuer un rôle personnalisé avec l'autorisation compute.subnetworks.use au niveau du projet.

Effectuer un nettoyage

Après avoir suivi les exercices de ce guide, effectuez les tâches suivantes pour supprimer les ressources afin d'éviter que des frais inutiles ne vous soient facturés :

Supprimer les clusters

Supprimez les deux clusters que vous avez créés.

Console

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

   Accéder à Google Kubernetes Engine

2. Dans le sélecteur de projet, choisissez votre premier projet de service.

3. Sélectionnez tier-1-cluster, puis cliquez sur Supprimer.

4. Dans le sélecteur de projet, choisissez votre deuxième projet de service.

5. Sélectionnez tier-2-cluster, puis cliquez sur Supprimer.

gcloud

gcloud container clusters delete tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --location CONTROL_PLANE_LOCATION

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --location CONTROL_PLANE_LOCATION

Désactiver le VPC partagé

Désactivez le VPC partagé dans votre projet hôte.

Console

1. Accédez à la page VPC partagé de la console Google Cloud .

   Accéder à la page "VPC partagé"

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Cliquez sur Désactiver le VPC partagé.

4. Saisissez l'identifiant de votre projet hôte HOST_PROJECT_ID dans le champ, puis cliquez sur Désactiver.

gcloud

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_1_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc associated-projects remove SERVICE_PROJECT_2_ID \
    --host-project HOST_PROJECT_ID

gcloud compute shared-vpc disable HOST_PROJECT_ID

Supprimer vos règles de pare-feu

Supprimez les règles de pare-feu que vous avez créées.

Console

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

   Accéder à la page "Pare-feu"

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Dans la liste des règles, sélectionnez les règles suivantes : my-shared-net-rule, my-shared-net-rule-2 et my-shared-net-rule-3.

4. Cliquez sur Supprimer.

gcloud

Supprimez vos règles de pare-feu :

gcloud compute firewall-rules delete \
    my-shared-net-rule \
    my-shared-net-rule-2 \
    my-shared-net-rule-3 \
    --project HOST_PROJECT_ID

Supprimer le réseau partagé

Supprimez le réseau partagé que vous avez créé.

Console

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

   Accéder aux réseaux VPC

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Dans la liste des réseaux, sélectionnez shared-net.

4. Cliquez sur Supprimer le réseau VPC.

gcloud

gcloud compute networks subnets delete tier-1 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks subnets delete tier-2 \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Retirer le rôle Utilisateur de l'agent de service hôte

Retirez les rôles d'utilisateur de l'agent de service hôte de vos deux projets de service.

Console

1. Accédez à la page IAM de la console Google Cloud .

   Accéder à IAM

2. Dans le sélecteur de projet, choisissez votre projet hôte.

3. Dans la liste des membres, sélectionnez la ligne qui indique que [e-mail] est assorti du rôle d'utilisateur de l'agent de service hôte Kubernetes Engine.

4. Sélectionnez la ligne qui indique que [e-mail] est assorti du rôle d'utilisateur de l'agent de service hôte Kubernetes Engine.

5. Cliquez sur Supprimer l'accès.

gcloud

1. Retirez le rôle d'utilisateur de l'agent de service hôte du compte de service GKE de votre premier projet de service :

   gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

2. Retirez le rôle d'utilisateur de l'agent de service hôte du compte de service GKE de votre deuxième projet de service :

   gcloud projects remove-iam-policy-binding HOST_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/container.hostServiceAgentUser
   

Dépannage

Les sections suivantes vous aident à résoudre les problèmes courants liés aux clusters VPC partagés.

Erreur : échec de la récupération des métadonnées du projet de réseau

Le message suivant est une erreur courante lorsque vous utilisez des clusters VPC partagés :

Failed to get metadata from network project. GCE_PERMISSION_DENIED: Google
Compute Engine: Required 'compute.projects.get' permission for
'projects/HOST_PROJECT_ID

Ce problème peut survenir pour les raisons suivantes :

• L'API GKE n'a pas été activée dans le projet hôte.

• Le compte de service GKE du projet hôte n'existe pas. Il peut par exemple avoir été supprimé.

• Le compte de service GKE du projet hôte ne dispose pas du rôle Agent de service Kubernetes Engine (container.serviceAgent) dans le projet hôte. La liaison a peut-être été supprimée par inadvertance.

• Le compte de service GKE du projet de service ne dispose pas du rôle d'utilisateur de l'agent de service hôte dans le projet hôte.

Pour résoudre le problème, vérifiez si le compte de service GKE du projet hôte existe.

Si le compte de service n'existe pas, procédez comme suit :

• Si l'API GKE n'est pas activée dans le projet hôte, activez-la. Cela a pour effet de créer le compte de service GKE du projet hôte et de lui attribuer le rôle d'Agent de service Kubernetes Engine (container.serviceAgent) dans le projet hôte.

• Si l'API GKE est activée dans le projet hôte, cela signifie que le compte de service GKE du projet hôte a été supprimé ou qu'il ne dispose pas du rôle d'Agent de service Kubernetes Engine (container.serviceAgent) dans le projet hôte. Pour restaurer le compte de service GKE ou la liaison de rôle, vous devez désactiver puis réactiver l'API GKE. Pour en savoir plus, consultez Erreur 400/403 : le compte n'est pas autorisé à apporter des modifications.

  Remarque : La désactivation suivie de la réactivation de l'API GKE dans le projet hôte n'affecte pas le fonctionnement des clusters existants des projets de service. Toutefois, vous ne pouvez pas créer de clusters utilisant un réseau VPC partagé (dans un projet de service ou dans le projet hôte) alors que l'API GKE est désactivée.

Problème : connectivité

Si vous rencontrez des problèmes de connectivité entre des VM Compute Engine qui se trouvent dans le même réseau cloud privé virtuel (VPC) ou deux réseaux VPC connectés à l'aide de l'appairage de réseaux VPC, consultez la section Dépannage de la connectivité entre les instances de machines virtuelles (VM) avec des adresses IP internes dans la documentation sur le réseau cloud privé virtuel (VPC).

Problème : perte de paquets

Si vous rencontrez des problèmes de perte de paquets lors de l'envoi de trafic depuis un cluster vers une adresse IP externe à l'aide de Cloud NAT, de clusters de VPC natif ou de l'agent de masquage d'adresses IP, consultez Dépannage de la perte de paquets Cloud NAT à partir d'un cluster.

Étape suivante

• Consultez la présentation du VPC partagé.
• Découvrez-en plus sur le provisionnement d'un VPC partagé.
• Lisez la présentation du réseau GKE.
• Découvrez les règles de pare-feu créées automatiquement.
• Découvrez comment résoudre les problèmes de connectivité entre des instances de machines virtuelles (VM) et des adresses IP internes.