Osvědčené postupy pro připojení k síti a zabezpečení v Azure Kubernetes Service (AKS)

Důležité

Dne 31. března 2028 bude síť kubenet pro Azure Kubernetes Service (AKS) vyřazena.

Aby nedocházelo k přerušení služeb, budete musetaktualizovat na překrytí rozhraní Azure Container Networking Interface (CNI)před tímto datem, kdy už nebudou podporovány úlohy spuštěné na kubenetu pro AKS.

Při vytváření a správě clusterů v Azure Kubernetes Service (AKS) poskytujete síťové připojení pro uzly a aplikace. Mezi tyto síťové prostředky patří rozsahy IP adres, nástroje pro vyrovnávání zatížení a kontrolery příchozího přenosu dat.

Tento článek s osvědčenými postupy se zaměřuje na síťové připojení a zabezpečení pro operátory clusteru. V tomto článku se naučíte:

• Vysvětlete režim síťového rozhraní CNI (Container Networking Interface) v AKS.
• Naplánujte požadované adresování IP a připojení.
• Distribuujte provoz pomocí nástrojů pro vyrovnávání zatížení, kontrolerů příchozího přenosu dat nebo firewallu webových aplikací (WAF).
• Bezpečně se připojte k uzlům clusteru.

Volba vhodného síťového modelu

Pokyny k osvědčeným postupům

Pro většinu scénářů používejte Azure CNI Overlay. Pokud úlohy vyžadují přímý přístup k IP adresám podů z připojených sítí, použijte plochou síť s podsítí podů Azure CNI.

Virtuální sítě poskytují základní připojení pro uzly AKS a zákazníky pro přístup k vašim aplikacím. Clustery AKS můžete nasadit do virtuálních sítí dvěma různými způsoby:

• Překryvná síť: Azure CNI Overlay přiřazuje IP adresy podům z odděleného rozsahu CIDR pro pody. Provoz, který opouští cluster, je přeložen na IP adresu uzlu a pody nejsou z připojených sítí přímo přístupné prostřednictvím svých privátních IP adres.
• Plochá síť: Azure CNI Pod Subnet nebo starší Azure CNI Node Subnet přiděluje podům IP adresy z prostoru virtuální sítě. Pody můžou být dosažitelné svými privátními IP adresami z připojených sítí.

Další informace o výběru síťového modelu najdete v tématu Plánování sítí podů pro AKS.

Přehled sítí CNI Azure

Azure CNI poskytuje správu IP adres (IPAM) a možnosti připojení pro pody a uzly. Možnost IPAM je oddělená od roviny dat sítě. Můžete například použít Azure CNI využívající Cilium s možností Azure CNI Overlay nebo s možností ploché sítě.

Následující diagram znázorňuje dva uzly AKS, z nichž každý je připojený přes síťový most ke sdílené Azure virtuální síti.

Azure sítí CNI umožňuje oddělení kontroly a správy prostředků. Z hlediska zabezpečení často chcete, aby tyto prostředky spravovály a zabezpečily různé týmy. Charakteristiky připojení závisí na síťovém modelu. Pody v překryvné síti navazují spojení k virtuální síti a místním prostředkům prostřednictvím IP adresy uzlu. Pody s plochou sítí můžou komunikovat přímo s připojenými prostředky prostřednictvím svých privátních IP adres.

Pokud používáte síť Azure CNI, virtuální síťový prostředek je v samostatné skupině prostředků pro AKS cluster. Delegujte oprávnění pro identitu clusteru AKS pro přístup k těmto prostředkům a jejich správě. Identita, kterou používá cluster AKS, musí mít v podsíti ve vaší virtuální síti alespoň oprávnění Přispěvatel sítě.

Pokud chcete místo předdefinované role Přispěvatel sítě definovat vlastní roli , musíte mít následující oprávnění:

Povolení	Description
Microsoft.Network/virtualNetworks/subnets/join/action	Připojí prostředky clusteru AKS k podsíti virtuální sítě.
Microsoft.Authorization/roleAssignments/write	Vytvoří požadovaná přiřazení rolí.
Microsoft.Network/virtualNetworks/subnets/read	Načte konfiguraci podsítě, když definujete vlastní podsítě a identifikátoryCIDR.

Ve výchozím nastavení používá AKS spravovanou identitu pro svou identitu clusteru. Místo toho ale můžete použít služební účet.

• Další informace o delegování oprávnění objektu AKS najdete v tématu Delegovat přístup k dalším prostředkům Azure.
• Další informace o spravovaných identitách najdete v tématu Použití spravovaných identit.

Naplánujte rozsahy adres na základě síťového modelu. Mějte na paměti následující kritéria:

• S Azure CNI Overlay dimenzujte podsíť uzlů pro uzly a pro pody použijte samostatný privátní rozsah CIDR. Každý uzel obdrží adresní /24 prostor z CIDR podu.
• U ploché sítě zvětšte podsítě virtuální sítě pro uzly i pody. Azure CNI Pod Subnet používá samostatné podsítě pro uzly a pody, zatímco původní Azure CNI Node Subnet používá jednu podsíť pro obojí.
• Nepoužívejte rozsahy IP adres, které se překrývají s existujícími síťovými prostředky.
  • Je nutné povolit připojení k místním nebo partnerským sítím v Azure.
• Pokud chcete zpracovávat události horizontálního navýšení kapacity nebo upgrady clusteru, potřebujete další IP adresy dostupné v přiřazené podsíti.
  • Tento dodatečný adresní prostor je zvlášť důležitý, pokud používáte kontejnery Windows Server, protože fondy uzlů vyžadují upgrade, aby se použily nejnovější opravy zabezpečení. Další informace o uzlech Windows Server najdete v tématu Upgrade fondu uzlů v AKS.

Pokud chcete vypočítat požadovaný adresní prostor IP adres, přečtěte si téma Plánování IP adres pro clustery AKS.

Při vytváření clusteru s Azure sítěmi CNI zadáte další rozsahy adres pro cluster, například IP adresu služby DNS a rozsah adres služby. Obecně platí, že se tyto rozsahy adres navzájem nepřekrývají ani žádné sítě přidružené ke clusteru, včetně všech virtuálních sítí, podsítí, místních sítí a partnerských sítí.

Podrobnosti o síťových modelech, omezeních a velikosti adres najdete v článku Přehled sítí Azure CNI.

Distribuce příchozího přenosu dat

Pokyny k osvědčeným postupům

Pokud chcete distribuovat provoz HTTP nebo HTTPS do vašich aplikací, použijte prostředky a kontrolery příchozího přenosu dat. V porovnání s nástrojem pro vyrovnávání zatížení Azure poskytují kontrolery příchozího přenosu dat další funkce a dají se spravovat jako nativní prostředky Kubernetes.

I když Azure load balancer může distribuovat zákaznický provoz do aplikací v clusteru AKS, má omezené schopnosti porozumět tomuto provozu. Prostředek pro vyrovnávání zatížení funguje ve vrstvě 4 a distribuuje provoz na základě protokolu nebo portů.

Většina webových aplikací využívajících PROTOKOL HTTP nebo HTTPS by měla používat prostředky a kontrolery příchozího přenosu dat Kubernetes, které fungují ve vrstvě 7. Ingress může distribuovat provoz na základě adresy URL aplikace a postarat se o ukončení šifrování TLS/SSL. Příchozí přenos dat také snižuje počet IP adres, které zveřejňujete a mapujete.

S nástrojem pro vyrovnávání zatížení každá aplikace obvykle potřebuje přiřazenou veřejnou IP adresu a namapovanou na službu v clusteru AKS. Pomocí ingresního prostředku může jedna IP adresa distribuovat provoz do více aplikací.

Diagram znázorňuje jednu veřejnou IP adresu, která přijímá externí provoz a kontroler příchozího přenosu dat distribuuje tento provoz do více služeb v clusteru AKS.

Ingress má dvě komponenty: prostředek Ingress a řadič Ingress.

Prostředek Ingress

Prostředek ingress je YAML manifestemkind: Ingress. Definuje hostitele, certifikáty a pravidla pro směrování provozu do služeb spuštěných v clusteru AKS.

Následující ukázkový manifest YAML používá spravovanou třídu Ingress NGINX doplňku pro směrování aplikací. Distribuuje provoz pro myapp.com do jedné ze dvou služeb, blogservice nebo storeservice a přesměruje zákazníka na jednu službu nebo druhou na základě adresy URL, ke které přistupuje.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Pole ingressClassName vybere třídu příchozího přenosu dat a musí odpovídat třídě nakonfigurované na kontroleru příchozího přenosu dat v clusteru. Tato hodnota webapprouting.kubernetes.azure.com vybere spravovaný kontroler příchozího přenosu dat NGINX poskytovaný doplňkem směrování aplikace. Pokud používáte jinou implementaci, nahraďte ho názvem třídy kontroleru příchozího přenosu dat.

Ingress kontroler

Kontroler příchozího přenosu dat hostovaný clusterem běží jako úloha na uzlu AKS a sleduje příchozí požadavky. Příchozí provoz se pak distribuuje na základě pravidel definovaných v prostředku příchozího přenosu dat přidruženého k danému kontroleru. Zatímco nejběžnější kontroler příchozího přenosu dat je založený na NGINX, AKS vás neomezuje na konkrétní kontroler. Můžete použít Application Gateway for Containers, Contour, HAProxy, Traefik a další.

Na uzlu Linuxu musíte naplánovat kontrolery příchozího přenosu dat hostované v clusteru. Uveďte, že by prostředek měl běžet na uzlu se systémem Linux pomocí selektoru uzlu v manifestu YAML nebo při nasazení chartu Helm. Další informace naleznete v článku Použití selektorů uzlů k řízení, kde jsou pody plánovány v AKS.

Ingress s doplňkem pro směrování aplikací

Doplněk pro směrování aplikací poskytuje spravované implementace Ingressu pro AKS. V případě nových dlouhodobých nasazení použijte implementaci rozhraní API služby Application Routing Gateway, pokud podporuje vaše požadavky. Gateway API je dlouhodobým standardem pro Kubernetes ingress a správu provozu na 7. vrstvě.

Upozornění

Údržba Upstream Ingress NGINX končí v březnu 2026. Microsoft poskytuje podporu kritických bezpečnostních oprav pro prostředky NGINX Ingress doplňku pro směrování aplikací až do listopadu 2026. Pokud používáte spravovanou implementaci NGINX, naplánujte migraci na implementaci rozhraní API služby Application Routing Gateway nebo jinou podporovanou implementaci do listopadu 2026.

Spravovaná implementace NGINX poskytuje následující funkce:

• Snadná konfigurace spravovaných NGINX Ingress řadičů na základě Kubernetes NGINX Ingress řadiče.
• 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 v Azure Key Vault

Další informace najdete v tématu Konfigurace příchozího přenosu dat pomocí rozhraní API služby Application Routing Gateway a spravovaného příchozího přenosu dat NGINX pomocí doplňku směrování aplikace.

Zabezpečení provozu pomocí firewallu webových aplikací (WAF)

Pokyny k osvědčeným postupům

Pokud chcete zkontrolovat potenciální útoky příchozího provozu, použijte firewall webových aplikací (WAF), jako je Barracuda WAF, pro Azure nebo Azure Web Application Firewall ve službě Application Gateway pro kontejnery. Application Gateway pro kontejnery směruje provoz HTTP, HTTPS, gRPC, WebSocket a pro inferenci AI a podporuje ukončení TLS.

Kontroler příchozího provozu hostovaný v clusteru je ve vašem clusteru AKS spuštěn jako úloha Kubernetes a směruje provoz ke službám a aplikacím. Využívá některé prostředky uzlu, jako je procesor, paměť a šířka pásma sítě. Ve větších prostředích můžete zvážit následující:

• Předejte část tohoto směrování provozu nebo ukončení protokolu TLS na síťový prostředek mimo cluster AKS.
• Zkontrolujte příchozí provoz kvůli potenciálním útokům.

Diagram znázorňuje externí provoz procházející Azure Application Gateway pro kontejnery. Když je nakonfigurovaná ochrana WAF, pravidla WAF filtrují požadavky předtím, než služba Application Gateway for Containers přesměruje povolený provoz do služeb v clusteru AKS.

Pro tu další vrstvu zabezpečení filtruje firewall webových aplikací (WAF) příchozí provoz. Spravovaná a vlastní pravidla chrání před útoky, jako je skriptování mezi weby a injektáž SQL. Application Gateway for Containers je služba vyrovnávání zatížení vrstvy 7 a služba pro správu provozu, která podporuje Azure WAF.

Ochrana WAF není povolená nasazením služby Application Gateway pro kontejnery. Musíte vytvořit zásadu WAF a dokončit obě následující konfigurace, než začne WAF kontrolovat provoz:

• Vytvořte podřízený prostředek Azure SecurityPolicy, který odkazuje na zásadu WAF.
• Použijte vlastní prostředek Kubernetes WebApplicationFirewallPolicy, který odkazuje na stejnou zásadu WAF a cílí na prostředek Gateway nebo HTTPRoute, který chcete chránit.

Po dokončení obou konfigurací ověřte stav vlastního zdroje a protokoly WAF, než se na tuto zásadu začnete spoléhat jako na ochranu. Další informace najdete v tématu Azure Web Application Firewall ve službě Application Gateway pro kontejnery.

Vzhledem k tomu, že tyto funkce provádějí i jiná řešení třetích stran, můžete i nadále využívat stávající investice nebo odborné znalosti vašeho preferovaného produktu.

Nástroj pro vyrovnávání zatížení nebo vstupní prostředky neustále běží v clusteru AKS a optimalizují rozdělení provozu. Azure Application Gateway pro kontejnery je možné centrálně spravovat jako kontroler příchozího přenosu dat s definicí prostředku. Začněte tím, že vytvoříte službu Application Gateway pro kontejnery a pak nakonfigurujete ochranu WAF samostatně.

Řízení toku provozu pomocí zásad sítě

Pokyny k osvědčeným postupům

Pomocí zásad sítě povolte nebo zamítněte provoz do podů. Ve výchozím nastavení je veškerý provoz mezi pody v clusteru povolený. Pro lepší zabezpečení definujte pravidla, která omezují komunikaci mezi kontejnery.

Zásady sítě jsou funkce Kubernetes dostupná v AKS, která umožňuje řídit tok provozu mezi pody. Povolíte nebo zakážete provoz do podu na základě nastavení, jako jsou přiřazené popisky, obor názvů nebo síťový port. Zásady sítě představují nativní způsob, jak řídit tok provozu podů. Vzhledem k tomu, že se pody dynamicky vytvářejí v clusteru AKS, je možné automaticky použít požadované zásady sítě.

Pokud chcete použít zásady sítě v AKS, vyberte modul zásad sítě, který podporuje operační systémy uzlů a rovinu síťových dat. Modul zásad můžete povolit při vytváření clusteru nebo v existujícím podporovaném clusteru.

Pro uzlové fondy se systémem Linux použijte Azure CNI s podporou Cilium a jeho integrované vynucování zásad sítě Cilium. Cilium není podporováno pro fondy uzlů Windows. Pro Windows úlohy použijte Calico.

Důležité

Azure podpora NPM (Network Policy Manager) pro uzly Windows končí 30. září 2026 a nová předplatná už ji nemůžou povolit. Azure podpora NPM pro uzly s Linuxem končí 30. září 2028. Migrace linuxových clusterů z NPM na Cilium před datem ukončení podpory

Zásady sítě vytvoříte pomocí manifestu YAML jako prostředek Kubernetes. Zásady se použijí na definované pody s příchozím nebo výstupním pravidlem definujícím tok provozu.

Následující příklad aplikuje síťovou politiku na pody s popiskem app: backend. Pravidlo příchozího provozu povoluje provoz jenom z podů s app: frontend štítkem.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Pokud chcete začít se zásadami, přečtěte si téma Secure traffic between pods using network policies in Azure Kubernetes Service (AKS).

Optimalizace překladu DNS pomocí LocalDNS

Pokyny k osvědčeným postupům

Pomocí LocalDNS můžete zlepšit výkon a spolehlivost DNS a snížit zatížení centralizovaných podů CoreDNS. LocalDNS je předkonfigurovaný v AKS Automatic. Ve službě AKS Standard povolte a nakonfigurujte LocalDNS na fond uzlů.

LocalDNS nasazuje DNS proxy server jako službu systemd na každém uzlu, který lokálně zpracovává DNS dotazy. Ve výchozím nastavení pody odesílají všechny dotazy DNS do centralizovaných podů CoreDNS. Ve velkém měřítku může centralizace těchto dotazů vytvořit úzké hrdlo, zatímco lokální vyhodnocování snižuje počet síťových skoků a latenci.

LocalDNS také eliminuje conntrack položky tabulky pro provoz DNS, což brání conntrack vyčerpání tabulek a souběhovým podmínkám, které mohou způsobit přerušená připojení. Připojení z místní mezipaměti k CoreDNS se upgradují na PROTOKOL TCP, což umožňuje vyrovnávání připojení a rychlejší vyčištění položek sledování.

U úloh, které vyžadují vysokou dostupnost DNS, localDNS podporuje obsluhu zastaralých odpovědí uložených v mezipaměti po konfigurovatelnou dobu, když nadřazený server DNS není k dispozici. Tato funkce typu best-effort může pomoci zachovat konektivitu podů a spolehlivost služeb během přechodných výpadků DNS, ale nezaručuje, že bude zastaralý záznam k dispozici.

V AKS Standard povolení LocalDNS u existujícího fondu uzlů přeinstaluje jeho uzly. Naplánujte zavedení tak, aby toto přerušení zohlednilo.

Další informace o architektuře a možnostech LocalDNS najdete v tématu Překlad DNS v AKS. Pokyny ke konfiguraci najdete v tématu Konfigurace localDNS.

Bezpečné připojení k uzlům

Pokyny k osvědčeným postupům

Nezpřístupňujte vzdálené připojení k uzlům AKS. Pro běžné řešení potíží s linuxovými uzly použijte kubectl debug rozhraní Kubernetes API. Pokud potřebujete přístup SSH, připojte se přes privátní sítě nebo Azure Bastion.

Většinu operací v AKS můžete dokončit pomocí nástrojů pro správu Azure nebo serveru rozhraní API Kubernetes. Uzly AKS jsou dostupné jenom v privátní síti a nejsou připojené k veřejnému internetu. Pro uzly s Linuxem použijte kubectl debug ke spuštění kontejneru privilegovaného ladění prostřednictvím rozhraní API Kubernetes. Tento přístup nevyžaduje přímé připojení SSH k uzlu.

Pokud přístup k rozhraní API Kubernetes není vhodný nebo vyžadujete SSH, použijte privátní IP adresu uzlu z připojené sítě. Azure Bastion může poskytovat privátní připojení bez vystavení veřejné IP adresy na uzlu. Pro Windows uzly použijte kontejner procesu hostitele nebo se připojte prostřednictvím uzlu proxy systému Linux. Azure Bastion je alternativou, pokud není k dispozici uzel proxy serveru. Další informace najdete v tématu Připojení k uzlům clusteru AKS pro účely údržby nebo řešení potíží.

Diagram znázorňuje virtuální síť pro správu obsahující hostitele služby Bastion, který směruje připojení přes zabezpečené partnerské propojení do virtuální sítě clusteru AKS.

Pokud používáte hostitele bastionu nebo jump box, umístěte ho do samostatné zabezpečené partnerské virtuální sítě pro správu. Zabezpečte síť pro správu pomocí Azure ExpressRoute nebo brány VPN pro připojení k místní síti a řízení přístupu pomocí skupin zabezpečení sítě.

Další kroky

Tento článek se zaměřuje na síťové připojení a zabezpečení. Další informace o základech sítě v Kubernetes najdete v tématu Koncepty sítí pro aplikace v Azure Kubernetes Service (AKS)