A Support Flag Is Not Your Upgrade Decision
A support indicator and an upgrade decision answer different questions. A delayed label should not be allowed to become an undocumented reason to postpone maintenance.
Istio’s 9 September notice announced 12 October as 1.29’s support deadline. The table still said Yes and Expected at our 12 October, 17:10 Madrid and 15 October checks. At our 18 October check, it showed No and 15 October. The 16 October final notice confirms security and critical-bug backports have ended. The date conflict remains unexplained.
Keep the evidence and the decision separate
The completed support state resolves the flag, not the date difference. Keep the earlier notice and observations alongside the final announcement and current table. They preserve what an operator could know at each point, without inventing an extra maintenance commitment.
Consider a hypothetical change review. One owner has the end-of-support notice; another has a green entry in a dashboard copied from the table. Recording which source each used exposes the disagreement. It does not require either person to pretend the sources agreed, and it makes the reason for proceeding or deferring reviewable.
Check the path, not just the destination
Inventory control-plane and data-plane revisions, cluster owners, Kubernetes versions, installation methods, extensions and rollback paths. Istio says the data plane cannot lead the control plane and recommends matching revisions. Check the target’s patched build and supported Kubernetes range against the cluster.
The 1.31 announcement also moved charts and other release artefacts to new hosting locations while retaining Docker Hub images. It scheduled a Google Cloud artefact shutdown test for 13 October, 15:00 to 18:00 UTC. That window has passed. The announcement is a test schedule, not proof that it ran or that a particular pipeline succeeded.
The practical check is the installation path your team would use during an urgent rebuild. A current image in one registry does not demonstrate that the chart, download script or cached dependency used by a separate job is available. Rehearse that path with the same source references the recovery procedure expects to use.
Close the change with an operating result
BlackTree’s operational assessment is to agree success criteria before moving workloads. A rehearsal should exercise policy, traffic, telemetry, gateways and rollback, with a named owner for failures. Keep the decision to accept the target separate from the later evidence that the intended revisions are actually running.
A useful handover says what changed, which checks passed, what remains unresolved and when the next review is due. It should not ask the next shift to reconstruct approval from a support flag or a successful command. These are operating recommendations, not a claim that a specific cluster has been tested or upgraded.
Sources: 1.29 support announcement; final support notice; support and skew policy; 1.31 release announcement.
Lifecycle record: Istio 1.29 support boundary.
