Airbnb hat erfolgreich sein Istio Service Mesh 14 Mal aktualisiert und verwaltet dabei Zehntausende von Pods über Dutzende von Kubernetes-Clustern und Tausende von VMs. Ihr Aktualisierungsprozess priorisiert Nullausfallzeiten und schrittweise Rollouts, die unabhängige Aktualisierungen ohne Benutzereingriffe ermöglichen. Die Architektur umfasst einen Management-Cluster für Istiod und mehrere Workload-Cluster. Aktualisierungen folgen einem Canary-Modell, bei dem aktuelle und neue Istio-Versionen gleichzeitig ausgeführt werden.Dies wird durch die Koordinierung von Control Plane (Istiod) und Data Plane (istio-proxy) Updates erreicht. Entscheidend ist, dass ältere istio-proxy-Versionen nicht mit neueren Istiods verwendet werden; sie werden atomar aktualisiert. Eine zentrale Management-Datei, rollouts.yml, diktiert die gewünschte Verteilung der Istio-Versionen über Namespaces hinweg. Für Kubernetes injiziert ein Inhouse-Tool namens Krispr während der CI und der Pod-Aufnahme Istio-Revisionslabels in Deployments.Dieser Mechanismus stellt sicher, dass Workloads aktualisiert werden, auch wenn sie nicht häufig eingesetzt werden. Für virtuelle Maschinen werden Aktualisierungen von einem On-Host-Daemon, mxagent, verwaltet, der Artefakte basierend auf VM-Tags installiert. Ein zentraler Controller, mxrc, aktualisiert diese Tags, um sie mit rollouts.yml abzugleichen. Mxrc überwacht auch die VM-Gesundheit und gewährleistet einen kontrollierten Aktualisierungsprozess. Dieser Ansatz entkoppelt effektiv Infrastrukturaktualisierungen von Anwendungsdeployments. Airbnbs kontinuierliche Investitionen in Wartbarkeit und Sicherheit haben diese komplexen, groß angelegten Istio-Aktualisierungen ermöglicht.