Bagaimanakah anda akan mereka bentuk permintaan sumber peringkat Pod Kubernetes?

Masalah dan konteks

Sumber peringkat Pod Kubernetes membolehkan Pod mengisytiharkan permintaan (requests) dan had (limits) CPU, memori, atau hugepages sebagai tambahan kepada nilai peringkat kontena. Nilai peringkat Pod mengambil keutamaan apabila kedua-duanya wujud, dan ia mempengaruhi penjadualan, QoS, dan pemarkahan OOM. Feature gate PodLevelResources dan versi kluster mesti disahkan sebelum pelancaran.

Andaikan proksi dan worker berkongsi beban kerja yang tidak sekata (bursty), tetapi proksi mempunyai SLO kependaman dan worker boleh menggunakan kapasiti terluang. Matlamatnya adalah untuk menyatakan hubungan tersebut tanpa menyebabkan penjadual atau kubelet menguatkuasakan belanjawan yang tidak diingini oleh pasukan.

Perkara yang dinilai oleh penemu duga

Penemu duga mencari model pemilikan sumber yang jelas, peraturan keutamaan yang betul, dan kesedaran bahawa permintaan peringkat Pod mengubah penjadualan dan QoS. Jawapan yang kukuh membincangkan jaminan agregat berbanding setiap kontena, had, penskalaan automatik, kebolehmerhatian, dan ujian migrasi.

Jawapan biasa hanya menyalin jumlah permintaan kontena ke dalam spec.resources. Jawapan yang mantap menerangkan sama ada belanjawan Pod merupakan kumpulan kongsi (shared pool), kontena mana yang memerlukan lantai minimum (floor), dan cara menghalang satu worker daripada menggunakan ruang senggang kependaman (latency headroom) milik proksi.

Soalan untuk dijelaskan terlebih dahulu

• Adakah permintaan peringkat Pod merupakan belanjawan dikongsi atau nilai minimum tegar bagi setiap kontena?
• Versi Kubernetes, feature gates, pengurus sumber, dan sistem pengendalian manakah yang berada dalam skop?
• Adakah proksi memerlukan lantai CPU yang dijamin atau had memori yang bebas daripada worker?
• Bagaimanakah dasar HPA, VPA, dan pengusiran (eviction) memerhatikan skop baharu ini?
• Apakah yang berlaku apabila kedua-dua permintaan peringkat Pod dan peringkat kontena ditentukan semasa migrasi?

Jika kontena mempunyai domain penskalaan atau kegagalan yang bebas, Pod berasingan mungkin lebih selamat. Jika ia benar-benar berkongsi kitaran hayat dan belanjawan lonjakan (burst), sumber peringkat Pod boleh menyatakan hubungan tersebut secara lebih langsung.

Jawapan 30 saat

“Saya akan mengesahkan sokongan feature-gate dan versi terlebih dahulu, kemudian memodelkan Pod sebagai belanjawan dikongsi dengan lantai proksi yang jelas. Permintaan peringkat Pod diutamakan, jadi saya akan mengelakkan tetapan bercampur yang tidak disengajakan, menguji kelakuan QoS dan OOM, serta menyemak input autoscaler. Saya akan menguji kanari manifes tersebut, membandingkan kependaman, pendikit (throttling), pengusiran, dan kos dengan dasar lama, serta mengekalkan pelan pengunduran (rollback) kepada permintaan peringkat kontena.”

Reka bentuk langkah demi langkah

1. Petakan peranan sumber. Ukur kepekaan kependaman proksi, kelakuan lonjakan worker, penggunaan keadaan mantap (steady-state), dan pertumbuhan memori. Tentukan sama ada kontena berkongsi belanjawan atau memerlukan jaminan terasing.
2. Sahkan keupayaan. Sahkan versi pelayan Kubernetes, gate PodLevelResources pada satah kawalan dan nod, jenis sumber yang disokong, dan had khusus Linux jika berkenaan.
3. Tetapkan belanjawan Pod. Pilih permintaan untuk penjadualan dan had untuk siling agregat. Pastikan belanjawan meninggalkan ruang untuk lantai kependaman proksi dan lonjakan worker.
4. Elakkan keutamaan yang kabur. Semasa migrasi, dokumentasikan bahawa nilai peringkat Pod mengatasi nilai peringkat kontena. Buang nilai kontena yang lapuk atau kekalkannya hanya apabila dasar secara sengaja memerlukan kedua-dua skop.
5. Semak QoS dan pengusiran. Kira semula kelas QoS dan kelakuan OOM, kemudian uji tekanan nod, pendikit (throttling), dan perebutan worker. Agregat yang sihat masih boleh menyembunyikan kebuluran sumber (starvation) pada proksi.
6. Laksanakan dan perhatikan. Jalankan kanari pada satu beban kerja dan jejaki kependaman p95, pendikit CPU, tekanan memori, OOM kills, pengusiran, mula semula, dan kos. Kembangkan pelaksanaan hanya apabila kawalan keselamatan (guardrails) kekal utuh.

Alternatif lain termasuk Deployment berasingan, permintaan khusus kontena sahaja, atau sidecar dengan had yang jelas. Sumber peringkat Pod paling berguna apabila kitaran hayat dan kapasiti lonjakan dikongsi secara sengaja.

Contoh jawapan

“Proksi memerlukan lantai kependaman, manakala worker boleh meminjam CPU terluang. Saya akan menetapkan permintaan Pod yang mencerminkan agregat normal dan had untuk siling lonjakan, kemudian mengesahkan bahawa proksi tidak mengalami kebuluran sumber di bawah beban worker. Semasa migrasi, saya akan mengalih keluar permintaan kontena yang bercanggah atau mendokumentasikan tujuannya kerana nilai peringkat Pod akan diutamakan. Saya akan melakukan kanari pada dua nod, memantau kependaman p95, pendikit, OOM, pengusiran, dan kelakuan autoscaler, serta berundur kepada dasar kontena sebelumnya jika SLO proksi merosot.”

Kesilapan biasa

• Kesilapan: Menganggap permintaan Pod adalah jaminan bagi setiap kontena secara automatik → Mengapa ia gagal: belanjawan mungkin dikongsi → Penyelesaian: tentukan lantai dan pengasingan secara jelas.
• Kesilapan: Membiarkan nilai kontena yang bercanggah tanpa didokumentasikan → Mengapa ia gagal: keutamaan peringkat Pod mengejutkan pengendali → Penyelesaian: dokumentasikan dan uji sumber yang berkesan.
• Kesilapan: Hanya menyemak penggunaan CPU → Mengapa ia gagal: tekanan memori dan kelakuan OOM boleh berubah → Penyelesaian: perhatikan CPU, memori, QoS, pengusiran, dan kependaman bersama-sama.
• Kesilapan: Mendayakan ciri pada satu komponen satah kawalan sahaja → Mengapa ia gagal: semua nod dan komponen yang diperlukan mesti menyokongnya → Penyelesaian: sahkan keupayaan seluruh kluster sebelum pelancaran.

Soalan susulan dan respons

Bagaimana jika proksi mengalami kebuluran sumber walaupun Pod berada di bawah hadnya?

Kendalikan ia sebagai kegagalan perebutan (contention). Tambahkan lantai proksi, asingkan beban kerja, atau gunakan pengasingan peringkat kontena; ruang senggang agregat sahaja tidak menjamin kependaman.

Bagaimanakah permintaan peringkat Pod mempengaruhi QoS?

Ia mengambil keutamaan apabila kedua-dua skop wujud dan mempengaruhi pengiraan QoS serta OOM bagi Pod. Kira semula kelas semasa migrasi dan uji tekanan nod.

Bolehkah Pod Windows menggunakan sumber peringkat Pod?

Semak had khusus bagi setiap versi. Kelakuan Kubernetes 1.35 yang didokumentasikan tidak menyokong sumber peringkat Pod untuk Pod Windows, jadi kekalkan dasar peringkat kontena di sana.

Bilakah anda akan memilih untuk memisahkan Pod?

Pisahkan apabila kontena berskala, gagal, atau mempunyai SLO secara bebas. Kekalkan satu Pod apabila kitaran hayat kongsi dan belanjawan lonjakan adalah disengajakan serta boleh diperhatikan.