Bagaimana Anda akan merancang resource request tingkat Pod di Kubernetes?

Masalah dan konteks

Sumber daya tingkat Pod di Kubernetes memungkinkan sebuah Pod mendeklarasikan request dan limit untuk CPU, memori, atau hugepages selain dari nilai di tingkat kontainer. Nilai tingkat Pod lebih diutamakan (mengambil preseden) ketika keduanya ada, serta memengaruhi penjadwalan (scheduling), QoS, dan penilaian OOM. Feature gate PodLevelResources dan versi klaster harus diverifikasi sebelum peluncuran.

Asumsikan proxy dan worker berbagi beban kerja yang fluktuatif (bursty), tetapi proxy memiliki SLO latensi dan worker dapat menggunakan kapasitas yang tersisa. Tujuannya adalah untuk mengekspresikan hubungan tersebut tanpa membuat scheduler atau kubelet memaksakan anggaran yang tidak dimaksudkan oleh tim.

Apa yang dievaluasi oleh pewawancara

Pewawancara mencari model kepemilikan sumber daya yang jelas, aturan preseden yang benar, dan kesadaran bahwa request tingkat Pod mengubah penjadwalan dan QoS. Jawaban yang kuat mendiskusikan jaminan agregat versus per-kontainer, limit, autoscaling, observabilitas, dan pengujian migrasi.

Jawaban biasa hanya menyalin jumlah total request kontainer ke dalam spec.resources. Jawaban yang kuat menjelaskan apakah anggaran Pod adalah kumpulan bersama (shared pool), kontainer mana yang membutuhkan batas bawah (floor), dan cara mencegah satu worker menghabiskan batas aman (headroom) latensi milik proxy.

Pertanyaan untuk diklarifikasi terlebih dahulu

Apakah request tingkat Pod merupakan anggaran bersama atau batas minimum yang ketat untuk setiap kontainer?
Versi Kubernetes, feature gate, resource manager, dan sistem operasi apa saja yang masuk dalam cakupan?
Apakah proxy memerlukan jaminan batas bawah CPU atau limit memori yang independen dari worker?
Bagaimana HPA, VPA, dan kebijakan penggusuran (eviction) mengamati cakupan baru ini?
Apa yang terjadi jika request tingkat Pod dan tingkat kontainer ditentukan secara bersamaan selama migrasi?

Jika kontainer memiliki domain penskalaan atau kegagalan yang independen, memisahkannya ke dalam Pod yang berbeda mungkin lebih aman. Jika kontainer-kontainer tersebut benar-benar berbagi siklus hidup dan anggaran burst, sumber daya tingkat Pod dapat mengekspresikan hubungan tersebut secara lebih langsung.

Jawaban 30 detik

“Pertama, saya akan memverifikasi dukungan versi dan feature gate, lalu memodelkan Pod sebagai anggaran bersama dengan batas bawah (floor) proxy yang eksplisit. Request tingkat Pod lebih diutamakan, jadi saya akan menghindari pengaturan campuran yang tidak disengaja, menguji perilaku QoS dan OOM, serta memeriksa input autoscaler. Saya akan melakukan uji canary pada manifes, membandingkan latensi, throttling, eviction, dan biaya dengan kebijakan lama, serta mempertahankan opsi rollback ke request tingkat kontainer.”

Desain langkah demi langkah

Petakan peran sumber daya. Ukur sensitivitas latensi proxy, sifat burstiness worker, penggunaan kondisi stabil (steady-state), dan pertumbuhan memori. Putuskan apakah kontainer berbagi anggaran atau memerlukan jaminan yang terisolasi.
Verifikasi kemampuan. Konfirmasikan versi server Kubernetes, gate PodLevelResources pada control plane dan node, tipe sumber daya yang didukung, serta batasan khusus Linux jika berlaku.
Tetapkan anggaran Pod. Pilih request untuk penjadwalan dan limit untuk batas atas (ceiling) agregat. Pastikan anggaran menyisakan ruang untuk batas bawah latensi proxy dan burst worker.
Hindari preseden yang ambigu. Selama migrasi, dokumentasikan bahwa nilai tingkat Pod menimpa nilai tingkat kontainer. Hapus nilai kontainer yang sudah usang atau pertahankan hanya jika kebijakan memang sengaja membutuhkan kedua cakupan.
Periksa QoS dan eviction. Hitung ulang kelas QoS dan perilaku OOM, lalu uji tekanan node, throttling, dan perebutan sumber daya worker. Agregat yang sehat masih dapat menyembunyikan terjadinya kelaparan sumber daya (starvation) pada proxy.
Luncurkan dan amati. Lakukan canary pada satu workload dan pantau latensi p95, CPU throttling, tekanan memori, OOM kill, eviction, restart, dan biaya. Perluas peluncuran hanya jika batas pengaman (guardrails) tetap terjaga.

Alternatif lainnya mencakup Deployment terpisah, request khusus kontainer saja, atau sidecar dengan limit eksplisit. Sumber daya tingkat Pod paling berguna ketika siklus hidup dan kapasitas burst sengaja dibagi bersama.

Contoh jawaban

“Proxy membutuhkan batas bawah latensi, sementara worker dapat meminjam CPU yang tersisa. Saya akan menetapkan request Pod yang mencerminkan agregat normal dan limit untuk batas atas burst, kemudian memvalidasi bahwa proxy tidak mengalami kelaparan sumber daya di bawah beban kerja worker. Selama migrasi, saya akan menghapus request kontainer yang bertentangan atau mendokumentasikan tujuannya karena nilai tingkat Pod yang akan dimenangkan. Saya akan melakukan canary pada dua node, memantau latensi p95, throttling, OOM, eviction, dan perilaku autoscaler, lalu melakukan rollback ke kebijakan kontainer sebelumnya jika SLO proxy mengalami penurunan.”

Kesalahan umum

Kesalahan: Mengasumsikan request Pod otomatis menjadi jaminan per-kontainer → Mengapa gagal: anggaran mungkin bersifat bersama → Perbaikan: tentukan batas bawah (floor) dan isolasi secara eksplisit.
Kesalahan: Membiarkan nilai kontainer yang bertentangan tanpa dokumentasi → Mengapa gagal: preseden tingkat Pod mengejutkan operator → Perbaikan: dokumentasikan dan uji sumber daya yang efektif.
Kesalahan: Hanya memeriksa utilisasi CPU → Mengapa gagal: tekanan memori dan perilaku OOM dapat berubah → Perbaikan: amati CPU, memori, QoS, eviction, dan latensi secara bersamaan.
Kesalahan: Mengaktifkan fitur hanya pada satu komponen control-plane → Mengapa gagal: semua node dan komponen yang diperlukan harus mendukungnya → Perbaikan: verifikasi kemampuan di seluruh klaster sebelum peluncuran.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika proxy mengalami kelaparan sumber daya meskipun Pod berada di bawah limitnya?

Perlakukan hal tersebut sebagai kegagalan perebutan sumber daya (contention). Tambahkan batas bawah proxy, pisahkan workload, atau gunakan isolasi tingkat kontainer; ruang bebas (headroom) agregat saja tidak menjamin latensi.

Bagaimana request tingkat Pod memengaruhi QoS?

Request tingkat Pod lebih diutamakan ketika kedua cakupan ada dan memengaruhi perhitungan QoS serta OOM pada Pod. Hitung ulang kelas QoS selama migrasi dan uji tekanan node.

Bisakah Windows Pod menggunakan sumber daya tingkat Pod?

Periksa batasan spesifik versi. Perilaku Kubernetes 1.35 yang terdokumentasi tidak mendukung sumber daya tingkat Pod untuk Windows Pod, jadi pertahankan kebijakan tingkat kontainer di lingkungan tersebut.

Kapan Anda akan memilih untuk memisahkan Pod?

Pisahkan ketika kontainer memiliki penskalaan, kegagalan, atau SLO yang independen. Pertahankan satu Pod jika siklus hidup bersama dan anggaran burst memang disengaja serta dapat diamati.