Defining a 3-Node Rancher Cluster with Edge Image Builder

This one's a definition, not a deployment yet: eib-base-rancher, 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/API, not just a cluster that happens to be managed by one elsewhere. No ISO has been built, no VM booted, no hardware assigned. It's config only, modeled on the same patterns the lenny project already established.

Verify the Chart Repos First, This Time

The lenny definition shipped with two real bugs: cert-manager and MetalLB were both assumed to live in charts.rancher.io, 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 repos got checked directly before writing anything:

$ helm search repo jetstack/cert-manager --versions | head -3
jetstack/cert-manager   v1.21.0   v1.21.0   A Helm chart for cert-manager
jetstack/cert-manager   v1.20.3   v1.20.3   A Helm chart for cert-manager
jetstack/cert-manager   v1.20.2   v1.20.2   A Helm chart for cert-manager

$ helm search repo rancher-stable/rancher --versions | head -3
rancher-stable/rancher   2.14.3   v2.14.3   Install Rancher Server to manage Kubernetes clu...
rancher-stable/rancher   2.14.2   v2.14.2   Install Rancher Server to manage Kubernetes clu...
rancher-stable/rancher   2.14.1   v2.14.1   Install Rancher Server to manage Kubernetes clu...

Both real, both confirmed, both wired up correctly the first time:

edge-cluster.yaml

kubernetes:
  version: v1.33.3+rke2r1
  network:
    apiVIP: 172.16.0.20
    apiHost: api.rancher.shed.local
  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
        targetNamespace: cert-manager
        createNamespace: true
        installationNamespace: kube-system
        valuesFile: certmanager.yaml
      - name: rancher
        version: 2.14.3
        repositoryName: rancher-stable
        targetNamespace: cattle-system
        createNamespace: true
        installationNamespace: kube-system
        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 type: server — 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, which is the standard shape for a dedicated management cluster.

Rancher's Two Real Placeholders

kubernetes/helm/values/rancher.yaml has two values that genuinely cannot be filled in yet, and are 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

replicas: 3

ingress:
  tls:
    source: rancher

hostname is what a browser will actually connect to, and has to resolve somewhere real before Rancher can serve anything. bootstrapPassword stays empty on purpose — it's the initial admin credential, and an EIB definition checked into a repo is exactly the wrong place for it. ingress.tls.source: rancher picks the simplest option: the chart generates its own self-signed certificate, no cert-manager Issuer/ClusterIssuer wiring required beyond installing cert-manager itself.

                Later option: switching ingress.tls.source to secret
                would let this reuse the exact same private-CA pattern lenny already runs
                (kubernetes/manifests/cert-issuer.yaml's self-signed bootstrap issuer +
                long-lived CA certificate) instead of a separate self-signed cert per cluster.
            

Everything Else Is a Placeholder Too

With no physical hardware chosen yet, the per-node network configs use real lab IPs on the existing 172.16.0.0/24 subnet (consistent with the lenny cluster's own addressing) 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 — it's not a real OUI, so there's no mistaking these for actual hardware addresses later. kubernetes/config/server.yaml's RKE2 token is a placeholder value the same way. None of this can actually build into a working cluster until real machines are chosen and these values get replaced.

Rancher Edge Image Builder RKE2 cert-manager Helm

Blog