If you’re running containers on Oracle Linux 7, January 2025 marked a quiet but important turn. That’s when OL7 x86_64 moved into Extended Support (ES) through June 2028. Security and critical fixes continue through ES RPMs, but OL7 images stopped refreshing after December 2024.

What’s more, Kubernetes 1.35 was released in December 2025. Kubernetes 1.35 standardizes on cgroup v2—something OL7 cannot offer. Kubernetes 1.35 will soon be supported in OKE.

Let’s go over what these changes how these changes impact you.

  • You can still use OL7 in OKE, but the move to Extended Support (ES) means you need to tweak your patching. OL7 remains patchable even though the images are frozen. The task of patching shifts from “pull a new image” to “apply ES RPMs” in your build or startup process.
  • Starting with Kubernetes 1.35, OKE will require Oracle Linux 8 images or higher for OKE images. OL7 is not supported on 1.35 and later, and Platform Images (OL7 or OL8) are not supported for 1.35 and on.
  • When it comes to cgroup v2 and Kubernetes 1.35, there’s an important usability change. You will find that the kubelet won’t start on an OS that lacks cgroup v2. So, to avoid a stalled upgrade and an unplanned outage, you will want to plan an OS transition before you move to 1.35.
Note: This post reflects the state of support at publication. For the latest Oracle Linux lifecycle, supported OKE versions, and migration guidance, review the current documentation and policies before making changes.

Here’s what you can do now. Start by completing an inventory of where OL7 shows up—images in pipelines, and node pools in clusters. If you’re staying on 1.33/1.34 for now, pin to the December 2024 OL7 images and make ES updates part of your flow. That means enabling ES repositories, so package managers and scanners see patched packages, re‑signing images after updates, and deploying by digest so what runs matches what you scanned.

Next – when you start heading to 1.35, treat “move OKE OL7 images to OKE OL8 images” as prerequisite work. There is no in‑place OS upgrade for nodes. You would do well to start slowly: spin up a small OL8 OKE node pool, migrate a few services, and check the details that matter (containerd/systemd cgroup v2 settings, kubelet flags, CNI/CSI/DaemonSets, autoscaling, and observability). When the pattern is solid, repeat: add OL8 pools, cordon and drain OL7 nodes, and remove the OL7 pool when stable. OKE will allow the 1.35 upgrade once all node pools use OKE OL8 images.

Remember these dates in mind as you develop your planning for the future.

  • December 2024: Final OL7 image refresh.
  • January 2025: OL7 enters Extended Support; quarterly updates for 1.33 and 1.34 continue
  • December 2025: Kubernetes 1.35 published with cgroup v2 (which is not supported by OL7).
  • Through June 2028: OL7 ES window.

This change does not limit you to a frozen security posture. ES RPMs keep you current if you build them into CI/CD. Scanners, SBOMs, and signatures should reflect those updates; many teams add a scheduled rebuild so security evidence stays fresh even when the image tag doesn’t move. On the cluster side, blue/green node pool cutovers remain the safest way to move OS versions. Keep Pod Disruption Budgets honest, validate CNI/CSI versions, and confirm that logging and metrics tell you the truth before you retire an old pool.

We know change can be difficult, but let’s take a moment to call out how the OL7 ES and Kubernetes 1.35 changes bring value to different teams in your organization.

  • Platform teams keep control: OKE blocks risky upgrades, and OL8 OKE images provide a known‑good baseline for 1.35+.
  • App teams get an upgrade path with guardrails: keep shipping on OL7 with ES while you test on OL8; move when ready.
  • Security and compliance see continuity: ES patches show up in builds and scans; signatures and digests keep provenance clear; Cloud Guard and Vulnerability Scanning help you prove posture.

To wrap up: If Kubernetes 1.35 is on your roadmap, it’s time to schedule an OL8 OKE pilot. If you’re staying on 1.33/1.34, make your ES patching and verification muscle‑memory. For migration planning or ES adoption questions, contact your Oracle account team or Cloud Solution Architect, or open a support request.

Resources