Skip to content

GitOps Kubernetes Foundation

Executive summary

  • Provisions an on-prem RKE2 control plane and worker pool through the same validation and lifecycle model used elsewhere in the platform.
  • Produces a clean kubeconfig handoff so the cluster can be validated immediately after the blueprint completes.
  • Establishes the baseline required for later GitOps and workload blueprints without treating Kubernetes as a one-off special case.
  • Keeps the wider platform story consistent: networking, data services, and Kubernetes follow the same contract-driven path.

Case study – how this was used in practice

  • Context: The platform needed a repeatable Kubernetes baseline before workload rollout and GitOps overlays could be treated as standard operations.
  • Challenge: Cluster delivery had to stay aligned with the same environment, validation, and lifecycle rules used for networking and database services.
  • Approach: The RKE2 blueprint path was used to provision the cluster, publish kubeconfig state, and confirm node readiness before workload layering.
  • Outcome: The cluster now fits cleanly into the wider platform instead of being treated as a separate special-case automation lane.

Demo

Video walkthrough

  • Video placeholder: replace VIDEO_URL_HERE with the published walkthrough URL.
  • Suggested embed target: VIDEO_URL_HERE

Show blueprint completion, kubeconfig retrieval, kubectl get nodes, and the baseline system pods that confirm the cluster is ready for the next layer.

Screenshots

Add these files when they are ready:

![kubectl get nodes -o wide against the new cluster](./images/gitops-kubernetes-foundation-01-kubectl-nodes.png)
![Baseline system pods after the cluster becomes ready](./images/gitops-kubernetes-foundation-02-system-pods.png)
![Argo CD or workload-ready follow-on view](./images/gitops-kubernetes-foundation-03-gitops-follow-on.png)

Architecture

  • Cluster layer: on-prem RKE2 control-plane and worker nodes.
  • Operator handoff: kubeconfig state is published by the platform path instead of assembled manually.
  • Extension path: GitOps and workload layers sit on top of the same environment model without changing the underlying foundation.

Implementation highlights

Evidence and run records

Relevant run records typically live under:

  • envs/dev/logs/module/platform__onprem__platform-vm/...
  • envs/dev/logs/module/platform__onprem__rke2-cluster/...
  • envs/dev/state/kubeconfigs/...

Learning outcomes

  • Understand how Kubernetes delivery fits into the same contract-driven platform model.
  • See the cluster handoff from blueprint completion to operator validation.
  • Recognize the foundation required before GitOps and application rollout are added.

Reuse and extensions

  • Extend this baseline with Argo CD, workload blueprints, or later DR-aware application patterns.
  • Reuse the same environment and validation rules for additional clusters or separate training lanes.

Status and versioning

Validated against the current on-prem RKE2 blueprint path. Video and screenshots are still to be added.

Maintainer

  • Owner: HybridOps
  • Primary contact: platform-docs
  • Last reviewed: 2026-03-09