Kubernetes Gateway API Útmutató: Az Ingress helyettesítése Cilium Gateway-jel HTTP forgalomhoz

Bevezetés

A Kubernetes forgalomkezelés jelentősen fejlődött az Ingress vezérlők bevezetése óta. Míg a Kubernetes Ingress alapul szolgált a HTTP forgalom irányításához, gyorsan felfedte a korlátait a bonyolult, több bérlős környezetekben.

Képzeld el, hogy egy növekvő Kubernetes platformon dolgozol, ahol szükséged van arra, hogy:

Szolgáltatások biztonságos megosztása több csapat között
Fejlett útválasztás megvalósítása a fejléc és lekérdezési paraméterek alapján
Kezelje a forgalmi politikákat anélkül, hogy beszállítóra jellemző megjegyzéseket használna
Skálázza a forgalomkezelést működési összetettség nélkül.

Itt van Kubernetes Gateway API, amely átalakítja a szolgáltatások hálózatkezeléséhez való hozzáállását. Az Ingress utáni következő fejlődésként a Gateway API szerepkör-orientált, bővíthető és szolgáltató-független módot kínál a HTTP és HTTPS forgalom kezelésére a Kubernetes klaszterekben.

A Gateway API-t a Cilium Gateway segítségével fogod megtanulni a DigitalOcean Kubernetes (DOKS) környezetében, ami azt jelenti, hogy nulla további vezérlő telepítés és natív CNI integráció.

Ebben a részletes útmutatóban megismerkedhet a Gateway API alapjaival, és egy termelésre kész HTTP szolgáltatást valósíthat meg fejlett útválasztási lehetőségekkel a Cilium natív Gateway támogatásának segítségével.

Kulcsfontosságú megállapítások

Ez a átfogó Kubernetes Gateway API oktatóanyag mindent lefed az alapvető fogalmaktól a termelési telepítésig:

Alapvető Fogalmak és Architektúra

Gateway API vs Bejárati vezérlő: Értsd meg az alapvető különbségeket és mikor érdemes átállni a hagyományos bejáratra
Cilium Gateway Implementáció: Használja a DOKS natív Cilium támogatását a nulladik költségű Gateway API telepítéshez.
Szerepalapú Erőforrás Modell: Master GatewayClass, Gateway és HTTPRoute különválasztása a jobb csapatmunkáért

Gyakorlati Megvalósítás

HTTP Forgalom Útvonalvezérlés: Konfigurálja az útvonalalapú irányítást, a fejléc összehangolását és a lekérdezési paraméterek szűrését.
Fejlett Forgalomkezelés: Forgalommegosztás, terheléselvenés és keresztnév-térbeli irányítás végrehajtása
Termelési Telepítés: Állítsa be a DNS integrációt az ExternalDNS-sel és a megfelelő szolgáltatáskeresést

Legjobb gyakorlatok & optimalizálás

Multi-Tenant Környezetek: Tervezzen skálázható Gateway konfigurációkat több csapat számára
Biztonsági szempontok: Alkalmazzon megfelelő hozzáférési korlátozásokat és forgalmi politikákat
Monitorozás és Megfigyelhetőség: Integrálódjon a Kubernetes-natív monitorozási megoldásokkal

Előfeltételek: Alapvető Kubernetes ismeretek és egy működő DOKS klaszter. Új a Kubernetes világában? Kezdje a Kubernetes Alapok útmutatónkkal.

Előfeltételek

Mielőtt elkezdené ezt a bemutatót, győződjön meg arról, hogy van:

Egy futó VPC Native DigitalOcean Kubernetes klaszter (1.33+ verzió)
kubectl telepítve és konfigurálva van, hogy kommunikáljon a kluszterével
A Gateway API CRD-k telepítve vannak (a DOKS tartalmazza a Ciliumot, amely ezt alapértelmezés szerint támogatja).
Egy regisztrált domain név és DNS hozzáférés

Megjegyzés: Segítségre van szüksége a követelményekkel kapcsolatban? Nézze meg ezeket az útmutatókat:

Hozzon létre egy DOKS klasztert
Telepítse és konfigurálja a kubectl-t
Állítsa be a DNS-t a DigitalOcean-nal

Vegye figyelembe, hogy a dolearn.xyz domain szerepel a példákban, győződjön meg róla, hogy ezeket a hivatkozásokat a saját domainjére cseréli.

Miért Gateway API? Jobb út az HTTP irányításához

Ha dolgoztál már a Kubernetes Ingress-szel, valószínűleg érezted a korlátait. Míg az Ingress megnyitotta az utat az HTTP(S) terhelések kitettsége előtt, gyorsan megmutatta a gyengeségeit:

A vezérlőspecifikus annotációkra támaszkodva a fejlett funkciókhoz
Küzd a többlakásos beállításokkal
A felelősség határvonalainak elmosása az infrastruktúra csapatok és a fejlesztők között

Ahogy a platformok egyre összetettebbé válnak, gondoljunk a több csapat által végzett munkákra, a kanári bevezetésekre és a finomhangolt forgalomirányításra, akkor az Ingress önálló használata kezd olyan érzést kelteni, mint a ragasztószalag.

Itt jön be a Gateway API. A Kubernetes SIG-Network által tervezett rendszer, mint a szolgáltatási hálózat következő evolúciója, egy szerep-orientált, hordozható és kiterjeszthető modellt hoz a forgalomirányításhoz.

Ha új vagy a Kubernetes hálózatkezelésében, először nézd meg a Kubernetes Hálózati Alapok című útmutatónkat, hogy megértsd az alapokat.

A Gateway API kulcsfontosságú előnyei az Ingress-szel szemben**

1. Gazdag, kifejező útvonalazás

Lépj túl az egyszerű hoszt/útvonal megfelelődéseken. A Gateway API támogatja a fejlécfeltételeket, lekérdezési paramétereket és a súlyozott forgalommegosztást alapból, ezzel a kanári kiadásokat, A/B teszteket és kék-zöld telepítéseket elsőrangú állampolgárokká téve, nem pedig a megjegyzésekben elrejtett hackekkel.

2. Világos szerepkülönbség

A Gateway API tiszta felelősségmegosztást vezet be háromféle erőforrás felhasználásával:

Az infrastruktúra szolgáltatók meghatározzák a GatewayClass-t.
A klaszter operátorok telepítik a Gateway -t
A fejlesztők meghatározzák a HTTPRoute -ot (vagy más Route erőforrásokat, például GRPCRoute-ot)

A tutorial későbbi részében mélyebben megvizsgáljuk mindegyik forrást.

Ezek az erőforrások megakadályozzák a jogosultságok átfedését, egyszerűsítik a kormányzást, és természetesen illeszkednek a többcsapatnyi munkafolyamatokhoz.

3. Kereszt-namespace és többbérlős kész

A Gateway API natívan támogatja a kereszt-namespace irányítást, amely ideális nagy platformok vagy szervezetek számára, ahol a szolgáltatások és csapatok több namespace-re terjednek ki.

4. Szállítófüggetlen és hordozható

Nincs több szolgáltatóhoz kötés. A Gateway API szabványos CRD-ket határoz meg, így a routing logikája zökkenőmentesen áthelyezhető különböző szolgáltatók vezérlői között.

5. Fejlett forgalomirányítás, annotációs káosz nélkül

A próbálkozások, tükrözés, szűrők és forgalmi politikák első osztályú elemek vagy jól meghatározott kiterjesztések. Nincs szükség nem dokumentált megjegyzésekre vagy gyártó-specifikus trükkökre.

DOKS és Cilium integráció

A DigitalOcean Kubernetes-en (DOKS) a Cilium a default CNI megvalósítás. Ennek fontos következménye van a csapatok számára, akik az Ingress és a Gateway API között választanak:

Ha továbbra is használja az Ingress-t, felelős a saját ingress vezérlője (NGINX, HAProxy, Traefik stb.) működtetéséért. Ez extra terhet jelent - telepíteni kell, karban kell tartani és figyelemmel kell kísérni a frissítéseket.

A Gateway API-val ez a teher eltűnik. Mivel a DOKS alapértelmezetten a Cilium-ot tartalmazza, a Gateway API támogatás már be van építve. A HTTP irányítás egy natív, teljes mértékben kezelt funkció a vezérlő síkon, anélkül, hogy extra komponenseket kellene karbantartanod.

További részletekért nézze meg útmutatóinkat a DOKS klaszter beállításáról és a Cilium hálózati funkciókról.

Kapunyitó API Alapblokkok

GatewayClass

A GatewayClass meghatározza a gateway típusát, amelyet a klasztered használhat. Gondolj rá, mint egy sablonra, amely megmondja a Kubernetesnek, hogyan kellene viselkedniük a Gatewey-nek. A mi esetünkben a Gateway Class a Cilium. A GatewayClass-t a DigitalOcean hozza létre és kezeli.

Kapuk

A Gateway egy GatewayClass példánya. Ez képviseli a valódi belépési pontot a klaszteredbe, amelyet egy Terheléselosztó támogat egy Felhőbeállításban. A Gateway-t általában a DevOps vagy platform szerepben lévő valaki hozza létre, általában ez az a csapat, amely a Kubernetes klasztereket és a megosztott infrastruktúrát kezeli.

Egy Kapunyitó három fő dolgot hoz össze:

GatewayOsztályNév
- Köti a Hozzáférést egy adott implementációhoz.
Hallgatók
- Ezek olyanok, mint a „belépési pontok” a klaszterbe.
- Egy hallgató megfogalmazza:
  - Protokoll (pl. HTTP, HTTPS, TCP, gRPC).
  - Port (például 80 vagy 443).
  - Hostnév(ek) (pl. example.com, *.app.io).
  - TLS végrehajtás (ha a Gatewaynek kell kezelnie a tanúsítványokat).
  - Útvonalkötési szabályok — mely típusú útvonalak csatlakozhatnak ide.
- Lényegében a hallgatók határozzák meg, milyen típusú forgalmat hajlandó elfogadni és feldolgozni ez a Kapu.
Címek
- A tényleges IP-címek vagy terheléselosztó előtér, amelyeket a Gateway vezérlő biztosít.
- Ez lehet egy felhő alapú terheléselosztó, egy klaszter IP, vagy akár csak egy csomóponti port beállítás a környezetedtől függően.

HTTPÚtvonalak

HTTP útvonal szabályokat definiál egy vagy több szolgáltatás számára a klaszteredben. Az HTTP útvonalakat jellemzően fejlesztők hozzák létre.

Az HTTPRoute a következőkből áll:

Szülő Hivatkozások
Ezek meghatározzák, hogy melyik Átjárókhoz és azok melyik specifikus figyelőjéhez csatlakozhat ez az útvonal.
Gazdagépek nevei
- A HTTPRoutes szűkítheti, hogy mely hostnevekhez vonatkoznak (pl. api.example.com, shop.example.com).
- Ha több útvonal egy átjárót oszt meg, a gazdanevek biztosítják, hogy a forgalom a megfelelő háttérbe kerüljön.
Szabályok
- Ahol a párosítás és az útvonalmeghatározás történik. A következők alapján párosíthat:
- Útvonalleírások (/api, /shop)
- Fejlécek (X-Canary: true).
- Lekérdezési paraméterek.
- Szűrők: Alkalmazzon átalakításokat, mint például átirányítások, fejléc-újraírások, kérés/válasz módosítások vagy forgalom tükörzése.
- BackendRefs: Adja meg a célállomás szolgáltatásokat (vagy háttérszolgáltatásokat), támogatva a forgalom megosztását súlyok segítségével.
- Időtúllépések: A kérés életciklusának korlátozása (pl. kérési időtúllépés).

Telepítsünk egy mintarekesztést, és tegyük elérhetővé egy átjárón és egy HTTPRoute-on keresztül.

1. lépés - Telepítsen egy mintát alkalmazást

Futtasd ezt a parancsot a terminálodból (győződj meg róla, hogy a kubectl be van állítva a DigitalOcean Kubernetes klaszteredhez való csatlakozáshoz):

kubectl apply \
    -f https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/platform/kube/bookinfo.yaml

A bookinfo.yaml manifest alkalmazása elindítja a négy Bookinfo mikroszolgáltatást: productpage, details, reviews és ratings—a magjával.

Szolgáltatások a 9080 porton, hogy minden mikroszolgáltatás felfedezhető legyen.
A Podok futtatásához szükséges telepítések (a részletek és értékelések v1-es verzióval rendelkeznek, a terméklap v1-es, míg az értékelések v1, v2 és v3-as verziókkal rendelkeznek).
Szolgáltatásfiókok, hogy minden szolgáltatásnak saját személyazonossága legyen.

2. lépés - A Cilium Gateway telepítése

Amikor létrehoz egy Kaput, akkor azt is eldönti, hogy hogyan fogják megosztani:

Dedikált Átjáró: Ugyanabban a névtérben telepítve, mint az alkalmazás és a HTTPRoutes. Ez a modell jól működik, amikor minden csapat vagy alkalmazás a saját Átjáróját birtokolja.
Megosztott Híd: Más névtérben telepítve és több alkalmazás között megosztva. Ebben az esetben a Híd tulajdonosának kifejezetten engedélyeznie kell, hogy más névterek útvonalakat csatoljanak az allowedRoutes mezőn keresztül.

A mi esetünkre létrehozunk egy Dedikált Átjárót.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cilium-gateway-http
spec:
  gatewayClassName: cilium
  listeners:
  - protocol: HTTP
    port: 80
    name: web-gw
    allowedRoutes:
      namespaces:
        from: Same

A Gateway és az alkalmazás HTTPRoutes ugyanabban a névtérben található. Csak a minta-alkalmazás csapata csatlakoztathat útvonalakat hozzá, ami elkülöníti az útválasztást és megakadályozza, hogy más csapatok/névtér használhassák ezt a belépési pontot.

Miután a fenti manifestumot alkalmazták, két erőforrás jön létre. A Gateway és a LoadBalancer típusú Szolgáltatás. Megjegyezzük, hogy eltarthat néhány percig, amíg a terheléselosztó létrejön és az IP címe megjelenik.

kubectl get gateways

NAME                  CLASS    ADDRESS           PROGRAMMED   AGE
cilium-gateway-http   cilium   134.209.130.13    True         47m

kubectl get svc -o wide | grep LoadBalancer

cilium-gateway-cilium-gateway-http   LoadBalancer   10.108.72.44    138.197.230.74    80:32015/TCP                 50m     <none>

3. lépés - Hozza létre az HTTPRoute-ot

Miután létrehoztál egy Gateway-t, a következő lépés az HTTPRoute-ok meghatározása. Ezek megmondják a Gateway-nek, hogyan irányítsa a bejövő kéréseket az alkalmazásaid szolgáltatásaihoz.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-app-test
spec:
  parentRefs:
  - name: cilium-gateway-http
  hostnames: 
  - "httptest.dolearn.xyz"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /details
    backendRefs:
    - name: details
      port: 9080
      
  - matches:
    - headers:
      - type: Exact
        name: magic
        value: foo
      queryParams:
      - type: Exact
        name: great
        value: example
      path:
        type: PathPrefix
        value: /
      method: GET
    backendRefs:
    - name: productpage
      port: 9080

Mit csinál?

Hivatkozások egy átjáróra
1. parentRefs a cilium-gateway-http átjáróra mutat az ugyanabban névtérben.
2. Ez megmondja a klaszternek, hogy melyik átjárónak kell feldolgoznia ezeket az útvonalakat.
Hostname-ok definiálása
1. A httptest.dolearn.xyz címre érkező kérések erre az HTTPRoute-ra fognak illeszkedni.
Útvonal-szabályok beállítása
Első szabály: A /details -val kezdődő útvonalakkal rendelkező kéréseket a details szolgáltatáshoz irányítjuk a 9080-as porton.
1. Második szabály: A kérések, amelyek
  - Fejléc magic: foo
  - Lekérdezési paraméter great=példa
  - Útvonal, amely /-ral kezdődik
  - A GET módszerek a productpage szolgáltatáshoz kerülnek irányításra a 9080-as porton.

4. lépés - Az ExternalDNS beállítása a DigitalOcean-nal (opcionális)

Az ExternalDNS automatizálja a DNS-rekordok kezelését a szolgáltatódnál (jelen esetben a DigitalOcean-nél) a Kubernetes erőforrások, például a Szolgáltatások, Bejegyzések és a Gateway API útvonalak alapján.

1. Hozzon létre egy DigitalOcean API tokent

Szükséged lesz egy személyes hozzáférési tokenre írási jogokkal a DNS rekordok kezeléséhez.

2. Tárold a Tokent Kubernetes Titkosként

Hozzon létre egy Kubernetes Titkot, amelyet az ExternalDNS használ a DigitalOcean-nal való hitelesítéshez:

kubectl create secret generic digitalocean-dns \
  --from-literal=access-token=<YOUR_DIGITALOCEAN_TOKEN>

3. Addja hozzá az ExternalDNS Helm tárolót

helm repo add external-dns https://kubernetes-sigs.github.io/external-dns/
helm repo update

4. Értékek konfigurálása a Helm telepítéshez

env: # Passes the DigitalOcean token from the secret
  - name: DO_TOKEN
    valueFrom:
      secretKeyRef:
        name: digitalocean-dns
        key: access-token

provider: # ExternalDNS provider configuration
  name: digitalocean

policy: sync # Ensures ExternalDNS continuously reconciles DNS records
txtOwnerId: gateway-api # Ensures ExternalDNS does not conflict others using this domain

sources: # Kubernetes resources to watch and create DNS records for
  - service
  - ingress
  - gateway-grpcroute
  - gateway-httproute

5. Telepítse az ExternalDNS-t

Telepítsd az ExternalDNS-t Helm segítségével:

helm install external-dns external-dns/external-dns -f values.yaml

6. Ellenőrizze a DNS rekordokat

A telepítés után az ExternalDNS-nek automatikusan DNS-rekordokat kell létrehoznia a Szolgáltatásaidhoz/Ingrésaidhoz.

Ellenőrizheti a következőkkel:

dig +short httptest.dolearn.xyz
138.197.230.74

Hivatkozás: https://kubernetes-sigs.github.io/external-dns/latest/

Alternatívaként, manuálisan is hozzáadhatja a DNS rekordokat: https://docs.linux-console.net/products/networking/dns/how-to/manage-records/

5. lépés - HTTP kérés küldése

Most, hogy a Gateway készen áll, HTTP kéréseket küldhetsz az alkalmazásnak a szolgáltatás használatával.

curl --fail -s http://httptest.dolearn.xyz/details/1 | jq

{
  "id": 1,
  "author": "William Shakespeare",
  "year": 1595,
  "type": "paperback",
  "pages": 200,
  "publisher": "PublisherA",
  "language": "English",
  "ISBN-10": "1234567890",
  "ISBN-13": "123-1234567890"
}

curl -v -H 'magic: foo' http://httptest.dolearn.xyz\?great\=example

* Host httptest.dolearn.xyz:80 was resolved.
* IPv6: (none)
* IPv4: 134.209.130.13
*   Trying 134.209.130.13:80...
* Connected to httptest.dolearn.xyz (134.209.130.13) port 80
> GET /?great=example HTTP/1.1
> Host: httptest.dolearn.xyz
> User-Agent: curl/8.7.1
> Accept: */*
> magic: foo
>
* Request completely sent off
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< content-length: 1683
< server: envoy
< date: Mon, 25 Aug 2025 13:21:59 GMT
< x-envoy-upstream-service-time: 8
<
<!DOCTYPE html>
<html>
  <head>
    <title>Simple Bookstore App</title>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- Latest compiled and minified CSS -->
<link rel="stylesheet" href="static/bootstrap/css/bootstrap.min.css">

<!-- Optional theme -->
<link rel="stylesheet" href="static/bootstrap/css/bootstrap-theme.min.css">

  </head>
  <body>


<p>
    <h3>Hello! This is a simple bookstore application consisting of three services as shown below</h3>
</p>

<table class="table table-condensed table-bordered table-hover"><tr><th>name</th><td>http://details:9080</td></tr><tr><th>endpoint</th><td>details</td></tr><tr><th>children</th><td><table class="table table-condensed table-bordered table-hover"><tr><th>name</th><th>endpoint</th><th>children</th></tr><tr><td>http://details:9080</td><td>details</td><td></td></tr><tr><td>http://reviews:9080</td><td>reviews</td><td><table class="table table-condensed table-bordered table-hover"><tr><th>name</th><th>endpoint</th><th>children</th></tr><tr><td>http://ratings:9080</td><td>ratings</td><td></td></tr></table></td></tr></table></td></tr></table>

<p>
    <h4>Click on one of the links below to auto generate a request to the backend as a real user or a tester
    </h4>
</p>
<p><a href="/productpage?u=normal">Normal user</a></p>
<p><a href="/productpage?u=test">Test user</a></p>



<!-- Latest compiled and minified JavaScript -->
<script src="static/jquery.min.js"></script>

<!-- Latest compiled and minified JavaScript -->
<script src="static/bootstrap/js/bootstrap.min.js"></script>

  </body>
</html>
* Connection #0 to host httptest.dolearn.xyz left intact

És ez itt van! Sikeresen telepítettél egy mintalehetőséget, és kitetetted egy Gateway és egy HTTPRoute segítségével.

GYIK

1. Hogyan használjam a Gateway API-t a Kubernetes-ben?

A Gateway API használatához a Kubernetes-ben kövesse az alábbi lépéseket:

Gateway API CRD-k telepítése (automatikusan benne van a DOKS-ben a Ciliummal)
Gateway vezérlő telepítése (A Cilium Gateway előtelepítve van a DOKS-on)
Hozzon létre egy GatewayClass erőforrást (amelyet a DigitalOcean kezel)
Határozz meg egy átjárót a forgalmad belépési pontjaként
HTTPRoute erőforrások konfigurálása alkalmazás-specifikus irányításhoz

DOKS Advantage: A Cilium mint alapértelmezett CNI, a Gateway API támogatás beépített—nincs szükség további vezérlő telepítésére.

2. Mi a különbség a Gateway API és az Ingress vezérlő között?

A Gateway API a Kubernetes forgalomkezelés modern evolúciója:

Belépési korlátozások:

Vezérlőspecifikus megjegyzések fejlett funkciókhoz
Egységes erőforrásmodell, amely keveri az infrastruktúra- és az alkalmazásproblémákat
Korlátozott többbérlős támogatás

Gateway API előnyei:

Szerepközpontú tervezés: Külön források az infrastruktúra csapatok számára (Gateway) és a fejlesztőknek (HTTPRoute)
Natív funkció támogatás: Forgalom megosztása, fejléc egyeztetés, cross-namespace útvonalválasztás annotációk nélkül
Szállító hordozhatóság: Standardizált különböző megvalósítások között

3. Átkonvertálhatok az Ingress-ből a Gateway API-ra leállás nélkül?

Igen! A Gateway API támogatja a fokozatos migrációs stratégiákat:

Párhuzamos telepítés: Futtassa a Gateway API-t a meglévő Ingress vezérlők mellett
Szolgáltatásról szolgáltatásra történő migráció: Alkalmazások fokozatos áthelyezése
Kék-zöld migráció: Először tesztelje a Gateway API-t nem produkciós forgalommal
Forgalmi megosztás: Használja a Gateway API beépített forgalmi megosztását a kanári telepítésekhez.

Tudjon meg többet Kubernetes migrációs útmutatónkban.

4. Hogyan hasonlít a Cilium Gateway más Gateway API megvalósításokhoz?

A Cilium Gateway egyedi előnyöket kínál a DOKS-en.

Natív CNI integráció: Nincs külön vezérlő pod vagy további erőforrás-terhelés
eBPF-meghajtású teljesítmény: Hardverrel gyorsított forgalomfeldolgozás
Belső megfigyelhetőség: Integrálva a Cilium megfigyelési lehetőségeivel
Automatikus skálázás: Automatikusan skálázódik a kluszternódjaidhoz manuális konfiguráció nélkül.

5. Milyen példa a Gateway API gyakori használati eseteire?

Közönséges Átjáró API megvalósítási minták:

Útvonal-alapú irányítás:

rules:
- matches:
  - path:
      type: PathPrefix
      value: /api
  backendRefs:
  - name: api-service

Fejlécre alapozott útvonalválasztás:

rules:
- matches:
  - headers:
    - name: "version"
      value: "v2"
  backendRefs:
  - name: api-v2-service

Forgalom szétosztás:

backendRefs:
- name: service-v1
  weight: 80
- name: service-v2
  weight: 20

6. Készen áll a Gateway API a termelési környezetekre?

Abszolút! A Gateway API elérte a GA státuszt és készen áll a termelési környezetre:

Stabil API: a v1 API visszafelé kompatibilitást garantál
Széleskörű elterjedés: Használják a legnagyobb felhőszolgáltatók és vállalatok.
Aktív fejlesztés: Folyamatos fejlesztések és funkciók hozzáadása
Erős ökoszisztéma: Növekvő számú megvalósítás és eszköz

DOKS-on: A Cilium Gateway teljes mértékben támogatott és ajánlott a gyártási munkaterhelésekhez.

Következtetés

Gratulálok! Sikeresen megvalósítottad a produkciós szintű Kubernetes Gateway API beállítását a Cilium segítségével. Íme, amit elértél:

A Bookinfo mikroszolgáltatásokat megfelelő szolgáltatás-felfedezéssel telepítve
Cilium Gateway létrehozva a DOKS natív CNI integráció kihasználásával
Konfigurált fejlett HTTPRoute szabályok útvonal- és fejléc-alapú irányítással
Automatikus DNS-kezelés beállítása ExternalDNS integrációval
Valós forgalmi forgatókönyvek tesztelése több útvonalválasztási feltétel mellett

Következő lépések

Most, hogy egy szilárd Gateway API alapod van, fontold meg ezeket a fejlettebb megvalósításokat:

DOKS Működési Készség, 2. rész: HTTPS engedélyezése
Konfigurálja az OAuth hitelesítést külső szolgáltatókkal
Állítsa be a Prometheus megfigyelést a Gateway metrikáihoz

Fedezd fel átfogó Kubernetes oktatóanyagainkat, amelyek mindent lefednek az alapoktól a vállalati mintákig.

Csatlakozz a DigitalOcean közösségéhez, hogy megoszthasd a Gateway API megvalósításaidat, és tanulhass más fejlesztőktől.