Some estates are Kubernetes-first. Many are not. They still run most of the business as virtual machines and want Kubernetes only where it pays for itself. Putting every application on OpenShift on day one is a different project from replacing VMware.
The path on kcore
kcore creates a Kubernetes cluster on nodes that are already members of the kcore cluster. The first apply stores the cluster, generates certificates, and deploys kubelet, etcd, and the API server. Put every member in that first manifest. Membership is fixed at create. kctl kubernetes scale records nodes. It does not join or remove them.
An API VIP can run with keepalived. Cilium is installed on the primary cluster, the one whose API port is 6443. A second cluster on the same hosts must not run a second Cilium. The agents would share BPF pins. Volumes can be LVM or ZFS directories through the local-path provisioner, or an LVM thin pool that does not bind claims. The Kubernetes page states those limits in full.
Terraform provider 0.5.0 has no Kubernetes cluster resource. The manifest and kctl kubernetes apply are the path. A ClusterUpdate moves the host NixOS pin, which is where the Kubernetes binaries come from. There is no separate cordon-and-drain roller.
How to decide
- VM-first, Kubernetes later, same metal: this model.
- Kubernetes is already the operating system and VMs are the exception: look at a Kubernetes-first product and be honest about the staff you have.
- You think you need a second Cilium on the same hosts: do not.
Stay on VMs until the cluster manifest is something you can re-apply. Then add the workers in that first manifest, not as a surprise scale later.
Questions: team@tacconiconsulting.com.