Skip to content

Operations: maintenance and upgrades

Every component is expected to have a documented lifecycle before its phase is closed.

Component lifecycle inventory

Component Version pin location Upgrade path Upgrade guide Maintenance tasks
SeaweedFS (state store) infra/modules/seaweedfs-local/variables.tf (image_tag) Replace container; data stays on the host Phase 8 Back up data directory; verify versioning
cloud-provider-kind infra/stacks/substrate-kind-shared/variables.tf (digest) Replace container Phase 8 —
kind node image (Kubernetes) infra/stacks/substrate-kind/profiles/*.tfvars (digest) One minor version at a time: 1.35 → 1.36 → 1.37 Phase 8 —
Cilium gitops/platform/cilium/config.yaml Git change; Argo CD rolls out Phase 8 Hubble certificate CronJob health
Talos Linux (Proxmox substrate) infra/modules/proxmox-talos-cluster/variables.tf (talos_version, kubernetes_version) Image-based rolling upgrade Phase 8 —
Argo CD gitops/platform/argocd/config.yaml Git change; Argo CD upgrades itself Phase 8 —
Strimzi operator Phase 3 Operator first, then Kafka version, then metadata version Phase 8 Certificate renewal, rebalancing
Kafka Phase 3 Rolling restart by Strimzi Phase 8 Partition reassignment, retention review
ClickHouse Phase 4 Rolling replica upgrade Phase 8 Merges, TTL, backup verification
Valkey Phase 4 Replica-first failover Phase 8 Memory review
Kyverno Phase 2 Helm chart Phase 8 Policy report review
kube-prometheus-stack Phase 2 Helm chart (CRDs first) Phase 8 Retention and cardinality review

Upgrade principles

  1. Read upstream release notes and upgrade guide; record breaking changes.
  2. Upgrade in dev first, via a Git change (never by hand).
  3. Order: CRDs → operators → workloads.
  4. Define the rollback path before upgrading; note what is not reversible (e.g. Kafka metadata version).
  5. Verify with health checks and smoke tests; record the outcome.

Maintenance plan

To be defined in Phase 8: scheduled tasks, cadence and owners per component.