Upravit

Architektura mikroslužeb na Azure Kubernetes Service

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Pipelines
Monitor

Tato referenční architektura ukazuje aplikaci mikroslužeb nasazenou do Azure Kubernetes Service (AKS). Popisuje základní konfiguraci AKS, která může být výchozím bodem pro většinu nasazení. Tento článek předpokládá základní znalosti Kubernetes. Tento článek se zaměřuje hlavně na aspekty infrastruktury a DevOps při spouštění architektury mikroslužeb v AKS. Pokyny k návrhu mikroslužeb najdete v tématu Vytváření mikroslužeb v Azure.

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

Architektura

Diagram znázorňující referenční architekturu AKS

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

Pokud byste chtěli vidět pokročilejší příklad mikroslužeb, který je založený na standardní architektuře AKS, přečtěte si téma Architektura mikroslužeb Advanced Azure Kubernetes Service (AKS).

Pracovní postup

Tato architektura se skládá z následujících součástí.

Azure Kubernetes Service (AKS). AKS je spravovaný cluster Kubernetes hostovaný v cloudu Azure. Azure spravuje službu rozhraní API Kubernetes a stačí spravovat jenom uzly agenta.

Virtuální síť: Ve výchozím nastavení AKS vytvoří virtuální síť, ke které jsou připojené uzly agenta. Virtuální síť můžete nejprve vytvořit pro pokročilejší scénáře, což vám umožní řídit věci, jako je konfigurace podsítě, místní připojení a přidělování IP adres. Další informace najdete v tématu Konfigurace pokročilých sítí v Azure Kubernetes Service (AKS).

Příchozí přenos dat. Server příchozího přenosu dat zveřejňuje trasy HTTP(S) službám v rámci clusteru. Další informace najdete v části Brána rozhraní API níže.

Azure Load Balancer. Po vytvoření clusteru AKS je cluster připravený k použití nástroje pro vyrovnávání zatížení. Po nasazení služby NGINX se nástroj pro vyrovnávání zatížení nakonfiguruje s novou veřejnou IP adresou, která bude před vaším kontrolerem příchozího přenosu dat. Tímto způsobem nástroj pro vyrovnávání zatížení směruje internetový provoz na příchozí přenos dat.

Externí úložiště dat. Mikroslužby jsou obvykle bezstavové a stav zápisu do externích úložišť dat, jako je Azure SQL Database nebo Azure Cosmos DB.

Azure Active Directory. AKS používá identitu Azure Active Directory (Azure AD) k vytváření a správě dalších prostředků Azure, jako jsou nástroje pro vyrovnávání zatížení Azure. Azure AD se také doporučuje pro ověřování uživatelů v klientských aplikacích.

Azure Container Registry. Pomocí služby Container Registry můžete ukládat privátní image Dockeru, které jsou nasazené do clusteru. AKS se může ověřit ve službě Container Registry pomocí své identity Azure AD. AKS nevyžaduje Azure Container Registry. Můžete použít jiné registry kontejnerů, například Docker Hub. Stačí se ujistit, že registr kontejneru odpovídá smlouvě o úrovni služeb (SLA) pro vaši úlohu nebo ji překračuje.

Azure Pipelines. Azure Pipelines jsou součástí Azure DevOps Services a spouští automatizovaná sestavení, testy a nasazení. Můžete také použít řešení CI/CD třetích stran, jako je Jenkins.

Helm. Helm je správce balíčků pro Kubernetes, který umožňuje seskupit a generalizovat objekty Kubernetes do jediné jednotky, kterou je možné publikovat, nasazovat, správě verzí a aktualizovat.

Azure Monitor Azure Monitor shromažďuje a ukládá metriky a protokoly, telemetrii aplikací a metriky platformy pro služby Azure. Tato data slouží k monitorování aplikace, nastavení upozornění a řídicích panelů a k analýze původní příčiny selhání. Azure Monitor se integruje s AKS a shromažďuje metriky z kontrolerů, uzlů a kontejnerů.

Požadavky

Návrh

Tato referenční architektura se zaměřuje na architektury mikroslužeb, i když mnohé z doporučených postupů platí pro jiné úlohy spuštěné v AKS.

Mikroslužby

Mikroslužba je volně spojená, 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. Služba by měla být vždy dostupná, i když se pody pohybují. Objekt Kubernetes Service představuje přirozený způsob modelování mikroslužeb v Kubernetes.

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. Funguje jako reverzní proxy server, který směruje požadavky z klientů do mikroslužeb. Může také provádět různé průřezové úlohy, jako je ověřování, ukončení protokolu SSL a omezování rychlosti. Další informace naleznete v tématu:

V Kubernetes se funkce brány rozhraní API primárně zpracovávají kontrolerem příchozího přenosu dat. Důležité informace jsou popsané v části Příchozí přenos dat .

Ú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í sadu dat, aby nedocházelo ke skrytým závislostem mezi službami. Oddělení dat pomáhá zabránit neúmyslnému propojení mezi službami, ke kterému může dojít, když služby sdílejí stejná podkladová datová schémata. Když služby spravují svá vlastní úložiště dat, můžou také používat správné úložiště dat pro své konkrétní požadavky.

Další informace najdete v tématu Návrh mikroslužeb: Důležité informace o datech.

Vyhněte se ukládání trvalých dat v úložišti místního clusteru, protože to spojuje data s uzlem. Místo toho použijte externí službu, jako je Azure SQL Database nebo Azure Cosmos DB. Další možností je připojit trvalý datový svazek k řešení pomocí disků Azure nebo Azure Files.

Další informace najdete v tématu Možnosti úložiště pro aplikaci v Azure Kubernetes Service.

Objekt služby

Objekt Kubernetes Service poskytuje sadu funkcí, které odpovídají požadavkům mikroslužeb na zjistitelnost služeb:

  • IP adresa. Objekt Service poskytuje statickou interní IP adresu pro skupinu podů (ReplicaSet). Při vytváření nebo přesouvání podů je služba vždy dostupná na této interní IP adrese.

  • Vyrovnávání zatížení. Provoz odesílaný na IP adresu služby se vyrovná do podů.

  • Zjišťování služeb. Služba DNS Kubernetes přiřazuje interní položky DNS. To znamená, že brána rozhraní API může volat back-endovou službu pomocí názvu DNS. Stejný mechanismus lze použít pro komunikaci mezi službami. Položky DNS jsou uspořádané podle oboru názvů, takže pokud vaše obory názvů odpovídají ohraničeným kontextům, pak se název DNS služby bude mapovat přirozeně na doménu aplikace.

Následující diagram znázorňuje koncepční vztah mezi službami a pody. Skutečné mapování na IP adresy a porty koncového bodu provádí kube-proxy, síťový proxy server Kubernetes.

Diagram znázorňující služby a pody

Příchozí přenos dat

V Kubernetes může kontroler příchozího přenosu dat implementovat vzor brány rozhraní API. V takovém případě funguje kontroler příchozího přenosu dat a příchozího přenosu dat ve spojení s těmito funkcemi:

  • Směrujte požadavky klientů na pravé back-endové služ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 chytivost 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 omezení rychlosti klienta (omezování).

Příchozí přenos dat abstrahuje nastavení konfigurace proxy serveru. Potřebujete také kontroler příchozího přenosu dat, který poskytuje základní implementaci příchozího přenosu dat. Existují kontrolery příchozího přenosu dat mimo jiné pro Nginx, HAProxy, Traefik a Azure Application Gateway.

Prostředek příchozího přenosu dat můžou plnit různé technologie. Aby mohly spolupracovat, musí být nasazené jako kontroler příchozího přenosu dat uvnitř clusteru. Funguje jako hraniční směrovač nebo reverzní proxy server. Reverzní proxy server je potenciálním kritickým bodem nebo kritickým bodem selhání, proto vždy nasaďte alespoň dvě repliky pro zajištění vysoké dostupnosti.

Konfigurace proxy serveru často vyžaduje složité soubory, které může být obtížné vyladit, pokud nejste odborník. Kontroler příchozího přenosu dat tedy poskytuje pěknou abstrakci. Kontroler příchozího přenosu dat má také přístup k rozhraní Kubernetes API, takže se může inteligentně rozhodovat o směrování a vyrovnávání zatížení. Například kontroler příchozího přenosu dat Nginx obchází síťový proxy server kube-proxy.

Na druhou stranu, pokud potřebujete úplnou kontrolu nad nastavením, můžete chtít obejít tuto abstrakci a nakonfigurovat proxy server ručně. Další informace najdete v tématu Nasazení serveru Nginx nebo HAProxy do Kubernetes.

Poznámka

Pro AKS můžete také použít Azure Application Gateway pomocí kontroleru Application Gateway příchozího přenosu dat (AGIC). Azure Application Gateway může provádět směrování vrstvy 7 a ukončení protokolu SSL. Má také integrovanou podporu Firewallu webových aplikací (WAF). Pokud váš cluster AKS používá síť CNI, Application Gateway je možné nasadit do podsítě virtuální sítě clusteru nebo do jiné virtuální sítě než virtuální síť AKS, ale tyto dvě virtuální sítě musí být v partnerském vztahu. AGIC podporuje také síťový modul plug-in Kubenet. Při použití režimu Kubenet musí kontroler příchozího přenosu dat spravovat směrovací tabulku v podsíti Application Gateway, aby směroval provoz na IP adresy podů. Další informace najdete v tématu Nastavení sítě mezi Application Gateway a AKS.

Informace o službách vyrovnávání zatížení v Azure najdete v tématu Přehled možností vyrovnávání zatížení v Azure.

Šifrování TLS/SSL

V běžných implementacích se k ukončení SSL používá kontroler příchozího přenosu dat. Proto v rámci nasazení kontroleru příchozího přenosu dat musíte vytvořit certifikát TLS. Certifikáty podepsané svým držitelem používejte jenom pro účely vývoje a testování. Další informace najdete v tématu Vytvoření kontroleru příchozího přenosu dat HTTPS a použití vlastních certifikátů TLS v Azure Kubernetes Service (AKS).

V případě produkčních úloh získejte podepsané certifikáty od důvěryhodných certifikačních autorit (CA). Informace o generování a konfiguraci certifikátů Let's Encrypt najdete v tématu Vytvoření kontroleru příchozího přenosu dat se statickou veřejnou IP adresou v Azure Kubernetes Service (AKS).

V rámci zásad organizace možná budete muset certifikáty obměňovat. Informace najdete v tématu Obměna certifikátů v Azure Kubernetes Service (AKS).

Obory názvů

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ů. Když ve výchozím nastavení vytvoříte nový objekt, přejde do default oboru názvů . Je ale vhodné vytvořit obory názvů, které jsou popisnější, aby pomohly uspořádat prostředky v clusteru.

Za prvé, obory názvů pomáhají zabránit kolizím názvů. Když více týmů nasadí mikroslužby do stejného clusteru s potenciálně stovkami mikroslužeb, bude obtížné je spravovat, pokud všechny přejdou do stejného oboru názvů. Obory názvů navíc umožňují:

  • Použití 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ů, včetně RBAC a zásad zabezpečení.

Pro architekturu mikroslužeb zvažte uspořádání mikroslužeb do ohraničených kontextů a vytvoř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řejít 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 nástrojů do jejich vlastního samostatného oboru názvů. Můžete například nasadit Elasticsearch nebo Prometheus pro monitorování clusteru nebo Tiller pro Helm.

Sondy stavu

Kubernetes definuje dva typy sond stavu, které může pod vystavit:

  • Sonda připravenosti: Informuje Kubernetes, jestli je pod připravený přijímat požadavky.

  • Sonda aktivity: Říká Kubernetes, jestli se má pod odebrat a spustit novou instanci.

Když přemýšlíte o sondách, je užitečné si vzpomenout, jak služba funguje v Kubernetes. Služba má selektor popisků, který odpovídá sadě podů (nula nebo více). Kubernetes vyrovnává zatížení provozu do podů, které odpovídají selektoru. Provoz přijímají jenom pody, které se úspěšně spustily a jsou v pořádku. Pokud dojde k chybě kontejneru, Kubernetes pod ukončí a naplánuje výměnu.

V některých případech nemusí být pod připravený přijímat provoz, i když se úspěšně spustil. Mohou například existovat úlohy inicializace, kdy aplikace spuštěná v kontejneru načítá věci do paměti nebo čte konfigurační data. Pokud chcete označit, že je pod v pořádku, ale není připravený přijímat provoz, definujte sondu připravenosti.

Sondy aktivity řeší případ, kdy je pod stále spuštěný, ale není v pořádku a měl by se recyklovat. Předpokládejme například, že kontejner obsluhuje požadavky HTTP, ale z nějakého důvodu přestane reagovat. Kontejner neskončí, ale přestal obsluhovat všechny požadavky. Pokud definujete sondu aktivity PROTOKOLU HTTP, sonda přestane reagovat a bude informovat Kubernetes, aby pod restartoval.

Tady je několik důležitých aspektů při návrhu sond:

  • Pokud má váš kód dlouhou dobu spouštění, existuje nebezpečí, že sonda aktivity nahlásí selhání před dokončením spuštění. Pokud chcete tomuto selhání sondy zabránit, použijte initialDelaySeconds nastavení, které zpozdí spuštění sondy.

  • Sonda aktivity nepomůže, pokud restartování podu pravděpodobně neobnoví jeho stav v pořádku. Sondu aktivity můžete použít ke zmírnění rizik nevracení paměti nebo neočekávaného zablokování, ale nemá smysl restartovat pod, který okamžitě znovu selže.

  • Někdy se ke kontrole závislých služeb používají sondy připravenosti. Pokud je například pod závislý na databázi, sonda může zkontrolovat připojení k databázi. Tento přístup ale může způsobovat neočekávané problémy. Externí služba může být z nějakého důvodu dočasně nedostupná. To způsobí selhání sondy připravenosti pro všechny pody ve vaší službě, což způsobí odebrání všech z vyrovnávání zatížení a vytvoření kaskádových selhání upstreamu. Lepším přístupem je implementace zpracování opakovaných pokusů ve vaší službě, aby se služba správně zotavila z přechodných selhání.

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 (paměť a procesor). U prostředků bez kontejnerů, jako jsou vlákna nebo síťová připojení, zvažte použití přepážky k izolaci prostředků.

Kvóty prostředků použijte k omezení celkového počtu prostředků povolených pro obor názvů. Front-end tak nebude moct vyhladovět back-endové služby pro prostředky ani naopak.

Zabezpečení

Řízení přístupu na základě role (RBAC)

Kubernetes i Azure mají mechanismy pro řízení přístupu na základě role (RBAC):

  • Azure RBAC řídí přístup k prostředkům v Azure, včetně možnosti vytvářet nové prostředky Azure. Oprávnění je možné přiřadit uživatelům, skupinám nebo instančním objektům. (Instanční objekt je identita zabezpečení používaná aplikacemi.)

  • Kubernetes RBAC řídí oprávnění k rozhraní Kubernetes API. Například vytváření podů a jejich výpis jsou akce, které je možné autorizovat (nebo odepřít) uživateli prostřednictvím řízení přístupu na základě role Kubernetes. Pokud chcete uživatelům přiřadit oprávnění Kubernetes, vytvořte role a vazby rolí:

    • Role je sada oprávnění, která platí v rámci oboru názvů. Oprávnění se definují jako příkazy (get, update, create, delete) u prostředků (podů, nasazení atd.).

    • RoleBinding přiřazuje uživatelům nebo skupinám roli.

    • Existuje také objekt ClusterRole, který se podobá roli, ale vztahuje se na celý cluster napříč všemi obory názvů. Pokud chcete přiřadit uživatele nebo skupiny k roli clusteru, vytvořte binding role clusteru.

AKS integruje tyto dva mechanismy RBAC. Když vytváříte cluster AKS, můžete ho nakonfigurovat tak, aby k ověřování uživatelů používal Azure AD. Podrobnosti o tom, jak to nastavit, najdete v tématu Integrace Azure Active Directory s Azure Kubernetes Service.

Jakmile je tato konfigurace nakonfigurovaná, musí se uživatel, který chce získat přístup k rozhraní Kubernetes API (například prostřednictvím kubectl), přihlásit pomocí svých přihlašovacích údajů Azure AD.

Ve výchozím nastavení nemá uživatel Azure AD přístup ke clusteru. Aby správce clusteru udělil přístup, vytvoří vazby rolí, které odkazují na uživatele nebo skupiny Azure AD. Pokud uživatel nemá oprávnění pro určitou operaci, selže.

Pokud uživatelé nemají ve výchozím nastavení přístup, jak má správce clusteru oprávnění vytvářet vazby rolí? Cluster AKS má ve skutečnosti dva typy přihlašovacích údajů pro volání serveru rozhraní Kubernetes API: uživatel clusteru a správce clusteru. Přihlašovací údaje správce clusteru udělí úplný přístup ke clusteru. Příkaz az aks get-credentials --admin Azure CLI stáhne přihlašovací údaje správce clusteru a uloží je do souboru kubeconfig. Správce clusteru může tento kubeconfig použít k vytváření rolí a vazeb rolí.

Místo nativní správy objektů role a vazby rolí clusteru Kubernetes v Kubernetes se pro autorizaci Kubernetes upřednostňuje použití Azure RBAC. To umožňuje jednotnou správu a řízení přístupu napříč prostředky Azure, AKS a prostředky Kubernetes. Tato přiřazení rolí Azure RBAC můžou cílit na cluster nebo obory názvů v rámci clusteru a získat tak podrobnější řízení přístupu. Azure RBAC podporuje omezenou sadu výchozích oprávnění a můžete ho kombinovat s nativním mechanismem Kubernetes pro správu rolí a vazeb rolí a podporovat tak pokročilé nebo podrobnější vzory přístupu. Pokud je tato možnost povolená, Azure AD instanční objekty se budou ověřovat výhradně pomocí Azure RBAC, zatímco běžní uživatelé Kubernetes a účty služeb se ověřují výhradně pomocí RBAC Kubernetes.

Vzhledem k tomu, že přihlašovací údaje správce clusteru jsou tak výkonné, použijte Azure RBAC k omezení přístupu k nim:

  • Role Správa clusteru Azure Kubernetes Service má oprávnění ke stažení přihlašovacích údajů správce clusteru. K této roli by měli být přiřazeni pouze správci clusteru.

  • Role uživatele clusteru Azure Kubernetes Service má oprávnění ke stažení přihlašovacích údajů uživatele clusteru. K této roli je možné přiřadit uživatele, kteří nejsou správci. Tato role neposkytuje žádná konkrétní oprávnění k prostředkům Kubernetes v clusteru – jenom umožňuje uživateli připojit se k serveru rozhraní API.

Když definujete zásady RBAC (Kubernetes i Azure), zamyslete se nad rolemi ve vaší organizaci:

  • Kdo může vytvořit nebo odstranit cluster AKS a stáhnout přihlašovací údaje správce?
  • Kdo může spravovat cluster?
  • Kdo může vytvářet nebo aktualizovat prostředky v rámci oboru názvů?

Je vhodné omezit oprávnění RBAC Kubernetes podle oboru názvů pomocí rolí a vazby rolí místo rolí ClusterRoles a ClusterRoleBindings.

Nakonec je tu otázka, jaká oprávnění má cluster AKS k vytváření a správě prostředků Azure, jako jsou nástroje pro vyrovnávání zatížení, sítě nebo úložiště. K ověření pomocí rozhraní API Azure používá cluster Azure AD instanční objekt. Pokud při vytváření clusteru nezadáte instanční objekt, vytvoří se automaticky. Osvědčeným postupem zabezpečení je ale nejprve vytvořit instanční objekt a přiřadit mu minimální oprávnění RBAC. Další informace najdete v tématu Instanční objekty s Azure Kubernetes Service.

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žní 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 neprozrazovat je.

U prostředků Azure je jednou z možností použití spravovaných identit. Představa spravované identity spočívá v tom, že aplikace nebo služba má identitu uloženou v Azure AD a používá ji k ověřování ve službě Azure. Aplikace nebo služba má vytvořený instanční objekt v Azure AD a ověřuje se pomocí tokenů OAuth 2.0. Kód spuštěného procesu může transparentně získat token, který se má použít. Nebudete tak muset ukládat žádná hesla ani připojovací řetězce. Spravované identity v AKS můžete použít přiřazením identit Azure AD jednotlivým podům pomocí Azure AD identit úloh (Preview).

V současné době nepodporují ověřování pomocí spravovaných identit všechny služby Azure. Seznam najdete v tématu Služby Azure, které podporují ověřování Azure AD.

I u spravovaných identit budete pravděpodobně muset uložit přihlašovací údaje nebo jiné tajné kódy aplikací, ať už jde o služby Azure, které nepodporují spravované identity, služby třetích stran, klíče rozhraní API atd. Tady je několik možností bezpečného ukládání tajných kódů:

Použití systému, jako je HashiCorp Vault nebo Azure Key Vault, přináší několik výhod, například:

  • Centralizovaná kontrola tajných kódů.
  • Zajišťuje, aby všechny tajné kódy byly šifrované v neaktivním stavu.
  • Centralizovaná správa klíčů.
  • Řízení přístupu k tajným kódům.
  • Auditování

Zabezpečení kontejnerů a orchestratoru

Toto jsou doporučené postupy pro zabezpečení podů a kontejnerů:

  • Monitorování hrozeb: Monitorování hrozeb pomocí Microsoft Defender pro kontejnery (nebo funkcí třetích stran) Pokud hostujete kontejnery na virtuálním počítači, použijte Microsoft Defender pro servery nebo funkci třetí strany. Kromě toho můžete integrovat protokoly z řešení pro monitorování kontejnerů ve službě Azure Monitor do služby Microsoft Sentinel nebo existujícího řešení SIEM.

  • Monitorování ohrožení zabezpečení: Průběžně monitorujte image a spuštěné kontejnery na známá ohrožení zabezpečení pomocí Microsoft Defender pro cloud nebo řešení třetí strany dostupného prostřednictvím Azure Marketplace.

  • Automatizace oprav imagí pomocí ACR Tasks, funkce Azure Container Registry. Image kontejneru se sestavuje z vrstev. Základní vrstvy zahrnují image operačního systému a image architektury aplikací, například ASP.NET Core nebo Node.js. Základní image se obvykle vytvářejí od vývojářů aplikací a spravují je jiní správci projektů. Když jsou tyto image opravené v upstreamu, je důležité aktualizovat, otestovat a znovu nasadit vlastní image, abyste nezanecháli žádná známá ohrožení zabezpečení. S automatizací tohoto procesu vám může pomoct ACR Tasks.

  • Ukládat image do důvěryhodného privátního registru, jako je Azure Container Registry nebo Důvěryhodný registr Dockeru. Pomocí webhooku ověřování přístupu v Kubernetes zajistěte, aby pody mohly načítat jenom image z důvěryhodného registru.

  • Princip použití 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ého adresáře uvnitř kontejnerů. Kontejnery neposkytují úplnou izolaci z hlediska zabezpečení, takže je lepší spustit proces kontejneru jako neprivilegovaný uživatel.

DevOps

Tato referenční architektura poskytuje šablonu Azure Resource Manager pro zřizování cloudových prostředků a jejich závislostí. S využitím [šablon Azure Resource Manager][arm-template] můžete použít Azure DevOps Services ke zřízení různých prostředí během několika minut, například k replikaci produkčních scénářů. To vám umožní ušetřit náklady a zřídit prostředí zátěžového testování pouze v případě potřeby.

Zvažte použití kritérií izolace úloh ke strukturování šablony ARM. Úloha je obvykle definována jako libovolná jednotka funkčnosti. můžete mít například samostatnou šablonu pro cluster a pak jinou pro závislé služby. Izolace úloh umožňuje DevOps provádět kontinuální integraci a průběžné doručování (CI/CD), protože každou úlohu přidružuje a spravuje odpovídající tým DevOps.

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

Tady jsou některé cíle robustního procesu CI/CD pro architekturu mikroslužeb:

  • Každý tým může nezávisle vytvářet a nasazovat služby, které vlastní, aniž by to ovlivnilo nebo narušilo jiné týmy.
  • Před nasazením nové verze služby do produkčního prostředí se nasadí do prostředí pro vývoj, testování a kontrolu kvality za účelem ověření. V každé fázi se vynucují brány kvality.
  • Novou verzi služby je možné nasadit souběžně s předchozí verzí.
  • Jsou zavedeny dostatečné zásady řízení přístupu.
  • U kontejnerizovaných úloh můžete důvěřovat imagím kontejnerů nasazených v produkčním prostředí.

Další informace o výzvách najdete v tématu CI/CD pro architektury mikroslužeb.

Konkrétní doporučení a osvědčené postupy najdete v tématu CI/CD pro mikroslužby v Kubernetes.

Optimalizace nákladů

K odhadu nákladů použijte cenovou kalkulačku Azure. Další důležité informace jsou popsané v části Náklady v microsoft azure Well-Architected Framework.

Tady je několik bodů, které je potřeba zvážit u některých služeb používaných v této architektuře.

Azure Kubernetes Service (AKS)

S nasazením, správou a provozem clusteru Kubernetes nejsou spojené žádné náklady. Platíte jenom za instance virtuálních počítačů, úložiště a síťové prostředky, které váš cluster Kubernetes využívá.

Pokud chcete odhadnout náklady na požadované prostředky, projděte si kalkulačku služby Container Services.

Azure Load Balancer

Účtují se vám jenom poplatky za počet nakonfigurovaných pravidel vyrovnávání zatížení a odchozích přenosů. Pravidla příchozího překladu adres (NAT) jsou zdarma. Pokud nejsou nakonfigurovaná žádná pravidla, za Standard Load Balancer se neúčtují žádné hodinové poplatky.

Další informace najdete v tématu ceny Azure Load Balancer.

Azure Pipelines

Tato referenční architektura používá pouze Azure Pipelines. Azure nabízí Azure Pipeline jako samostatnou službu. Máte povoleno bezplatnou úlohu hostované Microsoftem s 1 800 minutami měsíčně pro CI/CD a jednu úlohu v místním prostředí s neomezeným počtem minut měsíčně. Za další úlohy se účtují poplatky. Další informace najdete v tématu ceny Azure DevOps Services.

Azure Monitor

V případě Služby Azure Monitor Log Analytics se vám účtují poplatky za příjem a uchovávání dat. Další informace najdete v tématu Ceny služby Azure Monitor.

Nasazení tohoto scénáře

Pokud chcete nasadit referenční implementaci pro tuto architekturu, postupujte podle kroků v úložišti GitHub.

Referenční implementace mikroslužeb AKS

Další kroky