Kubernetes Platform: CI/CD & Monitoring for 15+ Applications

Context

The engineering team runs Spring Boot services, Nuxt apps, Strapi, and Node.js and Python tools — 29 repositories — across five Kubernetes clusters: four single-node servers and a 5-node MicroK8s cluster. Every app has dev and production; the main web app and API also have staging.

Problem

Every build waited in line behind one shared runner, pipelines had drifted from app to app, and there was no shared view of cluster and service health.

What I did

• Run GitHub Actions pipelines on self-hosted runners: build the Docker image, push it to a private registry, render manifests with envsubst, and kubectl apply them to the app’s cluster context — push-based, no manual SSH.
• Moved CI off a single shared runner to two runners on a 6-vCPU cluster node that share one queue and one Docker build cache, and made deploy jobs re-checkout the code so either runner can pick them up (18 repositories).
• Consolidated four Spring Boot service workflows into one build-once workflow with a concurrency group and a rollout-status gate.
• Configured Horizontal Pod Autoscalers, per-environment namespaces, and Traefik IngressRoutes, with TLS through Cloudflare and cert-manager for other domains.
• Replaced a Docker cleanup cron that wiped everything with a nightly job that removes stale images but keeps up to 20 GB of build cache.
• Built a central monitoring stack on one k3s node: VictoriaMetrics (5-year retention) scrapes cAdvisor, kubelet, node-exporter, and kube-state-metrics from four clusters, a standalone VPS, and the production MongoDB server; Grafana uses it as the default datasource.
• Deployed Headlamp as a web UI for workloads, logs, and resources, with Grafana and Headlamp exposed through Traefik.