Kubernetes 1.36 upgrade: 4 real breaking changes and 1 myth to ignore

Summary. Kubernetes v1.36, codenamed ハル (Haru), was released on 22 April 2026 with 70 enhancements: 18 graduated to Stable, 25 entered Beta and 25 landed in Alpha. Patch support for the 1.36 branch ends on 28 June 2027. Three changes in this release can stop a production workload: the gitRepo volume driver is permanently disabled and the kubelet refuses to run pods that use it, Service .spec.externalIPs is deprecated with full removal planned for v1.43, and stricter IP and CIDR validation rejects values that older manifests happily stored. A fourth blocker sits outside the release itself: Ingress NGINX was retired on 24 March 2026, its repository is archived read-only, and its last release, v1.15.1, never listed 1.36 as a supported version. One claim circulating widely is wrong. The kube-proxy IPVS mode was not removed in v1.36. Amazon EKS shipped 1.36 on 2 June 2026 with standard support to 2 August 2027; Azure AKS reached GA in June 2026; Google GKE has 1.36 in the Rapid and Regular channels but not Stable. Falling out of standard support on EKS takes a cluster from $0.10 to $0.60 per cluster-hour, a 6x jump on the control plane alone.

Most upgrade guides published since April repeat a summary of a summary. This one works from the release announcement, the KEP tracking issues, the vendor version calendars and the retirement notice, and it flags the one place where those primary sources contradict what almost everyone is writing.

What actually shipped in v1.36

The release blog for v1.36 states the shape of the release plainly: "This release consists of 70 enhancements. Of those enhancements, 18 have graduated to Stable, 25 are entering Beta, and 25 have graduated to Alpha." The v1.36.0 tag was cut on 22 April 2026.

The support arithmetic matters more than the feature list. Kubernetes maintains release branches for the three most recent minor versions, and 1.19 and newer get roughly a year of patch support. As of August 2026 that means:

If you are on 1.34 today, upstream patches stop on 27 October 2026. That is the real deadline driving most of the upgrade traffic right now, and it is why the 1.36 breaking changes are worth auditing before the calendar forces the decision.

The release blog's own deprecation section is short. In its words, "Kubernetes v1.36 includes a couple of deprecations", and it names exactly two: the deprecation of Service .spec.externalIPs and the removal of the gitRepo volume driver. Keep that count in mind when you read the next section.

Breaking change 1: gitRepo is permanently disabled, and the kubelet enforces it

The gitRepo volume type has been deprecated since v1.11. In v1.36 it is finished. The release announcement is unambiguous: "For Kubernetes v1.36, the gitRepo volume plugin is permanently disabled and cannot be turned back on. This change protects clusters from a critical security issue where using gitRepo could let an attacker run code as root on the node."

The announcement continues: "Although gitRepo has been deprecated for years and better alternatives have been recommended, it was still technically possible to use it in previous releases. From v1.36 onward, that path is closed for good, so any existing workloads depending on gitRepo will need to migrate to supported approaches such as init containers or external git-sync style tools." The work is tracked as KEP-5040.

The operational detail that catches teams is where the failure surfaces. AWS documents it precisely in the EKS 1.36 release notes: "The gitRepo volume type is permanently disabled in Kubernetes 1.36 and cannot be re-enabled. The Kubernetes API still accepts Pods with gitRepo volumes, but the kubelet will refuse to run them and return an error."

Read that again, because it defines your test strategy. kubectl apply succeeds. Admission succeeds. Your CI pipeline goes green. The pod then fails to start on the node. A manifest-linting gate in CI will not catch this if the gate only checks that the API server accepts the object. You need an inventory scan against live and stored manifests, and you need a pod that actually schedules in a 1.36 staging cluster.

There is no official detection command published for this, so build your own from the object shape. Every affected pod carries a volume with a gitRepo key:

            # Live objects across all namespaces
kubectl get pods --all-namespaces -o json \
  | jq -r '.items[]
      | select(.spec.volumes[]? | has("gitRepo"))
      | "\(.metadata.namespace)/\(.metadata.name)"'

# Controllers that will recreate them
for kind in deployments statefulsets daemonsets jobs cronjobs replicasets; do
  kubectl get "$kind" --all-namespaces -o json \
    | jq -r --arg k "$kind" '.items[]
        | select(.. | objects | has("gitRepo"))
        | "\($k) \(.metadata.namespace)/\(.metadata.name)"'
done
          

Run the second loop as well as the first. Scanning only running pods finds the symptom and misses the Deployment that will recreate it after the upgrade.

The migration targets AWS names are init containers or a git-sync sidecar. Both are ordinary patterns. An init container that clones into an emptyDir before the app container starts is the closest one-for-one replacement and is usually a ten-line change. A git-sync sidecar is the right answer when the repository content needs to refresh while the pod is alive, which was the original reason many teams reached for gitRepo in the first place.

Breaking change 2: externalIPs is deprecated, on a four-release ladder

The second named deprecation is the externalIPs field on Services. The release announcement sets out both the reason and the schedule: "This field has been a known security headache for years, enabling man-in-the-middle attacks on your cluster traffic, as documented in CVE-2020-8554. From Kubernetes v1.36 and onwards, you will see deprecation warnings when using it, with full removal planned for v1.43."

The KEP tracking issue, opened by danwinship on 26 November 2025 and labelled sig/network, records the staged plan in full:

That is a long runway, and the long runway is the trap. Nothing breaks in v1.36, so the warning gets filtered out of the logs and the ticket never gets written. The version that hurts is v1.40, where the default flips. On a normal three-releases-a-year cadence, v1.40 arrives inside the next 18 months, which is well within the life of most platform roadmaps being drawn up now.

AWS restates the same schedule in its 1.36 notes: "The externalIPs field in Service .spec is deprecated in Kubernetes 1.36. You will see deprecation warnings when creating or updating Services that use this field. Full removal is planned for Kubernetes 1.43."

The recommended replacements are named in the release announcement: "consider using LoadBalancer services for cloud-managed ingress, NodePort for simple port exposure, or Gateway API for a more flexible and secure way to handle external traffic."

Finding the affected Services is a one-liner:

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

In bare-metal and on-premises clusters this query usually returns something. externalIPs was the cheap way to pin a Service to a node address without a cloud load balancer, and MetalLB or a Gateway API implementation is the sustainable replacement.

Breaking change 3: stricter IP and CIDR validation rejects manifests that used to apply

The third change is the one nobody puts in a headline, and it is the one most likely to break a pipeline on upgrade day. AWS documents it in the EKS 1.36 notes under KEP-4858: API fields no longer accept IP or CIDR values with extraneous leading zeros, such as 010.000.000.005 instead of 10.0.0.5, or CIDR values with ambiguous semantics, such as 192.168.0.5/24 instead of 192.168.0.0/24. Existing stored objects are preserved through validation ratcheting, but new creates and updates are rejected. The rule applies to built-in API kinds, not to custom resource kinds.

Validation ratcheting is doing a lot of work in that sentence. Your existing objects survive the upgrade untouched, so the cluster looks healthy. The failure appears the next time someone edits one of those objects, or the next time a GitOps controller reconciles the manifest from source. A cluster can pass its post-upgrade smoke test and then fail a deploy three weeks later, which is the worst possible shape for an incident.

Two places generate these values in practice. Hand-written NetworkPolicy ipBlock entries, where 192.168.1.5/24 is a very common copy-paste error, and templated Helm values where an octet gets zero-padded for alignment. Grep the repository, not the cluster:

            # Zero-padded octets in any YAML
grep -rEn '\b0[0-9]{1,2}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\b' --include='*.yaml' .

# CIDRs whose host bits are set (candidates, verify each)
grep -rEn '[0-9]{1,3}(\.[0-9]{1,3}){3}/(8|16|24)\b' --include='*.yaml' . \
  | grep -vE '\.0/(8|16|24)\b'
          

The second command produces false positives on /8 and /16 ranges. Treat it as a candidate list for a human to review, not a gate.

The myth: IPVS was not removed in v1.36

Here is where the widely repeated version of this story falls apart.

Many write-ups published since April state that kube-proxy's IPVS mode was removed in v1.36. InfoQ's release coverage puts it directly: "IPVS mode in kube-proxy, deprecated in v1.35, is also removed." AWS's own EKS notes contributed to the expectation, because the 1.35 section of the version page carries a forward-looking line: "IPVS mode in kube-proxy is deprecated and will be removed in Kubernetes 1.36."

The primary sources say otherwise.

The current Kubernetes networking reference still documents ipvs proxy mode, and marks it FEATURE STATE: Kubernetes v1.35 [deprecated], not removed. The accompanying note explains the reasoning: "The ipvs proxy mode was an experiment in providing a Linux kube-proxy backend with better rule-synchronizing performance and higher network-traffic throughput than the iptables mode. While it succeeded in those goals, the kernel IPVS API turned out to be a bad match for the Kubernetes Services API, and the ipvs backend was never able to implement all of the edge cases of Kubernetes Service functionality correctly."

The release announcement for v1.36 backs this up by omission. It says the release "includes a couple of deprecations" and then names two: externalIPs and gitRepo. IPVS is not among them. AWS's 1.36 section likewise says nothing about IPVS removal, having flagged it only as a forward-looking notice under 1.35.

What should a platform team do with that? Not relax. Deprecated means the removal is coming, and the docs already name the destination: "The nftables proxy mode (described below) is essentially a replacement for both the iptables and ipvs modes, with better performance than either of them, and is recommended as a replacement for ipvs. If you are deploying onto Linux systems that are too old to run the nftables proxy mode, you should also consider trying the iptables mode rather than ipvs, since the performance of iptables mode has improved greatly since the ipvs mode was first introduced."

The practical difference is sequencing, and sequencing is what an upgrade plan is made of. If IPVS had been removed in v1.36, an IPVS cluster could not upgrade at all until kube-proxy was migrated, which turns a networking change into a hard blocker on the critical path. It was not removed, so the migration off IPVS is a scheduled piece of work you can run before or after the 1.36 upgrade, with the target being nftables rather than iptables. Getting that wrong in either direction costs a sprint. Believing the removal claim adds an unnecessary blocker; ignoring the deprecation leaves you exposed when it does land.

Check what your clusters actually run:

            kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep -E '^mode:'

# On managed node pools, confirm the running flag too
kubectl -n kube-system logs ds/kube-proxy --tail=200 | grep -i 'proxy mode'
          

The real cost here is usually the connection-tracking and capacity review, not the config flag.

Breaking change 4: Ingress NGINX is gone, and it never supported 1.36

This one is not in the v1.36 changelog, and it is the most likely reason a 1.36 upgrade stalls.

Ingress NGINX was retired on 24 March 2026. The GitHub repository banner is blunt: "This repository was archived by the owner on Mar 24, 2026. It is now read-only." The v1.36 release announcement confirms it: "Kubernetes SIG Network and the Security Response Committee have retired Ingress NGINX on March 24, 2026. Since that date, there have been no further releases, no bugfixes, and no updates to resolve any security vulnerabilities discovered. Existing deployments of Ingress NGINX will continue to function, and installation artifacts like Helm charts and container images will remain available."

The retirement notice, published by Tabitha Sable of the Kubernetes Security Response Committee on 12 November 2025, explains why the project could not be kept alive: "Currently, Ingress NGINX is receiving best-effort maintenance. SIG Network and the Security Response Committee have exhausted our efforts to find additional support to make Ingress NGINX sustainable. To prioritize user safety, we must retire the project." The same notice records the root cause: "Despite the project's popularity among users, Ingress NGINX has always struggled with insufficient or barely-sufficient maintainership. For years, the project has had only one or two people doing development work, on their own time, after work hours and on weekends."

The recommendation is direct: "SIG Network and the Security Response Committee recommend that all Ingress NGINX users begin migration to Gateway API or another Ingress controller immediately." The repository README adds a line worth quoting to anyone still weighing this up: "If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Now the compatibility problem. The final Ingress NGINX release, v1.15.1, lists its supported Kubernetes versions as 1.35, 1.34, 1.33, 1.32 and 1.31. There is no 1.36 row, because the project was archived a month before 1.36 shipped. Running Ingress NGINX on a 1.36 cluster puts you on an untested combination with no upstream patch path for anything you find.

The official detection command is in the retirement notice: "In most cases, you can check whether you use Ingress NGINX by running kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx with cluster administrator permissions."

AWS frames the effort honestly in its own notes: none of the available alternatives are direct drop-in replacements, and each will require planning and engineering time. Budget accordingly. Gateway API uses different resource types, and every rewrite and annotation-driven behaviour has to be re-expressed.

The one good reason to want 1.36: user namespaces are Stable

The upgrade is not all removals. Support for user namespaces in pods graduated to Stable in v1.36, work done under KEP-127 and led by SIG Node. The release announcement describes what it buys you: "Container isolation and node security reach a major maturity milestone in Kubernetes v1.36 as support for User Namespaces graduates to Stable. This long-awaited feature provides a critical layer of defense-in-depth by allowing the mapping of a container's root user to a non-privileged user on the host, ensuring that even if a process escapes the container, it possesses no administrative power over the underlying node."

For regulated workloads this is the first platform-native answer to container-escape risk that does not require a separate sandboxing runtime. Treat it the way you would treat any newly stable isolation primitive: enable it on a non-critical namespace first, run representative load, and confirm your CSI drivers and any privileged sidecars behave under the remapped UID range.

Managed control planes: where 1.36 actually is today

Self-managed clusters have had 1.36 since 22 April 2026. Managed services arrived later, and they are not aligned.

The GKE Stable row is the one to plan around. If your production estate is pinned to the Stable channel, 1.36 is simply not an option yet, and GKE's policy gives "up to a total of 24 months of support for a minor version after the version has been made available for new cluster creation in the Regular channel", split into roughly 14 months of standard support and about 10 months of extended support.

On EKS the version calendar is the document to work from. It gives 1.34 an end of standard support of 2 December 2026 and 1.35 an end of 27 March 2027, with 1.33 having already ended on 29 July 2026. The policy is stated plainly: a minor version gets 14 months of standard support, then 12 months of extended support.

What falling behind costs on EKS

This is where an upgrade slip turns into a line item. AWS prices the EKS control plane by support tier: "When your Amazon EKS cluster runs a Kubernetes version that is in standard support, you pay $0.10 per cluster per hour. When your Amazon EKS cluster runs a Kubernetes version in extended support, you pay $0.60 per cluster per hour."

The $0.33 figure is AWS's own worked example: a cluster created on release day and never upgraded pays $0.10 for 14 months and $0.60 for the following 12, averaging $0.33 per hour across the 26-month window.

Applying AWS's published rates, a platform team running 40 clusters that drifts a single version behind into extended support pays 40 times the $365 monthly difference, about $14,600 a month on the control plane alone, before a single node is counted. That is the number to put in front of a finance stakeholder when the upgrade sprint is competing with feature work. The same arithmetic drove the earlier deadline covered in our EKS 1.33 standard support upgrade path analysis, and it is a recurring item in any serious cloud FinOps programme for Indian teams.

A pre-upgrade audit you can run this week

Order matters. Run the inventory before you touch a control plane.

1. Inventory your versions and dates. On EKS, aws eks describe-cluster-versions returns releaseDate, endOfStandardSupportDate, endOfExtendedSupportDate, status and kubernetesPatchVersion for each version. On GKE, gcloud container get-server-config --flatten="channels" --filter="channels.channel=REGULAR" --format="yaml(channels.channel,channels.defaultVersion)" --location=COMPUTE_LOCATION gives you the channel default, and the CLUSTER_VERSION_END_OF_LIFE and CLUSTER_VERSION_SKEW_UNSUPPORTED Recommender subtypes surface clusters already past end of standard support.

1. Find Ingress NGINX first, because it has the longest lead time. Use the official selector query, then decide between a Gateway API implementation and a commercially supported controller. This decision gates everything else.

1. Scan for gitRepo volumes in both live pods and their controllers. Every hit is a manifest change, not a config change.

1. Scan for Services with externalIPs. Nothing breaks in 1.36, so schedule this against v1.40 rather than treating it as an upgrade blocker.

1. Grep the manifest repositories for zero-padded IPs and CIDRs with host bits set. This is a source-repository job, not a cluster job, because ratcheting hides the problem in the cluster.

1. Record your kube-proxy mode. If it is ipvs, plan a move to nftables as separate work with its own capacity review. Do not let anyone tell you it blocks the 1.36 upgrade.

1. Upgrade a staging cluster and schedule a real pod, not just an apply. The gitRepo failure mode only appears at the kubelet.

Teams that already run a container runtime migration playbook will recognise the shape of this. Much of it mirrors what we set out in the Kubernetes 1.35 containerd 2.0 migration guide, and if you run GPU workloads the Kubernetes DRA GA resource claims migration work usually lands in the same window.

India-specific considerations

Three things change the calculus for teams operating from India.

Cluster sprawl is the dominant cost driver in most Indian engineering organisations we see, not node size. The EKS control-plane arithmetic above is per cluster, so a team running one cluster per service per environment pays the 6x extended-support penalty many times over. Consolidating environments onto fewer, larger clusters with namespace isolation usually saves more than any instance-type change, and user namespaces going Stable in v1.36 makes that consolidation defensible to a security reviewer.

Regional availability follows the same calendar everywhere, but capacity for a blue-green upgrade does not. If your plan is to stand up a parallel 1.36 cluster and shift traffic, confirm instance availability in your Mumbai or Hyderabad region before you commit to the date. A rolling in-place upgrade is the fallback, and it is slower.

Data protection obligations under the Digital Personal Data Protection Act 2023 do not change with a Kubernetes version, but the Ingress NGINX retirement does touch them. An unpatched ingress controller sitting in front of personal data is a control weakness you will have to explain, and "the upstream project was archived in March 2026" is not a defence. Where the ingress layer terminates TLS for personal data, treat the migration as a security remediation with a date, not a backlog item.

FAQ

How eCorpIT can help

eCorpIT runs Kubernetes upgrade and platform-hardening engagements for teams that would rather not discover the kubelet's gitRepo behaviour during a production window. Our senior engineering teams handle the inventory scan, the Ingress NGINX to Gateway API migration, the kube-proxy nftables move and the control-plane cost review as one piece of work, with a staging rehearsal before anything touches production. We are CMMI Level 5, MSME Certified and ISO 27001:2022 certified, and we design platforms aligned with DPDP Act 2023 requirements. Tell us your current versions and cluster count at /contact-us/ and we will come back with a sequenced plan and a date.

References

1. Kubernetes v1.36: ハル (Haru) release announcement

1. Kubernetes v1.36.0 release tag on GitHub

1. Kubernetes releases and end-of-life dates

1. KEP-5040: remove the gitRepo volume driver

1. KEP-5707 tracking issue: deprecate service.spec.externalIPs

1. KEP-127: support user namespaces in pods

1. Kubernetes networking reference, including IPVS proxy mode state

1. Amazon EKS Kubernetes version release notes, standard support

1. Amazon EKS Kubernetes version release calendar

1. Amazon EKS extended support for Kubernetes versions pricing

1. Azure Kubernetes Service supported Kubernetes versions

1. Google Kubernetes Engine Rapid channel release notes

1. Google Kubernetes Engine Regular channel release notes

1. Google Kubernetes Engine Stable channel release notes

1. Google Kubernetes Engine versioning and support policy

1. Ingress NGINX retirement notice, Tabitha Sable, Kubernetes Security Response Committee

1. kubernetes/ingress-nginx repository README, archived 24 March 2026

1. InfoQ: Kubernetes v1.36 released, Matt Saunders, 14 May 2026

Last updated: 7 August 2026.