Megosztás a következőn keresztül:

Útmutató saját üzemeltetésű átjáró futtatásához a Kubernetesen éles környezetben

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Fejlesztő | Prémium

A saját üzemeltetésű átjáró éles környezetben való futtatásához különböző szempontokat kell figyelembe venni. Például magas rendelkezésre állású módon kell üzembe helyezni, konfigurációs biztonsági másolatokkal kezelni az ideiglenes leválasztást és még sok mást.

Ez a cikk útmutatást nyújt arról, hogyan futtathat saját üzemeltetésű átjárót a Kubernetesen éles számítási feladatokhoz, hogy az zökkenőmentesen és megbízhatóan fusson.

Fontos

Az Azure API Management saját üzemeltetésű átjáró 0-s és 1-es verziójú tárolórendszerképeinek támogatása 2023. október 1-jén megszűnik, a hozzá tartozó Configuration API 1-es verziójával együtt. A migrálási útmutatónk segítségével a Configuration API 2-es verziójával használhatja a saját üzemeltetésű átjáró 2.0.0-s vagy újabb verzióját. További információ az elavulással kapcsolatos dokumentációnkban

Hozzáférési jogkivonat

Érvényes hozzáférési jogkivonat nélkül a saját üzemeltetésű átjárók nem férhetnek hozzá és nem tölthetnek le konfigurációs adatokat a társított API Management szolgáltatás végpontjáról. A hozzáférési jogkivonat legfeljebb 30 napig érvényes lehet. Újra létre kell hozni, és a fürtnek új jogkivonattal kell konfigurálnia, manuálisan vagy automatizálással, mielőtt lejár.

A jogkivonatok frissítésének automatizálásakor ezzel a felügyeleti API-művelettel hozzon létre új jogkivonatot. A Kubernetes titkos kulcsainak kezelésével kapcsolatos információkért tekintse meg a Kubernetes webhelyét.

Tipp.

A saját üzemeltetésű átjárót a Kubernetesben is üzembe helyezheti, és a Microsoft Entra ID használatával engedélyezheti a hitelesítést az API Management-példányon.

Automatikus skálázás

Bár útmutatást nyújtunk a saját üzemeltetésű átjáró minimális replikáinak számával kapcsolatban, javasoljuk, hogy a saját üzemeltetésű átjáró automatikus skálázását használja a forgalom igényének proaktívabb kielégítése érdekében.

A saját üzemeltetésű átjáró horizontálisan kétféleképpen skálázható automatikusan:

  • Automatikus skálázás az erőforrás-használat (CPU és memória) alapján
  • Automatikus skálázás a másodpercenkénti kérelmek száma alapján

Ez a natív Kubernetes-funkciókkal vagy a Kubernetes eseményvezérelt automatikus skálázásával (KEDA) lehetséges. A KEDA egy CNCF-inkubációs projekt, amely arra törekszik, hogy az alkalmazás automatikus skálázása egyszerű legyen.

Feljegyzés

A KEDA egy nyílt forráskódú technológia, amelyet Azure-támogatás nem támogat, és az ügyfeleknek kell működtetni.

Erőforrás-alapú automatikus skálázás

A Kubernetes lehetővé teszi a saját üzemeltetésű átjáró automatikus skálázását az erőforrás-használat alapján egy vízszintes pod automatikus skálázásával. Lehetővé teszi a processzor- és memóriaküszöbök, valamint a felskálázható vagy felskálázható replikák számának meghatározását.

Egy másik lehetőség a Kubernetes eseményvezérelt automatikus skálázás (KEDA) használata, amely lehetővé teszi a számítási feladatok skálázását különböző skálázók, például a CPU és a memória alapján.

Tipp.

Ha már a KEDA-t használja más számítási feladatok skálázásához, javasoljuk, hogy a KEDA-t egységesített alkalmazás-automatikus skálázóként használja. Ha ez nem így van, akkor erősen javasoljuk, hogy támaszkodjon a natív Kubernetes-funkciókra a Vízszintes pod automatikus skálázási funkcióján keresztül.

Forgalomalapú automatikus skálázás

A Kubernetes nem biztosít beépített mechanizmust a forgalomalapú automatikus skálázáshoz.

A Kubernetes eseményvezérelt automatikus skálázása (KEDA) néhány módszert kínál, amelyek segíthetnek a forgalomalapú automatikus skálázásban:

Konfigurációs biztonsági mentés

Konfiguráljon egy helyi tárolókötetet a saját üzemeltetésű átjárótárolóhoz, hogy megőrizhesse a legújabb letöltött konfiguráció biztonsági másolatát. Ha a kapcsolat megszakad, a tárkötet újrainduláskor használhatja a biztonsági másolat másolatát. A kötet csatlakoztatási útvonalának csoportazonosítóval kell rendelkeznie /apim/config , és annak a csoportazonosítónak 1001kell lennie. Lásd egy példát a GitHubon. A Kubernetes-tárterületről a Kubernetes webhelyén tájékozódhat. A csatlakoztatott útvonal tulajdonjogának módosításához tekintse meg a securityContext.fsGroup Kubernetes webhelyén található beállítást.

Feljegyzés

A saját üzemeltetésű átjárók ideiglenes Azure-kapcsolatkimaradás esetén történő viselkedéséről további információt a saját üzemeltetésű átjárók áttekintésében talál.

Tárolórendszerkép címkéje

Az Azure Portalon megadott YAML-fájl a legújabb címkét használja. Ez a címke mindig a saját üzemeltetésű átjárótároló lemezképének legújabb verziójára hivatkozik.

Érdemes lehet egy adott verziócímkét használni az éles környezetben, hogy elkerülje az újabb verzióra való véletlen frissítést.

Az elérhető címkék teljes listáját letöltheti.

Tipp.

A Helm használatával történő telepítéskor a rendszerkép-címkézés az Ön számára van optimalizálva. A Helm-diagram alkalmazásverziója rögzíti az átjárót egy adott verzióra, és nem támaszkodik rá latest.

További információ arról, hogyan telepíthet saját üzemeltetésű API Management-átjárót a Kubernetesre a Helmel.

Tárolóerőforrások

Alapértelmezés szerint az Azure Portalon megadott YAML-fájl nem ad meg tárolóerőforrás-kéréseket.

Lehetetlen megbízhatóan előrejelezni és javasolni a tárolónkénti CPU- és memóriaerőforrások mennyiségét, valamint az adott számítási feladat támogatásához szükséges replikák számát. Számos tényező játszik szerepet, például:

  • Adott hardver, amelyen a fürt fut.
  • A virtualizálás jelenléte és típusa.
  • Az egyidejű ügyfélkapcsolatok száma és sebessége.
  • Kérések aránya.
  • A konfigurált szabályzatok típusa és száma.
  • A hasznos adatok mérete és a hasznos adatok pufferelése vagy streamelése.
  • Háttérszolgáltatás késése.

Javasoljuk, hogy az erőforrás-kérelmeket két magra és 2 GiB-ra állítsa kiindulási pontként. Végezzen terheléstesztet, és az eredmények alapján vertikális fel- vagy fel- vagy leskálázást végezzen.

Egyéni tartománynevek és SSL-tanúsítványok

Ha egyéni tartományneveket használ az API Management-végpontokhoz, különösen ha a felügyeleti végponthoz egyéni tartománynevet használ, előfordulhat, hogy frissítenie kell az< átjáró-name.yaml> fájl értékét config.service.endpoint az alapértelmezett tartománynév helyett az egyéni tartománynévre. Győződjön meg arról, hogy a felügyeleti végpont elérhető a Kubernetes-fürt saját üzemeltetésű átjárójának podjáról.

Ebben az esetben, ha a felügyeleti végpont által használt SSL-tanúsítványt nem egy jól ismert hitelesítésszolgáltatói tanúsítvány írja alá, győződjön meg arról, hogy a hitelesítésszolgáltatói tanúsítványt a saját üzemeltetésű átjáró podja megbízhatónak tekinti.

Feljegyzés

A saját üzemeltetésű átjáró v2-vel az API Management új konfigurációs végpontot biztosít: <apim-service-name>.configuration.azure-api.net. Ehhez a végponthoz az egyéni gazdagépnevek támogatottak, és az alapértelmezett gazdagépnév helyett használhatók.

DNS-szabályzat

A DNS-névfeloldás kritikus szerepet játszik abban, hogy a saját üzemeltetésű átjáró képes kapcsolódni az Azure függőségeihez, és API-hívásokat küldeni a háttérszolgáltatásoknak.

Az Azure Portalon megadott YAML-fájl az alapértelmezett ClusterFirst-szabályzatot alkalmazza. Ez a szabályzat azt eredményezi, hogy a fürt DNS-címe nem oldja fel a névfeloldási kérelmeket a csomóponttól örökölt felsőbb rétegbeli DNS-kiszolgálóra.

A Kubernetes névfeloldásáról a Kubernetes webhelyén tájékozódhat. Érdemes lehet testre szabni a DNS-szabályzatot vagy a DNS-konfigurációt a beállításnak megfelelően.

Külső forgalmi szabályzat

Az Azure Portalon megadott YAML-fájl a Szolgáltatás objektum mezőjét a következőre Localállítja externalTrafficPolicy be: . Ez megőrzi a hívó IP-címét (amely elérhető a kérelemkörnyezetben), és letiltja a csomópontok közötti terheléselosztást, így kiküszöböli az általa okozott hálózati ugrásokat. Vegye figyelembe, hogy ez a beállítás a forgalom aszimmetrikus elosztását okozhatja az üzemelő példányokban, csomópontonként egyenlőtlen számú átjáró poddal.

Magas szintű rendelkezésre állás

A saját üzemeltetésű átjáró kulcsfontosságú összetevője az infrastruktúrának, és magas rendelkezésre állásúnak kell lennie. A hiba azonban bekövetkezhet és bekövetkezhet.

Fontolja meg a saját üzemeltetésű átjáró védelmét a fennakadások ellen.

Tipp.

Ha a Helm használatával telepíti, egyszerűen engedélyezheti a magas rendelkezésre állású ütemezést a highAvailability.enabled konfigurációs beállítás engedélyezésével.

További információ arról, hogyan telepíthet saját üzemeltetésű API Management-átjárót a Kubernetesre a Helmel.

Védelem a csomóponthibák ellen

Annak érdekében, hogy az adatközpontok vagy csomóponthibák miatt ne legyen érintett, érdemes lehet olyan Kubernetes-fürtöt használni, amely rendelkezésre állási zónákat használ a magas rendelkezésre állás eléréséhez a csomópont szintjén.

A rendelkezésre állási zónák lehetővé teszik a saját üzemeltetésű átjáró podjának ütemezését a zónák közötti csomópontokon a következőkkel:

Feljegyzés

Ha az Azure Kubernetes Service-t használja, ebből a cikkből megtudhatja, hogyan használhat rendelkezésre állási zónákat.

Védelem a podok megszakadása ellen

A podok különböző okokból, például manuális podtörlés, csomópontkarbantartás stb. miatt fennakadást tapasztalhatnak.

Fontolja meg a Pod-megszakítási költségvetések használatát, hogy minimális számú podot kényszerítsen ki, hogy bármikor elérhető legyen.

HTTP(S) proxy

A saját üzemeltetésű átjáró támogatja a HTTP(S) proxyt a hagyományos HTTP_PROXYés HTTPS_PROXY NO_PROXY a környezeti változók használatával.

A konfigurálást követően a saját üzemeltetésű átjáró automatikusan használja a proxyt a háttérszolgáltatások felé irányuló összes kimenő HTTP-kéréshez.

A 2.1.5-ös vagy újabb verziótól kezdve a saját üzemeltetésű átjáró megfigyelhetőséget biztosít a kérelmek proxyzásához:

  • Az API Inspector további lépéseket jelenít meg a HTTP(S) proxy használata és a kapcsolódó interakciók során.
  • A részletes naplók a kérelemproxy viselkedésének jelzésére szolgálnak.

Feljegyzés

Az alapszintű hitelesítést használó HTTP-proxyk ismert hibája miatt a visszavont tanúsítványok listájának (CRL) érvényesítése nem támogatott. A saját üzemeltetésű átjáró beállításaiban további információt a megfelelő konfigurálás módjáról olvashat.

Figyelmeztetés

Győződjön meg arról, hogy az infrastruktúra követelményei teljesültek, és hogy a saját üzemeltetésű átjáró továbbra is tud csatlakozni hozzájuk, vagy bizonyos funkciók nem fognak megfelelően működni.

Helyi naplók és metrikák

A saját üzemeltetésű átjáró telemetriát küld az Azure Monitornak, és Azure-alkalmazás Elemzések a társított API Management szolgáltatás konfigurációs beállításainak megfelelően. Ha az Azure-hoz való csatlakozás átmenetileg megszakad, a telemetriai folyamatok megszakadnak az Azure-ba, és az adatok elvesznek a kimaradás idejére.

Fontolja meg az Azure Monitor Container Elemzések használatát a tárolók monitorozásához vagy a helyi monitorozás beállításához, hogy az API-forgalom megfigyelése és a telemetriai adatvesztés megakadályozása az Azure-beli kapcsolatkimaradások során.

Névtér

A Kubernetes-névterek segítségével egyetlen fürt osztható el több csapat, projekt vagy alkalmazás között. A névterek hatókört biztosítanak az erőforrásokhoz és a nevekhez. Erőforráskvóta és hozzáférés-vezérlési szabályzatok társíthatók hozzájuk.

Az Azure Portal parancsokat biztosít a saját üzemeltetésű átjáróerőforrások létrehozásához az alapértelmezett névtérben. Ez a névtér automatikusan létrejön, minden fürtben létezik, és nem törölhető. Fontolja meg egy saját üzemeltetésű átjáró létrehozását és üzembe helyezését egy külön névtérben éles környezetben.

Replikák száma

Az éles üzemre alkalmas replikák minimális száma három, lehetőleg a példányok magas rendelkezésre állású ütemezésével kombinálva.

Alapértelmezés szerint egy saját üzemeltetésű átjáró üzembe helyezése RollingUpdate üzembe helyezési stratégiával történik. Tekintse át az alapértelmezett értékeket, és fontolja meg a maxUnavailable és a maxSurge mezők explicit beállítását, különösen akkor, ha magas replikaszámot használ.

Teljesítmény

Javasoljuk, hogy a tárolónaplókat figyelmeztetésekre (warn) csökkentse a teljesítmény javítása érdekében. További információ a saját üzemeltetésű átjáró konfigurációs referenciájában.

Kérelem szabályozása

A kérések szabályozása a saját üzemeltetésű átjárókban az API Management sebességkorlátjának vagy a sebességkorlát kulcsonkénti szabályzatának használatával engedélyezhető. Konfigurálja a sebességkorlátok számát az átjárópéldányok közötti szinkronizáláshoz a fürtcsomópontok között a következő portok felfedésével a Kubernetes-üzembe helyezésben a példányfelderítéshez:

  • Port 4290 (UDP) a sebességkorlátozó szinkronizáláshoz
  • 4291-s port (UDP), szívverések más példányoknak való küldéséhez

Feljegyzés

A sebességkorlátok száma egy saját üzemeltetésű átjáróban konfigurálható helyi szinkronizálásra (a fürtcsomópontok közötti átjárópéldányok között), például a Helm-diagram Kubernetes-alapú üzembe helyezésével vagy az Azure Portal üzembe helyezési sablonjainak használatával. A sebességkorlátok száma azonban nem szinkronizálható az API Management-példányban konfigurált többi átjáróerőforrással, beleértve a felhőben lévő felügyelt átjárót is.

Biztonság

A saját üzemeltetésű átjáró nem gyökérként futtatható a Kubernetesben, így az ügyfelek biztonságosan futtathatják az átjárót.

Íme egy példa a saját üzemeltetésű átjárótároló biztonsági környezetére:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Figyelmeztetés

A saját üzemeltetésű átjáró írásvédett fájlrendszerrel (readOnlyRootFilesystem: true) való futtatása nem támogatott.

Figyelmeztetés

Helyi hitelesítésszolgáltatói tanúsítványok használatakor a saját üzemeltetésű átjárónak felhasználói azonosítóval (UID) 1001 kell futnia a hitelesítésszolgáltatói tanúsítványok kezeléséhez, ellenkező esetben az átjáró nem indul el.

Következő lépések