A production-oriented GitOps control plane for deploying, governing, and operating the Ja-Mics application platform across multiple Kubernetes environments. This repository defines the ArgoCD application manifests, environment overlays, and platform services required to reconcile application workloads and shared infrastructure in a secure, repeatable, and auditable way.
This repo works in conjunction with:
- Application source code: ja-mics-ap
- Infrastructure repository: internal enterprise infrastructure platform (AWS/EKS and supporting cloud resources)
- This GitOps repository: Kubernetes-argocd
This repository exists to provide a declarative, version-controlled delivery model for enterprise workloads. Instead of applying Kubernetes manifests manually, teams commit desired state into Git, and ArgoCD continuously reconciles the live cluster to match that state.
This approach improves:
- Deployment consistency across environments
- Auditability and change traceability
- Faster rollback and recovery
- Security and policy enforcement through Git-based review workflows
- Standardized platform operations for multiple services
The repository is designed for a multi-service architecture with shared platform components such as ingress, monitoring, logging, tracing, networking, storage, and security policy enforcement.
While GitOps is powerful, it is not without trade-offs:
- Requires strong Git and CI/CD governance to prevent drift or misconfiguration
- Cluster access and secrets management must be tightly controlled
- ArgoCD introduces another operational dependency in the platform stack
- Multi-environment drift can occur if overlays are not reviewed carefully
- Platform changes can affect many teams if shared components are modified broadly
These are manageable by using review policies, environment isolation, RBAC controls, and structured platform ownership.
The platform follows a GitOps-first operational model where application manifests and platform definitions are stored in Git and applied by ArgoCD to the target cluster.
flowchart LR
A[GitHub Repositories] --> B[Infrastructure Repo]
A --> C[ja-mics-ap Source Repo]
A --> D[Kubernetes-argocd GitOps Repo]
D --> E[ArgoCD ApplicationSets]
E --> F[Dev Cluster]
E --> G[Staging Cluster]
E --> H[Prod Cluster]
C --> I[Container Image Build]
I --> J[Amazon ECR]
J --> F
J --> G
J --> H
B --> K[AWS EKS / Networking / Security / Storage]
K --> F
K --> G
K --> H
F --> L[Applications: user-service, order-service, payment-service, product-service]
G --> L
H --> L
L --> M[Monitoring / Logging / Tracing / Ingress / Policy]
Kubernetes-argocd/
├── apps/
│ ├── user-service/
│ ├── order-service/
│ ├── payment-service/
│ └── product-service/
├── argocd/
│ ├── dev/
│ ├── staging/
│ └── prod/
├── infrastructure/
├── platform/
│ ├── ingress/
│ ├── monitoring/
│ ├── logging/
│ ├── tracing/
│ ├── networking/
│ ├── security/
│ └── storage/
├── .github/
│ └── workflows/
├── README.md
└── LICENSE (if added for production compliance)
- Kubernetes application deployment via ArgoCD
- Multi-environment overlays for dev, staging, and prod
- Shared ingress and service exposure patterns
- Monitoring with Prometheus and Grafana
- Logging with Loki / Fluent Bit / Promtail
- Distributed tracing with Tempo and OpenTelemetry
- Policy enforcement with Kyverno
- Storage and CSI integrations for AWS-backed workloads
- Network security and ingress governance
- Build status: GitHub Actions
- Coverage: tracked as part of the application CI and release pipeline in the application repository
- Deployment model: GitOps with ArgoCD and Kustomize-based overlays
Before deploying or modifying this platform, ensure you have the following:
- Access to an AWS EKS cluster or equivalent Kubernetes cluster
- ArgoCD installed and bootstrapped in the target cluster
- kubectl configured for cluster access
- GitHub access to the repository and deployment workflows
- AWS credentials with permissions to manage EKS and supporting resources
- A working understanding of Kubernetes, Kustomize, and GitOps workflow practices
- A running application image registry such as Amazon ECR
- Clone the repository:
git clone https://github.com/Emmy-github-webdev/Kubernetes-argocd.git
cd Kubernetes-argocd-
Review the ArgoCD bootstrap definitions under the argocd folder.
-
Apply the root ArgoCD application for the target environment:
kubectl apply -f argocd/dev/root-app.yaml- Validate ArgoCD resources:
kubectl get applications -n argocd
kubectl get applicationsets -n argocd- Confirm the platform and application workloads are reconciled successfully.
kubectl apply -f argocd/dev/root-app.yamlkubectl get application -A
kubectl describe application dev-platform-root -n argocdThis repository supports environment-specific application layering via overlays:
argocd/dev/
argocd/staging/
argocd/prod/Each environment can reconcile different application versions, settings, and infrastructure constraints while preserving a common platform foundation.
The deployment flow is intentionally simple and enterprise-friendly:
- Application source is maintained in the application repo.
- Containers are built and pushed to the registry.
- This GitOps repository declares the target state.
- ArgoCD compares live cluster state with Git state.
- Kubernetes resources are reconciled automatically.
- Platform components and service workloads remain consistent across environments.
This repository is the control plane layer that connects application delivery to operational governance.
For deeper implementation details, refer to the structured repository folders and environment manifests:
This repository is intentionally organized so platform engineers, DevOps teams, and application teams can work from a common system of record.
Contributions are welcome. To keep the platform stable, please follow these norms:
- Create feature branches from the main branch
- Keep changes scoped and environment-aware
- Validate YAML and Kustomize manifests before submission
- Use clear commit messages and meaningful PR descriptions
- Review security, networking, and observability impact before merging
- Ensure environment-specific changes are intentional and supported by the appropriate overlay
Please open a pull request against the main branch and include a concise summary of the operational impact.
This repository currently does not include a public license file in the root directory. Before production release or external distribution, it is recommended to add an appropriate enterprise license such as MIT, Apache 2.0, or a company-specific policy.
If you are preparing for open-source publication, add a LICENSE file and update this section to match the selected license.
- Kubernetes
- ArgoCD
- Kustomize
- GitHub Actions
- AWS EKS
- Prometheus
- Grafana
- Loki
- Tempo
- OpenTelemetry
- Kyverno
- NGINX Ingress / AWS load balancer patterns
- External Secrets / Secret Store integrations
- Docker / containerized microservices
- GitHub repository: Kubernetes-argocd
- GitHub Actions: Workflow runs
- Application source repo: ja-mics-ap
- Infrastructure repo: enterprise internal infrastructure repository
After deployment, confirm the platform is healthy with the following checks.
kubectl config current-context
kubectl get nodesIf you see No resources found or Unable to connect to the server, refresh the kubeconfig:
aws eks update-kubeconfig \
--region <region> \
--name <cluster-name>kubectl get applications -A
kubectl get pods -n argocdYou should see ArgoCD pods and synced application resources in the argocd namespace.
kubectl get ns
kubectl get deployments -A
kubectl get pods -AIf pods are stuck in Pending, ImagePullBackOff, or CrashLoopBackOff, inspect the pod and logs:
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace>kubectl logs -n argocd deployment/argocd-application-controller
kubectl describe deployment <deployment-name> -n <namespace>Typical causes include invalid Kustomize configuration, missing namespaces, image pull errors, secret issues, or Git access problems.
kubectl rollout restart deployment <deployment-name> -n <namespace>kubectl get pods -n monitoring
kubectl get svc -n monitoringFor Grafana:
kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80Then open:
http://localhost:3000
This repository is the GitOps backbone for an enterprise Kubernetes platform. It provides a secure, scalable, and auditable way to manage application delivery, platform components, and environment consistency across multiple deployments. The result is a modern operating model that fits the expectations of enterprise DevOps, platform engineering, and cloud-native delivery teams.