Configurer la visibilité intranœud

Autopilot Standard

---

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.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. 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 la console Google Cloud.

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 Google 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 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 la console Google Cloud.

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 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, 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 la console Google Cloud.

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 la console Google Cloud.

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