Airbnb a réussi à mettre à jour son maillage de service Istio 14 fois, gérant des dizaines de milliers de pods répartis sur des dizaines de clusters Kubernetes et des milliers de machines virtuelles. Le processus de mise à jour priorise la absence de temps d'arrêt et les déploiements graduels, permettant des mises à jour indépendantes sans intervention utilisateur. L'architecture comprend un cluster de gestion pour Istiod et plusieurs clusters de charge de travail. Les mises à jour suivent un modèle de canari, exécutant les versions actuelles et nouvelles d'Istio en parallèle.Cela est rendu possible en coordonnant les mises à jour du plan de contrôle (Istiod) et du plan de données (istio-proxy). De manière cruciale, les anciennes versions d'istio-proxy ne sont pas utilisées avec les nouvelles versions d'Istiod ; elles sont mises à jour de manière atomique. Un fichier de gestion central, rollouts.yml, définit la distribution souhaitée des versions d'Istio dans les espaces de nom. Pour Kubernetes, un outil maison appelé Krispr injecte des étiquettes de révision Istio dans les déploiements pendant la CI et l'admission de pod.Ce mécanisme garantit que les charges de travail sont mises à jour même si elles ne sont pas déployées fréquemment. Pour les machines virtuelles, les mises à jour sont gérées par un démon d'hôte, mxagent, qui installe des artefacts en fonction des balises de VM. Un contrôleur central, mxrc, met à jour ces balises pour les aligner avec rollouts.yml. Mxrc surveille également la santé des VM, garantissant un processus de mise à jour contrôlé. Cette approche découple efficacement les mises à jour d'infrastructure des déploiements d'application. L'investissement continu d'Airbnb dans la maintenabilité et la sécurité a rendu possible ces mises à jour complexes et à grande échelle d'Istio.