Configurer la visibilité intranœud

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ètre nonMasqueradeCIDRs, vous devez inclure la plage CIDR du pod dans nonMasqueradeCIDRs 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.

gcloud init

1. 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

2. Suivez les instructions pour autoriser gcloud CLI à utiliser votre compte Google Cloud.
3. Créez ou sélectionnez une configuration.
4. Choisissez un projet Google Cloud.
5. Choisissez une zone Compute Engine par défaut.
6. Choisissez une région Compute Engine par défaut.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans gcloud CLI en utilisant les options --project, --zone et --region.

gcloud config

1. Définissez votre ID de projet par défaut :

   gcloud config set project PROJECT_ID

2. Définissez votre région Compute Engine par défaut (par exemple, us-central1) :

   gcloud config set compute/region COMPUTE_REGION

3. Définissez votre zone Compute Engine par défaut (par exemple, us-central1-c) :

   gcloud config set compute/zone COMPUTE_ZONE

4. Mettez à jour gcloud vers la dernière version :

   gcloud components update

Remarque : Vous pouvez remplacer ces paramètres par défaut dans gcloud CLI en utilisant les options --project, --zone et --region.

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 cluster
• COMPUTE_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 :

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

   Accéder à Google Kubernetes Engine

2. Cliquez sur  Créer.

3. Saisissez le nom de votre cluster.

4. Dans la boîte de dialogue Configurer le cluster, à côté de GKE standard, cliquez sur Configurer.

5. Configurez le cluster selon vos besoins.

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

7. Cochez la case Activer la visibilité intranœud.

8. 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 :

1. Accédez à la page Google Kubernetes Engine dans 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, cliquez sur  Modifier la visibilité intranœud.

4. Cochez la case Activer la visibilité intranœud.

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

Avertissement : Lorsque vous activez la visibilité intranœud, GKE respecte les intervalles de maintenance configurés lorsqu'il recrée les nœuds. Cela signifie que la visibilité intranœud ne sera pas opérationnelle sur le cluster avant le prochain intervalle de maintenance. Pour éviter d'attendre, vous pouvez mettre à niveau manuellement le pool de nœuds en définissant l'option --cluster-version sur la même version de GKE que celle que le plan de contrôle exécute. Pour cette solution, vous devez utiliser gcloud CLI. Pour en savoir plus, consultez la section Mise en garde à propos des intervalles de maintenance.

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 :

1. Accédez à la page Google Kubernetes Engine dans 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, cliquez sur  Modifier la visibilité intranœud.

4. Décochez la case Activer la visibilité intranœud.

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

Avertissement : Lorsque vous désactivez la visibilité intranœud, GKE respecte les intervalles de maintenance configurés lorsqu'il recrée les nœuds. Cela signifie que la visibilité intranœud ne sera pas désactivée avant le prochain intervalle de maintenance. Pour éviter d'attendre, vous pouvez mettre à niveau manuellement le pool de nœuds en définissant l'option --cluster-version sur la même version de GKE que celle que le plan de contrôle exécute. Pour cette solution, vous devez utiliser gcloud CLI. Pour en savoir plus, consultez la section Mise en garde à propos des intervalles de maintenance.

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 :

1. Activer les journaux de flux pour le sous-réseau par défaut dans la région us-central1.
2. Créer un cluster à nœud unique dans lequel la visibilité intranœud est activée dans la zone us-central1-a.
3. Créer deux pods dans votre cluster.
4. Envoyer une requête HTTP d'un pod à un autre.
5. Afficher l'entrée du journal de flux pour la requête de pod à pod.

Activer des journaux de flux

1. Activez les journaux de flux du sous-réseau par défaut :

   gcloud compute networks subnets update default \
       --region=us-central1 \
       --enable-flow-logs
   

2. 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

1. 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
   

2. Récupérez les identifiants de votre cluster :

   gcloud container clusters get-credentials flow-log-test \
       --zone=us-central1-a
   

Créer deux pods

1. 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
   

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f pod-1.yaml
   

3. 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
   

4. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f pod-2.yaml
   

5. 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 et pod-2.

Envoyer une requête

1. Ouvrez une interface système sur le conteneur dans pod-1 :

   kubectl exec -it pod-1 -- sh
   

2. 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 de pod-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
   

3. 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 de pod-1.
• POD_2_IP_ADDRESS : adresse IP de pod-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 :

1. Supprimez le cluster à l'aide de la commande suivante :

   gcloud container clusters delete -q flow-log-test
   

2. 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 ou single-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.