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 Load Balancer
Azure Pipelines
Azure Monitor

Tato referenční 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. Článek primárně zdůrazňuje aspekty infrastruktury a DevOps správy mikroslužeb v AKS. Další informace o návrhu mikroslužeb najdete v tématu návrh architektury mikroslužeb.

logo GitHubu. Referenční implementace této architektury je k dispozici na GitHubu.

Architektura

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.

Pokud chcete vidět příklad pokročilejší mikroslužby založené na základní architektuře AKS, podívejte se na pokročilou architekturu mikroslužeb AKS.

Pracovní postup

Tento tok požadavku implementuje odběratele vydavatele , konkurenční uživatelea směrování brány vzory návrhu cloudu.

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

  1. Klientská aplikace odešle datovou část JSON přes HTTPS do veřejného plně kvalifikovaného názvu domény nástroje pro vyrovnávání zatížení (spravovaný kontroler příchozího přenosu dat) pro naplánování vyzvednutí dronů.

    • 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:

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

    • Odešle požadavek HTTPS do mikroslužby doručování, která předává data do externího úložiště dat ve službě Azure Cache for 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 doručovací mikroslužba načte data ze služby Azure Cache for Redis.

Další informace o ukázkové aplikaci mikroslužeb naleznete v tématu referenční implementace mikroslužeb ukázky.

Součásti

  • AKS je spravovaný cluster Kubernetes hostovaný v cloudu Azure. AKS snižuje složitost a provozní režii při správě Kubernetes tím, že přesměruje většinu této odpovědnosti do Azure.

  • server příchozího přenosu dat zveřejňuje trasy HTTP(S) službám v clusteru. Referenční implementace používá spravovaný kontroler příchozího přenosu dat založený na NGINX prostřednictvím doplňku směrování aplikace. Kontroler příchozího přenosu dat implementuje bránu rozhraní API vzor pro mikroslužby.

  • externích úložišť 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. Referenční implementace používá azure Cosmos DB, Azure Cache for Redis, Azure Cosmos DB pro MongoDB a Service Bus jako úložiště dat nebo místa pro uložení stavu.

  • Microsoft Entra ID vyžaduje cluster AKS. Poskytuje spravovanou identitu, která se používá pro přístup ke službě Azure Container Registry a ke zřizování a zřizování prostředků Azure, jako jsou nástroje pro vyrovnávání zatížení a spravované disky. Úlohy nasazené v clusteru AKS také vyžadují identitu v Microsoft Entra pro přístup k prostředkům chráněným microsoftem Entra, jako je Azure Key Vault a Microsoft Graph. V této referenční architektuře ID úlohy Microsoft Entra integruje s Kubernetes a poskytuje úlohy s identitami. Pro každou úlohu můžete také použít spravované identity nebo přihlašovací údaje aplikace.

  • container Registry lze použít k ukládání privátních imagí kontejneru, které jsou nasazené do clusteru. AKS se může ověřit pomocí služby Container Registry pomocí své identity Microsoft Entra. V referenční implementaci se image kontejnerů mikroslužeb sestaví a nasdílí do služby Container Registry.

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

  • Helm je správce balíčků pro Kubernetes, který poskytuje mechanismus pro seskupování a standardizaci objektů Kubernetes do jedné jednotky, kterou je možné publikovat, nasazovat, správě verzí a aktualizovat.

  • Azure Monitor shromažďuje a ukládá metriky a protokoly, telemetrii aplikací a metriky platformy pro služby Azure. Azure Monitor se integruje s AKS a shromažďuje metriky z kontrolerů, uzlů a kontejnerů.

  • Application Insights monitoruje mikroslužby a kontejnery. Dá se použít k zajištění pozorovatelnosti mikroslužeb, což zahrnuje tok provozu, kompletní latenci a procento chyb. Stav mikroslužeb a vztahů mezi nimi je možné zobrazit na jedné mapě aplikace.

Alternativy

Azure Container Apps poskytuje spravované prostředí Kubernetes bez serveru. 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, Istio ingress Gateway 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.

Pro mikroslužby, které potřebují udržovat informace o stavu, Dapr poskytuje 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

Příklad referenční implementace mikroslužeb implementuje komponenty architektury a postupy popsané v tomto článku. V tomto příkladu fiktivní společnost s názvem Fabrikam, Inc., spravuje flotilu dronů letadel. 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í.

Cílem tohoto scénáře je ukázat osvědčené postupy pro architekturu mikroslužeb a nasazení v AKS.

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

Důležité informace

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.

Návrh

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.

Mikroslužby

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.

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 například 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. Kontroler příchozího přenosu dat a příchozího přenosu dat funguje ve spojení s:

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

  • Přesměrování zpracování funkcí z back-endových služeb, jako je ukončení protokolu 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 z spravovaného kontroleru příchozího přenosu dat založeného na NGINX prostřednictvím doplňku pro směrování aplikací Application Gateway for Containers. 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.

Objekty Kubernetes prostředků příchozího přenosu dat byly nahrazeny pokročilejším a všestrannějším rozhraním API brány Kubernetes. Kontroler příchozího přenosu dat i rozhraní API brány jsou objekty Kubernetes používané ke směrování správy provozu a vyrovnávání zatížení. Rozhraní API brány je moderní sada rozhraní API pro definování pravidel směrování L4 a L7 v Kubernetes tak, aby byla obecná, výrazná, rozšiřitelná a orientovaný na role.

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í být nutné okamžitě přejít na rozhraní API brány Kubernetes.

Měli byste použít 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. Flexibilita poskytovaná prostředky směrování rozhraní API brány Kubernetes je nezbytná.

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

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. 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ž několik týmů nasadí mikroslužby do stejného clusteru, může to být stovky mikroslužeb, bude obtížné je spravovat, pokud všechny přejdou do stejného oboru názvů. Obory názvů také umožňují:

  • 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, můžete použít obory názvů jako pohodlný mechanismus pro řízení oblastí, do kterých se každý tým může nasadit. Například vývojový tým A může mít přístup pouze k oboru názvů A a vývojovému týmu B může být udělen přístup pouze k oboru názvů B prostřednictvím zásad RBAC kubernetes .

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 ohraničeným kontextem "Plnění objednávky" můžou přecházet do stejného oboru názvů. 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 jsou 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ý.

Když uvažujete o sondách, je důležité pamatovat si, 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 nemusí být pod připravený k příjmu provozu, i když se úspěšně spustil. Můžou se například provádět úlohy inicializace, například když aplikace spuštěná v kontejneru načte data do paměti nebo přeč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 aktivity slouží ke kontrole, jestli je pod spuštěný, ale nefunguje správně a je potřeba ho restartovat. Pokud například kontejner zpracovává požadavky HTTP, ale najednou přestane reagovat bez chybového ukončení, sonda aktivity zjistí tuto událost 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 spuštění, existuje nebezpečí, že sonda aktivity hlásí 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 aktivity můžete použít ke zmírnění nevracení paměti nebo neočekávané zablokování, ale neexistuje žádný důvod k restartování podu, který se okamžitě nezdaří.

  • Někdy se sondy připravenosti používají ke kontrole závislých služeb. 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 je možné implementovat sítě služby Istio, aby se vytvořila odolná architektura, která dokáže zvládnout selhání mikroslužeb, a jako alternativu je možné implementovat zpracování opakování, odolnost proti chybám a jističe.

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-end nemůže hladovět back-endové služby pro prostředky nebo naopak. 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 je potřeba 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 organizace možná budete muset certifikáty také otočit. 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.

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 lze použít k implementaci tokenů OAuth 2.0 pro autorizační. Sítě služeb, jako je Istio také poskytují mechanismy autorizace a ověřování pro mikroslužby, které zahrnují ověřování tokenů OAuth a směrování založené na tokenech. Referenční implementace nepokrývá scénáře ověřování a autorizace mikroslužeb.

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 nevracet je.

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 spuštěný v rámci procesu může transparentně získat token. 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:

Použití řešení, jako je Key Vault, nabízí několik výhod, mezi které patří:

  • Centralizovaná kontrola tajných kódů
  • Pomáhá zajistit šifrování všech tajných kódů v klidovém stavu.
  • Centralizovaná správa klíčů
  • Řízení přístupu k tajným kódům
  • Správa životního cyklu klíčů
  • Kontrola.

Referenční implementace ukládá připojovací řetězce služby Azure Cosmos DB a další tajné kódy ve službě Key Vault. Referenční implementace 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. Kromě toho můžete integrovat protokoly z řešení monitorování kontejnerů ve službě Azure Monitor do Microsoft Sentinelu 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í K automatizaci oprav imagí použijte úlohy služby Azure Container Registry. 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, je důležité aktualizovat, testovat a znovu nasadit vlastní image, abyste nenecháli žádná známá ohrožení zabezpečení. Úlohy služby Azure 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í úplnou 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. Další aspekty jsou popsány v části Cost v rozhraní Microsoft Azure Well-Architected Framework.

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

Azure Kubernetes Service (AKS)

  • V úrovně Free nejsou spojené žádné náklady na AKS při nasazování, 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í horizontálního automatického škálování podů k automatickému škálování mikroslužeb nebo horizontálního navýšení kapacity v závislosti na zatížení.

  • Nakonfigurujte automatického škálování clusteru pro škálování uzlů nebo horizontální navýšení kapacity 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 (zátěžový vyrovnávač)

Úč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.

Kanály Azure

Tato referenční architektura používá pouze Azure Pipelines. 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

Pro Azure Monitor 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í. K nasazení těchto souborů Bicep a rychlému nastavení různých prostředí, jako je replikace produkčních scénářů, můžete použít Azure Pipelines. 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.

Nasazení tohoto scénáře

Pokud chcete nasadit referenční implementaci pro tuto architekturu, postupujte podle kroků v úložišti GitHub. Další informace najdete v tématu referenční implementace mikroslužeb AKS.

Přispěvatelé

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