Files
register-referentie/docs/architecture/adr-0033-kubernetes-via-one-helm-chart.md
T
not 17f1f2f809
CI / lint (push) Successful in 1m46s
CI / build (push) Successful in 1m29s
CI / unit (push) Successful in 1m5s
CI / frontend (push) Successful in 1m41s
CI / mutation (push) Successful in 3m30s
CI / verify-stack (push) Successful in 5m50s
docs(nav): publish every ADR and runbook, gated by a nav check (closes #169) (#172)
## What & why

`docs/` is the source of truth (CLAUDE.md §12), but only pages listed in `mkdocs.yml`'s nav
are published — and mkdocs' own `validation.nav.omitted_files: warn` keeps the build green
while dropping the rest. So the site had quietly stopped at **ADR-0010** and
**`runbooks/ci.md`**: 31 pages, including every ADR from 0011 to 0034, six of the seven
runbooks, and `synthetic-data.md`, existed in the repo and nowhere else.

- `infra/check-docs-nav.py` fails when a page under `docs/` is not in the nav. It runs in
  `make lint`, so the existing CI job gates it — python3 only, no new tooling, and no
  mkdocs install needed to check it.
- The nav now lists all 34 ADRs, all 7 runbooks and `synthetic-data.md`.
- ADR-0033's `Slice:` header said "none yet"; #25 closed it.
- The landing page gained a pointer to the Talos runbook.

Closes #169

## Definition of Done

- [x] Linked Gitea issue (above).
- [x] Failing test committed before the fix — the red commit lists all 31 missing pages.
- [x] Implementation makes the test pass.
- [x] Conventional Commits referencing the issue (`refs #169`).
- [ ] CI green — awaiting the run on this PR (`python3 infra/check-docs-nav.py` passes locally;
      `make lint` also needs the .NET SDK, which CI has).
- [x] `docker compose up` unaffected — docs and `mkdocs.yml` only, plus one `make lint` line.
- [x] Docs updated — that is the change.
- [x] No ADR needed: no dependency, no boundary, no §8 rule touched.
- [x] Not user-visible, so no demo note.

## Notes for reviewers

- The check is a **substring test**, not a YAML parse (there's a `ponytail:` note in the
  script): a page's path either appears in `mkdocs.yml` or it doesn't. That keeps it
  dependency-free — `mkdocs.yml` can't be read by `yaml.safe_load` anyway, it carries a
  `!!python/name:` tag for the mermaid fence. It does not check that an entry *points at a
  file that exists*; mkdocs' `not_found: warn` covers that direction.
- ADR labels in the nav are shortened by hand (`"ADR-0013: Behandel-portal wiring"`), since
  several H1s are a full sentence.

**Known gap, not fixed here:** CLAUDE.md §12 says the site is "published via a Gitea Actions
workflow to Gitea Pages", and no such workflow exists — `mkdocs build` is never run, by CI or
by any make target. Gitea has no built-in Pages, so publishing needs a decision (a
`gitea-pages` server, an artifact, or a static host) rather than a patch. Worth its own issue
if the published site is actually wanted; until then this PR makes the nav correct for whoever
runs `mkdocs serve`.Reviewed-on: #172
2026-09-18 12:55:20 +00:00

162 lines
10 KiB
Markdown

# ADR-0033: Kubernetes deployment is one values-driven Helm chart, not a chart per service
- **Status:** Accepted
- **Date:** 2026-09-04
- **Deciders:** Respellion engineering
- **Slice:** #25 (S-24) — raised directly as a deployment-target request and matched to
that issue afterwards; see the "Process note" at the end
## Context
The stack is defined once, in `infra/docker-compose.yml`: 30-odd containers made of six
upstream Common Ground modules (OpenZaak, Open Notificaties, Objecten, Objecttypen,
Keycloak, Flowable), their databases and workers, five .NET services, four portals, six
one-shot bootstrap containers, and an observability backplane (off by default here). Compose is the
CI-canonical stack: `make verify` and every `verify-*` script drive it.
We now also want the stack on Kubernetes — first target a **single-node Talos VM on a
laptop**. Four properties of this particular stack shape the answer:
- **The upstream images are used verbatim** and read their configuration from a mounted
directory (`setup_configuration/data.yaml`, Keycloak realm exports, BPMN/DMN). Compose
streams those files into external volumes (`infra/seed-config.sh`) because bind mounts
don't reach sibling containers on the CI runner. Kubernetes needs the same files as
ConfigMaps — from *somewhere*.
- **Django's `URLValidator` rejects single-label hosts.** Compose works around it by
handing the ACL and the seeds a container *IP* (ADR-0009, ADR-0020, ADR-0029, and the
`objecten.local` network alias). In Kubernetes a Service FQDN is already multi-label, so
the workaround has a natural replacement — but the hosts have to line up exactly, since
Objecten reflects the request Host into the URLs it publishes to NRC.
- **The OIDC issuer must be one string** for both the browser and the BFF (ADR-0010).
`infra/host-browser.yml` already solved this for a host browser: pin `KC_HOSTNAME`, keep
backchannel discovery in-cluster, and mount a `config.json` per portal.
- **Nothing here is highly available.** One replica of everything, on one node.
## Decision
**One chart — `infra/helm/big-reference` — whose `values.yaml` is a near-literal
transcription of the compose file, rendered by three generic templates (Deployment, Job,
Service) over a `workloads` map.** Adding a service is a values edit.
Consequences of that shape, each chosen deliberately:
- **Config files are not copied into the chart.** `infra/helm/seed-configmaps.sh` creates
the ConfigMaps from the files that already live in the repo — the Kubernetes sibling of
`infra/seed-config.sh`. The chart therefore needs `make k8s-seed` before `helm install`,
which is the same two-step dance compose already has.
- **Bootstrap one-shots become Jobs, with no ordering mechanism.** Every one is idempotent
(ADR-0020); each waits for the TCP ports it needs via a busybox init container and
Kubernetes retries the rest. `make k8s-reseed` re-runs them.
- **The four Django services apply their own `setup_configuration`** —
`args: [sh, -c, "/setup_configuration.sh && exec /start.sh"]` — instead of getting a
separate `*-init` Job like compose. Both of those image scripts run
`manage.py migrate`, and compose serialises them with
`depends_on: service_completed_successfully`; Kubernetes has no such edge, so a Job and
its web pod migrate the same database concurrently and Django dies with
*"relation zgw_consumers_service already exists"*. Running the two steps in order inside
the one container leaves exactly one migrator per database, and deletes four workloads.
- **`args`, never `command`.** Compose's `command:` replaces the image's CMD; Kubernetes'
`command:` replaces its ENTRYPOINT. Transcribing one to the other silently broke every
upstream image that relies on its entrypoint — postgres ran as root and refused to
start, Keycloak tried to exec `start-dev` as a binary. The chart now `fail`s at render
time if a workload sets `command`, because the symptom (a crashloop three layers down)
is nothing like the cause.
- **Published ports are NodePorts.** No ingress controller, no LoadBalancer, no TLS. The
four portals are the exception in *use*, not in wiring: PKCE needs `crypto.subtle`, which
browsers expose only in a secure context, so a portal has to be reached over `localhost`
(`make k8s-portals` forwards them) or eventually over HTTPS. `.Values.host` is therefore
"the address the browser uses", not "the node's address" — it pins Keycloak's issuer and
each portal's `config.json`, and both must agree with the URL bar (ADR-0010).
- **Databases are `emptyDir` by default**, so the stack comes up on a cluster with no CSI
driver; setting `persistence.storageClass` switches every database to a PVC.
- **Only two hosts become FQDNs** — OpenZaak (for the ACL and the zaaktype seed) and
Objecten (for the ACL's register writes), the two that Django validates as URLs.
Everything else keeps the short compose service name, because the upstream
`setup_configuration` files name those and Objecten matches an objecttype URL against the
one it was configured with. The portals used to be a third case — nginx's `resolver` never
appends search domains, so the bare `bff` upstream could not resolve on Kubernetes — which
ADR-0034 removed by serving them with Caddy, whose resolver honours `/etc/resolv.conf`.
- **Compose stays CI-canonical.** The chart is a second deployment target, not a
replacement; the acceptance, verify and e2e lanes are unchanged.
### Alternatives considered
- **A chart per service, or an umbrella of 30 subcharts.** The conventional layout, and
roughly 1,500 lines of near-identical YAML for a stack where 28 of 30 workloads are
"one pod, one image, some env". It buys independent versioning we don't want (the stack
is demoed as a whole) and costs the eye-diffability against the compose file that keeps
the two stacks honest.
- **`kompose convert`.** One-shot generation, no ongoing artefact to maintain — but it
drops exactly the parts that carry the design (init ordering, the config volumes, the
issuer pinning) and produces output nobody owns.
- **Bitnami PostgreSQL/Redis subcharts.** Six more dependencies (CLAUDE.md §13) and a
second way of expressing the same three-line database.
- **ingress-nginx with hostname routing.** Needs a controller, `/etc/hosts` entries and a
matching issuer host; NodePorts need none of it and reuse the mechanism
`infra/host-browser.yml` already proves.
- **A registry on the laptop** (the obvious home for images built there). Talos cannot
side-load an image, so a registry is required either way — but reaching one on the host
means opening an inbound port on firewalld's `libvirt` zone, which needs root, and
pushing to it over plain HTTP means an `insecure-registries` entry in the Docker daemon,
which needs root again. `infra/helm/registry.yaml` runs the registry *in* the cluster on
a NodePort instead: pushing laptop → node is outbound and unfiltered, the node pulls from
its own NodePort, and `docker save | crane push --insecure` needs no daemon
configuration. Cost: one more (throwaway, `emptyDir`) workload, and a re-push if its pod
is replaced.
- **Helm hooks (`pre-install`/`post-install`) for bootstrap ordering.** Hooks run after
`--wait`, which would deadlock: OpenZaak's readiness needs the migrations that the hook
is supposed to run. Idempotent Jobs plus retries need no such sequencing.
- ponytail ceiling: single-node assumptions are baked in — one replica per workload,
`Recreate` rollouts, ReadWriteOnce volumes, no PodDisruptionBudgets, no resource
requests or limits (a laptop VM schedules everything or nothing), plain HTTP.
Upgrade path for a real cluster: add requests/limits per workload (the field is already
passed through), swap NodePorts for an Ingress with TLS, and give the databases a real
StorageClass — none of which changes the workload graph.
## Consequences
**Positive**
- One file to read to see what the cluster runs, and it lines up with the compose file
line for line.
- The compose IP workarounds disappear: cluster DNS supplies multi-label hosts.
- `make k8s-lint` renders and schema-checks the whole stack without a cluster.
- The config inputs have exactly one home (the repo) for both stacks — no fork to drift.
**Negative / costs**
- A second deployment description to keep in step with compose. Nothing enforces that
today; a drift check belongs in CI (follow-up).
- `helm install` alone is not enough — the ConfigMaps must be seeded first, and a missing
one surfaces as `ContainerCreating`, not as a clear error.
- Generic templates mean a values typo can render valid-but-wrong YAML; `k8s-lint` catches
schema errors, not intent.
- The verify/e2e lanes do not run against the chart, so the Kubernetes path is verified by
hand (docs/runbooks/kubernetes-talos.md §5) rather than by CI.
- The chart deviates from compose in four places now (args, self-configuring Django pods,
FQDN hosts, NodePorts). Each is forced by the platform and commented where it appears,
but it is four more things that can drift.
## Coupling rules touched (CLAUDE.md §8)
None. The chart deploys the same graph: portals reach only the BFF (§8.3), only the ACL
holds ZGW credentials (§8.1), only the Workflow Client talks to Flowable (§8.2), each
service keeps its own database (§8.5). No workload gained a peer it didn't have in compose.
## Verified
Brought up from scratch on a single-node Talos v1.14.0 VM (6 vCPU / 10 GB, virtio disk)
under virt-manager: 29 pods ready and four bootstrap Jobs complete in under three minutes,
with zero restarts, using ~4.4 GB of the VM's 10 GB. The smoke test in the runbook's §5
walks the whole path — portal proxy → BFF → domain → Flowable → ACL → OpenZaak + Objecten →
NRC → event-subscriber → projection → public register — plus a werkbak read with an
MFA'd medewerker token. The browser flow itself was driven with Playwright against
`http://localhost:30140`: secure context, PKCE, Keycloak form, login, no console errors.
## Process note
CLAUDE.md §14 wants the ADR proposal issue opened before the code, and §7 wants a slice
issue behind the work. This landed the other way round — chart first, on request. The
issue and the CI drift check are the outstanding follow-ups.