Managed Kubernetes dengan Amazon EKS: Deploy dan Scale Aplikasi Container

Mengapa Managed Kubernetes Menjadi Pilihan untuk Production

Menjalankan Kubernetes secara self-managed menggunakan kubeadm atau Minikube memang memberikan fleksibilitas penuh, tetapi approach ini menghadirkan tantangan operasional yang tidak sedikit. Kita harus mengelola control plane, backup dan restore etcd, serta menangani upgrade siklus secara manual. Risiko downtime akibat miskonfigurasi control plane menjadi konsekuensi yang harus ditanggung sendiri. Belum lagi kompleksitas high availability — kita perlu menjalankan minimal tiga etcd members dan multiple API Server instances untuk menjaga cluster tetap tersedia saat maintenance.

Amazon EKS hadir sebagai solusi managed Kubernetes yang menangani heavy lifting tersebut. AWS mengelola control plane — termasuk API Server dan etcd — dengan SLA 99.95% uptime dan patching otomatis tanpa downtime. Integrasi native dengan ekosistem AWS seperti IAM, VPC, dan Load Balancer membuat EKS menjadi pilihan tepat untuk production workload yang membutuhkan skalabilitas dinamis. Beberapa use case ideal meliputi aplikasi microservices, data processing pipeline, dan CI/CD runner yang membutuhkan auto scaling.

Keunggulan lain EKS adalah kemudahan upgrade versi Kubernetes. AWS mendukung tiga versi minor terakhir dan menyediakan mekanisme rolling update untuk control plane. Kita tidak perlu khawatir tentang etcd backup atau API Server certificate renewal — semua itu sudah menjadi tanggung jawab AWS.

Arsitektur Cluster EKS dan Komponen Utama

Sebelum deploy aplikasi, kita perlu memahami komponen fundamental yang membangun sebuah EKS cluster. Control plane EKS dikelola sepenuhnya oleh AWS, artinya kita tidak perlu repot mengurus API Server, etcd, atau scheduler. Kita cukup fokus pada worker nodes dan konfigurasi networking. Setiap cluster EKS memiliki endpoint API yang terintegrasi dengan IAM untuk autentikasi — baik melalui aws-iam-authenticator maupun access entries yang lebih baru.

Worker nodes di EKS dapat menggunakan EC2 instances atau Fargate (serverless). Managed Node Groups menjadi pilihan paling populer karena AWS mengelola patching, scaling, dan replacement node secara otomatis. Untuk workload yang tidak memerlukan akses ke GPU atau persistent storage, Fargate menawarkan opsi serverless di mana kita hanya membayar per Pod tanpa mengelola node sama sekali. Kedua opsi ini bisa berjalan bersamaan dalam satu cluster menggunakan kombinasi Fargate profiles dan node groups.

Untuk networking, EKS menggunakan Amazon VPC CNI plugin yang memberikan alamat IP langsung dari VPC ke setiap Pod. Pendekatan ini berbeda dengan Flannel atau Calico yang menggunakan overlay network, dan memberikan latency yang lebih rendah karena tidak memerlukan encapsulation. Konsekuensinya, setiap Pod akan mendapatkan IP address dari range subnet VPC, sehingga perencanaan alokasi IP menjadi penting — terutama untuk cluster besar dengan ribuan Pod.

Konfigurasi IAM Roles for Service Accounts (IRSA) memungkinkan setiap Pod memiliki identity AWS sendiri. Mekanisme ini bekerja dengan mengasosiasikan IAM role ke Kubernetes service account, lalu Pod yang menggunakan service account tersebut bisa mengakses AWS services tertentu tanpa harus menggunakan credential file atau environment variable. Ini lebih aman dibanding memberikan akses langsung ke instance role karena kita bisa menerapkan least privilege principle secara granular. Berikut contoh konfigurasi EKS cluster menggunakan Terraform:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  name   = "eks-vpc"
  cidr   = "10.0.0.0/16"

  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.3.0/24", "10.0.4.0/24"]
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "production-cluster"
  cluster_version = "1.30"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    main = {
      desired_size = 3
      min_size     = 2
      max_size     = 10
      instance_types = ["t3.medium"]
    }
  }
}

Konfigurasi di atas mendefinisikan VPC dengan subnet privat untuk worker nodes dan subnet publik untuk Load Balancer. Managed node group dimulai dengan 3 instance dan dapat diskalakan antara 2 hingga 10 node sesuai kebutuhan.

Gambar: Arsitektur high-level Kubernetes — Sumber: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Kubernetes.png) (CC BY-SA 4.0)

Deploy Aplikasi ke EKS Cluster

Setelah cluster siap, langkah pertama adalah mengkonfigurasi kubeconfig menggunakan AWS CLI. Perintah aws eks update-kubeconfig --name production-cluster --region ap-southeast-1 akan menggenerate file kubeconfig yang terintegrasi dengan AWS IAM autentikasi. Setelah itu, kita bisa langsung menggunakan kubectl get nodes untuk memverifikasi koneksi. Setiap user atau role yang ingin mengakses cluster harus memiliki izin yang sesuai — baik melalui aws-auth ConfigMap (untuk EKS versi lama) maupun melalui EKS Access Entries yang lebih baru dan lebih mudah dikelola.

Struktur manifest Kubernetes pada EKS tidak berbeda dengan Kubernetes pada umumnya. Kita tetap menggunakan Deployment, Service, dan Ingress. Yang membedakan adalah integrasi dengan AWS Load Balancer Controller yang memungkinkan kita menggunakan Application Load Balancer (ALB) sebagai Ingress controller — menggantikan kebutuhan Nginx Ingress atau Traefik untuk traffic HTTP/S. AWS Load Balancer Controller diinstal sebagai Deployment di cluster dan secara otomatis memprovision ALB setiap kali Ingress resource dibuat.

Pilihan Service type juga perlu dipertimbangkan dengan matang. Service type ClusterIP hanya bisa diakses dari dalam cluster. NodePort mengekspos port di setiap node, sementara LoadBalancer akan memprovision Network Load Balancer (NLB) untuk setiap Service. Untuk production, kombinasi ClusterIP + Ingress dengan ALB adalah pattern yang paling umum karena memberikan routing layer yang terpusat.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: app
        image: nginx:alpine
        resources:
          requests:
            cpu: "256m"
            memory: "512Mi"
          limits:
            cpu: "512m"
            memory: "1Gi"
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-svc
  namespace: production
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-svc
            port:
              number: 80

Manifest di atas mendeploy aplikasi Nginx dengan 3 replica, mengeksposnya melalui Service type ClusterIP, dan membuat ALB publik melalui Ingress. AWS Load Balancer Controller akan otomatis memprovision ALB dan menghubungkannya dengan target group yang berisi Pod-Pod kita.

Auto Scaling — Horizontal Pod Autoscaler dan Cluster Autoscaler

Salah satu keunggulan utama menggunakan EKS adalah kemampuan auto scaling yang berlapis. Kita memiliki dua mekanisme scaling yang bekerja secara komplementer: Horizontal Pod Autoscaler (HPA) untuk skala di level Pod, dan Cluster Autoscaler untuk skala di level node. Keduanya harus dikonfigurasi bersama agar scaling berjalan mulus — HPA menambah Pod, dan ketika Pod baru tidak muat di node yang ada, Cluster Autoscaler menambah node baru.

HPA akan menambah atau mengurangi jumlah replica Pod berdasarkan metrik CPU atau memory utilization. Prasyarat utamanya adalah setiap container harus mendefinisikan resource requests dan limits. Tanpa ini, HPA tidak memiliki baseline untuk menghitung utilisasi dan tidak akan berfungsi. Untuk production, sebaiknya kita juga menggunakan custom metrics seperti request per second (RPS) atau queue length menggunakan Kubernetes Event-driven Autoscaling (KEDA).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Cluster Autoscaler bekerja pada level yang berbeda. Ketika HPA meminta replica tambahan tetapi node yang tersedia tidak memiliki kapasitas cukup, Cluster Autoscaler akan menambahkan node baru ke Managed Node Group. Sebaliknya, ketika ada node dengan utilisasi rendah, node tersebut akan di-drain dan dihapus.

Kita bisa mensimulasikan scaling dengan menjalankan load test menggunakan alat seperti kubectl run load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://web-app-svc.production; done". Setelah beberapa menit, kita akan melihat Pod bertambah dari 2 menjadi 5 atau lebih, dan jika diperlukan, node baru akan bergabung secara otomatis.

Best Practices Keamanan dan Monitoring

Keamanan di EKS membutuhkan pendekatan berlapis yang mencakup network, identity, dan data. Network Policies menjadi komponen penting untuk mengisolasi traffic antar Pod. Dengan Network Policies, kita bisa menerapkan prinsip zero-trust di level jaringan — hanya service yang benar-benar perlu berkomunikasi yang diizinkan terhubung. Ini sangat penting untuk mencegah lateral movement jika salah satu Pod berhasil dieksploitasi.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-except-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-app
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - protocol: TCP
      port: 80

Kebijakan di atas memastikan hanya Pod dari namespace ingress-nginx yang dapat mengakses aplikasi kita melalui port 80. Semua traffic lain akan ditolak secara default.

Untuk monitoring, CloudWatch Container Insights memberikan visibilitas penuh ke dalam log dan metrics cluster. Kita bisa melihat CPU dan memory utilization per node, per Pod, dan bahkan per container. Aktifkan dengan perintah aws eks create-addon --cluster-name production-cluster --addon-name amazon-cloudwatch-observability.

Dari sisi cost optimization, menggunakan Spot Instances untuk worker nodes dapat menghemat hingga 70% dibanding On-Demand. Kita juga bisa mengkombinasikan Savings Plans dengan Auto Scaling untuk mendapatkan diskon tambahan. Upgrade versi Kubernetes sebaiknya dilakukan secara bertahap — AWS mendukung 3 versi minor terakhir — dan kita bisa menggunakan EKS version upgrade strategy dengan mencadangkan node group lama sebelum migrasi.

Itulah panduan lengkap deploy dan scale aplikasi container di Amazon EKS. Konsep-konsep seperti auto scaling, network policy, dan cost optimization ini menjadi materi utama dalam bootcamp DevOps dan Cloud Computing di Rumah Coding. Tertarik untuk mendalami lebih lanjut?