Pertanyaan dan konteks
Tim platform menemukan bahwa kontainer batch milik satu penyewa dapat menekan layanan online selama lonjakan beban (peak). Node menggunakan cgroup v2, tetapi tim hanya menetapkan satu batas memori sehingga tidak dapat membedakan antara reklamasi (reclaim), pembatasan bertahap (throttling), dan penghentian (termination). Rancang kebijakan memori berlapis dengan batas proteksi, pemantauan kejadian (events), dan rollback.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda memisahkan proteksi memory.min/low dari reklamasi/throttling memory.high dan penegakan batas memory.max.
- Apakah Anda memahami hierarki memory.events dan memory.events.local yang bersifat lokal.
- Apakah Anda menangani pembunuhan grup OOM (OOM group killing), child cgroup, burst, dan overcommit.
- Apakah Anda dapat menghubungkan file kernel dengan orkestrasi, peringatan (alert), dan simulasi kegagalan.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
- Apakah Anda melindungi beban kerja penting, membatasi penyewa, atau melindungi seluruh node?
- Apakah beban kerja tersebut sensitif terhadap latensi, berorientasi batch, atau aman untuk direklamasi dan dicoba ulang?
- Bagaimana hierarki cgroup-nya, dan apakah grup induk (parent) berisi sidecar?
- Apakah Kubernetes mengelola beban kerja tersebut, dan bagaimana requests serta limits dipetakan ke cgroup v2?
- Haruskah OOM mematikan satu proses, seluruh cgroup, atau meminta controller untuk membangun ulang kontainer?
Kerangka jawaban 30 detik
Gunakan memory.min dan memory.low untuk tingkat proteksi, memory.high sebagai batas awal reklamasi dan throttling, serta memory.max sebagai batas keras akhir. memory.oom.group menentukan apakah penanganan OOM berlaku untuk seluruh grup. Alokasikan anggaran dari node ke penyewa hingga ke beban kerja, pantau memory.current, memory.events, dan PSI, serta validasi dengan canary, uji tekanan (pressure test), dan rollback. Di Kubernetes, baca file cgroup yang sebenarnya setelah perenderan alih-alih hanya mempercayai YAML.
Jawaban mendalam langkah demi langkah
Langkah 1: Bangun model semantik
memory.min adalah batas proteksi keras yang penggunaannya hanya direklamasi di bawah tekanan yang sangat kuat; memory.low adalah proteksi best-effort yang dapat direklamasi di bawah tekanan parah. memory.high memicu reklamasi dan throttling tetapi tidak secara langsung memanggil OOM killer. memory.max adalah batas mutlak yang tidak dapat dilanggar dan dapat memicu cgroup OOM ketika reklamasi tidak dapat memenuhinya.
Langkah 2: Alokasikan anggaran induk dan anak
Cadangkan kapasitas node untuk sistem dan layanan penting, tetapkan batas atas untuk setiap induk penyewa, lalu atur grup anak untuk beban kerja online, batch, dan sidecar. Proteksi anak tidak boleh melebihi anggaran induk yang tersedia secara tanpa syarat. Catat penggunaan saat ini, events, dan versi kebijakan di setiap tingkatan. Sisakan ruang (headroom) di bawah high untuk burst sehingga lonjakan singkat tidak langsung menjadi OOM pada max.
Langkah 3: Tentukan hubungan antara high dan max
memory.high memungkinkan kernel menerapkan reklamasi dan throttling terlebih dahulu; aplikasi dapat melambat setelah mengamati latensi, throughput, dan events. memory.max adalah katup pengaman terakhir dan harus mencerminkan kemampuan pemulihan (recoverability). Nilai high yang terlalu rendah menyebabkan throttling kronis, sedangkan max yang terlalu tinggi melimpahkan tekanan ke induk atau node. Kalibrasikan keduanya dengan uji beban.
Langkah 4: Tentukan kebijakan OOM group
Untuk proses yang terikat erat, memory.oom.group=1 membuat penanganan OOM berlaku untuk seluruh grup sehingga proses pembantu (helper) tidak tertinggal setelah hanya proses utama yang dimatikan. Tugas batch independen mungkin lebih memilih satu proses berhenti dan antrean mencoba memprosesnya kembali. Catat penyebab keluar (exit cause), restart, dan pekerjaan yang belum selesai untuk kedua pilihan tersebut; OOM bukanlah percobaan ulang yang tidak terlihat.
Langkah 5: Pantau memory.events
memory.events bersifat hierarkis, sehingga event anak dapat muncul di induk; memory.events.local hanya melaporkan event lokal. Pantau selisih (delta) untuk high, max, oom, dan oom_kill, yang dikorelasikan dengan memory.current, working set, PSI, latensi, dan usia antrean. Lakukan penguraian (parsing) kunci alih-alih mengandalkan urutan file karena kunci baru bisa saja muncul.
Langkah 6: Petakan kebijakan ke orkestrasi
Di Kubernetes, periksa requests, limits, QoS, dan mode cgroup node secara bersamaan. Setelah perenderan, masuk ke dalam kontainer dan baca /sys/fs/cgroup untuk memverifikasi nilai sebenarnya dan memastikan runtime tidak menimpanya. Periksa penghitungan akuntansi sidecar, init container, dan emptyDir bersama; kontainer anak dapat terlihat sehat padahal induknya telah mencapai high atau max.
Langkah 7: Simulasi, rilis, dan roll back
Pada canary node tunggal, turunkan high secara bertahap dan amati reklamasi serta throttling, lalu uji terminasi max dan oom.group. Berikan peringatan secara terpisah untuk high yang berkelanjutan, max pertama, dan oom_kill yang sebenarnya. Publikasikan kebijakan berversi dengan versi sebelumnya dan snapshot event. Lakukan rollback anggaran terlebih dahulu, kemudian rekonsiliasi tugas yang dimatikan dan percobaan ulang antrean agar tidak ada sisa tekanan pada node.
Contoh jawaban berkualitas tinggi
Gunakan min dan low untuk proteksi, high untuk reklamasi dan throttling yang dapat diamati, serta max sebagai batas keras akhir. Alokasikan anggaran node, penyewa, dan beban kerja melalui hierarki induk-anak, lalu pilih oom.group berdasarkan kemampuan pemulihan. Pantau memory.events hierarkis versus lokal bersama dengan PSI, latensi, usia antrean, dan restart. Di Kubernetes, verifikasi file cgroup yang dirender. Luncurkan dengan canary dan simulasi tekanan, serta simpan kebijakan rollback yang berversi.
Kesalahan umum
- Memperlakukan memory.high sebagai batas OOM langsung.
- Menganggap memory.low sebagai jaminan yang tidak dapat dilanggar.
- Mempercayai YAML kontainer tanpa membaca file cgroup runtime.
- Mencampuradukkan event hierarkis induk dengan event lokal.
- Melakukan restart setelah OOM tanpa memeriksa idempoten, pekerjaan parsial, dan badai percobaan ulang (retry storms).
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Apa yang terjadi setelah memory.high terlampaui?
Kernel menerapkan tekanan reklamasi dan throttling. Proses dapat terus berjalan tetapi latensi dapat meningkat. Ini bukan pemicu OOM-killer; korelasikan penghitung high dengan PSI dan latensi layanan.
Pertanyaan lanjutan 2: Mengapa tetap mempertahankan memory.max jika high sudah ada?
High memungkinkan beban kerja mengalah di bawah tekanan, sedangkan max membatasi pertumbuhan yang tidak dapat direklamasi serta melindungi induk atau node. Max harus dirancang dengan mempertimbangkan kemampuan pemulihan dan kebijakan restart.
Pertanyaan lanjutan 3: Mengapa memory.events dapat terlihat menghitung suatu event dua kali?
memory.events pada induk mencakup event sub-tree secara default, sedangkan memory.events.local bersifat lokal untuk cgroup tersebut. Pilih satu tingkat untuk setiap peringatan dan lakukan deduplikasi berdasarkan hierarki.
Pertanyaan lanjutan 4: Kapan memory.oom.group harus diaktifkan?
Aktifkan ketika proses dalam satu cgroup harus hidup dan dimulai ulang bersama-sama. Tugas independen dapat keluar secara individual. Kedua pilihan tersebut memerlukan pengujian pembersihan, percobaan ulang, dan observabilitas.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa pemetaan Kubernetes sudah benar?
Pada node target, baca memory.min, memory.low, memory.high, memory.max, dan events untuk cgroup kontainer. Bandingkan nilainya dengan requests, limits, QoS, dan pengaturan runtime yang dirender, lalu jalankan simulasi tekanan.