Eliminating the OS Barrier: vSphere Kubernetes Service 3.6 Now Supports RHEL 9

For many enterprise platform teams, adoption isn’t blocked by Kubernetes features—it’s blocked by the operating system (OS). You might want the automated lifecycle management of vSphere Kubernetes Service (VKS), but you cannot abandon the Red Hat Enterprise Linux (RHEL) standards that underpin your security compliance, licensing models, and operational toolchains.

Historically, this forced a difficult choice: adopt a managed platform and rebuild your entire operational stack on a new OS (like Ubuntu or Photon), or stay on legacy infrastructure just to keep your OS.

With the release of VKS 3.6, we are removing that friction.

We are excited to announce Build Your Own Image (BYOI) support for RHEL 9. This isn’t just about adding another option to the menu; it’s about acknowledging that the best platform is one that fits seamlessly into your existing environment, without forcing you to rebuild your foundation.

The “UBI Tax” and Why the OS Matters

Why is the underlying node OS such a dealbreaker? For many, it comes down to support and licensing efficiency.

When organizations build their application stack on Red Hat Universal Base Images (UBI) and these UBI containers run on a RHEL host, they automatically inherit the host’s support status. This provides end-to-end support from Red Hat for the entire stack.

VKS 3.6 allows you to keep this end-to-end support from Red Hat by bringing RHEL 9 nodes directly into the VKS lifecycle management, preserving your support chain and compliance posture without sacrificing modern platform automation.

How It Works: The Image Baker Workflow

We didn’t just want to support RHEL; we wanted to give you control over how it’s built. VKS 3.6 introduces the Image Baker tool through the VCF CLI. Image Baker is a specialized tool designed to create customizable VM images through a declarative, systematic build process for VKS.  

Unlike traditional approaches that snapshot live VMs, Image Baker leverages an OCI-based BuildKit backend to systematically curate the filesystem. This helps ensure your images are clean, compliant, and contain the exact Kubernetes components required by VKS.

Step 1: Define the Image Spec

First, make sure you follow the prerequisites here. Once that’s complete, we can define a configuration file (e.g., rhel-9.yaml) that specifies the OS version and the Kubernetes distribution. For RHEL, you explicitly point to the Red Hat Universal Base Image (UBI).

You can also deeply customize the node at this stage—increasing disk size, installing operational tools, or hardening the OS by disabling services. For this example we’ll build a simple image, but if you’re looking for more customization options, check out the Tech Docs.

Step 2: Set Credentials and Bake

Because this process pulls from Red Hat registries, you must export your subscription credentials as environment variables. Then, using the VCF CLI vcf kr bake command to generate the image.

The tool handles the heavy lifting: it pulls the base UBI, installs the Kubernetes components (kubelet, kubeadm, CNI), applies security configurations, and packages everything into a standardized OVA file located in the artifacts/ directory.

Deploying RHEL Clusters: Zero Friction

Once the image is baked, using it is incredibly simple. The operational workflow remains identical to deploying standard VKS clusters, preserving the “single pane of glass” experience in VCF.

1. Import: Upload your generated RHEL 9 OVA to the Content Library.
2. Annotate: In your cluster YAML definition, you specify the OS resolution annotation. You can apply this in two places—the Control Plane and the Worker Node pools—to ensure the entire cluster runs on RHEL (or apply just to the worker nodes for a mixed OS cluster).

3. Deploy: Apply the configuration (kubectl apply -f cluster.yaml), and VKS handles the rest—provisioning control planes, worker nodes, and wiring up the networking.  You can check the status of the cluster using kubectl get cluster rhel-cluster -n rhel-ns.

Once the cluster is ready, get the kubeconfig with the VCF CLI or kubectl, and then verify the nodes are successfully running RHEL 9 using standard kubectl commands:

Advanced Flexibility: Mixed Clusters and Upgrades

Flexibility is the core theme of VKS 3.6. We know that migrations aren’t always “all or nothing.”

• Mixed Node Clusters: You can now run clusters with mixed operating systems. For example, you might keep your Control Plane nodes on Ubuntu or Photon OS, while running your Worker Node pools on RHEL 9 to support your specific application licensing needs.
• Seamless Upgrades: Even though you are building your own image, VKS still orchestrates the upgrade process. When upgrading an existing RHEL cluster,  simply provide the newer RHEL OVA, and VKS handles the rolling upgrade of the nodes, helping ensure zero downtime.

Meeting You Where You Are

VKS 3.6 represents a shift in how we approach enterprise Kubernetes. We are moving from rigid defaults to safer, adaptable choices. Whether you are an enterprise optimizing Red Hat licensing or a customer looking for a smooth migration path, VKS 3.6 is ready for you.

Start planning your migration today—build your image, keep your standards, and let VKS handle the rest.