Skip to content

Applications

Active applications

The main application Kustomization currently includes:

The nginx test files are outside the active apps/base/kustomization.yaml resource list and are not deployed by Flux.

kubectl get deployments,statefulsets,services,ingress -A
flux get kustomizations -n flux-system

clients-api

clients-api is a Spring Boot API backed by PostgreSQL managed by CloudNativePG. It is used to exercise the complete delivery path: application CI, container images, Helm, Flux, database lifecycle, autoscaling and monitoring.

Environments

Environment Git source Purpose
production main stable release
development main overlay development configuration
staging staging pre-production validation

Each environment owns separate Kubernetes resources and database state.

Delivery flow

  1. A semantic version tag starts GitHub Actions.
  2. CI tests and builds the application image.
  3. CI publishes the image and Helm chart.
  4. Flux image automation selects an allowed version and updates Git.
  5. Flux reconciles the HelmRelease and Kubernetes resources.

Semantic versions are used for release selection. Commit-SHA tags are useful for traceability but are not the ordering mechanism for production promotion.

Runtime configuration

The production profile uses the CloudNativePG read-write Service and credentials from a Kubernetes Secret. No database password is stored in plaintext Git.

Readiness and liveness probes use the Spring Boot Actuator endpoints:

  • readiness removes an unready Pod from Service endpoints;
  • liveness restarts a process that cannot recover;
  • startup timing must allow JVM initialization and database connection setup.
kubectl get pods,service,endpointslices -n clients
kubectl logs -n clients deployment/clients-api --since=15m
kubectl describe pod -n clients -l app=clients-api

Scaling ownership

HPA is the sole owner of the Deployment replica count. The Deployment manifest does not set spec.replicas, otherwise Flux and HPA would continuously overwrite each other.

CPU utilization targets are calculated against requests.cpu, not the CPU limit. Resource requests affect scheduling; limits bound runtime use.

kubectl get hpa -n clients
kubectl top pods -n clients

Availability

A PodDisruptionBudget protects at least one API replica during voluntary disruption. It does not protect against all simultaneous failures and does not make the database or ingress path highly available by itself.

CloudNativePG 1.30.0 (chart 0.29.0) manages PostgreSQL 17.4:

Namespace Cluster Instances Replication
clients clients-db 2 Asynchronous streaming
clients-staging clients-db-staging 2 Asynchronous streaming

Each cluster has a primary and a replica, with a separate Longhorn PVC per instance. Clients use the *-rw Service, which follows the current primary.

nodeMaintenanceWindow is disabled in normal operation. CNPG maintains PDBs and manages role changes for primary eviction. Asynchronous replication does not guarantee zero data loss if the primary fails before its replica receives all WAL.

Database health must be checked independently from application readiness: require readyInstances == spec.instances, Ready=True and Cluster in healthy state. Same-cluster join and replication traffic on TCP 5432 is explicitly allowed by NetworkPolicy. See Backup for backup coverage and recovery limitations.

kubectl get pdb -n clients
kubectl get clusters.postgresql.cnpg.io -A
kubectl get pods,pvc -n clients

Monitoring

A ServiceMonitor selects the application Service and scrapes the Actuator Prometheus endpoint. Both the Service labels and ServiceMonitor selector must match.

kubectl get servicemonitor -n clients
kubectl get servicemonitor -n clients -o yaml

k8s-badge

k8s-badge is a small stateless workload that publishes cluster status as JSON and SVG. It follows the same GitOps rule: changes are made in Git and verified after Flux applies the expected revision.

Operational checks

flux get kustomizations -n flux-system
flux get helmreleases -A
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get events -A --sort-by=.lastTimestamp | tail -n 50

Completed Jobs are expected in the non-Running list. Pending, Unknown, CrashLoopBackOff or repeated restart states require investigation.