Architektura mikroslužeb Advanced Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Kubernetes Service (AKS)

Azure Virtual Network

Tato referenční architektura popisuje několik konfigurací, které je potřeba zvážit při spouštění mikroslužeb ve službě Azure Kubernetes Service (AKS). Tento článek popisuje konfiguraci zásad sítě, automatické škálování podů a distribuované trasování napříč aplikací založenou na mikroslužbách.

Tato architektura vychází ze základní architektury AKS, která slouží jako výchozí bod pro infrastrukturu AKS. Standardní hodnoty AKS popisují funkce infrastruktury, jako je ID úlohy Microsoft Entra, omezení příchozího přenosu dat a výchozího přenosu dat, limity prostředků a další zabezpečené konfigurace infrastruktury AKS. Tyto funkce nejsou popsané v tomto článku. Než budete pokračovat v práci s obsahem mikroslužeb, doporučujeme seznámit se se základní architekturou AKS.

Architektura

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

Pokud chcete 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.

Následující pracovní postup odpovídá předchozímu diagramu:

Žádost HTTPS se odešle k naplánování vyzvednutí dronů. Požadavek prochází službou Azure Application 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 Azure Service Bus.
Back-endový systém přiřadí dron a upozorní uživatele. Mikroslužba pracovního postupu provede následující úlohy:
- Využívá informace o zprávě z fronty zpráv služby Service Bus.
- Odešle požadavek HTTPS do mikroslužby pro doručování, která předává data do externího úložiště externích dat Azure Managed Redis.
- Odešle požadavek HTTPS do mikroslužby plánovače dronů.
- Odešle požadavek HTTPS do mikroslužby balíčku, která předává data do externího úložiště dat Azure DocumentDB.
- Pokročilé zásady služby Container Networking Services (Cilium NetworkPolicy) řídí provoz mezi službami uvnitř clusteru a rovina dat transparentně vynucuje volitelné šifrování podů mezi uzly (WireGuard). Služba Advanced Container Networking Services není ve výchozím nastavení povolená. Načte data na úrovni uzlů a podů a ingestuje je do služby Azure Monitor, aby bylo možné získat kompletní viditelnost.
Architektura používá požadavek HTTPS GET k vrácení stavu doručení. Tento požadavek prochází službou Application Gateway do mikroslužby doručování.
Mikroslužba doručování čte data ze služby Azure Managed Redis.

Komponenty

AKS je spravovaná platforma Kubernetes, která poskytuje spravované clustery pro nasazování a škálování kontejnerizovaných aplikací. Když používáte AKS, Azure spravuje server rozhraní API Kubernetes. Operátor clusteru může přistupovat k uzlům Kubernetes nebo fondům uzlů a spravovat je. Tato architektura používá následující funkce infrastruktury AKS:
- AKS-managed Microsoft Entra ID for Azure role-based access control (Azure RBAC) je funkce, která integruje Microsoft Entra ID s AKS k vynucení řízení přístupu na základě identity. V této architektuře zajišťuje zabezpečené, centralizované ověřování a autorizaci pro uživatele a úlohy clusteru.
- Azure CNI využívající Cilium je doporučené síťové řešení pro přímé připojení k virtuální síti Azure. V této architektuře přiřazuje IP adresy z virtuální sítě k podům a poskytuje integrované možnosti zásad sítě a viditelnost provozu.
- Advanced Container Networking Services je sada spravovaných síťových funkcí pro AKS, která poskytuje pozorovatelnost sítě a rozšířené zabezpečení v clusteru:
  - Pozorovatelnost kontejnerové sítě využívá nástroje založené na rozšířeném filtru paketů Berkeley (eBPF), jako je Hubble a Retina, ke shromažďování dotazů DNS (Domain Name System), toků mezi kontejnery a mezi kontejnery a službami, poklesů paketů a dalších metrik. Funguje jak v datových rovinách Cilium, tak i v datových rovinách Linuxu, které nejsou Cilium. Integruje se také se spravovanou službou Azure Monitor pro Prometheus a Azure Managed Grafana pro vizualizaci a upozorňování. V této architektuře služba Container Network Observability diagnostikuje chybné konfigurace zásad, latenci DNS nebo chyby a nerovnováhu provozu mezi mikroslužbami.
  - Container Network Security se vztahuje na clustery, které používají Azure CNI využívající Cilium. Vynucuje prostředky Cilium NetworkPolicy, včetně filtrování odchozího přenosu dat založeného na plně kvalifikovaném názvu domény (FQDN), pro implementaci segmentace sítě s nulovou důvěrou a pro snížení provozních nákladů. V této architektuře fungují zásady FQDN v rámci clusteru společně se službou Azure Firewall nebo Azure NAT Gateway, aby vynucovaly výstup s minimálními oprávněními a zároveň zjednodušovaly údržbu zásad.
- Doplněk Azure Policy pro AKS je integrované rozšíření, které přímo do clusterů AKS přináší řízení zásad správného řízení a dodržování předpisů. Používá pravidla zásad správného řízení napříč prostředky AKS pomocí služby Azure Policy. V této architektuře vynucuje dodržování předpisů ověřováním konfigurací a omezením neautorizovaných nasazení.
- Spravované příchozí přenosy dat NGINX pomocí doplňku pro směrování aplikací jsou funkce v AKS, která pomáhá zpřístupnit aplikace na internetu pomocí provozu HTTP nebo HTTPS. Poskytuje předem nakonfigurovaný kontroler příchozího přenosu dat NGINX pro AKS. V této architektuře zpracovává směrování provozu do služeb a umožňuje vystavení podů službě Application Gateway.
- Oddělení fondů systémových a uživatelských uzlů je architektura, která rozděluje uzly clusteru na dva různé typy fondů uzlů a izoluje komponenty infrastruktury AKS od úloh aplikací. V této architektuře se zvyšuje efektivita zabezpečení a prostředků tím, že fondy uzlů vyhradí na konkrétní provozní role.
- ID úlohy je bezpečný a škálovatelný způsob přístupu k prostředkům Azure pro úlohy Kubernetes pomocí ID Microsoft Entra bez nutnosti tajných kódů nebo přihlašovacích údajů uložených v clusteru. ID úlohy umožňuje úlohám AKS bezpečně přistupovat k prostředkům Azure pomocí federované identity. V této architektuře eliminuje potřebu tajných kódů a zlepšuje stav zabezpečení prostřednictvím přístupu na základě identit.
Application Gateway je služba spravovaná v Azure, která poskytuje vyrovnávání zatížení vrstvy 7 a funkce firewallu webových aplikací (WAF). V této architektuře zveřejňuje mikroslužbu příjmu jako veřejný koncový bod a vyrovnává příchozí webový provoz do aplikace.
Azure Firewall je služba spravovaná v Azure, která poskytuje inteligentní zabezpečení sítě nativní pro cloud a ochranu před hrozbami. V této architektuře řídí odchozí komunikaci z mikroslužeb do externích prostředků, což povoluje pouze schválené FQDN jako odchozí provoz.
Azure Private Link je služba spravovaná v Azure, která umožňuje privátní připojení k nabídkám PaaS (Platforma jako služba) Azure prostřednictvím páteřní sítě Microsoftu. V této architektuře přiřadí privátní IP adresy pro přístup ke službě Azure Container Registry a Azure Key Vaultu z fondů uzlů AKS prostřednictvím privátních koncových bodů.
Azure Virtual Network je služba spravovaná v Azure, která poskytuje izolovaná a zabezpečená prostředí pro spouštění aplikací a virtuálních počítačů. V této architektuře používá topologii s hvězdicovou hvězdicovou strukturou. Síť centra hostuje Službu Azure Firewall a Azure Bastion. Paprsková síť obsahuje podsítě systému AKS a fondu uzlů uživatelů spolu s podsítí služby Application Gateway.

Externí úložiště a další komponenty

Azure Managed Redis je služba spravovaná v Azure, která poskytuje vysoce výkonné úložiště dat v paměti pro ukládání do mezipaměti, úložiště relací a přístup k datům v reálném čase. Kromě tradičního ukládání do mezipaměti zahrnuje podporu pokročilých datových typů a funkcí, jako je úložiště dokumentů JSON, fulltextové a vektorové vyhledávání a zpracování datových proudů. V této architektuře mikroslužba pro doručování využívá Azure Managed Redis jako úložiště stavu a mezipaměť na straně ke zlepšení rychlosti a odezvy během náročného provozu.
Container Registry je služba spravovaná v Azure, která ukládá privátní image kontejnerů pro nasazení v AKS. V této architektuře uchovává image kontejnerů pro mikroslužby a AKS se s ní ověřuje pomocí své spravované identity Microsoft Entra. Můžete také použít další registry, jako je Docker Hub.
Azure Cosmos DB je globálně distribuovaná služba NoSQL, relační a vektorové databáze spravovaná v Azure. V této architektuře slouží Azure Cosmos DB a Azure DocumentDB jako externí úložiště dat pro každou mikroslužbu.
Key Vault je služba spravovaná v Azure, která bezpečně ukládá a spravuje tajné kódy, klíče a certifikáty. V této architektuře ukládá služba Key Vault přihlašovací údaje, které mikroslužby používají pro přístup ke službě Azure Cosmos DB a Azure Managed Redis.
Azure Monitor je platforma pozorovatelnosti spravovaná v Azure, která shromažďuje metriky, protokoly a telemetrii napříč službami. V této architektuře umožňuje monitorování aplikace, upozorňování, řídicího panelu a analýzy původní příčiny selhání napříč službami AKS a integrovanými službami.

Pozorovatelnost sítí kontejnerů pro pokročilé služby kontejnerového síťového připojení používá Hubble k viditelnosti toku a Retina pro spravovanou síťovou telemetrii. Tyto nástroje se integrují se spravovanými back-endy pro pozorovatelnost, jako je Azure Monitor managed service for Prometheus a Azure Managed Grafana, k řešení potíží a sestavování zpráv o servisu na úrovni služeb (SLO).
Service Bus je služba zasílání zpráv spravovaná v Azure, která podporuje spolehlivou a asynchronní komunikaci mezi distribuovanými aplikacemi. V této architektuře služba Service Bus slouží jako vrstva fronty mezi mikroslužbami příjmu dat a pracovních postupů, která umožňuje oddělenou a škálovatelnou výměnu zpráv.

Ostatní operace podporují systémové komponenty

Flux je Azurem podporované, open-source a rozšiřitelné řešení průběžného doručování pro Kubernetes, které umožňuje GitOps v AKS. V této architektuře Flux automatizuje nasazení synchronizací souborů manifestu aplikace z úložiště Git, což zajišťuje konzistentní a deklarativní doručování mikroslužeb do clusteru AKS.
Helm je nativní správce balíčků Kubernetes, který spojuje objekty Kubernetes do jedné jednotky pro publikování, nasazování, správu verzí a aktualizaci. V této architektuře se Helm používá k balení a nasazování mikroslužeb do clusteru AKS.
Ovladač CSI pro úložiště tajemství služby Key Vault je ovladač integrovaný do Azure, který umožňuje clusterům AKS připojit tajemství ze služby Key Vault pomocí svazků CSI. V této architektuře se tajné kódy připojují přímo do kontejnerů mikroslužeb, což umožňuje zabezpečené načítání přihlašovacích údajů pro Azure Cosmos DB a Azure Managed Redis.

Alternativy

Místo použití doplňku pro směrování aplikací můžete použít alternativy, jako je Application Gateway for Containers a doplněk Istio Gateway. Porovnání možností příchozího přenosu dat v AKS najdete v tématu Příchozí přenos dat v AKS. Application Gateway pro kontejnery je evolucí řadiče příchozího toku služby Application Gateway a poskytuje další funkce, jako je rozdělení provozu a vážené vyrovnávání zatížení metodou round-robin.

Jako nástroj GitOps můžete místo fluxu použít ArgoCD. Flux i ArgoCD jsou k dispozici jako rozšíření clusteru.

Místo ukládání přihlašovacích údajů pro Azure Cosmos DB a Azure Managed Redis v trezorech klíčů doporučujeme používat spravované identity k ověřování, protože mechanismy ověřování bez hesla jsou bezpečnější. Další informace najdete v tématu Použití spravovaných identit pro připojení ke službě Azure Cosmos DB z virtuálního počítače Azure a ověření spravované identity pomocí ID Microsoft Entra pro přístup k prostředkům služby Service Bus. Azure Managed Redis také podporuje ověřování pomocí spravovaných identit.

Podrobnosti scénáře

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í. Zákazník může sledovat polohu dronů a sledovat nepřetržitě aktualizovaný odhadovaný čas příjezdu, zatímco probíhá doručení.

Doporučení

Následující doporučení můžete použít pro většinu scénářů. Pokud nemáte konkrétní požadavek, který by těmto doporučením nedopovídal, postupujte podle nich.

Spravované příchozí přenosy dat NGINX s doplňkem směrování aplikací

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 provedením následujících akcí:

Směrování požadavků klientů na správné back-endové služby za účelem poskytnutí jednoho koncového bodu pro klienty a pomoc s oddělením klientů od služeb
Agregace více požadavků do jednoho požadavku za účelem snížení chatování mezi klientem a back-endem
Přesměrování zpracování funkcí, jako je ukončení protokolu SSL (Secure Sockets Layer), ověřování, omezení IP adres a omezování rychlosti klienta z back-endových služeb

Kontrolery příchozích dat zjednodušují příjem provozu do clusterů AKS, zlepšují bezpečnost a výkon a šetří prostředky. Tato architektura používá spravované příchozí přenosy dat NGINX s doplňkem směrování aplikace pro řízení příchozího přenosu dat.

Doporučujeme použít kontroler příchozího přenosu dat s interní (privátní) IP adresou a interním nástrojem pro vyrovnávání zatížení a integrovat ho do privátních zón DNS Azure pro překlad názvů hostitelů mikroslužeb. Nakonfigurujte privátní IP adresu nebo název hostitele kontroleru příchozího přenosu dat jako adresu back-endového fondu ve službě Application Gateway. Application Gateway přijímá provoz na veřejném koncovém bodu, provádí kontroly WAF a směruje provoz na privátní IP adresu příchozího přenosu dat.

Nakonfigurujte kontroler příchozího přenosu dat s vlastním názvem domény a certifikátem SSL tak, aby provoz byl kompletní šifrovaný. Application Gateway přijímá provoz na naslouchacím procesu HTTPS. Po kontrole WAF služba Application Gateway směruje provoz do koncového bodu HTTPS kontroleru příchozího přenosu dat. Nakonfigurujte všechny mikroslužby tak, aby používaly vlastní názvy domén a certifikáty SSL, které zabezpečují komunikaci mezi mikroslužbami v rámci clusteru AKS.

Víceklientskými úlohami nebo jedním clusterem, který podporuje vývojová a testovací prostředí, můžou vyžadovat více kontrolerů příchozího přenosu dat. Doplněk pro směrování aplikací podporuje pokročilé konfigurace a přizpůsobení, včetně více kontrolerů příchozího přenosu dat v rámci stejného clusteru AKS a použití poznámek ke konfiguraci prostředků příchozího přenosu dat.

Sítě a zásady sítě

Používejte Azure CNI využívající Cilium. Datová vrstva eBPF má vhodný výkon směrování a podporuje libovolně velký cluster. Cilium nativně implementuje Kubernetes NetworkPolicy a poskytuje rozsáhlou viditelnost síťového provozu. Další informace najdete v tématu Konfigurace Azure CNI využívajícího Cilium v AKS.

Důležité

Pokud ve své architektuře mikroslužeb vyžadujete uzly Windows, projděte si aktuální omezení jen pro Linux a naplánujte vhodné plány pro smíšené fondy operačního systému. Další informace najdete v tématu omezení Azure CNI poháněného technologií Cilium.

Pro konkrétní potřeby správy IP adres podporuje Azure CNI využívající Cilium jak modely IP adres směrovaných virtuální sítí, tak i překryvné pody. Další informace najdete v tématu Azure CNI využívající cilium.

Zásady sítě nulové důvěryhodnosti

Zásady sítě určují, jak spolu pody AKS komunikují 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 návrhu 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. Definujte a vynucujte Zásady sítě Kubernetes (implementované službou Advanced Container Networking Services/Cilium) pro segmentaci provozu mezi mikroslužbami a omezení výchozího přenosu dat pouze na povolené plně kvalifikované názvy domén.

Jednou ze strategií implementace 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é platí pro všechny pody umístěné v backend-dev oboru názvů.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

Po nastavení omezující zásady začněte definovat konkrétní pravidla sítě, která umožní provoz do a z každého podu v mikroslužbě. V následujícím příkladu se zásady sítě Cilium použijí na jakýkoli pod v backend-dev oboru názvů, který má popisek, který odpovídá app.kubernetes.io/component: backend. Zásada odmítne veškerý provoz, pokud není zdrojový z podu, který má popisek, který odpovídá app.kubernetes.io/part-of: dronedelivery.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

Další informace o zásadách sítě Kubernetes a dalších příkladech potenciálních výchozích zásad najdete v dokumentaci ke zásadám sítě Kubernetes. Osvědčené postupy pro zásady sítě v AKS najdete v tématu Použití zásad sítě v AKS.

Pokud používáte Azure CNI využívající Cilium, je NetworkPolicy Kubernetes vynucován pomocí Cilium. Pro specializované požadavky poskytuje Azure další moduly zásad sítě, včetně správce zásad sítě Azure a Calico. Jako výchozí modul zásad sítě doporučujeme Cilium.

Kvóty prostředků

Správci používají kvóty zdrojů k rezervaci a omezení zdrojů 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 následující prostředky:

Výpočetní prostředky, jako jsou jednotky centrálního zpracování (procesory), paměť a grafické procesory (GPU)
Prostředky úložiště, včetně počtu svazků nebo místa na disku pro konkrétní třídu úložiště
Počet objektů, jako je maximální počet tajemství, služeb nebo úloh, které lze 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 používat všechny prostředky pro back-endové služby a back-end nemůže používat všechny prostředky pro front-endové služby.

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 v následujících článcích:

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. Pody a uzly můžete škálovat ručně, ale automatické škálování minimalizuje riziko, že služby při vysokém zatížení dosáhnou limitů prostředků. Strategie automatického škálování musí odpovídat pro pody i uzly.

Automatické škálování clusteru

Automatické škálování clusteru (CA) škáluje počet uzlů. Pokud se pody nedají naplánovat kvůli omezením prostředků, certifikační autorita 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 Bicep clusteru:

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ě Bicep nastaví příklad minimálního a maximálního počtu uzlů pro certifikační autoritu:

minCount: 2
maxCount: 5

Horizontální 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 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/v2
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
        target:
          type: Utilization
          averageUtilization: 70

HPA zohledňuje skutečné prostředky spotřebované nebo jiné metriky ze spuštěných podů. Certifikační autorita zřídí uzly pro pody, které ještě nejsou naplánované. V důsledku toho 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í.

Další informace najdete v tématu Možnosti škálování pro aplikace v AKS.

Vertikální automatické škálování podů

Vertikální automatické škálování podů (VPA) automaticky upraví požadavky na procesor a paměť pro vaše pody tak, aby odpovídaly vzorcům využití vašich úloh. Když je nakonfigurovaná, VPA automaticky nastaví požadavky na prostředky a omezení kontejnerů pro každou úlohu na základě předchozího využití. VPA zpřístupňuje procesor a paměť pro jiné pody a pomáhá zajistit efektivní využití clusterů AKS.

V této architektuře VPA zvyšuje požadavky na procesor a paměť a limity pro mikroslužby na základě jejich předchozího využití. Pokud například mikroslužba pracovního postupu využívá více procesoru v porovnání s jinými mikroslužbami, může VPA toto využití monitorovat a zvýšit limity procesoru pro mikroslužbu pracovního postupu.

Automatické škálování řízené událostmi v Kubernetes

Doplněk Kubernetes Event-Driven Autoscaling (KEDA) umožňuje škálování řízené událostmi, které zajišťuje škálování mikroslužby za účelem pokrytí poptávky udržitelným a nákladově efektivním způsobem. KeDA může například vertikálně navýšit kapacitu mikroslužeb, když počet zpráv ve frontě služby Service Bus překročí konkrétní prahové hodnoty.

Ve scénáři doručování dronů Fabrikam škáluje KEDA mikroslužbu pracovního postupu v závislosti na hloubkě fronty služby Service Bus a na základě výstupu mikroslužby příjmu dat. Seznam škálovacích nástrojů KEDA pro služby Azure najdete v tématu Integrace se službou KEDA v AKS.

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ě spustí a jsou v pořádku. Pokud dojde k chybovému ukončení kontejneru, Kubernetes odebere pod a naplánuje nahrazení. Kubernetes definuje tři typy sond stavu, které může pod vystavit:

Sonda připravenosti říká Kubernetes, jestli je pod připravený přijímat požadavky.
Sonda aktivity říká Kubernetes, jestli se má pod odebrat a jestli se má spustit nová instance.
Spouštěcí sonda říká Kubernetes, jestli je pod spuštěný.

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, který obsluhuje požadavky HTTP, přestane fungovat, kontejner neselhá, ale přestane obsluhovat požadavky. Sonda aktivity HTTP přestane reagovat, což upozorní Kubernetes na restartování podu.

Někdy nemusí být pod připravený k příjmu provozu, i když se pod úspěšně spustí. Například aplikace, která běží 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 v 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í. Vzorec HPA spoléhá na fázi připravenosti podu, takže je nezbytné, aby existovaly sondy stavu a byly přesné.

Sledování

Monitorování je nezbytné v architektuře mikroslužeb k detekci anomálií, diagnostice problémů a pochopení závislostí služeb. Application Insights, která je součástí služby Azure Monitor, poskytuje monitorování výkonu aplikací (APM) pro aplikace napsané v .NET, Node.js, Javě a mnoha dalších jazycích. Azure poskytuje několik integrovaných funkcí pro komplexní viditelnost:

Spravovaná služba Azure Monitoru pro Prometheus shromažďuje a upozorňuje na metriky infrastruktury a úloh.
Funkce Live Data v Přehledech kontejnerů monitoruje clustery, uzly a kontejnery AKS pro stav a využití prostředků.
Azure Managed Grafana vizualizuje metriky a řídicí panely pro clustery a mikroslužby.

Pokročilá pozorovatelnost služby Container Networking Services doplňuje tyto nástroje tím, že poskytuje hluboký přehled založený na protokolu eBPF na síťové chování clusterů AKS. Zaznamenává latenci DNS, toky pod-to-pod a služby, poklesy zásad sítě a metriky protokolu úrovně 7, jako jsou stavové kódy HTTP a doby odezvy. Tato telemetrie se integruje se spravovanou službou Azure Monitor pro Prometheus pro metriky a Azure Managed Grafana pro řídicí panely. Rovina dat Cilium eBPF poskytuje přehled a řešení potíží na úrovni toku. V kombinaci s pokročilými službami Container Networking Services a Azure Monitorem tato funkce poskytuje komplexní pozorovatelnost sítě. Tato integrace umožňuje detekci kritických bodů sítě, chybných konfigurací zásad a problémů s komunikací, které by tradiční APM mohly vynechat.

Návod

Kombinování síťových dat služby Advanced Container Networking Services s telemetrií služby Azure Monitor pro kompletní zobrazení stavu aplikace a infrastruktury Application Insights můžete také integrovat s AKS , aniž byste museli provádět změny kódu a korelovat výkon aplikací s clusterem a síťovými přehledy.

Důležité informace

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které můžete použít ke zlepšení kvality úlohy. Další informace najdete v tématu Well-Architected Framework.

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 naleznete v tématu Kontrolní seznam pro kontrolu návrhu prozabezpečení .

Při plánování zabezpečení zvažte následující body:

Použijte ochranu nasazení v clusteru AKS. Ochrana nasazení vynucuje osvědčené postupy Kubernetes ve vašem clusteru AKS prostřednictvím ovládacích prvků Azure Policy.
Integrujte kontrolu zabezpečení do kanálů sestavení a nasazení mikroslužeb. Spravujte prostředí DevOps pomocí zabezpečení Microsoft Defenderu pro Cloud DevOps. V rámci kanálů kontinuální integrace a průběžného nasazování (CI/CD) používejte kontrolu kódu bez agentů a spusťte nástroje pro analýzu statického kódu , abyste mohli identifikovat a řešit ohrožení zabezpečení kódu mikroslužby v rámci procesů sestavení a nasazení.
Pod AKS se ověřuje pomocí identity úlohy uložené v Microsoft Entra ID. Identitu úlohy byste měli použít, protože nevyžaduje tajný klíč klienta.
Když používáte spravované identity, může aplikace rychle získat tokeny OAuth 2.0 Azure Resource Manageru při spuštění. Nepotřebuje hesla ani připojovací řetězce. V AKS můžete přiřadit identity jednotlivým podům pomocí ID úlohy.
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í Azure RBAC s nejnižšími oprávněními. Přiřaďte identity pouze službám, 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 najdete v tématu Správa účtů služby Kubernetes.
Ne všechny služby Azure podporují Microsoft Entra ID pro autentizaci na úrovni dat. K ukládání přihlašovacích údajů nebo tajných kódů aplikací pro tyto služby, pro služby jiné společnosti než Microsoft nebo pro klíče rozhraní API použijte Key Vault. Poskytuje centralizovanou správu, řízení přístupu, šifrování neaktivních uložených dat a auditování pro všechny klíče a tajné kódy.
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 tématu Použití zprostředkovatele služby Key Vault pro ovladač CSI úložiště tajných kódů v clusteru AKS. Doporučujeme udržovat samostatné trezory klíčů pro každou mikroslužbu.

Advanced Container Networking Services poskytuje segmentaci sítě v clusteru a řízení nulové důvěryhodnosti pro clustery AKS. K implementaci segmentace vrstvy 3 a vrstvy 4 v clusteru použijte zásady sítě Cilium v Azure CNI využívající cilium . Pokročilé zabezpečení služby Container Networking Services rozšiřuje tento základ přidáním pokročilých funkcí:

FQDN základní filtrování odchozího provozu, které omezuje odchozí provoz na schválené domény.
Zásady s podporou úrovně 7 pro protokoly, jako jsou HTTP a gRPC Remote Procedure Call (gRPC), k ověřování a řízení komunikace na úrovni aplikace.
Šifrování WireGuard pro zabezpečení přenosu mezi kontejnery a ochranu citlivých dat během přenosu.

Tyto funkce fungují společně s hraniční obranou, jako jsou skupiny zabezpečení sítě (NSG) a Azure Firewall, aby poskytovaly vícevrstvý přístup zabezpečení, který vynucuje řízení provozu z clusteru.
Pokud mikroslužba potřebuje komunikovat s prostředky, jako jsou externí adresy URL mimo cluster, řídí přístup přes Azure Firewall. Pokud mikroslužba nepotřebuje provádět odchozí volání, použijte clustery izolované v síti.
Povolte Microsoft Defender for Containers , aby poskytoval správu stavu zabezpečení, posouzení ohrožení zabezpečení pro mikroslužby, ochranu před internetovými útoky za běhu a další funkce zabezpečení.

Mechanismy datového rozhraní a zásad sítě

Cilium na AKS je v současné době podporováno pro uzly Linuxu a zajišťuje uplatňování zásad sítě v datovém prostředí. Mějte na paměti upozornění ohledně zásad, například použití ipBlock s IP adresami uzlů a IP adresami podů, a že pody, které používají síť hostitele, mají identitu hostitele. Zásady na úrovni podů se nevztahují. Zarovnejte verze AKS a Cilium s podporovanou maticí verzí. Další informace najdete v tématu omezení Azure CNI poháněného technologií Cilium.

Optimalizace nákladů

Optimalizace nákladů se zaměřuje na způsoby, jak snížit zbytečné výdaje a zlepšit efektivitu provozu. Další informace naleznete v tématu Kontrolní seznam pro kontrolu návrhu proOptimalizace nákladů .

Část Optimalizace nákladů v Well-Architected Framework popisuje aspekty nákladů.
K odhadu nákladů pro konkrétní scénář použijte cenovou kalkulačku Azure.
Na úrovni Free nemá AKS žá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 využí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ů.
Zvažte použití úrovně Free AKS pro vývojové úlohy a pro produkční úlohy použijte úrovně Standard a Premium .
Zvažte povolení analýzy nákladů AKS pro podrobné přidělování nákladů na infrastrukturu clusteru podle konstruktorů specifických pro Kubernetes.

Efektivita provozu

Efektivita provozu se zabývá provozními procesy, které nasazují aplikaci a udržují ji spuštěnou v produkčním prostředí. Další informace naleznete v tématu kontrolní seznam pro kontrolu efektivity provozu.

Při plánování správy zvažte následující body:

Spravujte infrastrukturu clusteru AKS prostřednictvím automatizovaného nasazovacího pipeline, jako jsou pracovní postupy GitHub Actions.
Soubor pracovního postupu nasadí pouze infrastrukturu, nikoli úlohu, do již existující virtuální sítě a konfigurace Microsoft Entra. Nasazení infrastruktury a úlohy samostatně umožňuje řešit různé životní cykly 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.

Efektivita výkonu

Efektivita výkonu odkazuje na schopnost vaší úlohy efektivně škálovat tak, aby splňovala požadavky uživatelů. Další informace naleznete v tématu Kontrola návrhu kontrolní seznam pro zvýšení efektivity výkonu.

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. Pokud se uživatelé i automatické škálování pokusí změnit počet replik, může dojít k neočekávanému 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 často vytvářet nebo vyřadit, když se aplikace škáluje směrem dovnitř nebo ven. Aby se zmírnily tyto účinky, proveďte následující akce:
- 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.
Pokud z mikroslužby existuje velký počet odchozích toků, zvažte použití bran překladu síťových adres (NAT), abyste se vyhnuli vyčerpání portů překladu zdrojových síťových adres (SNAT).
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 najdete v tématu Přidání poolů uzlů, které mají jedinečné podsítě. Organizace mají různé standardy pro své hvězdicové implementace. Nezapomeňte postupovat podle pokynů organizace.
Zvažte použití Azure CNI s překryvnými sítěmi , abyste ušetřili adresní prostor sítě.

Další kroky

Váš názor

Byla tato stránka užitečná?