Mirantis Kubernetes Engine 4.2.0 Delivers Support for Windows Workloads, VMware Child Clusters, and FIPS 140-3

Mirantis Kubernetes Engine (MKE) 4.2.0 is our biggest 4.x release yet, and it widens both what you can run and how you operate it. You can now run Windows workloads alongside Linux, turn on optional FIPS 140-3 for regulated and federal environments, and stand up clusters on Kubernetes 1.35, all without provisioning an external load balancer first. Day-2 operations get a major lift too: add and remove nodes without a full cluster reconcile, manage ingress from a new dashboard Gateway section, and run on more resilient defaults. Every capability here is built to work in fully airgapped environments, and a direct upgrade from MKE 3.9 carries your Windows and Active Directory workloads forward with it.

Here is what's new.

Run Windows workloads, with gMSA and Active Directory

MKE 4.2.0 adds Windows worker node support. You can join Windows nodes to a cluster on a fresh install or migrate your existing Windows workers from MKE 3.9, and route traffic to Windows workloads through ingress just as you do for Linux.

For teams running Windows containers against Active Directory, MKE 4.2.0 supports group Managed Service Accounts (gMSA), so your Windows workloads can authenticate to domain resources without embedding credentials. Both fresh-install and MKE 3 → 4 gMSA migration are supported, and like the rest of the release, Windows and gMSA work in airgapped clusters.

Kubernetes 1.35

MKE 4.2.0 moves to Kubernetes 1.35 across both manager and child clusters, keeping you current with upstream and the latest API, scheduling, and runtime improvements. The upgrade also resolves long-standing edge cases around kubelet behavior on cgroup v1 hosts and the handling of legacy etcd data during migration.

Optional FIPS 140-3 for regulated and federal environments

For customers in government and financial services, or other regulated industries, MKE 4.2.0 introduces optional FIPS 140-3 mode. Turn it on in your cluster configuration and MKE deploys FIPS-validated cryptography across the components it manages (the operator, the Dex authentication service, the etcd maintenance service, and the dashboard), along with the FIPS build of the underlying Kubernetes distribution.

FIPS is strictly opt-in: leave it off and your existing deployments are completely unchanged, with no added cost or performance overhead. When you do enable it, remember that the host operating system must itself be running in FIPS mode. MKE handles its own components and Kubernetes layer, and relies on your nodes for the OS.

Install without an external load balancer

Previously, MKE 4 required an external load balancer to be in place before installation could begin. MKE 4.2.0 removes that prerequisite: using k0s control-plane load balancing (CPLB), you can deploy a cluster without provisioning an external load balancer first.

That means fewer moving parts on day one, a meaningful simplification for edge, lab, and airgapped deployments where a separate load balancer is awkward or simply unavailable.

Modernized ingress on Envoy Gateway v1.7

The ingress data plane has been upgraded to Envoy Gateway v1.7, bringing the latest Gateway API capabilities and security fixes to MKE's north-south traffic. As part of this work, the older MKE 3.9-era ingress is being retired in favor of the Envoy Gateway path, and upgrades from 3.9 to 4.2 carry your ingress configuration across automatically.

A more capable dashboard

The MKE 4 dashboard gains real configuration depth in 4.2.0:

• Manage ingress from the UI. A new Gateway section lets cluster administrators configure the Envoy Gateway controller and MKE's internal gateways directly in the dashboard, with a built-in notice that guides teams through the ingress retirement and migration.

A cleaner, more consistent experience. A refreshed login screen plus a wave of UI fixes: masked license keys, corrected session-timeout handling, more consistent labels and filters, and clearer ingress and node-related screens.

Smoother day-2 cluster operations

MKE 4.2.0 makes routine cluster management easier and more predictable, especially at fleet scale:

• Add and remove nodes without a full reconcile. Node add and remove are now targeted operations that no longer require re-running mkectl apply across the entire cluster. For large fleets doing routine node rotation or autoscaling, a single node change stays a single node change, and an unrelated configuration edit no longer touches every node.

• See what your cluster is doing. A new mkectl status command surfaces cluster and operation state at a glance, and mkectl apply has a wait capability which blocks until reconciliation actually completes, so scripts and pipelines can act on a real result.

• A safer reset.mkectl reset is hardened with proper cleanup, timeouts, and verification, so tearing a cluster down and starting over is reliable.

• etcd maintenance reaches MKE 3 parity. Scheduled event cleanup and defragmentation, automatic response to etcd alarms (including a temporary storage-quota bump when etcd hits a NOSPACE condition), and configurable maintenance schedules now extend to child clusters as well.

More resilient and tunable by default

• Dependable backup, restore, and disaster recovery. Backup and restore only matter if they work on your cluster, not just a default one. MKE 4.2.0 hardens restore and disaster recovery for real production setups: airgapped clusters with a private certificate authority, SELinux in enforcing mode, the Calico eBPF dataplane, custom TLS, LDAP login, dedicated data mount points, and multi-node HA control planes.

Restore now keeps your custom certificates, addresses, SELinux labels, node labels, and dedicated mount points intact, redistributes registry config to every node, and no longer hangs on an unreachable node. It also follows one consistent flow, bootstrapping a single node from the snapshot and rejoining the rest with mkectl apply, the same model as MKE 3. The same hardening covers upgrade rollback.

• Higher availability for MKE's own components. System components now ship with PriorityClasses, PodDisruptionBudgets, multiple replicas, and topology spread constraints, so MKE's management plane tolerates node failures and disruptions far better out of the box.

• Tunable monitoring. You can now configure resource requests and limits and metrics retention for the bundled Prometheus, so monitoring fits the size and budget of your environment rather than a fixed default.

Broader platform support

MKE 4.2.0 expands where you can run child clusters and what they can integrate with:

• VMware vSphere child clusters: provision and manage MKE child clusters on vSphere, including in airgapped environments.

• CSI Secrets Store integration: install the Container Storage Interface (CSI) Secrets Store Driver directly with mkectl, so workloads can mount secrets from external secret stores.

• Updated networking: Calico and the Tigera operator move to 3.31, resolving known eBPF and FQDN policy issues.

This release is also built on k0rdent Enterprise 1.3, the multi-cluster management layer underneath MKE's child-cluster lifecycle.

Ready for airgapped environments

Airgapped, offline operation is a first-class use case for MKE, and 4.2.0 hardens it across the board. The new Windows, gMSA, FIPS, and vSphere child-cluster capabilities were all validated for airgapped installs, and this release fixes a range of offline-specific issues, including removing a hardcoded CDN dependency in the dashboard's code editor, correcting image-bundle and registry-mirror contents, and fixing node provisioning paths that previously assumed internet access. If you run MKE behind a registry mirror with offline image bundles, 4.2.0 is a smoother experience end to end.

Upgrading to MKE 4.2.0

If you're already on MKE 4, you can upgrade in place to 4.2.0. The release continues to use the etcd maintenance service to safely roll back a failed upgrade, so an interrupted upgrade can return the cluster to its prior state.

For MKE 3 customers, MKE 3.9 is the supported source version for a direct upgrade to MKE 4.2.0, and that upgrade now brings your Windows workers and gMSA configuration along with it, and migrates ingress onto Envoy Gateway automatically.

A few things to confirm before you upgrade: review the 4.2.0 release notes for the current list of known issues and any data-plane-specific constraints (for example, around eBPF/BPF and cgroup v1 hosts), and check whether any addons in your environment require a manual step during the upgrade. 

Stability and fixes

Beyond the headline features, MKE 4.2.0 resolves more than 200 bugs. A large share of that work went into backup and restore reliability and upgrade and rollback robustness (the operations you most want to be boring), along with the dashboard polish noted above and fixes for installation edge cases on SELinux and RHEL/Rocky hosts.

For more information about Mirantis Kubernetes Engine 4.2.0, view the release notes, download the datasheet, or contact us.