Nätverkstopologi och anslutningsöverväganden för AKS

Utformningsbeaktanden

Azure Kubernetes Service (AKS) tillhandahåller tre olika nätverksmodeller för containernätverk: Kubenet, CNI Overlay och CNI. Var och en av dessa modeller har sin unika uppsättning funktioner och fördelar, vilket ger flexibilitet och skalbarhetsalternativ för containernätverk i AKS.

Kubenet

Kubenet är en grundläggande nätverkslösning som sparar IP-adressutrymme och erbjuder enkel konfiguration. Det är idealiskt för små AKS-kluster med färre än 400 noder, där manuellt hantera och underhålla användardefinierade vägar är acceptabelt. Den är lämplig för scenarier där interna eller externa lastbalanserare räcker för att nå poddar utanför klustret.

Azure CNI

Azure CNI är en nätverksmodell som är utformad för avancerade nätverk. Det ger fullständig anslutning till virtuella nätverk för poddar, vilket möjliggör podd-till-podd- och podd-till-VM-anslutning. Det är idealiskt för scenarier där avancerade AKS-funktioner, till exempel virtuella noder, krävs. Det är lämpligt för scenarier där tillräckligt med IP-adressutrymme är tillgängligt och externa resurser måste nå poddar direkt. AKS-nätverksprinciper stöds också med Azure CNI.

Azure CNI-överlägg

Azure CNI Overlay är utformat för att åtgärda brist på IP-adresser och förenkla nätverkskonfigurationen. Det är lämpligt för scenarier där det räcker att skala upp till 1 000 noder och 250 poddar per nod, och ytterligare ett hopp för poddanslutning är acceptabelt. KRAV för UTGÅENDE AKS kan också uppfyllas med Azure CNI-överlägg.

En sammanfattning av rekommenderade användningsfall per nätverksmodell finns i Jämför nätverksmodeller i AKS.

När du utformar ditt AKS-kluster är det dessutom viktigt att noggrant planera IP-adressering och storleken på det virtuella nätverksundernätet för att stödja skalning. Virtuella noder kan användas för snabb klusterskalning, men det finns några kända begränsningar.

AKS-kluster stöder SKU:er för Basic och Standard Azure Load Balancer, och tjänster kan exponeras med offentliga eller interna lastbalanserare. AKS använder CoreDNS för att ge namnmatchning till poddar som körs i klustret, och utgående nätverkstrafik (utgående) kan skickas via ett virtuellt Azure-brandväggs- eller nätverksinstallationskluster.

Som standard kan alla poddar i ett AKS-kluster skicka och ta emot trafik utan begränsningar. Kubernetes-nätverksprinciper kan dock användas för att förbättra säkerheten och filtrera nätverkstrafik mellan poddar i ett AKS-kluster. Två nätverksprincipmodeller är tillgängliga för AKS: Azure-nätverksprinciper och Calico.

Slutligen konfigurerar AKS en nätverkssäkerhetsgrupp (NSG) i det undernät där klustret distribueras. Vi rekommenderar att du inte redigerar den här nätverkssäkerhetsgruppen manuellt, men tjänster som distribueras i AKS kan påverka den.

Genom att välja lämplig nätverksmodell och noggrant planera nätverksresurser kan du optimera prestanda, säkerhet och kostnad för ditt AKS-kluster.

Privata kluster

AKS-klustrets IP-synlighet kan vara antingen offentlig eller privat. Privata kluster exponerar Kubernetes API över en privat IP-adress, men inte över en offentlig. Den här privata IP-adressen representeras i det virtuella AKS-nätverket via en privat slutpunkt. Kubernetes-API:et ska inte nås via dess IP-adress, utan i stället via dess fullständigt kvalificerade domännamn (FQDN). Upplösningen från Kubernetes API FQDN till dess IP-adress utförs vanligtvis av en Azure Privat DNS-zon. Den här DNS-zonen kan skapas av Azure i resursgruppen AKS-nod, eller så kan du ange en befintlig DNS-zon.

Enligt beprövade metoder i företagsskala erbjuds DNS-matchning för Azure-arbetsbelastningar av centraliserade DNS-servrar som distribueras i anslutningsprenumerationen, antingen i ett virtuellt hubbnätverk eller i ett virtuellt nätverk med delade tjänster som är anslutet till ett Azure Virtual WAN. Dessa servrar löser villkorligt Azure-specifika och offentliga namn med hjälp av Azure DNS (IP-adress 168.63.129.16) och privata namn med företagets DNS-servrar. Dessa centraliserade DNS-servrar kan dock inte matcha AKS API FQDN förrän de är anslutna till den privata DNS-zon som skapats för AKS-klustret. Varje AKS har en unik privat DNS-zon eftersom ett slumpmässigt GUID läggs till i zonnamnet. För varje nytt AKS-kluster bör därför motsvarande privata DNS-zon anslutas till det virtuella nätverk där de centrala DNS-servrarna finns.

Alla virtuella nätverk ska konfigureras för att använda dessa centrala DNS-servrar för namnmatchning. Men om det virtuella AKS-nätverket har konfigurerats för att använda de centrala DNS-servrarna och dessa DNS-servrar inte är anslutna till den privata DNS-zonen ännu, kommer AKS-noderna inte att kunna matcha det fullständiga domännamnet för Kubernetes-API:et, och skapandet av AKS-klustret misslyckas. Det virtuella AKS-nätverket ska konfigureras att använda de centrala DNS-servrarna först när klustret har skapats.

När klustret har skapats skapas anslutningen mellan den privata DNS-zonen och det virtuella nätverk där de centrala DNS-servrarna distribueras. Det virtuella AKS-nätverket har också konfigurerats för att använda de centrala DNS-servrarna i anslutningsprenumerationen, och administratörsåtkomsten till AKS Kubernetes API följer det här flödet:

1. Administratören löser det fullständiga domännamnet för Kubernetes-API:et. De lokala DNS-servrarna vidarebefordrar begäran till de auktoritativa servrarna: DNS-matcharna i Azure. Dessa servrar vidarebefordrar begäran till Azure DNS-servern (168.63.129.16), som hämtar IP-adressen från Azure Privat DNS-zonen.
2. När du har löst IP-adressen dirigeras trafiken till Kubernetes-API:et från en lokal plats till VPN- eller ExpressRoute-gatewayen i Azure, beroende på anslutningsmodellen.
3. Den privata slutpunkten har introducerat en /32 väg i det virtuella hubbnätverket. VPN- och ExpressRoute-gatewayerna skickar trafik direkt till den privata Kubernetes API-slutpunkten som distribueras i det virtuella AKS-nätverket.

Trafik från programanvändare till klustret

Inkommande styrenheter kan användas för att exponera program som körs i AKS-klustren.

• Ingresskontrollanter tillhandahåller routning på programnivå på bekostnad av en liten komplexitetsökning.
• Ingresskontrollanter kan använda WAF-funktioner (Web Application Firewall).
• Ingresskontrollanter kan köra off-cluster och in-cluster:
  • En ingresskontrollant utanför klustret avlastar beräkning (till exempel HTTP-trafikroutning eller TLS-avslutning) till en annan tjänst utanför AKS, till exempel tillägget Ingress Controller för Azure Application Gateway (AGIC).
  • En lösning i klustret använder AKS-klusterresurser för beräkning (till exempel HTTP-trafikroutning eller TLS-avslutning). Ingresskontrollanter i klustret kan erbjuda lägre kostnader, men de kräver noggrann resursplanering och underhåll.
• Det grundläggande tillägget för HTTP-programroutning är enkelt att använda, men har vissa begränsningar som beskrivs i HTTP-programroutning.

Ingresskontrollanter kan exponera program och API:er med en offentlig eller privat IP-adress.

• Konfigurationen bör justeras med utgående filtreringsdesign för att undvika asymmetrisk routning. UDR kan orsaka asymmetrisk routning (potentiellt), men inte nödvändigtvis. Application Gateway kan SNAT på trafik, vilket innebär att returtrafiken går tillbaka till Application Gateway-noden och inte till UDR-vägen om UDR bara har konfigurerats för Internettrafik.
• Om TLS-avslutning krävs måste hanteringen av TLS-certifikat beaktas.

Programtrafik kan komma från antingen lokalt eller offentligt Internet. Följande bild beskriver ett exempel där en Azure Application Gateway är konfigurerad för omvänd proxyanslutning till klustren både lokalt och från det offentliga Internet.

Trafik från lokal plats följer flödet för de numrerade blå pratbubblan i föregående diagram.

1. Klienten löser det FQDN som tilldelats till programmet, antingen med hjälp av DE DNS-servrar som distribueras i anslutningsprenumerationen eller lokala DNS-servrar.
2. När du har matchat programmets FQDN till en IP-adress (programgatewayens privata IP-adress) dirigeras trafiken via en VPN- eller ExpressRoute-gateway.
3. Routning i gatewayundernätet har konfigurerats för att skicka begäran till brandväggen för webbprogrammet.
4. Brandväggen för webbprogrammet skickar giltiga begäranden till arbetsbelastningen som körs i AKS-klustret.

Azure Application Gateway i det här exemplet kan distribueras i samma prenumeration som AKS-klustret, eftersom dess konfiguration är nära relaterad till de arbetsbelastningar som distribueras i AKS och därför hanteras av samma programteam. Åtkomst från Internet följer flödet för de numrerade gröna pratbubblan i föregående diagram.

1. Klienter från det offentliga Internet löser DNS-namnet för programmet med hjälp av Azure Traffic Manager. Du kan också använda andra globala belastningsutjämningstekniker som Azure Front Door .
2. Programmets offentliga FQDN matchas av Traffic Manager till den offentliga IP-adressen för programgatewayen, som klienterna har åtkomst till via det offentliga Internet.
3. Programgatewayen kommer åt arbetsbelastningen som distribueras i AKS.

Alternativt kan trafikflöden för webbaserade program göras för att passera både Azure Firewall i anslutningsprenumerationen och WAF i det virtuella AKS-nätverket. Den här metoden har fördelen att erbjuda lite mer skydd, till exempel att använda azure firewall intelligence-baserad filtrering för att släppa trafik från kända skadliga IP-adresser på Internet. Men det har vissa nackdelar också. Till exempel förlusten av den ursprungliga klientens IP-adress och den extra samordning som krävs mellan brandväggen och programteamen när program exponeras. Detta beror på att dnat-regler (målnätverksadressöversättning) kommer att behövas i Azure Firewall.

Trafik från AKS-poddar till serverdelstjänster

Poddarna som körs i AKS-klustret kan behöva komma åt serverdelstjänster som Azure Storage, Azure SQL-databaser eller Azure Cosmos DB NoSQL-databaser. Tjänstslutpunkter för virtuellt nätverk och Private Link kan användas för att skydda anslutningen till dessa Azure-hanterade tjänster.

Om du använder privata Azure-slutpunkter för serverdelstrafik kan DNS-matchning för Azure-tjänsterna utföras med hjälp av Azure Privat DNS-zoner. Eftersom DNS-matcharna för hela miljön finns i det virtuella hubbnätverket (eller det virtuella nätverket för delade tjänster om du använder Virtual WAN-anslutningsmodellen) bör dessa privata zoner skapas i anslutningsprenumerationen. Om du vill skapa den A-post som krävs för att matcha FQDN för den privata tjänsten kan du associera den privata DNS-zonen (i anslutningsprenumerationen) med den privata slutpunkten (i programprenumerationen). Den här åtgärden kräver vissa behörigheter i dessa prenumerationer.

Det går att skapa A-posterna manuellt, men om du kopplar den privata DNS-zonen till den privata slutpunkten blir konfigurationen mindre känslig för felkonfigurationer.

Serverdelsanslutning från AKS-poddar till Azure PaaS-tjänster som exponeras via privata slutpunkter följer den här sekvensen:

1. AKS-poddarna löser FQDN för Azure-plattformen som en tjänst (PaaS) med hjälp av de centrala DNS-servrarna i anslutningsprenumerationen, som definieras som anpassade DNS-servrar i det virtuella AKS-nätverket.
2. Den lösta IP-adressen är den privata IP-adressen för de privata slutpunkterna, som nås direkt från AKS-poddarna.

Trafik mellan AKS-poddarna och de privata slutpunkterna per standard går inte via Azure Firewall i det virtuella hubbnätverket (eller den säkra virtuella hubben om du använder Virtual WAN), även om AKS-klustret har konfigurerats för utgående filtrering med Azure Firewall. Anledningen är att den privata slutpunkten skapar en /32 väg i undernäten i det virtuella programmets nätverk, där AKS distribueras.

Designrekommendationer

• Om din säkerhetsprincip kräver att kubernetes-API:et har en privat IP-adress (i stället för en offentlig IP-adress) distribuerar du ett privat AKS-kluster.
  • Använd anpassade privata DNS-zoner när du skapar ett privat kluster i stället för att låta skapandeprocessen använda en privat DNS-zon för systemet.
• Använd Azure Container Networking Interface (CNI) som en nätverksmodell, såvida du inte har ett begränsat antal IP-adresser som kan tilldelas AKS-klustret.
  • Följ dokumentationen om IP-adressplanering med CNI.
  • Om du vill använda Windows Server-nodpooler och virtuella noder för att verifiera eventuella begränsningar kan du läsa vanliga frågor och svar om Windows AKS-support.
• Använd Azure DDoS Protection för att skydda det virtuella nätverk som används för AKS-klustret om du inte använder Azure Firewall eller WAF i en centraliserad prenumeration.
• Använd DNS-konfigurationen som är länkad till den övergripande nätverkskonfigurationen med Azure Virtual WAN eller hubb- och ekerarkitektur, Azure DNS-zoner och din egen DNS-infrastruktur.
• Använd Private Link för att skydda nätverksanslutningar och använda privat IP-baserad anslutning till andra hanterade Azure-tjänster som används som stöd för Private Link, till exempel Azure Storage, Azure Container Registry, Azure SQL Database och Azure Key Vault.
• Använd en ingresskontrollant för att tillhandahålla avancerad HTTP-routning och säkerhet och för att erbjuda en enda slutpunkt för program.
• Alla webbprogram som har konfigurerats för att använda en ingress ska använda TLS-kryptering och inte tillåta åtkomst via okrypterad HTTP. Den här principen tillämpas redan om prenumerationen innehåller de rekommenderade principerna i Principer som innehåller referensimplementeringar av landningszoner i företagsskala.
• Om du vill spara beräknings- och lagringsresurserna i ditt AKS-kluster kan du använda en ingresskontrollant utanför klustret.
  • Använd tillägget Azure Application Gateway Ingress Controller (AGIC), som är en hanterad Azure-tjänst från första part.
  • Med AGIC distribuerar du en dedikerad Azure Application Gateway för varje AKS-kluster och delar inte samma Application Gateway i flera AKS-kluster.
  • Om det inte finns några resurs- eller driftbegränsningar, eller om AGIC inte tillhandahåller de funktioner som krävs, använder du en ingresskontrollantlösning i klustret som NGINX, Traefik eller någon annan Kubernetes-lösning som stöds.
• För internetuppkopplade och säkerhetskritiska, interna webbprogram använder du en brandvägg för webbprogram med ingresskontrollanten.
  • Både Azure Application Gateway och Azure Front Door integrerar Azure Web Application Firewall för att skydda webbaserade program.
• Om din säkerhetsprincip kräver att du inspekterar all utgående Internettrafik som genereras i AKS-klustret kan du skydda utgående nätverkstrafik med hjälp av Azure Firewall eller en virtuell nätverksinstallation från tredje part som distribuerats i det hanterade virtuella hubbens virtuella nätverk. Mer information finns i Begränsa utgående trafik. Den utgående AKS-typen UDR kräver att en routningstabell associeras med AKS-nodens undernät, så den kan inte användas i dag med den dynamiska routningsinmatning som stöds av Azure Virtual WAN eller Azure Route Server.
• För icke-privata kluster använder du auktoriserade IP-intervall.
• Använd standardnivån i stället för Basic-nivån för Azure Load Balancer.
• När du utformar ett Kubernetes-kluster i Azure är en av de viktigaste övervägandena att välja lämplig nätverksmodell för dina specifika krav. Azure Kubernetes Service (AKS) erbjuder tre olika nätverksmodeller: Kubenet, Azure CNI och Azure CNI Overlay. För att fatta ett välgrundat beslut är det viktigt att förstå funktionerna och egenskaperna för varje modell.

För en funktionsjämförelse mellan de tre nätverksmodellerna i AKS; Kubenet, Azure CNI och Azure CNI Overlay finns i Jämför nätverksmodeller i AKS.