Contrôler la communication entre les pods et les services à l'aide de règles de réseau

Cette page explique comment contrôler la communication entre les pods et les services de votre cluster à l'aide de l'application de règles de réseau de GKE.

Vous pouvez également contrôler le trafic sortant des pods vers n'importe quel point de terminaison ou service en dehors du cluster à l'aide de règles de réseau de nom de domaine complet (FQDN). Pour plus d'informations, consultez la section Contrôler la communication entre les pods et les services à l'aide des noms de domaine complets (FQDN).

À propos de l'application de la règle de réseau de GKE

L'application de la règle de réseau vous permet de créer des règles de réseau Kubernetes dans votre cluster. Par défaut, tous les pods d'un cluster peuvent communiquer entre eux librement. Les règles de réseau créent des règles de pare-feu au niveau du pod qui déterminent quels pods et services peuvent accéder les uns aux autres au sein du cluster.

La définition d'une règle de réseau vous permet d'activer des dispositifs tels que la défense en profondeur lorsque votre cluster diffuse une application à plusieurs niveaux. Par exemple, vous pouvez créer une règle de réseau pour empêcher un service frontal de votre application qui aurait été piraté de communiquer directement avec un service de facturation ou de comptabilité séparé de celui-ci par plusieurs niveaux.

Une règle de réseau peut également aider votre application à héberger simultanément des données de plusieurs utilisateurs. Par exemple, vous pouvez fournir une architecture mutualisée sécurisée en définissant un modèle attribuant un espace de noms à chaque locataire. Dans un tel modèle, les règles de réseau peuvent garantir que les pods et les services d'un espace de noms donné n'ont pas la possibilité d'accéder aux pods ou services d'un autre espace de noms.

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.

Conditions requises et limites

Les exigences et limites suivantes s'appliquent aux clusters Autopilot et Standard : Les exigences et limites suivantes ne s'appliquent qu'aux clusters standards :

  • Vous devez autoriser la sortie vers le serveur de métadonnées si vous utilisez une règle de réseau avec la fédération d'identité de charge de travail pour GKE.
  • L'activation de l'application de la règle de réseau augmente l'espace mémoire utilisé par le processus kube-system d'environ 128 Mo et requiert environ 300 millicores de processeur. Cela signifie que si vous activez les règles de réseau pour un cluster existant, vous devrez peut-être augmenter la taille de ce cluster pour continuer à exécuter vos charges de travail planifiées.
  • L'activation de la règle de réseau nécessite la recréation de vos nœuds. Si votre cluster a un intervalle de maintenance actif, la recréation automatique de vos nœuds n'interviendra qu'au prochain intervalle de maintenance. Si vous préférez, vous avez la possibilité de mettre à jour manuellement votre cluster à tout moment.
  • La taille de cluster minimale recommandée pour l'application de la règle de réseau est de trois instances e2-medium.
  • La règle de réseau n'est pas acceptée pour les clusters dont les nœuds sont des instances du type f1-micro ou g1-small, car les besoins en ressources sont trop élevés.

Pour plus d'informations sur les types de machines nœud et les ressources pouvant être allouées, voir Architecture des clusters standard : les nœuds.

Activer l'application de la règle de réseau

L'application de la règle de réseau est activée par défaut pour les clusters Autopilot. Vous pouvez donc passer à l'étape Créer une règle de réseau.

Vous pouvez activer l'application des règles de réseau en mode standard dans GKE à l'aide de gcloud CLI, de la console Google Cloud ou de l'API GKE.

L'application de la règle de réseau est intégrée à GKE Dataplane V2. Vous n'avez pas besoin d'activer l'application de la règle de réseau dans les clusters qui utilisent GKE Dataplane V2.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Pour activer l'application de la règle de réseau lors de la création d'un cluster, exécutez la commande suivante :

    gcloud container clusters create CLUSTER_NAME --enable-network-policy

    Remplacez CLUSTER_NAME par le nom du nouveau cluster.

    Pour activer l'application de la règle de réseau pour un cluster existant, procédez comme suit :

    1. Exécutez la commande suivante pour activer le module complémentaire :

      gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=ENABLED

      Remplacez CLUSTER_NAME par le nom du cluster.

    2. Exécutez la commande suivante pour activer l'application de la règle de réseau sur votre cluster, ce qui recrée les pools de nœuds de votre cluster avec l'application de la règle de réseau activée :

      gcloud container clusters update CLUSTER_NAME --enable-network-policy

Console

Pour activer l'application de la règle de réseau lors de la création d'un cluster, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Cliquez sur Créer.

  3. Dans la boîte de dialogue Créer un cluster, cliquez sur Configurer pour GKE Standard.

  4. Configurez le cluster comme vous le souhaitez.

  5. Dans le volet de navigation, cliquez sur Réseau sous Cluster.

  6. Cochez la case Activer la règle de réseau.

  7. Cliquez sur Créer.

Pour activer l'application de la règle de réseau pour un cluster existant, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Règle de réseau, cliquez sur Modifier la règle de réseau.

  4. Cochez la case Activer la règle de réseau pour le maître, puis cliquez sur Enregistrer les modifications.

  5. Attendez que les modifications s'appliquent, puis cliquez à nouveau sur Modifier la règle de réseau.

  6. Cochez la case Activer la règle de réseau pour les nœuds.

  7. Cliquez sur Save Changes (Enregistrer les modifications).

API

Pour activer l'application de la règle de réseau, procédez comme suit :

  1. Spécifiez l'objet networkPolicy au sein de l'objet cluster que vous fournissez à la méthode projects.zones.clusters.create ou projects.zones.clusters.update.

  2. L'objet networkPolicy requiert une valeur "enum" spécifiant le fournisseur de règle de réseau à utiliser, ainsi qu'une valeur booléenne indiquant s'il faut activer l'application de la règle de réseau. Si vous activez l'application de la règle de réseau sans définir de fournisseur, les commandes create et update renvoient une erreur.

Désactiver l'application de la règle de réseau dans un cluster standard

Vous pouvez désactiver l'application de la règle de réseau à l'aide de gcloud CLI, de la console Google Cloud ou de l'API GKE. Vous ne pouvez pas désactiver l'application de la règle de réseau dans les clusters Autopilot ou les clusters qui utilisent GKE Dataplane V2.

gcloud

  1. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  2. Pour désactiver l'application de la règle de réseau, procédez comme suit :

    1. Désactivez l'application de la règle de réseau sur votre cluster :
    gcloud container clusters update CLUSTER_NAME --no-enable-network-policy

    Remplacez CLUSTER_NAME par le nom du cluster.

    Une fois cette commande exécutée, GKE recrée vos pools de nœuds de cluster avec l'application de la règle de réseau désactivée.

  3. Vérifiez que tous les nœuds ont été recréés :

    kubectl get nodes -l projectcalico.org/ds-ready=true

    Si l'opération réussit, le résultat ressemble à ce qui suit :

    No resources found

    Si le résultat ressemble à ce qui suit, vous devez attendre que GKE ait terminé de mettre à jour les pools de nœuds :

    NAME                                             STATUS                     ROLES    AGE     VERSION
gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600

    Lorsque vous désactivez l'application de la règle de réseau, GKE peut ne pas mettre à jour immédiatement les nœuds si votre cluster dispose d'une exclusion ou d'un intervalle de maintenance configuré. Pour en savoir plus, consultez la section Lenteur du processus de mise à jour du cluster.

  4. Une fois tous les nœuds recréés, désactivez le module complémentaire :

    gcloud container clusters update CLUSTER_NAME --update-addons=NetworkPolicy=DISABLED

Console

Pour désactiver l'application de la règle de réseau pour un cluster existant, procédez comme suit :

  1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

    Accéder à Google Kubernetes Engine

  2. Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.

  3. Sous Mise en réseau, dans le champ Règle de réseau, cliquez sur Modifier la règle de réseau.

  4. Décochez la case Activer la règle de réseau pour les nœuds, puis cliquez sur Enregistrer les modifications.

  5. Attendez que les modifications s'appliquent, puis cliquez à nouveau sur Modifier la règle de réseau.

  6. Décochez la case Activer la règle de réseau pour le maître.

  7. Cliquez sur Save Changes (Enregistrer les modifications).

API

Pour désactiver l'application de la règle de réseau pour un cluster existant, procédez comme suit :

  1. Mettez à jour votre cluster pour utiliser networkPolicy.enabled: false à l'aide de l'API setNetworkPolicy.

  2. Vérifiez que tous vos nœuds ont été recréés à l'aide de gcloud CLI :

    kubectl get nodes -l projectcalico.org/ds-ready=true

    Si l'opération réussit, le résultat ressemble à ce qui suit :

    No resources found

    Si le résultat ressemble à ce qui suit, vous devez attendre que GKE ait terminé de mettre à jour les pools de nœuds :

    NAME                                             STATUS                     ROLES    AGE     VERSION
gke-calico-cluster2-default-pool-bd997d68-pgqn   Ready,SchedulingDisabled   <none>   15m     v1.22.10-gke.600
gke-calico-cluster2-np2-c4331149-2mmz            Ready                      <none>   6m58s   v1.22.10-gke.600

    Lorsque vous désactivez l'application de la règle de réseau, GKE peut ne pas mettre à jour immédiatement les nœuds si votre cluster dispose d'une exclusion ou d'un intervalle de maintenance configuré. Pour en savoir plus, consultez la section Lenteur du processus de mise à jour du cluster.

  3. Mettez à jour votre cluster pour utiliser update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true à l'aide de l'API updateCluster.

Créer une règle de réseau

La création de la règle de réseau fait appel à l'API Network Policy de Kubernetes.

Pour plus d'informations sur la création d'une règle de réseau, consultez les rubriques suivantes dans la documentation de Kubernetes :

Règles de réseau et fédération d'identité de charge de travail pour GKE

Si vous utilisez une règle de réseau avec la fédération d'identité de charge de travail pour GKE, vous devez autoriser la sortie vers les adresses IP suivantes afin que vos pods puissent communiquer avec le serveur de métadonnées GKE.

  • Pour les clusters exécutant une version GKE 1.21.0-gke.1000 ou ultérieure, autorisez la sortie vers 169.254.169.252/32 sur le port 988.
  • Pour les clusters exécutant une version GKE antérieure à 1.21.0-gke.1000, autorisez la sortie vers 127.0.0.1/32 sur le port 988.
  • Pour les clusters exécutant GKE Dataplane V2, autorisez la sortie vers 169.254.169.254/32 sur le port 80.

Si vous n'autorisez pas la sortie vers ces adresses IP et ports, des interruptions peuvent se produire durant les mises à niveau automatiques.

Migrer depuis Calico vers GKE Dataplane V2

Si vous migrez vos règles de réseau de Calico vers GKE Dataplane V2, tenez compte des limites suivantes :

  • Vous ne pouvez pas utiliser une adresse IP de pod ou de service dans le champ ipBlock.cidr d'un fichier manifeste NetworkPolicy. Vous devez référencer les charges de travail à l'aide d'étiquettes. Par exemple, la configuration suivante n'est pas valide :

    - ipBlock:
    cidr: 10.8.0.6/32

  • Vous ne pouvez pas spécifier de champ ports.port vide dans un fichier manifeste NetworkPolicy. Lorsque vous spécifiez un protocole, vous devez également spécifier un port. Par exemple, la configuration suivante n'est pas valide :

    ingress:
- ports:
  - protocol: TCP

Utiliser des équilibreurs de charge d'application

Lorsqu'un objet Ingress est appliqué à un service pour créer un équilibreur de charge d'application, vous devez configurer la règle de réseau appliquée aux pods derrière cet objet Service pour autoriser les plages d'adresses IP pour les vérifications d'état de l'équilibreur de charge d'application appropriées. Si vous utilisez un équilibreur de charge d'application interne, vous devez également configurer la règle de réseau afin d'autoriser le sous-réseau proxy réservé.

Si vous n'utilisez pas l'équilibrage de charge natif en conteneurs avec des groupes de points de terminaison du réseau, les ports de nœud d'un objet Service peuvent transférer les connexions vers les pods d'autres nœuds, à moins que vous n'empêchiez ce comportement en définissant externalTrafficPolicyexternalTrafficPolicy sur Local dans la définition du service. Si externalTrafficPolicy n'est pas défini sur Local, la règle de réseau doit également autoriser les connexions à partir d'autres adresses IP de nœud dans le cluster.

Inclusion des plages d'adresses IP des pods dans les règles ipBlock

Pour contrôler le trafic pour des pods spécifiques, sélectionnez toujours les pods en fonction de leur espace de noms ou des libellés de pod en utilisant les champs namespaceSelector et podSelector dans vos règles d'entrée ou de sortie NetworkPolicy. N'utilisez pas le champ ipBlock.cidr pour sélectionner intentionnellement les plages d'adresses IP des pods, qui sont éphémères par nature. Le projet Kubernetes ne définit pas explicitement le comportement du champ ipBlock.cidr lorsqu'il inclut des plages d'adresses IP de pods. La spécification de plages CIDR étendues dans ce champ, telles que 0.0.0.0/0 (qui incluent les plages d'adresses IP des pods) peut avoir des résultats inattendus dans différentes implémentations de NetworkPolicy.

Les sections suivantes décrivent la façon dont les différentes implémentations de NetworkPolicy dans GKE évaluent les plages d'adresses IP que vous spécifiez dans le champ "ipBlock.cidr", ainsi que l'impact qu'elles peuvent avoir sur les plages d'adresses IP de pod intrinsèquement incluses dans les plages CIDR étendues. Comprendre les différences de comportement des différentes implémentations vous aidera à vous préparer aux résultats de votre migration vers une autre implémentation.

Comportement ipBlock dans GKE Dataplane V2

Avec la mise en œuvre NetworkPolicy de GKE Dataplane V2, le trafic du pod n'est jamais couvert par une règle ipBlock. Par conséquent, même si vous définissez une règle générique telle que cidr: '0.0.0.0/0', le trafic des pods n'est pas inclus. Cela permet par exemple d'autoriser les pods d'un espace de noms à recevoir le trafic provenant d'Internet, sans autoriser également le trafic des pods. Pour inclure également le trafic des pods, sélectionnez explicitement les pods à l'aide d'un sélecteur de pod ou d'espace de noms supplémentaire dans les définitions de règles d'entrée ou de sortie de NetworkPolicy.

Comportement ipBlock dans Calico

Pour la mise en œuvre Calico de NetworkPolicy, les règles ipBlock couvrent le trafic des pods. Avec cette mise en œuvre, pour configurer une plage CIDR étendue sans autoriser le trafic des pods, excluez explicitement la plage CIDR des pods du cluster, comme dans l'exemple suivant :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-non-pod-traffic
spec:
  ingress:
  - from:
    - ipBlock:
      cidr: '0.0.0.0/0'
      except: ['POD_IP_RANGE']

Dans cet exemple, POD_IP_RANGE correspond à la plage d'adresses IPv4 du pod de votre cluster, par exemple 10.95.0.0/17. Si vous disposez de plusieurs plages d'adresses IP, elles peuvent être incluses individuellement dans le tableau, par exemple ['10.95.0.0/17', '10.108.128.0/17'].

Dépannage

Impossibilité pour les pods de communiquer avec le plan de contrôle sur les clusters qui utilisent Private Service Connect

Les pods sur des clusters GKE qui utilisent Private Service Connect peuvent rencontrer un problème de communication avec le plan de contrôle si la sortie du pod vers l'adresse IP interne du plan de contrôle est limitée par les règles de réseau de sortie.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez si votre cluster utilise Private Service Connect. Pour plus d'informations, consultez la page Clusters publics avec Private Service Connect. Sur les clusters qui utilisent Private Service Connect, chaque plan de contrôle est attribué à une adresse IP interne à partir du sous-réseau de nœud du cluster.

  2. Configurez la règle de sortie de votre cluster de façon à autoriser le trafic vers l'adresse IP interne du plan de contrôle.

    Procédez comme suit pour identifier l'adresse IP interne du plan de contrôle :

    gcloud

    Exécutez la commande suivante pour rechercher privateEndpoint :

    gcloud container clusters describe CLUSTER_NAME

    Remplacez CLUSTER_NAME par le nom du cluster.

    Cette commande récupère le point de terminaison privé (privateEndpoint) du cluster spécifié.

    Console

    1. Accédez à la page Google Kubernetes Engine dans Google Cloud Console.

      Accéder à Google Kubernetes Engine

    2. Dans le volet de navigation, sous Clusters, cliquez sur le cluster dont vous souhaitez identifier l'adresse IP interne.

    3. Sous Paramètres de base du cluster, accédez à Internal endpoint, où figure l'adresse IP interne.

    Une fois que vous êtes en mesure de localiser privateEndpoint ou Internal endpoint, configurez la règle de sortie de votre cluster de façon à autoriser le trafic vers l'adresse IP interne du plan de contrôle. Pour plus d'informations, consultez la section Créer une règle de réseau.

Lenteur du processus de mise à jour du cluster

Lorsque vous activez ou désactivez l'application de la règle de réseau sur un cluster existant, il est possible que GKE ne mette pas à jour immédiatement les nœuds si le cluster dispose d'une exclusion ou d'un intervalle de maintenance configuré.

Vous pouvez mettre à niveau manuellement un pool de nœuds en définissant l'option --cluster-version sur la même version GKE que celle que le plan de contrôle exécute. Vous devez utiliser Google Cloud CLI pour effectuer cette opération. Pour en savoir plus, consultez la section Mise en garde à propos des intervalles de maintenance.

Pods déployés manuellement non planifiés

Lorsque vous activez l'application de la règle de réseau sur le plan de contrôle d'un cluster existant, GKE annule la planification de tous les pods de nœud ip-masquerade-agent ou calico que vous avez déployés manuellement.

GKE ne reprogramme pas ces pods tant que l'application de la règle de réseau n'est pas activée sur les nœuds de cluster et que les nœuds ne sont pas recréés.

Si vous avez configuré une exclusion ou un intervalle de maintenance, cela peut entraîner une interruption prolongée.

Pour réduire la durée de cette interruption, vous pouvez attribuer manuellement les libellés suivants aux nœuds du cluster :

  • node.kubernetes.io/masq-agent-ds-ready=true
  • projectcalico.org/ds-ready=true

La règle de réseau n'est pas appliquée

Si une règle de réseau n'est pas appliquée, vous pouvez résoudre le problème en procédant comme suit :

  1. Vérifiez que l'application de la règle de réseau est activée. La commande que vous utilisez varie selon que GKE Dataplane V2 est activé ou non sur votre cluster.

    Si GKE Dataplane V2 est activé sur votre cluster, exécutez la commande suivante :

    kubectl -n kube-system get pods -l k8s-app=cilium

    Si la sortie est vide, l'application de la règle de réseau est désactivée.

    Si GKE Dataplane V2 est désactivé sur votre cluster, exécutez la commande suivante :

    kubectl get nodes -l projectcalico.org/ds-ready=true

    Si la sortie est vide, l'application de la règle de réseau est désactivée.

  2. Vérifiez les étiquettes du pod :

    kubectl describe pod POD_NAME

    Remplacez POD_NAME par le nom du pod.

    Le résultat ressemble à ce qui suit :

    Labels:        app=store
               pod-template-hash=64d9d4f554
               version=v1

  3. Vérifiez que les étiquettes de la règle correspondent à celles du pod :

    kubectl describe networkpolicy

    Le résultat ressemble à ce qui suit :

    PodSelector: app=store

    Dans ce résultat, les étiquettes app=store correspondent aux étiquettes app=store de l'étape précédente.

  4. Vérifiez si des règles de réseau sélectionnent vos charges de travail :

    kubectl get networkpolicy

    Si la sortie est vide, aucune règle de réseau n'a été créée dans l'espace de noms et ne sélectionne vos charges de travail. Si la sortie n'est pas vide, vérifiez si la règle sélectionne vos charges de travail :

    kubectl describe networkpolicy

    Le résultat ressemble à ce qui suit :

    ...
PodSelector:     app=nginx
Allowing ingress traffic:
   To Port: <any> (traffic allowed to all ports)
   From:
      PodSelector: app=store
Not affecting egress traffic
Policy Types: Ingress

Problèmes connus

Arrêt des pods StatefulSet avec Calico

Les clusters GKE avec la règle de réseau Calico activée peuvent rencontrer un problème où un pod StatefulSet supprime les connexions existantes lors de la suppression du pod. Une fois qu'un pod passe à l'état Terminating, la configuration terminationGracePeriodSeconds dans la spécification de pod n'est pas respectée et entraîne des perturbations pour les autres applications ayant une connexion existante avec le pod StatefulSet. Pour en savoir plus sur ce problème, consultez le problème Calico nº4710.

Ce problème affecte les versions GKE suivantes :

  • 1.18
  • 1.19 à 1.19.16-gke.99
  • 1.20 à 1.20.11-gke.1299
  • 1.21 à 1.21.4-gke.1499

Pour résoudre ce problème, mettez à niveau votre plan de contrôle GKE vers l'une des versions suivantes :

  • 1.19.16-gke.100 (et versions ultérieures)
  • 1.20.11-gke.1300 (et versions ultérieures)
  • 1.21.4-gke.1500 (et versions ultérieures)

Pod bloqué à l'état containerCreating

Les clusters GKE avec la règle de réseau Calico activée peuvent rencontrer un problème où les pods sont bloqués à l'état containerCreating.

Sous l'onglet Événements du pod, un message semblable à celui-ci s'affiche :

plugin type="calico" failed (add): ipAddrs is not compatible with
configured IPAM: host-local

Pour résoudre ce problème, utilisez le mode IPAM de l'hôte local pour Calico au lieu de calico-ipam dans les clusters GKE.

Étapes suivantes