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. Google Kubernetes Engine n'est pas compatible avec 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é.

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`

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

Accédez à la page d'accueil de Google Cloud Console.

Accéder à la page d'accueil
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 Google Kubernetes Engine dans vos projets

Avant de poursuivre les exercices de ce guide, assurez-vous que l'API Google Kubernetes Engine 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 Google Kubernetes Engine à l'aide de Google Cloud Console ou de l'outil gcloud.

Console

Accédez au tableau de bord API et services dans Cloud Console.
Accéder au tableau de bord des API
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 Google Kubernetes Engine 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 et tier-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" dans Cloud Console.
Accéder à la page Réseaux VPC
Dans le sélecteur de projet, choisissez votre projet hôte.
Cliquez sur 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 us-central1.
Dans le champ Plage d'adresses IP, saisissez 10.0.4.0/22.
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.
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 IP secondaire, saisissez 10.4.0.0/14.
Cliquez sur + Ajouter un sous-réseau.
Dans le champ Nom, saisissez tier-2.
Dans le champ Région, sélectionnez us-central1.
Dans le champ Plage d'adresses IP, saisissez 172.16.4.0/22.
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.
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.
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	service-`service-project-1-num`@container-engine-robot.iam.gserviceaccount.com
GKE	service-`service-project-2-num`@container-engine-robot.iam.gserviceaccount.com
API Google	`service-project-1-num`@cloudservices.gserviceaccount.com
API Google	`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éseau tier-1 de votre projet hôte.
- Dans votre deuxième projet de service, attribuez à deux projets 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 :

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

Accéder à la page VPC partagé
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-project2-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 :

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

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

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

où etag-string est la valeur du champ etag 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 us-central1

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.

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

où etag-string est la valeur du champ etag 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 us-central1

Si vous souhaitez que le cluster GKE crée et gère les ressources de pare-feu dans votre projet hôte, vous pouvez effectuer l'une des tâches suivantes :

Dans votre projet hôte, accordez le rôle Compute Security Admin.
Attribuez un rôle personnalisé avec les autorisations compute.firewalls.* et compute.networks.updatePolicy au compte de service GKE du projet de service. Pour en savoir plus, consultez la section Créer des règles de pare-feu supplémentaires.

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	Niveau 1
`service-project-1-num`@cloudservices.gserviceaccount.com	Utilisateur de réseau Compute	Niveau 1
service-`service-project-2-num`@container-engine-robot.iam.gserviceaccount.com	Utilisateur de réseau Compute	Niveau 2
`service-project-2-num`@cloudservices.gserviceaccount.com	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
service-`service-project-num`@container-engine-robot.iam.gserviceaccount.com	Utilisateur du réseau	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, où service-project-num est le numéro de votre projet de service :

service-service-project-num@container-engine-robot.iam.gserviceaccount.com

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

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 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 de ligne de commande gcloud.

gcloud

gcloud container subnets list-usable \
    --project service-project-id \
    --network-project host-project-id

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 de la commande 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.

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

Accédez au menu Google Kubernetes Engine de Cloud Console.

Accéder au menu Google Kubernetes Engine
Dans le sélecteur de projet, choisissez votre premier projet de service.
Cliquez sur le bouton Créer un cluster.
Dans le champ Nom du cluster, saisissez tier-1-cluster.
Pour le Type d'emplacement, sélectionnez Zonal.
Dans la liste déroulante Zone, sélectionnez us-central1-a.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
Sélectionnez Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias).
Désélectionnez l'option Créer automatiquement des plages secondaires.
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.
Sous Pools de nœuds, cliquez sur le nom de votre groupe d'instances. 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 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

Accédez au menu Google Kubernetes Engine de Cloud Console.

Accéder au menu Google Kubernetes Engine
Dans le sélecteur de projet, choisissez votre deuxième projet de service.
Cliquez sur le bouton Créer un cluster.
Dans le champ Nom du cluster, saisissez tier-2-cluster.
Pour le Type d'emplacement, sélectionnez Zonal.
Dans la liste déroulante Zone, sélectionnez us-central1-a.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
Sélectionnez Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias).
Désélectionnez l'option Créer automatiquement des plages secondaires.
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-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.
Sous Pools de nœuds, cliquez sur le nom de votre groupe d'instances. 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 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.

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

Accéder à la page Règles de pare-feu
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 au menu Google Kubernetes Engine de Cloud Console.

Accéder à la page Règles de pare-feu
Dans le sélecteur de projet, choisissez votre premier projet de service.
Cliquez sur tier-1-cluster.
Sous Pools de nœuds, cliquez sur le nom de votre groupe d'instances. Exemple : gke-tier-1-cluster-default-pool-faf87d48-grp.
Dans la liste des nœuds, 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 avec SSH :

gcloud compute ssh node-name \
    --project service-project-1-id \
    --zone us-central1-a \

où node-name est le nom d'un de vos nœuds.

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 plage 10.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, vous pouvez effectuer l'une des opérations suivantes :

Dans votre projet hôte, accordez le rôle Compute Security Admin.
Attribuez un rôle personnalisé avec les autorisations compute.firewalls.* et compute.networks.updatePolicy au compte de service GKE du projet de service.

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

Accédez au menu Google Kubernetes Engine de Cloud Console.

Accéder au menu Google Kubernetes Engine
Cliquez sur le bouton Créer un cluster.
Dans le champ Nom du cluster, saisissez private-cluster-vpc.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
Cliquez sur Cluster privé.
Assurez-vous que la case Accéder au maître en utilisant son adresse IP externe est cochée.
Définissez la plage d'adresses IP maître 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.
Assurez-vous que la case Activer le routage du trafic de VPC natif (utilisation d'une adresse IP d'alias) est cochée.
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 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

Accédez au menu Google Kubernetes Engine de Cloud Console.

Accéder au menu Google Kubernetes Engine
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 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

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

Accéder à la page VPC partagé
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 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

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

Accéder à la page Règles de pare-feu
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-2 et my-shared-net-rule-3.
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" dans Cloud Console.

Accéder à la page Réseaux VPC
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 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

Accédez à la page IAM dans Cloud Console.

Accéder à la page IAM
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.

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-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 Google Kubernetes Engine 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 Google Kubernetes Engine du projet de service n'a pas le rôle d'utilisateur de l'agent de service hôte dans le projet hôte.

Solution : Vérifiez si le compte de service Google Kubernetes Engine 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 Google Kubernetes Engine 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 Google Kubernetes Engine 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 Google Kubernetes Engine 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.

Configurer des clusters avec un VPC partagé

Présentation

À propos des exemples

Avant de commencer

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

Console

gcloud

Activer l'API Google Kubernetes Engine dans vos projets

Console

gcloud

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

Console

gcloud

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

Activer le VPC partagé et attribuer des rôles

Console

gcloud

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

Accès à Kubernetes Engine

Attribuer le rôle d'utilisateur de l'agent de service hôte

Console

gcloud

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

gcloud

Notes sur les plages secondaires

Créer un cluster dans votre premier projet de service

Console

gcloud

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

Console

gcloud

Créer des règles de pare-feu

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

Console

gcloud

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

Console

gcloud

Mettre à jour la règle de pare-feu pour envoyer une requête ping entre les nœuds

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

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

Console

gcloud

Réserver des adresses IP

Nettoyage

Supprimer les clusters

Console

gcloud

Désactiver un VPC partagé

Console

gcloud

Supprimer vos règles de pare-feu

Console

gcloud

Supprimer le réseau partagé

Console

gcloud

Retirer le rôle d'utilisateur de l'agent de service hôte

Console

gcloud

Dépannage

Autorisation refusée

Étape suivante