mTLS Istio 503 intermitents après mise à jour cluster

Question

bonjour à tous après la dernière mise à jour de notre cluster k8s et istio vers 1.18 on a des 503 randomly sur certains calls entre services qui utilisent mTLS les logs istio-proxy sont pas super clairs ça parle de handshake failed ou de no healthy upstream. avant la maj c'était nickel# un bout des logs istio-proxy
[2023-10-27T10:00:00.123456Z] "GET /api/data HTTP/1.1" 503 - - "-" 0 92 10 9 "-" "curl/7.81.0" "a1b2c3d4e5" "10.42.0.1:8080" "10.42.0.2:9080" PASSTHROUGH_CLUSTER - -

helene93 · Answer

503 avec mTLS qui foire ça sent le certificat invalide ou expiré entre services. t'as vérifié les secrets kubernetes pour les certs istio c'est géré par citadel/istiod non

qriou · Answer

oui istiod gère ça les secrets sont à jour selon kubectl get secret istio.default -o yaml | grep 'creationTimestamp' ça correspond aux dates de rotation

helene93 · Answer

ok donc pas un cert expiré. est-ce que tu as des gateways ou des sidecars qui n'ont pas la bonne config de trust domain ou qui n'ont pas pu refresh leurs secrets

qriou · Answer

on a vérifié le trust domain c'est bon. par contre certains pods ont été redémarrés et d'autres non est-ce que ça peut être un souci de versioning entre anciens et nouveaux proxies

helene93 · Answer

absolument ça c'est une piste sérieuse. si tu as des proxys qui tournent encore avec une config de l'ancienne version ou qui n'ont pas bien rechargé les certs après la maj ça peut causer des problèmes de négociation TLS

qriou · Answer

donc la solution serait un redémarrage complet de tous les pods ou un istioctl proxy-config secret pour forcer le refresh

helene93 · Answer

un redémarrage des workloads est plus safe pour s'assurer que tous les sidecars ont bien la dernière config et les certs. ou si tu peux utiliser rollout restart deployment sur tous les deployments qui utilisent le mesh

qriou · Answer

ok on va faire un `kubectl rollout restart deployment -n ` sur les namespaces concernés. ça va impacter la prod mais au moins ça va nettoyer

helene93 · Answer

pendant le redémarrage surveille attentivement les logs des istio-proxy dans les pods qui redémarrent. tu peux augmenter le niveau de log de l'envoy pour avoir plus de détails sur le handshake TLS `istioctl proxy-config log  --level tls:debug`

qriou · Answer

bonne idée pour le debug level. on a fait un rollout restart sur les services impactés. les 503 sont beaucoup moins fréquents maintenant mais persistent encore un peu sur un service précis

helene93 · Answer

un service précis ? est-ce que ce service a une config spéciale un peerauthentication ou un destinationrule avec une politique mtls spécifique qui est peut-être en conflit avec la nouvelle version d'istio

qriou · Answer

bingo ! on a un DestinationRule sur ce service qui forçait TLS_AUTO_CLIENT au lieu de ISTIO_MUTUAL pour une raison obscure une relique de l'ancienne config. j'ai corrigé ça

helene93 · Answer

ah voilà ! les reliques de config c'est la plaie en service mesh surtout après une upgrade majeure. tls_auto_client c'est pour du trafic externe ou non-mesh pas pour la communication intra-mesh qui doit être istio_mutual

qriou · Answer

clairement. après avoir corrigé le DestinationRule et un dernier rollout restart tout est rentré dans l'ordre plus aucun 503. merci infiniment pour l'aide j'aurais pas pensé à cette config déterrée

helene93 · Answer

nickel ! good job. les erreurs mTLS sont les plus chieuses à debugger quand les logs sont pas assez verbaux

qriou · Answer

totalement. la prochaine fois je regarderai les DestinationRule en premier. thx encore

mTLS Istio 503 intermitents après mise à jour cluster

16 commentaires

Laisser une réponse

Les packages dans le langage de programmation Go

Créer ses propres images Docker avec le Dockerfile

Les différents objets et composants de Kubernetes

Blindez votre DevOps : Sécurité de la Chaîne Logicielle

DevOps Agentique : L'Ère des Systèmes Autonomes Intelligents

Rejoindre la communauté