Panduan Lengkap Persiapan Interview Kubernetes (Bagian 1)

Panduan praktis berbasis skenario dalam format tanya jawab sekaligus materi persiapan ujian CKA. Berisi 75+ pertanyaan yang membahas fondasi → arsitektur → networking → security → troubleshooting → skenario dunia nyata. Untuk berbagai posisi seperti SRE • DevOps • Kubernetes Admin • Platform Engineer

Bagian 1 — Pengertian Dasar & Konsep Utama

Selamat datang di bagian pertama dari 12 bagian Panduan Lengkap Persiapan Wawancara Kubernetes. Kita akan memulai dari fondasi paling penting: memahami konsep dasar Kubernetes dan bagaimana komponen-komponen utamanya bekerja bersama dalam mengelola aplikasi berbasis container.

Pada bagian ini, kita akan membahas Pod, Node, Control Plane, etcd, kubelet, kube-proxy, Namespace, label, selector, hingga konsep desired state dan reconciliation loop. Pemahaman ini akan menjadi bekal penting sebelum masuk ke pembahasan yang lebih kompleks pada bagian-bagian berikutnya

Q1. Apa itu Kubernetes dan mengapa kita membutuhkannya?


Jawaban singkat:

Kubernetes (K8s) adalah sebuah platform orkestrasi container open-source yang bertujuan untuk mengotomatisasi deployment, scaling, dan pengelolaan aplikasi berbasis container di dalam sebuah cluster yang terdiri dari banyak machine/server.

Pembahasan lebih dalam: Sebelum Kubernetes, menjalankan container di production berarti harus menangani berbagai hal secara manual:

  • Server mana yang menjalankan container tertentu
  • Apa yang terjadi ketika sebuah mesin mengalami kegagalan/kerusakan
  • Bagaimana melakukan rollout versi baru dengan aman
  • Bagaimana membuat service dapat diakses oleh pengguna

Kubernetes menyelesaikan semua kebutuhan tersebut secara declarative. Kita cukup mendefinisikan apa yang diinginkan, contohnya “3 replikasi dari aplikasi web yang saya miliki”. Kubernetes akan terus bekerja agar kondisi aktual sesuai dengan apa yang diinginkan tersebut. Konsep ini disebut declarative model dengan reconciliation loop.

Kelebihan utama kubernetes:

  • Self-healing (me-restart container yang gagal/mati)
  • Horizontal scaling (auto-scale pada CPU/memory/custom metric)
  • Service discovery & load balancing (built-in DNS)
  • Rolling updates & rollbacks (zero-downtime deployment)
  • Secret & config management
  • Storage orchestration

Tujuan interviewer: Apakah kamu mengerti mengapa Kubernetes dibutuhkan, bukan hanya apa yang dapat dilakukannya?

Q2. Apa itu Pod? Mengapa tidak menjalankan container secara langsung?


Jawaban singkat:

A Pod adalah bagian/unit terkecil yang dapat di-deploy di Kubernetes — wadah untuk satu atau beberapa container yang saling terkait erat dan berbagi network namespace yang sama (IP + port space) and storage volumes.

Pembahasan lebih dalam:

  • container yang berada dalam sebuah Pod akan berbagi jaringan (memiliki IP yang sama dan berkomunikasi secara localhost), storage volumes, and lifecycle.
  • Kubernetes melakukan scheduling terhadap Pod, bukan container. Abstraksi ini memungkinkan container pendukung yang saling terhubung erat (seperti logging sidecar) berjalan berdampingan dengan aplikasi utama pada host yang sama dan berbagi resource.
  • Setiap Pod memperoleh IP unik di dalam cluster.

Contoh — minimal Pod manifest:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

Tujuan interviewer: Banyak kandidat yang masih keliru membedakan “container” dan “Pod”. Mampu menjelaskan perbedaannya dengan jelas menunjukkan pemahaman Kubernetes yang lebih baik.

Q3. Kapan beberapa container dapat dijalankan dalam satu Pod?


Jawaban singkat:

Hanya ketika container memiliki keterkaitan yang sangat erat dan mereka harus saling berbagi network, storage, dan lifecycle — biasanya menggunakan pola sidecar, ambassador, dan adapter.

Pola:

  • Sidecar: Proses pendukung yang berjalan berdampingan dengan aplikasi utama, misalnya log shipper, Istio proxy, atau config reloader.
  • Ambassador: Proxy yang mewakili aplikasi saat berkomunikasi dengan dunia luar, misalnya connection pooler untuk koneksi ke database.
  • Adapter: Menyesuaikan atau menstandarkan format output, misalnya mengubah format log aplikasi agar sesuai dengan format yang digunakan oleh sistem monitoring.

Anti-pattern: Menjalankan web server dan database dalam Pod yang sama. Keduanya memiliki lifecycle dan kebutuhan scaling yang berbeda, sehingga sebaiknya dijalankan dalam Deployment yang terpisah.

Q4. Jelaskan arsitektur Kubernetes secara high-level.


Jawaban singkat:

Kubernetes memiliki dua komponen utama: Control Plane (master) dan Worker Node (eksekutor). Control plane menentukan apa yang harus dijalankan, sedangkan Worker node menjalankan workload tersebut.

Komponen Control Plane:

Komponen                  Peran
kube-apiserver            Pintu masuk utama kedalam cluster. Semua proses baca/tulis harus melalui komponen ini.
etcd                      Penyimpanan key-value terdistribusi yang menyimpan seluruh status cluster.
kube-scheduler            Menentukan node mana yang harus menjalankan Pod baru.
kube-controller-manager   Menjalankan reconciliation loop (ReplicaSet, Node, Job controller).
cloud-controller-manager  Berkomunikasi dengan API penyedia cloud (LBs, volume).

Komponen Worker node:

Komponen            Peran
kubelet             Agen di setiap node; berkomunikasi dengan API server, menjalankan kontainer via CRI.
kube-proxy          Mengarahkan aturan jaringan untuk lalu lintas Service (iptables/IPVS).
Container Runtime   containerd, CRI-O — yang benar-benar menjalankan kontainer.

Alur dari “kubectl apply -f pod.yaml”:

  1. kubectl → API server (authN, authZ, validation).
  2. API server menuliskan status yang diinginkan ke etcd.
  3. Scheduler melihat adanya Pod yang belum dijadwalkan, memilih node, lalu memperbarui spesifikasi Pod.
  4. kubelet pada node yang dipilih mendeteksi Pod yang telah ditugaskan, lalu menginstruksikan container runtime untuk melakukan pull image dan menjalankan container.
  5. kube-proxy Memperbarui aturan networking agar Service dapat menemukan dan mengarahkan traffic ke Pod tersebut.

Q5. Apa itu etcd dan mengapa komponen ini sangat penting?


Jawaban singkat:

etcd adalah penyimpanan key-value terdistribusi yang konsisten dan menyimpan seluruh status dari cluster Kubernetes, seperti status setiap objek, status yang diinginkan, serta status saat ini.

Pembahasan lebih dalam:

  • Menggunakan algoritma Raft consensus → membutuhkan jumlah anggota ganjil (3, 5, 7) untuk mencapai High Availability (HA).
  • Jika etcd mengalami kegagalan dan tidak memiliki backup, kita akan kehilangan seluruh state cluster yang tersimpan di etcd (meskipun Pod yang sudah berjalan akan tetap berjalan pada node).
  • Backup wajib dilakukan — gunakan etcdctl snapshot save.

Perintah backup:

ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Tujuan interviewer: Merupakan topik hangat dalam ujian CKA. Mereka ingin mendengar kata kunci “Raft”, “jumlah ganjil”, “backup”, dan “encryption at rest”.

Q6. Apa yang sebenarnya dilakukan kube-scheduler?


Jawaban singkat:

kube-scheduler memantau Pod yang belum mendapatkan node (spec.nodeName kosong) dan memilih node terbaik untuk Pod tersebut dalam dua tahap: filtering and scoring.

Tahapan:

  1. Filtering (predicate): Mengeliminasi node yang tidak dapat menjalankan Pod, misalnya karena kekurangan CPU/memory, adanya taint yang tidak dapat ditoleransi Pod, arsitektur yang salah, gagal nodeAffinity, dll.
  2. Scoring (priorities): Memberikan skor pada node yang tersisa dan menyebarkan ke seluruh zona, memprioritaskan node yang beban kerjanya lebih rendah, mempertimbangkan podAffinity/anti-affinity, ketersediaan image (apakah image sudah ada di node tersebut?).

Node dengan skor tertinggi akan dipilih. Scheduler kemudian menuliskan spec.nodeName kembali melalui API server. Selanjutnya kubelet pada node tersebut akan mengambil alih..

Hal yang mempengaruhi keputusan scheduler:

  • nodeSelector — persyaratan mutlak
  • nodeAffinity — preferensi fleksibel atau mutlak
  • podAffinity / podAntiAffinity — penempatkan Pod berdekatan atau berjauhan relatif terhadap Pod lain
  • taints (pada node) + tolerations (pada Pods) — mencegah Pod ditempatkan di node tertentu
  • topologySpreadConstraints — menyebarkan beban secara merata di seluruh zona/node
  • priorityClassName — memungkinkan Pod penting menyela (preempt) Pod lainnya

Q7. Apa peran kubelet pada sebuah node?


Jawaban singkat:

kubelet adalah sebuah agen pada node yang menerima PodSpec dari API server dan memastikan container yang didefinisikan benar-benar berjalan dan dalam kondisi sehat pada node tersebut.

Tanggung jawab kubelet:

  • Pulls images melalui container runtime (CRI).
  • Menjalankan/menghentikan container.
  • Menjalankan pemeriksaan (liveness, readiness, startup).
  • Melaporkan status node dan Pod kembali ke API server.
  • Mengelola proses mounting volume.

Jika kubelet pada sebuah node tidak berjalan atau mati, setelah melewati grace period, status node akan berubah menjadi NotReady, dan controller akan menjadwalkan ulang Pod dari node tersebut ke node lain.

Q8. Apa itu kube-proxy dan bagaimana komponen ini mengimplementasikan Service?


Jawaban singkat:

kube-proxy berjalan di setiap node dan mengonfigurasi kernel Linux (melalui iptables atau IPVS) sehingga lalu lintas ke IP virtual Service diteruskan ke salah satu Pod di belakangnya.

Mode:

  • iptables mode (default): Membuat aturan iptables. Traffic akan diarahkan secara acak ke salah satu endpoint. Metode ini sederhana dan dapat menangani hingga beberapa ribu Service.
  • IPVS mode: Menggunakan Linux IPVS (in-kernel L4 load balancer). Dapat menangani hingga puluhan ribu Service dan mendukung berbagai algoritma load balancing seperti round-robin, least-connection, dan lainnya. Direkomendasikan untuk cluster berskala besar.
  • eBPF-based (Cilium menggantikan kube-proxy): Lebih cepat dan jauh lebih fleksibel.

Ketika sebuah Service dibuat, setiap kube-proxy di dalam cluster akan mendeteksi perubahan tersebut dan memperbarui aturan networking pada node masing-masing. Inilah yang memungkinkan setiap Pod mengakses Service melalui ClusterIP dari mana saja di dalam cluster.

Q9. Apa itu Namespace? Kapan kita perlu membuatnya?


Jawaban singkat:

Namespace adalah partisi logis di dalam cluster yang digunakan untuk mengelompokkan resource dan menerapkan isolasi pada setiap kelompok, seperti RBAC, resource quota, dan network policy.

Namespace bawaan (default):

  • default — tempat object dibuat jika Anda tidak menentukan namespace
  • kube-system — digunakan untuk komponen sistem Kubernetes
  • kube-public — digunakan untuk data yang dapat diakses secara publik di dalam cluster
  • kube-node-lease — – digunakan untuk menyimpan informasi heartbeat node melalui mekanisme lease

Namespace dibuat ketika ingin:

  • Memisahkan environments (dev/staging/prod) di dalam satu cluster, meskipun untuk environment production, banyak yang lebih memilih menggunakan cluster terpisah.
  • Memisahkan tim yang menggunakan cluster yang sama.
  • Menerapkan ResourceQuota atau NetworkPolicy yang berbeda untuk setiap kelompok.

Namespaced vs cluster-scoped:

  • Namespaced: Pods, Services, deployment, ConfigMaps, Secrets, PVCs…
  • cluster-scoped: node, PersistentVolumes, StorageClasses, ClusterRoles, Namespaces themselves.

Q10. Apa itu declarative model dan reconciliation loop?


Jawaban singkat:

Kita mendefinisikan apa yang diinginkan (desired state) dalam YAML. Kubernetes controllers secara terus-menerus membandingkan desired state dengan current state and melakukan tindakan untuk menyelaraskan perbedaannya. Inilah filosofi utama desain Kubernetes.

Contoh: Anda mendefinisikan replicas: 3. Kemudian, sebuah node mengalami kegagalan (mati) sehingga satu Pod hilang. ReplicaSet controller mendeteksi bahwa current state (2) ≠ desired state (3), lalu secara otomatis membuat Pod baru. Tidak diperlukan tindakan manual.
Inilah alasan Kubernetes disebut sebagai sistem self-healing, dimana setiap controller menjalankan loop secara terus-menerus dengan proses “observe → diff → act” atau “mengamati → membandingkan → melakukan tindakan“.

Q11. Command Imperative vs Declarative — mana yang sebaiknya digunakan?


Jawaban singkat:

Gunakan Declarative (file YAML yang disimpan di Git + kubectl apply -f) untuk lingkungan production. Gunakan Imperative (kubectl run, kubectl create) untuk uji coba cepat atau kecepatan saat ujian CKA.

Pendekatan   Contoh                             Kapan digunakan
Imperatif    kubectl run nginx --image=nginx    Uji cepat, belajar, ujian CKA
Deklaratif   kubectl apply -f deployment.yaml   Produksi, GitOps

Tips CKA: Gunakan perintah imperatif dengan opsi --dry-run=client -o yaml untuk membuat kerangka file YAML dengan cepat:

kubectl create deployment web --image=nginx --replicas=3 --dry-run=client -o yaml > web.yaml

Q12. Apa itu label, selector, dan annotation?


Jawaban singkat:

  • Labels: pasangan key/value yang digunakan untuk mengidentifikasi dan mengelompokkan objek. Selector menggunakannya label tersebut untuk memilih object yang sesuai.
  • Selectors: query berdasarkan label (app=web,tier=frontend).
  • Annotations: metadata key/value untuk tools/manusia. Tidak digunakan untuk seleksi objek.

Contoh:

metadata:
  labels:
    app: payments
    tier: backend
    env: prod
  annotations:
    deploy.company.com/owner: "team-payments"
    prometheus.io/scrape: "true"

Service menggunakan selector untuk menemukan Pod yang sesuai:

spec:
  selector:
    app: payments
    tier: backend

Hal penting yang sering terlewat: Jika selector pada Service tidak cocok dengan label pada Pod, Service tersebut tidak akan memiliki endpoint, sehingga traffic tidak dapat diteruskan ke Pod mana pun. Ini adalah hal pertama yang perlu diperiksa ketika menghadapi kasus “Service tidak berfungsi“.

Workloads & Controllers

Networking & Services

Storage & Configuration

Scaling & Autoscaling

Sebuah program edukasi yang disusun oleh Solusi247 untuk membangun talenta data Indonesia

Contact Us

Segitiga Emas Business Park
Jl. Prof. Dr. Satrio KAV 6, Setia Budi
Jakarta Selatan
P: +62 21 579 511 32
M: info@datalearns247.com