Defining a 3-Node Rancher Cluster with Edge Image Builder

A definition, not a deployment yet: a new EIB project, separate from the lenny cluster, describing a 3-node RKE2 HA control plane whose entire job is running Rancher Manager itself — the management UI and API, not just a cluster that happens to be managed by one elsewhere. No ISO has been built, no VM booted, no hardware assigned yet. Config only, modeled on the same patterns the lenny project already established.

Verify the Chart Repos First, This Time

Lenny's definition shipped with two real bugs: cert-manager and MetalLB were both assumed to live in the same Helm repo as Longhorn, copied from how Longhorn is sourced there, without actually checking. Neither chart exists in that repo at all — both would have failed to resolve at build time. This time, both real repos got checked directly before writing anything, and both charts wired up correctly the first time:

edge-cluster.yaml

kubernetes:
  helm:
    repositories:
      - name: jetstack
        url: https://charts.jetstack.io
      - name: rancher-stable
        url: https://releases.rancher.com/server-charts/stable
    charts:
      - name: cert-manager
        version: v1.20.2
        repositoryName: jetstack
        valuesFile: certmanager.yaml
      - name: rancher
        version: 2.14.3
        repositoryName: rancher-stable
        valuesFile: rancher.yaml
  nodes:
    - hostname: rancher1.shed.local
      initializer: true
      type: server
    - hostname: rancher2.shed.local
      type: server
    - hostname: rancher3.shed.local
      type: server

All three nodes are servers — no separate agent pool. Rancher's own workload is light enough to run directly on the same three nodes that form the HA control plane, the standard shape for a dedicated management cluster.

Rancher's Two Real Placeholders

The values file has two things that genuinely cannot be filled in yet, left as visible placeholders rather than plausible-looking fake data:

kubernetes/helm/values/rancher.yaml

hostname: rancher.shed.local    # must resolve to apiVIP / the ingress LB
bootstrapPassword: ""           # never commit a real value

ingress:
  tls:
    source: rancher

hostname is what a browser will actually connect to. bootstrapPassword stays empty on purpose — it's the initial admin credential, and a checked-in EIB definition is exactly the wrong place for it. ingress.tls.source: rancher picks the simplest option: the chart generates its own self-signed certificate, no extra cert-manager wiring beyond installing it.

Later option: switching to a secret-sourced cert would let this reuse the exact same private-CA pattern lenny already runs, instead of a separate self-signed cert per cluster.

Everything Else Is a Placeholder Too

With no physical hardware chosen, the per-node network configs use real lab IPs on the existing subnet but obviously-fake MAC addresses:

Host	Role	MAC	IP
`rancher1.shed.local`	server (initializer)	`00:00:00:00:00:21` placeholder	`172.16.0.21`
`rancher2.shed.local`	server	`00:00:00:00:00:22` placeholder	`172.16.0.22`
`rancher3.shed.local`	server	`00:00:00:00:00:23` placeholder	`172.16.0.23`

The 00:00:00 prefix is deliberate — not a real OUI, so there's no mistaking these for actual hardware later. None of this can build into a working cluster until real machines are chosen and these values get replaced.