Tato referenční architektura podrobně popisuje několik konfigurací, které je potřeba zvážit při spouštění mikroslužeb ve službě Azure Kubernetes Services. Mezi témata patří konfigurace zásad sítě, automatického škálování podů a distribuovaného trasování napříč aplikací založenou na mikroslužbách.
Tato architektura vychází ze základní architektury AKS, což je doporučený výchozí bod pro infrastrukturu Azure Kubernetes Service (AKS). Základní funkce AKS podrobně popisuje funkce infrastruktury, jako jsou ID úloh Microsoft Entra, omezení příchozího a výchozího přenosu dat, limity prostředků a další zabezpečené konfigurace infrastruktury AKS. Tyto podrobnosti infrastruktury nejsou v tomto dokumentu popsány. Než budete pokračovat v obsahu mikroslužeb, doporučujeme seznámit se se směrným plánem AKS.
Referenční implementace této architektury je k dispozici na GitHubu.
Architektura
Stáhněte si soubor aplikace Visio s touto architekturou.
Pokud byste chtěli začít s ukázkou základních mikroslužeb v AKS, podívejte se na architekturu mikroslužeb v AKS.
Workflow
Tento tok požadavku implementuje vzory návrhu cloudu pro zákazníky vydavatele, konkurující zákazníky a směrování brány. Tok zasílání zpráv pokračuje následujícím způsobem:
Žádost HTTPS se odešle k naplánování vyzvednutí dronů. Požadavky procházejí bránou Aplikace Azure lication Gateway do webové aplikace pro příjem dat, která běží jako mikroslužba v clusteru v AKS.
Webová aplikace pro příjem dat vytvoří zprávu a odešle ji do fronty zpráv služby Service Bus.
Back-endový systém přiřadí dron a upozorní uživatele. Pracovní postup:
- Využívá informace o zprávě z fronty zpráv služby Service Bus.
- Odešle požadavek HTTPS do mikroslužby delivery, která předává data do externího úložiště dat Azure Cache for Redis.
- Odešle požadavek HTTPS do mikroslužby Plánovač dronů.
- Odešle požadavek HTTPS do mikroslužby package, která předává data do externího úložiště dat MongoDB.
Požadavek HTTPS GET se používá k vrácení stavu doručení. Tento požadavek prochází službou Application Gateway do mikroslužby doručení.
Mikroslužba doručování čte data ze služby Azure Cache for Redis.
Komponenty
Tato architektura používá následující komponenty Azure:
Azure Kubernetes Service je nabídka Azure, která poskytuje spravovaný cluster Kubernetes. Při použití AKS spravuje Azure server rozhraní API Kubernetes. Uzly Nebo fondy uzlů Kubernetes jsou přístupné a dají se spravovat operátorem clusteru.
Mezi funkce infrastruktury AKS používané v této architektuře patří:
- Oddělení fondů systémových a uživatelských uzlů
- AKS spravované ID Microsoft Entra pro řízení přístupu na základě role (RBAC)
- ID úloh Microsoft Entra
- Doplněk Azure Policy pro AKS
- Azure Container Networking Interface (CNI)
- Přehledy kontejnerů služby Azure Monitor
Virtuální sítě Azure jsou izolovaná a vysoce zabezpečená prostředí pro spouštění virtuálních počítačů a aplikací. Tato referenční architektura používá topologii virtuální sítě s hvězdicovou hvězdicovou sítí. Virtuální síť centra obsahuje podsítě brány Azure Firewall a Azure Bastion. Paprsková virtuální síť obsahuje podsítě systému AKS a fondu uzlů uživatele a podsíť brány Aplikace Azure lication.
Azure Private Link přiděluje konkrétní privátní IP adresy pro přístup ke službě Azure Container Registry a Key Vaultu z privátních koncových bodů v podsíti systému AKS a fondu uzlů uživatele.
Aplikace Azure lication Gateway pomocí firewallu webových aplikací (WAF) zveřejňuje trasy HTTP(S) do clusteru AKS a vyrovnává zatížení webového provozu do webové aplikace. Tato architektura používá jako kontroler příchozího přenosu dat Kubernetes Aplikace Azure lication Gateway (AGIC).
Azure Bastion poskytuje zabezpečený protokol RDP (Remote Desktop Protocol) a zabezpečený přístup prostředí (SSH) k virtuálním počítačům ve virtuálních sítích pomocí zabezpečené vrstvy soketu (SSL), aniž by bylo nutné virtuální počítače zveřejnit prostřednictvím veřejných IP adres.
Azure Firewall je služba zabezpečení sítě, která chrání všechny prostředky služby Azure Virtual Network. Brána firewall povoluje pouze schválené služby a plně kvalifikované názvy domén (FQDN) jako odchozí provoz.
Externí úložiště a další komponenty:
Azure Key Vault ukládá a spravuje klíče zabezpečení pro služby AKS.
Azure Container Registry ukládá privátní image kontejnerů, které je možné spustit v clusteru AKS. AKS se ověřuje ve službě Container Registry pomocí své spravované identity Microsoft Entra. Můžete také použít další registry kontejnerů, jako je Docker Hub.
Azure Cosmos DB ukládá data pomocí opensourcové služby Azure Cosmos DB pro MongoDB. Mikroslužby jsou obvykle bezstavové a zapisují jejich stav do externích úložišť dat. Azure Cosmos DB je databáze NoSQL s opensourcovými rozhraními API pro MongoDB a Cassandra.
Azure Service Bus nabízí spolehlivé cloudové zasílání zpráv jako službu a jednoduchou hybridní integraci. Service Bus podporuje vzory asynchronního zasílání zpráv, které jsou společné s aplikacemi mikroslužeb.
Azure Cache for Redis přidává vrstvu ukládání do mezipaměti do architektury aplikace, aby se zlepšila rychlost a výkon pro vysoké zatížení provozu.
Azure Monitor shromažďuje a ukládá metriky a protokoly, včetně telemetrie aplikací a metrik platformy a služeb Azure. Tato data můžete použít k monitorování aplikace, nastavení výstrah a řídicích panelů a provádění analýzy původní příčiny selhání.
Další komponenty podpory operací (OSS):
Helm, správce balíčků pro Kubernetes, který spojuje objekty Kubernetes do jedné jednotky, kterou můžete publikovat, nasazovat, verze a aktualizovat.
Poskytovatel csi úložiště tajných kódů služby Azure Key Vault, získá tajné kódy uložené ve službě Azure Key Vault a pomocí rozhraní ovladače CSI služby Secret Store je připojí k podům Kubernetes.
Flux, otevřené a rozšiřitelné řešení průběžného doručování pro Kubernetes založené na sadě GitOps Toolkit.
Podrobnosti scénáře
Příklad aplikace doručování pomocí dronů Fabrikam znázorněná v předchozím diagramu implementuje komponenty architektury a postupy, které jsou popsány v tomto článku. V tomto příkladu spravuje společnost Fabrikam, Inc., fiktivní společnost, flotilu dronů. Firmy se registrují v této službě a uživatelé si můžou vyžádat, aby dron vyzvedl zboží k doručení. Když zákazník naplánuje vyzvednutí, back-endový systém přiřadí dron a upozorní uživatele odhadovanou dobou doručení. Během doručování může zákazník sledovat polohu dronů s nepřetržitě aktualizovaným ETA.
Potenciální případy použití
Toto řešení je ideální pro letecké, letecké a letecké odvětví.
Doporučení
Tato doporučení implementujte při nasazování pokročilých architektur mikroslužeb AKS.
Kontroler příchozího přenosu dat služby Application Gateway (AGIC)
Směrování brány rozhraní API je obecný vzor návrhu mikroslužeb. Brána rozhraní API funguje jako reverzní proxy server, který směruje požadavky klientů do mikroslužeb. Prostředek příchozího přenosu dat Kubernetes a kontroler příchozího přenosu dat zpracovávají většinu funkcí brány rozhraní API:
Směrování požadavků klientů na správné back-endové služby poskytuje jeden koncový bod pro klienty a pomáhá oddělit klienty od služeb.
- Agregace více požadavků do jednoho požadavku za účelem omezení chatování mezi klientem a back-endem.
- Přesměrování zpracování funkcí, jako je ukončení protokolu SSL, ověřování, omezení IP adres a omezování rychlosti klienta nebo omezování z back-endových služeb.
Stav clusteru AKS se přeloží do konfigurace specifické pro službu Application Gateway a použije se prostřednictvím Azure Resource Manageru.
Externí kontrolery příchozího přenosu dat zjednodušují příjem provozu do clusterů AKS, zlepšují bezpečnost a výkon a šetří prostředky. Tato architektura používá Aplikace Azure lication Gateway Ingress Controller (AGIC) pro řízení příchozího přenosu dat. Použití služby Application Gateway ke zpracování veškerého provozu eliminuje potřebu dalšího nástroje pro vyrovnávání zatížení. Vzhledem k tomu, že pody navazují přímá připojení ke službě Application Gateway, snižuje se počet požadovaných segmentů směrování, což vede k lepšímu výkonu.
Application Gateway má integrované možnosti automatického škálování, na rozdíl od kontrolerů příchozího přenosu dat v clusteru, které je potřeba škálovat na více instancí, pokud spotřebovávají nepotřebné množství výpočetních prostředků. Služba Application Gateway může provádět směrování vrstvy 7 a ukončení protokolu SSL a má kompletní integraci protokolu TLS (Transport Layer Security) s integrovanou bránou firewall webových aplikací (WAF).
U možnosti příchozího přenosu dat AGIC je nutné povolit sítě CNI při konfiguraci clusteru AKS, protože služba Application Gateway je nasazená do podsítě virtuální sítě AKS. Víceklientskými úlohami nebo jedním clusterem, který podporuje vývojová a testovací prostředí, můžou vyžadovat další kontrolery příchozího přenosu dat.
Zásady sítě s nulovou důvěryhodností
Zásady sítě určují, jak mají pody AKS mezi sebou komunikovat a s ostatními koncovými body sítě. Ve výchozím nastavení je povolený veškerý příchozí a výchozí provoz do podů a z podů. Při navrhování toho, jak spolu mikroslužby komunikují a s jinými koncovými body, zvažte použití principu nulové důvěryhodnosti, kdy přístup k jakékoli službě, zařízení, aplikaci nebo úložišti dat vyžaduje explicitní konfiguraci.
Jednou ze strategií při implementaci zásad nulové důvěryhodnosti je vytvoření zásady sítě, která zakazuje veškerý příchozí a odchozí provoz do všech podů v rámci cílového oboru názvů. Následující příklad ukazuje odepření všech zásad, které by platily pro všechny pody umístěné v back-end-dev oboru názvů.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: backend-dev
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Jakmile je zavedená omezující zásada, začněte definovat konkrétní pravidla sítě, která povolí provoz do a z každého podu v mikroslužbě. V následujícím příkladu se zásady sítě použijí na libovolný pod v back-end-dev oboru názvů s popiskem, který odpovídá app.kubernetes.io/component: backend. Zásada odmítne veškerý provoz, pokud zdroj z podu s popiskem, který odpovídá app.kubernetes.io/part-of: dronedelivery.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: package-v010-dev-np-allow-ingress-traffic
namespace: backend-dev
spec:
podSelector:
matchLabels:
app.kubernetes.io/component: backend
ingress:
- from:
- podSelector:
matchLabels:
app.kubernetes.io/part-of: dronedelivery
ports:
- port: 80
protocol: TCP
Kvóty prostředků
Kvóty zdrojů představují způsob, jak správci rezervovat a omezit prostředky v rámci vývojového týmu nebo projektu. Kvóty prostředků pro obor názvů můžete nastavit a použít je k nastavení limitů pro:
- Výpočetní prostředky, jako jsou procesory a paměť nebo GPU.
- Prostředky úložiště, včetně počtu svazků nebo množství místa na disku pro danou třídu úložiště.
- Počet objektů, například maximální počet tajných kódů, služeb nebo úloh, které je možné vytvořit.
Jakmile kumulativní součet požadavků na prostředky nebo omezení překročí přiřazenou kvótu, žádná další nasazení nebudou úspěšná.
Kvóty prostředků zajišťují, aby celková sada podů přiřazených k oboru názvů nemohla překročit kvótu prostředků oboru názvů. Front-end nemůže hladovět back-endové služby pro prostředky nebo naopak.
Při definování kvót prostředků musí všechny pody vytvořené v oboru názvů poskytovat omezení nebo požadavky ve specifikacích podů. Pokud tyto hodnoty nezadají, nasazení se odmítne.
Následující příklad ukazuje specifikaci podu, která nastavuje požadavky a limity kvót prostředků:
requests:
cpu: 100m
memory: 350Mi
limits:
cpu: 200m
memory: 500Mi
Další informace o kvótách prostředků najdete tady:
Automatické škálování
Kubernetes podporuje automatické škálování , aby se zvýšil počet podů přidělených k nasazení nebo zvýšil počet uzlů v clusteru, aby se zvýšil celkový počet dostupných výpočetních prostředků. Automatické škálování je samoopravující autonomní systém zpětné vazby. I když můžete škálovat pody a uzly ručně, automatické škálování minimalizuje riziko, že se služby při vysokém zatížení stanou hladověnými prostředky. Strategie automatického škálování musí brát v úvahu pody i uzly.
Automatické škálování clusteru
Automatické škálování clusteru (CA) škáluje počet uzlů. Předpokládejme, že pody nelze naplánovat kvůli omezením prostředků; automatické škálování clusteru zřídí více uzlů. Definujete minimální počet uzlů, aby byl cluster AKS a vaše úlohy funkční a maximální počet uzlů pro velký provoz. Certifikační autorita každých několik sekund zkontroluje čekající pody nebo prázdné uzly a odpovídajícím způsobem škáluje cluster AKS.
Následující příklad ukazuje konfiguraci certifikační autority ze šablony ARM:
"autoScalerProfile": {
"scan-interval": "10s",
"scale-down-delay-after-add": "10m",
"scale-down-delay-after-delete": "20s",
"scale-down-delay-after-failure": "3m",
"scale-down-unneeded-time": "10m",
"scale-down-unready-time": "20m",
"scale-down-utilization-threshold": "0.5",
"max-graceful-termination-sec": "600",
"balance-similar-node-groups": "false",
"expander": "random",
"skip-nodes-with-local-storage": "true",
"skip-nodes-with-system-pods": "true",
"max-empty-bulk-delete": "10",
"max-total-unready-percentage": "45",
"ok-total-unready-count": "3"
},
Následující řádky v šabloně ARM nastaví příklad minimálního a maximálního počtu uzlů pro certifikační autoritu:
"minCount": 2,
"maxCount": 5,
Automatické škálování podů
Horizontální automatické škálování podů (HPA) škáluje pody na základě pozorovaných metrik procesoru, paměti nebo vlastních metrik. Pokud chcete nakonfigurovat horizontální škálování podů, zadáte cílové metriky a minimální a maximální počet replik ve specifikaci podu nasazení Kubernetes. Zátěžový test služeb k určení těchto čísel.
Ca a HPA dobře spolupracují, takže povolte obě možnosti automatického škálování v clusteru AKS. HPA škáluje aplikaci, zatímco certifikační autorita škáluje infrastrukturu.
Následující příklad nastaví metriky prostředků pro HPA:
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: delivery-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: delivery
minReplicas: 2
maxReplicas: 5
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 60
HPA se podívá na skutečné prostředky spotřebované nebo jiné metriky spuštěných podů, ale certifikační autorita zřídí uzly pro pody, které ještě nejsou naplánované. Proto certifikační autorita zkoumá požadované prostředky, jak je uvedeno ve specifikaci podu. Tyto hodnoty můžete doladit pomocí zátěžového testování.
Sondy stavu
Kubernetes vyrovnává provoz do podů, které odpovídají selektoru popisků pro službu. 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 odebere pod a naplánuje nahrazení.
V Kubernetes může pod vystavit dva typy sond stavu:
- Sonda aktivity říká Kubernetes, jestli se pod úspěšně spustil a je v pořádku.
- Sonda připravenosti říká Kubernetes, jestli je pod připravený přijímat požadavky.
Sondy aktivity zpracovávají pody, které jsou stále spuštěné, ale nejsou v pořádku a měly by být recyklovány. Pokud například kontejner obsluhující požadavky HTTP přestane reagovat, kontejner se neshromáždí, ale přestane obsluhovat požadavky. Sonda aktivity HTTP přestane reagovat, což informuje Kubernetes o restartování podu.
Někdy nemusí být pod připravený k příjmu provozu, i když se pod úspěšně spustil. Například aplikace spuštěná v kontejneru může provádět úlohy inicializace. Sonda připravenosti udává, jestli je pod připravený přijímat provoz.
Mikroslužby by měly zveřejnit koncové body ve svém kódu, které usnadňují sondy stavu, se zpožděním a časovým limitem přizpůsobeným speciálně kontrolám, které provádějí. Klíče vzorců HPA jsou téměř výhradně mimo fázi Připraveno na podu, takže je důležité, aby sondy stavu existovaly a byly přesné.
Sledování
V aplikaci mikroslužeb je monitorování application Performance Management (APM) důležité pro detekci anomálií, diagnostiku problémů a rychlé pochopení závislostí mezi službami. Application Insights, která je součástí služby Azure Monitor, poskytuje monitorování APM pro živé aplikace napsané v .NET Core, Node.js, Javě a mnoha dalších jazycích aplikací.
Application Insights:
- Protokoluje požadavky HTTP, včetně latence a kódu výsledku.
- Ve výchozím nastavení povolí distribuované trasování.
- Zahrnuje ID operace v trasování, takže můžete spárovat všechny trasování konkrétní operace.
- Často zahrnuje další kontextové informace v trasování.
Pokud chcete kontextovat telemetrii služeb se světem Kubernetes, integrujte telemetrii služby Azure Monitor s AKS a shromážděte metriky z kontrolerů, uzlů a kontejnerů a také protokolů kontejnerů a uzlů. Pokud používáte .NET, knihovna Application Insights pro Kubernetes rozšiřuje telemetrii Application Insights o image, kontejner, uzel, pod, popisek a informace o sadě replik.
Následující diagram znázorňuje příklad mapy závislostí aplikace, kterou Application Insights generuje pro trasování telemetrie mikroslužeb AKS:
Další informace o možnostech instrumentace běžných jazyků pro integraci Application Insights najdete v tématu Monitorování aplikací pro Kubernetes.
Důležité informace
Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.
Škálovatelnost
Při plánování škálovatelnosti zvažte následující body.
Nekombinujte automatické škálování a imperativní ani deklarativní správu počtu replik. Uživatelé i automatické škálování, kteří se pokoušejí změnit počet replik, můžou způsobit neočekávané chování. Pokud je povolená služba HPA, snižte počet replik na minimální počet, který chcete nasadit.
Vedlejším účinkem automatického škálování podů je, že se pody můžou vytvářet nebo vyřadit často, protože dochází k událostem horizontálního navýšení kapacity a horizontálního navýšení kapacity. Zmírnění těchto účinků:
- Pomocí sond připravenosti dejte Kubernetes vědět, kdy je nový pod připravený přijímat provoz.
- Pomocí rozpočtů přerušení podů omezte počet podů, které je možné vyřadit ze služby najednou.
Po vytvoření clusteru nemůžete velikost virtuálního počítače změnit, proto při vytváření clusteru vyberte odpovídající velikost virtuálního počítače pro uzly agenta.
Víceklientové nebo jiné pokročilé úlohy můžou mít požadavky na izolaci fondu uzlů, které vyžadují větší a pravděpodobně menší podsítě. Další informace o vytváření fondů uzlů s jedinečnými podsítěmi najdete v tématu Přidání fondu uzlů s jedinečnou podsítí. Organizace mají různé standardy pro své hvězdicové implementace. Nezapomeňte postupovat podle pokynů organizace.
Možnosti správy
Při plánování správy zvažte následující body.
Správa infrastruktury clusteru AKS prostřednictvím kanálu automatizovaného nasazení Referenční implementace pro tuto architekturu poskytuje pracovní postup GitHub Actions , na který můžete odkazovat při vytváření kanálu.
Soubor pracovního postupu nasadí pouze infrastrukturu, nikoli úlohu, do již existující virtuální sítě a konfigurace Microsoft Entra. Nasazení infrastruktury a úloh samostatně umožňuje řešit různé životní cyklus a provozní obavy.
Pokud dojde k selhání oblasti, zvažte pracovní postup jako mechanismus nasazení do jiné oblasti. Sestavte kanál, abyste mohli nasadit nový cluster v nové oblasti s parametrem a vstupními změnami.
Zabezpečení
Zabezpečení poskytuje záruky proti záměrným útokům a zneužití cenných dat a systémů. Další informace najdete v tématu Přehled pilíře zabezpečení.
Při plánování zabezpečení zvažte následující body.
Pod AKS se ověřuje pomocí identity úlohy uložené v Microsoft Entra ID. Použití identity úlohy je vhodnější, protože nevyžaduje tajný klíč klienta.
Pomocí spravovaných identit může proces provádění rychle získat tokeny OAuth 2.0 Azure Resource Manageru; není nutné používat hesla ani připojovací řetězec. V AKS můžete identitám přiřadit jednotlivé pody pomocí ID úloh Microsoft Entra.
Každá služba v aplikaci mikroslužby by měla mít přiřazenou jedinečnou identitu úlohy, aby bylo možné usnadnit přiřazení RBAC s nejnižšími oprávněními. Identitám byste měli přiřadit jenom služby, které je vyžadují.
V případech, kdy komponenta aplikace vyžaduje přístup k rozhraní API Kubernetes, se ujistěte, že jsou pody aplikací nakonfigurované tak, aby používaly účet služby s odpovídajícím oborem přístupu k rozhraní API. Další informace o konfiguraci a správě účtu služby Kubernetes najdete v tématu Správa účtů služby Kubernetes Service.
Ne všechny služby Azure podporují ověřování roviny dat pomocí ID Microsoft Entra. K ukládání přihlašovacích údajů nebo tajných kódů aplikací pro tyto služby, pro služby třetích stran nebo pro klíče rozhraní API použijte Azure Key Vault. Azure Key Vault poskytuje centralizovanou správu, řízení přístupu, šifrování neaktivních uložených dat a auditování všech klíčů a tajných kódů.
V AKS můžete připojit jeden nebo více tajných kódů ze služby Key Vault jako svazek. Pod pak může číst tajné kódy služby Key Vault stejně jako běžný svazek. Další informace najdete v projektu secrets-store-csi-driver-provider-azure na GitHubu.
Optimalizace nákladů
Optimalizace nákladů se zabývá způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace najdete v tématu Přehled pilíře optimalizace nákladů.
Část Náklady v architektuře Microsoft Azure popisuje aspekty nákladů. K odhadu nákladů pro konkrétní scénář použijte cenovou kalkulačku Azure.
AKS nemá žádné náklady spojené s nasazením, správou a provozem clusteru Kubernetes. Platíte jenom za instance virtuálních počítačů, úložiště a síťové prostředky, které cluster spotřebovává. Automatické škálování clusteru může výrazně snížit náklady na cluster odebráním prázdných nebo nepoužívaných uzlů.
Pokud chcete odhadnout náklady na požadované prostředky, přečtěte si kalkulačku služby Container Services.
Zvažte povolení analýzy nákladů AKS pro podrobné přidělování nákladů na infrastrukturu clusteru podle konkrétních konstruktorů Kubernetes.
Další kroky
- Seznámení se službou Azure Kubernetes Service
- Co jsou virtuální sítě Azure?
- Co je privátní propojení Azure?
- Co je Aplikace Azure lication Gateway?
- Co je Azure Bastion?
- O Azure Key Vault
- Úvod do služby Azure Container Registry
- Vítá vás Azure Cosmos DB
- Přehled služby Azure Monitor