Aspekty síťové topologie a připojení pro AKS

Aspekty návrhu

Azure Kubernetes Service (AKS) poskytuje tři různé síťové modely pro sítě kontejnerů: Kubenet, CNI Overlay a CNI. Každý z těchto modelů má svou jedinečnou sadu funkcí a výhod, které nabízejí možnosti flexibility a škálovatelnosti pro sítě kontejnerů v AKS.

Kubenet

Kubenet je základní síťové řešení, které šetří adresní prostor IP adres a nabízí jednoduchou konfiguraci. Je ideální pro malé clustery AKS s méně než 400 uzly, kde je přijatelná ruční správa a údržba tras definovaných uživatelem. Je vhodný pro scénáře, ve kterých jsou interní nebo externí nástroje pro vyrovnávání zatížení dostatečné pro přístup k podům mimo cluster.

Azure CNI

Azure CNI je síťový model navržený pro pokročilé sítě. Poskytuje úplné připojení virtuální sítě pro pody, což umožňuje připojení pod-to-pod a pod-to-VM. Je ideální pro scénáře, ve kterých jsou vyžadovány pokročilé funkce AKS, jako jsou virtuální uzly. Je vhodný pro scénáře, kdy je k dispozici dostatečný adresní prostor IP adres a externí prostředky potřebují přímý přístup k podům. Síťové zásady AKS se podporují také v Azure CNI.

Azure CNI Overlay

Překrytí Azure CNI je navržené tak, aby řešilo nedostatek IP adres a zjednodušilo konfiguraci sítě. Je vhodný pro scénáře, kdy stačí vertikální navýšení kapacity až 1 000 uzlů a 250 podů na uzel a je přijatelné další směrování pro připojení podů. Požadavky na výchozí přenos dat AKS je také možné splnit s překrytím Azure CNI.

Souhrn doporučených případů použití pro každý síťový model najdete v tématu Porovnání síťových modelů v AKS.

Při návrhu clusteru AKS je navíc důležité pečlivě naplánovat přidělování IP adres a velikost podsítě virtuální sítě tak, aby podporovalo škálování. Virtuální uzly je možné použít pro rychlé škálování clusteru, ale existují určitá známá omezení.

Clustery AKS podporují skladové položky Azure Load Balanceru úrovně Basic a Standard a služby můžou být zpřístupněny veřejnými nebo interními nástroji pro vyrovnávání zatížení. AKS používá CoreDNS k poskytování překladu ip adres podům spuštěným v clusteru a odchozí (výchozí) síťový provoz je možné odesílat přes Azure Firewall nebo cluster síťových virtuálních zařízení.

Ve výchozím nastavení můžou všechny pody v clusteru AKS odesílat a přijímat provoz bez omezení. Zásady sítě Kubernetes se ale dají použít ke zlepšení zabezpečení a filtrování síťového provozu mezi pody v clusteru AKS. Pro AKS jsou k dispozici dva modely zásad sítě: zásady sítě Azure a Calico.

AKS nakonec nastaví skupinu zabezpečení sítě (NSG) v podsíti, ve které je cluster nasazený. Tuto skupinu zabezpečení sítě nedoporučujeme upravovat ručně, ale služby nasazené v AKS ho můžou ovlivnit.

Celkově výběr vhodného síťového modelu a pečlivé plánování síťových prostředků může pomoct optimalizovat výkon, zabezpečení a náklady na cluster AKS.

Privátní clustery

Viditelnost IP adres clusteru AKS může být veřejná nebo soukromá. Privátní clustery zpřístupňují rozhraní API Kubernetes přes privátní IP adresu, ale ne přes veřejný. Tato privátní IP adresa je reprezentována ve virtuální síti AKS prostřednictvím privátního koncového bodu. Rozhraní API Kubernetes by nemělo být přístupné prostřednictvím ip adresy, ale prostřednictvím plně kvalifikovaného názvu domény (FQDN). Překlad plně kvalifikovaného názvu domény rozhraní API Kubernetes na jeho IP adresu obvykle provádí zóna Azure Privátní DNS. Tuto zónu DNS může vytvořit Azure ve skupině prostředků uzlu AKS nebo můžete zadat existující zónu DNS.

Podle osvědčených postupů na podnikové úrovni nabízí překlad DNS pro úlohy Azure centralizované servery DNS nasazené v předplatném připojení, a to buď v centrální virtuální síti, nebo ve virtuální síti sdílených služeb připojených k Azure Virtual WAN. Tyto servery budou podmíněně překládat názvy specifické pro Azure a veřejné názvy pomocí Azure DNS (IP adresa 168.63.129.16) a privátních názvů pomocí podnikových serverů DNS. Tyto centralizované servery DNS ale nebudou moct plně kvalifikovaný název domény plně kvalifikovaného názvu domény rozhraní API AKS přeložit, dokud se nepřipojí k privátní zóně DNS vytvořené pro cluster AKS. Každá služba AKS má jedinečnou privátní zónu DNS, protože náhodný identifikátor GUID je před názvem zóny. Takže pro každý nový cluster AKS by měla být odpovídající privátní zóna DNS připojená k virtuální síti, kde jsou umístěné centrální servery DNS.

Všechny virtuální sítě by měly být nakonfigurované tak, aby pro překlad názvů používaly tyto centrální servery DNS. Pokud je ale virtuální síť AKS nakonfigurovaná tak, aby používala centrální servery DNS a tyto servery DNS ještě nejsou připojené k privátní zóně DNS, uzly AKS nebudou moct přeložit plně kvalifikovaný název domény rozhraní Kubernetes API a vytvoření clusteru AKS selže. Virtuální síť AKS by měla být nakonfigurovaná tak, aby používala centrální servery DNS až po vytvoření clusteru.

Po vytvoření clusteru se vytvoří připojení mezi privátní zónou DNS a virtuální sítí, ve které jsou nasazené centrální servery DNS. Virtuální síť AKS je také nakonfigurovaná tak, aby používala centrální servery DNS v předplatném připojení a přístup správce k rozhraní API AKS Kubernetes bude postupovat podle tohoto toku:

Poznámka:

Obrázky v tomto článku odrážejí návrh pomocí tradičního modelu připojení hvězdicové architektury. Cílové zóny na podnikové úrovni se můžou rozhodnout pro model připojení Virtual WAN, ve kterém budou centrální servery DNS ve virtuální síti sdílených služeb připojené k centru Virtual WAN.

1. Správce přeloží plně kvalifikovaný název domény rozhraní Kubernetes API. Místní servery DNS předávají požadavek autoritativním serverům: překladače DNS v Azure. Tyto servery předávají požadavek na server Azure DNS (168.63.129.16), který získá IP adresu z zóny Azure Privátní DNS.
2. Po překladu IP adresy se provoz do rozhraní Kubernetes API směruje z místního prostředí do brány VPN nebo ExpressRoute v Azure v závislosti na modelu připojení.
3. Privátní koncový bod zavedl trasu /32 ve virtuální síti centra. Brány VPN a ExpressRoute odesílají provoz přímo do privátního koncového bodu rozhraní Kubernetes API nasazeného ve virtuální síti AKS.

Provoz z uživatelů aplikace do clusteru

Příchozí kontrolery (příchozí přenos dat) je možné použít ke zveřejnění aplikací spuštěných v clusterech AKS.

• Kontrolery příchozího přenosu dat poskytují směrování na úrovni aplikace za cenu mírného zvýšení složitosti.
• Kontrolery příchozího přenosu dat mohou zahrnovat funkce firewallu webových aplikací (WAF).
• Kontrolery příchozího přenosu dat můžou spouštět mimo cluster a v clusteru:
  • Kontroler příchozího přenosu dat mimo cluster přesměruje výpočetní výkon (například směrování provozu HTTP nebo ukončení protokolu TLS) do jiné služby mimo AKS, jako je doplněk Aplikace Azure Kontroleru příchozího přenosu dat brány (AGIC).
  • Řešení v clusteru využívá prostředky clusteru AKS pro výpočetní prostředky (například směrování provozu HTTP nebo ukončení protokolu TLS). Kontrolery příchozího přenosu dat v clusteru můžou nabízet nižší náklady, ale vyžadují pečlivé plánování a údržbu prostředků.
• Základní doplněk pro směrování aplikací HTTP je snadno použitelný, ale má určitá omezení, jak je uvedeno ve směrování aplikace HTTP.

Kontrolery příchozího přenosu dat můžou vystavit aplikace a rozhraní API s veřejnou nebo privátní IP adresou.

• Konfigurace by měla být v souladu s návrhem výstupního filtrování, aby nedocházelo k asymetrickým směrováním. Trasy definované uživatelem můžou způsobit asymetrické směrování (potenciálně), ale nemusí to nutně způsobit. Application Gateway může při provozu směrovat SNAT, což znamená, že se zpětný provoz vrací do uzlu služby Application Gateway, a ne na trasu definovanou uživatelem, pokud je trasa definovaná uživatelem nastavená jenom pro internetový provoz.
• Pokud je vyžadováno ukončení protokolu TLS, je potřeba zvážit správu certifikátů TLS.

Provoz aplikací může pocházet z místního prostředí nebo z veřejného internetu. Následující obrázek popisuje příklad, ve kterém je brána Aplikace Azure nakonfigurovaná pro reverzní připojení proxy serveru ke clusterům jak z místního prostředí, tak z veřejného internetu.

Provoz z místního prostředí sleduje tok očíslovaných modrých popisků v předchozím diagramu.

1. Klient přeloží plně kvalifikovaný název domény přiřazený k aplikaci pomocí serverů DNS nasazených v předplatném připojení nebo místních serverů DNS.
2. Po překladu plně kvalifikovaného názvu domény aplikace na IP adresu (privátní IP adresu aplikační brány) se provoz směruje přes vpn nebo bránu ExpressRoute.
3. Směrování v podsíti brány je nakonfigurované tak, aby odeslalo požadavek do brány firewall webových aplikací.
4. Firewall webových aplikací odesílá platné požadavky na úlohu spuštěnou v clusteru AKS.

Bránu Aplikace Azure v tomto příkladu je možné nasadit ve stejném předplatném jako cluster AKS, protože jeho konfigurace úzce souvisí s úlohami nasazenými v AKS, a proto je spravována stejným aplikačním týmem. Přístup z internetu sleduje tok očíslovaných zelených popisků v předchozím diagramu.

1. Klienti z veřejného internetu přeloží název DNS aplikace pomocí Azure Traffic Manageru. Alternativně je možné použít další globální technologie vyrovnávání zatížení, jako je Azure Front Door .
2. Traffic Manager přeloží veřejný plně kvalifikovaný název domény aplikace na veřejnou IP adresu aplikační brány, ke které klienti přistupují přes veřejný internet.
3. Aplikační brána přistupuje k úloze nasazené v AKS.

Poznámka:

Tyto toky jsou platné pouze pro webové aplikace. Jiné než webové aplikace jsou mimo rozsah tohoto článku a můžou být zpřístupněny prostřednictvím brány Azure Firewall ve virtuální síti centra nebo zabezpečeného virtuálního centra, pokud používáte model připojení virtual WAN.

Případně je možné provést toky přenosů pro webové aplikace, které procházejí bránou Azure Firewall v předplatném připojení i WAF ve virtuální síti AKS. Tento přístup má výhodu, že nabízí další ochranu, jako je použití inteligentního filtrování založeného na bráně Azure Firewall, aby se provoz ze známých škodlivých IP adres na internetu odečítá. Má však také určité nevýhody. Například ztráta původní IP adresy klienta a dodatečná koordinace potřebná mezi bránou firewall a aplikačními týmy při zveřejnění aplikací. Důvodem je to, že pravidla překladu cílových síťových adres (DNAT) budou potřeba ve službě Azure Firewall.

Provoz z podů AKS do back-endových služeb

Pody spuštěné v clusteru AKS můžou potřebovat přístup k back-endovým službám, jako jsou Azure Storage, databáze Azure SQL nebo databáze NoSQL služby Azure Cosmos DB. Koncové body služeb virtuální sítě a Private Link je možné použít k zabezpečení připojení k těmto spravovaným službám Azure.

Pokud pro back-endový provoz používáte privátní koncové body Azure, můžete překlad DNS pro služby Azure provádět pomocí zón Azure Privátní DNS. Vzhledem k tomu, že překladače DNS pro celé prostředí jsou v centrální virtuální síti (nebo ve virtuální síti sdílených služeb, pokud používáte model připojení virtual WAN), měly by se tyto privátní zóny vytvořit v předplatném připojení. Pokud chcete vytvořit záznam A potřebný k překladu plně kvalifikovaného názvu domény privátní služby, můžete přidružit privátní zónu DNS (v předplatném připojení) k privátnímu koncovému bodu (v předplatném aplikace). Tato operace vyžaduje v těchto předplatných určitá oprávnění.

Záznamy A je možné vytvořit ručně, ale přidružení privátní zóny DNS k privátnímu koncovému bodu má za následek nastavení méně náchylné k chybné konfiguraci.

Připojení back-endu z podů AKS ke službám Azure PaaS vystaveným prostřednictvím privátních koncových bodů postupujte takto:

1. Pody AKS přeloží plně kvalifikovaný název domény platformy Azure jako služby (PaaS) pomocí centrálních serverů DNS v předplatném připojení, které jsou definované jako vlastní servery DNS ve virtuální síti AKS.
2. Přeložená IP adresa je privátní IP adresa privátních koncových bodů, ke kterým se přistupuje přímo z podů AKS.

Provoz mezi pody AKS a privátními koncovými body ve výchozím nastavení neprochází bránou Azure Firewall ve virtuální síti centra (nebo zabezpečeného virtuálního centra, pokud používáte Virtual WAN), i když je cluster AKS nakonfigurovaný pro filtrování výchozích přenosů dat pomocí služby Azure Firewall. Důvodem je, že privátní koncový bod vytvoří trasu /32 v podsítích virtuální sítě aplikace, ve které je nasazená služba AKS.

Doporučení k návrhu

• Pokud vaše zásady zabezpečení vyžadují použití rozhraní Kubernetes API s privátní IP adresou (místo veřejné IP adresy), nasaďte privátní cluster AKS.
  • Při vytváření privátního clusteru používejte vlastní privátní zóny DNS místo toho, aby proces vytváření používal zónu privátního DNS systému.
• Azure Container Networking Interface (CNI) použijte jako síťový model, pokud nemáte omezený rozsah IP adres, které je možné přiřadit ke clusteru AKS.
  • Postupujte podle dokumentace k plánování IP adres pomocí CNI.
  • Pokud chcete k ověření konečných omezení použít fondy uzlů Windows Serveru a virtuální uzly, přečtěte si nejčastější dotazy k podpoře Windows AKS.
• Azure DDoS Protection použijte k ochraně virtuální sítě používané pro cluster AKS, pokud nepoužíváte Azure Firewall nebo WAF v centralizovaném předplatném.
• Použijte konfiguraci DNS propojenou s celkovým nastavením sítě pomocí služby Azure Virtual WAN nebo hvězdicové architektury, zón Azure DNS a vlastní infrastruktury DNS.
• Private Link slouží k zabezpečení síťových připojení a použití privátního připojení založeného na IP adresách k jiným spravovaným službám Azure, které podporují službu Private Link, jako je Azure Storage, Azure Container Registry, Azure SQL Database a Azure Key Vault.
• Pomocí kontroleru příchozího přenosu dat můžete poskytovat pokročilé směrování a zabezpečení PROTOKOLU HTTP a nabízet jeden koncový bod pro aplikace.
• Všechny webové aplikace nakonfigurované tak, aby používaly příchozí přenos dat, by měly používat šifrování TLS a nepovolovat přístup přes nešifrovaný protokol HTTP. Tato zásada se už vynucuje, pokud předplatné obsahuje doporučené zásady v zásadách, včetně referenčních implementací cílových zón na podnikové úrovni.
• Pokud chcete ušetřit výpočetní prostředky a prostředky úložiště clusteru AKS, použijte kontroler příchozího přenosu dat mimo cluster.
  • Použijte doplněk Aplikace Azure Kontroleru příchozího přenosu dat brány (AGIC), což je služba Azure spravovaná první stranou.
  • S AGIC nasaďte pro každý cluster AKS vyhrazenou bránu Aplikace Azure a nesdílejte stejnou službu Application Gateway napříč několika clustery AKS.
  • Pokud neexistují žádná omezení prostředků nebo provozu nebo AGIC neposkytuje požadované funkce, použijte řešení kontroleru příchozího přenosu dat v clusteru, jako je NGINX, Traefik nebo jakékoli jiné řešení podporované Kubernetes.
• V případě internetových a bezpečnostních kritických interních webových aplikací použijte bránu firewall webových aplikací s kontrolerem příchozího přenosu dat.
  • Aplikace Azure Gateway i Azure Front Door integrují Azure Web Application Firewall pro ochranu webových aplikací.
• Pokud vaše zásady zabezpečení vyžadují kontrolu veškerého odchozího internetového provozu vygenerovaného v clusteru AKS, zabezpečte odchozí síťový provoz pomocí služby Azure Firewall nebo síťového virtuálního zařízení třetí strany nasazeného ve virtuální síti spravovaného centra. Další informace najdete v tématu Omezení odchozího provozu. UDR odchozího typu AKS vyžaduje přidružení směrovací tabulky k podsíti uzlu AKS, takže ji není možné použít v současné chvíli s využitím injektáže dynamické trasy podporované službou Azure Virtual WAN nebo Azure Route Serverem.
• V případě nesoukromého clusteru použijte autorizované rozsahy IP adres.
• Místo úrovně Basic služby Azure Load Balancer použijte úroveň Standard.
• Při návrhu clusteru Kubernetes v Azure je jedním z klíčových aspektů výběr vhodného síťového modelu pro vaše konkrétní požadavky. Azure Kubernetes Service (AKS) nabízí tři různé síťové modely: Kubenet, Azure CNI a Azure CNI Overlay. Aby bylo možné provést informované rozhodnutí, je nezbytné porozumět schopnostem a charakteristikám jednotlivých modelů.

Porovnání funkcí mezi třemi síťovými modely v AKS; Porovnání síťových modelů v AKS najdete v tématu Kubenet, Azure CNI a Azure CNI Overlay.