Services

Purpose

This page is a reference guide to the shared services deployed on top of the Lumie cluster. It focuses on GitOps ownership boundaries, not product feature behavior: which Argo CD root owns which class of services, where cluster-scoped prerequisites live, and what operators should verify before adding or changing shared infrastructure.

Source Paths

Path	Role
lumie-infra/applications/kustomization.yaml	Top-level application registration, including cluster-bootstrap and product workloads
lumie-infra/applications/cluster-bootstrap/	Wave -2 manifests for StorageClass and ClusterIssuer resources
lumie-infra/bootstrap/kustomization.yaml	Wave -1 foundation services
lumie-infra/platform/kustomization.yaml	Shared platform infrastructure
lumie-infra/storage/kustomization.yaml	Shared data-plane infrastructure
lumie-infra/security/kustomization.yaml	Cluster security services
lumie-infra/observability/kustomization.yaml	Metrics, logs, traces, and autosizing support

Runtime Hierarchy

Service Catalog By Root

Root	Key services	Why it exists
cluster-bootstrap	minio-local StorageClass, letsencrypt-* ClusterIssuer resources	Cluster-scoped prerequisites that must exist before normal namespaced apps reconcile cleanly
bootstrap	MinIO, Zot, Vault plus Vault Secrets Operator, Gitea	Foundation services needed by later apps for object storage, image pulls, secrets, and Git
platform	CoreDNS config, Traefik config, cert-manager, RabbitMQ operator, RabbitMQ, KEDA	Shared platform runtime used by many workloads
storage	CNPG, infra-db, Redis, pgweb	Stateful backing services for apps and operators
security	Kyverno, Falco, Keycloak, Trivy, Teleport	Admission, identity, runtime security, and access tooling
observability	Prometheus, Grafana, Loki, Tempo, Thanos, OTel, Goldilocks, VPA	Day-two telemetry and sizing support
applications	Argo CD self-management, Tekton, Lumie backend/frontend/workers, docs, dev env, tooling	Product and operator-facing workloads above the platform

Cluster-Scoped Versus Namespaced Services

Not every shared service is a normal namespace-local app:

• cluster-bootstrap is intentionally separate because ClusterIssuer and StorageClass resources are cluster-scoped and should land before workloads reference them.
• priority-classes in platform/ is also cluster-scoped even though it is reconciled through an Argo CD Application.
• K3s-managed runtime objects such as local-path-provisioner and some addon-owned ConfigMaps exist outside the App-of-Apps roots.

Operators should be careful not to assume that every shared resource can be found under a namespace-specific Helm values file.

Ownership And Dependency Rules

Dependency	Upstream owner	Downstream effect
Vault and VSO	bootstrap/vault	VaultStaticSecret consumers in nearly every root block until Vault is healthy
Zot registry	bootstrap/zot	Image pulls for cluster workloads and registry mirror behavior on nodes
Traefik	k3s addon plus platform/traefik-config	Ingress for product apps, docs, Gitea, Keycloak, and custom domains
cert-manager issuers	applications/cluster-bootstrap	TLS secret issuance for ingresses and explicit Certificate objects
RabbitMQ	platform/rabbitmq	Async workers and backend messaging contracts
CNPG and Redis	storage/	Product database, caching, and internal operator databases

Operational Notes

• Adding a service directory is not enough. The corresponding argocd.yaml must be registered in the parent kustomization.yaml, or Argo CD will never see it.
• The shared charts/common chart is the default deployment surface for many services, so ingress, service, VaultStaticSecret, ServiceMonitor, and RBAC behavior often comes from reusable templates rather than raw manifests.
• The live cluster inspected on June 14, 2026 showed all active Argo CD applications in Synced and Healthy state, including cluster-bootstrap, platform, storage, security, observability, and applications.

Contract Drift

There is one important bootstrap mismatch in the inspected sources:

• lumie-infra/provision/ansible/roles/argocd-bootstrap/defaults/main.yml still lists web-apps/application.yaml in app_of_apps_paths, but the repo no longer contains lumie-infra/web-apps/. The current cluster is healthy because the root applications already exist, but a fresh bootstrap using that stale path would fail unless the defaults are updated or the path is restored.

Failure Modes

Failure point	Impact
App manifest not registered in parent kustomization	Service never reaches Argo CD reconciliation
Bootstrap order broken	Vault, Gitea, or registry consumers can stall waiting on prerequisites
Cluster-scoped prereqs missing	Ingress TLS and storage provisioning fail even if app namespaces sync
Repo-only legacy directories mistaken for active services	Operators may troubleshoot the wrong runtime path

Verification

kubectl get applications -n argocd
kubectl get clusterissuers
kubectl get storageclass

rg -n "argocd.yaml|cluster-bootstrap|platform|storage|security|observability|applications" \
  lumie-infra/applications/kustomization.yaml \
  lumie-infra/bootstrap/kustomization.yaml \
  lumie-infra/platform/kustomization.yaml \
  lumie-infra/storage/kustomization.yaml \
  lumie-infra/security/kustomization.yaml \
  lumie-infra/observability/kustomization.yaml