Netwerkarchitectuur voor AKS in Azure Stack HCI

In dit scenario ziet u hoe u netwerkconcepten ontwerpt en implementeert voor het implementeren van AKS-knooppunten (Azure Kubernetes Service) op AKS-clusters.

Dit artikel bevat aanbevelingen voor het ontwerpen van netwerken voor Kubernetes-knooppunten en Kubernetes-containers. Het maakt deel uit van een richtlijnenset voor architectuurbasislijnen van twee artikelen. Bekijk hier de aanbevelingen voor de basislijnarchitectuur.

Architectuur

In de volgende afbeelding ziet u de netwerkarchitectuur voor Azure Kubernetes Service op Azure Stack HCI- of Windows Server 2019/2022-datacenterclusters:

Een Visio-bestand van deze architectuur downloaden.

Het scenario bestaat uit de volgende onderdelen en mogelijkheden:

• Azure Stack HCI (22H2) is een hypergeconvergeerde infrastructuurclusteroplossing (HCI) die als host fungeert voor gevirtualiseerde Windows- en Linux-workloads en hun opslag in een hybride on-premises omgeving. Azure Stack HCI-cluster wordt geïmplementeerd als een cluster met 2-4 knooppunten.
• Windows Server 2019/2022 datacenterfailovercluster is een groep onafhankelijke computers die samenwerken om de beschikbaarheid en schaalbaarheid van geclusterde rollen te vergroten.
• Azure Kubernetes Service in Azure Stack HCI is een on-premises implementatie van Azure Kubernetes Service (AKS), waarmee het uitvoeren van toepassingen in containers op schaal wordt geautomatiseerd.
• Active Directory-domein Services is een hiërarchische structuur waarin informatie over objecten in het netwerk wordt opgeslagen. Het biedt identiteits- en toegangsoplossing voor identiteiten die zijn gekoppeld aan gebruikers, computers, toepassingen of andere resources die zijn opgenomen in een beveiligingsgrens.
• Beheercluster ook wel AKS-host genoemd, is verantwoordelijk voor het implementeren en beheren van meerdere workloadclusters. Het beheercluster verbruikt 1 IP-adres uit de knooppuntgroep, maar u moet nog 2 IP-adressen reserveren voor updatebewerkingen. Het beheercluster verbruikt ook één IP-adres uit de VIP-groep.
• Workloadcluster is een maximaal beschikbare implementatie van Kubernetes met behulp van Linux-VM's voor het uitvoeren van Kubernetes-besturingsvlakonderdelen en Linux- en/of Windows-werkknooppunten.
  • Besturingsvlak. Wordt uitgevoerd op een Linux-distributie en bevat API-serveronderdelen voor interactie met kubernetes-API en een gedistribueerd sleutel-waardearchief, enzovoort, voor het opslaan van alle configuratie en gegevens van het cluster. Het verbruikt één IP-adres uit de knooppuntgroep en één IP van de VIP-groep.
  • Load balancer. Wordt uitgevoerd op een Virtuele Linux-machine en biedt services met gelijke taakverdeling voor het workloadcluster. Het verbruikt één IP-adres uit de knooppuntgroep en één IP van de VIP-groep.
  • Werkknooppunten. Uitvoeren op een Windows- of Linux-besturingssysteem dat als host fungeert voor toepassingen in containers. Het verbruikt IP-adressen uit de knooppuntgroep, maar u moet ten minste 3 meer IP-adressen plannen voor updatebewerkingen.
  • Kubernetes-resources. Pods vertegenwoordigen één exemplaar van uw toepassing, die meestal een 1:1-toewijzing met een container hebben, maar bepaalde pods kunnen meerdere containers bevatten. Implementaties vertegenwoordigen een of meer identieke pods. Pods en implementaties worden logisch gegroepeerd in een naamruimte waarmee de toegang tot het beheer van de resources wordt beheerd. Ze verbruiken 1 IP per pod uit de VIP-groep.
• Azure Arc is een cloudservice die het beheermodel op basis van Azure Resource Manager uitbreidt naar niet-Azure-resources, waaronder virtuele machines (VM's), Kubernetes-clusters en in containers geplaatste databases.
• Azure Policy is een cloudservice die Azure- en on-premises resources evalueert via integratie met Azure Arc door eigenschappen te vergelijken met aanpasbare bedrijfsregels.
• Azure Monitor is een cloudservice die de beschikbaarheid en prestaties van uw toepassingen en services maximaliseert door een uitgebreide oplossing te bieden voor het verzamelen, analyseren en uitvoeren van telemetrie vanuit uw cloud- en on-premises omgevingen.
• Microsoft Defender voor Cloud is een geïntegreerd beveiligingsbeheersysteem voor infrastructuur dat de beveiligingsstatus van uw datacenters versterkt en geavanceerde bedreigingsbeveiliging biedt voor uw hybride workloads in de cloud en on-premises.

Onderdelen

• Azure Stack HCI (20H2)
• Windows Server 2019/2022 datacenter failovercluster
• Azure Kubernetes Service (AKS)
• Windows-beheercentrum
• Een Azure-abonnement
• Azure Arc
• Toegangsbeheer op basis van rollen in Azure (RBAC)
• Azure Monitor
• Microsoft Defender voor Cloud

Scenariodetails

De gebruiksvoorbeelden voor dit scenario worden beschreven in het eerste artikel van de reeks Basislijnarchitectuur.

Netwerken van Kubernetes-knooppunten

De belangrijkste overweging in het netwerkontwerp voor de AKS in Azure Stack HCI is het selecteren van het netwerkmodel dat voldoende IP-adressen biedt. AKS in Azure Stack HCI maakt gebruik van virtuele netwerken om IP-adressen toe te wijzen aan de Kubernetes-knooppuntresources. U kunt twee IP-adrestoewijzingsmodellen gebruiken:

• Statisch IP-netwerk is voorspelbaarder, maar voegt extra inspanning toe voor de eerste configuratie.
• Dhcp-netwerken (Dynamic Host Configuration Protocol) maken gebruik van dynamische toewijzing van IP-adressen en minder inspanning, maar u moet voorzichtig zijn om de beschikbare groep IP-adressen niet uit te putten. U moet ook reserveringen en uitsluitingsbereiken beheren voor virtuele IP-adresgroepen en bepaalde clusterbrede resources, zoals de cloudagentservice.

Beide toewijzingsmodellen moeten IP-adressen plannen voor:

• Virtuele IP-adresgroep
• IP-adresgroep van Kubernetes-knooppunt-VM

Virtuele IP-adresgroep

Een virtuele IP-adresgroep is een set IP-adressen die verplicht zijn voor elke AKS-implementatie in Azure Stack HCI. Plan het aantal IP-adressen in de virtuele IP-pool op basis van het aantal workloadclusters en Kubernetes-services. De virtuele IP-adresgroep biedt IP-adressen voor de volgende typen resources:

• Cloudagent vereist een zwevend IP-adres uit de virtuele IP-pool.

• Het API-serveronderdeel dat wordt uitgevoerd in de virtuele Machine van Kubernetes Virtual Appliance (KVA) (beheercluster) gebruikt een IP-adres uit de virtuele IP-pool. De API-server is een onderdeel van het Kubernetes-besturingsvlak dat de Kubernetes-API beschikbaar maakt. De API-server is de front-end voor het Kubernetes-besturingsvlak. De KVA is een virtuele machine met Mariner Linux en host een Kubernetes-cluster. Het IP-adres is zwevend en wordt ook gebruikt voor andere KVA-VM's die u in AKS in Azure Stack HCI implementeert. De virtuele KVA-machine host ook een kubernetes-service voor virtuele IP-load balancer.

• Plan IP-adressering voor het aantal VM's in het besturingsvlak dat op de doelservers is geïmplementeerd, omdat ze ook meer IP-adressen uit de virtuele IP-adresgroep gebruiken. Overwegingen worden beschreven in de volgende sectie.

• Het doelcluster bevat een load balancer-VM, die HAProxy is en eigenaar is van de virtuele IP-adresgroep voor het doelcluster. Met deze VM worden alle Kubernetes-services beschikbaar gemaakt via de virtuele IP-adresgroep.

• Toepassingen die worden uitgevoerd in Kubernetes-pods gebruiken IP-adressen uit de virtuele IP-adresgroep.

• HaProxy load balancer wordt geïmplementeerd als een gespecialiseerde virtuele machine en kan worden gebruikt om binnenkomende aanvragen over meerdere eindpunten te verdelen. Ze gebruiken IP-adressen uit de virtuele IP-pool en u moet IP-adressering plannen voor elk workloadcluster.

IP-adresgroep van Kubernetes-knooppunt-VM

Kubernetes-knooppunten worden geïmplementeerd als virtuele machines in een AKS op Azure Stack HCI-implementatie. Zorg ervoor dat u het aantal IP-adressen plant op basis van het totale aantal Kubernetes-knooppunten en dat u ten minste drie meer IP-adressen opneemt die tijdens het upgradeproces worden gebruikt. Voor de configuratie van statische IP-adressen moet u het IP-adresbereik van het Kubernetes-knooppunt opgeven. Dit is niet nodig voor DHCP-toewijzing. Plan aanvullende IP-adressen voor:

• De KVA-VM gebruikt ook meer IP-adres voor Kubernetes uit de IP-adresgroep van het Kubernetes-knooppunt. Plan om IP-adressen toe te voegen tijdens het updateproces, omdat de KVA-VM hetzelfde virtuele IP-adres gebruikt voor de API-service, maar een afzonderlijk IP-adres vereist van de KUbernetes-knooppunt-VM-pool.
• VM's in het besturingsvlak gebruiken één IP-adres uit de KUbernetes-knooppunt-VM-adresgroep voor de API-serverservice. Deze virtuele machines hosten ook de Azure ARC-agent die verbinding maakt met Azure Portal voor beheerdoeleinden.
• Knooppunten in een knooppuntgroep (Linux of Windows) verbruiken IP-adressen uit de IP-pool die is toegewezen voor de Kubernetes-knooppunt-VM.

On-premises cloudservice van Microsoft

Plan ip-adresbereik voor microsoft on-premises cloud (MOC) waarmee beheerstacks worden ingeschakeld, zodat de VM's in Azure Stack HCI worden beheerd in de cloud. De IP-adrestoewijzing voor de MOC-service bevindt zich in het onderliggende fysieke netwerk en de IP-adressen die zijn geconfigureerd voor de Azure Stack HCI-clusterknooppunten bevinden zich in uw datacenter. U kunt OP een van de volgende manieren IP-adressen configureren voor de fysieke knooppunten van uw Azure Stack HCI:

• Azure Stack HCI-clusterknooppunten met een IP-adrestoewijzingsmodus op basis van DHCP. DE MOC-service haalt een IP-adres op van de DHCP-service die wordt weergegeven in het fysieke netwerk.
• Azure Stack HCI-clusterknooppunten met een statisch IP-toewijzingsmodel. Het IP-adres voor de MOC-cloudservice moet expliciet worden opgegeven als een IP-bereik in CIDR-indeling (Classless Inter-Domain Routing) en moet zich in hetzelfde subnet bevinden als de IP-adressen van Azure Stack HCI-clusterknooppunten.

Load balancer in AKS on Azure Stack HCI

Voor een kleine implementatie kunt u de ingebouwde load balancer gebruiken, geïmplementeerd als een Linux-VM die gebruikmaakt van HAProxy + KeepAlive om verkeer te verzenden naar toepassingsservices die zijn geïmplementeerd als onderdeel van het AKS-cluster. HaProxy load balancer configureert pods als eindpunten in de load balancer. Hiermee worden aanvragen naar de Kubernetes API-server geladen en wordt verkeer naar toepassingsservices beheerd.

U kunt ook een aangepaste load balancer gebruiken om verkeer naar uw services te beheren. De aangepaste load balancer biedt extra flexibiliteit voor de implementatie en zorgt ervoor dat AKS in Azure Stack HCI naast bestaande implementaties zoals SDN-implementaties (Software Defined Network) werkt die gebruikmaken van load balancers. Voor aangepaste load balancers biedt kube-virtual IP Kubernetes-clusters met een virtueel IP-adres en een load balancer voor zowel het besturingsvlak als kubernetes Services van het type LoadBalancer. De kube-virtual IP-service wordt automatisch geïmplementeerd op elk werkknooppunt.

AKS op Azure Stack HCI ondersteunt ook het gebruik van MetalLB of andere OSS Kubernetes-load balancers om verkeer te verdelen dat is bestemd voor services in een workloadcluster. MetalLB is een load balancer-implementatie voor bare-metal Kubernetes-clusters, met behulp van standaardrouteringsprotocollen, zoals BGP van het Border Gateway-protocol. Het kan werken met zowel netwerkinvoegtoepassingen, Calico als Flannel, maar u moet ervoor zorgen dat het virtuele IP-adresbereik dat tijdens de installatie van AKS op Azure Stack HCI is opgegeven, niet overlapt met het IP-adresbereik dat is gepland voor de aangepaste load balancer.

Dit scenario implementeren

Een ingangscontroller implementeren

Overweeg om een ingangscontroller te implementeren voor TLS-beëindiging, omkeerbare proxy of configureerbare verkeersroutering. Toegangsbeheerobjectcontrollers werken op Laag 7 en kunnen intelligente regels gebruiken om toepassingsverkeer te distribueren. Kubernetes-resources voor inkomend verkeer worden gebruikt om de regels en routes voor uitgaand verkeer worden geconfigureerd voor individuele Kubernetes-services. Wanneer u een ingangscontroller definieert, voegt u de regels voor verkeersroutering samen in één resource die wordt uitgevoerd als onderdeel van uw cluster.

Gebruik een controller voor inkomend verkeer om services beschikbaar te maken via extern bereikbare URL's. Inkomend verkeer toont HTTP- en HTTPS-routes van buiten het cluster naar services binnen het cluster. Verkeersroutering wordt beheerd door regels die zijn gedefinieerd voor de toegangsbeheerobjectresource. De HTTP-regels voor inkomend verkeer bevatten de volgende informatie:

• Een optionele host. Als u geen hostgegevens opgeeft, wordt de regel toegepast op al het binnenkomende HTTP-verkeer.
• Een lijst met paden met een gekoppelde back-end die is gedefinieerd met een service.name en een service.port.name of service.port.number.
• Een back-end die een combinatie van service- en poortnamen biedt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

Gebruik een ingangscontroller om het verkeer tussen verschillende back-ends van de toepassing te verdelen. Het verkeer wordt gesplitst en verzonden naar verschillende service-eindpunten en implementaties, op basis van de padgegevens.

Als u HTTP-verkeer wilt routeren naar meerdere hostnamen op hetzelfde IP-adres, kunt u voor elke host een andere toegangsbeheerobjectresource gebruiken. Het verkeer dat via het IP-adres van de load balancer wordt geleverd, wordt gerouteerd op basis van de hostnaam en het pad dat is opgegeven in de regel voor inkomend verkeer.

Concepten van containernetwerken in Azure Kubernetes Service (AKS) in Azure Stack HCI

Kubernetes biedt een abstractielaag voor een virtueel netwerk, zodat de containertoepassingen intern of extern kunnen communiceren. Het kube-proxyonderdeel wordt uitgevoerd op elk knooppunt en kan directe toegang bieden tot de service, verkeer distribueren met behulp van load balances of toegangsbeheerobjectcontrollers gebruiken voor complexere routering van toepassingen. Kubernetes gebruikt services om een set pods logisch te groeperen en netwerkconnectiviteit te bieden. De volgende Kubernetes-services zijn beschikbaar:

• Cluster-IP: Deze service maakt een intern IP-adres voor toepassingen die alleen intern zijn.
• NodePort: Deze service maakt poorttoewijzing op het onderliggende knooppunt, waardoor de toepassing rechtstreeks toegankelijk is met het IP-adres en de poort van het knooppunt.
• LoadBalancer: U kunt Kubernetes-services extern beschikbaar maken met behulp van load balancer-regels of een controller voor inkomend verkeer.
• ExternalName:. Deze service maakt gebruik van een specifieke DNS-vermelding voor de Kubernetes-toepassing.

Kubernetes-netwerken

In AKS in Azure Stack HCI kan het cluster worden geïmplementeerd met behulp van een van de volgende netwerkmodellen:

• Project Calico-netwerken. Dit is een standaardnetwerkmodel voor AKS in Azure Stack HCI en is gebaseerd op een opensource-netwerk dat netwerkbeveiliging biedt voor containers, virtuele machines en systeemeigen hostworkloads. Calico-netwerkbeleid kan worden toegepast op elk type eindpunt, zoals pods, containers, VM's of hostinterfaces. Elk beleid bestaat uit regels waarmee inkomend en uitgaand verkeer wordt beheerd met behulp van acties die het verkeer tussen bron- en doeleindpunten kunnen toestaan, weigeren, registreren of doorgeven. Calico kan linux uitgebreide Berkeley Packet Filter (eBPF) of Linux-kernelnetwerkpijplijn gebruiken voor het leveren van verkeer. Calico wordt ook ondersteund in Windows met behulp van Host Networking Service (HNS) voor het maken van netwerknaamruimten per containereindpunt. In het Kubernetes-netwerkmodel krijgt elke pod een eigen IP-adres dat wordt gedeeld tussen containers binnen die pod. Pods communiceren op het netwerk met behulp van IP-adressen van pods en de isolatie wordt gedefinieerd met behulp van netwerkbeleid. Calico gebruikt CNI-invoegtoepassingen (Container Network Interface) voor het toevoegen of verwijderen van pods naar en van het Kubernetes-podnetwerk en CNI IPAM-invoegtoepassingen (IP-adresbeheer) voor het toewijzen en vrijgeven van IP-adressen.
• Flannel-overlaynetwerken. Flannel maakt een virtuele netwerklaag die het hostnetwerk overlays. Overlaynetwerken maken gebruik van inkapseling van de netwerkpakketten via het bestaande fysieke netwerk. Flannel vereenvoudigt IP-adresbeheer (IPAM), ondersteunt het hergebruik van IP tussen verschillende toepassingen en naamruimten en biedt logische scheiding van containernetwerken van het onderliggende netwerk dat wordt gebruikt door de Kubernetes-knooppunten. Netwerkisolatie wordt bereikt met behulp van Virtual eXtensible Local Area Network (VXLAN), een inkapselingsprotocol dat datacentrumconnectiviteit biedt met tunneling om laag 2-verbindingen uit te rekken via een onderliggend Laag 3-netwerk. Flannel wordt ondersteund door Linux-containers met behulp van DaemonSet - en Windows-containers met behulp van de Flannel CNI-invoegtoepassing.

Azure Stack HCI-netwerkontwerp

Het algemene netwerkontwerp omvat planningsactiviteiten voor de Azure Stack HCI.

Begin eerst met het plannen van de hardware en installatie van Azure Stack HCI. U kunt geïntegreerde systemen aanschaffen bij een Microsoft-hardwarepartner met het Vooraf geïnstalleerde Azure Stack HCI-besturingssysteem, of u kunt gevalideerde knooppunten kopen en het besturingssysteem zelf installeren. Azure Stack HCI is bedoeld als een virtualisatiehost, dus Kubernetes-serverfuncties moeten worden uitgevoerd binnen VM's.

Vereisten voor fysiek netwerk voor Azure Stack HCI

Microsoft certificeert geen netwerkswitches, maar er zijn bepaalde vereisten waaraan de leverancier van de apparatuur moet voldoen:

• Standaard: IEEE 802.1Q die een VLAN (Virtual Local Area Network) definieert.
• Standaard: IEEE 802.1Qbb waarmee Priority Flow Control (PFC) wordt gedefinieerd.
• Standaard: IEEE 802.1Qaz die Enhanced Transmission Selection (ETS) definieert.
• Standaard: IEEE 802.1AB waarmee het LLTD-protocol (Link Layer Topology Discovery) wordt gedefinieerd.

Hostnetwerkvereisten voor Azure Stack HCI

Overweeg het gebruik van een netwerkadapter die de SDDC-certificering (Software Defined Data Center) van Windows Server heeft bereikt met de Standard- of Premium Additional Qualification (AQ).

Zorg ervoor dat de netwerkadapter ondersteuning biedt voor:

• Dynamische virtuele machine multiwachtrij (dynamische VMMQ of d.VMMQ) is een intelligente technologie aan de ontvangstzijde voor het automatisch afstemmen van netwerkverkeersverwerking naar CPU-kernen.
• Remote Direct Memory Access (RDMA) is een netwerkstack-offload naar de netwerkadapter. Hiermee kan SMB-opslagverkeer het besturingssysteem omzeilen voor verwerking.
• Met gast-RDMA kunnen SMB-workloads voor VM's dezelfde voordelen krijgen als het gebruik van RDMA op hosts.
• Switch Embedded Teaming (SET) is een softwaregebaseerde teamtechnologie.

Overweeg het gebruik van Network ATC, dat op intentie gebaseerde controle biedt om de configuratie van hostnetwerken te vereenvoudigen.

AKS op een Azure Stack HCI vereist een betrouwbare netwerkverbinding met hoge bandbreedte en lage latentie tussen elk serverknooppunt. Zorg ervoor dat ten minste één netwerkadapter beschikbaar is en toegewezen is voor clusterbeheer. Controleer ook of fysieke switches in uw netwerk zijn geconfigureerd om verkeer toe te staan op alle VLAN's die u gaat gebruiken.

Virtuele switch

Azure Stack HCI vereenvoudigt het netwerkontwerp door een virtuele switch te configureren die kan worden gebruikt voor netwerkclassificatie. De virtuele netwerkinterfacekaart (vNIC) kan worden geplaatst in verschillende VLAN's voor de hosts om verschillende verkeersstroom voor de volgende netwerken te bieden:

• Beheernetwerk. Het beheernetwerk maakt deel uit van het noord-zuid-netwerk en wordt gebruikt voor hostcommunicatie.
• Rekennetwerk. Het rekennetwerk maakt deel uit van het noord-zuid-netwerk en wordt gebruikt voor verkeer van virtuele machines. Gebruik QOS (Quality of Service), I/O-virtualisatie met één hoofdmap (SR-IOV) en virtuele Remote Direct Memory Access (vRDMA) om de netwerkprestaties af te stemmen op basis van de vraag.
• Opslagnetwerk. Het opslagnetwerk maakt deel uit van het oost-west-netwerk en vereist RDMA met aanbevolen doorvoer 10 GB+. Deze wordt gebruikt voor livemigratie van de VM's.
• VM-gastnetwerk.

Oost-West-verkeer voordeel van RDMA-verkeer

Netwerkverkeer oost-west vertegenwoordigt communicatie tussen de hosts en biedt geen externe toegang. Verkeer blijft binnen de ToR-switch (Top of Rack) en laag-2-grens. Het bevat de volgende typen verkeer:

• Cluster-heartbeats en communicatie tussen knooppunten
• [SMB] Opslagbuslaag
• [SMB] Gedeeld clustervolume
• [SMB] Opslag opnieuw opbouwen

Noord-Zuid verkeer

Noord-Zuid-verkeer is het externe verkeer dat de AKS bereikt in het Azure Stack HCI-cluster. U kunt het verkeer plannen voor het scala aan Azure-services dat bewaking, facturering en beveiligingsbeheer mogelijk maakt via de integratie van Azure ARC. Het noord-zuidverkeer heeft de volgende kenmerken:

• Verkeer stroomt uit een ToR-switch naar de ruggengraat of van de rug naar een ToR-switch.
• Verkeer verlaat het fysieke rek of overschrijdt een laag-3-grens (IP).
• Verkeer omvat beheer (PowerShell, Windows Admin Center), compute (VM) en stretched clusterverkeer tussen sites.
• Maakt gebruik van een Ethernet-switch voor connectiviteit met het fysieke netwerk.

AKS in Azure Stack HCI kan verschillende implementatieopties voor het clusternetwerk gebruiken:

• Geconvergeerd netwerk waarbij meerdere netwerkintenties (MGMT, Compute, Storage) worden gecombineerd. Dit is de aanbevolen implementatie voor meer dan drie fysieke knooppunten en vereist dat alle fysieke netwerkadapters zijn verbonden met dezelfde ToR-switches. ROCEv2 wordt ten zeerste aanbevolen.
• Switchless implementatie maakt gebruik van Noord-Zuid-communicatie als netwerkteam door reken- en beheernetwerken te combineren.
• Hybride implementatie als combinatie van beide implementaties.

Aanbevelingen

De volgende aanbevelingen gelden voor de meeste scenario's. Volg de aanbevelingen, tenzij u een specifieke vereiste hebt die deze overschrijft.

Netwerkaanbevelingen

Het belangrijkste probleem in het netwerkontwerp voor de AKS in Azure Stack HCI is het selecteren van een netwerkmodel dat voldoende IP-adressen biedt voor uw Kubernetes-cluster en de bijbehorende services en toepassingen.

• Overweeg om statische IP-adressen te implementeren zodat AKS in Azure Stack HCI de TOEWIJZING van het IP-adres kan beheren.

• Dimensie de IP-adresbereiken correct, zodat u voldoende vrije IP-adressen hebt voor een Kubernetes-knooppuntgroep en voor een virtuele IP-pool. Zorg ervoor dat uw virtuele IP-adresgroep groot genoeg is, zodat wanneer u een upgrade uitvoert, u rolling upgrades kunt gebruiken, waarvoor meer IP-adressen nodig zijn. U kunt het volgende plannen:

  • Adressering/hostnamen voor proxy-instellingen
  • IP-adressen voor het doelclusterbesturingsvlak
  • IP-adressen voor Azure ARC
  • IP-adressen voor horizontaal schalen van werkrol- en besturingsvlakknooppunten in doelclusters

• Uw virtuele IP-adresgroep moet groot genoeg zijn om de implementatie van de toepassingsservices te ondersteunen die verbinding met de externe router vereisen.

• Implementeer Calico CNI om verbeterd netwerkbeleid te bieden voor het beheren van de pod- en toepassingscommunicatie.

• Zorg ervoor dat de fysieke clusterknooppunten (HCI of Windows Server) zich in hetzelfde rek bevinden en zijn verbonden met dezelfde ToR-switches.

• Schakel IPv6 uit op alle netwerkadapters.

• Zorg ervoor dat de bestaande virtuele switch en de naam hetzelfde zijn voor alle clusterknooppunten.

• Controleer of alle subnetten die u voor uw cluster definieert, tussen elkaar en op internet routeerbaar zijn.

• Zorg ervoor dat er netwerkconnectiviteit is tussen Azure Stack HCI-hosts en de tenant-VM's.

• Schakel dynamische DNS-updates in uw DNS-omgeving in om AKS in Azure Stack HCI de algemene clusternaam van de cloudagent te registreren in het DNS-systeem voor detectie.

• Overweeg het implementeren van classificatie van het netwerkverkeer op basis van de richting:

  • Noord-Zuid-verkeer is het verkeer van Azure Stack HCI en de rest van het netwerk,
    • Beheer
    • Compute
    • Stretched clusterverkeer tussen sites
  • Oost-West-verkeer binnen Azure Stack HCI:
    • Opslagverkeer, inclusief livemigratie tussen knooppunten in hetzelfde cluster.
    • Ethernet-switch of directe verbinding.

Modellen voor opslagverkeer

• Gebruik meerdere subnetten en VLAN's om opslagverkeer in Azure Stack HCI te scheiden.
• Overweeg de toewijzing van verkeersbandbreedte van verschillende verkeerstypen te implementeren.

Overwegingen

Het Microsoft Azure Well-Architected Framework is een reeks richtlijnen die in dit scenario worden gevolgd. De volgende overwegingen worden in de context van deze tenets omkaderd.

Betrouwbaarheid

• Ingebouwde tolerantie, inherent aan softwaregedefinieerde berekening van Microsoft (failovercluster van Hyper-V-knooppunten), opslag (Opslagruimten Direct geneste tolerantie) en netwerken (Software Defined Networking).
• Overweeg de netwerkswitch te selecteren die industriestandaarden ondersteunt en zorgt voor betrouwbare communicatie tussen knooppunten. De volgende standaarden zijn:
  • Standaard: IEEE 802.1Q
  • Standaard IEEE 802.1Qbb
  • Standaard IEEE 802.1 Qas
  • Standaard IEEE 802.1 AB
• Overweeg om meerdere hosts in het beheercluster en in het Kubernetes-cluster te implementeren om te voldoen aan het minimale beschikbaarheidsniveau voor workloads.
• AKS in Azure Stack HCI maakt gebruik van failoverclustering en livemigratie voor hoge beschikbaarheid en fouttolerantie. Livemigratie is een Hyper-V-functie waarmee u actieve virtuele machines transparant van de ene Hyper-V-host naar een andere kunt verplaatsen zonder dat er sprake is van downtime.
• Zorg ervoor dat services waarnaar wordt verwezen in de sectie Architectuur worden ondersteund in de regio waarnaar Azure Arc wordt geïmplementeerd.

Beveiliging

• Beveilig verkeer tussen pods met behulp van netwerkbeleid in AKS in Azure Stack HCI.
• De API-server in AKS op Azure Stack HCI bevat de certificeringsinstantie die certificaten ondertekent voor communicatie van de Kubernetes-API-server naar kubelet.
• Gebruik Eenmalige aanmelding (SSO) van Microsoft Entra om een beveiligde verbinding met de Kubernetes API-server te maken.
• U kunt Azure RBAC gebruiken om de toegang tot Kubernetes met Azure Arc in Azure en on-premises omgevingen te beheren met behulp van Microsoft Entra-identiteiten. Zie Azure RBAC gebruiken voor Kubernetes-autorisatie voor meer informatie.

Kostenoptimalisatie

• Gebruik de Azure-prijscalculator om de kosten te schatten voor de services die in de architectuur worden gebruikt. Andere aanbevolen procedures worden beschreven in de sectie Kostenoptimalisatie in Microsoft Azure Well-Architected Framework.
• Overweeg hyperthreading op uw fysieke computer te implementeren om de kosten te optimaliseren, omdat de AKS in Azure Stack HCI-factureringseenheid een virtuele kern is.
• Azure Arc-besturingsvlakfunctionaliteit wordt zonder extra kosten geboden. Dit omvat ondersteuning voor resourceorganisatie via Azure-beheergroepen en -tags en toegangsbeheer via Azure RBAC. Voor Azure-services die worden gebruikt in combinatie met servers met Azure Arc, worden kosten in rekening gebracht op basis van hun gebruik.
• Voor kosteneffectiviteit kunt u slechts twee clusterknooppunten met slechts vier schijven en 64 GB geheugen per knooppunt gebruiken. Als u de kosten verder wilt minimaliseren, kunt u switchloze interconnects tussen knooppunten gebruiken, waardoor redundante switchapparaten niet meer nodig zijn.

Operationele uitmuntendheid

• Vereenvoudigd beheer met behulp van Het Windows-beheercentrum. Windows Admin Center is de gebruikersinterface voor het maken en beheren van AKS in Azure Stack HCI. Het kan worden geïnstalleerd op Windows 10/11 of Windows Server-VM die moet worden geregistreerd in Azure en zich in hetzelfde domein bevinden als het Azure Stack HCI- of Windows Server Datacenter-cluster.
• Integratie met Azure Arc of een reeks Azure-services die meer beheer-, onderhouds- en tolerantiemogelijkheden bieden (Azure Monitor, Azure Backup).
• Als uw Kubernetes-cluster is gekoppeld aan Azure Arc, kunt u uw Kubernetes-cluster beheren met behulp van GitOps. Als u de aanbevolen procedures voor het verbinden van een hybride Kubernetes-cluster met Azure Arc wilt bekijken, raadpleegt u het scenario voor hybride beheer en implementatie van Azure Arc voor Kubernetes-clusters .
• Het Azure Stack HCI-platform helpt ook om virtuele netwerken voor AKS op Azure Stack HCI-clusters te vereenvoudigen door het onderliggende netwerk op een maximaal beschikbare manier te bieden.

Prestatie-efficiëntie

• Gebruik gecertificeerde Hardware van Azure Stack HCI voor verbeterde uptime en prestaties van toepassingen, vereenvoudigd beheer en bewerkingen en lagere totale eigendomskosten.
• Opslag: Opslagruimten Direct
  • Volumeconfiguratie (geneste tweerichtingsspiegel versus geneste pariteit met gespiegelde spiegel)
  • Schijfconfiguratie (caching, lagen)
• Zorg ervoor dat de clusterknooppunten zich fysiek in hetzelfde rek bevinden en zijn verbonden met dezelfde ToR-switches.
• Plan IP-adresreserveringen voor het configureren van AKS-hosts, workloadclusters, cluster-API-servers, Kubernetes Services en toepassingsservices. Microsoft raadt aan minimaal 256 IP-adressen te reserveren voor AKS-implementatie in Azure Stack HCI.
• Overweeg om een ingangscontroller te implementeren die op laag 7 werkt en intelligentere regels gebruikt om toepassingsverkeer te distribueren.
• Gebruik GPU-versnelling (Graphics Processing Unit) voor uitgebreide workloads.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

• Lisa DenBeste | ProjectManagement Program Manager
• Kenny Harder | Projectmanager
• Mike Kostersitz | Principal Program Manager Lead
• Meg Olsen | Voornaamste
• Nate Waters | Product Marketing Manager

Andere Inzenders:

• Walter Oliver | Senior Program Manager

Volgende stappen

• Overzicht van AKS

Verwante resources

• Basislijnarchitectuur voor AKS in Azure Stack HCI