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

Tato referenční architektura ukazuje aplikaci mikroslužeb nasazenou do služby 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.

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

Architektura

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

Workflow

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 Kubernetes API a potřebujete spravovat jenom uzly agenta.

Virtuální síť: AKS ve výchozím nastavení vytvoří virtuální síť, do které jsou připojené uzly agenta. Jako první můžete vytvořit virtuální síť 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í ve službě 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 Database nebo Azure Cosmos DB.

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

Azure Container Registry. Službu Container Registry použijte k ukládání privátních imagí Dockeru, které jsou nasazené do clusteru. AKS se může ověřit pomocí služby Container Registry pomocí své identity Microsoft Entra. AKS nevyžaduje Službu Azure Container Registry. Můžete použít další registry kontejnerů, jako je Docker Hub. Ujistěte se, že registr kontejneru odpovídá vaší úloze nebo překračuje smlouvu o úrovni služeb (SLA).

Azure Pipelines. Azure Pipelines jsou součástí Azure DevOps Services a spouštějí 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, 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í, řídicích panelů a provádění analýzy 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ž řada doporučených postupů se vztahuje na 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:

• Použití bran rozhraní API v mikroslužbách
• Volba technologie brány

V Kubernetes zajišťuje funkce brány rozhraní API primárně kontroler 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 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ž navíc služby spravují svoje 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 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 tato data 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 služby Azure Files.

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

Předmět servisu

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 odeslaný na IP adresu služby je na pody vyrovnána zatížení.

• 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ých bodů a porty provádí kube-proxy server sítě Kubernetes.

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ě fungují 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 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 chattivost 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 (omezování).

Příchozí přenos dat abstrahuje nastavení konfigurace pro proxy server. Potřebujete také kontroler příchozího přenosu dat, který poskytuje základní implementaci příchozího přenosu dat. Kontrolery příchozího přenosu dat pro Nginx, HAProxy, Traefik a Aplikace Azure Gateway jsou 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 uvnitř 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 aspoň 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íkem. 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.

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 potřebujete vytvořit certifikát TLS. Certifikáty podepsané svým držitelem používejte pouze pro účely vývoje/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 ve službě 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 ve službě Azure Kubernetes Service (AKS).

Můžete také potřebovat obměňovat certifikáty podle zásad organizace. Informace najdete v tématu Obměna certifikátů ve službě 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ů. 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, 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ů navíc 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 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 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 žádosti.

• Sonda aktivity: Říká Kubernetes, jestli se má pod odebrat, a spustí se nová instance.

Když uvažujete o sondách, je užitečné si vzpomenout, 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ě spustily 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 pod úspěšně spustil. Například můžou existovat úlohy inicializace, kdy aplikace spuštěná v kontejneru načte věci do paměti nebo čte konfigurační data. Pokud chcete označit, že pod je v pořádku, ale není připravený přijímat provoz, definujte sondu připravenosti.

Sondy 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 zablokuje. Kontejner se neukončí, ale přestal obsluhovat žádné požadavky. Pokud definujete sondu aktivity HTTP, sonda přestane reagovat a informuje Kubernetes o restartování podu.

Při navrhování sond je potřeba vzít v úvahu následující skutečnosti:

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

• Sonda aktivity nepomůže, pokud restartování podu pravděpodobně neobnoví stav v pořádku. Sondu aktivity můžete použít ke zmírnění nevracení paměti nebo neočekávaného zablokování, 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ůsobit neočekávané problémy. Externí služba může být z nějakého důvodu 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 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 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ů. Front-end tak nemůže hladově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. Vytváření podů a výpis podů jsou například akce, které je možné autorizovat (nebo odepřít) 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í se definují jako příkazy (get, update, create, delete) u prostředků (pody, nasazení atd.).

  • Vazby rolí přiřazují uživatele nebo skupiny k 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 pro ověřování uživatelů používalo ID Microsoft Entra. Podrobnosti o tom, jak to nastavit, najdete v tématu Integrace ID Microsoft Entra se službou 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ů Microsoft Entra.

Ve výchozím nastavení nemá uživatel Microsoft Entra přístup ke clusteru. Správce clusteru vytvoří vazby rolí, které odkazují na uživatele nebo skupiny Microsoft Entra. Pokud uživatel nemá oprávnění pro konkrétní operaci, selže.

Pokud uživatelé ve výchozím nastavení nemají přístup, jak má správce clusteru oprávnění k vytvoření vazeb 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ě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 pomocí této kubeconfig vytvářet role a vazby rolí.

Místo správy rolí clusteru Kubernetes 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 prostředky Kubernetes. Tato přiřazení rolí Azure RBAC můžou cílit na cluster nebo obory názvů v rámci clusteru, aby bylo možné jemněji řídit přístup. 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 vazeb rolí, které podporují pokročilé nebo podrobnější vzory přístupu. Pokud je tato možnost povolená, budou objekty zabezpečení Microsoft Entra ověřeny výhradně azure RBAC, zatímco běžní uživatelé a účty služeb Kubernetes jsou výhradně ověřeni RBAC Kubernetes.

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

• Role clusteru Azure Kubernetes Service 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 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ůžete 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ů?

Osvědčeným postupem je nastavit obor oprávnění RBAC Kubernetes podle oboru názvů, pomocí rolí a vazeb rolí, nikoli rolí a clusterových rolí a rolí.

Nakonec je 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í AZURE API používá cluster instanční objekt Microsoft Entra. Pokud při vytváření clusteru nezadáte instanční objekt, vytvoří se automaticky. 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 se službou 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žň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 Microsoft Entra ID a tuto identitu používá k ověření ve službě Azure. Aplikace nebo služba má vytvořený instanční objekt v MICROSOFT Entra ID 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ězec. Spravované identity v AKS můžete použít přiřazením identit Microsoft Entra jednotlivým podům pomocí ID úloh Microsoft Entra (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í Microsoft Entra.

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 je několik možností bezpečného ukládání tajných kódů:

• Azure Key Vault. V AKS můžete připojit jeden nebo více tajných kódů ze služby Key Vault jako svazek. Svazek čte tajné kódy ze služby Key Vault. Pod pak může číst tajné kódy stejně jako běžný svazek. Další informace najdete v tématu Použití zprostředkovatele služby Azure Key Vault pro ovladač CSI úložiště tajných kódů v clusteru AKS.

  Pod se ověřuje buď pomocí identity úlohy, nebo pomocí spravované identity přiřazené uživatelem nebo systémem. Další informace najdete v tématu Poskytnutí identity pro přístup k poskytovateli služby Azure Key Vault pro ovladač CSI úložiště tajných kódů.

• HashiCorp Vault. Aplikace Kubernetes se můžou ověřovat pomocí služby HashiCorp Vault pomocí spravovaných identit Microsoft Entra. Viz HashiCorp Vault hovoří o Microsoft Entra ID. Do Kubernetes můžete nasadit samotný trezor. Zvažte jeho spuštění v samostatném vyhrazeném clusteru od clusteru aplikací.

• Tajné kódy Kubernetes Další možností je jednoduše použít tajné kódy Kubernetes. Tato možnost je nejjednodušší nakonfigurovat, ale má několik problémů. Tajné kódy se ukládají v etcd, což je distribuované úložiště klíč-hodnota. AKS šifruje neaktivní uložený atd. Microsoft spravuje šifrovací klíče.

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ů
• Zajištění š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
• 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 Defenderu for Containers (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í 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í: Nepřetržitě monitorujte image a spuštěné kontejnery kvůli známým ohrožením zabezpečení pomocí programu Microsoft Defender for Cloud nebo řešení třetí strany dostupné prostřednictvím Azure Marketplace.

• Automatizace oprav imagí pomocí ACR Tasks, funkce 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í nadřazeně od vývojářů aplikací a spravují je jiní správci projektů. Když jsou tyto image opravené v upstreamu, je důležité aktualizovat, testovat a znovu nasadit vlastní image, abyste neopustili žádná známá ohrožení zabezpečení. ACR Tasks vám může pomoct tento proces automatizovat.

• Ukládat image do důvěryhodného privátního registru , jako je Azure Container Registry nebo Docker Trusted Registry. Pomocí ověřovacího 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ě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 pohledu zabezpečení, takže je lepší spustit proces kontejneru jako neprivilegovaný uživatel.

DevOps

Tato referenční architektura poskytuje šablonu Azure Resource Manageru pro zřizování cloudových prostředků a jejích závislostí. Pomocí [šablon Azure Resource Manageru][arm-template] můžete pomocí azure DevOps Services zřídit různá prostředí v řádu minut, například replikovat produkční scénáře. 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 pro 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ždá úloha je přidružená a spravovaná odpovídajícím týmem 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 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 prostředí pro vývoj/testování/kontrolu kvality 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.

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 architektuře 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 provozu 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 spotřebované clusterem Kubernetes.

Náklady na požadované prostředky vám pomůže odhadnout kalkulačka služby Container Service.

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 Load Balancer úrovně Standard 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. Máte povolenou 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 za měsíc. Za další úlohy se účtují poplatky. Další informace najdete v tématu Azure DevOps Services – ceny.

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.

Nasazení tohoto scénáře

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

Další kroky

• Instanční objekty se službou Azure Kubernetes Service
• Microsoft Defender for Containers
• Microsoft Defender pro servery
• Řešení monitorování kontejnerů ve službě Azure Monitor
• Microsoft Sentinel nebo existující řešení SIEM
• Microsoft Defender for Cloud nebo řešení třetí strany dostupné prostřednictvím Azure Marketplace
• Úlohy ACR

Související prostředky

• Pokud chcete pracovat s pokročilejším příkladem mikroslužeb, podívejte se na architekturu mikroslužeb Advanced Azure Kubernetes Service (AKS).
• Další informace o monitorování této architektury najdete v tématu Monitorování architektury mikroslužeb ve službě Azure Kubernetes Service (AKS).
• Informace o tom, jak jsme změřili výkon této aplikace, najdete v tématu Scénář ladění výkonu: Distribuované obchodní transakce.
• CI/CD pro architektury mikroslužeb
• CI/CD pro mikroslužby v Kubernetes