Apa itu Kubernetes? #

Dalam lanskap pengembangan perangkat lunak modern, kita sering kali mendengar istilah kontainerisasi dan orkestrasi kontainer. Jika kita sudah terbiasa membungkus aplikasi ke dalam kontainer menggunakan Docker, kita mungkin berpikir bahwa tugas kita sudah selesai. Namun, menjalankan kontainer di komputer lokal sangatlah berbeda dengan mengelola ratusan kontainer yang saling terhubung di puluhan server produksi yang tersebar di berbagai pusat data. Di sinilah Kubernetes hadir sebagai penyelamat.

Kubernetes (sering disingkat sebagai K8s, di mana angka 8 menggantikan delapan huruf antara “K” dan “s”) adalah platform sumber terbuka (open-source) yang dirancang khusus untuk mengotomatisasi deployment, penskalaan (scaling), dan pengelolaan kontainer aplikasi. Kubernetes bertindak sebagai kapten kapal yang mengoordinasikan seluruh kontainer agar berjalan secara harmonis, efisien, dan tanpa henti.

Evolusi Arsitektur Infrastruktur IT #

Untuk benar-benar memahami mengapa kita membutuhkan Kubernetes, kita harus melihat bagaimana cara industri mengelola infrastruktur server berevolusi selama beberapa dekade terakhir. Perjalanan ini dibagi menjadi empat era utama:

flowchart TD
    subgraph Era_1 ["1. Era Bare-Metal (Server Fisik)"]
        direction TB
        A1["Satu OS Langsung di Hardware"] --> A2["Satu Aplikasi Mendominasi Resource"]
        A2 --> A3["Konflik Dependensi & Provisioning Lambat"]
    end

    subgraph Era_2 ["2. Era Virtualisasi (VM)"]
        direction TB
        B1["Hypervisor Membagi Satu Fisik ke Banyak VM"] --> B2["Setiap VM Memiliki OS Sendiri (Guest OS)"]
        B2 --> B3["Isolasi Aman tapi Overhead OS Sangat Tebal"]
    end

    subgraph Era_3 ["3. Era Kontainerisasi (Docker)"]
        direction TB
        C1["Isolasi Tingkat OS (Namespace & Cgroups)"] --> C2["Berbagi Kernel Host OS yang Sama"]
        C2 --> C3["Ringan, Boot Cepat, dan Sangat Portabel"]
    end

    subgraph Era_4 ["4. Era Orkestrasi (Kubernetes)"]
        direction TB
        D1["Mengelola Kluster Server (Banyak VM/Fisik)"] --> D2["Otomatisasi Penempatan, Healing, & Scaling"]
        D2 --> D3["Infrastruktur Deklaratif Berskala Produksi"]
    end

    Era_1 --> Era_2
    Era_2 --> Era_3
    Era_3 --> Era_4

    style Era_1 stroke:#7f8c8d,stroke-width:2px
    style Era_2 stroke:#2980b9,stroke-width:2px
    style Era_3 stroke:#27ae60,stroke-width:2px
    style Era_4 stroke:#8e44ad,stroke-width:2px

1. Era Bare-Metal (Server Fisik) #

Pada awalnya, organisasi menjalankan aplikasi di atas server fisik. Di era ini, satu sistem operasi dijalankan langsung di atas perangkat keras. Kelemahan terbesar dari pendekatan ini adalah ketidakmampuan untuk membatasi alokasi resource bagi setiap aplikasi. Jika kita menjalankan aplikasi A dan aplikasi B di server yang sama, dan aplikasi A mengalami kebocoran memori (memory leak), maka aplikasi B akan ikut kehabisan resource dan mati. Solusi saat itu adalah menjalankan satu aplikasi per server fisik, yang berujung pada pemborosan biaya investasi perangkat keras (CapEx) karena utilisasi server rata-rata sangat rendah.

2. Era Virtualisasi (Virtual Machine) #

Sebagai solusi atas kelemahan bare-metal, teknologi virtualisasi diperkenalkan. Dengan bantuan Hypervisor, kita bisa membagi satu server fisik menjadi beberapa Virtual Machine (VM). Setiap VM bertindak sebagai komputer independen yang memiliki sistem operasi sendiri (Guest OS), CPU virtual, memori, dan storage. Virtualisasi meningkatkan utilisasi perangkat keras secara drastis dan memberikan isolasi keamanan yang sangat baik antar aplikasi. Namun, VM memiliki kelemahan inheren: setiap VM sangat tebal (membutuhkan beberapa gigabyte ruang penyimpanan untuk OS-nya sendiri) dan membutuhkan waktu booting yang lama (beberapa menit) karena OS harus melakukan inisialisasi kernel secara penuh.

3. Era Kontainerisasi #

Kontainer hadir sebagai alternatif virtualisasi yang jauh lebih ringan. Berbeda dengan VM yang memisahkan perangkat keras, kontainer melakukan isolasi di tingkat sistem operasi (menggunakan fitur kernel Linux seperti namespaces dan control groups atau cgroups). Kontainer-kontainer yang berjalan di satu server fisik akan berbagi kernel sistem operasi host yang sama. Hal ini membuat kontainer sangat ringan (ukurannya sering kali hanya puluhan megabyte) dan dapat melakukan booting secara instan (dalam hitungan milidetik). Portabilitas kontainer memastikan bahwa apa yang kita jalankan di laptop pengembang akan berjalan dengan perilaku yang persis sama di server staging maupun produksi.

4. Era Orkestrasi Kontainer (Kubernetes) #

Kontainer memang luar biasa, namun ketika aplikasi kita mulai dipecah menjadi puluhan microservices yang dideploy ke dalam ratusan kontainer di puluhan mesin server, kita menghadapi masalah kompleksitas baru. Kita membutuhkan sistem untuk mengelola daur hidup kontainer tersebut secara terpusat: mesin server mana yang kosong untuk menjalankan kontainer baru? Bagaimana jika satu mesin server mati secara fisik? Bagaimana cara mendistribusikan traffic pengguna secara merata ke seluruh kontainer? Kebutuhan inilah yang memicu lahirnya era orkestrasi kontainer dengan Kubernetes sebagai pemimpin utamanya.

Sejarah dan DNA di Balik Kubernetes #

Kubernetes bukanlah proyek yang dibuat secara terburu-buru. Platform ini memiliki DNA yang sangat matang karena lahir dari pengalaman operasional berskala raksasa milik Google. Selama lebih dari satu dekade sebelum Kubernetes dirilis, Google telah mengelola seluruh beban kerja mereka — mulai dari Gmail, Google Search, hingga YouTube — menggunakan sistem orkestrasi internal yang sangat rahasia bernama Borg, yang kemudian berevolusi menjadi proyek Omega.

Borg bertugas mengelola jutaan tugas komputasi dan meluncurkan miliaran kontainer setiap minggunya di seluruh pusat data Google. Ketika teknologi kontainer mulai naik daun di industri umum (terutama setelah Docker diluncurkan ke publik pada tahun 2013), Google menyadari bahwa industri membutuhkan alat orkestrasi standar yang dirancang berdasarkan pelajaran yang mereka petik selama mengembangkan Borg.

Pada tahun 2014, sekelompok insinyur Google (termasuk Joe Beda, Brendan Burns, dan Craig McLuckie, dibantu oleh arsitek Borg lainnya) mengumumkan proyek Kubernetes sebagai versi open-source yang didesain ulang dari awal menggunakan bahasa pemrograman Go.

Untuk memastikan keberlangsungan dan netralitas proyek ini, Google bekerja sama dengan Linux Foundation untuk mendirikan Cloud Native Computing Foundation (CNCF) pada tahun 2015, dan menyumbangkan Kubernetes sebagai proyek benih (seed project) pertamanya. Saat ini, Kubernetes dikelola oleh komunitas global yang terdiri dari ribuan kontributor dan didukung oleh raksasa teknologi dunia, menjadikannya standar baku platform cloud-native modern.

Peran Utama Kubernetes dalam Daur Hidup Aplikasi #

Sebagai sebuah orkestrator, Kubernetes mengambil alih seluruh tugas operasional yang melelahkan dari tangan tim engineer. Secara konkret, berikut adalah peran-peran utama yang dijalankan Kubernetes untuk menjaga keandalan aplikasi kita di produksi:

1. Pensejadwalan Pintar (Smart Scheduling) #

Ketika kita meminta Kubernetes untuk menjalankan sebuah aplikasi, Kubernetes tidak akan menempatkannya secara acak. API Server akan berkoordinasi dengan Scheduler untuk menganalisis status kapasitas seluruh node dalam cluster. Kubernetes akan memilih node yang paling cocok berdasarkan kebutuhan CPU/Memory kontainer, kebijakan afinitas (affinity), serta batasan-batasan jaringan dan storage yang kita definisikan.

2. Pemulihan Mandiri (Self-Healing) #

Kubernetes berasumsi bahwa kegagalan infrastruktur adalah hal yang pasti terjadi. Jika sebuah kontainer mati karena error kode program (crash), Kubernetes akan langsung mendeteksi dan merestart kontainer tersebut. Lebih jauh lagi, jika seluruh mesin server (node) mengalami kegagalan fisik (misalnya mati listrik), Kubernetes secara otomatis akan memindahkan dan menjadwalkan ulang seluruh kontainer yang berada di node rusak tersebut ke node lain yang masih sehat.

3. Penskalaan Otomatis (Horizontal Scaling) #

Kita tidak perlu lagi melakukan pemantauan traffic secara manual untuk menambah server di jam sibuk. Melalui Horizontal Pod Autoscaler (HPA), Kubernetes secara kontinu memantau metrik penggunaan CPU, memori, atau bahkan custom metrik dari aplikasi kita. Jika beban kerja melewati batas ambang (threshold) yang kita tentukan, Kubernetes akan langsung membuat replika kontainer baru dalam hitungan detik. Sebaliknya, saat traffic menurun, kontainer tambahan akan dihapus untuk menghemat biaya infrastruktur.

4. Penemuan Layanan dan Load Balancing (Service Discovery & Load Balancing) #

Di Kubernetes, kontainer bersifat dinamis dan dapat berpindah node kapan saja, yang berarti IP address kontainer akan selalu berubah. Kubernetes memecahkan masalah ini dengan memberikan nama DNS yang stabil untuk sekumpulan kontainer. Kubernetes juga memiliki load balancer internal untuk mendistribusikan traffic secara merata ke seluruh replika kontainer yang sedang sehat.

5. Manajemen Konfigurasi dan Rahasia (Config & Secret Management) #

Kubernetes memungkinkan kita untuk menyimpan konfigurasi lingkungan aplikasi (seperti database URL) di dalam objek ConfigMap dan data sensitif (seperti password, API keys, dan SSL certificate) di dalam objek Secret. Informasi ini dapat di-inject secara dinamis ke dalam kontainer saat runtime sebagai environment variables atau di-mount sebagai file, tanpa perlu membakarnya ke dalam image kontainer.

Model Deklaratif vs Model Imperatif #

Salah satu rahasia kekuatan Kubernetes terletak pada penggunaan Model Deklaratif (Declarative Model). Untuk memahami perbedaannya, mari kita bandingkan dengan Model Imperatif (Imperative Model) yang biasa kita gunakan pada skrip tradisional.

Model Imperatif (Bagaimana Cara Mencapainya):
  "SSH ke server-1, unduh image versi 2, hentikan kontainer lama, jalankan kontainer baru, 
   pastikan port terbuka. Jika gagal di tengah jalan, kirim alert dan biarkan sistem rusak."

Model Deklaratif (Keadaan Akhir yang Diinginkan):
  "Saya ingin sistem selalu berada dalam keadaan: berjalan 3 replika aplikasi X 
   menggunakan image versi 2 di port 80."

Pada model deklaratif, kita hanya menuliskan dokumen YAML yang mendefinisikan Desired State (Keadaan yang Diinginkan). Dokumen ini kemudian kita kirimkan ke Kubernetes API Server. Tugas kita selesai di sana.

Kubernetes kemudian akan menjalankan mekanisme yang disebut Reconciliation Loop (Loop Rekonsiliasi) secara terus-menerus. Loop kontrol ini bekerja dengan alur sebagai berikut:

flowchart TD
    A["Mulai Loop (Control Loop)"] --> B["Amati Keadaan Aktual (Actual State)"]
    B --> C["Bandingkan dengan Keadaan yang Diinginkan (Desired State)"]
    C --> D{Apakah Keduanya Sama?}
    D -- Ya --> E["Tidur sejenak (Loop Kembali ke Awal)"]
    D -- Tidak --> F["Lakukan Tindakan Korektif (Koreksi Selisih)"]
    F --> B

Contoh Nyata Loop Rekonsiliasi: #

  1. Desired State: 3 replika Pod aplikasi pembayaran harus berjalan.
  2. Actual State: Kubernetes mendeteksi hanya ada 2 Pod yang berjalan karena 1 Pod mati akibat OOM (Out Of Memory).
  3. Tindakan Korektif: Controller Manager mendeteksi selisih tersebut dan memerintahkan scheduler untuk segera membuat 1 Pod baru di node yang memiliki kapasitas memori kosong.
  4. Hasil Akhir: Keadaan aktual kembali selaras dengan keadaan yang diinginkan.

Dengan model ini, infrastruktur kita menjadi sangat tangguh karena Kubernetes secara otomatis memperbaiki setiap deviasi yang terjadi tanpa perlu campur tangan manusia.

Menghapus Kebingungan: Kubernetes vs Docker #

Bagi pemula yang baru memasuki ekosistem cloud-native, sering kali muncul pertanyaan: “Mana yang lebih baik, Kubernetes atau Docker?” Ini adalah pertanyaan yang kurang tepat karena keduanya berada di lapisan teknologi yang berbeda dan saling melengkapi.

  • Docker adalah alat untuk membuat paket aplikasi beserta dependensinya ke dalam satu unit kontainer standar, serta menjalankannya di sebuah mesin.
  • Kubernetes adalah orkestrator yang mengelola jalannya kontainer-kontainer tersebut di sebuah kluster yang terdiri dari banyak mesin.

Untuk analogi yang mudah dipahami:

  • Docker adalah mobil, sedangkan Kubernetes adalah pengatur lalu lintas kota.
  • Docker adalah musisi, sedangkan Kubernetes adalah konduktor orkestra.
  • Docker adalah kontainer kargo fisik, sedangkan Kubernetes adalah pelabuhan peti kemas beserta alat berat dan sistem logistiknya.

Peran Container Runtime Interface (CRI) #

Perlu dicatat bahwa Kubernetes tidak terikat eksklusif pada Docker. Kubernetes berkomunikasi dengan mesin kontainer melalui standar API terbuka yang disebut Container Runtime Interface (CRI).

Sejak versi 1.24, Kubernetes telah menghapus dukungan langsung untuk mesin Docker secara bawaan (depresiasi dockershim) demi efisiensi. Namun, ini tidak berarti kita tidak bisa lagi menggunakan Docker. Image kontainer yang kita build menggunakan Docker mematuhi standar Open Container Initiative (OCI), yang berarti image tersebut dapat dijalankan dengan sempurna di Kubernetes menggunakan runtime modern yang lebih ringan dan dikhususkan untuk orkestrasi seperti containerd atau CRI-O.

Anti-Pattern: Mengobati Kubernetes Seperti Mesin Virtual (VM) #

Salah satu kesalahan paling fatal yang sering dilakukan oleh tim yang baru bermigrasi ke Kubernetes adalah memperlakukan Pod (kontainer) seperti layaknya Virtual Machine tradisional.

ANTI-PATTERN:
// KITA MELAKUKAN:
- Masuk ke dalam Pod menggunakan perintah `kubectl exec -it` untuk mengedit konfigurasi secara langsung.
- Mengunggah file konfigurasi database atau static assets ke dalam filesystem Pod.
- Mengabaikan fakta bahwa Pod dapat dihapus, mati, atau berpindah kapan saja (ephemeral).
// AKIBATNYA:
- Ketika Pod tersebut direstart atau berpindah node oleh scheduler, seluruh perubahan manual 
  dan data di dalamnya akan hilang selamanya.
- Deployment kita tidak konsisten dan tidak dapat direproduksi secara deklaratif.

✓ SOLUSI YANG BENAR:
- Selalu perlakukan kontainer sebagai entitas sementara (*ephemeral* / *stateless*).
- Jika ingin mengubah konfigurasi, ubahlah di file manifest YAML `ConfigMap` atau `Secret`, lalu lakukan deployment ulang.
- Jika ingin menyimpan data persisten (seperti file upload pengguna atau data DB), gunakan objek `PersistentVolumeClaim` (PVC).
- Seluruh pipeline deployment harus berjalan otomatis melalui deklarasi manifest, bukan konfigurasi manual ad-hoc di dalam container.

Ringkasan #

  • Kubernetes (K8s) adalah platform orkestrasi kontainer — bertugas mengotomatisasi deployment, penskalaan, dan pemulihan kontainer aplikasi secara terpusat di sebuah kluster server.
  • DNA Google Borg — dirancang berdasarkan pengalaman Google selama lebih dari 10 tahun dalam mengelola miliaran kontainer menggunakan sistem internal Borg.
  • Kekuatan Model Deklaratif — kita mendefinisikan desired state aplikasi kita, dan Kubernetes akan terus melakukan reconciliation loop untuk memastikan actual state kluster selalu selaras.
  • Kubernetes dan Docker Saling Melengkapi — Docker digunakan untuk membungkus aplikasi menjadi kontainer, sedangkan Kubernetes digunakan untuk mengoperasikan kontainer tersebut di skala produksi.
  • Hindari VM Mentality — kontainer di Kubernetes bersifat sementara (ephemeral). Semua konfigurasi harus dideklarasikan di manifest YAML, bukan dikonfigurasi manual di dalam kontainer yang sedang berjalan.

← Sebelumnya: Pengenalan   Berikutnya: Problem yang Diselesaikan →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact