中文
devexamples
← Workflows

阅读中文版本

Service Mesh Upgrade Workflow

Upgrade the control plane and data plane in stages, verify compatibility, watch for sidecar or ambient transition issues, and keep rollback simple.

advanced~180 minservice-meshkubernetesupgrade

Objective

Upgrade a service mesh across control and data planes with minimal disruption and a clear rollback.

Environment

  • A service mesh installation
  • Compatibility notes for the target version

Steps

1. Review compatibility between control plane, data

Review compatibility between control plane, data plane, and Kubernetes versions.

Expected state: Known incompatibilities are handled first.

2. Upgrade the control plane and verify

Upgrade the control plane and verify configuration still reconciles.

Expected state: Control plane is healthy before the data plane moves.

3. Roll the data plane gradually, verifying

Roll the data plane gradually, verifying traffic between batches.

Expected state: Sidecars upgrade without breaking traffic.

4. Keep the previous version available until

Keep the previous version available until confidence is high.

Expected state: Rollback is one step.

Decision points

Big-bang or staged data plane?

  • Staged
  • Big-bang

Staged by namespace or batch; the data plane touches every request path.

Sidecar or ambient for new workloads?

  • Pilot ambient
  • Sidecar only

Pilot ambient on low-risk workloads; validate observability and policy parity before broad adoption.

Expected outcome

Control and data planes upgraded with traffic healthy through the rollout and a tested rollback path.

Verification

Confirm error rates and latency stay normal through each data-plane batch and that the pod and sidecar versions converge.

Cleanup

Record the version transition and remove the explicit image pins after full rollout.

Overview

Upgrade a service mesh across control and data planes with minimal disruption and a clear rollback. Confirm error rates and latency stay normal through each data-plane batch and that the pod and sidecar versions converge.

Steps

  1. Review compatibility between control plane, data plane, and Kubernetes versions. Expected state: Known incompatibilities are handled first.
  2. Upgrade the control plane and verify configuration still reconciles. Expected state: Control plane is healthy before the data plane moves.
  3. Roll the data plane gradually, verifying traffic between batches. Expected state: Sidecars upgrade without breaking traffic.
  4. Keep the previous version available until confidence is high. Expected state: Rollback is one step.
istioctl x precheck
istioctl upgrade --set profile=default
kubectl rollout restart deploy -n prod

Verification

  • Control and data planes upgraded with traffic healthy through the rollout and a tested rollback path.

Decision points

  • Big-bang or staged data plane? Options: Staged; Big-bang. Recommended: Staged by namespace or batch; the data plane touches every request path.
  • Sidecar or ambient for new workloads? Options: Pilot ambient; Sidecar only. Recommended: Pilot ambient on low-risk workloads; validate observability and policy parity before broad adoption.