Lesson 01 of 12 · Foundations
Why ZTP for edge
Why edge platforms need zero-touch provisioning: the cost and risk of sending engineers to every site, what 'zero-touch' really means from power-on to a Ready cluster, the day 0/1/2 lifecycle, and the principles that make hundreds of sites manageable.
What "edge" means here
Edge sites are small computing locations close to where data is produced or used: retail stores, factories, telecom cell sites and central offices, hospitals, ships, wind farms. They share constraints:
- Many sites (tens to thousands), each small (1–10 servers).
- No IT staff on site; sometimes no easy physical access at all.
- Limited or unreliable connectivity; sometimes fully air-gapped.
- Physical risk: devices can be stolen or tampered with.
Imagine opening 500 lemonade stands across the country. You can't send an expert to set up each one. So you send every stand an identical kit and a one-page instruction: "put the table here, plug it in." The moment it's plugged in, the stand phones headquarters, downloads the recipe, and starts selling, exactly like every other stand.
Why zero-touch?
| Without ZTP | With ZTP |
|---|---|
| An engineer travels to install OS and Kubernetes | Someone racks and cables; the rest is remote |
| Days to weeks per site | Hours per site, many in parallel |
| Every site slightly different (hand-made) | Every site built from the same definition |
| Rebuilding a failed site means another trip | Rebuild remotely from Git |
| Hard to audit | Every step logged and versioned |
A truck roll (sending someone on site) can cost more than the hardware. At fleet scale, consistency is also a reliability feature: identical sites fail in identical, understood ways.
From power-on to Ready
Day 0 (before shipping) Day 1 (at the site) Day 2 (forever)
─────────────────────── ───────────────────── ────────────────
inventory: serials, MACs, BMC → power on → BMC reachable → upgrades (OS, K8s)
site definition in Git PXE/virtual media boot scale / replace nodes
signed OS images + bundles OS installed from image config changes via GitOps
network plan (VLANs, IPs) Kubernetes cluster formed monitoring, backups
GitOps applies workloads rebuild / retire site
site reports healthy
The following lessons cover each step: architecture and sizing (02–03), bare-metal provisioning (04–05), OS images and offline delivery (06–07), cluster formation (08–09), fleet management (10), edge constraints (11) and recovery (12).
Principles that make it work
- Everything declarative: hardware inventory, cluster spec, workloads, all in Git.
- Immutable, versioned images: nodes are replaced or reimaged, not hand-patched.
- Pull, not push: sites fetch their desired state; they may not be reachable from the centre.
- Assume disconnection: sites must run (and ideally self-heal) without the central platform.
- Identity and trust from the start: know which hardware is genuine, and give each site only its own credentials.
- Rebuildable: any site can be wiped and recreated from its definition plus backups.
Try it: write a site definition
- Pick an imaginary edge use case (a store, a factory line, a cell site) and list what runs there.
- Write the inventory for a 3-server site: hostnames, MACs, BMC IPs, disk devices, roles.
- Draft the site's network plan: VLANs for BMC, provisioning and workloads; IP ranges; the cluster VIP.
- List every step from power-on to "apps running", and mark which ones you can automate today.
- Estimate the cost of one truck roll vs one hour of automation work, for 200 sites.
Going deeper: organising for fleets
- Treat the site definition as a product with a schema and validation (CI rejects a site with missing MACs or overlapping IP ranges).
- Standardise hardware SKUs: every extra model multiplies firmware, driver and image testing.
- Plan the logistics too: pre-staging hardware at a warehouse, labelling, shipping, return of failed units.
- Measure the fleet: time to provision, success rate on first attempt, and number of truck rolls per quarter.
Recap
- Edge = many small, remote, often disconnected sites with no local staff.
- ZTP: after rack, cable, power, everything is automated from firmware to workloads.
- Day 0 prepares (inventory, images, definition), day 1 provisions, day 2 operates for years.
- Principles: declarative, immutable, pull-based, disconnection-tolerant, trusted identity, rebuildable.
This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.