Controlled Kubernetes Delivery Across Development, Staging, and Production

Executive Summary

The relevant improvement was not simply that workloads ran on Kubernetes. The relevant improvement was that delivery became controlled from commit to cluster.

GitLab held source, review flow, and CI policy. GitLab CI built containers, ran tests, validated charts, and published immutable artifacts. Nexus3 held those images and Helm charts as the registry of record. ArgoCD then reconciled approved deployment intent into Kubernetes across development, staging, and production.

The cluster side mattered too, but as operating context rather than the headline. Rancher Cluster Manager provided the graphical management layer, made cluster handling more approachable, and simplified rollout of a monitoring stack. RKE2 and K3s provided pragmatic Kubernetes distributions depending on environment needs. vSphere integration covered both cluster provisioning and CSI-backed storage so the platform fit the infrastructure reality instead of pretending it started in the cloud.

Client Context

This kind of work shows up when application delivery has moved beyond a small number of manually understood services.

Earlier container delivery patterns often work for a while. The problem starts when more services, more environments, and more release pressure turn those habits into operational risk. Development, staging, and production may exist, but they do not yet behave as disciplined promotion stages. Artifacts are rebuilt too often. Deployment logic is scattered. Rollback confidence is weak because it is not always clear which artifact version actually reached which environment.

That was the real problem space here. The need was not a more fashionable runtime. The need was release control.

Why This Is a Delivery Story

This article is about software delivery architecture, not about Linux and Windows standardization and not about Ansible-led host operations.

The main design question was how to separate build, artifact custody, deployment intent, and runtime reconciliation so that application changes could move across environments in a traceable and controlled way. Kubernetes was the runtime target. It was not the entire story.

Target Operating Model

The operating model centered on a clear chain of responsibility.

GitLab was authoritative for source, merge control, tags, and CI logic.

GitLab CI built containers, ran tests, linted or templated charts where appropriate, and published approved outputs.

Nexus3 became the artifact hub for OCI images and Helm charts. That mattered because build outputs needed durable custody outside the pipeline that created them. As a side benefit, the same platform also supports broader artifact governance such as npm or NuGet packages.

ArgoCD handled pull-based deployment and reconciliation. That preserved a clean separation between CI and cluster access while making drift and sync state easier to inspect.

Helm was the preferred packaging model for first-party applications.

Kustomize was used more narrowly for smaller structural changes, namespace-spanning adjustments, or cluster service customization where overlays were cleaner than forcing everything through Helm values.

Multi-Stage Delivery Across Development, Staging, and Production

The stage model was treated as a control system, not as naming decoration.

Development existed for rapid integration feedback. Staging existed to prove a release candidate in a more production-like path. Production existed as a deliberate promotion target, not as the place where build logic suddenly changed.

That distinction only works if the artifact is stable across stages. The operating principle was therefore simple: build once, test once, publish immutable artifacts, then promote deliberately.

This improved traceability. A release could be followed from commit to pipeline, from pipeline to image or chart version in Nexus3, and from approved version to ArgoCD sync revision in the target environment.

GitLab CI Responsibilities

GitLab CI carried the engineering checks that belonged before deployment.

That included container builds, application tests, chart validation, release tagging, and artifact publication. The point was not to turn CI into a cluster administrator. The point was to ensure the output entering the registry had already passed the expected quality gates.

Keeping those responsibilities in GitLab also made review and change control easier to govern because merge requests, pipeline logic, and release mechanics lived in the same auditable system.

Nexus3 as Artifact Hub

Nexus3 was important because artifacts needed a proper system of record.

Container images and Helm charts were versioned and stored there, which made rollback and promotion logic far easier to reason about than pipeline-local outputs or environment-specific rebuilds. Rebuilding artifacts for each environment would have weakened auditability and made it harder to prove that staging and production really saw the same release candidate.

That separation also kept responsibilities cleaner. GitLab governed source and CI. Nexus3 governed artifact custody. ArgoCD governed deployment reconciliation.

Helm as Preferred Packaging Model

Helm was the default choice for application packaging because application deployments benefit from versioned release semantics.

Charts made it easier to package first-party workloads in a reusable way, keep deployment inputs explicit, and promote known versions between environments. This was especially useful once more than one application or service had to move through the same staged delivery model.

Where Kustomize Fit

Kustomize was not used as a second default for everything.

It was useful where a small overlay was clearer than adding more logic to Helm values, especially for namespace-spanning adjustments, selected cluster services, or small structural differences between environments. That restraint mattered. Too much logic in Helm values becomes hard to reason about, but too many Kustomize overlays become hard to promote safely.

ArgoCD as Deployment Layer

ArgoCD provided the pull-based deployment model.

This reduced CI blast radius because pipelines did not need broad direct cluster credentials for every deployment step. It also improved operational visibility through sync status, history, and drift detection.

Just as importantly, ArgoCD expressed a different responsibility than the registry. Nexus3 stored approved artifacts. Git expressed approved desired state. ArgoCD made sure the cluster converged toward that state.

Repo Strategy

The repo layout followed the same separation of concerns.

Application source lived in the application repository. Helm chart source could stay in the same repository when tightly coupled to the application. A separate chart repository only made sense when charts had an independent lifecycle or broader reuse. The GitOps repository served a different purpose again: it expressed which approved version belonged in development, staging, or production for ArgoCD to consume.

That distinction matters in practice because a chart repository and a GitOps repository solve different governance problems.

Rancher, RKE2, K3s, and vSphere Context

The runtime layer still mattered, because delivery discipline has to fit real operations.

RKE2 and K3s were relevant Kubernetes distributions in this work, chosen according to environment needs and operational constraints. Rancher Cluster Manager added a graphical management interface that made cluster handling more approachable, especially for teams that needed visibility without living in Kubernetes internals all day.

Rancher also made it easier to establish a monitoring baseline. A monitoring stack could be rolled out more consistently through the management layer instead of being treated as an afterthought on each cluster.

vSphere was part of the practical operating context as well. That included cluster provisioning integration and vSphere CSI for persistent storage, which is exactly the kind of detail that determines whether a platform is merely installed or actually usable.

Outcomes

The result was a more governable release chain.

Promotion across development, staging, and production became clearer. Rollback logic became easier to trust because approved artifacts were versioned and traceable. Build, registry, and reconciliation responsibilities no longer blurred into one another. Cluster operations also became more approachable through Rancher, which mattered for adoption beyond a narrow specialist group.

The value was not that the stack sounded modern. The value was that application delivery became easier to control.

Tradeoffs and Guardrails

This model still requires discipline.

Rebuilding artifacts per environment is an anti-pattern when auditability matters. Putting too much variation into Helm values makes releases harder to reason about. Using Kustomize everywhere creates overlay sprawl. Splitting repositories too aggressively can also create governance overhead without enough benefit.

The architecture works best when each part keeps its job: GitLab for source and CI policy, Nexus3 for artifact custody, Git for approved environment intent, ArgoCD for reconciliation, and Rancher for practical cluster operations.

What This Article Is Not

This article is not about Linux and Windows host standardization. It is not the Ansible and Semaphore story. It is also not a generic cluster installation walkthrough.

The point is the delivery chain: build once, store immutable artifacts, promote deliberately, and reconcile approved state into Kubernetes in a way that teams can actually operate.

CTA

If your organization needs a more controlled path from code to Kubernetes, PLANFOLD's sovereignty and modernization work is designed for exactly that kind of delivery architecture.