Architektura mikroslužeb v Azure Kubernetes Service (AKS)

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Monitor
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 infrastrukturu a aspekty 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.

Referenční architektura AKS

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

Pokud chcete zobrazit pokročilejší příklad mikroslužeb, který je postavený na základní architektuře AKS,podívejte se na architekturu mikroslužeb Advanced Azure Kubernetes Service (AKS).

Komponenty

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. Když používáte AKS, Azure spravuje službu Kubernetes API a vy potřebujete spravovat pouze uzly agentů.

Virtuální síť: Ve výchozím nastavení vytvoří AKS virtuální síť, ke které jsou připojeny uzly agentů. Virtuální síť můžete nejprve vytvořit pro pokročilejší scénáře, které vám umožní řídit například konfiguraci podsítě, místní připojení a adresování IP. 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 zpřístupňuje trasy HTTP(S) službám uvnitř 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 kontroleru 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 stav zápisu do externích úložišť dat, například Azure SQL Database nebo Cosmos DB.

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

Azure Container Registry. Použijte Container Registry k uložení privátních imagí Docker, které jsou nasazeny do clusteru. AKS se může ověřit pomocí Container Registry s využitím jeho identity Azure AD. Všimněte si, že AKS nevyžaduje Azure Container Registry. Můžete použít jiné Registry kontejnerů, jako je například Docker Hub.

Azure Pipelines. Azure Pipelines jsou součástí Azure DevOps Services a spouštějí automatizované buildy, testy a nasazení. Můžete také použít řešení CI/CD třetí strany, jako je například Jenkinse.

Helm. Helm je správce balíčků pro Kubernetes, způsob, jak seskupit a zobecnit objekty Kubernetes do jedné jednotky, která se dá publikovat, nasadit, nasazovat a aktualizovat.

Azure monitor. Azure Monitor shromažďuje a ukládá metriky a protokoly, telemetrie aplikací a metriky platforem pro služby Azure. Tato data použijte k monitorování aplikace, nastavení výstrah, řídicích panelů a k analýze selhání hlavní příčiny. Azure Monitor se integruje s AKS ke shromažďování metrik z řadičů, uzlů a kontejnerů.

Na co dát pozor při navrhování

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

Mikroslužby

Mikroslužba je volně sjednocená, 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 nějaké formy zjišťování služeb. Služba by měla být vždy dosažitelná, 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 jsou obecným vzorem návrhu mikroslužeb. Brána rozhraní API je mezi externími klienty a mikroslužbami. Funguje jako reverzní proxy a směruje požadavky od klientů do mikroslužeb. 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:

V Kubernetes funkce brány rozhraní API primárně zpracovává 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í datovou sadu, aby se zabránilo skrytým závislostem mezi službami. Oddělení dat pomáhá zabránit neúmyslnému párování mezi službami, ke kterému může dojít, když služby sdílejí stejná podkladová datová schémata. Když služby spravují vlastní úložiště dat, mohou také použít 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 místním úložišti clusteru, protože tato data jsou vázaná s uzlem. Místo toho použijte externí službu, například Azure SQL Database nebo Cosmos DB. Další možností je připojit k řešení trvalý objem dat pomocí disků Azure nebo souborů Azure.

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

Objekt služby

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

  • IP adresa. Objekt služby poskytuje statickou interní IP adresu pro skupinu lusků (ReplicaSet). Po vytvoření nebo přesunutí lusků je tato služba vždy dostupná na této interní IP adrese.

  • Vyrovnávání zatížení. Provoz odeslaný na IP adresu služby se vyrovnává zatížením v luskech.

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

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

Služby a lusky

Příchozí přenos dat

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

  • Směrovat požadavky klienta na správné služby back-end. To poskytuje jeden koncový bod pro klienty a pomáhá oddělit klienty od služeb.

  • Agregujte více požadavků do jednoho požadavku, aby se snížila chatovatost 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 proxy server. Potřebujete také kontroler příchozího přenosu dat, který poskytuje základní implementaci příchozího přenosu dat. K dispozici jsou mimo jiné kontrolery příchozího přenosu dat pro Nginx, HAProxy, Traefik a Azure Application Gateway příchozího přenosu dat.

Prostředek příchozího přenosu dat může být splněn různými technologiemi. Pokud chcete pracovat společně, je potřeba je nasadit 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í, proto vždy nasaďte alespoň dvě repliky pro vysokou dostupnost.

Konfigurace virtuálního proxy server často vyžaduje složité soubory, které se mohou těžko vyladit, pokud nejste odborníkem. Kontroler příchozího přenosu dat tedy poskytuje dobrou abstrakci. Kontroler příchozího přenosu dat má také přístup k rozhraní Kubernetes API, takže může 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í síťový proxy server kube-proxy.

Na druhé straně, pokud 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í Nginx nebo HAProxy do Kubernetes.

Pro AKS můžete také použít Azure Application Gateway pomocí kontroleru příchozího Application Gateway dat. Tato možnost vyžaduje, aby při konfiguraci clusteru AKS byla povolena síť CNI, protože Application Gateway se nasadí do podsítě virtuální sítě AKS. 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).

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

U běžných implementací se pro ukončení SSL používá kontroler příchozích dat. Proto je v rámci nasazení řadiče pro příchozí přenos dat nutné vytvořit certifikát TLS. Pro účely vývoje a testování používejte jenom certifikáty podepsané svým držitelem. Další informace najdete v tématech Vytvoření kontroleru příchozího přenosu HTTPS a používání vlastních certifikátů TLS ve službě Azure Kubernetes Service (AKS).

Pro produkční úlohy Získejte podepsané certifikáty od důvěryhodných certifikačních autorit (CA). Informace o generování a konfiguraci certifikátů, které se šifrují , najdete v tématu Vytvoření kontroleru příchozího přenosu se statickou veřejnou IP adresou ve službě Azure KUBERNETES Service (AKS).

Je také možné, že vaše certifikáty budete muset otočit podle zásad organizace. Informace najdete v tématu, otočení certifikátů ve službě Azure Kubernetes Service (AKS).

Obory názvů

Obory názvů slouží k uspořádání služeb v rámci clusteru. Každý objekt v clusteru Kubernetes patří do oboru názvů. Ve výchozím nastavení, když vytvoříte nový objekt, přejde do default oboru názvů. Je ale vhodné vytvořit obory názvů, které jsou výstižnější, a usnadnit tak uspořádání prostředků v clusteru.

První obory názvů zabraňují kolizím názvů. Když více týmů nasadí mikroslužby do stejného clusteru s potenciálně stovkami mikroslužeb, je obtížné spravovat, pokud všechny přecházejí 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 lusků přiřazených tomuto oboru názvů neměla 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 "pořadí plnění" by mohly přejít do stejného oboru názvů. Můžete také vytvořit obor názvů pro každý vývojový tým.

Utilitní služby umístěte do 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 zveřejnit:

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

  • Sonda živého přenosu: Říká Kubernetes, jestli se má pod odebrat a spustit nová instance.

Při přemýšlení o testech 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 vyvažuje provoz do podů, které odpovídají selektoru. Provoz přijímají pouze pody, které se úspěšně sjímaly a jsou v pořádku. Pokud dojde k chybě kontejneru, Kubernetes pod urazí a naplánuje nahrazení.

V některých případech nemusí být pod připravený přijímat provoz, i když byl pod úspěšně spuštěn. Mohou se například zobrazit ú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ý přijímat provoz, definujte sondu připravenosti.

Sondy živého stavu se řešou na 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 obsluhující požadavky HTTP, ale z nějakého důvodu přestane reagovat. Kontejner se nehavaruje, ale přestal obsluhut všechny požadavky. Pokud definujete sondu aktivity HTTP, sonda přestane reagovat a informuje Kubernetes o restartování podu.

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

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

  • Sonda živého provozu neumožňuje, pokud restartováním pod je pravděpodobný stav obnovení v dobrém stavu. K zmírnění nevracení paměti nebo neočekávaných zablokování můžete použít sondu živého provozu, ale v případě, že nebudete muset hned znovu fungovat, nebudete mít žádný bod.

  • V některých případech se ke kontrole závislých služeb používají testy připravenosti. Pokud má například závislost na databázi, sonda může ověřit připojení k databázi. Tento přístup ale může vytvořit neočekávané problémy. Externí služba může být z nějakého důvodu dočasně nedostupná. To způsobí, že test připravenosti selže pro všechny lusky ve vaší službě, což způsobí, že všechny z nich budou odebrány z vyrovnávání zatížení, a tím i vytvoření kaskádových selhání proti směru. Lepším přístupem je implementace zpracování opakování v rámci služby, aby se služba mohla obnovit správně z přechodných chyb.

Omezení prostředků

Spor prostředku může ovlivnit dostupnost služby. Definujte omezení prostředků pro kontejnery, aby jeden kontejner nemohl proplavit prostředky clusteru (paměť a CPU). Pro prostředky, které nejsou kontejnery, jako jsou například vlákna nebo síťová připojení, zvažte použití modelu přepážky k izolaci prostředků.

Pomocí kvót prostředků můžete omezit celkový počet prostředků povolených pro obor názvů. Front-end pak nemůže omezují back-endové služby pro prostředky nebo naopak.

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

Kubernetes a 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í lze 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 výpis podů jsou akce, které mohou být autorizovány (nebo odepřeny) uživateli prostřednictvím řízení přístupu na základě role v 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í na obor názvů. Oprávnění se definují jako příkazy (get, update, create, delete) k prostředkům (pody, nasazení atd.).

    • Vazba rolí přiřadí uživatele nebo skupiny k roli.

    • Existuje také objekt Role clusteru, který se je jako role, ale vztahuje se na celý cluster ve všech oborech názvů. Pokud chcete přiřadit uživatele nebo skupiny k role clusteru, vytvořte vazby role clusteru.

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

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

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

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

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

  • Role správce Azure Kubernetes Service clusteru má oprávnění ke stažení přihlašovacích údajů správce clusteru. K této roli by se měla přiřadit jenom Správci clusteru.

  • Role uživatele clusteru služby Azure Kubernetes 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 bez správce. Tato role neuděluje žádná konkrétní oprávnění k prostředkům Kubernetes v clusteru — , ale umožňuje uživateli připojit se k serveru rozhraní API.

Pokud definujete zásady RBAC (Kubernetes i Azure), uvažujte o rolích 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 podle oboru názvů, pomocí rolí a RoleBindings spíše než ClusterRoles a ClusterRoleBindings.

Nakonec máte otázku, 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ěřování sebe sama s rozhraními API Azure používá cluster instanční objekt služby Azure AD. Pokud při vytváření clusteru nezadáte instanční objekt, vytvoří se ho automaticky. Je však dobrým zvykem zabezpečení nejprve vytvořit instanční objekt a přiřadit k němu minimální oprávnění RBAC. Další informace najdete v tématu objekty služby ve službě Azure Kubernetes.

Správa tajných klíčů 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. Je nutné, aby tyto přihlašovací údaje byly bezpečné a nevrácené.

U prostředků Azure je jednou z možností použití spravovaných identit. Účelem spravované identity je, že aplikace nebo služba má identitu uloženou v Azure AD a používá tuto identitu k ověřování pomocí služby Azure. Pro aplikaci nebo službu se vytvořil instanční objekt ve službě Azure AD a ověřuje se pomocí tokenů OAuth 2,0. Spuštěný proces volá adresu místního hostitele pro získání tokenu. 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 jednotlivým podům pomocí projektu aad-pod-identity.

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

I se spravovanými identitami budete pravděpodobně muset ukládat 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ů z Key Vault jako svazek. Svazek čte tajné kódy z Key Vault. Pod pak může tajné kódy číst stejně jako běžný objem. Další informace najdete v projektu secrets-store-csi-driver-provider-azure na GitHubu.

    Pod se ověřuje buď pomocí identity podu (popsané výše), nebo pomocí objektu služby Azure AD spolu s tajným kódem klienta. Použití identit podů se doporučuje, protože v takovém případě tajný kód klienta není potřeba.

  • Trezor společnosti HashiCorp. Aplikace Kubernetes se mohou ověřovat ve službě HashiCorp Vault pomocí spravovaných identit Azure AD. Viz HashiCorp Vault mluví Azure Active Directory. Můžete nasadit samotnou trezor do Kubernetes. Zvažte jeho spuštění v samostatném vyhrazeném clusteru, než je váš cluster aplikací.

  • Tajné kódy Kubernetes. Další možností je jednoduše použít tajné kódy Kubernetes. Tato možnost se nejsnadněji konfiguruje, ale má určité problémy. Tajné kódy jsou uložené v etcd, což je úložiště s distribuovanými hodnotami klíčů. AKS šifruje etcd v klidovém umístění. Microsoft spravuje šifrovací klíče.

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

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

Zabezpečení kontejnerů a Orchestrator

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

  • Monitorování hrozeb – Monitorujte hrozby pomocí Azure Defenderu pro Registry kontejnerů a Azure Defender pro Kubernetes (nebo funkce třetích stran). Pokud Hostujte kontejnery na virtuálním počítači, použijte Azure Defender pro servery nebo funkci třetí strany. Kromě toho můžete integrovat protokoly z řešení monitorování kontejnerů v Azure monitor do Azure Sentinel nebo do existující Siem.

  • Monitorování ohrožení zabezpečení – Průběžně monitorujte image a spouštění kontejnerů pro známé chyby zabezpečení pomocí Azure Security Center nebo řešení třetích stran dostupného prostřednictvím Azure Marketplace.

  • Automatizujte opravy obrázků pomocí úloh ACR, což je funkce Azure Container Registry. Obrázek kontejneru je sestaven z vrstev. Základní vrstvy zahrnují image operačního systému a bitové kopie aplikační architektury, například ASP.NET Core nebo Node.js. Základní image většinou vytvářejí nadřazený z vývojářů aplikací a jsou spravovány jinými údržbami projektů. Když se tyto image převádějí proti směru,'s, je důležité aktualizovat, testovat a znovu nasazovat vlastní image, takže nebudete't, abyste ponechali všechna známá ohrožení zabezpečení. ACR úlohy můžou přispět k automatizaci tohoto procesu.

  • Ukládat image do důvěryhodného privátního registru, jako je Azure Container Registry nebo důvěryhodný registr Dockeru. Použijte k ověření webhooku přístupu v Kubernetes, abyste zajistili, že pody mohou natahovat jenom image z důvěryhodného registru.

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

    • Nespouštět kontejnery v privilegovaného 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řen uvnitř kontejnerů. Kontejnery neposkytují úplnou izolaci z hlediska zabezpečení,'lepší spustit proces kontejneru jako neprivilegovaný uživatel.

Důležité informace o DevOps

Tato referenční architektura poskytuje [šablonu Azure Resource Manager][arm-template] pro zřizování cloudových prostředků a jejich závislostí. S použitím [Azure Resource Manager templates][arm-template] můžete pomocí [Azure DevOps Services][az-devops] zřídit během několika minut různá prostředí, 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.

Při strukturování šablony ARM zvažte použití kritérií izolace úloh. Úloha se obvykle definuje 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 nezávisle vytvářet a nasazovat služby, které vlastní, aniž by to ovlivnilo nebo narušilo jiné týmy.
  • Než se do produkčního prostředí nasadí nová verze služby, nasadí se do prostředí pro vývoj, testování a testování a pro ověření. Brány kvality se vynucuje v každé fázi.
  • Novou verzi služby je možné nasadit vedle předchozí verze.
  • Jsou k dispozici dostatečné zásady řízení přístupu.
  • Pro kontejnerové úlohy můžete důvěřovat obrazům kontejnerů, které jsou nasazeny 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.

Důležité informace o nákladech

K odhadu nákladů použijte cenovou kalkulačku Azure. Další požadavky jsou popsány v části cost v Microsoft Azure Well-Architected Framework.

Tady jsou některé body, které je potřeba vzít v úvahu pro některé služby používané v této architektuře.

Azure Kubernetes Service (AKS)

Pro AKS se nevztahují žádné náklady na nasazení, správu a provoz clusteru Kubernetes. 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, Prohlédněte si kalkulačku služby Container Services.

Nástroj pro vyrovnávání zatížení Azure

Účtuje se vám jenom počet konfigurovaných nakonfigurovaných pravidel vyrovnávání zatížení a odchozích pravidel. 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 Azure Load Balancer ceny .

Azure Pipelines

Tato referenční architektura používá pouze Azure Pipelines. Azure nabízí kanál Azure jako jednotlivou službu. Pro CI/CD a 1 samoobslužnou úlohu s neomezeným počtem minut za měsíc máte k dispozici bezplatnou úlohu Microsoft hosta s 1 800 minut za měsíc pro úlohy v místním prostředí, které mají neomezenou dobu. Další informace najdete v tématu Azure DevOps Services ceny.

Azure Monitor

V případě Azure Monitor Log Analytics se vám bude účtovat příjem a uchovávání dat. Další informace najdete v tématu Azure monitor ceny pro další informace.

Nasazení řešení

Pokud chcete nasadit referenční implementaci této architektury, postupujte podle kroků v úložišti GitHub.

Další kroky