Gesaan dan konteks
Satu pasukan platform ingin mengubah CPU dan memori tanpa mencipta semula Pod. Reka bentuk aliran penskalaan semula in-place, terangkan masa kontena mesti dimulakan semula, cara mengendalikan kapasiti yang tidak mencukupi, serta cara memerhati dan mengundur balik.
Kubernetes 1.33 meluluskan penskalaan semula in-place kontena ke peringkat Beta; penskalaan semula sumber peringkat Pod berada pada peringkat Beta dalam 1.36. Pod yang sedang berjalan boleh menerima sumber CPU dan memori baharu, manakala kubelet menggunakan resizePolicy, kapasiti nod dan status cgroup untuk menggunakan atau menangguhkan perubahan tersebut. "Mengubah spec" bukan bermaksud "tidak akan memulakan semula".
Perkara yang diuji oleh penemu duga
Merangkumi batas peringkat Pod berbanding sumber kontena, semantik CPU dan memori bagi resizePolicy, syarat Pending dan InProgress, permintaan tidak boleh laksana (infeasible) dan ditangguhkan (deferred), tanggungjawab scheduler berbanding kubelet, QoS dan keutamaan, serta sempadan kenari dan undur balik (rollback).
Rangka jawapan 30 saat
"Saya akan menjadikan penskalaan semula sebagai permintaan deklaratif ditambah mesin keadaan. Pengawal mengemas kini spec sumber, kubelet menyemak kebolehlaksanaan, dan melaporkan PodResizePending atau PodResizeInProgress; CPU selalunya digunakan tanpa mula semula, manakala tingkah laku mula semula memori mengikut resizePolicy bagi setiap kontena. Permintaan yang tidak boleh laksana mengekalkan sebabnya dan mencuba semula di bawah had. Platform memerhati observedGeneration, cgroup sebenar, mula semula, dan perubahan QoS, menggunakan kenari kecil dan tampalan balikan untuk undur balik."
Penyelaman mendalam langkah demi langkah
Langkah 1: Tentukan model sumber
Sumber kontena menetapkan requests dan limits bagi setiap kontena; versi yang disokong juga mendedahkan batas agregat peringkat Pod. Limit Pod mengehadkan penggunaan agregat, tetapi limit kontena tidak boleh melebihinya. API mesti menyatakan sama ada ia mengedit spec.containers[*].resources atau spec.resources.
Langkah 2: Bina aliran penskalaan semula deklaratif
Platform menerima sasaran dan sebab, menulis medan sumber, dan menyimpan nilai lama, pelaku, dan generation. API tidak pernah mengedit cgroup nod secara langsung. Kubelet memerhati generation baharu, menyemak dan menggunakannya, kemudian menulis status.
Langkah 3: Kendalikan dasar mula semula
Kontena boleh memilih dasar bagi setiap sumber:
resizePolicy:
- resourceName: cpu
restartPolicy: NotRequired
- resourceName: memory
restartPolicy: RestartContainerNotRequired mencuba kemas kini dalam talian; RestartContainer membenarkan mula semula untuk menggunakan nilai baharu. Bagi Pod dengan restartPolicy: Never, setiap sumber kontena mesti menggunakan NotRequired, atau permintaan itu tidak sah.
Langkah 4: Modelkan kebolehlaksanaan dan status tertangguh
Apabila nod tidak dapat menyediakan sasaran, kubelet melaporkan PodResizePending dengan sebab seperti Infeasible atau Deferred; permintaan yang diproses boleh memasuki PodResizeInProgress. Pengawal harus membaca status dan bukannya hanya API spec, serta menggunakan observedGeneration untuk mengaitkan status dengan generation yang diminta.
Langkah 5: Layani CPU dan memori secara berbeza
CPU biasanya boleh mengemas kini kuota cgroup tanpa memulakan semula aplikasi. Pengecilan memori boleh dihadkan oleh set kerja semasa, dan beberapa masa jalanan memerlukan mula semula untuk menggunakannya dengan selamat. Jangan membuat inferens tentang tingkah laku memori daripada CPU; baca dasar bagi setiap sumber dan pancarkan peristiwa yang jelas.
Langkah 6: Selaraskan penjadualan dan QoS
Kemas kini in-place bukanlah penjadualan semula. Meningkatkan request mungkin memerlukan kapasiti nod, jadi permintaan yang ditangguhkan harus mencuba semula mengikut PriorityClass, kelas QoS, dan masa menunggu. Kira semula kuota, QoS, dan amaran selepas kemas kini supaya ruang nama atau beban kerja Guaranteed tidak terkurang kira secara senyap.
Langkah 7: Perhatikan nilai berkesan
Kumpulkan spec yang diingini, status conditions, observedGeneration, cgroup kontena sebenar, mula semula, OOM, pendikit (throttling) CPU, dan set kerja memori. Jika status menyatakan selesai tetapi cgroup tidak berubah, anggap ia sebagai kegagalan dan sekat tampalan lain daripada menimbun perubahan.
Langkah 8: Kenari, had kadar (rate-limit), dan undur balik
Skalakan semula secara kelompok mengikut beban kerja dan kumpulan nod, hadkan operasi serentak, dan tetapkan tamat masa Pending serta had percubaan semula. Sekiranya berlaku kegagalan, pulihkan sumber yang disimpan; jika dasar memori memulakan semula kontena, salurkan keluar (drain) trafik dan sahkan kesediaan sebelum memperluas. Setiap permintaan memerlukan kunci kedap idempoten (idempotency key) untuk menghalang percubaan semula pengawal daripada menduplikasi kerja.
Pertukaran (trade-off) dan sempadan
Kesinambungan tanpa mula semula berbanding kepastian sumber
Perubahan in-place mengurangkan gangguan, tetapi kapasiti dan keadaan tertangguh menjadikan penyiapan bersifat tak segerak. Gunakan langkah kecil untuk perkhidmatan yang sensitif terhadap kependaman; kerja kelompok mungkin menerima permulaan semula untuk mendapatkan hasil deterministik.
Batas Pod berbanding ketepatan kontena
Sumber Pod menyatakan siling kongsi manakala sumber kontena melindungi kontena kritikal. Apabila kedua-duanya wujud, sahkan bahawa limit kontena kekal dalam batas Pod dan tunjukkan sempadan berkesan dalam UI dan rekod audit.
Percubaan semula automatik berbanding kelulusan
Kekurangan kapasiti sementara wajar dicuba semula secara terhad. Mula semula memori, perubahan QoS, atau waktu puncak pengeluaran mungkin memerlukan kelulusan atau tetingkap penyelenggaraan; percubaan semula tanpa had adalah tidak selamat.
Latih tubi kegagalan dan pelan evolusi
Nod kekurangan kapasiti
Hantar pengembangan melebihi kapasiti nod, sahkan Infeasible atau Deferred, dan sahkan bahawa percubaan semula tidak mengubah nilai berkesan yang lama.
Perubahan memori memulakan semula kontena
Tetapkan RestartContainer untuk memori dan perhatikan penyaluran keluar trafik, mula semula, pemulihan kesediaan, dan susunan peristiwa. Pastikan pengawal tidak melaporkan mula semula sebagai kegagalan perniagaan.
Perlumbaan generation (race conditions)
Hantar dua sasaran dengan cepat. Generation lama tidak boleh menulis ganti sasaran baharu, dan observedGeneration akhir mesti sepadan dengan nilai cgroup.
Kesilapan biasa dan susulan
Kesilapan 1: Menganggap penskalaan semula in-place tidak pernah memulakan semula
Susulan: Apakah yang menyebabkan mula semula? resizePolicy kontena boleh memerlukannya, terutamanya untuk memori; penskalaan semula peringkat Pod tidak mempunyai dasar mula semula yang berasingan, tetapi dasar kontena masih terpakai.
Kesilapan 2: Menganggap kemas kini spec sebagai selesai
Susulan: Bagaimanakah anda mengesahkan kejayaan? Semak conditions, observedGeneration, cgroup, peristiwa kontena, dan bilangan mula semula dan bukannya hanya medan yang diingini.
Kesilapan 3: Menampal berulang kali apabila kapasiti tiada
Susulan: Apakah tindakan yang betul? Kekalkan sebab Pending, cuba semula dalam had keutamaan dan masa, serta tawarkan migrasi, sasaran yang lebih kecil, atau kelulusan.
Susulan lanjutan dan jawapan model
Mengapakah CPU dan memori direka bentuk secara berasingan?
Kuota CPU biasanya boleh berubah dalam talian; pengecilan memori dihadkan oleh set kerja dan tingkah laku masa jalanan serta mungkin dimulakan semula. API kongsi masih memerlukan dasar dan status bagi setiap sumber.
Bagaimanakah anda menghalang penskalaan semula pendua daripada menulis ganti sasaran yang lebih baharu?
Gunakan versi sumber atau generation untuk kemas kini bersyarat, terima hanya sasaran terkini, dan selaraskan (reconcile) status serta cgroup melalui observedGeneration.
Bilakah anda patut mengelakkan penskalaan semula in-place?
Gunakan penggantian bergilir (rolling replacement) apabila pengasingan yang kuat diperlukan, kapasiti tidak stabil, aplikasi tidak boleh bertolak ansur dengan pemulaan semula, atau perubahan sumber melanggar andaian masa jalanan. Kekalkan penskalaan semula in-place sebagai pengoptimuman yang terkawal.