Belajar Cloud Computing - Managed Container & Kubernetes Services

#Pendahuluan

Di episode 11 kita mengurus logika kecil dengan serverless. Namun banyak aplikasi tidak nyaman dipaksa masuk bentuk fungsi — ia punya framework penuh, dependency banyak, proses berjalan panjang, dan port yang harus terbuka. Untuk aplikasi seperti itu, cara deployment modernnya adalah container, dan cara mengaturnya di skala besar adalah Kubernetes.

Episode 12 ini membahas kenapa container menjadi standar deployment, bagaimana container unggul atas VM, apa yang dimaksud managed Kubernetes, siapa mengelola apa, serta perbandingan EKS, ECS, Fargate, GKE, Cloud Run, AKS, dan Azure Container Apps. Kalian juga akan melihat langsung perintah kubectl dan manifest Deployment pertama.

#Container: Mengapa Menjadi Standar Modern

Sebelum container, masalah terbesar deployment adalah "berjalan di mesin saya". Aplikasi yang bekerja di laptop developer sering mogok di production karena versi runtime, library, dan konfigurasi yang berbeda. Container menyelesaikannya secara radikal: aplikasi dan seluruh lingkungannya dikemas menjadi satu image, lalu dijalankan di mana pun dengan hasil yang sama.

Aspek	VM	Container
Unit virtualisasi	Seluruh OS (hypervisor)	Proses + OS kernel host
Ukuran	Gigabyte	Megabyte
Waktu boot	Menit	Detik
Kepadatan per host	Puluhan	Ratusan hingga ribuan
Konsistensi	Bergantung konfigurasi OS	Identik di mana pun

Tip

Analoginya seperti pengiriman barang. VM adalah truk yang membawa seluruh pabriknya — besar, lambat, dan boros. Container adalah kontainer peti kemas: isi, standar ukurannya, dan bisa diangkut oleh kapal, truk, atau kereta mana pun di dunia. Standarisasi itulah yang mengubah logistik dunia — dan membuat container mengubah cara perangkat lunak didistribusikan.

Image container dibangun dari Dockerfile, disimpan di registry (seperti Docker Hub, ECR, GCR, atau ACR), lalu ditarik dan dijalankan oleh host. Setiap perubahan kode menghasilkan image baru dengan versi tag — reproducibility yang dulu mustahil dicapai dengan server manual.

#Dari VM ke Container ke Orchestration

Menjalankan satu container itu mudah. Masalah muncul saat container sudah puluhan: siapa yang menempatkan container ke mesin mana, siapa yang merestart container yang crash, siapa yang mengarahkan traffic ke container yang benar, dan bagaimana menambah jumlah container saat beban naik. Jawabannya adalah orchestration, dan standar de facto-nya adalah Kubernetes (K8s).

Kubernetes memecah dunia menjadi dua level:

Cluster: sekumpulan mesin (worker nodes) tempat container berjalan.
Orchestrator: otak yang memutuskan penempatan, kesehatan, dan penskalaan.

Kalian tidak lagi berinteraksi dengan container satu per satu, melainkan mendeklarasikan kondisi yang diinginkan — "jalankan 3 replika aplikasi ini" — dan Kubernetes bekerja menjaga agar kenyataan selalu sama dengan keinginan kalian.

#Managed Kubernetes: Siapa Mengelola Apa

Menjalankan Kubernetes sendiri berarti mengoperasikan komponen control plane yang rumit — API server, scheduler, controller manager, dan etcd. Mengelola semua itu sendiri (self-managed) hanya masuk akal di skala raksasa. Bagi hampir semua tim, pilihan yang benar adalah managed Kubernetes: EKS (AWS), GKE (GCP), dan AKS (Azure).

Komponen	Dikelola provider	Dikelola kalian
Control plane (API server, scheduler, etcd)	Ya — HA dan patch otomatis	Tidak
Worker nodes (mesin tempat container jalan)	Tidak	Ya — versi, ukuran, jumlah, patch
Pod dan workload	Tidak	Ya
Network policy, storage, security	Tidak	Ya

Important

Pemisahan ini penting karena menentukan tanggung jawab kalian. Provider menjamin control plane-nya hidup, tetapi kalian tetap bertanggung jawab penuh atas worker nodes — versi Kubernetes-nya, node yang rusak, kapasitasnya. Analoginya seperti menyewa gedung: pengelola properti (provider) menjamin listrik dan lift gedung, tetapi kalian yang mengisi, mengatur, dan merawat isi tiap ruangan (worker nodes dan workload).

#Praktik: kubectl dan Manifest Deployment

Setelah cluster tersedia, kalian berinteraksi dengannya lewat kubectl. Memeriksa kesehatan worker nodes:

Status Ready pada semua node berarti control plane bisa menjadwalkan container di mesin-mesin itu. Selanjutnya, aplikasi dideklarasikan dalam manifest YAML — sumber kebenaran yang bisa disimpan di git, bukan klik-klik konsol:

deployment.yaml - manifest Deployment sederhana

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: company/web-app:1.4.0
          ports:
            - containerPort: 8080

Manifest ini mendeklarasikan: "selalu pastikan ada 3 replika aplikasi web-app dari image versi 1.4.0". Mengirim manifest ke cluster dilakukan dengan kubectl apply -f deployment.yaml:

Note

Perhatikan pola yang akan kalian temui di seluruh Kubernetes: kalian mendeklarasikan kondisi yang diinginkan, dan Kubernetes yang mengeksekusinya. Jika sebuah pod mati, Kubernetes membuat penggantinya untuk menjaga jumlah replika tetap tiga. Jika kalian mengubah image menjadi versi baru, Kubernetes melakukan rolling update secara bertahap tanpa downtime. Inilah yang disebut self-healing dan declarative — fondasi yang nanti menjadi bahan utama episode Infrastructure as Code.

#Serverless Container Runtimes

Managed Kubernetes memberi kalian kontrol penuh, tetapi tetap menyisakan pekerjaan: memilih ukuran node, mengatur scaling, dan menjaga kesehatan node. Untuk aplikasi yang ingin memakai container tanpa memikirkan node sama sekali, ada kategori serverless container:

AWS Fargate: runtime container untuk ECS dan EKS yang menghilangkan manajemen node — kalian memilih CPU dan memori per task, bukan per mesin.
Google Cloud Run: menjalankan container yang scale-to-zero — tidak ada eksekusi, tidak ada tagihan, seperti serverless di episode 11 tetapi dalam bentuk container penuh.
Azure Container Apps: platform container serverless berbasis Kubernetes dengan auto-scaling dan integrasi event.

Aspek	Managed Kubernetes	Serverless container
Manajemen node	Kalian urus worker nodes	Provider, sepenuhnya
Skala	Node dan pod otomatis	Hingga nol (scale-to-zero)
Kontrol	Penuh (network, storage, fleksibilitas)	Terbatas pada konfigurasi runtime
Cocok untuk	Aplikasi kompleks, workload custom	Aplikasi berbasis request dan event

Tip

Arahkan keputusan seperti ini: butuh kontrol penuh dan workload beragam, gunakan managed Kubernetes; hanya butuh menjalankan container yang melayani request, gunakan serverless container. Mulai dari yang lebih sederhana, naik ke Kubernetes hanya ketika kebutuhan nyata muncul — jangan membangun cluster untuk aplikasi yang bisa ditangani Cloud Run atau Fargate.

#Komparasi Layanan Container Big 3

Kebutuhan	AWS	GCP	Azure
Managed Kubernetes	EKS	GKE	AKS
Container orchestrator terkelola	ECS	Cloud Run	Container Apps
Serverless container	Fargate	Cloud Run	Azure Container Apps
Container registry	ECR	Artifact Registry	ACR

Konsep di balik nama-nama ini identik: image container, orchestrator atau runtime terkelola, dan registry untuk menyimpan image. Berpindah antar cloud berarti belajar perintah baru, tetapi pola berpikirnya — image, deployment, replicas, services — tetap sama.

#Penutup

Pada episode 12 ini kalian telah memahami kenapa container menjadi standar deployment — aplikasi dikemas bersama lingkungannya sehingga berjalan identik di mana pun — dan bagaimana orchestration menangani puluhan container sekaligus. Kalian juga memahami pembagian peran dalam managed Kubernetes: provider mengelola control plane, kalian mengelola worker nodes dan workload. Terakhir, kalian berkenalan dengan serverless container seperti Fargate, Cloud Run, dan Container Apps yang menghilangkan manajemen node sama sekali, serta praktik langsung kubectl get nodes dan kubectl apply -f deployment.yaml.

Kunci yang harus dibawa pulang:

Container menstandarkan deployment — image yang sama berjalan identik di mana pun.
Managed Kubernetes = provider urus control plane, kalian urus sisanya.
Pilih Kubernetes saat butuh kontrol, pilih serverless container saat butuh kesederhanaan.

Aplikasi kalian kini bisa di-deploy dengan cara modern. Tapi begitu aplikasi diluncurkan, pengguna dari seluruh dunia bertanya: kenapa halaman yang sama lambat di Jakarta dan cepat di London, dan bagaimana nama domain kalian selalu menemukan jalan ke server yang benar? Episode 13 menjawab dua pertanyaan itu: Content Delivery Network (CDN) & Cloud DNS — mengirim konten dari titik terdekat dan menerjemahkan nama domain dengan cerdas.