Nätverksbegrepp för program i Azure Kubernetes Service (AKS)
I en containerbaserad mikrotjänstmetod för programutveckling arbetar programkomponenter tillsammans för att bearbeta sina uppgifter. Kubernetes tillhandahåller olika resurser som möjliggör det här samarbetet:
- Du kan ansluta till och exponera program internt eller externt.
- Du kan skapa program med hög tillgänglighet genom att belastningsutjämning dina program.
- Du kan begränsa flödet av nätverkstrafik till eller mellan poddar och noder för att förbättra säkerheten.
- Du kan konfigurera inkommande trafik för SSL/TLS-avslutning eller routning av flera komponenter för dina mer komplexa program.
Den här artikeln beskriver de grundläggande begreppen som tillhandahåller nätverk till dina program i AKS:
Grunderna i Kubernetes-nätverk
Kubernetes använder ett virtuellt nätverkslager för att hantera åtkomst inom och mellan dina program eller deras komponenter:
Kubernetes-noder och virtuella nätverk: Kubernetes-noder är anslutna till ett virtuellt nätverk. Den här konfigurationen gör det möjligt för poddar (grundläggande distributionsenheter i Kubernetes) att ha både inkommande och utgående anslutning.
Kube-proxykomponent: kube-proxy körs på varje nod och ansvarar för att tillhandahålla nödvändiga nätverksfunktioner.
När det gäller specifika Kubernetes-funktioner:
- Lastbalanserare: Du kan använda en lastbalanserare för att fördela nätverkstrafiken jämnt över olika resurser.
- Ingresskontrollanter: Dessa underlättar Layer 7-routning, vilket är viktigt för att dirigera programtrafik.
- Utgående trafikkontroll: Med Kubernetes kan du hantera och styra utgående trafik från klusternoder.
- Nätverksprinciper: Dessa principer möjliggör säkerhetsåtgärder och filtrering för nätverkstrafik i poddar.
I samband med Azure-plattformen:
- Azure effektiviserar virtuella nätverk för AKS-kluster (Azure Kubernetes Service).
- När du skapar en Kubernetes-lastbalanserare i Azure konfigureras motsvarande Azure-lastbalanserareresurs samtidigt.
- När du öppnar nätverksportar för poddar konfigurerar Azure automatiskt de nödvändiga reglerna för nätverkssäkerhetsgrupper.
- Azure kan också hantera externa DNS-konfigurationer för HTTP-programroutning när nya inkommande vägar upprättas.
Virtuella Azure-nätverk
I AKS kan du distribuera ett kluster som använder någon av följande nätverksmodeller:
Kubenet-nätverk
Nätverksresurserna skapas och konfigureras vanligtvis när AKS-klustret distribueras.
CNI-nätverk (Azure Container Networking Interface)
AKS-klustret ansluts till befintliga resurser och konfigurationer för virtuella nätverk.
Kubenet-nätverk (grundläggande)
Kubenet-nätverksalternativet är standardkonfigurationen för att skapa AKS-kluster. Med kubenet:
- Noder får en IP-adress från det virtuella Azure-nätverkets undernät.
- Poddar får en IP-adress från ett logiskt annat adressutrymme än nodernas virtuella Azure-nätverksundernät.
- NAT (Network Address Translation) konfigureras sedan så att poddarna kan komma åt resurser i Azure Virtual Network.
- Källans IP-adress för trafiken översätts till nodens primära IP-adress.
Noder använder kubenet Kubernetes-plugin-programmet. Du kan låta Azure-plattformen skapa och konfigurera de virtuella nätverken åt dig, eller välja att distribuera ditt AKS-kluster till ett befintligt virtuellt nätverksundernät.
Endast noderna får en dirigerbar IP-adress. Poddarna använder NAT för att kommunicera med andra resurser utanför AKS-klustret. Den här metoden minskar antalet IP-adresser som du behöver reservera i ditt nätverksutrymme för poddar att använda.
Kommentar
Kubenet är standardnätverksalternativet för ett AKS-kluster för att skapa ett virtuellt nätverk och undernät, men det rekommenderas inte för produktionsdistributioner. För de flesta produktionsdistributioner bör du planera för och använda Azure CNI-nätverk på grund av dess överlägsna skalbarhet och prestandaegenskaper.
Mer information finns i Konfigurera kubenet-nätverk för ett AKS-kluster.
Azure CNI-nätverk (avancerat)
Med Azure CNI får varje podd en IP-adress från undernätet och kan nås direkt. Dessa IP-adresser måste planeras i förväg och vara unika i hela nätverket. Varje nod har en konfigurationsparameter för det maximala antalet poddar som den stöder. Motsvarande antal IP-adresser per nod reserveras sedan i förväg. Den här metoden kan leda till överbelastning av IP-adresser eller behovet av att återskapa kluster i ett större undernät när programmets krav växer, så det är viktigt att planera korrekt. För att undvika dessa planeringsutmaningar är det möjligt att aktivera funktionen Azure CNI-nätverk för dynamisk allokering av IP-adresser och utökat undernätsstöd.
Kommentar
På grund av Kubernetes-begränsningar måste resursgruppens namn, namnet på det virtuella nätverket och undernätets namn vara högst 63 tecken.
Till skillnad från kubenet översätts inte trafik till slutpunkter i samma virtuella nätverk (NAT) till nodens primära IP-adress. Källadressen för trafik i det virtuella nätverket är podd-IP-adressen. Trafik som är extern till det virtuella nätverket NATs fortfarande till nodens primära IP-adress.
Noder använder Plugin-programmet Azure CNI Kubernetes.
Mer information finns i Konfigurera Azure CNI för ett AKS-kluster.
Azure CNI Overlay-nätverk
Azure CNI Overlay representerar en utveckling av Azure CNI som hanterar skalbarhets- och planeringsutmaningar som uppstår vid tilldelning av virtuella nätverks-IP-adresser till poddar. Azure CNI Overlay tilldelar privata CIDR-IP-adresser till poddar. De privata IP-adresserna är separata från det virtuella nätverket och kan återanvändas i flera kluster. Azure CNI Overlay kan skalas utöver den gräns på 400 noder som tillämpas i Kubenet-kluster. Azure CNI Overlay är det rekommenderade alternativet för de flesta kluster.
Azure CNI som drivs av Cilium
Azure CNI som drivs av Cilium använder Cilium för att tillhandahålla högpresterande nätverk, observerbarhet och tillämpning av nätverksprinciper. Den integreras internt med Azure CNI Overlay för skalbar IP-adresshantering (IPAM).
Dessutom tillämpar Cilium nätverksprinciper som standard, utan att kräva en separat nätverksprincipmotor. Azure CNI powered by Cilium can scale beyond Azure Network Policy Manager's limits of 250 nodes/20-K pod by using eBPF programs and a more efficient API object structure.
Azure CNI som drivs av Cilium är det rekommenderade alternativet för kluster som kräver tvingande nätverksprincip.
Bring Your Own CNI
Du kan installera ett CNI som inte är Microsoft CNI i AKS med hjälp av funktionen Bring your own CNI .
Jämföra nätverksmodeller
Både kubenet och Azure CNI tillhandahåller nätverksanslutning för dina AKS-kluster. Det finns dock fördelar och nackdelar med var och en. På hög nivå gäller följande överväganden:
kubenet
- Sparar IP-adressutrymme.
- Använder interna eller externa Kubernetes-lastbalanserare för att nå poddar utanför klustret.
- Du hanterar och underhåller användardefinierade vägar manuellt (UDR).
- Maximalt 400 noder per kluster.
Azure CNI
- Poddar får fullständig anslutning till virtuella nätverk och kan nås direkt via sin privata IP-adress från anslutna nätverk.
- Kräver mer IP-adressutrymme.
| Nätverksmodell | Användningsområde för |
|---|---|
| Kubenet | • IP-adressutrymmeskonversation är en prioritet. • Enkel konfiguration. • Färre än 400 noder per kluster. • Kubernetes interna eller externa lastbalanserare räcker för att nå poddar utanför klustret. • Manuellt hantera och underhålla användardefinierade vägar är acceptabelt. |
| Azure CNI | • Fullständig anslutning till virtuella nätverk krävs för poddar. • Avancerade AKS-funktioner (till exempel virtuella noder) behövs. • Det finns tillräckligt med IP-adressutrymme. • Podd-till-podd- och podd-anslutning till virtuella datorer krävs. • Externa resurser måste nå poddar direkt. • AKS-nätverksprinciper krävs. |
| Azure CNI-överlägg | • Brist på IP-adresser är ett problem. • Det räcker med att skala upp till 1 000 noder och 250 poddar per nod. • Extra hopp för poddanslutning är acceptabelt. • Enklare nätverkskonfiguration. • KRAV för UTGÅENDE AKS kan uppfyllas. |
Följande beteendeskillnader finns mellan kubenet och Azure CNI:
| Kapacitet | Kubenet | Azure CNI | Azure CNI-överlägg | Azure CNI som drivs av Cilium |
|---|---|---|---|---|
| Distribuera kluster i ett befintligt eller nytt virtuellt nätverk | Stöds – UDR:erna tillämpas manuellt | Stöds | Stöds | Stöds |
| Poddanslutning | Stöds | Stöds | Stöds | Stöds |
| Podd-VM-anslutning; Virtuell dator i samma virtuella nätverk | Fungerar när den initieras av podden | Fungerar åt båda hållen | Fungerar när den initieras av podden | Fungerar när den initieras av podden |
| Podd-VM-anslutning; Virtuell dator i peer-kopplat virtuellt nätverk | Fungerar när den initieras av podden | Fungerar åt båda hållen | Fungerar när den initieras av podden | Fungerar när den initieras av podden |
| Lokal åtkomst med HJÄLP av VPN eller Express Route | Fungerar när den initieras av podden | Fungerar åt båda hållen | Fungerar när den initieras av podden | Fungerar när den initieras av podden |
| Åtkomst till resurser som skyddas av tjänstslutpunkter | Stöds | Stöds | Stöds | |
| Exponera Kubernetes-tjänster med hjälp av en lastbalanserartjänst, App Gateway eller ingresskontrollant | Stöds | Stöds | Stöds | Samma begränsningar när du använder överläggsläge |
| Stöd för Windows-nodpooler | Stöds inte | Stöds | Stöds | Endast tillgängligt för Linux och inte för Windows. |
| Standard azure DNS och privata zoner | Stöds | Stöds | Stöds |
Mer information om Azure CNI och kubenet och för att avgöra vilket alternativ som är bäst för dig finns i Konfigurera Azure CNI-nätverk i AKS och Använda kubenet-nätverk i AKS.
Stödomfång mellan nätverksmodeller
Oavsett vilken nätverksmodell du använder kan både kubenet och Azure CNI distribueras på något av följande sätt:
- Azure-plattformen kan automatiskt skapa och konfigurera de virtuella nätverksresurserna när du skapar ett AKS-kluster.
- Du kan skapa och konfigurera de virtuella nätverksresurserna manuellt och ansluta till dessa resurser när du skapar AKS-klustret.
Även om funktioner som tjänstslutpunkter eller UDR stöds med både kubenet och Azure CNI, definierar supportprinciperna för AKS vilka ändringar du kan göra. Till exempel:
- Om du manuellt skapar de virtuella nätverksresurserna för ett AKS-kluster stöds du när du konfigurerar dina egna UDR eller tjänstslutpunkter.
- Om Azure-plattformen automatiskt skapar de virtuella nätverksresurserna för ditt AKS-kluster kan du inte ändra dessa AKS-hanterade resurser manuellt för att konfigurera dina egna UDR eller tjänstslutpunkter.
Ingresskontrollanter
När du skapar en LoadBalancer-tjänst skapar du även en underliggande Azure-lastbalanserareresurs. Lastbalanseraren är konfigurerad för att distribuera trafik till poddarna i tjänsten på en viss port.
LoadBalancer fungerar bara på lager 4. På nivå 4 känner tjänsten inte till de faktiska programmen och kan inte göra några fler routningsöverväganden.
Ingresskontrollanter fungerar på nivå 7 och kan använda mer intelligenta regler för att distribuera programtrafik. Ingresskontrollanter dirigerar vanligtvis HTTP-trafik till olika program baserat på den inkommande URL:en.
Jämföra alternativ för ingress
I följande tabell visas funktionsskillnaderna mellan de olika alternativen för ingresskontrollanter:
| Funktion | Tillägg för programroutning | Application Gateway for Containers | Azure Service Mesh/Istio-baserat tjänstnät |
|---|---|---|---|
| Ingress/Gateway-styrenhet | NGINX-ingresskontrollant | Azure Application Gateway för containrar | Ingressgateway för Istio |
| API | Ingress-API | API för ingress och gateway-API | Gateway-API |
| Värd | I klustret | Azure värdhanterat | I klustret |
| Skalning | Automatisk skalning | Automatisk skalning | Automatisk skalning |
| Belastningsutjämning | Intern/extern | Externt | Intern/extern |
| SSL-avslutning | I klustret | Ja: Avlastning och E2E SSL | I klustret |
| mTLS | Ej tillämpligt | Ja till serverdel | Ej tillämpligt |
| Statisk IP-adress | Ej tillämpligt | FQDN | Ej tillämpligt |
| Azure Key Vault-lagrade SSL-certifikat | Ja | Ja | Ej tillämpligt |
| Azure DNS-integrering för DNS-zonhantering | Ja | Ja | Ej tillämpligt |
I följande tabell visas de olika scenarier där du kan använda varje ingresskontrollant:
| Alternativ för ingress | Användningsområde för |
|---|---|
| Hanterad NGINX – tillägg för programroutning | • In-cluster värdbaserade, anpassningsbara och skalbara NGINX-ingresskontrollanter. • Grundläggande funktioner för belastningsutjämning och routning. • Intern och extern lastbalanserare. • Konfiguration av statisk IP-adress. • Integrering med Azure Key Vault för certifikathantering. • Integrering med Azure DNS-zoner för offentlig och privat DNS-hantering. • Stöder API:et ingress. |
| Application Gateway för containrar | • Azure-värdbaserad ingressgateway. • Flexibla distributionsstrategier som hanteras av kontrollanten eller ta med din egen Application Gateway för containrar. • Avancerade trafikhanteringsfunktioner som automatiska återförsök, återhämtning i tillgänglighetszonen, ömsesidig autentisering (mTLS) till serverdelsmål, trafikdelning/viktad resursallokering och automatisk skalning. • Integrering med Azure Key Vault för certifikathantering. • Integrering med Azure DNS-zoner för offentlig och privat DNS-hantering. • Stöder API:er för ingress och gateway. |
| Ingressgateway för Istio | • Baserat på Envoy, när du använder med Istio för ett servicenät. • Avancerade trafikhanteringsfunktioner som hastighetsbegränsning och kretsbrytning. • Stöd för mTLS • Stöder gateway-API:et. |
Skapa en ingressresurs
Tillägget för programroutning är det rekommenderade sättet att konfigurera en ingresskontrollant i AKS. Tillägget för programroutning är en fullständigt hanterad ingresskontrollant för Azure Kubernetes Service (AKS) som tillhandahåller följande funktioner:
Enkel konfiguration av hanterade NGINX-ingresskontrollanter baserat på Kubernetes NGINX-ingresskontrollant.
Integrering med Azure DNS för offentlig och privat zonhantering.
SSL-avslutning med certifikat som lagras i Azure Key Vault.
Mer information om tillägget för programroutning finns i Hanterad NGINX-ingress med tillägget för programroutning.
Ip-bevarande av klientkälla
Konfigurera ingresskontrollanten så att klientkällans IP-adress bevaras på begäranden till containrar i AKS-klustret. När ingresskontrollanten dirigerar en klients begäran till en container i AKS-klustret är den ursprungliga käll-IP-adressen för den begäran inte tillgänglig för målcontainern. När du aktiverar IP-bevarande av klientkällan är käll-IP för klienten tillgängligt i begärandehuvudet under X-Forwarded-For.
Om du använder IP-konservering av klientkällan på ingresskontrollanten kan du inte använda TLS-direkt. Ip-bevarande av klientkälla och TLS-direkt kan användas med andra tjänster, till exempel LoadBalancer-typen .
Mer information om IP-bevarande av klientkälla finns i Så här fungerar IP-bevarande av klientkälla för LoadBalancer Services i AKS.
Kontrollera utgående trafik (utgående)
AKS-kluster distribueras i ett virtuellt nätverk och har utgående beroenden på tjänster utanför det virtuella nätverket. Dessa utgående beroenden definieras nästan helt och hållet med fullständigt kvalificerade domännamn (FQDN). Som standard har AKS-kluster obegränsad utgående (utgående) Internetåtkomst, vilket gör att de noder och tjänster som du kör får åtkomst till externa resurser efter behov. Om du vill kan du begränsa utgående trafik.
Mer information finns i Kontrollera utgående trafik för klusternoder i AKS.
Nätverkssäkerhetsgrupper
En nätverkssäkerhetsgrupp filtrerar trafik för virtuella datorer som AKS-noderna. När du skapar tjänster, till exempel en LoadBalancer, konfigurerar Azure-plattformen automatiskt alla nödvändiga regler för nätverkssäkerhetsgrupper.
Du behöver inte konfigurera NSG-regler manuellt för att filtrera trafik för poddar i ett AKS-kluster. Du kan definiera alla nödvändiga portar och vidarebefordran som en del av Kubernetes Service-manifesten och låta Azure-plattformen skapa eller uppdatera lämpliga regler.
Du kan också använda nätverksprinciper för att automatiskt tillämpa trafikfilterregler på poddar.
Mer information finns i Hur nätverkssäkerhetsgrupper filtrerar nätverkstrafik.
Nätverksprinciper
Som standard kan alla poddar i ett AKS-kluster skicka och ta emot trafik utan begränsningar. För förbättrad säkerhet definierar du regler som styr trafikflödet, till exempel:
- Serverdelsprogram exponeras endast för nödvändiga klientdelstjänster.
- Databaskomponenter är endast tillgängliga för de programnivåer som ansluter till dem.
Nätverksprincip är en Kubernetes-funktion som är tillgänglig i AKS som gör att du kan styra trafikflödet mellan poddar. Du kan tillåta eller neka trafik till podden baserat på inställningar som tilldelade etiketter, namnrymd eller trafikport. Nätverkssäkerhetsgrupper är bättre för AKS-noder, men nätverksprinciper är ett mer anpassat, molnbaserat sätt att styra flödet av trafik för poddar. Eftersom poddar skapas dynamiskt i ett AKS-kluster kan nödvändiga nätverksprinciper tillämpas automatiskt.
Mer information finns i Skydda trafik mellan poddar med hjälp av nätverksprinciper i Azure Kubernetes Service (AKS).
Nästa steg
Kom igång med AKS-nätverk genom att skapa och konfigurera ett AKS-kluster med dina egna IP-adressintervall med kubenet eller Azure CNI.
Rekommenderade metoder finns i Metodtips för nätverksanslutning och säkerhet i AKS.
Mer information om grundläggande Kubernetes- och AKS-begrepp finns i följande artiklar: