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 kapaldanpindah 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
execdanlogs -ftetep 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 kurdiarahkan ke suggestionkrutanpa 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 ⚓