Wawancara Backend: apa yang dapat dilindungi oleh PodDisruptionBudget, dan apa yang tidak dapat dilindunginya?

Konteks dan arahan

Anda mengoperasikan layanan yang dikelola oleh Deployment dengan jumlah replika yang diinginkan (desired replica count) sebanyak lima. Selama peningkatan versi (upgrade) kluster, sebuah node harus di-drain dan tim khawatir akan kehilangan beberapa replika sekaligus. Pewawancara meminta Anda untuk merancang atau meninjau PodDisruptionBudget dan menjelaskan pengaruhnya terhadap rolling release, kegagalan node, serta penghapusan Pod secara langsung.

Hal ini menguji batas ketersediaan (availability boundaries) dan penalaran operasional Kubernetes. PDB membatasi berapa banyak replika terpilih yang boleh tidak tersedia secara bersamaan karena gangguan sukarela (voluntary disruptions). PDB bukanlah replica controller dan bukan jaminan terhadap setiap kegagalan. Jawaban yang baik menghubungkan desired replicas, selector, entry point penggusuran (eviction), dan sisa kapasitas.

Hal yang dievaluasi oleh pewawancara

• Apakah Anda membedakan gangguan sukarela (voluntary) dari gangguan tidak sukarela (involuntary).
• Apakah Anda menjelaskan semantik yang saling eksklusif (mutually exclusive) dari minAvailable dan maxUnavailable.
• Apakah Anda mengetahui bahwa PDB bergantung pada jumlah replika yang diinginkan oleh controller dan Pod selector yang tepat.
• Apakah Anda dapat menjelaskan percobaan ulang (retry) pada drain, jalur penghapusan yang tidak tercakup, dan batasan rolling-update.
• Apakah Anda menambahkan replika, topologi, probe, dan kapasitas ke dalam rencana ketersediaan.

Pertanyaan untuk diklarifikasi terlebih dahulu

• Apakah layanan dikelola oleh Deployment, StatefulSet, atau controller lain yang didukung?
• Apakah selector hanya cocok dengan beban kerja (workload) ini? Selector yang luas dapat mencampurkan Pod yang tidak terkait ke dalam satu budget.
• Apakah Anda melindungi dari node drain dan penurunan skala (scale-down), atau pemadaman listrik? PDB tidak dapat mencegah pemadaman listrik.
• Apakah replika tersebar di seluruh zona dengan kapasitas yang cukup dan readiness yang benar? PDB membatasi penggusuran; PDB tidak menciptakan kapasitas.
• Berapa lama pemeliharaan (maintenance) dapat menunggu? Budget yang terlalu ketat dapat memperpanjang jendela pemeliharaan, sedangkan budget yang longgar mengurangi kapasitas.

Kerangka jawaban 30 detik

“PDB membatasi permintaan gangguan sukarela yang dilakukan melalui Eviction API. Dengan lima replika, minAvailable: 4 atau maxUnavailable: 1 dapat menyatakan bahwa paling banyak satu replika yang boleh hilang pada satu waktu, tetapi kedua kolom tersebut saling eksklusif. Budget bergantung pada replika yang diinginkan dari beban kerja dan selector yang tepat; kegagalan node, penghapusan Deployment secara langsung, dan rolling update aplikasi tidak sepenuhnya dihentikan oleh PDB. Jika drain ditolak, saya akan memeriksa budget, replika sehat, kapasitas, dan jalur penggusuran, sambil menggunakan replika, topologi, dan probe untuk sisa desain ketersediaan.”

Jawaban mendalam

Mengklasifikasikan gangguan

Node drain, pemeliharaan node, dan beberapa tindakan penurunan skala kluster biasanya meminta pemindahan Pod melalui Eviction API. Tindakan tersebut merupakan gangguan sukarela (voluntary disruptions), sehingga PDB dapat menolak penggusuran untuk sementara waktu. Pemadaman listrik, kegagalan kernel, atau isolasi jaringan adalah gangguan tidak sukarela (involuntary disruptions); PDB tidak dapat mencegahnya, dan Pod tidak tersedia yang dihasilkan tetap memengaruhi status budget.

Menjelaskan kolom yang saling eksklusif

minAvailable menyatakan berapa banyak Pod yang cocok harus tetap tersedia setelah penggusuran. maxUnavailable menyatakan berapa banyak Pod yang cocok yang boleh tidak tersedia setelah penggusuran. Keduanya tidak dapat disetel secara bersamaan. Untuk lima replika yang diinginkan, minAvailable: 4 dan maxUnavailable: 1 menyatakan maksud serupa pada ukuran tersebut, tetapi persentase berubah seiring skala dan pembulatan, jadi sebutkan jumlah yang diinginkan dan semantik versinya.

Menunjukkan ketergantungan pada replika yang diinginkan dan selector

Control plane menemukan beban kerja pengelola melalui Pod owner references dan mendapatkan jumlah yang diinginkan dari .spec.replicas. Selector harus cocok dengan label Deployment atau StatefulSet dan tetap spesifik. Selector yang cocok dengan banyak aplikasi menciptakan budget bersama; tanpa sumber daya pemilik yang didukung, Kubernetes tidak dapat memperoleh total replika secara andal.

Menggunakan konfigurasi untuk menunjukkan batasan

Contoh ini memungkinkan paling banyak satu Pod terpilih menjadi tidak tersedia akibat penggusuran sukarela ketika beban kerja menginginkan lima replika:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-api
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: checkout-api

Ini tidak menjamin empat Pod sehat setiap saat. Sebuah replika mungkin sudah tidak sehat sebelumnya, atau sebuah node bisa gagal mendadak. Sebelum rollout, verifikasi selector, readiness, replika yang diinginkan, dan kapasitas multi-zona.

Menjelaskan penolakan dan percobaan ulang drain

Ketika penggusuran tidak diizinkan untuk saat ini, jumlah replika sehat sudah di bawah minAvailable, atau budget controller tidak dapat menghitung status, Eviction API dapat menolak permintaan tersebut. kubectl drain secara berkala mencoba kembali permintaan yang gagal sampai Pod dihentikan atau batas waktu (timeout) tercapai. Pemecahan masalah dimulai dari status PDB, Pod yang dipilih, jumlah sehat, kegagalan readiness, dan konfirmasi bahwa tindakan pemeliharaan benar-benar menggunakan Eviction API.

Memisahkan rolling update dan penghapusan langsung

Rolling update pada Deployment dan StatefulSet diatur oleh strategi pembaruannya sendiri; PDB bukanlah pengganti lengkap untuk aturan-aturan tersebut. PDB juga tidak dapat membatasi setiap penghapusan langsung terhadap Pod atau Deployment. Sistem rilis harus menggabungkan maxUnavailable, maxSurge, readiness, dan perilaku rollback alih-alih menyerahkan semua keamanan rilis kepada PDB.

Menambahkan keandalan di luar PDB

PDB mencakup satu kelas gangguan. Menahan kegagalan node atau zona juga memerlukan replika yang cukup, penyebaran topologi (topology spread), ruang kapasitas ekstra (headroom), readiness dan liveness yang benar, graceful termination, dan pengosongan koneksi (connection draining). Untuk layanan stateful berbasis kuorum, tentukan budget dari kebutuhan kuorum; untuk layanan stateless, validasi ketersediaan dengan lalu lintas nyata, waktu pemulihan, dan pengujian kapasitas.

Model jawaban berkualitas tinggi

“Deployment menginginkan lima replika, jadi pertama-tama saya akan memverifikasi bahwa selector PDB hanya cocok dengan checkout-api serta readiness dan kapasitas lintas zona dalam kondisi baik. Jika penggusuran sukarela harus menyisakan empat replika yang tersedia, saya dapat menggunakan minAvailable: 4 atau maxUnavailable: 1; keduanya saling eksklusif, dan saya akan memilih nilai absolut atau persentase berdasarkan perilaku penskalaan.

PDB melindungi proses node drain, pemeliharaan, dan beberapa tindakan scale-down yang menggunakan Eviction API. PDB tidak dapat menghentikan pemadaman listrik, kegagalan kernel, atau penghapusan Pod secara langsung, dan rolling update terutama dikendalikan oleh strategi Deployment. Jika drain ditolak, saya akan memeriksa replika sehat, status budget, selector, kegagalan readiness, kapasitas, dan jalur penggusuran; kubectl drain dapat mencoba kembali hingga timeout.

Saya akan memvalidasi PDB bersama dengan jumlah replika, penyebaran topologi, readiness, graceful termination, dan rollback rilis. Budget yang terlalu ketat dapat memblokir pemeliharaan, sedangkan budget yang terlalu longgar dapat melanggar kapasitas minimum, sehingga ambang batas harus ditentukan dari simulasi lalu lintas dan kegagalan daripada persentase universal.”

Kesalahan umum

• Mengklaim PDB mencegah kegagalan node: gangguan sukarela dan tidak sukarela tertukar → batasi klaim pada jalur Eviction API.
• Menyetel minAvailable dan maxUnavailable secara bersamaan: kolom tersebut saling eksklusif → pilih salah satu ekspresi budget.
• Hanya menghitung Pod saat ini: budget menggunakan replika yang diinginkan → periksa owner references dan .spec.replicas.
• Memilih seluruh namespace: aplikasi yang tidak terkait berbagi satu budget → gunakan selector beban kerja yang spesifik.
• Mengatakan PDB melindungi rolling update dan penghapusan langsung: controller dan jalur penghapusan memiliki semantik terpisah → periksa setiap kebijakan dan jalur izin.
• Menghapus PDB saat drain terblokir: risiko kekurangan kapasitas dapat meningkat → periksa replika sehat, probe, status budget, dan kapasitas terlebih dahulu.
• Mengonfigurasi PDB tanpa topologi atau kapasitas: Pod yang bertahan dapat berada di domain kegagalan yang sama → kombinasikan zona, headroom, dan simulasi pengujian.
• Memperlakukan persentase sebagai jumlah replika tetap: penskalaan mengubah maknanya → sebutkan skala yang diinginkan, pembulatan, dan perilaku autoscaling.

Pertanyaan lanjutan dan jawaban

Pertanyaan lanjutan 1: Apa arti minAvailable: 80% untuk lima replika?

Ini memerlukan jumlah ketersediaan yang dihasilkan oleh aturan persentase dan pembulatan Kubernetes. Jangan berasumsi bahwa hasilnya selalu tepat empat; verifikasi semantik API saat ini dan amati perilaku setelah penskalaan.

Pertanyaan lanjutan 2: Mengapa drain masih dapat membuat layanan tidak tersedia?

PDB hanya membatasi penggusuran sukarela yang diterima; PDB tidak dapat memperbaiki Pod yang sudah tidak sehat, membuat kapasitas baru, membatalkan konsentrasi pada satu zona, atau membuat aplikasi mampu mentolerir pemindahan koneksi. Readiness, topologi, kapasitas, dan graceful termination harus divalidasi bersama.

Pertanyaan lanjutan 3: Apakah kubectl delete pod diblokir oleh PDB?

Jangan berasumsi demikian. Dokumentasi Kubernetes menyatakan bahwa menghapus Pod atau Deployment secara langsung dapat melewati perlindungan PDB, sehingga izin akses, audit, dan proses rilis harus membatasi jalur tersebut.

Pertanyaan lanjutan 4: PDB menunjukkan nol gangguan yang diizinkan (allowed disruptions). Haruskah Anda melonggarkannya terlebih dahulu?

Periksa terlebih dahulu selector, replika yang diinginkan, replika sehat, kegagalan readiness, dan status controller. Melonggarkan budget secara membabi buta dapat menyembunyikan masalah kesehatan. Jika pemeliharaan benar-benar membutuhkan perubahan sementara, evaluasi kapasitas dan rollback, catat waktu jendelanya, dan pulihkan kembali kebijakannya.

Pertanyaan lanjutan 5: Apa perbedaan antara layanan stateful dan stateless?

Layanan stateful harus mempertahankan kuorum atau jumlah replika minimum dari protokol konsistensi serta memvalidasi penyeimbangan ulang (rebalancing) dan pemulihan. Layanan stateless biasanya berfokus pada sisa kapasitas, latensi, dan pembersihan koneksi (connection draining). Tidak ada klaim ketersediaan yang hanya bergantung pada jumlah replika semata.

Pertanyaan lanjutan 6: Bagaimana Anda memverifikasi bahwa PDB efektif?

Dalam jendela waktu yang terkendali, uji coba Eviction API dan proses node drain, lalu amati penolakan, percobaan ulang, jeda terminasi (termination grace), lalu lintas, kesalahan, dan waktu pemulihan. Uji juga kegagalan node dan jalur penghapusan langsung agar tim tidak salah mengira batasan PDB sebagai jaminan terhadap semua jenis kegagalan.