The Hidden Contract in NKP 2.18

NKP 2.18 came out on July 2, 2026, and the feature list is one search away, so this is not another walkthrough of it. The hidden contract of the title is the implicit agreement between the platform and whoever operates it: which objects your automation is allowed to touch, which CLI version works against which cluster, which namespace things live in. In this release that agreement changes more than the features do, and it is hidden because it lives in the known issues and the migration notes rather than in the announcements. What follows is the version I would give a colleague before an upgrade: what actually changes for the people who run the platform day to day, and what to check before touching anything.

The Engine Room

The foundations move forward the way you would expect from a mature platform. NKP 2.18 ships Kubernetes 1.35.2 as the default, upgrades the container runtime to containerd v2, and moves the Cluster API machinery, the components that actually create and manage clusters on your infrastructure, to the newer v1beta2 APIs. If those names mean little to you, the practical translation is this: the version of Kubernetes your applications run on stays current, and the plumbing underneath was modernized. For most applications the change is transparent: pods get rescheduled as nodes roll, and nothing above them notices, though anything running without replicas or a disruption budget will feel the roll itself. The exceptions are specific. Anything that talks to the container runtime directly, security agents, monitoring collectors, in-cluster image builders, deserves a test against containerd v2 before the fleet moves. If Kubernetes upgrades still make you nervous, that reflex usually dates back to the great API removals of release 1.22, when years of charts and operators stopped applying until they were rewritten. The ecosystem has since grown a strict deprecation policy and scanners that list what will break before you touch anything. Manifests and operators still using deprecated Kubernetes APIs should be scanned before the upgrade, and NKP Insights conveniently ships Pluto, a tool built for exactly that. Pluto is also open source, so even where Insights is not deployed the same scan costs nothing more than an afternoon: it belongs in the preparation, not in the postmortem. And workloads that spawn a large number of threads should check the known issue on the default pod PID limit, which can send them into a crash loop on hardened 2.18 nodes. Plumbing modernization should be boring, but boring is earned in a lab, not assumed.

The Part That Touches Your Scripts

The changes that deserve your attention are quieter, and they live in how you manage clusters rather than in what clusters can do.

The first is NKPCluster. If the name is new to you: it is a Kubernetes object that describes an entire cluster as one thing, its version, its node pools, the shape you want it to have, and the platform continuously works to make reality match that description. Until now that description was spread across more than one object, and automation could get away with editing the underlying pieces directly. From 2.18 the contract is explicit: NKPCluster is the one object you edit, and its name is what you use in nkp commands and GitOps pipelines. If your automation touches the lower-level objects today, migrating it is real work, and it is better scheduled than discovered.

The second is that CLI version discipline now has teeth. The 2.18 command line tool refuses to run most management operations, creating, deleting, scaling, against management clusters still on 2.17 or earlier, and deleting a pre-2.18 cluster with the new CLI fails outright. Keeping matched CLI versions per cluster generation was always the correct practice; the difference is that what used to depend on your rigor is now enforced by the tool. Plan to keep the older binary around until your whole fleet has crossed over.

The third is easy to miss and worth knowing in advance. New management clusters run in the kommander namespace instead of default, so node pool commands against a fresh 2.18 management cluster need the -n kommander flag. Management clusters upgraded from earlier releases keep their existing namespace instead, which means two management clusters on the same 2.18 version can require different flags depending on how they got there: scripts should not infer the namespace from the NKP version alone. Add to this a hard limit worth checking before you upgrade anything: workload cluster names longer than 58 characters make the workspace upgrade fail, because of how Kubernetes handles derived labels. Renaming a cluster is not a thing, so if you have baroque naming conventions, this is the moment to know.

The Compliance Chapter

The release also carries a clear message for regulated and disconnected environments. There is a new Ubuntu Pro operating system image hardened for CIS, STIG, and FIPS compliance, support for building GPU-enabled FIPS images in air-gapped environments, and the Nutanix data services for Kubernetes included in the default air-gapped bundle instead of being a separate download. If none of those acronyms lives in your contracts, you can skip this chapter entirely. If they do, or if you suspect they are about to, the FIPS story in particular deserves more space than a paragraph, and I will dedicate a separate article to it, because where FIPS actually reaches a European practitioner is a better question than it looks.

Before You Touch Anything

The preparation list is short and concrete. Check the compatibility floor first: 2.18 requires Prism Central pc.7.3 or later and AOS 7.3 or later, unchanged from 2.17, so anyone current on the previous release checks the box and moves on. If your management plane sits below that line instead, getting its upgrade approved often takes longer than the upgrade itself. Inventory your cluster names against the 58 character limit. Pin CLI binaries per cluster generation and decide the order in which the fleet converges. Grep your automation for direct edits to the lower-level cluster objects and for namespace assumptions, because those are the two silent breakages in this release. And read the known issues section before the features: 2.18 also introduces preflight checks that run during cluster updates, which means the platform now catches part of your misconfigurations before they become incidents, one more reason to bring the fleet across deliberately rather than opportunistically.

Then, before production, spend an afternoon in a lab exercising the operations that actually changed, instead of just verifying that versions come up:

• Create and delete a workload cluster with the 2.18 CLI.
• Scale a node pool and confirm which namespace it lives in.
• Run a GitOps reconciliation through NKPCluster end to end.
• Confirm your automation no longer edits the lower-level cluster objects.
• Put a thread-heavy workload and anything that talks to the container runtime on a 2.18 node and watch them.

Stricter Contracts Are Good News

The pattern across this release is consistent: the visible features move the platform forward, and the contract between the platform and your automation got stricter, which is good news that arrives disguised as inconvenience. What used to depend on operator discipline, matched CLI versions, one source of truth for cluster state, is now enforced by the platform, which protects the fleets that were never disciplined to begin with. The cost is a one-time pass through your scripts and pipelines. Pay it before the upgrade, not during, and hold the result to the right standard: a successful upgrade is not a cluster that comes back Ready, it is a platform that can still perform its next lifecycle operation without surprises.