Temu Bual Reka Bentuk Sistem: Bagaimanakah Anda Mereka Bentuk Pengawal Saiz Semula Peringkat Pod Kubernetes?

Gesaan dan konteks

Sebuah Pod berbilang kontena mempunyai proksi API, cache sidecar dan pekerja kelompok. Pasukan ingin melaraskan belanjawan CPU dan memori peringkat Pod daripada pendaman dan panjang giliran tanpa memadamkan Pod. Reka bentuk pengawal, termasuk pemerhatian, keputusan, penulisan /resize, penjejakan status, perlindungan keserentakan, permintaan tidak boleh laksana dan undur balik.

Perkara yang diuji oleh penemu bual

Sama ada anda membezakan sumber yang diingini, sumber sebenar dan dasar mula semula kontena.
Sama ada anda mereka bentuk penyelarasan idempoten, status condition dan percubaan semula tertangguh/tidak boleh laksana.
Sama ada belanjawan Pod dan permintaan kontena mempunyai sempadan yang jelas dan rel keselamatan.
Sama ada metrik, kebenaran, pemulihan dan peluncuran progresif adalah sebahagian daripada reka bentuk.

Soalan untuk penjelasan

Adakah kluster menyokong pensaizan semula peringkat Pod, dan apakah feature gates serta versi kubectl yang dipasang?
Adakah pengawal mengubah CPU, memori, atau kedua-dua sumber Pod dan kontena?
Kontena manakah yang boleh dimulakan semula, dan manakah yang mempunyai sambungan atau keadaan yang tidak boleh diganggu?
Adakah matlamatnya pengurangan kos, SLO, atau menyerap giliran yang melonjak?

Jawapan 30 saat

Saya akan membina penyelarasan idempoten berasaskan peristiwa: membaca metrik dan keadaan Pod, mengira sasaran dalam belanjawan, SLO, kapasiti nod dan tempoh bertenang (cooldown), kemudian menghantar perubahan kecil melalui subresource /resize. Status merekodkan observedGeneration, PodResizePending, PodResizeInProgress dan sebab Infeasible atau Deferred; percubaan semula menggunakan backoff, keutamaan dan kiraan maksimum. CPU dan memori dinilai secara berasingan, resizePolicy kontena dipatuhi, dan belanjawan disahkan terakhir dipulihkan sekiranya terdapat risiko memori atau kemerosotan SLO. Setiap penulisan mempunyai pemilik, jejak audit dan sempadan RBAC.

Perbincangan mendalam langkah demi langkah

Tentukan model sumber dan sempadan keselamatan

spec.resources peringkat Pod ialah belanjawan agregat; requests dan limits kontena masih mempengaruhi jaminan dan tingkah laku mula semula. Kekalkan panduan keselamatan minimum, maksimum, langkah, tempoh bertenang dan SLO bagi setiap beban kerja, serta menolak permintaan yang melebihi kuota ruang nama atau kapasiti nod.

Kumpul metrik dan kira sasaran

Gunakan pendaman, panjang giliran, pendikit CPU (CPU throttling), set kerja dan peristiwa OOM. Gunakan tetingkap dan histerisis untuk mengelakkan tindak balas terhadap satu lonjakan semata-mata; sasaran mesti memenuhi kedua-dua belanjawan Pod dan kekangan jumlah permintaan kontena.

Hantar kemas kini subresource saiz semula yang idempoten

Pengawal mengemas kini keadaan yang diingini dengan versi sumber dan pemilik. Contoh permintaan:

yaml

spec:
  resources:
    requests:
      cpu: "300m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

Panggil subresource /resize dan semak resourceVersion. Jika berlaku konflik, baca semula dan selaraskan semula daripada menimpa pengguna atau pengawal lain.

Jejak condition dan keutamaan percubaan semula

Baca condition seperti PodResizePending dan PodResizeInProgress serta observedGeneration. Infeasible bermaksud kekangan semasa tidak dapat memenuhi permintaan; Deferred bermaksud ia ditangguhkan. Kekalkan sebab, percubaan seterusnya dan kiraan. Jadualkan percubaan semula mengikut keutamaan beban kerja, QoS dan masa menunggu supaya kerja berkeutamaan rendah tidak terabai selamanya.

Kendalikan dasar mula semula kontena

Perubahan peringkat Pod boleh mencetuskan resizePolicy peringkat kontena. CPU boleh digunakan tanpa mula semula manakala memori mungkin memerlukannya; periksa dasar, sambungan dan keadaan setiap kontena. Letakkan permintaan yang tidak boleh dimulakan semula di belakang giliran keselamatan dan jangan sesekali melaporkan kesinambungan perniagaan daripada kejayaan peringkat Pod semata-mata.

Perhati, undur balik dan kekal tersedia tinggi

Rekodkan nilai sasaran dan sebenar, peralihan condition, kiraan mula semula, SLO pendaman, kemuncak memori dan sebab kegagalan. Jalankan replika pengawal dengan pemilihan ketua dan nyahduplikasi giliran mengikut kunci Pod. Sekiranya belanjawan tidak elok, OOM atau kemerosotan SLO berlaku, pulihkan sasaran stabil terakhir dan jedakan automasi untuk semakan manusia.

Jawapan model

Saya akan membina penyelarasan idempoten yang membaca metrik pendaman, giliran, pendikit, set kerja dan OOM, kemudian mengira sasaran dalam belanjawan minimum/maksimum, langkah, tempoh bertenang, kapasiti nod dan kuota ruang nama. Hantar perubahan kecil berversi sumber melalui /resize; baca semula apabila berlaku konflik. Rekodkan observedGeneration, Pending, InProgress, Infeasible, sebab Deferred dan masa percubaan semula, dengan menjadualkan percubaan semula mengikut keutamaan dan menunggu. Periksa dasar saiz semula setiap kontena sebelum perubahan memori boleh memulakannya semula. Gunakan pemilihan ketua, metrik dan log audit; pulihkan belanjawan stabil terakhir dan jedakan automasi sekiranya berlaku kemerosotan SLO atau OOM.

Kesilapan lazim

Menyunting spesifikasi Pod secara terus dan menganggap kubelet menggunakannya, sambil mengabaikan subresource /resize.
Hanya membaca sumber yang diingini dan mengabaikan sumber sebenar serta condition.
Meninggalkan tempoh bertenang dan histerisis, menyebabkan ayunan dan mula semula yang kerap.
Menggugurkan permintaan Deferred selamanya atau mencuba semula permintaan Infeasible tanpa had.
Mengabaikan resizePolicy kontena dan risiko mula semula memori.
Ketiadaan resourceVersion, pemilik dan RBAC, membolehkan pengawal saling menimpa antara satu sama lain.

Soalan susulan

Bagaimanakah anda menghalang dua pengawal daripada menimpa antara satu sama lain?

Gunakan pemilikan eksplisit, resourceVersion, pengurusan medan dan satu pemilik penulisan; baca semula dan gabungkan niat semasa konflik daripada melakukan penimpaan tanpa syarat.

Bagaimanakah anda membezakan Infeasible daripada Deferred?

Infeasible bermaksud kekangan semasa tidak dapat memenuhi sasaran dan memerlukan sasaran atau kapasiti baharu; Deferred adalah bersifat sementara dan harus dicuba semula dengan sebab serta keutamaannya dikekalkan.

Bilakah automasi perlu dijeda?

Jedakan semasa OOM, kemerosotan SLO berterusan, condition tidak berubah, mula semula berlebihan atau pemerhatian tidak sah, sambil mengekalkan laluan pemulihan manual.

Bagaimanakah anda membuktikan tiada gangguan berlaku?

Hubung kaitkan condition saiz semula, restartCount kontena, ralat sambungan, pendaman dan metrik giliran mengikut dasar; fasa Pod yang kekal Running semata-mata adalah tidak mencukupi.