14 commentaires
Salut. Quand tu as des timeouts TLS aléatoires dans un mesh, il faut regarder si ce n'est pas lié au renouvellement des certificats par l'agent local.
Check les logs de ton sidecar istio-proxy au moment du bug avec kubectl logs -c istio-proxy. Regarde si tu vois des rotations de SDS (Secret Discovery Service).
Si c'est du mTLS pur, regarde aussi la MTU de ton interface réseau. Si un paquet de handshake (souvent gros à cause de la chaîne de certs) dépasse la MTU de ton tunnel (VXLAN ou Geneve), il est fragmenté.
Si un firewall ou une policy eBPF drop les fragments, ton handshake ne finira jamais. Lance un tcpdump pour voir la taille des paquets lors du Hello.
J'ai fait la capture. Effectivement, le certificat envoyé par Vault est énorme (on a une grosse chaîne de confiance intermédiaire).
Le paquet fait 1480 octets. Ma MTU sur les interfaces veth est à 1450 à cause de l'overlay Calico. On a de la fragmentation IP.
tcpdump -i eth0 -nn -vv 'port 8200'Le kernel flaggue certains paquets avec le bit DF (Don't Fragment), donc ils sont jetés.
Bingo pour la MTU. Mais ça n'explique pas pourquoi c'est aléatoire. Normalement, si c'est trop gros, ça échouerait 100% du temps, non ?
Pas forcément. Ça dépend du chemin réseau pris par le paquet dans le mesh. Si ça passe par un gateway ou un autre node avec une config différente, ça peut changer.
Aussi, vérifie si Vault n'utilise pas des suites de chiffrement qui forcent des échanges de clés plus longs selon le client qui se connecte.
Je viens de voir un autre truc. Dans les logs de Vault, j'ai des high heartbeat latency pile au moment des timeouts TLS. Le processeur semble freezer.
[WARN] raft: heartbeat missed: last-index=123456Est-ce que le processus d'encryptage TLS pourrait bouffer tout le temps CPU et retarder Raft ?
Possible si tu es sur des instances avec peu de coeurs. Vault est très sensible à la latence I/O et CPU pour son quorum Raft.
Si Envoy sature le CPU pour déchiffrer le mTLS, Vault n'a plus assez de cycles pour répondre aux heartbeats. Tu devrais isoler les coeurs CPU pour le processus Vault.
On est sur du c6i.xlarge, on devrait être larges. J'ai lancé top pendant un incident, et j'ai des pics de sy (system) énormes. Ça sent le syscall qui bloque.
J'ai fait un strace -c -p $(pgrep vault) et je vois énormément de temps passé dans getrandom.
Attends, getrandom ? C'est le kernel qui génère de l'entropie. Si ton pool d'entropie est vide, l'appel système bloque en attendant que le kernel récolte assez de bruit hardware.
C'est un problème connu sur les VMs sans hardware RNG pass-through. Vérifie la valeur dans /proc/sys/kernel/random/entropy_avail.
La valeur descend à 128 pendant les pics de connexion. C'est ultra bas !
Le handshake TLS appelle getrandom pour générer les secrets de session, et comme le kernel n'a plus assez d'entropie, il fait stalle le thread. Ça explique les 503 et les heartbeats manqués.
C'est ça. Pour corriger ça proprement sans changer d'instance, tu peux installer rng-tools ou haveged sur tes hosts pour réalimenter le pool d'entropie artificiellement.
Ou mieux, si tu es sur un kernel récent (5.6+), le kernel utilise une implémentation basée sur Chacha20 qui ne devrait plus bloquer. Quelle est ta version de kernel ?
On est sur une vieille image Amazon Linux 2 avec un kernel 4.14. On est en plein milieu d'une migration, mais on n'y est pas encore.
J'ai testé d'activer rngd sur un des noeuds :
systemctl start rngd
cat /proc/sys/kernel/random/entropy_availC'est remonté à 3000 instantanément.
On a lancé 50 jobs en parallèle, zéro erreur. C'était bien la combinaison d'un kernel ancien et d'une forte demande en entropie pour le mTLS qui flinguait Vault.
Je vais packager rngd dans notre AMI de base pour tous les noeuds Vault. Merci pour l'aiguillage sur les syscalls, j'étais parti beaucoup trop loin sur le réseau Istio !
Laisser une réponse
Vous devez être connecté pour poster un message !
On rencontre un souci super pointu sur notre cluster Vault. On a activé le mTLS partout via Istio.
Aléatoirement, les requêtes vers Vault (API port 8200) tombent en timeout au niveau du handshake TLS. Côté client, on voit des
upstream connect error or disconnect/reset before headers.C'est très frustrant car 99% du trafic passe sans souci, mais on a environ 0.5% d'erreurs qui font sauter nos pipelines CI/CD.