kubectl Tips #

Dalam operasional harian Kubernetes, CLI kubectl adalah alat utama yang menghubungkan kita dengan kontrol penuh atas seluruh sumber daya di dalam kluster. Meskipun hampir semua site reliability engineer (SRE) dan software engineer mengetahui perintah-perintah dasar seperti kubectl get pods, hanya sebagian kecil yang memanfaatkan fitur-fitur tingkat lanjut untuk mempercepat pemecahan masalah (troubleshooting). Saat terjadi insiden di lingkungan produksi, kecepatan navigasi baris perintah berdampak langsung pada metrik Mean Time to Resolution (MTTR). Artikel ini menyajikan panduan mendalam tentang tips, trik, dan konfigurasi canggih kubectl yang akan meningkatkan produktivitas operasional kita secara signifikan — mulai dari manipulasi output JSONPath, teknik debugging tingkat lanjut tanpa mengganggu kestabilan pod, manajemen multi-kluster, hingga otomatisasi dengan plugin dan alias shell.

Daftar Lengkap Shortcut Resource Names #

Kubernetes memiliki puluhan jenis sumber daya (resources). Mengetik nama lengkap seperti persistentvolumeclaims atau customresourcedefinitions berulang-ulang sangat membuang waktu. Oleh karena itu, Kubernetes menyediakan nama alias pendek (shortnames) resmi untuk hampir setiap jenis objek standar.

Kita dapat menghafal nama-nama pendek paling krusial berikut untuk menghemat ketukan tombol pada keyboard:

Untuk melihat seluruh nama pendek yang didukung oleh kluster kita aktif saat ini (termasuk Custom Resource yang diinstal oleh operator pihak ketiga), kita dapat menggunakan perintah berikut:

# Menampilkan daftar lengkap semua resource beserta API group, shortnames, dan cakupan namespace
kubectl api-resources

Manipulasi Output Tingkat Lanjut #

Secara default, kubectl menampilkan informasi dalam bentuk tabel sederhana. Namun, saat mengelola ratusan objek, kita memerlukan representasi data yang lebih spesifik. kubectl mendukung format output tingkat lanjut menggunakan ekspresi JSONPath, Custom Columns, dan integrasi pipa dengan perkakas jq.

1. Memanfaatkan JSONPath untuk Ekstraksi Data Presisi #

JSONPath memungkinkan kita memfilter dan mengambil nilai properti tertentu dari struktur data JSON yang dikembalikan oleh Kubernetes API Server. Sintaksis dasar JSONPath di dalam kubectl selalu dibungkus dengan tanda kutip tunggal dan kurung kurawal: -o jsonpath='{.path.to.field}'.

Berikut adalah kumpulan kueri JSONPath produksi yang sangat berguna:

# 1. Mendapatkan daftar nama semua Pod di namespace saat ini
kubectl get pods -o jsonpath='{.items[*].metadata.name}'

# 2. Menampilkan daftar nama Pod beserta alamat IP internal masing-masing
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}'

# 3. Mendapatkan semua nama citra kontainer (container images) yang sedang berjalan di kluster
kubectl get pods -A -o jsonpath='{.items[*].spec.containers[*].image}'

# 4. Memeriksa kapasitas total CPU dan Memory di setiap Node kluster
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t CPU: "}{.status.capacity.cpu}{"\t MEMORY: "}{.status.capacity.memory}{"\n"}{end}'

# 5. Mencari kontainer yang tidak memiliki konfigurasi limits CPU di namespace produksi
kubectl get deploy -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.containers[*].resources.limits.cpu}{"\n"}{end}'

2. Merancang Tabel Custom Columns #

Jika kueri JSONPath terlalu panjang untuk dibaca, kita dapat merancang tata letak tabel kita sendiri dengan mendefinisikan nama kolom baru beserta jalur JSONPath terkait menggunakan format -o custom-columns=<KEY>:<JSONPath>.

# Membuat laporan kustom untuk pemantauan Pod
kubectl get pods -n production \
  -o custom-columns=\
"NAMA POD:.metadata.name,\
STATUS POD:.status.phase,\
IP KONTENAL:.status.podIP,\
ALOKASI NODE:.spec.nodeName,\
RESTART KE-:.status.containerStatuses[0].restartCount"

Output yang dihasilkan akan langsung tersusun rapi seperti berikut:

NAMA POD             STATUS POD   IP KONTENAL    ALOKASI NODE   RESTART KE-
payment-api-v1-abc   Running      10.244.3.45    node-worker-1  0
billing-job-v2-xyz   Failed       10.244.4.12    node-worker-2  3

3. Integrasi Pipa dengan jq #

Untuk manipulasi tingkat lanjut yang melibatkan penyaringan kondisi kompleks, pengelompokan (grouping), atau operasi matematika, kita dapat mengalirkan format JSON asli ke biner jq.

# 1. Menampilkan nama Pod yang mengalami restart lebih dari 5 kali
kubectl get pods -o json | jq '.items[] | select(.status.containerStatuses[0].restartCount > 5) | {name: .metadata.name, restarts: .status.containerStatuses[0].restartCount}'

# 2. Menghitung total penggunaan CPU requests dari seluruh pod di kluster
kubectl get pods -A -o json | jq '[.items[].spec.containers[].resources.requests.cpu | select(. != null)]'

4. Mengurutkan dan Memfilter Hasil (Sorting & Filtering) #

Kita dapat mengurutkan baris keluaran secara native berdasarkan field JSON tertentu menggunakan flag --sort-by.

# 1. Mengurutkan Pod berdasarkan waktu pembuatan (Pod terbaru di posisi paling bawah)
kubectl get pods --sort-by=.metadata.creationTimestamp

# 2. Mengurutkan Pod berdasarkan jumlah restart kontainer terbanyak
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# 3. Menampilkan semua label yang menempel pada objek Pod
kubectl get pods --show-labels

# 4. Memfilter Pod berdasarkan label spesifik (app=payment-gateway)
kubectl get pods -l app=payment-gateway

# 5. Memfilter Pod dengan kondisi logika set (ambil yang berjalan di staging atau prod)
kubectl get pods -l 'environment in (staging, production)'

# 6. Memfilter Pod dengan negasi (abaikan Pod yang berlabel tier=frontend)
kubectl get pods -l 'tier!=frontend'

Teknik Debugging Tingkat Produksi #

Saat aplikasi mengalami kegagalan, kita membutuhkan akses diagnosis langsung tanpa mengganggu proses bisnis yang sedang berjalan. Berikut adalah teknik debugging menggunakan exec, debug, port-forward, dan analisis log tingkat lanjut.

1. kubectl exec vs kubectl debug (Layanan Distroless) #

Secara tradisional, kita masuk ke dalam kontainer yang bermasalah menggunakan perintah kubectl exec:

# Masuk ke shell interaktif kontainer utama
kubectl exec -it <pod-name> -- bash

# Jika kontainer tidak memiliki bash shell, coba sh alternatif
kubectl exec -it <pod-name> -- sh

Namun, di lingkungan produksi modern yang menerapkan prinsip keamanan ketat, citra kontainer sering kali dikemas dalam format Distroless atau Minimal (seperti Alpine minimal). Citra ini tidak memiliki perkakas utilitas dasar seperti bash, sh, curl, nslookup, bahkan ping untuk meminimalkan luas permukaan serangan (attack surface). Jika kita mencoba melakukan kubectl exec ke kontainer tersebut, kita akan mendapatkan galat (error) berupa shell tidak ditemukan.

Untuk mengatasi masalah ini, kita dapat menyisipkan Ephemeral Debug Container ke dalam Pod yang sudah berjalan tanpa perlu melakukan restart. Debug container ini akan berjalan di namespace jaringan dan proses yang sama dengan kontainer aplikasi kita.

# Menyisipkan kontainer debug interaktif menggunakan citra netshoot (toolkit jaringan lengkap)
kubectl debug -it <pod-name> \
  --image=nicolaka/netshoot \
  --target=<target-container-name>

Di dalam kontainer debug ephemeral tersebut, kita dapat menggunakan semua perkakas jaringan lengkap (seperti tcpdump, curl, dig) untuk menganalisis kontainer aplikasi utama yang bertetangga dengannya.

2. kubectl port-forward Fleksibel #

Kita dapat mengarahkan lalu lintas port jaringan dari mesin lokal kita langsung ke dalam kluster tanpa perlu membuat Service eksternal atau Ingress.

# 1. Forward ke port spesifik Pod
kubectl port-forward pod/<pod-name> 8080:8080

# 2. Forward ke port Deployment (secara otomatis memilih salah satu pod replika yang sehat)
kubectl port-forward deployment/payment-service 8080:8080

# 3. Forward ke Service internal
kubectl port-forward service/database-service 5432:5432

# 4. Port forward ke alamat IP non-localhost (agar dapat diakses oleh perangkat lain di jaringan yang sama)
kubectl port-forward service/payment-service 8080:80 --address=0.0.0.0

3. Analisis Log Lanjutan (kubectl logs) #

Membaca log mentah yang terlalu panjang sangat menyulitkan. Kita harus membatasi pencarian log menggunakan parameter waktu dan filter.

# 1. Mengikuti log secara real-time (stream logs)
kubectl logs -f <pod-name>

# 2. Mengambil log dari Pod yang memiliki beberapa kontainer (multi-container pod)
kubectl logs <pod-name> -c <container-name>

# 3. Mengambil log dari seluruh kontainer di dalam Pod secara bersamaan
kubectl logs <pod-name> --all-containers

# 4. Menampilkan 100 baris log terakhir
kubectl logs <pod-name> --tail=100

# 5. Menampilkan log yang tercatat dalam 30 menit terakhir saja
kubectl logs <pod-name> --since=30m

# 6. Menampilkan log sejak stempel waktu absolut (ISO-8601)
kubectl logs <pod-name> --since-time=2026-06-17T08:00:00Z

# 7. Menyertakan stempel waktu (timestamps) di setiap baris log
kubectl logs <pod-name> --timestamps

# 8. Mengambil log berdasarkan label selector (menggabungkan log dari semua pod replika)
kubectl logs -l app=payment-service --tail=50

Memantau Event Kluster secara Real-Time #

Ketika sebuah Pod terjebak dalam status Pending, ImagePullBackOff, atau CrashLoopBackOff, log internal aplikasi biasanya kosong karena proses kontainer belum sempat berjalan. Satu-satunya sumber informasi tepercaya pada fase ini adalah Kubernetes Events.

# 1. Memantau transisi keadaan seluruh objek di namespace target secara real-time
kubectl get events -w

# 2. Menampilkan events dan mengurutkannya berdasarkan waktu kejadian terakhir
kubectl get events --sort-by=.lastTimestamp

# 3. Menampilkan events lintas seluruh namespace di kluster untuk mendeteksi anomali global
kubectl get events -A --sort-by=.lastTimestamp | tail -30

Selain perintah kubectl get events, kita dapat membaca peristiwa kegagalan spesifik di akhir output deskripsi objek:

# Describe pod memberikan informasi status kontainer dan riwayat event penutupan/penjadwalan
kubectl describe pod <pod-name>

Manajemen Multi-Cluster via Kubeconfig #

Sering kali kita harus mengelola beberapa kluster Kubernetes sekaligus (misalnya kluster staging di cloud provider A dan kluster production di on-premise). Seluruh kredensial akses dan alamat API server disimpan di dalam file konfigurasi kubeconfig yang terletak di ~/.kube/config.

Struktur Kubeconfig #

Kubeconfig membagi konfigurasi menjadi tiga elemen utama:

• Clusters: Alamat URL endpoint API Server kluster dan sertifikat CA terkait.
• Users: Kredensial autentikasi (seperti token akses, sertifikat client, atau kunci enkripsi).
• Contexts: Pasangan pemetaan antara nama kluster, user, dan namespace default.

# 1. Melihat seluruh context yang terdaftar di mesin lokal
kubectl config get-contexts

# 2. Menampilkan context aktif saat ini
kubectl config current-context

# 3. Berpindah akses ke kluster lain secara instan
kubectl config use-context production-gcp-cluster

# 4. Mengubah default namespace untuk context saat ini (menghindari pengetikan -n berulang)
kubectl config set-context --current --namespace=finance-prod

Menggabungkan Beberapa File Kubeconfig secara Aman #

Ketika kita mengunduh file kredensial baru dari penyedia cloud, mereka sering kali memberikan file config terpisah (seperti config-staging.yaml). Menimpa langsung file ~/.kube/config bawaan akan menghapus akses kluster kita yang lain. Kita harus menggabungkannya secara aman:

# Gabungkan file config lama dengan config baru ke dalam file sementara, lalu timpa dengan aman
KUBECONFIG=~/.kube/config:~/Downloads/config-staging.yaml kubectl config view --flatten > ~/.kube/merged-config
mv ~/.kube/merged-config ~/.kube/config
chmod 600 ~/.kube/config

Utilitas Navigasi Multi-Cluster: kubectx dan kubens #

Meskipun perintah kubectl config sangat kuat, mengetiknya secara manual terlalu panjang. Kita direkomendasikan menginstal alat pembantu kubectx (untuk berpindah kluster) dan kubens (untuk berpindah namespace).

# Berpindah kluster secara interaktif atau langsung menggunakan nama
kubectx production-cluster

# Berpindah namespace default secara instan
kubens prod-payment

Ekstensi Kustom dengan Krew Plugin Manager #

Sama seperti apt untuk Debian atau brew untuk macOS, krew adalah manajer paket plugin resmi untuk kubectl. Dengan Krew, kita dapat memperluas kemampuan CLI kubectl dengan ratusan skrip plugin buatan komunitas.

1. Cara Instalasi Krew #

Jalankan perintah instalasi berikut di terminal Unix Anda:

# Mengunduh dan mengonfigurasi Krew di direktori user
(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/arm64/arm64/')" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew-${OS}_${ARCH}.tar.gz" &&
  tar zxvf "krew-${OS}_${ARCH}.tar.gz" &&
  KREW=./krew-"${OS}_${ARCH}" &&
  "$KREW" install krew
)

# Tambahkan baris berikut ke ~/.bashrc atau ~/.zshrc agar biner dapat dieksekusi langsung:
export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

2. Rekomendasi Plugin Esensial untuk Produksi #

Setelah Krew terpasang, instal plugin-plugin produktivitas tinggi berikut:

# 1. kubectl neat: Membersihkan metadata system yang tidak perlu saat mengekspor manifest YAML
# Sangat penting saat kita ingin mengekspor resource aktif dari kluster untuk disimpan ke Git (GitOps)
kubectl krew install neat
# Penggunaan: kubectl get deploy/payment-api -o yaml | kubectl neat > deploy-clean.yaml

# 2. kubectl tree: Menampilkan hierarki relasi antar resource secara grafis
# Memudahkan kita melihat Pod mana saja yang dibuat oleh ReplicaSet dari Deployment tertentu
kubectl krew install tree
# Penggunaan: kubectl tree deploy/payment-api

# 3. kubectl view-secret: Mendekode isi secret base64 secara instan tanpa perlu echo -n | base64 --decode
kubectl krew install view-secret
# Penggunaan: kubectl view-secret db-credentials-secret db-password

# 4. kubectl whoami: Menampilkan informasi otorisasi user/role saat ini di kluster aktif
kubectl krew install whoami

# 5. kubectl access-matrix: Memeriksa matriks izin RBAC (apakah role kita bisa create/delete resource tertentu)
kubectl krew install access-matrix
# Penggunaan: kubectl access-matrix --namespace=default

Kustomisasi Shell, Alias, dan Autocomplete #

Mengetik kata kubectl ratusan kali sehari sangat melelahkan. Mengonfigurasi pintasan (alias) dan fitur penyelesaian otomatis (tab completion) adalah langkah wajib untuk efisiensi maksimal.

1. Mengaktifkan Autocomplete Resmi #

Pastikan shell Anda dikonfigurasi untuk melengkapi argumen perintah secara otomatis saat Anda menekan tombol TAB.

# Untuk pengguna shell Zsh (tambahkan ke ~/.zshrc):
source <(kubectl completion zsh)

# Untuk pengguna shell Bash (tambahkan ke ~/.bashrc):
source <(kubectl completion bash)

2. Kumpulan Alias Produktivitas Tinggi #

Tambahkan pintasan-pintasan alias berikut ke dalam file profil shell Anda (~/.zshrc atau ~/.bashrc):

# Alias dasar penyingkat perintah utama
alias k='kubectl'
alias kg='kubectl get'
alias kd='kubectl describe'
alias kl='kubectl logs'
alias kx='kubectl exec -it'
alias kdel='kubectl delete'

# Pintasan dengan filter namespace spesifik untuk mempercepat diagnosis
alias kprod='kubectl --namespace production'
alias kdev='kubectl --namespace development'

# Pintasan monitoring instan
alias kgpo='kubectl get pods'
alias kgdep='kubectl get deployments'
alias kgsvc='kubectl get services'
alias kgsec='kubectl get secrets'

3. Fungsi Shell Kustom Dinamis #

Kita juga dapat membuat fungsi shell tingkat lanjut yang menerima argumen dinamis untuk mempercepat pemecahan masalah jaringan atau pembersihan lingkungan:

# Fungsi 1: Melakukan pencarian log interaktif berdasarkan nama label aplikasi
klog() {
  kubectl logs -f -l app=$1 --max-log-requests=10 -n ${2:-production}
}
# Cara penggunaan: 
# klog payment-api           -> logs dari app=payment-api di namespace production
# klog auth-service staging  -> logs dari app=auth-service di namespace staging

# Fungsi 2: Membuat Pod debug ephemeral jaringan instan di namespace default
kping() {
  kubectl run net-debug-pod --rm -it --image=nicolaka/netshoot --restart=Never -- ping $1
}
# Cara penggunaan: kping 10.244.3.45

Anti-Pattern dalam Operasional kubectl #

Meskipun kubectl sangat fleksibel, menggunakannya secara serampangan di lingkungan produksi dapat membahayakan stabilitas dan keamanan kluster.

1. Modifikasi Imperatif Langsung di Produksi (Ad-Hoc Mutability) #

// ANTI-PATTERN: Melakukan perubahan konfigurasi aplikasi langsung menggunakan perintah imperatif.
$ kubectl edit deployment/payment-api -n production
$ kubectl patch service/payment-service -p '{"spec":{"type":"LoadBalancer"}}'

✓ SOLUSI: Terapkan Praktik GitOps Deklaratif.
Seluruh perubahan keadaan kluster harus dideklarasikan di dalam repositori Git 
(misalnya melalui Helm chart atau Kustomize overlays) dan diterapkan secara otomatis 
menggunakan pipa CI/CD atau operator rekonsiliasi seperti ArgoCD. Perubahan manual 
menggunakan kubectl edit akan menyebabkan konfigurasi kluster tidak sinkron (drift) 
dengan Git dan akan tertimpa secara paksa saat pipeline berikutnya berjalan.

2. Menjalankan Pod Debug Tanpa Batas Sumber Daya (No Resource Limits) #

Menjalankan pod interaktif menggunakan kubectl run secara bebas di kluster produksi tanpa menentukan alokasi memori atau CPU request.

# ANTI-PATTERN: Kontainer debug ini berisiko melahap sumber daya fisik Node yang tidak terbatas
kubectl run stress-tester --image=ubuntu -- stress --cpu 4

# ==============================================================================
# BENAR: Selalu tentukan limits sumber daya terkecil jika terpaksa menjalankan Pod ad-hoc
kubectl run prod-debug --image=nicolaka/netshoot --rm -it \
  --overrides='{ "spec": { "resources": { "limits": { "cpu": "200m", "memory": "256Mi" } } } }'

Jika kita tidak menentukan batasan sumber daya pada pod ad-hoc yang kita jalankan, pod tersebut akan masuk ke dalam QoS Class BestEffort. Apabila pod tersebut mengalami kebocoran memori (memory leak) atau konsumsi CPU yang tinggi, ia akan mengganggu kestabilan Pod produksi penting lainnya yang berjalan di Node fisik yang sama (noisy neighbor effect).

Checklist Audit Efisiensi Operasional kubectl #

Gunakan checklist ini untuk mengukur kesiapan dan efisiensi navigasi baris perintah Anda:

KONFIGURASI SHELL DAN SHORTCUT:
  □ Shell autocomplete sudah aktif dan berfungsi melengkapi nama resource secara dinamis.
  □ Kumpulan alias dasar (seperti 'k' untuk 'kubectl') telah terkonfigurasi di profil shell.
  □ Memahami dan menggunakan shortnames resmi untuk resource inti (po, svc, deploy, pvc).
  □ Menggunakan perkakas 'kubectx' dan 'kubens' untuk mengelola multi-cluster context secara cepat.

MANIPULASI DATA DAN FORMATTING:
  □ Mampu mengekstrak field manifest spesifik menggunakan kueri JSONPath tanpa membuang waktu membaca YAML penuh.
  □ Menggunakan opsi '-o custom-columns' untuk membuat laporan tabel pemantauan kustom yang mudah dibaca.
  □ Memanfaatkan pipa 'jq' untuk melakukan penyaringan dan penghitungan logika kompleks pada output JSON.
  □ Menggunakan plugin 'kubectl neat' untuk membersihkan metadata system field saat melakukan ekspor YAML.

TEKNIK DEBUGGING DAN KEAMANAN:
  □ Memanfaatkan ephemeral debug container ('kubectl debug') untuk mendebug pod minimal/distroless.
  □ Mampu mengarahkan port internal kluster ke mesin lokal menggunakan 'kubectl port-forward'.
  □ Membatasi pencarian log dengan parameter '--since' atau '--tail' untuk mempercepat isolasi galat.
  □ Menghindari modifikasi langsung 'kubectl edit' pada objek produksi di luar jalur pipa GitOps.
  □ Selalu menyertakan parameter overrides limits sumber daya saat membuat pod ad-hoc di produksi.

Ringkasan #

• Kecepatan Navigasi CLI Adalah Kunci — Menguasai pintasan (shortnames) dan alias shell secara langsung mengurangi waktu pengetikan dan meminimalkan kesalahan ketik saat insiden kritis.
• JSONPath untuk Otomatisasi Data — Pelajari dasar sintaksis JSONPath untuk menyaring data kluster secara spesifik alih-alih melakukan pemindaian YAML secara manual.
• Gunakan Ephemeral Container untuk Debugging — Tinggalkan praktik memasang shell perkakas di dalam citra kontainer aplikasi utama; gunakan kubectl debug dengan citra netshoot untuk menjaga keamanan kluster.
• Events sebagai Deteksi Awal — Selalu periksa peristiwa kluster (kubectl get events) sebelum membaca log aplikasi untuk mendiagnosis kegagalan penjadwalan atau penarikan citra kontainer.
• Kelola Kubeconfig secara Aman — Pisahkan file config kluster antar lingkungan dan manfaatkan kubectx/kubens untuk menghindari insiden salah eksekusi perintah pada kluster produksi.
• Lakukan Bersih-Bersih Manifest — Gunakan plugin kubectl neat untuk membuang baris sistem bawaan (seperti managedFields) sebelum menyimpan kembali manifest ke dalam kontrol versi Git.

← Sebelumnya: Kustomize   Berikutnya: Local Development Tools →