Vereisten voor het plannen van IP-adressen
Van toepassing op: Azure Local, versie 23H2
Het plannen van IP-adressen voor AKS die door Azure Arc is ingeschakeld, omvat het ontwerpen van een netwerk dat ondersteuning biedt voor toepassingen, knooppuntgroepen, podnetwerken, servicecommunicatie en externe toegang. In dit artikel worden enkele belangrijke overwegingen beschreven voor het plannen van effectieve IP-adressen en het minimale aantal IP-adressen dat is vereist voor het implementeren van AKS in productie. Zie de AKS-netwerkconcepten en -vereisten voordat u dit artikel leest.
Eenvoudige IP-adresplanning voor Kubernetes-clusters en -toepassingen
In het volgende scenario kunt u IP-adressen reserveren vanuit één netwerk voor uw Kubernetes-clusters en -services. Dit voorbeeld is het eenvoudigste en eenvoudigste scenario voor ip-adrestoewijzing.
| IP-adresvereiste | Minimum aantal IP-adressen | Hoe en waar u deze reservering kunt maken |
|---|---|---|
| IP-adressen van AKS Arc-VM's | Reserveer één IP-adres voor elk werkknooppunt in uw Kubernetes-cluster. Als u bijvoorbeeld drie knooppuntgroepen wilt maken met 3 knooppunten in elke knooppuntgroep, hebt u 9 IP-adressen in uw IP-pool nodig. | Gereserveerde IP-adressen via IP-adresgroepen in het logische arc-VM-netwerk. |
| AKS Arc K8s-versie-upgrade-IP's | Omdat AKS Arc rolling upgrades uitvoert, reserveert u één IP-adres voor elk AKS Arc-cluster voor kubernetes-versie-upgradebewerkingen. | Gereserveerde IP-adressen via IP-adresgroepen in het logische arc-VM-netwerk. |
| IP-adres van besturingsvlak | Reserveer één IP-adres voor elk Kubernetes-cluster in uw omgeving. Als u bijvoorbeeld in totaal vijf clusters wilt maken, reserveert u 5 IP-adressen, één voor elk Kubernetes-cluster. | Gereserveerde IP-adressen via IP-adresgroepen in het logische arc-VM-netwerk. |
| IP-adressen van load balancers | Het aantal gereserveerde IP-adressen is afhankelijk van uw toepassingsimplementatiemodel. Als uitgangspunt kunt u één IP-adres reserveren voor elke Kubernetes-service. | Reserveer IP-adressen in hetzelfde subnet als het logische arc-VM-netwerk, maar buiten de IP-groep. |
Voorbeeldscenario voor IP-adresreservering voor Kubernetes-clusters en -toepassingen
Jane is een IT-beheerder die net begint met AKS die is ingeschakeld door Azure Arc. Jane wil twee Kubernetes-clusters implementeren: Kubernetes-cluster A en Kubernetes-cluster B op het lokale Azure-cluster. Jane wil ook een stemtoepassing uitvoeren boven op cluster A. Deze toepassing heeft drie exemplaren van de front-endgebruikersinterface die wordt uitgevoerd op de twee clusters en één exemplaar van de back-enddatabase. Alle AKS-clusters en -services worden uitgevoerd in één netwerk, met één subnet.
- Kubernetes-cluster A heeft 3 besturingsvlakknooppunten en 5 werkknooppunten.
- Kubernetes-cluster B heeft 1 besturingsvlakknooppunt en 3 werkknooppunten.
- 3 exemplaren van de front-endgebruikersinterface (poort 443).
- 1 exemplaar van de back-enddatabase (poort 80).
Op basis van de vorige tabel moet Jane in totaal 19 IP-adressen reserveren in het subnet van Jane:
- 8 IP-adressen voor de AKS Arc-knooppunt-VM's in cluster A (één IP per K8s-knooppunt-VM).
- 4 IP-adressen voor de AKS Arc-knooppunt-VM's in cluster B (één IP per K8s-knooppunt-VM).
- 2 IP-adressen voor het uitvoeren van een AKS Arc-upgradebewerking (één IP-adres per AKS Arc-cluster).
- 2 IP-adressen voor het AKS Arc-besturingsvlak (één IP-adres per AKS Arc-cluster)
- 3 IP-adressen voor de Kubernetes-service (één IP-adres per exemplaar van de front-endgebruikersinterface, omdat ze allemaal dezelfde poort gebruiken. De back-enddatabase kan een van de drie IP-adressen gebruiken zolang deze een andere poort gebruikt).
Als u doorgaat met dit voorbeeld en deze toevoegt aan de volgende tabel, krijgt u het volgende:
| Parameter | Aantal IP-adressen | Hoe en waar u deze reservering kunt maken |
|---|---|---|
| AKS Arc-VM's, K8s-versie-upgrade en IP-adres van besturingsvlak | 16 IP-adressen reserveren | Maak deze reservering via IP-adresgroepen in het logische Azure-netwerk. |
| IP-adressen van load balancers | 3 IP-adres voor Kubernetes-services, voor jane's stemtoepassing. | Deze IP-adressen worden gebruikt wanneer u een load balancer op cluster A installeert. U kunt de MetalLB Arc-extensie gebruiken of uw eigen load balancer van derden meenemen. Zorg ervoor dat dit IP-adres zich in hetzelfde subnet bevindt als het logische Arc-netwerk, maar buiten de IP-groep die is gedefinieerd in het logische arc-VM-netwerk. |
Voorbeelden van CLI-opdrachten voor IP-adresreservering voor Kubernetes-clusters en -toepassingen
In deze sectie wordt de set opdrachten beschreven die Jane uitvoert voor haar scenario. Maak eerst een logisch netwerk met een IP-adresgroep met ten minste 16 IP-adressen. We hebben de IP-groep gemaakt met 20 IP-adressen om de schaal op dag N te bieden. Zie az stack-hci-vm network lnet createvoor gedetailleerde informatie over parameteropties in logische netwerken:
$ipPoolStart = "10.220.32.18"
$ipPoolEnd = "10.220.32.37"
az stack-hci-vm network lnet create --subscription $subscription --resource-group $resource_group --custom-location $customLocationID --name $lnetName --vm-switch-name $vmSwitchName --ip-allocation-method "Static" --address-prefixes $addressPrefixes --gateway $gateway --dns-servers $dnsServers --ip-pool-start $ipPoolStart --ip-pool-end $ipPoolEnd
Maak vervolgens een AKS Arc-cluster met het vorige logische netwerk:
az aksarc create -n $aksclustername -g $resource_group --custom-location $customlocationID --vnet-ids $lnetName --aad-admin-group-object-ids $aadgroupID --generate-ssh-keys
U kunt nu de MetalLB-load balancer inschakelen met een IP-adresgroep van 3 IP-adressen, in hetzelfde subnet als het logische arc-VM-netwerk. U kunt later meer IP-adresgroepen toevoegen als uw toepassing een verhoging nodig heeft. Zie het overzicht van de MetalLB Arc-extensie voor gedetailleerde vereisten.
az k8s-runtime load-balancer create --load-balancer-name $lbName --resource-uri subscriptions/$subscription/resourceGroups/$resource_group/providers/Microsoft.Kubernetes/connectedClusters/metallb-demo --addresses 10.220.32.47-10.220.32.49 --advertise-mode ARP
Overwegingen voor LNETs voor AKS-clusters en Arc-VM's
Logische netwerken in Azure Local worden gebruikt door zowel AKS-clusters als Arc-VM's. U kunt logische netwerken op een van de volgende twee manieren configureren:
- Een logisch netwerk delen tussen AKS- en Arc-VM's.
- Definieer afzonderlijke logische netwerken voor AKS-clusters en Arc-VM's.
Het delen van een logisch netwerk tussen AKS- en Arc-VM's in Azure Local biedt het voordeel van gestroomlijnde communicatie, kostenbesparingen en vereenvoudigd netwerkbeheer. Deze aanpak introduceert echter ook potentiële uitdagingen, zoals resourceconflicten, beveiligingsrisico's en complexiteit bij het oplossen van problemen.
| Criteria | Een logisch netwerk delen | Afzonderlijke logische netwerken definiëren |
|---|---|---|
| Configuratiecomplexiteit | Eenvoudigere configuratie met één netwerk, waardoor de complexiteit van de installatie wordt verminderd. | Complexere installatie, omdat u meerdere logische netwerken moet configureren voor VM's en AKS-clusters. |
| Schaalbaarheid | Mogelijke schaalbaarheidsbeperkingen omdat zowel Arc-VM's als AKS-clusters netwerkbronnen delen. | Schaalbaarder omdat netwerkresources worden gescheiden en onafhankelijk kunnen worden geschaald. |
| Netwerkbeleidsbeheer | Eenvoudiger te beheren met één set netwerkbeleidsregels, maar moeilijker om workloads te isoleren. | Eenvoudiger om workloads te isoleren, omdat er afzonderlijke beleidsregels per logisch netwerk kunnen worden toegepast. |
| Beveiligingsoverwegingen | Verhoogd risico op beveiligingsproblemen tussen communicaties als deze niet goed zijn gesegmenteerd. | Betere beveiliging omdat elk netwerk kan worden gesegmenteerd en strikter geïsoleerd. |
| Impact van netwerkfouten | Een fout in het gedeelde netwerk kan gelijktijdig van invloed zijn op zowel AKS- als Arc-VM's. | Een fout in één netwerk is alleen van invloed op de workloads binnen dat netwerk, waardoor het totale risico wordt verminderd. |
Toewijzing van IP-adresbereik voor CIDR en service-CIDR
In deze sectie worden de IP-adresbereiken beschreven die door Kubernetes worden gebruikt voor pod- en servicecommunicatie binnen een cluster. Deze IP-adresbereiken worden gedefinieerd tijdens het maken van het AKS-cluster en worden gebruikt om unieke IP-adressen toe te wijzen aan pods en services binnen het cluster.
CIDR van podnetwerk
Pod-netwerk CIDR is een bereik van IP-adressen die door Kubernetes worden gebruikt om unieke IP-adressen toe te wijzen aan de afzonderlijke pods die worden uitgevoerd binnen een Kubernetes-cluster. Elke pod krijgt een eigen IP-adres binnen dit bereik, zodat pods met elkaar en met services binnen het cluster kunnen communiceren. In AKS worden IP-adressen van pods toegewezen via Calico CNI in de VXLAN-modus. Calico VXLAN helpt bij het maken van Overlay-netwerken, waarbij de IP-adressen van pods (van het podnetwerk CIDR) worden gevirtualiseerd en getunneld via het fysieke netwerk. In deze modus krijgt elke pod een IP-adres van de CIDR van het podnetwerk toegewezen, maar dit IP-adres is niet rechtstreeks routeerbaar in het fysieke netwerk. In plaats daarvan wordt het ingekapseld in de netwerkpakketten en verzonden via het onderliggende fysieke netwerk om de doelpod op een ander knooppunt te bereiken.
AKS biedt een standaardwaarde van 10.244.0.0/16 voor het podnetwerk CIDR. AKS biedt ondersteuning voor aanpassingen voor de CIDR van het podnetwerk. U kunt uw eigen waarde instellen met behulp van de --pod-cidr parameter bij het maken van het AKS-cluster. Zorg ervoor dat het CIDR-IP-bereik groot genoeg is om het maximum aantal pods per knooppunt en in het Kubernetes-cluster aan te bieden.
Servicenetwerk CIDR
Het CIDR-servicenetwerk is het bereik van IP-adressen die zijn gereserveerd voor Kubernetes-services, zoals LoadBalancers, ClusterIP en NodePort binnen een cluster. Kubernetes ondersteunt de volgende servicetypen:
- ClusterIP: het standaardservicetype, waarmee de service in het cluster beschikbaar wordt gemaakt. Het IP-adres dat is toegewezen vanuit het CIDR-servicenetwerk, is alleen toegankelijk binnen het Kubernetes-cluster.
- NodePort: maakt de service beschikbaar op een specifieke poort op het IP-adres van elk knooppunt. ClusterIP wordt nog steeds intern gebruikt, maar externe toegang verloopt via de IP-adressen van het knooppunt en een specifieke poort.
- LoadBalancer: Met dit type maakt u een door de cloudprovider beheerde load balancer en maakt u de service extern beschikbaar. De cloudprovider beheert doorgaans de externe IP-toewijzing, terwijl de interne ClusterIP binnen de CIDR van het servicenetwerk blijft.
AKS biedt een standaardwaarde van 10.96.0.0/12 voor het servicenetwerk CIDR. AKS biedt momenteel geen ondersteuning voor aanpassingen voor de CIDR van het servicenetwerk.
Volgende stappen
Logische netwerken maken voor Kubernetes-clusters in Azure Local, versie 23H2