Wawancara Umum: Bagaimana Anda Mengatur Tata Kelola Penyesuaian Ukuran Tingkat Pod di Kubernetes?

Perintah dan konteks

Tim platform sedang mengaktifkan penyesuaian ukuran CPU dan memori tingkat Pod di Kubernetes. Tim produk menginginkan penyetelan otomatis, bagian keuangan mengkhawatirkan biaya, dan SRE khawatir bahwa perubahan memori dapat me-restart kontainer. Buat kebijakan admisi, audit, respons insiden, dan rollback lintas tim.

Apa yang diuji oleh pewawancara

Apakah kemampuan teknis diubah menjadi batas kepemilikan, izin, dan anggaran yang jelas.
Apakah tingkatan risiko menentukan beban kerja mana yang boleh menyesuaikan ukuran secara otomatis.
Apakah kondisi status, kebijakan restart, dan SLO menjadi bukti persetujuan.
Apakah audit dan simulasi membuktikan kebijakan tersebut berfungsi saat terjadi insiden.

Pertanyaan untuk klarifikasi

Namespace, lingkungan, dan beban kerja mana yang boleh menyesuaikan ukuran?
Siapa yang menyetujui batas, memiliki tanggung jawab biaya, dan dapat membekukan perubahan secara mendesak?
Bagaimana Anda mendeteksi resizePolicy kontainer, koneksi stateful, dan risiko restart memori?
Apakah organisasi sudah memiliki kuota, jendela perubahan, audit, dan komando insiden?

Jawaban 30 detik

Saya akan membuat tingkatan berdasarkan lingkungan, kekritisan bisnis, dan risiko restart: lingkungan pengembangan dapat menyetel secara otomatis, sedangkan layanan produksi yang kritis memerlukan persetujuan. Kebijakan menetapkan batas CPU dan memori, kenaikan bertahap (step), masa jeda (cooldown), kuota namespace, serta batasan pengaman SLO, dan mewajibkan subresource /resize dengan pemilik, alasan, dan observedGeneration. Admisi menolak permintaan yang tidak dijelaskan atau di luar batas; event membedakan Pending, InProgress, Infeasible, dan Deferred. Audit menghubungkan biaya dengan restart, dan simulasi berkala melatih pembekuan, rollback, dan serah terima kepemilikan.

Pembahasan mendalam langkah demi langkah

Menentukan tingkatan risiko

Buat tingkatan berdasarkan lingkungan, SLO, status data, kemampuan interupsi koneksi, dan resizePolicy kontainer. Beban kerja kritis stateful, pembayaran, dan control-plane secara default memerlukan persetujuan untuk perubahan memori; beban kerja stateless berisiko rendah dapat disetel dalam batas yang ditentukan.

Menetapkan aturan admisi

Wajibkan allowlist namespace, batas sumber daya, step, cooldown, kapasitas node, kuota, jendela perubahan, dan label. Setiap permintaan mencantumkan sumber metrik, target, dan estimasi biaya.

Mengikat kebijakan ke status Kubernetes

Wajibkan pengontrol untuk membaca sumber daya yang diinginkan/aktual, observedGeneration, dan kondisi resize. Hanya InProgress yang selesai dengan nilai aktual yang cocok yang dianggap berhasil; Pending, Infeasible, dan Deferred tetap terlihat beserta alasannya.

Menangani restart dan rollback

Perubahan memori dapat me-restart kontainer, sehingga layanan harus mendeklarasikan pengosongan koneksi (connection draining), pemulihan status, dan jumlah restart maksimum. Melebihi batasan akan membekukan otomatisasi dan memulihkan anggaran stabil terakhir; fase Pod Running bukanlah bukti kelangsungan bisnis.

Menjadikan biaya dan audit sebagai prioritas utama

Catat CPU dan memori sebelum/sesudah, durasi, estimasi biaya, pemilik, penyetuju, dan hasil. Keuangan melihat varians anggaran berdasarkan namespace, tim, dan beban kerja; SRE mengorelasikan peristiwa SLO, OOM, dan restart.

Mensimulasikan insiden dan mengembangkan tata kelola

Latih skenario kekurangan kapasitas node, pemadaman pengontrol, anggaran yang buruk, dan rollback skala luas. Perbarui kebijakan, runbook, dan kontak setelahnya; setiap pengecualian memiliki masa kedaluwarsa agar allowlist sementara tidak menjadi permanen.

Jawaban model

Saya akan memperlakukan penyesuaian ukuran Pod sebagai perubahan yang diatur tata kelolanya, bukan sakelar yang terbuka bebas. Buat tingkatan berdasarkan lingkungan, SLO, status, dan resizePolicy; layanan stateful kritis memerlukan persetujuan. Admisi menetapkan namespace, batas, step, cooldown, kuota, kapasitas, dan jendela perubahan, serta mewajibkan /resize dengan pemilik, alasan, dan observedGeneration. Pengontrol melaporkan Pending, Infeasible, dan Deferred serta mengonfirmasi keberhasilan hanya dari status aktual. Pembatas restart memori memerlukan draining dan pemulihan; pelanggaran akan memicu pembekuan dan rollback. Audit menghubungkan biaya, SLO, OOM, dan restartCount, serta simulasi melatih pembekuan, rollback, dan serah terima kepemilikan.

Kesalahan umum

Menulis batas sumber daya tanpa penyetuju, otoritas pembekuan, atau pemilik.
Mengizinkan penyesuaian ukuran memori otomatis di setiap namespace produksi.
Mengabaikan kondisi /resize dan kebijakan restart kontainer.
Memperlakukan fase Pod Running sebagai bukti layanan bisnis yang tidak terputus.
Menghilangkan audit biaya, kedaluwarsa pengecualian, dan simulasi rollback.
Baru mencari pemilik dan runbook setelah insiden dimulai.

Pertanyaan lanjutan

Layanan mana yang secara default tidak boleh melakukan penyesuaian ukuran memori otomatis?

Layanan kritis yang tidak dapat melakukan draining dengan cepat, memiliki pemulihan status yang mahal, atau berisiko terhadap konsistensi saat restart harus memerlukan persetujuan dan simulasi yang telah selesai.

Bagaimana Anda mencegah tim melewati kebijakan dengan mengedit Pod secara langsung?

Gunakan admisi, RBAC, field management, dan audit untuk menolak penulisan yang tidak sah; izin darurat dibatasi waktu, dapat dilacak, dan kedaluwarsa secara otomatis.

Siapa yang memutuskan ketika biaya berkonflik dengan SLO?

Kebijakan menetapkan prioritas dan ambang batas anggaran di awal; pemilik produk dan SRE yang ditunjuk membuat keputusan di atas ambang batas tersebut daripada membiarkan pengontrol memilih secara diam-diam.

Bagaimana Anda tahu bahwa kebijakan tersebut berfungsi?

Bandingkan permintaan di luar batas yang ditolak, regresi SLO, OOM, restart, varians anggaran, waktu rollback, dan penyelesaian simulasi, lalu lakukan peninjauan bersama setiap tim.