Kubernetes 1.36 on Amazon EKS: The Upgrade Changes That Actually Matter

Kubernetes 1.36 is available on Amazon EKS. This operator deep dive covers its breaking changes, security and DRA features, upgrade sequence, and bounded rollback path.

TL;DR

Kubernetes 1.36 reached Amazon EKS on June 2, 2026 and remains in standard support through August 2, 2027. The upgrade permanently disables gitRepo volumes, enforces stricter IP and CIDR validation, deprecates Service externalIPs, changes SELinux volume behavior, and advances user namespaces, device health, and Dynamic Resource Allocation. Treat the control-plane update as the midpoint: inventory live objects, rehearse admission behavior, update add-ons and nodes, replace Fargate Pods, and validate workload SLOs. EKS permits rollback to the previous minor version within seven days, but it does not undo add-on, CRD, workload, or data changes.

Kubernetes 1.36 is not one change. It is a control-plane, node, workload, storage, networking, and hardware-management upgrade that must be validated layer by layer.

The Sneak Peek Is Now an Operating Decision

The March preview described what Kubernetes 1.36 might contain. That is no longer the useful question. Kubernetes 1.36 shipped upstream on April 22, 2026 with 70 enhancements—18 Stable, 25 Beta, and 25 Alpha—and Amazon EKS made it available on June 2. Platform teams now need to decide what changes at the API server, what changes only when nodes roll, and which upstream capabilities EKS exposes.

The headline is not “more features.” It is a set of sharper boundaries:

• kubelet will never mount an in-tree gitRepo volume again;
• built-in APIs reject non-canonical IP and CIDR values on new writes;
• Service.spec.externalIPs begins its path to removal;
• SELinux volume labeling changes how compatible Pods share a volume;
• user namespaces and fine-grained kubelet authorization strengthen node isolation;
• device health and DRA make accelerator failures more visible and schedulable;
• EKS now offers a bounded rollback path, but only for the managed control plane and only within seven days.

Those boundaries cross ownership lines. The EKS service team controls the managed control plane. You control manifests, admission webhooks, add-ons, node groups, Fargate workload replacement, CSI and DRA drivers, observability, and data semantics. A successful UpdateClusterVersion response proves only that the control-plane operation succeeded.

Release and support facts as of August 14, 2026:

Milestone	Date or state	Operator consequence
Upstream Kubernetes 1.36	April 22, 2026	Final release notes supersede the sneak peek.
Amazon EKS 1.36	June 2, 2026	Available for EKS control planes.
End of EKS standard support	August 2, 2027	Extended-support billing starts after this boundary.
End of EKS extended support	August 2, 2028	Remaining control planes become subject to automatic upgrade.
EKS rollback window	7 days after an eligible in-place upgrade	Recovery is time-bounded and does not revert every cluster component.

Before building an upgrade plan, query the service rather than copying a calendar into automation:

aws eks describe-cluster-versions \
  --query 'clusterVersions[?clusterVersion==`1.36`].{version:clusterVersion,status:status,release:releaseDate,standardEnd:endOfStandardSupportDate,extendedEnd:endOfExtendedSupportDate,platform:defaultPlatformVersion}' \
  --output table

Read 1.36 Through the EKS Responsibility Boundary

Upstream maturity and EKS availability are related, but they are not synonyms. AWS states that EKS supports GA Kubernetes API features, does not support alpha features, and does not enable every new beta API by default. A beta feature may also require a node-side gate, a recent EKS-optimized AMI, a container runtime capability, a CSI sidecar, or a vendor DRA driver. The managed API server cannot supply those dependencies for you.

Map every 1.36 feature to the component that implements it. Control-plane availability alone does not prove node, driver, storage, or workload readiness.

Use discovery against the target cluster instead of assuming an upstream API exists:

# What does this EKS API server actually serve?
kubectl api-resources --api-group=resource.k8s.io
kubectl api-resources | grep -Ei 'resourceclaim|deviceclass|volumegroupsnapshot'

# Which node and runtime versions will implement node-side behavior?
kubectl get nodes \
  -o custom-columns='NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,OS:.status.nodeInfo.osImage,RUNTIME:.status.nodeInfo.containerRuntimeVersion'

This distinction matters most for DRA. Kubernetes 1.36 graduates partitionable devices, consumable capacity, device taints and tolerations, and device binding conditions to beta. The EKS 1.36 notes say several DRA capabilities are enabled by default, but the scheduler cannot partition a GPU by intent alone. A compatible driver must advertise the device model and its capacity, the node must expose it, and the workload must request it through the DRA APIs.

Three Preflight Checks That Catch the Expensive Failures

1. Find gitRepo Before Kubelet Finds It

gitRepo has been deprecated since Kubernetes 1.11. Version 1.36 closes the escape hatch: the plugin is permanently disabled and cannot be re-enabled. The subtle failure mode is that the API still accepts a Pod containing the volume. Admission can succeed, scheduling can occur, and then kubelet refuses to start the Pod.

Scan the rendered Pods already running in each cluster:

kubectl get pods --all-namespaces -o json |
  jq -r '.items[]
    | select(any(.spec.volumes[]?; has("gitRepo")))
    | [.metadata.namespace, .metadata.name]
    | @tsv'

That catches live templates, but not dormant Helm values, CronJobs that have not fired, or manifests stored in Git. Scan rendered deployment output in CI as well. Replace the volume with an init container that performs a pinned checkout into an emptyDir, or use a maintained git-sync sidecar when continuous synchronization is intentional. Pin a commit SHA and verify the host key; replacing an unsafe volume with git clone main merely moves the supply-chain risk.

2. Make IP and CIDR Strings Canonical

StrictIPCIDRValidation is beta and enabled by default for fields in built-in API kinds. New creates and updates reject leading-zero IPs such as 010.000.000.005 and CIDRs with host bits such as 192.168.0.5/24. Existing stored objects remain readable through validation ratcheting, which creates an operational trap: an unrelated update to an old object can surface a previously tolerated value.

CRDs are outside this built-in validation path. Their authors must supply equivalent CEL or webhook validation.

# Rejected on a 1.36 API write
ipBlock:
  cidr: 192.168.0.5/24

# Canonical network prefix
ipBlock:
  cidr: 192.168.0.0/24

The most reliable test is not a regex over source YAML. Render overlays and charts, then submit them to a non-production 1.36 API server using server-side dry-run:

helm template payments ./charts/payments -f values.prod.yaml > rendered.yaml
kubectl --context eks-136-rehearsal apply \
  --server-side --dry-run=server -f rendered.yaml

This also exercises admission webhooks, defaulting, conversion, and API discovery against the version you will actually run.

3. Treat externalIPs Warnings as Migration Work

Kubernetes 1.36 deprecates Service.spec.externalIPs; removal is planned for 1.43. The field has long carried CVE-2020-8554 risk because a user able to create or patch a Service can intercept traffic for an external address in some network topologies.

kubectl get services --all-namespaces -o json |
  jq -r '.items[]
    | select((.spec.externalIPs // []) | length > 0)
    | [.metadata.namespace, .metadata.name, (.spec.externalIPs | join(","))]
    | @tsv'

Do not mechanically replace every result with NodePort. On EKS, the intended ownership usually determines the replacement: use a LoadBalancer Service when AWS should provision the endpoint, Gateway API when routes and policy need first-class ownership, or a deliberately firewalled node-level exposure only when the network design truly requires it.

Security: Smaller Node Privileges, Stronger Isolation

Two GA graduations matter together. User namespaces map root inside a Pod to an unprivileged UID on the host. Fine-grained kubelet authorization splits common monitoring operations away from the broad nodes/proxy permission.

A Pod opts out of the host user namespace with hostUsers: false:

apiVersion: v1
kind: Pod
metadata:
  name: userns-check
spec:
  hostUsers: false
  containers:
    - name: shell
      image: public.ecr.aws/docker/library/busybox:1.36
      command: ["sh", "-c", "id && sleep 3600"]
      securityContext:
        runAsUser: 0
        allowPrivilegeEscalation: false

Inside the container, UID 0 can remain convenient for legacy software, while the host maps it to an unprivileged identity. That is defense in depth, not permission to keep privileged Pods, hostPath mounts, host networking, or unrestricted capabilities. Validate CSI behavior, image-volume support, runtime support, UID-sensitive applications, and security policies before broad adoption.

For kubelet access, inventory subjects granted nodes/proxy before tightening RBAC:

kubectl get clusterrolebindings -o json |
  jq -r '.items[] | [.metadata.name, .roleRef.name] | @tsv' |
  while IFS=$'\t' read -r binding role; do
    kubectl get clusterrole "$role" -o json |
      jq -e '.rules[]? | select((.resources // []) | index("nodes/proxy"))' >/dev/null &&
      printf '%s\t%s\n' "$binding" "$role"
  done

Kubernetes 1.36’s fine-grained authorization lets monitoring systems request narrower kubelet subresources. Verify the exact metrics, logs, stats, or health paths each agent uses, grant only those permissions, then remove nodes/proxy. Revoking first can blind observability during the same maintenance window in which you need it most.

GPUs and Accelerators: Health Becomes a Scheduling Signal

Before resource health status, a GPU-backed Pod could crash while Kubernetes reported only application symptoms. In 1.36, the beta allocatedResourcesStatus data in container status provides a common place for Device Plugin and DRA allocations to report Healthy, Unhealthy, or Unknown state.

kubectl get pod inference-worker-0 -n ai -o json |
  jq '.status.containerStatuses[]
      | {container: .name, devices: (.allocatedResourcesStatus // [])}'

This changes incident triage. A crash loop with an unhealthy allocated device should route to node and accelerator remediation, not immediately to the application team. It also enables controllers to make better recovery decisions, but health reporting still depends on the device integration supplying status.

DRA’s beta features go further:

• Partitionable devices model a physical accelerator that can expose logical partitions.
• Consumable capacity lets claims consume part of a device-defined capacity instead of claiming a binary whole.
• Device binding conditions delay use until attachment or initialization conditions are satisfied.
• Device taints and tolerations prevent scheduling onto unsuitable or quarantined hardware.

The deep operational change is that allocation becomes a lifecycle rather than a count. Capacity planning must inspect ResourceClaims, driver inventory, allocation results, health, and cleanup—not only nvidia.com/gpu: 1. Roll out the driver and observability path before promising fractional accelerator density to tenants.

Storage: Faster SELinux Labels Need a Sharing Audit

Kubernetes 1.36 makes faster SELinux volume labeling GA. Instead of recursively relabeling every file, kubelet can mount a volume with -o context=.... Startup time becomes less sensitive to file count, but mount-time labeling also makes incompatible sharing patterns more visible.

The risk is not “SELinux might be slower.” It is two Pods on the same node expecting incompatible labels for the same volume, especially when privileged and unprivileged workloads share storage. Audit Pod templates, CSI driver capability, access modes, and co-location before the node rollout.

spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
    # Explicit compatibility escape hatch while a workload is remediated.
    seLinuxChangePolicy: Recursive

Treat Recursive as a deliberate, measured compatibility choice rather than a cluster-wide permanent default. Track Pod startup duration and kubelet SELinux warnings during the canary rollout.

Volume group snapshots also reach GA in 1.36, providing crash-consistent recovery points across multiple PVCs through CSI extension APIs. “Crash-consistent” is the critical phrase: the storage system coordinates the snapshot boundary, but the application may still need database flushing, filesystem freeze, or an application-aware hook.

# Confirm that the extension APIs and the intended CSI implementation exist.
kubectl api-resources | grep -i 'volume.*group.*snapshot'
kubectl get csidrivers

Test restore, not merely snapshot creation. A green snapshot object without a timed restore drill is storage inventory, not a recovery capability.

The EKS Upgrade Sequence That Preserves Evidence

EKS updates the control plane by launching replacement API server nodes and performing readiness checks. The operation needs up to five available IP addresses in the cluster subnets, may place replacement network interfaces in any configured cluster subnet, and cannot be paused or stopped after it starts. Check subnet capacity and security-group reachability before debating Kubernetes features.

Preserve evidence at each boundary. The managed control-plane update is step three of six, not the completion signal.

Phase 1: Inventory and Rehearse

Capture control-plane, node, add-on, and client versions. Run the three preflight scans above, review EKS upgrade insights, and replay representative writes against a 1.36 rehearsal cluster. Include admission webhooks: they must tolerate new fields and equivalent API versions.

aws eks describe-cluster --name "$CLUSTER" --region "$AWS_REGION" \
  --query 'cluster.{version:version,platform:platformVersion,status:status}'

kubectl get nodes -o wide
aws eks list-addons --cluster-name "$CLUSTER" --region "$AWS_REGION"
kubectl get --raw='/readyz?verbose'

Upgrade from 1.35 to 1.36 only. EKS and Kubernetes do not support skipping minor control-plane versions.

Phase 2: Upgrade and Observe the Control Plane

UPDATE_ID=$(aws eks update-cluster-version \
  --name "$CLUSTER" \
  --kubernetes-version 1.36 \
  --region "$AWS_REGION" \
  --query 'update.id' --output text)

aws eks describe-update \
  --name "$CLUSTER" \
  --region "$AWS_REGION" \
  --update-id "$UPDATE_ID" \
  --query 'update.{status:status,errors:errors}'

Keep API error rate, admission latency, controller work-queue depth, scheduler failures, and audit warnings visible. Client libraries must reconnect as API server addresses rotate.

Phase 3: Move Add-ons, Nodes, and Workloads Deliberately

Update EKS-managed VPC CNI, CoreDNS, and kube-proxy to versions compatible with 1.36. Then handle CSI drivers, AWS Load Balancer Controller, metrics agents, policy engines, Cluster Autoscaler, device plugins, and DRA drivers. Managed add-ons are not the whole dependency graph.

Roll a canary managed node group before the fleet. Validate image pulls, DNS, CNI allocation, storage attach/mount, SELinux behavior, log and metric collection, disruption budgets, and accelerator health. Managed and self-managed node groups do not follow the control plane automatically. Existing Fargate Pods also retain their old kubelet until replaced.

Upstream allows kubelet 1.33–1.36 behind a 1.36 API server, but the version-skew policy is a maximum envelope. Persistent three-version skew consumes your next upgrade’s safety margin. AWS recommends returning nodes to the control-plane minor version.

Rollback Is a Control-Plane Tool, Not Time Travel

EKS now documents rollback to the immediately previous Kubernetes minor version within seven days of an eligible in-place upgrade. That is valuable, but its boundary must be explicit.

EKS rolls back the API server, managed control-plane components, and platform version while preserving etcd. It does not automatically reverse EKS-managed add-on versions, self-managed add-ons, CRD schemas, Helm releases, GitOps commits, database migrations, or arbitrary node changes. Managed node groups and self-managed nodes must be compatible with the older control plane before rollback. Fargate Pods may need deletion and recreation. EKS Auto Mode coordinates its own node rollback first.

# Example: revert an eligible 1.36 cluster to 1.35.
aws eks update-cluster-version \
  --name "$CLUSTER" \
  --kubernetes-version 1.35 \
  --region "$AWS_REGION"

Rollback readiness insights check API usage, cluster health, kubelet and kube-proxy skew, and managed add-on compatibility. ERROR and UNKNOWN findings block rollback unless --force is used, but force cannot bypass the seven-day window or sequential-version requirement. Forcing past compatibility checks can preserve objects that the older control plane does not understand.

The safest recovery design therefore has two paths:

1. Control-plane regression: use the EKS rollback capability inside the eligibility window after preparing nodes and add-ons.
2. Workload or data regression: roll back GitOps or deployment state and restore data through an application-tested recovery process, whether or not the control plane changes.

Record the upgrade completion timestamp, rollback deadline, target versions for every managed component, and decision owner before production starts. A seven-day capability without a timed decision process is a seven-day surprise.

Why This Upgrade Model Works

This article organizes 1.36 by execution layer because that is where failures appear. API validation failures happen on writes. gitRepo fails at kubelet after admission. DRA needs scheduler, driver, and node agreement. SELinux behavior emerges during mount. EKS add-ons and nodes move on timelines separate from the managed API server.

The sequence also preserves diagnostic evidence. If you upgrade control plane, add-ons, nodes, drivers, and applications simultaneously, every signal changes at once and rollback becomes ambiguous. A staged rollout establishes a last-known-good boundary after each component group. It is slower on a calendar and much faster during an incident.

Kubernetes 1.36 is a worthwhile EKS target: it sharpens validation, closes a dangerous legacy volume path, strengthens node isolation, improves device diagnosis, and expands accelerator scheduling. The reliable adoption pattern is not caution for its own sake. It is controlled exposure—one layer, one hypothesis, and one observable result at a time.

Frequently Asked Questions

Q: Is Kubernetes 1.36 available on Amazon EKS?

A: Yes. Amazon EKS released Kubernetes 1.36 on June 2, 2026. AWS lists August 2, 2027 as the end of standard support and August 2, 2028 as the end of extended support. Query aws eks describe-cluster-versions before automating against those dates because support metadata can change.

Q: What can break when upgrading an EKS cluster to Kubernetes 1.36?

A: Prioritize gitRepo volumes, non-canonical IP and CIDR values, Service.spec.externalIPs, incompatible admission webhooks, SELinux volume-sharing patterns, stale add-ons, and node or Fargate version gaps. gitRepo is especially deceptive because the API can accept the Pod while kubelet refuses to run it.

Q: Does EKS enable every Kubernetes 1.36 beta feature?

A: No. EKS supports GA APIs, does not support alpha features, and does not automatically enable every new beta API. A feature can also depend on node configuration, runtime support, a CSI or DRA driver, and a compatible EKS platform or AMI. Use API discovery and component-specific documentation.

Q: Can an EKS 1.36 control-plane upgrade be rolled back?

A: An eligible in-place upgrade can return to the immediately previous minor version within seven days. The operation rolls back the managed control plane, not customer-managed add-ons, CRDs, workloads, data migrations, or non-Auto Mode nodes. Review rollback insights and component compatibility first.

Q: Should worker nodes remain three minor versions behind the 1.36 control plane?

A: No. Kubernetes supports kubelet 1.33 through 1.36 with a 1.36 API server, but that is a compatibility ceiling. Running at the edge removes room for the next control-plane upgrade and complicates add-on support. AWS recommends matching node and control-plane minor versions.

Primary Sources and Next Steps

• Kubernetes v1.36 sneak peek
• Kubernetes v1.36 release announcement
• Amazon EKS Kubernetes 1.36 release notes
• Amazon EKS version lifecycle and release calendar
• Update an existing EKS cluster
• Roll back an EKS cluster version
• Kubernetes version-skew policy
• KEP-5040: remove the gitRepo volume driver
• KEP-5707: deprecate Service.spec.externalIPs
• Kubernetes 1.36 DRA updates