Files
homelab/kubernetes/infrastructure/kustomization.yaml
claude-botandClaude Opus 5.5 ac44925baf
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
review-bot reviewed: comment
fix(flux): services that need OpenBao secrets apply after the secret store
crowdsec, external-dns-unifi, netbird-ingress and velero were in the
infrastructure Kustomization, while the ExternalSecrets that create their
Secrets were in infrastructure-crds, which depends on infrastructure. On a
cold start each was therefore installed before its Secret could exist: the
pods sat in CreateContainerConfigError until OpenBao was unsealed and ESO
synced. For the HelmReleases (crowdsec, external-dns-unifi, velero) Helm's
wait timed out meanwhile; with remediation.retries: 3 they give up after
four attempts and stay failed even once the Secret appears. Velero failing
that way stops every restore.

| workload | Secrets |
|---|---|
| crowdsec | crowdsec-bouncer-key (crowdsec, ingress), crowdsec-edge-bouncer-key |
| external-dns-unifi | external-dns-unifi-secret |
| netbird-ingress | netbird-ingress-setup-key |
| velero (+ backup-verify CronJob) | cloud-credentials, cloud-credentials-hetzner, hcloud-backup-verify |

Each now has a Kustomization of its own (clusters/homelab/
infrastructure-services.yaml), depending on infrastructure and
infrastructure-crds, with its ExternalSecrets beside it. The openbao
ClusterSecretStore in infrastructure-crds turns Ready only once OpenBao is
unsealed, so the Secret exists before the consumer installs. One
Kustomization each so that a broken service holds back only itself.

Velero's Schedules need the velero.io CRDs from its HelmRelease, so they move
from post-crds to infrastructure/velero-schedules with a Kustomization after
velero.

post-crds keeps cloudflare-api-token (consumed by its own ClusterIssuer) and
flux-git. The directories themselves stay where they are, so paths such as
the CI test infrastructure/velero/backup-verify/tests/run.sh are unchanged.

netbird-ingress gets 10m to roll its DaemonSet over three nodes
(maxUnavailable 1, minReadySeconds 45). The crowdsec comments name the
Kustomization it now runs in, and flux-graph.sh colours the new nodes.

Production rollout: infrastructure and infrastructure-crds must run with
prune: false (the stack's first PR) when this merges. Pruned, the velero
HelmRelease would be uninstalled, and the moved ExternalSecrets would take
their Secrets with them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-17 22:14:41 +02:00

42 lines
1.5 KiB
YAML

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# Secrets managed by SOPS + age (FluxCD native decryption).
# L2 load balancing is provided by Cilium (see post-crds/cilium-l2.yaml).
resources:
- namespaces/
- cluster-settings/
- cilium/
- multus/
- cert-manager/
- snapshot-controller/
- metrics-server/
- intel-gpu-plugin/
- traefik/
- rook-ceph/
- ceph-csi-drivers/
- cloudnative-pg/
- mariadb-operator/
- coredns-config/
- k8s-gateway/
- image-automation/
- flux-notifications/
- spegel/
- openbao/
- external-secrets/
- reloader/
- admission-policies/
# The OpenBao ClusterSecretStore lives in post-crds/ (needs ESO's CRDs and
# an initialized OpenBao; see kubernetes/MIGRATION-sops-openbao.md).
# cnpg-barman-plugin/ lives in its own Flux Kustomization
# (`infrastructure-cnpg-barman`) so it can dependsOn infrastructure-crds
# where the cert-manager Certificates create the TLS Secrets its
# Deployment mounts. Including it here causes the Deployment to block
# on missing Secrets while infrastructure itself cannot finish without
# the Deployment becoming Ready — circular.
# bird/ and netbird-service-sync/ run images from Gitea's registry and live in
# infrastructure-inhouse/, which waits for Gitea.
# crowdsec/, external-dns-unifi/, netbird-ingress/ and velero/ consume Secrets
# from OpenBao and have Kustomizations of their own after infrastructure-crds
# (clusters/homelab/infrastructure-services.yaml); velero-schedules/ follows
# velero.