Wawancara system design: Bagaimana cara melakukan rollout Kubernetes Node Declared Features dengan aman?

Permintaan dan konteks

Kluster Anda mengadopsi Kubernetes Node Declared Features: kubelet melaporkan kapabilitas node terkelola dalam status Node, scheduler memfilter Pod yang sesuai, dan admission controller memvalidasi pembaruan Pod. Rancang rollout, observabilitas, penanganan kegagalan, dan rollback untuk kluster dengan versi campuran. Asumsikan hanya fitur node terkontrol yang digunakan; tim aplikasi tidak dapat menulis nama kapabilitas arbitrer.

Hal yang dievaluasi pewawancara

• Apakah deklarasi kapabilitas diperlakukan sebagai fakta status node, bukan sekadar label yang dikontrol pengguna.
• Apakah urutan dependensi antara kubelet, kube-apiserver, kube-scheduler, dan admission control dinyatakan secara eksplisit.
• Apakah node lama, status kedaluwarsa, pembaruan Pod, dan rollback feature-gate tercakup.
• Apakah keamanan ditunjukkan dengan kelengkapan deklarasi dan penolakan penjadwalan, bukan hanya keberhasilan proses startup.

Pertanyaan klarifikasi

• Versi kubelet mana yang menghasilkan kapabilitas tersebut, dan apakah node lama boleh tetap melayani Pod biasa?
• Apakah tujuannya hanya melindungi penempatan awal, atau juga pembaruan setelah Pod di-binding?
• Apakah ada custom scheduler, beberapa API server, atau control plane multi-region?
• Jika terjadi laporan palsu, apakah Pod baru harus berhenti sementara Pod yang ada tetap berjalan?

Jawaban 30 detik

Saya akan memperlakukan ini sebagai rantai fakta lintas-komponen: kubelet memublikasikan status.declaredFeatures, plugin scheduler menyimpulkan kebutuhan Pod di PreFilter dan memfilter node, dan validasi admission melindungi pembaruan berikutnya. Saya akan mengaktifkannya terlebih dahulu pada node pool yang dapat dibalik (reversible) dan sebagian kecil beban kerja, memverifikasi kesesuaian konfigurasi feature-gate di API server, scheduler, dan kubelet, lalu memperluasnya. Saya akan memantau kelengkapan laporan, alasan penolakan penjadwalan, penolakan pembaruan, dan ketimpangan versi. Setiap inkonsistensi akan menghentikan beban kerja yang memerlukan kapabilitas baru dan mempertahankan jalur penjadwalan biasa untuk Pod lainnya.

Solusi langkah demi langkah

1. Tentukan sumber kebenaran (source of truth). Saat startup, kubelet mendeteksi fitur terkelola dan menulisnya ke Node.status.declaredFeatures; label aplikasi tidaklah setara. Nama kapabilitas harus berasal dari feature gate terkelola atau kontrak komponen yang eksplisit.
2. Perjelas dependensi secara eksplisit. Kubernetes memerlukan gate NodeDeclaredFeatures pada kube-apiserver, kube-scheduler, dan kubelet. Verifikasi versi control-plane dan konfigurasinya sebelum meng-upgrade kubelet; mengaktifkan satu sisi saja akan membuat field yang tidak dikonsumsi siapa pun atau scheduler yang mengharapkan laporan yang tidak dapat dihasilkan oleh node.
3. Rancang jalur penjadwalan. Plugin scheduler menyimpulkan fitur yang diperlukan dari PodSpec di PreFilter dan membandingkannya dengan deklarasi node di Filter. Node tanpa deklarasi yang diperlukan tidak dapat dijadwalkan (unschedulable) untuk Pod tersebut. Custom scheduler yang menggunakan field ini harus mempertahankan semantik default dan kegagalan yang sama.
4. Lindungi jalur pembaruan. Admission controller NodeDeclaredFeatureValidator memeriksa pembaruan Pod terhadap node yang di-binding, mencegah pembaruan berikutnya melewati batasan kapabilitas. Tampilkan penolakan yang jelas alih-alih mengalami degradasi secara diam-diam.
5. Tangani ketimpangan versi (version skew). Kubelet lama mungkin menghilangkan field tersebut atau tidak mengenali kapabilitas baru. Perlakukan fitur yang tidak dideklarasikan sebagai tidak didukung, membiarkan Pod dependen berstatus pending sementara Pod biasa menggunakan node yang kompatibel. Jangan mengedit status Node secara manual untuk memotong ketimpangan versi.
6. Lakukan rollout secara bertahap. Aktifkan gate pada node pool yang dapat dibalik, tempatkan beban kerja probe yang memerlukan kapabilitas tersebut, dan perluas secara bertahap. Hentikan jika tingkat laporan yang hilang, penolakan penjadwalan, penolakan pembaruan Pod, atau latensi scheduler melebihi baseline.
7. Amati dan audit. Kumpulkan versi deklarasi node, digest dari kumpulan kapabilitas, alasan pemfilteran scheduler, alasan penolakan admission, dan sidik jari (fingerprint) konfigurasi gate, yang dikelompokkan berdasarkan pool dan versi Kubernetes. Hindari menulis objek Node lengkap ke dalam log dengan kardinalitas tinggi.
8. Lakukan rollback dengan cermat. Hentikan pembuatan Pod yang bergantung pada fitur tersebut, pulihkan penjadwalan biasa, dan tutup gate sesuai urutan komponen setelah pekerjaan dependen yang tertunda ditangani. Jika bisnis sudah bergantung pada kapabilitas tersebut, migrasikan beban kerja atau pertahankan node yang kompatibel sebelum menghilangkan deklarasi.

Jawaban model

Pertama, saya akan mengidentifikasi sumber kebenaran dan batas perlindungan. Kubelet memublikasikan status.declaredFeatures terkelola, plugin NodeDeclaredFeatures pada scheduler memfilter penempatan, dan NodeDeclaredFeatureValidator melindungi pembaruan setelah proses binding. Karena Kubernetes memerlukan gate pada kube-apiserver, scheduler, dan kubelet, saya akan menyelaraskan versi dan konfigurasi sebelum mengaktifkannya pada satu pool yang dapat dibalik. Sebuah probe Pod akan memverifikasi pelaporan kapabilitas dan penempatan; tingkat laporan yang hilang, penolakan filter, penolakan pembaruan, dan latensi penjadwalan menjadi kriteria batas perluasan (expansion gates). Node lama yang tidak mendeklarasikan fitur tersebut dianggap tidak didukung, sedangkan Pod biasa tetap menggunakan jalur lama. Untuk rollback, saya akan menghentikan beban kerja dependen baru, memigrasikan yang sudah ada, menutup gate, dan memastikan jumlah pending serta penjadwalan biasa pulih kembali.

Kesalahan umum

• Memperlakukan declaredFeatures sebagai label biasa → pengguna dapat memalsukan kapabilitas dan merusak keamanan penjadwalan → hanya terima set yang dikelola oleh kubelet.
• Mengaktifkan gate hanya di scheduler → node tidak memublikasikan field tersebut → periksa konfigurasi API server, scheduler, dan kubelet secara bersamaan.
• Memperlakukan "tidak dideklarasikan" sebagai didukung → node versi campuran dapat menerima Pod yang tidak kompatibel → tidak dideklarasikan berarti tidak didukung.
• Hanya menguji penempatan awal → pembaruan Pod dapat melewati batasan → aktifkan dan amati juga validasi admission.
• Mengaktifkannya di seluruh kluster sekaligus → kegagalan tidak dapat diatribusikan ke pool, versi, atau beban kerja tertentu → gunakan probe, tahapan bertahap, dan kondisi penghentian.
• Langsung menonaktifkan gate → Pod dependen dapat menjadi tidak dapat dipulihkan → hentikan pembuatan dan migrasikan beban kerja dependen terlebih dahulu.

Pertanyaan lanjutan dan tanggapan

Sebuah node melaporkan kapabilitas tetapi statusnya sudah usang (stale). Apa yang harus dilakukan scheduler?

Jadikan usia laporan sebagai sinyal operasional. Pod yang memerlukan fitur tersebut harus menunggu atau pindah ke node yang statusnya segar daripada bergantung pada deklarasi lama. Setelah batas kesegaran terlampaui, isolasi pool tersebut dan minta konfirmasi operator.

Apa yang bisa salah jika custom scheduler mengabaikan plugin resmi?

Scheduler tersebut mungkin mengizinkan Pod yang ditolak oleh scheduler default. Jalur kustom harus mengimplementasikan semantik PreFilter, Filter, default, dan versi yang setara; jalankan pengujian kesesuaian (conformance test) sebelum mengizinkan beban kerja memilihnya.

Bagaimana cara menghindari celah inkonsistensi konfigurasi saat tiga komponen mengubah gate?

Sertakan sidik jari konfigurasi dalam pemeriksaan rollout, pertahankan pelayanan beban kerja biasa, dan lakukan rollout melalui control plane, scheduler, dan node pool dalam urutan yang terkontrol. Setiap ketidaksesuaian akan menghentikan ekspansi; keberhasilan proses startup saja bukanlah bukti keberhasilan.

Bisnis sudah bergantung pada fitur tersebut, tetapi saat rollback ditemukan bahwa node lama tidak mendukungnya. Apa yang harus dilakukan?

Pertahankan pool node yang mendeklarasikan kapabilitas tersebut, migrasikan atau kurangi beban kerja dependen, dan baru setelah itu tutup gate. Jika migrasi tidak memungkinkan, jeda rollback dan tambahkan kapasitas yang kompatibel alih-alih menghapus batasan penjadwalan secara mendadak.