Gesaan dan konteks
Pasukan platform sedang mendayakan penskalaan semula saiz CPU dan memori peringkat Pod Kubernetes. Pasukan produk mahukan penalaan automatik, pihak kewangan bimbang tentang kos, dan SRE bimbang bahawa perubahan memori boleh memulakan semula kontena. Bina dasar kemasukan, audit, tindak balas insiden dan undur balik (rollback) merentasi pasukan.
Perkara yang diuji oleh penemu duga
- Sama ada keupayaan teknikal bertukar menjadi sempadan pemilikan, kebenaran dan belanjawan yang jelas.
- Sama ada tahap risiko menentukan beban kerja yang boleh diskalakan semula secara automatik.
- Sama ada syarat status, dasar mula semula dan SLO menjadi bukti kelulusan.
- Sama ada audit dan latih tubi membuktikan dasar tersebut berfungsi semasa insiden.
Soalan untuk penjelasan
- Namespace, persekitaran dan beban kerja manakah yang boleh diskalakan semula saiznya?
- Siapakah yang meluluskan had, memiliki kos dan boleh membekukan perubahan secara mendesak?
- Bagaimanakah anda mengesan
resizePolicykontena, sambungan berstatus (stateful) dan risiko mula semula memori? - Adakah organisasi sudah mempunyai kuota, tetingkap perubahan, audit dan perintah insiden?
Jawapan 30 saat
Saya akan membahagikan tahap mengikut persekitaran, kekritikalan perniagaan dan risiko mula semula: persekitaran pembangunan boleh ditala secara automatik, manakala perkhidmatan pengeluaran kritikal memerlukan kelulusan. Dasar menetapkan had CPU dan memori, langkah (step), tempoh bertenang (cooldown), kuota namespace dan kawalan perlindungan SLO, serta memerlukan sub-sumber /resize dengan pemilik, sebab dan observedGeneration. Kemasukan menolak permintaan yang tidak dijelaskan atau di luar had; peristiwa membezakan Pending, InProgress, Infeasible dan Deferred. Audit menghubungkan kos dengan mula semula, dan latih tubi berkala mempraktikkan pembekuan, undur balik dan penyerahan pemilikan.
Penyelaman mendalam langkah demi langkah
Tentukan tahap risiko
Bahagikan tahap mengikut persekitaran, SLO, status data, kebolehan gangguan sambungan dan resizePolicy kontena. Beban kerja berstatus kritikal, pembayaran dan satah kawalan (control-plane) secara lalai memerlukan perubahan memori yang diluluskan; beban kerja tanpa status berisiko rendah boleh ditala dalam lingkungan had.
Wujudkan peraturan kemasukan
Wajibkan senarai dibenarkan namespace, had sumber, step, cooldown, kapasiti nod, kuota, tetingkap perubahan dan label. Setiap permintaan menyatakan sumber metrik, sasaran dan jangkaan kos.
Ikatkan dasar kepada status Kubernetes
Wajibkan pengawal untuk membaca sumber yang diingini/sebenar, observedGeneration dan syarat penskalaan semula saiz. Hanya InProgress yang selesai dengan nilai sebenar yang sepadan dianggap berjaya; Pending, Infeasible dan Deferred kekal kelihatan berserta sebabnya.
Kendalikan mula semula dan undur balik
Perubahan memori boleh memulakan semula kontena, jadi perkhidmatan mengisytiharkan penyaliran sambungan (connection draining), pemulihan status dan bilangan maksimum mula semula. Melebihi pagar kawalan akan membekukan automasi dan memulihkan belanjawan stabil yang terakhir; fasa Pod Running bukanlah bukti kesinambungan perniagaan.
Jadikan kos dan audit sebagai kelas pertama
Catatkan CPU dan memori sebelum/selepas, tempoh, anggaran kos, pemilik, pelulus dan hasil. Kewangan melihat varians belanjawan mengikut namespace, pasukan dan beban kerja; SRE mengaitkan peristiwa SLO, OOM dan mula semula.
Latih tubi insiden dan kembangkan tadbir urus
Praktikkan kekurangan kapasiti nod, gangguan pengawal, belanjawan yang salah dan undur balik secara meluas. Kemas kini dasar, buku panduan (runbooks) dan kenalan selepas itu; setiap pengecualian mempunyai tarikh luput supaya senarai dibenarkan sementara tidak menjadi kekal.
Jawapan model
Saya akan menganggap penskalaan semula saiz Pod sebagai perubahan yang ditadbir urus, bukan suis terbuka. Bahagikan tahap mengikut persekitaran, SLO, status dan resizePolicy; perkhidmatan berstatus kritikal memerlukan kelulusan. Kemasukan menetapkan namespace, had, step, cooldown, kuota, kapasiti dan tetingkap perubahan, serta memerlukan /resize dengan pemilik, sebab dan observedGeneration. Pengawal melaporkan Pending, Infeasible dan Deferred serta mengesahkan kejayaan hanya daripada keadaan sebenar. Pagar mula semula memori memerlukan penyaliran dan pemulihan; pelanggaran akan membekukan dan mengundur balik. Audit menghubungkan kos, SLO, OOM dan restartCount, dan latih tubi mengulang kaji pembekuan, undur balik serta penyerahan pemilikan.
Kesilapan biasa
- Menulis had sumber tanpa pelulus, pihak berkuasa pembekuan atau pemilik.
- Membenarkan penskalaan semula saiz memori automatik dalam setiap namespace pengeluaran.
- Mengabaikan syarat
/resizedan dasar mula semula kontena. - Menganggap fasa Pod Running sebagai bukti perkhidmatan perniagaan tidak terganggu.
- Meninggalkan audit kos, tarikh luput pengecualian dan latih tubi undur balik.
- Hanya mencari pemilik dan buku panduan selepas insiden bermula.
Soalan susulan
Perkhidmatan manakah yang patut ditetapkan secara lalai kepada tiada penskalaan semula saiz memori automatik?
Perkhidmatan kritikal yang tidak boleh disalirkan dengan cepat, mempunyai pemulihan status yang mahal, atau berisiko terhadap ketekalan semasa mula semula harus memerlukan kelulusan dan latih tubi yang lengkap.
Bagaimanakah anda menghalang pasukan daripada memintas dasar dengan mengedit Pod?
Gunakan kemasukan, RBAC, pengurusan medan dan audit untuk menolak penulisan yang tidak dibenarkan; kebenaran kecemasan dihadkan mengikut masa, boleh dikesan dan luput secara automatik.
Siapakah yang membuat keputusan apabila kos bercanggah dengan SLO?
Dasar menetapkan keutamaan dan ambang belanjawan terlebih dahulu; pemilik produk dan SRE yang dinamakan membuat keputusan di atas ambang tersebut dan bukannya membiarkan pengawal memilih secara senyap.
Bagaimanakah anda tahu bahawa dasar tersebut berfungsi?
Bandingkan permintaan luar had yang ditolak, penurunan SLO, OOM, mula semula, varians belanjawan, masa undur balik dan penyiapan latih tubi, kemudian semak semula dengan setiap pasukan.