Architettura di rete per il servizio Azure Kubernetes in Azure Stack HCI

Azure Stack HCI
Windows Server

Questo scenario illustra come progettare e implementare concetti di rete per la distribuzione di nodi servizio Azure Kubernetes (servizio Azure Kubernetes) nei cluster del servizio Azure Kubernetes.

Questo articolo include raccomandazioni per la progettazione della rete per i nodi Kubernetes e i contenitori Kubernetes. Fa parte di un set di linee guida di base per l'architettura di due articoli. Vedere le raccomandazioni sull'architettura di base qui.

Importante

Le informazioni contenute in questo articolo si applicano al servizio Azure Kubernetes in Azure Stack HCI versione 22H2 e AKS-HCI in Windows Server. La versione più recente del servizio Azure Kubernetes viene eseguita in Azure Stack HCI 23H2. Per altre informazioni sulla versione più recente, vedere la documentazione del servizio Azure Kubernetes in Azure Stack HCI versione 23H2.

Architettura

L'immagine seguente illustra l'architettura di rete per servizio Azure Kubernetes nei cluster data center di Azure Stack HCI o Windows Server 2019/2022:

Immagine concettuale che mostra l'architettura di base di rete.

Scaricare un file di Visio di questa architettura.

Lo scenario è costituito dai componenti e dalle funzionalità seguenti:

  • Azure Stack HCI (22H2) è una soluzione cluster di infrastruttura iperconvergente che ospita carichi di lavoro Windows e Linux virtualizzati e la relativa archiviazione in un ambiente locale ibrido. Il cluster Azure Stack HCI viene implementato come cluster a 2-4 nodi.
  • Il cluster di failover del data center di Windows Server 2019/2022 è un gruppo di computer indipendenti che interagiscono per aumentare la disponibilità e la scalabilità dei ruoli in cluster.
  • servizio Azure Kubernetes in Azure Stack HCI è un'implementazione locale di servizio Azure Kubernetes (AKS), che automatizza l'esecuzione di applicazioni in contenitori su larga scala.
  • Dominio di Active Directory Services è una struttura gerarchica che archivia informazioni sugli oggetti nella rete. Fornisce una soluzione di identità e accesso per le identità associate a utenti, computer, applicazioni o altre risorse incluse in un limite di sicurezza.
  • Il cluster di gestione noto anche come host del servizio Azure Kubernetes è responsabile della distribuzione e della gestione di più cluster del carico di lavoro. Il cluster di gestione utilizza 1 indirizzo IP dal pool di nodi, ma è necessario riservare altri 2 INDIRIZZI IP per le operazioni di aggiornamento. Il cluster di gestione usa anche un indirizzo IP dal pool di indirizzi VIP.
  • Il cluster del carico di lavoro è una distribuzione a disponibilità elevata di Kubernetes usando macchine virtuali Linux per l'esecuzione di componenti del piano di controllo Kubernetes e/o nodi di lavoro Linux e/o Windows.
    • Piano di controllo. Viene eseguito in una distribuzione Linux e contiene componenti del server API per l'interazione con l'API Kubernetes e un archivio chiave-valore distribuito, etcd, per archiviare tutti i dati e la configurazione del cluster. Usa un indirizzo IP dal pool di nodi e un INDIRIZZO IP dal pool VIP.
    • Servizio di bilanciamento del carico. Viene eseguito in una macchina virtuale Linux e fornisce servizi con carico bilanciato per il cluster del carico di lavoro. Usa un indirizzo IP dal pool di nodi e un INDIRIZZO IP dal pool VIP.
    • Nodi di lavoro. Eseguire in un sistema operativo Windows o Linux che ospita applicazioni in contenitori. Usa gli indirizzi IP del pool di nodi, ma è consigliabile pianificare almeno 3 indirizzi IP per le operazioni di aggiornamento.
    • Risorse Kubernetes. I pod rappresentano una singola istanza dell'applicazione, che in genere hanno un mapping 1:1 con un contenitore, ma alcuni pod possono contenere più contenitori. Le distribuzioni rappresentano uno o più pod identici. I pod e le distribuzioni vengono raggruppati logicamente in uno spazio dei nomi che controlla l'accesso alla gestione delle risorse. Usano 1 IP per pod dal pool VIP.
  • Azure Arc è un servizio basato sul cloud che estende il modello di gestione basato su Azure Resource Manager a risorse non di Azure, incluse macchine virtuali (VM), cluster Kubernetes e database in contenitori.
  • Criteri di Azure è un servizio basato sul cloud che valuta le risorse di Azure e locali tramite l'integrazione con Azure Arc confrontando le proprietà con le regole business personalizzabili.
  • Monitoraggio di Azure è un servizio basato sul cloud che ottimizza la disponibilità e le prestazioni delle applicazioni e dei servizi offrendo una soluzione completa per la raccolta, l'analisi e l'esecuzione dei dati di telemetria dagli ambienti cloud e locali.
  • Microsoft Defender per il cloud è un sistema unificato di gestione della sicurezza dell'infrastruttura che rafforza il comportamento di sicurezza dei data center e fornisce protezione avanzata dalle minacce nei carichi di lavoro ibridi nel cloud e in locale.

Componenti

Dettagli dello scenario

I casi d'uso per questo scenario sono descritti nel primo articolo della serie, Architettura di base.

Rete dei nodi Kubernetes

La considerazione principale nella progettazione di rete per il servizio Azure Kubernetes in Azure Stack HCI consiste nel selezionare il modello di rete che fornisce indirizzi IP sufficienti. Il servizio Azure Kubernetes in Azure Stack HCI usa la rete virtuale per allocare gli indirizzi IP alle risorse del nodo Kubernetes. È possibile usare due modelli di assegnazione di indirizzi IP:

  • La rete IP statica è più prevedibile, ma aggiunge ulteriore sforzo per la configurazione iniziale.
  • La rete DHCP (Dynamic Host Configuration Protocol) usa l'allocazione dinamica di indirizzi IP e meno fatica, ma è necessario prestare attenzione a non esaurire il pool di indirizzi IP disponibili. È anche necessario gestire le prenotazioni e gli intervalli di esclusione per i pool IP virtuali e alcune risorse a livello di cluster, ad esempio il servizio agente cloud.

Entrambi i modelli di assegnazione devono pianificare gli indirizzi IP per:

  • Pool di indirizzi IP virtuali
  • Pool IP della macchina virtuale del nodo Kubernetes

Pool di indirizzi IP virtuali

Un pool di indirizzi IP virtuali è un set di indirizzi IP obbligatori per qualsiasi servizio Azure Kubernetes nella distribuzione di Azure Stack HCI. Pianificare il numero di indirizzi IP nel pool di indirizzi IP virtuali in base al numero di cluster del carico di lavoro e ai servizi Kubernetes. Il pool di indirizzi IP virtuali fornisce gli indirizzi IP per i tipi di risorse seguenti:

  • L'agente cloud richiede un indirizzo IP mobile dal pool di indirizzi IP virtuali.

  • Il componente server API eseguito all'interno della macchina virtuale dell'appliance virtuale Kubernetes (KVA) usa un indirizzo IP dal pool di indirizzi IP virtuali. Il server API è un componente del piano di controllo Kubernetes che espone l'API Kubernetes. Il server API è il front-end per il piano di controllo Kubernetes. KVA è una macchina virtuale che esegue Mariner Linux e ospita un cluster Kubernetes. L'indirizzo IP è mobile e viene usato anche per qualsiasi altra macchina virtuale KVA distribuita nel servizio Azure Kubernetes in Azure Stack HCI. La macchina virtuale KVA ospita anche un servizio di bilanciamento del carico IP virtuale Kubernetes.

  • Pianificare l'indirizzamento IP per il numero di macchine virtuali del piano di controllo distribuite nei server di destinazione, poiché utilizzano anche più indirizzi IP dal pool di indirizzi IP virtuali. Le considerazioni sono descritte nella sezione successiva.

  • Il cluster di destinazione contiene una macchina virtuale del servizio di bilanciamento del carico, che è HAProxy e possiede il pool di indirizzi IP virtuali per il cluster di destinazione. Questa macchina virtuale espone tutti i servizi Kubernetes tramite il pool di indirizzi IP virtuali.

  • Le applicazioni eseguite nei pod Kubernetes usano indirizzi IP dal pool di indirizzi IP virtuali.

  • Il servizio di bilanciamento del carico HAProxy viene distribuito come macchina virtuale specializzata e può essere usato per bilanciare il carico delle richieste in ingresso tra più endpoint. Usano indirizzi IP dal pool di indirizzi IP virtuali ed è necessario pianificare l'indirizzamento IP per ogni cluster del carico di lavoro.

Pool IP della macchina virtuale del nodo Kubernetes

I nodi Kubernetes vengono distribuiti come macchine virtuali in un servizio Azure Kubernetes nella distribuzione di Azure Stack HCI. Assicurarsi di pianificare il numero di indirizzi IP in base al numero totale di nodi Kubernetes e includere almeno tre indirizzi IP usati durante il processo di aggiornamento. Per la configurazione degli indirizzi IP statici, è necessario specificare l'intervallo di pool ip della macchina virtuale del nodo Kubernetes, non è necessario per l'allocazione DHCP. Pianificare indirizzi IP aggiuntivi per:

  • La macchina virtuale KVA usa anche più indirizzi IP per Kubernetes dal pool di indirizzi IP della macchina virtuale del nodo Kubernetes. Pianificare l'aggiunta di indirizzi IP durante il processo di aggiornamento, perché la macchina virtuale KVA usa lo stesso indirizzo IP virtuale per il servizio API, ma richiede un indirizzo IP separato dal pool ip della macchina virtuale del nodo Kubernetes.
  • Le macchine virtuali del piano di controllo usano un indirizzo IP dal pool IP della macchina virtuale del nodo Kubernetes per il servizio server API. Queste macchine virtuali ospitano anche l'agente Azure ARC che si connette al portale di Azure a scopo di gestione.
  • I nodi in un pool di nodi (Linux o Windows) utilizzeranno gli indirizzi IP del pool IP allocato per la macchina virtuale del nodo Kubernetes.

Servizio cloud locale Microsoft

Pianificare l'intervallo di indirizzi IP per il cloud locale Microsoft che consente lo stack di gestione in modo che le macchine virtuali in Azure Stack HCI vengano gestite nel cloud. L'allocazione degli indirizzi IP per il servizio MOC si trova nella rete fisica sottostante e gli indirizzi IP configurati per i nodi del cluster Azure Stack HCI si trovano nel data center. È possibile configurare gli indirizzi IP per i nodi fisici di Azure Stack HCI in uno dei modi seguenti:

  • Nodi del cluster Azure Stack HCI con una modalità di allocazione degli indirizzi IP basata su DHCP. Il servizio MOC ottiene un indirizzo IP dal servizio DHCP presentato nella rete fisica.
  • Nodi del cluster Azure Stack HCI con un modello di allocazione IP statico. L'indirizzo IP per il servizio cloud MOC deve essere specificato in modo esplicito come intervallo IP in formato CIDR (Classless Inter-Domain Routing) e deve trovarsi nella stessa subnet degli indirizzi IP dei nodi del cluster Azure Stack HCI.

Bilanciamento del carico nel servizio Azure Kubernetes in Azure Stack HCI

Per una distribuzione di piccole dimensioni, è possibile usare il servizio di bilanciamento del carico predefinito, distribuito come macchina virtuale Linux che usa HAProxy + KeepAlive per inviare il traffico ai servizi dell'applicazione distribuiti come parte del cluster del servizio Azure Kubernetes. IL servizio di bilanciamento del carico HAProxy configura i pod come endpoint nel servizio di bilanciamento del carico. Carica le richieste di bilanciamento al server API Kubernetes e gestisce il traffico verso i servizi dell'applicazione.

È anche possibile usare un servizio di bilanciamento del carico personalizzato per gestire il traffico verso i servizi. Il servizio di bilanciamento del carico personalizzato offre una maggiore flessibilità per la distribuzione e garantisce che il servizio Azure Kubernetes in Azure Stack HCI funzioni insieme a distribuzioni esistenti, ad esempio distribuzioni SDN (Software Defined Network) che usano servizi di bilanciamento del carico. Per i servizi di bilanciamento del carico personalizzati, kube-virtual IP fornisce cluster Kubernetes con un indirizzo IP virtuale e un servizio di bilanciamento del carico sia per il piano di controllo che per i servizi Kubernetes di tipo LoadBalancer. Il servizio IP virtuale kube viene distribuito automaticamente in ogni nodo di lavoro.

Il servizio Azure Kubernetes in Azure Stack HCI supporta anche l'uso di MetalLB o di altri servizi di bilanciamento del carico basati su OSS Kubernetes per bilanciare il traffico destinato ai servizi in un cluster del carico di lavoro. MetalLB è un'implementazione del servizio di bilanciamento del carico per i cluster Kubernetes bare metal, che usano protocolli di routing standard, ad esempio BGP del protocollo Border Gateway. Può funzionare con entrambi i componenti aggiuntivi di rete, Calico e Flannel, ma è necessario assicurarsi che l'intervallo di indirizzi IP virtuali specificato durante l'installazione del servizio Azure Kubernetes in Azure Stack HCI non si sovrapponga all'intervallo di indirizzi IP pianificato per il servizio di bilanciamento del carico personalizzato.

Distribuire lo scenario

Distribuire un controller di ingresso

Prendere in considerazione l'implementazione di un controller di ingresso per la terminazione TLS, il proxy reversibile o il routing del traffico configurabile. I controller di ingresso funzionano al livello 7 e possono usare regole intelligenti per distribuire il traffico dell'applicazione. Le risorse di ingresso Kubernetes vengono usate per configurare le regole di ingresso e le route per i singoli servizi Kubernetes. Quando si definisce un controller di ingresso, si consolidano le regole di routing del traffico in una singola risorsa eseguita come parte del cluster.

Usare un controller di ingresso per esporre i servizi tramite URL raggiungibili esternamente. L'ingresso espone route HTTP e HTTPS dall'esterno del cluster ai servizi all'interno del cluster. Il routing del traffico è controllato da regole definite nella risorsa di ingresso. Le regole HTTP in ingresso contengono le informazioni seguenti:

  • Host facoltativo. Se non si forniscono informazioni sull'host, la regola viene applicata a tutto il traffico HTTP in ingresso.
  • Elenco di percorsi con un back-end associato definito con un service.name e un service.port.name o service.port.number.
  • Back-end che fornisce una combinazione di nomi di servizio e porte.
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

Usare un controller di ingresso per bilanciare il traffico tra diversi back-end dell'applicazione. Il traffico viene suddiviso e inviato a diversi endpoint di servizio e distribuzioni, in base alle informazioni sul percorso.

Per instradare il traffico HTTP a più nomi host nello stesso indirizzo IP, è possibile usare una risorsa di ingresso diversa per ogni host. Il traffico proveniente dall'indirizzo IP del servizio di bilanciamento del carico viene indirizzato in base al nome host e al percorso fornito nella regola di ingresso.

Concetti relativi alla rete dei contenitori nel servizio Azure Kubernetes (AKS) in Azure Stack HCI

Kubernetes fornisce un livello di astrazione a una rete virtuale, in modo che le applicazioni basate su contenitori possano comunicare internamente o esternamente. Il componente kube-proxy viene eseguito in ogni nodo e può fornire l'accesso diretto al servizio, distribuire il traffico usando i servizi di bilanciamento del carico o usare controller di ingresso per il routing delle applicazioni più complesso. Kubernetes usa i servizi per raggruppare logicamente un set di pod e fornire la connettività di rete. Sono disponibili i servizi Kubernetes seguenti:

  • IP del cluster: questo servizio crea un indirizzo IP interno per le applicazioni solo interne.
  • NodePort: questo servizio crea il mapping delle porte sul nodo sottostante, che rende l'applicazione direttamente accessibile con l'indirizzo IP e la porta del nodo.
  • LoadBalancer: è possibile esporre i servizi Kubernetes esternamente usando regole di bilanciamento del carico o un controller di ingresso.
  • ExternalName:. Questo servizio usa una voce DNS specifica per l'applicazione Kubernetes.

Reti Kubernetes

Nel servizio Azure Kubernetes in Azure Stack HCI il cluster può essere distribuito usando uno dei modelli di rete seguenti:

  • Rete calico del progetto. Si tratta di un modello di rete predefinito per il servizio Azure Kubernetes in Azure Stack HCI ed è basato su una rete open source che fornisce sicurezza di rete per contenitori, macchine virtuali e carichi di lavoro nativi basati su host. I criteri di rete Calico possono essere applicati a qualsiasi tipo di endpoint, ad esempio pod, contenitori, macchine virtuali o interfacce host. Ogni criterio è costituito da regole che controllano il traffico in ingresso e in uscita usando azioni che possono consentire, negare, registrare o passare il traffico tra gli endpoint di origine e di destinazione. Calico può usare la pipeline di rete del kernel Linux extended Berkeley Packet Filter (eBPF) o Linux per il recapito del traffico. Calico è supportato anche in Windows usando il servizio di rete host (HNS) per la creazione di spazi dei nomi di rete per ogni endpoint contenitore. Nel modello di rete Kubernetes ogni pod ottiene il proprio indirizzo IP condiviso tra i contenitori all'interno del pod. I pod comunicano in rete usando gli indirizzi IP dei pod e l'isolamento viene definito usando i criteri di rete. Calico usa plug-in CNI (Container Network Interface) per aggiungere o eliminare pod da e verso la rete dei pod Kubernetes e i plug-in di Gestione indirizzi IP CNI (Gestione indirizzi IP) per l'allocazione e il rilascio di indirizzi IP.
  • Rete di sovrapposizione flannel. Flannel crea un livello di rete virtuale che sovrappone la rete host. La rete di sovrapposizione usa l'incapsulamento dei pacchetti di rete sulla rete fisica esistente. Flannel semplifica Gestione indirizzi IP (Gestione indirizzi IP), supporta il riutilizzo degli indirizzi IP tra applicazioni e spazi dei nomi diversi e offre la separazione logica delle reti contenitore dalla rete underlay usata dai nodi Kubernetes. L'isolamento della rete viene ottenuto usando La rete locale virtuale (VXLAN), un protocollo di incapsulamento che fornisce la connettività del data center tramite il tunneling per estendere le connessioni di livello 2 su una rete di livello 3 sottostante. Flannel è supportato sia dai contenitori Linux che dai contenitori DaemonSet e Windows usando il plug-in CNI Flannel.

Progettazione di rete di Azure Stack HCI

La progettazione complessiva della rete include le attività di pianificazione per Azure Stack HCI.

Per prima cosa, iniziare pianificando l'hardware e l'installazione di Azure Stack HCI. È possibile acquistare sistemi integrati da un partner hardware Microsoft con il sistema operativo Azure Stack HCI preinstallato oppure acquistare nodi convalidati e installare manualmente il sistema operativo. Azure Stack HCI è destinato a un host di virtualizzazione, quindi i ruoli del server Kubernetes devono essere eseguiti all'interno delle macchine virtuali.

Requisiti di rete fisici per Azure Stack HCI

Microsoft non certifica i commutatori di rete, ma ha determinati requisiti che il fornitore delle apparecchiature deve soddisfare:

  • Standard: IEEE 802.1Q che definisce una rete locale virtuale (VLAN).
  • Standard: IEEE 802.1Qbb che definisce il controllo del flusso di priorità (PFC).
  • Standard: IEEE 802.1Qaz che definisce la selezione avanzata della trasmissione (ETS).
  • Standard: IEEE 802.1AB che definisce il protocollo LLTD (Link Layer Topology Discovery).

Requisiti di rete host per Azure Stack HCI

Prendere in considerazione l'uso di una scheda di rete che ha ottenuto la certificazione Windows Server Software Defined Data Center (SDDC) con la qualifica aggiuntiva Standard o Premium ( AQ).

Verificare che la scheda di rete supporti:

  • Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ o d.VMMQ) è una tecnologia intelligente sul lato ricezione per l'ottimizzazione automatica dell'elaborazione del traffico di rete verso core CPU.
  • Remote Direct Memory Access (RDMA) è un offload dello stack di rete nella scheda di rete. Consente al traffico di archiviazione SMB di ignorare il sistema operativo per l'elaborazione.
  • RdMA guest consente ai carichi di lavoro SMB per le macchine virtuali di ottenere gli stessi vantaggi dell'uso di RDMA negli host.
  • Switch Embedded Teaming (SET) è una tecnologia di teaming basata su software.

Prendere in considerazione l'uso di Network ATC, che fornisce un controllo basato sulle finalità per semplificare la configurazione della rete host.

Il servizio Azure Kubernetes in azure Stack HCI richiede una connessione di rete affidabile a larghezza di banda elevata e a bassa latenza tra ogni nodo del server. Assicurarsi che almeno una scheda di rete sia disponibile e dedicata per la gestione del cluster. Verificare anche che i commutatori fisici nella rete siano configurati per consentire il traffico su tutte le VLAN che verranno usate.

Commutatore virtuale

Azure Stack HCI semplifica la progettazione di rete configurando un commutatore virtuale che può essere usato per la classificazione di rete. La scheda di interfaccia di rete virtuale (vNIC) può essere inserita in reti VLAN diverse per consentire agli host di fornire un flusso di traffico diverso per le reti seguenti:

  • Rete di gestione. La rete di gestione fa parte della rete nord-sud e viene usata per la comunicazione host.
  • Rete di calcolo. La rete di calcolo fa parte della rete nord-sud e viene usata per il traffico delle macchine virtuali. Usare Quality of Service (QOS), la virtualizzazione di I/O a radice singola (SR-IOV) e l'accesso alla memoria remota remota virtuale (vRDMA) per ottimizzare le prestazioni di rete in base alla richiesta.
  • Rete di archiviazione. La rete di archiviazione fa parte della rete east-west e richiede RDMA con velocità effettiva consigliata da 10 GB+. Viene usato per la migrazione in tempo reale delle macchine virtuali.
  • Rete guest della macchina virtuale.

Vantaggio del traffico RDMA a est-ovest

Il traffico di rete East-West rappresenta la comunicazione tra gli host e non espone alcun accesso esterno. Il traffico rimane all'interno del commutatore Top of Rack (ToR) e del limite di livello 2. Include i tipi di traffico seguenti:

  • Heartbeat del cluster e comunicazione tra nodi
  • [SMB] Livello bus di archiviazione
  • [SMB] Volume condiviso cluster
  • [SMB] Ricompilazione archiviazione

Traffico nord-sud

Il traffico nord-sud è il traffico esterno che raggiunge il servizio Azure Kubernetes nel cluster Azure Stack HCI. È possibile pianificare il traffico per la gamma di servizi di Azure che consentono il monitoraggio, la fatturazione e la gestione della sicurezza tramite l'integrazione di Azure ARC. Il traffico nord-sud presenta le caratteristiche seguenti:

  • Il traffico esce da un interruttore ToR alla colonna vertebrale o da una colonna vertebrale a un interruttore ToR.
  • Il traffico lascia il rack fisico o supera un limite di livello 3 (IP).
  • Il traffico include la gestione (PowerShell, Windows Admin Center), il calcolo (VM) e il traffico del cluster esteso tra siti.
  • Usa un commutatore Ethernet per la connettività alla rete fisica.

Il servizio Azure Kubernetes in Azure Stack HCI può usare diverse opzioni di distribuzione di rete del cluster:

  • Rete convergente che combina più finalità di rete (MGMT, calcolo, archiviazione). Si tratta della distribuzione consigliata per più di tre nodi fisici e richiede che tutte le schede di rete fisiche siano connesse agli stessi commutatori ToR. ROCEv2 è altamente consigliato.
  • La distribuzione senza cambio usa la comunicazione nord-sud come team di rete combinando reti di calcolo e gestione.
  • Distribuzione ibrida come combinazione di entrambe le distribuzioni.

Consigli

Le raccomandazioni seguenti sono valide per la maggior parte degli scenari. Seguire le raccomandazioni, a meno che non si disponga di un requisito specifico che ne esegue l'override.

Raccomandazioni di rete

La preoccupazione principale nella progettazione di rete per il servizio Azure Kubernetes in Azure Stack HCI è la selezione di un modello di rete che fornisce indirizzi IP sufficienti per il cluster Kubernetes e i relativi servizi e applicazioni.

  • Prendere in considerazione l'implementazione di indirizzi IP statici per consentire al servizio Azure Kubernetes in Azure Stack HCI di controllare l'assegnazione di indirizzi IP.

  • Dimensionare correttamente gli intervalli di indirizzi IP in modo da avere un numero sufficiente di indirizzi IP liberi per un pool di nodi Kubernetes e per un pool di indirizzi IP virtuali. Assicurarsi che il pool di indirizzi IP virtuali sia sufficientemente grande, in modo che ogni volta che si esegue l'aggiornamento è possibile usare gli aggiornamenti in sequenza, che richiedono più indirizzi IP. È possibile pianificare quanto segue:

    • Indirizzamento/nomi host per le impostazioni proxy
    • Indirizzi IP per il piano di controllo del cluster di destinazione
    • Indirizzi IP per Azure ARC
    • Indirizzi IP per il ridimensionamento orizzontale dei nodi del piano di lavoro e del piano di controllo nei cluster di destinazione

  • Il pool di indirizzi IP virtuali deve essere sufficientemente grande da supportare la distribuzione dei servizi dell'applicazione che richiedono la connettività al router esterno.

  • Implementare Calico CNI per fornire criteri di rete avanzati per controllare la comunicazione tra pod e applicazioni.

  • Assicurarsi che i nodi del cluster fisico (HCI o Windows Server) si trovino nello stesso rack e connessi agli stessi commutatori ToR.

  • Disabilitare IPv6 in tutte le schede di rete.

  • Assicurarsi che il commutatore virtuale esistente e il relativo nome siano uguali in tutti i nodi del cluster.

  • Verificare che tutte le subnet definite per il cluster siano instradabili tra loro e verso Internet.

  • Assicurarsi che sia presente la connettività di rete tra gli host Azure Stack HCI e le macchine virtuali tenant.

  • Abilitare gli aggiornamenti DNS dinamici nell'ambiente DNS per consentire al servizio Azure Kubernetes in Azure Stack HCI di registrare il nome del cluster generico dell'agente cloud nel sistema DNS per l'individuazione.

  • Valutare la possibilità di implementare la classificazione del traffico di rete in base alla direzione:

    • Il traffico nord-sud è il traffico proveniente da Azure Stack HCI e dal resto della rete,
      • Gestione
      • Calcolo
      • Traffico del cluster esteso tra siti
    • Traffico east-west all'interno di Azure Stack HCI:
      • Traffico di archiviazione, inclusa la migrazione in tempo reale tra nodi nello stesso cluster.
      • Commutatore Ethernet o connessione diretta.

Modelli di traffico di archiviazione

  • Usare più subnet e VLAN per separare il traffico di archiviazione in Azure Stack HCI.
  • Valutare la possibilità di implementare l'allocazione della larghezza di banda del traffico di vari tipi di traffico.

Considerazioni

Microsoft Azure Well-Architected Framework è un set di set di principi guida seguiti in questo scenario. Le considerazioni seguenti sono incluse nel contesto di questi set di dati.

Affidabilità

  • Resilienza predefinita, intrinseca al calcolo software-defined Microsoft (cluster di failover di nodi Hyper-V), archiviazione (Spazi di archiviazione diretta resilienza annidata) e rete (Software Defined Networking).
  • Prendere in considerazione la selezione del commutatore di rete che supporta gli standard di settore e garantisce comunicazioni affidabili tra i nodi. Gli standard seguenti includono:
    • Standard: IEEE 802.1Q
    • Standard IEEE 802.1Qbb
    • Standard IEEE 802.1 Qas
    • Standard IEEE 802.1 AB
  • Prendere in considerazione l'implementazione di più host nel cluster di gestione e nel cluster Kubernetes per soddisfare il livello minimo di disponibilità per i carichi di lavoro.
  • Il servizio Azure Kubernetes in Azure Stack HCI usa il clustering di failover e la migrazione in tempo reale per la disponibilità elevata e la tolleranza di errore. La migrazione in tempo reale è una funzionalità hyper-V che consente di spostare in modo trasparente le macchine virtuali in esecuzione da un host Hyper-V a un altro senza tempi di inattività percepiti.
  • È necessario assicurarsi che i servizi a cui si fa riferimento nella sezione Architettura siano supportati nell'area in cui viene distribuito Azure Arc.

Sicurezza

  • Proteggere il traffico tra pod usando i criteri di rete nel servizio Azure Kubernetes in Azure Stack HCI.
  • Il server API nel servizio Azure Kubernetes in Azure Stack HCI contiene l'autorità di certificazione che firma i certificati per la comunicazione dal server API Kubernetes a kubelet.
  • Usare l'accesso Single Sign-On (SSO) di Microsoft Entra per creare una connessione sicura al server API Kubernetes.
  • È possibile usare il controllo degli accessi in base al ruolo di Azure per gestire l'accesso a Kubernetes abilitato per Azure Arc in ambienti Azure e locali usando le identità di Microsoft Entra. Per altre informazioni, vedere Usare il controllo degli accessi in base al ruolo di Azure per l'autorizzazione kubernetes.

Ottimizzazione dei costi

  • Usare il calcolatore prezzi di Azure per stimare i costi per i servizi usati nell'architettura. Altre procedure consigliate sono descritte nella sezione relativa all'ottimizzazione dei costi in Microsoft Azure Well-Architected Framework.
  • Valutare la possibilità di implementare l'hyper-threading nel computer fisico per ottimizzare il costo, perché il servizio Azure Kubernetes in Azure Stack HCI è un core virtuale.
  • La funzionalità del piano di controllo di Azure Arc viene fornita senza costi aggiuntivi. Ciò include il supporto per l'organizzazione delle risorse tramite i gruppi e i tag di gestione di Azure e il controllo degli accessi tramite il controllo degli accessi in base al ruolo di Azure. I servizi di Azure usati insieme ai server abilitati per Azure Arc comportano costi in base al relativo utilizzo.
  • Per un'efficienza economica, è possibile usare solo due nodi del cluster con solo quattro dischi e 64 gigabyte (GB) di memoria per nodo. Per ridurre ulteriormente i costi, è possibile usare interconnessioni senza cambio tra nodi, eliminando così la necessità di dispositivi switch ridondanti.

Eccellenza operativa

  • Gestione semplificata con Windows Admin Center. Windows Admin Center è l'interfaccia utente per la creazione e la gestione del servizio Azure Kubernetes in Azure Stack HCI. Può essere installato in una macchina virtuale Windows 10/11 o Windows Server che deve essere registrata in Azure e che si trovano nello stesso dominio del cluster Azure Stack HCI o Windows Server Datacenter.
  • Integrazione con Azure Arc o una gamma di servizi di Azure che offrono più funzionalità di gestione, manutenzione e resilienza (Monitoraggio di Azure, Backup di Azure).
  • Se il cluster Kubernetes è collegato ad Azure Arc, è possibile gestire il cluster Kubernetes usando GitOps. Per esaminare le procedure consigliate per la connessione di un cluster Kubernetes ibrido ad Azure Arc, vedere lo scenario di gestione e distribuzione ibrida di Azure Arc per i cluster Kubernetes.
  • La piattaforma Azure Stack HCI consente anche di semplificare la rete virtuale per il servizio Azure Kubernetes nei cluster Azure Stack HCI fornendo la rete "sottostante" in modo a disponibilità elevata.

Efficienza prestazionale

  • Usare l'hardware certificato Azure Stack HCI per migliorare il tempo di attività e le prestazioni delle applicazioni, la gestione e le operazioni semplificate e ridurre il costo totale di proprietà.
  • Archiviazione: Spazi di archiviazione diretta
    • Configurazione del volume (mirroring bidirezionale annidato e parità con accelerazione mirror annidata)
    • Configurazione del disco (memorizzazione nella cache, livelli)
  • Assicurarsi che i nodi del cluster si trovino fisicamente nello stesso rack e connessi agli stessi commutatori ToR.
  • Pianificare le prenotazioni degli indirizzi IP per configurare gli host del servizio Azure Kubernetes, i cluster di carico di lavoro, i server API del cluster, i servizi Kubernetes e i servizi dell'applicazione. Microsoft consiglia di riservare almeno 256 indirizzi IP per la distribuzione del servizio Azure Kubernetes in Azure Stack HCI.
  • Prendere in considerazione l'implementazione di un controller di ingresso che funziona al livello 7 e usa regole più intelligenti per distribuire il traffico dell'applicazione.
  • Usare l'accelerazione GPU (Graphics Processing Unit) per carichi di lavoro estesi.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Passaggi successivi