Wawancara Desain Sistem: Bagaimana Anda Mendesain Controller Pengubah Ukuran Tingkat Pod di Kubernetes?

Petunjuk dan konteks

Sebuah Pod multi-kontainer memiliki API proxy, cache sidecar, dan batch worker. Tim ingin menyesuaikan anggaran CPU dan memori tingkat Pod dari latensi dan panjang antrean tanpa menghapus Pod tersebut. Desain controller tersebut, termasuk observasi, keputusan, penulisan /resize, pelacakan status, perlindungan konkurensi, permintaan yang tidak layak, dan rollback.

Hal yang diuji oleh pewawancara

Apakah Anda membedakan sumber daya yang diinginkan (desired resources), sumber daya aktual (actual resources), dan kebijakan restart kontainer.
Apakah Anda mendesain rekonsiliasi yang idempoten, status condition, serta percobaan ulang untuk kondisi deferred/infeasible.
Apakah anggaran Pod dan permintaan kontainer memiliki batasan eksplisit dan batas pengaman (safety rails).
Apakah metrik, izin, pemulihan, dan peluncuran progresif merupakan bagian dari desain.

Pertanyaan untuk klarifikasi

Apakah kluster mendukung pengubahan ukuran tingkat Pod, dan feature gates serta versi kubectl apa yang terpasang?
Apakah controller mengubah CPU, memori, atau kedua sumber daya Pod dan kontainer?
Kontainer mana yang boleh di-restart, dan mana yang memiliki koneksi atau state yang tidak boleh terputus?
Apakah tujuannya adalah pengurangan biaya, pemenuhan SLO, atau menyerap lonjakan antrean?

Jawaban 30 detik

Saya akan membangun rekonsiliator idempoten berbasis peristiwa (event-driven): membaca metrik dan status Pod, menghitung target dalam batas anggaran, SLO, kapasitas node, dan masa jeda (cooldown), lalu mengirimkan perubahan kecil melalui subresource /resize. Status mencatat observedGeneration, PodResizePending, PodResizeInProgress, serta alasan Infeasible atau Deferred; percobaan ulang menggunakan backoff, prioritas, dan jumlah batas maksimum. CPU dan memori dievaluasi secara terpisah, resizePolicy kontainer dipatuhi, dan anggaran terverifikasi terakhir dipulihkan jika terjadi risiko memori atau penurunan SLO. Setiap penulisan memiliki pemilik, jejak audit, dan batasan RBAC.

Pembahasan mendalam langkah demi langkah

Tentukan model sumber daya dan batas keamanan

spec.resources tingkat Pod adalah anggaran agregat; requests dan limits kontainer tetap memengaruhi jaminan serta perilaku restart. Pertahankan guardrail per-workload untuk minimum, maksimum, langkah (step), jeda (cooldown), dan SLO, serta tolak permintaan yang melebihi kuota namespace atau kapasitas node.

Kumpulkan metrik dan hitung target

Gunakan latensi, panjang antrean, CPU throttling, working set, dan peristiwa OOM. Terapkan rentang waktu (windows) dan histeresis untuk menghindari reaksi terhadap lonjakan tunggal; target harus memenuhi batasan anggaran Pod dan total permintaan kontainer.

Kirim pembaruan resize-subresource yang idempoten

Controller memperbarui desired state dengan resource version dan pemilik. Contoh permintaan:

yaml

spec:
  resources:
    requests:
      cpu: "300m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

Panggil subresource /resize dan periksa resourceVersion. Jika terjadi konflik, baca ulang dan rekonsiliasi kembali alih-alih menimpa pengguna atau controller lain.

Lacak condition dan prioritas percobaan ulang

Baca condition seperti PodResizePending dan PodResizeInProgress serta observedGeneration. Infeasible berarti batasan saat ini tidak dapat memenuhi permintaan; Deferred berarti permintaan ditunda. Simpan alasan, waktu percobaan berikutnya, dan hitungan percobaan. Jadwalkan percobaan ulang berdasarkan prioritas workload, QoS, dan waktu tunggu agar tugas berprioritas rendah tidak mengalami starving selamanya.

Tangani kebijakan restart kontainer

Perubahan tingkat Pod dapat memicu resizePolicy tingkat kontainer. CPU dapat diterapkan tanpa restart sementara memori mungkin memerlukannya; periksa kebijakan, koneksi, dan state setiap kontainer. Tempatkan permintaan yang tidak boleh di-restart di belakang antrean pengaman dan jangan pernah melaporkan kelangsungan bisnis hanya dari keberhasilan di tingkat Pod.

Observasi, rollback, dan pertahankan ketersediaan tinggi

Catat nilai target dan aktual, transisi condition, jumlah restart, SLO latensi, puncak memori, dan alasan kegagalan. Jalankan replika controller dengan leader election dan lakukan deduplikasi antrean berdasarkan kunci Pod. Jika anggaran buruk, terjadi OOM, atau terjadi penurunan SLO, pulihkan target stabil terakhir dan jeda otomatisasi untuk ditinjau secara manual.

Contoh jawaban model

Saya akan membangun rekonsiliator idempoten yang membaca metrik latensi, antrean, throttling, working set, dan OOM, kemudian menghitung target dalam batas minimum/maksimum anggaran, langkah, jeda, kapasitas node, dan kuota namespace. Kirim perubahan bertahap berbasis resource-version melalui /resize; baca ulang jika terjadi konflik. Catat observedGeneration, Pending, InProgress, Infeasible, alasan Deferred, dan waktu percobaan ulang, dengan menjadwalkan percobaan ulang berdasarkan prioritas dan waktu tunggu. Periksa kebijakan pengubahan ukuran setiap kontainer sebelum perubahan memori dapat me-restart-nya. Gunakan leader election, metrik, dan log audit; pulihkan anggaran stabil terakhir dan jeda otomatisasi jika terjadi penurunan SLO atau OOM.

Kesalahan umum

Mengedit Pod spec secara langsung dan mengasumsikan kubelet menerapkannya, dengan mengabaikan subresource /resize.
Hanya membaca desired resources dan mengabaikan actual resources serta condition.
Melewatkan masa jeda (cooldown) dan histeresis, yang menyebabkan osilasi dan restart yang sering.
Mengabaikan permintaan Deferred selamanya atau mencoba ulang permintaan Infeasible tanpa batas.
Mengabaikan resizePolicy kontainer dan risiko restart akibat memori.
Tidak menyertakan resourceVersion, pemilik, dan RBAC, sehingga controller dapat saling menimpa data.

Pertanyaan lanjutan

Bagaimana Anda mencegah dua controller saling menimpa data?

Gunakan kepemilikan eksplisit, resourceVersion, field management, dan satu pemilik penulisan; baca ulang dan gabungkan maksud perubahan saat terjadi konflik alih-alih menimpa tanpa syarat.

Bagaimana Anda membedakan Infeasible dari Deferred?

Infeasible berarti batasan saat ini tidak dapat memenuhi target dan memerlukan target atau kapasitas baru; Deferred bersifat sementara dan harus dicoba ulang dengan mempertahankan alasan serta prioritasnya.

Kapan otomatisasi harus dijeda?

Jeda saat terjadi OOM, penurunan SLO yang berkelanjutan, condition yang tidak berubah, restart berlebihan, atau hasil observasi tidak valid, sambil tetap mempertahankan jalur pemulihan manual.

Bagaimana Anda membuktikan bahwa tidak terjadi gangguan?

Korelasikan condition resize, restartCount kontainer, kesalahan koneksi, latensi, dan metrik antrean berdasarkan kebijakan; fase Pod yang tetap Running saja tidak cukup membuktikannya.