Proiectul comunitar Ingress NGINX a anunțat retragerea pentru martie 2026, fără versiuni noi sau remedieri de securitate după această dată. Pentru echipele care încă îl folosesc, migrarea este o prioritate operațională. Anunțul privește controllerul comunitar, nu toate produsele care au NGINX în nume, și nu înseamnă că API-ul Kubernetes Ingress a dispărut. Consultă anunțul oficial.
Provocarea reală este păstrarea comportamentului aplicațiilor atunci când înlocuiești componenta care primește traficul de producție. Abordează schimbarea ca pe o migrare de trafic, cu teste de acceptanță, responsabilități clare și o cale de recuperare.
Începe cu comportamentul, nu cu YAML-ul
Inventariază numele de gazdă, certificatele, clasele Ingress, serviciile backend și adnotările. Desemnează un responsabil pentru fiecare rută. Acordă atenție autentificării, rescrierii adreselor, expresiilor regulate, limitelor pentru cereri, timeout-urilor și modului de păstrare a IP-ului clientului.
O fișă utilă de migrare include comportamentul actual, soluția propusă, o cerere de test și răspunsul așteptat. De exemplu, un endpoint pentru încărcarea fișierelor trebuie să păstreze dimensiunea acceptată și timeout-ul; un endpoint privat trebuie să respingă în continuare cererile neautentificate.
Ingress NGINX are particularități de potrivire a rutelor care pot surprinde la migrare. Citește articolul Kubernetes despre comportamentele care trebuie verificate înainte să presupui că un manifest convertit este echivalent.
Separă responsabilitățile platformei de cele ale aplicației
Gateway API introduce resurse pentru responsabilități diferite. Echipa platformei alege controllerul și GatewayClass, gestionează listener-ele și TLS și stabilește ce rute se pot atașa. Echipele aplicațiilor gestionează resursele HTTPRoute pentru gazde, căi și backend-uri. Este necesar un controller care implementează aceste resurse; instalarea CRD-urilor nu creează singură un proxy funcțional.
Schema separă responsabilitățile de traseul cererii. Gateway și HTTPRoute sunt resurse de configurare; cererile trec prin proxy-ul controllerului, nu prin obiectele API Kubernetes.
Pune în funcțiune o singură rută
Exemplul presupune că ai instalat CRD-urile Gateway API și un controller compatibil, că există un Gateway edge în același namespace și că listener-ul său permite atașarea rutei. Serviciul catalog trebuie să expună portul 8080. Configurează separat listener-ul HTTPS și certificatul înainte de expunerea publică.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: catalog
namespace: storefront
spec:
parentRefs:
- name: edge
hostnames:
- shop.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /catalog
backendRefs:
- name: catalog
port: 8080
Regula potrivește prefixul /catalog, dar nu îl elimină. Dacă backend-ul așteaptă /, adaugă o rescriere acceptată explicit de implementare și testeaz-o. Ghidul de rutare HTTP explică referințele către Gateway și rutarea către backend-uri.
Testează noul endpoint înainte să modifici DNS-ul
Instalează noul controller lângă cel vechi, cu o adresă separată de load balancer. Trimite cereri direct către noua adresă, păstrând numele gazdei și numele de server pentru TLS:
curl --resolve shop.example.com:443:203.0.113.10 \
https://shop.example.com/catalog
Înlocuiește adresa de exemplu cu endpoint-ul nou. Verifică redirecționările, autentificarea eșuată, căile inexistente, încărcările și traficul WebSocket sau gRPC, dacă există. Verifică stările Accepted și ResolvedRefs, apoi răspunsurile reale: acceptarea configurației nu dovedește singură că aplicația funcționează.
Mută traficul folosind criterii măsurabile
Înainte de schimbare, stabilește rata de erori și latența acceptabile față de situația curentă. Redu din timp TTL-ul DNS, unde este cazul, și ține cont că anumite conexiuni și cache-uri pot supraviețui schimbării.
Începe cu o gazdă cu risc redus. Compară numărul cererilor, erorile TLS, erorile backend-ului și latența aplicației. Păstrează traseul vechi doar pentru o perioadă limitată de revenire, apoi elimină-l după drenarea traficului și trecerea testelor. Un controller retras din mentenanță nu trebuie să devină o rezervă permanentă.
Migrarea este încheiată când fiecare gazdă are un responsabil, traseul nou trece testele de comportament, dashboard-urile acoperă noul controller, iar instalarea veche și permisiunile inutile sunt eliminate.