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.
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
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" 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, 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 IP secondaire, saisissez10.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, 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 IP 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 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 |
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 projets 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é" dans Cloud Console.
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 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
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 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
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.*
etcompute.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.
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.
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.
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.
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.*
etcompute.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.
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.
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.
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.
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.
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.
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-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 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.
É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.