Platform on mi-homes.org

K3s

Mon, 01 Jan 0001 00:00:00 +0000

This guide documents how to create Proxmox VMs using Terraform for use as Kubernetes nodes in a k3s cluster. The Terraform configuration clones a cloud-init template, assigns fixed IPs and SSH keys, and tags VMs for k3s roles so they can be targeted by k3s-ansible or similar automation.

Overview
#

The setup provisions two groups of VMs:

k3s masters (3 VMs): control-plane nodes for the Kubernetes cluster
k3s workers (2 VMs): worker nodes for running workloads

All VMs are created by full clone from a cloud-init template (VM ID 9999 in the examples). They receive static IPs, a common SSH user and public key, and Proxmox tags (k3s, master or worker) for identification. After Terraform applies, you deploy k3s onto these VMs using Ansible or another method. This guide uses placeholders like <subnet> and <first-master-ip>; replace them with values that match your network.

Rancher

Mon, 01 Jan 0001 00:00:00 +0000

This guide installs and operates Rancher on an existing Kubernetes cluster using Helm and cert-manager.

Official docs: Install/Upgrade Rancher on a Kubernetes Cluster

Prerequisites
#

Kubernetes cluster (K3s, RKE2, EKS, or any supported distribution)
kubectl and Helm installed

Installation
#

1. Add Helm repos
#

helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
helm repo update

2. Create namespace
#

kubectl create namespace cattle-system

3. Install cert-manager
#

Required for Rancher-generated TLS certificates (default). Skip if you use your own certificates (ingress.tls.source=secret) or TLS termination on an external load balancer.

Helm

Mon, 01 Jan 0001 00:00:00 +0000

Use commands below to install Helm, the package manager for Kubernetes.

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh
helm version

HashiCorp Vault

Mon, 01 Jan 0001 00:00:00 +0000

HashiCorp Vault can hold API keys, database passwords, tokens, and other sensitive values so they never appear in Git or Helm values. A typical Kubernetes pattern is: Vault (KV v2) → External Secrets Operator → Kubernetes Secret → Pods (env or volumes). Any workload that reads from a Secret can use this flow; you only align Vault paths and ExternalSecret fields with your app’s expectations.

Role in the stack
#

flowchart LR
 subgraph git["Git"]
 VY[Helm values / manifests]
 NS[Namespace and wiring]
 end
 subgraph cluster["Cluster"]
 V[Vault KV v2]
 ESO[External Secrets Operator]
 KS[Kubernetes Secret]
 end
 VY --> V
 NS --> V
 ESO -->|Vault API + token| V
 ESO --> KS

Vault must be running and unsealed before ClusterSecretStore and ExternalSecret resources can sync. In GitOps setups, install Vault first, then External Secrets Operator, then applications that declare ExternalSecret objects (or use equivalent sync waves / dependencies).

External Secrets Operator

Mon, 01 Jan 0001 00:00:00 +0000

External Secrets Operator (ESO) watches ExternalSecret resources and materializes ordinary Kubernetes Secret objects from an upstream backend. With HashiCorp Vault as the backend, the same pattern works for any application: you store values in Vault, declare mappings in Git, and mount or env-inject the resulting Secret as usual.

Role in the stack
#

flowchart LR
 subgraph git["Git"]
 CSS[ClusterSecretStore]
 X[ExternalSecret per app]
 end
 subgraph cluster["Cluster"]
 ESO[External Secrets Operator]
 V[Vault KV v2]
 KS[Kubernetes Secret]
 P[Pods]
 end
 CSS --> ESO
 X --> ESO
 ESO -->|token auth| V
 ESO -->|reconcile| KS
 KS --> P

ClusterSecretStore (cluster-scoped): one connection from the cluster to Vault (URL, mount, auth). Every namespace can reference it.
ExternalSecret (namespace-scoped): one per app (or per secret bundle), mapping Vault paths and properties to keys on a target Secret.
ESO reconciles on an interval and when specs change.

Install ESO after Vault is available and unsealable; install before workloads that depend on synced secrets, or ensure those workloads tolerate a short delay until the Secret exists.

Platform on mi-homes.org

K3s

Overview #

Rancher

Prerequisites #

Installation #

1. Add Helm repos #

2. Create namespace #

3. Install cert-manager #

Helm

HashiCorp Vault

Role in the stack #

External Secrets Operator

Role in the stack #

Overview
#

Prerequisites
#

Installation
#

1. Add Helm repos
#

2. Create namespace
#

3. Install cert-manager
#

Role in the stack
#

Role in the stack
#