Tentang Sesi Ini
Ringkasan & metadata
Sesi ini membahas Amazon EKS Auto Mode — sebuah mode operasi untuk Amazon EKS yang mengotomatiskan pengelolaan infrastruktur klaster Kubernetes. Alih-alih tim Anda sibuk mengurus node group, autoscaler, patching sistem operasi, dan komponen inti klaster, semua itu dikelola oleh AWS. Tujuannya satu: mengurangi ops overhead agar tim bisa kembali fokus ke hal yang benar-benar bernilai — menjalankan aplikasi (workload).
Menjalankan Kubernetes di produksi selama ini terkenal berat di sisi operasional. Anda harus memilih tipe instance untuk node, mengatur Cluster Autoscaler atau Karpenter, memantau kapan node penuh, menambal (patch) OS secara berkala, meng-upgrade versi node saat control plane naik versi, sampai memasang add-on inti seperti CNI (networking), driver penyimpanan (storage), dan pengendali load balancer. Semua ini adalah pekerjaan "menjaga lampu tetap menyala" yang tidak menambah fitur baru bagi pengguna aplikasi Anda. EKS Auto Mode memindahkan sebagian besar beban itu ke AWS.
Kenapa penting untuk Anda? Jika tim Anda kecil, tidak punya tim platform khusus, tetapi tetap ingin menikmati fleksibilitas Kubernetes tanpa terjebak mengurus node dan patch, sesi ini adalah jalan pintasnya.
Deeeplabs Pte Ltd adalah konsultan sekaligus Cloud System Integrator yang beroperasi di Asia Tenggara, dengan tim tersebar di Singapura dan Indonesia (30+ orang lintas dua negara) dan klaim melayani 200+ klien & mitra. Fokus jasanya mencakup transformasi & integrasi cloud, konsultasi/advisory, modernisasi aplikasi, data analytics, serta generative AI — profil yang menempatkannya sebagai penyedia jasa cloud/DevOps yang relevan dengan topik pengelolaan Kubernetes seperti EKS. Pada materi publik yang kami telusuri (situs resmi, LinkedIn, Crunchbase), tidak ditemukan pernyataan resmi mengenai tingkat keanggotaan AWS Partner tertentu maupun penggunaan Amazon EKS/EKS Auto Mode; positioning cloud mereka bersifat lintas-platform.
Sumber: deeeplabs.com (halaman About), profil LinkedIn & Crunchbase Deeeplabs, serta dokumentasi AWS Partner Network (partners.amazonaws.com). Detail arsitektur spesifik sesi ilustratif kecuali disebutkan.
Apa Itu & Bagaimana Bekerjanya
Apa itu EKS Auto Mode
Bayangkan klaster Kubernetes punya dua bagian: control plane (otak yang mengatur) dan data plane (node/mesin tempat aplikasi benar-benar berjalan). EKS selama ini sudah mengelola control plane untuk Anda. EKS Auto Mode melangkah lebih jauh: ia juga mengelola data plane dan komponen inti klaster. AWS yang menyediakan node, menskalakannya naik-turun sesuai beban, menambalnya, dan mendaur ulang node yang sudah usang secara otomatis.
Prinsipnya: Anda tetap memakai Kubernetes yang standar dan familiar — kubectl, manifest YAML, Deployment, Service — tetapi tidak lagi memikirkan mesin di baliknya. Ketika Anda men-deploy aplikasi yang butuh lebih banyak sumber daya, Auto Mode menyediakan compute yang tepat secara otomatis. Ketika beban turun, node yang tak terpakai dilepas agar Anda tidak membayar kapasitas menganggur.
Yang diotomatiskan Auto Mode
Berikut area utama yang diambil alih dan dikelola AWS di mode ini:
Perhatikan pola besarnya: Anda tetap memegang kendali atas aplikasi (apa yang dijalankan, berapa banyak replika, konfigurasi), sementara AWS memegang kendali atas infrastruktur (mesin apa yang dipakai, kapan ditambal, kapan diganti). Pembagian tugas inilah yang memangkas ops overhead.
Analogi yang Mudah Dicerna
Ibarat mobil matic vs manual
Ibaratnya, mengelola Kubernetes tradisional itu seperti menyetir mobil manual. Anda harus terus memikirkan kopling dan perpindahan gigi: kapan naik gigi, kapan turun, jangan sampai mesin mati di tanjakan. Melelahkan, apalagi di jalanan macet. EKS Auto Mode adalah mobil MATIC (otomatis). Anda cukup menyetir — menginjak gas dan mengarahkan setir menuju tujuan — sementara transmisi mengurus perpindahan gigi sendiri.
- Menyetir (fokus jalan) = menjalankan aplikasi Anda — inilah yang seharusnya jadi perhatian utama.
- Pindah gigi manual = mengurus node, autoscaler, patch, upgrade — pekerjaan mekanis yang menyita perhatian.
- Transmisi otomatis = EKS Auto Mode yang menangani perpindahan itu tanpa Anda pikirkan.
- Tetap Anda yang menyetir = Anda tetap menentukan tujuan (aplikasi & kebijakan), bukan menyerahkan kemudi sepenuhnya.
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, sebuah klaster EKS Auto Mode terlihat seperti ini: Anda mengirim manifest lewat kubectl ke Control Plane EKS (dikelola AWS). Auto Mode lalu menyediakan node compute yang sesuai untuk menjalankan Pod aplikasi Anda, sekaligus memasang komponen inti — networking, storage, dan load balancing — dan menjaga node tetap ditambal serta up-to-date.
Alur penskalaan satu deployment
Ketika Anda men-deploy aplikasi baru atau lalu lintas melonjak, inilah yang terjadi di balik layar:
- Deploy. Anda menerapkan manifest (mis. Deployment 10 replika) lewat
kubectlke control plane. - Pod menunggu. Scheduler melihat Pod butuh compute yang belum tersedia (pending).
- Sediakan node. Auto Mode otomatis memilih & menyalakan tipe instance yang pas untuk menampung Pod tersebut.
- Jalankan. Pod ditempatkan di node baru; networking & storage sudah otomatis siap.
- Turun beban. Saat lalu lintas surut, node yang menganggur dilepas agar biaya turun.
- Rawat. Node yang usang ditambal atau didaur ulang oleh AWS tanpa intervensi Anda.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas di Indonesia. Pengalaman Deeeplabs mendampingi tim-tim seperti ini menjadi benang merah sesi.
Kubernetes tanpa tim platform besar
Sebuah perusahaan software dengan 6 engineer ingin memakai Kubernetes agar aplikasinya portabel dan tangguh, tetapi tidak punya tim platform/DevOps khusus untuk merawat klaster. Dengan EKS Auto Mode, mereka tak perlu mengurus node group, autoscaler, atau jadwal patching. Satu engineer cukup men-deploy lewat kubectl, dan AWS menangani compute di baliknya. Hasilnya: mereka menikmati kekuatan Kubernetes tanpa harus merekrut spesialis infrastruktur.
Fokus penuh ke produk, bukan mesin
Startup fintech tahap awal berpacu dengan waktu untuk merilis fitur. Setiap jam yang dihabiskan mengurus upgrade node atau menambal OS adalah jam yang tidak dipakai membangun produk. Dengan Auto Mode, beban "menjaga lampu tetap menyala" berpindah ke AWS, sehingga tim engineering bisa fokus penuh pada pengembangan produk dan mempercepat waktu ke pasar.
Hemat & auto-scale saat trafik naik-turun
Platform tiket acara mengalami lonjakan trafik ekstrem saat penjualan dibuka, lalu sepi di luar jam itu. Menyediakan node manual untuk puncak berarti membayar kapasitas menganggur sepanjang hari. Auto Mode menambah node otomatis saat lonjakan datang dan melepasnya begitu reda — menjaga layanan tetap responsif sekaligus menekan biaya karena Anda hanya membayar compute yang benar-benar dipakai.
Kapan cocok, kapan tidak? Auto Mode ideal ketika Anda ingin kemudahan dan tim kecil. Namun ada trade-off: Anda menukar sebagian kontrol granular atas node (mis. tuning OS mendalam, tipe instance yang sangat spesifik) dengan kenyamanan. Untuk workload yang butuh kontrol infrastruktur sangat rinci atau kepatuhan kustom di level node, mode terkelola tradisional bisa lebih sesuai. Pertimbangkan juga dampak biaya: ada premi kenyamanan, tetapi sering diimbangi penghematan dari penskalaan efisien dan berkurangnya jam kerja operasional.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- Ops overhead adalah musuh diam-diam. Mengurus node, autoscaler, dan patch menyita waktu tanpa menambah fitur.
- EKS Auto Mode memindahkan beban itu ke AWS — provisioning & scaling compute, patching, upgrade, dan komponen inti (networking, storage, load balancing).
- Anda tetap pegang aplikasi, AWS pegang infrastruktur. Kubernetes-nya tetap standar dan familiar.
- Sadari trade-off-nya. Kemudahan menukar sebagian kontrol granular; cocok untuk tim kecil, startup, dan beban fluktuatif, dengan dampak biaya yang perlu ditimbang.