Belajar Kubernetes #4: Perintah Dasar kubectl

Perintah dasar kubectl selalu mengikuti satu pola: kubectl [verb] [resource] [nama] [flag]. Verb adalah aksinya (get, describe, delete), resource adalah objek yang dikenai aksi (pod, deployment, service), nama menunjuk objek spesifik, dan flag mengatur detail perilakunya. Begitu pola ini nempel di kepala, kamu tidak perlu lagi menghafal puluhan perintah satu per satu.

Artikel ini bagian keempat dari seri Belajar Kubernetes dari Nol. Kita akan praktik langsung: menjalankan perintah harian kubectl ke deployment nginx, membaca outputnya, lalu menutup dengan trik produktivitas yang dipakai tim Arrazy sehari-hari saat mengelola cluster untuk backend Go dan Laravel milik klien.

Prasyarat Sebelum Mulai

Pastikan Minikube dari bagian 1 masih jalan. Tutorial ini diuji dengan Minikube v1.33, kubectl v1.30, dan Kubernetes v1.30. Kalau kamu belum paham siapa yang sebenarnya menerima perintah kubectl di sisi cluster, baca dulu Belajar Kubernetes #3: Arsitektur Kubernetes Cluster. Singkatnya, kubectl hanyalah klien yang mengirim request HTTP ke API server.

Cek dulu cluster hidup:

minikube status
kubectl version

Lalu siapkan deployment nginx sebagai bahan praktik. Kalau deployment dari bagian 1 sudah terhapus, buat lagi:

kubectl create deployment nginx --image=nginx:1.27

Anatomi Perintah kubectl

Bedah satu contoh nyata:

kubectl get pods nginx-7584b6f84c-x2m9q -o wide

• get adalah verb, artinya ambil dan tampilkan data
• pods adalah resource yang dituju
• nginx-7584b6f84c-x2m9q adalah nama objek spesifik, boleh dikosongkan untuk menampilkan semua
• -o wide adalah flag, di sini mengatur format output

Nama resource punya bentuk panjang dan singkatan. pods bisa ditulis pod atau po, deployments jadi deploy, services jadi svc. Daftar lengkapnya bisa dilihat dengan kubectl api-resources.

Context dan Kubeconfig, Penentu Cluster Mana yang Kamu Sentuh

kubectl tahu harus mengirim perintah ke cluster mana dari file kubeconfig, defaultnya di ~/.kube/config. File ini menyimpan daftar cluster, user, dan context. Context adalah pasangan cluster plus user plus namespace default. Saat kamu install Minikube, context bernama minikube otomatis dibuat dan diaktifkan.

kubectl config current-context

Output yang diharapkan:

minikube

Kalau nanti kamu pegang lebih dari satu cluster, misalnya Minikube di laptop dan k3s di VPS, gunakan kubectl config get-contexts untuk melihat semuanya dan kubectl config use-context minikube untuk pindah. Kebiasaan mengecek context sebelum menjalankan perintah destruktif itu penting. Salah context berarti perintah delete kamu mendarat di cluster yang salah.

Tujuh Perintah Harian kubectl

Tujuh verb ini menutupi mayoritas pekerjaan harian: get, describe, logs, exec, apply, delete, dan edit. Kita coba satu per satu ke deployment nginx.

kubectl get, Melihat Daftar Resource

kubectl get deployments
kubectl get pods

Output yang diharapkan kurang lebih:

NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           3m

NAME                     READY   STATUS    RESTARTS   AGE
nginx-7584b6f84c-x2m9q   1/1     Running   0          3m

Bagian acak di belakang nama pod akan berbeda di mesinmu, itu normal karena pod dibuat otomatis oleh ReplicaSet. Mau lihat beberapa jenis resource sekaligus juga bisa:

kubectl get deploy,pods,svc

kubectl describe, Melihat Detail dan Event

get memberi ringkasan, describe memberi cerita lengkap. Ganti nama pod sesuai output di mesinmu:

kubectl describe pod nginx-7584b6f84c-x2m9q

Scroll ke bagian paling bawah, ada tabel Events. Di sinilah Kubernetes mencatat riwayat pod: kapan dijadwalkan ke node, kapan image ditarik, kapan container dinyalakan. Saat pod bermasalah, Events hampir selalu jadi tempat pertama untuk mencari petunjuk.

kubectl logs, Membaca Output Aplikasi

kubectl logs deployment/nginx

Perintah ini menampilkan log nginx, termasuk access log tiap request yang masuk. Dua flag yang sering dipakai: -f untuk mengikuti log secara live seperti tail -f, dan --previous untuk membaca log container yang sudah mati karena restart. Flag kedua ini penyelamat saat aplikasi crash berulang dan log-nya hilang tiap restart.

kubectl exec, Masuk ke Dalam Container

Kadang kamu perlu mengecek langsung dari dalam container: isi file konfigurasi, environment variable, atau koneksi ke service lain.

kubectl exec -it deployment/nginx -- /bin/bash

Flag -it membuat sesi interaktif dengan terminal, dan -- memisahkan argumen kubectl dari perintah yang dijalankan di dalam container. Setelah masuk, coba:

cat /etc/nginx/conf.d/default.conf
exit

Untuk perintah sekali jalan tanpa masuk shell, langsung saja:

kubectl exec deployment/nginx -- nginx -v

Output yang diharapkan:

nginx version: nginx/1.27.5

kubectl apply, Menerapkan File YAML

apply membaca file manifest lalu menyamakan kondisi cluster dengan isi file. Buat file percobaan bernama nginx-scale.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

Terapkan lalu cek hasilnya:

kubectl apply -f nginx-scale.yaml
kubectl get pods

Sekarang ada dua pod nginx. Jangan pusing dulu dengan struktur YAML-nya, itu jatah bagian 6. Yang penting dipahami sekarang: apply bersifat deklaratif. Kamu menyatakan kondisi akhir yang diinginkan, Kubernetes yang mengurus caranya.

kubectl delete, Menghapus Resource

Coba hapus salah satu pod, ganti dengan nama pod di mesinmu:

kubectl delete pod nginx-7584b6f84c-x2m9q
kubectl get pods

Hasilnya menarik: pod yang dihapus hilang, tapi pod baru langsung muncul menggantikannya. Itu kerjaan ReplicaSet yang menjaga jumlah replicas tetap dua. Kalau mau benar-benar bersih, hapus deployment-nya, tapi jangan lakukan sekarang karena masih kita pakai.

kubectl edit, Mengubah Resource Langsung

kubectl edit deployment nginx

Perintah ini membuka manifest deployment di editor terminal, defaultnya vi. Ubah replicas: 2 menjadi replicas: 3, simpan, keluar, lalu cek kubectl get pods. Pod ketiga muncul. Praktis untuk eksperimen, tapi di pekerjaan nyata tim Arrazy lebih memilih mengubah file YAML lalu apply ulang, supaya semua perubahan tercatat di Git dan bisa di-review.

Cara Membaca Output kubectl get pods

Empat kolom output kubectl get pods sering bikin pemula salah paham, jadi kita bedah:

Kolom	Arti
READY	Jumlah container siap dibanding total container di pod. 1/1 artinya satu dari satu container siap. 0/1 artinya container ada tapi belum siap menerima traffic
STATUS	Fase pod saat ini. Running berarti jalan normal. Pending berarti belum dijadwalkan atau image masih ditarik. CrashLoopBackOff berarti container terus mati dan Kubernetes menunda restart berikutnya. ImagePullBackOff berarti image gagal ditarik, biasanya salah nama atau tag
RESTARTS	Berapa kali container di-restart. Angka yang terus naik adalah alarm, cek logs --previous dan describe
AGE	Umur pod sejak dibuat. Berguna untuk memastikan pod baru benar-benar tercipta setelah update

Kombinasi ketiganya yang perlu dibaca sebagai satu kesatuan. Pod dengan STATUS Running tapi READY 0/1 berarti proses jalan tapi belum lolos pemeriksaan kesiapan, topik yang kita dalami di bagian 13 tentang probe.

Trik Produktivitas kubectl

Alias k dan Autocompletion

Mengetik kubectl ratusan kali sehari itu melelahkan. Hampir semua praktisi memakai alias satu huruf. Untuk pengguna bash:

echo 'alias k=kubectl' >> ~/.bashrc
echo 'source <(kubectl completion bash)' >> ~/.bashrc
echo 'complete -o default -F __start_kubectl k' >> ~/.bashrc
source ~/.bashrc

Baris kedua mengaktifkan autocompletion, jadi menekan Tab akan melengkapi nama perintah, resource, bahkan nama pod. Baris ketiga membuat autocompletion ikut bekerja pada alias k. Pengguna zsh tinggal ganti bash menjadi zsh dan ~/.bashrc menjadi ~/.zshrc, tanpa baris complete.

kubectl explain, Dokumentasi di Terminal

Lupa field apa saja yang valid di sebuah resource? Tidak perlu buka browser:

kubectl explain pod.spec.containers

Output-nya menjelaskan setiap field beserta tipenya, langsung dari API server sesuai versi cluster yang kamu pakai. Perintah ini akan sangat sering kamu pakai saat mulai menulis YAML sendiri.

Flag -o wide dan -o yaml

kubectl get pods -o wide

Flag -o wide menambah kolom IP pod dan node tempat pod berjalan. Sementara -o yaml menampilkan manifest lengkap sebuah resource persis seperti yang tersimpan di cluster:

kubectl get deployment nginx -o yaml

Ini cara cepat mempelajari struktur resource dari objek yang sudah jalan, termasuk field default yang diisi otomatis oleh Kubernetes.

kubectl port-forward, Akses Cepat Tanpa Service

Mau membuka nginx di browser tanpa bikin Service dulu? Forward saja port-nya:

kubectl port-forward deployment/nginx 8080:80

Output yang diharapkan:

Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

Buka http://localhost:8080 di browser dan halaman selamat datang nginx muncul. Tekan Ctrl+C untuk berhenti. Teknik ini juga aman dipakai di cluster production untuk mengintip dashboard internal atau database tanpa mengekspos apa pun ke publik. Tim kami memakainya hampir tiap hari saat membangun sistem aplikasi untuk klien, misalnya mengecek service backend yang belum punya Ingress.

Troubleshooting Error Umum kubectl

error: You must be logged in to the server (Unauthorized)

Artinya request sampai ke API server tapi kredensialmu ditolak. Penyebab tersering di Minikube adalah sertifikat client yang kedaluwarsa atau kubeconfig yang menunjuk kredensial lama setelah cluster dibuat ulang. Solusi:

minikube update-context

Kalau masih gagal, jalan terakhir yang hampir selalu beres adalah minikube delete lalu minikube start. Cek juga apakah variabel KUBECONFIG sedang menunjuk file lain dengan echo $KUBECONFIG.

The connection to the server localhost:8080 was refused

Error klasik yang artinya kubectl tidak menemukan kubeconfig sama sekali, lalu jatuh ke alamat default localhost:8080. Biasanya karena Minikube belum dinyalakan atau kamu menjalankan kubectl sebagai user lain, misalnya lewat sudo, yang home directory-nya tidak punya ~/.kube/config. Jalankan minikube start dan jangan pakai sudo untuk kubectl.

Perintah Mendarat di Cluster yang Salah

Kamu merasa sudah membuat deployment tapi kubectl get pods hasilnya kosong, atau sebaliknya muncul resource asing yang tidak pernah kamu buat. Hampir pasti context-mu sedang menunjuk cluster lain. Cek dan pindahkan:

kubectl config get-contexts
kubectl config use-context minikube

Tanda bintang di output get-contexts menunjukkan context aktif. Biasakan melirik context setiap kali membuka terminal baru, apalagi kalau kamu pegang cluster production.

exec Gagal: /bin/bash no such file or directory

Tidak semua image punya bash. Image berbasis Alpine misalnya hanya menyediakan sh. Kalau kubectl exec -it ... -- /bin/bash gagal dengan error ini, ganti dengan:

kubectl exec -it deployment/nginx -- /bin/sh

Rangkuman dan Lanjut ke Bagian 5

Kamu sekarang pegang fondasi terpenting untuk bekerja dengan Kubernetes: pola verb resource nama flag, tujuh perintah harian, cara membaca output get, plus alias dan autocompletion supaya kerja lebih cepat. Semua materi setelah ini tinggal soal mengenal resource baru, karena cara mengoperasikannya tetap lewat perintah yang sama.

Di bagian berikutnya, Belajar Kubernetes #5: Pod, Unit Terkecil Kubernetes, kita bedah pod lebih dalam: lifecycle-nya, kenapa satu pod bisa berisi lebih dari satu container, dan kapan itu berguna. Artikelnya terbit menyusul, pantau daftarnya di halaman hub Belajar Kubernetes.

Referensi

• kubectl Reference, kubernetes.io
• kubectl Quick Reference, kubernetes.io
• Organizing Cluster Access Using kubeconfig Files, kubernetes.io
• Kubectl Handbook, minikube.sigs.k8s.io