Airbnb는 성공적으로 Istio 서비스 메시를 14회 업그레이드했으며, 수십 개의 Kubernetes 클러스터와 수천 대의 VM에 걸쳐 수만 개의 파드를 관리했습니다. 그들의 업그레이드 프로세스는 제로 다운타임과 점진적인 롤아웃을 우선시하며, 사용자 개입 없이 독립적인 업그레이드를 가능하게 합니다. 아키텍처는 Istiod를 위한 관리 클러스터와 여러 워크로드 클러스터를 포함합니다. 업그레이드는 현재 및 새 Istio 버전을 동시에 실행하는 카나리 모델을 따릅니다.이는 컨트롤 플레인(Istiod) 및 데이터 플레인(istio-proxy) 업데이트를 조정하여 달성됩니다. 중요한 점은 이전 istio-proxy 버전은 최신 Istiod와 함께 사용되지 않으며, 원자적으로 업데이트된다는 것입니다. 중앙 관리 파일인 rollouts.yml은 네임스페이스에 걸쳐 원하는 Istio 버전 배포를 지시합니다. Kubernetes의 경우, Krispr라는 자체 도구가 CI 및 파드 승인 중에 배포에 Istio 개정 레이블을 삽입합니다.이 메커니즘은 자주 배포되지 않는 워크로드도 업그레이드를 보장합니다. 가상 머신(VM)의 경우, 업그레이드는 VM 태그에 따라 아티팩트를 설치하는 온-호스트 데몬인 mxagent에 의해 관리됩니다. 중앙 컨트롤러인 mxrc는 rollouts.yml에 맞게 이러한 태그를 업데이트합니다. Mxrc는 또한 VM 상태를 모니터링하여 통제된 업그레이드 프로세스를 보장합니다. 이 접근 방식은 인프라 업그레이드와 애플리케이션 배포를 효과적으로 분리합니다. Airbnb의 지속적인 유지보수 및 안전 투자는 이러한 복잡하고 대규모 Istio 업그레이드를 가능하게 했습니다.