Sdílet prostřednictvím

Architektura mikroslužeb ve službě Azure Kubernetes Service

Microsoft Entra ID
Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Spravovaný Redis
Azure Pipelines
Azure Monitor

Tato architektura ukazuje aplikaci mikroslužeb nasazenou do služby Azure Kubernetes Service (AKS). Popisuje základní konfiguraci AKS, kterou můžete použít jako výchozí bod pro většinu nasazení. Tento článek předpokládá, že máte základní znalosti Kubernetes. Zdůrazňuje aspekty infrastruktury a operací vývojářů (DevOps) správy mikroslužeb v AKS. Pro produkční nasazení tato architektura doporučuje jako síťové řešení používat Azure CNI využívající Cilium. Tato služba poskytuje lepší výkon, integrované vynucení zásad sítě a lepší pozorovatelnost prostřednictvím datové roviny založené na rozšířeném filtru paketů Berkeley (eBPF). Další informace o návrhu mikroslužeb najdete v tématu návrh architektury mikroslužeb.

Architecture

diagram znázorňující mikroslužby v referenční architektuře AKS

Helm je ochranná známka nadace CLOUD Native Computing Foundation (CNCF). Použití této značky neznamená žádné doporučení.

Stáhněte si soubor aplikace Visio s touto architekturou.

Příklad pokročilejší mikroslužby založené na základní architektuře AKS najdete v pokročilé architektuře mikroslužeb AKS.

Tok dat

Tento tok požadavku implementuje vzory návrhu cloudu pro zákazníky vydavatele, konkurující zákazníky a směrování brány.

Následující tok dat odpovídá předchozímu diagramu:

  1. Klientská aplikace odešle datovou část JSON přes HTTPS na veřejný plně kvalifikovaný název domény (FQDN) zátěžového vyvažovače (spravovaný kontroler vstupu) pro naplánování vyzvednutí dronu.

    • Spravovaný kontroler příchozího přenosu dat směruje požadavek do mikroslužby příjmu dat.

    • Mikroslužba příjmu dat zpracovává žádosti o doručení a zařadí do fronty služby Azure Service Bus.

  2. Mikroslužba pracovního postupu provede následující akce:

    • Využívá informace o zprávě z fronty zpráv služby Service Bus.

    • Odešle požadavek HTTPS do mikroslužby doručení, která předává data do externího úložiště dat ve službě Azure Managed Redis.

    • Odešle požadavek HTTPS do mikroslužby plánovače dronů.

    • Odešle požadavek HTTPS do mikroslužby balíčku, která předává data do externího úložiště dat v MongoDB.

  3. Požadavek HTTPS GET vrátí stav doručení. Tento požadavek prochází kontrolerem spravovaného příchozího přenosu dat do mikroslužby pro doručování. Pak mikroslužba pro doručování čte data ze spravovaného Redis Azure.

Components

  • AKS je spravovaná služba Kubernetes, která hostuje a orchestruje kontejnery mikroslužeb. V této architektuře poskytuje AKS platformu runtime pro nasazení, škálování a správu mikroslužeb aplikace pro doručování pomocí dronů.

  • Azure CNI využívající Cilium je doporučené síťové řešení pro přímé připojení k virtuální síti Azure. V této architektuře přiřazuje IP adresy z virtuální sítě k podům a poskytuje integrované možnosti zásad sítě a viditelnost provozu.

  • Server příchozího přenosu dat zveřejňuje trasy HTTP a HTTPS službám v clusteru. V této architektuře se spravovaný kontroler příchozího přenosu dat založený na NGINX používá prostřednictvím doplňku směrování aplikací. Kontroler příchozího přenosu dat implementuje bránu rozhraní API vzor pro mikroslužby.

  • Externí úložiště dat, jako je Azure SQL Database nebo Azure Cosmos DB, používají bezstavové mikroslužby k zápisu dat a dalších informací o stavu. V této architektuře slouží Azure Cosmos DB, Azure Managed Redis, Azure DocumentDB a Service Bus jako úložiště dat nebo místa pro uložení stavu.

  • Microsoft Entra ID je cloudová služba pro správu identit a přístupu, která poskytuje možnosti ověřování a autorizace pro cluster AKS a nasazené úlohy. AKS vyžaduje integraci s Microsoft Entra ID, která poskytuje spravovanou identitu pro přístup ke službě Azure Container Registry a zřizování prostředků Azure, jako jsou nástroje pro vyrovnávání zatížení a spravované disky. Každá úloha nasazená v clusteru AKS vyžaduje identitu pro přístup k prostředkům chráněným microsoftem Entra, jako je Azure Key Vault a Microsoft Graph. Tato architektura využívá ID úlohy Microsoft Entra k integraci s Kubernetes a poskytování zabezpečených identit pro úlohy. Alternativně můžete pro ověřování úloh použít spravované identity nebo přihlašovací údaje aplikace.

  • Container Registry je spravovaná služba, která může ukládat privátní image kontejnerů, které jsou nasazené do clusteru. AKS se může ověřit pomocí služby Container Registry pomocí své identity Microsoft Entra. Image kontejnerů mikroslužeb se sestavují a odsílají do služby Container Registry. V této architektuře Container Registry ukládá privátní image kontejnerů pro mikroslužby, které se nasadí do clusteru AKS.

  • azure Pipelines je součástí sady Azure DevOps a spouští automatizované sestavení, testy a nasazení. V prostředích mikroslužeb se důrazně doporučuje přístup kontinuální integrace a průběžného nasazování (CI/CD ). Různé týmy můžou nezávisle vytvářet a nasazovat mikroslužby do AKS pomocí Azure Pipelines. V této architektuře Azure Pipelines sestaví a nasadí mikroslužby doručování pomocí dronů do AKS.

  • Helm je správce balíčků pro Kubernetes, který poskytuje mechanismus pro seskupování a standardizaci objektů Kubernetes do jedné jednotky, kterou můžete publikovat, nasazovat, verze a aktualizovat. V této architektuře Helm balí mikroslužby doručování pomocí dronů k nasazení do AKS.

  • Azure Monitor je monitorovací platforma, která shromažďuje a ukládá metriky a protokoly, telemetrii aplikací a metriky platformy pro služby Azure. V této architektuře se Azure Monitor integruje s AKS za účelem shromažďování metrik z kontrolerů, uzlů a kontejnerů.

  • Application Insights je nástroj pro monitorování výkonu, který monitoruje mikroslužby a kontejnery. Může poskytovat pozorovatelnost v mikroslužbách, mezi které patří tok provozu, kompletní latence a procento chyb. Může zobrazit stav mikroslužeb a vztahů mezi nimi na jedné mapě aplikace. V této architektuře Application Insights monitoruje stav a výkon mikroslužeb doručování pomocí dronů a zobrazuje jejich vztahy na mapě aplikace.

Alternatives

Azure Container Apps je spravovaná bezserverová platforma, která poskytuje prostředí založené na Kubernetes bez nutnosti správy infrastruktury. Slouží jako jednodušší alternativa K AKS pro hostování mikroslužeb, pokud nepotřebujete přímý přístup k Kubernetes nebo jeho rozhraním API a nevyžaduje kontrolu nad infrastrukturou clusteru.

Místo spravované brány příchozího přenosu dat v AKS můžete použít alternativy, jako je Application Gateway for Containers, brána příchozího přenosu dat Istio nebo jiná řešení než Microsoft. Další informace najdete v tématu Příchozí přenos dat v AKS.

Image kontejnerů můžete ukládat do registrů kontejnerů jiných než Microsoftu, jako je Docker Hub.

V případě sítí tato architektura doporučuje Azure CNI využívající Cilium pro jeho výkon a integrované vynucování zásad, a alternativně lze v konkrétních scénářích použít síťová řešení, jako je Azure CNI Overlay.

Důležité

Pokud ve své architektuře mikroslužeb vyžadujete uzly Windows, projděte si aktuální omezení jen pro Linux a naplánujte vhodné plány pro smíšené fondy operačního systému. Další informace najdete v tématu omezení Azure CNI poháněného technologií Cilium.

U mikroslužeb, které musí udržovat informace o stavu, poskytuje Dapr abstraktní vrstvu pro správu stavu mikroslužeb.

Pomocí GitHub Actions můžete vytvářet a nasazovat mikroslužby nebo zvolit řešení CI/CD od jiných společností než Microsoft, jako je Jenkins.

Pozorovatelnost mikroslužeb lze dosáhnout pomocí alternativních nástrojů, jako je Kiali.

Podrobnosti scénáře

Fiktivní společnost s názvem Fabrikam, Inc., spravuje flotilu letadel dronů. Firmy se zaregistrují ve službě a uživatelé si mohou vyžádat dron, aby si vyzvedli zboží k dodání. Když zákazník naplánuje vyzvednutí, back-endový systém přiřadí dron a upozorní uživatele odhadovanou dobou doručení. Když probíhá doručování, může zákazník sledovat polohu dronů s nepřetržitě aktualizovanou odhadovanou dobou doručení.

Potenciální případy použití

Při návrhu složitých aplikací založených na mikroslužbách v AKS použijte následující osvědčené postupy:

  • Složité webové aplikace
  • Obchodní logika vyvinutá pomocí principů návrhu mikroslužeb

Considerations

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace najdete v tématu rozhraní Microsoft Azure Well-Architected Framework.

Design

Tato referenční architektura se zaměřuje na mikroslužby, ale řada doporučených postupů se vztahuje na jiné úlohy, které běží v AKS.

Microservices

Mikroslužba je volně svázaná, nezávisle nasaditelná jednotka kódu. Mikroslužby obvykle komunikují prostřednictvím dobře definovaných rozhraní API a jsou zjistitelné prostřednictvím určité formy zjišťování služeb. Objekt služby Kubernetes představuje typický způsob modelování mikroslužeb v Kubernetes.

Úložiště dat

V architektuře mikroslužeb by služby neměly sdílet řešení úložiště dat. Každá služba by měla spravovat vlastní datovou sadu, aby se zabránilo skrytým závislostem mezi službami. Oddělení dat pomáhá vyhnout se neúmyslnému párování mezi službami. K tomuto procesu může dojít, když služby sdílejí stejná podkladová schémata dat. Když služby spravují svá vlastní úložiště dat, můžou pro své konkrétní požadavky použít správné úložiště dat. Další informace najdete v tématu Aspekty dat pro mikroslužby.

Vyhněte se ukládání trvalých dat v místním úložišti clusteru, protože tato metoda sváže data s uzlem. Místo toho použijte externí službu, jako je SQL Database nebo Azure Cosmos DB. Další možností je připojit trvalý datový svazek k řešení pomocí Azure Disk Storage nebo Azure Files. Další informace najdete v tématu Možnosti úložiště pro aplikace v AKS.

Sítě a zásady sítě

V případě nasazení produkčních mikroslužeb v AKS použijte jako síťové řešení Azure CNI využívající Cilium . Tento přístup poskytuje několik výhod pro architektury mikroslužeb:

  • Výkon a škálovatelnost: Rovina dat založená na protokolu eBPF zlepšuje výkon směrování služeb a podporuje větší clustery s nižší latencí v porovnání s tradičními síťovými řešeními.

  • Vynucení zásad sítě: Cilium vynucuje prostředky Kubernetes NetworkPolicy bez nutnosti samostatného modulu zásad sítě, jako je Azure Network Policy Manager nebo Calico. Tato integrace zjednodušuje konfiguraci clusteru a snižuje provozní režii.

  • Pozorovatelnost: Rovina dat eBPF poskytuje přehled o síťovém provozu, včetně dotazů DNS (Domain Name System), toků mezi pody a komunikace mezi službami. Tato viditelnost pomáhá řešit potíže s interakcemi mikroslužeb a identifikovat kritické body výkonu.

  • Flexibilní správa IP adres: Azure CNI využívající Cilium podporuje modely přiřazení IP adres virtuální sítě i překrytí podů na základě požadavků na architekturu sítě vaší úlohy.

Při implementaci zásad sítě pro mikroslužby postupujte podle principu architektury nulové důvěryhodnosti tím, že explicitně definujete, které služby spolu můžou vzájemně komunikovat. Začněte s politikou "deny-all" a selektivně povolte pouze nezbytný síťový provoz mezi mikroslužbami. Další informace najdete v tématu Osvědčené postupy pro zásady sítě v AKS.

brána rozhraní API

Brány rozhraní API představují obecný vzor návrhu mikroslužeb. Brána rozhraní API se nachází mezi externími klienty a mikroslužbami. Brána slouží jako reverzní proxy server a směruje požadavky klientů do mikroslužeb. Brána rozhraní API může také provádět různé křížové úlohy, jako je ověřování, ukončení protokolu SSL (Secure Sockets Layer) a omezování rychlosti. Další informace najdete v následujících zdrojích informací:

V Kubernetes zpracovává kontroler příchozího přenosu dat především funkce brány rozhraní API. Vstup a kontroler vstupu spolupracují na provádění následujících akcí:

  • Směrujte požadavky klientů na správné back-endové mikroslužby. Toto směrování poskytuje klientům jeden koncový bod a pomáhá oddělit klienty od služeb.

  • Agregujte více požadavků do jednoho požadavku, abyste snížili chattnost mezi klientem a back-endem.

  • Odlehčení funkcionality z back-endových služeb, jako je ukončení spojení SSL, ověřování, omezení IP adres nebo omezování rychlosti klienta (označované jako omezování).

Existují kontrolery příchozího přenosu dat pro reverzní proxy servery, mezi které patří NGINX, HAProxy, Traefik a Azure Application Gateway. AKS poskytuje několik možností spravovaného příchozího přenosu dat. Můžete si vybrat ze spravovaného kontroleru příchozího přenosu dat založeného na NGINX prostřednictvím doplňku pro směrování aplikací nebo služby Application Gateway pro kontejnery. Nebo jako kontroler příchozího přenosu dat můžete zvolit bránu příchozího přenosu dat Istio. Další informace najdete v tématu Příchozí přenos dat v AKS.

Kubernetes nahradil prostředky příchozího přenosu dat pokročilejším a všestrannějším rozhraním GATEWAY API. Ingress kontrolery a Gateway API jsou objekty Kubernetes, které spravují směrování a vyrovnávání zatížení. Rozhraní API brány je navrženo jako generické, výrazné, rozšiřitelné a orientované na role. Představuje moderní sadu API pro definici pravidel směrování na úrovni 4 a 7 v Kubernetes.

Kontroler příchozího přenosu dat funguje jako hraniční směrovač nebo reverzní proxy server. Reverzní proxy server je potenciální kritický bod nebo kritický bod selhání, proto doporučujeme nasadit aspoň dvě repliky, které vám pomůžou zajistit vysokou dostupnost.

Kdy zvolit kontrolery příchozího přenosu dat nebo rozhraní API brány

Prostředky příchozího přenosu dat jsou vhodné pro následující případy použití:

  • Kontrolery příchozího přenosu dat jsou snadno nastavené a jsou vhodné pro menší a méně složitá nasazení Kubernetes, která upřednostňují snadnou konfiguraci.

  • Pokud máte v clusteru Kubernetes nakonfigurované kontrolery příchozího přenosu dat a efektivně splňují vaše požadavky, nemusíte okamžitě přejít na rozhraní API brány Kubernetes.

Pokud platí následující faktory, použijte rozhraní API brány:

  • Při řešení složitých konfigurací směrování, rozdělení provozu a pokročilých strategií správy provozu. Prostředky směrování rozhraní API brány Kubernetes poskytují flexibilitu potřebnou v těchto případech.

  • Pokud požadavky na síť vyžadují vlastní řešení nebo integraci modulů plug-in jiných společností než Microsoft. Přístup rozhraní API brány Kubernetes založený na vlastních definicích prostředků může poskytovat rozšířenou rozšiřitelnost.

Reliability

Spolehlivost pomáhá zajistit, aby vaše aplikace splňovala závazky, které jste pro své zákazníky udělali. Další informace najdete v kontrolním seznamu pro kontrolu návrhu pro spolehlivost.

Dělení mikroslužeb

K uspořádání služeb v rámci clusteru použijte obory názvů. Každý objekt v clusteru Kubernetes patří do oboru názvů. Je vhodné použít obory názvů k uspořádání prostředků v clusteru.

Obory názvů pomáhají zabránit kolizím názvů. Když do stejného clusteru nasadí více týmů mikroslužby, může se jednat o stovky mikroslužeb, bude jejich správa v jednom oboru názvů obtížná. Obory názvů také umožňují provádět následující akce:

  • Použijte omezení prostředků na obor názvů tak, aby celková sada podů přiřazených k danému oboru názvů nemohla překročit kvótu prostředků oboru názvů.

  • Použijte zásady na úrovni oboru názvů, které zahrnují řízení přístupu na základě role (RBAC) a zásady zabezpečení.

Když několik týmů vyvíjí a nasazuje mikroslužby, poskytují obory názvů pohodlný mechanismus pro řízení oblastí, do kterých se každý tým může nasadit. Například zásady RBAC Kubernetes udělují vývojovému týmu A přístup pouze k oboru názvů A a udělují vývojovému týmu B přístup pouze k oboru názvů B.

Pro architekturu mikroslužeb zvažte uspořádání mikroslužeb do ohraničených kontextů a vytváření oborů názvů pro každý ohraničený kontext. Například všechny mikroslužby související s kontextem Plnění objednávky mohou být zařazeny do stejného prostoru jmen. Případně vytvořte obor názvů pro každý vývojový tým.

Umístěte služby utility do vlastního samostatného oboru názvů. Můžete například nasadit monitorovací nástroje clusteru, jako je Elasticsearch a Prometheus, do oboru názvů monitorování.

Sondy stavu

Kubernetes definuje tři typy sond stavu, které může pod vystavit:

  • sonda připravenosti: říká Kubernetes, jestli je pod připravený přijímat požadavky.

  • sonda liveness: Říká Kubernetes, jestli se má pod odebrat a jestli se má spustit nová instance.

  • sonda spuštění: říká Kubernetes, jestli je pod spuštěný.

Pokud chcete porozumět sondám, nejprve zkontrolujte, jak služba funguje v Kubernetes. Služba má selektor popisků, který odpovídá sadě nula nebo více podů. Kubernetes vyrovnává provoz do podů, které odpovídají selektoru. Provoz přijímají pouze pody, které se úspěšně spustí a jsou v pořádku. Pokud dojde k chybovému ukončení kontejneru, Kubernetes ukončí pod a naplánuje nahrazení.

Někdy pod není připravený přijímat síťový provoz, i když se úspěšně spustí. Můžou se například provádět úlohy inicializace, například když aplikace, která běží v kontejneru, načte data do paměti nebo čte konfigurační soubory. Pro tyto pomalé kontejnery můžete použít spouštěcí sondu. Tento přístup pomáhá zabránit tomu, aby je Kubernetes ukončoval dříve, než budou mít šanci je plně inicializovat.

Sondy živosti kontrolují, jestli pod běží, ale nefunguje správně a potřebuje restart. Pokud například kontejner zpracovává požadavky HTTP, ale najednou přestane reagovat bez chybového ukončení, sonda živosti detekuje tuto situaci a aktivuje restartování podu. Pokud nastavíte sondu aktivity, zjistí, že kontejner nereaguje, a vyzve Kubernetes, aby restartoval pod, pokud kontejner opakovaně selže.

Při návrhu sond pro mikroslužby zvažte následující body:

  • Pokud má váš kód dlouhou dobu startu, může liveness probe hlásit selhání před dokončením spuštění. Pokud chcete zpozdit spuštění sondy aktivity, použijte spouštěcí sondu nebo použijte nastavení initialDelaySeconds s sondou aktivity.

  • Sonda aktivity pomáhá pouze v případě, že restartování podu pravděpodobně obnoví stav v pořádku. Sondu živosti můžete použít ke zmírnění ztrátám paměti nebo neočekávaným zablokováním, ale nerestartujte pod, u kterého očekáváte, že znovu selže okamžitě.

  • Někdy testy připravenosti kontrolují závislé služby. Pokud má například pod závislost na databázi, může sonda zkontrolovat připojení k databázi. Tento přístup ale může způsobit neočekávané problémy. Externí služba může být dočasně nedostupná. Tato nedostupnost způsobí selhání sondy připravenosti pro všechny pody ve vaší službě, což vede k jejich odebrání z vyrovnávání zatížení. Toto odebrání vytvoří kaskádové selhání upstreamu.

    Lepším přístupem je implementovat zpracování opakování ve vaší službě, aby se služba správně zotavila z přechodných selhání. Jako alternativu může síť služby Istio implementovat zpracování opakování, odolnost proti chybám a jističe. Tento přístup vytváří odolnou architekturu, která dokáže zvládnout selhání mikroslužeb.

Při řešení potíží se stavem mikroslužeb použijte funkce pozorovatelnosti sítě v Advanced Container Networking Services. Rovina dat eBPF zachycuje podrobné informace o toku sítě mezi mikroslužbami, což vám pomůže identifikovat problémy s připojením, problémy s překladem DNS nebo chybné konfigurace zásad sítě, které by mohly ovlivnit stav služby.

Omezení prostředků

Kolize prostředků může ovlivnit dostupnost služby. Definujte omezení prostředků pro kontejnery, aby jeden kontejner nemohl zahltit prostředky clusteru, jako je paměť a procesor. U jiných než kontejnerových prostředků, jako jsou vlákna nebo síťová připojení, zvažte použití vzoru Bulkhead k izolaci prostředků.

Pomocí kvót prostředků omezte celkové prostředky povolené pro obor názvů. Toto omezení zajišťuje, že front-endové služby nevyužívají prostředky, které back-endové služby potřebují, a back-endové služby nevyužívají prostředky, které front-endové služby potřebují. Kvóty prostředků můžou pomoct přidělovat prostředky ve stejném clusteru více vývojových týmů mikroslužeb.

Zabezpečení

Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu prozabezpečení .

Šifrování TLS a SSL

V mnoha implementacích se kontroler příchozího přenosu dat používá k ukončení protokolu SSL. V rámci nasazení kontroleru příchozího přenosu dat musíte vytvořit nebo importovat certifikát TLS (Transport Layer Security). Certifikáty podepsané svým držitelem používejte jenom pro účely vývoje a testování. Další informace najdete v tématu Nastavení vlastního názvu domény a certifikátu SSL pomocí doplňku směrování aplikace.

V případě produkčních úloh získejte podepsané certifikáty od důvěryhodných certifikačních autorit.

V závislosti na zásadách vaší organizace možná budete muset certifikáty obměňovat. Key Vault můžete použít k obměně certifikátů, které mikroslužby používají. Další informace najdete v tématu Konfigurace automatické obměny certifikátů ve službě Key Vault.

Segmentace sítě a zásady

Implementujte segmentaci sítě mezi mikroslužbami pomocí prostředků Kubernetes NetworkPolicy. Když používáte Azure CNI využívající Cilium, rovina dat eBPF vynucuje zásady sítě.

Postupujte podle těchto osvědčených postupů pro zásady sítě v architekturách mikroslužeb:

  • Použijte principy nulové důvěryhodnosti. Začněte se zásadami sítě typu deny-all na úrovni oboru názvů a explicitně povolte pouze požadovaný provoz mezi mikroslužbami.

  • Segment podle ohraničeného kontextu. Vytvořte obory názvů pro každý ohraničený kontext v architektuře mikroslužeb a použijte zásady sítě pro řízení provozu mezi těmito kontexty.

  • Řízení odchozího provozu Pomocí zásad sítě omezte odchozí provoz z mikroslužeb jenom na schválené externí služby a koncové body.

  • Monitorujte efektivitu zásad. Pomocí pozorovatelných funkcí roviny dat Cilium eBPF můžete monitorovat vynucení zásad sítě a identifikovat blokovaný provoz, který může znamenat chybné konfigurace nebo problémy se zabezpečením.

RBAC

Když současně vyvíjí a nasazuje mikroslužby více týmů, můžou mechanismy AKS RBAC poskytovat podrobné řízení a filtrování uživatelských akcí. K řízení přístupu k prostředkům clusteru můžete použít Kubernetes RBAC nebo Azure RBAC s ID Microsoft Entra. Další informace najdete v tématu Možnosti přístupu a identity proAKS .

Ověřování a autorizace

Mikroslužby můžou vyžadovat, aby služby nebo uživatelé ověřili a autorizovali přístup k mikroslužbě pomocí certifikátů, přihlašovacích údajů a mechanismů RBAC. Microsoft Entra ID můžete použít k implementaci tokenů OAuth 2.0 pro autorizaci. Sítě služeb, jako je síť služby Istio , také poskytují mechanismy autorizace a ověřování pro mikroslužby, mezi které patří ověřování tokenů OAuth a směrování založené na tokenech.

Správa tajných kódů a přihlašovací údaje aplikace

Aplikace a služby často potřebují přihlašovací údaje, které jim umožňují připojit se k externím službám, jako je Azure Storage nebo SQL Database. Výzvou je zachovat tyto přihlašovací údaje v bezpečí a zabránit únikům informací.

Pro prostředky Azure používejte spravované identity, pokud je to možné. Spravovaná identita je jako jedinečné ID aplikace nebo služby uložené v Microsoft Entra ID. Tato identita se používá k ověřování ve službě Azure. Aplikace nebo služba má pro něj vytvořený instanční objekt v MICROSOFT Entra ID a ověřuje se pomocí tokenů OAuth 2.0. Kód, který se spouští v rámci procesu, může token transparentně získat. Tento přístup vám pomůže zajistit, abyste nemuseli ukládat žádná hesla ani připojovací řetězce. Pokud chcete používat spravované identity, můžete přiřadit identity Microsoft Entra jednotlivým podům v AKS pomocí ID úlohy Microsoft Entra.

I když používáte spravované identity, možná budete muset uložit některé přihlašovací údaje nebo jiné tajné kódy aplikace. Toto úložiště je nezbytné pro služby Azure, které nepodporují spravované identity, služby jiných společností než Microsoft nebo klíče rozhraní API. K bezpečnějšímu ukládání tajných kódů můžete použít následující možnosti:

Pomocí řešení, jako je Key Vault, získáte následující výhody:

  • Centralizovaná kontrola tajných kódů
  • Šifrování uložených tajemství v klidovém stavu
  • Centralizovaná správa klíčů
  • Řízení přístupu k tajným kódům
  • Správa životního cyklu klíčů
  • Auditing

Tato architektura používá spravovanou identitu pro mikroslužby k ověření ve službě Key Vault a přístup k tajným kódům.

Zabezpečení kontejnerů a orchestrátoru

Následující doporučené postupy vám můžou pomoct zabezpečit pody a kontejnery:

  • Monitorujte hrozby. Monitorování hrozeb pomocí Microsoft Defenderu for Containers nebo jiných funkcí než Microsoftu. Pokud hostujete kontejnery na virtuálním počítači, použijte Microsoft Defenderu pro servery nebo funkci jiné společnosti než Microsoft. Protokoly můžete také integrovat z řešení monitorování kontejnerů ve službě Azure Monitor do služby Microsoft Sentinel nebo existujícího řešení pro správu informací o zabezpečení a událostí (SIEM).

  • Monitorování ohrožení zabezpečení Průběžně monitorujte image a spuštěné kontejnery kvůli známým ohrožením zabezpečení pomocí Microsoft Defenderu pro cloud nebo řešení jiného než Microsoftu.

  • Automatizace oprav imagí Pomocí úloh Container Registry můžete automatizovat opravy obrazů. Image kontejneru se sestavuje z vrstev. Základní vrstvy zahrnují image operačního systému a image architektury aplikací, jako jsou ASP.NET Core nebo Node.js. Základní image se obvykle vytvářejí v upstreamu od vývojářů aplikací a ostatní správci projektů je spravují. Když jsou tyto image opravené v upstreamu, musíte aktualizovat, testovat a znovu nasadit vlastní image, abyste nenecháli žádná známá ohrožení zabezpečení. Úlohy služby Container Registry vám můžou pomoct tento proces automatizovat.

  • Ukládání imagí v důvěryhodném privátním registru K ukládání imagí použijte důvěryhodný privátní registr, jako je Container Registry nebo Docker Trusted Registry. Pomocí ověřovacího webhooku přístupu v Kubernetes můžete zajistit, aby pody mohly načítat jenom obrázky z důvěryhodného registru.

  • Použijte princip nejnižších oprávnění. Nespouštět kontejnery v privilegovaném režimu. Privilegovaný režim poskytuje kontejneru přístup ke všem zařízením na hostiteli. Pokud je to možné, vyhněte se spouštění procesů jako kořenové uvnitř kontejnerů. Kontejnery neposkytují celkovou izolaci z hlediska zabezpečení, takže je lepší spustit proces kontejneru jako neprivilegovaný uživatel.

Důležité informace o nasazení CI/CD

Zvažte následující cíle robustního procesu CI/CD pro architekturu mikroslužeb:

  • Každý tým může vytvářet a nasazovat služby, které vlastní nezávisle, aniž by to ovlivnilo nebo nenarušilo jiné týmy.

  • Před nasazením nové verze služby do produkčního prostředí se nasadí do vývojového, testovacího a Q&prostředí A pro ověření. V každé fázi se vynucují brány kvality.

  • Vedle předchozí verze je možné nasadit novou verzi služby.

  • Jsou zavedeny dostatečné zásady řízení přístupu.

  • U kontejnerizovaných úloh můžete důvěřovat imagím kontejnerů, které jsou nasazené do produkčního prostředí.

Další informace o problémech najdete v tématu CI/CD pro architektury mikroslužeb.

Použití sítě služeb, jako je Istio, může pomoct s procesy CI/CD, jako jsou kanárské nasazení, testování mikroslužeb a fázované zavedení s rozdělením provozu na základě procent.

Další informace o konkrétních doporučeních a osvědčených postupech najdete v tématu Sestavení kanálu CI/CD pro mikroslužby v Kubernetes pomocí Azure DevOps a Helm.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu proOptimalizace nákladů .

K odhadu nákladů použijte cenovou kalkulačku Azure.

U některých služeb používaných v této architektuře zvažte následující body.

AKS

  • Na plánu Free nejsou žádné náklady spojené s AKS při nasazení, správě a provozu clusteru Kubernetes. Platíte jenom za instance virtuálních počítačů, úložiště a síťové prostředky, které cluster Kubernetes využívá.

  • Zvažte použití Horizontal Pod Autoscaler (HPA) k automatickému škálování mikroslužeb v závislosti na zatížení.

  • Nakonfigurujte cluster Austoscaler (CA) tak, aby škáloval uzly dovnitř nebo ven v závislosti na zatížení.

  • Zvažte použití spotových uzlů k hostování nekritických mikroslužeb.

  • Projděte si osvědčené postupy optimalizace nákladů proAKS.

  • Pokud chcete odhadnout náklady na požadované prostředky, použijte kalkulačku AKS.

Azure Load Balancer

Účtuje se vám jenom počet nakonfigurovaných pravidel vyrovnávání zatížení a odchozích přenosů. Pravidla překladu příchozích síťových adres jsou bezplatná. Za Load Balancer úrovně Standard se neúčtují žádné hodinové poplatky, pokud nejsou nakonfigurovaná žádná pravidla. Další informace najdete v tématu ceny služby Azure Load Balancer.

Azure Pipelines

Tato referenční architektura používá Azure Pipelines pro úlohy CI/CD. Azure poskytuje kanál jako samostatnou službu. Máte povolenou bezplatnou úlohu hostované Microsoftem s 1 800 minutami pro každý měsíc pro CI/CD a jednu úlohu v místním prostředí s neomezenými minutami pro každý měsíc. Za další úlohy se účtují další náklady. Další informace najdete v tématu cenách služeb Azure DevOps.

Azure Monitor

U Log Analytics se vám účtují poplatky za příjem a uchovávání dat. Další informace najdete v tématu o cenách služby Azure Monitor.

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

Tato referenční architektura zahrnuje soubory Bicep pro zřizování cloudových prostředků a jejich závislostí. Azure Pipelines můžete použít k nasazení těchto souborů Bicep a rychlému nastavení různých prostředí, jako je replikace produkčních scénářů. Tento přístup vám pomůže ušetřit náklady zřízením prostředí zátěžového testování pouze v případě potřeby.

Zvažte vytvoření struktury souboru Bicep podle kritérií izolace úloh. Úloha je obvykle definována jako libovolná jednotka funkčnosti. Můžete mít například samostatný soubor Bicep pro cluster a pak další soubor závislých služeb. Azure DevOps můžete použít k provádění CI/CD s izolací úloh, protože jednotlivé úlohy jsou přidružené a spravované vlastním týmem.

Contributors

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

Další přispěvatelé:

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další kroky