Ingress-NGINX పదవీ విరమణ చేసింది: కుబెర్నెటెస్ బృందాలు తర్వాత ఏమి చేయాలి

Ingress-NGINX మార్చి 2026లో పదవీ విరమణ చేసింది. ఇప్పటికే ఉన్న ఇన్‌స్టాలేషన్‌లు ఇంకా పనిచేస్తున్నాయి, కానీ ఇకపై ఫిక్స్‌లు అందుకోవు. కంట్రోలర్, Ingress API మరియు Gateway APIని గందరగోళపరచకుండా సురక్షితమైన మైగ్రేషన్‌ను ఎలా ప్లాన్ చేయాలో ఇక్కడ ఉంది.

ఈ భాషల్లో చదవండి: English · తెలుగు · हिन्दी

Three boxes: retired Ingress-NGINX, Inventory & capture, and Gateway API, connected left to right by arrows

మీ ఇంగ్రెస్ కంట్రోలర్ ఇప్పటికీ సాధారణంగా ట్రాఫిక్‌ను రూట్ చేస్తూనే ఉండవచ్చు, కానీ దాన్ని రక్షిస్తున్న ప్రాజెక్ట్ ఆగిపోయింది. మైగ్రేషన్ అంటే YAML ను మార్చడం మాత్రమే కాదు.

ఇది ఇప్పటికీ పనిచేస్తోంది—అందుకే దీన్ని వాయిదా వేయడం సులభం

మీ Kubernetes అప్లికేషన్లు సాధారణంగా స్పందిస్తున్నాయి. TLS సర్టిఫికెట్లు రెన్యూ అవుతున్నాయి. రూట్లు ఇప్పటికీ సరైన Service లకు ట్రాఫిక్‌ను పంపిస్తున్నాయి. మీ ఇంగ్రెస్ లేయర్ గడువు ముగిసిందని డాష్‌బోర్డ్‌లో ఏదీ చెప్పదు.

కానీ ఆ రూట్లు Kubernetes కమ్యూనిటీ యొక్క Ingress-NGINX కంట్రోలర్పై ఆధారపడి ఉంటే, ఆ సాఫ్ట్‌వేర్ ఇప్పుడు రిటైర్ అయ్యింది. ప్రాజెక్ట్ రిపోజిటరీ 24 మార్చి 2026 న ఆర్కైవ్ చేయబడింది. ఇకపై కొత్త రిలీజ్‌లు, బగ్ ఫిక్స్‌లు లేదా సెక్యూరిటీ ప్యాచ్‌లు రావు.

ఉన్న ఇన్‌స్టాలేషన్లు రిమోట్‌గా డిజేబుల్ చేయబడలేదు. ఇమేజ్‌లు మరియు Helm చార్ట్‌లు ఇప్పటికీ అందుబాటులో ఉన్నాయి. ఇది ఆపరేషనల్ కంటిన్యూటీకి ఉపయోగకరమే, కానీ ఇది ఒక ప్రమాదకరమైన అభిప్రాయాన్ని కూడా సృష్టిస్తుంది: కంట్రోలర్ ఇప్పటికీ నడుస్తున్నందున, మైగ్రేషన్ వేచి ఉండవచ్చు అనే భావన.

రిస్క్ అంటే తక్షణ షట్‌డౌన్ కాదు. తదుపరి వల్నరబిలిటీని ఇక మెయింటెయినర్లు ఫిక్స్ చేయని ఒక కాంపోనెంట్ ద్వారా ఇంటర్నెట్ ట్రాఫిక్‌ను నడపడం కొనసాగించడమే రిస్క్.

మొదట, ఒకేలా వినిపించే మూడు విషయాలను వేరు చేయండి

Kubernetes నెట్‌వర్కింగ్ చాలా పోలిన పేర్లను వాడుతున్నందున రిటైర్‌మెంట్ ప్రకటనను తప్పుగా అర్థం చేసుకోవడం సులభం.

పేరుఇది ఏమిటిప్రస్తుత స్థితి
Ingress APIప్రాథమిక HTTP మరియు HTTPS రూటింగ్‌ను వివరించడానికి ఒక స్థిరమైన Kubernetes రిసోర్స్రిటైర్ కాలేదు లేదా డిప్రికేట్ కాలేదు
Ingress-NGINXIngress రిసోర్స్‌లను మరియు NGINX-నిర్దిష్ట ఎనోటేషన్‌లను నడుస్తున్న ప్రాక్సీ కాన్ఫిగరేషన్‌గా మార్చే Kubernetes-కమ్యూనిటీ కంట్రోలర్24 మార్చి 2026 న రిటైర్ అయ్యింది
NGINX Ingress ControllerF5 నిర్వహించే ఒక వేరే కంట్రోలర్ఒక వేరే ఉత్పత్తి; Kubernetes రిటైర్‌మెంట్ దీనికి వర్తించదు
Gateway APIKubernetes నెట్‌వర్కింగ్ రిసోర్స్‌లు మరియు కన్ఫార్మెన్స్ నియమాల యొక్క కొత్త సెట్కొత్త డిజైన్‌లకు మరియు అనేక మైగ్రేషన్‌లకు సిఫారసు చేయబడిన దిశ

ఒక Ingress రిసోర్స్ కేవలం ఒక డిక్లరేషన్ మాత్రమే. ఒక కంట్రోలర్ ఆ డిక్లరేషన్‌ను చదివి వాస్తవ ట్రాఫిక్-హ్యాండ్లింగ్ సాఫ్ట్‌వేర్‌ను కాన్ఫిగర్ చేస్తుంది. ఒక కంట్రోలర్‌ను రిటైర్ చేయడం Kubernetes నుండి Ingress API ని తీసివేయదు.

Gateway API కూడా తనంతట తానే ఒక కంట్రోలర్‌ను ఇవ్వదు. ఇది GatewayClass, Gateway మరియు HTTPRoute వంటి రిసోర్స్‌లను నిర్వచిస్తుంది. మీకు కావాల్సిన ఫీచర్లు మరియు ఆపరేటింగ్ మోడల్‌కు మద్దతు ఇచ్చే ఒక ఇంప్లిమెంటేషన్‌ను మీరు ఇప్పటికీ ఎంచుకోవాలి.

YAML ను మార్చడం ఎందుకు సరిపోదు

Ingress-NGINX సాపేక్షంగా చిన్నదైన Ingress API తో మొదలై, ఆ తర్వాత ఎనోటేషన్‌లు, ConfigMap లు మరియు కస్టమ్ రిసోర్స్‌ల ద్వారా ఏళ్ల తరబడి కంట్రోలర్-నిర్దిష్ట ప్రవర్తనను పోగుచేసుకుంది.

రెండు క్లస్టర్లు ఒకేలా కనిపించే Ingress రిసోర్స్‌లను కలిగి ఉండవచ్చు కానీ ఈ కింది సెట్టింగ్‌ల వల్ల భిన్నంగా ప్రవర్తించవచ్చు:

  • పాత్ రీరైట్‌లు మరియు రెగ్యులర్ ఎక్స్‌ప్రెషన్‌లు;
  • రిక్వెస్ట్ మరియు కనెక్షన్ టైమ్‌అవుట్‌లు;
  • గరిష్ట రిక్వెస్ట్-బాడీ పరిమాణం;
  • HTTP-నుండి-HTTPS రీడైరెక్ట్‌లు;
  • సోర్స్-IP హ్యాండ్లింగ్;
  • ప్రామాణీకరణ మరియు రేట్ లిమిట్‌లు;
  • కస్టమ్ NGINX కాన్ఫిగరేషన్ స్నిప్పెట్‌లు;
  • TLS పాస్‌త్రూ మరియు సర్టిఫికెట్ ప్లేస్‌మెంట్.

వీటిలో కొన్నింటికి స్టాండర్డ్ Gateway API సమానులు ఉన్నాయి. కొన్నింటికి ఇంప్లిమెంటేషన్-నిర్దిష్ట పాలసీ రిసోర్స్‌లు అవసరం. మిగతావి కాపీ చేయడం కంటే మళ్లీ ఆలోచించాల్సినవి.

ఉదాహరణకు, Ingress-NGINX రెగ్యులర్-ఎక్స్‌ప్రెషన్ మ్యాచ్‌లు కేస్-ఇన్సెన్సిటివ్ ప్రిఫిక్స్ మ్యాచ్‌లు కావచ్చని Kubernetes మైగ్రేషన్ మార్గదర్శకత్వం హెచ్చరిస్తుంది. కాబట్టి బృందం వాస్తవ ప్రవర్తనను పరీక్షించకపోతే యాంత్రికంగా అనువదించిన రూట్ వేర్వేరు పాత్‌లను అంగీకరించవచ్చు. బాడీ-సైజ్ పరిమితులు, URL నార్మలైజేషన్ మరియు కస్టమ్ కాన్ఫిగరేషన్ స్నిప్పెట్‌లకు కూడా పోర్టబుల్ వన్-టు-వన్ మ్యాపింగ్ ఉండకపోవచ్చు.

మైగ్రేట్ చేయాల్సినది మ్యానిఫెస్ట్ కాదు. అది ట్రాఫిక్ ప్రవర్తన.

A safe Ingress-NGINX migration path A six-stage path moves from an existing retired Ingress-NGINX deployment through inventory, behaviour capture, target selection, assisted translation, parallel validation and controlled cutover. Migrate the behaviour, not only the YAML Retired Ingress-NGINXStill routes traffic; no future fixes 1. InventoryClusters, routes, annotations, integrations 2. Capture behaviourRoutes, redirects, TLS, limits, failures 3. Choose targetController, conformance, policies, ownership 4. Translate and reviewUse Ingress2Gateway; resolve every warning 5. Run in parallelCompare behaviour and failure paths 6. Shift traffic, observe, then removeGradual cutover · tested rollback · uninstall old controller
బొమ్మ 1. మైగ్రేషన్‌కు ప్రారంభమైనా, ముగింపు అయినా కాకుండా, కన్వర్షన్‌ను దాని మధ్య దశగా పరిగణించండి.

Gateway API అనేది ఒక దిశ, ఉత్పత్తి ఎంపిక కాదు

Gateway API అసలైన Ingress మోడల్‌లోని అనేక పరిమితులను మెరుగుపరుస్తుంది. ఇది ఇన్‌ఫ్రాస్ట్రక్చర్ యాజమాన్యాన్ని అప్లికేషన్ రూటింగ్ నుండి వేరు చేస్తుంది, షేర్డ్ క్లస్టర్‌లకు స్పష్టమైన అనుమతి మోడల్‌ను అందిస్తుంది మరియు ప్రతి ఎక్స్‌టెన్షన్‌ను ఎనోటేషన్‌ల లోపల ఉంచకుండానే మరింత సమృద్ధమైన రూటింగ్‌కు మద్దతు ఇస్తుంది.

అది ప్రతి Gateway API ఇంప్లిమెంటేషన్‌ను సమానం చేయదు. ఇంప్లిమెంటేషన్‌లు వేర్వేరు రూట్ టైప్‌లు, ఐచ్ఛిక ఫీచర్లు మరియు పాలసీ ఎక్స్‌టెన్షన్‌లకు మద్దతు ఇవ్వవచ్చు. Gateway API ప్రాజెక్ట్ కన్ఫార్మెన్స్ ఫలితాలను ప్రచురిస్తుంది, కానీ కన్ఫార్మెన్స్ ప్రతి సాధ్యమైన ఫీచర్‌కు కాకుండా ఒక నిర్దిష్ట ప్రొఫైల్ మరియు రూట్ టైప్‌కు వర్తించవచ్చు.

ఒక కంట్రోలర్‌ను ఎంచుకునే ముందు, మీ వర్క్‌లోడ్‌లకు ఏమి అవసరమో పోల్చండి:

అవసరంనిర్ధారించుకోవాల్సిన ప్రశ్న
HTTP రూటింగ్ఇంప్లిమెంటేషన్ ప్రస్తుత Gateway + HTTPRoute కన్ఫార్మెన్స్‌ను పాస్ చేస్తుందా?
TLSసర్టిఫికెట్‌లు ఎక్కడ నిల్వ చేయబడతాయి, మరియు TLS టర్మినేట్ అవుతుందా లేదా పాస్‌త్రూ అవుతుందా?
ప్రామాణీకరణఇది స్టాండర్డా, ఇంప్లిమెంటేషన్-నిర్దిష్ట పాలసీనా లేదా బాహ్య సర్వీసా?
ట్రాఫిక్ పాలసీటైమ్‌అవుట్‌లు, రిట్రైలు, బాడీ లిమిట్‌లు మరియు రేట్ లిమిట్‌లు ఎలా వ్యక్తీకరించబడతాయి?
మల్టీ-టీమ్ యాజమాన్యంప్లాట్‌ఫారమ్ మరియు అప్లికేషన్ బృందాలు వేర్వేరు రిసోర్స్‌లను సురక్షితంగా నిర్వహించగలవా?
ఆపరేషన్లుఅప్‌గ్రేడ్‌లు, లాగ్‌లు, మెట్రిక్‌లు, ట్రేసింగ్ మరియు రోల్‌బ్యాక్ ఎలా నిర్వహించబడతాయి?
పోర్టబిలిటీడిజైన్‌లో ఏ భాగాలు ఒకే కంట్రోలర్ ఎక్స్‌టెన్షన్‌లపై ఆధారపడి ఉన్నాయి?

సరైన లక్ష్యం ఒక మేనేజ్డ్ క్లౌడ్ Gateway కంట్రోలర్, Envoy Gateway, Traefik, Istio లేదా మరో కన్ఫార్మెంట్ ఇంప్లిమెంటేషన్ కావచ్చు. తక్షణ Gateway API మైగ్రేషన్ ఆచరణాత్మకంగా లేనప్పుడు ఇది మరో మెయింటెయిన్డ్ Ingress కంట్రోలర్ కూడా కావచ్చు. రిటైర్‌మెంట్ మీకు అన్‌సపోర్టెడ్ సాఫ్ట్‌వేర్‌ను వదిలిపెట్టమని చెబుతుంది; అది ప్రతి క్లస్టర్‌కు ఒకే గమ్యం సరైనదని చేయదు.

సురక్షితమైన మైగ్రేషన్ క్రమం

1. Ingress-NGINX నిజంగా ఎక్కడ వాడుతున్నారో కనుగొనండి

క్లస్టర్‌లు, కంట్రోలర్ వెర్షన్‌లు, Helm రిలీజ్‌లు, IngressClass ఆబ్జెక్ట్‌లు, Ingress రిసోర్స్‌లు, ఎనోటేషన్‌లు, ConfigMap లు, స్నిప్పెట్‌లు, TCP/UDP ఎక్స్‌పోజర్ మరియు cert-manager లేదా ExternalDNS వంటి ఇంటిగ్రేషన్‌లను ఇన్వెంటరీ చేయండి. నాన్-ప్రొడక్షన్ మరియు డిజాస్టర్-రికవరీ క్లస్టర్‌లను చేర్చండి; మర్చిపోయిన క్లస్టర్‌లు తరచుగా చివరిగా మైగ్రేట్ చేయబడతాయి.

2. రీప్లేస్‌మెంట్‌ను ఎంచుకునే ముందు ప్రవర్తనను రికార్డ్ చేయండి

ప్రతి ముఖ్యమైన రూట్‌కు, హోస్ట్‌లు, పాత్‌లు, రీడైరెక్ట్‌లు, హెడర్‌లు, ప్రామాణీకరణ, టైమ్‌అవుట్‌లు, బాడీ లిమిట్‌లు, TLS ప్రవర్తన మరియు వైఫల్య ప్రతిస్పందనలను క్యాప్చర్ చేయండి. ఈ ప్రవర్తన కోసం టెస్ట్‌లను జోడించండి. కాన్ఫిగరేషన్ మాత్రమే కంట్రోలర్ ప్రవేశపెట్టిన డిఫాల్ట్‌లను వెల్లడించకపోవచ్చు.

3. లక్ష్య ఇంప్లిమెంటేషన్‌ను ఎంచుకోండి

తక్షణ లక్ష్యం మరో మెయింటెయిన్డ్ Ingress కంట్రోలరా లేదా Gateway API ఇంప్లిమెంటేషనా అని నిర్ణయించండి. కన్ఫార్మెన్స్, ప్లాట్‌ఫారమ్ మద్దతు, ఎక్స్‌టెన్షన్‌లు, ఆపరేషనల్ యాజమాన్యం మరియు ప్రవర్తనను మార్చే ఖర్చును మూల్యాంకనం చేయండి.

4. Ingress2Gateway ను ఒక సహాయకుడిగా వాడండి

Kubernetes SIG Network యొక్క Ingress2Gateway 1.0 సాధారణ Ingress-NGINX ఎనోటేషన్‌లను అనువదించగలదు మరియు అది వ్యక్తీకరించలేని కాన్ఫిగరేషన్ గురించి హెచ్చరించగలదు. ఇది 30 కంటే ఎక్కువ సాధారణ ఎనోటేషన్‌లకు మద్దతు ఇస్తుంది మరియు వాస్తవ కంట్రోలర్‌లపై అనువాదాలను పరీక్షిస్తుంది.

దాని సొంత డాక్యుమెంటేషన్ స్పష్టంగా చెబుతుంది: ఇది ఒక మైగ్రేషన్ సహాయకుడు, వన్-షాట్ రీప్లేస్‌మెంట్ కాదు. ప్రతి హెచ్చరికను పరిష్కరించని పనిగా పరిగణించండి. చెల్లుబాటు అయ్యే Gateway API YAML ఉత్పత్తి అయ్యిందని మాత్రమే హెచ్చరికలను వదిలిపెట్టవద్దు.

5. రెండు మార్గాలను నడిపి ఫలితాలను పోల్చండి

ఉన్న మార్గం పక్కనే కొత్త కంట్రోలర్ మరియు రూట్‌లను డిప్లాయ్ చేయండి. సాధారణ ట్రాఫిక్, వైఫల్య కేసులు, పెద్ద రిక్వెస్ట్‌లు, రీడైరెక్ట్‌లు, దీర్ఘకాలం నడిచే రిక్వెస్ట్‌లు, క్లయింట్ IP లు మరియు సర్టిఫికెట్ ప్రవర్తనను పరీక్షించండి. తర్వాత వెయిటెడ్ DNS, లోడ్-బ్యాలెన్సర్ నియంత్రణలు లేదా మద్దతు ఉన్న ట్రాఫిక్ స్ప్లిటింగ్‌ను వాడి క్రమంగా ట్రాఫిక్‌ను తరలించండి.

కొత్త రూట్ వాస్తవ ట్రాఫిక్‌ను మరియు తగిన పరిశీలన కాలాన్ని తట్టుకునే వరకు పరీక్షించిన రోల్‌బ్యాక్ మార్గాన్ని ఉంచుకోండి.

6. పాత కంట్రోలర్‌ను పూర్తిగా తీసివేయండి

కటోవర్ తర్వాత, పాత Ingress రిసోర్స్‌లు, అడ్మిషన్ కాంపోనెంట్‌లు, కంట్రోలర్ వర్క్‌లోడ్‌లు, సర్వీస్ ఖాతాలు, క్లస్టర్ రోల్‌లు, ConfigMap లు, Service లు మరియు లోడ్ బ్యాలెన్సర్‌లను తీసివేయండి. వాడని ఇంటర్నెట్-ఫేసింగ్ కంట్రోలర్‌ను ఇన్‌స్టాల్ చేసి ఉంచడం అటాక్ సర్ఫేస్‌ను మరియు ఆపరేషనల్ గందరగోళాన్ని కొనసాగిస్తుంది.

బృందాలు ఈ వారం ఏమి చేయాలి?

ఫ్యాషనబుల్ రీప్లేస్‌మెంట్‌ను ఇన్‌స్టాల్ చేయడంతో మొదలుపెట్టవద్దు. సాక్ష్యంతో మొదలుపెట్టండి.

ప్రతి క్లస్టర్‌లో ఒక ఇన్వెంటరీ నడిపి ఈ ప్రశ్నలకు సమాధానం ఇవ్వండి:

  1. మనం రిటైర్ అయిన Kubernetes Ingress-NGINX కంట్రోలర్‌ను నడుపుతున్నామా?
  2. ఏ ఇంటర్నెట్-ఫేసింగ్ సర్వీసులు దీనిపై ఆధారపడి ఉన్నాయి?
  3. ప్రాథమిక Ingress రిసోర్స్ చూపని ప్రవర్తనను ఏ ఎనోటేషన్‌లు లేదా కస్టమ్ కాన్ఫిగరేషన్ నిర్వచిస్తాయి?
  4. మైగ్రేషన్‌కు ఎవరు యజమాని మరియు లక్ష్య తేదీ ఏమిటి?
  5. ట్రాఫిక్ తరలించే ముందు రీప్లేస్‌మెంట్ సరిగ్గా ప్రవర్తిస్తుందని మనం ఎలా నిరూపిస్తాం?

సమాధానాలు అసంపూర్ణంగా ఉంటే, Ingress-NGINX ను ఒక అన్‌సపోర్టెడ్ ప్లాట్‌ఫారమ్ డిపెండెన్సీగా రికార్డ్ చేసి మైగ్రేషన్‌కు యజమానిని ఇవ్వండి. పనిచేస్తున్న కంట్రోలర్ అనేది సపోర్టెడ్ కంట్రోలర్‌కు సమానం కాదు.

తెలుసుకోవాలా, వాడాలా లేదా నైపుణ్యం సాధించాలా?

తెలుసుకోవాలి: Ingress API, Ingress-NGINX మరియు Gateway API వేర్వేరు విషయాలని డెవలపర్లు అర్థం చేసుకోవాలి. తమ సర్వీసులు ఏ రూటింగ్ ప్రవర్తనలపై ఆధారపడి ఉన్నాయో అప్లికేషన్ బృందాలు తెలుసుకోవాలి.

వాడాలి: ప్లాట్‌ఫారమ్ మరియు DevOps ఇంజినీర్లు ఎనోటేషన్‌లను ఇన్వెంటరీ చేసి, ఇంప్లిమెంటేషన్‌లను మూల్యాంకనం చేసి, రూట్‌లను అనువదించి, పారలల్ వాతావరణాల్లో ప్రవర్తనను పరీక్షించాలి.

నైపుణ్యం సాధించాలి: షేర్డ్ క్లస్టర్‌లకు బాధ్యత వహించే ప్లాట్‌ఫారమ్ ఆర్కిటెక్ట్‌లు GatewayClass, Gateway, రూట్ యాజమాన్యం, పాలసీ అటాచ్‌మెంట్, కన్ఫార్మెన్స్ ధ్రువీకరణ మరియు కంట్రోలర్ లైఫ్‌సైకిల్ గవర్నెన్స్‌ను డిజైన్ చేయాలి.

Ingress-NGINX రిటైర్‌మెంట్ ఒక తొందరపాటు కంట్రోలర్ మార్పుకు కారణం కాదు. ఇంగ్రెస్ లేయర్‌ను కనిపించని ప్లంబింగ్‌గా చూడటం మానేయడానికి ఇది ఒక కారణం. దాని ప్రవర్తనను అర్థం చేసుకోండి, మెయింటెయిన్డ్ గమ్యాన్ని ఎంచుకోండి మరియు సాక్ష్యంతో ట్రాఫిక్‌ను మైగ్రేట్ చేయండి.

సూచనలు మరియు మరింత చదవడానికి

  • Ingress NGINX Retirement: What You Need to Know — Kubernetes, 11 నవంబర్ 2025. అధికారిక రిటైర్‌మెంట్ ప్రకటన మరియు ఏమి అందుబాటులో ఉంటుందో వివరణ. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
  • Kubernetes v1.36 Sneak Peek: Ingress NGINX retirement — Kubernetes, 30 మార్చి 2026. 24 మార్చి 2026 న రిటైర్‌మెంట్‌ను మరియు ఫిక్స్‌లు మరియు సెక్యూరిటీ అప్‌డేట్‌ల ముగింపును ధృవీకరిస్తుంది. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
  • Before You Migrate: Five Surprising Ingress-NGINX Behaviors — Kubernetes, 27 ఫిబ్రవరి 2026. సాధారణ కాన్ఫిగరేషన్ కన్వర్షన్ సమయంలో కోల్పోగల కంట్రోలర్ ప్రవర్తనలను చూపిస్తుంది. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
  • Announcing Ingress2Gateway 1.0 — Kubernetes SIG Network, 20 మార్చి 2026. మైగ్రేషన్ సహాయకుడిని, దాని పరీక్షించిన ఎనోటేషన్ మద్దతును మరియు దాని పరిమితులను వివరిస్తుంది. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
  • Migrating from Ingress — Kubernetes Gateway API project. ప్రధాన Ingress కాన్సెప్ట్‌లను Gateway API కు మ్యాప్ చేస్తుంది మరియు ఇంప్లిమెంటేషన్-నిర్దిష్ట ఫీచర్లు ఎక్కడ మిగిలి ఉంటాయో వివరిస్తుంది. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
  • Gateway API implementations and conformance — Kubernetes Gateway API project. ఇంప్లిమెంటేషన్‌లను జాబితా చేస్తుంది మరియు కన్ఫార్మెన్స్ నివేదికల పరిధిని వివరిస్తుంది. సెప్టెంబర్ 2026 లో సమీక్షించబడింది.
సవరణను తెలియజేయండి

సవరణలు ఎడిటర్‌కు చేరుతాయి; అవి ఎప్పుడూ ఆటోమేటిక్‌గా ప్రచురించబడవు. ఖాతా అవసరం లేదు.