Deni.dev Logo
Kembali ke Blog
18-06-2026
7 mnt baca

Membongkar Paradigma 'Zero-Node Overhead': Strategi Orkestrasi Kubernetes Tanpa Control Plane Tradisional untuk Edge Computing

#Docker#Kubernetes#Edge Computing#K3s#DevOps

Membongkar Paradigma "Zero-Node Overhead": Strategi Orkestrasi Kubernetes Tanpa Control Plane Tradisional untuk Edge Computing

Selama hampir satu dekade, kombinasi Docker dan Kubernetes (K8s) telah menjadi standar baku dalam arsitektur cloud-native. Docker bertindak sebagai media isolasi aplikasi lewat kontainerisasi yang ringkas, sementara Kubernetes mengemban tugas berat sebagai dirigen yang mengorkestrasi ribuan kontainer tersebut. Namun, di balik keandalannya, Kubernetes konvensional menyimpan satu kelemahan bawaan: obesity infrastruktur.

Secara arsitektural, sebuah klaster Kubernetes standar membutuhkan sumber daya yang masif hanya untuk menjalankan dirinya sendiri (control plane). Komponen seperti etcd, kube-apiserver, kube-controller-manager, dan kube-scheduler membutuhkan memori ber-gigabyte dan siklus CPU yang konstan. Di pusat data modern, hal ini bukan masalah besar. Namun, bagaimana jika Anda harus mengorkestrasi puluhan kontainer Docker di perangkat Edge Computing—seperti IoT Gateway di perkebunan terpencil, sensor pabrik pintar, atau perangkat kasir pintar (POS) dengan spesifikasi hardware yang sangat minim?

Artikel ini tidak akan membahas dasar-dasar docker build atau cara membuat Deployment standar. Kita akan menyelami lebih dalam ke sudut pandang yang jarang dieksplorasi: Bagaimana memangkas habis beban (overhead) Kubernetes hingga mendekati nol (Zero-Node Overhead) dengan memanfaatkan inovasi container runtime modern dan teknik pemisahan kontrol plane eksternal.

Masalah Utama: Mengapa K8s Standar "Membunuh" Perangkat Edge?

Dalam arsitektur Kubernetes standar, Control Plane bertindak sebagai otak dari klaster. etcd, sebagai basis data terdistribusi yang menyimpan status klaster, membutuhkan I/O disk yang sangat cepat dan memori yang stabil.

Jika kita memaksakan arsitektur ini ke perangkat Edge dengan memori hanya 1 GB atau 2 GB RAM, hal berikut akan terjadi:

  1. OOM-Killed Kronis: Komponen K8s akan berebut memori dengan aplikasi bisnis (kontainer Docker Anda), memicu mekanisme Out-of-Memory (OOM) Killer dari kernel Linux.
  2. Degradasi Storage: Write operation yang konstan dari etcd ke kartu SD atau penyimpanan flash murah pada perangkat IoT akan memperpendek umur hardware secara drastis dalam hitungan bulan.
  3. Ketergantungan Jaringan: Kubernetes didesain dengan asumsi jaringan antar node selalu stabil dan berlatensi rendah. Jaringan edge yang sering terputus (intermittent) akan membuat klaster menganggap node mati dan memicu rescheduling massal yang tidak perlu.

Untuk mengatasi ini, kita harus mengubah cara kita memandang Docker dan Kubernetes.

Dekonstruksi Runtime: Dari Docker Engine ke containerd

Langkah pertama menuju efisiensi ekstrem adalah menyingkirkan Docker Engine (dockerd) di lingkungan produksi edge dan beralih langsung ke containerd.

Banyak developer pemula tidak menyadari bahwa Docker sebenarnya adalah sebuah ekosistem besar yang berlapis-lapis. Saat Anda menjalankan perintah Docker, perintah tersebut melewati CLI, menuju Docker Daemon, lalu diteruskan ke containerd, sebelum akhirnya dieksekusi oleh tingkat paling bawah yaitu runc.

Dengan memotong Docker Daemon dan berkomunikasi langsung dengan containerd via Kubelet (menggunakan Container Runtime Interface atau CRI), kita dapat menghemat penggunaan memori hingga ratusan megabyte per node tanpa kehilangan kemampuan isolasi kontainer yang biasa disediakan oleh Docker.

Strategi Arsitektur: Memisahkan Otak dari Tubuh

Untuk mencapai Zero-Node Overhead, kita harus menerapkan pola arsitektur Remote Control Plane / Datacenter-Driven K8s. Dalam pola ini, perangkat edge sama sekali tidak menjalankan komponen manajemen. Mereka murni bertindak sebagai worker node yang mengeksekusi kontainer aplikasi.

Teknologi seperti K3s (Lightweight Kubernetes) besutan Rancher, atau KubeEdge, membawa konsep ini ke level berikutnya dengan mengganti komponen internal K8s:

  1. Substitusi etcd ke SQLite/PostgreSQL: K3s mengganti etcd dengan mekanisme KINE (K3s Is Not Etcd), memungkinkan penggunaan SQLite untuk klaster single-node, atau database SQL terpusat di cloud untuk multi-node.
  2. Kombinasi Binary: Semua komponen control plane dikompresi menjadi satu file binary tunggal berukuran kurang dari 100MB.
  3. Optimasi Kubelet: Memangkas fitur-fitur K8s cloud-spesifik (seperti cloud provider integration) yang tidak dibutuhkan di perangkat lokal.

Mari kita lihat perbandingan kebutuhan memori minimum secara arsitektural:

Komponen Vanilla Kubernetes (K8s) K3s (Edge-Optimized)
Control Plane Memory Minimum 2 GB - 4 GB RAM ~512 MB RAM
Worker Node Memory ~1 GB RAM ~50 MB RAM
Storage Footprint > 1 GB ~100 MB
Database Status etcd (Sangat intensif I/O) SQLite / KINE (Ringan)

Penerapan Praktis: Mengonfigurasi Klaster K3s dengan Agen Ringan

Berikut adalah simulasi bagaimana kita mengonfigurasi sebuah perangkat edge agar berjalan dengan overhead sekecil mungkin, namun tetap dapat dikendalikan secara penuh dari server Kubernetes terpusat.

Langkah 1: Inisialisasi Server Terpusat (Cloud/Data Center)

Di sisi server (yang memiliki resource besar), kita jalankan K3s server tanpa menyertakan komponen agent lokal agar server fokus mengelola status saja:

curl -sfL https://get.k3s.io | sh -s - server \
  --disable-agent \
  --disable=traefik,servicelb,local-storage \
  --node-name cloud-master

Note: Kita menonaktifkan Traefik dan Load Balancer bawaan untuk menghemat bandwidth dan resource karena komponen tersebut akan kita kelola secara spesifik.

Untuk menghubungkan node edge, kita membutuhkan token registrasi yang aman:

cat /var/lib/rancher/k3s/server/node-token

Langkah 2: Konfigurasi Perangkat Edge (Zero-Overhead Agent)

Di sisi perangkat IoT / Edge, kita hanya menginstal K3s Agent. Kita akan menginstruksikan agent untuk menggunakan containerd secara optimal dan membatasi alokasi resource logging yang sering membengkak.

Buat file konfigurasi /etc/rancher/k3s/config.yaml di perangkat edge sebelum instalasi:

server: "https://<IP_SERVER_CLOUD>:6443"
token: "K10ebd747d627...TOKEN_DARI_SERVER..."
node-name: "edge-sensor-01"
kubelet-arg:
  - "image-gc-high-threshold=60"
  - "image-gc-low-threshold=40"
  - "cpu-manager-policy=none"

Penjelasan kode: image-gc (Garbage Collection) diatur agresif (60% dan 40%) agar perangkat segera menghapus image Docker lama yang tidak terpakai dari penyimpanan lokal yang terbatas.

Jalankan installer khusus agent:

curl -sfL https://get.k3s.io | K3s_URL=https://<IP_SERVER_CLOUD>:6443 K3s_TOKEN=<TOKEN> sh -s - agent

Dengan konfigurasi ini, perangkat edge Anda kini berjalan sebagai bagian dari klaster Kubernetes global, namun penggunaan memori sistem untuk agen orkestrasi di node tersebut tidak akan melebihi kisaran 50-80 MB saja.

Menangani Tantangan Jaringan: Pola "Edge-Tunneling"

Salah satu hambatan terbesar arsitektur ini adalah enkapsulasi jaringan. Perangkat edge biasanya berada di balik NAT, firewall ketat, atau menggunakan IP dinamis seluler (4G/5G). Server Kubernetes di Cloud tidak bisa langsung "memanggil" Kubelet di perangkat edge.

K3s mengatasi ini secara elegan dengan teknologi bernama Tunnelut (terintegrasi langsung). Ketika agen edge menyala, ia akan membuka koneksi WebSocket keluar yang persisten (outbound tunnel) menuju server master. 

+--------------------------+                  +-------------------------+
|    Cloud/Data Center     |                  |       Edge Device       |
|                          |  Secure Tunnel   |                         |
|  [ K3s Master Server ]  |<==================|   [ K3s Light Agent ]   |
|                          | (Inbound Closed) |                         |
+--------------------------+                  +-------------------------+

Semua instruksi orkestrasi, pengiriman manifes YAML, dan pemantauan metrik kontainer akan dilewatkan melalui terowongan (tunnel) satu arah ini. Jika jaringan terputus, agen di edge akan tetap menjalankan kontainer Docker yang sudah ada secara mandiri tanpa merusak aplikasi, dan melakukan sinkronisasi ulang saat jaringan pulih kembali.

Kesimpulan: Masa Depan Orkestrasi yang Efisien

Memadukan Docker dan Kubernetes tidak lagi berarti Anda harus mengorbankan efisiensi hardware. Dengan memahami dekonstruksi runtime (beralih ke containerd) dan memisahkan beban control plane lewat framework seperti K3s, paradigma Zero-Node Overhead bukan lagi sekadar impian teoritis.

Pendekatan ini membuka peluang baru bagi para insinyur sistem untuk membawa keunggulan DevOps pipeline, GitOps, dan standardisasi kontainerisasi ke lini terdepan infrastruktur fisik, tanpa perlu khawatir perangkat keras mereka akan kehabisan napas. Orkestrasi modern bukan tentang seberapa besar sistem yang Anda kelola, melainkan seberapa cerdas Anda memangkas komponen yang tidak diperlukan.

Menikmati artikel ini? Berikan apresiasi Anda!