Abdimajid Hussein
All projects
02CompletedKubernetes · GitOps · Observability

Amazon EKS Application Platform

  • AWS
  • EKS
  • Terraform
  • Kubernetes
  • Helm

01 What I built

After running a single container service I wanted to operate a cluster: how traffic gets in, how workloads get updated and how you see what the cluster is doing.

  • GitOps delivery: CI builds, Argo CD deploys
  • Automated DNS and TLS with ExternalDNS and cert-manager
  • Trivy gate blocks HIGH and CRITICAL image vulnerabilities

02 Architecture

  1. 01Internet
    User
    Route 53
    records managed by ExternalDNS
  2. 02Edge
    AWS load balancer
    HTTPS
  3. 03Cluster ingress
    NGINX Ingress
    TLS from cert-manager · Let's Encrypt
  4. 04Workloads
    ClusterIP Service
    2048 app pods
    private worker nodes
  5. 05Outbound
    NAT gateway
    private subnet egress, image pulls from ECR
  6. 06Operations
    Argo CD
    reconciles Helm state from Git
    Prometheus + Grafana
    metrics and dashboards
Route 53 resolves the hostname to the load balancer, which forwards to NGINX Ingress, then the Service and the pods. Private nodes reach the internet through a NAT gateway. Argo CD, Prometheus and Grafana run alongside the workload, not in the request path.

03 Important decision

Why does CI build and Argo CD deploy?

GitHub Actions validates, scans and publishes images. Argo CD owns reconciliation, so what runs is whatever Git says and the pipeline does not need direct cluster deployment access.

04 Issue solved

Trivy blocked the application pipeline

Problem
The application pipeline failed because Trivy found HIGH-severity vulnerabilities in the NGINX Alpine base image packages.
Root cause
The base image shipped with outdated Alpine packages.
Fix
Kept the security gate on and upgraded packages during the image build (apk upgrade), then rebuilt until the HIGH and CRITICAL scan passed.

05 Repository

View the repository
Back to all projects