Sdílet prostřednictvím

Pokyny pro spuštění samo-hostované brány na Kubernetes v produkčním prostředí

PLATÍ PRO: Vývojář | Prémie

Aby bylo možné spustit bránu hostovanou na vlastních serverech 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.

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 nakonfigurovat s novým tokenem buď ručně, nebo prostřednictvím automatizace, předtím než token vyprší.

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.

Návod

Samoobslužnou bránu můžete také nasadit do Kubernetes a povolit ověřování pro instanci služby API Management pomocí Microsoft Entra ID.

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.

Existují dva způsoby, jak horizontálně škálovat vlastní bránu:

  • 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 lokálně hostovanou bránu na základě využití prostředků pomocí Horizontálního automatizovaného škálování podů. Umožňuje definovat prahové hodnoty procesoru a paměti a počet replik pro rozšíř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.

Návod

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

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:

  • Škálování na základě metrik z Kubernetes vstupního bodu můžete provádět, pokud jsou k dispozici v systému Prometheus nebo Azure Monitor, pomocí předem připraveného škálovače.
  • Můžete nainstalovat doplněk HTTP, který je dostupný v beta verzi a škáluje se na základě počtu požadavků za sekundu.

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 skupinou s ID 1001. 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 kontejnerového obrazu

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

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.

Návod

Při instalaci pomocí Helm je označování obrazů optimalizováno pro vás. Verze aplikace Helm chartu uzamkne gateway na danou verzi a nespoléhá na latest.

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 uvedený na Azure Portalu nespecifikuje žádosti o 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 dat a jestli jsou data ve vyrovnávací paměti nebo streamovaná.
  • Latence základní služby

Jako výchozí bod doporučujeme nastavit požadavky na prostředky na dvě jádra a 2 GiB. Proveďte zátěžový test a na základě jeho výsledků zvyšte nebo snižte kapacitu, a to buď vertikálním, nebo horizontálním škálováním.

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 vconfig.service.endpoint<>, 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 samohostované brány 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 bránou hostovanou lokálně v2 poskytuje API Management nový konfigurační koncový bod: <apim-service-name>.configuration.azure-api.net. Pro tento koncový bod lze použít vlastní názvy hostitelů, které mohou nahradit výchozí název hostitele.

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ů, které nejsou vyřešeny DNS clusteru, budou předány na nadřazený DNS server, 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í zátěže mezi uzly, což eliminuje síťové přeskoky způsobené tím. 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.

Testování stavu

Použijte koncový bod sond HTTP /status-0123456789abcdef pro sondy připravenosti a životnosti ve vašich nasazeních brány. To vám pomůže směrovat provoz jenom do nasazení brány, která se úspěšně spustila a byla připravena obsluhovat provoz, nebo jsou stále responzivní.

Bez zdravotních kontrol se mohou nasazení brány spustit rychleji, ale konfigurace nemusí být ještě plně načtená, což může vést ke vzniku chyby 503 v datovém provozu.

Návod

Při instalaci pomocí Nástroje Helm jsou pro vás ve výchozím nastavení povolené sondy stavu.

Vysoká dostupnost

Brána hostovaná na vlastním serveru 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 hostované na vlastním serveru před přerušením.

Návod

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

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 nasazení podu samostatně hostované brány 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 narušené z různých důvodů, jako je ruční odstranění podů, údržba uzlů atd.

Zvažte použití Pod Disruption Budgets (rozpočtů přerušení podů) k zajištění minimálního počtu podů, které budou vždy k dispozici.

Proxy server HTTP(S)

Lokální brána poskytuje podporu pro HTTP(S) proxy server pomocí tradičních proměnných prostředí HTTP_PROXY, HTTPS_PROXY a NO_PROXY.

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 samostatně hostovaná brána pozorovatelnost související s proxy zpracováním 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.

Varování

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 hostovaná v místním prostředí odesílá telemetrii do služby Azure Monitor a Azure Application Insights 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 Insights 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.

Jmenný prostor

Jmenné prostory Kubernetes pomáhají rozdělit jeden cluster mezi více týmy, projekty nebo aplikace. Jmenné prostory poskytují obor 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ů samoobslužné brány 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í samo-hostované brány 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 rozvrhováním instancí pro vysokou dostupnost.

Ve výchozím nastavení se brána v místním prostředí nasazuje s nasazovací strategieRollingUpdate. 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

Ke zlepšení výkonu doporučujeme omezit protokoly kontejnerů na varová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í lze povolit pomocí zásady rate-limit nebo rate-limit-by-key v rámci 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 omezení rychlosti
  • Port 4291 (UDP) pro odesílání heartbeat 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 s vlastním hostováním je schopná v Kubernetes běžet jako uživatel bez oprávnění root, což zákazníkům umožňuje bezpečně provozovat bránu.

Zde je příklad kontextu zabezpečení pro kontejner samohostované brány:

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

Varování

Spuštění samostatně hostované brány se systémem souborů jen pro čtení (readOnlyRootFilesystem: true) se nepodporuje.

Varování

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í.

Související obsah

  • Last updated on