Skip to content

UID2-7589: bump AKS E2E Kubernetes version from 1.33 to 1.36 - #258

Merged
cYKatherine merged 1 commit into
mainfrom
kchen-UID2-7589-aks-k8s-version
Jul 29, 2026
Merged

UID2-7589: bump AKS E2E Kubernetes version from 1.33 to 1.36#258
cYKatherine merged 1 commit into
mainfrom
kchen-UID2-7589-aks-k8s-version

Conversation

@cYKatherine

Copy link
Copy Markdown
Contributor

What

Bumps the hardcoded --kubernetes-version in scripts/aks/start_aks_cluster.sh from 1.33 to 1.36.

Why

The nightly scheduled Publish All Operators workflow in uid2-operator has failed on 2026-07-28 and 2026-07-29 in the Azure Private Operator / E2E Azure AKS / E2E Test job, at the Start AKS cluster step. Every other job in the pipeline passes — the failure is isolated to AKS cluster creation:

ERROR: (K8sVersionNotSupported) Managed cluster opr-e2e-cluster-10737571 is on version
1.33.13, which is only available for Long-Term Support (LTS). To enable LTS on the
cluster, see https://aka.ms/aks/enable-lts. Otherwise, use [az aks get-versions] command
to get the supported version list in this region.
Code: K8sVersionNotSupported

AKS gives each minor version 12 months of standard support after GA. 1.33 went GA in Jun 2025 and reached end of life in Jul 2026 — i.e. right now — so it has dropped to LTS-only and az aks create rejects it outright. Nothing changed on our side; this is Azure's support calendar catching up with a stale pin.

Why 1.36 and not 1.34

Per the AKS supported versions calendar:

Version AKS GA End of life
1.33 Jun 2025 Jul 2026 (now LTS-only)
1.34 Nov 2025 Nov 2026
1.35 Mar 2026 Mar 2027
1.36 Jun 2026 Jun 2027
1.37 Oct 2026 not yet GA

1.34 is the smallest bump but expires in ~4 months, which would reintroduce this exact failure almost immediately. 1.36 is the latest GA release and buys ~11 months.

Risk

Low. The E2E cluster is created fresh per workflow run (opr-e2e-cluster-<run-id>) and torn down afterwards, so there is no in-place cluster upgrade to coordinate and no persistent state to migrate. This is the only hardcoded occurrence of the Kubernetes version across uid2-shared-actions and uid2-operator. CI-only change — no client-facing impact.

The remaining az aks create flags (--network-plugin azure, --network-policy calico, --node-vm-size Standard_D4d_v5, --auto-upgrade-channel patch, --os-sku Ubuntu) are all still valid on 1.36. Note --auto-upgrade-channel patch only tracks patches within a minor, so it does not protect against minor-version retirement — hence the pin still needs periodic bumping, which the added comment records.

Considered and rejected

Resolving the version dynamically from az aks get-versions would be self-healing, but makes the E2E Kubernetes version shift between runs, which undermines reproducibility when debugging an operator failure. Keeping a deterministic pin with an explicit expiry note was preferred.

Testing

  • bash -n scripts/aks/start_aks_cluster.sh passes.
  • Real verification is a green Azure Private Operator / E2E Azure AKS / E2E Test job — will confirm against a run of Publish All Operators once this merges, since the workflow consumes this script from the default branch.

Ticket: UID2-7589

🤖 Generated with Claude Code

The nightly Publish All Operators workflow has been failing since 2026-07-28
in the Azure Private Operator / E2E Azure AKS / E2E Test job, at the
Start AKS cluster step:

  ERROR: (K8sVersionNotSupported) Managed cluster opr-e2e-cluster-10737571 is
  on version 1.33.13, which is only available for Long-Term Support (LTS).

AKS gives each minor version 12 months of standard support after GA. 1.33
went GA in Jun 2025 and reached end of life in Jul 2026, so it is now
LTS-only and az aks create rejects it outright.

Pinning to 1.36, the latest GA release (GA Jun 2026, EOL Jun 2027), rather
than the next version up (1.34, EOL Nov 2026) so this does not recur in four
months. The E2E cluster is created fresh per workflow run and torn down
afterwards, so there is no in-place cluster upgrade to coordinate.

Added a comment recording the recurring maintenance obligation, since a bare
version pin gives no signal that it expires.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@cYKatherine

Copy link
Copy Markdown
Contributor Author

Verified the version choice against the live E2E subscription (Pre-Production - Testing Only, 63e97a70-…) rather than relying on the published calendar alone:

$ az aks get-versions --location westus3

1.31   preview=False plans=AKSLongTermSupport                       patches=['1.31.100', '1.31.13']
1.32   preview=False plans=AKSLongTermSupport                       patches=['1.32.10', '1.32.11']
1.33   preview=False plans=AKSLongTermSupport                       patches=['1.33.12', '1.33.13']
1.34   preview=False plans=KubernetesOfficial,AKSLongTermSupport    patches=['1.34.0' … '1.34.9']
1.35   preview=False plans=KubernetesOfficial,AKSLongTermSupport    patches=['1.35.0' … '1.35.6']
1.36   preview=False plans=KubernetesOfficial,AKSLongTermSupport    patches=['1.36.0', '1.36.1', '1.36.2']

This confirms both halves of the change:

  • Root cause. 1.33 now offers AKSLongTermSupport only — the KubernetesOfficial (standard support) plan is gone. That is exactly what az aks create rejects with K8sVersionNotSupported, so the failure is fully explained by the support-plan transition and not by anything in our config.
  • Target. 1.36 carries KubernetesOfficial, is not preview, and is available in westus3 with patches up to 1.36.2. 1.37 is not offered in this region at all, so 1.36 is the latest usable GA release here.

@cYKatherine
cYKatherine merged commit 1804b3a into main Jul 29, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants