The earlier rule covered creationTimestamp, volumeMode and status but missed
apiVersion and kind, which the API server also injects into
volumeClaimTemplates. Those two alone kept both StatefulSets permanently
OutOfSync: a sync would apply successfully and report Synced, then the very
next comparison flagged them again.
A StatefulSet's volumeClaimTemplates are immutable, and the API server
injects creationTimestamp, volumeMode and a status block that are not in
the manifest. ArgoCD diffed those and reported OutOfSync permanently,
since no sync could ever resolve them.
infisical-postgres and infisical-valkey are the only StatefulSets here
using volumeClaimTemplates, which is why this app alone was affected.
Five components under applications/netbox: the web pod, an rqworker,
a daily housekeeping CronJob, postgres 18 and two valkey instances.
The task queue runs appendonly on its own PVC so queued jobs survive a
restart, while the cache instance is disposable.
Worker and cronjob override args rather than command, which replaces
CMD while keeping tini as the entrypoint, so only the web pod runs
migrations. Media, reports and scripts share one RWX PVC via subPaths
because both the web pod and the worker mount them.
Exposed on the internal gateway only.
Bumps every outdated image and chart except databases, which are
deliberately left on their current versions.
Applications:
authentik 2026.5.2 -> 2026.8.0 (server and worker)
immich v2.7.5 -> v3.1.0
gitea 1.25 -> 1.27.2
gotify 2.9.1 -> 3.0.0
uptime-kuma 2.2.1 -> 2.5.3
zipline 4.5.3 -> 4.7.0
outline 1.8.1 -> 1.9.2
reactive-resume v5.0 -> v5.2.8
netbootxyz nbxyz18 -> nbxyz24
bentopdf v2.8.2 -> v2.8.7
jellyfin 10.11.9 -> 10.11.11
gitea runner init busybox 1.37.0 -> 1.38.0
Infra:
kube-vip v0.9.1 -> v1.2.3
victoria-metrics-k8s-stack 0.77.0 -> 0.91.2
intel-device-plugins v0.35.0 -> v0.36.0
crowdsec-envoy-bouncer 0.6.3 -> 0.8.0
Immich v3 drops pgvecto.rs support. Verified the live database already
runs vchord 0.4.3 and pgvector 0.8.1 with no pgvecto.rs extension, both
inside the ranges v3 accepts, so no database change is required.
The victoria-metrics chart renamed defaultRules.create to
defaultRules.enabled at both the top level and per group. Migrated those
keys so the etcd, kubeScheduler, kubernetesSystemControllerManager and
kubernetesSystemScheduler exclusions keep applying. Without the rename
those groups revert to enabled and alert on control-plane components
that k3s runs embedded.
That chart also moved default rules and dashboards to a runtime sync job
instead of templating them, so ArgoCD will prune the VMRules and
dashboard ConfigMaps it currently owns and the job will recreate them.
kube-vip is not managed by ArgoCD. The manifest change is inert until
applied by hand.
Jeffrey