Inventariați comportamentul înainte de a înlocui Ingress NGINX

Înlocuirea unui controler ingress schimbă programul care interpretează configurația de rutare. Un fișier convertit poate fi acceptat de Kubernetes, iar aplicația se poate comporta diferit. Începeți migrarea cu inventarul comportamentelor observabile de rutare și securitate, apoi alegeți o implementare întreținută care le poate păstra. Condiția de acceptare trebuie verificată la nivelul aplicației.

Privind din noiembrie 2026, anunțul de retragere din 11 noiembrie 2025 prevedea mentenanță în limita resurselor disponibile până în martie 2026 pentru Ingress NGINX al comunității. Preciza că instalările urmau să funcționeze în continuare, iar materialele de instalare să rămână disponibile după retragere. Era un termen pentru mentenanță, nu oprirea programată a rutelor tuturor utilizatorilor. Anunțul privea controlerul comunității Kubernetes, nu API-ul Ingress și nici toate produsele care folosesc NGINX.

Termenul istoric a trecut

O verificare actuală într-o sursă primară contează aici. Articolul Kubernetes datat 30 martie 2026, accesat în noiembrie 2026, afirmă că Ingress NGINX a fost retras la 24 martie 2026. El precizează încetarea lansărilor, corecțiilor și actualizărilor de securitate, în timp ce instalările existente continuă să funcționeze. Martie 2026 este, așadar, un moment trecut, nu o fereastră viitoare de planificare.

Confirmarea actuală nu inspectează clusterul cititorului. Identificați imaginea controlerului, pachetul Helm și organizația responsabilă de mentenanță înainte să decideți dacă anunțul vi se aplică. Numele asemănătoare pot ascunde implementări și condiții de suport diferite. O rută care încă răspunde nu dovedește mentenanță activă; retragerea comunității nu stabilește nici situația controlerului altui furnizor.

Notați responsabilitatea împreună cu dependența. Dacă furnizorul platformei administrează controlerul, întrebați ce implementare și versiune operează și ce cale de înlocuire susține. Dacă echipa aplicației îl administrează, includeți componenta în inventarul de mentenanță. O migrare fără responsabil poate lăsa ambele controlere în funcțiune, fără o asumare clară a întreținerii.

Descrieți comportamentul ascuns în adnotări

Începeți cu numele de gazdă importante și operațiile utilizatorilor care depind de ele. Notați potrivirea și rescrierea căilor, redirecționările, limitele dimensiunii cererilor și timpii de așteptare relevanți. O adnotare arată intenția configurației. Ea nu dovedește singură că înlocuitorul o interpretează identic sau că implementarea existentă o aplică acum așa cum vă așteptați.

Autentificarea cere o verificare separată. Identificați cum primește cererea serviciul extern de autentificare, ce antete transportă identitatea și cum se schimbă răspunsul la refuz sau la indisponibilitatea serviciului. Migrarea poate păstra rutarea reușită și totuși admite accidental o cerere care trebuia respinsă. Includeți cazuri permise și respinse în condițiile de acceptare propuse.

Tratați TLS către aplicație separat de certificatul văzut de browser. Conexiunea dintre gateway și aplicație are propriile cerințe privind numele de gazdă și încrederea. Notați identitatea de certificat acceptată, proveniența certificatelor de încredere și rezultatul unei validări eșuate. Copierea unui câmp legat de TLS nu dovedește echivalența verificării.

Aceștia sunt pași propuși pentru inventariere și verificare. Pentru articol nu s-au inspectat clustere și nu s-au executat verificări de autentificare sau certificate. Dovezile relevante trebuie să provină din configurația produsului și din comportamentul observat într-un mediu potrivit. Păstrați necunoscutele la vedere, fără să le transformați tacit în comportament implicit.

Gateway API definește funcții; implementările le execută

Articolul despre Gateway API 1.4 publicat la 6 noiembrie 2025 precizează că versiunea 1.4.0 fusese lansată la 6 octombrie 2025. Publicația din noiembrie explica o lansare din octombrie. Plasa BackendTLSPolicy și supportedFeatures din starea GatewayClass în canalul Standard, iar filtrul HTTPRoute externalAuth era experimental. Nivelurile diferite de maturitate contează pentru echivalența autentificării.

O funcție din specificație nu promite că fiecare versiune de controler o implementează. Comparați documentația pentru versiunea candidatului și informațiile despre conformitate cu funcția exactă de care aveți nevoie. O afirmație generală despre suportul Gateway API poate acoperi rutarea simplă și omite o anumită politică. Păstrați implementarea și versiunea împreună cu dovezile, pentru verificarea lor după actualizări.

Folosiți conversia configurației ca început al analizei. Fiecărui comportament vechi trebuie să-i corespundă un mecanism cu suport, o schimbare intenționată agreată cu responsabilul sau o problemă nerezolvată care blochează mutarea. Astfel, acceptarea sintaxei nu devine o falsă dovadă a migrării aplicației. Comparația arată și unde rămân necesare extensii proprii controlerului.

Alt controler Ingress poate cere o schimbare mai mică

Cel mai puternic contraargument față de migrarea imediată la Gateway API este practic: un alt controler Ingress întreținut poate păstra o parte mai mare din modul existent de operare. Retragerea unui controler nu obligă toate aplicațiile să-și reproiecteze simultan resursele de rutare. O implementare alternativă cu suport merită evaluată dacă îndeplinește cerințele.

Și alternativa cere verificări de comportament. Sintaxa Ingress comună nu face adnotările proprietare portabile, iar opțiunile cu nume similare nu stabilesc reguli echivalente de autentificare sau TLS. Comparați schimbarea totală și obligația de mentenanță, inclusiv extensiile și familiaritatea operatorilor. Mutarea mai mică ajută când dovezile arată că este mai mică pentru aplicația concretă.

Planificați transferul traficului și revenirea folosind aceleași cazuri de acceptare. Stabiliți ce oprește mutarea, cine poate restabili traseul anterior și cum rămâne compatibilă configurația păstrată. Revenirea ar trebui limitată în timp ținând cont de riscul cunoscut al componentei retrase. Este o opțiune de recuperare, nu un motiv pentru amânarea nelimitată a migrării.

Pentru mentenanță software, cereți un inventar al comportamentului și o recomandare de înlocuire legată de dovezi despre implementare. Propunerea ar trebui să arate ce rămâne echivalent, ce se schimbă intenționat și ce incertitudini blochează transferul traficului. Alegeți controlerul când comparația poate explica responsabilitățile de rutare și securitate ale aplicației.