Configurer la visibilité intranœud

Ce guide explique comment configurer la visibilité intranœud dans un cluster Google Kubernetes Engine (GKE) afin que tout le trafic réseau de votre cluster soit visible par le réseau Google Cloud.

La visibilité intranœud vous permet d'effectuer les opérations suivantes :

• 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 d'un même nœud.
• Utiliser la mise en miroir de paquets pour cloner le trafic entre les pods du même nœud, puis le transférer pour examen.

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 est désactivée par défaut.

La visibilité intranœud est requise si vous souhaitez que votre cluster utilise un réseau VPC dont la MTU est de 1 500 octets. De plus, le cluster doit disposer de la version 1.15 ou d'une version ultérieure de GKE. Pour en savoir plus sur les réseaux VPC avec une MTU de 1 500 octets, consultez la section Unité de transmission maximale dans la documentation sur les VPC.

Éléments à prendre en compte

Augmentation du volume des journaux

Lorsque la visibilité intranœud est activée, le volume des journaux de flux peut augmenter lorsque le trafic capturé par le VPC devient plus important. Vous pouvez gérer les coûts associés à la journalisation de flux en ajustant les paramètres de journalisation.

Tout le trafic entre pods est soumis à des pare-feu

Tout le trafic entre les pods, y compris ceux déployés sur le même nœud, est visible par le VPC lorsque la visibilité intranœud est activée. L'activation de la visibilité intranœud peut entraîner l'application de règles de pare-feu à un trafic qui ne faisait auparavant l'objet d'aucune restriction. Évaluez vos pare-feu de niveau nœud à l'aide de tests de connectivité pour vous assurer que le trafic légitime n'est pas bloqué.

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é le SDK Cloud.

Configurez les paramètres gcloud par défaut à l'aide de l'une des méthodes suivantes :

• Utilisez gcloud init pour suivre les instructions permettant de définir les paramètres par défaut.
• Utilisez gcloud config pour définir individuellement l'ID, la zone et la région de votre projet.

Utiliser gcloud init

Si le message d'erreur One of [--zone, --region] must be supplied: Please specify location s'affiche, effectuez les tâches ci-dessous.

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 à 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 pour les clusters zonaux ou une région pour les clusters régionaux ou Autopilot.

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Utiliser gcloud config

• Définissez votre ID de projet par défaut :

  gcloud config set project PROJECT_ID

• Si vous utilisez des clusters zonaux, définissez votre zone de calcul par défaut :

  gcloud config set compute/zone COMPUTE_ZONE

• Si vous utilisez des clusters Autopilot ou régionaux, définissez votre région de calcul par défaut :

  gcloud config set compute/region COMPUTE_REGION

• Mettez à jour gcloud vers la dernière version :

  gcloud components update

Remarque : Vous pouvez remplacer ces paramètres par défaut dans les commandes gcloud à l'aide des options --project, --zone et --region.

Présentation de la liste de tâches

Voici un aperçu des tâches que vous devez effectuer pour configurer la visibilité intranœud :

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 pour lequel la visibilité intranœud est activée.
3. Créer deux pods dans votre cluster.
4. Envoyer une requête HTTP d'un pod à l'autre.
5. Afficher l'entrée du journal de flux pour la requête de pod à pod.

Les exemples dans ce guide utilisent :

• us-central1 comme région par défaut ;
• us-central1-a comme zone par défaut.

Activer des journaux de flux pour un sous-réseau

Vous pouvez activer les journaux de flux pour un sous-réseau à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

1. Activez les journaux de flux pour le sous-réseau par défaut dans la région us-central1 :

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

2. Vérifiez que les journaux de flux sont activés pour votre sous-réseau :

   gcloud compute networks subnets describe default --region us-central1
   

   Le résultat de la commande montre que les journaux de flux sont activés :

   ...
   enableFlowLogs: true
   ...
   ipCidrRange: 10.128.0.0/20
   region: https://www.googleapis.com/compute/v1/projects/abc-712099/regions/us-central1
   

Console

1. Accédez à la page "Réseaux VPC de Google Kubernetes Engine" dans Cloud Console.

   Accéder à la page Réseaux VPC

2. Dans la ligne us-central1, cliquez sur Par défaut.

3. Sur la page Détails du sous-réseau, cliquez sur Modifier.

4. Sous Journaux de flux, sélectionnez Activé.

5. Cliquez sur Enregistrer.

Activer la visibilité intranœud lors de la création d'un cluster

Vous pouvez créer un cluster dans lequel la visibilité intranœud est activée à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

Créez un cluster à nœud unique pour lequel la visibilité intranœud est activée :

gcloud container clusters create cluster-name \
    --zone us-central1-a \
    --num-nodes 1 \
    --enable-intra-node-visibility

Console

1. Accédez au menu Google Kubernetes Engine de Cloud Console.

   Accéder au menu Google Kubernetes Engine

2. Cliquez sur Créer.

3. Saisissez le nom de votre cluster.

4. Pour le type d'emplacement, sélectionnez Zonal.

5. Dans la liste déroulante Zone, sélectionnez us-central1-a.

6. Dans le volet de navigation, cliquez sur default-pool sous Pools de nœuds.

7. Saisissez un nom pour le pool de nœuds.

8. Pour les nœuds de version statique, choisissez la Version du nœud.

9. Dans le champ Nombre de nœuds, saisissez 1.

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

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

12. Cliquez sur Créer.

Obtenir les identifiants d'un cluster

Obtenez les identifiants pour votre nouveau cluster :

gcloud container clusters get-credentials cluster-name \
    --zone us-central1-a

Les identifiants sont enregistrés dans votre fichier kubeconfig, qui se trouve généralement dans $HOME/.kube/config.

Créer deux pods

1. Pour le premier pod, créez un fichier nommé pod-1.yaml basé sur l'exemple de fichier manifeste suivant :

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-1
   spec:
     containers:
     - name: container-1
       image: gcr.io/google-samples/hello-app:2.0
   

2. Créez le pod en exécutant la commande suivante :

   kubectl apply -f pod-1.yaml
   

3. Pour le second pod, créez un fichier nommé pod-2.yaml basé sur l'exemple de fichier manifeste suivant :

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-2
   spec:
     containers:
     - name: container-2
       image: gcr.io/google-samples/node-hello:1.0
   

4. Créez le pod en exécutant la commande suivante :

   kubectl apply -f pod-2.yaml
   

5. Affichez les pods :

   kubectl get pod pod-1 pod-2 --output wide
   

   Le résultat affiche les adresses IP de vos pods. Notez ces adresses.

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

Envoyer une requête de pod-1 à pod-2

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
   

   où pod-2-ip-address est l'adresse IP de pod-2 que vous avez notée précédemment.

   Le résultat affiche la réponse du conteneur en cours d'exécution dans pod-2 :

   Hello Kubernetes!
   

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

Vous pouvez afficher les entrées du journal de flux à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

Affichez une entrée de journal de flux pour la requête envoyée de pod-1 à pod-2 :

gcloud logging read \
    'logName="projects/project-id/logs/compute.googleapis.com%2Fvpc_flows" AND jsonPayload.connection.src_ip="pod-1-ip-address"'

où :

• project-id est l'ID de votre projet.
• pod-1-ip-address est l'adresse IP de pod-1.

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

Console

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

   Accéder à la page des journaux Stackdriver

2. Dans le champ de filtre, cliquez sur , puis sur Convertir en filtre avancé.

3. Remplacez le texte du champ de filtre par ce qui suit :

   resource.type="gce_subnetwork"
   logName="projects/project-id/logs/compute.googleapis.com%2Fvpc_flows"
   jsonPayload.connection.src_ip="pod-1-ip-address"
   

   Remplacez l'élément suivant :

   • project-id est l'ID de votre projet.
   • pod-1-ip-address est l'adresse IP de pod-1.

4. Développez l'entrée de journal qui s'affiche. Sous jsonPayload, vous pouvez voir que la requête a été envoyée de pod-1 à pod-2. Dans l'exemple suivant, l'adresse IP de pod-1 est 10.56.0.13 et celle de pod-2 est 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
   

Rappelez-vous que votre cluster ne comporte qu'un seul nœud. pod-1 et pod-2 se trouvent donc sur le même nœud. Même dans ce cas, le journal de flux contient des entrées pour la communication intranœud entre pod-1 et pod-2.

Activer la visibilité intranœud sur un cluster existant

Vous pouvez activer la visibilité intranœud pour un cluster existant à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

gcloud beta container clusters update cluster-name \
    --enable-intra-node-visibility

où cluster-name est le nom du cluster existant.

Console

1. Accédez au menu Google Kubernetes Engine de Cloud Console.

   Accéder au menu 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, à côté du champ Visibilité intranœud, cliquez sur Modifier la visibilité intranœud.

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

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

Lorsque vous activez la visibilité intranœud pour un cluster existant, les composants du plan de contrôle et des nœuds de calcul sont redémarrés.

Avertissement : Si vous utilisez des intervalles de maintenance, la visibilité intranœud n'est pas activée tant qu'un intervalle de maintenance n'a pas eu lieu. Pour éviter d'attendre, vous pouvez "mettre à jour" manuellement le pool de nœuds avec la version déjà utilisée en définissant l'option --cluster-version sur la même version GKE que celle que le plan de contrôle exécute. Si vous optez pour cette solution, vous devez exécuter la commande gcloud. Pour en savoir plus, consultez la section Mises en garde de la documentation sur les intervalles de maintenance.

Une fois que vous avez activé cette fonctionnalité, vous pouvez vérifier qu'elle est active en examinant les règles de routage de votre nœud :

1. Affichez les règles des adresses IP :

   ip rule show
   

   Le résultat ressemble à ceci :

   0:  from all lookup local
   30001:  from all fwmark 0x4000/0x4000 lookup main
   30002:  from all iif lo lookup main
   30003:  not from all iif eth0 lookup 1
   32766:  from all lookup main
   32767:  from all lookup default
   

2. Affichez les routes des adresses IP :

   ip route show table 1
   

   Le résultat ressemble à ceci :

   default via GKE-node-subnet-gw dev eth0
   

Désactiver la visibilité intranœud

Vous pouvez désactiver la visibilité intranœud pour un cluster existant à l'aide de l'outil gcloud ou de Google Cloud Console.

gcloud

gcloud beta container clusters update cluster-name \
    --no-enable-intra-node-visibility

où cluster-name est le nom du cluster existant.

Console

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

   Accéder à la page 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, à côté du champ Visibilité intranœud, 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).

Lorsque vous désactivez la visibilité intranœud pour un cluster existant, les composants du plan de contrôle et des nœuds de calcul sont redémarrés.

Avertissement : Si vous utilisez des intervalles de maintenance, la visibilité intranœud n'est pas désactivée tant qu'un intervalle de maintenance n'a pas eu lieu. Pour éviter d'attendre, vous pouvez "mettre à jour" manuellement le pool de nœuds avec la version déjà utilisée en définissant l'option --cluster-version sur la même version GKE que celle que le plan de contrôle exécute. Si vous optez pour cette solution, vous devez exécuter la commande gcloud. Pour en savoir plus, consultez la section Mises en garde de la documentation sur les intervalles de maintenance.

Restrictions

Les clusters sur lesquels la visibilité intranœud est activée sont soumis aux restrictions suivantes :

• Si vous activez la visibilité intranœud et utilisez un ip-masq-agent défini sur le paramètre nonMasqueradeCIDRs, nonMasqueradeCIDRs doit inclure le pod CIDR. Sinon, vous risquez de rencontrer des problèmes de connectivité intranœud.

Étape suivante

• Apprenez à contrôler la communication entre les pods et les services de votre cluster en créant une règle de réseau pour un cluster.

• Découvrez les avantages des plages d'adresses IP d'alias Google Cloud dans les clusters de VPC natif.