Pokyny pro spuštění brány v místním prostředí v kubernetes v produkčním prostředí

  • Článek

PLATÍ PRO: Vývojář | Premium

Aby bylo možné spustit bránu v místním prostředí v produkčním prostředí, je potřeba vzít v úvahu různé aspekty. Měla by se například nasadit vysoce dostupným způsobem, použít zálohy konfigurace ke zpracování dočasných odpojení a mnoho dalších.

Tento článek obsahuje pokyny ke spuštění brány v místním prostředí v Kubernetes pro produkční úlohy, aby se zajistilo bezproblémové a spolehlivé spuštění brány.

Důležité

Podpora místních imagí kontejnerů služby Azure API Management verze 0 a verze 1 končí 1. října 2023 spolu s odpovídajícím konfiguračním rozhraním API v1. Pomocí našeho průvodce migrací můžete používat místní bránu verze 2.0.0 nebo vyšší s rozhraním CONFIGURATION API v2. Další informace najdete v naší dokumentaci k vyřazení

Token přístupu

Bez platného přístupového tokenu nemůže brána v místním prostředí přistupovat ke koncovému bodu přidružené služby API Management a stahovat konfigurační data. Přístupový token může být platný maximálně 30 dnů. Musí se znovu vygenerovat a cluster nakonfigurovaný s čerstvým tokenem, a to buď ručně, nebo prostřednictvím automatizace, než vyprší jeho platnost.

Při automatizaci aktualizace tokenů použijte tuto operaci rozhraní API pro správu k vygenerování nového tokenu. Informace o správě tajných kódů Kubernetes najdete na webu Kubernetes.

Tip

Bránu v místním prostředí můžete také nasadit do Kubernetes a povolit ověřování do instance služby API Management pomocí ID Microsoft Entra.

Automatické škálování

Přestože poskytujeme pokyny k minimálnímu počtu replik pro bránu v místním prostředí, doporučujeme použít automatické škálování pro bránu v místním prostředí, které bude vyhovět požadavkům vašeho provozu proaktivněji.

Bránu v místním prostředí můžete horizontálně škálovat dvěma způsoby:

  • Automatické škálování na základě využití prostředků (procesoru a paměti)
  • Automatické škálování na základě počtu požadavků za sekundu

To je možné prostřednictvím nativních funkcí Kubernetes nebo pomocí automatického škálování řízeného událostmi Kubernetes (KEDA). KEDA je projekt CNCF Inkubačníon, který se snaží usnadnit automatické škálování aplikací.

Poznámka:

KEDA je opensourcová technologie, která není podporována podpora Azure a musí ji provozovat zákazníci.

Automatické škálování na základě prostředků

Kubernetes umožňuje automaticky škálovat bránu v místním prostředí na základě využití prostředků pomocí horizontálního automatického škálování podů. Umožňuje definovat prahové hodnoty procesoru a paměti a počet replik pro horizontální navýšení nebo snížení kapacity.

Alternativou je použití automatického škálování založeného na událostech Kubernetes (KEDA), které umožňuje škálovat úlohy na základě různých škálovacích nástrojů, včetně procesoru a paměti.

Tip

Pokud už ke škálování dalších úloh používáte KEDA, doporučujeme použít KEDA jako jednotný automatický škálování aplikací. Pokud tomu tak není, důrazně doporučujeme spoléhat se na nativní funkce Kubernetes prostřednictvím horizontálního automatického škálování podů.

Automatické škálování založené na provozu

Kubernetes neposkytuje předefinovaný mechanismus automatického škálování založeného na provozu.

Automatické škálování řízené událostmi Kubernetes (KEDA) nabízí několik způsobů, jak vám může pomoct s automatickým škálováním založeným na provozu:

Zálohování konfigurace

Nakonfigurujte místní svazek úložiště pro kontejner brány v místním prostředí, aby mohl zachovat záložní kopii nejnovější stažené konfigurace. Pokud je připojení vypnuté, může svazek úložiště po restartování použít záložní kopii. Cesta připojení svazku musí být /apim/config a musí být vlastněna ID 1001skupiny . Podívejte se na příklad na GitHubu. Další informace o úložišti v Kubernetes najdete na webu Kubernetes. Pokud chcete změnit vlastnictví připojené cesty, podívejte se na securityContext.fsGroup nastavení na webu Kubernetes.

Poznámka:

Informace o chování brány v místním prostředí v případě dočasného výpadku připojení Azure najdete v přehledu brány v místním prostředí.

Značka image kontejneru

Soubor YAML poskytnutý na webu Azure Portal používá nejnovější značku. Tato značka vždy odkazuje na nejnovější verzi image kontejneru brány v místním prostředí.

Zvažte použití konkrétní značky verze v produkčním prostředí, abyste se vyhnuli neúmyslnému upgradu na novější verzi.

Můžete si stáhnout úplný seznam dostupných značek.

Tip

Při instalaci pomocí Nástroje Helm je označování imagí optimalizované pro vás. Verze aplikace Chartu Helm připne bránu na danou verzi a nespoléhá na latestni .

Přečtěte si další informace o tom, jak nainstalovat bránu služby API Management v místním prostředí v Kubernetes s Helmem.

Prostředky kontejneru

Ve výchozím nastavení soubor YAML zadaný na webu Azure Portal nezadá požadavky na prostředky kontejneru.

Není možné spolehlivě předpovědět a doporučit množství prostředků procesoru a paměti pro jednotlivé kontejnery a počet replik potřebných pro podporu konkrétní úlohy. Hraje se mnoho faktorů, například:

  • Konkrétní hardware, na kterém je cluster spuštěný.
  • Přítomnost a typ virtualizace
  • Počet a rychlost souběžných klientských připojení
  • Frekvence požadavků.
  • Druh a počet nakonfigurovaných zásad
  • Velikost datové části a informace o tom, jestli jsou datové části v vyrovnávací paměti nebo streamované.
  • Latence back-endové služby

Jako výchozí bod doporučujeme nastavit požadavky na prostředky na dvě jádra a 2 GiB. Na základě výsledků proveďte zátěžový test a vertikálně navyšte nebo navyšte nebo dolů nebo dolů.

Vlastní názvy domén a certifikáty SSL

Pokud používáte vlastní názvy domén pro koncové body služby API Management, zejména pokud pro koncový bod správy používáte vlastní název domény, budete možná muset aktualizovat hodnotu config.service.endpoint v< souboru gateway-name.yaml>, aby se výchozí název domény nahradil vlastním názvem domény. Ujistěte se, že koncový bod správy je přístupný z podu brány v místním prostředí v clusteru Kubernetes.

Pokud v tomto scénáři certifikát SSL používaný koncovým bodem pro správu není podepsaný dobře známým certifikátem certifikační autority, musíte se ujistit, že je certifikát certifikační autority důvěryhodný podem brány v místním prostředí.

Poznámka:

S místní bránou v2 poskytuje api Management nový koncový bod konfigurace: <apim-service-name>.configuration.azure-api.net. Pro tento koncový bod se podporují vlastní názvy hostitelů a místo výchozího názvu hostitele je možné použít.

Zásady DNS

Překlad názvů DNS hraje důležitou roli ve schopnosti brány v místním prostředí připojit se k závislostem v Azure a odesílat volání rozhraní API do back-endových služeb.

Soubor YAML poskytnutý na webu Azure Portal použije výchozí zásady ClusterFirst . Tato zásada způsobí, že požadavky na překlad názvů nepřeloží DNS clusteru na nadřazený server DNS, který je zděděný z uzlu.

Další informace o překladu názvů v Kubernetes najdete na webu Kubernetes. Zvažte přizpůsobení zásad DNS nebo konfigurace DNS podle potřeby pro vaše nastavení.

Zásady externího provozu

Soubor YAML zadaný na webu Azure Portal nastaví externalTrafficPolicy pole pro objekt služby na Local. Tím se zachová IP adresa volajícího (přístupná v kontextu požadavku) a zakáže vyrovnávání zatížení mezi uzly, což eliminuje směrování sítě způsobené. Mějte na paměti, že toto nastavení může způsobit asymetrickou distribuci provozu v nasazeních s nerovným počtem podů brány na uzel.

Vysoká dostupnost

Brána v místním prostředí je klíčovou součástí infrastruktury a musí být vysoce dostupná. K selhání ale může dojít.

Zvažte ochranu brány v místním prostředí před přerušením.

Tip

Při instalaci pomocí nástroje Helm můžete snadno povolit plánování s vysokou dostupností povolením highAvailability.enabled možnosti konfigurace.

Přečtěte si další informace o tom, jak nainstalovat bránu služby API Management v místním prostředí v Kubernetes s Helmem.

Ochrana před selháním uzlu

Pokud chcete zabránit ovlivnění kvůli selhání datového centra nebo uzlu, zvažte použití clusteru Kubernetes, který používá zóny dostupnosti k dosažení vysoké dostupnosti na úrovni uzlu.

Zóny dostupnosti umožňují naplánovat pod brány v místním prostředí na uzlech rozložených napříč zónami pomocí:

Poznámka:

Pokud používáte službu Azure Kubernetes Service, přečtěte si, jak používat zóny dostupnosti v tomto článku.

Ochrana před přerušením podu

Pody můžou být přerušené z různých důvodů, jako je ruční odstranění podů, údržba uzlů atd.

Zvažte použití rozpočtů přerušení podů k vynucení minimálního počtu podů, které budou v daném okamžiku k dispozici.

Proxy server HTTP

Brána v místním prostředí poskytuje podporu proxy serverů HTTP pomocí tradičních HTTP_PROXYHTTPS_PROXY a NO_PROXY proměnných prostředí.

Po nakonfigurování brána v místním prostředí automaticky použije proxy server pro všechny odchozí požadavky HTTP(S) na back-endové služby.

Od verze 2.1.5 nebo vyšší poskytuje brána v místním prostředí pozorovatelnost související s proxy serverem požadavků:

Poznámka:

Kvůli známému problému s proxy servery HTTP používajícím základní ověřování se ověřování seznamu odvolaných certifikátů (CRL) nepodporuje. Další informace najdete v tématu Nastavení brány v místním prostředí, kde najdete informace o tom, jak ho správně nakonfigurovat.

Upozorňující

Ujistěte se, že jsou splněné požadavky na infrastrukturu a že se k nim brána v místním prostředí může stále připojovat nebo že některé funkce nebudou správně fungovat.

Místní protokoly a metriky

Brána v místním prostředí odesílá telemetrii do služby Azure Monitor a Aplikace Azure Přehledy podle nastavení konfigurace v přidružené službě API Management. Když dojde k dočasné ztrátě připojení k Azure , přeruší se tok telemetrie do Azure a po dobu výpadku se data ztratí.

Zvažte použití služby Azure Monitor Container Přehledy k monitorování kontejnerů nebo nastavení místního monitorování, abyste zajistili možnost sledovat provoz rozhraní API a zabránit ztrátě telemetrie během výpadků připojení Azure.

Obor názvů

Obory názvů Kubernetes pomáhají rozdělit jeden cluster mezi více týmů, projektů nebo aplikací. Obory názvů poskytují obor názvů pro prostředky a názvy. Můžou být přidružené k kvótě prostředků a zásadám řízení přístupu.

Azure Portal poskytuje příkazy pro vytvoření prostředků brány v místním prostředí ve výchozím oboru názvů. Tento obor názvů se vytvoří automaticky, existuje v každém clusteru a nedá se odstranit. Zvažte vytvoření a nasazení brány v místním prostředí do samostatného oboru názvů v produkčním prostředí.

Počet replik

Minimální počet replik vhodných pro produkční prostředí je tři, nejlépe v kombinaci s plánováním instancí s vysokou dostupností.

Ve výchozím nastavení se brána v místním prostředí nasazuje se strategií nasazení RollingUpdate. Zkontrolujte výchozí hodnoty a zvažte explicitní nastavení polí maxUnavailable a maxSurge , zejména pokud používáte vysoký počet replik.

Výkon

Kvůli zvýšení výkonu doporučujeme omezit protokoly kontejnerů na upozornění (warn). Další informace najdete v našich referenčních informacích ke konfiguraci brány v místním prostředí.

Omezování požadavků

Omezení požadavků v bráně v místním prostředí je možné povolit pomocí zásad rychlosti nebo omezení rychlosti podle klíče služby API Management. Nakonfigurujte počty omezení rychlosti pro synchronizaci mezi instancemi brány napříč uzly clusteru tak, že v nasazení Kubernetes zobrazíte následující porty pro zjišťování instancí:

  • Port 4290 (UDP) pro synchronizaci omezování rychlosti
  • Port 4291 (UDP) pro odesílání prezenčních signálů do jiných instancí

Poznámka:

Počty omezení rychlosti v bráně v místním prostředí je možné nakonfigurovat tak, aby se synchronizovaly místně (mezi instancemi bran napříč uzly clusteru), například prostřednictvím nasazení chartu Helm pro Kubernetes nebo pomocí šablon nasazení webu Azure Portal. Počty omezení rychlosti se ale nesynchronizují s jinými prostředky brány nakonfigurovanými v instanci služby API Management, včetně spravované brány v cloudu.

Zabezpečení

Brána v místním prostředí je schopná v Kubernetes běžet jako ne root, což zákazníkům umožňuje bezpečně spouštět bránu.

Tady je příklad kontextu zabezpečení pro kontejner brány v místním prostředí:

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

Upozorňující

Spuštění brány v místním prostředí se systémem souborů jen pro čtení (readOnlyRootFilesystem: true) se nepodporuje.

Upozorňující

Pokud používáte místní certifikáty certifikační autority, musí brána v místním prostředí běžet s ID uživatele (UID), 1001 aby mohla spravovat certifikáty certifikační autority, jinak se brána nespustí.

Další kroky