Clusters privés

Cette page explique comment fonctionnent les clusters privés dans Google Kubernetes Engine (GKE). Vous pouvez également apprendre à créer et gérer des clusters privés.

Un cluster privé est un type de cluster de VPC natif qui ne dépend que des adresses IP internes. Les nœuds, les pods et les services d'un cluster privé nécessitent des plages d'adresses IP de sous-réseau uniques.

Vous pouvez créer et configurer des clusters privés en mode Standard ou Autopilot.

Si vous souhaitez fournir un accès Internet sortant à certains nœuds privés, vous pouvez utiliser Cloud NAT ou gérer votre propre passerelle NAT.

Architecture

Les clusters privés utilisent des nœuds qui ne possèdent pas d'adresse IP externe. Cela signifie que les clients sur Internet ne peuvent pas se connecter aux adresses IP des nœuds. Par exemple, un service de type NodePort hébergé dans un cluster privé est inaccessible aux clients externes, car le nœud ne dispose pas d'une adresse IP publique routable sur Internet.

Contrairement à un cluster public, un cluster privé possède un point de terminaison privé du plan de contrôle et un point de terminaison public du plan de contrôle. Vous devez spécifier une plage d'adresses IP /28 unique pour le point de terminaison privé du plan de contrôle. Vous pouvez choisir de désactiver le point de terminaison public du plan de contrôle.

Le schéma suivant présente l'architecture d'un cluster privé :

Architecture d'un cluster privé

Même si les nœuds utilisent des adresses IP internes, les clients externes peuvent se connecter aux services de votre cluster. Exemple :

Utiliser l'accès privé à Google dans des clusters privés

Pour les clusters privés utilisant des réseaux VPC dans le même projet que le cluster, GKE s'assure que l'accès privé à Google est activé sur le sous-réseau utilisé par le cluster privé au moment de sa création. Un administrateur réseau, propriétaire ou éditeur d'un projet hôte de VPC partagé doit activer manuellement l'accès privé à Google sur les sous-réseaux utilisés par les clusters privés si ceux-ci sont créés dans des projets de service de VPC partagé.

L'accès privé à Google est activé par défaut dans les clusters privés, sauf dans les clusters de VPC partagé. Vous devez activer manuellement l'accès privé à Google pour les clusters de VPC partagé.

L'accès privé à Google fournit des nœuds privés et leurs charges de travail avec un accès aux API et services Google Cloud via le réseau privé de Google. Par exemple, l'accès privé à Google est requis pour que les clusters privés puissent accéder aux images de conteneur d'Artifact Registry et envoyer des journaux à Cloud Logging.

Plan de contrôle des clusters privés

Chaque cluster GKE dispose d'un serveur d'API Kubernetes géré par le plan de contrôle (maître).

Ce plan de contrôle s'exécute sur une machine virtuelle (VM) située dans un réseau VPC d'un projet appartenant à Google. Un cluster régional comporte plusieurs plans de contrôle, chacun s'exécutant sur sa propre VM.

Dans les clusters privés, le réseau VPC du plan de contrôle est connecté au réseau VPC de votre cluster via l'appairage de réseaux VPC. Votre réseau VPC contient les nœuds du cluster, et le plan de contrôle du cluster se trouve dans un réseau VPC Google Cloud appartenant à Google.

Le trafic entre les nœuds et le plan de contrôle est entièrement routé à l'aide d'adresses IP internes. Si vous utilisez l'appairage de réseaux VPC pour connecter le réseau VPC de votre cluster à un troisième réseau, celui-ci ne peut pas accéder aux ressources du réseau VPC du plan de contrôle. En effet, l'appairage de réseaux VPC n'accepte que la communication entre les réseaux directement appairés et le troisième réseau ne peut pas être appairé au réseau du plan de contrôle. Pour en savoir plus, consultez la section Restrictions de l'appairage de réseaux VPC.

Réutilisation de l'appairage de réseaux VPC

Les clusters privés créés après le 15 janvier 2020 utilisent une connexion d'appairage de réseaux VPC commune si les clusters se trouvent au même emplacement et utilisent le même réseau VPC. Dans ce contexte, le terme emplacement fait exclusivement référence à une région ou à une zone Google Cloud.

  • Pour les clusters zonaux : le premier cluster privé que vous créez dans une zone génère une connexion d'appairage de réseaux VPC au réseau VPC du cluster. Les autres clusters privés zonaux que vous créez dans la même zone et le réseau VPC utilisent la même connexion d'appairage.

  • Pour les clusters régionaux : le premier cluster privé que vous créez dans une région génère une connexion d'appairage de réseaux VPC au réseau VPC du cluster. Les autres clusters privés régionaux que vous créez dans la même région et le réseau VPC utilisent la même connexion d'appairage.

  • GKE n'utilise pas d'appairage commun pour les clusters zonaux et régionaux, même lorsque les clusters zonaux appartiennent à la même région que les clusters régionaux.

Les exemples suivants clarifient ce comportement. Chaque exemple utilise une connexion d'appairage de réseaux VPC :

  • Au moins deux clusters privés zonaux de la zone us-east1-b utilisent le même réseau VPC.

  • Au moins deux clusters privés régionaux de la région us-east1 utilisent le même réseau VPC.

Cependant, un ou plusieurs clusters privés zonaux dans us-east1-b et un ou plusieurs clusters régionaux dans us-east1 utilisant le même réseau VPC nécessitent deux connexions d'appairage de réseaux VPC.

Pour en savoir plus sur les clusters privés et les connexions, consultez la section Réutilisation de l'appairage de réseaux VPC.

Points de terminaison dans les clusters privés

Le plan de contrôle d'un cluster privé possède un point de terminaison privé en plus d'un point de terminaison public. Le plan de contrôle d'un cluster non privé ne possède qu'un point de terminaison public.

Point de terminaison privé
Le point de terminaison privé est une adresse IP interne dans le réseau VPC du plan de contrôle. Dans un cluster privé, les nœuds communiquent toujours avec le point de terminaison privé du plan de contrôle. En fonction de votre configuration, vous pouvez gérer le cluster avec des outils tels que kubectl, qui se connectent également au point de terminaison privé. Toute VM qui utilise le même sous-réseau que votre cluster privé peut également accéder au point de terminaison privé.
Point de terminaison public
Il s'agit de l'adresse IP externe du plan de contrôle. Par défaut, des outils tels que kubectl communiquent avec le plan de contrôle sur son point de terminaison public.

Accès aux points de terminaison du cluster

Vous pouvez contrôler l'accès aux points de terminaison à l'aide de l'une des configurations suivantes :

  • Accès public aux points de terminaison désactivé : il s'agit de l'option la plus sécurisée, car elle empêche tout accès Internet au plan de contrôle. C'est un bon choix si vous avez configuré votre réseau sur site pour une connexion à Google Cloud via Cloud Interconnect ou Cloud VPN.

    Si vous désactivez l'accès public au point de terminaison, vous devez configurer des réseaux autorisés pour le point de terminaison privé. Si vous ne les configurez pas, vous ne pouvez vous connecter au point de terminaison privé que depuis des nœuds de cluster ou des VM appartenant au même sous-réseau que le cluster. Avec ce paramètre, les réseaux autorisés doivent être des adresses IP internes.

  • Accès public aux points de terminaison activé, réseaux autorisés activés : dans cette configuration, les réseaux autorisés s'appliquent au point de terminaison public du plan de contrôle. Cette option est idéale si vous devez administrer le cluster à partir de réseaux sources non connectés au réseau VPC de votre cluster à l'aide de Cloud Interconnect ou de Cloud VPN.

  • Accès public aux points de terminaison activé, réseaux autorisés désactivés : il s'agit de l'option par défaut, qui est également la moins restrictive. Puisque les réseaux autorisés ne sont pas activés, vous pouvez administrer votre cluster à partir de n'importe quelle adresse IP source, à condition de vous authentifier.

Le tableau suivant récapitule les différentes manières d'accéder aux points de terminaison :

Accès public aux points de terminaison désactivé Accès public aux points de terminaison activé,
réseaux autorisés activés
Accès public aux points de terminaison activé,
réseaux autorisés désactivés.
Sécurité Niveau maximal de restriction des accès au plan de contrôle. L'accès client au point de terminaison public du plan de contrôle est bloqué. L'accès au plan de contrôle doit provenir d'adresses IP internes. Accès restreint au plan de contrôle à partir des adresses IP internes et externes que vous avez définies. Accès au plan de contrôle depuis n'importe quelle adresse IP.
Procédure de configuration détaillée Créer un cluster privé sans accès client au point de terminaison public. Créer un cluster privé avec accès limité au point de terminaison public. Créer un cluster privé disposant d'un accès illimité au point de terminaison public.
Options de configuration de Cloud Console
  1. Sélectionner Activer le VPC natif.
  2. Sélectionner Cluster privé.
  3. Supprimer Accéder au plan de contrôle à l'aide de son adresse IP externe.
    L'option Activer les réseaux autorisés pour le plan de contrôle est automatiquement activée.
  1. Sélectionner Activer le VPC natif.
  2. Sélectionner Cluster privé.
  3. Sélectionner Accéder au plan de contrôle à l'aide de son adresse IP externe.
  4. Sélectionner Activer les réseaux autorisés pour le plan de contrôle.
  1. Sélectionner Activer le VPC natif.
  2. Sélectionner Cluster privé.
  3. Sélectionner Accéder au plan de contrôle à l'aide de son adresse IP externe.
  4. Supprimer Activer les réseaux autorisés pour le plan de contrôle.
Options de création de cluster gcloud --enable-ip-alias
--enable-private-nodes
--enable-private-endpoint
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--enable-master-authorized-networks
--enable-ip-alias
--enable-private-nodes
--no-enable-master-authorized-networks
Communication entre les nœuds et le plan de contrôle

Les nœuds contactent toujours le plan de contrôle à l'aide du point de terminaison privé.

Communication webhook entre les nœuds et le serveur d'API

Les webhooks qui utilisent un service avec un port cible autre que 443 nécessitent une règle de pare-feu pour autoriser cette action. Pour en savoir plus, consultez la section Ajouter des règles de pare-feu pour des cas d'utilisation spécifiques.

Réseaux autorisés (maîtres) du plan de contrôle

Obligatoire pour l'accès au plan de contrôle à partir d'adresses IP internes autres que des nœuds et des pods.

Vous n'avez pas besoin d'autoriser explicitement la plage d'adresses IP internes des nœuds. Les adresses de la plage d'adresses IP principales du sous-réseau du cluster sont toujours autorisées à communiquer avec le point de terminaison privé.

Utilisez --master-authorized-networks pour spécifier des adresses IP internes supplémentaires qui peuvent accéder au plan de contrôle. Il n'est pas possible d'inclure des adresses IP externes dans la liste des réseaux autorisés, car l'accès au point de terminaison public est désactivé.

Obligatoire pour l'accès au plan de contrôle à partir d'adresses IP externes et d'adresses IP internes autres que les nœuds et les pods.

Utilisez --master-authorized-networks pour spécifier les adresses IP externes et internes, autres que les nœuds et les pods, qui peuvent accéder au plan de contrôle.

Non utilisé.

Si vous activez l'accès au point de terminaison public du plan de contrôle sans activer les réseaux autorisés, l'accès au point de terminaison public du plan de contrôle n'est pas restreint.

Accès à l'aide de kubectl

Depuis les nœuds : se sert toujours du point de terminaison privé. kubectl doit être configuré pour utiliser le point de terminaison privé.

À partir d'autres VM du réseau VPC du cluster : les autres VM peuvent utiliser kubectl pour communiquer avec le point de terminaison privé à la condition qu'elles se trouvent dans la même région que le cluster et que leurs adresses IP internes soient incluses dans la liste des réseaux autorisés maîtres ou qu'elles se trouvent dans le même sous-réseau que les nœuds du cluster. kubectl doit être configuré pour utiliser le point de terminaison privé.

Depuis des adresses IP publiques : jamais.

Depuis les nœuds : se sert toujours du point de terminaison privé. kubectl doit être configuré pour utiliser le point de terminaison privé.

À partir d'autres VM du réseau VPC du cluster : les autres VM peuvent utiliser kubectl pour communiquer avec le point de terminaison privé à la condition qu'elles se trouvent dans la même région que le cluster et que leurs adresses IP internes soient incluses dans la liste des réseaux autorisés maîtres ou qu'elles se trouvent dans le même sous-réseau que les nœuds du cluster. kubectl doit être configuré pour utiliser le point de terminaison privé.

Depuis les adresses IP publiques : les machines avec des adresses IP publiques ne peuvent utiliser kubectl pour communiquer avec le point de terminaison public que si leurs adresses IP publiques sont incluses dans la liste des réseaux autorisés. Cela inclut les ordinateurs extérieurs à Google Cloud et les VM Google Cloud avec des adresses IP externes.

Depuis les nœuds : se sert toujours du point de terminaison privé. kubectl doit être configuré pour utiliser le point de terminaison privé.

À partir d'autres VM du réseau VPC du cluster : les autres VM peuvent utiliser kubectl pour communiquer avec le point de terminaison privé à la condition qu'elles se trouvent dans la même région que le cluster. kubectl doit être configuré pour utiliser le point de terminaison privé.

À partir d'adresses IP publiques : toute machine disposant d'une adresse IP publique peut utiliser kubectl pour communiquer avec le point de terminaison public. Cela inclut les ordinateurs extérieurs à Google Cloud et des VM Google Cloud avec des adresses IP externes.

Étape suivante