Temu duga reka bentuk sistem: Bagaimanakah anda melancarkan Kubernetes Node Declared Features dengan selamat?

Gesaan dan konteks

Kluster anda sedang mengguna pakai Kubernetes Node Declared Features: kubelet melaporkan keupayaan nod terurus dalam status Node, penjadual menapis Pod sewajarnya, dan pengawal kemasukan (admission controller) mengesahkan kemas kini Pod. Reka bentuk pelancaran, kebolehcerapan, pengendalian kegagalan, dan pengunduran untuk kluster versi bercampur. Andaikan hanya ciri nod terkawal digunakan; pasukan aplikasi tidak boleh menulis nama keupayaan sewenang-wenangnya.

Perkara yang dinilai oleh penemu duga

• Sama ada pengisytiharan keupayaan dianggap sebagai fakta status nod dan bukannya label yang dikawal pengguna.
• Sama ada susunan kebergantungan antara kubelet, kube-apiserver, kube-scheduler, dan kawalan kemasukan dinyatakan secara eksplisit.
• Sama ada nod lama, status lapuk, kemas kini Pod, dan pengunduran feature-gate diliputi.
• Sama ada keselamatan ditunjukkan dengan kelengkapan pengisytiharan dan penolakan penjadualan, bukan sekadar permulaan proses.

Soalan penjelasan

• Versi kubelet manakah yang menghasilkan keupayaan tersebut, dan adakah nod lama dibenarkan terus memberi perkhidmatan kepada Pod biasa?
• Adakah matlamatnya untuk melindungi penempatan sahaja, atau juga kemas kini selepas Pod diikat (bound)?
• Adakah terdapat penjadual tersuai, pelbagai pelayan API, atau satah kawalan berbilang wilayah?
• Sekiranya terdapat laporan palsu, patutkah Pod baharu dihentikan sementara Pod sedia ada terus berjalan?

Jawapan 30 saat

Saya akan menganggap ini sebagai rantaian fakta rentas komponen: kubelet menerbitkan status.declaredFeatures, pemalam penjadual membuat inferens keperluan Pod dalam PreFilter dan menapis nod, dan pengesahan kemasukan melindungi kemas kini seterusnya. Saya akan mendayakannya terlebih dahulu pada kolam nod yang boleh diundur dan sebahagian kecil beban kerja, mengesahkan konfigurasi feature-gate yang sepadan pada pelayan API, penjadual, dan kubelet, kemudian mengembangkannya. Saya akan memantau kelengkapan laporan, sebab penolakan penjadualan, penolakan kemas kini, dan ketidakseimbangan versi. Sebarang ketidakkonsistenan akan menghentikan beban kerja yang memerlukan keupayaan baharu dan mengekalkan laluan penjadualan biasa untuk Pod lain.

Penyelesaian langkah demi langkah

1. Tentukan punca kebenaran (source of truth). Semasa permulaan, kubelet mengesan ciri terurus dan menulisnya ke Node.status.declaredFeatures; label aplikasi adalah tidak setara. Nama keupayaan mesti datang daripada feature gate terurus atau kontrak komponen yang eksplisit.
2. Jelaskan kebergantungan secara eksplisit. Kubernetes memerlukan gate NodeDeclaredFeatures pada kube-apiserver, kube-scheduler, dan kubelet. Sahkan versi satah kawalan dan konfigurasi sebelum menaik taraf kubelet; mendayakan satu pihak sahaja akan mencipta medan yang tidak digunakan oleh sesiapa atau penjadual yang mengharapkan laporan yang tidak dapat dihasilkan oleh nod.
3. Reka bentuk laluan penjadualan. Pemalam penjadual membuat inferens ciri yang diperlukan daripada PodSpec dalam PreFilter dan membandingkannya dengan pengisytiharan nod dalam Filter. Nod tanpa pengisytiharan yang diperlukan tidak boleh dijadualkan untuk Pod tersebut. Penjadual tersuai yang menggunakan medan ini mesti mengekalkan semantik lalai dan kegagalan yang sama.
4. Lindungi laluan kemas kini. Pengawal kemasukan NodeDeclaredFeatureValidator menyemak kemas kini Pod terhadap nod yang diikat, menghalang kemas kini kemudian daripada memintas kekangan keupayaan. Paparkan penolakan yang jelas dan bukannya merosot secara senyap.
5. Kendalikan ketidakseimbangan versi (version skew). Kubelet lama mungkin meninggalkan medan tersebut atau tidak mengetahui keupayaan baharu. Anggap ciri yang tidak diisytiharkan sebagai tidak disokong, membiarkan Pod bergantung dalam keadaan tergantung (pending) sementara Pod biasa menggunakan nod yang serasi. Jangan sunting status Node secara manual untuk memintas ketidakseimbangan ini.
6. Lancar secara berperingkat. Dayakan gate pada kolam nod yang boleh diundur, letakkan beban kerja prob yang memerlukan keupayaan tersebut, dan kembangkan secara beransur-ansur. Berhenti apabila kadar laporan hilang, penolakan penjadualan, penolakan kemas kini Pod, atau kependaman penjadual melebihi garis dasarnya.
7. Perhati dan audit. Kumpulkan versi pengisytiharan nod, ringkasan (digest) set keupayaan, sebab penapis penjadual, sebab penolakan kemasukan, dan cap jari konfigurasi gate, diasingkan mengikut kolam dan versi Kubernetes. Elakkan daripada menulis objek Node penuh ke dalam log berkardinaliti tinggi.
8. Undur (rollback) secara berhemah. Hentikan penciptaan Pod yang bergantung pada ciri tersebut, pulihkan penjadualan biasa, dan tutup gate mengikut susunan komponen selepas kerja bergantung yang belum selesai dikendalikan. Jika perniagaan sudah bergantung pada keupayaan tersebut, migrasikan beban kerja atau kekalkan nod yang serasi sebelum menghilangkan pengisytiharan.

Jawapan model

Saya akan mengenal pasti punca kebenaran dan sempadan perlindungan terlebih dahulu. Kubelet menerbitkan status.declaredFeatures terurus, pemalam NodeDeclaredFeatures penjadual menapis penempatan, dan NodeDeclaredFeatureValidator melindungi kemas kini selepas pengikatan. Oleh kerana Kubernetes memerlukan gate pada kube-apiserver, penjadual, dan kubelet, saya akan menyelaraskan versi dan konfigurasi sebelum mendayakannya pada satu kolam yang boleh diundur. Pod prob mengesahkan pelaporan keupayaan dan penempatan; kadar laporan hilang, penolakan penapis, penolakan kemas kini, dan kependaman penjadualan menjadi kriteria pengembangan. Nod lama yang tidak mengisytiharkan ciri tersebut adalah tidak disokong, manakala Pod biasa mengekalkan laluan lama. Untuk pengunduran, saya akan menghentikan beban kerja bergantung baharu, memigrasikan beban kerja sedia ada, menutup gate, dan mengesahkan bahawa kiraan pending dan penjadualan biasa kembali pulih.

Kesilapan lazim

• Menganggap declaredFeatures sebagai label biasa → pengguna boleh memalsukan keupayaan dan menggagalkan keselamatan penjadualan → terima set yang diuruskan oleh kubelet sahaja.
• Mendayakan gate hanya pada penjadual → nod tidak menerbitkan medan tersebut → semak konfigurasi pelayan API, penjadual, dan kubelet secara bersama.
• Menganggap "tidak diisytiharkan" sebagai disokong → nod versi bercampur mungkin menerima Pod yang tidak serasi → tidak diisytiharkan bermaksud tidak disokong.
• Menguji penempatan awal sahaja → kemas kini Pod boleh memintas kekangan → dayakan dan perhatikan juga pengesahan kemasukan.
• Mendayakannya pada seluruh kluster sekaligus → kegagalan tidak dapat dikaitkan dengan kolam, versi, atau beban kerja tertentu → gunakan prob, peringkat, dan syarat henti.
• Melumpuhkan gate serta-merta → Pod bergantung mungkin menjadi tidak dapat dipulihkan → hentikan penciptaan dan migrasikan beban kerja bergantung terlebih dahulu.

Soalan susulan dan respons

Sebuah nod melaporkan keupayaan tetapi statusnya lapuk (stale). Apakah yang perlu dilakukan oleh penjadual?

Jadikan usia laporan sebagai isyarat operasi. Pod yang memerlukan ciri tersebut perlu menunggu atau berpindah ke nod yang segar daripada bergantung pada pengisytiharan lama. Selepas tarikh akhir kesegaran, asingkan kolam dan perlukan pengesahan pengendali.

Apakah masalah yang boleh timbul dengan penjadual tersuai yang mengabaikan pemalam rasmi?

Ia mungkin membenarkan Pod yang ditolak oleh penjadual lalai. Laluan tersuai mesti melaksanakan semantik PreFilter, Filter, lalai, dan versi yang setara; jalankan ujian pematuhan (conformance tests) sebelum membenarkan beban kerja memilihnya.

Bagaimanakah anda mengelakkan tetingkap ketidakkonsistenan konfigurasi semasa tiga komponen menukar gate?

Letakkan cap jari konfigurasi dalam semakan pelancaran, pastikan beban kerja biasa terus berjalan, dan lancarkan melalui satah kawalan, penjadual, dan kolam nod mengikut susunan terkawal. Sebarang ketidakpadanan akan menghentikan pengembangan; permulaan proses semata-mata bukanlah tanda kejayaan.

Perniagaan bergantung pada ciri tersebut, tetapi pengunduran mendapati nod lama tidak menyokongnya. Apakah tindakan seterusnya?

Kekalkan kolam nod yang mengisytiharkan keupayaan tersebut, migrasikan atau kurangkan beban kerja bergantung, dan hanya selepas itu tutup gate. Jika migrasi mustahil, jeda pengunduran dan tambah kapasiti yang serasi dan bukannya mengeluarkan kekangan penjadualan secara tiba-tiba.