Gesaan dan skop
Migrasi mesti mengekalkan kod status, laluan, pengepala, dan pemilihan bahagian belakang (backend) yang diperhatikan secara luaran semasa beralih daripada sumber Ingress dan anotasi khusus pengawal kepada sumber Gateway API. Kemahiran teras ialah kejuruteraan keserasian pada sempadan proksi, jadi soalan ini tergolong dalam backend. Blog Kubernetes mendokumentasikan beberapa tingkah laku Ingress-NGINX yang mudah terlepas pandang, termasuk kesan regex merentasi hos, pengalihan tersirat, dan penormalan.
Perkara yang dinilai oleh penemu duga
Mencari inventori tingkah laku trafik sebenar dan bukannya sekadar latihan terjemahan YAML. Calon yang mantap memisahkan semantik Gateway API yang mudah alih daripada ungkapan nalar khusus pelaksanaan, mengenal pasti tingkah laku tersirat yang memerlukan penapis eksplisit, dan mencadangkan ujian pembezaan dengan rollback. Mereka juga harus membincangkan pemilikan, kebergantungan sijil dan pendengar (listener), kebolehcerapan, serta pertukaran DNS atau trafik secara berperingkat.
Soalan untuk dijelaskan terlebih dahulu
- Versi Ingress-NGINX, anotasi, pengawal Gateway API, dan tahap pematuhan yang manakah digunakan?
- Hos manakah yang menggunakan
use-regex,rewrite-target, auth, canary, atau coretan tersuai? - Adakah klien bergantung pada pengalihan 301, huruf besar/kecil laluan, tanda sengkang pendua, atau segmen berkod?
- Bolehkah Gateway baharu berjalan secara selari dan menerima trafik yang dicerminkan atau disampelkan?
- Siapakah yang memiliki sumber Gateway, HTTPRoute, dasar backend, dan TLS?
- Apakah pencetus rollback dan berapa cepatkah trafik boleh kembali ke pengawal lama?
Kerangka jawapan 30 saat
"Mula-mula saya akan menangkap inventori tingkah laku daripada manifes, log akses, dan probe kotak hitam. Saya akan menjana sumber Gateway API bagi setiap tingkah laku, memodelkan regex, penulisan semula, pengalihan, dan TLS secara eksplisit dan bukannya menganggap anotasi diterjemahkan secara automatik. Kemudian saya akan menjalankan ujian pembezaan terhadap pengawal lama dan baharu, membayangi atau melakukan canary pada trafik, membandingkan status, lokasi, backend yang dipilih, dan kependaman, serta memastikan rollback DNS atau penghalaan sentiasa bersedia. Hanya selepas sifar perbezaan yang tidak dapat dijelaskan barulah saya memigrasikan setiap hos."
Jawapan langkah demi langkah
Langkah 1: Buat inventori kontrak yang diperhatikan
Huraikan setiap hos dan laluan, tetapi sahkan dengan permintaan. Pemadanan regex Ingress-NGINX boleh menjadi tidak sensitif huruf besar/kecil dan berasaskan awalan, serta satu anotasi boleh menjejaskan semua laluan untuk sesuatu hos merentasi objek Ingress. Rekodkan pengalihan, laluan yang dinormalkan, pengepala, pengesahan, tamat masa, dan pilihan backend sebagai kontrak yang boleh diuji.
Langkah 2: Kelaskan tingkah laku mudah alih dan khusus pengawal
Petakan penghalaan hos/laluan biasa kepada Gateway dan HTTPRoute. Anggap pemadanan ungkapan nalar sebagai khusus pelaksanaan dan sahkan semantik pengawal yang dipilih. Tukarkan tingkah laku penulisan semula dan pengalihan kepada penapis HTTPRoute yang eksplisit jika disokong. Anotasi atau coretan yang tidak disokong menjadi penghalang migrasi dengan pemilik dan reka bentuk penggantian.
Langkah 3: Bina matriks ujian pembezaan
Bagi setiap kontrak, uji laluan biasa dan bermusuhan (adversarial): varian huruf besar/kecil, trailing slash, segmen . dan .., tanda sengkang pendua, aksara berkod, laluan yang hilang, dan kegagalan backend. Bandingkan status, Location, laluan yang diterima oleh backend, pengepala, perkhidmatan yang dipilih, dan badan ralat. Gunakan lekapan (fixtures) dan pengepala permintaan yang sama untuk kedua-dua pengawal.
Langkah 4: Buktikan kesediaan pengawal dan dasar
Semak syarat status Gateway dan HTTPRoute, lampiran pendengar, kesediaan sijil, dasar rujukan rentas ruang nama, dan sokongan pelaksanaan bagi setiap penapis. Sumber yang diterima oleh API bukanlah bukti bahawa satah data (dataplane) melaksanakan setiap ciri yang diminta.
Langkah 5: Canary dan rollback
Jalankan Gateway selari dengan hos kecil atau sebahagian kecil trafik. Cerminkan permintaan idempoten yang selamat jika boleh; jika tidak, mainkan semula lekapan yang telah dibersihkan. Batalkan jika terdapat perbezaan penghalaan yang tidak dapat dijelaskan, perubahan 4xx/5xx, hanyutan pengalihan, atau regresi kependaman. Kekalkan pengawal lama serta pemberat DNS atau trafik tanpa perubahan sehingga tempoh pemerhatian ditutup.
Jawapan model
"Saya akan menganggap tingkah laku Ingress-NGINX semasa sebagai kontrak luaran. Selepas menginventori manifes, anotasi, log, dan probe, saya akan memodelkan setiap kontrak secara eksplisit dalam sumber Gateway dan HTTPRoute. Regex, penulisan semula, pengalihan trailing-slash, dan penormalan URL memerlukan pengesahan khusus pengawal; beberapa tingkah laku tersirat mesti menjadi penapis eksplisit. Saya akan menjalankan matriks pembezaan yang merangkumi status, Location, laluan backend, pengepala, dan pemilihan perkhidmatan, kemudian melakukan canary dengan pemberat rollback. Syarat status Gateway dan tuntutan pematuhan adalah perlu tetapi tidak mencukupi, jadi saya akan mengekalkan bukti kotak hitam sebelum menukar DNS."
Kesilapan lazim
- Menterjemah YAML satu demi satu → anotasi mungkin membawa kesan tersembunyi merentasi hos → inventori tingkah laku masa jalanan dan ujinya.
- Menganggap
Exactbermaksud pemadanan yang serupa → pengawal lama mungkin mempunyai kesan sampingan regex atau penormalan → uji varian huruf besar/kecil, tanda sengkang, dan aksara berkod. - Bergantung pada status Accepted sumber → sokongan satah data mungkin masih tidak lengkap → semak syarat dan respons kotak hitam.
- Menukar DNS terlebih dahulu → rollback menjadi perlahan dan legap → lakukan canary pada trafik sementara laluan lama kekal tersedia.
- Mengabaikan laluan yang kelihatan di backend → penulisan semula boleh merosakkan aplikasi → sahkan laluan dan pengepala yang diterima oleh backend.
- Hanya menguji laluan gembira (happy paths) → gangguan tersembunyi dalam pengalihan dan URL yang tidak sah → sertakan lekapan negatif dan bermusuhan.
Soalan susulan
Susulan 1: Mengapakah migrasi regex boleh mengubah trafik?
Ingress-NGINX boleh menggunakan tingkah laku regex seperti awalan yang tidak sensitif huruf besar/kecil merentasi laluan untuk sesuatu hos. Ungkapan nalar Gateway API adalah khusus pelaksanaan, manakala Exact dan Prefix tidak bertukar menjadi regex secara senyap.
Susulan 2: Bagaimanakah anda mengekalkan pengalihan trailing-slash?
Modelkannya secara eksplisit dengan penapis pengalihan HTTP dan uji kedua-dua varian tanda sengkang. Jangan menganggap pelaksanaan Gateway menambah 301 lama secara automatik.
Susulan 3: Apakah isyarat rollback yang selamat?
Gunakan perbezaan yang tidak dapat dijelaskan dalam status, Location, laluan backend, pemilihan perkhidmatan, kadar ralat, atau kependaman, yang dinilai terhadap garis dasar tetap dan tempoh pemerhatian yang terhad.
Susulan 4: Apakah yang dibuktikan oleh perkakas migrasi?
Penukar boleh mempercepatkan inventori dan menghasilkan sumber calon, tetapi ia tidak dapat membuktikan semantik khusus pengawal, interaksi anotasi tersembunyi, atau keserasian aplikasi. Kekalkan ujian pembezaan sebagai pintu pelepasan (release gate).