Rozšířená architektura mikroslužeb Azure Kubernetes Service (AKS)

Application Gateway

Container Registry

Kubernetes Service

Virtual Network

Tato referenční architektura popisuje několik konfigurací, které je potřeba vzít v úvahu při spouštění mikroslužeb na Azure Kubernetes Services. Témata zahrnují konfiguraci zásad sítě, automatického škálování a distribuované trasování v rámci aplikace založené na mikroslužbách.

Tato architektura se sestavuje na základě základní architektury AKS, doporučuje se od Microsoftu počáteční bod pro infrastrukturu AKS. AKS podle směrného plánu podrobně infrastruktury funkce, jako je Azure Active Directory (Azure AD) pod úrovní identity, příchozí a odchozí přenosy, omezení prostředků a další zabezpečené konfigurace infrastruktury AKS. Tyto podrobnosti infrastruktury nejsou pokryté v tomto dokumentu. Před pokračováním v obsahu mikroslužeb doporučujeme seznámit se s AKS směrným plánem.

logo GitHub v GitHubje k dispozici referenční implementace této architektury.

Diagram sítě znázorňující síť hvězdicové sítě se dvěma partnerskými virtuálními sítěmi a prostředky Azure, které tato implementace používá.

Pokud chcete začít používat pro AKS příklad základních mikroslužeb, přečtěte si téma Architektura mikroslužeb na AKS .

Komponenty

Tato architektura používá následující součásti Azure:

Služba Azure Kubernetes je nabídka Azure, která poskytuje spravovaný cluster Kubernetes. Při použití AKS se server Kubernetes API spravuje pomocí Azure. Uzly Kubernetes nebo fondy uzlů jsou přístupné a dají se spravovat pomocí operátora clusteru.

Mezi funkce infrastruktury AKS používané v této architektuře patří:

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 partnerským rozbočovačem. Virtuální síť rozbočovače obsahuje podsítě Azure firewall a Azure bastionu. Virtuální síť paprsků obsahuje podsítě AKS systémů a uživatelských uzlů a podsíť Azure Application Gateway.

Privátní odkaz Azure přiděluje konkrétní privátní IP adresy pro přístup k Azure Container Registry a Key Vault z privátních koncových bodů v rámci podsítě fondu uzlů v systému AKS a uživatelského uzlu.

Azure Application Gateway s firewallem webových aplikací (WAF) zveřejňuje trasy HTTP (S) do clusteru AKS a načítají zatížení webového provozu do webové aplikace. Tato architektura používá jako kontroler Kubernetes pro příchozí přenosy AGIC () Application Gateway Azure .

Azure bastionu poskytuje zabezpečený protokol RDP (Remote Desktop Protocol) a SSH (Secure Shell) k virtuálním počítačům ve virtuálních sítích pomocí protokolu SSL (Secure Socket Layer) bez nutnosti vystavovat virtuální počítače prostřednictvím veřejných IP adres.

Azure firewall je služba zabezpečení sítě, která chrání všechny prostředky Azure Virtual Network. Brána firewall povoluje jako výstupní přenos pouze schválené služby a plně kvalifikované názvy domény (FQDN).

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

Azure Key Vault ukládá a spravuje klíče zabezpečení pro služby AKS Services.

Azure Container Registry ukládá privátní image kontejnerů, které se dají spouštět v clusteru AKS. AKS se ověřuje pomocí Container Registry pomocí spravované identity Azure AD. Můžete také použít jiné Registry kontejnerů, jako je Docker Hub.

Azure Cosmos DB ukládá data pomocí open source rozhraní API Azure Cosmos DB pro MongoDB. Mikroslužby jsou obvykle bezstavové a píší jejich stav do externích úložišť dat. Azure Cosmos DB je databáze NoSQL s open source 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 asynchronní vzory zasílání zpráv, které jsou společné pro aplikace mikroslužeb.

Azure cache pro Redis přidává do architektury aplikace vrstvu ukládání do mezipaměti za účelem zlepšení rychlosti a výkonu pro náročné zatížení provozu.

Azure monitor shromažďuje a ukládá metriky a protokoly, včetně telemetrie aplikací a platforem Azure a metriky služeb. Tato data můžete použít k monitorování aplikace, nastavení výstrah a řídicích panelů a k analýze selhání hlavní příčiny.

Další součásti systému Operations Support (OSS):

Helm, správce balíčků pro Kubernetes, který vytváří objekty Kubernetes do jedné jednotky, kterou můžete publikovat, nasadit, verze a aktualizovat.

Azure Key Vault poskytovatel pro úložiště s tajnými klíči, načte tajné klíče uložené v Azure Key Vault a pomocí rozhraní ovladače úložiště s tajnými klíči je připojí k Kubernetes luskům.

Tok, otevřené a rozšiřitelné řešení pro průběžné doručování pro Kubernetes, které využívá GitOps Toolkit.

Tok požadavků

Ukázková aplikace pro doručování od společnosti Fabrikam pomocí dronů uvedená v předchozím diagramu implementuje komponenty architektury a postupy popsané v tomto článku. V tomto příkladu společnost Fabrikam, Inc., fiktivní společnost, spravuje loďstvo pro pomocí dronů letadla. 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-end systém přiřadí pomocí dronů a upozorní uživatele na odhadovanou dobu doručení. I když probíhá doručování, zákazník může sledovat umístění pomocí dronů s nepřetržitě aktualizovaným ETA.

tento tok požadavků implementuje vzory návrhu cloudu pro předplatitele Publisher, konkurenční zákazníkya směrování brány . Tok zasílání zpráv pokračuje následujícím způsobem:

Odeslal se požadavek HTTPS k naplánování pomocí dronůho vyzvednutí. Požadavky procházejí prostřednictvím Azure Application Gateway do webové aplikace pro příjem dat, která se spouští jako mikroslužba v clusteru v AKS.
webová aplikace pro přijímání zpráv vytvoří zprávu a pošle ji do fronty zpráv Service Bus.
Back-end systém přiřadí pomocí dronů a upozorní uživatele. Pracovní postup:
- využívá informace zprávy z fronty zpráv Service Bus.
- Pošle požadavek HTTPS službě Delivery Delivery, která předá data do mezipaměti Azure pro externí úložiště dat Redis.
- Odešle požadavek HTTPS mikroslužbě plánovače pomocí dronů.
- Odešle požadavek HTTPS do mikroslužby balíčku, která předá data do MongoDB externích datových úložišť.
Požadavek HTTPS GET se používá k vrácení stavu doručení. Tato žádost projde prostřednictvím Application Gateway do služby Delivery Delivery.
Mikroslužba doručování čte data z mezipaměti Azure pro Redis.

Doporučení

Implementujte tato doporučení při nasazení pokročilých architektur AKS mikroslužeb.

Kontroler příchozího přenosu Application Gateway (AGIC)

Směrování brány API je obecný vzor návrhu mikroslužeb. Brána API funguje jako reverzní proxy server, který směruje požadavky od klientů do mikroslužeb. Kubernetes příchozí a vstupní kontroler zaznamená většinu funkcí brány API pomocí:

Směrování požadavků klienta na správné back-end služby poskytuje jeden koncový bod pro klienty a umožňuje oddělit klienty od služeb.

Agregace více požadavků do jediné žádosti o omezení počtu pořadu mezi klientem a back-endu.
Snižování zátěže, jako je ukončení protokolu SSL, ověřování, omezení protokolu IP a omezení rychlosti klienta, nebo omezení pro služby back-end.

Stav clusteru AKS se převede na konfiguraci specifickou pro Application Gateway a použije se přes Azure Resource Manager.

Externí řadiče příchozího přenosu dat zjednodušují příjem provozu do AKS clusterů, zlepšují zabezpečení a výkon a ukládají prostředky. Tato architektura používá pro řízení příchozího přenosu dat řadič Azure Application Gateway AGIC ( pro příchozí přenosy dat). Použití Application Gateway ke zpracování všech přenosů eliminuje nutnost dalšího nástroje pro vyrovnávání zatížení. Vzhledem k tomu, že lusky navázaly přímé připojení k Application Gateway, je počet povinných segmentů snížený, což vede k lepšímu výkonu.

Application Gateway má integrované možnosti automatického škálování, na rozdíl od řadičů příchozího přenosu v clusteru, které se musí škálovat, pokud spotřebovávají nepotřebné množství výpočetních prostředků. Application Gateway může provést směrování vrstvy 7 a ukončení protokolu SSL a má komplexní přenos TLS (Transport Layer Security) integrovaný s integrovaným firewallem webových aplikací (WAF).

Pro možnost příchozího přenosu dat ( AGIC ) je nutné povolit síť CNI při konfiguraci clusteru AKS, protože Application Gateway je nasazena do podsítě virtuální sítě AKS. Víceklientské úlohy nebo jeden cluster, který podporuje vývojové a testovací prostředí, může vyžadovat více řadičů příchozího přenosu dat.

Zásady sítě s nulovou důvěryhodností

Zásady sítě určují, jak mohou AKS lusky komunikovat mezi sebou a s jinými koncovými body sítě. Ve výchozím nastavení jsou všechny příchozí a odchozí přenosy povoleny do a z lusků. Při navrhování, jak vaše mikroslužby vzájemně komunikují a s ostatními koncovými body, zvažte, že budete mít k základní zásadu s nulovým vztahem důvěryhodnosti , kde přístup k jakékoli službě, zařízení, aplikaci nebo úložišti dat vyžaduje explicitní konfiguraci.

Jednou z 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 lusků v rámci cílového oboru názvů. Následující příklad ukazuje ' Odepřít všechny zásady ', které by se použily pro všechny lusky umístěné v oboru názvů pro vývoj back-endu.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: backend-dev
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Jakmile je zásada omezující zásadu zastaralá, začněte definovat specifická Síťová pravidla, která umožní provoz do každého pod a z něj v mikroslužbě. V následujícím příkladu se zásady sítě aplikují na všechny položky v oboru názvů pro vývoj back-endu s popiskem, který odpovídá App.Kubernetes.IO/Component: back-end. Zásada odmítne jakýkoliv provoz, pokud není ze seznamu pod a popisek, 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

Další informace o zásadách sítě Kubernetes a dalších příkladech možných výchozích zásad najdete v tématu zásady sítě v dokumentaci k Kubernetes.

Kvóty prostředků

Kvóty prostředků představují způsob, jakým správci můžou rezervovat a omezovat prostředky v rámci vývojového týmu nebo projektu. V oboru názvů můžete nastavit kvóty prostředků a použít je k nastavení omezení pro:

Výpočetní prostředky, jako je například procesor a paměť nebo GPU.
Storage prostředky, 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 klíčů, služeb nebo úloh, které lze vytvořit.

Jakmile kumulativní součet požadavků na prostředky nebo omezení projde přiřazenou kvótou, neproběhne žádná další nasazení.

Kvóty prostředků zajišťují, aby celková sada lusků přiřazených k oboru názvů nepřekročila kvótu prostředků oboru názvů. Front-end nemůže omezují back-endové služby pro prostředky nebo naopak.

Při definování kvót prostředků musí všechny lusky vytvořené v oboru názvů poskytovat omezení nebo požadavky ve svých specifikacích pod. Pokud tyto hodnoty nezadávají, nasazení se odmítne.

Následující příklad ukazuje specifikaci pod, která nastavuje požadavky a omezení kvóty prostředků:

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

Další informace o kvótách prostředků najdete v těchto tématech:

Automatické škálování

Kubernetes podporuje automatické škálování , aby se zvýšil počet lusků přidělený nasazením nebo zvýšily uzly v clusteru, aby se zvýšily celkové dostupné výpočetní prostředky. Automatické škálování je automatickým opravou systému nezávislého zpětné vazby. I když můžete vertikálně škálovat části a uzly, automatické škálování minimalizuje pravděpodobnost služeb, které se stávají nedostatek při vysokém zatížení. Strategie automatického škálování musí brát v úvahu jak lusky, tak i uzly.

Automatické škálování clusteru

Automatické škálování clusteru (CA) škáluje počet uzlů. V důsledku omezení prostředků nelze předpokládat, že lusky nejde naplánovat; Automatické škálování clusteru zřídí další uzly. Definujete minimální počet uzlů, které udržují cluster AKS a vaše úlohy v provozu, a maximální počet uzlů pro velký provoz. CA kontroluje několik sekund pro čekání na vyřízení nebo prázdné uzly a patřičně š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 sadě šablon ARM příkladují minimální a maximální počet uzlů pro certifikační autoritu:

"minCount": 2,
"maxCount": 5,

Automatické škálování pod

Horizontální horizontální navýšení (hPa) se škáluje podle POZOROVANých procesorů, paměti nebo vlastních metrik. Chcete-li konfigurovat horizontální škálování pod, zadejte cílové metriky a minimální a maximální počet replik ve specifikaci Kubernetes Deployment pod. Zátěžové testování služeb pro určení těchto čísel.

CA a HPA dobře spolupracují, takže v clusteru AKS povolte možnosti automatického škálování. 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 vyhledá skutečné spotřebované prostředky nebo jiné metriky ze spuštěných lusků, ale zřídí uzly pro lusky, které ještě nejsou naplánované. Proto certifikační autorita vyhledá požadované prostředky, jak je uvedeno v poli specifikace pod. K vyladění těchto hodnot použijte zátěžové testování.

Sondy stavu

Kubernetes Load vyrovnává provoz do lusků, které odpovídají selektor popisku pro službu. Pouze lusky, které byly úspěšně spuštěny a jsou v pořádku příjem provozu. Pokud dojde k selhání kontejneru, Kubernetes odstraní pod a naplánuje nahrazení.

V Kubernetes může být pod vystavení dvou typů sondy stavu:

Sonda živého měření oznamuje, zda byl po úspěšném spuštění a v pořádku.
Test připravenosti oznamuje Kubernetes, zda je pod připraveným přijímat požadavky.

Provozní sondy zpracovávají lusky, které jsou pořád spuštěné, ale nejsou v pořádku a měly by se recyklovat. Například Pokud kontejner obsluhující požadavky HTTP přestane reagovat, kontejner selže, ale zastaví obsluhu požadavků. Test živého zpracování HTTP přestane reagovat, což informuje Kubernetes o restartování pod.

V některých případech nemusí být na zařízení připraven příjem provozu, a to i v případě, že se po úspěšném spuštění pod ním. Například aplikace spuštěná v kontejneru může provádět inicializační úlohy. Test připravenosti indikuje, zda je v poli připraven příjem provozu.

Mikroslužby by měly vystavovat koncové body v kódu, které usnadňují sondy stavu, s prodlevou a časovým limitem upravenými konkrétně pro kontroly, které provádějí. Klíče vzorců hPa jsou téměř výhradně v připravené fázi na pod, takže je důležité, aby sondy stavu existovaly a byly přesné.

Sledování

V aplikaci mikroslužeb je monitorování výkonu aplikací (APM) velmi důležité pro detekci anomálií, diagnostikování problémů a rychlé porozumění závislostem mezi službami. Application Insights, která je součástí Azure Monitor, poskytuje monitorování APM pro živé aplikace napsané v rozhraní .net Core, Node.js, Java a mnoha dalších jazycích aplikací.

Application Insights:

Protokoluje požadavky HTTP včetně latence a kódu výsledku.
Povolí distribuované trasování ve výchozím nastavení.
Zahrnuje ID operace v trasováních, takže můžete vyhledat všechna trasování pro určitou operaci.
Často obsahuje další kontextové informace v trasováních.

Do telemetrie dát Services s Kubernetes World Integrujte Azure Monitor telemetrie s AKS, abyste mohli shromažďovat metriky z řadičů, uzlů a kontejnerů, a taky protokolů kontejnerů a uzlů. pokud používáte rozhraní .net, Application Insights pro knihovnu Kubernetes vylepšuje Application Insights telemetrie s použitím informací o obrázku, kontejneru, node, pod, popiskech a sadě replik.

následující diagram znázorňuje příklad mapy závislostí aplikace, kterou Application Insights generuje pro trasování telemetrie AKS mikroslužeb:

příklad mapy závislostí Application Insights pro AKS aplikaci mikroslužeb.

Další informace o možnostech instrumentace běžných jazyků pro integraci Application Insights najdete v tématu monitorování aplikací pro Kubernetes.

Aspekty zabezpečení

Při plánování škálovatelnosti Vezměte v úvahu následující body.

Nekombinujte automatické škálování a imperativní nebo deklarativní správu počtu replik. Uživatelé a automatické škálování při pokusu o změnu počtu replik můžou způsobit neočekávané chování. Když je povolený HPA, snižte počet replik na minimální číslo, které chcete nasadit.
Vedlejším účinkem z vedlejšího měřítka je, že je možné často vytvořit nebo vyřadit v případě, že dojde k horizontálnímu navýšení kapacity a škálování v událostech. Chcete-li tyto důsledky zmírnit:
- Využijte sondy připravenosti, abyste Kubernetesi, že nový pod je připravený přijmout provoz.
- Využijte rozpočty přerušení v rámci, abyste omezili počet lusků, které je možné ze služby v daný okamžik vyřadit.
Po vytvoření clusteru nemůžete změnit velikost virtuálního počítače, takže při vytváření clusteru vyberte vhodnou velikost virtuálního počítače pro uzly agenta.
Více tenantů nebo jiné pokročilé úlohy mohou mít požadavky na izolaci fondu uzlů, které vyžadují více a pravděpodobně menší podsítě. Další informace o vytváření fondů uzlů s jedinečnými podsítěmi, které jsou aktuálně ve verzi Public Preview, najdete v tématu Přidání fondu uzlů s jedinečnou podsítí (Preview). Organizace mají různé standardy pro implementace na střed a paprsky. Nezapomeňte postupovat podle pokynů pro organizaci.

Aspekty správy

Při plánování možností správy Vezměte v úvahu následující body.

Spravujte Clusterovou infrastrukturu AKS prostřednictvím kanálu automatizovaného nasazení. referenční implementace pro tuto architekturu poskytuje pracovní postup akcí GitHub , 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 služby Azure AD. Samostatné nasazení infrastruktury a zatížení vám umožní řešit jedinečný životní cyklus a provozní obavy.
Vezměte svůj pracovní postup jako mechanismus pro nasazení do jiné oblasti, pokud dojde k místnímu selhání. Sestavte kanál, abyste mohli nasadit nový cluster v nové oblasti s úpravami parametrů a vstupu.

Důležité informace o zabezpečení

Při plánování zabezpečení Vezměte v úvahu následující body.

AKS se sám ověřuje pomocí spravované identity uložené v Azure AD nebo instančního objektu služby Azure AD spolu s tajným klíčem klienta. Použití identity pod je vhodnější, protože nevyžaduje tajný klíč klienta.
Se spravovanými identitami může spouštěcí proces rychle získat Azure Resource Manager tokeny OAuth 2,0; není nutné používat hesla ani připojovací řetězce. v AKS můžete přiřadit identity k jednotlivým luskům pomocí Azure Active Directory (Azure AD) pod identitou.
U každé služby v aplikaci mikroslužeb by se měla přiřadit jedinečná identita pod, aby se usnadnilo nejméně privilegované přiřazení RBAC. Měli byste přiřazovat identity jenom službám, které je vyžadují.
V případech, kdy komponenta aplikace vyžaduje přístup k rozhraní Kubernetes API, se ujistěte, že jsou aplikace v obou aplikacích nakonfigurované pro použití účtu služby s vhodně vymezeným přístupem k rozhraní API. Další informace o konfiguraci a správě účtu služeb Kubernetes Services najdete v tématu Správa účtů služby Kubernetes.
Ne všechny služby Azure podporují ověřování roviny dat pomocí Azure AD. K ukládání přihlašovacích údajů nebo tajných klíčů aplikací pro tyto služby, pro služby třetích stran nebo pro klíče rozhraní API použijte Azure Key Vault. Key Vault poskytuje centralizovanou správu, řízení přístupu, šifrování v klidovém umístění 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ů z Key Vault jako svazek. V poli pak může Key Vault tajných kódů číst jako běžný svazek. Další informace najdete v tématu tajné klíče-Store-CSI-ovladač-poskytovatel – Azure na GitHub.

Ceny

část s náklady v Microsoft Azure Well-Architected Framework popisuje požadavky na náklady. Pomocí cenové kalkulačky Azure můžete odhadnout náklady na konkrétní scénář.
K nasazení, správě a provozu clusteru Kubernetes AKS nejsou spojené žádné náklady. Platíte jenom za instance virtuálních počítače, ú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, podívejte se na kalkulačku služby Container Services.