Temu Bual Reka Bentuk Sistem: Bagaimanakah Anda Akan Mereka Bentuk Kubernetes Node Readiness Controller?

Skop dan pertanyaan

Selepas nod dibut, kubelet mungkin melaporkan Ready walaupun pemacu GPU, CNI, pemalam storan atau ejen tempatan tidak boleh digunakan. Jika penjadual meletakkan Pod terlalu awal, beban kerja akan gagal berulang kali atau merosot secara senyap. Reka bentuk Node Readiness Controller yang mengisytiharkan prasyarat tambahan, menyekat penjadualan sehingga prasyarat dipenuhi, dan mengendalikan kebergantungan yang gagal kemudian dalam kitaran hayat nod.

Ini sesuai untuk temu bual kejuruteraan platform, SRE dan pengawal Kubernetes. Bahan temu bual Kubernetes awam merangkumi nod NotReady, taint dan toleration, serta penyelesaian masalah Pod dalam keadaan Pending. Projek rasmi Node Readiness Controller menerangkan API NodeReadinessRule, pengurusan taint automatik, mod bootstrap sahaja dan berterusan, serta dry run. Reka bentuk di bawah ialah jawapan temu bual yang munasabah, bukan soalan yang didakwa daripada mana-mana syarikat.

Perkara yang dinilai oleh penemu bual

Penemu bual mahu anda memisahkan antara "nod adalah Ready" dengan "nod sesuai untuk kelas beban kerja ini." Jawapan yang mantap mentakrifkan sumber syarat, skop peraturan, keidempotenan taint, pemulihan mula semula, keadaan yang boleh diperhati, dan perlindungan terhadap penyekatan seluruh kumpulan nod secara tidak sengaja.

Jawapan yang lemah menulis DaemonSet yang memeriksa segala-galanya. Jawapan yang mantap menerangkan sebab pelaporan syarat dipisahkan daripada penguatkuasaan dasar, cara bootstrap sahaja berbeza daripada penguatkuasaan berterusan, cara dry run menganggarkan radius impak, dan cara mengendalikan syarat lapuk, pemisahan pengawal serta peraturan yang bercanggah.

Soalan penjelasan sebelum menjawab

• Patutkah pengawal melindungi bootstrap nod sahaja, atau turut menghentikan penjadualan baharu apabila pemacu gagal kemudian? Ini menentukan mod penguatkuasaan dan tindakan pemulihan.
• Siapakah yang menghasilkan syarat: Node Problem Detector, pemalam peranti, ejen CNI atau DaemonSet tersuai? Sumber yang tidak dipercayai memerlukan semakan identiti dan kesegaran.
• Adakah semua syarat mesti True, atau mana-mana satu syarat sahaja boleh lulus? GPU, rangkaian dan storan biasanya memerlukan kumpulan nod dan peraturan yang berbeza.
• Adakah syarat false menyekat Pod baharu atau mengusir Pod sedia ada? Tindakan pertama boleh diterbalikkan; tindakan kedua memerlukan bukti yang lebih kukuh dan dasar pengusiran yang berasingan.

Rangka kerja jawapan 30 saat

"Saya akan memisahkan pelaporan syarat, penilaian peraturan dan pelaksanaan taint. NodeReadinessRule memilih nod dan menyenaraikan syarat yang mesti True; pengawal menambah atau mengalih keluar taint NoSchedule mengikut penguatkuasaan bootstrap sahaja atau berterusan. Operasi penulisan mestilah idempoten, boleh diperhati dan berkeupayaan dry-run. Peraturan dan status syarat berada dalam pelayan API supaya keadaan boleh dibina semula selepas mula semula. Saya akan merekodkan impak dahulu, mendayakan satu kumpulan nod, dan apabila berlaku kegagalan, menghentikan penulisan atau mengundur semula peraturan dan bukannya menjadikan seluruh kluster tidak boleh dijadualkan."

Jawapan langkah demi langkah

Mulakan dengan sempadan tanggungjawab. Pengawal tidak memeriksa GPU atau rangkaian secara langsung; ia menggunakan Node Conditions. Node Problem Detector, pemalam peranti atau ejen tersuai melaporkan fakta. Ini menggunakan semula ekosistem pemeriksaan sedia ada dan memisahkan "pemeriksaan gagal" daripada "penjadualan dibenarkan." Sesuatu syarat harus mengandungi jenis, status, masa kemas kini, sumber dan generasi pemerhatian; syarat lapuk tidak boleh terus membenarkan beban kerja.

Model peraturan mengandungi pemilih nod, set syarat, taint sasaran dan mod penguatkuasaan. Projek rasmi memerlukan setiap syarat yang disenaraikan dipenuhi sebelum mengalih keluar taint dan menyokong pemilihan nod heterogen mengikut label. bootstrap-only berhenti menilai peraturan tersebut selepas pemulaan berjaya. continuous menambah semula taint apabila syarat kritikal menjadi False kemudian. Mod pertama sesuai untuk pra-tarik imej atau persediaan perkakasan; mod kedua sesuai untuk kebergantungan yang mesti kekal sihat.

Gelung kawalan membaca peraturan, nod dan syarat, mengira taint yang diingini, serta menggunakan versi sumber untuk melaksanakan kemas kini. Penulisan mestilah idempoten dan dicuba semula sekiranya berlaku konflik: urus hanya taint yang dimiliki oleh pengawal ini, jangan sesekali mengalih keluar taint milik pentadbir atau pengawal lain. Jika dua peraturan menuntut kunci taint yang sama dengan maksud berbeza, pengesahan kemasukan harus menolak konflik tersebut; jika tidak, satu peraturan boleh membuang perlindungan peraturan lain secara tidak sengaja.

Jelaskan laluan kegagalan. Apabila pelapor berhenti mengemas kini, fail-closed atau fail-open ialah pilihan produk: kebergantungan keselamatan kritikal boleh menggunakan fail-closed, manakala bootstrap berisiko rendah boleh menggunakan fail-open dengan TTL yang pendek. Pengawal yang terputus sambungan tidak boleh mengosongkan taint sedia ada; ia melakukan penyesuaian selepas pemulihan. Jika nod dipadamkan atau labelnya berubah, tandakan peraturan sebagai tidak terpakai supaya keadaan lapuk tidak menyekat nod pengganti.

Kebolehperhatian harus merangkumi nod yang sepadan bagi setiap peraturan, syarat yang hilang atau lapuk, perbezaan taint yang diingini berbanding sebenar, kependaman dari masa syarat menjadi True sehingga boleh dijadualkan, dan bilangan Pod yang disekat (gated-Pod). Status harus mendedahkan syarat yang gagal dan masa penilaian terakhir tanpa merekodkan kelayakan atau data peranti sensitif. Untuk melindungi satah kawalan, buat barisan mengikut nod dan peraturan, gabungkan perubahan syarat yang pantas (coalesce), dan elakkan penulisan ke pelayan API bagi setiap denyutan jantung (heartbeat).

Lancarkan dengan dry run. Dry run projek rasmi merekodkan tindakan yang dimaksudkan dan mengemas kini status peraturan tanpa menggunakan taint. Perhatikan nod yang terjejas dan Pod yang berstatus Pending, kemudian dayakan satu kumpulan nod. Pengunduran semula menjeda penilaian peraturan baharu, mengekalkan taint perlindungan sedia ada, membetulkan sumber syarat dan melakukan penyesuaian semula; ia tidak memadamkan setiap taint NoSchedule dengan satu arahan.

Alternatif termasuk menambah nodeSelector pada setiap beban kerja, menggunakan Pod schedulingGates, atau menambah taint daripada skrip bootstrap. Pemilih beban kerja sesuai untuk kumpulan kecil pengguna yang diketahui tetapi terlepas pandang Pod masa hadapan. Pod gate melindungi Pod, manakala masalah ini melindungi nod. Skrip kekurangan keadaan kongsi dan pemulihan. Pengawal sesuai untuk nod heterogen dan kluster kongsi, dengan kos melibatkan CRD, gelung kawalan dan domain kegagalan tambahan.

Contoh jawapan berkualiti tinggi

Saya akan membina pengawal deklaratif yang bertanggungjawab hanya untuk "adakah Pod baharu boleh dijadualkan di sini?" Node Problem Detector, pemalam peranti atau ejen CNI menulis syarat; pengawal tidak menduplikasi pemeriksaan mereka. Peraturan memilih nod, menyenaraikan syarat yang mesti True, menamakan taint NoSchedule dan memilih mod. Kerja bootstrap menggunakan bootstrap-only: sebaik sahaja pemacu GPU dan ejen rangkaian sedia, taint dialih keluar. Kebergantungan berterusan menggunakan continuous: kegagalan kemudian akan menambah semula taint, tetapi tidak mengusir Pod sedia ada secara automatik.

Pengawal memiliki dan menyesuaikan hanya taint yang membawa penanda pemiliknya, menggunakan versi sumber dan percubaan semula konflik untuk keidempotenan. Tuntutan yang bercanggah bagi kunci taint yang sama akan ditolak. Status peraturan melaporkan nod yang sepadan, syarat yang hilang atau lapuk, perbezaan taint dan masa penilaian. Saya akan menggunakan dry run dahulu, membandingkan unjuran impak dengan Pod yang Pending, dan menjalankan canary pada satu kumpulan nod. Semasa pengawal terputus, kekalkan perlindungan sedia ada; selepas pemulihan, lakukan penyesuaian. Pengunduran semula menjeda penilaian dan membaiki sumber syarat daripada mengosongkan setiap taint kluster.

Kesilapan biasa

• Kesilapan → Meminta pengawal melakukan SSH ke dalam setiap nod; kegagalan → ia memintas sumber syarat Kubernetes dan meluaskan sempadan kebenaran; pembetulan → biarkan ejen khusus melaporkan syarat dan kekalkan penilaian dasar dalam pengawal.
• Kesilapan → Menggunakan continuous untuk bootstrap sekali sahaja; kegagalan → nod yang telah selesai terus turun naik (flapping) dan kekal tidak boleh dijadualkan; pembetulan → gunakan bootstrap-only dan rekodkan penyelesaian.
• Kesilapan → Memadamkan sebarang taint dengan kunci yang sama; kegagalan → perlindungan keselamatan pentadbir atau pengawal lain boleh hilang; pembetulan → gunakan penanda pemilikan, pengesahan konflik dan kemas kini peringkat medan.
• Kesilapan → Mengosongkan semua taint selepas pengawal mula semula; kegagalan → beban kerja ditempatkan pada nod yang belum sedia semasa tempoh pemulihan; pembetulan → kekalkan keadaan dan lakukan penyesuaian dengan semakan versi sumber.

Soalan susulan dan respons

Bagaimana jika pelapor syarat berhenti mengemas kini: fail-open atau fail-closed?

Kelaskan kebergantungan tersebut. Pemacu GPU, modul kripto dan rangkaian rentas zon boleh menggunakan fail-closed dengan masa tamat tempoh, menerima kehilangan kapasiti sementara. Bootstrap sekali sahaja yang berisiko rendah boleh menggunakan fail-open dengan rekod kejayaan dan TTL yang pendek. Dalam kedua-dua kes, ukur "unknown" secara berasingan daripada False supaya kehilangan telemetri tidak disalah anggap sebagai sihat.

Dua peraturan sepadan dengan nod dan menuntut kunci taint yang sama. Apakah tindakan anda?

Tolak konflik semantik semasa kemasukan atau penyusunan peraturan, dengan memerlukan kunci yang berbeza atau satu pemilik agregat yang jelas. Pengawal mengekalkan keadaan yang diingini bagi setiap peraturan dan mengalih keluar taint agregat hanya apabila setiap pemilik memenuhi syarat pelepasannya. Peraturan terakhir yang melakukan penyesuaian tidak boleh memadamkannya secara bersendirian.

Bagaimanakah anda membuktikan dry run tidak akan menghabiskan kapasiti kluster?

Kumpulkan nod yang sepadan, kapasiti boleh dijadualkan yang tersedia, permintaan Pod dan taburan topologi ke dalam satu laporan impak. Simulasikan satu kumpulan nod, perhatikan Pod yang disekat, barisan autoscaler dan kependaman penjadualan, kemudian kembangkan. Jika beban kerja kritikal kekurangan ruang kapasiti, ubah kumpulan nod atau peraturan sebelum penguatkuasaan.

Mengapakah tidak mengusir Pod sedia ada apabila nod gagal dalam kesediaan berterusan?

"Tiada Pod baharu" dan "Pod sedia ada tidak selamat" ialah keputusan yang berasingan. NoSchedule mengekalkan kesinambungan sambil menyekat penempatan baharu; pengusiran memerlukan PDB, penamatan secara tertib dan dasar keselamatan data yang tersendiri. Pengawal pengusiran yang berasingan harus bertindak hanya apabila terdapat bukti bahawa beban kerja sedia ada tidak selamat.