Kubernetes & GitOps

Kubernetes that runs real systems — live, in production.

Not a cluster that runs a demo — clusters that run a live televised sporting event, a Fortune 500 bank’s modernization, billions of distributed ML calculations, and a sub-second real-time event-streaming platform. Leopard Data designs the platform, ships it with GitOps and Flux, and makes the day-2 operations boring: observability, promotion across environments, stateful data, and autoscaling that holds up when it matters.

Start a Project See the Architecture

What We Do on Kubernetes

Six disciplines, every one of them shipped on a real cluster carrying real load.

Platform & Cluster Engineering

From bare metal to managed cloud — Talos Linux, Red Hat OpenShift, AWS EKS, Azure AKS, and local k3d/k3s. CNI with Cilium, storage classes with Rook Ceph, certificate automation with cert-manager, and time sync with PTP. Bootstrapped, declarative, reproducible.

GitOps Delivery with Flux

Git is the single source of truth. Flux source, kustomize, helm, and image-automation controllers reconcile the cluster to the repo — pulling new images from ECR/ACR, writing tags back to Git, and self-healing drift. No kubectl apply from a laptop, ever.

CI/CD & Environment Promotion

Commit-to-pod pipelines that build, test, and package OCI images, then promote through dev → staging → production via branch-mapped Kustomize overlays. “Works in dev” becomes “behaves identically in prod” because both come from the same declarative source.

Observability & Day-2 Ops

Grafana, Prometheus, and Loki/Alloy wired across every pod so warnings and errors surface to a single operator view. Runbooks for NATS and Postgres, failover drills, and the unglamorous work of keeping a system up — including chasing down OOM and log-shipping bugs before they bite.

Stateful Workloads & Data

The hard part most teams avoid on Kubernetes: high-availability PostgreSQL, NATS JetStream with persistent storage, Valkey, and Rook Ceph for a real storage class. Helm-managed, Flux-deployed, failover-tested, with automated Flyway schema migration on push.

Autoscaling & Distributed Compute

KEDA event-driven autoscaling from queue depth, Ray for parallelizing ML across the cluster, and replica strategies for high availability. Scale-to-zero when idle, scale to hundreds of pods when a billion-calculation job lands.

Game components deployed to an on-prem cluster on live broadcast

Sub-second

Sub-second event streaming over NATS JetStream

100s of M

ML calculations distributed across EKS with KEDA & Ray

Zero

Hand deploys — Git is the only source of truth

How It Actually Works

The pipelines and platforms we ship — from a Git commit to a running pod, and across every environment.

1 · GitOps CI/CD — commit to running pod

A push triggers the build pipeline; the image lands in a registry; the image tag is written into the GitOps repo; Flux notices and reconciles the cluster to match. The pipeline never touches the cluster directly — it only changes Git, and Git is what the cluster follows.

flowchart LR
    DEV["Developer push"] --> REPO["Git repo -- application source"]
    REPO --> CI["CI pipeline -- build, test, scan"]
    CI --> IMG["OCI image built"]
    IMG --> REG["Container registry -- ECR or ACR"]
    CI --> TAG["Bump image tag in GitOps repo"]
    TAG --> GITOPS["GitOps repo -- Kustomize and Helm manifests"]
    GITOPS --> FLUX["Flux controllers reconcile"]
    REG --> FLUX
    FLUX --> CLUSTER["Kubernetes cluster -- desired state applied"]
    CLUSTER --> OBS["Grafana, Prometheus, Loki -- verify healthy"]

The pipeline writes to Git, not to the cluster. Flux closes the loop.

2 · Branch-to-environment promotion

Each long-lived branch maps to a Kustomize overlay, and each overlay maps to a cluster. A merge to develop reconciles dev automatically; a release branch flows to staging; a tagged commit on main promotes to production. Promotion is a Git operation — reviewable, revertable, and gated on a green environment below it.

flowchart LR
    D["develop branch"] --> O1["Kustomize overlay -- dev"] --> C1["Dev cluster"]
    R["release branch"] --> O2["Kustomize overlay -- staging"] --> C2["Staging cluster"]
    M["main branch -- tagged release"] --> O3["Kustomize overlay -- prod"] --> C3["Production cluster"]
    C1 -.->|"promote when green"| C2
    C2 -.->|"promote when green"| C3

Same manifests, per-environment overlays. Promotion is a reviewed merge, not a manual deploy.

3 · The Flux reconcile loop

Flux is a set of controllers that continuously compares the live cluster to the GitOps repo and the container registry. Image-automation watches the registry for new tags and writes them back to Git; source-controller pulls the repo; kustomize- and helm-controllers apply it; drift is corrected on the next reconcile. The cluster converges to Git — always.

flowchart LR
    GIT["GitOps repo -- single source of truth"] --> SRC["source-controller -- pulls repo"]
    REG["Container registry"] --> IAC["image-reflector and image-automation"]
    IAC -->|"write new tag back to Git"| GIT
    SRC --> KUST["kustomize-controller"]
    SRC --> HELM["helm-controller"]
    KUST --> APPLY["Apply manifests to cluster"]
    HELM --> APPLY
    APPLY --> STATE["Cluster reaches desired state"]
    STATE -->|"drift detected on reconcile"| KUST

Image automation, reconciliation, and self-healing drift correction — the GitOps control loop.

4 · Distributed ML on AWS EKS — KEDA & Ray

For a Fortune 500 industrial client, a feature-ranking and forecasting workload had to spread billions of calculations across the cluster. A driver fans work onto a queue; KEDA scales runner pods on queue depth (including scale-to-zero); Ray parallelizes the LSTM/DeepAR PyTorch models across workers; results land in PostgreSQL and feed the ranked output.

flowchart TD
    USER["Data scientist -- ranking job CLI"] --> DRV["Main driver -- reads config, writes DB"]
    DRV --> Q["RabbitMQ queue -- work items"]
    Q --> KEDA["KEDA scaler -- watches queue depth"]
    subgraph EKS["AWS EKS cluster"]
      KEDA -->|"scale 0 to N"| POD["Target and model runner pods"]
      POD --> RAY["Ray head and workers -- LSTM and DeepAR in PyTorch"]
    end
    POD --> DB[("PostgreSQL -- results")]
    RAY --> DB
    DB --> RANK["Ranked features -- best correlated trends"]

Event-driven autoscaling plus Ray parallelism — so a billion-calculation job actually finishes.

5 · Platform blueprint — the cluster we bootstrap on Talos

The same platform layer goes onto every cluster we run, dev through production: an immutable Talos Linux base, Cilium for networking and policy, Rook Ceph for storage classes, cert-manager and External Secrets for trust and credentials, then Flux on top reconciling the data services, observability, and application workloads. It is the standardized foundation underneath everything else on this page — including stealth platform work whose application specifics stay under NDA.

flowchart TD
    OS["Talos Linux -- immutable, API-managed nodes"] --> CNI["Cilium CNI -- networking and policy"]
    CNI --> STORE["Rook Ceph -- storage classes"]
    STORE --> SEC["cert-manager and External Secrets Operator"]
    SEC --> FLUX["Flux -- GitOps reconciliation"]
    FLUX --> DATA["Data services -- PostgreSQL HA, NATS JetStream, Valkey"]
    FLUX --> OBS["Observability -- Grafana, Prometheus, Loki"]
    FLUX --> APPS["Application workloads -- replicas for HA"]
    DATA --> APPS
    OBS --> APPS

One standardized platform stack, bootstrapped and reconciled by Flux across every environment.

The Stack We Ship With

The cluster technologies we run — the same tools across every engagement.

Clusters & OS

Kubernetes Talos Linux Red Hat OpenShift AWS EKS Azure AKS k3d k3s minikube talosctl kubectl

GitOps & Packaging

Flux CD GitOps Kustomize Helm Pulumi Terraform Ansible Automation Platform Azure DevOps

Observability & Cluster Ops

Grafana Prometheus Loki Alloy K9s Freelens Application Insights

Networking & Security

Cilium cert-manager External Secrets Operator Tailscale Mesh VPN AWS Secrets Manager ZScaler

Data & Messaging

PostgreSQL (HA) NATS JetStream Valkey RabbitMQ Kafka EMQX MQTT Rook Ceph Flyway

Scaling, Registries & Supply Chain

KEDA Ray Anyscale PTP time sync AWS ECR Azure Container Registry Docker OCI Containers

Languages & Tooling

Rust Python C# / .NET Go Bash Git GitHub

Kubernetes in the Wild — Real Engagements

Four platforms, four very different reliability bars. All of them shipped.

Live Broadcast · On-Prem

TGL Golf — Game Operations on OpenShift

Leopard Data led the systems group as Kubernetes architect for a primetime indoor golf league, deploying all 16 game components onto Red Hat OpenShift — a development cluster for rehearsal and the on-prem cluster physically running inside the arena on game day. Provisioning was modeled in Red Hat Ansible Automation Platform as a single declarative source of truth, so dev/prod parity made the live deploy boring instead of terrifying. Verified on a Universal Studios sound stage, then re-adapted on-site for the arena’s constrained network — broadcast-stable on opening night.

Read the full case study

Fortune 500 · Banking

Fiserv — Mainframe to Azure on AKS

As top technologist and Business Solutions Architect on a 60+ person program, Leopard Data drove the technical delivery of a mainframe-to-Azure banking modernization on Azure Kubernetes Service (AKS) — event-driven services over Event Grid, Service Bus pub/sub, and Cosmos DB, with Grafana, Elastic, and Splunk for observability and Azure AD B2C / OAuth2 for identity. We designed the K8s service topology, defined testable interfaces across the system, and stood up KEDA-on-Kubernetes demos that became the team’s reference for event-driven scaling.

Industrial · Distributed ML

Koch — Distributed Machine Learning on EKS

For the largest private company in the U.S., Leopard Data engineered the distribution layer for a feature-ranking and forecasting engine running hundreds of millions of calculations. We proved out KEDA against RabbitMQ on minikube, scaled it into a real AWS EKS cluster, and integrated Ray for parallelizing LSTM and DeepAR PyTorch models — then advised management candidly on where Kubernetes earned its keep versus where serverless was the better call.

Read the full case study

Stealth · Under NDA

Stealth Real-Time Data Platform

Platform engineering delivered under a mutual NDA, shown only in the generic. Leopard Data built the Kubernetes and GitOps foundation: a self-managed Talos Linux cluster bootstrapped with Flux and promoted across multiple physical environments from a single GitOps repo, running the platform stack we standardize on — Cilium networking, Rook Ceph storage, cert-manager and External Secrets, HA data services, and Grafana/Prometheus/Loki observability throughout. The product it carries, and its application architecture, remain sealed under NDA — what’s shown here is the GitOps delivery and the cluster engineering pattern underneath it.

Standing up Kubernetes — or trying to tame it?

From platform build and GitOps with Flux to observability, stateful data, and autoscaling, Leopard Data ships the real thing. Corp-to-Corp engagements out of Plano, TX.

Send an Inquiry See AI & ML