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 :- Vous devez autoriser la sortie vers le serveur de métadonnées.
- Si vous spécifiez un champ
endPort
dans une règle de réseau sur un cluster sur lequel GKE Dataplane V2 est activé, il risque de ne pas prendre effet à partir de la version 1.22 de GKE. Pour plus d'informations, consultez la section Les plages de ports des règles de réseau ne prennent pas effet. Pour les clusters Autopilot, GKE Dataplane V2 est toujours activé.
- 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
oug1-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
-
In the Google Cloud console, 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.
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 :
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.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 :
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Cliquez sur add_box Créer.
Dans la boîte de dialogue Créer un cluster, cliquez sur Configurer pour GKE Standard.
Configurez le cluster comme vous le souhaitez.
Dans le volet de navigation, cliquez sur Réseau sous Cluster.
Cochez la case Activer la règle de réseau.
Cliquez sur Créer.
Pour activer l'application de la règle de réseau pour un cluster existant, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Mise en réseau, dans le champ Règle de réseau, cliquez sur edit Modifier la règle de réseau.
Cochez la case Activer la règle de réseau pour le maître, puis cliquez sur Enregistrer les modifications.
Attendez que les modifications s'appliquent, puis cliquez à nouveau sur edit Modifier la règle de réseau.
Cochez la case Activer la règle de réseau pour les nœuds.
Cliquez sur Save Changes (Enregistrer les modifications).
API
Pour activer l'application de la règle de réseau, procédez comme suit :
Spécifiez l'objet
networkPolicy
au sein de l'objetcluster
que vous fournissez à la méthode projects.zones.clusters.create ou projects.zones.clusters.update.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 commandescreate
etupdate
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
-
In the Google Cloud console, 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.
Pour désactiver l'application de la règle de réseau, procédez comme suit :
- 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.
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.
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 :
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Mise en réseau, dans le champ Règle de réseau, cliquez sur edit Modifier la règle de réseau.
Décochez la case Activer la règle de réseau pour les nœuds, puis cliquez sur Enregistrer les modifications.
Attendez que les modifications s'appliquent, puis cliquez à nouveau sur edit Modifier la règle de réseau.
Décochez la case Activer la règle de réseau pour le maître.
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 :
Mettez à jour votre cluster pour utiliser
networkPolicy.enabled: false
à l'aide de l'APIsetNetworkPolicy
.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.
Mettez à jour votre cluster pour utiliser
update.desiredAddonsConfig.NetworkPolicyConfig.disabled: true
à l'aide de l'APIupdateCluster
.
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 port988
. - 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 port988
. - Pour les clusters exécutant GKE Dataplane V2, autorisez la sortie vers
169.254.169.254/32
sur le port80
.
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 manifesteNetworkPolicy
. 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 manifesteNetworkPolicy
. 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 externalTrafficPolicy
externalTrafficPolicy 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.
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 :
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.
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
Accédez à la page Google Kubernetes Engine dans Google Cloud Console.
Dans le volet de navigation, sous Clusters, cliquez sur le cluster dont vous souhaitez identifier l'adresse IP interne.
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
ouInternal 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 :
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.
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
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 étiquettesapp=store
de l'étape précédente.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
Mettez en œuvre des approches courantes pour restreindre le trafic à l'aide de règles de réseau.
Utilisez la fonctionnalité de journalisation des règles de réseau.