Airbnbは、Istioサービスメッシュのアップグレードに14回成功し、数十のKubernetesクラスターと数千のVMにわたる数万のポッドを管理しています。彼らのアップグレードプロセスでは、ダウンタイムゼロと段階的なロールアウトを優先しており、ユーザーの介入なしに独立したアップグレードが可能です。アーキテクチャは、Istiod用の管理クラスターと複数のワークロードクラスターを含みます。アップグレードはカナリアモデルに従い、現在のIstioバージョンと新しいIstioバージョンを同時に実行します。これは、コントロールプレーン（Istiod）とデータプレーン（istio-proxy）の更新を調整することによって達成されます。重要なのは、古いistio-proxyバージョンは新しいIstiodとは使用されず、アトミックに更新されることです。中央の管理ファイルであるrollouts.ymlは、名前空間全体でのIstioバージョンの望ましい配布を指示します。Kubernetesの場合、Krisprと呼ばれる社内ツールが、CIおよびポッドアドミッション中にIstioリビジョンラベルをデプロイメントに注入します。このメカニズムにより、ワークロードは頻繁にデプロイされない場合でもアップグレードされます。仮想マシンについては、アップグレードはオンホストデーモンであるmxagentによって管理され、VMタグに基づいてアーティファクトをインストールします。中央コントローラーであるmxrcは、これらのタグをrollouts.ymlと整合するように更新します。MxrcはVMの正常性も監視し、制御されたアップグレードプロセスを保証します。このアプローチは、インフラストラクチャのアップグレードとアプリケーションのデプロイメントを効果的に分離します。Airbnbの保守性と安全性への継続的な投資は、これらの複雑で大規模なIstioアップグレードを可能にしました。