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

Útmutató önállóan üzemeltetett átjáró Kubernetesen való futtatásához éles környezetben

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ásolatokat használva az ideiglenes kapcsolatmegszakítások kezelésére, és még sok más funkcióra.

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.

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. Meg kell újítani, és a fürtöt új jogkivonattal kell konfigurálni, manuálisan vagy automatizált módon, 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 Horizontal Pod Autoscaler segítségével. Lehetővé teszi a processzor- és memóriaküszöbök, valamint a felskálázandó vagy le 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.fsGroupKubernetes 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.

Konténerké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 Önnek van optimalizálva. A Helm-diagram alkalmazásverziója pontosítja az átjárót egy adott verzióra, és nem támaszkodik latest-ra.

Tudjon meg többet arról, hogyan telepíthet önállóan telepített API Management átjárót a Kubernetes platformra Helm eszközzel.

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:

  • Specifikus 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 skálázza fel vagy le.

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 azconfig.service.endpoint< fájl értékét > 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 okozza, hogy a fürt DNS által nem feloldott névfeloldási kérelmek továbbítva lesznek a csomópontról örökölt felsőbb szintű DNS-kiszolgálóhoz.

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 portálon megadott YAML-fájl a externalTrafficPolicy objektum mezőjét Local értékre állítja 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, ha az üzembe helyezett példányoknál a csomópontoknál egyenlőtlen mennyiségű átjáró podokkal rendelkeznek.

Állapottesztelés

A HTTP-mintavételek végpontját /status-0123456789abcdef használhatja az átjáró üzemelő példányainak készültségi és élettartam-mintavételeihez. Ez segít csak olyan átjárótelepítések felé irányítani a forgalmat, amelyek sikeresen elindultak és készen állnak a forgalom kiszolgálására, vagy amelyekről ismert, hogy továbbra is reagálnak.

Egészségügyi vizsgálatok nélkül előfordulhat, hogy az átjáró üzembe helyezései gyorsabban elindulnak, de a konfiguráció még nem teljesen töltődött be, ami 503-as hibákat okozhat az adatsík forgalmában.

Tipp.

A Helm használatával történő telepítéskor az állapot-ellenőrzések alapértelmezés szerint engedélyezve vannak.

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.

Tudjon meg többet arról, hogyan telepíthet önállóan telepített API Management átjárót a Kubernetes platformra Helm eszközzel.

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édekezés 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 keretek használatát, hogy biztosítson minimális számú podot, amely bármikor elérhető.

HTTP(S) proxy

A saját üzemeltetésű átjáró támogatja a HTTP(S) proxyt a hagyományos HTTP_PROXYés HTTPS_PROXYNO_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 arra szolgálnak, hogy jelezzék a kérés proxy szerver viselkedését.

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 Insightst 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 Insights használatát a tárolók figyelésére, vagy helyi figyelés beállítását annak érdekében, hogy az API-forgalom megfigyelhető legyen és elkerülhető legyen a telemetriai veszteség az Azure-beli kapcsolatkimaradások során.

Névtér

A Kubernetes névterek segítségével egyetlen fürt elosztható 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 klaszterben 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ésistraté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ési szintre (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 korlátozása

A kérések korlátozása a saját üzemeltetésű átjárókban az API Management sebességkorlátozási vagy kulcsonkénti sebességkorlátozási szabályzatának használatával engedélyezhető. Állítsa be a sebességkorlátozási számlálókat úgy, hogy szinkronizálódjanak az átjárópéldányok között a klaszter csomópontjain az instance felismeréshez szükséges következő portok megnyitásával a Kubernetes telepítésben:

  • 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át számlálók egy önállóan üzemeltetett átjáróban konfigurálhatók a helyi szinkronizálásra (a fürtcsomópontok közötti átjárópéldányok esetén), például a Helm chart Kubernetes-alapú telepítésével vagy az Azure Portal telepíté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.

Kapcsolódó tartalom

  • Last updated on