mTLS Istio 503 intermitents après mise à jour cluster

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

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

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

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

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

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

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

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

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`

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

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

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

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`

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

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

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