Releases

metal3-io v0.13.0 drops the iRMC driver, deprecates BMH firmware spec, and ships HostClaim CRDs plus multi-arch PXE boot — a release with real breaking changes that demand pre-upgrade review.

• breakingAudit iRMC usage and BMH.Spec.Firmware fields before upgrading

  The iRMC driver is gone — any BareMetalHost resources targeting iRMC BMC endpoints will stop reconciling after upgrade. Separately, BMH.Spec.Firmware is now deprecated; while it won't immediately break, you should plan migration to the replacement API. Scan your BMH manifests and Helm values for both before touching production.

• breakingVerify CAPI and controller-runtime compatibility in your management cluster

  The jump to CAPI v1.13.1 and controller-runtime v0.23.3 is not trivial. If you run other CAPI providers alongside metal3, check their compatibility matrices now. A version mismatch between providers sharing the same management cluster can cause subtle CRD conflicts or webhook failures at runtime.

• enhancementAdopt HostClaim CRDs for declarative bare-metal host allocation

  HostClaim and HostClaimSet resources give you a Kubernetes-native way to request and reserve bare-metal capacity without writing custom controllers. If you're currently managing host allocation through scripts or external tooling, evaluate whether HostClaim covers your use case — it's now feature-complete enough to replace simple reservation workflows.

OpenYurt v1.7.0 ships OTA image preheating for near-zero-downtime edge upgrades, label-driven YurtHub deployment, K8s-on-K8s support, and Kubernetes v1.34 compatibility — alongside removal of several deprecated components.

• breakingAudit usage of removed components before upgrading

  YurtAppOverrider, YurtAppDaemon (controller + webhook), yurt-coordinator, and the delegate lease controller are gone. If your workloads or Helm charts reference any of these, they will break silently or fail to deploy post-upgrade. Audit your manifests, Helm values, and any automation scripts before cutting over. The NodePool CRD also moves to v1beta2 — verify your tooling handles the new API version and the renamed field (enableLeaderElections replaces enablePoolScopeMetadata).

• enhancementAdopt OTA image preheating for edge DaemonSet upgrades

  If you manage DaemonSets on edge nodes with constrained or intermittent connectivity, the new ImagePreHeat controller is a practical fix for upgrade-induced downtime. Trigger preheating via the new OTA API endpoint before scheduling the rollout. Watch the PodImageReady condition to confirm images are cached before initiating the actual upgrade. This is especially valuable for large images or nodes behind slow WAN links.

• enhancementSwitch to label-driven YurtHub onboarding

  The new YurtNodeConversionController lets you onboard and offboard edge nodes by applying a label — no more running yurtadm join manually per node. This is a meaningful operational improvement if you manage fleets of edge nodes. Start testing this workflow in a non-production node pool first, since it interacts with systemd directly and the feature is new in this release.

Flatcar stable-4593.2.0 is a large security + infrastructure release: 150+ kernel CVEs patched, openssh/openssl/curl/intel-microcode updated, and significant initrd/partition layout changes that need attention before upgrading.

• securityMass CVE remediation across kernel and userspace — update now

  Linux kernel patches cover 150+ CVEs, and userspace components (openssh 10.2_p1, openssl 3.5.4, curl 8.16.0, intel-microcode, gnupg, pam) each carry their own CVE fixes. This is a large security catch-up from Stable 4459.2.4. Any Flatcar node on stable should be updated promptly — the auto-update mechanism will handle it, but verify nodes are actually cycling through updates if you have update pauses configured.

• breakingsshd now uses OpenSSH upstream defaults including post-quantum key exchange

  sshd_config no longer hard-codes Ciphers, MACs, and KexAlgorithms; OpenSSH upstream defaults now apply, which includes post-quantum key exchange. If your environment requires specific legacy algorithms (e.g., for compliance tooling or older SSH clients), add drop-in config to /etc/ssh/sshd_config.d/ before upgrading. Test SSH connectivity after the update in a non-prod node first.

• breakingPartition layout changed; kernel module availability in first-stage initrd is reduced

  Partition sizes have grown: /boot to 1 GB, /usr to 2 GB, /oem to 1 GB. Existing nodes can still update, but new disk images will use the larger layout. If you have tight disk quotas, pre-provision or verify disk images have room. Also, the kernel+initrd on /boot is now half the size due to a two-stage initrd split — if any required drivers were only in the first-stage initrd, you may see boot issues. Report regressions to the Flatcar team immediately.

KubeEdge v1.23 ships a major edge DB refactor (Beego → GORM), node query optimization to cut edge-cloud bandwidth, device anomaly detection in CRDs, and solid Windows EdgeCore improvements.

• breakingUpdate all Device status reads to use the new DeviceStatus CRD

  Device status has been extracted from the Device CRD into a standalone DeviceStatus CRD. The release says backward compatibility is maintained for the CRD schema itself, but any code, scripts, or automation that reads device status directly from the Device object will silently miss updates after the upgrade. Audit your operators, dashboards, and GitOps pipelines before upgrading — reroute status reads to the new DeviceStatus CRD.

• enhancementValidate edge DB behavior after the Beego-to-GORM migration

  The entire edge database layer has been rewritten. GORM replaces Beego ORM and all DB operations are now funneled through a single MetaManager entry point. This is a lower-risk change but still a deep internal refactor. Run your existing edge workloads against a staging environment on v1.23 before rolling to production — watch for any edge cases in MetaManager behavior, especially around reconnect and offline-mode scenarios.

• enhancementTake advantage of local node query optimization for large deployments

  If you're running dozens or hundreds of edge nodes, the shift from remote CloudCore node queries to local edge DB lookups should noticeably reduce your edge-cloud tunnel bandwidth. No configuration change is required — CloudCore automatically syncs node updates to the edge DB. Still worth monitoring your edge-cloud channel metrics post-upgrade to confirm the improvement in your specific topology.