Kubernetes and GitOps

EKS GitOps Platform

Separate staging and production EKS clusters managed with Terraform and Argo CD.

By Himan MandujaSource reviewed 18 October 2026Reviewed commit 95338e5 ↗

AWS EKS · Terraform · Argo CD · Istio

On this page

Two clusters as an environment boundary
From branch to desired state
The reconciliation contract
Traffic, scaling, and visibility
What the snapshot can prove
Source files

This platform separates staging and production into two EKS clusters, then uses versioned Kubernetes manifests as the delivery interface. Terraform defines the cluster foundations; GitHub Actions publishes images and writes desired-state changes; Argo CD is configured to reconcile those changes.

It is an advanced GitOps demonstration, with useful details around environment isolation and cluster operations. The reviewed snapshot also contains stale repository references in the Argo applications. That matters to the delivery story, so the article distinguishes the designed workflow from a verified, currently operating loop.

Two clusters as an environment boundary

Separate Terraform stacks define cluster A and cluster B. Their VPC CIDRs are 10.0.0.0/16 and 10.1.0.0/16, with public and private subnets across two availability zones. The checked EKS configuration specifies Kubernetes 1.34 and a managed t3.large node group.

Using separate clusters gives staging and production distinct control planes and network foundations. It also increases the operational surface: each environment has infrastructure, add-ons, access configuration, and upgrades to manage. Each VPC uses a single NAT Gateway, so the egress design still carries an availability-zone dependency.

Architecture reconstructed from the linked implementation.Swipe to inspect →

Argo CD source URLs still reference an older repository name in this snapshot. Dashed connections indicate the reconciliation configuration that needs verification.

From branch to desired state

The delivery workflow builds frontend and backend images and publishes them to GHCR. Branch classification selects the target: main or master uses a production sha- tag, while other branches use a staging test- tag based on the short commit SHA.

The workflow then edits the environment’s deployment manifest and commits the new image references. Feature-branch handling checks out the default branch before updating cluster A’s manifest; production handling updates cluster B. This is direct desired-state mutation in Git. The workflow does not itself encode a separate human pull-request approval gate for those manifest commits.

The reconciliation contract

Argo CD application definitions select the cluster-specific manifest paths and enable automated synchronization with pruning and self-healing. In that model, image publication does not directly deploy a pod: changing Git establishes desired state, and the reconciler performs the cluster update.

However, both checked Argo application definitions still reference the older devops-project-7.git repository URL and contain fixed EKS API destinations. Those references need verification or correction before claiming this renamed repository drives a working end-to-end GitOps loop. Screenshots of earlier sync activity are useful historical evidence, not a substitute for that contract.

Argo CD production application showing Synced and Healthy status — The production application was captured as Synced and Healthy. Its source uses the older repository name discussed above. Repository source ↗

Traffic, scaling, and visibility

Terraform-managed Helm add-ons include Istio, Metrics Server, Prometheus, and Kiali. An Istio ingress gateway exposes a Kubernetes LoadBalancer service; the checked release does not establish that the resulting AWS load balancer is specifically an ALB, so the architecture avoids that assumption.

Application manifests include frontend and backend services, Istio routing resources, and CPU-based horizontal pod autoscaling with a 50% target and a two-to-ten replica range. HPA adjusts workload replicas; it should not be confused with proving that the underlying node group will automatically add capacity for every resulting load.

Prometheus and Kiali provide the documented metrics and service-traffic view. The repository includes captures of sync state, autoscaling, and traffic graphs, but does not supply a controlled load-test result or quantified reliability improvement.

Kiali production traffic graph with Istio ingress, frontend, and backend nodes — Kiali displays the production application topology. The panel also says No inbound traffic, so this image does not establish a throughput result. Repository source ↗

kubectl HPA output with two-to-ten replica bounds and four current replicas — The captured HPAs target 50% CPU with a two-to-ten replica range. Four replicas are listed; this single snapshot does not demonstrate a scaling event. Repository source ↗

What the snapshot can prove

The source demonstrates a two-environment infrastructure design and the mechanics of image-to-manifest GitOps delivery. Public cluster API access, a broad NodePort ingress rule, stale Argo repository references, and pinned destination URLs are concrete boundaries to address before reusing the configuration.

The public project site is documentation; it does not establish that paid EKS clusters are still running. A meaningful next validation would correct the Argo source/destination configuration, reconcile both environments, and deliberately introduce drift to test self-healing. That remains a proposed verification, not a result attributed to this article.

Source files

Cluster A definitionEKS, node group, networking, and access settings.
Cluster add-onsIstio, Metrics Server, Prometheus, and Kiali.
Delivery workflowBranch classification, image tags, and manifest commits.
Argo CD applicationActual source URL, destination, and synchronization policy.