Kubernetes v1.36 Explained Clearly

Kubernetes might initially seem like a purely developer-centric topic—complex, technical, and far removed from everyday work life. However, this is a misconception. At its core, Kubernetes is about something very fundamental: How modern software is reliably operated.

Or put more simply: Kubernetes ensures that digital applications—from online shops to internal company systems—run stably, even when changes are constantly happening in the background.

This makes Kubernetes a kind of operating system for digital infrastructure.

And that’s precisely why it’s worth taking a look at new versions like Kubernetes v1.36—even without a technical background.

A Release That Primarily Does One Thing: Shift Responsibility

When you take a closer look at the planned and already decided changes in Kubernetes v1.36, a common thread emerges that runs through almost all areas—and can best be described as:

Kubernetes takes convenience away from its users to give them back control.

What initially sounds contradictory becomes effective especially when you understand that many of the previous “simple” solutions quickly achieved goals but often accepted security gaps, lack of transparency, or hard-to-control dependencies.

Version 1.36 addresses this very specifically.

When Convenience Becomes a Risk: Why Features Disappear

One of the already firmly decided changes concerns a feature with the technical name externalIPs. Behind this cumbersome term lies a simple idea: it allowed you to easily determine how external access to applications in the system was directed.

This was convenient because it was quick and required little coordination. At the same time, this was precisely the problem.

Because what many were not aware of: This openness allowed, under certain circumstances, traffic to be redirected—such that it could run unnoticed over foreign systems. A classic gateway for so-called man-in-the-middle attacks.

With Kubernetes v1.36, this feature is now officially marked as deprecated (Deprecation—firmly decided). It will continue to function initially, but every use will generate warnings—a clear signal that action is needed before the feature disappears entirely in a later version.

The real value of this change lies not only in the technology but in the clarity:

Instead of silently tolerating risks, Kubernetes forces its users to choose more conscious and secure paths—such as structured network models where it is clearly defined who can access what.

A Quiet but Important Cut: The End of gitRepo

This approach is even more consistent with a second change that is also finally decided and implemented with v1.36: the complete removal of the so-called gitRepo mechanism.

What initially seemed like a practical feature—loading code directly from a repository when starting an application—turns out to be a risky shortcut upon closer inspection.

This mechanism led to code from external sources potentially being executed with extensive system rights. In other words: it opened a backdoor without always recognizing it as such.

With the removal of this feature, a clear signal is sent:

Modern IT systems should not only function but also be traceable and verifiable.

The advantage lies less in immediate functionality and more in structural improvement: Companies are forced to establish cleaner processes—such as clearly defined deployments or GitOps approaches, where every change is versioned and traceable.

Rethinking Security: When Keys No Longer Reside in the Same System

One of the most important planned but not yet finally confirmed innovations concerns the handling of security keys—a topic often underestimated, although it is at the center of every digital infrastructure.

Previously, it was common for Kubernetes to manage many of these keys itself. This is practical but leads to a critical dependency: The system that operates applications is also responsible for their security.

With the new feature for external signing of ServiceAccount tokens (expected GA in v1.36, but not yet finally confirmed), this coupling is dissolved.

In practice, this means:

Keys can now reside in external, specialized systems—such as particularly secured hardware modules or central key management systems.

The advantage becomes clear especially when you take a step back:

• Security is outsourced from the operational system
• Responsibilities are more clearly separated
• Existing compliance structures can be better integrated

Especially in the context of European data strategies and regulatory requirements, this creates a real lever for digital sovereignty, as companies retain control over critical security components—regardless of where their applications run.

When Infrastructure Becomes More Efficient: Getting More Out of Existing Resources

Another area that initially seems technical but is economically highly relevant concerns the use of hardware—especially expensive special resources like GPUs.

Here, Kubernetes plans an extension that allows such devices to be split and made available to multiple applications simultaneously (planned, not finally confirmed).

To make this tangible, a simple image helps:

Previously, it was often like reserving an entire vehicle for each task—even if only a fraction of the capacity was needed. With the new feature, multiple “passengers” can use the same “vehicle” without hindering each other.

The advantage is obvious:

• Higher utilization of existing infrastructure
• Less need for additional hardware
• Lower costs with simultaneously better performance

Especially for companies that operate their own data centers or want to optimize cloud costs, this is an important step—even if the final implementation is yet to be seen.

More Order in the System: Who Is Allowed to Use What?

Closely related is another planned feature that ensures certain resources can only be used if explicitly permitted (also planned, not yet finally confirmed).

Again, it’s less about technology in the narrow sense and more about governance:

In complex systems, it is crucial to know who accesses which resources—and why.

These mechanisms prevent applications from accidentally or uncontrollably accessing sensitive or expensive resources. Instead, a clearly regulated system is created that can be better monitored and controlled.

A Look Beyond the Release: Why Ingress NGINX Disappears

Closely tied to Kubernetes v1.36, but not part of the release itself, is the discontinuation of Ingress NGINX.

This tool was long used to control external access to applications. That it is no longer being developed shows how much the requirements have changed.

The crucial point here is less the “what” than the “why”:

Older solutions reach their limits when it comes to security, maintainability, and standardization. Therefore, the ecosystem is shifting towards modern approaches like the Gateway API, which are more structured, clearer, and better controllable in the long term.

What Changes Overall—and Why It’s Relevant

When you combine all these developments, a clear picture emerges that goes beyond individual features.

Kubernetes is evolving into a platform that:

• makes fewer implicit assumptions
• requires more explicit decisions
• but becomes significantly more transparent and controllable

This has immediate impacts on companies:

Systems are no longer operated “just somehow” but are consciously designed.

And therein lies—despite all the additional complexity—the real advantage.

Conclusion: Control Replaces Convenience

Kubernetes v1.36 does not bring spectacular individual innovations but a consistent evolution that only becomes fully apparent in the overall picture.

Insecure features are removed, new possibilities create more control, and existing mechanisms are adjusted to better fit modern security and governance models.

Or put differently, and deliberately somewhat pointedly:

Kubernetes doesn’t become harder—it becomes more honest.

For companies that want to operate their digital infrastructure sovereignly in the long term, this is precisely good news.