Redigera

Dela via

Nätverksarkitektur för AKS på Azure Stack HCI

Azure Stack HCI
Windows Server

Det här scenariot visar hur du utformar och implementerar nätverksbegrepp för distribution av AKS-noder (Azure Kubernetes Service) i AKS-kluster.

Den här artikeln innehåller rekommendationer för nätverksdesign för Kubernetes-noder och Kubernetes-containrar. Det är en del av en vägledningsuppsättning för arkitekturbaslinjer med två artiklar. Se rekommendationer för baslinjearkitektur här.

Viktigt!

Informationen i den här artikeln gäller för AKS på Azure Stack HCI version 22H2 och AKS-HCI på Windows Server. Den senaste versionen av AKS körs på Azure Stack HCI 23H2. Mer information om den senaste versionen finns i dokumentationen om AKS på Azure Stack HCI version 23H2.

Arkitektur

Följande bild visar nätverksarkitekturen för Azure Kubernetes Service på Azure Stack HCI eller Windows Server 2019/2022 datacenterkluster:

Konceptuell bild som visar nätverksbaslinjearkitektur.

Ladda ned en Visio-fil med den här arkitekturen.

Scenariot består av följande komponenter och funktioner:

  • Azure Stack HCI (22H2) är en klusterlösning för hyperkonvergerad infrastruktur (HCI) som är värd för virtualiserade Windows- och Linux-arbetsbelastningar och deras lagring i en lokal hybridmiljö. Azure Stack HCI-kluster implementeras som ett 2–4-nodkluster.
  • Windows Server 2019/2022 datacenter redundanskluster är en grupp oberoende datorer som arbetar tillsammans för att öka tillgängligheten och skalbarheten för klustrade roller.
  • Azure Kubernetes Service på Azure Stack HCI är en lokal implementering av Azure Kubernetes Service (AKS), som automatiserar körningen av containerbaserade program i stor skala.
  • Active Directory-domän Services är en hierarkisk struktur som lagrar information om objekt i nätverket. Den tillhandahåller identitets- och åtkomstlösning för identiteter som är associerade med användare, datorer, program eller andra resurser som ingår i en säkerhetsgräns.
  • Hanteringskluster som även kallas AKS-värd ansvarar för att distribuera och hantera flera arbetsbelastningskluster. Hanteringsklustret använder en IP-adress från nodpoolen, men du bör reservera ytterligare två IP-adresser för uppdateringsåtgärder. Hanteringsklustret förbrukar också en IP-adress från VIP-poolen.
  • Arbetsbelastningskluster är en distribution med hög tillgänglighet av Kubernetes med virtuella Linux-datorer för att köra Kubernetes-kontrollplanskomponenter och Linux- och/eller Windows-arbetsnoder.
    • Kontrollplan. Körs på en Linux-distribution och innehåller API-serverkomponenter för interaktion med Kubernetes API och ett distribuerat nyckelvärdeslager osv. för lagring av alla konfigurationer och data i klustret. Den förbrukar en IP-adress från nodpoolen och en IP-adress från VIP-poolen.
    • Lastbalanserare. Körs på en virtuell Linux-dator och tillhandahåller belastningsutjämningstjänster för arbetsbelastningsklustret. Den förbrukar en IP-adress från nodpoolen och en IP-adress från VIP-poolen.
    • Arbetsnoder. Kör på ett Windows- eller Linux-operativsystem som är värd för containerbaserade program. Den använder IP-adresser från nodpoolen, men du bör planera minst tre IP-adresser till för uppdateringsåtgärder.
    • Kubernetes-resurser. Poddar representerar en enda instans av ditt program, som vanligtvis har en 1:1-mappning med en container, men vissa poddar kan innehålla flera containrar. Distributioner representerar en eller flera identiska poddar. Poddar och distributioner grupperas logiskt i ett namnområde som styr åtkomsten till hanteringen av resurserna. De förbrukar 1 IP per podd från VIP-poolen.
  • Azure Arc är en molnbaserad tjänst som utökar den Azure Resource Manager-baserade hanteringsmodellen till icke-Azure-resurser, inklusive virtuella datorer, Kubernetes-kluster och containerbaserade databaser.
  • Azure Policy är en molnbaserad tjänst som utvärderar Azure och lokala resurser genom integrering med Azure Arc genom att jämföra egenskaper med anpassningsbara affärsregler.
  • Azure Monitor är en molnbaserad tjänst som maximerar tillgängligheten och prestandan för dina program och tjänster genom att leverera en omfattande lösning för att samla in, analysera och agera på telemetri från dina molnmiljöer och lokala miljöer.
  • Microsoft Defender för molnet är ett enhetligt säkerhetshanteringssystem för infrastruktur som stärker säkerhetsstatusen för dina datacenter och ger avancerat skydd mot hot i dina hybridarbetsbelastningar i molnet och lokalt.

Komponenter

Information om scenario

Användningsfallen för det här scenariot beskrivs i den första artikeln i serien, Baslinjearkitektur.

Kubernetes-nodnätverk

Det viktigaste i nätverksdesignen för AKS på Azure Stack HCI är att välja den nätverksmodell som ger tillräckligt med IP-adresser. AKS på Azure Stack HCI använder virtuella nätverk för att allokera IP-adresser till Kubernetes-nodresurserna. Du kan använda två IP-adresstilldelningsmodeller:

  • Statiska IP-nätverk är mer förutsägbara men lägger extra arbete på den inledande konfigurationen.
  • DHCP-nätverk (Dynamic Host Configuration Protocol) använder dynamisk allokering av IP-adresser och mindre arbete, men du måste vara noga med att inte uttömma den tillgängliga poolen med IP-adresser. Du måste också hantera reservationer och undantagsintervall för virtuella IP-pooler och vissa klusteromfattande resurser som molnagenttjänsten.

Båda tilldelningsmodellerna måste planera IP-adresser för:

  • Virtuell IP-pool
  • IP-pool för kubernetes-nod

Virtuell IP-pool

En virtuell IP-pool är en uppsättning IP-adresser som är obligatoriska för alla AKS på Azure Stack HCI-distribution. Planera antalet IP-adresser i den virtuella IP-poolen baserat på antalet arbetsbelastningskluster och Kubernetes-tjänster. Den virtuella IP-poolen tillhandahåller IP-adresser för följande typer av resurser:

  • Molnagenten kräver en flytande IP-adress från den virtuella IP-poolen.

  • API-serverkomponenten som körs i den virtuella Kubernetes-installationen (KVA) (hanteringsklustret) använder en IP-adress från den virtuella IP-poolen. API-servern är en komponent i Kubernetes-kontrollplanet som exponerar Kubernetes-API:et. API-servern är klientdelen för Kubernetes-kontrollplanet. KVA är en virtuell dator som kör Mariner Linux och är värd för ett Kubernetes-kluster. IP-adressen är flytande och används även för andra virtuella KVA-datorer som du distribuerar i AKS på Azure Stack HCI. Den virtuella KVA-datorn är också värd för en kubernetes-tjänst för virtuell IP-lastbalanserare.

  • Planera IP-adressering för antalet virtuella kontrollplansdatorer som distribueras på målservrarna, eftersom de också förbrukar fler IP-adresser från den virtuella IP-poolen. Överväganden beskrivs i nästa avsnitt.

  • Målklustret innehåller en virtuell dator för lastbalanserare, som är HAProxy och äger den virtuella IP-poolen för målklustret. Den här virtuella datorn exponerar alla Kubernetes-tjänster via den virtuella IP-poolen.

  • Program som körs i Kubernetes-poddar använder IP-adresser från den virtuella IP-poolen.

  • HAProxy-lastbalanseraren distribueras som en specialiserad virtuell dator och kan användas för att belastningsutjämning av inkommande begäranden över flera slutpunkter. De använder IP-adresser från den virtuella IP-poolen och du måste planera IP-adressering för varje arbetsbelastningskluster.

IP-pool för kubernetes-nod

Kubernetes-noder distribueras som virtuella datorer i en AKS på Azure Stack HCI-distribution. Se till att du planerar antalet IP-adresser enligt det totala antalet Kubernetes-noder och inkluderar minst tre IP-adresser till som används under uppgraderingsprocessen. För konfiguration av statisk IP-adress måste du ange IP-poolintervallet för den virtuella Kubernetes-nodens VM, detta är inte nödvändigt för DHCP-allokering. Planera ytterligare IP-adresser för:

  • Den virtuella KVA-datorn använder också mer IP-adress för Kubernetes från IP-poolen för den virtuella Kubernetes-noden. Planera att lägga till IP-adresser under uppdateringsprocessen eftersom den virtuella KVA-datorn använder samma virtuella IP-adress för API-tjänsten, men kräver en separat IP-adress från IP-poolen för den virtuella Kubernetes-noden.
  • Virtuella Kontrollplansdatorer använder en IP-adress från KUBernetes-nodens VM-IP-pool för API-servertjänsten. Dessa virtuella datorer är också värdar för Azure ARC-agenten som ansluter till Azure Portal i hanteringssyfte.
  • Noder i en nodpool (Linux eller Windows) använder IP-adresser från DEN IP-pool som allokerats för den virtuella Kubernetes-nodddatorn.

Microsofts lokala molntjänst

Planera IP-adressintervall för Microsofts lokala moln (MOC), som möjliggör hanteringsstack så att de virtuella datorerna på Azure Stack HCI hanteras i molnet. IP-adressallokeringen för MOC-tjänsten finns i det underliggande fysiska nätverket och IP-adresserna som konfigurerats för Azure Stack HCI-klusternoderna finns i ditt datacenter. Du kan konfigurera IP-adresser för de fysiska noderna i din Azure Stack HCI i något av följande:

  • Azure Stack HCI-klusternoder med ett DHCP-baserat IP-adressallokeringsläge. MOC-tjänsten hämtar en IP-adress från DHCP-tjänsten som visas i det fysiska nätverket.
  • Azure Stack HCI-klusternoder med en statisk IP-allokeringsmodell. IP-adressen för MOC-molntjänsten måste uttryckligen anges som ett IP-intervall i CIDR-format (Classless Inter-Domain Routing) och måste finnas i samma undernät som IP-adresserna för Azure Stack HCI-klusternoder.

Lastbalanserare i AKS på Azure Stack HCI

För en liten distribution kan du använda den inbyggda lastbalanseraren som distribueras som en virtuell Linux-dator som använder HAProxy + KeepAlive för att skicka trafik till programtjänster som distribueras som en del av AKS-klustret. HAProxy-lastbalanseraren konfigurerar poddar som slutpunkter i lastbalanseraren. Den läser in saldobegäranden till Kubernetes API-servern och hanterar trafik till programtjänster.

Du kan också använda en anpassad lastbalanserare för att hantera trafik till dina tjänster. Den anpassade lastbalanseraren ger ökad flexibilitet i distributionen och ser till att AKS på Azure Stack HCI fungerar tillsammans med befintliga distributioner som SDN-distributioner (Software Defined Network) som använder lastbalanserare. För anpassade lastbalanserare tillhandahåller kube-virtual IP Kubernetes-kluster med en virtuell IP-adress och lastbalanserare för både kontrollplanet och Kubernetes Services av typen LoadBalancer. Den kube-virtuella IP-tjänsten distribueras automatiskt på varje arbetsnod.

AKS på Azure Stack HCI stöder också användning av MetalLB eller andra OSS Kubernetes-baserade lastbalanserare för att balansera trafik som är avsedd för tjänster i ett arbetsbelastningskluster. MetalLB är en lastbalanserareimplementering för Kubernetes-kluster utan operativsystem, med hjälp av standarddirigeringsprotokoll, till exempel BGP för Border Gateway-protokoll. Det kan fungera med både nätverkstillägg, Calico och Flannel, men du måste se till att det virtuella IP-adressintervallet som angavs under installationen av AKS på Azure Stack HCI inte överlappar det IP-adressintervall som planeras för den anpassade lastbalanseraren.

Distribuera det här scenariot

Distribuera en ingresskontrollant

Överväg att implementera en ingresskontrollant för TLS-avslutning, reversibel proxy eller konfigurerbar trafikroutning. Ingresskontrollanter fungerar på Layer 7 och kan använda intelligenta regler för att distribuera programtrafik. Kubernetes ingress-resurser används för att konfigurera inkommande regler och vägar för enskilda Kubernetes-tjänster. När du definierar en ingresskontrollant konsoliderar du trafikdirigeringsreglerna till en enda resurs som körs som en del av klustret.

Använd en ingresskontrollant för att exponera tjänster via url:er som kan nås externt. Ingress exponerar HTTP- och HTTPS-vägar utanför klustret för tjänster i klustret. Trafikroutning styrs av regler som definierats för ingressresursen. Ingressens HTTP-regler innehåller följande information:

  • En valfri värd. Om du inte anger värdinformation tillämpas regeln på all inkommande HTTP-trafik.
  • En lista över sökvägar som har en associerad serverdel definierad med en service.name och en service.port.name eller service.port.number.
  • En serverdel som ger en kombination av tjänst- och portnamn.
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

Använd en ingresskontrollant för att balansera trafiken mellan olika serverdelar i programmet. Trafiken delas upp och skickas till olika tjänstslutpunkter och distributioner baserat på sökvägsinformationen.

Om du vill dirigera HTTP-trafik till flera värdnamn på samma IP-adress kan du använda en annan ingressresurs för varje värd. Trafiken som kommer via lastbalanserarens IP-adress dirigeras baserat på värdnamnet och sökvägen som anges i ingressregeln.

Begrepp för nätverk för containrar i Azure Kubernetes Service (AKS) i Azure Stack HCI

Kubernetes tillhandahåller ett abstraktionslager till ett virtuellt nätverk, så att de containerbaserade programmen kan kommunicera internt eller externt. Kube-proxykomponenten körs på varje nod och kan antingen ge direkt åtkomst till tjänsten, distribuera trafik med lastbalanser eller använda ingresskontrollanter för mer komplex programroutning. Kubernetes använder tjänster för att logiskt gruppera en uppsättning poddar och tillhandahålla nätverksanslutning. Följande Kubernetes-tjänster är tillgängliga:

  • Kluster-IP: Den här tjänsten skapar en intern IP-adress för interna program.
  • NodePort: Den här tjänsten skapar portmappning på den underliggande noden, vilket gör programmet direkt tillgängligt med nodens IP-adress och port.
  • LoadBalancer: Du kan exponera Kubernetes-tjänster externt med hjälp av regler för lastbalanserare eller en ingresskontrollant.
  • ExternalName:. Den här tjänsten använder en specifik DNS-post för Kubernetes-programmet.

Kubernetes-nätverk

I AKS på Azure Stack HCI kan klustret distribueras med någon av följande nätverksmodeller:

  • Project Calico-nätverk. Detta är en standardnätverksmodell för AKS på Azure Stack HCI och baseras på ett nätverk med öppen källkod som ger nätverkssäkerhet för containrar, virtuella datorer och interna värdbaserade arbetsbelastningar. Calico-nätverksprincip kan tillämpas på alla typer av slutpunkter, till exempel poddar, containrar, virtuella datorer eller värdgränssnitt. Varje princip består av regler som styr inkommande och utgående trafik med hjälp av åtgärder som antingen kan tillåta, neka, logga eller skicka trafiken mellan käll- och målslutpunkter. Calico kan använda antingen Linux extended Berkeley Packet Filter (eBPF) eller Linux kernel networking pipeline för trafikleverans. Calico stöds också i Windows med hjälp av värdnätverkstjänsten (HNS) för att skapa nätverksnamnområden per containerslutpunkt. I Kubernetes-nätverksmodellen får varje podd en egen IP-adress som delas mellan containrar i podden. Poddar kommunicerar i nätverket med hjälp av podd-IP-adresser och isoleringen definieras med hjälp av nätverksprinciper. Calico använder CNI-plugin-program (Container Network Interface) för att lägga till eller ta bort poddar till och från Kubernetes poddnätverk och CNI IPAM-plugin-program (IP Address Management) för allokering och lansering av IP-adresser.
  • Nätverk för flanellöverlägg. Flannel skapar ett virtuellt nätverkslager som överlagrar värdnätverket. Överläggsnätverk använder inkapsling av nätverkspaketen över det befintliga fysiska nätverket. Flannel förenklar IP Address Management (IPAM), stöder IP-återanvändning mellan olika program och namnområden och ger logisk separation av containernätverk från underläggsnätverket som används av Kubernetes-noderna. Nätverksisolering uppnås med hjälp av VXTensible Local Area Network (VXLAN), ett inkapslingsprotokoll som tillhandahåller datacenteranslutning med tunneltrafik för att sträcka ut Layer 2-anslutningar över ett underliggande Layer 3-nätverk. Flannel stöds både av Linux-containrar som använder DaemonSet - och Windows-containrar med hjälp av Flannel CNI-plugin-programmet.

Azure Stack HCI-nätverksdesign

Den övergripande nätverksdesignen omfattar planeringsaktiviteter för Azure Stack HCI.

Börja med att planera maskinvara och installation av Azure Stack HCI. Du kan antingen köpa integrerade system från en Microsoft-maskinvarupartner med Azure Stack HCI-operativsystemet förinstallerat, eller så kan du köpa verifierade noder och installera operativsystemet själv. Azure Stack HCI är avsett som en virtualiseringsvärd, så Kubernetes-serverroller måste köras på virtuella datorer.

Krav på fysiskt nätverk för Azure Stack HCI

Microsoft certifierar inte nätverksväxlar, men det har vissa krav som leverantören av utrustningen måste uppfylla:

  • Standard: IEEE 802.1Q som definierar ett virtuellt lokalt nätverk (VLAN).
  • Standard: IEEE 802.1Qbb som definierar PFC (Priority Flow Control).
  • Standard: IEEE 802.1Qaz som definierar ETS (Enhanced Transmission Selection).
  • Standard: IEEE 802.1AB som definierar LLTD-protokollet (Link Layer Topology Discovery).

Värdnätverkskrav för Azure Stack HCI

Överväg att använda ett nätverkskort som har uppnått SDDC-certifieringen (Windows Server Software Defined Data Center) med AQ (Standard eller Premium Additional Qualification).

Kontrollera att nätverkskortet stöder:

  • Dynamic Virtual Machine Multi-Queue (Dynamisk VMMQ eller d.VMMQ) är en intelligent teknik på mottagarsidan för automatisk justering av bearbetning av nätverkstrafik till CPU-kärnor.
  • Rdma (Remote Direct Memory Access) är en avlastning av nätverksstacken till nätverkskortet. Det gör att SMB-lagringstrafik kan kringgå operativsystemet för bearbetning.
  • Med gäst-RDMA kan SMB-arbetsbelastningar för virtuella datorer få samma fördelar med att använda RDMA på värdar.
  • Switch Embedded Teaming (SET) är en programvarubaserad teamindelningsteknik.

Överväg att använda Network ATC, som ger avsiktsbaserad kontroll för att förenkla konfigurationen av värdnätverk.

AKS på en Azure Stack HCI kräver en tillförlitlig nätverksanslutning med hög bandbredd och låg svarstid mellan varje servernod. Se till att minst ett nätverkskort är tillgängligt och dedikerat för klusterhantering. Kontrollera också att fysiska växlar i nätverket är konfigurerade för att tillåta trafik på eventuella VLAN som du använder.

Virtuell växel

Azure Stack HCI förenklar nätverksdesignen genom att konfigurera en virtuell växel som kan användas för nätverksklassificering. Kortet för virtuellt nätverksgränssnitt (vNIC) kan placeras i olika VLAN för värdarna för att tillhandahålla olika trafikflöden för följande nätverk:

  • Hanteringsnätverk. Hanteringsnätverket är en del av nätverket nord-syd och används för värdkommunikation.
  • Beräkningsnätverk. Beräkningsnätverket är en del av nätverket nord-syd och används för trafik på virtuella datorer. Använd Tjänstkvalitet (QOS), enkelrotig I/O-virtualisering (SR-IOV) och virtuell fjärrdirigeringsåtkomst (vRDMA) för att justera nätverksprestanda baserat på efterfrågan.
  • Lagringsnätverk. Lagringsnätverket är en del av det öst-västliga nätverket och kräver RDMA med rekommenderat dataflöde 10 GB+. Den används för direktmigrering av de virtuella datorerna.
  • Gästnätverk för virtuella datorer.

Trafikfördelar mellan öst och väst för RDMA-trafik

Öst-västlig nätverkstrafik representerar kommunikation mellan värdarna, och den exponerar inte någon extern åtkomst. Trafiken förblir inom ToR-växeln (Top of Rack) och Layer-2-gränsen. Den innehåller följande typer av trafik:

  • Kluster pulsslag och kommunikation mellan noder
  • [SMB] Lagringsbusslager
  • [SMB] Klusterdelade volymer
  • [SMB] Återskapa lagring

Trafik mellan nord och syd

Nord-syd-trafik är den externa trafik som når AKS på Azure Stack HCI-klustret. Du kan planera trafiken för de olika Azure-tjänster som möjliggör övervakning, fakturering och säkerhetshantering genom integrering av Azure ARC. Trafiken nord-syd har följande egenskaper:

  • Trafiken flödar ut från en ToR-växel till ryggraden eller in från ryggraden till en ToR-växel.
  • Trafiken lämnar det fysiska racket eller korsar en Layer-3-gräns (IP).
  • Trafiken omfattar hantering (PowerShell, Windows Admin Center), beräkning (VM) och klustertrafik mellan platser.
  • Använder en Ethernet-växel för anslutning till det fysiska nätverket.

AKS på Azure Stack HCI kan använda flera distributionsalternativ för klusternätverk:

  • Konvergerat nätverk som kombinerar flera nätverks avsikter (MGMT, Compute, Storage). Detta är den rekommenderade distributionen för fler än tre fysiska noder och kräver att alla fysiska nätverkskort är anslutna till samma ToR-växlar. ROCEv2 rekommenderas starkt.
  • Distribution utan växel använder kommunikation mellan nord och syd som ett nätverksteam genom att kombinera beräknings- och hanteringsnätverk.
  • Hybriddistribution som en kombination av båda distributionerna.

Rekommendationer

Följande rekommendationer gäller för de flesta scenarier. Följ rekommendationerna om du inte har ett specifikt krav som åsidosätter det.

Nätverksrekommendationer

Det största problemet i nätverksdesignen för AKS på Azure Stack HCI är att välja en nätverksmodell som tillhandahåller tillräckligt med IP-adresser för ditt Kubernetes-kluster och dess tjänster och program.

  • Överväg att implementera statiska IP-adresser så att AKS på Azure Stack HCI kan styra IP-adresstilldelningen.

  • Dimensionera IP-adressintervallen korrekt så att du har tillräckligt med kostnadsfria IP-adresser för en Kubernetes-nodpool och för en virtuell IP-pool. Se till att din virtuella IP-pool är tillräckligt stor så att du när du uppgraderar kan använda löpande uppgraderingar, vilket kräver fler IP-adresser. Du kan planera följande:

    • Adressering/värdnamn för proxyinställningar
    • IP-adresser för målklusterkontrollplanet
    • IP-adresser för Azure ARC
    • IP-adresser för horisontell skalning av arbets- och kontrollplansnoder i målkluster

  • Din virtuella IP-pool bör vara tillräckligt stor för att stödja distributionen av de programtjänster som kräver anslutning till den externa routern.

  • Implementera Calico CNI för att tillhandahålla förbättrad nätverksprincip för att styra podd- och programkommunikationen.

  • Kontrollera att de fysiska klusternoderna (HCI eller Windows Server) finns i samma rack och anslutna till samma ToR-växlar.

  • Inaktivera IPv6 på alla nätverkskort.

  • Kontrollera att den befintliga virtuella växeln och dess namn är desamma för alla klusternoder.

  • Kontrollera att alla undernät som du definierar för klustret kan dirigeras mellan varandra och till Internet.

  • Kontrollera att det finns nätverksanslutning mellan Azure Stack HCI-värdar och de virtuella klientdatorerna.

  • Aktivera dynamiska DNS-uppdateringar i DNS-miljön så att AKS på Azure Stack HCI kan registrera molnagentens allmänna klusternamn i DNS-systemet för identifiering.

  • Överväg att implementera klassificering av nätverkstrafiken i dess riktning:

    • Nord-syd-trafik är trafiken från Azure Stack HCI och resten av nätverket,
      • Hantering
      • Compute
      • Klustertrafik mellan platser
    • Trafik mellan öst och väst i Azure Stack HCI:
      • Lagringstrafik inklusive direktmigrering mellan noder i samma kluster.
      • Ethernet-växel eller direktanslutning.

Modeller för lagringstrafik

  • Använd flera undernät och VLAN för att separera lagringstrafik i Azure Stack HCI.
  • Överväg att implementera trafikbandbreddsallokering av olika trafiktyper.

Att tänka på

Microsoft Azure Well-Architected Framework är en uppsättning vägledande grundsatser som följs i det här scenariot. Följande överväganden är inramade i samband med dessa grundsatser.

Tillförlitlighet

  • Inbyggd återhämtning, inbyggd i Microsofts programvarudefinierade beräkning (redundanskluster med Hyper-V-noder), lagring (Lagringsutrymmen direkt kapslad återhämtning) och nätverk (programvarudefinierat nätverk).
  • Överväg att välja den nätverksväxel som stöder branschstandarder och säkerställer tillförlitlig kommunikation mellan noder. Följande standarder omfattar:
    • Standard: IEEE 802.1Q
    • Standard-IEEE 802.1Qbb
    • Standard-IEEE 802.1 Qas
    • Standard IEEE 802.1 AB
  • Överväg att implementera flera värdar i hanteringsklustret och i Kubernetes-klustret för att uppfylla den lägsta tillgänglighetsnivån för arbetsbelastningar.
  • AKS på Azure Stack HCI använder redundanskluster och direktmigrering för hög tillgänglighet och feltolerans. Direktmigrering är en Hyper-V-funktion som gör att du transparent kan flytta virtuella datorer som körs från en Hyper-V-värd till en annan utan upplevd stilleståndstid.
  • Du bör se till att tjänster som refereras i avsnittet Arkitektur stöds i den region som Azure Arc distribueras till.

Säkerhet

  • Skydda trafiken mellan poddar med hjälp av nätverksprinciper i AKS på Azure Stack HCI.
  • API-servern i AKS på Azure Stack HCI innehåller certifikatutfärdaren som signerar certifikat för kommunikation från Kubernetes API-servern till kubelet.
  • Använd enkel inloggning med Microsoft Entra (SSO) för att skapa en säker anslutning till Kubernetes API-server.
  • Du kan använda Azure RBAC för att hantera åtkomst till Azure Arc-aktiverade Kubernetes i Azure och lokala miljöer med hjälp av Microsoft Entra-identiteter. Mer information finns i Använda Azure RBAC för Kubernetes-auktorisering.

Kostnadsoptimering

  • Använd Priskalkylatorn för Azure för att beräkna kostnaderna för de tjänster som används i arkitekturen. Andra metodtips beskrivs i avsnittet kostnadsoptimering i Microsoft Azure Well-Architected Framework.
  • Överväg att implementera hypertrådning på din fysiska dator för att optimera kostnaden, eftersom AKS på Azure Stack HCI-faktureringsenheten är en virtuell kärna.
  • Azure Arc-kontrollplansfunktioner tillhandahålls utan extra kostnad. Detta omfattar stöd för resursorganisation via Azure-hanteringsgrupper och taggar samt åtkomstkontroll via Azure RBAC. Azure-tjänster som används tillsammans med Azure Arc-aktiverade servrar medför kostnader beroende på deras användning.
  • För kostnadseffektivitet kan du använda så få som två klusternoder med endast fyra diskar och 64 GB minne per nod. För att ytterligare minimera kostnaderna kan du använda växellösa sammankopplade anslutningar mellan noder, vilket eliminerar behovet av redundanta växelenheter.

Driftsäkerhet

  • Förenklad hantering med Hjälp av Administrationscenter för Windows. Windows Admin Center är användargränssnittet för att skapa och hantera AKS på Azure Stack HCI. Den kan installeras på en virtuell Windows 10/11- eller Windows Server-dator som måste vara registrerad i Azure och som finns i samma domän som Azure Stack HCI- eller Windows Server Datacenter-klustret.
  • Integrering med Azure Arc eller en rad Azure-tjänster som ger mer hanterings-, underhålls- och återhämtningsfunktioner (Azure Monitor, Azure Backup).
  • Om ditt Kubernetes-kluster är kopplat till Azure Arc kan du hantera ditt Kubernetes-kluster med GitOps. Mer information om metodtips för att ansluta ett Kubernetes-hybridkluster till Azure Arc finns i scenariot för Azure Arc-hybridhantering och -distribution för Kubernetes-kluster .
  • Azure Stack HCI-plattformen hjälper också till att förenkla virtuella nätverk för AKS i Azure Stack HCI-kluster genom att tillhandahålla det "underliggande" nätverket på ett sätt med hög tillgänglighet.

Prestandaeffektivitet

  • Använd Azure Stack HCI-certifierad maskinvara för bättre programupptid och prestanda, förenklad hantering och drift samt lägre total ägandekostnad.
  • Lagring: Lagringsutrymmen Direct
    • Volymkonfiguration (kapslad dubbelriktad spegling jämfört med kapslad speglingsaccelererad paritet)
    • Diskkonfiguration (cachelagring, nivåer)
  • Se till att klusternoderna finns fysiskt i samma rack och anslutna till samma ToR-växlar.
  • Planera IP-adressreservationer för att konfigurera AKS-värdar, arbetsbelastningskluster, kluster-API-servrar, Kubernetes Services och programtjänster. Microsoft rekommenderar att du reserverar minst 256 IP-adresser för AKS-distribution på Azure Stack HCI.
  • Överväg att implementera en ingresskontrollant som fungerar på lager 7 och använder mer intelligenta regler för att distribuera programtrafik.
  • Använd GPU-acceleration (graphics processing unit) för omfattande arbetsbelastningar.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Nästa steg