Síťové koncepty pro aplikace v Azure Kubernetes Service (AKS)

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

  • K aplikacím se můžete připojit a zpřístupnit je interně nebo externě.
  • Vysoce dostupné aplikace 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.
  • Pro složitější aplikace můžete nakonfigurovat příchozí přenos dat pro ukončení protokolu SSL/TLS nebo směrování více komponent.

Tento článek představuje základní koncepty, které poskytují sítě pro vaše aplikace v AKS:

Základy Kubernetes

Pokud chcete povolit přístup k aplikacím nebo mezi komponentami aplikací, poskytuje Kubernetes virtuálním sítím abstraktní vrstvu. Uzly Kubernetes se připojují k virtuální síti a poskytují příchozí a odchozí připojení pro pody. Komponenta kube-proxy běží na každém uzlu a poskytuje tyto síťové funkce.

V Kubernetes:

  • Služby logicky seskupují pody, aby umožňovaly přímý přístup k určitému portu prostřednictvím IP adresy nebo názvu DNS.
  • ServiceTypes umožňují určit, jaký druh služby chcete.
  • Provoz můžete distribuovat pomocí nástroje pro vyrovnávání zatížení.
  • Složitější směrování provozu aplikací je také možné dosáhnout pomocí kontrolerů příchozího přenosu dat.
  • Pro uzly clusteru můžete řídit odchozí (výchozí přenos dat).
  • Zabezpečení a filtrování síťového provozu pro pody je možné pomocí zásad sítě.

Platforma Azure také zjednodušuje virtuální sítě pro clustery AKS. Při vytváření nástroje pro vyrovnávání zatížení Kubernetes také vytvoříte a nakonfigurujete základní prostředek nástroje pro vyrovnávání zatížení Azure. Při otevírání síťových portů pro pody se konfigurují odpovídající pravidla skupiny zabezpečení sítě Azure. Pro směrování aplikací HTTP může Azure také nakonfigurovat externí DNS , protože jsou nakonfigurované nové trasy příchozího přenosu dat.

Služby

Aby se zjednodušila konfigurace sítě pro úlohy aplikací, Kubernetes používá služby k logickému seskupení sady podů a k zajištění síťového připojení. Zadáním typu Kubernetes ServiceType můžete určit požadovaný druh služby, například pokud chcete službu vystavit na externí IP adresu mimo váš cluster. Další informace najdete v dokumentaci Kubernetes ke službě Publishing Services (ServiceTypes).

K dispozici jsou následující typy servicetype:

  • ClusterIP

    ClusterIP vytvoří interní IP adresu pro použití v rámci clusteru AKS. Tato služba je vhodná pro interní aplikace , které podporují jiné úlohy v rámci clusteru. Toto je výchozí hodnota, která se použije, pokud pro službu explicitně nezadáte typ.

    Diagram znázorňující tok provozu ClusterIP v clusteru AKS

  • NodePort

    NodePort vytvoří mapování portů na podkladovém uzlu, které umožňuje přístup k aplikaci přímo pomocí IP adresy a portu uzlu.

    Diagram znázorňující tok provozu NodePort v clusteru AKS

  • LoadBalancer

    LoadBalancer vytvoří prostředek Nástroje pro vyrovnávání zatížení Azure, nakonfiguruje externí IP adresu a připojí požadované pody k back-endovému fondu nástroje pro vyrovnávání zatížení. Aby se provoz zákazníků dostal do aplikace, vytvoří se pravidla vyrovnávání zatížení na požadovaných portech.

    Diagram znázorňující Load Balancer tok provozu v clusteru AKS

    Pro další řízení a směrování příchozího provozu můžete místo toho použít kontroler příchozího přenosu dat.

  • ExternalName

    Vytvoří konkrétní položku DNS pro snadnější přístup k aplikacím.

IP adresu služeb a nástrojů pro vyrovnávání zatížení je možné přiřadit dynamicky, nebo můžete zadat existující statickou IP adresu. Můžete přiřadit interní i externí statické IP adresy. Existující statické IP adresy jsou často svázány s položkou DNS.

Můžete vytvořit interní i externí nástroje pro vyrovnávání zatížení. Interním nástrojům pro vyrovnávání zatížení je přiřazena pouze privátní IP adresa, takže k nim není možné přistupovat z internetu.

Další informace o službách najdete v dokumentaci k Kubernetes.

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ě CNI (Container Networking Interface) Azure Container Networking Interface

    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 vytváření clusteru AKS. Pomocí kubenetu:

  1. Uzly obdrží IP adresu z podsítě virtuální sítě Azure.
  2. Pody přijímají IP adresu z logicky odlišného adresního prostoru, než je 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. Můžete nechat platformu Azure, aby za vás vytvořila a nakonfiguruje virtuální sítě, nebo se rozhodnout 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é je potřeba rezervovat v síťovém prostoru pro použití podů.

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 předem naplánovány a jedinečné v rámci vašeho síťového prostoru. Každý uzel má konfigurační parametr pro maximální počet podů, které podporuje. Ekvivalentní počet IP adres na uzel je pak rezervován 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.

Na rozdíl od kubenetu provoz do koncových bodů ve stejné virtuální síti není překladem adres (NAT) na primární IP adresu uzlu. Zdrojová adresa pro provoz uvnitř virtuální sítě je IP adresa podu. Provoz, který je externí pro virtuální síť, se stále zobrazuje na primární IP adresu uzlu.

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

Diagram znázorňující dva uzly s mosty, které je vzájemně propojují s jednou virtuální sítí Azure

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

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

Kubenet i Azure CNI poskytují síťové připojení pro clustery AKS. Každý z nich má ale své výhody a nevýhody. Na základní ú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 z připojených sítí je možné k jejich privátní IP adrese přímo přistupovat.
    • Vyžaduje více adresního prostoru IP adres.

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

Schopnost Kubenet Azure CNI
Nasazení clusteru ve stávající nebo nové virtuální síti Podporované – ručně použité trasy definované uživatelem Podporováno
Připojení k podu Podporováno Podporováno
Připojení k pod-virtuálním počítačům; Virtuální počítač ve stejné virtuální síti Funguje, když ho inicializoval pod. Funguje oběma směry
Připojení k pod-virtuálním počítačům; Virtuální počítač v partnerské virtuální síti Funguje, když ho inicializoval pod. Funguje oběma směry
Místní přístup pomocí sítě VPN nebo ExpressRoute Funguje, když ho inicializoval pod. Funguje oběma směry
Přístup k prostředkům zabezpečeným koncovými body služby Podporováno Podporováno
Zveřejnění služeb Kubernetes pomocí služby nástroje pro vyrovnávání zatížení, služby App Gateway nebo kontroleru příchozího přenosu dat Podporováno Podporováno
Výchozí Azure DNS a privátní zóny Podporováno Podporováno
Podpora fondů uzlů Windows Nepodporuje se Podporováno

Pokud jde o DNS, s moduly plug-in Kubenet i Azure CNI nabízí DNS CoreDNS, což je nasazení spuštěné v AKS s vlastním automatickým škálováním. Další informace o CoreDNS v Kubernetes najdete v tématu Přizpůsobení služby DNS. Služba CoreDNS je ve výchozím nastavení nakonfigurovaná tak, aby přesměrovala neznámé domény do funkcí DNS azure Virtual Network, kde je cluster AKS nasazený. Proto budou azure DNS a privátní zóny fungovat pro pody spuštěné v AKS.

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ématech Konfigurace sítí Azure CNI v AKS a Použití sítí kubenet v AKS.

Obor podpory mezi síťovými modely

Bez ohledu na model sítě, který použijete, je možné nasadit kubenet i Azure CNI jedním z následujících způsobů:

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

I když jsou možnosti, jako jsou koncové body služby nebo trasy definované uživatelem podporované v kubenetu i v 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 tras definovaných 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é AKS ručně změnit a nakonfigurovat tak vlastní trasy definované uživatelem nebo koncové body služby.

Kontrolery příchozích dat

Když vytvoříte službu 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 pracují ve vrstvě 7 a můžou k distribuci provozu aplikací používat inteligentnější pravidla. Kontrolery příchozího přenosu dat obvykle směrují provoz HTTP do různých aplikací na základě příchozí adresy URL.

Diagram znázorňující tok příchozího provozu v clusteru AKS

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

V AKS můžete vytvořit prostředek příchozího přenosu dat pomocí NGINX, podobného nástroje nebo funkce směrování aplikací HTTP AKS. Když povolíte směrování aplikací HTTP pro cluster AKS, platforma Azure vytvoří kontroler příchozího přenosu dat a externí řadič DNS . Při vytváření nových prostředků příchozího přenosu dat v Kubernetes se požadované záznamy DNS A vytvoří v zóně DNS specifické pro cluster.

Další informace najdete v tématu Nasazení směrování aplikací HTTP.

Application Gateway kontroler příchozího přenosu dat (AGIC)

S doplňkem Application Gateway Kontroler příchozího přenosu dat (AGIC) můžete pomocí nativního nástroje pro vyrovnávání zatížení azure úrovně Application Gateway úrovně 7 zpřístupnit cloudový software na internetu. AGIC běží v clusteru AKS jako pod. Využívá prostředky příchozího přenosu dat Kubernetes a převede je na konfiguraci Application Gateway, která bráně umožňuje vyrovnávat zatížení provozu do podů Kubernetes.

Další informace o doplňku AGIC pro AKS najdete v tématu Co je Application Gateway kontroler příchozího přenosu dat?.

Ukončení protokolu SSL/TLS

Další běžnou funkcí příchozího přenosu dat je ukončení PROTOKOLU SSL/TLS. Ve velkých webových aplikacích, ke které se přistupuje přes HTTPS, zpracovává ukončení protokolu TLS prostředek příchozího přenosu dat, nikoli v rámci samotné aplikace. Pokud chcete zajistit automatické generování a konfiguraci certifikace TLS, můžete nakonfigurovat prostředek příchozího přenosu dat tak, aby používal zprostředkovatele, jako je "Let's Encrypt".

Další informace o konfiguraci kontroleru příchozího přenosu dat NGINX pomocí funkce Let's Encrypt najdete v tématu Příchozí přenos dat a protokol TLS.

Zachování IP adresy zdroje klienta

Nakonfigurujte kontroler příchozího přenosu dat tak, aby při požadavcích na kontejnery v clusteru AKS zachoval zdrojovou IP adresu klienta. 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í IP adresy zdroje klienta, zdrojová IP adresa klienta bude 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í IP adresy zdroje klienta, nemůžete použít předávací protokol TLS. Uchování IP adresy zdroje klienta a předávání PROTOKOLU TLS je možné použít s jinými službami, jako je typ LoadBalancer .

Další informace o zachování IP adresy zdroje klienta najdete v tématu Jak funguje uchovávání IP adres 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 tuto virtuální síť. Tyto odchozí závislosti jsou téměř zcela definovány pomocí plně kvalifikovaných názvů domén (FQDN). Ve výchozím nastavení mají clustery AKS neomezený odchozí (výchozí) internetový přístup, což umožňuje uzlům a službám, které spouštíte, přístup 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 loadBalancer, platforma Azure automaticky konfiguruje 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 rámci manifestů 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 najdete 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 zpřístupněny jenom 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 přenosový port. I když jsou skupiny zabezpečení sítě pro uzly AKS lepší, zásady sítě jsou vhodnějším nativním způsobem řízení toku provozu pro pody. Při dynamickém vytváření podů 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ě v Azure Kubernetes Service (AKS).

Další kroky

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

Související 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: