Skip to content

Raspberry Pi k3s fleet — prerequisites and assumptions

Parent runbook: How to provision k3s, Longhorn, and Rancher on a Raspberry Pi fleet.

Mandatory

  1. 64-bit Linux on every node, kernel and userspace aligned with k3s installation requirements (verify current doc at deploy time).
  2. Unique hostname per node (or explicit K3S_NODE_NAME at join)—duplicate names break joins; see Raspberry Pi fleet provisioning standard.
  3. Synchronized time (systemd-timesyncd, chrony, or NTP on the LAN)—required for TLS, logs, and etcd coherence.
  4. Outbound path to pull images during install (or a private registry plan documented in advance)—air-gapped installs are Later and out of scope for this outline.
  5. Operator skill: ssh, sudo, basic kubectl, willingness to read upstream k3s / Longhorn / Rancher docs for version-pinned commands.

Assumptions (explicit)

Assumption If false
Small fleet (typically 1 server + 1–4 agents, not a hyperscale datacenter) Revisit etcd sizing, network policy, and monitoring—still not “infinite Pi.”
Ethernet backhaul for cluster nodes during bootstrap Wi‑Fi-only may work but is not assumed stable for Longhorn replication or etcd latency.
You can tolerate maintenance windows on P0/P1 HA control plane is Optional; see Central and HA storage options.
Workloads are modest (a few stateful services, not hundreds of pods per node) Set resource requests/limits and avoid Rancher + heavy observability on the same tiny nodes.

Phase scope

Phase What this package assumes you want
P0 Learn k3s + maybe Longhorn; data disposable; single k3s server OK.
P1 Pilot workloads (e.g. farmOS trial); backups mandatory; still one server acceptable if RTO is honest.
Later HA k3s servers, tested failover, Rancher as a managed component, off-site backup targets.

Optional (HA / scale)

  • HA control plane (multiple k3s servers + embedded etcd or external datastore)—see k3s HA docs externally.
  • Dedicated monitoring stack (Prometheus/Grafana) on separate hardware—not on 2× Pi 4 by default.