Rete Kubernetes nel dispositivo Azure Stack Edge Pro GPU

SI APPLICA A:Azure Stack Edge Pro - GPUAzure Stack Edge Pro 2Azure Stack Edge Pro RAzure Stack Edge Mini R

Nel dispositivo Azure Stack Edge Pro GPU viene creato un cluster Kubernetes quando si configura il ruolo di calcolo. Dopo aver creato il cluster Kubernetes, le applicazioni in contenitori possono essere distribuite nel cluster Kubernetes in Pod. Esistono diversi modi per usare la rete per i pod nel cluster Kubernetes.

Questo articolo descrive la rete in un cluster Kubernetes in generale e in particolare nel contesto del dispositivo Azure Stack Edge Pro GPU.

Requisiti di rete

Di seguito è riportato un esempio di un'app a due livelli tipica distribuita nel cluster Kubernetes.

• L'app ha un front-end del server Web e un'applicazione di database nel back-end.
• A ogni pod viene assegnato un indirizzo IP, ma questi indirizzi IP possono cambiare al riavvio e al failover del pod.
• Ogni app è costituita da più pod e deve essere presente il bilanciamento del carico del traffico tra tutte le repliche pod.

Lo scenario precedente comporta i requisiti di rete seguenti:

• È necessario che l'applicazione con connessione esterna sia accessibile da un utente dell'applicazione all'esterno del cluster Kubernetes tramite un nome o un indirizzo IP.
• Le applicazioni all'interno del cluster Kubernetes, ad esempio front-end e i pod back-end qui dovrebbero essere in grado di comunicare tra loro.

Per risolvere entrambe le esigenze precedenti, viene introdotto un servizio Kubernetes.

Servizi di rete

Esistono due tipi di servizi Kubernetes:

• Servizio IP del cluster: considerare questo servizio come fornire un endpoint costante per i pod dell'applicazione. Non è possibile accedere a qualsiasi pod associato a questi servizi dall'esterno del cluster Kubernetes. L'indirizzo IP usato con questi servizi proviene dallo spazio indirizzi nella rete privata.

  Per esporre i pod all'interno del cluster Kubernetes per l'accesso come altri pod e non come servizio di bilanciamento del carico esposto esternamente, vedere Come esporre il servizio Kubernetes come servizio IP del cluster per la comunicazione interna.

• IP del servizio di bilanciamento del carico, ad esempio il servizio IP del cluster, ma l'INDIRIZZO IP associato proviene dalla rete esterna e può essere accessibile dall'esterno del cluster Kubernetes.

Configurazione di rete Kubernetes

Gli indirizzi IP usati per i nodi Kubernetes e i servizi esterni vengono forniti tramite la pagina Calcolo nell'interfaccia utente locale del dispositivo.

L'assegnazione IP è per:

• INDIRIZZI IP del nodo Kubernetes: questo intervallo IP viene usato per i nodi master e di lavoro kubernetes. Questi indirizzi IP vengono usati quando i nodi Kubernetes comunicano tra loro.
• INDIRIZZI IP del servizio esterno Kubernetes: questo intervallo IP viene usato per i servizi esterni (noti anche come servizi di Load Balancer) esposti all'esterno del cluster Kubernetes.

Componenti di rete kubernetes

Calico, Metallb e Core DNS sono tutti i componenti installati per la rete nella GPU di Azure Stack Edge Pro.

• Calico assegna un indirizzo IP da un intervallo IP privato a ogni pod e configura la rete per questi pod in modo che il pod in un nodo possa comunicare con il pod in un altro nodo.
• Metallb viene eseguito in un pod in cluster e assegna l'indirizzo IP ai servizi di tipo load balancer. Gli indirizzi IP del servizio di bilanciamento del carico vengono scelti dall'intervallo ip del servizio fornito tramite l'interfaccia utente locale.
• DNS core: questo componente aggiuntivo configura il mapping del nome del servizio di mapping del servizio all'indirizzo IP del cluster.

Quando ci si connette all'interfaccia di PowerShell del dispositivo, è possibile visualizzare i componenti di rete precedenti in esecuzione nel cluster Kubernetes.

Interfacce di rete, commutatori

Il dispositivo è disponibile come configurazione a 1 nodo che costituisce il cluster di infrastruttura. Il cluster Kubernetes è separato dal cluster di infrastruttura e viene distribuito al di sopra del cluster di infrastruttura. Il cluster Kubernetes ha un nodo master e un nodo di lavoro. Entrambi i nodi Kubernetes sono macchine virtuali che eseguono le applicazioni e i flussi di lavoro cloud.

Le macchine virtuali master e di lavoro hanno ognuna due interfacce di rete, una che si connette al commutatore virtuale interno e un'altra che si connette al commutatore virtuale esterno.

• Commutatore virtuale esterno: questa opzione viene creata quando si abilita una porta del dispositivo per il calcolo tramite la pagina Calcolo nell'interfaccia utente locale. Si tratta del commutatore usato per l'infrastruttura di calcolo, ad esempio questo commutatore viene usato per le macchine virtuali distribuite nel dispositivo.

• Commutatore virtuale interno: questo commutatore viene creato come parte delle impostazioni predefinite della factory nel dispositivo. Il commutatore virtuale interno usa Nat (Network Address Translation) per instradare il traffico attraverso la porta configurata con un gateway predefinito. Ad esempio, questa opzione instrada tutte le richieste di runtime IoT dalle macchine virtuali alla portale di Azure.

Route di rete

Per le macchine virtuali Kubernetes nel dispositivo, è possibile instradare il traffico aggiungendo una nuova configurazione di route. Una configurazione di route è una voce della tabella di routing che include i campi seguenti:

Parametro	Descrizione
Destination	Un indirizzo IP o un prefisso di indirizzo IP.
Lunghezza del prefisso	Lunghezza del prefisso corrispondente all'indirizzo o all'intervallo di indirizzi nella destinazione.
Hop successivo	Indirizzo IP a cui viene inoltrato il pacchetto.
Interfaccia	Interfaccia di rete che inoltra il pacchetto IP.
Metrica	La metrica di routing determina l'interfaccia di rete preferita usata per raggiungere la destinazione.

Modificare il routing nella rete di calcolo

Usare il Add-HcsNetRoute cmdlet per modificare il routing nelle macchine virtuali master e del ruolo di lavoro Kubernetes. Si consideri il layout nel diagramma seguente.

• La porta 2 è connessa a Internet ed è il percorso desiderato per il traffico in uscita.
• È stato abilitato il calcolo sulla porta 3 e questo ha creato un commutatore virtuale esterno in questa interfaccia di rete.
• La porta 3 è connessa a una rete privata con fotocamere e altri sensori che alimentano dati non elaborati al dispositivo Azure Stack Edge per l'elaborazione.

Se un gateway è configurato nell'ambiente nella rete privata, è consigliabile impostare route personalizzate per le macchine virtuali master e di lavoro Kubernetes in modo che possano comunicare con il gateway solo per il traffico pertinente. In questo modo è possibile controllare il traffico trasmesso nella rete di calcolo rispetto alle altre porte configurate nel dispositivo Azure Stack Edge. Ad esempio, è possibile che tutti gli altri traffico con connessione Internet vengano trasmessi sulle altre porte fisiche nel dispositivo. In questo caso, il traffico con connessione Internet può attraversare la porta 2.

È anche consigliabile tenere conto di queste altre considerazioni:

• Se si dispone di una subnet flat, non è necessario aggiungere queste route alla rete privata. Facoltativamente, è possibile aggiungere queste route quando nella rete privata sono presenti più subnet.
• È possibile aggiungere queste route solo alle macchine virtuali master e di lavoro Kubernetes e non al dispositivo (host Windows).
• Prima di aggiungere questa route, non è necessario configurare il calcolo Kubernetes. È anche possibile aggiungere o aggiornare route dopo la configurazione del calcolo Kubernetes.
• È possibile aggiungere una nuova configurazione di route solo tramite l'interfaccia di PowerShell del dispositivo e non tramite l'interfaccia utente locale.
• Assicurarsi che l'interfaccia di rete che verrà usata abbia una configurazione statica.

Aggiungere una configurazione di route

Per aggiungere una nuova route personalizzata alla rete privata, usare il cmdlet come segue:

Add-HcsNetRoute -InterfaceAlias <Port number> -DestinationPrefix <Destination IP address or IP address prefix> -NextHop <IP address of next hop> -RouteMetric <Route metric number> 

Di seguito è riportato un esempio di output.

Add-HcsNetRoute -InterfaceAlias "Port3" -DestinationPrefix "192.168.20.0/24" -NextHop "192.168.20.1" -RouteMetric 100 

Il comando precedente creerà una voce nella tabella di routing che definisce una subnet di destinazione 192.168.20.0/24, specifica l'hop successivo come 192.168.20.1 e assegna a questa voce di routing una metrica di routing pari a 100. Abbassare la metrica di routing, maggiore è la priorità assegnata alla route.

Controllare la configurazione della route

Usare questo cmdlet per verificare la presenza di tutte le configurazioni di route personalizzate aggiunte nel dispositivo. Queste route non includono tutte le route di sistema o le route predefinite già esistenti nel dispositivo.

Get-HcsNetRoute -InterfaceAlias <Port number>

Rimuovere una configurazione di route

Usare questo cmdlet per rimuovere una configurazione di route aggiunta nel dispositivo.

Remove-HcsNetRoute -InterfaceAlias <Port number> -DestinationPrefix <Destination IP or IP prefix>

Routing con più interfacce di rete

Se sono connesse più porte del dispositivo, il raggruppamento NIC standard o switch embedded teaming (edizione Standard T) che consente di raggruppare più schede di rete fisiche in una singola scheda di rete virtuale in un ambiente Hyper-V, non è supportata.

Passaggi successivi

Per configurare la rete Kubernetes nella GPU di Azure Stack Edge Pro, vedere:

• Esporre un'applicazione senza stato esternamente nella GPU di Azure Stack Edge Pro tramite IoT Edge.

• Esporre un'applicazione senza stato esternamente nella GPU di Azure Stack Edge Pro tramite kuebctl.