Perintah dan cakupan
Migrasi harus mempertahankan kode status, jalur, header, dan pemilihan backend yang teramati secara eksternal saat berpindah dari sumber daya Ingress dan anotasi khusus pengontrol ke sumber daya Gateway API. Keterampilan intinya adalah rekayasa kompatibilitas pada batas proksi, jadi pertanyaan ini termasuk dalam backend. Blog Kubernetes mendokumentasikan beberapa perilaku Ingress-NGINX yang mudah terlewatkan, termasuk efek regex di seluruh host, pengalihan implisit, dan normalisasi.
Hal yang dinilai pewawancara
Mencari inventaris perilaku lalu lintas aktual daripada sekadar latihan penerjemahan YAML. Kandidat yang kuat memisahkan semantik Gateway API yang portabel dari ekspresi reguler khusus implementasi, mengidentifikasi perilaku implisit yang memerlukan filter eksplisit, dan mengusulkan pengujian diferensial dengan kemampuan rollback. Mereka juga harus mendiskusikan kepemilikan, dependensi sertifikat dan listener, observabilitas, serta cutover DNS atau lalu lintas bertahap.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Versi Ingress-NGINX, anotasi, pengontrol Gateway API, dan tingkat kesesuaian (conformance) mana yang diterapkan?
- Host mana yang menggunakan
use-regex,rewrite-target, autentikasi, canary, atau cuplikan (snippet) kustom? - Apakah klien bergantung pada pengalihan 301, sensitivitas huruf besar/kecil pada jalur, garis miring ganda, atau segmen yang dienkode?
- Bisakah Gateway baru berjalan secara paralel dan menerima lalu lintas yang dicerminkan (mirrored) atau disampel?
- Siapa yang memiliki sumber daya Gateway, HTTPRoute, kebijakan backend, dan TLS?
- Apa pemicu rollback dan seberapa cepat lalu lintas dapat kembali ke pengontrol lama?
Kerangka jawaban 30 detik
“Pertama-tama, saya akan mengambil inventaris perilaku dari manifes, log akses, dan probe black-box. Saya akan menghasilkan sumber daya Gateway API per perilaku, secara eksplisit memodelkan regex, penulisan ulang, pengalihan, dan TLS alih-alih berasumsi anotasi akan langsung diterjemahkan. Kemudian saya akan menjalankan pengujian diferensial terhadap pengontrol lama dan baru, menerapkan lalu lintas bayangan atau canary, membandingkan status, lokasi, backend yang dipilih, dan latensi, serta menjaga rollback DNS atau perutean tetap siap. Hanya setelah tidak ada perbedaan yang tidak dapat dijelaskan, saya akan memigrasikan setiap host.”
Jawaban langkah demi langkah
Langkah 1: Menginventarisasi kontrak yang teramati
Urai setiap host dan jalur, tetapi verifikasi dengan permintaan nyata. Pencocokan regex Ingress-NGINX dapat bersifat tidak peka huruf besar/kecil (case-insensitive) dan berbasis prefiks, serta sebuah anotasi dapat memengaruhi semua jalur untuk suatu host di seluruh objek Ingress. Catat pengalihan, jalur yang dinormalisasi, header, autentikasi, batas waktu (timeout), dan pilihan backend sebagai kontrak yang dapat diuji.
Langkah 2: Mengklasifikasikan perilaku portabel dan khusus pengontrol
Petakan perutean host/jalur biasa ke Gateway dan HTTPRoute. Perlakukan pencocokan ekspresi reguler sebagai khusus implementasi dan verifikasi semantik pengontrol yang dipilih. Konversikan perilaku penulisan ulang dan pengalihan ke filter HTTPRoute eksplisit jika didukung. Anotasi atau cuplikan yang tidak didukung menjadi penghambat migrasi dengan pemilik dan rancangan pengganti.
Langkah 3: Membangun matriks pengujian diferensial
Untuk setiap kontrak, uji jalur normal dan merugikan (adversarial): varian huruf besar/kecil, trailing slash, segmen . dan .., garis miring ganda, karakter yang dienkode, rute yang hilang, dan kegagalan backend. Bandingkan status, Location, jalur yang diterima oleh backend, header, layanan yang dipilih, dan badan pesan kesalahan. Gunakan fixture dan header permintaan yang sama untuk kedua pengontrol.
Langkah 4: Membuktikan kesiapan pengontrol dan kebijakan
Periksa kondisi status Gateway dan HTTPRoute, lampiran listener, kesiapan sertifikat, kebijakan referensi lintas namespace, dan dukungan implementasi untuk setiap filter. Sumber daya yang diterima oleh API bukanlah bukti bahwa dataplane mengimplementasikan setiap fitur yang diminta.
Langkah 5: Canary dan rollback
Jalankan Gateway paralel dengan host kecil atau sebagian kecil lalu lintas. Cerminkan permintaan idempoten yang aman jika memungkinkan; jika tidak, putar ulang fixture yang telah disanitasi. Batalkan jika ada perbedaan perutean yang tidak dapat dijelaskan, perubahan 4xx/5xx, pergeseran pengalihan, atau regresi latensi. Biarkan pengontrol lama serta bobot DNS atau lalu lintas tidak berubah hingga jendela pengamatan ditutup.
Contoh jawaban
“Saya akan memperlakukan perilaku Ingress-NGINX saat ini sebagai kontrak eksternal. Setelah menginventarisasi manifes, anotasi, log, dan probe, saya akan memodelkan setiap kontrak secara eksplisit dalam sumber daya Gateway dan HTTPRoute. Regex, penulisan ulang, pengalihan trailing-slash, dan normalisasi URL memerlukan verifikasi khusus pengontrol; beberapa perilaku implisit harus menjadi filter eksplisit. Saya akan menjalankan matriks diferensial yang mencakup status, Location, jalur backend, header, dan pemilihan layanan, kemudian melakukan canary dengan bobot rollback. Kondisi status Gateway dan klaim kesesuaian diperlukan tetapi tidak cukup, jadi saya akan mempertahankan bukti black-box sebelum mengubah DNS.”
Kesalahan umum
- Menerjemahkan YAML satu per satu → anotasi dapat membawa efek tersembunyi di seluruh host → inventarisasi perilaku runtime dan uji.
- Mengasumsikan
Exactberarti pencocokan yang identik → pengontrol lama mungkin memiliki efek samping regex atau normalisasi → selidiki varian huruf besar/kecil, garis miring, dan karakter terenkode. - Mengandalkan status Accepted pada sumber daya → dukungan dataplane masih bisa belum lengkap → periksa kondisi dan respons black-box.
- Memotong DNS terlebih dahulu → rollback menjadi lambat dan tidak jelas → lakukan canary lalu lintas sementara jalur lama tetap tersedia.
- Mengabaikan jalur yang terlihat oleh backend → penulisan ulang dapat merusak aplikasi → pastikan jalur dan header yang diterima oleh backend.
- Hanya menguji jalur sukses (happy path) → pemadaman tersembunyi dalam pengalihan dan URL yang salah bentuk → sertakan fixture negatif dan merugikan.
Pertanyaan lanjutan
Lanjutan 1: Mengapa migrasi regex dapat mengubah lalu lintas?
Ingress-NGINX dapat menerapkan perilaku regex seperti prefiks yang tidak peka huruf besar/kecil di seluruh jalur untuk suatu host. Ekspresi reguler Gateway API bersifat khusus implementasi, sedangkan Exact dan Prefix tidak secara diam-diam berubah menjadi regex.
Lanjutan 2: Bagaimana Anda mempertahankan pengalihan trailing-slash?
Modelkan secara eksplisit dengan filter pengalihan HTTP dan uji kedua varian garis miring. Jangan berasumsi bahwa implementasi Gateway menambahkan 301 lama secara otomatis.
Lanjutan 3: Apa sinyal rollback yang aman?
Gunakan perbedaan yang tidak dapat dijelaskan dalam status, Location, jalur backend, pemilihan layanan, tingkat kesalahan, atau latensi, yang dievaluasi terhadap baseline tetap dan jendela pengamatan yang dibatasi.
Lanjutan 4: Apa yang dibuktikan oleh alat bantu migrasi?
Konverter dapat mempercepat inventarisasi dan menghasilkan sumber daya kandidat, tetapi konverter tidak dapat membuktikan semantik khusus pengontrol, interaksi anotasi yang tersembunyi, atau kompatibilitas aplikasi. Pertahankan pengujian diferensial sebagai gerbang rilis (release gate).