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>
42 lines
1.5 KiB
YAML
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.
|