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

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 na základě obchodních požadavků organizace.

 GitHub: Azure Kubernetes Service (AKS) Secure Baseline Reference Implementation. Můžete ho použít jako výchozí bod a nakonfigurovat podle svých potřeb.

Konfigurace sítě

Topologie sítě
Plánování IP adres
Nasazení prostředků příchozího přenosu dat

Výpočetní prostředky clusteru

Výpočetní prostředky pro základní cluster
Referenční informace k i image kontejneru
Správa zásad

Správa identit

Integrace Azure AD pro cluster
Integrace Azure AD pro úlohu

Zabezpečení toku dat

Zabezpečení toku sítě
Přidání správy tajných klíče

Kontinuita podnikových procesů

Škálovatelnost
Dostupnost clusteru a uzlu
Dostupnost a podpora více oblastí

Operace

Kanály CI/CD clusteru a úloh
Stav a metriky clusteru
Správa nákladů a vytváření sestav

Síťová topologie

Tato architektura používá síťovou topologii centra s paprsky. Centrum a paprsky jsou nasazené v samostatných virtuálních sítích propojených prostřednictvím partnerského vztahu. Tato topologie má několik výhod:

• Oddělení správy: Umožňuje způsob použití zásad správného řízení a řízení poloměru okruhu. Podporuje také koncept cílové zóny s rozdělením povinností.

• Minimalizuje přímé vystavení prostředků Azure veřejnému internetu.

• Organizace často pracují s oblastní topologií s centrálními paprsky. V budoucnu je možné rozšířit topologie sítě s paprsky a zajistit izolaci úloh.

• Všechny webové aplikace by měly k řízení toků provozu HTTP vyžadovat službu Firewall webových aplikací (WAF).

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

• Díky tomu je architektura rozšiřitelná. Aby bylo možné přizpůsobit nové funkce nebo úlohy, je možné místo přepracování síťové topologie přidat nové paprsky.

• Určité prostředky, jako je brána firewall a DNS, je možné sdílet napříč sítěmi.

Rozbočovač

Centrální virtuální síť je ústředním bodem připojení a pozorovatelnosti. V rámci sítě se nasadí 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 vpn nebo bránu ExpressRoute. Brána zajišťuje připojení mezi směrovači v místní síti a virtuální sítí.

Podsíť pro hostování Azure Bastion

Tato podsíť je zástupný symbol pro Azure Bastion. Bastion 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 operace.

Mluvil

Paprsková virtuální síť bude obsahovat cluster AKS a další související prostředky. Paprsk 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ý funguje ve vrstvě 7. Referenční implementace používá skladové Application Gateway v2, která umožňuje Web Application Firewall (WAF). WAF zabezpečuje příchozí provoz před běžnými útoky na webový provoz. Instance má konfiguraci veřejné front-endové IP adresy, která přijímá požadavky uživatelů. Z návrhu Application Gateway vyhrazenou podsíť.

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

Pro směrování a distribuci provozu je Traefik kontroler příchozího přenosu dat, který bude plnit prostředky příchozího přenosu dat Kubernetes. 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 systémových uzlů hostuje pody, na které běží základní služby clusteru. Fond uzlů uživatele spouští úlohu Contoso a kontroler příchozího přenosu dat, aby se usnadnila příchozí komunikace s úlohou. Úloha je jednoduchá ASP.NET aplikace.

Další informace najdete v části Topologie sítě centra s paprsky v Azure.

Plánování IP adres

Adresní prostor virtuální sítě by měl být dostatečně velký pro všechny podsítě. Účet pro všechny entity, které budou přijímat provoz. IP adresy pro tyto entity se přidělí z adresního prostoru podsítě. Zamyslete se nad těmito body.

• Upgrade

  AKS pravidelně aktualizuje uzly, aby se ujistil, že základní virtuální počítače jsou aktuální funkce zabezpečení a další systémové opravy. Během procesu upgradu vytvoří AKS uzel, který dočasně hostuje pody, zatímco uzel upgradu je cordonovaný a vyprázdněný. Tento dočasný uzel má přiřazenou IP adresu z podsítě clusteru.

  U podů můžete potřebovat další adresy v závislosti na vaší strategii. Pro postupné aktualizace budete potřebovat adresy dočasných podů, které spouštějí úlohu, zatímco se skutečné pody aktualizují. Pokud použijete strategii nahrazení, pody se odstraní a vytvoří se nové. Adresy přidružené ke starým podům se proto znovu použije.

• Škálovatelnost

  Vezměte v úvahu počet uzlů všech systémových a uživatelských uzlů a jejich maximální limit škálovatelnosti. Předpokládejme, že chcete škálovat na více než 400 %. Pro všechny uzly s horizontálním navýšením velikosti budete potřebovat čtyřikrát více adres.

  V této architektuře je možné každý pod kontaktovat přímo. Každý pod proto potřebuje individuální adresu. Škálovatelnost podů bude mít vliv na výpočet adresy. Toto rozhodnutí bude záviset na vaší volbě počtu podů, které chcete rozšiřovat.

• Azure Private Link adresy

  Zovážte adresy, které jsou potřeba ke komunikaci s dalšími službami Azure přes Private Link. 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 k internímu prostředí. AKS přístup ke komponentám Azure, jako jsou síťové infrastruktury, Azure Container Registry a Azure Key Vault. Autorizujte jenom prostředky, ke kterým má cluster povolený přístup.
• Přístup mimo Cloud. Poskytnutí identit přístup ke clusteru Kubernetes. Autorizujte jenom ty externí entity, které mají povolený přístup k serveru rozhraní Kubernetes API a Azure Resource Manager.

AKS přístup k Azure

existují dva způsoby, jak spravovat AKS pomocí služby azure access prostřednictvím 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 klíče, ale také si tento tajný klíč vydáte 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.
• Monitorování metrik Publisher. Schopnost clusteru odesílat metriky do Azure Monitor.
• AcrPull. Schopnost clusteru načítat image z určených kontejnerů Azure Container Registry.

Přístup clusteru

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.

AKS umožňuje Kubernetes přístup pomocí Azure Active Directory dvěma způsoby. první používá Azure Active Directory jako zprostředkovatele identity integrovaného s nativním systémem Kubernetes RBAC. Druhý k řízení přístupu k clusteru používá nativní službu Azure RBAC. Obě jsou popsané níže.

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. Definuje objekt RoleBinding CluserRoleBinding nebo .

Kubernetes má některé předdefinované role, jako je správce clusteru, úpravy, zobrazení atd. Vytvořte vazbu těchto rolí Azure Active Directory uživatele a skupiny a použijte podnikový adresář ke správě přístupu. Další informace najdete v tématu Použití Kubernetes RBAC s integrací Azure AD.

Ujistěte se, že vaše skupiny Azure AD používané pro přístup ke clusteru a oboru názvů jsou součástí vašich recenzí přístupu Azure AD.

Použití Azure RBAC pro autorizaci Kubernetes

Místo použití řízení přístupu na základě role v Kubernetes s integrovaným ověřováním AAD je další možností použití Azure RBAC a přiřazení rolí k vynucení přístupu ke clusteru. Výhodou použití Azure RBAC je, že není nutné konfigurovat nativní role RBAC a vazby rolí Kubernetes.

Další informace najdete v tématu Role Azure.

Místní účty

AKS podporuje nativní ověřování uživatelů Kubernetes. Přístup uživatelů ke clusterům pomocí této metody se nenavrhuje. Je založená na certifikátech a provádí se externě pro vašeho primárního zprostředkovatele identity. ztěžují centralizované řízení přístupu uživatelů a zásady správného řízení. Vždy spravujte přístup ke clusteru prostřednictvím Azure Active Directory a nakonfigurujte cluster tak, aby explicitně zakažte přístup k místnímu účtu.

V této referenční implementaci je přístup prostřednictvím účtů místního clusteru explicitně zakázán při nasazení clusteru.

Integrace Azure Active Directory pro úlohu

Podobně jako spravované identity Azure pro celý cluster můžete spravované identity přiřazovat na úrovni podu. 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á provoz 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 pouze 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.

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.

• Egress provozu. 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.

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á od klienta jenom šifrované požadavky TLS. 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.

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řesouvá 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 se ukládají v Azure Key Vault a připojí se ke clusteru pomocí ovladače CONTAINER Storage Interface (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ě. Vaše požadavky na úlohy a dodržování předpisů budou diktovat, kde provádíte ukončení protokolu TLS.

Egress toku provozu

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 pro inteligenci hrozeb.

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 se konkrétní podsítě 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 nejsou možné, můžete prostřednictvím jejich veřejných koncových bodů přistupovat k jiný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ě.

Povolte zásady sítě, když je cluster zřízen, protože ho nelze 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.

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 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 Storage 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. Buďte opatrní při volbě tohoto režimu, protože může být pro fungování úlohy příliš omezující.

• Máte oblasti v rámci úlohy, které by nemusely být v souladu s návrhem? Azure Policy má možnost zadat obory názvů Kubernetes, které jsou vyloučené z vynucování zásad. Doporučuje se, abyste stále v režimu auditování použili zásady, abyste si je dozvěděli o těchto instancích.

• Máte požadavky, které nejsou zahrnuté do předdefinovaných zásad? V těchto vzácných případech vytvořte vlastní definici Azure Policy, která použije vaše vlastní zásady pro webneprů gatekeeper. Neaplikujte zásady přímo na cluster.

• Máte požadavky na organizaci? V takovém případě tyto zásady přidejte na úrovni skupiny pro správu. Cluster by měl také přiřadit vlastní zásady pro konkrétní úlohy, i když má organizace obecné zásady.

• Zásady Azure se přiřazují konkrétním oborům. Zajistěte, aby byly do předprodukčního prostředí ověřené i produkční zásady. V opačném případě může při nasazování do provozního prostředí docházet k neočekávaným dalším omezením, která nebyla v předprodukčním prostředí zaúčtována.

V této referenční implementaci Azure Policy je povolený, když se vytvoří cluster AKS, a přiřadí omezující iniciativu v režimu auditování , aby bylo možné získat přehled o nedodržení předpisů.

Implementace taky nastavuje další zásady, které nejsou součástí žádné integrované iniciativy. Tyto zásady jsou nastaveny v režimu odepření . Například je k dispozici zásada, která zajistí, že se image z nasazeného ACRu jenom nasazují. 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ů.

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 stejnými hodnotami pro požadavky a limity. Potom tyto hodnoty postupně vylaďte, dokud nenaleďte prahovou hodnotu, která může způsobit nestabilitu v clusteru.

Tato omezení je možné zadat v manifestech nasazení. Další informace najdete v tématu Nastavení požadavků a omezení podů.

Podpora zón dostupnosti a více oblastí

Pokud vaše smlouva SLA vyžaduje vyšší dostupnost, chraňte se před ztrátou v zóně. Zóny dostupnosti můžete použít, pokud je oblast podporuje. Komponenty řídicí roviny i uzly ve fondech uzlů jsou pak schopné rozložit napříč zónami. Pokud je celá zóna nedostupná, uzel v jiné zóně v rámci oblasti je stále k dispozici. Každý fond uzlů se mapuje na samostatnou škálovací sadu virtuálních počítačů, která spravuje instance uzlů a škálovatelnost. Operace a konfigurace škálovací sady spravuje služba AKS. Při povolování vícezónových zón je třeba vzít v úvahu následující skutečnosti:

• Celá infrastruktura. Zvolte oblast, která podporuje zóny dostupnosti. Další informace najdete v tématu Omezení a dostupnost oblastí. Pokud si chcete koupit sla pro dostupnost, zvolte oblast, která tuto možnost podporuje. Smlouva SLA pro dostupnost 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 v 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 k zotavení ze selhání oblasti s využitím spárované oblasti. Výhodou použití spárovaných oblastí je spolehlivost během aktualizací. Azure zajišťuje, aby se v jednu chvíli aktualizovala pouze jedna oblast v páru. Určitá DevOps nástroje, jako je flux, mohou nasazení ve více oblastech usnadnit.

• 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 dokáže distribuovat ne webovou komunikaci mezi zóny. 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 Azure Container Registry 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

Při nasazování 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 do clusteruAutoscaler 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.

Aktualizace zabezpečení

Udržování verze Kubernetes v aktuálním stavu s podporovanými verzemi N-2. Upgrade na nejnovější verzi Kubernetes je kritický, protože se často uvolňují nové verze.

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

Oznámení o událostech vyvolaných vaším clusterem, jako je například nová dostupnost verze AKS pro váš cluster, je možné dosáhnout prostřednictvím systémového tématu AKS pro Azure Event Grid. Referenční implementace nasadí toto Event Grid systémové téma, abyste se mohli přihlásit k odběru Microsoft.ContainerService.NewKubernetesVersionAvailable události z řešení oznámení datového proudu událostí.

Týdenní aktualizace

AKS poskytuje nové image uzlů s nejnovějšími aktualizacemi operačního systému a za běhu. Tyto nové image nejsou automaticky aplikovány. Zodpovídáte za rozhodování o tom, jak často se mají obrázky aktualizovat. Doporučuje se, abyste měli proces upgradu základní image fondů uzlů na týden. Další informace najdete v poznámkách k verzi AKSv tématu Azure KUBERNETES Service (AKS) .

Každodenní aktualizace

Mezi upgrady imagí AKS uzly stahují a instalují opravy operačního systému a za běhu jednotlivě. Instalace může vyžadovat restartování virtuálních počítačů uzlů. AKS neprovede restart uzlů z důvodu nedokončených aktualizací. Mít proces, který monitoruje uzly pro používané aktualizace, které vyžadují restartování a provádí restartování těchto uzlů kontrolovaným způsobem. Možnost Open Source je Kured (démon pro Kubernetes restart).

Udržování imagí uzlů v synchronizaci s nejnovějším týdenním vydáním minimalizuje tyto příležitostné požadavky na restartování a zachová stav zvýšeného zabezpečení. Spoléhání se jenom na upgrady imagí uzlů zajistí kompatibilitu AKS a týdenní opravy zabezpečení. Vzhledem k tomu, že při použití každodenních aktualizací dojde k rychlejšímu řešení potíží se zabezpečením, nebylo nutně testováno v AKS. Pokud je to možné, použijte upgrade bitové kopie uzlu jako primární strategii pro opravy zabezpečení.

Monitorování zabezpečení

Monitorujte infrastrukturu kontejneru pro aktivní hrozby a potenciální bezpečnostní rizika:

• Povolte Azure Defender pro Kubernetes pro detekci hrozeb v clusterech Kubernetes.
• K monitorování stav zabezpečení Kubernetes použijte Azure Security Center (ASC).
• Informace o posílení zabezpečení používaného pro hostitele virtuálních počítačů s AKS najdete v tématu posílení zabezpečení v hostitelském operačním systému.

Operace s clustery a úlohami (DevOps)

Tady je několik důležitých informací. Další informace najdete v článku věnovaném pilířům pro provozní výkon .

Izolace odpovědností úloh

Rozdělení zatížení podle týmů a typů prostředků na jednotlivé části můžete individuálně spravovat.

Začněte se základní úlohou, která obsahuje základní komponenty a na ni se sestavuje. Počáteční úlohou je konfigurace sítě. Zřizování virtuálních sítí pro centrum a paprsky a podsítě v těchto sítích. Například paprsek má samostatné podsítě pro fondy systémových a uživatelských uzlů a prostředky příchozího přenosu dat. Podsíť pro 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)

Pokud je to možné, vyberte deklarativní metodu idempotentní prostřednictvím imperativního přístupu. Namísto psaní sekvence příkazů, které určují možnosti konfigurace, použijte deklarativní syntaxi, která popisuje prostředky a jejich vlastnosti. Jednou z možností je, že jiné šablony Azure Resource Manager (ARM) jsou terraformu.

Ujistěte se, že zřizujete prostředky podle zásad řízení. Když například vybíráte správné velikosti virtuálních počítačů, můžete zůstat v rámci omezení nákladů a možností zóny dostupnosti tak, aby odpovídaly požadavkům vaší aplikace.

Pokud potřebujete napsat sekvenci příkazů, použijte rozhraní příkazového řádku Azure. Tyto příkazy se týkají řady služeb Azure a můžou být automatizované prostřednictvím skriptování. rozhraní příkazového řádku Azure je podporované v systémech Windows a Linux. Další možností pro více platforem je Azure PowerShell. Vaše volba bude záviset na preferovaných dovednosti.

Uložení a verze skriptů a souborů šablon v systému správy zdrojů.

CI/CD úlohy

Pipelines pro pracovní postup a nasazení musí mít možnost průběžně sestavovat a nasazovat aplikace. Aktualizace se musí nasadit bezpečně a rychle a vrátit se zpátky v případě, že dojde k problémům.

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

v této architektuře jsme zvolili GitHub akce pro správu pracovního postupu a nasazení. mezi další oblíbené možnosti patří Azure DevOps Services a jenkinse.

CI/CD clusteru

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

• Monitoruje všechna nakonfigurovaná úložiště.
• Detekuje nové změny konfigurace.
• Spustí 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 budou tyto změny nasazeny.

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

1. Vývojář potvrdí změny ve zdrojovém kódu, jako jsou například konfigurační soubory YAML, které jsou uloženy v úložišti Git. Změny jsou následně vloženy na server Git.

2. tok běží v části vedle zatížení. tok má k úložišti Git přístup jen pro čtení, aby se zajistilo, že tok bude používat jenom změny, jak si vyžádali vývojáři.

3. tok rozpoznává změny v konfiguraci a aplikuje tyto změny pomocí příkazů kubectl.

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

Strategie nasazení úloh a clusterů

Nasaďte všechny změny (součásti architektury, úlohy, konfigurace clusteru) aspoň jeden předprodukční cluster AKS. Tato změna způsobí simulaci změny, může Unravel problémy před nasazením do produkčního prostředí.

Před přechodem k dalšímu kroku spusťte testy/ověření v každé fázi a ujistěte se, že můžete doručovat aktualizace do provozního prostředí vysoce kontrolovaným způsobem a minimalizovat přerušení před neočekávanými problémy s nasazením. toto nasazení by mělo následovat podobně jako v produkci, a to pomocí stejného kanálu GitHub akce nebo operátorů toku.

Pokročilé techniky nasazení, jako je například nasazení Blue-zelená, testování a/B a Kanárské verze, budou vyžadovat další proces a potenciálně nástroje. Příznakem je oblíbené open source řešení, které vám může přispět k řešení vašich pokročilých scénářů nasazení.

Správa nákladů

Pomocí cenové kalkulačky Azure můžete odhadnout náklady na služby používané v architektuře. další osvědčené postupy jsou popsané v části věnované optimalizaci nákladů v Microsoft Azure Well-Architected Framework.

Zřídit

• Pro AKS se nevztahují žádné náklady na nasazení, správu a provoz clusteru Kubernetes. Hlavním ovladačem nákladů jsou instance virtuálních počítačů, úložiště a síťové prostředky spotřebované clusterem. Zvažte možnost výběru levnějších virtuálních počítačů pro fondy systémových uzlů. Doporučená SKU je DS2_v2.

• Nemáte stejnou konfiguraci pro vývoj a testování a produkční prostředí. Produkční úlohy mají navíc požadavky na vysokou dostupnost a budou dražší. Nemusí být nutné v prostředí pro vývoj a testování.

• Pro produkční úlohy přidejte smlouvu SLA pro provozuschopnost. 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 na využití předplatných 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é výdaje 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 způsobů je vytvář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 poskytuje různé řídicí panely pro monitorování a analýzu nákladů:

• Azure Advisor

• Azure Cost Management

V ideálním případě monitorujte náklady v reálném čase nebo alespoň v pravidelných intervalech, abyste před koncem měsíce, kdy se náklady už počítají, šly provést akci. Sledujte také měsíční trend v průběhu času, abyste zůstali v rozpočtu.

Pokud se chcete rozhodovat na základě dat, můžete určit, který prostředek (podrobná úroveň) má největší náklady. Také dobře seznamte se s měřiči, které se používají k výpočtu využití jednotlivých prostředků. Analýzou metrik můžete například určit, jestli má platforma příliš velké velikosti. Měřiče využití můžete zobrazit v Azure Monitor metrikách.

Optimalizace

Dějte na základě doporučení poskytovaných Azure Advisor. Existují i jiné způsoby optimalizace:

• Povolte automatické škálování clusteru, aby detekovat a odebírat nevyužité uzly ve fondu uzlů.

• Pokud to vaše úloha podporuje, zvolte nižší SKU pro fondy uzlů.

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

• Pokud to vaše úloha podporuje, škálte fondy uzlů uživatele na 0 uzlů, pokud se neočekává jejich spuštění. Kromě toho, pokud v clusteru nezůstane naplánované spouštění žádných úloh, zvažte použití funkce AKS Start/Stop k vypnutí všech výpočetních prostředků, mezi které patří fond systémových uzlů a řídicí rovina AKS.

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

Další kroky

• Další informace o hostování mikroslužeb na standardních hodnotách AKS najdete v tématu Architektura mikroslužeb Advanced Azure Kubernetes Service (AKS).
• Informace o nasazení standardních hodnot AKS napříč několika oblastmi najdete v tématu Standardní hodnoty AKS pro clustery ve více oblastech.
• Informace o nasazení standardních hodnot AKS do prostředí PCI-DSS 3.2.1 najdete v tématu Regulovaný cluster AKS pro PCI-DSS 3.2.1.
• Viz Plány produktů AKS najdete v tématu Azure Kubernetes Service plán na GitHub.

Související články

Pokud potřebujete něco obnovovat v Kubernetes, dokončete úvod do Kubernetes a vyvíjet a nasazovat aplikace v Kubernetes v Microsoft Learn.