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 Autopilot et 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 de 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.
À 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é.
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.
- Assurez-vous de bien connaître les concepts liés aux VPC partagés, y compris les différents rôles IAM (Identity and Access Management) 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 connaître 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 |
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 gcloud CLI ou de la console Google Cloud.
Console
Accédez à la page d'accueil dans la console Google Cloud.
Dans le sélecteur de projet, choisissez le projet que vous avez désigné comme projet hôte.
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.
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
Accédez à la page API et services de la console Google Cloud.
Dans le sélecteur de projet, choisissez le projet que vous avez désigné comme projet hôte.
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.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 :
- Dans votre projet hôte, créez un réseau nommé
shared-net
. - Créez deux sous-réseaux nommés
tier-1
ettier-2
. - Pour chaque sous-réseau, créez deux plages d'adresses secondaires : une pour les services et une pour les pods.
Console
Accédez à la page Réseaux VPC de Google Cloud Console.
Dans le sélecteur de projet, choisissez votre projet hôte.
Cliquez sur add_box Créer un réseau VPC.
Dans le champ Nom, saisissez
shared-net
.Dans Mode de création du sous-réseau, sélectionnez Personnalisé.
Dans la zone Nouveau sous-réseau, saisissez la valeur
tier-1
pour le champ Nom.Dans le champ Région, sélectionnez une région.
Dans Type de pile IP, sélectionnez IPv4 (single-stack).
Dans Plage IPv4, saisissez
10.0.4.0/22
.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, saisissez10.0.32.0/20
.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, saisissez10.4.0.0/14
.Cliquez sur Ajouter un sous-réseau.
Dans le champ Nom, saisissez
tier-2
.Pour Région, sélectionnez la même région que celle sélectionnée pour le sous-réseau précédent.
Dans Plage IPv4, saisissez
172.16.4.0/22
.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, saisissez172.16.16.0/20
.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, saisissez172.20.0.0/14
.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 | service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com |
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com | |
API Google | SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com |
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com |
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 :
- Dans votre projet hôte, activez le VPC partagé.
- Associez vos deux projets de service au projet hôte.
- 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éseautier-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éseautier-2
de votre projet hôte.
- Dans votre premier projet de service, attribuez à deux comptes de service le rôle
Console
Procédez comme suit pour activer le VPC partagé, associer des projets de service et attribuer des rôles :
Accédez à la page VPC partagé de la console Google Cloud.
Dans le sélecteur de projet, choisissez votre projet hôte.
Cliquez sur Configurer un VPC partagé. L'écran Activer le projet hôte s'affiche.
Cliquez sur Enregistrer et continuer. La page Sélectionner des sous-réseaux s'affiche.
Sous Mode de partage, sélectionnez Sous-réseaux individuels.
Sous Sous-réseaux à partager, cochez les éléments tier-1 et tier-2. Décochez toutes les autres cases.
Cliquez sur Continuer. La page Autoriser s'affiche.
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.
Sous Accès à Kubernetes Engine, cochez la case Activé.
Cliquez sur Enregistrer. Une nouvelle page s'affiche.
Sous Autorisations sur les sous-réseaux individuels, cochez tier-1.
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
.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.
Dans le volet central, sous Autorisations sur les sous-réseaux individuels, cochez le sous-réseau tier-2 et décochez tier-1.
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
.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
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
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
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
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 valeuretag
.Créez un fichier nommé
tier-1-policy.yaml
ayant le contenu suivant :bindings: - members: - serviceAccount:SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com - serviceAccount:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com role: roles/compute.networkUser etag: ETAG_STRING
Remplacez
ETAG_STRING
par la valeuretag
que vous avez notée précédemment.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
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 valeuretag
.Créez un fichier nommé
tier-2-policy.yaml
ayant le contenu suivant :bindings: - members: - serviceAccount:SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com - serviceAccount:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com role: roles/compute.networkUser etag: ETAG_STRING
Remplacez
ETAG_STRING
par la valeuretag
que vous avez notée précédemment.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 :
Accordez au compte de service GKE du projet de service le rôle
Compute Security Admin
pour le projet hôte.
Console
Dans la console Google Cloud, accédez à la page IAM.
Sélectionnez le projet hôte.
Cliquez sur
Accorder l'accès, puis saisissez le compte compte principal du projet de service, c'est-à-dire le compte de service GKE,service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
.Sélectionnez le rôle
Compute Security Admin
dans la liste déroulante.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:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \
--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:
Dans la console Google Cloud, accédez à la page Rôles.
Dans la liste déroulante située en haut de la page, sélectionnez le projet hôte.
Cliquez sur Créer un rôle.
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.
Cliquez sur Ajouter des autorisations.
Filtrez sur
compute.networks
et sélectionnez les autorisations IAM mentionnées ci-dessus.Une fois toutes les autorisations requises sélectionnées, cliquez sur Ajouter.
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:
Dans la console Google Cloud, accédez à la page IAM.
Sélectionnez le projet hôte.
Cliquez sur
Accorder l'accès, puis saisissez le compte de service GKE du projet de service principal,service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
.Filtrez le champ Title (Titre) du rôle personnalisé nouvellement créé et sélectionnez-le.
Cliquez sur Enregistrer.
gcloud
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
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:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com \ --role=projects/HOST_PROJECT_ID/roles/ROLE_ID
Remplacez les éléments suivants :
ROLE_ID
: nom du rôle, tel quegkeFirewallAdmin
.ROLE_TITLE
est un titre convivial pour le rôle, par exempleGKE Firewall Admin
.ROLE_DESCRIPTION
est une brève description du rôle, par exempleGKE service account FW permissions
.LAUNCH_STAGE
: étape de lancement du rôle dans son cycle de vie, telle queALPHA
,BETA
ouGA
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.
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 |
---|---|---|
service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com | Utilisateur de réseau Compute | tier-1 |
SERVICE_PROJECT_1_NUM@cloudservices.gserviceaccount.com | Utilisateur de réseau Compute | tier-1 |
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com | Utilisateur de réseau Compute | tier-2 |
SERVICE_PROJECT_2_NUM@cloudservices.gserviceaccount.com | Utilisateur de réseau Compute | tier-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 |
---|---|---|
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com | Utilisateur de réseau Compute | Sous-réseau spécifique ou ensemble du projet hôte |
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com | 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 :
service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
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
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:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
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:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \ --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 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.
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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans le sélecteur de projet, choisissez votre premier projet de service.
Cliquez sur add_boxCréer.
Dans la section Autopilot ou Standard, cliquez sur Configurer.
Dans le champ Nom, saisissez
tier-1-cluster
.Dans la liste déroulante Région, sélectionnez la même région que celle utilisée pour les sous-réseaux.
Dans le volet de navigation, cliquez sur Mise en réseau.
Sélectionnez Réseaux partagés avec moi (du projet hôte).
Pour le Réseau, sélectionnez shared-net.
Pour le Sous-réseau de nœud, sélectionnez tier-1.
Pour la Plage CIDR secondaire du pod, sélectionnez tier-1-pods.
Pour la Plage CIDR secondaire des services, sélectionnez tier-1-services.
Cliquez sur Créer.
Une fois la création terminée, dans la liste des clusters, cliquez sur tier-1-cluster.
Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.
Sous Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez inspecter.
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.
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=COMPUTE_REGION \
--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
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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans le sélecteur de projet, choisissez votre deuxième projet de service.
Cliquez sur add_boxCréer.
Dans la section Standard ou Autopilot, cliquez sur Configurer.
Dans le champ Nom, saisissez
tier-2-cluster
.Dans la liste déroulante Région, sélectionnez la même région que celle utilisée pour les sous-réseaux.
Dans le volet de navigation, cliquez sur Mise en réseau.
Pour le Réseau, sélectionnez shared-net.
Pour le Sous-réseau de nœud, sélectionnez tier-2.
Pour la Plage CIDR secondaire du pod, sélectionnez tier-2-pods.
Pour la Plage CIDR secondaire des services, sélectionnez tier-2-services.
Cliquez sur Créer.
Une fois la création terminée, dans la liste des clusters, cliquez sur tier-2-cluster.
Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.
Sous Pools de nœuds, cliquez sur le nom du pool de nœuds que vous souhaitez inspecter.
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
.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=COMPUTE_REGION \
--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
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.
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
Accédez à la page Pare-feu de la console Google Cloud.
Dans le sélecteur de projet, choisissez votre projet hôte.
Dans le menu Réseau VPC, cliquez sur Créer une règle de pare-feu.
Dans le champ Nom, saisissez
my-shared-net-rule
.Pour le Réseau, sélectionnez shared-net.
Pour le Sens du trafic, sélectionnez Entrée.
Pour l'option Action en cas de correspondance, sélectionnez Autoriser.
Pour les Cibles, sélectionnez Toutes les instances du réseau.
Dans la section Filtre source, sélectionnez Plages d'adresses IP.
Dans le champ Plages d'adresses IP sources, saisissez
0.0.0.0/0
.Dans Protocoles et ports, sélectionnez Protocoles et ports spécifiés. Dans la zone de texte, saisissez
tcp:22
.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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans le sélecteur de projet, choisissez votre premier projet de service.
Cliquez sur tier-1-cluster.
Sur la page Détails du cluster, cliquez sur l'onglet Nœuds.
Sous Pools de nœuds, cliquez sur le nom de votre pool de nœuds.
Sous Groupes d'instances, cliquez sur le nom de votre groupe d'instances. Exemple : gke-tier-1-cluster-default-pool-faf87d48-grp.
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
.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 envoyer une requête ping entre les nœuds
Dans votre fenêtre de ligne de commande SSH, démarrez CoreOS Toolbox :
/usr/bin/toolbox
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 plage10.0.4.0/22
.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).À 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
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.
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é.
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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Cliquez sur add_boxCréer.
Dans la section Autopilot ou Standard, cliquez sur Configurer.
Dans le champ Nom, saisissez
private-cluster-vpc
.Dans le volet de navigation, cliquez sur Mise en réseau.
Sélectionner Cluster privé.
(Facultatif pour Autopilot) : Définissez la plage d'adresses IP du plan de contrôle sur
172.16.0.16/28
.Dans la liste déroulante Réseau, sélectionnez le réseau VPC que vous avez créé précédemment.
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.
Configurez le cluster selon vos besoins.
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-auto private-cluster-vpc \
--project=PROJECT_ID \
--location=COMPUTE_REGION \
--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.
Nettoyer
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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans le sélecteur de projet, choisissez votre premier projet de service.
Sélectionnez tier-1-cluster, puis cliquez sur Supprimer.
Dans le sélecteur de projet, choisissez votre deuxième projet de service.
Sélectionnez tier-2-cluster, puis cliquez sur Supprimer.
gcloud
gcloud container clusters delete tier-1-cluster \
--project SERVICE_PROJECT_1_ID \
--zone COMPUTE_ZONE
gcloud container clusters delete tier-2-cluster \
--project SERVICE_PROJECT_2_ID \
--zone COMPUTE_ZONE
Désactiver un VPC partagé
Désactivez le VPC partagé dans votre projet hôte.
Console
Accédez à la page VPC partagé de Google Cloud Console.
Dans le sélecteur de projet, choisissez votre projet hôte.
Cliquez sur Désactiver le VPC partagé.
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
Accédez à la page Pare-feu de la console Google Cloud.
Dans le sélecteur de projet, choisissez votre projet hôte.
Dans la liste des règles, sélectionnez les règles suivantes : my-shared-net-rule, my-shared-net-rule et my-shared-net-rule.
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
Accédez à la page Réseaux VPC de Google Cloud Console.
Dans le sélecteur de projet, choisissez votre projet hôte.
Dans la liste des réseaux, sélectionnez shared-net.
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 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
Accédez à la page IAM de la console Google Cloud.
Dans le sélecteur de projet, choisissez votre projet hôte.
Dans la liste des membres, sélectionnez la ligne qui indique que
service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com
est assorti du rôle d'utilisateur de l'agent de service hôte Kubernetes Engine.Sélectionnez la ligne qui indique que
service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com
est assorti du rôle d'utilisateur de l'agent de service hôte Kubernetes Engine.Cliquez sur Supprimer l'accès.
gcloud
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:service-SERVICE_PROJECT_1_NUM@container-engine-robot.iam.gserviceaccount.com \ --role roles/container.hostServiceAgentUser
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:service-SERVICE_PROJECT_2_NUM@container-engine-robot.iam.gserviceaccount.com \ --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_IDMotifs 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.
É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.