Gesaan dan skop
Komponen penjadualan luaran mengesyorkan nod untuk Pod yang Pending bagi mengurangkan penapisan berulang selepas preemption. Berdasarkan Kubernetes nominatedNodeName, reka bentuk protokol kerjasama dan jelaskan mengapa ia tidak boleh menggantikan nodeName, cara penulisan ganti penjadual dan perubahan sumber dikendalikan, serta cara anda melakukan rollback.
Kubernetes v1.35 menandakan nominatedNodeName sebagai beta. Ia merupakan medan status yang boleh digunakan oleh komponen luaran untuk menamakan nod bagi Pod yang pending. Penamaan ini adalah usaha terbaik (best effort), penjadual boleh menulis ganti ke atasnya, dan nod yang dinamakan mungkin masih gagal dalam pemeriksaan penjadualan. Temu duga ini menguji sama ada anda memisahkan pembayang niat daripada pengikatan (binding) akhir.
Perkara yang diuji oleh penemu duga
Merangkumi kebenaran penulisan status dan pemilikan, pemasaan penamaan dan penapisan, penamatan santun (graceful termination) bagi mangsa preemption, perbezaan semantik antara nodeName dan nominatedNodeName, keputusan luaran yang idempoten dan mempunyai tempoh luput, metrik, serta pelancaran dan rollback feature-gate.
Jawapan 30 saat
"Saya menganggap nominatedNodeName sebagai pembayang yang boleh dibatalkan, bukan satu janji. Komponen luaran mengemas kini status hanya dengan kebenaran eksplisit serta merekodkan versi dan sebab; penjadual mengesahkan nod yang dinamakan pada setiap kitaran dan beralih kembali (fallback) kepada semua calon apabila ia gagal. Pod dengan keutamaan lebih tinggi boleh mengambil nod tersebut, dan penjadual boleh menulis semula atau mengosongkan medan itu. Saya menggunakan nodeName akhir dan peristiwa pengikatan sebagai hasil, mengukur kadar hit, kadar fallback, kependaman penjadualan dan masa penamatan mangsa, serta melumpuhkan feature gate atau penulis luaran jika isyarat tersebut merosot."
Penyelesaian langkah demi langkah
Langkah 1: Asingkan semantik medan
nodeName ialah penetapan tegar (hard assignment) dalam spec Pod. Ia memintas penjadual, dan nod yang tiada atau bersaiz tidak mencukupi boleh menyebabkan Pod gagal secara terus. nominatedNodeName berada dalam status dan menyatakan calon untuk Pod yang pending; kedua-dua penama luaran dan preemption penjadual boleh menulisnya, jadi ia merupakan status lembut (soft state).
Langkah 2: Tentukan kebenaran luaran
Berikan RBAC minimum kepada komponen luaran untuk mengemas kini status Pod sasaran sahaja, dan rekodkan sebab penamaan, versi algoritma dan cap masa dalam anotasi atau peristiwa. Ia tidak boleh menulis spec.nodeName atau menganggap bahawa kemas kini status menyebabkan kubelet mengikat Pod dengan serta-merta.
apiVersion: v1
kind: Pod
metadata:
name: batch-worker
status:
nominatedNodeName: worker-07Langkah 3: Hormati pemilikan penjadual
Penjadual boleh menulis medan tersebut selepas preemption atau semasa memasuki WaitOnPermit atau PreBind. Komponen luaran mesti menerima penulisan ganti dan mengelakkan pertelingkahan penulisan (write war). Bandingkan resourceVersion sebelum setiap kemas kini; jika berlaku konflik, baca semula dan kira semula.
Langkah 4: Reka bentuk penapisan dan fallback
Penjadual terlebih dahulu memeriksa sama ada nod yang dinamakan masih melepasi penapis sumber, keafinian, taint dan topologi. Jika tidak, aliran calon biasa akan diteruskan. Komponen luaran harus melakukan pra-semakan pantas sebelum menamakan, tetapi hasilnya tidak sekali-kali menjadi keputusan akhir penjadual.
Langkah 5: Kendalikan tetingkap preemption
Preemption memberi mangsa tempoh penamatan santun, jadi nod yang dinamakan mungkin kekal tidak boleh dilaksanakan semasa mangsa keluar. Penjadual boleh mengosongkan medan atau menyerahkan nod kepada Pod berkeutamaan lebih tinggi. Trafik perniagaan harus menunggu peristiwa pengikatan dan bukannya menganggap status penamaan sebagai sedia.
Langkah 6: Jadikan keputusan idempoten dan mempunyai tempoh luput
Lampirkan ID keputusan yang boleh dikesan dan TTL yang singkat pada setiap penamaan. Perubahan sumber nod, kemas kini spec Pod, perubahan keutamaan atau penyusunan semula giliran menjadikan penamaan lama basi. Penyelarasan berulang harus menulis nilai yang sama hanya semasa keputusan masih sah.
Langkah 7: Tentukan kebolehlihatan
Ukur kejayaan penulisan penamaan, konflik status, kegagalan penapis pada nod yang dinamakan, kependaman penjadualan fallback, masa Pending ke pengikatan, masa penamatan mangsa dan bilangan pengosongan medan. Pecahkan mengikut kluster, keutamaan, penjadual dan versi algoritma luaran untuk mengesan regresi.
Langkah 8: Lancarkan dan lakukan rollback
Dayakan laluan ini dalam beberapa ruang nama dan PriorityClass berisiko rendah terlebih dahulu, membandingkan kependaman penjadualan dan hasil preemption. Jika masa penapisan, pengikatan yang salah atau pergolakan status meningkat, hentikan penulisan status luaran dan lumpuhkan feature gate penjadual. Kekalkan ketersediaan penjadualan biasa; jangan paksa fallback dengan menulis nodeName.
Pertukaran (trade-offs) dan sempadan
nominatedNodeName atau nodeName
nominatedNodeName mengekalkan penapisan, preemption dan pengikatan di bawah kawalan penjadual, menjadikannya sesuai untuk pengesyoran luaran. nodeName memintas penjadual dan dikhaskan untuk kes lanjutan di mana pemanggil menerima tanggungjawab sumber dan kegagalan; ia bukan mekanisme pecutan umum.
Pembayang dahulu atau imbas setiap nod
Mencuba pembayang terlebih dahulu boleh mengurangkan penapisan berulang dalam kluster besar selepas preemption, tetapi nod mungkin telah berubah. Imbasan fallback penuh ialah dasar ketepatan dan tidak boleh dialih keluar demi pengoptimuman prestasi.
Kebolehlihatan atau kawalan
Status menjadikan niat penjadualan dapat dilihat tanpa memberikan kawalan muktamad. Makluman, pengawal dan automasi perniagaan harus memantau pengikatan, FailedScheduling dan peristiwa dan bukannya bergantung pada nominatedNodeName semata-mata.
Latih tubi kegagalan dan evolusi
Nod yang dinamakan kehilangan kapasiti
Mulakan Pod berkeutamaan lebih tinggi selepas penamaan dan sahkan bahawa penjadual menulis ganti atau mengosongkan medan tersebut dan Pod asal beralih kepada fallback dan bukannya kekal Pending secara kekal.
Kemas kini status mengalami konflik
Kemas kini status Pod yang sama secara serentak dan sahkan bahawa komponen luaran membaca semula selepas konflik resourceVersion dan bukannya menulis ganti penjadual dengan objek yang lapuk.
Penamatan mangsa lambat
Berikan mangsa preemption tempoh penamatan santun yang panjang. Sahkan bahawa nod yang dinamakan tidak dilaporkan sebagai tersedia terlalu awal dan pantau kependaman ekor (tail) dari Pending ke pengikatan.
Kesilapan lazim dan susulan
Kesilapan 1: Menganggap nominatedNodeName sebagai hasil pengikatan
Susulan: Adakah Pod dijamin berjalan di sana sebaik sahaja medan itu wujud? Tidak. Penjadual menapis semula; nodeName akhir dan peristiwa pengikatan adalah hasilnya.
Kesilapan 2: Menggantikan penamaan dengan nodeName
Susulan: Mengapa tidak menulis nodeName secara terus? Ia memintas perlindungan sumber, taint, keafinian dan preemption serta mungkin gagal pada nod yang tidak sesuai.
Kesilapan 3: Menulis ganti status secara berulang-ulang
Susulan: Bagaimana jika penjadual menukar medan tersebut? Terima perlumbaan pemilikan, gunakan resourceVersion, TTL keputusan dan penyelarasan idempoten dan bukannya bertelingkah dengan penjadual.
Susulan lebih mendalam dan jawapan model
Mengapakah nod yang dinamakan mungkin bukan keputusan akhir?
Semasa penamatan mangsa, nod lain mungkin melepaskan kapasiti atau Pod berkeutamaan lebih tinggi mungkin mengambil nod yang dinamakan. Penjadual terus mencuba dan mungkin mengosongkan atau menulis ganti penamaan tersebut.
Bagaimanakah anda membuktikan bahawa pengoptimuman ini berkesan?
Bandingkan masa penapis, kependaman Pending ke pengikatan, kadar hit penamaan, kadar fallback dan masa penamatan mangsa sebelum dan selepas pelancaran. Jumlah penulisan sahaja tidak membuktikan penjadualan yang lebih pantas.
Apakah sempadan keselamatan minimum untuk komponen luaran?
Kemas kini status hanya pada Pod yang dibenarkan, jangan sekali-kali menulis nodeName atau spec keutamaan dan sumber, dan sahkan hasil melalui peristiwa pengikatan. Setiap keputusan mesti mempunyai tempoh luput, boleh diaudit dan boleh di-rollback.