RKE2 HA Platform Foundation¶
Overview¶
RKE2 HA Platform Foundation provides the Kubernetes base for later workload delivery. The current environment has a three node control plane, a published kubeconfig, and a live GitOps root.
It is the cluster base that later application, secret delivery, and burst services build on.
Case study¶
- Context: the estate had no on-prem Kubernetes. Application and secret delivery had no repeatable target, and each new workload requirement reopened the question of where and how to run it.
- Challenge: provisioning a HA control plane and handing it to operators in a usable state (with kubeconfig published and GitOps ready) through a single controlled path rather than a sequence of manual steps.
- Approach:
onprem/rke2@v1delivers the three-node control plane. Kubeconfig is published as part of the platform workflow, not assembled manually. Argo CD and secret delivery are added on top of the same cluster baseline throughonprem/rke2-workloads@v1. - Outcome: RKE2 control plane healthy across
rke2-cp-01,rke2-cp-02, andrke2-cp-03. Kubeconfig published and immediately operable. GitOps roothyops-workloads-rootactive. Later services (GKE burst, secret delivery) build on the same foundation.
Covers cluster delivery, published kubeconfig access, node readiness, and the extension path into GitOps, secret delivery, and workload rollout.
Outcome¶
The result is an on-prem Kubernetes platform that is ready for controlled workload delivery.
- Three control plane nodes provide the current HA baseline.
- Operator access is published as part of the platform path rather than assembled manually.
- GitOps, secret delivery, and burst extensions build on top of the same cluster.
Operating model¶
- RKE2 provides the on-prem HA control plane.
- Published kubeconfig makes the cluster immediately operable after delivery.
- GitOps and secret delivery extend the same baseline rather than creating parallel paths.
- Private runtime delivery can be added later without changing the public workload surface.
Architecture¶
The cluster is a first-class platform service. Kubeconfig is published as part of the delivery path, and workload extensions build on the same baseline rather than creating parallel paths.
Cluster sequence¶
- The RKE2 control plane is provisioned through the platform path.
- Kubeconfig is published for operator use.
- GitOps and secret delivery are added on top of the cluster.
- Public and private workload paths can then be introduced without changing the foundation.
Platform state¶
IP addresses, hostnames, and instance identifiers visible in screenshots and recordings reflect the ephemeral infrastructure provisioned during the recorded exercise.
Implementation¶
- Cluster layer: RKE2 delivers the HA control plane for the current environment.
- Operator handoff: kubeconfig is published as part of the platform workflow.
- GitOps readiness: Argo CD and workload roots extend the same cluster baseline.
- Secret delivery: on prem GSM bootstrap and GKE Workload Identity use the same delivery model downstream.
Key components¶
- Cluster blueprint:
onprem/rke2@v1 - Workload extension path:
onprem/rke2-workloads@v1 - Cluster module:
platform/onprem/rke2-cluster - Related extensions:
platform/k8s/gsm-bootstrap,platform/k8s/gcp-secret-store,platform/k8s/runtime-bundle-secret
Where it fits¶
- on-prem Kubernetes foundations for controlled workload rollout
- GitOps-ready internal platform clusters
- secret delivery, workload burst, and private runtime delivery built on one cluster baseline
References¶
Further reading
Implementation references
platform/onprem/rke2-clusterplatform/k8s/gsm-bootstrapplatform/k8s/gcp-secret-storeplatform/k8s/runtime-bundle-secret
Related¶
Related reading¶
What was verified¶
Verified against HybridOps v1.0.1 with the RKE2 control plane healthy, kubeconfig published, and the GitOps extension path available.

