See how Cilium with Isovalent Networking for Kubernetes runs on Red Hat OpenShift Hosted Control Planes (HCP). This demo walks through running Cilium on the HCP management cluster, then creating a new HCP cluster and installing Cilium there as well. As the first and only CNI certified for OpenShift HCP, Cilium delivers advanced networking, security, and observability, ready for enterprise adoption. We're proud to announce that Isovalent Networking for Kubernetes is now officially supported for Hosted Control Planes. This milestone makes us the first and only CNI currently to achieve the new Hosted Control Planes certification, and it strengthens our position as the enterprise choice for secure and scalable Kubernetes networking. Just as a quick debrief at the start, what actually is Hosted Control Planes? If you're using Red Hat OpenShift today but haven't looked at some of these deployment options, Hosted Control Planes is a modern cloud-native architecture that allows the control plane components of an OpenShift cluster to be decoupled from the nodes and run as pods on a separate management cluster. Think about all the services that normally run on those control plane nodes, such as the API server, the controller manager, etcd, and the scheduler. With Hosted Control Planes, they run centrally on the management cluster, while the hosted clusters themselves just run worker nodes. From an architectural point of view, on the left-hand side you have the typical standalone control plane deployment model that we all know and have used with OpenShift for years. You have control plane nodes running all of those components, and then a worker pool running your workloads. On the right-hand side, with Hosted Control Planes, you have a central management cluster, powered by HyperShift under the hood, which hosts the control plane services for each tenant cluster in dedicated namespaces. Outside of that cluster, you then have the worker-node clusters that are focused purely on running workloads. There are a number of architectural benefits that come with that, such as cost efficiency, faster provisioning, improved isolation for tenant-style environments, and simplified operations when you want to hand these clusters off to different teams. Install Cilium on the management cluster Before I dive into the live demo showing this working with Isovalent Networking for Kubernetes using Cilium, I just want to show you the official certified OpenShift CNI plugins page. If I do a quick search for Hosted Control Planes, you can see that we only get one match, and that is our offering. We're certified across OpenShift 4.16, 4.18, and 4.19, and we're the only CNI that offers this today. Now I'm going to take you through deploying a new cluster on top of our existing Hosted Control Planes management cluster that's already running Cilium. I'll show you those commands and some of the configuration options you need to have in place. First of all, we have our default OpenShift cluster deployed in AWS today. The Hosted Control Planes capability is enabled by default if your deployment meets the requirements, although you can disable it if needed. I do recommend going through the OpenShift documentation first so you understand the prerequisites, the architecture, and what's expected before diving into the setup. I'm going to double-check the status. The multicluster engine is already up and available, and the HyperShift add-on is deployed, healthy, and ready. If I look at my OpenShift environment, it looks like any other deployment into AWS, with all the namespaces and pods you would expect to see for a brand new cluster. At the top, because we've already installed Cilium into this cluster, we can also see all of our Cilium pods deployed already. If I run a quick Cilium status check, everything is healthy, which is great. This is essentially a normal OpenShift cluster, but with the prerequisites in place so that Hosted Control Planes is available. Install Cilium on the HCP cluster Now we're going to create a new cluster that we're going to install Cilium on. Unlike a normal OpenShift deployment, if you remember from the architectural diagram, the control plane nodes don't exist as separate nodes for that guest cluster. The services that would normally run on those control plane nodes actually run inside the management cluster in a dedicated namespace. So let's run the commands for this. There is a special HCP CLI tool that you can download. We've already created the environment in AWS and provided the necessary details, and it's going to go off and create the cluster for me. That took around two minutes to create. Now I'm going to check the status of that cluster. It has its own cluster resource inside my OpenShift environment, and because we're still connected to the management cluster, we can see that status from there. Right now it's partially available. The control plane is coming up, but we haven't installed Cilium yet. That's because when I created the cluster, I explicitly set the network type to Other, which means don't install a default CNI. That means there needs to be an additional step, whether manual like I'm doing today or automated through GitOps, to connect to the new cluster once it's available and then install and configure the CNI. If I list the pods that are relevant to this new cluster, you'll see a new namespace prefixed with the cluster name. The pods in that namespace are everything we'd normally expect to run on control plane nodes in a standalone cluster, but because we're using Hosted Control Planes, they're centralized inside the management cluster. Now it makes sense for us to connect to the new cluster and install Cilium there. I'm going to use the HCP command again to create a kubeconfig file and export it. If I run oc get nodes, we can see that I have three nodes available and they only show the role of worker, because there are no dedicated control plane nodes. As expected, the status is NotReady because we don't have a CNI yet. If I look at the pods running there, it's a shorter list than a full standalone OpenShift deployment. We still have some core management services, but we don't yet have the networking layer in place. Before we start the installation, I'm going to define two variables for the Kubernetes service host and service port that we'll inject into the manifests. Deploy OpenShift Hosted Control Planes I'm now moving into my Cilium lifecycle folder. I've already pre-downloaded the manifests required to install Isovalent Networking for Kubernetes into this environment. Any Isovalent customer can get those from our enterprise documentation, which also includes the Hosted Control Planes steps. I'm going to inject the Kubernetes service host and port into a few configuration files. First into the lifecycle manager, then into the subscription, and finally into the Cilium configuration itself. The reason I'm doing this is because I'm enabling kube-proxy replacement in Cilium so that I don't need to run kube-proxy on the cluster. I'm mostly using the default Cilium config from the documentation, but with those two additional variables at the bottom. Another file that's really important here is the operator configuration. If you don't create this properly, you may end up with the wrong settings on the cluster. We need to keep the default network type as Other, and we also need to set the kube-proxy deployment to false. We do that by editing the OpenShift network custom resource named cluster. Again, this is all documented in our enterprise docs. Now that those files are ready, I'm going to apply the first manifest to create the Cilium namespace. That's where the Cilium services will be installed with the right security context and configuration for OpenShift. This is slightly different from a standard Kubernetes install, where we typically use the kube-system namespace. We're also going to install the Cilium CRDs so the rest of the configuration can be applied successfully. Once those prerequisites are in place, I can apply the rest of the manifests in the lifecycle folder. After that, I'll wait for Cilium to install and become ready using the Cilium CLI wait command. That didn't take too long. I think it was around 44 seconds for Cilium to come up, so that's very fast. Validate OpenShift Hosted Control Planes At this point, we're pretty much done. We now have two clusters: the management cluster and the secondary Hosted Control Planes cluster we just created. If I run oc get nodes, we can see the nodes becoming ready. After another short wait, all three nodes show as Ready, which is exactly what we want. We already know Cilium is healthy, and if I check the pods again we can see the rest of the OpenShift components continuing to start in the background. Because the CNI is now available, the rest of the OpenShift installation can complete successfully. And that's where we're going to leave today's video: showing how to deploy a Hosted Control Planes environment in OpenShift using Cilium on the management cluster, and then install Cilium on the hosted cluster as well. Thank you very much.