Use when the user asks about upgrading Istio, checking Istio version compatibility, planning an Istio migration, performing pre-upgrade checks, preparing for a version bump, or creating an Istio upgrade plan. Checks CRD compatibility and storage version changes, validates sidecar proxy version skew against control-plane skew limits, reviews EnvoyFilter deprecated xDS API usage and Wasm ABI compatibility, analyzes east-west gateway upgrade ordering in multi-cluster environments, assesses federation controller compatibility and trust bundle exchange, identifies breaking changes across all intermediate Istio releases, and produces a scored upgrade readiness assessment with a go/no-go recommendation and rollback strategy.
84
97%
Does it follow best practices?
Impact
96%
1.18xAverage score across 1 eval scenario
Advisory
Suggest reviewing before use
A large e-commerce platform runs Istio in a multi-primary, multi-network topology across three Kubernetes clusters: us-east, us-west, and eu-central. Each cluster runs its own istiod control plane and they communicate via East-West gateways. The platform has real-time inventory synchronization and checkout services that span cluster boundaries, so cross-cluster traffic cannot be interrupted for more than a few seconds during any maintenance window.
The current version is Istio 1.21 and the team needs to upgrade to Istio 1.22. The operations team has provided a snapshot of the current cluster state in inputs/cluster_state.txt. There is a known concern: the eu-central cluster's East-West gateway was last upgraded several months ago and may be running an older image.
Your task is to produce a detailed, actionable upgrade execution plan that the ops team can follow step by step during the maintenance window. The plan should account for the multi-cluster topology and ensure cross-cluster traffic remains available throughout.
Produce a file called upgrade_plan.md containing: