Ce guide explique comment configurer la visibilité intranœud sur un cluster Google Kubernetes Engine (GKE).
La visibilité intranœud configure la mise en réseau sur chaque nœud du cluster afin que le trafic envoyé d'un pod à un autre soit traité par le réseau de cloud privé virtuel (VPC) du cluster, même si les pods se trouvent sur le même nœud.
La visibilité intranœud est désactivée par défaut sur les clusters standards et activée par défaut dans les clusters Autopilot.
Architecture
La visibilité intranœud garantit que les paquets envoyés entre les pods sont toujours traités par le réseau VPC, ce qui garantit que les règles de pare-feu, les routes, les journaux de flux et les configurations de mise en miroir de paquets s'appliquent aux paquets.
Lorsqu'un pod envoie un paquet à un autre pod sur le même nœud, le paquet quitte le nœud et est traité par le réseau Google Cloud. Le paquet est ensuite immédiatement renvoyé au même nœud et transféré au pod de destination.
La visibilité intranœud déploie le DaemonSet netd
.
Avantages
La visibilité intranœud offre les avantages suivants :
- Afficher les journaux de flux pour tout le trafic entre les pods, y compris le trafic entre les pods d'un même nœud.
- Créer des règles de pare-feu qui s'appliquent à tout le trafic entre les pods, y compris le trafic entre les pods du même nœud.
- Utiliser la mise en miroir de paquets pour cloner le trafic, y compris le trafic entre les pods du même nœud, puis le transférer pour examen.
Conditions requises et limites
La visibilité intranœud présente les exigences et les limites suivantes :
- Votre cluster doit utiliser GKE version 1.15 ou ultérieure.
- La visibilité intranœud n'est pas compatible avec les pools de nœuds Windows Server.
- La visibilité intranœud est requise si vous souhaitez que votre cluster utilise un réseau VPC dont l'unité de transmission maximale (MTU) est supérieure à 1 460 octets. Pour en savoir plus, consultez la présentation de l'unité de transmission maximale.
- Si vous activez la visibilité intranœud et utilisez un
ip-masq-agent
configuré avec le paramètrenonMasqueradeCIDRs
, vous devez inclure la plage CIDR du pod dansnonMasqueradeCIDRs
pour éviter les problèmes de connectivité intranœud. - Lorsque la visibilité intranœud est activée, des délais DNS fréquents peuvent se produire si le pod client et le pod kube-dns sont situés sur le même nœud. Pour en savoir plus, consultez la section Expiration de délais DNS.
- Si vous activez la visibilité intranœud et la stratégie réseau, vous risquez de rencontrer des réinitialisations du trafic entre pods.
Règles de pare-feu
Lorsque vous activez la visibilité intranœud, le réseau VPC traite tous les paquets envoyés entre les pods, y compris les paquets envoyés entre les pods du même nœud. Cela signifie que les règles de pare-feu VPC et les règles de pare-feu hiérarchiques s'appliquent de manière cohérente à la communication entre pods, quel que soit leur emplacement.
Si vous configurez des règles de pare-feu personnalisées pour la communication au sein du cluster, évaluez soigneusement les besoins de mise en réseau de votre cluster pour déterminer l'ensemble des règles d'autorisation du trafic sortant et entrant. Vous pouvez utiliser des tests de connectivité pour vous assurer que le trafic légitime n'est pas bloqué. Par exemple, la communication entre pods est nécessaire au fonctionnement de la règle de réseau.
Avant de commencer
Avant de commencer, effectuez les tâches suivantes :
- Assurez-vous d'avoir activé l'API Google Kubernetes Engine. Activer l'API Google Kubernetes Engine
- Assurez-vous d'avoir installé Google Cloud CLI.
- Configurez les paramètres par défaut de Google Cloud CLI pour votre projet en utilisant l'une des méthodes suivantes :
- Utilisez
gcloud init
si vous souhaitez suivre les étapes de définition des paramètres par défaut du projet. - Utilisez
gcloud config
pour définir individuellement l'ID, la zone et la région de votre projet. -
Exécutez
gcloud init
et suivez les instructions :gcloud init
Si vous utilisez SSH sur un serveur distant, utilisez l'option
--console-only
pour empêcher la commande d'ouvrir un navigateur :gcloud init --console-only
- Suivez les instructions pour autoriser gcloud CLI à utiliser votre compte Google Cloud.
- Créez ou sélectionnez une configuration.
- Choisissez un projet Google Cloud.
- Choisissez une zone Compute Engine par défaut.
- Choisissez une région Compute Engine par défaut.
- Définissez votre ID de projet par défaut :
gcloud config set project PROJECT_ID
- Définissez votre région Compute Engine par défaut (par exemple,
us-central1
) :gcloud config set compute/region COMPUTE_REGION
- Définissez votre zone Compute Engine par défaut (par exemple,
us-central1-c
) :gcloud config set compute/zone COMPUTE_ZONE
- Mettez à jour
gcloud
vers la dernière version :gcloud components update
gcloud init
gcloud config
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
.
Activer la visibilité intranœud sur un nouveau cluster
Vous pouvez créer un cluster dans lequel la visibilité intranœud est activée à l'aide de gcloud CLI ou de Google Cloud Console.
gcloud
Pour créer un cluster à nœud unique dans lequel la visibilité intranœud est activée, utilisez l'option --enable-intra-node-visibility
:
gcloud container clusters create CLUSTER_NAME \
--region=COMPUTE_REGION \
--enable-intra-node-visibility
Remplacez les éléments suivants :
CLUSTER_NAME
: nom de votre nouveau clusterCOMPUTE_REGION
: région de calcul du cluster.
Console
Pour créer un cluster à nœud unique dans lequel la visibilité intranœud est activée, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans Cloud Console.
Cliquez sur add_box Créer.
Saisissez le nom de votre cluster.
Dans la boîte de dialogue Configurer le cluster, à côté de GKE standard, cliquez sur Configurer.
Configurez le cluster selon vos besoins.
Dans le volet de navigation, sous Cluster, cliquez sur Réseau.
Cochez la case Activer la visibilité intranœud.
Cliquez sur Create (Créer).
Activer la visibilité intranœud sur un cluster existant
Vous pouvez activer la visibilité intranœud pour un cluster existant à l'aide de gcloud CLI ou de Google Cloud Console.
Lorsque vous activez la visibilité intranœud pour un cluster existant, GKE redémarre les composants du plan de contrôle et des nœuds de calcul.
gcloud
Pour activer la visibilité intranœud sur un cluster existant, utilisez l'option --enable-intra-node-visibility
:
gcloud container clusters update CLUSTER_NAME \
--enable-intra-node-visibility
Remplacez CLUSTER_NAME
par le nom de votre cluster.
Console
Pour activer la visibilité intranœud sur un cluster existant, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Mise en réseau, cliquez sur edit Modifier la visibilité intranœud.
Cochez la case Activer la visibilité intranœud.
Cliquez sur Save Changes (Enregistrer les modifications).
Désactiver la visibilité intranœud
Vous pouvez désactiver la visibilité intranœud sur un cluster à l'aide de gcloud CLI ou de Google Cloud Console.
Lorsque vous désactivez la visibilité intranœud sur un cluster existant, GKE redémarre les composants du plan de contrôle et des nœuds de calcul.
gcloud
Pour désactiver la visibilité intranœud, utilisez l'option --no-enable-intra-node-visibility
:
gcloud container clusters update CLUSTER_NAME \
--no-enable-intra-node-visibility
Remplacez CLUSTER_NAME
par le nom de votre cluster.
Console
Pour désactiver la visibilité intranœud, procédez comme suit :
Accédez à la page Google Kubernetes Engine dans Cloud Console.
Dans la liste des clusters, cliquez sur le nom du cluster que vous souhaitez modifier.
Sous Mise en réseau, cliquez sur edit Modifier la visibilité intranœud.
Décochez la case Activer la visibilité intranœud.
Cliquez sur Save Changes (Enregistrer les modifications).
Exercice : Vérifier la visibilité intranœud
Cet exercice décrit la procédure à suivre pour activer la visibilité intranœud et vérifier qu'elle fonctionne sur votre cluster.
Dans cet exercice, vous allez effectuer les tâches suivantes :
- Activer les journaux de flux pour le sous-réseau par défaut dans la région
us-central1
. - Créer un cluster à nœud unique dans lequel la visibilité intranœud est activée dans la zone
us-central1-a
. - Créer deux pods dans votre cluster.
- Envoyer une requête HTTP d'un pod à un autre.
- Afficher l'entrée du journal de flux pour la requête de pod à pod.
Activer des journaux de flux
Activez les journaux de flux du sous-réseau par défaut :
gcloud compute networks subnets update default \ --region=us-central1 \ --enable-flow-logs
Vérifiez que les journaux de flux sont activés pour le sous-réseau par défaut :
gcloud compute networks subnets describe default \ --region=us-central1
La sortie indique que les journaux de flux sont activés, comme suit :
... enableFlowLogs: true ...
Créer un cluster
Créez un cluster à nœud unique dans lequel la visibilité intranœud est activée :
gcloud container clusters create flow-log-test \ --zone=us-central1-a \ --num-nodes=1 \ --enable-intra-node-visibility
Récupérez les identifiants de votre cluster :
gcloud container clusters get-credentials flow-log-test \ --zone=us-central1-a
Créer deux pods
Créez un pod.
Enregistrez le fichier manifeste suivant dans un fichier nommé
pod-1.yaml
:apiVersion: v1 kind: Pod metadata: name: pod-1 spec: containers: - name: container-1 image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Appliquez le fichier manifeste à votre cluster :
kubectl apply -f pod-1.yaml
Créez un deuxième pod.
Enregistrez le fichier manifeste suivant dans un fichier nommé
pod-2.yaml
:apiVersion: v1 kind: Pod metadata: name: pod-2 spec: containers: - name: container-2 image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0
Appliquez le fichier manifeste à votre cluster :
kubectl apply -f pod-2.yaml
Affichez les pods :
kubectl get pod pod-1 pod-2 --output wide
La sortie affiche les adresses IP de vos pods comme suit :
NAME READY STATUS RESTARTS AGE IP ... pod-1 1/1 Running 0 1d 10.52.0.13 ... pod-2 1/1 Running 0 1d 10.52.0.14 ...
Notez les adresses IP de
pod-1
etpod-2
.
Envoyer une requête
Ouvrez une interface système sur le conteneur dans
pod-1
:kubectl exec -it pod-1 -- sh
Dans l'interface système, envoyez une requête à
pod-2
:wget -qO- POD_2_IP_ADDRESS:8080
Remplacez
POD_2_IP_ADDRESS
par l'adresse IP depod-2
.La sortie affiche la réponse du conteneur en cours d'exécution dans
pod-2
.Hello, world! Version: 2.0.0 Hostname: pod-2
Saisissez "exit" pour quitter l'interface système et revenir à votre environnement de ligne de commande principal.
Afficher les entrées du journal de flux
Pour afficher une entrée de journal de flux, exécutez la commande suivante :
gcloud logging read \
'logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="POD_1_IP_ADDRESS" AND jsonPayload.connection.dest_ip="POD_2_IP_ADDRESS"'
Remplacez les éléments suivants :
PROJECT_ID
: ID de votre projet.POD_1_IP_ADDRESS
: adresse IP depod-1
.POD_2_IP_ADDRESS
: adresse IP depod-2
.
Le résultat affiche une entrée du journal de flux pour une requête envoyée de pod-1
à pod-2
. Dans cet exemple, pod-1
a l'adresse IP 10.56.0.13
, et pod-2
a l'adresse IP 10.56.0.14
.
...
jsonPayload:
bytes_sent: '0'
connection:
dest_ip: 10.56.0.14
dest_port: 8080
protocol: 6
src_ip: 10.56.0.13
src_port: 35414
...
Effectuer un nettoyage
Afin d'éviter que des frais inutiles ne soient facturés sur votre compte, procédez comme suit pour supprimer les ressources que vous avez créées :
Supprimez le cluster à l'aide de la commande suivante :
gcloud container clusters delete -q flow-log-test
Désactivez les journaux de flux du sous-réseau par défaut :
gcloud compute networks subnets update default --no-enable-flow-logs
Problèmes connus
Réinitialisation des connexions
Si vous activez à la fois la visibilité intranœud et la stratégie réseau sur un cluster, certaines connexions peuvent être réinitialisées en ce qui concerne le trafic entre les pods d'un même nœud.
Ce problème affecte les clusters sur les versions de GKE suivantes :
- 1.19.9-gke.1900 à 1.19.12-gke.500
- 1.20.5-gke.2000 à 1.20.8-gke.600
- 1.21.0-gke.400 à 1.21.2-gke.500
Pour résoudre ce problème, mettez à niveau votre cluster vers l'une des versions GKE suivantes :
- 1.19.12-gke.700 (et versions ultérieures)
- 1.20.8-gke.700 (et versions ultérieures)
- 1.21.2-gke.600 (et versions ultérieures)
Expiration de délais DNS
Lorsque la visibilité intranœud est activée, des délais avant expiration DNS peuvent se produire si le pod client et le pod kube-dns sont situés sur le même nœud.
Ce problème affecte les clusters sur les versions de GKE suivantes :
- 1.18.16-gke.300 et versions ultérieures
- 1.19.7-gke.1500 et versions ultérieures
- 1.20.2-gke.1500 et versions ultérieures
Ce problème affecte principalement les charges de travail basées sur Alpine, mais peut également affecter les pods basés sur Debian avec glibc
2.9. Les requêtes DNS pour les noms externes, telles que metadata.internal
ou googleapis.com
, expirent. Les requêtes DNS au sein du cluster utilisant des noms de domaine complets ne sont pas affectées.
Pour résoudre ce problème, mettez à niveau votre cluster vers l'une des versions GKE suivantes :
- 1.22.2-gke.1300 ou ultérieure.
- 1.21.5-gke.1300 ou ultérieure.
- 1.20.13-gke.1000 ou ultérieure.
- 1.19.16-gke.8700 ou ultérieure.
Atténuation
Pour résoudre ce problème, utilisez l'une des solutions suivantes :
Activez NodeLocal DNSCache.
Désactivez la visibilité intranœud.
Sérialisez les résolutions DNS en ajoutant le champ
single-request
ousingle-request-reopen
au fichier manifeste de votre pod :dnsConfig: options: - name: single-request
Cette solution de contournement n'est applicable qu'aux pods autres que Alpine. Vous devez appliquer cette modification à chaque pod.
Réduisez l'expansion du chemin de recherche en définissant l'option
ndots
dans le fichier manifeste de votre pod sur une valeur faible, telle que 2 :dnsConfig: options: - name: ndots value: "2"
Vous pouvez également définir
ndots
sur 0 pour éviter l'extension du chemin de recherche. Si vous désactivez l'extension du chemin de recherche, le pod effectue des recherches sur tous les noms de services à l'aide du nom de domaine complet. Les recherches similaires àkubernetes.default
ne fonctionnent pas. Vous devez utiliser un nom de domaine complet semblable àkubernetes.default.svc.cluster.local
.
Étape suivante
- Apprenez à contrôler la communication entre les pods et les services de votre cluster en créant une stratégie réseau pour un cluster.
- Découvrez les avantages des clusters de VPC natif.