Perbandingan Distribusi Kubernetes untuk Homelab dengan 3 Node

Memilih varian Kubernetes terbaik untuk homelab kami

Konten Halaman

Saya sedang membandingkan variasi Kubernetes self-hosted yang cocok untuk homelab berbasis Ubuntu dengan 3 node (16 GB RAM, 4 inti CPU masing-masing), dengan fokus pada kemudahan pengaturan dan pemeliharaan, dukungan untuk persistent volumes dan LoadBalancers.

Skenario: Kami memiliki tiga node Ubuntu (16 GB RAM, 4 inti CPU masing-masing) dalam sebuah homelab. Ketersediaan high-availability (HA) dan dukungan ARM bukan prioritas. Kami ingin klaster Kubernetes yang mudah diinstal dan sedikit pemeliharaan (baik single-node maupun 3-node) dengan dukungan untuk Persistent Volumes (PV) dan LoadBalancer (LB) (sehingga aplikasi native cloud yang memerlukan penyimpanan atau IP eksternal berjalan lancar). Kami akan fokus pada opsi klaster 3-node tanpa kebutuhan HA atau kompatibilitas CPU ARM.

kubernetes homelab

Di bawah ini kami membandingkan distribusi Kubernetes ringan yang populer: [Kubernetes(https://www.glukhov.org/id/post/2024/10/kubernetes-cheatsheet/ “daftar dan deskripsi perintah k8s yang paling sering dan berguna - k8s cheatsheet”) distribusi – K3s, MicroK8s, Minikube, dan kubeadm (Kubernetes vanilla) – dan bagaimana mereka berdiri di kriteria utama (fitur, instalasi/pemeliharaan, dukungan PV/LB, kebutuhan sumber daya, pengaturan klaster, dan alat). Kami juga memiliki beberapa rekomendasi untuk memilih berdasarkan skenario homelab.

K3s (Kubernetes Ringan oleh Rancher)

Fitur Utama: K3s adalah distribusi Kubernetes yang disertifikasi CNCF yang dirancang untuk penggunaan sumber daya minimal (dapat berjalan dengan hanya 512 MB RAM). Ia mengemas seluruh control plane Kubernetes ke dalam satu binary dan proses, menggunakan komponen ringan (misalnya, SQLite sebagai default datastore alih-alih etcd, flannel untuk jaringan). Ia mencakup default yang masuk akal seperti controller ingress bawaan (Traefik) dan load balancer sederhana. K3s menghilangkan fitur legacy/alpha untuk mengurangi kelebihan.

  • Kemudahan Instalasi & Pemeliharaan: Sangat sederhana – kita dapat menginstalnya dengan satu baris perintah (curl ... | sh) atau melalui alat seperti K3sup. Server akan langsung berjalan dengan komponen default. Menambahkan node sangat mudah (jalankan agen K3s dengan token dari server). Pembaruan mudah (ganti binary atau gunakan skrip instalasi untuk versi baru). Tidak diperlukan konfigurasi etcd terpisah (kecuali jika memilih pengaturan multi-master HA). K3s dirancang untuk memerlukan sedikit sekali perubahan setelah diinstal, membuatnya populer untuk IoT dan homelab.

  • Dukungan Persistent Volume: Bawaan. Secara default, K3s datang dengan local-path StorageClass milik Rancher, yang secara dinamis menyediakan PV di filesystem host untuk setiap PVC. Ini berarti setiap PVC akan terpenuhi dengan membuat volume hostPath secara otomatis di node. Ini adalah solusi penyimpanan single-node (setiap volume berada di disk satu node), tetapi berjalan dengan baik secara default untuk aplikasi stateful. Untuk penyimpanan yang lebih canggih, kita dapat menambahkan sesuatu seperti Longhorn milik Rancher (penyimpanan block distributed) yang didukung K3s, tetapi untuk homelab, penyedia local-path default biasanya sudah cukup.

  • Dukungan LoadBalancer: Bawaan. K3s menyertakan controller ringan yang disebut ServiceLB (dulunya “Klipper LB”) yang memungkinkan layanan tipe LoadBalancer mendapatkan IP/port di host tanpa penyedia cloud eksternal. Saat kita membuat layanan LoadBalancer, K3s mendeploy DaemonSet dari pod LB kecil (svc-...) di setiap node, yang menggunakan port host untuk mengarahkan lalu lintas ke layanan. Secara esensial, K3s memanfaatkan IP node (internal atau eksternal) untuk menjadi IP LB, dan menggunakan routing iptables di pod LB untuk mengirimkan lalu lintas ke ClusterIP layanan. Ini berjalan tanpa konfigurasi – layanan tidak akan tetap “pending” (berbeda dengan Kubernetes vanilla di bare metal). Pertukaran adalah bahwa IP eksternal LB akan menjadi salah satu IP node (atau semua node) dan kita harus memastikan port bebas. Untuk kebanyakan penggunaan homelab (mengunggah beberapa layanan di port HTTP/HTTPS), ini sudah cukup baik. Jika diperlukan, kita dapat menonaktifkan LB bawaan dan menginstal MetalLB secara manual, tetapi kebanyakan pengguna tetap menggunakan default yang nyaman.

  • Kebutuhan Sumber Daya: Sangat rendah. K3s bahkan dapat berjalan di perangkat keras rendah. Secara resmi, 512 MB RAM dan beberapa ratus MB disk sudah cukup untuk node server. Dalam praktiknya, klaster kecil mungkin hanya menggunakan beberapa ratus MB memori untuk control plane. Binary-nya kurang dari 100 MB. Overhead CPU minimal (K3s menggunakan sedikit lebih banyak CPU saat idle dibandingkan MicroK8s, tetapi tidak terlalu jauh). Node kami (16 GB masing-masing) lebih dari cukup untuk menjalankan K3s secara nyaman.

  • Single-Node vs Multi-Node: Cocok untuk keduanya. K3s dapat berjalan single-node (semua control-plane dan beban kerja di satu mesin) atau multi-node. Untuk pengaturan 3-node, kita mungkin menjalankan 1 server (master) dan 2 agen, atau bahkan membuat semua 3 sebagai server untuk HA (tidak diperlukan di sini karena HA bukan tujuan). Bergabungnya agen sangat mudah dengan token. Datastore SQLite default K3s bekerja untuk single-server; untuk multi-server HA kita akan beralih ke etcd embedded (K3s dapat melakukannya secara otomatis saat memulai beberapa node server).

  • CLI & UI Tools: Kami berinteraksi dengan K3s seperti halnya Kubernetes – melalui kubectl. K3s menyertakan build kubectl sendiri (kita dapat menjalankan k3s kubectl ... atau hanya menggunakan kubectl standar dengan menunjuk ke kubeconfig K3s). Tidak ada CLI khusus K3s selain perintah instalasi; dirancang secara sengaja minimalis. Tidak ada UI web bawaan (Dashboard upstream tidak diinstal secara default). Namun, kita dapat secara manual menginstal Kubernetes Dashboard atau alat lain di K3s seperti klaster standar. Rancher (alat manajemen GUI oleh perusahaan yang sama) juga dapat diinstal di atas K3s jika UI penuh diinginkan, tetapi bukan bagian dari K3s itu sendiri. Secara esensial, K3s menyediakan API inti k8s dan kita menambahkan ekstra sesuai kebutuhan (ingress, penyimpanan, dll. – beberapa dari yang sudah dikemas seperti disebutkan).

MicroK8s (Kubernetes Low-Ops oleh Canonical)

Fitur Utama: MicroK8s adalah distribusi Kubernetes ringan oleh Canonical, disampaikan sebagai paket snap. Ia menginstal klaster Kubernetes yang sepenuhnya konforman (biner upstream) dengan satu perintah dan dirancang untuk kemudahan penggunaan (“low ops”) di satu mesin atau klaster kecil. Ia menekankan pendekatan “batteries-included” – kita mendapatkan banyak fitur opsional yang dapat diaktifkan dengan perintah sederhana. MicroK8s default ke pengalaman Kubernetes vanilla (semua API standar) tetapi dengan fitur tambahan yang nyaman untuk kebutuhan umum. Ia mendukung pengaturan single-node dan multi-node (kita dapat membentuk klaster dengan “menggabungkan” node), bahkan memiliki mode HA untuk control plane (menggunakan Dqlite – SQLite terdistribusi – saat kita memiliki 3 master).

  • Kemudahan Instalasi & Pemeliharaan: Sangat mudah juga – hanya snap install microk8s --classic di mesin Ubuntu akan mengatur node Kubernetes. Ini adalah satu paket yang mencakup semua komponen. MicroK8s dikelola melalui sistem snap Ubuntu, yang berarti pembaruan bersifat atomik dan dapat otomatis (kita dapat melacak saluran untuk versi Kubernetes). Kemampuan pembaruan otomatis ini unik di antara opsi ini – kita dapat memilih untuk mendapatkan patch keamanan dan pembaruan kecil melalui snap refresh. Pengelolaan MicroK8s dilakukan melalui perintah microk8s, yang memiliki subperintah untuk mengaktifkan/menonaktifkan fitur. Secara keseluruhan, ini sangat rendah hambatan: tidak ada container atau VM yang dikelola (berjalan secara native di host), dan tidak ada etcd eksternal yang dikonfigurasi (menggunakan datastore internal). Pemeliharaan hanyalah memperbarui snap saat diperlukan dan menggunakan microk8s.status untuk memantau.

  • Dukungan Persistent Volume: Tersedia melalui add-on. Secara default, MicroK8s tidak secara otomatis menyediakan PV sampai kita mengaktifkan add-on “hostpath-storage”. Mengaktifkan ini (dengan microk8s enable hostpath-storage) menciptakan StorageClass default yang mengalokasikan volume dari direktori di host. Ini secara esensial adalah penyedia hostPath dinamis, konsepnya mirip dengan local-path K3s. Setelah diaktifkan, setiap PVC akan terikat ke PV hostpath di node MicroK8s. (Di klaster MicroK8s multi-node, PV hostpath akan berada di satu node – cocok untuk pengujian atau penggunaan homelab tetapi bukan penyimpanan terdistribusi). MicroK8s juga menawarkan Mayastor dan add-on penyimpanan lainnya jika kita ingin penyimpanan yang lebih canggih di seluruh node, tetapi untuk kesederhanaan penyimpanan hostpath bekerja baik. Catatan: Add-on ini tidak diaktifkan secara default (untuk menjaga kekompakan), jadi kita akan ingin mengaktifkannya agar PVC berfungsi. Canonical mencatat ini bukan untuk penggunaan HA produksi (karena tidak direplikasi), tetapi untuk homelab ini sempurna.

  • Dukungan LoadBalancer: Tersedia melalui add-on. MicroK8s tidak menyertakan load balancer default, tetapi menyediakan MetalLB sebagai add-on yang mudah. Menjalankan microk8s enable metallb:<start-IP>-<end-IP> mendeploy MetalLB dalam mode Layer 2 dan memungkinkan kita menentukan pool IP dari LAN untuk digunakan oleh layanan LoadBalancer. Setelah diaktifkan, setiap layanan tipe LoadBalancer akan secara otomatis mendapatkan IP dari rentang tersebut (dan MicroK8s akan mengumumkannya melalui ARP di LAN). Ini memberikan pengalaman seperti di cloud pada bare metal. (Jika kita tidak mengaktifkan MetalLB, layanan LoadBalancer akan tetap pending, karena MicroK8s sendiri tidak mengimplementasikannya – seperti Kubernetes upstream.) Di homelab, MetalLB sederhana dan memungkinkan kita mengakses layanan di jaringan lokal. Kita akan perlu memilih subnet atau rentang IP gratis di jaringan kita untuk itu. Perintah enable MicroK8s membuat pengaturan mudah, tetapi tetap langkah terpisah. (Berbeda dengan K3s yang berjalan secara default untuk LB tetapi dengan keterbatasan menggunakan IP/node/port.) Banyak pengguna MicroK8s hanya mengaktifkan MetalLB sebagai bagian dari pengaturan awal mereka untuk mendapatkan LB yang berfungsi.

  • Kebutuhan Sumber Daya: MicroK8s cukup ringan, meskipun sedikit lebih besar dari K3s dalam ukuran. Ia menjalankan semua layanan inti (API server, controller, scheduler, kubelet, etcd atau Dqlite) secara native. Penggunaan idle biasanya sekitar 500–600 MB RAM untuk control plane, tergantung apa add-on yang diaktifkan. Canonical menyebutkan baseline memori sekitar 540 MB. Penggunaan CPU rendah saat idle, dan node kami dengan 16 GB memiliki banyak ruang. Kebutuhan ruang disk kecil (snap sekitar 200 MB plus data etcd). Secara keseluruhan, MicroK8s dapat berjalan di perangkat keras sederhana (bahkan ditawarkan untuk Raspberry Pi), dan dalam skenario kami mesin dengan mudah menampungnya. Jika beberapa add-on diaktifkan (dashboard, monitoring, dll.), penggunaan sumber daya akan meningkat sesuai.

  • Single-Node vs Multi-Node: MicroK8s bekerja baik untuk keduanya. Kita dapat menggunakan untuk klaster single-node (misalnya di mesin dev atau satu server) atau membuat klaster multi-node dengan “menggabungkan” node. Dokumentasi MicroK8s menyediakan perintah untuk menambahkan node (kita mengambil token join dari node pertama dan menggunakan di node lainnya). Dalam pengaturan multi-node tanpa HA, satu node akan menjadi control plane utama. Dengan 3 node, kita juga memiliki opsi untuk mengaktifkan ha-cluster mode (membuat control plane HA dengan menjalankan Dqlite di 3 node), meskipun dalam kasus kami HA tidak diperlukan. Baik single-node maupun tiga node, pengalaman API Kubernetes sama. MicroK8s multi-node sedikit lebih baru dari pendekatan K3s tetapi sekarang cukup stabil. Ini adalah pilihan yang baik jika kita ingin “micro cloud” dari beberapa box Ubuntu yang menjalankan k8s dengan sedikit usaha.

  • CLI & UI Tools: MicroK8s menyertakan microk8s alat baris perintah, yang sangat berguna. Misalnya, microk8s enable <addon> mengaktifkan/menonaktifkan berbagai layanan (DNS, ingress, penyimpanan, metallb, dashboard, dll.), dan microk8s status menunjukkan apa yang sedang berjalan. Ia juga menyertakan kubectl yang tertanam: kita dapat menggunakan microk8s kubectl ... (atau membuat alias) yang berbicara ke klaster – ini bagus karena kita tidak perlu mengkonfigurasi kubeconfig. Untuk UI, MicroK8s menyediakan Kubernetes Dashboard sebagai add-on (microk8s enable dashboard), yang akan mendeploy UI web standar. Setelah diaktifkan, kita dapat mengaksesnya (berjalan di port 10443 atau melalui proxy). MicroK8s tidak memiliki GUI khusus sendiri – bergantung pada Kubernetes Dashboard atau alat lain – tetapi kemudahan mengaktifkannya adalah plus. Secara keseluruhan, MicroK8s menekankan pengalaman satu perintah untuk tugas umum dan filosofi “it just works”, mengabstraksi banyak kompleksitas (dengan biaya menyembunyikan beberapa internal). Ini membuatnya sangat ramah untuk homelab bagi mereka yang ingin klaster Kubernetes tanpa pengaturan manual setiap komponen.

Perbandingan K3s vs MicroK8s: Keduanya cukup mirip dalam tujuan dan kemampuan – ringan, mudah, mampu multi-node. K3s cenderung sedikit lebih “DIY” saat menambahkan ekstra (bergantung pada Helm charts atau manifest manual untuk hal-hal yang tidak termasuk), sedangkan MicroK8s menawarkan add-on bawaan melalui CLI-nya. MicroK8s juga lebih “vanilla” Kubernetes di bawahnya (komponen upstream, hanya dikemas sebagai snap), sedangkan K3s menggunakan beberapa binary khusus dan satu layanan untuk segalanya. Keduanya adalah pilihan yang baik untuk homelab; keputusan sering kali tergantung pada preferensi: jika Ubuntu/snap dan rasa terintegrasi lebih disukai, MicroK8s hebat, sedangkan jika kita lebih menyukai pendekatan minimalis dengan sedikit kontrol manual lebih, K3s sangat baik. (Kami akan memberikan rekomendasi di akhir.)

Minikube (Klaster Lokal K8s Tunggal)

Fitur Utama: Minikube terutama merupakan alat untuk menjalankan Kubernetes secara lokal (seringkali di PC atau laptop pengembang) daripada klaster tradisional di beberapa mesin. Minikube menciptakan klaster Kubernetes tunggal dalam VM atau kontainer di mesin kita. Minikube dikenal karena dukungan luas terhadap lingkungan – dapat berjalan di Linux, macOS, Windows, dan mendukung berbagai hypervisor (VirtualBox, KVM, Hyper-V, driver Docker, dll.). Minikube dikelola oleh Kubernetes SIGs dan sering digunakan untuk pengujian dan pembelajaran. Meskipun Minikube dapat diatur untuk konfigurasi multi-node, sebenarnya dirancang untuk klaster satu node (mode “multi-node” Minikube sebenarnya hanya memulai beberapa node pada host yang sama menggunakan runtime kontainer – berguna untuk mensimulasikan klaster, tetapi bukan untuk menjalankan di mesin fisik terpisah).

  • Kemudahan Instalasi & Penggunaan: Minikube sangat mudah dimulai di satu mesin. Kita menginstal biner minikube, memastikan kita memiliki driver VM (atau Docker), dan menjalankan minikube start. Ini akan mengatur VM/kontainer lokal dan meluncurkan Kubernetes di dalamnya. Ini mungkin cara termudah untuk menjalankan klaster Kubernetes pertama kali. CLI (minikube) menyediakan perintah untuk berinteraksi dengan VM (mulai, berhenti, menghapus) dan mengaktifkan add-on. Karena Minikube dirancang untuk penggunaan lokal, bukan “daemon yang berjalan terus-menerus” – kita biasanya memulainya ketika dibutuhkan dan menghentikannya ketika selesai, meskipun kita dapat menjalankannya secara kontinu di server homelab jika diinginkan. Pemeliharaan/pembaruan mudah: hanya perlu memperbarui versi minikube dan me-restart klaster (Minikube juga dapat memperbarui versi Kubernetes yang dijalankannya dengan flag). Namun, satu keterbatasan adalah bahwa Minikube dirancang untuk satu node (menambahkan lebih banyak node berarti memulai instance VM tambahan di host yang sama, bukan bergabung dengan host fisik terpisah). Jadi, menggunakan Minikube di tiga node fisik terpisah akan berarti menjalankan tiga klaster tunggal independen, yang mungkin bukan yang kita inginkan. Minikube sangat cocok untuk pengembangan dan pengujian di satu mesin, tetapi bukan untuk mengelola klaster yang menyebar di beberapa server fisik.

  • Dukungan Persistent Volume: Bawaan (hostPath). Klaster Minikube secara otomatis mencakup StorageClass default yang menggunakan penyedia hostPath. Faktanya, Minikube menjalankan sebuah kontroler kecil yang secara dinamis menciptakan PV hostPath di dalam VM ketika PVC diminta. Ini berarti kita dapat membuat PersistentVolumeClaims dan mereka akan dipenuhi menggunakan penyimpanan di sistem file VM Minikube (biasanya di bawah /tmp/hostpath-provisioner atau yang serupa). Ini berfungsi secara langsung – tidak diperlukan konfigurasi untuk penggunaan PV dasar. Misalnya, StorageClass “standard” default di Minikube sesuai dengan penyimpanan hostPath di node. Satu catatan: jika kita me-restart atau menghapus VM Minikube, volume hostPath tersebut bisa hilang (Minikube mencoba untuk mempertahankan beberapa direktori di antara restart – misalnya, /data, /var/lib/minikube, /tmp/hostpath* dipertahankan). Namun, secara umum, untuk lingkungan non-produksi ini sudah cukup. Jika kita ingin mensimulasikan lebih lanjut, Minikube juga memiliki addon driver CSI hostpath yang mendukung snapshot dan dapat berfungsi dalam mode multi-node, tetapi ini lebih untuk eksperimen. Kesimpulan: Minikube mendukung PV secara default melalui hostPath, yang cukup untuk pengujian aplikasi stateful di homelab.

  • Dukungan LoadBalancer: Didukung melalui tunneling (atau addon MetalLB). Di awan, layanan LoadBalancer mendapatkan LB awan dengan IP eksternal. Di Minikube, jelas tidak ada penyedia awan, jadi Minikube menyediakan dua mekanisme:

    • Minikube Tunnel: Kita dapat menjalankan minikube tunnel dalam proses terpisah yang akan menciptakan rute jaringan di host kita dan menetapkan IP ke layanan LoadBalancer kita. Secara esensial, ini menggunakan host kita untuk bertindak sebagai “LB eksternal”. Ketika kita menciptakan layanan LoadBalancer, Minikube akan menampilkan “external IP” (biasanya dari subnet klaster) dan proses minikube tunnel akan mengarahkan IP tersebut ke layanan. Ini memerlukan proses tunnel tetap berjalan (dan biasanya izin root untuk menciptakan rute). Ini sedikit langkah manual, tetapi Minikube mencetak pengingat jika kita memiliki layanan LoadBalancer tanpa tunnel berjalan (“External-IP pending” hingga kita memulai tunnel).
    • Addon MetalLB: Versi baru Minikube juga mencakup addon MetalLB. Kita dapat melakukan minikube addons enable metallb dan mengonfigurasi rentang IP (Minikube akan meminta kita). Ini efektif menginstal MetalLB di dalam klaster Minikube, yang kemudian menangani layanan LoadBalancer seperti yang dilakukan di Kubernetes bare-metal. Ini adalah solusi yang lebih “dalam klaster” dan tidak memerlukan proses tunnel terpisah setelah pengaturan awal.

    Kedua opsi ini berfungsi, dan mana yang digunakan tergantung pada kita. Untuk mengekspos satu layanan secara cepat, minikube tunnel cepat dan sementara. Untuk pengaturan yang lebih permanen, addon MetalLB dapat diaktifkan sehingga LB mendapatkan IP nyata (misalnya, kita mungkin memberinya rentang seperti 10.0.0.240-250 pada Minikube dengan jaringan bridged). Ingat bahwa Minikube biasanya satu node, jadi secara efektif “load balancer” tidak membagi beban di beberapa node – hanya menyediakan akses eksternal ke layanan satu node. Ini sudah cukup untuk pengembangan. Di homelab, jika kita hanya menggunakan satu node dan menjalankan Minikube di sana, kita bisa menggunakan ini untuk mengakses aplikasi kita. Namun, jika kita ingin memanfaatkan semua 3 node, pendekatan Minikube terhadap LB bukan untuk skenario tersebut.

  • Kebutuhan Sumber Daya: Minikube itu sendiri ringan, tetapi karena biasanya menjalankan Kubernetes satu node penuh (dalam VM), penggunaan sumber daya mirip dengan klaster kecil normal. Rekomendasi minimum adalah 2 GB RAM dan 2 CPU untuk VM. Secara default, Minikube sering mengalokasikan 2 GB RAM untuk VM-nya. Dalam kasus kita, dengan 16 GB per mesin, ini sangat sederhana. Minikube (Kubernetes) yang sedang berjalan mungkin menggunakan sekitar 600 MB memori. Satu hal yang perlu dipertimbangkan adalah bahwa Minikube akan berjalan di atas sistem operasi kita – baik sebagai VM melalui hypervisor atau kontainer Docker – yang menambahkan sedikit overhead. Di server homelab, kita bisa menjalankan Minikube dengan driver “none” (yang menginstal komponen Kubernetes langsung di host). Namun, driver “none” (juga dikenal sebagai bare-metal) secara esensial mirip dengan menggunakan kubeadm di node tersebut, dan memerlukan pembersihan manual, jadi tidak terlalu populer. Kebanyakan menggunakan driver VM atau Docker. Secara ringkas, semua node homelab kita dapat menjalankan Minikube dengan mudah. Satu-satunya keterbatasan adalah bahwa Minikube tidak akan menggunakan sumber daya semua 3 node – akan terbatas pada host tunggal yang dijalankannya (kecuali menggunakan mode multi-node eksperimental dalam satu host).

  • Single-Node vs Multi-Node: Secara utama single-node. Minikube ideal untuk klaster single-node di satu mesin. Ia memiliki fitur untuk mensimulasikan beberapa node (misalnya, minikube start --nodes 3 dengan driver Docker akan memulai 3 node Kubernetes sebagai kontainer di satu host), tetapi ini hanya untuk pengujian. Kita tidak dapat menggunakan Minikube untuk menciptakan klaster multi-node nyata di 3 server fisik terpisah. Jika kita memiliki 3 mesin, kita harus menjalankan 3 instance Minikube independen (tidak dalam satu klaster). Ini bukan pengalaman klaster nyata (mereka tidak akan mengetahui satu sama lain). Oleh karena itu, Minikube tidak disarankan jika tujuan kita adalah memanfaatkan semua tiga node dalam satu klaster Kubernetes – lebih baik untuk skenario di mana kita hanya memiliki satu mesin (PC atau satu server) dan ingin menjalankan K8s di sana. Ini juga hebat untuk mempelajari dasar-dasar Kubernetes dan pengembangan lokal.

  • CLI & UI Tools: minikube CLI adalah antarmuka utama. Kita menggunakan untuk memulai/menghentikan klaster, dan memiliki pintasan yang bagus: misalnya, minikube dashboard akan mengaktifkan Kubernetes Dashboard dan membukanya di browser kita. minikube addons enable <addon> dapat mengaktifkan berbagai komponen opsional (ingress, metallb, metrics-server, dll.). Minikube mengatur akses kubectl secara otomatis (mengkonfigurasi konteks “minikube” di kubeconfig kita). Untuk UI, seperti yang disebutkan, Kubernetes Dashboard mudah diakses melalui perintah dashboard. Minikube tidak memiliki antarmuka web UI unik sendiri; ia bergantung pada alat standar. Debugging Minikube juga mudah karena kita dapat minikube ssh untuk masuk ke node VM jika diperlukan. Secara keseluruhan, alat-alatnya sangat ramah pengguna untuk skenario single-node.

Kubeadm (Kubernetes Standar di Node Kita Sendiri)

Fitur Utama: Kubeadm bukanlah “distribusi” tetapi alat resmi untuk menciptakan klaster Kubernetes dari awal. Menggunakan kubeadm berarti kita menginstal komponen Kubernetes standar di mesin kita. Ini esensial cara kita “membuat sendiri” klaster, mengikuti praktik terbaik tetapi tanpa tambahan yang termasuk dalam distribusi. Kubeadm akan mengatur node control plane (yang menjalankan etcd, API server, controller manager, scheduler) dan menggabungkan node worker ke dalamnya. Hasilnya adalah klaster Kubernetes standar penuh yang identik dengan yang kita dapatkan di VM awan. Pendekatan ini memberi kita kontrol dan fleksibilitas penuh – kita memilih plugin jaringan, penyedia penyimpanan, dll. – tetapi juga memerlukan usaha manual awal terbanyak dan pengetahuan. Sering digunakan di lingkungan produksi atau pembelajaran untuk memahami internal Kubernetes.

  • Kemudahan Instalasi & Pemeliharaan: Dibandingkan dengan yang lain, kubeadm paling terlibat. Kita harus menginstal dependensi secara manual (runtime kontainer seperti containerd, kubeadm, kubelet, kubectl) di setiap node. Lalu menjalankan kubeadm init di master, dan kubeadm join di worker dengan token yang diberikan. Kita juga perlu mengatur CNI (plugin jaringan) setelah inisialisasi (Calico, Flannel, dll.) karena kubeadm tidak menginstal satu secara default. Ada langkah-langkah yang terdokumentasi dengan baik untuk semua ini (prosesnya bukan sulit, tetapi banyak langkah) – secara esensial, kubeadm memberi kita klaster awal tetapi mengharapkan kita untuk menangani add-on. Dalam hal pemeliharaan, kita bertanggung jawab untuk pembaruan (kubeadm memiliki perintah upgrade, tetapi kita harus mengosongkan node, memperbarui biner, dll. secara manual), serta memantau kesehatan etcd, pembaruan sertifikat, dll. Singkatnya, kubeadm kuat tetapi manual. Sering disebut “cara sulit” (meskipun tidak seburuk membangun dari sumber). Untuk seorang penggemar homelab yang menikmati pembelajaran, kubeadm adalah cara yang hebat untuk memahami Kubernetes secara mendalam. Namun, jika prioritas kita adalah “mudah dan sedikit pemeliharaan,” kubeadm akan lebih banyak usaha daripada K3s/MicroK8s. Setiap pembaruan atau perubahan akan memerlukan usaha manual. Dengan demikian, setelah diatur, ini adalah hal yang nyata: klaster Kubernetes standar tanpa abstraksi tersembunyi.

  • Dukungan Persistent Volume: Tidak ada secara default (harus ditambahkan secara manual). Klaster yang diinstal dengan kubeadm secara esensial adalah Kubernetes kosong – tidak mencakup StorageClass default atau penyedia dinamis secara bawaan. Di lingkungan awan, penyedia awan biasanya menyediakan StorageClass default (misalnya, AWS EBS, dll.), tetapi di lingkungan homelab bare-metal, kita harus menginstal solusi sendiri. Pendekatan umum:

    • HostPath Provisioner: Kita dapat meniru apa yang dilakukan K3s/Minikube dengan menginstal sesuatu seperti Rancher Local Path Provisioner (yang merupakan kontroler kecil + StorageClass yang menciptakan PV hostPath). Ini adalah add-on sederhana (hanya manifest YAML) dan memberi kita penyimpanan dinamis lokal.
    • NFS atau NAS: Beberapa pengguna homelab mengatur server NFS (atau menggunakan NAS) dan kemudian menggunakan PV statis atau driver CSI NFS untuk provisioning.
    • OpenEBS/Longhorn/Ceph: Ada opsi yang lebih kompleks seperti menginstal Longhorn atau Ceph RBD melalui Rook jika kita ingin penyimpanan terdistribusi di antara node. Ini memerlukan lebih banyak sumber daya dan kompleksitas.

    Titik kunci adalah bahwa kubeadm tidak “menyelesaikan” penyimpanan untuk kita – kita harus memutuskan dan mengkonfigurasinya. Jika kemudahan adalah prioritas, jalur tercepat adalah menginstal hostPath provisioner atau menggunakan NFS. Misalnya, local-path provisioner dari Rancher dapat diinstal dalam beberapa perintah kubectl apply dan akan meniru perilaku K3s (menciptakan volume di bawah /var/lib/rancher/ di node apa pun). Namun, ini adalah langkah manual. Hingga kita melakukan itu, setiap PVC yang kita buat akan tetap dalam status Pending karena Kubernetes tidak memiliki provisioning default. Jadi, meskipun kubeadm pasti mendukung Persistent Volumes (ini adalah Kubernetes penuh), dukungan untuk PV dinamis sebaik usaha yang kita lakukan untuk mengaturnya.

  • Dukungan LoadBalancer: Tidak ada secara default (harus ditambahkan secara manual). Cerita yang sama di sini: di klaster on-prem tradisional, kita tidak memiliki implementasi LoadBalancer bawaan. Jika kita menciptakan layanan tipe LoadBalancer di klaster kubeadm biasa, ia akan tetap dalam status pending selamanya hingga kita menginstal controller untuk menanganinya. Solusi umum adalah menginstal MetalLB sendiri. MetalLB dapat diinstal melalui manifest atau chart Helm – kita akan mengonfigurasi rentang IP dan kemudian akan mengalokasikan IP tersebut untuk layanan LoadBalancer (seperti di MicroK8s). Banyak panduan tersedia untuk menginstal MetalLB di klaster kubeadm. Alternatif lain yang digunakan beberapa orang adalah kube-vip untuk VIP control-plane dan layanan LB, tetapi MetalLB lebih sederhana untuk layanan. Secara esensial, dengan kubeadm kita memiliki kebebasan (atau beban) untuk mengatur mekanisme load-balancing apa pun yang sesuai kebutuhan kita. Jika kita tidak mengatur apa pun, kita terbatas pada layanan NodePort untuk akses eksternal. Untuk homelab, menginstal MetalLB sangat disarankan – ini sederhana dan memberi kita fungsi IP layanan seperti di awan. Namun, ini adalah langkah tambahan yang harus kita lakukan (berbeda dengan K3s yang bekerja langsung atau MicroK8s dengan enable sederhana).

  • Kebutuhan Sumber Daya: Kubernetes standar sedikit lebih berat dari versi yang dipangkas. Setiap node akan menjalankan kubelet dan kube-proxy, dan master akan menjalankan etcd dan komponen control-plane. Satu node control-plane masih dapat berjalan dengan 2 GB RAM, tetapi biasanya kita mungkin ingin sedikit lebih banyak untuk kenyamanan jika menjalankan pod di sana. Panduan padok menyarankan 2 GB untuk master, 2 GB untuk worker minimum. Dalam skenario kita (16 GB per node), ini sudah cukup. etcd dan API server yang sedang berjalan mungkin menggunakan beberapa ratus MB memori masing-masing. Tidak ada perbedaan besar saat runtime antara klaster kubeadm dan MicroK8s – setelah semua, MicroK8s adalah komponen yang sama. Perbedaannya hanya apa yang berjalan secara default (MicroK8s mungkin mengaktifkan DNS dan penyimpanan secara default, sedangkan di kubeadm kita akan menginstalnya). Jadi, dari segi sumber daya, kubeadm bisa se ringkas atau se berat yang kita konfigurasikan. Tanpa instalasi tambahan, ini bisa cukup ringkas. Dengan konfigurasi standar (misalnya kita menambahkan CoreDNS, Dashboard, dll.), harapkan sekitar 1 GB atau lebih untuk beban sistem. Kita memiliki cukup RAM, jadi sumber daya bukan masalah. Ini lebih tentang waktu dan sumber daya manusia yang diperlukan untuk mengelolanya daripada CPU/RAM.

  • Single-Node vs Multi-Node: Kubeadm dapat melakukan keduanya, dengan fleksibilitas penuh. Kita dapat menginisialisasi klaster single-node (dan bahkan meminta kubeadm untuk memungkinkan node tunggal menjalankan beban kerja dengan menonaktifkan taint master). Atau kita dapat memiliki satu master dan menggabungkan dua worker (konfigurasi 3-node yang umum). Kita bahkan dapat mengatur 3 master dan 3 worker, dll. – topologi apa pun. Dalam kasus kita, konfigurasi kubeadm yang mungkin adalah 1 node control-plane dan 2 worker (karena HA tidak diperlukan, kita tidak perlu beberapa master). Ini memberi kita klaster fungsional 3-node. Proses untuk multi-node sangat terdokumentasi: secara esensial, instal Kubernetes di semua, inisialisasi satu, gabungkan yang lainnya. Hasilnya identik dengan yang diberikan oleh klaster terkelola atau distribusi lain: 3 node kita muncul dalam kubectl get nodes, dll. Jadi, kubeadm pasti memenuhi kebutuhan “dapat menggunakan semua 3 node”.

  • CLI & UI Tools: Dengan kubeadm, satu-satunya CLI khusus adalah kubeadm itu sendiri, digunakan untuk langkah-langkah pengaturan dan (nanti) pembaruan. Secara harian, gunakan kubectl untuk mengelola klaster. Tidak ada CLI manajemen terintegrasi selain yang disediakan Kubernetes. Untuk UI, tidak ada yang termasuk secara default – kita dapat menginstal Kubernetes Dashboard atau alat lain secara manual (seperti di klaster apa pun). Secara esensial, kubeadm memberi kita kanvas Kubernetes kosong. Ini terserah kita untuk mengisi – yang mencakup menginstal kemudahan seperti dashboard, controller ingress, kelas penyimpanan, dll. Banyak dashboard pihak ketiga (Lens, Octant, dll.) juga dapat terhubung ke klaster kubeadm jika kita ingin pengalaman manajemen GUI, tetapi ini alat eksternal. Secara ringkas, dengan kubeadm kita mendapatkan lingkungan Kubernetes murni – fleksibilitas maksimal, tetapi juga kebutuhan untuk mengatur segalanya seperti jika ini adalah klaster produksi.

  • Kubespray Lihat juga cara menginstal versi ini dari Kubernetes dengan Kubespray.

Tabel Perbandingan Sampingan

Berikut adalah ringkasan perbandingan antara empat opsi berdasarkan aspek penting:

Aspek K3s (Kubernetes Ringan oleh Rancher) MicroK8s (Kubernetes “Low-Ops” oleh Canonical) Minikube (Kubernetes Dev Single-Node) Kubeadm (Kubernetes Murni)
Instalasi Skrip instalasi satu baris (single binary). Berjalan sebagai layanan sistem tunggal. Pengaturan sangat cepat. Instalasi satu perintah melalui snap di Ubuntu. Semua komponen termasuk. Klaster mudah dengan microk8s join. Instal CLI minikube, lalu minikube start untuk meluncurkan VM/container lokal. Multiplatform dan ramah pemula. Instalasi manual kubeadm, kubelet, dll. di setiap node. Jalankan kubeadm init + kubeadm join dengan prasyarat. Melibatkan beberapa langkah (runtime, plugin jaringan, dll.).
Pemeliharaan & Upgrade Upgrade manual (ganti binary atau gunakan skrip instalasi untuk versi baru). Sederhana, karena hanya satu binary; sedikit yang perlu dikelola. Tidak ada auto-update. Refresh snap untuk pembaruan (dapat otomatis). Add-ons dan layanan klaster dikelola melalui CLI microk8s. Secara umum low-ops; tersedia pembaruan otomatis. Mudah menghapus/membuat ulang klaster untuk pengembangan. Upgrade dengan memperbarui versi minikube dan memulai ulang klaster. Dirancang untuk penggunaan sementara (kurang fokus pada upgrade in-place yang tahan lama). Pengguna bertanggung jawab untuk semua upgrade. Gunakan kubeadm upgrade tetapi harus mengosongkan node, mengelola backup etcd, dll. Kontrol penuh, tetapi Anda yang melakukan pekerjaan (tidak ada pembaruan otomatis).
Versi K8s Mengikuti upstream secara cukup dekat (sering digunakan dalam rilis edge). Konforman CNCF. Beberapa fitur dinonaktifkan secara default (alpha/legacy). Mengikuti rilis upstream (saluran snap untuk 1.27, 1.28, dll.). Konforman CNCF. Secara dasarnya binary K8s murni. Kita dapat memilih versi Kubernetes saat mulai (misalnya, minikube start --kubernetes-version=v1.27). Secara default menggunakan versi stabil terbaru. Versi apa pun yang kita inginkan (instal versi kubeadm/kubelet tertentu). Kubernetes upstream penuh – kita memutuskan versi dan kapan upgrade.
Fitur Default Default yang disertakan: Flannel CNI, CoreDNS, Traefik ingress, service LB, local storage class, metrics-server, dll. (Semua dapat dinonaktifkan jika tidak diperlukan). Minimal konfigurasi yang diperlukan untuk berfungsi. Default minimal: DNS biasanya aktif, lainnya opsional. Add-ons satu perintah mudah untuk ingress (NGINX), MetalLB, hostpath storage, dashboard, dll.. Dapat mengaktifkan mode HA pada 3+ node. Disertakan dalam VM: biasanya mencakup runtime Docker/containerd, Kubernetes dengan addons default seperti StorageProvisioner dan DNS. Add-ons opsional (ingress, dashboard, dll.) diaktifkan melalui CLI. Tidak ada multi-node secara default. Bodi: Tidak ada yang melebihi Kubernetes inti. Tidak ada ingress, tidak ada storage atau LB default, tidak ada dashboard sampai kita menginstalnya. Kita memilih plugin CNI (harus menginstal satu untuk jaringan). Secara esensial klaster DIY.
Dukungan Persistent Volume Ya – out-of-box. Rancher local-path dynamic provisioner disertakan, yang menciptakan hostPath PVs di node untuk setiap PVC. Default StorageClass “local-path” menggunakan disk lokal secara otomatis. Ya – mudah ditambahkan. Aktifkan hostpath-storage untuk mendapatkan StorageClass default untuk PV dinamis menggunakan hostPath. Sampai diaktifkan, tidak ada provisioner PV default. Add-on ini tidak untuk produksi multi-node, tetapi baik untuk homelab. Ya – out-of-box. StorageClass default menggunakan provisioner hostPath di dalam VM minikube. PVCs dipenuhi oleh controller sederhana yang menciptakan hostPath PV di filesystem node. Data bertahan setelah restart di beberapa direktori. Tidak (manual). Tidak ada provisioner default – klaster awalnya tidak memiliki StorageClass. Pengguna harus menginstal solusi penyimpanan (misalnya, local path provisioner, NFS, Ceph, dll.). Pendekatan dasar: terapkan YAML provisioner hostPath untuk meniru apa yang dilakukan K3s/Minikube. Sampai saat itu, PVCs tetap menunggu.
Dukungan LoadBalancer Ya – ServiceLB bawaan. Kontroler servicelb K3s (Klipper) memantau layanan LoadBalancer dan mendeploy pod di node untuk mengeksposnya. Menggunakan IP node dan host port untuk mengarahkan lalu lintas. Berfungsi out-of-the-box tanpa konfigurasi. Cocok untuk klaster kecil; menggunakan IP internal/eksternal node untuk layanan. Ya – melalui add-on MetalLB. Aktifkan metallb dengan rentang IP untuk alokasi. Memberikan load balancer Layer-2 sebenarnya di bare metal. Tidak diaktifkan secara default. Setelah diaktifkan, setiap layanan LoadBalancer mendapatkan IP unik dari pool kita. Memerlukan sedikit konfigurasi awal (rentang IP). Ya – melalui tunnel atau MetalLB. Tidak ada cloud LB, tetapi kita dapat menjalankan minikube tunnel untuk menetapkan IP eksternal ke layanan LoadBalancer (menciptakan route di host). Alternatifnya, aktifkan add-on MetalLB di minikube untuk IP LB otomatis. Secara default, layanan LB akan menunjukkan “pending” sampai kita menggunakan salah satu metode ini. Tidak (manual). Tidak ada LB bawaan. Biasanya menginstal MetalLB secara manual untuk fungsi LB bare-metal. Setelah MetalLB (atau controller LB lain) diatur, layanan LoadBalancer berfungsi. Tanpa itu, layanan LB tetap menunggu selamanya.
Jaringan (CNI) Default = Flannel (overlay networking). K3s juga mendukung penggantian CNI jika diperlukan. Disertakan CoreDNS untuk DNS klaster. Traefik ingress termasuk secara default (dapat dinonaktifkan). Default = Calico (untuk versi terbaru dalam mode HA) atau default sederhana. (MicroK8s sebelumnya menggunakan flannel; sekarang cenderung menggunakan Calico untuk pembatasan ketat). CoreDNS diaktifkan secara default. NGINX ingress tersedia melalui add-on (microk8s enable ingress). Default = kubenet/bridge (tergantung driver; sering menggunakan jaringan NAT sederhana). CoreDNS berjalan secara default. Kita dapat mengaktifkan add-on NGINX ingress jika diperlukan. Jaringan terbatas pada satu VM; NodePort dapat diakses melalui minikube ip. Pilihan CNI. Kubeadm tidak menginstal plugin CNI apa pun – kita harus mendeploy satu (Calico, Flannel, Weave, dll.). Kita memiliki kontrol penuh. Sebagian besar panduan memiliki kita menerapkan YAML Calico setelah kubeadm init. CoreDNS diinstal oleh kubeadm secara default sebagai DNS klaster. Controller ingress – pilih dan instal sendiri (misalnya, NGINX atau Traefik via manifests/Helm).
Klaster Multi-Node Ya. Dirancang untuk multi-node. Mudah bergabung dengan token. Dapat menggunakan DB eksternal atau etcd tersemat untuk multi-master. Cocok untuk homelab 2-3+ node. Tidak diperlukan ketergantungan tambahan – K3s memiliki klaster bawaan. Ya. Mendukung klaster multi-node MicroK8s (dengan microk8s join). Dapat mengaktifkan HA dengan 3+ master (Dqlite). Sangat mudah membentuk klaster, terutama jika semua node menjalankan Ubuntu + snap. Tidak (fisik). Dirancang untuk single-node. Dapat mensimulasikan multi-node pada satu mesin (beberapa node dalam container Docker), tetapi tidak dapat menyebar ke beberapa host fisik dalam satu klaster. Gunakan instance Minikube terpisah untuk klaster terpisah. Ya. Mendukung multi-node secara penuh (itu tujuannya). Kita dapat memiliki 1 master + banyak worker, atau bahkan beberapa master (meskipun setup HA kubeadm lebih kompleks). Tidak ada pembatasan bawaan pada ukuran klaster.
Overhead Sumber Daya Sangat rendah. Control plane ~<0.5 GB memori idle. Proses tunggal untuk control plane menghasilkan footprint kecil. Efisien pada CPU (meskipun dapat menggunakan sedikit lebih banyak CPU pada idle dibandingkan MicroK8s menurut beberapa laporan). Ideal untuk daya rendah atau banyak kapasitas cadangan. Rendah. ~0.5–0.6 GB memori untuk control plane idle. Sedikit lebih besar basis memori dibandingkan K3s, tetapi tetap stabil. Menggunakan snap Ubuntu (mungkin memiliki sedikit overhead). Masih ringan relatif terhadap Kubernetes penuh. Sedang. VM default 2 GB alokasi (penggunaan ~0.6 GB idle). Berjalan satu node Kubernetes penuh, plus lapisan VM. Tidak menjadi masalah pada sistem 16 GB, tetapi secara esensial mengonsumsi sumber daya dari klaster kecil pada satu mesin. Sedang. Satu master dengan satu worker mungkin menggunakan ~1 GB idle setelah menambahkan add-on standar. Setiap node tambahan menambahkan sedikit overhead (hanya kubelet, proxy). Mirip dengan menjalankan Kubernetes di VM cloud ukuran serupa. Pada 3 node dengan 16 GB masing-masing, overhead tidak signifikan dalam konteks.
Alat CLI Gunakan k3s untuk instalasi dan sebagai wrapper untuk kubectl (atau gunakan kubectl standar). Tidak ada CLI manajemen terpisah (K3s hampir “set and forget”). Beberapa skrip bantuan (misalnya, k3s-killall.sh). GUI Rancher dapat ditambahkan jika diinginkan. CLI microk8s yang kaya: misalnya, microk8s enable/disable <addon>, microk8s status. Juga mencakup microk8s kubectl. Dirancang untuk menyederhanakan tugas umum (tidak diperlukan pengeditan langsung manifest sistem untuk dasar). CLI minikube untuk memulai/berhenti klaster, mengelola konfigurasi dan add-on, serta mendapatkan informasi (IP, URL layanan, log). Juga menyediakan perintah kenyamanan seperti minikube dashboard. Interaksi dengan klaster melalui kubectl (konfigurasi otomatis untuk konteks minikube). Hanya kubeadm untuk setup awal dan upgrade. Operasi sehari-hari melalui kubectl standar dan alat-alat Kubernetes lainnya. Tidak ada CLI distro khusus selain bootstrap. Anda akan bekerja dengan perintah Kubernetes mentah dan mungkin alat OS untuk pemeliharaan.
UI / Dashboard Tidak disertakan secara default. Dapat menginstal secara manual Dashboard Kubernetes atau menggunakan alat eksternal (tidak ada yang khusus Rancher kecuali kita menambahkan Rancher secara terpisah). K3s fokus pada operasi tanpa antarmuka. Tidak disertakan secara default, tetapi tersedia melalui satu perintah: microk8s enable dashboard mendeploy UI Dashboard standar. Akses mudah untuk klaster melalui microk8s dashboard-proxy. Juga terintegrasi dengan baik dengan GUI Lens Canonical jika diinginkan (Lens dapat mengakses langsung MicroK8s). Tidak diaktifkan secara default, tetapi perintah minikube dashboard akan mendeploy dan membuka UI Dashboard web untuk kita. Ini dimaksudkan untuk kenyamanan dalam pengembangan lokal – satu perintah dan kita memiliki GUI untuk melihat beban kerja. Tidak disertakan. Kita mungkin menginstal Dashboard (terapkan YAML) jika diinginkan. Selain itu, gunakan CLI atau aplikasi dashboard pihak ketiga. Dalam homelab, seseorang mungkin menginstal dashboard dan membuat NodePort atau menggunakan kubectl proxy untuk melihatnya. Kubeadm tidak peduli dengan UI.

Sumber: Data di atas disintesis dari dokumen resmi dan panduan pengguna: misalnya, footprint memori dari perbandingan MicroK8s sendiri, penyimpanan default di dokumen K3s, perilaku service LB K3s dari dokumen K3s, detail add-on MicroK8s dari dokumen Canonical, PV dan tunnel Minikube dari dokumen Kubernetes, dan laporan pengalaman umum. (Lihat Referensi untuk kutipan lengkap.)

Rekomendasi

Berdasarkan prioritas (mudahnya pengaturan/pemeliharaan, dan dukungan bawaan untuk penyimpanan dan load balancer) serta skenario (3 node Ubuntu, tidak peduli dengan HA):

  • Pilihan Terbaik: K3s atau MicroK8s adalah pilihan terbaik untuk homelab dengan 3 node:

    • Keduanya sangat mudah diinstal (perintah tunggal di setiap node) dan memerlukan pemeliharaan minimal. Mereka mengabstraksi kebanyakan kompleksitas menjalankan klaster.
    • Keduanya mendukung klaster multi-node secara bawaan (kita dapat menggabungkan 3 node kita dan melihat satu klaster yang terpadu).
    • Masing-masing menyediakan solusi untuk Persistent Volumes dan LoadBalancers tanpa usaha yang besar: K3s menyertakan fitur ini secara default (penyimpanan Local Path, Klipper LB) dan MicroK8s menyediakannya melalui perintah enable sederhana. Ini berarti kita dapat mendeploy aplikasi umum (basis data dengan PVC, layanan dengan tipe=LoadBalancer) dengan sedikit pengaturan manual.
    • K3s mungkin menarik jika kita ingin footprint terkecil dan tidak masalah menggunakan default bawaannya (seperti Traefik ingress, dll.). Ini adalah pendekatan “set up dan langsung berjalan” dengan default yang berpendapat. Ini juga sangat populer di komunitas homelab karena kesederhanaannya. Kita akan menggunakan kubectl standar secara utama, dan dapat menyesuaikan atau menonaktifkan komponen yang dikemas jika diperlukan. K3s mungkin lebih disukai jika kita tidak menggunakan Ubuntu atau jika kita menyukai ekosistem Rancher (atau rencana menggunakan UI manajemen Rancher nanti).
    • MicroK8s mungkin menarik jika kita lebih menyukai solusi yang didukung Ubuntu dan menyukai ide mengaktifkan fitur dengan satu perintah. Secara dasarnya, ini adalah Kubernetes murni di bawahnya, yang beberapa orang temukan lebih mudah diperluas. Add-on (seperti microk8s enable ingress dns storage metallb) dapat memberi kita “micro cloud” yang penuh fungsi dalam beberapa menit. MicroK8s juga menangani pembaruan secara halus melalui snaps, yang bisa sangat membantu untuk menjaga klaster tetap up-to-date tanpa intervensi manual (kita dapat mematikan ini atau mengontrol saluran untuk menghindari kejutan). Jika kita sudah menjalankan Ubuntu di semua node (yang kita lakukan) dan tidak masalah menggunakan snaps, MicroK8s adalah pilihan yang sangat baik untuk klaster yang minim pemeliharaan.

    Dengan kata lain: Tidak akan salah memilih K3s atau MicroK8s untuk skenario ini. Keduanya akan memberi kita Kubernetes yang mudah digunakan dan ramah homelab dengan fitur yang kita butuhkan. Banyak pengguna melaporkan pengalaman positif dengan keduanya dalam pengaturan rumah dengan 2–3 node. MicroK8s mungkin sedikit unggul dalam kemudahan penggunaan (karena add-on dan integrasi), sementara K3s mungkin sedikit unggul dalam menjalankan dengan ringkas dan sederhana di bawahnya.

  • Kapan memilih Minikube: Jika kita hanya menjalankan di satu mesin atau ingin klaster dev sementara, Minikube sangat bagus untuk itu. Ini adalah cara termudah untuk mengaktifkan Kubernetes di laptop atau satu node untuk pengujian. Namun, untuk klaster permanen dengan 3 node, Minikube bukan alat yang tepat – tidak akan menggabungkan 3 node tersebut menjadi satu klaster. Kita akan mengalami penggunaan hardware yang tidak optimal atau mengelola 3 klaster terpisah, yang tidak diinginkan. Jadi, dalam homelab dengan beberapa node, Minikube tidak disarankan sebagai solusi utama. Kita mungkin masih menggunakan Minikube di komputer pribadi untuk mencoba hal-hal sebelum mendeploy ke klaster homelab, tetapi untuk klaster itu sendiri, gunakan sesuatu seperti K3s/MicroK8s.

  • Kapan memilih Kubeadm: Jika tujuan kita adalah mempelajari internal Kubernetes atau memiliki kontrol penuh dan pengaturan “seperti produksi”, kubeadm adalah latihan yang baik. Ini akan memaksa kita memahami bagaimana menginstal CNI, penyimpanan, dll., dan kita akan membangun klaster secara bertahap. Dalam hal kemudahan penggunaan, meskipun, kubeadm adalah paling manual. Setiap fitur yang kita butuhkan (seperti penyimpanan atau LB) harus dikonfigurasi. Untuk homelab yang fokus pada pembelajaran, ini bisa menjadi kelebihan (edukatif); untuk homelab yang hanya ingin berjalan, ini adalah kelemahan. Selain itu, pemeliharaan akan lebih rumit (terutama saat pembaruan). Kecuali kita secara spesifik ingin pengalaman Kubernetes murni untuk pembelajaran atau kebutuhan khusus, menggunakan K3s atau MicroK8s akan menghemat banyak waktu dan mengurangi kebingungan dalam lingkungan homelab. Dengan demikian, beberapa pengguna berpengalaman lebih menyukai kubeadm bahkan di rumah untuk menghindari kekhasan vendor dan mengendalikan segalanya. Ini benar-benar tergantung pada seberapa banyak usaha yang ingin kita habiskan. Untuk kebanyakan orang, kubeadm terlalu berlebihan untuk klaster kecil di mana ketersediaan tinggi bukan kekhawatiran.

  • Opsi Lain: Ada beberapa versi Kubernetes ringan lainnya, seperti k0s (oleh Mirantis) dan alat seperti kind (Kubernetes in Docker). Untuk kelengkapan:

    • k0s adalah distro Kubernetes satu-binary lainnya, dengan tujuan serupa seperti K3s/MicroK8s, yang fokus pada fleksibilitas dan footprint minimal. Ini relatif baru tetapi memiliki penggemar di komunitas homelab. Ini juga dapat dijalankan dengan mudah di 3 node kita. Saat ini, tidak memiliki basis pengguna sebesar K3s/MicroK8s, tetapi ini adalah opsi yang patut diawasi (terutama jika menyukai gagasan Kubernetes open-source, konfigurabel, dan minimal – beberapa laporan bahkan menunjukkan bahwa k0s menggunakan sedikit sumber daya idle lebih sedikit daripada K3s/MicroK8s dalam konfigurasi serupa).
    • kind utamanya digunakan untuk menguji klaster Kubernetes dalam kontainer Docker (sering digunakan untuk pipeline CI). Ini bukan sesuatu yang kita jalankan sebagai klaster homelab yang selalu aktif – lebih cocok untuk klaster sementara cepat di satu mesin (mirip dengan tujuan Minikube).
    • Rancher Kubernetes Engine (RKE) atau K3d atau yang lainnya juga ada, tetapi ini biasanya ditujukan untuk klaster berbasis kontainer (k3d menjalankan klaster K3s di Docker) atau skenario pengaturan yang lebih kompleks. Di homelab, K3s dan MicroK8s hampir menjadi solusi mudah yang dianggap sebagai standar.

Kesimpulan: Untuk homelab dengan 3 node yang cukup baik, MicroK8s atau K3s adalah pilihan yang disarankan untuk mendapatkan klaster Kubernetes yang berfungsi dengan sedikit masalah. Mereka akan memungkinkan kita memanfaatkan semua node kita dalam satu klaster, dan menyediakan dukungan bawaan untuk volume persisten dan layanan LoadBalancer, yang tepatnya apa yang kita minta. Jika kita lebih menyukai solusi yang lebih plug-and-play dan terintegrasi dengan Ubuntu, pilih MicroK8s. Jika kita lebih menyukai solusi yang sangat ringkas, terbukti, dan didukung oleh Rancher, pilih K3s. Kita akan memiliki klaster yang berjalan dalam beberapa menit, baik dengan cara mana pun. Setelah berjalan, kita dapat mendeploy Dashboard Kubernetes atau alat lain untuk mengelolanya, dan mulai menjalankan aplikasi kita dengan penyimpanan persisten dan eksposisi layanan yang mudah. Nikmati perjalanan Kubernetes kita di homelab!

Halaman Resmi Distribusi Kubernetes

Tautan Berguna Lainnya