Configurer des clusters avec un VPC partagé

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.

Présentation

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 zonaux et régionaux. Les clusters qui utilisent un VPC partagé ne peuvent pas utiliser les anciens réseaux, et les adresses IP d'alias doivent y être activées.

Vous pouvez configurer le VPC partagé lorsque vous créez un nouveau cluster. GKE ne permet pas de convertir des 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.

À propos des exemples

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é.

Les exemples de ce guide utilisent des noms et des plages d'adresses spécifiques pour illustrer les procédures générales. Si vous le souhaitez, vous pouvez modifier les noms et les plages d'adresses suivant vos besoins. Notez également que les exercices utilisent la région us-central1 et la zone us-central1-a. Si vous le souhaitez, vous pouvez adapter la région et la zone à votre cas de figure.

Avant de commencer

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

• Assurez-vous de disposer d'une organisation Google Cloud.
• Assurez-vous que votre organisation dispose de trois projets Google Cloud.
• Vous devez 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'organisation 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.

Déterminer les identifiants et numéros de vos projets

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

Console

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

   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 Cloud Console ou de l'outil de ligne de commande gcloud.

Console

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

   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 l'API Kubernetes Engine 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 Cloud Console.

   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 us-central1.

8. Dans le champ Plage d'adresses IP, saisissez 10.0.4.0/22.

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

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

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

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

13. Dans le champ Région, sélectionnez us-central1.

14. Dans le champ Plage d'adresses IP, saisissez 172.16.4.0/22.

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

16. 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 IP secondaire, saisissez 172.20.0.0/14.

17. 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 us-central1 \
    --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 us-central1 \
    --secondary-range tier-2-services=172.16.16.0/20,tier-2-pods=172.20.0.0/14

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é dans Cloud Console.

   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 de Kubernetes Engine 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 de Kubernetes Engine 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 us-central1
   

   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 us-central1
   

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 us-central1
   

   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 us-central1
   

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 Cloud Console, accédez à la page IAM.

   Accéder à IAM

2. Sélectionnez le projet hôte.

3. Cliquez sur Ajouter, puis saisissez le compte de service principal GKE du projet de service, [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 Cloud Console, 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 Create (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 Cloud Console, accédez à la page IAM.

   Accéder à IAM

2. Sélectionnez le projet hôte.

3. Cliquez sur Ajouter, puis saisissez le compte de service principal GKE du projet de service, [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 l'équilibrage de charge HTTP(S) interne, 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	Niveau 1
[e-mail]	Utilisateur de réseau Compute	Niveau 1
[e-mail]	Utilisateur de réseau Compute	Niveau 2
[e-mail]	Utilisateur de réseau Compute	Niveau 2

Accès à Kubernetes Engine

Lorsque vous associez un projet de service, l'activation de l'accès à Kubernetes Engine 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.

Si un projet de service a été associé sans activation de l'accès à Kubernetes Engine et à supposer que l'API Kubernetes Engine ait déjà été activée sur l'hôte et dans 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ôles 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 d'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é Cloud Console, 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é Cloud Console 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 Cloud Console ou l'outil de ligne de commande gcloud 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 l'outil gcloud.

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 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   REGION       NETWORK      SUBNET          RANGE
xpn-host  us-central1  empty-vpc    empty-subnet    10.0.0.0/21
xpn-host  us-east1     some-vpc     some-subnet     10.0.0.0/19
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ pods-range           │ 10.2.0.0/21   │ usable for pods or services │
    │ svc-range            │ 10.1.0.0/21   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-2          172.16.4.0/22
    ┌──────────────────────┬────────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE  │            STATUS           │
    ├──────────────────────┼────────────────┼─────────────────────────────┤
    │ tier-2-services      │ 172.16.16.0/20 │ usable for pods or services │
    │ tier-2-pods          │ 172.20.0.0/14  │ usable for pods or services │
    └──────────────────────┴────────────────┴─────────────────────────────┘
xpn-host  us-central1  shared-net   tier-1          10.0.4.0/22
    ┌──────────────────────┬───────────────┬─────────────────────────────┐
    │ SECONDARY_RANGE_NAME │ IP_CIDR_RANGE │            STATUS           │
    ├──────────────────────┼───────────────┼─────────────────────────────┤
    │ tier-1-services      │ 10.0.32.0/20  │ unusable                    │
    │ tier-1-pods          │ 10.4.0.0/14   │ usable for pods             │
    │ tier-1-extra         │ 10.8.0.0/14   │ usable for pods or services │
    └──────────────────────┴───────────────┴─────────────────────────────┘

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

• Lorsque le compte de service Kubernetes Engine 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 Kubernetes Engine du projet hôte n'existe pas (par exemple, si vous avez supprimé ce compte accidentellement).
• Lorsque l'API Kubernetes Engine n'est pas activée dans le projet hôte, cela implique que le compte de service Kubernetes Engine dans le projet hôte est manquant.

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

Notes sur les plages 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 l'outil gcloud ou de Google Cloud Console.

Console

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

   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 le champ Nom, saisissez tier-1-cluster.

5. Pour le Type d'emplacement, sélectionnez Zonal.

6. Dans la liste déroulante Zone, sélectionnez us-central1-a.

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

8. Cochez la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias).

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

10. Sélectionnez Réseaux partagés avec moi (du projet hôte).

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

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

13. Pour la Plage CIDR secondaire du pod, sélectionnez tier-1-pods.

14. Pour la Plage CIDR secondaire des services, sélectionnez tier-1-services.

15. Cliquez sur Créer.

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

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

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

19. 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.

20. 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 tier-1-cluster \
    --project SERVICE_PROJECT_1_ID \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork projects/HOST_PROJECT_ID/regions/us-central1/subnetworks/tier-1 \
    --cluster-secondary-range-name tier-1-pods \
    --services-secondary-range-name tier-1-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-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-...  us-central1-a  ... 10.0.4.2
gke-tier-1-cluster-...  us-central1-a  ... 10.0.4.3
gke-tier-1-cluster-...  us-central1-a  ... 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 l'outil gcloud ou de Google Cloud Console.

Console

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

   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 le champ Nom, saisissez tier-2-cluster.

5. Pour le Type d'emplacement, sélectionnez Zonal.

6. Dans la liste déroulante Zone, sélectionnez us-central1-a.

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

8. Cochez la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias).

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

10. Sélectionnez Réseaux partagés avec moi (du projet hôte).

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

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

13. Pour la Plage CIDR secondaire du pod, sélectionnez tier-2-pods.

14. Pour la Plage CIDR secondaire des services, sélectionnez tier-2-services.

15. Cliquez sur Créer.

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

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

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

19. 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.

20. 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 tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone=us-central1-a \
    --enable-ip-alias \
    --network projects/HOST_PROJECT_ID/global/networks/shared-net \
    --subnetwork projects/HOST_PROJECT_ID/regions/us-central1/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-...  us-central1-a  ... 172.16.4.2
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.3
gke-tier-2-cluster-...  us-central1-a  ... 172.16.4.4

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 Cloud Console.

   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 Cloud Console.

   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 avec SSH :

gcloud compute ssh NODE_NAME \
    --project SERVICE_PROJECT_1_ID \
    --zone us-central1-a \

Remplacez NODE_NAME par le nom de l'un de vos nœuds.

Mettre à jour la règle de pare-feu pour envoyer une requête ping 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 privé dans un VPC partagé

Vous pouvez utiliser le VPC partagé avec des clusters privés. Aucune configuration spéciale n'est requise. Cependant, vous devez vous assurer que la plage CIDR du plan de contrôle (maître) ne chevauche pas les autres plages réservées du réseau partagé.

Pour les clusters privés créés avant le 15 janvier 2020, le nombre maximal de clusters GKE privés utilisables par réseau VPC est limité au nombre de connexions d'appairage du réseau VPC. Les nouveaux clusters privés réutilisent les connexions d'appairage du réseau VPC, ce qui supprime cette limitation. 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.

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

Console

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur Créer.

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

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

5. Sélectionner Cluster privé.

6. Assurez-vous que la case Accéder au plan de contrôle à l'aide de son adresse IP externe est cochée.

7. Définissez le champ 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. Assurez-vous que la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias) est cochée.

11. Configurez le cluster selon vos besoins.

12. Cliquez sur Créer.

gcloud

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

gcloud container clusters create private-cluster-vpc \
    --project PROJECT_ID \
    --enable-ip-alias \
    --network projects/HOST_PROJECT/global/networks/shared-net \
    --subnetwork SHARED_SUBNETWORK \
    --cluster-secondary-range-name c0-pods \
    --services-secondary-range-name c0-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 l'outil de ligne de commande gcloud :

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.

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 Cloud Console.

   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 \
    --zone us-central1-a

gcloud container clusters delete tier-2-cluster \
    --project SERVICE_PROJECT_2_ID \
    --zone us-central1-a

Désactiver un VPC partagé

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

Console

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

   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 la zone de texte, 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 Cloud Console.

   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 Cloud Console.

   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 us-central1

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

gcloud compute networks delete shared-net --project HOST_PROJECT_ID

Retirer le rôle d'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 Cloud Console.

   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.

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

Autorisation refusée

Symptôme :

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

Motifs possibles :

• L'API Kubernetes Engine 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.

Solution : Vérifiez si le compte de service GKE du projet hôte existe. Si ce n'est pas le cas, procédez comme suit :

• Si l'API Kubernetes Engine 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 Kubernetes Engine 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 Kubernetes Engine. Pour plus d'informations, consultez la page sur le dépannage de Google Kubernetes Engine.

  Remarque : La désactivation suivie de la réactivation de l'API Kubernetes Engine 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 Kubernetes Engine est désactivée.

É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.