Sdílet prostřednictvím


Překryvné sítě rozhraní CNI (Azure Container Networking Interface)

V případě překrytí Azure CNI se uzly clusteru nasadí do podsítě virtuální sítě Azure. Pody se přiřazují IP adresy z privátní ciDR logicky odlišné od virtuální sítě hostující uzly. Provoz podů a uzlů v rámci clusteru používá překryvnou síť. Překlad síťových adres (NAT) používá IP adresu uzlu pro přístup k prostředkům mimo cluster. Toto řešení šetří značné množství IP adres virtuální sítě a umožňuje škálovat cluster na velké velikosti. Výhodou je, že privátní CIDR můžete znovu použít v různých clusterech AKS, což rozšiřuje prostor IP adres dostupný pro kontejnerizované aplikace ve službě Azure Kubernetes Service (AKS).

Přehled překryvných sítí

V překryvných sítích se z podsítí přiřazují pouze uzly clusteru Kubernetes. Pody přijímají IP adresy z privátního CIDR poskytovaného při vytváření clusteru. Každému /24 uzlu je přiřazen adresní prostor vyřezaný ze stejného CIDR. Další uzly vytvořené při horizontálním navýšení kapacity clusteru automaticky přijímají /24 adresní prostory ze stejného CIDR. Azure CNI přiřadí IP adresy podům z tohoto /24 prostoru.

V zásobníku sítí Azure pro privátní prostor CIDR podu se vytvoří samostatná doména směrování, která vytvoří překryvnou síť pro přímou komunikaci mezi pody. Není nutné zřizovat vlastní trasy v podsíti clusteru nebo použít metodu zapouzdření pro tunelování provozu mezi pody, což zajišťuje výkon připojení mezi pody na úrovni parny virtuálních počítačů ve virtuální síti. Úlohy spuštěné v podech si ani neuvědomují, že probíhá manipulace se síťovými adresami.

Diagram znázorňující dva uzly se třemi pody spuštěnými v překryvné síti Provoz podů do koncových bodů mimo cluster se směruje přes překlad adres (NAT).

Komunikace s koncovými body mimo cluster, jako jsou místní a partnerské virtuální sítě, probíhá pomocí IP adresy uzlu prostřednictvím překladu adres (NAT). Azure CNI přeloží zdrojovou IP adresu (překryvnou IP adresu podu) provozu na primární IP adresu virtuálního počítače, která umožňuje zásobník sítí Azure směrovat provoz do cíle. Koncové body mimo cluster se nemůžou připojit přímo k podu. Aplikaci podu musíte publikovat jako službu Kubernetes Load Balancer, aby byla dostupná ve virtuální síti.

Odchozí (výchozí) připojení k internetu můžete poskytnout pro překryvné pody pomocí Load Balanceru úrovně Standard nebo spravované služby NAT Gateway. Odchozí provoz můžete řídit také tak, že ho přesměrujete na bránu firewall pomocí tras definovaných uživatelem v podsíti clusteru.

Připojení příchozího přenosu dat ke clusteru můžete nakonfigurovat pomocí kontroleru příchozího přenosu dat, jako je Nginx nebo směrování aplikace HTTP. Připojení příchozího přenosu dat nejde nakonfigurovat pomocí brány Aplikace Azure. Podrobnosti najdete v tématu Omezení překrytí Azure CNI.

Rozdíly mezi překrytí kubenetu a Azure CNI

Následující tabulka obsahuje podrobné porovnání mezi překrytí kubenet a Azure CNI:

Plocha Azure CNI Overlay kubenet
Škálování clusteru 5000 uzlů a 250 podů/uzlů 400 uzlů a 250 podů/uzlů
Konfigurace sítě Jednoduché – pro sítě podů se nevyžadují žádné další konfigurace. Složité – vyžaduje směrovací tabulky a trasy definované uživatelem v podsíti clusteru pro sítě podů.
Výkon připojení podů Výkon při analýze s virtuálními počítači ve virtuální síti Další segment směrování přidává menší latenci
Zásady sítě Kubernetes Zásady sítě Azure, Calico, Cilium Kaliko
Podporované platformy operačního systému Linux a Windows Server 2022, 2019 Jenom Linux

Plánování IP adres

Uzly clusteru

Při nastavování clusteru AKS se ujistěte, že vaše podsítě virtuální sítě mají dostatek místa pro budoucí škálování. Každý fond uzlů můžete přiřadit k vyhrazené podsíti.

Podsíť /24 může obsahovat až 251 uzlů, protože první tři IP adresy jsou vyhrazené pro úlohy správy.

Pody

Řešení překrytí /24 přiřadí adresní prostor pro pody na každém uzlu z privátního CIDR, který zadáte při vytváření clusteru. Velikost /24 je pevná a nedá se zvětšit ani zmenšit. Na uzlu můžete spustit až 250 podů.

Při plánování adresního prostoru IP adres pro pody zvažte následující faktory:

  • Ujistěte se, že privátní CIDR je dostatečně velký, aby poskytoval /24 adresní prostory pro nové uzly, aby podporovaly budoucí rozšíření clusteru.
  • Stejný prostor CIDR podu lze použít na několika nezávislých clusterech AKS ve stejné virtuální síti.
  • Prostor CIDR podů se nesmí překrývat s rozsahem podsítě clusteru.
  • Prostor CIDR podu se nesmí překrývat s přímo připojenými sítěmi (jako je partnerský vztah virtuálních sítí, ExpressRoute nebo VPN). Pokud externí provoz obsahuje zdrojové IP adresy v rozsahu podCIDR, potřebuje překlad na nepřekrývající se IP adresu přes SNAT pro komunikaci s clusterem.

Rozsah adres služby Kubernetes Service

Velikost adresy služby CIDR závisí na počtu služeb clusteru, které plánujete vytvořit. Musí být menší než /12. Tento rozsah by se neměl překrývat s rozsahem CIDR podsítě, rozsahem podsítí clusteru a rozsahem IP adres používanými v partnerských virtuálních sítích a místních sítích.

IP adresa služby DNS Kubernetes

Tato IP adresa se nachází v rozsahu adres služby Kubernetes používaném zjišťováním služby clusteru. Nepoužívejte první IP adresu v rozsahu adres, protože tato adresa se používá pro kubernetes.default.svc.cluster.local tuto adresu.

Skupiny zabezpečení sítě

Provoz pod-to-pod s využitím překrytí Azure CNI není zapouzdřený a použijí se pravidla skupiny zabezpečení sítě podsítě. Pokud skupina zabezpečení sítě podsítě obsahuje pravidla zamítnutí, která by ovlivnila provoz CIDR podů, ujistěte se, že jsou splněna následující pravidla pro zajištění správné funkčnosti clusteru (kromě všech požadavků na výchozí přenos dat AKS):

  • Provoz z uzlu CIDR do uzlu CIDR na všech portech a protokolech
  • Provoz z uzlu CIDR do podu CIDR na všech portech a protokolech (vyžadovaných pro směrování provozu služby)
  • Provoz z CIDR podu do CIDR podu na všech portech a protokolech (vyžadovaných pro provoz podů a podů do provozu, včetně DNS)

Provoz z podu do libovolného cíle mimo blok CIDR podu využívá SNAT k nastavení zdrojové IP adresy na IP adresu uzlu, na kterém se pod spouští.

Pokud chcete omezit provoz mezi úlohami v clusteru, doporučujeme použít zásady sítě.

Maximální počet podů na uzel

Maximální počet podů na uzel můžete nakonfigurovat při vytváření clusteru nebo při přidání nového fondu uzlů. Výchozí a maximální hodnota překrytí Azure CNI je 250 a minimální hodnota je 10. Maximální počet podů na hodnotu uzlu nakonfigurovanou při vytváření fondu uzlů se vztahuje pouze na uzly v daném fondu uzlů.

Volba síťového modelu, který se má použít

Azure CNI nabízí dvě možnosti přidělování IP adres pro pody: tradiční konfigurace, která přiřazuje IP adresy virtuálních sítí podům a překryvné sítě. Volba, kterou možnost použít pro cluster AKS, je vyvážená mezi flexibilitou a pokročilými potřebami konfigurace. Následující aspekty vám pomůžou zjistit, kdy může být každý síťový model nejvhodnější.

Použití překryvných sítí v případech:

  • Chcete škálovat na velký počet podů, ale ve virtuální síti máte omezený adresní prostor IP adres.
  • Většina komunikace podů je v clusteru.
  • Nepotřebujete pokročilé funkce AKS, jako jsou virtuální uzly.

Tradiční možnost virtuální sítě použijte v následujících případech:

  • Máte k dispozici adresní prostor IP adres.
  • Většina komunikace podů je s prostředky mimo cluster.
  • Prostředky mimo cluster se musí spojit přímo s pody.
  • Potřebujete pokročilé funkce AKS, jako jsou virtuální uzly.

Omezení překrytí Azure CNI

Azure CNI Overlay má následující omezení:

  • Application Gateway nemůžete použít jako kontroler příchozího přenosu dat (AGIC).
  • Skupiny dostupnosti virtuálních počítačů (VMAS) se nepodporují.
  • Virtuální počítače řady DCsv2 nemůžete používat ve fondech uzlů. Pokud chcete splnit požadavky důvěrného computingu, zvažte místo toho použití důvěrných virtuálních počítačů řady DCasv5 nebo DCadsv5.
  • Pokud k nasazení clusteru používáte vlastní podsíť, musí názvy podsítě, virtuální sítě a skupiny prostředků obsahující virtuální síť obsahovat 63 znaků nebo méně. Tyto názvy se použijí jako popisky v pracovních uzlech AKS a podléhají pravidlům syntaxe popisků Kubernetes.