budiman rahardjo / Kenapa gue bikin Nahkoda, Kubernetes dalam Bahasa Manusia

Created Wed, 09 Sep 2026 00:00:00 +0000 Modified Wed, 09 Sep 2026 14:16:05 +0700

Kenapa gue bikin Nahkoda, Kubernetes dalam Bahasa Manusia

Kali ini gue mau share satu project CLI yang beberapa waktu terakhir gue rapihin lagi, nama nya Nahkoda.

Nahkoda ini semacam penerjemah di depan kubectl. Kita nulis maksud nya pake Bahasa Indonesia sederhana, terus Nahkoda yang nyusun command Kubernetes nya.

Contoh nya kayak gini:

liat kru rusak
baca jurnal api-7 terus
masuk kru backend-5d7f
pindah kapal staging

Di belakang layar, command itu tetap jadi kubectl get, kubectl logs, kubectl exec, atau kubectl config use-context. Jadi Nahkoda bukan pengganti kubectl dan ga berusaha menyembunyikan Kubernetes. Tujuan nya lebih simple: bikin command sehari-hari lebih gampang diinget dan lebih enak dibaca.

Bahasa manusia masuk, command kubectl yang masih bisa diaudit keluar.

awal nya kenapa bikin ini?

Sebagai orang yang sering pegang environment Kubernetes, gue udah cukup familiar sama kubectl. Tapi familiar bukan berarti ga pernah salah ketik, lupa namespace, salah context, atau harus buka history cuma buat nyari flag yang jarang dipake.

Command kayak gini sebenernya powerful:

kubectl get pods -A --field-selector=status.phase!=Running

Tapi untuk kebutuhan sehari-hari, maksud yang ada di kepala gue biasanya cuma: liat kru yang rusak.

Dari situ gue kepikiran, gimana kalo istilah Kubernetes dibikin jadi metafora pelayaran:

Kubernetes Bahasa Nahkoda
Cluster / context Kapal
Namespace Geladak
Pod Kru
Node Mesin
Deployment Armada
DaemonSet Penjaga
Service Pelabuhan
Ingress Mercusuar
ConfigMap Peta
Secret Sandi
Logs Jurnal
Events Berita

Metafora ini bukan cuma biar lucu. Waktu istilah nya konsisten, command jadi lebih gampang ditebak walaupun belum pernah baca dokumentasi lengkap nya.

command yang paling sering gue pake

Nahkoda bisa dipake satu kali dari shell:

nahkoda liat kru rusak
nahkoda cek kru api-7
nahkoda baca jurnal api-7 terus
nahkoda liat berita
nahkoda cek kesehatan

Atau masuk ke mode interaktif:

nahkoda

Setelah muncul prompt ⚓ >, ketik li lalu tekan TAB. Autocomplete ini hidup di dalam REPL Nahkoda, bukan shell completion zsh/bash.

Untuk pindah cluster/context:

liat kapal
pindah kapal staging

Untuk namespace tertentu:

liat kru di geladak payment
cek kru api-7 di geladak payment

Dan sebelum command yang mengubah cluster, bisa dicek dulu hasil terjemahan nya:

nahkoda --dry-run hapus kru api-7
nahkoda --dry-run atur armada backend ke 5

Ini penting karna bikin, hapus, atur, dan tukar memang command mutatif. Nahkoda membantu menerjemahkan, tapi keputusan buat mengubah cluster tetap tanggung jawab operator.

update v1.5.3: jangan cuma diem waktu ada masalah

Salah satu hal yang baru gue perbaiki justru bukan fitur command baru, tapi feedback saat ada masalah.

Sebelum nya, waktu ga ada Kubernetes context aktif atau cluster lagi ga merespons, terminal bisa keliatan kayak hang setelah menulis Menjalankan.... Secara teknis proses nya masih menunggu timeout, tapi dari sisi user ga ada kepastian: ini lagi kerja, error, atau beneran stuck?

Di v1.5.3 perilaku nya dibikin lebih jelas:

  • waktu REPL dibuka, Nahkoda langsung cek apakah ada context aktif
  • operasi cluster gagal cepat kalo context belum dipilih
  • error nya kasih petunjuk liat kapal dan pindah kapal <nama>
  • kalo context ada tapi kubectl belum merespons, setelah 2 detik muncul status menunggu
  • command finite tetap dihentikan oleh timeout konfigurasi, default nya 30 detik
  • exec dan logs -f tetep dibiarkan jalan sampai user berhentiin sendiri
  • stderr kubectl sekarang langsung keliatan, termasuk pada command yang output nya difilter

Screenshot di atas dibuat dari output aktual binary Homebrew v1.5.3 dengan kubeconfig kosong, lalu format visual nya dirapihin supaya nyaman dibaca di blog. Jadi ga ada cluster production yang disentuh cuma buat bikin demo.

Menurut gue ini detail kecil tapi penting. CLI yang bagus bukan cuma bisa jalan waktu kondisi normal, tapi juga harus jujur waktu dia lagi nunggu atau ga bisa lanjut.

di balik layar nya gimana?

Nahkoda ditulis pake Go dan alur nya dipisah jadi beberapa tahap:

input Bahasa Indonesia
parser bikin AST
semantic resolver validasi maksud
planner susun rencana kubectl
executor jalankan command
kubectl berkomunikasi ke cluster

Pemisahan ini bikin parser ga perlu tau cara menjalankan proses, dan executor ga perlu nebak arti kata kru atau geladak.

Beberapa hal yang gue rapihin di release terbaru:

  • konfigurasi kubectl_path, namespace default, timeout, cache TTL, dan suggestions sekarang benar-benar dipake runtime
  • config parsial ga lagi diam-diam mematikan nilai default
  • audit kesehatan ga boleh bilang sehat kalo pemeriksaan pod, node, atau event gagal
  • typo seperti liat kur diarahkan ke suggestion kru tanpa bikin automation nunggu prompt
  • autocomplete diselaraskan sama command yang memang didukung
  • create resource yang grammar nya belum lengkap ditolak sebelum memanggil kubectl
  • error log dibatasi permission 0600
  • metadata binary release sekarang terpasang dengan benar lewat GoReleaser

Semua perubahan itu dikunci pake regression test, lalu CI ngejalanin lint, race test, build, dan integration test pake Kind sebelum release dibuat.

proses bikin nya juga banyak dibantu AI

Sama kayak project JagoanCV yang pernah gue ceritain, Nahkoda juga banyak dibantu AI. Bukan cuma buat nulis code, tapi buat audit perilaku, nyari gap antara dokumentasi sama implementasi, bikin test, dan ngebongkar asumsi yang ternyata salah.

Contoh nya config. Di dokumentasi terlihat seolah namespace, timeout, dan toggle autocomplete udah tersedia. Struct dan file JSON nya memang ada. Tapi setelah ditelusuri, beberapa field itu belum benar-benar masuk ke jalur runtime.

AI lumayan membantu buat menyisir hal kayak gitu, tapi hasil nya tetep harus diuji. Bahkan setelah semua test hijau, pemakaian langsung di terminal masih bisa nemuin masalah UX yang unit test belum tangkap.

Loop nya kurang lebih tetep sama:

pake sendiri → nemu yang ganjel → reproduksi → perbaiki → test → release

Menurut gue bagian paling berguna dari AI bukan bikin semuanya sekali jadi, tapi memperpendek jarak dari “ada yang aneh” sampai “akar masalah nya ketemu”.

cara install

Untuk macOS atau Linux lewat Homebrew:

brew tap budimanr3101/nahkoda
brew install nahkoda

Kalo udah pernah install:

brew update
brew upgrade nahkoda

Cek versi yang aktif:

nahkoda --help | head -1

Untuk Windows tersedia lewat Scoop, dan binary macOS, Linux, serta Windows juga ada di halaman release GitHub.

Source code nya open-source di github.com/budimanr3101/nahkoda, dokumentasi lengkap ada di budimanr3101.github.io/nahkoda, dan release v1.5.3 bisa dilihat di GitHub Releases.

selanjut nya mau dibawa kemana?

Masih ada beberapa hal yang menurut gue menarik buat dikembangin:

  • native shell completion untuk zsh, bash, dan fish
  • konfirmasi yang aman buat command mutatif dengan opsi --yes
  • create deployment/service/ingress dengan grammar yang tetep sederhana
  • filtering berbasis output JSON supaya ga bergantung ke format tabel kubectl
  • rotasi error log

Tapi untuk sekarang, target utama nya bukan nambah command sebanyak-banyak nya. Gue lebih pengen command yang sudah ada bisa dipake dengan perilaku yang jelas, aman, dan ga bikin operator nebak-nebak.

Kalo ada yang nyobain Nahkoda terus nemu command yang terasa aneh, typo yang belum kebaca, atau output yang bikin bingung, kabarin gue. Feedback dari pemakaian langsung biasanya jauh lebih berharga daripada asumsi waktu ngoding.

thanks ⚓