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

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 :

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

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 container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --enable-intra-node-visibility

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 container clusters update CLUSTER_NAME \
    --enable-intra-node-visibility

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 container clusters update CLUSTER_NAME \
    --no-enable-intra-node-visibility

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: google/cloud-sdk:slim
       command:
       - sh
       - -c
       - while true; do sleep 30; done
   

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 :

   curl -s 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
   

Étapes suivantes

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