HackMD
Hosted Control Planes or Hypershift
Tooling that exists to explore this stuff on a libvirt host
https://github.com/karmab/kcli
Basic Architecture:
in the hypershift cluster you can deploy multicluster engine that will enable you to deploy hosted control planes for other clusters. These control planes can be exposed by service type lb or by ingress.
you can then deploy openshift virtualization which enables you to then create node pools. These node pools can be used to define kubevirt vms that are workers, or you can use them to define the ignition configs for bare metal nodes.
So the hypershift cluster can encompass a bunch of beefy recycled vsphere nodes and you can then use openshift apis to spin up and manage the lifecycle of virtual machines that will be the workers to these hosted control plane nodes.
The benefit here is that you can recycle your virt compute investment and use that to dynamically scale task built openshift clusters.
Cilium Use Cases.
In the hypershift cluster:
Currently, Openshift documents that the cni must be ovn-kubernetes. This I think is tied to the need to support vm migration between nodes etc.
We can do some good work here on the hypershift cluster as well as in a lot of cases these clusters are on bare metal nodes in datacenters. So the need for load balancers, bgp all apply.
In the hosted control plane cluster:
This install is pretty straight forward. From the cilium side the control plane is already up similar to eks. When the node pool get's provisioned we land the cilium operator on one and deploy the rest of the stack.
The guest clusters can be deployed with or without kube-proxy replacement no problem.
From the perspective of the guest cluster you can't see the control plane nodes, again because of the eks like nature of hosted control planes.
Stretch with a more sophisticated operator!
Install cilium operator in the hypershift cluster discover that we are in a hypershift cluster. Then integrate into the guest clusters as they are provisioned etc.
