Architektura mikroslužeb na Azure Kubernetes Service

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Pipelines

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 týkající se provozová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 raději viděli pokročilejší příklad mikroslužeb založený na architektuře standardních hodnot AKS, podívejte se na architekturu 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 potřebujete spravovat jenom uzly agenta.

Virtuální síť: Ve výchozím nastavení AKS vytvoří virtuální síť, do které jsou připojené uzly agenta. Virtuální síť můžete vytvořit jako první pro pokročilejší scénáře, které 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 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 kontrolerem příchozího přenosu dat. Tímto způsobem nástroj pro vyrovnávání zatížení směruje internetový provoz do příchozího přenosu dat.

Externí úložiště dat Mikroslužby jsou obvykle bezstavové a zapisují do externích úložišť dat, jako je Azure SQL Databáze 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 pomocí služby 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čí zajistit, aby registr kontejneru odpovídal vaší úloze nebo překročil smlouvu o úrovni služeb (SLA).

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, způsob, jak seskupit a generalizovat objekty Kubernetes do jedné jednotky, která se dá 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í, řídicích panelů a provádění analýzy hlavních příčin 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ž mnoho doporučených postupů platí pro jiné úlohy spuštěné 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. Služba by měla být vždy dostupná i v případě, že 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 a směruje požadavky klientů na mikroslužby. Může také provádět různé křížové úlohy, jako je ověřování, ukončení protokolu SSL a omezování rychlosti. Další informace naleznete v tématu:

Funkce brány rozhraní API v Kubernetes se primárně zpracovává kontrolerem příchozího přenosu dat. Aspekty jsou popsány 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í 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, ke kterým může dojít, když služby sdílejí stejná podkladová schémata dat. Když také služby spravují vlastní úložiště dat, můžou pro své konkrétní požadavky používat správné úložiště dat.

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 je spojuje 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 zjišťování služeb:

  • IP adresa. Objekt služby 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 je vyrovnána zatížení podů.

  • Zjišťování služeb. Služby mají přiřazené interní záznamy DNS službou DNS Kubernetes. 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 mapuje 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 koncového bodu a porty provádí kube-proxy server, 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 správné back-endové služby. Toto směrování poskytuje pro klienty jeden koncový bod a pomáhá oddělit klienty od služeb.

  • Agregujte několik požadavků do jednoho požadavku, abyste snížili chattivost mezi klientem a back-endem.

  • Přesměrování zátěže z back-endových služeb, jako je ukončení protokolu SSL, ověřování, omezení IP adres nebo omezování 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 pro Nginx, HAProxy, Traefik a Azure Application Gateway mimo jiné.

Prostředek příchozího přenosu dat je možné splnit různými technologiemi. Aby bylo možné spolupracovat, musí být nasazeny jako kontroler příchozího přenosu dat v clusteru. Funguje jako hraniční směrovač nebo reverzní proxy server. Reverzní proxy server je potenciální kritický bod nebo kritický bod selhání, takže vždy nasaďte alespoň dvě repliky pro zajištění vysoké dostupnosti.

Konfigurace proxy serveru často vyžaduje složité soubory, což 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, aby mohl provádět inteligentní rozhodnutí o směrování a vyrovnávání zatížení. Například kontroler příchozího přenosu dat Nginx obchází proxy server sítě kube-proxy.

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

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 cluster AKS používá sítě CNI, Application Gateway je možné nasadit do podsítě virtuální sítě clusteru nebo ji můžete nasadit v jiné virtuální síti z virtuální sítě AKS, ale obě virtuální sítě musí být vzájemně propojeny. AGIC také podporuje modul plug-in sítě 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 Jak nastavit 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 kontroler příchozího přenosu dat používá k ukončení protokolu SSL. Proto v rámci nasazení kontroleru příchozího přenosu dat musíte vytvořit certifikát TLS. Pro účely vývoje a testování používejte pouze certifikáty podepsané svým držitelem. Další informace najdete v tématu Vytvoření kontroleru příchozího přenosu dat HTTPS a použití vlastních certifikátů TLS na 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).

Certifikáty můžete také muset otočit podle zásad organizace. Informace najdete v tématu Otočení certifikátů v Azure Kubernetes Service (AKS).

Obory názvů

Pomocí oborů názvů uspořádejte služby v rámci clusteru. Každý objekt v clusteru Kubernetes patří do oboru názvů. Ve výchozím nastavení při vytváření nového objektu 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.

Nejprve obory názvů pomáhají zabránit kolizím názvů. Když několik týmů nasadí mikroslužby do stejného clusteru s možná stovkami mikroslužeb, bude obtížné je spravovat, pokud všechny přejdou do stejného oboru názvů. Kromě toho vám obory názvů umožňují:

  • Použijte omezení prostředků na obor názvů, 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 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" 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 nástrojů do 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é pod může vystavit:

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

  • Sonda živé aktivity: Informuje Kubernetes, jestli se má pod odebrat a jestli se má spustit nová instance.

Když uvažujete o sondách, je užitečné si vzpomenout na to, 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é byly úspěšně spuštěny a jsou v pořádku. Pokud dojde k chybovému ukončení kontejneru, Kubernetes pod ukončí a naplánuje nahrazení.

Někdy nemusí být pod připravený k příjmu provozu, i když se pod úspěšně spustil. Může se například jednat o úlohy inicializace, kdy aplikace spuštěná v kontejneru načte věci do paměti nebo načte konfigurační data. Pokud chcete označit, že pod je v pořádku, ale není připravený k příjmu provozu, definujte sondu připravenosti.

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

Tady je několik aspektů při návrhu sond:

  • Pokud má váš kód dlouhou dobu spuštění, existuje nebezpečí, že sonda živé aktivity oznámí selhání před dokončením spuštění. Pokud chcete zabránit selhání této sondy, použijte initialDelaySeconds nastavení, které zpožďuje spuštění sondy.

  • Sonda živé aktivity nepomůže, pokud restartování podu pravděpodobně neobnoví stav v pořádku. Sondu živé aktivity můžete použít ke zmírnění problémů s nevracením paměti nebo neočekávaným zablokováním, ale restartování podu, který se okamžitě nezdaří, neexistuje žádný bod.

  • 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ů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 nich z vyrovnávání zatížení a vytvoření kaskádových selhání upstream. 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í.

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ů, které nejsou kontejnery, jako jsou vlákna nebo síťová připojení, zvažte použití vzoru Bulkhead k izolaci prostředků.

Kvóty prostředků použijte k omezení celkových prostředků povolených pro obor názvů. Front-end tak nemůže zmást 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. Vytváření podů a výpis podů jsou například akce, které je možné autorizovat (nebo zamítnout) uživateli prostřednictvím RBAC 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á se vztahují v rámci oboru názvů. Oprávnění jsou definována jako příkazy (get, update, create, delete) u prostředků (pody, nasazení atd.).

    • Vazby rolí přiřazují 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 clusterRoleBinding.

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

Po nakonfigurování se musí uživatel, který chce získat přístup k rozhraní Kubernetes API (například přes 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. Pokud chcete udělit přístup, správce clusteru vytvoří vazby rolí, které odkazují na Azure AD uživatele nebo skupiny. Pokud uživatel nemá oprávnění pro konkrétní 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í na prvním místě? Cluster AKS má ve skutečnosti dva typy přihlašovacích údajů pro volání serveru rozhraní API Kubernetes: uživatele clusteru a správce clusteru. Přihlašovací údaje správce clusteru uděluje ú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 správy rolí clusteru Kuernetes a objektů RoleBinding nativně v Kubernetes se upřednostňuje použití Azure RBAC pro autorizaci Kubernetes. To umožňuje jednotnou správu a řízení přístupu napříč prostředky Azure, AKS a 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 ji kombinovat s nativním mechanismem Kubernetes pro správu rolí a vazb rolí, které podporují pokročilé nebo podrobnější vzory přístupu. Pokud je tato možnost povolená, Azure AD instanční objekty budou ověřeny výhradně službou Azure RBAC, zatímco běžné uživatele a účty služeb Kubernetes ověří výhradně RBAC Kubernetes.

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

  • Role Azure Kubernetes Service clusteru Správa 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 uvnitř clusteru – umožňuje jenom 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é nastavit obor oprávnění RBAC Kubernetes oborem názvů, používat role a vazby rolí místo rolí a clusterových rolí.

Nakonec je otázka, jaká oprávnění cluster AKS musí vytvářet a spravovat prostředky 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 jeden instanční objekt. Je ale vhodné 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 aplikací

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.

U prostředků Azure je jednou z možností použití spravovaných identit. Myšlenka spravované identity spočívá v tom, že aplikace nebo služba má identitu uloženou v Azure AD a tuto identitu používá k ověření ve službě Azure. Aplikace nebo služba má pro něj 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. Tímto způsobem nemusíte 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í identit úloh Azure AD (Preview).

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

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

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

  • Centralizovaná kontrola tajných kódů.
  • Ujistěte se, že jsou všechny tajné kódy zašifrované v klidovém stavu.
  • Centralizovaná správa klíčů
  • Řízení přístupu k tajným kódům
  • Auditování

Zabezpečení kontejneru a orchestratoru

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

  • Monitorování hrozeb: Monitorujte hrozby pomocí Microsoft Defender pro kontejnery (nebo funkce 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í Monitorování kontejnerů ve službě Azure Monitor do Microsoft Sentinelu nebo existujícího řešení SIEM.

  • Monitorování ohrožení zabezpečení: Průběžné monitorování imagí a spouštění kontejnerů pro známá ohrožení zabezpečení pomocí Microsoft Defender pro cloud nebo řešení třetí strany dostupné prostřednictvím Azure Marketplace.

  • Automatizace oprav obrázků 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 aplikační architektury, jako jsou ASP.NET Core nebo Node.js. Základní image se obvykle vytvářejí před vývojáři aplikací a udržují je ostatní správci projektů. Pokud jsou tyto image opravené v nadřazené verzi, je důležité aktualizovat, testovat a znovu nasadit vlastní image, abyste neopustili žádná známá ohrožení zabezpečení. Úlohy ACR vám můžou pomoct tento proces automatizovat.

  • Uložte image do důvěryhodného privátního registru, například do Azure Container Registry nebo důvěryhodného registru Dockeru. Pomocí ověřování webhooku přístupu v Kubernetes zajistěte, aby pody mohly načítat jenom image z důvěryhodného registru.

  • Použití principu nejnižších oprávnění

    • Nespouš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 od hlediska zabezpečení, takže je lepší spustit proces kontejneru jako neprivilegovaný uživatel.

DevOps

Tato referenční architektura poskytuje šablonu [Azure Resource Manager][arm-template] pro zřizování cloudových prostředků a jejích závislostí. Pomocí šablon [Azure Resource Manager][arm-template] můžete pomocí [Azure DevOps Services][az-devops] zřídit různá prostředí v minutách, 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í jenom v případě potřeby.

Zvažte použití kritérií izolace úloh pro strukturování šablony ARM, úloha je obvykle definována jako libovolná jednotka funkčnosti; Můžete například mít samostatnou šablonu clusteru 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ždá úloha je přidružená a spravovaná odpovídajícím týmem DevOps.

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

Tady je několik cílů 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 rušilo jiné týmy.
  • Než se do produkčního prostředí nasadí nová verze služby, nasadí se do prostředí dev/test/QA pro ověření. V každé fázi se vynucují brány kvality.
  • Novou verzi služby je možné nasadit vedle předchozí verze.
  • Jsou nastaveny dostatečné zásady řízení přístupu.
  • U kontejnerizovaných úloh můžete důvěřovat imagím kontejnerů nasazených do produkčního prostředí.

Další informace o problémech 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ší aspekty jsou popsané v části Náklady v rozhraní 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)

V nasazení, správě 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

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

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

Azure Pipelines

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

Azure Monitor

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

Další kroky