Cette page a été traduite par l'API Cloud Translation.

À propos de Private Service Connect

Autopilot Standard

Cette page présente Private Service Connect dans les clusters Google Kubernetes Engine (GKE).

Sur cette page, nous partons du principe que vous connaissez les éléments suivants :

Principes de base de la mise en réseau, comme l'adressage IP
Réseaux VPC

Présentation

Private Service Connect (PSC) fait partie de l'infrastructure réseau de Trusted Cloud by S3NS. Il permet à vos clusters GKE de consommer de manière sécurisée et privée des services hébergés sur Trusted Cloud by S3NS ou dans des environnements sur site, sans avoir à exposer ces services publiquement. Avec PSC, Trusted Cloud by S3NS attribue une adresse IP interne au plan de contrôle pour transférer les requêtes vers l'API de gestion des clusters GKE, ce qui vous permet de gérer vos clusters sans que le trafic ne transite jamais par l'Internet public. PSC fournit un framework cohérent qui permet de connecter différents réseaux via une approche de mise en réseau des services. Il permet également aux producteurs et aux consommateurs de services de communiquer à l'aide d'adresses IP internes à un VPC.

Dans un cluster GKE utilisant l'infrastructure PSC, toutes les communications entre le plan de contrôle du cluster et les nœuds se font de manière privée. Vous pouvez également isoler votre cluster au niveau du plan de contrôle et du pool de nœuds sans avoir à gérer des configurations d'appairage VPC complexes.

Avantages des clusters activés avec Private Service Connect

Sécurité : PSC établit des connexions privées entre le plan de contrôle et les nœuds de votre cluster GKE, ce qui permet de maintenir le trafic entièrement au sein du réseau Google et à l'écart d'Internet public. Cela minimise le risque d'accès non autorisé.

Connectivité simplifiée : pour les clusters PSC, vous n'avez pas à gérer de sous-réseaux spécifiques pour le point de terminaison du plan de contrôle. Le point de terminaison PSC se trouve entièrement dans le réseau du cluster, ce qui élimine la nécessité de configurations réseau complexes.

Évolutivité : vous pouvez créer jusqu'à 1 000 clusters avec PSC activé pour répondre à des besoins élevés en ressources. En revanche, vous ne pouvez créer que 75 clusters par zone ou région pour les clusters utilisant l'appairage de réseaux VPC.

Configuration personnalisable : PSC vous permet de contrôler indépendamment l'isolation du plan de contrôle, des pools de nœuds ou des charges de travail de votre cluster, ce qui rend vos clusters plus évolutifs et sécurisés. Vous pouvez configurer une combinaison de pools de nœuds privés et publics dans votre cluster.

Flexibilité : une fois le cluster créé, vous pouvez modifier les paramètres d'isolation à tout moment. Vous pouvez basculer entre l'accès public et privé au plan de contrôle, et modifier l'accessibilité du pool de nœuds et de la charge de travail depuis Internet sans avoir à créer de cluster.

Limites

Le plan de contrôle possède à la fois un point de terminaison interne et un point de terminaison externe. Le point de terminaison interne du plan de contrôle n'accepte pas les adresses IP internes dans les URL des webhooks que vous configurez. Si vous disposez d'un webhook avec une adresse IP interne dans l'URL, vous pouvez atténuer cette incompatibilité en procédant comme suit :

Créez un service sans interface graphique et sans sélecteur pour gérer manuellement les points de terminaison vers lesquels ce service dirige le trafic. L'exemple suivant montre un service avec un webhook écoutant sur le port 3000 :
```
apiVersion: v1
kind: Service
metadata:
  name: <service-name>
spec:
  clusterIP: None
  ports:
  - port: 3000
    targetPort: 3000
```
Créez un point de terminaison correspondant à la destination requise. Par exemple, si votre webhook utilise l'adresse IP interne 10.0.0.1 dans l'URL, vous pouvez créer le point de terminaison suivant :
```
apiVersion: v1
kind: Endpoints
metadata:
  name: <service-name>
subsets:
- addresses:
  - ip: 10.0.0.1
  ports:
  - port: 3000
```
Mettez à jour la configuration du webhook : dans la configuration du webhook, supprimez l'URL avec l'adresse IP interne et ajoutez le service que vous avez créé lors de la première étape. Exemple :
```
...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    service:
      name: <service-name>
      namespace: <namespace>
      path: "/validate"
      port: 3000
```
Dans l'exemple précédent, le webhook a un chemin d'accès /validate et écoute le port 3000.
Vérifiez votre webhook : assurez-vous que votre webhook peut continuer à recevoir des requêtes du serveur d'API et qu'il peut approuver, refuser ou modifier la requête en fonction d'une logique personnalisée. Si une erreur se produit lors de la validation du webhook, vous devrez peut-être créer un certificat, puis mettre à jour la configuration du webhook avec les détails du nouveau certificat. Exemple :
```
...
kind: ValidatingWebhookConfiguration
...
webhooks:
- name: <webhook-name>
...
  clientConfig:
    ...
    caBundle: <new-certificate>
...
```

Architecture

Le diagramme suivant présente l'architecture d'un cluster utilisant PSC :

Voici les principaux composants d'un cluster avec PSC activé :

Plan de contrôle : chaque cluster GKE dispose d'un serveur d'API Kubernetes géré par le plan de contrôle. Ce plan de contrôle s'exécute sur une machine virtuelle (VM) située dans un réseau VPC d'un projet géré par Google. Un cluster régional comporte plusieurs instances dupliquées du plan de contrôle, chacune s'exécutant sur sa propre VM.

Le plan de contrôle possède à la fois un point de terminaison interne (point de terminaison Private Service Connect) pour la communication interne du cluster et un point de terminaison externe. Vous pouvez choisir de désactiver le point de terminaison externe. Le trafic entre les nœuds et le plan de contrôle est entièrement routé à l'aide d'adresses IP internes. Pour en savoir plus sur la configuration de votre cluster, consultez Vérifier la configuration de votre plan de contrôle.

Réseau VPC : il s'agit d'un réseau virtuel dans lequel vous créez des sous-réseaux avec des plages d'adresses IP internes spécifiques aux nœuds et aux pods du cluster.

Point de terminaison Private Service Connect : il s'agit du point de terminaison interne du plan de contrôle du cluster, qui se trouve dans le réseau VPC de votre projet. Le point de terminaison PSC sert de point d'entrée pour accéder au plan de contrôle du cluster.

Rattachement de service : le rattachement de service est une ressource qui établit une connexion sécurisée et privée entre votre réseau VPC et le réseau VPC du producteur. Comme illustré dans le schéma précédent, le point de terminaison PSC accède au rattachement de service via une connexion privée et permet au trafic de circuler entre les nœuds et le plan de contrôle.

Configurer l'accès au cluster

Vous disposez de plusieurs options pour configurer l'accès au plan de contrôle et aux nœuds sur les clusters compatibles avec PSC. Vous pouvez modifier ces configurations à tout moment après la création du cluster. Pour configurer l'accès à votre cluster, consultez Personnaliser l'isolation de votre réseau.

Accès au plan de contrôle

Accédez au plan de contrôle à l'aide du point de terminaison basé sur un DNS uniquement (recommandé). Vous pouvez autoriser les requêtes d'accès au plan de contrôle en créant des stratégies d'autorisation IAM.
Accédez au plan de contrôle à l'aide de points de terminaison basés sur des adresses IP uniquement. Vous pouvez choisir d'utiliser les points de terminaison externe et interne du plan de contrôle, ou de désactiver le point de terminaison externe pour n'autoriser l'accès qu'à partir des adresses IP réservées par Google (à des fins de gestion des clusters) et des adresses IP internes des clusters GKE.

Si vous utilisez des adresses IP, nous vous recommandons d'utiliser des réseaux autorisés pour restreindre l'accès au plan de contrôle de votre cluster. Les réseaux autorisés vous permettent également de bloquer l'accès à votre plan de contrôle depuis les VM Trusted Cloud by S3NS , Cloud Run ou les fonctions Cloud Run provenant d'adresses IP externes Trusted Cloud by S3NS .
Accédez au plan de contrôle avec un point de terminaison basé sur un DNS et des points de terminaison basés sur des adresses IP.

Accès aux nœuds du cluster

Avec les clusters compatibles avec PSC, vous pouvez configurer des clusters en mode mixte. Vous pouvez configurer votre cluster pour qu'il comporte des nœuds avec accès interne ou externe. Vous pouvez également modifier la configuration réseau des nœuds en fonction du type de cluster que vous utilisez :

Pour les clusters Autopilot, vous pouvez configurer certaines charges de travail pour qu'elles s'exécutent sur des nœuds privés et d'autres sur des nœuds publics. Par exemple, vous pouvez exécuter un mélange de charges de travail dans votre cluster, dont certaines nécessitent un accès à Internet et d'autres non. Vous pouvez déployer une charge de travail sur un nœud avec une adresse IP externe pour vous assurer que seules ces charges de travail sont accessibles publiquement.
Pour les clusters standards, vous pouvez provisionner certains de vos nœuds avec des adresses IP internes, tandis que d'autres nœuds peuvent utiliser des adresses IP externes.

Clusters avec Private Service Connect

Pour vérifier si votre cluster utilise Private Service Connect, exécutez la commande gcloud container clusters describe. Si votre cluster utilise Private Service Connect, la ressource privateClusterConfig possède les valeurs suivantes :

Le champ peeringName est vide ou n'existe pas.
Une valeur est attribuée au champ privateEndpoint.

Pour activer PSC sur votre cluster, créez-le sur la version 1.29 ou ultérieure. Sinon, pour les versions 1.28 et antérieures, créez votre cluster sans activer les nœuds privés. Vous pouvez toujours modifier ce paramètre et activer les nœuds privés après la création du cluster.

Étapes suivantes

Découvrez comment personnaliser l'isolation réseau dans GKE.