BlackTree Security · Infrastructure · Automation · AI

Istio’s Deadline Arrived Before Its Support Flag Changed

The date has arrived; the status flag has not changed.

Istio’s advance notice, dated 9 September 2026, says support for version 1.29 ends on 12 October. At 17:10 Madrid, the live table still marked 1.29 supported and its 12 October end date expected.

Keep the two vendor signals visible

The announcement says that after the deadline the project will stop backporting security fixes and critical bug fixes to 1.29. A dated flag observation does not confirm that the transition has been completed.

Put both signals in one operational decision record: the 9 September notice, the announced 12 October deadline, the live flag and the observation time. If the flag changes later, add the new observation without replacing the original chronology.

Prepare without waiting for the label

A status lag does not remove the migration risk. Inventory control-plane and data-plane revisions, cluster ownership, Kubernetes versions, installation method, extensions and rollback paths. Verify the target’s patch and Kubernetes range.

Keep the data plane at or behind its control plane; Istio recommends matching revisions. From the 1.31 line onwards, operators must also account for changed artifact locations: images remain on Docker Hub, while charts and other release artifacts use the project’s newer hosting locations.

A planned test on 13 October, from 15:00 to 18:00 UTC, will briefly disable the old Google Cloud-hosted artifacts. Check installation and CI dependencies before that window.

Use one dated decision sequence

BlackTree recommends:

  1. Record both signals. Save the announcement date, announced deadline, live flag and observation time.
  2. Map the mesh. List every control plane, data plane, gateway, cluster and installation channel.
  3. Choose a supported target. Verify the current patch, Kubernetes range and artifact locations from official pages.
  4. Rehearse by revision. Test policy, traffic, telemetry, gateways and rollback before moving production workloads.
  5. Move in the allowed order. Keep the data plane from getting ahead of its control plane.
  6. Close on evidence. Recheck support status and record the versions running after the change.

Keep dated records rather than relying on a label alone.

Sources

Lifecycle record: Istio 1.29 support boundary.

Leave a Reply

Your email address will not be published. Required fields are marked *