Making a bare-metal Kubernetes platform operable

The problem I was working through

At jaraco, the platform work started with a practical question: how do you make a bare-metal Kubernetes environment predictable enough for enterprise applications, without hiding the operational details that matter when something fails?

I worked as a Working Student, Platform & Data from February 2025 in Münster. My role covered the cluster foundation and the surrounding services that make a platform usable in practice: storage, observability, networking, identity, secrets, certificates, quality checks, scanning, and deployment automation.

What had to work together

The cluster itself is only one part of the system. A workload also depends on the storage layer, network reachability, certificates, secrets, identity, logs, metrics, and the path from source control to the running application.

That is why the work was not simply “set up Kubernetes.” I contributed to a 12-node on-premise bare-metal Kubernetes platform that hosts 10+ enterprise applications, and I connected it with the services needed to operate those applications:

Ceph for storage.
Grafana, Grafana Alloy, Prometheus, and Loki for observability.
Flannel and Cilium as part of the networking integrations.
Keycloak, SonarQube, HashiCorp Vault, cert-manager with Let’s Encrypt, and Trivy for identity, quality, secrets, certificates, and scanning.
FluxCD and GitHub Actions to make delivery more repeatable and reduce manual deployment work.

Platform overview

This diagram is a logical view of platform responsibilities. It is not a physical network diagram or an internal security topology.

What the metrics mean

The useful part of the 12-node figure is not the number by itself. It shows the platform was large enough that manual, one-off handling would become hard to reason about. The platform also hosts 10+ enterprise applications, so delivery and operational checks had to be repeatable across more than one workload.

The reported outcomes include 99% uptime and a 40% reduction in manual deployment time from the automated workflows. I treat those as project outcomes, not live status indicators. The deployment metric refers to manual deployment effort; it is not a claim about total lead time, release frequency, or application-level performance.

The engineering habit this reinforced

GitOps is useful because it gives the platform a desired state, but it also changes how failures are investigated. A successful CI run is only part of the story. The source revision has to be fetched, the controller has to reconcile it, the workload has to become ready, and the application still needs healthy signals.

That habit now shapes how I think about platform work: make the deployment path inspectable, avoid relying on manual memory, and close an investigation only when the intended revision and the runtime state agree.

Current work around the platform

Alongside the platform work, I am developing an AI-integrated data mesh system. That work is ongoing and is not included in the completed deployment metrics above.