Kubernetes adalah teknologi yang saat ini menjadi fondasi utama dalam pengembangan aplikasi modern berbasis cloud. Seiring meningkatnya penggunaan Docker dan arsitektur microservices, kebutuhan untuk mengelola container dalam jumlah besar menjadi semakin penting.
Di Indonesia, Kubernetes semakin banyak digunakan oleh startup, perusahaan teknologi, hingga enterprise. Banyak lowongan kerja untuk DevOps Engineer, Cloud Engineer, dan Site Reliability Engineer yang menjadikan Kubernetes sebagai skill utama.
Artikel ini disusun sebagai panduan lengkap yang akan membahas Kubernetes dari nol hingga praktik. Cocok untuk pemula yang ingin belajar Kubernetes secara terstruktur dan memahami cara kerja serta contoh penerapannya.
Apa Itu Kubernetes?
Kubernetes (dibaca: koo-ber-neh-tees) adalah platform open-source untuk mengotomatiskan deployment, scaling, dan manajemen aplikasi berbasis container. Sederhananya, Kubernetes berperan sebagai "manajer cerdas" yang memastikan aplikasi Anda selalu berjalan dengan optimal — bahkan ketika ada komponen yang gagal, lonjakan traffic tiba-tiba, atau kebutuhan update tanpa downtime.
Definisi Kubernetes Secara Sederhana
Bayangkan Anda mengelola sebuah restoran besar dengan puluhan juru masak (container). Tanpa koordinator, Anda harus mengatur sendiri siapa memasak apa, mengganti juru masak yang sakit, dan menambah staf saat restoran ramai. Kubernetes adalah manajer restoran otomatis yang melakukan semua itu untuk Anda — memastikan setiap "juru masak" (container) berjalan, digantikan jika bermasalah, dan ditambah jumlahnya saat permintaan meningkat.
Secara teknis, Kubernetes adalah sistem container orchestration yang mengelola cluster dari banyak mesin (node) sekaligus, memungkinkan Anda mendeploy dan mengelola aplikasi dalam skala besar dengan cara yang deklaratif — cukup definisikan "keadaan yang diinginkan", dan Kubernetes akan bekerja keras mewujudkannya secara otomatis.
Sejarah Singkat Kubernetes dan Asal-Usulnya dari Google
Kubernetes lahir dari pengalaman nyata Google dalam mengelola miliaran container setiap minggunya menggunakan sistem internal bernama Borg — sebuah platform orkestrasi yang telah digunakan Google selama lebih dari satu dekade sebelum Kubernetes ada. Pada tahun 2014, Google memutuskan untuk membagikan kebijaksanaan tersebut kepada dunia dengan merilis Kubernetes sebagai proyek open-source.
- 2003–2004: Google mengembangkan sistem Borg secara internal untuk mengelola skala besar workload produksi mereka.
- 2014: Google merilis Kubernetes sebagai proyek open-source di GitHub, terinspirasi langsung dari arsitektur Borg.
- 2015: Kubernetes versi 1.0 resmi diluncurkan, dan Google menyerahkan pengelolaannya ke Cloud Native Computing Foundation (CNCF).
- 2016–kini: Kubernetes menjadi standar industri de facto untuk container orchestration, diadopsi oleh ribuan perusahaan di seluruh dunia.
Mengapa Kubernetes Disebut "K8s"?
Anda mungkin sering melihat Kubernetes ditulis sebagai K8s di dokumentasi, forum, atau percakapan developer. Ini bukan typo atau singkatan sembarangan — melainkan sebuah numeronym, yaitu singkatan berbasis angka yang populer di kalangan engineer.
Cara bacanya sederhana: huruf K adalah huruf pertama, angka 8 mewakili 8 huruf di tengah (ubernete), dan huruf s adalah huruf terakhir dari kata Kubernetes. Konvensi serupa juga digunakan pada kata lain di dunia teknologi, seperti:
- i18n → internationalization (i + 18 huruf + n)
- a11y → accessibility (a + 11 huruf + y)
- K8s → Kubernetes (K + 8 huruf + s)
Jadi, kapan pun Anda membaca K8s di dokumentasi atau artikel teknis, itu merujuk pada Kubernetes. Penggunaan singkatan ini sangat umum di komunitas DevOps dan cloud-native karena lebih praktis diketik, terutama saat menulis kode, konfigurasi, atau perintah CLI.
Mengapa Kubernetes Penting di Era Modern?
Di era di mana aplikasi dituntut untuk selalu online, mampu melayani jutaan pengguna sekaligus, dan bisa diperbarui tanpa gangguan — mengelola infrastruktur secara manual bukan lagi pilihan yang realistis. Kubernetes hadir sebagai jawaban atas kompleksitas tersebut, mengubah cara tim engineering modern membangun, mendeploy, dan mengoperasikan aplikasi di skala produksi.
Tantangan Mengelola Aplikasi Tanpa Kubernetes
Sebelum era container orchestration, tim DevOps harus menghadapi berbagai masalah operasional yang menyita waktu dan rentan terhadap human error. Bayangkan Anda menjalankan aplikasi e-commerce dengan traffic yang tidak terduga — saat flash sale tiba, server kewalahan, dan Anda harus menambah kapasitas secara manual, satu per satu, di tengah kepanikan.
Berikut adalah tantangan nyata yang dihadapi tim engineering tanpa Kubernetes:
- Scaling manual yang lambat: Menambah server baru membutuhkan waktu dan langkah konfigurasi yang panjang, sementara lonjakan traffic tidak bisa menunggu.
- Tidak ada self-healing: Jika sebuah container atau server crash, tidak ada mekanisme otomatis untuk me-restart atau memindahkannya — tim harus siaga 24/7.
- Deployment berisiko tinggi: Update aplikasi sering menyebabkan downtime karena tidak ada strategi rollout yang terstruktur seperti rolling update atau canary deployment.
- Pemborosan sumber daya: Tanpa alokasi resource yang cerdas, server sering berjalan di bawah kapasitas optimal — membayar mahal untuk kapasitas yang tidak terpakai.
- Konfigurasi yang tidak konsisten: Perbedaan environment antara development, staging, dan production menjadi sumber bug yang sulit dilacak.
Manfaat Utama Menggunakan Kubernetes
Kubernetes tidak sekadar memecahkan masalah di atas — ia mengubah paradigma pengelolaan infrastruktur secara fundamental. Dengan Kubernetes, tim engineering dapat fokus pada pengembangan fitur, bukan pada tugas-tugas operasional yang repetitif dan rentan error.
- Auto-scaling cerdas: Kubernetes secara otomatis menambah atau mengurangi jumlah container berdasarkan beban aktual — baik horizontal (lebih banyak pod) maupun vertikal (lebih banyak resource per pod).
- Self-healing otomatis: Container yang crash akan di-restart secara otomatis, pod yang tidak sehat dipindahkan ke node lain, dan traffic tidak akan diarahkan ke instance yang belum siap.
- Zero-downtime deployment: Strategi rolling update memungkinkan pembaruan aplikasi berjalan bertahap tanpa memutus layanan, disertai kemampuan rollback instan jika terjadi masalah.
- Efisiensi resource yang optimal: Kubernetes mengemas container ke dalam node secara cerdas berdasarkan kebutuhan CPU dan memori, memaksimalkan utilisasi infrastruktur.
- Portabilitas penuh: Jalankan cluster yang sama di laptop, data center on-premise, AWS, GCP, atau Azure — tanpa perubahan konfigurasi yang signifikan.
- Manajemen konfigurasi terpusat: ConfigMap dan Secret memungkinkan pemisahan konfigurasi dari kode aplikasi, menjaga konsistensi di semua environment.
Siapa yang Menggunakan Kubernetes? (Perusahaan & Use Case Nyata)
Kubernetes bukan hanya untuk perusahaan teknologi raksasa. Dari startup tahap awal hingga korporasi Fortune 500, adopsi Kubernetes terus tumbuh pesat. Menurut survei CNCF, lebih dari 96% organisasi kini menggunakan atau mengevaluasi Kubernetes untuk lingkungan produksi mereka.
Berikut beberapa contoh nyata perusahaan global dan bagaimana mereka memanfaatkan Kubernetes:
- Spotify: Menggunakan Kubernetes untuk mengelola ribuan microservice yang melayani lebih dari 600 juta pengguna aktif, memungkinkan tim engineering mendeploy kode ratusan kali per hari.
- Airbnb: Memanfaatkan Kubernetes untuk menangani lonjakan traffic musiman yang tidak terduga, memastikan platform tetap stabil saat permintaan booking melonjak drastis.
- The New York Times: Berpindah ke Kubernetes untuk mempercepat siklus rilis konten digital dan meningkatkan keandalan platform berita mereka di saat traffic puncak.
- Tokopedia & Gojek: Dua unicorn Indonesia ini menggunakan Kubernetes sebagai fondasi infrastruktur microservice mereka untuk melayani puluhan juta transaksi harian.
- Perusahaan perbankan & fintech: Memanfaatkan Kubernetes untuk memenuhi kebutuhan high availability dan compliance, memastikan layanan finansial tidak pernah mengalami downtime.
Yang menarik, Kubernetes kini juga mulai diadopsi di luar dunia web — mulai dari industri manufaktur yang menjalankan workload IoT di edge, hingga lembaga riset ilmiah yang mengelola komputasi data berskala besar. Ini membuktikan bahwa Kubernetes bukan sekadar tren, melainkan infrastruktur fundamental untuk komputasi modern di berbagai industri.
Konsep Dasar yang Wajib Dipahami Sebelum Belajar Kubernetes
Sebelum terjun langsung ke Kubernetes, ada beberapa fondasi konsep yang wajib Anda pahami terlebih dahulu. Melewati bagian ini ibarat mencoba belajar menyetir mobil tanpa tahu apa itu mesin atau bahan bakar — Anda mungkin bisa mengikuti instruksi, tetapi tidak akan benar-benar mengerti mengapa sesuatu bekerja. Kuasai tiga konsep berikut, dan Kubernetes akan terasa jauh lebih logis dan mudah dipelajari.
Apa Itu Container dan Docker?
Container adalah unit perangkat lunak yang membungkus kode aplikasi beserta semua dependensinya — library, runtime, konfigurasi, dan file sistem — ke dalam satu paket yang terisolasi dan portabel. Dengan container, aplikasi yang berjalan di laptop developer akan berperilaku identik saat dideploy ke server produksi, menghilangkan masalah klasik "works on my machine" yang selama ini menjadi momok tim engineering.
Docker adalah platform paling populer untuk membuat dan
menjalankan container. Docker menyederhanakan proses containerisasi aplikasi
melalui sebuah file konfigurasi bernama Dockerfile,
yang berisi instruksi langkah demi langkah tentang cara membangun image
container Anda. Dari image tersebut, Anda bisa menjalankan satu atau banyak
container sekaligus di mesin mana pun yang memiliki Docker terinstal.
Cara mudah memahami hubungan keduanya:
- Dockerfile → Resep masakan: instruksi tertulis tentang cara membuat sesuatu.
- Docker Image → Cetakan kue: hasil jadi dari resep yang bisa digunakan berkali-kali.
- Docker Container → Kue yang sudah dipanggang: instance nyata yang sedang berjalan dan bisa langsung 'dimakan' (digunakan).
- Docker Hub / Registry → Toko resep online: tempat menyimpan dan berbagi image container dengan tim atau publik.
Kubernetes sendiri tidak terikat hanya pada Docker — ia mendukung berbagai container runtime seperti containerd dan CRI-O. Namun karena Docker adalah yang paling umum digunakan, memahami Docker adalah langkah pertama yang tepat sebelum masuk ke Kubernetes.
Perbedaan Container vs Virtual Machine (VM)
Pertanyaan ini hampir selalu muncul saat seseorang pertama kali berkenalan dengan container. Keduanya sama-sama menyediakan isolasi lingkungan untuk menjalankan aplikasi — tetapi cara kerjanya sangat berbeda, dan perbedaan inilah yang membuat container jauh lebih ringan dan cepat dibandingkan VM.
Virtual Machine (VM) bekerja dengan cara mengemulasi keseluruhan hardware komputer. Setiap VM membawa salinan penuh sistem operasi (OS) sendiri — lengkap dengan kernel, driver, dan semua komponen OS — di atas sebuah lapisan software bernama hypervisor. Akibatnya, setiap VM membutuhkan beberapa gigabyte ruang disk dan memakan waktu menit untuk dinyalakan.
Container mengambil pendekatan yang jauh lebih efisien. Alih-alih membawa OS sendiri, container berbagi kernel OS dari host machine, dan hanya membungkus lapisan aplikasi beserta dependensinya. Hasilnya:
- Ukuran lebih kecil: Image container umumnya hanya puluhan hingga ratusan MB, dibandingkan VM yang bisa mencapai beberapa GB.
- Startup jauh lebih cepat: Container bisa aktif dalam hitungan detik atau bahkan milidetik, sementara VM memerlukan waktu boot yang lebih lama.
- Lebih hemat resource: Satu server fisik bisa menjalankan puluhan hingga ratusan container secara bersamaan, jauh lebih efisien dibanding VM.
- Portabilitas tinggi: Container berjalan konsisten di mana saja — laptop, server bare metal, hingga cloud — selama ada container runtime yang kompatibel.
- Isolasi tetap terjaga: Meskipun berbagi kernel, setiap container memiliki filesystem, jaringan, dan proses yang terisolasi satu sama lain.
Penting untuk dicatat: container dan VM bukan teknologi yang saling menggantikan. Di dunia nyata, keduanya sering digunakan bersama — container berjalan di dalam VM untuk mendapatkan keunggulan isolasi hardware dari VM sekaligus efisiensi dan kecepatan dari container. Justru inilah yang terjadi di hampir semua layanan cloud managed Kubernetes seperti GKE, EKS, dan AKS.
Apa Itu Container Orchestration?
Menjalankan satu atau dua container secara manual di laptop adalah hal yang mudah. Tapi bagaimana jika aplikasi Anda terdiri dari 50 microservice, masing-masing membutuhkan beberapa instance, tersebar di 20 server, dan harus selalu online tanpa gangguan? Di sinilah container orchestration menjadi tidak tergantikan.
Container orchestration adalah proses mengotomatiskan deployment, manajemen, scaling, jaringan, dan ketersediaan container dalam skala besar. Anggap saja seperti seorang konduktor orkestra yang memastikan setiap musisi (container) memainkan nada yang tepat, pada waktu yang tepat, dengan harmoni yang sempurna — tanpa konduktor harus menyentuh setiap instrumen satu per satu.
Secara konkret, sebuah sistem container orchestration bertanggung jawab atas:
- Scheduling: Menentukan di server mana sebuah container akan dijalankan berdasarkan ketersediaan resource, kebijakan affinity, dan constraint lainnya.
- Load balancing: Mendistribusikan traffic secara merata ke semua instance container yang sehat agar tidak ada satu pun yang kelebihan beban.
- Self-healing: Mendeteksi container yang gagal dan secara otomatis me-restart, mengganti, atau memindahkannya ke node lain tanpa intervensi manual.
- Automated rollouts & rollbacks: Mendeploy versi baru aplikasi secara bertahap dan otomatis membatalkan update jika terdeteksi ada masalah.
- Secret & configuration management: Menyimpan dan mendistribusikan konfigurasi sensitif seperti API key dan password ke container yang membutuhkan.
- Storage orchestration: Secara otomatis me-mount sistem penyimpanan yang diperlukan — baik dari penyimpanan lokal maupun cloud — ke container yang tepat.
Meskipun ada beberapa solusi container orchestration lain seperti Docker Swarm dan Apache Mesos, Kubernetes telah memenangkan persaingan ini secara telak. Dengan ekosistem yang sangat matang, komunitas yang besar, dan dukungan dari semua cloud provider utama, Kubernetes adalah pilihan standar industri yang hampir tidak terbantahkan untuk kebutuhan container orchestration di skala produksi saat ini.
Arsitektur dan Cara Kerja Kubernetes
Memahami arsitektur Kubernetes adalah kunci untuk bisa menggunakannya secara efektif — bukan sekadar mengikuti tutorial tanpa tahu apa yang terjadi di balik layar. Kubernetes dibangun dari komponen-komponen yang bekerja secara terkoordinasi, masing-masing memiliki tanggung jawab yang spesifik dan terdefinisi dengan baik. Begitu Anda memahami "siapa mengerjakan apa", segala sesuatunya akan terasa jauh lebih masuk akal.
Gambaran Umum Arsitektur Kubernetes
Sebuah cluster Kubernetes terdiri dari dua jenis mesin utama yang bekerja bersama: Control Plane (dulu disebut Master Node) dan satu atau lebih Worker Node. Analoginya seperti sebuah perusahaan logistik — Control Plane adalah kantor pusat yang merencanakan dan mengoordinasikan semua pekerjaan, sementara Worker Node adalah gudang dan kurir yang benar-benar mengeksekusi pengiriman di lapangan.
Alur kerja dasarnya berjalan seperti ini:
- Developer atau sistem CI/CD mengirim instruksi ke cluster melalui kubectl atau API — misalnya 'jalankan 3 instance aplikasi ini'.
- Control Plane menerima instruksi, mencatat desired state ke dalam database terdistribusi (etcd), lalu memutuskan di Worker Node mana container akan ditempatkan.
- Worker Node menerima perintah, menarik image container dari registry, dan menjalankan container sesuai spesifikasi yang diberikan.
- Control Plane terus memantau kondisi cluster secara berkala. Jika realita tidak sesuai desired state — misalnya ada container yang crash — ia akan mengambil tindakan korektif secara otomatis.
Komponen Control Plane (Master Node)
Control Plane adalah otak dari seluruh cluster Kubernetes. Ia bertanggung jawab atas semua keputusan global — mulai dari penjadwalan workload, deteksi kegagalan, hingga respons terhadap perubahan yang terjadi di cluster. Control Plane terdiri dari empat komponen utama yang masing-masing memiliki peran tersendiri.
🔌 API Server (kube-apiserver)
API Server adalah pintu masuk utama ke seluruh cluster Kubernetes.
Semua komunikasi — baik dari kubectl,
dashboard UI, sistem CI/CD, maupun komponen internal Kubernetes sendiri —
harus melewati API Server. Ia mengekspos Kubernetes API berbasis REST,
memvalidasi setiap request, menerapkan kebijakan autentikasi dan otorisasi,
lalu meneruskan instruksi yang valid ke komponen lain. Anggap API Server
sebagai resepsionis sekaligus security gate yang mengontrol seluruh akses
ke markas besar.
🗄️ etcd
etcd adalah database key-value terdistribusi yang menjadi satu-satunya sumber kebenaran (single source of truth) untuk seluruh state cluster Kubernetes. Semua informasi tentang node, pod, config, secret, dan desired state tersimpan di sini. Jika etcd hilang atau rusak tanpa backup, seluruh cluster kehilangan memorinya. Itulah mengapa dalam environment produksi, etcd selalu dijalankan dalam konfigurasi highly available dengan minimal tiga instance untuk toleransi kegagalan.
📅 Scheduler (kube-scheduler)
Scheduler bertugas menjawab satu pertanyaan krusial setiap kali ada pod baru yang perlu dijalankan: "Di Worker Node mana pod ini paling tepat ditempatkan?" Keputusannya tidak sembarangan — Scheduler mempertimbangkan berbagai faktor secara bersamaan:
- Ketersediaan resource: node mana yang memiliki cukup CPU dan memori untuk menjalankan pod.
- Kebijakan affinity & anti-affinity: apakah pod harus ditempatkan berdekatan atau justru dipisah dari pod lain.
- Taints & tolerations: apakah node memiliki 'larangan' tertentu yang harus dihormati oleh pod.
- Data locality: menempatkan pod sedekat mungkin dengan data yang dibutuhkan untuk meminimalkan latency.
🔄 Controller Manager (kube-controller-manager)
Controller Manager menjalankan sekumpulan controller — proses-proses latar belakang yang terus-menerus memantau state cluster dan mengambil tindakan korektif agar kondisi aktual selalu sesuai dengan desired state yang didefinisikan. Beberapa controller penting yang berjalan di dalamnya:
- Node Controller: mendeteksi dan merespons ketika sebuah node berhenti merespons.
- Replication Controller: memastikan jumlah pod yang berjalan selalu sesuai dengan jumlah yang diminta.
- Endpoints Controller: mengelola daftar endpoint untuk setiap Service agar selalu up-to-date.
- Service Account Controller: membuat akun dan token default untuk namespace baru secara otomatis.
Komponen Worker Node
Worker Node adalah mesin-mesin yang benar-benar menjalankan beban kerja aplikasi Anda. Setiap Worker Node dikelola oleh Control Plane dan menjalankan tiga komponen utama yang memungkinkan container berjalan dan berkomunikasi dengan baik.
🤖 Kubelet
Kubelet adalah agen utama Kubernetes yang berjalan di setiap Worker Node. Ia adalah "eksekutor lapangan" yang menerima instruksi dari Control Plane dan memastikan container-container yang seharusnya berjalan di node tersebut memang benar-benar berjalan dalam kondisi sehat. Kubelet secara rutin melaporkan status node dan pod kembali ke API Server, sehingga Control Plane selalu memiliki gambaran terkini tentang kondisi cluster.
🌐 Kube-proxy
Kube-proxy adalah komponen jaringan yang berjalan di setiap node dan bertanggung jawab atas routing traffic di dalam cluster. Ia memelihara aturan jaringan yang memungkinkan komunikasi ke pod dari dalam maupun luar cluster. Saat Anda mengakses sebuah Service Kubernetes, kube-proxy-lah yang bekerja di balik layar untuk memastikan request Anda sampai ke pod yang tepat — termasuk melakukan load balancing jika ada lebih dari satu pod yang melayani Service tersebut.
📦 Container Runtime
Container Runtime adalah software yang bertanggung jawab untuk benar-benar menjalankan container di level sistem operasi. Kubernetes berkomunikasi dengan container runtime melalui antarmuka standar bernama CRI (Container Runtime Interface), yang memungkinkan fleksibilitas dalam pemilihan runtime. Container runtime yang umum digunakan bersama Kubernetes antara lain:
- containerd: runtime ringan yang menjadi default di sebagian besar distribusi Kubernetes modern, termasuk yang digunakan oleh GKE, EKS, dan AKS.
- CRI-O: runtime minimalis yang dirancang khusus untuk Kubernetes, populer di environment OpenShift.
- Docker Engine: meskipun dukungan langsung (dockershim) telah dihapus sejak Kubernetes v1.24, Docker masih bisa digunakan melalui containerd yang ada di bawahnya.
Bagaimana Kubernetes Mengelola Beban Kerja Secara Otomatis?
Salah satu keajaiban Kubernetes adalah konsep declarative configuration dan reconciliation loop. Alih-alih memberi tahu Kubernetes bagaimana cara melakukan sesuatu (imperatif), Anda cukup mendefinisikan apa yang Anda inginkan (deklaratif) — dan Kubernetes akan terus bekerja tanpa henti untuk mewujudkan serta mempertahankan kondisi tersebut.
Prinsip ini dikenal sebagai control loop atau reconciliation loop. Cara kerjanya sederhana namun sangat powerful:
- Observe — Kubernetes terus-menerus mengamati current state cluster: berapa pod yang sedang berjalan, resource apa yang terpakai, node mana yang sehat.
- Diff — Kubernetes membandingkan current state dengan desired state yang Anda definisikan. Apakah ada perbedaan? Apakah ada pod yang kurang atau node yang bermasalah?
- Act — Jika ada perbedaan, Kubernetes segera mengambil tindakan untuk menutup gap tersebut: membuat pod baru, me-restart container yang crash, atau memindahkan workload dari node yang gagal.
- Repeat — Siklus ini berjalan terus-menerus, setiap saat, tanpa henti — memastikan cluster Anda selalu dalam kondisi yang Anda inginkan.
Inilah yang membuat Kubernetes terasa seperti infrastruktur yang "hidup" dan cerdas. Anda tidak perlu lagi memantau server secara manual di tengah malam — cukup definisikan desired state sekali dalam file YAML, dan Kubernetes akan menjaga agar aplikasi Anda tetap berjalan sesuai spesifikasi tersebut, kapan pun dan dalam kondisi apa pun.
Objek-Objek Utama dalam Kubernetes
Kubernetes menggunakan konsep objek sebagai cara untuk merepresentasikan state dari cluster Anda. Setiap objek adalah sebuah "rekaman niat" — deklarasi tertulis tentang apa yang Anda inginkan ada dan berjalan di dalam cluster. Memahami objek-objek ini adalah seperti mempelajari kosakata dasar sebuah bahasa baru: begitu Anda fasih, Anda bisa mengekspresikan hampir semua kebutuhan infrastruktur hanya dengan menulis file YAML.
Pod — Unit Terkecil di Kubernetes
Pod adalah unit deployable terkecil yang bisa dibuat dan
dikelola di Kubernetes. Sebuah Pod membungkus satu atau lebih container yang
berbagi jaringan, storage, dan spesifikasi yang sama — mereka selalu
dijadwalkan bersama di node yang sama dan berkomunikasi satu sama lain
melalui localhost.
Analogi terbaik untuk Pod adalah sebuah apartemen: container-container di dalamnya adalah penghuni yang berbagi alamat yang sama (IP address), koneksi internet (network namespace), dan ruang penyimpanan bersama (volumes). Meski satu Pod bisa berisi beberapa container, praktik terbaiknya adalah satu container utama per Pod — container tambahan biasanya berperan sebagai sidecar yang mendukung container utama, seperti log collector atau proxy.
Beberapa hal penting yang perlu dipahami tentang Pod:
- Pod bersifat ephemeral (sementara): Pod tidak dirancang untuk bertahan selamanya. Jika sebuah Pod mati, Kubernetes tidak akan menghidupkannya kembali — melainkan membuat Pod baru sebagai penggantinya.
- Setiap Pod mendapat IP address unik di dalam cluster, memungkinkan komunikasi antar Pod tanpa konfigurasi NAT.
- Pod jarang dibuat secara langsung dalam praktik nyata — biasanya dikelola oleh objek higher-level seperti Deployment atau StatefulSet.
- Pod mendukung health check melalui liveness probe dan readiness probe untuk memastikan container benar-benar siap melayani traffic.
Deployment — Mengatur Replikasi dan Update Aplikasi
Deployment adalah objek Kubernetes yang paling sering Anda gunakan sehari-hari. Ia bertindak sebagai manajer untuk Pod — mendefinisikan berapa banyak replika Pod yang harus berjalan, container image apa yang digunakan, dan bagaimana cara melakukan update saat ada versi baru. Deployment-lah yang memberi Kubernetes kemampuan untuk menjaga aplikasi Anda tetap berjalan meskipun ada Pod yang mati.
Di balik layar, Deployment mengelola sebuah objek bernama ReplicaSet yang bertugas memastikan jumlah Pod yang berjalan
selalu sesuai dengan angka yang Anda tentukan. Jika satu Pod crash,
ReplicaSet langsung membuat Pod pengganti. Jika Anda ingin scale up,
cukup ubah angka replicas
dan Kubernetes akan menangani sisanya.
Kemampuan utama yang diberikan Deployment kepada aplikasi Anda:
- Rolling update: memperbarui Pod secara bertahap satu per satu, memastikan selalu ada instance yang melayani traffic selama proses update berlangsung.
- Instant rollback: jika update bermasalah, satu perintah kubectl rollout undo cukup untuk mengembalikan ke versi sebelumnya dalam hitungan detik.
- Scaling deklaratif: tambah atau kurangi jumlah replika kapan saja hanya dengan mengubah satu angka di file YAML atau melalui perintah kubectl scale.
- Pause & resume rollout: Anda bisa menghentikan proses update di tengah jalan untuk observasi, lalu melanjutkannya kembali saat yakin semuanya berjalan baik.
Service — Menghubungkan Pod ke Dunia Luar
Pod bersifat ephemeral — mereka lahir dan mati, dan setiap kali Pod baru dibuat, ia mendapat IP address yang berbeda. Lalu bagaimana aplikasi lain atau pengguna bisa mengaksesnya secara konsisten jika alamatnya terus berubah? Jawabannya adalah Service.
Service menyediakan endpoint jaringan yang stabil untuk sekumpulan Pod. Ia bertindak seperti resepsionis virtual yang selalu berada di alamat yang sama, menerima semua request masuk, dan meneruskannya ke Pod yang sedang aktif — terlepas dari berapa banyak Pod yang ada atau berapa kali Pod tersebut diganti. Service menggunakan label selector untuk menemukan Pod yang menjadi targetnya secara dinamis.
Terdapat empat tipe Service yang perlu Anda ketahui:
- ClusterIP (default): mengekspos Service hanya di dalam cluster dengan IP internal. Cocok untuk komunikasi antar microservice yang tidak perlu diakses dari luar.
- NodePort: mengekspos Service melalui port statis di setiap node (range 30000–32767), memungkinkan akses dari luar cluster langsung ke IP node. Umumnya digunakan untuk development atau testing.
- LoadBalancer: membuat external load balancer di cloud provider (AWS ELB, GCP Load Balancer, dll.) yang meneruskan traffic ke Service. Ini adalah cara paling umum untuk mengekspos aplikasi ke internet di environment cloud.
- ExternalName: memetakan Service ke nama DNS eksternal, berguna untuk mengintegrasikan layanan di luar cluster ke dalam jaringan internal Kubernetes.
Namespace — Memisahkan Lingkungan Kerja
Namespace adalah mekanisme Kubernetes untuk membagi satu cluster fisik menjadi beberapa cluster virtual yang terisolasi satu sama lain. Bayangkan sebuah gedung perkantoran besar yang dibagi menjadi beberapa lantai — setiap tim menempati lantainya sendiri, memiliki ruang kerja yang terpisah, namun tetap berbagi infrastruktur gedung yang sama seperti listrik dan lift.
Namespace sangat berguna untuk memisahkan environment dalam satu cluster yang sama. Kubernetes sendiri hadir dengan empat namespace bawaan:
- default: namespace tempat semua resource dibuat jika Anda tidak menentukan namespace secara eksplisit.
- kube-system: namespace untuk komponen internal Kubernetes seperti CoreDNS, kube-proxy, dan metrics-server.
- kube-public: namespace yang bisa dibaca oleh semua user, termasuk yang tidak terautentikasi. Jarang digunakan secara langsung.
- kube-node-lease: menyimpan objek Lease yang digunakan untuk heartbeat node, membantu Control Plane mendeteksi kegagalan node lebih cepat.
Dalam praktik nyata, tim biasanya membuat namespace seperti development, staging, dan production
untuk memisahkan environment, atau membuat namespace per tim seperti team-backend dan team-frontend.
Namespace juga menjadi unit untuk menerapkan Resource Quota
dan RBAC (Role-Based Access Control) — membatasi berapa
banyak CPU dan memori yang bisa digunakan suatu tim, serta siapa saja yang
boleh mengakses resource di dalamnya.
ConfigMap & Secret — Mengelola Konfigurasi dan Data Sensitif
Salah satu prinsip terpenting dalam pengembangan aplikasi modern adalah memisahkan konfigurasi dari kode. Jangan pernah hardcode URL database, API key, atau password langsung di dalam image container — karena setiap perubahan konfigurasi akan memaksa Anda membangun ulang image, dan data sensitif bisa bocor ke version control. Kubernetes menyediakan dua objek khusus untuk menangani hal ini.
📋 ConfigMap
ConfigMap menyimpan data konfigurasi non-sensitif dalam format key-value. Data di dalamnya bisa diinjeksikan ke Pod sebagai environment variable, argumen command-line, atau file konfigurasi yang di-mount ke dalam filesystem container. Contoh penggunaan yang umum antara lain menyimpan URL endpoint API, nama database, konfigurasi feature flag, atau pengaturan log level aplikasi.
🔐 Secret
Secret secara konsep mirip dengan ConfigMap, namun dirancang khusus untuk menyimpan data sensitif seperti password, token OAuth, SSH key, dan TLS certificate. Data dalam Secret disimpan dalam format base64-encoded dan bisa dienkripsi saat istirahat (at rest) menggunakan enkripsi etcd. Beberapa hal penting seputar Secret yang perlu Anda perhatikan:
- Base64 bukan enkripsi: encoding base64 hanya menyamarkan data, bukan mengamankannya. Untuk keamanan nyata, aktifkan enkripsi at-rest pada etcd atau gunakan solusi eksternal seperti HashiCorp Vault.
- Secret di-mount ke Pod sebagai volume atau environment variable, sehingga nilainya tidak pernah hardcode di dalam image container.
- Akses ke Secret dikontrol ketat melalui RBAC — hanya Pod atau user yang memiliki izin eksplisit yang bisa membaca isinya.
- Gunakan tools seperti Sealed Secrets atau External Secrets Operator untuk menyimpan Secret dengan aman di Git tanpa mengekspos nilainya.
Ingress — Mengatur Lalu Lintas HTTP/HTTPS
Jika Service bertipe LoadBalancer membuat satu load balancer per Service — yang bisa sangat mahal di cloud jika Anda memiliki banyak aplikasi — maka Ingress hadir sebagai solusi yang jauh lebih efisien. Ingress adalah objek yang mendefinisikan aturan routing HTTP/HTTPS dari dunia luar ke Service-Service di dalam cluster, semua melalui satu entry point.
Bayangkan Ingress sebagai resepsionis gedung bertingkat: semua tamu masuk melalui satu pintu utama, lalu diarahkan ke lantai (Service) yang tepat berdasarkan tujuan mereka. Dengan Ingress, Anda bisa:
- Host-based routing: mengarahkan traffic berdasarkan domain — api.contoh.com ke Service backend, www.contoh.com ke Service frontend, semua dari satu IP publik.
- Path-based routing: mengarahkan traffic berdasarkan path URL — /api ke Service backend, /static ke Service CDN, /auth ke Service autentikasi.
- TLS termination: mengelola SSL/TLS certificate secara terpusat di Ingress, sehingga Service di belakangnya bisa berkomunikasi dengan HTTP biasa tanpa beban enkripsi.
- Rewrite & redirect rules: memodifikasi URL sebelum diteruskan ke Service, berguna untuk migrasi path tanpa mengubah kode aplikasi.
Ingress membutuhkan sebuah Ingress Controller untuk bisa berfungsi — Kubernetes tidak menyertakan Ingress Controller secara default. Pilihan yang paling populer adalah NGINX Ingress Controller untuk penggunaan umum, dan Traefik untuk yang menginginkan fitur lebih kaya dan konfigurasi dinamis. Di layanan cloud managed, biasanya tersedia Ingress Controller bawaan yang terintegrasi dengan load balancer cloud masing-masing.
Persiapan Sebelum Memulai Tutorial Kubernetes
Sebelum menulis satu baris konfigurasi pun, pastikan lingkungan kerja Anda sudah siap. Melewati tahap persiapan ini dengan tergesa-gesa adalah penyebab nomor satu frustasi bagi pemula — mereka menghabiskan berjam-jam men-debug masalah yang sebenarnya berakar dari instalasi yang tidak sempurna. Ikuti panduan ini dengan teliti, dan Anda akan memiliki fondasi yang solid untuk memulai perjalanan Kubernetes Anda.
Kebutuhan Sistem dan Tools yang Diperlukan
Kubernetes dirancang untuk berjalan di berbagai platform — mulai dari laptop developer hingga cluster cloud berskala enterprise. Untuk keperluan belajar dan development lokal, spesifikasi berikut sudah lebih dari cukup untuk menjalankan cluster Kubernetes single-node di mesin Anda sendiri.
💻 Spesifikasi Hardware Minimum
- CPU: minimal 2 core (4 core direkomendasikan untuk pengalaman yang lebih lancar saat menjalankan beberapa Pod sekaligus).
- RAM: minimal 4 GB (8 GB sangat direkomendasikan — Kubernetes dan komponennya sendiri membutuhkan sekitar 2 GB hanya untuk berjalan).
- Disk: minimal 20 GB ruang kosong untuk menyimpan image container dan data cluster.
- Koneksi internet: diperlukan untuk mengunduh image container dari registry seperti Docker Hub atau Google Container Registry.
🖥️ Sistem Operasi yang Didukung
- Linux (Ubuntu 20.04/22.04, Debian, Fedora, CentOS): pilihan terbaik dan paling native. Semua tools berjalan optimal di Linux.
- macOS (10.15 Catalina atau lebih baru): didukung penuh oleh Minikube dan Docker Desktop. Perlu sedikit penyesuaian karena macOS tidak mendukung Linux containers secara native.
- Windows 10/11 (dengan WSL2 aktif): bisa digunakan dengan baik menggunakan WSL2 (Windows Subsystem for Linux 2). Pastikan WSL2 sudah terinstal dan dikonfigurasi sebelum memulai.
🛠️ Tools Wajib yang Perlu Diinstal
- kubectl: CLI resmi Kubernetes untuk berinteraksi dengan cluster. Ini adalah tool utama yang akan Anda gunakan setiap hari.
- Docker Desktop atau Docker Engine: diperlukan sebagai container runtime untuk menjalankan container di mesin lokal.
- Minikube, Kind, atau k3s: salah satu dari ketiganya dibutuhkan untuk menjalankan cluster Kubernetes lokal di laptop Anda.
- Text editor dengan YAML support: VS Code dengan ekstensi Kubernetes sangat direkomendasikan karena menyediakan syntax highlighting, autocompletion, dan validasi YAML secara real-time.
Instalasi kubectl — CLI Resmi Kubernetes
kubectl (dibaca: kube-control atau kube-cuddle, keduanya diterima di komunitas) adalah command-line interface resmi untuk berkomunikasi dengan cluster Kubernetes melalui API Server. Hampir semua operasi Kubernetes — dari melihat status Pod hingga mendeploy aplikasi baru — dilakukan melalui kubectl. Menguasai kubectl adalah investasi keterampilan yang sangat berharga.
🐧 Instalasi di Linux (Ubuntu/Debian)
# Download binary kubectl versi terbaru
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
# Berikan permission eksekusi
chmod +x kubectl
# Pindahkan ke direktori PATH
sudo mv kubectl /usr/local/bin/
# Verifikasi instalasi
kubectl version --client
🍎 Instalasi di macOS (via Homebrew)
# Install menggunakan Homebrew
brew install kubectl
# Verifikasi instalasi
kubectl version --client
🪟 Instalasi di Windows (via Chocolatey)
# Install menggunakan Chocolatey (jalankan sebagai Administrator)
choco install kubernetes-cli
# Verifikasi instalasi
kubectl version --client
Setelah instalasi, konfigurasikan kubectl autocompletion
di shell Anda — fitur ini akan menghemat banyak waktu mengetik karena
kubectl memiliki banyak perintah dan flag yang panjang. Tambahkan baris
berikut ke file ~/.bashrc
atau ~/.zshrc:
# Untuk bash
echo 'source <(kubectl completion bash)' >> ~/.bashrc
# Untuk zsh
echo 'source <(kubectl completion zsh)' >> ~/.zshrc
# Alias populer yang digunakan komunitas Kubernetes
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -o default -F __start_kubectl k' >> ~/.bashrc
Instalasi Minikube untuk Kubernetes Lokal
Minikube adalah tool resmi dari komunitas Kubernetes yang menjalankan cluster Kubernetes single-node di dalam sebuah virtual machine atau container di laptop Anda. Minikube adalah pilihan paling direkomendasikan untuk pemula karena dokumentasinya lengkap, perintahnya intuitif, dan dilengkapi dengan add-on bawaan seperti dashboard UI, metrics-server, dan Ingress controller yang bisa diaktifkan hanya dengan satu perintah.
🐧 Instalasi di Linux
# Download binary Minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
# Install ke sistem
sudo install minikube-linux-amd64 /usr/local/bin/minikube
# Mulai cluster Kubernetes lokal
minikube start
# Verifikasi cluster berjalan
kubectl get nodes
🍎 Instalasi di macOS
# Install via Homebrew
brew install minikube
# Mulai cluster (menggunakan Docker sebagai driver)
minikube start --driver=docker
# Aktifkan Ingress add-on (opsional tapi berguna)
minikube addons enable ingress
# Buka Kubernetes Dashboard di browser
minikube dashboard
Beberapa perintah Minikube yang akan sering Anda gunakan selama belajar:
- minikube start: menghidupkan cluster. Tambahkan flag --cpus=4 --memory=8192 untuk mengalokasikan lebih banyak resource.
- minikube stop: menghentikan cluster tanpa menghapus data — bisa dilanjutkan lagi kapan saja.
- minikube delete: menghapus cluster sepenuhnya beserta semua datanya. Berguna untuk memulai dari awal dengan konfigurasi bersih.
- minikube status: mengecek status semua komponen cluster apakah berjalan dengan normal.
- minikube tunnel: membuat tunnel jaringan untuk mengekspos Service bertipe LoadBalancer ke localhost saat development.
Alternatif Lain: Kind, k3s, dan Docker Desktop
Minikube bukan satu-satunya cara menjalankan Kubernetes secara lokal. Tergantung kebutuhan dan preferensi Anda, ada beberapa alternatif yang masing-masing memiliki keunggulan tersendiri. Berikut perbandingan singkat keempat opsi yang tersedia:
🐳 Kind (Kubernetes IN Docker)
Kind menjalankan node-node Kubernetes sebagai container Docker, bukan sebagai VM. Ini membuatnya sangat ringan, cepat dinyalakan, dan ideal untuk pengujian otomatis di pipeline CI/CD. Kind juga mendukung multi-node cluster yang bisa mensimulasikan environment produksi lebih realistis dibanding Minikube.
# Install Kind
brew install kind # macOS
# atau
go install sigs.k8s.io/kind@latest # via Go
# Buat cluster baru
kind create cluster --name belajar-k8s
# Buat multi-node cluster dengan config file
kind create cluster --config kind-config.yaml
⚡ k3s — Kubernetes Ultra-Ringan
k3s adalah distribusi Kubernetes yang sangat ringan dari Rancher Labs, dirancang untuk lingkungan dengan resource terbatas seperti Raspberry Pi, edge computing, atau server dengan RAM minimal. Dengan ukuran binary hanya sekitar 100 MB dan kebutuhan RAM mulai dari 512 MB, k3s adalah pilihan terbaik jika Anda ingin belajar Kubernetes di hardware lama atau VPS murah.
# Install k3s dengan satu perintah (Linux)
curl -sfL https://get.k3s.io | sh -
# Cek status cluster
sudo k3s kubectl get nodes
# Gunakan kubectl biasa dengan kubeconfig k3s
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes
🖥️ Docker Desktop — Solusi All-in-One
Jika Anda sudah menggunakan Docker Desktop di macOS atau Windows, Kubernetes bisa diaktifkan langsung dari menu Settings tanpa instalasi tambahan apa pun. Cukup buka Docker Desktop → Settings → Kubernetes → Enable Kubernetes, tunggu beberapa menit, dan cluster siap digunakan. Ini adalah opsi paling mudah bagi pemula yang sudah familiar dengan Docker Desktop.
- Minikube → Terbaik untuk pemula: dokumentasi lengkap, add-on mudah diaktifkan, dashboard bawaan.
- Kind → Terbaik untuk CI/CD dan testing otomatis: ringan, cepat, mendukung multi-node.
- k3s → Terbaik untuk hardware terbatas atau edge: paling ringan, binary tunggal, production-ready.
- Docker Desktop → Terbaik untuk pengguna macOS/Windows yang sudah pakai Docker: zero configuration, langsung aktif.
Tidak ada pilihan yang salah di antara keempatnya — semua menggunakan Kubernetes yang sama dan kompatibel penuh dengan kubectl. Untuk keperluan tutorial di artikel ini, kami akan menggunakan Minikube sebagai referensi utama karena kemudahan penggunaannya dan dokumentasi yang paling ramah pemula. Namun semua perintah dan konfigurasi YAML yang akan kita gunakan berjalan identik di keempat platform tersebut.
Tutorial Kubernetes untuk Pemula (Step-by-Step)
Teori sudah cukup — sekarang saatnya tangan Anda menyentuh keyboard dan merasakan sendiri bagaimana Kubernetes bekerja. Tutorial ini dirancang secara progresif: setiap langkah membangun di atas langkah sebelumnya, sehingga di akhir section ini Anda akan memiliki aplikasi yang berjalan penuh di atas cluster Kubernetes lokal — lengkap dengan replikasi, auto-recovery, dan akses dari browser. Pastikan Minikube sudah berjalan sebelum memulai.
Langkah 1 — Menjalankan Cluster Kubernetes Pertama Kali
Langkah pertama adalah memastikan cluster Minikube Anda berjalan dan kubectl dapat berkomunikasi dengannya dengan baik. Jalankan perintah berikut satu per satu dan perhatikan outputnya.
# Mulai cluster Minikube dengan resource yang cukup
minikube start --cpus=2 --memory=4096 --driver=docker
# Verifikasi cluster berjalan normal
minikube status
# Output yang diharapkan:
# minikube
# type: Control Plane
# host: Running
# kubelet: Running
# apiserver: Running
# kubeconfig: Configured
Setelah cluster berjalan, verifikasi bahwa kubectl sudah terhubung ke cluster yang benar dan node dalam kondisi sehat:
# Cek node yang tersedia di cluster
kubectl get nodes
# Output yang diharapkan:
# NAME STATUS ROLES AGE VERSION
# minikube Ready control-plane 1m v1.28.0
# Lihat informasi detail cluster
kubectl cluster-info
# Lihat semua namespace yang ada secara default
kubectl get namespaces
Jika status node menampilkan Ready,
selamat — cluster Kubernetes pertama Anda sudah berjalan! Jika statusnya NotReady,
tunggu beberapa menit dan jalankan perintah yang sama — Kubernetes
membutuhkan waktu untuk menginisialisasi semua komponennya saat pertama
kali dinyalakan.
Langkah 2 — Membuat dan Menjalankan Pod Pertama
Sebelum menggunakan Deployment, mari berkenalan langsung dengan Pod — unit terkecil Kubernetes. Kita akan membuat Pod yang menjalankan server web Nginx sederhana menggunakan dua cara: secara imperatif (perintah langsung) dan deklaratif (file YAML).
Cara Imperatif (Cepat untuk Testing)
# Buat Pod langsung dari command line
kubectl run pod-pertama --image=nginx:latest --port=80
# Pantau status Pod hingga Running
kubectl get pods --watch
# Output yang diharapkan setelah beberapa detik:
# NAME READY STATUS RESTARTS AGE
# pod-pertama 1/1 Running 0 30s
# Lihat detail lengkap Pod termasuk events
kubectl describe pod pod-pertama
# Akses shell di dalam container Pod
kubectl exec -it pod-pertama -- /bin/bash
# Dari dalam container, cek Nginx berjalan
curl localhost
exit
Cara Deklaratif (Best Practice — Pakai File YAML)
Buat file bernama pod-pertama.yaml
dengan konten berikut:
apiVersion: v1
kind: Pod
metadata:
name: pod-nginx
labels:
app: nginx
environment: belajar
spec:
containers:
- name: nginx-container
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "200m"
# Terapkan file YAML ke cluster
kubectl apply -f pod-pertama.yaml
# Verifikasi Pod berjalan
kubectl get pods -o wide
# Hapus Pod saat sudah selesai bereksperimen
kubectl delete pod pod-nginx
Perhatikan field resources.requests
dan resources.limits
di YAML di atas. Ini adalah best practice yang wajib diterapkan di
environment produksi — tanpa batas resource, sebuah container yang
bermasalah bisa menghabiskan seluruh CPU dan memori node, membuat
Pod lain ikut crash.
Langkah 3 — Membuat Deployment dengan File YAML
Di dunia nyata, Anda hampir tidak pernah membuat Pod secara langsung.
Selalu gunakan Deployment agar aplikasi Anda mendapat
kemampuan self-healing dan rolling update secara otomatis. Buat file
bernama deployment-nginx.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3 # Jalankan 3 instance sekaligus
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "100m"
limits:
memory: "128Mi"
cpu: "200m"
livenessProbe: # Restart container jika tidak sehat
httpGet:
path: /
port: 80
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe: # Kirim traffic hanya jika container siap
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
# Deploy ke cluster
kubectl apply -f deployment-nginx.yaml
# Pantau proses pembuatan Pod
kubectl get pods -l app=nginx --watch
# Lihat detail Deployment
kubectl describe deployment nginx-deployment
# Lihat ReplicaSet yang dibuat otomatis oleh Deployment
kubectl get replicasets
Sekarang coba buktikan sendiri kemampuan self-healing Kubernetes — hapus salah satu Pod secara paksa dan amati apa yang terjadi:
# Catat nama salah satu Pod
kubectl get pods -l app=nginx
# Hapus Pod tersebut secara paksa
kubectl delete pod <nama-pod-anda>
# Amati — dalam hitungan detik Pod baru langsung dibuat!
kubectl get pods -l app=nginx --watch
# Kubernetes memastikan jumlah Pod selalu 3 sesuai desired state
Langkah 4 — Melakukan Scaling Aplikasi
Salah satu kekuatan terbesar Kubernetes adalah kemampuan scaling yang instan. Anda bisa menambah atau mengurangi jumlah replika kapan saja tanpa downtime — baik secara imperatif maupun dengan mengubah file YAML.
# Scale up ke 5 replika secara imperatif
kubectl scale deployment nginx-deployment --replicas=5
# Pantau Pod baru yang bermunculan
kubectl get pods -l app=nginx --watch
# Scale down ke 2 replika
kubectl scale deployment nginx-deployment --replicas=2
# Verifikasi jumlah Pod berkurang
kubectl get pods -l app=nginx
# Alternatif: edit langsung via kubectl (membuka editor)
kubectl edit deployment nginx-deployment
Untuk scaling otomatis berdasarkan beban CPU, Kubernetes menyediakan objek HorizontalPodAutoscaler (HPA). Aktifkan metrics-server di Minikube terlebih dahulu, lalu buat HPA:
# Aktifkan metrics-server di Minikube
minikube addons enable metrics-server
# Buat HPA: scale otomatis antara 2-10 replika
# berdasarkan target penggunaan CPU 50%
kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=2 --max=10
# Pantau status HPA
kubectl get hpa --watch
Langkah 5 — Mengekspos Aplikasi dengan Service
Deployment sudah berjalan, tetapi aplikasi Anda belum bisa diakses dari
luar cluster. Saatnya membuat Service untuk mengeksposnya.
Buat file bernama service-nginx.yaml:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
labels:
app: nginx
spec:
type: NodePort # Ekspos ke luar cluster via port di Node
selector:
app: nginx # Arahkan traffic ke Pod berlabel app=nginx
ports:
- protocol: TCP
port: 80 # Port yang diekspos oleh Service
targetPort: 80 # Port di dalam container
nodePort: 30080 # Port eksternal (range 30000-32767)
# Terapkan Service
kubectl apply -f service-nginx.yaml
# Lihat Service yang berjalan
kubectl get services
# Output:
# NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
# nginx-service NodePort 10.96.xxx.xxx <none> 80:30080/TCP 10s
# Di Minikube, buka Service langsung di browser
minikube service nginx-service
# Atau dapatkan URL akses
minikube service nginx-service --url
Buka URL yang diberikan Minikube di browser — Anda akan melihat halaman selamat datang Nginx yang artinya aplikasi Anda berhasil diakses dari luar cluster. Kubernetes secara otomatis melakukan load balancing ke semua Pod yang aktif setiap kali ada request masuk.
Langkah 6 — Update dan Rollback Aplikasi
Langkah terakhir ini mendemonstrasikan salah satu fitur paling berharga
Kubernetes: zero-downtime deployment dengan kemampuan
rollback instan. Kita akan update image Nginx dari versi 1.25
ke 1.26
dan simulasikan skenario rollback.
# Update image ke versi baru secara imperatif
kubectl set image deployment/nginx-deployment nginx=nginx:1.26
# Pantau proses rolling update secara real-time
kubectl rollout status deployment/nginx-deployment
# Output saat berhasil:
# Waiting for deployment "nginx-deployment" rollout to finish:
# 1 out of 3 new replicas have been updated...
# 2 out of 3 new replicas have been updated...
# 3 out of 3 new replicas have been updated...
# deployment "nginx-deployment" successfully rolled out
# Lihat history semua versi deployment
kubectl rollout history deployment/nginx-deployment
Sekarang simulasikan skenario update yang bermasalah — deploy image yang tidak ada untuk memicu kegagalan, lalu lakukan rollback:
# Simulasi update dengan image yang salah/tidak ada
kubectl set image deployment/nginx-deployment nginx=nginx:versi-tidak-ada
# Pantau — Pod baru akan gagal masuk status ImagePullBackOff
kubectl get pods -l app=nginx --watch
# Rollback ke versi sebelumnya secara instan!
kubectl rollout undo deployment/nginx-deployment
# Atau rollback ke versi spesifik (misal revision 1)
kubectl rollout undo deployment/nginx-deployment --to-revision=1
# Verifikasi semua Pod kembali Running normal
kubectl get pods -l app=nginx
# Konfirmasi versi image sudah kembali ke sebelumnya
kubectl describe deployment nginx-deployment | grep Image
- Selama rolling update, Kubernetes memastikan minimal sejumlah Pod selalu Running — tidak ada downtime meskipun update sedang berjalan.
- Kubernetes menyimpan history revision deployment, memungkinkan rollback ke versi mana pun yang pernah dideploy sebelumnya.
- Gunakan anotasi --record saat melakukan update agar history revision lebih informatif dengan mencatat perintah yang digunakan.
- Tambahkan strategi RollingUpdate di spec Deployment untuk mengontrol maxUnavailable dan maxSurge sesuai kebutuhan toleransi aplikasi Anda.
Selamat! 🎉 Anda baru saja menyelesaikan siklus penuh deployment Kubernetes — dari menjalankan cluster pertama, membuat Pod, mendeploy dengan Deployment, melakukan scaling, mengekspos aplikasi via Service, hingga update dan rollback tanpa downtime. Ini adalah fondasi yang digunakan oleh engineer di perusahaan-perusahaan terbesar dunia setiap harinya. Di section berikutnya, kita akan mempraktikkan skenario deployment yang lebih nyata dan kompleks.
Contoh Deployment Nyata di Kubernetes
Di section sebelumnya kita sudah menguasai dasar-dasar operasional Kubernetes. Kini saatnya naik level — kita akan mempraktikkan tiga skenario deployment yang mencerminkan kasus nyata di lingkungan produksi. Setiap contoh dirancang lebih kompleks dari sebelumnya, memperkenalkan konsep dan pola baru yang akan sering Anda temui saat bekerja sebagai engineer profesional.
Contoh 1 — Deploy Aplikasi Web Sederhana (Nginx)
Contoh pertama ini memperkenalkan pola deployment paling fundamental: sebuah aplikasi web statis yang dilayani oleh Nginx dengan konten kustom yang diinjeksikan melalui ConfigMap. Pola ini sangat umum digunakan untuk frontend statis, landing page, atau dokumentasi internal yang perlu di-deploy di atas Kubernetes.
Kita akan membuat tiga file YAML yang bekerja bersama: ConfigMap untuk menyimpan konten HTML, Deployment untuk menjalankan Nginx, dan Service untuk mengeksposnya ke luar cluster.
📄 Step 1 — Buat ConfigMap untuk Konten HTML
Buat file configmap-html.yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-html-config
namespace: default
data:
index.html: |
<!DOCTYPE html>
<html lang="id">
<head>
<meta charset="UTF-8">
<title>Aplikasi Kubernetes Pertamaku</title>
<style>
body { font-family: sans-serif; text-align: center; padding: 60px; background: #f0f4f8; }
h1 { color: #326CE5; }
p { color: #555; }
</style>
</head>
<body>
<h1>🚀 Halo dari Kubernetes!</h1>
<p>Aplikasi ini berjalan di atas cluster Kubernetes.</p>
<p>Pod: <strong>{HOSTNAME}</strong></p>
</body>
</html>
🚀 Step 2 — Buat Deployment yang Me-mount ConfigMap
Buat file deployment-web.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25-alpine # Alpine lebih ringan ~40MB vs ~180MB
ports:
- containerPort: 80
volumeMounts:
- name: html-volume
mountPath: /usr/share/nginx/html # Mount HTML ke direktori Nginx
resources:
requests:
memory: "32Mi"
cpu: "50m"
limits:
memory: "64Mi"
cpu: "100m"
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 5
volumes:
- name: html-volume
configMap:
name: nginx-html-config # Ambil konten dari ConfigMap
🌐 Step 3 — Buat Service dan Deploy Semuanya
apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: NodePort
selector:
app: web
ports:
- port: 80
targetPort: 80
nodePort: 30090
# Deploy semua resource sekaligus
kubectl apply -f configmap-html.yaml
kubectl apply -f deployment-web.yaml
kubectl apply -f web-service.yaml
# Verifikasi semua berjalan
kubectl get configmap,deployment,pods,service -l app=web
# Buka di browser
minikube service web-service
# Refresh beberapa kali — perhatikan nama Pod berbeda
# di setiap request, bukti load balancing bekerja!
Contoh 2 — Deploy Aplikasi Node.js dengan Database MySQL
Contoh kedua ini adalah skenario yang paling sering ditemui di dunia nyata: aplikasi backend yang terhubung ke database. Kita akan mendeploy sebuah REST API Node.js sederhana bersama MySQL, memperkenalkan konsep penting seperti StatefulSet untuk database, PersistentVolume untuk penyimpanan data yang tahan restart, dan komunikasi antar-Service di dalam cluster.
🔐 Step 1 — Buat Secret untuk Kredensial MySQL
# Encode password ke base64 (JANGAN gunakan password lemah di produksi!)
echo -n 'passwordRahasia123' | base64
# Output: cGFzc3dvcmRSYWhhc2lhMTIz
Buat file secret-mysql.yaml:
apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
data:
mysql-root-password: cGFzc3dvcmRSYWhhc2lhMTIz # base64 encoded
mysql-database: YXBwa3Vi # "appkub" dalam base64
mysql-user: YXBwdXNlcg== # "appuser" dalam base64
mysql-password: YXBwcGFzczEyMw== # "apppass123" dalam base64
🗄️ Step 2 — Deploy MySQL dengan PersistentVolume
Buat file mysql-statefulset.yaml:
apiVersion: apps/v1
kind: StatefulSet # StatefulSet untuk workload stateful seperti DB
metadata:
name: mysql
spec:
serviceName: mysql-headless # Headless service untuk DNS stabil
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:8.0
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-root-password
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-database
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-password
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql # Data MySQL tersimpan di sini
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
volumeClaimTemplates: # PVC dibuat otomatis per replika
- metadata:
name: mysql-data
spec:
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 5Gi # 5 GB storage untuk data MySQL
---
apiVersion: v1
kind: Service
metadata:
name: mysql-headless
spec:
clusterIP: None # Headless: tidak ada IP virtual, DNS langsung ke Pod
selector:
app: mysql
ports:
- port: 3306
targetPort: 3306
🟢 Step 3 — Deploy Aplikasi Node.js
Buat file deployment-api.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
labels:
app: api
spec:
replicas: 2
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: node:20-alpine
ports:
- containerPort: 3000
env:
- name: DB_HOST
value: "mysql-headless" # DNS internal ke Service MySQL
- name: DB_PORT
value: "3306"
- name: DB_NAME
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-database
- name: DB_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-user
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: mysql-password
- name: NODE_ENV
value: "production"
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "300m"
readinessProbe:
httpGet:
path: /health
port: 3000
initialDelaySeconds: 15 # Tunggu DB siap sebelum cek health
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: api-service
spec:
type: NodePort
selector:
app: api
ports:
- port: 3000
targetPort: 3000
nodePort: 30300
# Deploy semua komponen secara berurutan
kubectl apply -f secret-mysql.yaml
kubectl apply -f mysql-statefulset.yaml
# Tunggu MySQL siap sebelum deploy API (penting!)
kubectl wait --for=condition=ready pod -l app=mysql --timeout=120s
# Deploy aplikasi Node.js
kubectl apply -f deployment-api.yaml
# Pantau semua resource
kubectl get secret,statefulset,deployment,pods,service
# Cek log MySQL untuk memastikan inisialisasi berhasil
kubectl logs -l app=mysql --tail=20
# Cek log API
kubectl logs -l app=api --tail=20
Contoh 3 — Deploy Aplikasi Multi-Container dengan ConfigMap & Secret
Contoh ketiga ini mensimulasikan arsitektur microservice sederhana yang lebih realistis: sebuah aplikasi dengan tiga komponen terpisah — frontend (React/Nginx), backend API (Python Flask), dan Redis sebagai cache — yang semuanya berjalan dalam satu namespace khusus dengan konfigurasi terpusat melalui ConfigMap dan Secret.
🏗️ Step 1 — Buat Namespace Khusus
# Buat namespace untuk aplikasi ini
kubectl create namespace toko-app
# Set namespace sebagai default untuk sesi ini
kubectl config set-context --current --namespace=toko-app
# Verifikasi
kubectl config view --minify | grep namespace
⚙️ Step 2 — Buat ConfigMap Terpusat
Buat file configmap-app.yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: toko-app
data:
# Konfigurasi aplikasi
APP_ENV: "production"
APP_PORT: "5000"
LOG_LEVEL: "info"
CACHE_TTL: "300" # Cache Redis 5 menit
REDIS_HOST: "redis-service" # DNS internal ke Service Redis
REDIS_PORT: "6379"
ALLOWED_ORIGINS: "https://toko.contoh.com"
MAX_UPLOAD_SIZE: "10mb"
🔐 Step 3 — Buat Secret untuk API Keys
apiVersion: v1
kind: Secret
metadata:
name: app-secret
namespace: toko-app
type: Opaque
stringData: # stringData: Kubernetes encode otomatis ke base64
JWT_SECRET: "jwt-super-secret-key-ganti-ini-di-produksi"
PAYMENT_API_KEY: "pk_live_xxxxxxxxxxxxxxxxxxxx"
SMTP_PASSWORD: "smtp-password-rahasia"
REDIS_PASSWORD: "redis-pass-rahasia"
⚡ Step 4 — Deploy Redis Cache
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis
namespace: toko-app
spec:
replicas: 1
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:7-alpine
ports:
- containerPort: 6379
command:
- redis-server
- "--requirepass"
- "$(REDIS_PASSWORD)" # Ambil password dari Secret
env:
- name: REDIS_PASSWORD
valueFrom:
secretKeyRef:
name: app-secret
key: REDIS_PASSWORD
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
---
apiVersion: v1
kind: Service
metadata:
name: redis-service
namespace: toko-app
spec:
clusterIP: None # Headless — hanya untuk internal cluster
selector:
app: redis
ports:
- port: 6379
targetPort: 6379
🐍 Step 5 — Deploy Backend Flask API
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
namespace: toko-app
spec:
replicas: 2
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: flask-api
image: python:3.11-slim
ports:
- containerPort: 5000
envFrom:
- configMapRef:
name: app-config # Injeksikan SEMUA key dari ConfigMap
- secretRef:
name: app-secret # Injeksikan SEMUA key dari Secret
resources:
requests:
memory: "128Mi"
cpu: "100m"
limits:
memory: "256Mi"
cpu: "300m"
readinessProbe:
httpGet:
path: /api/health
port: 5000
initialDelaySeconds: 20
periodSeconds: 10
livenessProbe:
httpGet:
path: /api/health
port: 5000
initialDelaySeconds: 30
periodSeconds: 15
---
apiVersion: v1
kind: Service
metadata:
name: backend-service
namespace: toko-app
spec:
type: ClusterIP # Hanya diakses internal (via Ingress)
selector:
app: backend
ports:
- port: 5000
targetPort: 5000
🌐 Step 6 — Deploy Semua dan Verifikasi
# Deploy semua resource dalam namespace toko-app
kubectl apply -f configmap-app.yaml
kubectl apply -f secret-app.yaml
kubectl apply -f redis-deployment.yaml
kubectl apply -f backend-deployment.yaml
# Pantau semua resource dalam namespace
kubectl get all -n toko-app
# Cek environment variable yang diinjeksikan ke container backend
kubectl exec -n toko-app deploy/backend -- env | grep -E 'APP_|REDIS_|LOG_'
# Test koneksi Redis dari dalam Pod backend
kubectl exec -n toko-app deploy/backend -- sh -c 'redis-cli -h redis-service -a $REDIS_PASSWORD ping'
# Output: PONG — Redis terhubung!
# Lihat semua log secara bersamaan dengan label selector
kubectl logs -n toko-app -l app=backend --tail=30 -f
Penjelasan Struktur File YAML Deployment Lengkap
Setiap file YAML Kubernetes memiliki struktur yang konsisten dan wajib mengikuti skema tertentu. Memahami anatomi file YAML ini akan membantu Anda membaca, menulis, dan men-debug konfigurasi Kubernetes dengan jauh lebih cepat dan percaya diri.
# ─────────────────────────────────────────
# ANATOMI FILE YAML KUBERNETES
# ─────────────────────────────────────────
apiVersion: apps/v1 # [1] API group & versi. Gunakan:
# v1 → Pod, Service, ConfigMap, Secret
# apps/v1 → Deployment, StatefulSet, DaemonSet
# batch/v1 → Job, CronJob
# networking.k8s.io/v1 → Ingress
kind: Deployment # [2] Tipe objek Kubernetes yang ingin dibuat
metadata: # [3] Identitas objek
name: nama-deployment # Nama unik dalam namespace
namespace: default # Namespace tempat objek dibuat
labels: # Label untuk seleksi & organisasi
app: nama-app
version: "1.0"
environment: production
annotations: # Metadata tambahan (tidak untuk seleksi)
description: "Deployment untuk aplikasi utama"
contact: "tim-backend@perusahaan.com"
spec: # [4] Spesifikasi desired state
replicas: 3 # Jumlah Pod yang harus berjalan
selector: # [5] Cara Deployment menemukan Pod miliknya
matchLabels:
app: nama-app # Harus cocok dengan labels di template.metadata
template: # [6] Blueprint untuk setiap Pod yang dibuat
metadata:
labels:
app: nama-app # Label Pod — harus cocok dengan selector
spec: # [7] Spesifikasi container di dalam Pod
containers:
- name: nama-container
image: image:tag # Selalu pin ke versi spesifik, hindari :latest
ports:
- containerPort: 8080
env: # [8] Environment variables
- name: KUNCI
value: "nilai-langsung"
- name: DARI_SECRET
valueFrom:
secretKeyRef:
name: nama-secret
key: kunci-di-secret
envFrom: # [9] Injeksi seluruh ConfigMap/Secret sekaligus
- configMapRef:
name: nama-configmap
volumeMounts: # [10] Mount volume ke path di dalam container
- name: nama-volume
mountPath: /path/di/container
resources: # [11] WAJIB di produksi: batasi resource
requests: # Minimum yang dijamin tersedia
memory: "128Mi"
cpu: "100m" # 100m = 0.1 CPU core
limits: # Maksimum yang boleh digunakan
memory: "256Mi"
cpu: "500m"
readinessProbe: # [12] Kapan Pod siap menerima traffic?
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
livenessProbe: # [13] Kapan Pod perlu di-restart?
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
volumes: # [14] Definisi volume yang bisa di-mount
- name: nama-volume
configMap:
name: nama-configmap
Beberapa aturan dan tips penting saat menulis file YAML Kubernetes:
- Indentasi menggunakan spasi, BUKAN tab — YAML sangat sensitif terhadap indentasi yang tidak konsisten dan akan menyebabkan error yang membingungkan.
- Selalu pin versi image dengan tag spesifik (nginx:1.25) dan hindari tag :latest di environment produksi — :latest tidak deterministik dan bisa menyebabkan perilaku yang tidak terduga.
- Label selector antara Deployment dan Pod template harus identik — ketidakcocokan di sini adalah sumber error yang sangat umum bagi pemula.
- Gunakan kubectl apply -f (bukan kubectl create -f) agar file YAML bisa dijalankan berulang kali secara idempoten tanpa error 'resource already exists'.
- Simpan semua file YAML di Git — konfigurasi infrastruktur adalah kode, dan harus mendapat perlakuan yang sama: version control, code review, dan audit trail.
Perintah-Perintah kubectl yang Sering Digunakan
kubectl adalah teman setia Anda sehari-hari sebagai Kubernetes engineer. Menguasai perintah-perintahnya bukan sekadar soal hafalan — melainkan tentang membangun muscle memory yang memungkinkan Anda bergerak cepat saat mendeploy fitur baru, menginvestigasi insiden produksi, atau mengoptimalkan performa cluster. Section ini adalah referensi lengkap yang bisa Anda bookmark dan kembalikan kapan pun dibutuhkan.
Perintah Dasar Melihat Status Cluster dan Pod
Perintah-perintah read-only ini adalah yang paling sering dijalankan — biasanya puluhan kali per hari. Kuasai kelompok perintah ini terlebih dahulu karena tidak ada risiko merusak apapun saat menjalankannya.
📋 Melihat Resource di Cluster
# ── NODES ──────────────────────────────────────────────────
# Lihat semua node beserta status dan versi Kubernetes
kubectl get nodes
# Lihat node dengan detail resource (CPU & memory usage)
kubectl get nodes -o wide
kubectl top nodes # Butuh metrics-server
# ── PODS ────────────────────────────────────────────────────
# Lihat semua Pod di namespace saat ini
kubectl get pods
# Lihat Pod di SEMUA namespace sekaligus
kubectl get pods --all-namespaces
kubectl get pods -A # Shorthand
# Lihat Pod dengan info IP dan Node tempat berjalan
kubectl get pods -o wide
# Lihat Pod dengan label tertentu
kubectl get pods -l app=nginx
kubectl get pods -l app=nginx,env=prod # Filter multi-label
# Pantau perubahan status Pod secara real-time
kubectl get pods --watch
kubectl get pods -w # Shorthand
# Lihat Pod dalam format output berbeda
kubectl get pods -o yaml # Output lengkap dalam YAML
kubectl get pods -o json # Output dalam JSON
kubectl get pods -o jsonpath='{.items[*].metadata.name}' # Ekstrak field spesifik
# ── SEMUA RESOURCE SEKALIGUS ────────────────────────────────
# Lihat deployment, service, pod, replicaset bersamaan
kubectl get all
kubectl get all -n nama-namespace
# Lihat resource spesifik berdasarkan nama
kubectl get pod nama-pod
kubectl get deployment nama-deployment
kubectl get service nama-service
🔍 Melihat Detail dan Deskripsi Resource
# Deskripsi lengkap sebuah Pod — SANGAT berguna untuk debugging
# Menampilkan: events, kondisi, volume, environment variables, probe status
kubectl describe pod nama-pod
# Deskripsi Deployment — lihat strategi update dan kondisi rollout
kubectl describe deployment nama-deployment
# Deskripsi Node — lihat kapasitas, resource yang terpakai, dan Pod yang berjalan
kubectl describe node nama-node
# Deskripsi Service — lihat endpoint dan selector
kubectl describe service nama-service
# Tips: gunakan grep untuk filter output describe yang panjang
kubectl describe pod nama-pod | grep -A 5 "Events:"
kubectl describe pod nama-pod | grep -i "image|state|ready"
📊 Monitoring Resource Usage
# Aktifkan metrics-server di Minikube (jika belum)
minikube addons enable metrics-server
# Lihat penggunaan CPU dan memori per Pod
kubectl top pods
kubectl top pods -A # Semua namespace
kubectl top pods -l app=nginx # Filter berdasarkan label
kubectl top pods --sort-by=memory # Urutkan berdasarkan memory
kubectl top pods --sort-by=cpu # Urutkan berdasarkan CPU
# Lihat penggunaan resource per Node
kubectl top nodes
# Lihat resource requests dan limits semua Pod
kubectl get pods -o custom-columns='NAME:.metadata.name,CPU-REQ:.spec.containers[*].resources.requests.cpu,MEM-REQ:.spec.containers[*].resources.requests.memory,CPU-LIM:.spec.containers[*].resources.limits.cpu,MEM-LIM:.spec.containers[*].resources.limits.memory'
Perintah Membuat, Mengedit, dan Menghapus Resource
Kelompok perintah ini bersifat write — mereka mengubah state
cluster secara aktif. Selalu pastikan Anda berada di namespace dan
context yang benar sebelum menjalankannya, terutama di environment
produksi. Satu perintah kubectl delete yang
salah namespace bisa menyebabkan insiden yang tidak perlu.
✅ Membuat dan Menerapkan Resource
# apply: buat ATAU update resource dari file YAML (idempoten — aman dijalankan berulang)
kubectl apply -f deployment.yaml
kubectl apply -f ./ # Terapkan SEMUA file YAML di direktori saat ini
kubectl apply -f ./k8s/ # Terapkan semua file di folder k8s/
kubectl apply -R -f ./ # Rekursif termasuk subdirektori
# create: buat resource baru (error jika sudah ada — tidak idempoten)
kubectl create -f pod.yaml
kubectl create namespace nama-namespace
kubectl create configmap nama-cm --from-file=config.properties
kubectl create configmap nama-cm --from-literal=KEY=value --from-literal=KEY2=value2
kubectl create secret generic nama-secret --from-literal=password=rahasia
kubectl create secret generic nama-secret --from-file=./credentials.json
# Dry-run: preview perubahan TANPA menerapkan ke cluster
kubectl apply -f deployment.yaml --dry-run=client
kubectl apply -f deployment.yaml --dry-run=server # Validasi di sisi server
# Generate YAML dari perintah imperatif (sangat berguna untuk belajar!)
kubectl create deployment nginx --image=nginx --dry-run=client -o yaml
kubectl run pod-test --image=nginx --dry-run=client -o yaml > pod.yaml
✏️ Mengedit Resource
# Edit resource langsung di editor (membuka $EDITOR, default: vi)
kubectl edit deployment nama-deployment
kubectl edit service nama-service
kubectl edit configmap nama-configmap
# Ganti editor default ke nano (lebih ramah pemula)
KUBE_EDITOR="nano" kubectl edit deployment nama-deployment
# Patch resource tanpa membuka editor — ideal untuk skrip otomasi
# Ganti jumlah replika
kubectl patch deployment nama-deployment -p '{"spec":{"replicas":5}}'
# Ganti image container
kubectl set image deployment/nama-deployment nama-container=nginx:1.26
# Tambahkan label ke Pod yang sudah berjalan
kubectl label pod nama-pod environment=production
# Tambahkan anotasi
kubectl annotate deployment nama-deployment description="Deployment utama aplikasi toko"
# Scale deployment
kubectl scale deployment nama-deployment --replicas=3
kubectl scale deployment nama-deployment --replicas=0 # Matikan semua Pod sementara
🗑️ Menghapus Resource
# Hapus resource dari file YAML (kebalikan dari apply)
kubectl delete -f deployment.yaml
kubectl delete -f ./k8s/ # Hapus semua resource dari folder
# Hapus resource berdasarkan tipe dan nama
kubectl delete pod nama-pod
kubectl delete deployment nama-deployment
kubectl delete service nama-service
kubectl delete namespace nama-namespace # ⚠️ Menghapus SEMUA resource di dalamnya!
# Hapus semua Pod dengan label tertentu
kubectl delete pods -l app=nginx
# Hapus Pod secara paksa tanpa menunggu graceful termination
# Gunakan hanya jika Pod stuck di status Terminating
kubectl delete pod nama-pod --force --grace-period=0
# Hapus semua resource di namespace tertentu sekaligus
kubectl delete all --all -n nama-namespace
🔄 Manajemen Rollout dan Deployment
# Pantau status proses rolling update
kubectl rollout status deployment/nama-deployment
# Lihat history semua revision deployment
kubectl rollout history deployment/nama-deployment
# Lihat detail perubahan di revision tertentu
kubectl rollout history deployment/nama-deployment --revision=3
# Rollback ke revision sebelumnya
kubectl rollout undo deployment/nama-deployment
# Rollback ke revision spesifik
kubectl rollout undo deployment/nama-deployment --to-revision=2
# Pause rolling update di tengah jalan (untuk observasi)
kubectl rollout pause deployment/nama-deployment
# Lanjutkan rolling update yang di-pause
kubectl rollout resume deployment/nama-deployment
# Restart semua Pod dalam Deployment (rolling restart tanpa downtime)
# Berguna untuk memuat ulang konfigurasi dari ConfigMap/Secret
kubectl rollout restart deployment/nama-deployment
🗂️ Manajemen Context dan Namespace
# Lihat semua context yang tersedia (cluster yang bisa diakses)
kubectl config get-contexts
# Pindah ke context lain (misal: dari minikube ke cluster produksi)
kubectl config use-context nama-context
# Lihat context yang sedang aktif
kubectl config current-context
# Jalankan perintah di namespace tertentu tanpa mengubah default
kubectl get pods -n nama-namespace
kubectl get pods --namespace=nama-namespace
# Ganti namespace default untuk sesi ini
kubectl config set-context --current --namespace=nama-namespace
# Tips pro: Install kubectx dan kubens untuk berpindah context/namespace lebih cepat
# brew install kubectx
# kubectx nama-context → pindah context
# kubens nama-namespace → pindah namespace
Perintah Debugging dan Troubleshooting di Kubernetes
Kemampuan debugging yang baik adalah yang membedakan Kubernetes engineer junior dari yang senior. Saat sesuatu tidak berjalan sesuai harapan — dan itu pasti akan terjadi — kelompok perintah inilah yang akan memandu Anda menemukan akar masalah dengan cepat dan sistematis.
📜 Melihat Log Container
# Lihat log Pod
kubectl logs nama-pod
# Ikuti log secara real-time (seperti tail -f)
kubectl logs nama-pod -f
kubectl logs nama-pod --follow # Versi panjang
# Lihat N baris log terakhir
kubectl logs nama-pod --tail=100
# Lihat log dari container spesifik (jika Pod punya beberapa container)
kubectl logs nama-pod -c nama-container
# Lihat log Pod yang sudah crash/restart (log dari instance sebelumnya)
kubectl logs nama-pod --previous
kubectl logs nama-pod -p # Shorthand — SANGAT berguna!
# Lihat log dari semua Pod dengan label tertentu sekaligus
kubectl logs -l app=nginx --tail=50
kubectl logs -l app=nginx -f --max-log-requests=10
# Filter log berdasarkan waktu
kubectl logs nama-pod --since=1h # 1 jam terakhir
kubectl logs nama-pod --since-time="2024-01-15T10:00:00Z"
💻 Menjalankan Perintah di Dalam Container
# Buka shell interaktif di dalam container (seperti SSH ke server)
kubectl exec -it nama-pod -- /bin/bash
kubectl exec -it nama-pod -- /bin/sh # Untuk image Alpine (tidak ada bash)
# Masuk ke container spesifik dalam Pod multi-container
kubectl exec -it nama-pod -c nama-container -- /bin/bash
# Jalankan perintah satu kali tanpa shell interaktif
kubectl exec nama-pod -- ls /app
kubectl exec nama-pod -- cat /etc/nginx/nginx.conf
kubectl exec nama-pod -- env | grep DB_ # Cek environment variables
# Copy file dari/ke container
kubectl cp nama-pod:/path/file/di/container ./file-lokal
kubectl cp ./file-lokal nama-pod:/path/tujuan/di/container
# Contoh nyata: ambil file log dari container
kubectl cp nama-pod:/var/log/app/error.log ./error.log
🌐 Debugging Jaringan dan Konektivitas
# Port-forward: akses Service/Pod langsung dari localhost tanpa Ingress
# Format: kubectl port-forward <resource> <port-lokal>:<port-remote>
kubectl port-forward pod/nama-pod 8080:80
kubectl port-forward service/nama-service 8080:80
kubectl port-forward deployment/nama-deployment 8080:3000
# Jalankan di background
kubectl port-forward service/nama-service 8080:80 &
# Deploy Pod debugging sementara dengan tools jaringan lengkap
# (curl, nslookup, ping, netstat, dll.)
kubectl run debug-pod --image=nicolaka/netshoot -it --rm -- bash
# Dari dalam Pod debug, test konektivitas ke Service lain
curl http://nama-service:80/health
nslookup nama-service # Cek DNS resolution
nslookup nama-service.nama-namespace.svc.cluster.local
# Cek endpoint Service (apakah ada Pod yang terdaftar?)
kubectl get endpoints nama-service
kubectl describe endpoints nama-service
🔎 Investigasi Pod Bermasalah
# Alur investigasi sistematis saat Pod tidak Running:
# Langkah 1: Cek status dan kondisi Pod
kubectl get pods
# Status umum yang perlu diinvestigasi:
# Pending → Pod belum dijadwalkan ke Node (cek resource/taint)
# CrashLoopBackOff → Container terus crash dan di-restart
# ImagePullBackOff → Gagal mengunduh image (cek nama/tag/registry)
# OOMKilled → Container kehabisan memori (naikkan memory limit)
# Terminating → Pod stuck saat penghapusan (coba --force)
# Langkah 2: Describe Pod untuk melihat events
kubectl describe pod nama-pod
# Perhatikan bagian "Events:" di bawah output — di sinilah petunjuk masalah!
# Langkah 3: Lihat log container
kubectl logs nama-pod
kubectl logs nama-pod --previous # Log sebelum crash
# Langkah 4: Cek apakah masalah di level Node
kubectl describe node nama-node | grep -A 10 "Conditions:"
kubectl describe node nama-node | grep -A 20 "Allocated resources:"
# Langkah 5: Periksa events di seluruh namespace
kubectl get events --sort-by='.lastTimestamp'
kubectl get events -n nama-namespace --sort-by='.lastTimestamp'
kubectl get events --field-selector reason=BackOff # Filter event spesifik
⚡ Perintah Produktivitas Tinggi (Tips Pro)
# Alias kubectl ke k — hemat ribuan ketikan per hari
alias k=kubectl
# Explain: dokumentasi field YAML langsung dari terminal
kubectl explain pod
kubectl explain pod.spec
kubectl explain deployment.spec.strategy
kubectl explain service.spec.type # Sangat berguna saat menulis YAML!
# API resources: lihat semua tipe resource yang tersedia
kubectl api-resources
kubectl api-resources --namespaced=true # Hanya resource berbasis namespace
kubectl api-resources --namespaced=false # Resource level cluster (Node, PV, dll.)
# Gunakan jsonpath untuk ekstrak data spesifik dari output
# Contoh: ambil IP semua Pod yang berjalan
kubectl get pods -o jsonpath='{.items[*].status.podIP}'
# Contoh: ambil nama image semua container yang berjalan
kubectl get pods -o jsonpath='{.items[*].spec.containers[*].image}'
# Lihat semua resource yang ada di sebuah namespace (termasuk CRD)
kubectl get all,configmap,secret,ingress,pvc -n nama-namespace
# Hapus semua Pod yang sudah Completed (hasil Job yang selesai)
kubectl delete pods --field-selector=status.phase=Succeeded
# Force delete Pod yang stuck di Terminating
kubectl delete pod nama-pod --grace-period=0 --force
- Selalu cek namespace aktif sebelum menjalankan perintah write — gunakan kubectl config current-context dan kubectl config view --minify | grep namespace untuk konfirmasi.
- Biasakan menggunakan --dry-run=client sebelum kubectl apply di environment produksi untuk mempreview perubahan tanpa risiko.
- Instal plugin kubectl seperti kubectx/kubens (berpindah context/namespace), stern (multi-pod log tailing), dan k9s (TUI dashboard) untuk produktivitas yang jauh lebih tinggi.
- Gunakan kubectl explain setiap kali lupa nama field di YAML — lebih cepat dari membuka dokumentasi browser dan tidak membutuhkan koneksi internet.
- Simpan perintah-perintah kubectl yang sering digunakan sebagai shell alias atau fungsi di ~/.bashrc untuk menghemat waktu.
Kubernetes di Cloud — Managed Kubernetes Services
Menjalankan Kubernetes secara mandiri di server sendiri (self-hosted) adalah pilihan yang valid, tetapi membutuhkan keahlian dan waktu yang signifikan untuk mengelola Control Plane, mengurus upgrade versi, memastikan ketersediaan etcd, dan mengkonfigurasi jaringan cluster secara manual. Di sinilah Managed Kubernetes Services hadir sebagai solusi — cloud provider mengambil alih semua beban operasional Control Plane, sehingga tim Anda bisa fokus sepenuhnya pada aplikasi dan bisnis, bukan pada infrastruktur Kubernetes itu sendiri.
Google Kubernetes Engine (GKE)
Google Kubernetes Engine (GKE) adalah managed Kubernetes service dari Google Cloud Platform — dan bukan tanpa alasan jika GKE sering disebut sebagai layanan Kubernetes paling matang di industri. Google adalah pencipta Kubernetes itu sendiri, dan pengalaman serta kedalaman teknis tersebut tercermin langsung dalam kualitas dan fitur GKE yang tidak dimiliki kompetitor secara penuh.
✨ Keunggulan Utama GKE
- Autopilot Mode: mode revolusioner di mana Google mengelola SELURUH infrastruktur cluster secara otomatis — termasuk Node, scaling, keamanan, dan optimasi resource. Anda hanya mendeploy workload dan membayar per Pod, bukan per Node.
- Upgrade otomatis terdepan: GKE biasanya mendukung versi Kubernetes terbaru lebih cepat dari kompetitor, karena Google langsung berkontribusi ke upstream Kubernetes.
- Integrasi Google Cloud yang dalam: native integration dengan BigQuery, Cloud Spanner, Pub/Sub, Cloud Armor (WAF), dan seluruh ekosistem Google Cloud tanpa konfigurasi ekstra.
- Workload Identity: mekanisme autentikasi yang memungkinkan Pod mengakses layanan Google Cloud menggunakan Google Service Account tanpa perlu menyimpan credential di Secret.
- Binary Authorization: kebijakan keamanan yang memastikan hanya container image yang sudah diverifikasi dan ditandatangani yang boleh berjalan di cluster produksi.
- GKE Sandbox (gVisor): lapisan isolasi tambahan menggunakan gVisor untuk workload yang membutuhkan keamanan container tingkat tinggi.
🚀 Membuat Cluster GKE via CLI
# Install Google Cloud SDK terlebih dahulu
# https://cloud.google.com/sdk/docs/install
# Login ke Google Cloud
gcloud auth login
# Set project aktif
gcloud config set project PROJECT_ID
# ── MODE STANDARD ─────────────────────────────────────────
# Buat cluster GKE Standard (Anda kelola Node-nya)
gcloud container clusters create nama-cluster --zone=asia-southeast2-a # Jakarta region
--num-nodes=3 --machine-type=e2-standard-2 --enable-autoscaling --min-nodes=1 --max-nodes=5 --enable-autorepair --enable-autoupgrade
# ── MODE AUTOPILOT ────────────────────────────────────────
# Buat cluster GKE Autopilot (Google kelola segalanya)
gcloud container clusters create-auto nama-cluster-autopilot --region=asia-southeast2 # Jakarta region
# Hubungkan kubectl ke cluster GKE
gcloud container clusters get-credentials nama-cluster --zone=asia-southeast2-a
# Verifikasi koneksi
kubectl get nodes
kubectl cluster-info
Amazon Elastic Kubernetes Service (EKS)
Amazon Elastic Kubernetes Service (EKS) adalah managed Kubernetes service dari AWS — cloud provider terbesar di dunia dengan pangsa pasar yang mendominasi. EKS menjadi pilihan utama bagi perusahaan yang sudah sangat invested di ekosistem AWS, karena integrasinya dengan ratusan layanan AWS lainnya berjalan secara native dan seamless.
✨ Keunggulan Utama EKS
- Ekosistem AWS terlengkap: integrasi native dengan IAM, VPC, ALB/NLB, RDS, ElastiCache, S3, CloudWatch, dan ratusan layanan AWS lainnya yang sudah familiar bagi tim yang berbasis AWS.
- EKS Fargate: jalankan Pod tanpa mengelola Node sama sekali — setiap Pod mendapat compute environment terisolasi sendiri, ideal untuk workload batch atau microservice yang jarang berjalan.
- EKS Anywhere: opsi unik yang memungkinkan Anda menjalankan EKS di data center on-premise atau hardware sendiri menggunakan tools dan API yang sama persis dengan EKS di cloud.
- AWS Graviton support: jalankan workload di processor ARM berbasis Graviton2/3 untuk efisiensi harga hingga 40% lebih baik dibanding instance x86 setara.
- IRSA (IAM Roles for Service Accounts): mekanisme keamanan untuk memberikan izin AWS IAM ke Pod secara granular tanpa mengekspos credentials.
🚀 Membuat Cluster EKS via eksctl
# Install eksctl — CLI resmi untuk mengelola EKS
# https://eksctl.io/installation/
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl
# Konfigurasi AWS credentials
aws configure
# Masukkan: AWS Access Key ID, Secret Access Key, Region
# ── BUAT CLUSTER DENGAN CONFIG FILE ───────────────────────
# Buat file cluster.yaml:
cat <<EOF > cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: nama-cluster-eks
region: ap-southeast-1 # Singapore (terdekat dengan Indonesia)
version: "1.28"
nodeGroups:
- name: node-group-1
instanceType: t3.medium
desiredCapacity: 2
minSize: 1
maxSize: 4
amiFamily: AmazonLinux2
iam:
withAddonPolicies:
autoScaler: true
cloudWatch: true
albIngress: true
EOF
# Buat cluster dari config file (membutuhkan 15-20 menit)
eksctl create cluster -f cluster.yaml
# Hubungkan kubectl ke cluster EKS
aws eks update-kubeconfig --name nama-cluster-eks --region ap-southeast-1
# Verifikasi
kubectl get nodes
Azure Kubernetes Service (AKS)
Azure Kubernetes Service (AKS) adalah managed Kubernetes service dari Microsoft Azure. AKS adalah pilihan yang sangat kuat bagi organisasi yang ekosistem teknologinya berpusat pada produk-produk Microsoft — mulai dari Active Directory, Windows Server, hingga aplikasi .NET dan SQL Server. Microsoft juga merupakan kontributor aktif di komunitas Kubernetes open-source, menjadikan AKS sebagai layanan yang terus berkembang pesat.
✨ Keunggulan Utama AKS
- Control Plane gratis: tidak seperti EKS yang mengenakan biaya $0.10/jam untuk Control Plane, AKS tidak membebankan biaya untuk Control Plane — Anda hanya membayar untuk Node (VM) yang berjalan.
- Integrasi Azure Active Directory (AAD): autentikasi dan otorisasi cluster terintegrasi langsung dengan AAD, memudahkan manajemen akses bagi organisasi yang sudah menggunakan Microsoft 365.
- Windows Node Pool: satu-satunya managed Kubernetes service yang mendukung Worker Node berbasis Windows Server secara native, ideal untuk organisasi yang menjalankan aplikasi .NET Framework.
- Azure DevOps integration: pipeline CI/CD terintegrasi erat dengan Azure DevOps untuk workflow deployment yang seamless tanpa konfigurasi tambahan.
- Azure Policy for AKS: terapkan kebijakan keamanan dan compliance secara terpusat ke seluruh cluster menggunakan Azure Policy, ideal untuk organisasi dengan kebutuhan governance ketat.
- Confidential Computing: jalankan workload sensitif di node dengan Intel SGX untuk enkripsi data-in-use, menjaga data tetap terenkripsi bahkan saat diproses.
🚀 Membuat Cluster AKS via Azure CLI
# Install Azure CLI
# https://learn.microsoft.com/cli/azure/install-azure-cli
# Login ke Azure
az login
# Buat Resource Group (wadah untuk semua resource Azure)
az group create --name rg-kubernetes --location southeastasia # Singapore region
# Buat cluster AKS
az aks create --resource-group rg-kubernetes --name nama-cluster-aks --node-count 2 --node-vm-size Standard_B2s --enable-cluster-autoscaler --min-count 1 --max-count 5 --kubernetes-version 1.28.0 --enable-addons monitoring # Aktifkan Azure Monitor
--generate-ssh-keys
# Hubungkan kubectl ke cluster AKS
az aks get-credentials --resource-group rg-kubernetes --name nama-cluster-aks
# Verifikasi
kubectl get nodes
Perbandingan Singkat: Mana yang Tepat untuk Anda?
Tidak ada jawaban universal untuk pertanyaan ini — pilihan terbaik sangat bergantung pada konteks spesifik organisasi Anda. Berikut perbandingan komprehensif ketiga layanan dari berbagai dimensi yang paling relevan untuk pengambilan keputusan:
| Dimensi | GKE | EKS | AKS |
|---|---|---|---|
| Biaya Control Plane | Gratis (Standard) / Per Pod (Autopilot) | $0.10/jam (~$72/bulan) | Gratis |
| Kemudahan Setup | ⭐⭐⭐⭐⭐ Termudah | ⭐⭐⭐ Butuh eksctl/Terraform | ⭐⭐⭐⭐ Mudah via CLI |
| Kematangan Fitur | ⭐⭐⭐⭐⭐ Terlengkap | ⭐⭐⭐⭐ Sangat lengkap | ⭐⭐⭐⭐ Berkembang pesat |
| Ekosistem Terbaik | Google Cloud (AI/ML, BigQuery) | AWS (terluas & terdalam) | Microsoft (Azure AD, .NET) |
| Serverless Node | Autopilot Mode | Fargate | Virtual Nodes (ACI) |
| Windows Support | Terbatas | Tersedia | Native & terbaik |
| Region Asia Terdekat | Jakarta (asia-southeast2) | Singapore (ap-southeast-1) | Singapore (southeastasia) |
| Cocok untuk | Startup & tim yang prioritaskan kemudahan | Enterprise yang all-in AWS | Organisasi berbasis Microsoft |
Sebagai panduan praktis untuk konteks Indonesia, berikut rekomendasi berdasarkan profil organisasi yang paling umum:
- Pilih GKE jika: Anda memulai dari nol, tim Anda baru pertama kali menggunakan managed Kubernetes, atau aplikasi Anda memanfaatkan layanan AI/ML Google seperti Vertex AI dan BigQuery.
- Pilih EKS jika: infrastruktur Anda sudah sangat bergantung pada layanan AWS (RDS, S3, SQS, dll.), atau Anda membutuhkan opsi hybrid cloud via EKS Anywhere untuk data center lokal.
- Pilih AKS jika: organisasi Anda menggunakan Microsoft 365, Azure Active Directory, atau menjalankan aplikasi .NET dan SQL Server yang perlu diintegrasikan erat dengan layanan Azure.
- Pertimbangkan alternatif lokal: untuk kepatuhan regulasi data residency Indonesia, pertimbangkan cloud provider lokal seperti Alibaba Cloud Indonesia, Telkom Sigma, atau IDCloudHost yang mulai menyediakan managed Kubernetes.
Satu hal yang perlu diingat: semua konfigurasi YAML Kubernetes yang Anda tulis akan berjalan identik di GKE, EKS, maupun AKS — itulah salah satu keindahan terbesar Kubernetes sebagai standar terbuka. Investasi belajar Kubernetes tidak terikat pada satu cloud provider, dan keahlian Anda sepenuhnya portabel ke mana pun Anda bekerja.
Best Practices Kubernetes untuk Pemula
Mengetahui cara menjalankan Kubernetes adalah satu hal — menjalankannya dengan benar adalah hal yang sama sekali berbeda. Banyak tim engineering yang berhasil mendeploy aplikasi ke Kubernetes, tetapi kemudian menghadapi masalah performa, keamanan, atau biaya yang tidak terduga karena mengabaikan praktik-praktik fundamental sejak awal. Bagian ini merangkum pelajaran yang biasanya hanya didapat setelah bertahun-tahun pengalaman — atau setelah mengalami insiden produksi yang menyakitkan.
Selalu Gunakan Resource Limits dan Requests
Ini adalah best practice nomor satu yang paling sering diabaikan oleh
pemula — dan konsekuensinya bisa sangat serius di lingkungan produksi.
Tanpa resources.requests dan resources.limits,
sebuah container yang mengalami memory leak atau lonjakan CPU bisa
menghabiskan seluruh resource sebuah Node — menyebabkan Pod lain
yang tidak bersalah ikut crash dalam kondisi yang dikenal sebagai
"noisy neighbor problem".
📐 Memahami Requests vs Limits
- requests: jumlah resource minimum yang dijamin tersedia untuk container. Kubernetes Scheduler menggunakan nilai ini untuk menentukan di Node mana Pod akan ditempatkan. Jika Node tidak memiliki cukup resource sesuai requests, Pod tidak akan dijadwalkan di sana.
- limits: batas maksimum resource yang boleh digunakan container. Jika container mencoba menggunakan CPU melebihi limit, ia akan di-throttle (diperlambat). Jika melebihi memory limit, container akan langsung di-kill dengan status OOMKilled.
- CPU diukur dalam satuan cores atau millicores: 1000m = 1 CPU core. Nilai 250m berarti container bisa menggunakan maksimal 25% dari satu CPU core.
- Memory diukur dalam bytes dengan suffix: Mi (mebibytes) dan Gi (gibibytes). Gunakan Mi/Gi, bukan MB/GB, untuk presisi yang tepat di Kubernetes.
# ❌ JANGAN LAKUKAN INI — tanpa resource limits
spec:
containers:
- name: api
image: my-api:1.0
# Tidak ada resources → container bisa menghabiskan seluruh Node!
---
# ✅ SELALU LAKUKAN INI — dengan resource limits
spec:
containers:
- name: api
image: my-api:1.0
resources:
requests:
memory: "128Mi" # Minimum yang dijamin tersedia
cpu: "100m" # 0.1 CPU core dijamin
limits:
memory: "256Mi" # Maksimum memori — jika lebih → OOMKilled
cpu: "500m" # Maksimum CPU — jika lebih → throttled
# ── PANDUAN NILAI AWAL YANG REALISTIS ─────────────────────
# Aplikasi Node.js/Python ringan:
# requests: cpu=100m, memory=128Mi
# limits: cpu=500m, memory=256Mi
#
# Aplikasi Java/JVM (butuh lebih banyak memory):
# requests: cpu=250m, memory=512Mi
# limits: cpu=1000m, memory=1Gi
#
# Database (MySQL, PostgreSQL):
# requests: cpu=250m, memory=256Mi
# limits: cpu=1000m, memory=512Mi
🛡️ Gunakan LimitRange untuk Nilai Default Otomatis
Daripada mengandalkan setiap developer untuk selalu ingat menambahkan resource limits, terapkan LimitRange di setiap namespace untuk secara otomatis menetapkan nilai default dan batas maksimum yang boleh diminta:
apiVersion: v1
kind: LimitRange
metadata:
name: default-limits
namespace: production
spec:
limits:
- type: Container
default: # Nilai limits jika tidak didefinisikan
cpu: "500m"
memory: "256Mi"
defaultRequest: # Nilai requests jika tidak didefinisikan
cpu: "100m"
memory: "128Mi"
max: # Batas maksimum yang boleh diminta
cpu: "2"
memory: "2Gi"
min: # Batas minimum yang harus didefinisikan
cpu: "50m"
memory: "64Mi"
💰 Gunakan ResourceQuota untuk Batasi Konsumsi per Namespace
apiVersion: v1
kind: ResourceQuota
metadata:
name: namespace-quota
namespace: team-backend
spec:
hard:
requests.cpu: "4" # Total CPU requests maksimal di namespace ini
requests.memory: "8Gi" # Total memory requests maksimal
limits.cpu: "8" # Total CPU limits maksimal
limits.memory: "16Gi" # Total memory limits maksimal
pods: "20" # Maksimal 20 Pod berjalan bersamaan
services: "10" # Maksimal 10 Service
persistentvolumeclaims: "5" # Maksimal 5 PVC
Pisahkan Environment dengan Namespace
Menjalankan workload development, staging, dan production dalam satu
namespace yang sama adalah resep untuk bencana. Satu perintah kubectl delete
yang salah, satu ConfigMap yang tertimpa, atau satu Service yang
salah routing bisa berdampak ke environment yang tidak seharusnya.
Namespace adalah pagar yang memisahkan lingkungan kerja — gunakanlah
secara konsisten.
🏗️ Strategi Namespace yang Direkomendasikan
# ── STRATEGI 1: PISAH PER ENVIRONMENT ────────────────────
# Cocok untuk: tim kecil-menengah dengan satu produk utama
kubectl create namespace development
kubectl create namespace staging
kubectl create namespace production
kubectl create namespace monitoring # Prometheus, Grafana, dll.
kubectl create namespace ingress-nginx # Ingress controller
# ── STRATEGI 2: PISAH PER TIM/PRODUK ─────────────────────
# Cocok untuk: perusahaan dengan banyak tim atau produk berbeda
kubectl create namespace team-backend-prod
kubectl create namespace team-backend-dev
kubectl create namespace team-frontend-prod
kubectl create namespace team-data-prod
# ── TERAPKAN RBAC PER NAMESPACE ───────────────────────────
# Beri akses developer hanya ke namespace development mereka
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-access
namespace: development
subjects:
- kind: User
name: nama-developer@perusahaan.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: edit # Role bawaan: view, edit, admin
apiGroup: rbac.authorization.k8s.io
- Terapkan NetworkPolicy per namespace untuk memblokir komunikasi lintas namespace yang tidak diizinkan — secara default semua Pod di cluster bisa saling berkomunikasi.
- Gunakan prefix yang konsisten untuk nama namespace (prod-, staging-, dev-) agar mudah diidentifikasi saat bekerja dengan kubectl.
- Pertimbangkan menggunakan cluster terpisah untuk production dan non-production jika kebutuhan isolasi sangat tinggi — namespace memberikan isolasi logis, bukan fisik.
- Pasang ResourceQuota di setiap namespace production untuk mencegah deployment yang tidak terkontrol menghabiskan resource cluster.
Simpan Konfigurasi di Version Control (GitOps)
GitOps adalah praktik menggunakan Git sebagai satu-satunya sumber kebenaran untuk konfigurasi infrastruktur dan aplikasi. Alih-alih menjalankan perintah kubectl secara manual langsung ke cluster, semua perubahan dilakukan melalui Git commit — dan sebuah operator otomatis yang berjalan di dalam cluster akan mendeteksi perubahan tersebut dan menerapkannya secara otomatis. Hasilnya: audit trail yang sempurna, rollback yang mudah, dan tidak ada lagi "perubahan manual yang tidak terdokumentasi" yang menjadi sumber misteri di tengah insiden.
🌿 Struktur Repository GitOps yang Direkomendasikan
# Struktur monorepo untuk konfigurasi Kubernetes
k8s-configs/
├── base/ # Konfigurasi dasar yang dibagikan
│ ├── deployment.yaml
│ ├── service.yaml
│ └── kustomization.yaml
├── overlays/ # Override per environment
│ ├── development/
│ │ ├── kustomization.yaml # Patch: replicas=1, image=dev tag
│ │ └── config-patch.yaml
│ ├── staging/
│ │ ├── kustomization.yaml # Patch: replicas=2, image=staging tag
│ │ └── config-patch.yaml
│ └── production/
│ ├── kustomization.yaml # Patch: replicas=5, image=v1.2.3
│ └── config-patch.yaml
└── apps/ # Konfigurasi per aplikasi
├── frontend/
├── backend-api/
└── worker/
🔄 Tools GitOps Populer
- ArgoCD: platform GitOps deklaratif yang paling populer, menyediakan dashboard UI yang cantik untuk memvisualisasikan state aplikasi dan perbedaan antara Git dan cluster secara real-time.
- Flux CD: alternatif ArgoCD yang lebih ringan dan berbasis CLI, terintegrasi erat dengan ekosistem CNCF dan mendukung multi-tenancy yang lebih fleksibel.
- Kustomize: tool bawaan kubectl untuk mengelola variasi konfigurasi per environment tanpa duplikasi YAML — gunakan base + overlays untuk DRY configuration.
- Helm: package manager Kubernetes yang memungkinkan distribusi dan instalasi aplikasi kompleks dengan satu perintah, menggunakan templating YAML yang powerful.
# Install ArgoCD di cluster
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Tunggu semua Pod ArgoCD siap
kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=argocd-server -n argocd --timeout=120s
# Akses ArgoCD UI via port-forward
kubectl port-forward svc/argocd-server -n argocd 8080:443
# Dapatkan password admin awal
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
# Buka https://localhost:8080 di browser
# Login: admin / password dari perintah di atas
Monitoring dengan Prometheus dan Grafana
Menjalankan aplikasi di Kubernetes tanpa monitoring adalah seperti mengendarai mobil di malam hari tanpa lampu — Anda tidak akan tahu ada masalah sampai sudah terlambat. Prometheus dan Grafana adalah kombinasi standar industri untuk observability di Kubernetes: Prometheus mengumpulkan dan menyimpan metrik, sementara Grafana memvisualisasikannya dalam dashboard yang informatif dan mudah dipahami.
📊 Metrik Kubernetes yang Wajib Dipantau
- CPU & Memory utilization per Pod dan Node: pastikan tidak ada Pod yang konsisten di atas 80% — ini sinyal untuk scale up atau optimasi kode.
- Pod restart count: Pod yang sering restart mengindikasikan crash loop, OOMKill, atau masalah liveness probe yang perlu segera diinvestigasi.
- HTTP request rate, error rate, dan latency (RED metrics): tiga metrik ini adalah indikator kesehatan layanan yang paling langsung berkorelasi dengan pengalaman pengguna.
- Pending Pods: Pod yang lama di status Pending menandakan cluster kekurangan resource atau ada masalah scheduling yang perlu ditangani.
- PersistentVolume usage: pantau kapasitas penyimpanan database dan aplikasi stateful agar tidak kehabisan disk secara tiba-tiba di produksi.
🚀 Install Prometheus & Grafana via Helm (Cara Tercepat)
# Install Helm terlebih dahulu
# https://helm.sh/docs/intro/install/
brew install helm
# Tambahkan repository Helm untuk kube-prometheus-stack
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
# Buat namespace khusus untuk monitoring
kubectl create namespace monitoring
# Install kube-prometheus-stack (Prometheus + Grafana + AlertManager sekaligus)
helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring --set grafana.adminPassword=adminGrafana123 --set prometheus.prometheusSpec.retention=15d --set grafana.defaultDashboardsEnabled=true
# Pantau proses instalasi
kubectl get pods -n monitoring --watch
# Akses Grafana UI
kubectl port-forward -n monitoring svc/prometheus-grafana 3000:80
# Buka http://localhost:3000
# Login: admin / adminGrafana123
# Akses Prometheus UI
kubectl port-forward -n monitoring svc/prometheus-kube-prometheus-prometheus 9090:9090
# Buka http://localhost:9090
🔔 Contoh AlertManager Rule untuk Notifikasi Otomatis
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: alerting-rules
namespace: monitoring
spec:
groups:
- name: kubernetes.rules
rules:
# Alert jika Pod crash lebih dari 3 kali dalam 15 menit
- alert: PodCrashLooping
expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
for: 5m
labels:
severity: critical
annotations:
summary: "Pod {{ $labels.pod }} terus crash"
description: "Pod {{ $labels.pod }} di namespace {{ $labels.namespace }} mengalami crash loop."
# Alert jika memory usage Node di atas 85%
- alert: NodeMemoryHigh
expr: |
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
/ node_memory_MemTotal_bytes * 100 > 85
for: 10m
labels:
severity: warning
annotations:
summary: "Memory Node {{ $labels.instance }} tinggi"
description: "Penggunaan memory mencapai {{ $value }}%"
- Gunakan kube-prometheus-stack (bukan install Prometheus dan Grafana secara terpisah) karena sudah dilengkapi dengan dashboard Kubernetes bawaan yang komprehensif dan aturan alerting yang sudah terkonfigurasi.
- Integrasikan AlertManager dengan Slack, PagerDuty, atau email tim agar notifikasi insiden sampai ke orang yang tepat secara real-time — bukan ditemukan saat sudah terjadi downtime.
- Tambahkan label app dan version di setiap Pod untuk memudahkan filtering metrik per aplikasi dan versi di Grafana.
- Pertimbangkan OpenTelemetry sebagai standar instrumentasi yang vendor-neutral, memungkinkan Anda mengganti backend observability (Prometheus, Jaeger, Zipkin) tanpa mengubah kode aplikasi.
Kubernetes vs Docker Compose — Kapan Menggunakan Masing-Masing?
Salah satu pertanyaan yang paling sering muncul dari developer yang baru berkenalan dengan Kubernetes adalah: "Saya sudah punya Docker Compose yang berfungsi dengan baik — mengapa harus repot berpindah ke Kubernetes?" Ini adalah pertanyaan yang sangat valid, dan jawabannya bukan "selalu gunakan Kubernetes". Keduanya adalah tools yang luar biasa, namun dirancang untuk skala dan kompleksitas yang berbeda. Memahami perbedaan ini akan menghindarkan Anda dari over-engineering yang tidak perlu — atau sebaliknya, under-engineering yang menghambat pertumbuhan.
Kelebihan dan Kekurangan Docker Compose
Docker Compose adalah tool untuk mendefinisikan dan
menjalankan aplikasi multi-container di satu mesin menggunakan
sebuah file YAML bernama docker-compose.yml.
Dengan satu perintah docker compose up,
seluruh stack aplikasi Anda — frontend, backend, database, cache —
langsung berjalan dalam hitungan detik. Kesederhanaan inilah yang
menjadikan Docker Compose tidak tergantikan untuk skenario tertentu.
✅ Kelebihan Docker Compose
- Sangat mudah dipelajari dan digunakan: satu file YAML, satu perintah, langsung berjalan. Kurva belajarnya sangat landai dibanding Kubernetes yang memiliki banyak konsep dan objek.
- Setup development lokal yang sempurna: menjalankan seluruh stack aplikasi di laptop dengan database, cache, dan semua dependency-nya dalam satu perintah adalah use case ideal Docker Compose.
- Tidak butuh infrastruktur tambahan: tidak perlu cluster, tidak perlu Control Plane, tidak perlu Node — cukup satu mesin dengan Docker terinstal.
- Hot reload yang mudah: volume mounting untuk live code reloading saat development sangat mudah dikonfigurasi, mempercepat feedback loop developer secara signifikan.
- Reproduksi bug yang konsisten: tim dapat berbagi file docker-compose.yml untuk memastikan semua developer menjalankan environment yang identik, mengeliminasi masalah 'works on my machine'.
- Startup yang sangat cepat: seluruh stack bisa berjalan dalam 10-30 detik, jauh lebih cepat dari waktu yang dibutuhkan untuk memulai cluster Kubernetes.
❌ Kekurangan Docker Compose
- Terbatas pada satu mesin: Docker Compose tidak bisa mendistribusikan container ke beberapa server secara native — seluruh stack harus berjalan di satu host.
- Tidak ada self-healing otomatis: jika sebuah container crash, Docker Compose bisa me-restart-nya (dengan restart policy), tetapi tidak memiliki kemampuan health-aware scheduling seperti Kubernetes.
- Scaling sangat terbatas: docker compose scale menambah replika di satu mesin, namun tidak ada load balancing otomatis, health check yang canggih, atau distribusi ke node lain.
- Tidak ada rolling update: memperbarui aplikasi dengan Docker Compose menyebabkan downtime singkat karena container lama harus dihentikan sebelum yang baru dimulai.
- Manajemen secret yang primitif: Docker Compose mendukung secrets, tetapi jauh kurang canggih dibanding Secret Kubernetes yang terintegrasi dengan RBAC dan enkripsi.
- Tidak production-ready untuk skala besar: begitu traffic tumbuh dan kebutuhan high availability muncul, keterbatasan Docker Compose akan terasa sangat nyata.
📄 Anatomi docker-compose.yml yang Umum Digunakan
# docker-compose.yml — Stack aplikasi web modern
version: "3.9"
services:
# ── FRONTEND ──────────────────────────────────────────────
frontend:
build:
context: ./frontend
dockerfile: Dockerfile.dev
ports:
- "3000:3000"
volumes:
- ./frontend/src:/app/src # Hot reload: perubahan kode langsung terlihat
environment:
- REACT_APP_API_URL=http://localhost:8000
depends_on:
- backend
# ── BACKEND API ───────────────────────────────────────────
backend:
build: ./backend
ports:
- "8000:8000"
volumes:
- ./backend:/app
environment:
- DATABASE_URL=postgresql://user:pass@db:5432/appdb
- REDIS_URL=redis://cache:6379
depends_on:
db:
condition: service_healthy # Tunggu DB benar-benar siap
cache:
condition: service_started
restart: unless-stopped
# ── DATABASE ──────────────────────────────────────────────
db:
image: postgres:15-alpine
volumes:
- postgres_data:/var/lib/postgresql/data # Data persisten
environment:
POSTGRES_USER: user
POSTGRES_PASSWORD: pass
POSTGRES_DB: appdb
healthcheck:
test: ["CMD-SHELL", "pg_isready -U user -d appdb"]
interval: 10s
timeout: 5s
retries: 5
# ── CACHE ─────────────────────────────────────────────────
cache:
image: redis:7-alpine
volumes:
- redis_data:/data
restart: unless-stopped
volumes:
postgres_data:
redis_data:
Kapan Harus Beralih ke Kubernetes?
Migrasi dari Docker Compose ke Kubernetes adalah keputusan strategis yang harus didasarkan pada kebutuhan nyata, bukan tren teknologi. Kubernetes membawa kompleksitas yang nyata — kurva belajar yang curam, overhead operasional yang signifikan, dan kebutuhan keahlian khusus di tim. Investasi tersebut hanya sepadan jika Anda menghadapi masalah yang memang hanya bisa diselesaikan oleh Kubernetes.
🚨 Sinyal Kuat Bahwa Anda Sudah Butuh Kubernetes
- Traffic tidak terprediksi dan sering lonjakan: jika aplikasi Anda mengalami perbedaan traffic 10x antara peak dan off-peak, kemampuan auto-scaling Kubernetes akan menghemat biaya infrastruktur secara signifikan.
- Kebutuhan zero-downtime deployment: jika downtime saat update sudah tidak bisa ditoleransi oleh bisnis — baik karena SLA, regulasi, atau ekspektasi pengguna — rolling update Kubernetes adalah solusinya.
- Arsitektur microservice dengan banyak komponen: mengelola 10+ service yang saling bergantung dengan Docker Compose di satu mesin menjadi mimpi buruk operasional yang Kubernetes selesaikan dengan elegan.
- Tim engineering yang tumbuh: ketika banyak developer mendeploy ke environment yang sama secara bersamaan, namespace, RBAC, dan GitOps Kubernetes memberikan governance yang Docker Compose tidak bisa berikan.
- Kebutuhan high availability dan fault tolerance: jika satu server down tidak boleh menyebabkan seluruh layanan mati, distribusi workload Kubernetes ke beberapa Node adalah kebutuhan mutlak.
- Workload yang heterogen: menjalankan job batch, cron job, daemon process, dan web service dalam infrastruktur yang sama dengan kebijakan scheduling yang berbeda — Kubernetes menangani ini secara native.
🟢 Situasi di Mana Docker Compose Masih Pilihan Terbaik
- Development environment lokal: hampir tidak ada alasan menggunakan Kubernetes lokal untuk development sehari-hari jika Docker Compose sudah mencukupi kebutuhan Anda.
- Aplikasi internal dengan traffic rendah dan stabil: tool internal, dashboard admin, atau aplikasi B2B dengan pengguna terbatas tidak membutuhkan kompleksitas Kubernetes.
- Proyek solo atau tim sangat kecil (1-3 orang): overhead operasional Kubernetes tidak sebanding dengan manfaatnya jika tidak ada tim dedicated untuk mengelolanya.
- MVP atau proof of concept: saat memvalidasi ide produk, kecepatan iterasi jauh lebih penting dari skalabilitas — selesaikan product-market fit dulu, skalakan kemudian.
- Budget infrastruktur sangat terbatas: cluster Kubernetes minimum yang layak membutuhkan setidaknya 3 Node — biayanya bisa 3-5x lebih mahal dari satu VPS Docker Compose.
Tabel Perbandingan Lengkap
Berikut perbandingan komprehensif antara Docker Compose dan Kubernetes dari berbagai dimensi yang paling relevan untuk pengambilan keputusan. Gunakan tabel ini sebagai referensi cepat saat Anda atau tim sedang mendiskusikan pilihan teknologi untuk proyek baru.
| Dimensi | 🐳 Docker Compose | ☸️ Kubernetes |
|---|---|---|
| Kurva belajar | ⭐ Sangat mudah, bisa produktif dalam 1 jam | ⭐⭐⭐⭐ Curam, butuh beberapa minggu hingga bulan |
| Skala deployment | Single machine (1 server) | Multi-node cluster (banyak server) |
| Self-healing | Terbatas (restart policy saja) | Penuh otomatis (reschedule, replace, restart) |
| Auto-scaling | Tidak ada | HPA, VPA, dan Cluster Autoscaler |
| Rolling update | Tidak ada (ada downtime) | Native, zero-downtime |
| Load balancing | Dasar (round-robin internal) | Canggih dengan Service & Ingress |
| High availability | Tidak ada | Built-in multi-node failover |
| Manajemen secret | Dasar | Canggih dengan RBAC & enkripsi |
| Networking | Bridge network sederhana | CNI plugin yang powerful & fleksibel |
| Storage | Volume lokal saja | PV/PVC multi-provider (cloud & lokal) |
| Monitoring bawaan | Tidak ada | Terintegrasi dengan Prometheus stack |
| RBAC & Governance | Tidak ada | Role-Based Access Control granular |
| Biaya operasional | Rendah — satu file YAML | Tinggi — butuh keahlian khusus |
| Biaya infrastruktur | Murah — satu VPS sudah cukup | Lebih mahal — minimal 3 Node |
| Cocok untuk | Dev lokal, proyek kecil, MVP | Produksi skala menengah-besar |
| Waktu setup awal | 5-10 menit | 30 menit - beberapa jam |
🔄 Tips Migrasi: Dari Docker Compose ke Kubernetes
Jika Anda sudah memutuskan untuk bermigrasi, kabar baiknya adalah
ada tools yang bisa mempercepat proses konversi file docker-compose.yml
menjadi manifest Kubernetes:
# ── KOMPOSE: Konversi docker-compose.yml ke Kubernetes YAML ──
# Install Kompose
brew install kompose # macOS
# atau
curl -L https://github.com/kubernetes/kompose/releases/latest/download/kompose-linux-amd64 -o kompose && chmod +x kompose && sudo mv kompose /usr/local/bin/
# Konversi docker-compose.yml ke manifest Kubernetes
kompose convert
# Output: file YAML Kubernetes untuk setiap service
# frontend-deployment.yaml
# frontend-service.yaml
# backend-deployment.yaml
# backend-service.yaml
# db-deployment.yaml (⚠️ perlu diubah ke StatefulSet secara manual)
# Langsung deploy hasil konversi ke cluster
kompose up
# ── LANGKAH MIGRASI YANG DIREKOMENDASIKAN ─────────────────
# 1. Gunakan kompose convert sebagai starting point, bukan hasil akhir
# 2. Review dan sesuaikan setiap file YAML — kompose tidak selalu sempurna
# 3. Ubah Deployment database menjadi StatefulSet dengan PersistentVolumeClaim
# 4. Pindahkan environment variables sensitif ke Kubernetes Secret
# 5. Tambahkan resource limits, liveness probe, dan readiness probe
# 6. Uji di environment staging sebelum migrasi production
- Jangan terburu-buru bermigrasi: Docker Compose yang stabil dan berfungsi baik jauh lebih baik dari Kubernetes yang dikelola dengan buruk. Migrasi hanya saat kebutuhan nyata sudah ada.
- Pertahankan docker-compose.yml untuk development lokal bahkan setelah migrasi ke Kubernetes production — keduanya bisa dan sebaiknya hidup berdampingan.
- Mulai dengan satu service non-kritis: jangan migrasi semua sekaligus. Pindahkan satu service terlebih dahulu, pelajari pola dan tantangannya, lalu terapkan ke service berikutnya.
- Dokumentasikan setiap keputusan migrasi: tulis Architecture Decision Record (ADR) yang menjelaskan mengapa setiap perubahan dilakukan — sangat berharga untuk onboarding anggota tim baru.
Ingat prinsip yang paling penting: gunakan tool yang tepat untuk masalah yang tepat. Docker Compose dan Kubernetes bukan kompetitor — mereka adalah tools yang saling melengkapi dalam ekosistem yang sama. Banyak tim engineering profesional menggunakan Docker Compose untuk development lokal setiap hari, sambil menjalankan Kubernetes di production. Itu bukan inkonsistensi — itu adalah pragmatisme engineering yang baik.
Kesimpulan
Rangkuman Perjalanan Belajar Kubernetes Anda
Selamat — Anda telah menyelesaikan perjalanan dari memahami apa itu Kubernetes, mempelajari arsitekturnya secara mendalam, hingga mempraktikkan deployment nyata lengkap dengan monitoring dan best practices produksi. Kubernetes memang bukan teknologi yang bisa dikuasai dalam semalam, tetapi setiap konsep yang Anda pelajari hari ini adalah investasi yang akan terus memberikan nilai selama bertahun-tahun karier engineering Anda ke depan.
- Kubernetes adalah platform container orchestration open-source yang mengotomatiskan deployment, scaling, dan manajemen aplikasi — lahir dari pengalaman Google mengelola miliaran container menggunakan sistem internal Borg.
- Arsitektur Kubernetes terdiri dari Control Plane (API Server, etcd, Scheduler, Controller Manager) dan Worker Node (Kubelet, Kube-proxy, Container Runtime) yang bekerja bersama melalui reconciliation loop untuk menjaga desired state.
- Objek-objek utama Kubernetes — Pod, Deployment, Service, Namespace, ConfigMap, Secret, dan Ingress — adalah kosakata dasar yang perlu dikuasai untuk bisa mendefinisikan dan mengelola workload secara deklaratif.
- Persiapan lingkungan lokal dengan kubectl dan Minikube adalah langkah awal yang krusial, dengan alternatif seperti Kind, k3s, dan Docker Desktop yang masing-masing memiliki keunggulan untuk use case berbeda.
- Tutorial step-by-step dari membuat Pod pertama, Deployment dengan self-healing, scaling dengan HPA, hingga rolling update dan rollback zero-downtime adalah siklus deployment yang digunakan engineer profesional setiap harinya.
- Tiga contoh deployment nyata — aplikasi Nginx dengan ConfigMap, Node.js dengan MySQL StatefulSet, dan microservice multi-tier dengan Redis — mencerminkan pola arsitektur yang paling umum ditemui di lingkungan produksi.
- Menguasai perintah kubectl secara mendalam — dari monitoring status, manajemen resource, hingga debugging sistematis — adalah keterampilan sehari-hari yang membedakan engineer Kubernetes junior dan senior.
- Managed Kubernetes Services (GKE, EKS, AKS) menghilangkan beban operasional Control Plane sehingga tim bisa fokus pada aplikasi, dengan GKE sebagai pilihan termudah untuk pemula dan EKS untuk ekosistem AWS yang dalam.
- Best practices seperti resource limits, pemisahan namespace, GitOps dengan ArgoCD, dan monitoring dengan Prometheus-Grafana adalah fondasi yang harus diterapkan sejak awal — jauh lebih mudah daripada memperbaikinya di kemudian hari.
- Docker Compose dan Kubernetes bukan kompetitor — gunakan Docker Compose untuk development lokal dan proyek kecil, beralih ke Kubernetes saat kebutuhan high availability, auto-scaling, dan multi-node deployment sudah nyata ada.
- Sertifikasi CKA, CKAD, dan CKS dari Linux Foundation adalah jalur validasi kemampuan Kubernetes yang diakui industri secara global, dengan format ujian berbasis performa langsung di cluster nyata.
Langkah terbaik setelah membaca artikel ini adalah langsung membuka terminal dan mempraktikkan setiap contoh yang telah disajikan. Mulai dari menjalankan cluster Minikube pertama Anda, mendeploy aplikasi sederhana, hingga bereksperimen dengan self-healing dan rolling update. Dokumentasi resmi Kubernetes di href="https://kubernetes.io/docs" target="_blank" rel="noopener noreferrer" class="text-blue-500 hover:text-blue-600 font-medium underline underline-offset-2 transition-colors" > kubernetes.io/docs adalah referensi terlengkap yang selalu bisa Anda andalkan, dan komunitas Kubernetes di Slack, Reddit, serta Stack Overflow adalah tempat yang ramah untuk bertanya saat menemui hambatan. Selamat belajar — dunia cloud-native menanti Anda! 🚀