0 Fork 0

Files

T

jakman85andClaude Opus 5 44983095e1 feat(runbooks): make the 42 alert runbook_url annotations resolve

Every platform-health alert rule carries
`runbook_url: "https://${BASE_DOMAIN}/runbooks/<name>"` — 42 annotations over 34
distinct names, across platform/monitoring/alerts.yaml,
platform/monitoring/pvc-capacity-alerts.yaml, platform/cnpg/alerts.yaml and
platform/kubevirt/alerts.yaml. There was no runbooks/ directory and no HTTPRoute
serving that path: an in-cluster probe of
https://home.keithjackson.dev/runbooks/node-down returned HTTP 404. Every alert that
reached a human handed them a dead link at the exact moment the documentation is read,
and the annotation made it look solved — the same green-surface-over-absent-mechanism
class as the import Job that reported success while storing placeholder secrets.

No alerts.yaml is touched and no runbook_url value changes. The existing URL scheme is
made to resolve instead.

WHAT LANDS
- runbooks/<34>.md — one per name, each grounded in this cluster's real topology and,
  where one exists, its real incident history: the 2026-09-07 k3s-prod-1 etcd I/O
  starvation (measured PSI 11.36 vs 0.75/1.29, the exact journal lines, the four
  mechanisms proven inert), the Longhorn reboot tax and the freeze/thaw of
  concurrent-replica-rebuild-per-node-limit, Cilium's once-resolved egress interface
  cache (Ifindex 3 against a live 1780) and the absence of OSS failover, the CNPG
  38-hour ContinuousArchiving=False with its measured 6.8 MiB/h disk-full clock and the
  2026-09-12 aggregation-scope fix, the 2026-09-06 Keycloak lockout in which all 12
  clients held literal placeholder secrets behind an entirely green cluster, the Velero
  R2 x-amz-tagging NotImplemented incompatibility and its v1.14.3-rc.2 pin, and swap
  re-enabling itself across reboots via systemd-gpt-auto-generator.
  Each page states what the alert means HERE, the first diagnostic commands, likely
  causes ordered by probability with a remediation each, and when to escalate or stop.
- Every page uses FULLY-QUALIFIED resource names and says why: three CRDs register the
  kind `Backup` here, the bare short name resolves to Longhorn's (zero objects), so
  `kubectl get backup -A` prints "No resources found" on a cluster holding 6 Velero and
  27 CNPG backups. Acting on that false negative is how a CLI quirk becomes data loss.
- Every page states that kubectl only works via
  `infra/devcontainer/dev.sh run bash -c '...'` with an explicit `--context k3s-prod`,
  because dev.sh defaults its current-context to k3s-dev.
- Pages also record which alert groups are INERT today (measured 2026-09-13: no
  Longhorn, cert-manager, Flux-controller or Hubble scrape job exists, so 13 rules
  evaluate against nothing) so nobody reads their silence as health.

SERVING — runbooks/serving/ plus clusters/base/runbooks.yaml
A two-replica nginx-unprivileged serving a ConfigMap generated from runbooks/*.md, at
the apex `/runbooks` prefix, in its own non-gating post-platform Flux tier
(dependsOn platform-config, wait:false) — the platform/homepage pattern, file for file.
- The service catalog cannot express this route: ingressRoutes[].host is pattern-bound
  to a single DNS label plus the apex, so the bare apex is unrepresentable, and there is
  no path field.
- Rejected: redirecting to the Gitea web UI. A runbook is read when the platform is
  broken, and Gitea is an app-tier workload whose own dependencies several of these
  runbooks document; Gateway API's RequestRedirect also has no "append .md" modifier,
  so it would need 34 hand-maintained ReplaceFullPath rules.
- configMapGenerator maps each file to an EXTENSIONLESS key (node-down=node-down.md),
  so /runbooks/node-down is a plain static lookup with no rewrite rule. Served as
  text/plain: the namespace has DNS-only egress, so a CDN markdown renderer could not
  load anyway.
- The tier declares NO postBuild.substituteFrom, deliberately: envsubst would run over
  the prose and silently empty every ${...} shell example (it fails open — the 2026-09-01
  emptied Cilium k8sServiceHost). The HTTPRoute omits `hostnames:` and inherits the
  https-apex listener's, so nothing needs substituting.

AUTH — PUBLIC, deliberately
auth-mode=none. Gating these pages behind oauth2-proxy/Keycloak would make
runbooks/keycloak-down unreadable when Keycloak is down and
runbooks/keycloak-client-secrets unreadable during the exact 2026-09-06 failure mode.
An operator who cannot log in is this route's primary reader. Content is operational
procedure only, no secrets. The rationale is recorded in an annotation on the HTTPRoute
so the route is left OUT of the Gateway ext-authz attachment when forward-auth
enforcement lands.

PROVEN — in-cluster probe through the Gateway on prod
  /runbooks/node-down        HTTP 200   8613 bytes  text/plain; charset=utf-8
  /runbooks/keycloak-down    HTTP 200   9378 bytes  text/plain; charset=utf-8
  /runbooks/cnpg-archiving   HTTP 200  11729 bytes  text/plain; charset=utf-8
  /runbooks/longhorn-faulted HTTP 200   9135 bytes  text/plain; charset=utf-8
  /runbooks/vpn-down         HTTP 200  11092 bytes  text/plain; charset=utf-8
  /runbooks/backup-failure   HTTP 200   9604 bytes  text/plain; charset=utf-8
HTTPRoute Accepted by io.cilium/gateway-controller on sectionName https-apex; the
`/runbooks` prefix wins over homepage's apex `/` by Gateway API longest-path precedence.

GUARD — conformance/tests/l0-static/alert-runbooks-resolvable (R-OBS-04)
363 offline assertions. It checks BOTH halves, because the regression is silent in both
directions: an alert with a new runbook_url and no runbook links to a 404, AND a runbook
committed without its configMapGenerator entry is in git, reviewed, merged, and still
404s in the cluster. Also asserts a quality floor so a stub cannot make the link look
fixed, and that route/listener/nginx prefix agree with the annotations.
Proven to fail, then reverted: a bogus runbook_url (2 FAIL), a runbook removed from the
generator (1 FAIL), and a 31-byte stub (7 FAIL).

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-09-12 23:49:58 -05:00

8.9 KiB

Raw Blame History

longhorn-faulted — A Longhorn volume is FAULTED (data at risk, volume offline)

Alert: LonghornVolumeFaulted (critical, 1m) File: platform/monitoring/alerts.yaml, group platform-health.longhorn Expression: longhorn_volume_robustness == 3

What this means here

Faulted means Longhorn has no usable replica. The volume is offline; the workload's writes are failing. This is the most serious storage state on the cluster and the for: 1m is deliberate — there is no benign transient version of this.

Understand what is and is not recoverable before you touch anything:

The volumes on this cluster are 3-replica with hard node anti-affinity, so faulted normally means two or three replicas are gone at once — two nodes lost, or one node lost while another volume's rebuild had not finished, or a disk that ate its replica.
Standbys and replicas are not backups. Recorded verbatim for the databases and true for all of this: "Standbys replicate corruption and deletions faithfully; only the Barman archive is a backup." For a CNPG volume (keycloak-db, nextcloud-db, semaphore-db) the real recovery path is the object-store archive, not Longhorn. For everything else it is Velero.
If this is a longhorn-vm volume (RWX Block, migratable: true) the VM is down, not just the disk. If it is longhorn-scratch (single replica, CDI scratch space) losing it is expected and harmless — re-run the import.

Verify the alert can even fire (measured 2026-09-13)

Prometheus on prod scrapes 19 jobs: apiserver, cdi-prometheus-metrics, coredns, keycloak-discovery, keycloak-service, keycloak/keycloak-db, kube-prometheus-stack-alertmanager, kube-prometheus-stack-grafana, kube-prometheus-stack-operator, kube-prometheus-stack-prometheus, kube-state-metrics, kubelet, kubevirt-prometheus-metrics, nextcloud-db/nextcloud-db, node-exporter, oauth2-proxy, semaphore-db/semaphore-db, velero, velero/node-agent. There is no Longhorn, cert-manager, Flux-controller or Hubble/Cilium job. Check the series this rule depends on before you trust its silence:

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n monitoring port-forward svc/kube-prometheus-stack-prometheus 19090:9090 & \
   sleep 5; curl -s -G --data-urlencode "query=count by (job) (up)" localhost:19090/api/v1/query'

This alert is currently INERT. count(longhorn_volume_robustness) returned 0 series on prod on 2026-09-13 — Longhorn ships no ServiceMonitor here, so the whole platform-health.longhorn group has no data. A faulted volume today announces itself as an application outage. That is a known open defect; treat volumes.longhorn.io as the source of truth, not this alert's silence.

Running the commands in this runbook

kubectl does not work on the operator workstation. The toolchain lives only in the pinned dev container, and the host's k3s-oidc context hangs on a browser prompt once its token expires — that hang is not the cluster being down. Every command below runs as:

infra/devcontainer/dev.sh run bash -c 'kubectl --context k3s-prod get nodes'

Always pass --context k3s-prod explicitly. dev.sh merges both clusters into one kubeconfig and defaults its current-context to k3s-dev, so a command without --context silently answers about the wrong cluster. (CLUSTER=prod infra/devcontainer/dev.sh run kubectl ... is equivalent.) Do not run two dev.sh invocations at once — they share one container and interfere.

USE FULLY-QUALIFIED RESOURCE NAMES, ALWAYS. Three CRDs on this cluster register the kind Backup: longhorn.io/v1beta2, postgresql.cnpg.io/v1 and velero.io/v1. The bare short name resolves to Longhorn's, which holds zero objects — so kubectl get backup -A prints "No resources found" on a cluster holding 6 Velero backups and 27 CNPG backups. Verified on prod 2026-09-13. Reading that as "the backups are gone" and acting on it turns a false negative into real data loss. Write backups.velero.io, backups.postgresql.cnpg.io, clusters.postgresql.cnpg.io, settings.longhorn.io, volumes.longhorn.io, nodes.longhorn.io.

Mutating kubectl (apply, patch, annotate, rollout) and flux reconcile are blocked for agents here: every durable change goes through git (git push origin main is the deploy). Where this runbook gives a mutating command it is for an operator, and it says so.

First commands

Stop and take inventory before changing anything. Which volume, which workload, which replicas exist:

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n longhorn-system get volumes.longhorn.io \
     -o custom-columns=NAME:.metadata.name,ROBUST:.status.robustness,STATE:.status.state,NODE:.status.currentNodeID | grep -Ev "healthy"'

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod -n longhorn-system get replicas.longhorn.io \
     -o custom-columns=NAME:.metadata.name,VOL:.spec.volumeName,NODE:.spec.nodeID,STATE:.status.currentState,FAILED:.spec.failedAt | sort -k2'

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod get pv -o custom-columns=PV:.metadata.name,CLAIM:.spec.claimRef.namespace/.spec.claimRef.name,SC:.spec.storageClassName | grep <volume-name>'

What recovery material exists — fully-qualified names, or you will be told there is nothing:

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod get backups.velero.io -A; echo; \
   kubectl --context k3s-prod get backups.postgresql.cnpg.io -A; echo; \
   kubectl --context k3s-prod -n longhorn-system get backups.longhorn.io'

kubectl get backup -A prints "No resources found" on this cluster even when six Velero and 27 CNPG backups exist. Never make a recovery decision from the short name.

Node and disk state:

infra/devcontainer/dev.sh run bash -c \
  'kubectl --context k3s-prod get nodes; kubectl --context k3s-prod -n longhorn-system get nodes.longhorn.io -o wide'

Likely causes, most likely first

1. Two nodes were unavailable at once

Usually a second reboot or cordon while the first node's rebuilds were still running. Remediation: bring the nodes back. Longhorn will reattach if the replica data survived on disk — which is why you must not delete replicas before checking.

2. A disk failed and took its replica with it

k3s-prod-1's original 2011 SSD had 61,440 reallocated sectors before it was replaced; the dev-era Seagate had 448 current-pending plus 448 offline-uncorrectable. Check SMART on the node holding the failed replica (/runbooks/node-io has the command). If the disk is bad, the replica is gone — the path forward is restore, not repair.

3. All replicas were evicted or deleted

Check whether a disk was disabled, a node removed from Longhorn, or a replicas.longhorn.io object deleted. staleReplicaTimeout: 30 (minutes) means Longhorn eventually discards replicas it considers stale.

4. It is a single-replica volume by design

longhorn-scratch is numberOfReplicas: 1. Losing it is not an incident — delete the DataVolume and re-import.

Remediation, in order

Do not delete the volume, the PVC, or any replica. A faulted volume with a stale replica is recoverable; a deleted one is not.
If a node is down, restore the node (/runbooks/node-down). That is the highest-probability fix.
If Longhorn shows a replica with data but marked failed, an operator can salvage it from the Longhorn UI (Volume → Salvage) — this is the documented path for "all replicas failed but the data is still there".
If the volume backs a CNPG database, do not try to salvage Postgres files. Recover the Cluster from the Barman archive (/runbooks/cnpg-archiving for how to confirm the archive is real first).
Otherwise restore from Velero. Note honestly: dr-restore is authored and has never been executed (conformance.home.k3s/never-executed), and the R2 restore path has not been rehearsed. Expect to be the first person to run it, and read /runbooks/backup-failure for the R2 plugin caveats before you rely on a backup's metadata.

When to escalate or stop

Get the operator now. This is a critical, data-at-risk alert; it is not a runbook-and-carry-on situation. Everything above is diagnosis, and steps 3–5 are operator actions.
Stop before any destructive command. Specifically: no delete pvc, no delete volumes.longhorn.io, no delete replicas.longhorn.io, no touching files under /data/longhorn.
Do not reboot anything while a volume is faulted.
If the affected volume is keycloak-db, expect a full SSO outage as a knock-on: kubectl OIDC, Grafana, Headlamp, Gitea and forward-auth all depend on it. The certificate-based kubeconfig is an independent break-glass path and still works.

Source of truth: runbooks/longhorn-faulted.md. Index: /runbooks/ Records: DECISIONS-LOG.md (drive failures 2026-08-22 and 2026-09-07; dr-restore never executed).

8.9 KiB Raw Blame History Unescape Escape