Gesaan dan konteks
Sebuah kluster Kubernetes HA sedang melakukan peningkatan berperingkat (rolling upgrade) pada satah kawalannya daripada v1.35 ke v1.36. Sepanjang tempoh ini, kejadian kube-apiserver yang berbeza mungkin mengetahui versi sumber yang berbeza, jadi klien yang dihalakan ke pelayan yang lebih lama boleh menerima 404 yang mengelirukan bagi sumber yang sebenarnya wujud pada rakan setara (peer) yang lebih baharu. Reka bentuk dan terangkan cara Mixed Version Proxy harus menghalakan permintaan, mengehadkan kepercayaan, menyediakan kebolehlihatan, dan menyokong pengunduran. Bezakan tingkah laku Beta Kubernetes v1.36 daripada dasar kecondongan versi (version-skew policy) biasa.
Perkara yang dinilai oleh penemu duga
- Mengasingkan kecondongan versi, cache penemuan (discovery cache), dan keterlihatan API kepada domain kegagalan yang berbeza.
- Mengetahui bahawa proksi menghalakan permintaan sumber; ia tidak menggantikan penukaran API atau penghijrahan storan.
- Menerangkan penemuan rakan setara, pemajuan (forwarding), penyebaran identiti, dan pencegahan gelung (loop prevention).
- Merangkumi keselamatan naik taraf, kebolehkaaditan, had masa tamat (timeouts), percubaan semula (retries), dan pengunduran.
Soalan penjelasan untuk ditanya
- Adakah ini penggantian berguling dalam satu kluster atau penghijrahan rentas kluster? Andaikan satu kluster dengan beberapa pelayan API rakan setara.
- Adakah klien hanya menggunakan sumber terbina dalam Kubernetes, atau juga pelayan API agregat dan CRD? Sahkan liputan proksi untuk versi sumber yang tidak diketahui.
- Adakah pengimbang beban kongsi, mTLS, audit berpusat, dan metrik sudah tersedia? Perkara ini menentukan penyebaran identiti dan diagnosis.
- Apakah belanjawan untuk kependaman tambahan, ketidaktersediaan, dan masa pengunduran?
Rangka kerja jawapan 30 saat
Mulakan dengan kegagalan: semasa naik taraf berguling, pelayan API lama boleh tersilap menganggap versi sumber baharu sebagai sumber yang tiada. Kemudian berikan laluannya: pelayan API pintu masuk melakukan penemuan dan keputusan setempat; apabila versi tidak diketahui secara setempat, ia memajukan ke rakan setara yang serasi, mengembalikan respons rakan setara, status, dan identiti audit kepada pemanggil. Akhiri dengan sempadan: patuhi dasar kecondongan versi, larang gelung proksi, hadkan identiti proksi, kembalikan kegagalan pemajuan yang jelas, elakkan percubaan semula yang menyembunyikan kerosakan satah kawalan, dan undur semula melalui metrik serta suis ciri bertahap.
Perbincangan mendalam langkah demi langkah
1. Kelaskan permintaan dan tentukan sama ada hendak memajukan
Pelayan API menghuraikan kumpulan, versi, sumber, dan kata kerja (verb). Jika sumber didaftarkan secara setempat, ia mengikut pengesahan, pembenaran, kemasukan, dan storan setempat. Jika versi yang diminta tidak diketahui dalam penemuan setempat, pelayan menyemak rakan setara mana yang mengiklankan versi sumber tersebut. Ia memajukan hanya selepas rakan setara mengesahkan sokongan secara eksplisit; jika tidak, ia mengembalikan ralat yang boleh dibezakan. Proksi tidak boleh meneka versi atau menukar setiap 404 perniagaan biasa menjadi pencetus pemajuan.
2. Temui rakan setara, kekalkan identiti, dan hentikan gelung
Rakan setara harus datang daripada senarai keahlian satah kawalan yang terkawal atau mekanisme penemuan dalaman yang dipercayai. Sambungan menggunakan identiti perkhidmatan satah kawalan sedia ada dan saluran yang disulitkan. Permintaan yang dimajukan membawa identiti pengguna asal, kumpulan, pengepala pembenaran, dan konteks audit, manakala proksi masih menguatkuasakan sempadan pembenarannya sendiri. Tambahkan penanda lompatan (hop marker) atau metadata dalaman yang setara; pelayan yang melihat penanda tersebut tidak boleh memajukan lagi, bagi menghalang gelung A-ke-B-ke-A.
3. Kendalikan ketekalan dan kegagalan
Operasi baca boleh memerhatikan cache penemuan yang berbeza seketika merentasi pelayan API, jadi klien harus bergantung pada versi sumber pelayan dan resourceVersion. Pemajuan berlaku hanya apabila sasaran boleh dicapai dan serasi dari segi versi; had masa tamat, penolakan, atau respons ketidakpadanan versi akan gagal cepat (fail fast) dengan sebab yang direkodkan. Jangan gunakan percubaan semula tanpa had pada operasi tulis, yang boleh menduplikasi kesan sampingan. Jika percubaan semula diperlukan, gunakan kunci kedap kuasa (idempotency key) atau dasar percubaan semula klien yang eksplisit.
4. Lancarkan, perhatikan, dan undur semula
Naik taraf satu pelayan API di luar waktu puncak, kemudian pantau kadar ketepatan proksi, kependaman pemajuan, ralat versi tidak diketahui, respons 5xx, kelengkapan audit, dan penumpuan penemuan sebelum mengembangkan kelompok. Mixed Version Proxy bertaraf Beta dan didayakan secara lalai dalam v1.36, tetapi itu tidak menghapuskan keperluan untuk mengesahkan matriks kecondongan versi pengedaran. Jika isyarat merosot, hentikan penggantian, kekalkan trafik pada rakan setara yang diketahui serasi, dan jika disokong, lumpuhkan pintu ciri (feature gate) serta undurkan satah kawalan. Kekalkan rantaian pemajuan dan identiti asal dalam rekod audit.
Contoh jawapan model
Saya akan menganggap Mixed Version Proxy sebagai lapisan keserasian satah kawalan sementara, bukan sebagai get laluan API yang baharu. Pelayan pintu masuk mengesahkan, membenarkan, dan mengelaskan permintaan. Sumber yang diketahuinya secara setempat mengikut laluan setempat; versi sumber yang tidak diketahui secara setempat dimajukan hanya apabila rakan setara mengiklankannya secara eksplisit. Sambungan menggunakan identiti satah kawalan sedia ada, membawa konteks pengguna asal dan audit, serta menambahkan penanda satu lompatan untuk mengelakkan gelung. Status rakan setara dan semantik respons dikekalkan. Had masa tamat akan gagal cepat, dan operasi tulis tidak menerima percubaan semula automatik tanpa had.
Saya akan mengesahkan laluan tersebut dengan naik taraf bertahap: rekodkan ketepatan setempat, ketepatan proksi, versi sasaran, kependaman, kelas ralat, dan ID korelasi audit. Jeda kelompok apabila kadar ketepatan atau 5xx melebihi ambang. Pengaktifan Beta secara lalai dalam v1.36 bukan pengganti kepada semakan dasar kecondongan pengedaran atau liputan API agregat dan CRD. Pengunduran bermaksud menghentikan penggantian, memulihkan set ahli satah kawalan, melumpuhkan pintu ciri jika disokong, dan menyemak cache penemuan supaya klien tidak terus menggunakan keupayaan lapuk.
Kesilapan biasa
- Menggambarkan proksi sebagai penukar versi API sewenang-wenangnya dan bukannya laluan untuk versi sumber yang tidak diketahui.
- Hanya menyebut "majukan ke nod yang lebih baharu" tanpa penemuan rakan setara, penyebaran identiti, atau perlindungan gelung.
- Memajukan setiap 404, menjadikan sumber yang benar-benar tiada sebagai trafik satah kawalan.
- Mencuba semula operasi tulis tanpa syarat dan mewujudkan kesan sampingan pendua.
- Hanya memerhatikan kependaman purata sambil terlepas pandang penumpuan penemuan, integriti audit, atau kekangan kecondongan.
Soalan susulan dan respons
Soalan susulan 1: Bolehkah pelayan API agregat atau CRD diproksikan secara automatik?
Sahkan sama ada sumber tersebut berada dalam skop Mixed Version Proxy yang dilaksanakan. Pelayan API agregat mempunyai sempadan penemuan, pengesahan, dan ketersediaan yang bebas; sokongan untuk sumber terbina dalam tidak membayangkan sokongan untuknya. Berikan matriks keupayaan dan laluan gagal-cepat yang eksplisit untuk sumber yang tidak disokong.
Soalan susulan 2: Bagaimanakah anda menghalang pemajuan daripada memburukkan lagi gangguan satah kawalan?
Gunakan penanda satu lompatan, batas masa (deadlines), had keserentakan, dan pemutus litar (circuit breaker). Jangan cuba semula tanpa henti pada punca. Berikan amaran tentang kadar ketepatan proksi, ralat sasaran, dan kedalaman giliran, serta benarkan pengawal naik taraf menjeda kelompok apabila isyarat tersebut melangkaui ambang.
Soalan susulan 3: Bagaimana jika cache penemuan klien sudah lapuk?
Klien masih mengikut peraturan penemuan dan kecondongan versi Kubernetes. Pemajuan sebelah pelayan boleh mengurangkan 404 palsu semasa naik taraf berguling; ia tidak boleh menyimpan cache sumber baharu secara kekal untuk klien atau menggantikan penghijrahan versi API. Minta klien menemui semula dan menggunakan versi API eksplisit apabila perlu.