Pertanyaan dan konteks
Kubernetes v1.36 mempromosikan Validasi Deklaratif ke GA dan mengaktifkan feature gate DeclarativeValidation secara default. Aturan ditulis sebagai penanda +k8s: di samping definisi tipe, lalu dihasilkan oleh validation-gen. Pertanyaan ini menguji apakah Anda dapat menghubungkan kontrak API, generator, kompatibilitas, dan operasi rilis.
Apa yang dievaluasi pewawancara
- Apakah Anda dapat menjelaskan risiko pemeliharaan dan konsistensi dalam validasi yang ditulis secara manual.
- Apakah Anda membedakan aturan deklaratif, kode yang dihasilkan, eksposur OpenAPI, dan penolakan runtime.
- Apakah Anda menjelaskan dengan benar bagaimana ambient ratcheting memengaruhi pembaruan pada objek lama.
- Apakah Anda merancang pengujian, rollback, dan migrasi bertahap sehingga aturan yang diperketat tidak merusak objek yang tersimpan.
Pertanyaan untuk diklarifikasi terlebih dahulu
Konfirmasikan apakah API adalah tipe bawaan Kubernetes atau CRD, apakah klien bergantung pada OpenAPI, dan apakah batasan tersebut baru, dilonggarkan, atau diperketat. Konfirmasikan juga apakah objek lama berisi nilai yang secara historis diterima dan versi generator, linter, serta server mana yang harus saling beroperasi.
Jawaban 30 detik
Validasi deklaratif menempatkan batasan di samping definisi tipe, memungkinkan satu generator menghasilkan kode yang konsisten, dan membuat aturan tersedia untuk OpenAPI. Rencana tersebut harus mencakup perancangan aturan, pembuatan dan pemeriksaan statis, validasi runtime server, kompatibilitas objek lama, dan rollback. Saat memperketat aturan, ambient ratcheting melindungi bidang lama yang tidak diubah, namun nilai baru tetap memerlukan tinjauan kompatibilitas dan validasi bertahap.
Penjelasan mendalam langkah demi langkah
1. Tentukan sumber aturan
Gunakan penanda seperti +k8s:required, +k8s:minimum=0, atau batasan enum sehingga aturan dapat ditemukan di samping bidang. Untuk invarian lintas bidang, dokumentasikan invarian, pesan kesalahan, dan versi yang didukung alih-alih menyembunyikan logika bisnis di luar generator.
2. Hasilkan dan verifikasi
validation-gen mem-parsing penanda, menghasilkan fungsi validasi Go, dan mendaftarkannya ke dalam skema API. CI menjalankan generator, pengujian unit, kube-api-linter, dan pemeriksaan perbedaan OpenAPI sehingga penanda, kode yang dihasilkan, dan skema publik tidak mengalami pergeseran (drift). File yang dihasilkan harus dapat direproduksi dan tidak boleh diedit secara manual.
3. Tangani evolusi versi
Evaluasi objek yang tersimpan dan perilaku klien sebelum menambahkan batasan. Ambient ratcheting membandingkan objek lama dan baru: jika suatu bidang secara semantik tidak berubah, aturan baru tidak memblokir pembaruan karena nilai lamanya; jika bidang berubah, aturan baru akan berlaku. Pengetatan tetap memerlukan alat migrasi, metrik audit, dan pesan kesalahan yang jelas.
4. Rilis dan rollback
Ukur tingkat penolakan dalam rangkaian kompatibilitas dan validasi bayangan (shadow validation) sebelum peluncuran bertahap. Pantau kode kesalahan API, versi sumber daya, dan upaya coba lagi (retries) klien. Jika tingkat kesalahan melonjak, lakukan rollback pada generator atau versi aturan sambil menjaga agar objek yang diterima tetap dapat dibaca. Feature gate GA yang diaktifkan secara default tidak menghilangkan pengujian migrasi.
Contoh jawaban yang kuat
Saya memperlakukan validasi sebagai kontrak API berversi. Penanda seperti +k8s: mengekspresikan batasan bidang, validation-gen menghasilkan kode Go yang dapat direproduksi, dan CI menggunakan pengujian unit, linter, dan perbedaan OpenAPI untuk menjaga ketiga tampilan tetap selaras. Invarian lintas bidang memerlukan pengujian khusus dan kesalahan yang stabil, dan file yang dihasilkan tidak boleh diedit secara manual.
Sebelum memperketat aturan, saya memutar ulang objek yang tersimpan dan mengukur perilaku klien. Ambient ratcheting hanya membebaskan nilai lama yang tidak berubah; begitu pengguna mengedit bidang tersebut, aturan baru akan berlaku, sehingga alat migrasi dan peluncuran bertahap tetap diperlukan. Setelah peluncuran, saya memantau tingkat penolakan, distribusi versi, dan upaya coba lagi, lalu melakukan rollback pada versi aturan jika diperlukan. GA menyediakan mekanisme terpadu, bukan pengganti tata kelola kompatibilitas.
Kesalahan umum
- Memperlakukan generator hanya sebagai alat pemformatan dan mengabaikan perannya dalam perilaku runtime server.
- Memperlakukan OpenAPI sebagai satu-satunya titik validasi sambil mengabaikan kode server yang dihasilkan dan kompatibilitas versi.
- Salah mengartikan ambient ratcheting sebagai pelonggaran permanen meskipun bidang yang diedit tetap menjalani validasi baru.
- Menambahkan aturan tanpa rencana migrasi, metrik peluncuran, atau jalur rollback untuk objek yang tersimpan.
Pertanyaan lanjutan dan tanggapan
Mengapa tidak terus menulis fungsi validasi secara manual?
Logika yang ditulis tangan tersebar, sulit ditemukan, dan rentan terhadap perilaku yang tidak konsisten di berbagai sumber daya. Penanda, generator, dan linter membuat aturan dapat ditinjau, dapat direproduksi, dan lebih mudah dipublikasikan melalui OpenAPI.
Apakah memperketat nilai minimum akan langsung merusak objek lama?
Pembaruan yang membiarkan bidang tidak berubah dapat mempertahankan nilai historisnya melalui ambient ratcheting. Pembuatan objek atau pengeditan bidang tersebut harus memenuhi aturan baru, sehingga klien yang membaca, menyalin, atau menulis ulang objek tetap memerlukan tinjauan.
Bagaimana Anda membuktikan bahwa kode yang dihasilkan tidak mengalami pergeseran?
Kunci versi generator di CI, jalankan pembuatan kode, dan gagalkan jika direktori kerja mengalami perubahan. Bandingkan OpenAPI, pengujian unit, dan perilaku penolakan end-to-end; tinjau diff yang dihasilkan sebelum meluncurkan peningkatan generator.