I recently finished reading Cracking the Kubernetes Interview, which inspired me to try some of the new concepts covered in the book.
The best way to learn is by building, so I decided to expand on my previous article, Deploying a Spring Boot Application into an Amazon EKS Cluster Using Argo CD. While the original focused on deploying a Spring Boot application into Kubernetes, this iteration evolves the project into a more modern, production-inspired platform.
In this article, we'll build an end-to-end GitOps solution that provisions cloud infrastructure, bootstraps Kubernetes, and continuously delivers applications using Terraform, Amazon EKS, GitHub Actions, and Argo CD.
Along the way, we'll also explore several production-grade patterns, including:
- Argo CD App-of-Apps for scalable GitOps management
- Kubernetes Gateway API for modern traffic routing
- AWS Secrets Manager integrated with the Secrets Store CSI Driver for secure secret management
- A clean separation of responsibilities across infrastructure, application, and GitOps repositories
The goal isn't just to deploy an application - it's to build a small but realistic Kubernetes platform using practices commonly found in production environments.
The project is intentionally split into three repositories, each with a single responsibility:
- Infrastructure - Provision the cloud platform.
- Application - Build and publish application artifacts.
- GitOps - Define and continuously reconcile everything running inside Kubernetes.
Architecture
┌────────────────────────────────────┐
│ argo-deployment-demo-infra-helm │
│ │
│ Terraform │
│ • AWS Infrastructure │
│ • Amazon EKS │
│ • Argo CD Bootstrap │
└──────────────┬─────────────────────┘
│
▼
Kubernetes Cluster
(Argo CD installed here)
▲
│ watches
│
┌──────────────┴─────────────────────┐
│ argo-deployment-demo-gitops │
│ │
│ Desired Kubernetes State │
│ • Platform Components │
│ • Gateway API │
│ • Applications │
│ • Configuration │
└──────────────▲─────────────────────┘
│
│ updated by CI
│
┌──────────────┴─────────────────────┐
│ argo-deployment-demo-app │
│ │
│ Spring Boot Application │
│ GitHub Actions │
│ Docker Image │
└────────────────────────────────────┘
Repository Overview
Infrastructure
Repository: https://github.com/kolyaiks/argo-deployment-demo-infra-helm
This repository provisions the complete cloud platform using Terraform.
Its responsibility is to bootstrap the Kubernetes platform by provisioning:
- AWS infrastructure
- Amazon EKS
- IAM roles and supporting AWS resources
- Argo CD
Once Terraform finishes, the Kubernetes cluster is ready, Argo CD is installed, and GitOps takes over from there.
Application
Repository: https://github.com/kolyaiks/argo-deployment-demo-app
This repository contains the application source code together with its CI pipeline.
It is responsible for:
- Developing the application
- Building Docker images
- Running automated validation
- Publishing container images
- Updating the GitOps repository with the latest image version
Developers primarily work in this repository during day-to-day feature development.
Here is how the application running in Kubernetes cluster will look like:
GitOps
Repository: https://github.com/kolyaiks/argo-deployment-demo-gitops
This repository is the single source of truth for everything running inside the Kubernetes cluster.
Using Argo CD's App-of-Apps pattern, it manages both platform components and application workloads.
Examples include:
- Argo CD Applications
- Kubernetes platform components
- Gateway API resources
- Application deployments
- Environment-specific configuration
- Image versions
Argo CD continuously monitors this repository and reconciles the cluster until the running state matches what is defined in Git.
Production Patterns
App-of-Apps
The project uses Argo CD's App-of-Apps pattern to manage deployments in a structured and scalable way.
Instead of creating and managing each Argo CD Application manually (or applying them one by one), a single root application is responsible for deploying a set of child applications defined in Git.
Each child application can represent:
- a platform component (e.g. Gateway API, ingress controller, external secrets)
- an environment setup (dev/stage/prod)
- an actual workload (Spring Boot service)
This creates a clean bootstrap model:
One Argo CD application - deploys the entire platform structure automatically.
Why this matters in practice
-
Faster cluster bootstrap
- You deploy Argo CD once, point it at the root app, and the entire platform builds itself.
-
No manual Argo CD wiring
- You don’t need to click through UI or maintain multiple independent Application manifests.
-
Clear dependency control
- Platform components (like Gateway API or secrets controllers) can be applied before application workloads.
-
Safer scaling
- Adding a new service is just adding a new folder or manifest in Git - not touching Argo CD configuration.
-
Consistent environments
- Dev/stage/prod can all reuse the same structure, only differing in values, not in setup logic.
In short, the App-of-Apps pattern turns Argo CD from a tool that manages applications into a system that can bootstrap and manage an entire Kubernetes platform from a single Git entry point.
This how it will look like once bootstrap app deploys all the child apps:
Gateway API
Application traffic is exposed using the Kubernetes Gateway API, the next-generation replacement for traditional Ingress resources.
The Gateway API separates infrastructure ownership from application routing, providing a cleaner networking model that scales well across multiple teams and applications.
This project demonstrates how modern Kubernetes networking can be integrated into a GitOps workflow and managed declaratively alongside application deployments.
AWS Secrets Manager Integration
Sensitive configuration is stored securely in AWS Secrets Manager rather than inside Git repositories.
Secrets are mounted into Kubernetes workloads using the Secrets Store CSI Driver and the AWS provider, enabling:
- No secrets committed to Git
- Centralized secret management
- Runtime secret retrieval
- Native AWS IAM integration
- Secure GitOps deployments
Secret in AWS Secrets Manager that contains the env name to be pulled into pod's env variable:
Why Three Repositories?
Separating responsibilities allows each repository to evolve independently while maintaining a clean GitOps workflow.
| Repository | Responsibility |
|---|---|
| Infrastructure | Provision AWS infrastructure, Amazon EKS, and bootstrap Argo CD |
| Application | Build, validate, and publish application artifacts |
| GitOps | Deploy and manage Kubernetes components and applications using Argo CD |
This architecture demonstrates several production-ready platform engineering practices:
- Infrastructure as Code with Terraform
- GitOps with Argo CD
- App-of-Apps architecture
- Kubernetes Gateway API
- Secure secret management with AWS Secrets Manager
- Automated CI/CD using GitHub Actions
- Declarative Kubernetes resource management
- Clear separation between infrastructure provisioning and Kubernetes operations
Learn More
Each repository contains detailed documentation covering its implementation, configuration, and deployment workflow:
- Infrastructure: https://github.com/kolyaiks/argo-deployment-demo-infra-helm
- Application: https://github.com/kolyaiks/argo-deployment-demo-app
- GitOps: https://github.com/kolyaiks/argo-deployment-demo-gitops
Together, these repositories demonstrate a complete GitOps platform - from provisioning AWS infrastructure and bootstrapping Argo CD, to building containerized applications, and finally managing every Kubernetes resource declaratively through Git using the App-of-Apps pattern.



Top comments (0)