Un sidecar VPN a besoin d'une règle de démarrage et d'une règle d'échec

Un pod démarre le conteneur du tunnel avant l'application et les premières requêtes réussissent, ce qui est exactement le cas qui masque le problème. L'ordre règle une course et ne dit rien du trafic que l'application lance quatre heures plus tard, après la défaillance du tunnel. Ce sont deux décisions distinctes. En général, une seule est conçue.

L'ordre ne verrouille que la première requête

Kubernetes prend en charge un cycle de vie de sidecar construit à partir de conteneurs init redémarrables. Dans ce modèle, une sonde de démarrage peut retenir l'étape d'initialisation suivante jusqu'à ce que le tunnel signale sa disponibilité. C'est une véritable amélioration, et elle mérite d'être utilisée délibérément plutôt qu'en ajoutant un sleep à un script de point d'entrée. La barrière ne vaut que par la condition qu'elle teste.

Hors de ce modèle, la sémantique de l'ordre appartient à l'environnement d'exécution ou au système de dépendances que vous utilisez, et ils n'ont pas à correspondre. Un déploiement copié d'une autre plateforme peut sembler attendre le tunnel parce que l'application se trouve démarrer lentement. Ce n'est pas la même garantie, et il échoue sous charge.

Dites ce que la barrière observe : un processus existe, une interface existe, une poignée de main est terminée. Chacune de ces affirmations est plus faible que « le chemin de données vers les destinations dont ce pod a besoin fonctionne ».

Imposez le chemin de données au lieu de le supposer

Une sonde est un contrôle à un instant donné et un pare-feu est une propriété qui vaut entre les instants. Si l'exigence est que le trafic de l'application ne quitte jamais le tunnel, elle doit être exprimée dans l'espace de noms réseau partagé comme une règle d'accepter ou de rejeter. L'ordre de démarrage des conteneurs ne peut pas porter cette exigence. Seule une règle le peut.

Les conteneurs d'un même pod partagent cet espace de noms, le point d'application est donc l'espace de noms lui-même. Quoi que vous écriviez, cela doit laisser disponible la connexion extérieure du tunnel, car la bloquer pour protéger l'application coupe le chemin dont l'application a besoin.

Décidez explicitement la politique d'échec : le trafic de l'application doit-il s'arrêter complètement lorsque le tunnel n'est pas sain, ou continuer et être marqué comme non protégé ? Les deux se défendent, et ni l'un ni l'autre n'est ce que l'on obtient en démarrant les conteneurs dans un ordre particulier.

Testez le trafic que vous n'avez pas mentionné

Prenez une nouvelle requête pendant une panne contrôlée du tunnel et vérifiez si elle sort. Répétez ensuite le contrôle pour les chemins qu'un test d'adresse de sortie ne touche jamais : résolution DNS à l'intérieur du cluster, destinations IPv6 et services atteints par des adresses internes au cluster plutôt que par l'internet public. Ce sont ces chemins qui continuent discrètement de fonctionner après la mort du tunnel.

Une page d'adresse de sortie prouve qu'une requête est allée là où vous l'attendiez à ce moment-là. Elle ne peut pas inventorier les autres chemins, et l'écart entre ce que vous avez testé et ce que le pod peut atteindre est là où vivent les échecs intéressants.

Répétez le test après un redémarrage du sidecar, pas seulement après un démarrage propre. Un conteneur de tunnel redémarré peut laisser l'espace de noms avec des routes et une politique dans un état intermédiaire.

Écrivez l'enregistrement de déploiement

Trois faits appartiennent aux notes de déploiement : le test de disponibilité et ce qu'il observe, l'action de rétablissement lorsque ce test échoue, et la règle d'application qui régit la sortie. La documentation des conteneurs sidecar couvre la mécanique du cycle de vie et vous laisse cette décision de politique. Cette division est correcte, et c'est aussi pourquoi la politique manque souvent.

Un contrôle de santé pris pour une protection est le type d'indicateur vert le plus coûteux, car il empêche les gens de poser des questions. Le nommer précisément dans la documentation coûte une phrase et l'évite.

Enfin, testez le chemin de rétablissement une fois avec l'application en cours d'exécution. Une conception qui exige de recréer le pod pour rétablir la sortie est une décision, et elle devrait être une que vous avez prise plutôt qu'une que vous avez découverte.