Stage 5 + part of Stage 6/7 of REFACTOR_PLAN.md. This is the highest-risk stage per the plan -- these Applications are NOT to be pushed/synced blindly. Each needs `kubectl diff` against live state one at a time before enabling. New Applications (previously-live resources with zero GitOps coverage): - cert-manager-config.yaml (manifests/cert-manager: both ClusterIssuers + the internal CA Certificate -- every TLS cert in the cluster depends on these, and nothing currently restores them on a cold rebuild). - authentik-config.yaml (manifests/authentik: ingress, proxy outpost, middleware -- raw manifests only, low risk). - authentik.yaml (the Authentik Helm chart itself): sync is deliberately left MANUAL and targetRevision is a REPLACE_ME placeholder -- I don't have a safe way to read the live chart version (`helm list -n authentik`), and guessing wrong risks an unwanted upgrade/downgrade of the SSO IdP gating Argo CD/ Grafana/Gitea logins. Needs your input before this one goes anywhere. - network.yaml: widens coverage to the 4 non-sealed files in manifests/network (ddns-cronjob, glances-debian-ingress, traefik-dashboard-ingress, watch-party-ingress) that were previously invisible to Argo CD; keeps network-secrets.yaml scoped to *-sealed.yaml only. Fixes: - homeassistant.yaml: destination.namespace was "homeassistant" (empty, unused) while the actual resources are hardcoded to "default" -- corrected, dropped CreateNamespace=true. The old empty namespace isn't auto-deleted (prune: false); safe to remove by hand if desired. - gitea-backup.yaml: added the missing Namespace object (nothing created "gitea-backup" before); replaced a cluster-wide ClusterRole/ClusterRoleBinding granting pods/exec everywhere with a Role/RoleBinding scoped to the `gitea` namespace, matching what the backup script actually execs into. NOTE: this is already under active sync via gitea-secrets.yaml (selfHeal: true, prune: false) -- once pushed, the old ClusterRole/ClusterRoleBinding will need manual `kubectl delete` since Argo CD won't prune them. - Added sync-wave "-2" to cert-manager/sealed-secrets Applications so their CRDs land before consumers (matches the existing -1/0 wave pattern). - Normalized targetRevision HEAD -> main on home-services/otel-collector/tempo. - Normalized sync policy per your decision: home-services/otel-collector/tempo prune true -> false; pihole/pihole-debian selfHeal false -> true (repo-wide consistency, per your call on finding #18). Verified: kubeconform valid across all manifests + Argo CD Application objects. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Argo CD
Argo CD is the cluster reconciler for this repo. manifests/argocd/app-of-apps.yaml
points Argo CD at argocd/apps, where each file defines one child
Application.
Bootstrap
Install or upgrade Argo CD with the pinned chart values:
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm upgrade --install argocd argo/argo-cd \
--namespace argocd --create-namespace \
--version 9.4.15 \
--values argocd/values/argocd.yaml
Then apply the app-of-apps:
kubectl apply -f manifests/argocd/app-of-apps.yaml
Argo CD is exposed at https://argocd.home.arpa by
manifests/argocd/argocd.yaml.
Application Types
| Type | Examples | Source |
|---|---|---|
| Helm chart plus values | Traefik, cert-manager, Gitea, Pi-hole, monitoring, Loki, Tempo | argocd/apps/*.yaml and values/*.yaml |
| Raw manifest directory | Core, media, network secrets, home services, portfolio | manifests/* |
| Argo CD self-management | argocd-self, argocd-config |
argocd/values and manifests/argocd |
Most Applications use automated sync with selfHeal: true and prune: false.
Expect Argo CD to correct drift, but do not expect deleted Git resources to be
pruned automatically.
Adding a Service
- Add raw manifests under
manifests/<area>or Helm values undervalues/. - Add an
Applicationinargocd/apps/. - Add any required DNS entries to both Pi-hole values files.
- Add certificates, secrets, and registry pull secrets if the service needs them.
- Commit and let the app-of-apps reconcile.
Use targetRevision: main for repo-managed services unless there is a specific
reason to track HEAD.