Konteks dan instruksi
Sebuah tim platform ingin mengubah CPU dan memori tanpa membuat ulang Pod. Rancang alur in-place resize, jelaskan kapan kontainer harus di-restart, cara menangani kapasitas yang tidak mencukupi, serta cara mengobservasi dan melakukan rollback.
Kubernetes 1.33 meluluskan in-place resize kontainer ke tahap Beta; resize sumber daya tingkat Pod berada di tahap Beta pada 1.36. Pod yang sedang berjalan dapat menerima sumber daya CPU dan memori baru, sementara kubelet menggunakan resizePolicy, kapasitas node, dan status cgroup untuk menerapkan atau menunda perubahan tersebut. “Mengubah spec” bukan berarti “tidak pernah me-restart”.
Hal yang diuji oleh pewawancara
Mencakup batas tingkat Pod versus sumber daya kontainer, semantik CPU dan memori dari resizePolicy, kondisi Pending dan InProgress, permintaan yang tidak layak (infeasible) dan ditunda (deferred), tanggung jawab scheduler versus kubelet, QoS dan prioritas, serta batasan canary dan rollback.
Kerangka jawaban 30 detik
“Saya akan menjadikan resize sebagai permintaan deklaratif ditambah state machine. Sebuah controller memperbarui spec sumber daya, kubelet memeriksa kelayakan, dan melaporkan PodResizePending atau PodResizeInProgress; CPU sering kali diterapkan tanpa restart, sedangkan perilaku restart memori mengikuti resizePolicy masing-masing kontainer. Permintaan yang tidak layak mempertahankan alasannya dan mencoba ulang dalam batas tertentu. Platform mengamati observedGeneration, cgroup aktual, restart, dan perubahan QoS, menggunakan canary kecil dan patch pembalik untuk rollback.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan model sumber daya
Sumber daya kontainer menetapkan requests dan limits untuk setiap kontainer; versi yang didukung juga mengekspos batas agregat tingkat Pod. Limit Pod membatasi penggunaan agregat, tetapi limit kontainer tidak boleh melebihinya. API harus menyatakan apakah ia mengedit spec.containers[*].resources atau spec.resources.
Langkah 2: Bangun alur resize deklaratif
Platform menerima target dan alasan, menulis field sumber daya, dan menyimpan nilai lama, pelaku (actor), serta generation. API tidak pernah mengedit cgroup node secara langsung. Kubelet mengamati generation baru, memeriksa dan menerapkannya, lalu menulis status.
Langkah 3: Tangani restart policy
Sebuah kontainer dapat memilih kebijakan per sumber daya:
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainerNotRequired mencoba pembaruan secara online; RestartContainer mengizinkan restart untuk menerapkan nilai baru. Untuk Pod dengan restartPolicy: Never, setiap sumber daya kontainer harus menggunakan NotRequired, jika tidak maka permintaan menjadi tidak valid.
Langkah 4: Modelkan kelayakan dan status penundaan
Ketika node tidak dapat menyediakan target, kubelet melaporkan PodResizePending dengan alasan seperti Infeasible atau Deferred; permintaan yang diproses dapat masuk ke PodResizeInProgress. Controller harus membaca status alih-alih hanya API spec, dan menggunakan observedGeneration untuk mengaitkan status dengan generation yang diminta.
Langkah 5: Perlakukan CPU dan memori secara berbeda
CPU biasanya dapat memperbarui kuota cgroup tanpa me-restart aplikasi. Pengecilan memori dapat dibatasi oleh working set saat ini, dan beberapa runtime memerlukan restart untuk menerapkannya secara aman. Jangan menyimpulkan perilaku memori dari CPU; baca kebijakan per sumber daya dan pancarkan event yang eksplisit.
Langkah 6: Koordinasikan penjadwalan dan QoS
Pembaruan in-place bukanlah penjadwalan ulang (reschedule). Meningkatkan request mungkin memerlukan kapasitas node, sehingga permintaan yang ditunda harus mencoba lagi berdasarkan PriorityClass, kelas QoS, dan waktu tunggu. Hitung ulang kuota, QoS, dan pemberitahuan setelah pembaruan agar namespace atau beban kerja Guaranteed tidak kekurangan alokasi secara diam-diam.
Langkah 7: Observasi nilai efektif
Kumpulkan spec yang diinginkan, status conditions, observedGeneration, cgroup kontainer aktual, restart, OOM, CPU throttling, dan working set memori. Jika status menyatakan selesai tetapi cgroup tidak berubah, anggap itu sebagai kegagalan dan blokir patch lain alih-alih menumpuk perubahan.
Langkah 8: Canary, pembatasan laju (rate-limit), dan rollback
Lakukan resize secara bertahap berdasarkan beban kerja dan node pool, batasi operasi yang bersamaan, serta tetapkan batas waktu Pending dan batas percobaan ulang. Jika terjadi kegagalan, pulihkan sumber daya yang disimpan; jika kebijakan memori me-restart kontainer, kuras (drain) lalu lintas dan verifikasi kesiapan (readiness) sebelum memperluas skala. Setiap permintaan memerlukan kunci idempotensi untuk mencegah percobaan ulang controller menduplikasi pekerjaan.
Trade-off dan batasan
Kontinuitas tanpa restart versus kepastian sumber daya
Perubahan in-place mengurangi gangguan, tetapi kapasitas dan status yang ditunda membuat penyelesaian bersifat asinkron. Gunakan langkah-langkah kecil untuk layanan yang sensitif terhadap latensi; batch job dapat menerima restart demi hasil yang deterministik.
Batas Pod versus presisi kontainer
Sumber daya Pod menyatakan batas atas bersama, sementara sumber daya kontainer melindungi kontainer kritis. Jika keduanya ada, validasi bahwa limit kontainer tetap berada dalam batas Pod dan tampilkan batasan efektif di UI serta catatan audit.
Percobaan ulang otomatis versus persetujuan
Kekurangan kapasitas sementara layak mendapatkan percobaan ulang yang dibatasi. Restart memori, perubahan QoS, atau lonjakan produksi mungkin memerlukan persetujuan atau maintenance window; percobaan ulang tanpa batas tidaklah aman.
Latihan kegagalan dan rencana evolusi
Node kekurangan kapasitas
Kirim ekspansi di atas kapasitas node, konfirmasikan Infeasible atau Deferred, dan verifikasi bahwa percobaan ulang tidak mengubah nilai efektif yang lama.
Perubahan memori me-restart kontainer
Tetapkan RestartContainer untuk memori dan amati pengurasan lalu lintas, restart, pemulihan kesiapan, serta urutan event. Pastikan controller tidak melaporkan restart sebagai kegagalan bisnis.
Perlombaan generation (race conditions)
Kirim dua target secara cepat. Generation lama tidak boleh menimpa target baru, dan observedGeneration akhir harus cocok dengan nilai cgroup.
Kesalahan umum dan tindak lanjut
Kesalahan 1: Mengasumsikan in-place resize tidak pernah me-restart
Tindak lanjut: Apa yang menyebabkan restart? resizePolicy milik kontainer dapat mewajibkannya, terutama untuk memori; resize tingkat Pod tidak memiliki restart policy terpisah, tetapi kebijakan kontainer tetap berlaku.
Kesalahan 2: Menganggap pembaruan spec sebagai tanda selesai
Tindak lanjut: Bagaimana Anda mengonfirmasi keberhasilan? Periksa conditions, observedGeneration, cgroup, event kontainer, dan jumlah restart alih-alih hanya memeriksa field yang diinginkan.
Kesalahan 3: Melakukan patch berulang kali saat kapasitas tidak mencukupi
Tindak lanjut: Apa yang benar? Pertahankan alasan Pending, coba lagi dalam batas prioritas dan waktu, dan tawarkan migrasi, target yang lebih kecil, atau persetujuan.
Tindak lanjut lanjutan dan contoh jawaban
Mengapa merancang CPU dan memori secara terpisah?
Kuota CPU biasanya dapat diubah secara online; pengecilan memori dibatasi oleh working set dan perilaku runtime serta mungkin memerlukan restart. API bersama tetap memerlukan kebijakan dan status per sumber daya.
Bagaimana cara mencegah resize duplikat menimpa target yang lebih baru?
Gunakan resource version atau generation untuk pembaruan bersyarat, terima hanya target terbaru, dan rekonsiliasi status serta cgroup melalui observedGeneration.
Kapan sebaiknya Anda menghindari in-place resize?
Gunakan penggantian bergulir (rolling replacement) ketika isolasi yang kuat diperlukan, kapasitas tidak stabil, aplikasi tidak dapat mentoleransi restart, atau perubahan sumber daya melanggar asumsi runtime. Pertahankan in-place resize sebagai optimasi yang terkontrol.