Základní architektura pro cluster Azure Kubernetes Service (AKS)

Azure Active Directory
Application Gateway
Bastion
Container Registry
Brána firewall
Key Vault
Kubernetes Service
Load Balancer
Monitor
Zásady
Private Link
Řízení přístupu na základě role v Azure

V této referenční architektuře vytvoříme základní infrastrukturu, která nasadí cluster Azure Kubernetes Service (AKS). Tento článek obsahuje doporučení pro sítě, zabezpečení, identitu, správu a monitorování clusteru založeného na podnikových požadavcích organizace.

Logo GitHubu : implementace této architektury je dostupná na GitHubu: implementace referenčních odkazů zabezpečení Azure Kubernetes Service (AKS). Můžete ho použít jako výchozí bod a nakonfigurovat ho podle vašich potřeb.

Poznámka

Tato referenční architektura vyžaduje znalosti Kubernetes a jejích konceptů. Pokud potřebujete aktualizační program, přečtěte si část související články týkající se prostředků.

Síťová topologie

Tato architektura používá síťovou topologii hvězdicové architektury. Rozbočovače a paprsky se nasazují v samostatných virtuálních sítích připojených prostřednictvím partnerského vztahu. Mezi výhody této topologie patří:

  • Oddělená správa. Umožňuje použití zásad správného řízení a řízení poloměru vysokého využití. Také podporuje koncept cílové zóny se oddělením povinností.

  • Minimalizuje přímou expozici prostředků Azure veřejnému Internetu.

  • Organizace často pracují s místními topologiemi hvězdicové topologie. Síťové topologie centra s paprsky je možné v budoucnu rozšířit a zajistit izolaci úloh.

  • Všechny webové aplikace by měly vyžadovat službu Firewall webových aplikací (WAF), která vám umožní řídit toky přenosů HTTP.

  • Přirozená volba pro úlohy, které mají více předplatných.

  • Díky tomu je architektura rozšiřitelná. Pro přizpůsobení nových funkcí nebo úloh je možné přidat nové paprsky namísto přenavrhování síťové topologie.

  • Některé prostředky, jako je brána firewall a DNS, se dají sdílet mezi sítěmi.

Hvězdicová síťová topologie

Rozbočovač

Rozbočovačová virtuální síť je centrálním bodem připojení a pozorování. V síti jsou nasazené tři podsítě.

Podsíť pro hostování Azure Firewall

Azure firewall je brána firewall jako služba. Instance brány firewall zabezpečuje odchozí síťový provoz. Bez této vrstvy zabezpečení může tok komunikovat se škodlivou službou třetí strany, která by mohla exfiltrovat citlivá firemní data.

Podsíť pro hostování brány

Tato podsíť je zástupný symbol pro bránu VPN nebo ExpressRoute. Brána poskytuje připojení mezi směrovači v místní síti a virtuální sítí.

Podsíť pro hostování Azure bastionu

Tato podsíť je zástupný symbol pro Azure bastionu. Bastionu můžete použít k zabezpečenému přístupu k prostředkům Azure bez vystavení prostředků na internetu. Tato podsíť se používá jenom pro správu a provoz.

Paprsku

Koncová virtuální síť bude obsahovat cluster AKS a další související prostředky. Paprskový uzel má tři podsítě:

Podsíť pro hostování Azure Application Gateway

Azure Application Gateway je nástroj pro vyrovnávání zatížení webového provozu, který pracuje ve vrstvě 7. Implementace reference používá SKU Application Gateway v2, které umožňuje Firewall webových aplikací (WAF). WAF zabezpečuje příchozí provoz z běžných útoků na webový provoz. Instance má veřejnou konfiguraci IP adresy front-endu, která přijímá požadavky uživatele. Application Gateway v rámci návrhu vyžaduje vyhrazenou podsíť.

Podsíť pro hostování prostředků příchozího přenosu dat

Pro směrování a distribuci provozu je Traefik adaptér příchozího přenosu dat, který bude plnit Kubernetes prostředky příchozího přenosu dat. V této podsíti existují interní nástroje pro vyrovnávání zatížení Azure.

Podsíť pro hostování uzlů clusteru

AKS udržuje dvě samostatné skupiny uzlů (nebo fondy uzlů). Fond uzlů systému je hostitelem lusků, které spouštějí základní Clusterové služby. Fond uzlů uživatele spustí úlohu contoso a řadič příchozího přenosu dat, aby se usnadnila příchozí komunikace s úlohou. Zatížení je jednoduchá aplikace v ASP.NET.

Další informace najdete v centru síťových topologií s paprsky v Azure.

Plánování IP adres

Topologie sítě clusteru AKS

Adresní prostor virtuální sítě by měl být dostatečně velký na to, aby obsahoval všechny podsítě. Účet pro všechny entity, které budou přijímat provoz. IP adresy těchto entit budou přiděleny z adresního prostoru podsítě. Vezměte v úvahu tyto body.

  • Upgrade

    AKS pravidelně aktualizuje uzly, aby se zajistilo, že základní virtuální počítače jsou aktuální pro funkce zabezpečení a další systémové opravy. Během procesu upgradu AKS vytvoří uzel, který dočasně hostí lusky, ale uzel upgradu je uzavřené a vyprázdněný. K tomuto dočasnému uzlu je přiřazena IP adresa z podsítě clusteru.

    V případě lusků budete možná potřebovat další adresy v závislosti na vaší strategii. Pro průběžné aktualizace budete potřebovat adresy pro dočasné lusky, které úlohu spouštějí, zatímco se aktualizují skutečné lusky. Pokud použijete strategii nahrazení, odeberou se z nich a nové vytvoří se. Adresy přidružené ke starým luskům se pak znovu použijí.

  • Škálovatelnost

    Vezměte v úvahu počet uzlů všech systémových a uživatelských uzlů a jejich maximální omezení škálovatelnosti. Předpokládejme, že chcete horizontální navýšení kapacity od 400%. Počet adres pro všechny tyto uzly s možností horizontálního rozšíření bude potřeba čtyřikrát.

    V této architektuře se dá každý pod kontaktem kontaktovat přímo. Každý z nich tedy potřebuje jednotlivou adresu. Pro výpočet adresy bude mít vliv na škálovatelnost pod. Toto rozhodnutí bude záviset na vaší volbě o počtu lusků, které chcete zvětšit.

  • Adresy privátních odkazů Azure

    Faktor v adresách, které jsou vyžadovány pro komunikaci s jinými službami Azure prostřednictvím privátního propojení. V této architektuře máme dvě adresy přiřazené k odkazům na Azure Container Registry a Key Vault.

  • Některé adresy jsou rezervované pro použití v Azure. Nedají se přiřadit.

Předchozí seznam není vyčerpávající. Pokud vaše návrh obsahuje další prostředky, které budou mít vliv na počet dostupných IP adres, přizpůsobilte tyto adresy.

Tato architektura je navržená pro jednu úlohu. U více úloh může být vhodné izolovat fondy uzlů uživatelů od sebe navzájem a z fondu uzlů systému. Tato volba může mít za následek menší velikost podsítí. Také prostředek příchozího přenosu dat může být složitější. Možná budete potřebovat více řadičů příchozího přenosu dat, které budou vyžadovat další adresy.

Kompletní sadu důležitých informací pro tuto architekturu najdete v tématu topologie sítě standardních hodnot AKS.

Informace související s plánováním IP adresy pro cluster AKS najdete v tématu plánování IP adres pro cluster.

Odkaz na Image kontejneru

Kromě úloh může cluster obsahovat několik dalších imagí, jako je například kontroler příchozího přenosu dat. Některé z těchto imagí se můžou nacházet ve veřejných registrech. Při nastavování do clusteru Vezměte v úvahu tyto body.

  • Cluster je ověřený pro vyžádání image.

  • Pokud používáte veřejnou image, zvažte jejich import do registru kontejneru, který se zarovnává s vaším objektem SLO. V opačném případě může být bitová kopie podléhat neočekávaným problémům s dostupností. Tyto problémy mohou způsobovat provozní problémy, pokud je bitová kopie k dispozici, když ji potřebujete. Tady jsou některé výhody použití registru kontejneru místo veřejného registru:

    • Můžete blokovat neoprávněný přístup k vašim obrázkům.
    • Nebudete mít veřejné závislé závislosti.
    • Přístup k protokolům pro vyžádání obsahu můžete monitorovat a sledovat tak aktivity a problémy s připojením.
    • Využijte integrované prohledávání kontejnerů a kompatibilitu imagí.

    Možnost je Azure Container Registry (ACR).

  • Vyžádat image z autorizovaných registrů. Toto omezení můžete vynutili pomocí Azure Policy. V této referenční implementaci cluster vyžádá pouze image z ACR, které jsou nasazeny jako součást architektury.

Konfigurace výpočtů pro základní cluster

V AKS se každý fond uzlů mapuje na sadu škálování virtuálního počítače. Uzly jsou virtuální počítače v jednotlivých fondech uzlů. K minimalizaci nákladů můžete použít menší velikost virtuálního počítače pro fond uzlů systému. Tato referenční implementace nasadí fond uzlů systému se třemi DS2_v2 uzly. Tato velikost postačuje pro splnění očekávaného zatížení systémových lusků. Disk s operačním systémem je 512 GB.

Pro fond uzlů uživatele je zde několik důležitých informací:

  • Vyberte větší velikosti uzlů pro sbalení maximálního počtu lusků nastavených v uzlu. Tím se minimalizuje nároky na služby spuštěné na všech uzlech, jako je monitorování a protokolování.

  • Nasaďte alespoň dva uzly. Zatížení tak bude mít model vysoké dostupnosti se dvěma replikami. Pomocí AKS můžete změnit počet uzlů bez opětovného vytvoření clusteru.

  • Skutečné velikosti uzlů pro vaše zatížení budou záviset na požadavcích určených týmem návrhu. Na základě obchodních požadavků jsme zvolili DS4_v2 pro produkční úlohy. Snížení nákladů na jednu z nich může vyřadit velikost na DS3_v2, což je minimální doporučení.

  • Při plánování kapacity pro cluster můžete předpokládat, že vaše zatížení může spotřebovávat až 80% z každého uzlu. zbývajících 20% je rezervováno pro služby AKS Services.

  • Nastavte maximální počet lusků na uzel na základě vašeho plánování kapacity. Pokud se snažíte vytvořit směrný plán kapacity, začněte s hodnotou 30. Upravte tuto hodnotu na základě požadavků na zatížení, velikost uzlu a omezení IP adresy.

Integrace Azure Active Directory pro cluster

Zabezpečení přístupu do clusteru a z něj je důležité. Vezměte v úvahu z perspektivy clusteru, když provádíte volby zabezpečení:

  • Přístup mimo Cloud. Autorizujte jenom ty externí entity, které mají povolený přístup k serveru rozhraní Kubernetes API a Azure Resource Manager.

  • Přístup k internímu prostředí. Autorizujte jenom prostředky, ke kterým má cluster povolený přístup.

Existují dva způsoby, jak spravovat přístup prostřednictvím služby Azure Active Directory (Azure AD): instanční objekty nebo spravované identity pro prostředky Azure.

Ze dvou způsobů se doporučuje používat spravované identity. S instančními objekty zodpovídáte za správu a střídání tajných kódů, a to buď ručně, nebo prostřednictvím kódu programu. Se spravovanými identitami spravuje Azure AD a provádí ověřování a včasné rotaci tajných kódů za vás.

Doporučuje se, aby se povolily spravované identity, aby cluster mohl komunikovat s externími prostředky Azure prostřednictvím Azure AD. Toto nastavení můžete povolit jenom při vytváření clusteru. I když se služba Azure AD nepoužívá okamžitě, můžete ji začlenit později.

Jako příklad pro vnitřní případ využijeme studii použití spravovaných identit, když cluster potřebuje vyžádat image z registru kontejneru. Tato akce vyžaduje, aby cluster získal přihlašovací údaje registru. Jednou z nich je ukládat tyto informace ve formě objektu Kubernetes tajných kódů a použít imagePullSecrets je k načtení tajného klíče. Tento přístup se nedoporučuje z důvodu složitosti zabezpečení. Nepotřebujete jenom předchozí znalosti tajného kódu, ale také si ho vyzrazeni prostřednictvím kanálu DevOps. Dalším důvodem je provozní režie správy rotace tajného klíče. Místo toho udělte k acrPull registru spravovanou identitu clusteru. Tento přístup řeší tyto aspekty.

V této architektuře cluster přistupuje k prostředkům Azure, které jsou zabezpečené pomocí služby Azure AD, a provádí operace, které podporují spravované identity. Přiřaďte řízení přístupu na základě role Azure (Azure RBAC) a oprávnění ke spravovaným identitám clusteru v závislosti na tom, jaké operace má cluster zamýšlí dělat. Cluster se ověří ve službě Azure AD a pak povolí nebo odepře přístup na základě rolí, ke kterým byl přiřazen. Tady jsou některé příklady z této referenční implementace, kde se ke clusteru přiřazují předdefinované role Azure:

  • Přispěvatel sítě. Schopnost clusteru řídit virtuální síť paprsků. Toto přiřazení role umožňuje, aby identita AKS systému clusterů mohla spolupracovat s vyhrazenou podsítí pro interní služby příchozího řadiče pro příchozí přenosy.

  • Monitoruje vydavatele metrik. Schopnost clusteru odesílat metriky do Azure Monitor.

  • AcrPull. Schopnost clusteru načítat image z určených kontejnerů Azure Container Registry.

Integrace Azure AD taky zjednodušuje zabezpečení pro přístup mimo Cloud. Předpokládejme, že uživatel chce používat kubectl. Jako první krok pošle příkaz, az aks get-credentials aby získal přihlašovací údaje clusteru. Azure AD ověří identitu uživatele v rolích Azure, které mají povoleno získávat přihlašovací údaje clusteru. Další informace najdete v tématu dostupná oprávnění rolí clusteru.

Přidružte Kubernetes RBAC k Azure Active Directory

Kubernetes podporuje řízení přístupu na základě role (RBAC) prostřednictvím:

  • Sada oprávnění. Definováno Role ClusterRole objektem nebo pro oprávnění na úrovni clusteru.

  • Vazby, které přiřazují uživatele a skupiny, kterým mohou provádět akce. Definováno RoleBinding CluserRoleBinding objektem nebo.

Kubernetes má některé předdefinované role, jako je například Správce clusteru, úpravy, zobrazení a tak dále. Připojte tyto role k Azure Active Directory uživatelů a skupin, aby bylo možné použít adresář Enterprise ke správě přístupu. Další informace najdete v tématu použití KUBERNETES RBAC s integrací služby Azure AD.

K dispozici je také možnost použít role Azure místo předdefinovaných rolí Kubernetes. Další informace najdete v tématu role Azure.

Integrace Azure Active Directory pro úlohu

Podobně jako u celého clusteru se spravovanými identitami Azure můžete přiřadit spravované identity na úrovni pod. Spravovaná identita podu umožňuje hostované úlohu přístup k prostředkům prostřednictvím Azure Active Directory. Úloha například ukládá soubory do Azure Storage. Když potřebuje přístup k skupině souborů, pod se vůči prostředku ověří.

V této referenční implementaci se spravované identity podů usnadní prostřednictvím aad-pod-identity.

Nasazení prostředků příchozího přenosu dat

Prostředky příchozího přenosu dat Kubernetes směrují a distribuují příchozí provoz do clusteru. Existují dvě části prostředků příchozího přenosu dat:

  • Interní nástroj pro vyrovnávání zatížení. Spravuje ho AKS. Tento nástroj pro vyrovnávání zatížení zpřístupňuje kontroler příchozího přenosu dat prostřednictvím privátní statické IP adresy. Slouží jako kontaktní bod, který přijímá příchozí toky.

    V této architektuře Azure Load Balancer používá . Nachází se mimo cluster v podsíti vyhrazené pro prostředky příchozího přenosu dat. Přijímá přenosy z Azure Application Gateway komunikace přes protokol TLS. Informace o šifrování TLS pro příchozí provoz najdete v tématu Tok příchozího přenosu dat.

  • Kontroler příchozího přenosu dat. Zvolili jsme Traefik. Běží ve fondu uzlů uživatele v clusteru. Přijímá provoz z interního nástroje pro vyrovnávání zatížení, ukončuje protokol TLS a předává ho podům úloh přes protokol HTTP.

Kontroler příchozího přenosu dat je důležitou součástí clusteru. Při konfiguraci této komponenty zvažte tyto body.

  • V rámci rozhodnutí o návrhu zvolte rozsah, ve kterém bude kontroler příchozího přenosu dat povolený. Kontroleru můžete například povolit interakci jenom s pody, na které běží konkrétní úloha.

  • Vyhněte se umístění replik na stejný uzel, aby se zatížení rozdělilo, a pokud uzel nefunguje, zajistěte kontinuitu podnikových dat. K podAntiAffinity tomuto účelu použijte .

  • Omezte pody tak, aby se naplánovali jenom ve fondu uzlů uživatele pomocí nodeSelectors . Toto nastavení izoluje pody úloh a systému.

  • Otevřete porty a protokoly, které umožňují konkrétním entitám odesílat provoz do kontroleru příchozího přenosu dat. V této architektuře Traefik přijímá provoz pouze z Azure Application Gateway.

  • Kontroler příchozího přenosu dat by měl odesílat signály, které indikují stav podů. Nakonfigurujte readinessProbe livenessProbe a nastavení, která budou v zadaném intervalu monitorovat stav podů.

  • Zvažte omezení přístupu kontroleru příchozího přenosu dat ke konkrétním prostředkům a možnost provádět určité akce. Toto omezení je možné implementovat prostřednictvím oprávnění RBAC pro Kubernetes. Například v této architektuře má Traefik udělená oprávnění ke sledování, získání a zobrazení seznamu služeb a koncových bodů pomocí pravidel v objektu ClusterRole Kubernetes.

Poznámka

Volba vhodného kontroleru příchozího přenosu dat se řídí požadavky úlohy, sada dovedností operátora a možnostmi podpory technologických možností. Nejdůležitější je schopnost splnit očekávání SLO.

Traefik je oblíbená open source možnost pro cluster Kubernetes a je v této architektuře zvolena pro ilustrativní účely. Ukazuje integraci produktů třetích stran se službami Azure. Implementace například ukazuje, jak integrovat Traefik se spravovanou identitou podu Azure AD a Azure Key Vault.

Další možností je Azure Application Gateway příchozího přenosu dat a jeho dobře integrovaný s AKS. Kromě možností kontroleru příchozího přenosu dat nabízí i další výhody. Například Application Gateway vstupní bod virtuální sítě vašeho clusteru. Může sledovat provoz vstupující do clusteru. Pokud máte aplikaci, která vyžaduje WAF, Application Gateway je dobrou volbou, protože je integrovaná s WAF. Poskytuje také příležitost k ukončení protokolu TLS.

Nastavení směrovače

Kontroler příchozích dat pomocí tras určuje, kam se má provoz odesílat. Trasy určují zdrojový port, na kterém se provoz přijímá, a informace o cílových portech a protokolech.

Tady je příklad z této architektury:

Traefik ke konfiguraci tras používá poskytovatele Kubernetes. , annotations tls a označují, entrypoints že trasy budou obsluhován přes protokol HTTPS. Určuje, middlewares že je povolený jenom provoz Azure Application Gateway podsítě. Odpovědi budou používat kódování gzip, pokud to klient přijme. Vzhledem k tomu, že Traefik ukončuje protokol TLS, komunikace s back-end službami je přes protokol HTTP.

apiVersion:networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

Zabezpečení toku sítě

Tok sítě je v tomto kontextu možné kategorizovat takto:

  • Příchozí provoz. Z klienta do úlohy spuštěné v clusteru.

  • Přenosy dat. Z podu nebo uzlu v clusteru do externí služby.

  • Provoz mezi pody. Komunikace mezi pody. Tento provoz zahrnuje komunikaci mezi kontroleru příchozího přenosu dat a úlohou. Pokud se vaše úloha skládá z několika aplikací nasazených do clusteru, spadá komunikace mezi těmito aplikacemi do této kategorie.

  • Správa provozu. Provoz, který prochází mezi klientem a serverem rozhraní Kubernetes API.

Tok provozu clusteru

Tato architektura má několik vrstev zabezpečení pro zabezpečení všech typů provozu.

Tok příchozího přenosu dat

Architektura přijímá pouze šifrované požadavky PROTOKOLU TLS od klienta. TLS verze 1.2 je minimální povolená verze s omezenou skupinou protokolů. Indikace názvu serveru (SNI) je povolené striktní. Koncové šifrování TLS se nastavuje prostřednictvím protokolu Application Gateway pomocí dvou různých certifikátů TLS, jak je znázorněno na tomto obrázku.

Ukončení protokolu TLS

  1. Klient odešle požadavek HTTPS na název domény: bicycle.contoso.com. Tento název je přidružený prostřednictvím záznamu DNS A k veřejné IP adrese Azure Application Gateway. Tento provoz je šifrovaný, aby se ujistil, že provoz mezi prohlížečem klienta a bránou není možné zkontrolovat ani změnit.

  2. Application Gateway má integrovaný Firewall webových aplikací (WAF) a vyjednává metody handshake protokolu TLS pro bicycle.contoso.com a umožňuje pouze zabezpečené šifry. Application Gateway je ukončovací bod protokolu TLS, protože se vyžaduje ke zpracování pravidel kontroly WAF a spouštění pravidel směrování, která přeposílá provoz do nakonfigurovaného back-endu. Certifikát TLS je uložený v Azure Key Vault. K přístupu se používá spravovaná identita přiřazená uživatelem integrovaná s Application Gateway. Informace o této funkci najdete v tématu Ukončení protokolu TLS s Key Vault certifikáty.

  3. Provoz se přesune z Application Gateway do back-endu, provoz se znovu zašifruje jiným certifikátem TLS (zástupný znak pro .aks-ingress.contoso.com), protože se předává internímu nástroji pro * vyrovnávání zatížení. Toto opětovné šifrování zajišťuje, že provoz, který není zabezpečený, nebude proudit do podsítě clusteru.

  4. Kontroler příchozího přenosu dat přijímá šifrovaný provoz prostřednictvím nástroje pro vyrovnávání zatížení. Kontroler je dalším ukončovacím bodem protokolu TLS pro .aks-ingress.contoso.com a předává provoz podům úloh * přes protokol HTTP. Certifikáty jsou uloženy v Azure Key Vault a připojeny ke clusteru pomocí ovladače rozhraní úložiště kontejnerů (CSI). Další informace najdete v tématu Přidání správy tajných údajů.

Celý provoz TLS můžete implementovat v každém segmentu směrování, který prochází do podu úlohy. Při rozhodování o zabezpečení provozu mezi pody nezapomeňte měřit výkon, latenci a provozní dopad. U většiny clusterů s jedním tenantem, které mají správnou řídicí rovinu RBAC a vyspělé postupy životního cyklu vývoje softwaru, stačí šifrování TLS až do kontroleru příchozího přenosu dat a ochranu pomocí Web Application Firewall (WAF). Tím se minimalizují režijní náklady na správu úloh a dopad na výkon sítě. To, kde provádíte ukončení protokolu TLS, budou diktovat vaše požadavky na úlohy a dodržování předpisů.

Tok příchozího přenosu dat

Pro řízení nulové důvěryhodnosti a možnost kontrolovat provoz prochází veškerý příchozí provoz z clusteru přes Azure Firewall. Tuto volbu můžete implementovat pomocí tras definovaných uživatelem. Dalším segmentem směrování trasy je privátní IP adresa Azure Firewall. Tady se Azure Firewall, jestli se má příchozí přenos blokovat nebo povolit. Toto rozhodnutí je založené na konkrétních pravidlech definovaných v Azure Firewall nebo integrovaných pravidlech detekce hrozeb.

Poznámka

Pokud jako veřejný bod pro příchozí a příchozí přenosy dat používáte veřejný nástroj pro vyrovnávání zatížení prostřednictvím Azure Firewall tras definovaných definovanými službou , může se zobrazit situace asymetrického směrování. Tato architektura používá interní nástroje pro vyrovnávání zatížení ve vyhrazené podsíti příchozího přenosu dat za Application Gateway. Tato volba návrhu nejen vylepšuje zabezpečení, ale také eliminuje problémy s asymetrickým směrováním. Alternativně můžete směrovat příchozí provoz přes váš Azure Firewall před nebo po Application Gateway. Tento přístup není ve většině situací nutný ani doporučený. Další informace o asymetrickém směrování najdete v tématu Integrace Azure Firewall s Azure Standard Load Balancer.

Výjimkou řízení nulové důvěryhodnosti je, když cluster potřebuje komunikovat s jinými prostředky Azure. Cluster například musí stáhnout aktualizovanou image z registru kontejneru. Doporučeným přístupem je použití Azure Private Link. Výhodou je, že konkrétní podsítě se dostanou přímo do služby. Provoz mezi clusterem a službou navíc není vystavený veřejnému internetu. Nevýhodou je, že Private Link místo použití cílové služby přes svůj veřejný koncový bod potřebuje další konfiguraci. Ne všechny služby Azure nebo skladové prostředky (SKU) také Private Link. V takových případech zvažte povolení přístupu ke službě koncovému bodu služby v podsíti.

Pokud Private Link koncové body služby nebo koncové body služby, můžete se prostřednictvím jejich veřejných koncových bodů dostat k dalším službám a řídit přístup prostřednictvím pravidel Azure Firewall a brány firewall integrované v cílové službě. Vzhledem k tomu, že tento provoz bude procházet statickou IP adresou brány firewall, můžete tuto adresu přidat do seznamu povolených IP adres služby. Nevýhodou je, že Azure Firewall pravidla, která budou mít jistotu, že je povolený jenom provoz z konkrétní podsítě.

Provoz mezi pody

Ve výchozím nastavení může pod přijímat provoz z jakéhokoli jiného podu v clusteru. Kubernetes NetworkPolicy se používá k omezení síťového provozu mezi pody. Zásady řešte uvážlivě, jinak se může zobrazit situace, kdy je kritický síťový tok blokovaný. Podle potřeby povolte pouze konkrétní komunikační cesty, jako je například provoz mezi kontroleru příchozího přenosu dat a úlohou. Další informace najdete v tématu Zásady sítě.

Při zřizování clusteru povolte zásady sítě, protože ho nemůžete přidat později. Pro technologie, které implementují , existuje několik NetworkPolicy možností. Doporučuje se Služba Azure Network Policy, která Azure Container Networking Interface (CNI), viz poznámka níže. Mezi další možnosti patří Zásady sítě Calico, dobře známá možnost open source. Pokud potřebujete spravovat zásady sítě v celém clusteru, zvažte použití služby Calico. Rozhraní Calico se nevztahuje na standardní podpora Azure.

Informace najdete v tématu Rozdíly mezi zásadami Azure Network Policy a Calico a jejich možnostmi.

Poznámka

AKS podporuje tyto síťové modely: kubenet a Azure Container Networking Interface (CNI). CNI je pokročilejší z těchto dvou modelů a vyžaduje se pro povolení Azure Network Policy. V tomto modelu získá každý pod IP adresu z adresního prostoru podsítě. Prostředky v rámci stejné sítě (nebo prostředků v partnerském vztahu) mají k podům přímý přístup prostřednictvím jejich IP adresy. Pro směrování tohoto provozu není naT potřeba.Cni je tedy výkonná, protože neexistují žádné další síťové překryvy. Nabízí také lepší řízení zabezpečení, protože umožňuje používat Azure Network Policy. Obecně se doporučuje CNI. CNI nabízí podrobnou kontrolu týmů a prostředků, které řídí. CNI také umožňuje více škálovaných podů než kubenet. Tuto volbu pečlivě zvažte, jinak bude potřeba cluster znovu nasadit. Informace o modelech najdete v tématu Porovnání modelů sítě.

Provoz správy

V rámci spuštění clusteru bude server rozhraní Kubernetes API přijímat provoz z prostředků, které chtějí provádět operace správy v clusteru, jako jsou požadavky na vytvoření prostředků nebo škálování clusteru. Mezi příklady těchto prostředků patří fond agentů sestavení v kanálu DevOps, podsíť Bastion a samotné fondy uzlů. Místo přijetí tohoto provozu správy ze všech IP adres použijte funkci Autorizované rozsahy IP adres služby AKS, která povolí provoz pouze z autorizovaných rozsahů IP adres na server rozhraní API.

Další informace najdete v tématu Definování rozsahů IP adres autorizovaných serverem rozhraní API.

Přidání správy tajných klíče

Tajné kódy můžete ukládat do spravovaného úložiště klíčů, jako je Azure Key Vault. Výhodou je, že spravované úložiště zajišťuje rotaci tajných kódů, nabízí silné šifrování, poskytuje protokol auditu přístupu a udržuje základní tajné kódy mimo kanál nasazení.

Azure Key Vault je dobře integrovaný s dalšími službami Azure. Pro přístup k tajným kódům použijte integrovanou funkci těchto služeb. Příklad toho, jak Azure Application Gateway k certifikátům TLS pro tok příchozího přenosu dat, najdete v části Tok příchozího přenosu dat.

Přístup k tajným kódům clusteru

Abyste podu umožnili přístup k tajným kódům z konkrétního úložiště, budete muset použít spravované identity podů.

K usnadnění procesu načítání použijte ovladač CSI úložiště tajných kódů. Pokud pod potřebuje tajný kód, ovladač se připojí k zadanému úložiště, načte tajný kód na svazku a připojí tento svazek v clusteru. Pod pak může získat tajný kód ze systému souborů svazku.

Ovladač CSI má mnoho poskytovatelů, kteří podporují různá spravovaná úložiště. V této implementaci jsme zvolili ovladač CSI pro Azure Key Vault úložiště tajných kódů, který načte certifikát TLS z Azure Key Vault a načte ho do podu, na které běží kontroler příchozího přenosu dat. Provádí se při vytváření podu a svazek ukládá veřejné i privátní klíče.

Úložiště úloh

Úloha použitá v této architektuře je bez stavu. Pokud potřebujete uložit stav, doporučuje se zachovat ho mimo cluster. Pokyny ke stavu úloh jsou nad rámec tohoto článku.

Další informace o možnostech úložiště najdete v tématu Možnosti úložiště pro aplikace v Azure Kubernetes Service (AKS).

Správa zásad

Efektivním způsobem správy clusteru AKS je vynucování zásad správného řízení prostřednictvím zásad. Kubernetes implementuje zásady prostřednictvím OPA Gatekeeper. V případě AKS se zásady doručí prostřednictvím Azure Policy. Každá zásada se použije na všechny clustery ve svém oboru. Azure Policy vynucení nakonec zpracovává OPA Gatekeeper v clusteru a zaprotokoluje se všechny kontroly zásad. Změny zásad se v clusteru neprojeví okamžitě. Očekávejte, že se zobrazí některá zpoždění.

Při nastavování zásad je použijte na základě požadavků úlohy. Zvažte tyto faktory:

  • Chcete nastavit kolekci zásad (nazývaných iniciativy) nebo zvolit jednotlivé zásady? Azure Policy nabízí dvě integrované iniciativy: základní a omezené. Každá iniciativa je kolekce předdefinových zásad použitelných pro cluster AKS. Doporučujeme vybrat iniciativu a vybrat další zásady pro cluster a prostředky (ACR, Application Gateway, Key Vault a další), které s clusterem komunikují, podle požadavků vaší organizace.

  • Chcete akci auditovat nebo odepřít? V režimu auditování je akce povolená, ale je označená jako nekompatibilní. Mít procesy pro pravidelnou kontrolu nevyhovujících stavů a provedení potřebných akcí. V režimu Odepřít se akce zablokuje, protože porušuje zásady. Při volbě tohoto režimu buďte opatrní, protože může být příliš omezující, aby úloha fungovala.

  • Máte v úlohách oblasti, které by neměly být z návrhu kompatibilní? Azure Policy možnost určit obory názvů Kubernetes, které jsou vyloučené z vynucování zásad. Doporučuje se používat zásady v režimu auditování, abyste o těchto instancích měli povědomí.

  • Máte požadavky, na které předdefinované zásady nevztahují? V těchto výjimečných případech vytvořte vlastní definici Azure Policy, která použije vaše vlastní zásady OPA Gatekeeper. Nepoužívejte zásady přímo na cluster.

  • Máte požadavky na celou organizaci? Pokud ano, přidejte tyto zásady na úrovni skupiny pro správu. Cluster by měl také přiřazovat vlastní zásady specifické pro úlohy, i když má organizace obecné zásady.

  • Zásady Azure jsou přiřazeny ke konkrétním rozsahům. Ujistěte se, že jsou v předprodukačním prostředí ověřené také produkční zásady. V opačném případě může při nasazování do produkčního prostředí dojít k neočekávaným dalším omezením, která nebyla v předprodukce ována.

V této referenční implementaci Azure Policy povolená při vytvoření clusteru AKS a přiřazení omezující iniciativy v režimu auditování, aby bylo možné získat přehled o nedodržování předpisů.

Implementace také nastavuje další zásady, které nejsou součástí žádných předdefinových iniciativ. Tyto zásady se nastaví v režimu Odepřít. Existují například zásady, které se ujistily, že se image načtou jenom z nasazené služby ACR. Zvažte vytvoření vlastních iniciativ. Zkombinujte zásady, které platí pro vaše zatížení, do jediného přiřazení.

Chcete-li sledovat, jak Azure Policy pracuje v rámci clusteru, můžete získat přístup k protokolům pod v části gatekeeper-system obor názvů a také k protokolům pro azure-policy a azure-policy-webhook lusky v kube-system oboru názvů.

Škálovatelnost uzlů a uzlů pod

Díky rostoucí poptávce se Kubernetes může škálovat načtením dalších lusků do existujících uzlů, a to prostřednictvím automatického škálování pod automatickým škálováním (HPA). Pokud již nemůžete naplánovat další lusky, je nutné zvýšit počet uzlů prostřednictvím automatického škálování clusteru AKS. Kompletní řešení škálování musí mít způsob, jak škálovat repliky pod a počet uzlů v clusteru.

Existují dva přístupy: automatické škálování nebo ruční škálování.

Ruční nebo programovací způsob vyžaduje, abyste mohli monitorovat a nastavovat výstrahy na využití procesoru nebo vlastní metriky. V případě škálování pod může operátor aplikace zvýšit nebo snížit počet replik pod, a to úpravou ReplicaSet rozhraní Kubernetes API. V případě škálování clusteru je jedním ze způsobů, jak obdržet upozornění, když se Kubernetes Scheduler nezdařil. Dalším způsobem je sledovat čekání na lusky v průběhu času. Počet uzlů můžete upravit prostřednictvím rozhraní příkazového řádku Azure nebo portálu.

Automatické škálování je přístup, protože některé z těchto ručních mechanismů jsou integrovány do automatického škálování.

Jako obecný přístup začněte testováním výkonu s minimálním počtem lusků a uzlů. Tyto hodnoty použijte k určení očekávaného směrného plánu. Pak použijte kombinaci metrik výkonu a ruční škálování, abyste našli kritické body a pochopili reakci aplikace na škálování. Nakonec tato data použijte k nastavení parametrů pro automatické škálování. Informace o scénáři optimalizace výkonu pomocí AKS najdete v tématu scénář ladění výkonu: distribuované obchodní transakce.

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

Hodnota vodorovně pod AutoScale (hPa) je prostředek Kubernetes, který škáluje počet lusků.

V prostředku HPA se doporučuje nastavit minimální a maximální počet replik. Tyto hodnoty omezí meze automatického škálování.

HPA se může škálovat na základě využití CPU, využití paměti a vlastních metrik. K dispozici je pouze využití CPU. Definice HorizontalPodAutoscaler Určuje cílové hodnoty pro tyto metriky. Specifikace například nastaví cílové využití procesoru. V době, kdy jsou lusky spuštěné, používá řadič HPA rozhraní API metrik Kubernetes ke kontrole využití CPU v poli. Porovnává tuto hodnotu s cílovým využitím a vypočte poměr. Pak použije poměr k určení, zda jsou lusky přetížené nebo nevytížené. Spoléhá na to, že Plánovač Kubernetes přiřadí nové lusky k uzlům nebo odebere lusky z uzlů.

Může dojít k konfliktu časování, kde (HPA) kontroluje před dokončením operace škálování. Výsledkem může být nesprávný výpočet poměru. Podrobnosti najdete v tématu Cooldownování událostí škálování.

Pokud je vaše zatížení založené na událostech, oblíbená možnost Open Source je keda. Zvažte KEDA, jestli je vaše zatížení řízené zdrojem událostí, jako je například fronta zpráv, nikoli PROCESORem nebo pamětí. KEDA podporuje mnoho zdrojů událostí (nebo škálovatelností). Seznam podporovaných KEDAch rozšíření najdete tady , včetně nástroje pro horizontální navýšení kapacity Azure monitor. pohodlný způsob, jak škálovat KEDA úlohy na základě metrik Azure Monitor.

Automatické škálování clusteru

Automatické škálování clusteru je součást AKS doplňku, která škáluje počet uzlů ve fondu uzlů. Měl by se přidat během zřizování clusteru. Pro každý fond uživatelských uzlů potřebujete samostatný cluster pro automatické škálování.

Automatické škálování clusteru je aktivované plánovačem Kubernetes. Pokud se plánovači Kubernetes nepovede naplánovat pod z důvodu omezení prostředků, automatické škálování automaticky zřídí nový uzel ve fondu uzlů. Funkce automatického škálování clusteru naopak kontroluje nevyužitou kapacitu uzlů. Pokud uzel není spuštěn s očekávanou kapacitou, lusky se přesunou do jiného uzlu a nepoužitý uzel se odebere.

Pokud povolíte automatické škálování, nastavte maximální a minimální počet uzlů. Doporučené hodnoty závisí na očekávaném výkonu zatížení a na tom, kolik chcete, aby se cluster rozrůst, a na důsledky nákladů. Minimální počet je rezervovaná kapacita pro daný fond uzlů. V této referenční implementaci je minimální hodnota nastavená na 2 z důvodu jednoduchého charakteru zatížení.

V případě fondu uzlů systému se doporučuje minimální hodnota 3.

Rozhodnutí o provozní kontinuitě

Pro zachování kontinuity podnikových prostředí definujte smlouva SLA pro infrastrukturu a vaši aplikaci. Informace o výpočtu za měsíc v době provozu najdete v tématu SLA pro službu Azure Kubernetes Service (AKS).

Uzly clusteru

Aby se dosáhlo minimální úrovně dostupnosti pro úlohy, je potřeba víc uzlů v rámci fondu uzlů. Pokud dojde k výpadku uzlu, jiný uzel ve fondu uzlů ve stejném clusteru může pokračovat v používání aplikace. Pro zajištění spolehlivosti jsou pro fond uzlů systému doporučeny tři uzly. Pro fond uzlů uživatele začněte bez méně než dvou uzlů. Pokud potřebujete vyšší dostupnost, zřiďte více uzlů.

Izolujte svou aplikaci od systémových služeb tím, že ji umístíte do samostatného fondu uzlů. Tímto způsobem se Kubernetes služby spouštějí na vyhrazených uzlech a nesoutěží se s úlohou. Pro identifikaci fondu uzlů k naplánování zatížení doporučujeme použít značky, popisky a značky chuti.

Pravidelným udržováním clusteru, jako jsou například včasné aktualizace, je zásadní pro spolehlivost. Doporučuje se také monitorovat stav lusků přes sondy.

Dostupnost pod

Zkontrolujte prostředky pod. Důrazně doporučujeme, aby nasazení určovala pod požadavky na prostředky. Plánovač pak může následně naplánovat pod. Pokud nemůžete naplánovat lusky, spolehlivost se významně nepoužívá.

Nastavte rozpočty přerušení pod. Toto nastavení určuje, kolik replik v nasazení může pocházet během události aktualizace nebo upgradu. Další informace naleznete v části pod rozpočty přerušení.

Nakonfigurujte více replik v nasazení, aby se zpracovávala přerušení, jako je například selhání hardwaru. U plánovaných událostí, jako jsou například aktualizace a upgrady, může rozpočet přerušení zajistit, aby požadovaný počet replik pod existoval pro zpracování očekávaného zatížení aplikace.

Nastavte kvóty prostředků na obory názvů úloh. Kvóta prostředků u oboru názvů zajistí, že požadavky a omezení jsou v nasazení správně nastaveny. Další informace najdete v tématu vymáhání kvót prostředků.

Poznámka

Nastavení kvót prostředků na úrovni clusteru může způsobit problém při nasazování úloh jiných výrobců, které nemají správné požadavky a omezení.

Nastavte počet požadavků a omezení pod. Nastavení těchto omezení umožňuje Kubernetes efektivně přidělovat prostředky procesoru, nebo paměti do lusků a mít vyšší hustotu kontejnerů na uzlu. Omezení můžou taky zvýšit spolehlivost a snížit náklady kvůli lepšímu využití hardwaru.

Pro odhad limitů, testování a stanovení směrného plánu. Začněte se stejnými hodnotami pro požadavky a omezení. Potom tyto hodnoty postupně vylaďte, dokud neurčíte prahovou hodnotu, která může způsobit nestabilitu clusteru.

Tato omezení lze zadat v manifestech nasazení. Další informace najdete v tématu nastavení požadavků a omezení.

Zóny dostupnosti a podpora více oblastí

Pokud vaše smlouva SLA vyžaduje vyšší dobu provozu, chraňte před ztrátou v zóně. Zóny dostupnosti můžete použít, pokud je tato oblast podporuje. Komponenty roviny ovládacího prvku i uzly v fondech uzlů je pak možné rozložit mezi zónami. Pokud není celá zóna k dispozici, uzel v jiné zóně v oblasti je stále k dispozici. Každý fond uzlů se mapuje na samostatnou sadu škálování virtuálního počítače, která spravuje instance uzlů a škálovatelnost. Operace a konfigurace škálování sady se spravují pomocí služby AKS. Tady jsou některé předpoklady při povolování více zón:

  • Celá infrastruktura. Vyberte oblast, která podporuje zóny dostupnosti. Další informace najdete v tématu omezení a dostupnost oblasti. Pokud si chcete koupit smlouvu SLA pro dobu provozu, vyberte oblast, která tuto možnost podporuje. Smlouva SLA pro dobu provozu je při použití zón dostupnosti vyšší.

  • Cluster. Zóny dostupnosti je možné nastavit pouze při vytvoření fondu uzlů a nelze je později změnit. Velikosti uzlů by měly být podporované ve všech zónách, aby byla možná očekávaná distribuce. Základní škálovací sada virtuálních počítačů poskytuje stejnou hardwarovou konfiguraci napříč zónami.

    Podpora vícezón se vztahuje nejen na fondy uzlů, ale také na řídicí rovinu. Řídicí rovina AKS bude zahrnovat požadované zóny, jako jsou fondy uzlů. Pokud ve svém clusteru podporu zón nevyu ídáte, nezaručuje se, že komponenty řídicí roviny budou rozloženy mezi zóny dostupnosti.

  • Závislé prostředky. Pro úplné zónové výhody musí všechny závislosti služeb podporovat také zóny. Pokud závislá služba zóny nepodporuje, je možné, že selhání zóny způsobí selhání této služby.

Například spravovaný disk je k dispozici v zóně, ve které je zřízen. V případě selhání se uzel může přesunout do jiné zóny, ale spravovaný disk se s uzlem do této zóny nepřesouhne.

V této architektuře se AKS pro zjednodušení nasazovat do jedné oblasti s fondy uzlů, které jsou součástí zón dostupnosti 1, 2 a 3. Další prostředky infrastruktury, například Azure Firewall a Application Gateway, se nasadí do stejné oblasti také s podporou vícezónových řešení. Geografická replikace je povolená pro Azure Container Registry.

Několik oblastí

Povolení zón dostupnosti nebude stačit, pokud dojde k vypnutí celé oblasti. Pokud chcete mít vyšší dostupnost, spusťte několik clusterů AKS v různých oblastech.

  • Použijte spárované oblasti. Zvažte použití kanálu CI/CD, který je nakonfigurovaný tak, aby se k zotavení po selhání oblasti používá spárovaná oblast. Výhodou použití spárovaných oblastí je spolehlivost během aktualizací. Azure zajišťuje, aby se v jednom okamžiku aktualizovala pouze jedna oblast v páru. Nasazení ve více oblastech mohou usnadnit některé nástroje DevOps, jako je flux.

  • Pokud prostředek Azure podporuje geografickou redundanci, zadejte umístění, kde bude mít redundantní služba svou sekundární. Například povolení geografické replikace pro Azure Container Registry automaticky replikuje image do vybraných oblastí Azure a bude poskytovat trvalý přístup k imagům i v případě, že v oblasti došlo k výpadku.

  • Zvolte směrovač přenosů, který může distribuovat provoz mezi zóny nebo oblasti podle vašich požadavků. Tato architektura nasazovat Azure Load Balancer protože může distribuovat provoz mimo web napříč zónami. Pokud potřebujete distribuovat provoz mezi oblastmi, Azure Front Door zvážit. Další důležité informace najdete v tématu Volba nástroje pro vyrovnávání zatížení.

Zotavení po havárii

V případě selhání v primární oblasti byste měli být schopni rychle vytvořit novou instanci v jiné oblasti. Tady je několik doporučení:

  • Použijte spárované oblasti.

  • Ne stavové úlohy je možné efektivně replikovat. Pokud potřebujete uložit stav v clusteru (nedoporučuje se), nezapomeňte data často zálohovat ve spárované oblasti.

  • Integrujte strategii obnovení, například replikaci do jiné oblasti, jako součást kanálu DevOps, aby splňovala vaše cíle úrovně služeb (SLO).

  • Při zřizování jednotlivých služeb Azure zvolte funkce, které podporují zotavení po havárii. Například v této architektuře je Azure Container Registry pro geografickou replikaci. Pokud dojde k výpadku oblasti, můžete i nadále natahovat image z replikované oblasti.

Smlouva SLA pro dostupnost serveru rozhraní Kubernetes API

AKS je možné použít jako bezplatnou službu, ale tato úroveň nenabízí finančně podefinované smlouvy SLA. Pokud chcete tuto sla získat, musíte k nákupu přidat sla pro dostupnost. Tuto možnost doporučujeme použít u všech produkčních clusterů. Rezervace clusterů bez této možnosti pro předprodukčové clustery V kombinaci s Zóny dostupnosti Azure se smlouva SLA serveru rozhraní Kubernetes API zvýší na 99,95 %. Na vaše fondy uzlů a další prostředky se vztahuje jejich vlastní smlouva SLA.

Kompromis

U nasazení architektury napříč zónami a zejména oblastmi existuje kompromis mezi náklady na dostupnost. Některé funkce replikace, například geografická replikace v Azure Container Registry, jsou k dispozici ve skladové skladové oblasti úrovně Premium, což je dražší. Náklady se také zvýší, protože poplatky za šířku pásma, které se použijí při přesunu provozu mezi zónami a oblastmi.

Můžete také očekávat další latenci sítě při komunikaci uzlů mezi zónami nebo oblastmi. Změřte dopad tohoto rozhodnutí o architektuře na vaši úlohu.

Testování pomocí simulací a vynucených převzetí služeb při selhání

Zajistěte spolehlivost prostřednictvím testování vynuceného převzetí služeb při selhání pomocí simulovaných výpadků, jako je například vypadnutí uzlu, vypadnutí všech prostředků AKS v konkrétní zóně pro simulaci zónových selhání nebo vypadnutí externí závislosti.

Monitorování a shromažďování metrik

Funkce Azure Monitor pro kontejnery je doporučeným nástrojem pro monitorování a protokolování, protože události můžete zobrazit v reálném čase. Zachycuje protokoly kontejnerů ze spuštěných podů a agreguje je pro zobrazení. Shromažďuje také informace z rozhraní API pro metriky o využití paměti a procesoru a monitoruje stav spuštěných prostředků a úloh. Můžete ho použít k monitorování výkonu při škálování podů. Další výhodou je, že můžete snadno použít Azure Portal grafy a řídicí panely. Umožňuje vytvářet výstrahy, které aktivují runbooky služby Automation, Azure Functions a další.

Většina úloh hostovaných v podech generuje metriky Prometheus. Azure Monitor dokáže scrapovat metriky Prometheus a vizualizovat je.

S Kubernetes jsou integrované některé nástroje třetích stran. Pokud je vaše organizace už používá, využijte platformy protokolů a metrik, jako je Grafana nebo Datadog.

V AKS spravuje Azure některé základní služby Kubernetes. Protokoly z těchto služeb by měly být povolené jenom pro každou žádost od zákaznické podpory. Doporučujeme však povolit tyto zdroje protokolů, protože vám můžou pomoct při řešení potíží s clustery:

  • Protokolováním služby ClusterAutoscaler získáte pozorovatelnost operací škálování. Další informace najdete v tématu Načtení protokolů a stavu automatického škálování clusteru.
  • KubeControllerManager, aby měl pozorovatelnost v plánovači podů.
  • KubeAuditAdmin, aby měl pozorovatelnost v aktivitách, které upravuje váš cluster.

Povolení samoochyty

Stav podů můžete monitorovat nastavením možností Liveness (Aktivity) a Readiness probes (Testy připravenosti). Pokud se detekuje nereagující pod, Kubernetes pod restartuje. Sonda živého stavu určuje, jestli je pod v pořádku. Pokud neodpovídá, Kubernetes pod restartuje. Sonda připravenosti určuje, jestli je pod připravený přijímat požadavky nebo provoz.

Poznámka

AKS poskytuje integrované samoopravení uzlů infrastruktury pomocí automatické opravy uzlů.

Aktualizace zabezpečení

Udržujte verzi Kubernetes aktuální s podporovanými verzemi N-2. Upgrade na nejnovější verzi Kubernetes je kritický, protože se často vydaná nová verze.

Další informace najdete v tématu Pravidelná aktualizace na nejnovější verzi Kubernetes a Upgrade clusteru Azure Kubernetes Service (AKS).

Týdenní aktualizace

AKS poskytuje nové image uzlů s nejnovějšími aktualizacemi operačního systému a modulu runtime. Tyto nové image se automaticky neumění. Zodpovídáte za rozhodnutí, jak často se mají image aktualizovat. Doporučujeme, abyste měli každý týden proces upgradu základní image fondů uzlů. Další informace najdete v tématu Azure Kubernetes Service (AKS) upgradu image a poznámky k verzi AKS.

Denní aktualizace

Mezi upgrady image si uzly AKS stahují a instalují opravy operačního systému a modulu runtime jednotlivě. Instalace může vyžadovat restartování virtuálních počítače uzlů. AKS nebude restartovat uzly kvůli čekajícím aktualizacím. Proveďte proces, který monitoruje použité aktualizace v uzlech, které vyžadují restartování, a řízeným způsobem provádí restartování těchto uzlů. Open source možností je Kured (proces démon restartování Kubernetes).

Udržování imagí uzlů v synchronizaci s nejnovější týdenní verzí minimalizuje tyto občasné žádosti o restartování při zachování vylepšené doby zabezpečení. Když se budete spoléhat jenom na upgrady i image uzlů, zajistíte kompatibilitu AKS a týdenní opravy zabezpečení. Zatímco při použití denních aktualizací se problémy se zabezpečením opraví rychleji, nemusí být nutně otestované v AKS. Pokud je to možné, použijte jako primární týdenní strategii oprav zabezpečení upgrade image uzlu.

Monitorování zabezpečení

Monitorujte infrastrukturu kontejnerů z oblasti aktivních hrozeb i potenciálních rizik zabezpečení:

Provoz clusterů a úloh (DevOps)

Tady je několik důležité informace. Další informace najdete v pilíři Efektivita provozu.

Izolace zodpovědností za úlohy

Rozdělte úlohu podle týmů a typů prostředků, abyste každou část jednotlivě spravují.

Začněte se základní úlohou, která obsahuje základní komponenty a vychází z ní. Počátečním úkolem by bylo nakonfigurovat sítě. Zřizované virtuální sítě pro centrum, paprsky a podsítě v těchto sítích. Například tento paprsk má samostatné podsítě pro fondy systémových a uživatelských uzlů a prostředky příchozího přenosu dat. Podsíť Azure Firewall v centru.

Další částí může být integrace základní úlohy s Azure Active Directory.

Použití infrastruktury jako kódu (IaC)

Zvolte idempotentní deklarativní metodu před imperativním přístupem, kde je to možné. Místo psaní posloupnosti příkazů, které určují možnosti konfigurace, použijte deklarativní syntaxi popisující prostředky a jejich vlastnosti. Jednou z možností je Azure Resource Manager (ARM) a další možností je Terraform.

Při zřizování prostředků se ujistěte, že se řídí zásadami. Když například vybíráte správné velikosti virtuálních počítačů, držte se v nákladových omezeních a možnostech zóny dostupnosti tak, aby odpovídaly požadavkům vaší aplikace.

Pokud potřebujete napsat posloupnost příkazů, použijte Azure CLI. Tyto příkazy pokrývají celou řadu služeb Azure a je možné je automatizovat pomocí skriptování. Azure CLI se podporuje ve Windows a Linuxu. Další možností pro více platforem je Azure PowerShell. Vaše volba bude záviset na preferované sady dovedností.

Skripty a soubory šablon a jejich verze můžete ukládat v systému správy zdrojového kódu.

CI/CD úloh

Kanály pro pracovní postupy a nasazení musí mít schopnost průběžně sestavovat a nasazovat aplikace. Aktualizace se musí nasazovat bezpečně a rychle a vrátit zpět pro případ, že by došlo k problémům.

Vaše strategie nasazení musí zahrnovat spolehlivý a automatizovaný kanál průběžného doručování (CD). Změny imagí kontejnerů úloh by se měly automaticky nasadit do clusteru.

V této architektuře jsme zvolili GitHub Actions pro správu pracovního postupu a nasazení. Mezi další oblíbené možnosti patří Azure DevOps Services a Jenkins.

CI/CD clusteru

CI/CD úloh

Místo imperativního přístupu, jako je kubectl, použijte nástroje, které automaticky synchronizují změny clusteru a úložiště. Pokud chcete pracovní postup spravovat, například vydání nové verze a ověření této verze před nasazením do produkčního prostředí, zvažte tok GitOps. Agent je nasazený v clusteru, aby se ujistil, že stav clusteru je koordinovaný s konfigurací uloženou v privátním úložišti Git. Kubernetes a AKS toto prostředí nativně nepodporují. Doporučenou možností je flux. K aktivaci nasazení v Kubernetes používá jeden nebo více operátorů v clusteru. Flux dělá tyto úlohy:

  • Monitoruje všechna nakonfigurovaná úložiště.
  • Zjišťuje nové změny konfigurace.
  • Aktivuje nasazení.
  • Aktualizuje požadovanou spuštěnou konfiguraci na základě těchto změn.

Můžete také nastavit zásady, které určují, jak se tyto změny nasadí.

Tady je příklad z referenční implementace, která ukazuje, jak automatizovat konfiguraci clusteru pomocí GitOps a Flux.

GitOps Flow

  1. Vývojář potvrdí změny zdrojového kódu, jako jsou konfigurační soubory YAML, které jsou uložené v úložišti Git. Změny se pak nasoudí na server Git.

  2. Flux běží v podu společně s úlohou. Flux má k úložišti Git přístup jen pro čtení, aby měl jistotu, že flux aplikuje změny jenom na žádost vývojářů.

  3. Flux rozpozná změny v konfiguraci a použije je pomocí příkazů kubectl.

  4. Vývojáři nemají přímý přístup k rozhraní Kubernetes API prostřednictvím kubectl. Mít na serveru Git zásady větví Tímto způsobem může změnu schválit více vývojářů, než se použije v produkčním prostředí.

Strategie nasazení úloh a clusterů

Nasaďte všechny změny (komponenty architektury, úlohy, konfigurace clusteru) alespoň do jednoho předproduového clusteru AKS. Tím se nasimuluje změna, která může před nasazením do produkčního prostředí vyřešit potíže.

Před přechodem na další fázi spusťte testy a ověření, abyste měli jistotu, že můžete do produkčního prostředí do produkčního prostředí provádět vysoce řízené aktualizace a minimalizovat přerušení před neočekávanými problémy s nasazením. Toto nasazení by mělo postupovat podobně jako v produkčním prostředí s použitím stejného GitHub Actions kanálu nebo operátorů Flux.

Pokročilé techniky nasazení, jako jsou modro-zelené nasazení,testování A/B a testovací verze Canary,budou vyžadovat další proces a potenciálně nástroje. Flagger je oblíbené open source řešení, které pomáhá řešit vaše pokročilé scénáře nasazení.

Správa nákladů

K odhadu nákladů na služby používané v architektuře použijte cenovou kalkulačku Azure. Další osvědčené postupy jsou popsány v části Optimalizace nákladů v Microsoft Azure Well-Architected Framework.

Zřídit

  • Za AKS nejsou spojené žádné náklady na nasazení, správu a provoz clusteru Kubernetes. Hlavním nákladem jsou instance virtuálních počítačů, úložiště a síťové prostředky spotřebované clusterem. Zvažte volbu levnějších virtuálních počítače pro fondy systémových uzlů. Doporučená SKU je DS2_v2.

  • Nemáte stejnou konfiguraci pro vývojová/testovací a produkční prostředí. Produkční úlohy mají další požadavky na vysokou dostupnost a budou dražší. V prostředí pro vývoj/testování nemusí být potřeba.

  • Pro produkční úlohy přidejte sla pro dobu provozu. Pro clustery navržené pro vývoj/testování nebo experimentální úlohy však existují úspory, u kterých není zaručená dostupnost. Například SLO je dostačující. Pokud to vaše úloha podporuje, zvažte také použití vyhrazených fondů spotových uzlů, na které běží spotové virtuální počítače.

    V případě neprodukních úloh, které zahrnují Azure SQL Database nebo Azure App Service jako součást architektury úloh AKS, vyhodnoťte, jestli máte nárok využívat předplatná Azure pro vývoj/testování k získání slev za služby.

  • Místo toho, abyste začínali s naddimenzováním clusteru, který splňuje potřeby škálování, zřizujte cluster s minimálním počtem uzlů a umožňte automatickému škálování clusteru monitorování a rozhodování o velikosti.

  • Nastavte požadavky a omezení podů tak, aby Kubernetes přiděloval prostředky uzlů s vyšší hustotou tak, aby se hardware využíoval ke kapacitě.

  • Povolení diagnostiky v clusteru může zvýšit náklady.

  • Pokud se očekává, že vaše úloha existuje po dlouhou dobu, můžete se zavázat k jednoletému nebo tříletému vyhrazenému virtuálnímu počítači, abyste snížili náklady na uzly. Další informace najdete v tématu Vyhrazené virtuální počítače.

  • Značky použijte při vytváření fondů uzlů. Značky jsou užitečné při vytváření vlastních sestav pro sledování vzniklých nákladů. Značky poskytují možnost sledovat celkový náklady a mapovat všechny náklady na konkrétní prostředek nebo tým. Pokud se cluster sdílí mezi týmy, sestavujte sestavy zpětného vúčtování na jednoho příjemce, abyste identifikovali měřené náklady na sdílené cloudové služby. Další informace najdete v tématu Určení taintu, popiskunebo značky pro fond uzlů.

  • Přenosy dat v rámci zón dostupnosti oblasti nejsou bezplatné. Pokud je vaše úloha ve více oblastech nebo dochází k přenosům mezi fakturačními zónami, očekávejte další náklady na šířku pásma. Další informace najdete v tématu Provoz napříč fakturačními zónami a oblastmi.

  • Vytvářejte rozpočty tak, aby byly v rámci nákladových omezení identifikovaných organizací. Jedním ze je vytvoření rozpočtů prostřednictvím Azure Cost Management. Můžete také vytvořit výstrahy, které budou dostávat oznámení při překročení určitých prahových hodnot. Další informace najdete v tématu Vytvoření rozpočtu pomocí šablony.

Monitor

Aby bylo možné monitorovat náklady na celý cluster, společně s náklady na výpočetní prostředky také shromažďují informace o nákladech na úložiště, šířku pásma, bránu firewall a protokoly. Azure nabízí různé řídicí panely pro monitorování a analýzu nákladů:

V ideálním případě sledujte náklady v reálném čase nebo alespoň v pravidelných tempo, které je potřeba provést před koncem měsíce, pokud jsou již náklady vypočítány. Sledujte také měsíční trend v čase, abyste si mohli zůstat v rozpočtu.

Chcete-li udělat rozhodnutí řízená daty, určete, který prostředek (detailní úroveň) má největší náklady. Také je dobré porozumět měřičům, které se používají k výpočtu využití každého prostředku. Analýzou metrik můžete určit, jestli je platforma pro instanci nadlimitní. Měřiče využití můžete zobrazit v Azure Monitor metriky.

Optimalizace

Působit na doporučeních, která poskytuje Azure Advisor. Existují i jiné způsoby, jak optimalizovat:

  • Povolte automatickému škálování clusteru zjišťování a odebírání nevyužitých uzlů ve fondu uzlů.

  • Vyberte nižší SKLADOVOU položku pro fondy uzlů, pokud ji vaše zatížení podporuje.

  • Pokud aplikace nevyžaduje škálování shlukování, zvažte nastavení velikosti clusteru na správnou velikost analýzou metrik výkonu v průběhu času.

  • Pokud to vaše zatížení podporuje, škálovat fondy uživatelských uzlů na 0 uzlů v případě, že neočekáváte, že budou spuštěné. Pokud ve vašem clusteru nemusíte spouštět žádné úlohy, které by bylo naplánováno ke spuštění, zvažte použití funkce AKS spustit/zastavit pro vypnutí všech výpočtů, včetně vašeho fondu systémových uzlů a roviny ovládacího prvku AKS.

Další informace související s náklady najdete v tématu AKS Price.

Další kroky

Pokud potřebujete aktualizační program v Kubernetes, dokončete Úvod do Kubernetes a vývoj a nasaďte aplikace na cestách Kubernetes výuky na Microsoft Learn.