Koncepty sítí pro aplikace ve službě Azure Kubernetes Service (AKS)

V kontejneru založeném na přístupu mikroslužeb k vývoji aplikací spolupracují komponenty aplikací na zpracování svých úloh. Kubernetes poskytuje různé prostředky, které umožňují tuto spolupráci:

• Můžete se připojit k aplikacím a zpřístupnit je interně nebo externě.
• Aplikace s vysokou dostupností můžete vytvářet vyrovnáváním zatížení aplikací.
• Pokud chcete zlepšit zabezpečení, můžete omezit tok síťového provozu do podů a uzlů nebo mezi těmito uzly.
• Přenosy příchozího přenosu dat můžete nakonfigurovat pro ukončení protokolu SSL/TLS nebo směrování více komponent pro složitější aplikace.

Tento článek představuje základní koncepty, které poskytují sítě aplikacím v AKS:

• Virtuální sítě Azure
• Kontrolery příchozího přenosu dat
• Zásady sítě

Základy sítí Kubernetes

Kubernetes využívá vrstvu virtuální sítě ke správě přístupu v rámci vašich aplikací a mezi jejich komponentami:

• Uzly Kubernetes a virtuální síť: Uzly Kubernetes jsou připojené k virtuální síti. Toto nastavení umožňuje, aby pody (základní jednotky nasazení v Kubernetes) měly příchozí i odchozí připojení.

• Komponenta kube-proxy: kube-proxy běží na každém uzlu a zodpovídá za poskytování potřebných síťových funkcí.

Týkající se konkrétních funkcí Kubernetes:

• Nástroj pro vyrovnávání zatížení: Nástroj pro vyrovnávání zatížení můžete použít k rovnoměrné distribuci síťového provozu napříč různými prostředky.
• Kontrolery příchozího přenosu dat: To usnadňuje směrování vrstvy 7, což je nezbytné pro směrování provozu aplikací.
• Řízení odchozího provozu: Kubernetes umožňuje spravovat a řídit odchozí provoz z uzlů clusteru.
• Zásady sítě: Tyto zásady umožňují bezpečnostní opatření a filtrování síťového provozu v podech.

V kontextu platformy Azure:

• Azure zjednodušuje virtuální sítě pro clustery AKS (Azure Kubernetes Service).
• Vytvoření nástroje pro vyrovnávání zatížení Kubernetes v Azure současně nastaví odpovídající prostředek nástroje pro vyrovnávání zatížení Azure.
• Když otevřete síťové porty pro pody, Azure automaticky nakonfiguruje potřebná pravidla skupiny zabezpečení sítě.
• Azure může také spravovat externí konfigurace DNS pro směrování aplikací HTTP při vytvoření nových tras příchozího přenosu dat.

Virtuální sítě Azure

V AKS můžete nasadit cluster, který používá jeden z následujících síťových modelů:

• Sítě Kubenet

  Síťové prostředky se obvykle vytvářejí a konfigurují při nasazení clusteru AKS.

• Sítě Azure Container Networking Interface (CNI)

  Cluster AKS je připojený k prostředkům a konfiguracím stávající virtuální sítě.

Sítě Kubenet (basic)

Možnost sítě kubenet je výchozí konfigurací pro vytvoření clusteru AKS. S kubenetem:

1. Uzly přijímají IP adresu z podsítě virtuální sítě Azure.
2. Pody přijímají IP adresu z logicky jiného adresního prostoru než podsíť virtuální sítě Azure uzlů.
3. Překlad adres (NAT) se pak nakonfiguruje tak, aby pody mohly získat přístup k prostředkům ve virtuální síti Azure.
4. Zdrojová IP adresa provozu se přeloží na primární IP adresu uzlu.

Uzly používají modul plug-in kubenet Kubernetes. Platformu Azure můžete nechat vytvářet a konfigurovat virtuální sítě za vás nebo můžete nasadit cluster AKS do existující podsítě virtuální sítě.

Směrovatelnou IP adresu obdrží jenom uzly. Pody používají překlad adres (NAT) ke komunikaci s dalšími prostředky mimo cluster AKS. Tento přístup snižuje počet IP adres, které potřebujete rezervovat v síťovém prostoru, aby se pody mohly používat.

Další informace najdete v tématu Konfigurace sítí kubenet pro cluster AKS.

Sítě Azure CNI (pokročilé)

Při použití Azure CNI získá každý pod IP adresu z podsítě a dá se k němu přistupovat přímo. Tyto IP adresy musí být naplánovány předem a jedinečně v celém síťovém prostoru. Každý uzel má konfigurační parametr pro maximální počet podů, které podporuje. Ekvivalentní počet IP adres na uzel se pak zahradí předem. Tento přístup může vést k vyčerpání IP adres nebo nutnosti znovu sestavit clustery ve větší podsíti s rostoucími požadavky vaší aplikace, takže je důležité správně naplánovat. Abyste těmto problémům s plánováním předešli, je možné povolit funkci sítí Azure CNI pro dynamické přidělování IP adres a rozšířenou podporu podsítě.

Na rozdíl od kubenetu se provoz do koncových bodů ve stejné virtuální síti nepřekládá (NAT) na primární IP adresu uzlu. Zdrojovou adresou provozu uvnitř virtuální sítě je IP adresa podu. Provoz, který je externí pro virtuální síť, stále naty na primární IP adresu uzlu.

Uzly používají modul plug-in Azure CNI Kubernetes.

Další informace najdete v tématu Konfigurace Azure CNI pro cluster AKS.

Překryvné sítě Azure CNI

Překrytí Azure CNI představuje vývoj azure CNI, který řeší problémy se škálovatelností a plánováním vyplývajícími z přiřazení IP adres virtuálních sítí k podům. Azure CNI Overlay přiřadí podům privátní IP adresy CIDR. Privátní IP adresy jsou oddělené od virtuální sítě a je možné je opakovaně používat napříč několika clustery. Překrytí Azure CNI se může škálovat nad rámec limitu 400 uzlů vynucených v clusterech Kubenet. Pro většinu clusterů se doporučuje překrytí Azure CNI.

Azure CNI využívající technologii Cilium

Azure CNI Powered by Cilium používá Cilium k zajištění vysoce výkonné sítě, pozorovatelnosti a vynucení zásad sítě. Nativně se integruje s překrytím Azure CNI pro škálovatelnou správu IP adres (Správa IP adres).

Cilium navíc ve výchozím nastavení vynucuje zásady sítě bez nutnosti samostatného síťového modulu zásad. Azure CNI Powered by Cilium může škálovat nad rámec limitů Azure Network Policy Manageru 250 uzlů / 20 K pomocí programů eBPF a efektivnější struktury objektů rozhraní API.

Azure CNI Powered by Cilium je doporučená možnost pro clustery, které vyžadují vynucení zásad sítě.

Používání vlastního CNI

V AKS je možné nainstalovat CNI jiné společnosti než Microsoft pomocí funkce Přineste si vlastní CNI .

Porovnání síťových modelů

Kubenet i Azure CNI poskytují síťové připojení pro clustery AKS. Existují však výhody a nevýhody pro každou z nich. Na vysoké úrovni platí následující aspekty:

• kubenet

  • Šetří adresní prostor IP adres.
  • Používá interní nebo externí nástroje pro vyrovnávání zatížení Kubernetes k přístupu k podům mimo cluster.
  • Trasy definované uživatelem můžete spravovat a udržovat ručně.
  • Maximálně 400 uzlů na cluster.

• Azure CNI

  • Pody získají úplné připojení k virtuální síti a můžou být přímo dostupné přes jejich privátní IP adresu z připojených sítí.
  • Vyžaduje více adresního prostoru IP adres.

Mezi kubenetem a Azure CNI existují následující rozdíly v chování:

Další informace o Azure CNI a kubenetu a pomoc s určením, která možnost je pro vás nejvhodnější, najdete v tématu Konfigurace sítí Azure CNI v AKS a použití sítí kubenet v AKS.

Podpora rozsahu mezi síťovými modely

Bez ohledu na síťový model, který používáte, můžete kubenet i Azure CNI nasadit jedním z následujících způsobů:

• Platforma Azure může při vytváření clusteru AKS automaticky vytvářet a konfigurovat prostředky virtuální sítě.
• Prostředky virtuální sítě můžete vytvořit a nakonfigurovat ručně a připojit se k těmto prostředkům při vytváření clusteru AKS.

Přestože se možnosti, jako jsou koncové body služby nebo trasy definované uživatelem, podporují kubenet i Azure CNI, zásady podpory pro AKS definují, jaké změny můžete provést. Příklad:

• Pokud ručně vytvoříte prostředky virtuální sítě pro cluster AKS, budete podporováni při konfiguraci vlastních trasy definované uživatelem nebo koncových bodů služby.
• Pokud platforma Azure automaticky vytvoří prostředky virtuální sítě pro váš cluster AKS, nemůžete tyto prostředky spravované službou AKS ručně změnit tak, aby nakonfigurovaly vlastní trasy definované uživatelem nebo koncové body služby.

Kontrolery příchozích dat

Při vytváření služby typu LoadBalancer vytvoříte také základní prostředek nástroje pro vyrovnávání zatížení Azure. Nástroj pro vyrovnávání zatížení je nakonfigurovaný tak, aby distribuoval provoz do podů ve vaší službě na daném portu.

LoadBalancer funguje jenom ve vrstvě 4. Ve vrstvě 4 služba neví o skutečných aplikacích a nemůže zvážit žádné další aspekty směrování.

Kontrolery příchozího přenosu dat fungují ve vrstvě 7 a můžou používat inteligentnější pravidla k distribuci provozu aplikací. Kontrolery příchozího přenosu dat obvykle směrují provoz HTTP do různých aplikací na základě příchozí adresy URL.

Porovnání možností příchozího přenosu dat

Následující tabulka uvádí rozdíly mezi různými možnostmi kontroleru příchozího přenosu dat:

Následující tabulka uvádí různé scénáře, ve kterých můžete použít každý kontroler příchozího přenosu dat:

Vytvoření prostředku příchozího přenosu dat

Doplněk směrování aplikací je doporučený způsob konfigurace kontroleru příchozího přenosu dat v AKS. Doplněk směrování aplikací je plně spravovaný kontroler příchozího přenosu dat pro Službu Azure Kubernetes Service (AKS), který poskytuje následující funkce:

• Snadná konfigurace spravovaných kontrolerů příchozího přenosu dat NGINX na základě kontroleru příchozího přenosu dat NGINX Kubernetes

• Integrace s Azure DNS pro správu veřejných a privátních zón

• Ukončení protokolu SSL s certifikáty uloženými ve službě Azure Key Vault

Další informace o doplňku směrování aplikace naleznete v tématu Spravované příchozí přenosy dat NGINX s doplňkem směrování aplikace.

Zachování zdrojových IP adres klienta

Nakonfigurujte kontroler příchozího přenosu dat tak, aby zachoval zdrojovou IP adresu klienta u požadavků na kontejnery v clusteru AKS. Když kontroler příchozího přenosu dat směruje požadavek klienta do kontejneru v clusteru AKS, původní zdrojová IP adresa tohoto požadavku není pro cílový kontejner dostupná. Když povolíte zachování zdrojové IP adresy klienta, zdrojová IP adresa pro klienta je k dispozici v hlavičce požadavku v části X-Forwarded-For.

Pokud na kontroleru příchozího přenosu dat používáte zachování zdrojových IP adres klienta, nemůžete použít předávací protokol TLS. Zachování zdrojových IP adres klienta a předávací protokol TLS lze použít s jinými službami, jako je typ LoadBalancer .

Další informace o zachování zdrojové IP adresy klienta najdete v tématu Jak funguje zachování ip adresy zdroje klienta pro služby LoadBalancer v AKS.

Řízení odchozího (výchozího) provozu

Clustery AKS se nasazují ve virtuální síti a mají odchozí závislosti na službách mimo danou virtuální síť. Tyto odchozí závislosti jsou téměř zcela definované plně s plně kvalifikovanými názvy domén (FQDN). Clustery AKS mají ve výchozím nastavení neomezený odchozí (výchozí) internetový přístup, který umožňuje uzlům a službám, které spustíte, přistupovat k externím prostředkům podle potřeby. V případě potřeby můžete omezit odchozí provoz.

Další informace najdete v tématu Řízení výchozího přenosu dat pro uzly clusteru v AKS.

Skupiny zabezpečení sítě

Skupina zabezpečení sítě filtruje provoz pro virtuální počítače, jako jsou uzly AKS. Při vytváření služeb, jako je například LoadBalancer, platforma Azure automaticky nakonfiguruje všechna potřebná pravidla skupiny zabezpečení sítě.

Pokud chcete filtrovat provoz podů v clusteru AKS, nemusíte konfigurovat pravidla skupiny zabezpečení sítě ručně. V manifestech služby Kubernetes Service můžete definovat všechny požadované porty a předávání a nechat platformu Azure vytvářet nebo aktualizovat příslušná pravidla.

S využitím zásad sítě také můžete zajistit automatické používání pravidel filtrování provozu na pody.

Další informace naleznete v tématu Jak skupiny zabezpečení sítě filtrují síťový provoz.

Zásady sítě

Ve výchozím nastavení můžou všechny pody v clusteru AKS odesílat a přijímat provoz bez omezení. Pro lepší zabezpečení definujte pravidla, která řídí tok provozu, například:

• Back-endové aplikace jsou vystavené pouze požadovaným front-endovým službám.
• Databázové komponenty jsou přístupné jenom pro aplikační vrstvy, které se k nim připojují.

Zásady sítě jsou funkce Kubernetes dostupná v AKS, která umožňuje řídit tok provozu mezi pody. Provoz do podu můžete povolit nebo zakázat na základě nastavení, jako jsou přiřazené popisky, obor názvů nebo port provozu. I když jsou skupiny zabezpečení sítě pro uzly AKS lepší, jsou zásady sítě vhodnějším cloudovým nativním způsobem, jak řídit tok provozu pro pody. Vzhledem k tomu, že se pody dynamicky vytvářejí v clusteru AKS, je možné automaticky použít požadované zásady sítě.

Další informace najdete v tématu Zabezpečení provozu mezi pody pomocí zásad sítě ve službě Azure Kubernetes Service (AKS).

Další kroky

Pokud chcete začít se sítěmi AKS, vytvořte a nakonfigurujte cluster AKS s vlastními rozsahy IP adres pomocí kubenetu nebo Azure CNI.

Přidružené osvědčené postupy najdete v tématu Osvědčené postupy pro připojení k síti a zabezpečení v AKS.

Další informace o základních konceptech Kubernetes a AKS najdete v následujících článcích:

• Clustery a úlohy Kubernetes / AKS
• Kubernetes / Přístup a identita AKS
• Zabezpečení Kubernetes / AKS
• Kubernetes / úložiště AKS
• Škálování Kubernetes / AKS