Configurer des adresses IP publiques utilisées en mode privé pour GKE

Autopilot Standard

Ce tutoriel explique comment appliquer des adresses IP publiques utilisées en mode privé (Privately Used Public IPs ou PUPI) à des blocs d'adresses de pod Google Kubernetes Engine (GKE).

Les adresses IP publiques utilisées en mode privé (Privately Used Public IPs ou PUPI) sont des adresses que vous pouvez utiliser en mode privé dans votre réseau cloud privé virtuel (VPC) Google Cloud. Ces adresses IP n'appartiennent pas à Google. Vous n'avez pas besoin d'être le propriétaire de ces adresses IP publiques pour les utiliser en mode privé.

Présentation

Les clusters GKE nécessitent des plages d'adresses IP dédiées pour les nœuds, les pods et les services. À mesure que votre infrastructure se développe, vous risquez d'épuiser l'espace d'adresses IP internes standard (RFC 1918). Une manière de réduire l'épuisement des adresses RFC 1918 privées consiste à utiliser des adresses IP publiques utilisées en mode privé (PUPI) pour le bloc CIDR du pod GKE. Les PUPI constituent une alternative à votre réseau de pods GKE, en réservant des adresses IP privées pour d'autres composants du cluster.

Cluster unique : si vous ne créez qu'un seul cluster GKE, vous pouvez activer les adresses PUPI en activant les plages d'adresses IP externes utilisées en mode privé.

Plusieurs clusters : si vous travaillez avec plusieurs clusters GKE connectés via l'appairage de VPC (scénario courant pour les fournisseurs de services), vous aurez besoin d'une configuration plus complexe. Le schéma suivant montre comment une entreprise (producteur) propose un service géré à un client (consommateur) à l'aide de PUPI avec un appairage VPC.

Adresses PUPI du bloc CIDR du pod GKE.

Le schéma précédent implique les éléments suivants :

Bloc CIDR principal : bloc CIDR non-PUPI utilisé pour les nœuds et l'équilibreur de charge interne, qui ne doit pas se chevaucher entre plusieurs VPC.
Bloc CIDR secondaire du producteur : bloc CIDR PUPI utilisé pour les pods (par exemple, 45.45.0.0/16).
Bloc CIDR secondaire du consommateur : tout autre bloc CIDR PUPI côté client (par exemple, 5.5.0.0/16).

Utilisation des adresses PUPI dans un scénario de fournisseur de services

Le fournisseur de services (producteur) exécute son service géré sur un cluster GKE (gke-2) au sein de son VPC (vpc-producer). Ce cluster utilise la plage PUPI 45.0.0.0/8 pour ses adresses IP de pod.

Le client (consommateur) dispose également d'un cluster GKE (gke-1) dans son propre VPC (vpc-consumer), qui utilise une plage PUPI différente, 5.0.0.0/8, pour ses adresses IP de pod.

Ces deux VPC sont connectés à l'aide de l'appairage de VPC, mais chacun continue d'utiliser des adresses IP privées standards (RFC 1918) pour les nœuds, les services et les équilibreurs de charge internes.

Assurer la communication entre les VPC

Consommateur vers producteur : par défaut, le VPC du consommateur partage automatiquement ses routes RFC 1918 (mais pas les adresses PUPI) avec le producteur. Cela permet aux ressources du VPC du client d'accéder aux services du VPC du producteur (généralement via des équilibreurs de charge internes).
Producteur vers consommateur : une configuration explicite est nécessaire pour que les pods du producteur puissent accéder aux ressources du VPC du consommateur.
Pas de chevauchement : le producteur et le consommateur doivent s'assurer que la plage PUPI du consommateur n'entre pas en conflit avec des adresses IP utilisées dans le VPC du producteur.
Exportation/Importation : le producteur doit activer l'exportation de ses routes PUPI, et le consommateur doit autoriser l'importation de ces routes via la connexion d'appairage.

Activer la communication lorsque les plages PUPI se chevauchent

Si le VPC du consommateur utilise déjà la même plage PUPI que le producteur, la communication directe à partir des pods du producteur n'est pas possible. Au lieu de cela, le producteur peut activer le masquage d'adresses IP, qui permet de masquer les adresses IP des pods derrière les adresses IP des nœuds du producteur.

Le tableau suivant indique les paramètres d'importation et d'exportation par défaut de chaque VPC. Vous pouvez modifier les paramètres d'appairage du VPC par défaut à l'aide de la commande gcloud compute networks peerings update.

Réseau VPC	Importer les paramètres	Exporter les paramètres	Remarques
Producteur	Comportement par défaut (désactivé) : n'importe pas les routes de sous-réseau avec des adresses IP publiques Pour activer : --import-subnet-routes-with-public-ip (via l'appairage)	Comportement par défaut (activé) : exporte les routes de sous-réseau avec des adresses IP publiques Pour désactiver : --no-export-subnet-routes-with-public-ip (via l'appairage)	Options contrôlées via la mise en réseau de services.
Grand public	Désactivé (par défaut)	Activé (par défaut)	Gérées généralement par le client, ne doivent pas être modifiées via la mise en réseau de services

L'application de ces paramètres aura les conséquences suivantes :

Le VPC de producteur verra toutes les routes clientes.
Le VPC de consommateur ne verra pas les routes des adresses PUPI configurées sur le sous-réseau de pod du VPC de producteur.
Le trafic en provenance des pods du producteur vers le réseau vpc-consumer devra être traduit derrière les adresses du nœud du cluster du producteur.

Prérequis

Pour établir une communication réussie entre les pods VPC et un autre VPC, assurez-vous que les conditions préalables et les configurations suivantes sont remplies :

Votre cluster GKE doit répondre aux exigences de version minimales suivantes :
- Clusters Autopilot : GKE 1.22 ou une version ultérieure
- Clusters standards : GKE 1.14 ou une version ultérieure.
Sélectionnez une plage PUPI qui n'est pas routable publiquement ni détenue par Google.
Assurez-vous que les adresses IP des nœuds et la plage d'adresses IP principale des deux VPC ne se chevauchent pas.
Si vous avez besoin d'une communication directe de pod à pod entre le VPC client et le service géré, procédez comme suit :
- Clusters Autopilot : configurez la traduction SNAT pour PUPI afin d'assurer la communication entre pods. Aucune configuration supplémentaire n'est requise.
- Clusters standards : traduisez les adresses IP des pods en adresses IP de nœud correspondantes à l'aide de la traduction SNAT. Activez la SNAT pour le trafic PUPI. Pour en savoir plus, consultez la section Activer les plages d'adresses IP externes utilisées en mode privé.

Configurer des adresses IP publiques utilisées en mode privé pour les clusters GKE

Pour configurer des adresses PUPI pour des clusters GKE :

Configurez deux réseaux cloud privés virtuels.
Configurez un sous-réseau dans chaque réseau cloud privé virtuel.
Configurer une plage d'adresses PUPI sur une plage d'adresses secondaire dans chaque sous-réseau.
Établissez une relation d'appairage de cloud privé virtuel entre les deux réseaux de cloud privé virtuel avec des paramètres d'importation et d'exportation appropriés.
Inspectez les routes contenues dans chaque cloud privé virtuel.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

Activez l'API Google Kubernetes Engine.

Activer l'API Google Kubernetes Engine

Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Utilisez uniquement des clusters de VPC natif.
Configurez les spécifications IPAM requises pour l'appairage de VPC.

Configurer des réseaux et des clusters

Créer des réseaux VPC :

Créez les deux réseaux VPC suivants avec RFC-1918 comme plages principales pour les nœuds et des plages PUPI pour les pods. Attribuez des plages d'adresses IP principales de l'espace d'adresses privées RFC 1918 (par exemple, 10.x.x.x, 172.16.x.x ou 192.168.x.x) aux deux VPC. Ces plages sont généralement utilisées pour les nœuds de calcul de vos clusters GKE. Outre les plages d'adresses IP internes, désignez des plages d'adresses IP publiques utilisées en mode privé (PUPI) distinctes pour chaque VPC. Ces plages PUPI sont utilisées exclusivement pour les adresses IP des pods dans les clusters GKE correspondants.
- Réseau VPC consommateur : ce VPC héberge le cluster GKE dans lequel les applications ou les charges de travail du client s'exécutent. Vous pouvez utiliser une configuration semblable à celle-ci :
```
Network: consumer
Subnetwork: consumer-subnet
Primary range: 10.129.0.0/24
Service range name and cidr: consumer-services, 172.16.5.0/24
Pod range name and cidr: consumer-pods, 5.5.5.0/24
Cluster name: consumer-cluster
```
- Réseau VPC du producteur : ce VPC héberge le cluster GKE chargé de fournir le service utilisé par le consommateur. Vous pouvez utiliser une configuration semblable à celle-ci :
```
Network: producer
Subnetwork: producer-subnet
Primary range: 10.128.0.0/24
Service range name and cidr: producer-services, 172.16.45.0/24
Pod range name and cidr: producer-pods, 45.45.45.0/24
Cluster name: producer-cluster
```
Pour en savoir plus sur la création de réseaux VPC, consultez la page Créer des réseaux VPC.
Les réseaux et sous-réseaux VPC créés avec des plages PUPI à l'étape précédente vous permettent de créer deux clusters GKE (producer et consumer).

Remarque : Les plages PUPI ne sont acceptées que comme plages d'adresses IP secondaires pour le réseau de pods dans GKE et ne peuvent pas être utilisées pour la plage d'adresses IP principale (utilisée par les nœuds et les services).
1. Créez des clusters producer avec le réseau et le sous-réseau producteur comme suit :
```
gcloud container clusters create PRODUCER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=NETWORK_NAME \
    --subnetwork=SUBNETWORK_NAME \
    --cluster-secondary-range-name=PRODUCER_PODS \
    --services-secondary-range-name=PRODUCER_SERVICES \
    --num-nodes=1 \
    --zone=PRODUCER_ZONE_NAME \
    --project=PRODUCER_PROJECT_NAME
```
  Remplacez les éléments suivants :
  - PRODUCER_CLUSTER_NAME : nom du cluster producteur GKE.
  - COMPUTE_LOCATION : emplacement Compute Engine du cluster.
  - PRODUCER_SUBNET_NAME : nom d'un sous-réseau existant. La plage d'adresses IP principale du sous-réseau est utilisée par les nœuds. Le sous-réseau doit exister dans la même région que celle utilisée par le cluster. S'il est omis, GKE tente d'utiliser un sous-réseau dans le réseau VPC default de la région du cluster.
  - Si la méthode d'attribution de plages secondaires est gérée par GKE :
    - POD_IP_RANGE : plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou taille du masque de sous-réseau d'un bloc CIDR (par exemple, /14) Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les pods. Si vous omettez l'option --cluster-ipv4-cidr, GKE choisit automatiquement une plage /14 (2¹⁸ adresses). La plage choisie automatiquement est sélectionnée de manière aléatoire à partir de 10.0.0.0/8 (une plage de 2²⁴ adresses).
    - SERVICES_IP_RANGE : plage d'adresses IP au format CIDR (par exemple, 10.4.0.0/19) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /19). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les services.
  - Si la méthode d'attribution de plages secondaires est gérée par l'utilisateur :
    - SECONDARY_RANGE_PODS : nom d'une plage d'adresses IP secondaire existante dans le paramètre SUBNET_NAME spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les pods du cluster.
    - SECONDARY_RANGE_SERVICES : nom d'une plage d'adresses IP secondaire existante dans le paramètre spécifié.
2. Créez des clusters consumer avec le réseau et le sous-réseau consommateur comme suit :
```
gcloud container clusters create CONSUMER_CLUSTER_NAME \
    --enable-ip-alias \
    --network=CONSUMER_NETWORK_NAME \
    --subnetwork=CONSUMER_SUBNETWORK_NAME \
    --cluster-secondary-range-name=CONSUMER_PODS \
    --services-secondary-range-name=CONSUMER_SERVICES \
    --num-nodes=1 \
    --zone=CONSUMER_ZONE \
    --project=CONSUMER_PROJECT
```
  Remplacez les éléments suivants :
  - CONSUMER_CLUSTER_NAME : nom du cluster GKE client.
  - COMPUTE_LOCATION : emplacement Compute Engine du cluster.
  - CONSUMER_SUBNET_NAME : nom d'un sous-réseau existant. La plage d'adresses IP principale du sous-réseau est utilisée par les nœuds. Le sous-réseau doit exister dans la même région que celle utilisée par le cluster. S'il est omis, GKE tente d'utiliser un sous-réseau dans le réseau VPC default de la région du cluster.
  - Si la méthode d'attribution de plages secondaires est gérée par GKE :
    - POD_IP_RANGE : plage d'adresses IP au format CIDR (par exemple, 10.0.0.0/14) ou taille du masque de sous-réseau d'un bloc CIDR (par exemple, /14) Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les pods. Si vous omettez l'option --cluster-ipv4-cidr, GKE choisit automatiquement une plage /14 (2¹⁸ adresses). La plage choisie automatiquement est sélectionnée de manière aléatoire à partir de 10.0.0.0/8 (une plage de 2²⁴ adresses) et n'inclut pas les plages d'adresses IP allouées aux VM, les routes existantes ou les plages allouées à d'autres clusters. La plage choisie automatiquement peut entrer en conflit avec des adresses IP réservées, des routes dynamiques ou des routes au sein de VPC appairés à ce cluster. Si vous utilisez l'un de ces éléments, vous devez spécifier --cluster-ipv4-cidr pour éviter les conflits.
    - SERVICES_IP_RANGE : plage d'adresses IP au format CIDR (par exemple, 10.4.0.0/19) ou à la taille du masque de sous-réseau d'un bloc CIDR (par exemple, /19). Cela permet de créer la plage d'adresses IP secondaire du sous-réseau utilisée par les services.
  - Si la méthode d'attribution de plages secondaires est gérée par l'utilisateur :
    - SECONDARY_RANGE_PODS : nom d'une plage d'adresses IP secondaire existante dans le paramètre SUBNET_NAME spécifié. GKE utilise la totalité de la plage d'adresses IP secondaire du sous-réseau pour les pods du cluster.
    - SECONDARY_RANGE_SERVICES : nom d'une plage d'adresses IP secondaire existante dans le paramètre spécifié.
Pour en savoir plus sur la création de clusters, consultez la section Créer des clusters.
Établissez la relation d'appairage VPC entre le réseau VPC client et le réseau VPC producteur comme suit :
- Pour connecter le réseau consumer au producteur, exécutez la commande suivante :
```
gcloud compute networks peerings create PEERING_NAME \
    --project=consumer_project \
    --network=consumer \
    --peer-network=producer
```
- Pour connecter le réseau producer au client, exécutez la commande suivante :
```
gcloud compute networks peerings create PEERING_NAME \
    --project=producer_project \
    --network=producer \
    --peer-network=consumer \
    --no-export-subnet-routes-with-public-ip \
    --import-subnet-routes-with-public-ip
```
Remplacez les éléments suivants :
- PEERING_NAME : nom du cluster GKE client.
- CONSUMER_CLUSTER_NAME : nom du cluster GKE client.
Par défaut, le VPC de consommateur exporte les adresses PUPI. Lorsque vous créez le VPC de producteur, utilisez les arguments suivants pour le configurer de sorte qu'il importe les adresses PUPI sans les exporter :
```
--no-export-subnet-routes-with-public-ip
--import-subnet-routes-with-public-ip
```

Valider les réseaux et les sous-réseaux

Vérifiez le réseau du producteur :

gcloud compute networks describe producer \
    --project=producer_project

Le résultat ressemble à ce qui suit :

...
kind: compute#network
name: producer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: false
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: true
  name: producer-peer-consumer
…

Vérifiez le sous-réseau du producteur :

gcloud compute networks subnets describe producer-subnet \
    --project=producer_project\
    --region=producer_region

Le résultat ressemble à ce qui suit :

...
ipCidrRange: 10.128.0.0/24
kind: compute#subnetwork
name: producer-subnet
…
secondaryIpRanges:
- ipCidrRange: 172.16.45.0/24
  rangeName: producer-services
- ipCidrRange: 45.45.45.0/24
  rangeName: producer-pods
…

Vérifiez le réseau consommateur :

gcloud compute networks subnets describe consumer-subnet \
    --project=consumer_project \
    --region=consumer_region

Le résultat ressemble à ce qui suit :

...
kind: compute#network
name: consumer
peerings:
- autoCreateRoutes: true
  exchangeSubnetRoutes: true
  exportCustomRoutes: false
  exportSubnetRoutesWithPublicIp: true
  importCustomRoutes: false
  importSubnetRoutesWithPublicIp: false
  name: consumer-peer-producer
...

Vérifiez le sous-réseau consommateur :

gcloud compute networks describe consumer \
--project=consumer_project

Le résultat ressemble à ce qui suit :

...
ipCidrRange: 10.129.0.0/24
kind: compute#subnetwork
name: consumer-subnet
...
secondaryIpRanges:
- ipCidrRange: 172.16.5.0/24
  rangeName: consumer-services
- ipCidrRange: 5.5.5.0/24
  rangeName: consumer-pods
...

Vérifier le cluster GKE et ses ressources

Obtenez les identifiants du cluster client :

gcloud container clusters get-credentials consumer-cluster \
    --project=consumer_project \
    --zone=consumer_zone

Le résultat ressemble à ce qui suit :

...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for consumer-cluster.
...

Installez et validez helloapp.

Vous pouvez également enregistrer le fichier manifeste suivant sous le nom deployment.yaml :

kubectl apply -f - <<'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
EOF

Appliquez le fichier deployment.yaml :
```
kubectl apply -f
```

Vérifiez le déploiement helloweb :

kubectl get deployment helloweb

Le résultat ressemble à ce qui suit :

...
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   1/1     1            1           10s
...

Valider la solution

Vérifiez que l'appairage de VPC a bien été créé :

gcloud compute networks peerings list

Le résultat ressemble à ce qui suit, qui montre les appairages nommés consommateur et producteur :

NAME                                     NETWORK    PEER_PROJECT                PEER_NETWORK                            STACK_TYPE  PEER_MTU  IMPORT_CUSTOM_ROUTES  EXPORT_CUSTOM_ROUTES  STATE   STATE_DETAILS
consumer-peer-producer                   consumer   <project_name>            producer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.
producer-peer-consumer                   producer   <project_name>             consumer                                IPV4_ONLY   1460      False                 False                 ACTIVE  [2023-08-07T13:14:57.178-07:00]: Connected.

Confirmez que le VPC de consommateur exporte les routes PUPI :

gcloud compute networks peerings list-routes consumer-peer-producer \
    --direction=OUTGOING \
    --network=consumer \
    --region=<consumer_region>

Le résultat ressemble à ce qui suit, qui montre les trois blocs CIDR consommateurs :

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted by peer

Vérifiez les routes PUPI importées par le VPC de producteur :

gcloud compute networks peerings list-routes producer-peer-consumer \
    --direction=INCOMING \
    --network=producer \
    --region=<producer_region>

Le résultat ressemble à ce qui suit, qui montre les trois blocs CIDR consommateurs :

DEST_RANGE     TYPE                  NEXT_HOP_REGION  PRIORITY  STATUS
10.129.0.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
172.16.5.0/24  SUBNET_PEERING_ROUTE  us-central1      0         accepted
5.5.5.0/24     SUBNET_PEERING_ROUTE  us-central1      0         accepted

Vérifiez que les pods GKE disposent d'une adresse PUPI :

kubectl get pod -o wide

Le résultat ressemble à ce qui suit, ce qui montre que les adresses IP des pods se trouvent dans la plage 5.5.5/24.

NAME                        READY   STATUS    RESTARTS   AGE   IP         NODE                                              NOMINATED NODE   READINESS GATES
helloweb-575d78464d-xfklj   1/1     Running   0          28m   5.5.5.16   gke-consumer-cluster-default-pool-e62b6542-dp5f   <none>           <none>

Étape suivante

Consultez le guide Configurer l'accès aux services privés.
Consultez le guide Premiers pas avec l'API Service Networking.
Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.