Les pods GKE ont perdu l’accès au VPN après la 1.14 : deux façons de corriger la source

Une mise à jour arrive, et les systèmes de l’autre côté du tunnel commencent à rejeter le trafic des pods qui fonctionnait la semaine précédente. Le tunnel est monté, les règles de pare-feu sont intactes, et personne n’a modifié la politique du pair. Ce qui a changé est invisible dans les journaux du cluster : l’adresse source que ces systèmes voient désormais. Cet écart explique une panne qui ressemble à une coupure réseau et se comporte comme un problème de permissions.

Il existe deux réponses valables, et elles mènent à des endroits différents. Choisissez le contrat de source avant de modifier une ConfigMap.

La règle par défaut qui n’est plus installée

Les anciennes versions de GKE installaient une règle de masquerade qui remplaçait les sources des pods par l’adresse du nœud dès que la destination se trouvait hors de 10.0.0.0/8. Une passerelle VPN dans cette plage voyait l’adresse du pod, tandis que tout ce qui était plus loin semblait venir du nœud. Les pairs ont bâti des listes d’autorisation et des routes de retour autour des adresses de nœuds parce que c’est ce qu’ils observaient.

Les versions suivantes ont cessé d’installer cette règle par défaut. Le trafic des pods arrive maintenant à la passerelle avec des adresses de pods, quelle que soit la destination. Un pair qui ne route que les adresses de nœuds rejette les réponses, et aucun des deux côtés n’écrit d’entrée de journal utile. La requête peut même réussir à l’extrémité distante, et c’est ce qui rend la panne difficile à traquer.

Rien n’est cassé au sens d’un composant mort. Les deux côtés ne sont simplement pas d’accord sur la source légitime.

Choisissez la source que le pair doit voir

Conserver les adresses de pods est le contrat le plus précis. Le côté distant voit la charge de travail qui a produit le trafic, la journalisation reste honnête et une politique par pod devient possible. Le prix est que le pair doit porter le préfixe des pods.

Conserver les adresses de nœuds est le contrat le moins coûteux. Réactivez le masquerade pour cette destination et le pair continue de voir une adresse à laquelle il fait déjà confiance.

Une question tranche entre les deux : que fait le pair de la source ? S’il journalise, applique une politique par source ou impose un routage de retour étroit, les adresses de pods justifient la configuration supplémentaire. S’il a seulement besoin d’envoyer des réponses, le masquerade coûte moins cher et ne demande rien à l’autre côté. Chaque choix se défend tant que les deux équipes l’écrivent.

Une troisième option est généralement une erreur : tout masquer et perdre la capacité d’attribuer le trafic. Évitez-la, sauf si un pair ne peut vraiment router rien d’autre que des adresses de nœuds.

Pointez nonMasqueradeCIDRs vers les vraies plages

GKE exécute l’ip-masq-agent dans kube-system, et sa ConfigMap liste les destinations qui évitent le masquerade. Pour préserver les sources des pods vers le tunnel, la plage des pods, le sous-réseau des nœuds et le préfixe local figurent tous dans cette liste.

Remplacez les valeurs d’exemple par des plages de votre propre cluster. Ne rendez pas la liste plus large que ne l’exige le besoin, car chaque entrée supplémentaire change ce que voit une autre destination. Les trois entrées ci-dessous représentent le réseau des pods, le sous-réseau des nœuds et le préfixe derrière le tunnel :

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Une entrée 0.0.0.0/0 désactive le masquerade pour toutes les destinations, ce qui modifie la façon dont des charges de travail sans rapport apparaissent aux services externes et est rarement voulu. L’agent relit sa configuration à resyncInterval, donc un redémarrage est généralement inutile. Vérifiez que le pod de l’agent tourne, puis ouvrez le fichier monté à l’intérieur. C’est la lecture de ce fichier qui prouve que le changement est arrivé.

Le chemin de retour est l’autre moitié

Le masquerade modifie la source de la requête et rien d’autre. Quelle que soit la source que le pair reçoit, il a toujours besoin d’une route vers elle, et le cluster a toujours besoin d’une route vers le pair.

Une capture sur la passerelle VPN sépare rapidement les deux défaillances. Des paquets qui arrivent avec des adresses de pods et ne reçoivent jamais de réponse signifient que le pair n’a pas de route pour le préfixe des pods. Une réponse qui apparaît sur la passerelle mais n’atteint jamais le cluster signifie que la route locale manque. Inscrivez le contrat dans le ticket dans tous les cas : quelle source le pair voit, et vers quel préfixe il renvoie.

Revérifiez après chaque mise à jour

Le comportement par défaut du masquerade a déjà changé une fois, et le remplacement d’un pool de nœuds peut réinitialiser le réseau du cluster. Traitez le contrat de source comme quelque chose à vérifier et non à supposer.

Après une mise à jour, envoyez une requête depuis un pod vers un service local et lisez la source que le pair journalise. Cette seule observation attrape une régression qu’une page d’état du tunnel signalerait volontiers comme saine. La répéter coûte une minute et épargne une soirée à la personne suivante.