Skip to content

Enhancements#

Detail on the enhancements introduced in MKE 4.2.1 includes:

Scheduled backups and backup encryption#

MKE 4.2.1 can take backups on a schedule, encrypt backup archives, verify them before restore, and keep a record of every backup.

The etcd maintenance service runs scheduled backups on the controllers of the management cluster. Configure the schedule in the spec.backup.schedule section of the mke4.yaml configuration file:

  • enabled: Turns scheduled backups on or off.
  • cronExpression: Backup schedule in cron format. Consecutive runs must be at least 5 minutes apart.
  • path: Directory that stores the backup archives. Default: /var/lib/mke/backups.
  • retain: Number of archives to keep on each node. Default: 30. Set to 0 to keep all archives.
  • replication: AllControllers (default) or LeaderOnly.
  • includeLogs: Includes logs in the backup archive.
  • configSnapshotFallback: None (default) or LastKnownGood.

The upgrade from MKE 3 migrates an existing MKE 3 backup schedule.

Backup encryption and verification work as follows:

  • The mkectl backup command requires either the --passphrase option or the --no-passphrase option. The passphrase must be at least 12 characters long. Pass - as the value to read the passphrase from stdin. The same requirement applies to the mkectl node add and mkectl node remove commands for control plane nodes, unless you pass --skip-snapshot.
  • Scheduled backups read the passphrase from the Secret that spec.backup.schedule.encryption.passphraseSecretRef.name names. The Secret must reside in the mke namespace, store the passphrase under the passphrase key, and carry the mke.mirantis.com/backup-passphrase=true label.
  • Archives encrypted with the passphrase from the Secret record a key ID, which mkectl restore uses to identify the passphrase that opens the archive.
  • The mkectl backup command prints an MD5 checksum of the archive. Pass the checksum to mkectl restore --md5 to verify the archive before the restore changes the cluster.

Every backup, whether scheduled, manual, or taken by mkectl upgrade, writes an MkeBackup record to the mke namespace:

  • The record contains the backup result, the archive size, the MD5 digest, and the MKE build and k0s version that produced the backup.
  • spec.backup.historyRetain sets the number of records to keep. Default: 200. MKE never prunes the most recent successful record.

Additional backup controls:

  • Backups bundle the MKE configuration that the operator last applied. Use mkectl backup --config-snapshot-fallback and mkectl restore --accept-noncurrent-config to control backup and restore behavior when that configuration is not current.
  • Set spec.backup.tempDir, or pass --temp-dir to mkectl backup, mkectl restore, mkectl upgrade, and the control plane mkectl node add and mkectl node remove commands, to move the staging directory off a small /tmp partition.

Important

Update any scripts that run mkectl backup without options. The command now fails unless you pass either --passphrase or --no-passphrase.

Authenticated registry pulls#

MKE can now pull images and charts with a registry account instead of anonymously. Authenticated pulls are supported for fresh installs, child clusters, and upgrades from MKE 3 and MKE 4.

  • Set spec.registries.imageRegistry.credentialsSecretName and spec.registries.chartRegistry.credentialsSecretName, then pass the account to mkectl apply with the --image-registry-username, --image-registry-password, --chart-registry-username, and --chart-registry-password options. mkectl stores the account in a kubernetes.io/dockerconfigjson Secret with the configured name in the mke namespace, and reuses it on later mkectl apply runs and MKE 4 upgrades.
  • For an upgrade from MKE 3, pass the same options to mkectl upgrade.
  • For child clusters, create the Secret in the mke namespace of the management cluster and reference it from the MkeChildConfig resource.
  • To keep passwords off the command line, set the MKE_IMAGE_REGISTRY_PASSWORD and MKE_CHART_REGISTRY_PASSWORD environment variables.
  • The mkectl restore command accepts the same registry options.

Important

Serve the authenticated registry over HTTPS. mkectl never sends credentials to a registry with a plain http:// address.

Organization and team resources#

MKE 4 now stores organizations and teams, including their members, grants, and LDAP sync settings, as dedicated resources instead of labeled ClusterRoles. Controllers in dex-http-server reconcile these resources into Kubernetes RBAC, and the MKE 4 Dashboard and accounts API manage them directly. The upgrade from MKE 4.2.0 and from MKE 3 converts existing organizations, teams, and grants automatically.

The new spec.authentication.ldap.noSimplePagination option applies to the LDAP sync searches that dex-http-server runs. The upgrade from MKE 3 migrates the setting.

Authentication proxy#

MKE 4 can now route outbound authentication traffic through a proxy, which allows clusters without direct internet egress to reach an external OIDC identity provider. Configure it in spec.authentication.proxy of the mke4.yaml configuration file or in the MKE 4 Dashboard under Admin Settings > Authentication > Proxy. The proxy does not apply to LDAP and is disabled by default. The upgrade from MKE 3 does not migrate MKE 3 proxy settings.

For more information, refer to Authentication proxy.

Child cluster infrastructure updates#

You can now change the infrastructure settings of existing AWS and vSphere child clusters.

  • MKE names MachineTemplates by a hash of their content, so a configuration change rolls out new machines instead of failing on an immutable template.
  • You cannot change the vSphere controlPlaneEndpointIP after you create the cluster.
  • Remote child clusters do not require this mechanism. MKE updates their mutable PooledRemoteMachine objects in place.

Child cluster configuration also changes as follows:

  • All infrastructure settings now reside under spec.infrastructure.configuration, which MKE validates for AWS and vSphere. spec.infrastructure.region is deprecated in favor of spec.infrastructure.configuration.region.
  • A child cluster can read its license from a Secret of type mke.mirantis.com/license through spec.license.secretRef. The inline spec.license.token field is deprecated for child clusters.

Control plane node add and remove#

  • The mkectl node add and mkectl node remove commands now add and remove control plane nodes when you pass --scope=controller+worker. The default scope is worker.
  • For control plane nodes, the command takes an etcd backup before and after the change. Pass --passphrase or --no-passphrase for the backups, or pass --skip-snapshot to skip them.
  • When mkectl apply joins new control plane nodes, MKE restarts the Deployments and StatefulSets in the mke and k0rdent namespaces so that their Pods spread across all controllers. This includes the mkectl apply run that rejoins controllers after mkectl restore. The mkectl node add command does not restart these workloads.

NodeLocalDNS on the Calico eBPF dataplane#

NodeLocalDNS can now be enabled on clusters that run the Calico eBPF dataplane. The combination was previously rejected by validation, as kube-proxy is disabled by design on an eBPF cluster and NodeLocalDNS relied on the kube-proxy iptables rules to intercept DNS traffic.

  • On an eBPF cluster, MKE excludes the kube-dns ClusterIP from eBPF NAT so that the node-local cache can intercept pod DNS queries. The exclusion is applied and removed automatically, in the correct order relative to the node-local-dns DaemonSet, so that enabling or disabling NodeLocalDNS completes in a single mkectl apply command without a sustained DNS outage.
  • To turn NodeLocalDNS on, you only need to set spec.nodeLocalDNS.enabled to true and run the mkectl apply command. No Calico or Felix configuration is required.
  • The spec.network.kubeProxy.disabled: true setting is accepted alongside spec.nodeLocalDNS.enabled: true.

Support is for parent and standalone clusters. The Calico eBPF dataplane is not supported on child clusters, and NodeLocalDNS on child clusters is unchanged. For detail, refer to NodeLocalDNS on the Calico eBPF dataplane.

System components rebalance when control plane nodes join cluster#

MKE 4 now automatically redistributes system components across the control plane nodes when you add control plane nodes with mkectl node add --scope controller+worker, including when the remaining controllers rejoin the cluster after a restore. Previously, the components remained on the bootstrap node until you manually ran kubectl rollout restart. Redistribution occurs only when the operation changes etcd membership, and does not apply to single-controller clusters. For more information, refer to Workload redistribution.

Operating systems#

  • MKE 4.2.1 supports Ubuntu 26.04 and RHEL 9.8.
  • Ubuntu 26.04 GPU nodes require NVIDIA GPU Operator 26.7.0, which ships with MKE 4.2.1.