Usare un servizio di bilanciamento del carico standard pubblico in servizio Azure Kubernetes (servizio Azure Kubernetes)

  • Articolo

Azure Load Balancer opera al livello 4 del modello OSI (Open Systems Interconnect) che supporta scenari in ingresso e in uscita. Distribuisce i flussi in ingresso che arrivano al front-end del servizio di bilanciamento del carico alle istanze del pool back-end.

Un servizio di bilanciamento del carico pubblico integrato con il servizio Azure Kubernetes svolge due scopi:

  1. Per fornire connessioni in uscita ai nodi del cluster all'interno della rete virtuale del servizio Azure Kubernetes convertendo l'indirizzo IP privato in un indirizzo IP pubblico incluso nel pool in uscita.
  2. Per fornire l'accesso alle applicazioni tramite i servizi Kubernetes di tipo LoadBalancer, consentendo di ridimensionare facilmente le applicazioni e creare servizi a disponibilità elevata.

Un servizio di bilanciamento del carico interno (o privato) viene usato quando solo gli INDIRIZZI IP privati sono consentiti come front-end. I bilanciamenti del carico interni vengono usati per bilanciare il carico del traffico all'interno di una rete virtuale. È possibile accedere al front-end di servizio di bilanciamento del carico da una rete locale in uno scenario ibrido.

Questo articolo illustra l'integrazione con un servizio di bilanciamento del carico pubblico nel servizio Azure Kubernetes. Per l'integrazione del servizio di bilanciamento del carico interno, vedere Usare un servizio di bilanciamento del carico interno nel servizio Azure Kubernetes.

Operazioni preliminari

  • Azure Load Balancer è disponibile in due SKU: Basic e Standard. Lo SKU Standard viene usato per impostazione predefinita quando si crea un cluster del servizio Azure Kubernetes. Lo SKU Standard consente di accedere alle funzionalità aggiunte, ad esempio un pool back-end più grande, più pool di nodi, zone di disponibilità ed è sicuro per impostazione predefinita. Si tratta dello SKU del servizio di bilanciamento del carico consigliato per il servizio Azure Kubernetes. Per altre informazioni sugli SKU Basic e Standard , vedere Confronto tra SKU di Azure Load Balancer.
  • Per un elenco completo delle annotazioni supportate per i servizi Kubernetes con tipo LoadBalancer, vedere Annotazioni di LoadBalancer.
  • Questo articolo presuppone che sia presente un cluster del servizio Azure Kubernetes con Azure Load Balancer con SKU Standard. Se è necessario un cluster del servizio Azure Kubernetes, è possibile crearne uno usando l'interfaccia della riga di comando di Azure, Azure PowerShell o il portale di Azure.
  • Il servizio Azure Kubernetes gestisce il ciclo di vita e le operazioni dei nodi dell'agente. La modifica delle risorse IaaS associate ai nodi dell'agente non è supportata. Un esempio di operazione non supportata consiste nell'apportare modifiche manuali al gruppo di risorse del servizio di bilanciamento del carico.

Importante

Se si preferisce usare il gateway, il firewall o il proxy per fornire una connessione in uscita, è possibile ignorare la creazione del pool in uscita del servizio di bilanciamento del carico e il rispettivo indirizzo IP front-end usando il tipo in uscita come UserDefinedRouting (UDR). Il tipo in uscita definisce il metodo in uscita per un cluster e per impostazione predefinita è di tipo LoadBalancer.

Usare il servizio di bilanciamento del carico standard pubblico

Dopo aver creato un cluster del servizio Azure Kubernetes con tipo LoadBalancer in uscita (impostazione predefinita), il cluster è pronto per l'uso del servizio di bilanciamento del carico per esporre i servizi.

Creare un manifesto del servizio denominato public-svc.yaml, che crea un servizio pubblico di tipo LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

Specificare l'indirizzo IP del servizio di bilanciamento del carico

Se si vuole usare un indirizzo IP specifico con il servizio di bilanciamento del carico, esistono due modi:

Importante

L'aggiunta della proprietà LoadBalancerIP al manifesto YAML del servizio di bilanciamento del carico è deprecata dopo Kubernetes upstream. Anche se l'utilizzo corrente rimane invariato e si prevede che i servizi esistenti funzionino senza modifiche, è consigliabile impostare invece le annotazioni del servizio.

  • Impostare le annotazioni del servizio: usare service.beta.kubernetes.io/azure-load-balancer-ipv4 per un indirizzo IPv4 e service.beta.kubernetes.io/azure-load-balancer-ipv6 per un indirizzo IPv6.
  • Aggiungere la proprietà LoadBalancerIP al manifesto YAML del servizio di bilanciamento del carico: aggiungere la proprietà Service.Spec.LoadBalancerIP al manifesto YAML del servizio di bilanciamento del carico. Questo campo è deprecato in seguito a Kubernetes upstream e non può supportare dual stack. L'utilizzo corrente rimane invariato e si prevede che i servizi esistenti funzionino senza modifiche.

Distribuire il manifesto del servizio

Distribuire il manifesto del servizio pubblico usando kubectl apply e specificare il nome del manifesto YAML.

kubectl apply -f public-svc.yaml

Azure Load Balancer è configurato con un nuovo indirizzo IP pubblico che precede il nuovo servizio. Poiché Azure Load Balancer può avere più indirizzi IP front-end, ogni nuovo servizio distribuito ottiene un nuovo indirizzo IP front-end dedicato a cui accedere in modo univoco.

Verificare che il servizio sia stato creato e che il servizio di bilanciamento del carico sia configurato usando il comando seguente.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

Quando si visualizzano i dettagli del servizio, nella colonna EXTERNAL-IP viene visualizzato l'indirizzo IP pubblico creato per questo servizio nel servizio di bilanciamento del carico. Potrebbero essere necessari alcuni minuti per passare dall'indirizzo <IP in sospeso> a un indirizzo IP pubblico effettivo.

Per informazioni più dettagliate sul servizio, usare il comando seguente.

kubectl describe service public-svc

L'output di esempio seguente è una versione condensata dell'output dopo l'esecuzione kubectl describe servicedi . LoadBalancer Ingress mostra l'indirizzo IP esterno esposto dal servizio. IP mostra gli indirizzi interni.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

Configurare il servizio di bilanciamento del carico standard pubblico

È possibile personalizzare impostazioni diverse per il servizio di bilanciamento del carico pubblico standard in fase di creazione del cluster o aggiornando il cluster. Queste opzioni di personalizzazione consentono di creare un servizio di bilanciamento del carico che soddisfi le esigenze del carico di lavoro. Con il servizio di bilanciamento del carico standard è possibile:

  • Impostare o ridimensionare il numero di indirizzi IP in uscita gestiti.
  • Usare indirizzi IP in uscita personalizzati o prefisso IP in uscita.
  • Personalizzare il numero di porte in uscita allocate a ogni nodo nel cluster.
  • Configurare l'impostazione di timeout per le connessioni inattive.

Importante

È possibile usare un'unica opzione IP in uscita (indirizzi IP gestiti, bring your own IP o prefisso IP) in un determinato momento.

Modificare il tipo di pool in ingresso

È possibile fare riferimento ai nodi del servizio Azure Kubernetes nei pool back-end del servizio di bilanciamento del carico tramite la configurazione IP (appartenenza basata su Azure set di scalabilità di macchine virtuali) o solo tramite l'indirizzo IP. L'utilizzo dell'appartenenza al pool back-end basato su indirizzi IP garantisce maggiore efficienza durante l'aggiornamento dei servizi e il provisioning di servizi di bilanciamento del carico, in particolare in caso di numero elevato di nodi. Il provisioning di nuovi cluster con pool back-end basati su IP e la conversione dei cluster esistenti è ora supportato. In combinazione con i tipi di uscita del gateway NAT o di routing definiti dall'utente, il provisioning di nuovi nodi e servizi è più efficiente.

Sono disponibili due diversi tipi di appartenenza al pool:

  • nodeIPConfiguration- Legacy set di scalabilità di macchine virtuali tipo di appartenenza al pool basato sulla configurazione IP
  • nodeIP - Tipo di appartenenza basato su IP

Requisiti

  • Il cluster del servizio Azure Kubernetes deve essere versione 1.23 o successiva.
  • Il cluster del servizio Azure Kubernetes deve usare servizi di bilanciamento del carico standard e set di scalabilità di macchine virtuali.

Limiti

  • I cluster che usano pool back-end basati su IP sono limitati a 2500 nodi.

Creare un nuovo cluster del servizio Azure Kubernetes con appartenenza al pool in ingresso basato su IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Aggiornare un cluster del servizio Azure Kubernetes esistente per l'uso dell'appartenenza al pool in ingresso basato su IP

Avviso

Questa operazione causa un'interruzione temporanea del traffico del servizio in ingresso nel cluster. Il tempo di impatto aumenta con cluster più grandi con molti nodi.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

Ridimensionare il numero di indirizzi IP pubblici in uscita gestiti

Azure Load Balancer offre connettività in uscita e in ingresso da una rete virtuale. Le regole in uscita semplificano la configurazione della conversione degli indirizzi di rete per il servizio di bilanciamento del carico standard pubblico.

Le regole in uscita seguono la stessa sintassi del bilanciamento del carico e delle regole NAT in ingresso:

INDIRIZZI IP front-end + parametri + pool back-end

Una regola in uscita configura NAT in uscita per tutte le macchine virtuali identificate dal pool back-end da convertire in front-end. I parametri forniscono un maggiore controllo sull'algoritmo NAT in uscita.

Anche se è possibile usare una regola in uscita con un singolo indirizzo IP pubblico, le regole in uscita sono ideali per il ridimensionamento di NAT in uscita perché semplificano il carico di configurazione. È possibile usare più indirizzi IP per pianificare scenari su larga scala e regole in uscita per attenuare i modelli soggetti a esaurimento SNAT. Ogni indirizzo IP fornito da un front-end fornisce porte temporanee di 64k per il servizio di bilanciamento del carico da usare come porte SNAT.

Quando si usa un servizio di bilanciamento del carico dello SKU Standard con indirizzi IP pubblici in uscita gestiti (creati per impostazione predefinita), è possibile ridimensionare il numero di indirizzi IP pubblici in uscita gestiti usando il --load-balancer-managed-outbound-ip-count parametro .

Usare il comando seguente per aggiornare un cluster esistente. È anche possibile impostare questo parametro per avere più indirizzi IP pubblici in uscita gestiti.

Importante

Non è consigliabile usare il portale di Azure per apportare modifiche alle regole in uscita. Quando si apportano queste modifiche, è necessario passare attraverso il cluster del servizio Azure Kubernetes e non direttamente nella risorsa di Load Balancer.

Le modifiche alle regole in uscita apportate direttamente nella risorsa di Load Balancer vengono rimosse ogni volta che il cluster viene riconciliato, ad esempio quando viene arrestato, avviato, aggiornato o ridimensionato.

Usare l'interfaccia della riga di comando di Azure, come illustrato negli esempi. Le modifiche alle regole in uscita apportate tramite az aks i comandi dell'interfaccia della riga di comando sono permanenti durante i tempi di inattività del cluster.

Per altre informazioni, vedere Regole in uscita di Azure Load Balancer.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

L'esempio precedente imposta il numero di indirizzi IP pubblici in uscita gestiti su 2 per il cluster myAKSCluster in myResourceGroup.

In fase di creazione del cluster, è anche possibile impostare il numero iniziale di indirizzi IP pubblici in uscita gestiti aggiungendo il --load-balancer-managed-outbound-ip-count parametro e impostandolo sul valore desiderato. Il numero predefinito di indirizzi IP pubblici in uscita gestiti è 1.

Specificare indirizzi IP pubblici o prefissi pubblici in uscita

Quando si usa un servizio di bilanciamento del carico dello SKU Standard , il cluster servizio Azure Kubernetes crea automaticamente un indirizzo IP pubblico nel gruppo di risorse dell'infrastruttura gestita dal servizio Azure Kubernetes e lo assegna al pool in uscita del servizio di bilanciamento del carico per impostazione predefinita.

Un indirizzo IP pubblico creato dal servizio Azure Kubernetes è una risorsa gestita dal servizio Azure Kubernetes, ovvero gestisce il ciclo di vita di tale indirizzo IP pubblico e non richiede l'azione dell'utente direttamente sulla risorsa IP pubblica. In alternativa, è possibile assegnare un proprio indirizzo IP pubblico personalizzato o un prefisso IP pubblico al momento della creazione del cluster. Gli indirizzi IP personalizzati possono anche essere aggiornati nelle proprietà del servizio di bilanciamento del carico di un cluster esistente.

I requisiti per l'uso del proprio indirizzo IP pubblico o prefisso includono:

  • Gli utenti devono creare e possedere indirizzi IP pubblici personalizzati. Gli indirizzi IP pubblici gestiti creati dal servizio Azure Kubernetes non possono essere riutilizzati come "bring your own IP personalizzato" perché possono causare conflitti di gestione.
  • È necessario assicurarsi che l'identità del cluster del servizio Azure Kubernetes (entità servizio o identità gestita) disponga delle autorizzazioni per accedere all'indirizzo IP in uscita, in base all'elenco di autorizzazioni IP pubblico necessarie.
  • Assicurarsi di soddisfare i prerequisiti e i vincoli necessari per configurare gli INDIRIZZI IP in uscita o i prefissi IP in uscita.

Aggiornare il cluster con il proprio indirizzo IP pubblico in uscita

Usare il az network public-ip show comando per elencare gli ID degli indirizzi IP pubblici.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

Il comando precedente mostra l'ID dell'indirizzo IP pubblico myPublicIP nel gruppo di risorse myResourceGroup.

Usare il az aks update comando con il load-balancer-outbound-ips parametro per aggiornare il cluster con gli indirizzi IP pubblici.

Nell'esempio seguente viene usato il load-balancer-outbound-ips parametro con gli ID del comando precedente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Aggiornare il cluster con il proprio prefisso IP pubblico in uscita

È anche possibile usare i prefissi degli indirizzi IP pubblici per l'uscita con l'istanza di bilanciamento del carico con SKU Standard. Nell'esempio seguente viene usato il comando az network public-ip prefix show per elencare gli ID dei prefissi IP pubblici.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

Il comando precedente mostra l'ID del prefisso dell'indirizzo IP pubblico myPublicIPPrefix nel gruppo di risorse myResourceGroup.

L'esempio seguente usa il parametro load-balancer-outbound-ip-prefixes con gli ID del comando precedente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Creare il cluster con i propri prefissi o IP pubblici

Quando si crea il cluster, è possibile usare indirizzi IP personalizzati o prefissi IP per l'uscita per supportare scenari come l'aggiunta di endpoint in uscita a un elenco elementi consentiti. Per definire i propri indirizzi IP pubblici e prefissi IP in fase di creazione del cluster, aggiungere gli stessi parametri mostrati nel comando precedente.

Usare il az aks create comando con il load-balancer-outbound-ips parametro per creare un nuovo cluster con indirizzi IP pubblici personalizzati.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

Usare il az aks create comando con il load-balancer-outbound-ip-prefixes parametro per creare un nuovo cluster con prefissi IP pubblici.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

Configurare le porte in uscita allocate

Importante

Se nel cluster sono presenti applicazioni in grado di stabilire un numero elevato di connessioni a un piccolo set di destinazioni, ad esempio molte istanze di un'applicazione front-end che si connettono a un database, potrebbe verificarsi un esaurimento delle porte SNAT. L'esaurimento delle porte SNAT si verifica quando un'applicazione esce dalle porte in uscita da usare per stabilire una connessione a un'altra applicazione o a un altro host. Se si ha uno scenario soggetto all'esaurimento delle porte SNAT, è consigliabile aumentare le porte in uscita allocate e gli INDIRIZZI IP front-end in uscita nel servizio di bilanciamento del carico.

Per altre informazioni su SNAT, vedere Usare SNAT per le connessioni in uscita.

Per impostazione predefinita, il servizio Azure Kubernetes imposta AllocateOutboundPorts sul servizio di bilanciamento del carico su 0, che consente l'assegnazione automatica delle porte in uscita in base alle dimensioni del pool back-end durante la creazione di un cluster. Ad esempio, se un cluster dispone di 50 o meno nodi, 1024 porte vengono allocate a ogni nodo. Man mano che aumenta il numero di nodi nel cluster, sono disponibili meno porte per nodo.

Importante

Esiste un limite rigido di 1024 porte indipendentemente dal fatto che vengano aggiunti indirizzi IP front-end quando le dimensioni del nodo sono minori o uguali a 50 (1-50).

Per visualizzare il valore AllocateOutboundPorts per il servizio di bilanciamento del carico del cluster del servizio Azure Kubernetes, usare az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

L'output di esempio seguente mostra che l'assegnazione automatica delle porte in uscita in base alle dimensioni del pool back-end è abilitata per il cluster.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

Per configurare un valore specifico per AllocateOutboundPorts e l'indirizzo IP in uscita durante la creazione o l'aggiornamento di un cluster, usare load-balancer-outbound-ports e load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipso load-balancer-outbound-ip-prefixes. Prima di impostare un valore specifico o aumentare un valore esistente per le porte in uscita o gli indirizzi IP in uscita, è necessario calcolare il numero appropriato di porte e indirizzi IP in uscita. Usare l'equazione seguente per questo calcolo arrotondato all'intero più vicino: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

Quando si calcola il numero di porte e indirizzi IP in uscita e si impostano i valori, tenere presenti le informazioni seguenti:

  • Il numero di porte in uscita per nodo è fisso in base al valore impostato.
  • Il valore per le porte in uscita deve essere un multiplo di 8.
  • L'aggiunta di altri indirizzi IP non aggiunge altre porte ad alcun nodo, ma offre capacità per più nodi nel cluster.
  • È necessario tenere conto dei nodi che potrebbero essere aggiunti come parte degli aggiornamenti, incluso il numero di nodi specificati tramite valori maxSurge.

Gli esempi seguenti illustrano come i valori impostati influiscono sul numero di porte e indirizzi IP in uscita:

  • Se vengono usati i valori predefiniti e il cluster ha 48 nodi, ogni nodo dispone di 1024 porte disponibili.
  • Se vengono usati i valori predefiniti e il cluster viene ridimensionato da 48 a 52 nodi, ogni nodo viene aggiornato da 1024 porte disponibili a 512 porte disponibili.
  • Se il numero di porte in uscita è impostato su 1.000 e il numero di indirizzi IP in uscita è impostato su 2, il cluster può supportare un massimo di 128 nodi: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • Se il numero di porte in uscita è impostato su 1.000 e il numero di indirizzi IP in uscita è impostato su 7, il cluster può supportare un massimo di 448 nodi: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • Se il numero di porte in uscita è impostato su 4.000 e il numero di indirizzi IP in uscita è impostato su 2, il cluster può supportare un massimo di 32 nodi: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • Se il numero di porte in uscita è impostato su 4.000 e il numero di indirizzi IP in uscita è impostato su 7, il cluster può supportare un massimo di 112 nodi: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

Importante

Dopo aver calcolato il numero di porte e indirizzi IP in uscita, verificare di avere capacità aggiuntiva di porta in uscita per gestire l'aumento del numero di nodi durante gli aggiornamenti. È fondamentale allocare porte in eccesso sufficienti per i nodi aggiuntivi necessari per l'aggiornamento e altre operazioni. Il servizio Azure Kubernetes usa per impostazione predefinita un nodo buffer per le operazioni di aggiornamento. Se si usano valori maxSurge, moltiplicare le porte in uscita per nodo in base al valore maxSurge per determinare il numero di porte necessarie. Ad esempio, se si calcola che sono necessarie 4000 porte per nodo con 7 indirizzi IP in un cluster con un massimo di 100 nodi e un massimo di 2:

  • 2 nodi di picco * 4000 porte per nodo = 8000 porte necessarie per l'aumento del nodo durante gli aggiornamenti.
  • 100 nodi * 4000 porte per nodo = 400.000 porte necessarie per il cluster.
  • 7 INDIRIZZI IP * 64000 porte per IP = 448.000 porte disponibili per il cluster.

L'esempio precedente mostra che il cluster ha una capacità superiore a 48.000 porte, che è sufficiente per gestire le 8000 porte necessarie per l'aumento del numero di nodi durante gli aggiornamenti.

Dopo aver calcolato e verificato i valori, è possibile applicare tali valori usando load-balancer-outbound-ports e load-balancer-managed-outbound-ip-count, load-balancer-outbound-ipso load-balancer-outbound-ip-prefixes durante la creazione o l'aggiornamento di un cluster.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

Configurare il timeout di inattività del servizio di bilanciamento del carico

Quando si esauriscono le risorse di porte SNAT, i flussi in uscita vengono completati dopo che i flussi esistenti rilasciano le porte SNAT. Il servizio di bilanciamento del carico recupera le porte SNAT alla chiusura del flusso e il servizio di bilanciamento del carico configurato dal servizio Azure Kubernetes usa un timeout di inattività di 30 minuti per recuperare le porte SNAT dai flussi inattive.

È anche possibile usare il trasporto (ad esempio, TCP keepalives o application-layer keepalives) per aggiornare un flusso inattiva e reimpostare questo timeout di inattività, se necessario. È possibile configurare questo timeout seguendo l'esempio seguente.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

Se si prevede di avere numerose connessioni di breve durata e nessuna connessione di lunga durata che potrebbe avere lunghi tempi di inattività, ad esempio l'uso kubectl proxy di o kubectl port-forward, è consigliabile usare un valore di timeout basso, ad esempio 4 minuti. Quando si usano keep-alive TCP, è sufficiente abilitarli sul lato della connessione. Ad esempio, è sufficiente abilitarli sul lato server solo per reimpostare il timer di inattività del flusso. Non è necessario che entrambi i lati avviino i keep-alives TCP. Si applicano concetti simili anche per il livello dell'applicazione, tra cui le configurazioni client-server di database. Controllare il lato server per verificare le opzioni disponibili per keep-alive specifici dell'applicazione.

Importante

Il servizio Azure Kubernetes abilita la reimpostazione TCP inattiva per impostazione predefinita. È consigliabile mantenere questa configurazione e sfruttarla per un comportamento dell'applicazione più prevedibile sugli scenari.

Tcp RST viene inviato solo durante la connessione TCP nello stato ESTABLISHED. Per altre informazioni, leggere qui.

Quando si imposta IdleTimeoutInMinutes su un valore diverso da quello predefinito di 30 minuti, valutare per quanto tempo i carichi di lavoro necessitano di una connessione in uscita. Si consideri anche che il valore di timeout predefinito per un servizio di bilanciamento del carico dello SKU Standard usato al di fuori del servizio Azure Kubernetes è di 4 minuti. Un valore di IdleTimeoutInMinutes che riflette in modo più accurato il carico di lavoro del servizio Azure Kubernetes specifico può contribuire a ridurre l'esaurimento SNAT causato dal collegamento di connessioni non più utilizzate.

Avviso

La modifica dei valori per AllocateOutboundPorts e IdleTimeoutInMinutes potrebbe modificare significativamente il comportamento della regola in uscita per il servizio di bilanciamento del carico e non deve essere eseguita in modo leggero. Controllare la sezione Risoluzione dei problemi SNAT ed esaminare le regole di bilanciamento del carico in uscita e le connessioni in uscita in Azure prima di aggiornare questi valori per comprendere appieno l'impatto delle modifiche.

Limitare il traffico in ingresso a intervalli IP specifici

Il manifesto seguente usa loadBalancerSourceRanges per specificare un nuovo intervallo IP per il traffico esterno in ingresso.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

Questo esempio aggiorna la regola per consentire il traffico esterno in ingresso solo dall'intervallo MY_EXTERNAL_IP_RANGE . Se si sostituisce MY_EXTERNAL_IP_RANGE con l'indirizzo IP della subnet interna, il traffico è limitato solo agli INDIRIZZI IP interni del cluster. Se il traffico è limitato agli indirizzi IP interni del cluster, i client esterni al cluster Kubernetes non sono in grado di accedere al servizio di bilanciamento del carico.

Nota

  • Il traffico esterno in ingresso passa dal servizio di bilanciamento del carico alla rete virtuale per il cluster del servizio Azure Kubernetes. La rete virtuale ha un gruppo di sicurezza di rete (NSG) che consente tutto il traffico in ingresso dal servizio di bilanciamento del carico. Questo gruppo di sicurezza di rete usa un tag di servizio di tipo LoadBalancer per consentire il traffico dal servizio di bilanciamento del carico.
  • Il CIDR del pod deve essere aggiunto a loadBalancerSourceRanges se sono presenti pod che devono accedere all'INDIRIZZO IP loadBalancer del servizio per i cluster con versione 1.25 o successiva.

Gestire l'INDIRIZZO IP del client nelle connessioni in ingresso

Per impostazione predefinita, un servizio di tipo LoadBalancerin Kubernetes e nel servizio Azure Kubernetes non rende persistente l'indirizzo IP del client nella connessione al pod. L'INDIRIZZO IP di origine nel pacchetto recapitato al pod diventa l'INDIRIZZO IP privato del nodo. Per mantenere l'indirizzo IP del client, è necessario impostare su service.spec.externalTrafficPolicylocal nella definizione del servizio. Il manifesto seguente mostra un esempio.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

Personalizzazioni tramite annotazioni Kubernetes

Le annotazioni seguenti sono supportate per i servizi Kubernetes con tipo LoadBalancere si applicano solo ai flussi INBOUND .

Annotazione Valore Descrizione
service.beta.kubernetes.io/azure-load-balancer-internal true oppure false Specificare se il servizio di bilanciamento del carico deve essere interno. Se non è impostato, il valore predefinito è pubblico.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet Nome della subnet Specificare la subnet a cui deve essere associato il servizio di bilanciamento del carico interno. Se non è impostata, per impostazione predefinita viene impostata la subnet configurata nel file di configurazione cloud.
service.beta.kubernetes.io/azure-dns-label-name Nome dell'etichetta DNS negli indirizzi IP pubblici Specificare il nome dell'etichetta DNS per il servizio pubblico . Se è impostata su una stringa vuota, la voce DNS nell'indirizzo IP pubblico non viene usata.
service.beta.kubernetes.io/azure-shared-securityrule true oppure false Specificare l'esposizione del servizio tramite una regola di sicurezza di Azure potenzialmente condivisa per aumentare l'esposizione del servizio, usando le regole di sicurezza aumentata di Azure nei gruppi di sicurezza di rete.
service.beta.kubernetes.io/azure-load-balancer-resource-group Nome del gruppo di risorse Specificare il gruppo di risorse di indirizzi IP pubblici del servizio di bilanciamento del carico che non si trovano nello stesso gruppo di risorse dell'infrastruttura del cluster (gruppo di risorse nodo).
service.beta.kubernetes.io/azure-allowed-service-tags Elenco dei tag di servizio consentiti Specificare un elenco di tag di servizio consentiti separati da virgole.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout Timeout di inattività TCP in minuti Specificare il tempo in minuti per i timeout di inattività della connessione TCP nel servizio di bilanciamento del carico. Il valore predefinito e minimo è 4. Il valore massimo è 30. Il valore deve essere un numero intero.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true oppure false Specificare se il servizio di bilanciamento del carico deve disabilitare la reimpostazione TCP al timeout di inattività.
service.beta.kubernetes.io/azure-load-balancer-ipv4 Indirizzo IPv4 Specificare l'indirizzo IPv4 da assegnare al servizio di bilanciamento del carico.
service.beta.kubernetes.io/azure-load-balancer-ipv6 Indirizzo IPv6 Specificare l'indirizzo IPv6 da assegnare al servizio di bilanciamento del carico.

Personalizzare il probe di integrità del servizio di bilanciamento del carico

Annotazione Valore Descrizione
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Intervallo probe di integrità
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Numero minimo di risposte non integre del probe di integrità
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Percorso della richiesta del probe di integrità
service.beta.kubernetes.io/port_{port}_no_lb_rule true/false {port} è il numero di porta del servizio. Se impostato su true, non viene generata alcuna regola lb o regola probe di integrità per questa porta. Il servizio controllo integrità non deve essere esposto alla rete Internet pubblica(ad esempio, istio/envoy health check service)
service.beta.kubernetes.io/port_{port}_no_probe_rule true/false {port} è il numero di porta del servizio. Se impostato su true, non viene generata alcuna regola del probe di integrità per questa porta.
service.beta.kubernetes.io/port_{port}_health-probe_protocol Protocollo probe di integrità {port} è il numero di porta del servizio. Protocollo esplicito per il probe di integrità per la porta del servizio {port}, override di port.appProtocol se impostato.
service.beta.kubernetes.io/port_{port}_health-probe_port numero di porta o nome della porta nel manifesto del servizio {port} è il numero di porta del servizio. Porta esplicita per il probe di integrità per la porta del servizio {porta}, sostituendo il valore predefinito.
service.beta.kubernetes.io/port_{port}_health-probe_interval Intervallo probe di integrità {port} è il numero di porta del servizio.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe Numero minimo di risposte non integre del probe di integrità {port} è il numero di porta del servizio.
service.beta.kubernetes.io/port_{port}_health-probe_request-path Percorso della richiesta del probe di integrità {port} è il numero di porta del servizio.

Come documentato qui, Tcp, Http e Https sono tre protocolli supportati dal servizio di bilanciamento del carico.

Attualmente, il protocollo predefinito del probe di integrità varia tra i servizi con protocolli di trasporto diversi, protocolli di app, annotazioni e criteri di traffico esterni.

  1. per i servizi locali, vengono usati HTTP e /healthz. Il probe di integrità eseguirà query su NodeHealthPort anziché sul servizio back-end effettivo
  2. per i servizi TCP del cluster, viene usato TCP.
  3. per i servizi UDP del cluster, nessun probe di integrità.

Nota

Per i servizi locali con l'integrazione PLS e il protocollo proxy PLS abilitato, il probe di integrità HTTP+/healthz predefinito non funziona. Il probe di integrità può quindi essere personalizzato allo stesso modo dei servizi cluster per supportare questo scenario.

A partire dalla versione 1.20, viene introdotta l'annotazione service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path del servizio per determinare il comportamento del probe di integrità.

  • Per i <cluster =1.23, spec.ports.appProtocol viene usato solo come protocollo probe quando service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path viene impostato anche .
  • Per i >cluster 1.24, spec.ports.appProtocol verrebbe usato come protocollo probe e / verrebbe usato come percorso di richiesta probe predefinito (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path potrebbe essere usato per passare a un percorso di richiesta diverso).

Si noti che il percorso della richiesta viene ignorato quando si usa TCP o è spec.ports.appProtocol vuoto. In particolare:

sku loadbalancer externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Protocollo probe LB Percorso richiesta probe LB
standard local qualsiasi qualsiasi qualsiasi http /healthz
standard cluster udp qualsiasi qualsiasi Null Null
standard cluster tcp (ignorato) tcp Null
standard cluster tcp tcp (ignorato) tcp Null
standard cluster tcp http/https TCP(<=1.23) o http/https(>=1.24) null(<=1.23) o /(>=1.24)
standard cluster tcp http/https /custom-path http/https /custom-path
standard cluster tcp protocollo non supportato /custom-path tcp Null
basic local qualsiasi qualsiasi qualsiasi http /healthz
basic cluster tcp (ignorato) tcp Null
basic cluster tcp tcp (ignorato) tcp Null
basic cluster tcp http TCP(<=1.23) o http/https(>=1.24) null(<=1.23) o /(>=1.24)
basic cluster tcp http /custom-path http /custom-path
basic cluster tcp protocollo non supportato /custom-path tcp Null

Dalla versione 1.21 sono state introdotte due annotazioni service.beta.kubernetes.io/azure-load-balancer-health-probe-interval del servizio e load-balancer-health-probe-num-of-probe che personalizzano la configurazione del probe di integrità. Se service.beta.kubernetes.io/azure-load-balancer-health-probe-interval non è impostato, viene applicato il valore predefinito 5. Se load-balancer-health-probe-num-of-probe non è impostato, viene applicato il valore predefinito 2. E il probe totale deve essere inferiore a 120 secondi.

Probe di integrità personalizzato di Load Balancer per la porta

Porte diverse in un servizio possono richiedere configurazioni di probe di integrità diverse. Ciò potrebbe essere dovuto alla progettazione del servizio ( ad esempio un singolo endpoint di integrità che controlla più porte) o a funzionalità di Kubernetes come MixedProtocolLBService.

Le annotazioni seguenti possono essere usate per personalizzare la configurazione del probe per porta del servizio.

annotazione specifica della porta annotazione probe globale Utilizzo
service.beta.kubernetes.io/port_{porta}_no_lb_rule N/D (nessun equivalente a livello globale) se impostato su true, non verranno generate regole lb e regole probe
service.beta.kubernetes.io/port_{port}_no_probe_rule N/D (nessun equivalente a livello globale) se impostato su true, non verranno generate regole probe
service.beta.kubernetes.io/port_{port}_health-probe_protocol N/D (nessun equivalente a livello globale) Impostare il protocollo probe di integrità per questa porta del servizio (ad esempio Http, Https, Tcp)
service.beta.kubernetes.io/port_{port}_health-probe_port N/D (nessun equivalente a livello globale) Imposta la porta probe di integrità per questa porta del servizio (ad esempio 15021)
service.beta.kubernetes.io/port_{port}_health-probe_request-path service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path Per Http o Https, imposta il percorso della richiesta del probe di integrità. Il valore predefinito è /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe Numero di errori di probe consecutivi prima che la porta venga considerata non integra
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval Quantità di tempo tra i tentativi di probe

Per il manifesto seguente, la regola probe per la porta httpsserver è diversa da quella per httpserver perché sono specificate annotazioni per il server https della porta.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

In questo manifesto le porte HTTPS usano una porta del nodo diversa, un controllo di conformità HTTP sulla porta 10256 in /healthz(endpointz healthz di kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

In questo manifesto le porte HTTPS usano un endpoint del probe di integrità diverso, un controllo di idoneità HTTP sulla porta 30000 su /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

Risoluzione dei problemi di SNAT

Se si è certi che si stanno avviando molte connessioni TCP o UDP in uscita allo stesso indirizzo IP e porta di destinazione e si osservano connessioni in uscita non riuscite o viene visualizzato un messaggio di notifica che informa che si stanno esaurendo le porte SNAT (porte temporanee preallocate usate da PAT), sono disponibili diverse opzioni di mitigazione generali. Esaminare queste opzioni e decidere qual è la soluzione migliore per lo scenario in uso. È possibile che uno o più possano aiutare a gestire lo scenario. Per informazioni dettagliate, vedere la guida alla risoluzione dei problemi delle connessioni in uscita.

La causa radice dell'esaurimento SNAT è spesso un anti-modello per stabilire, gestire o configurare timer in uscita modificati rispetto ai valori predefiniti. Leggere attentamente questa sezione.

Passaggi

  1. Controllare se le connessioni rimangono inattive per molto tempo e si basano sul timeout di inattività predefinito per il rilascio di tale porta. In tal caso, potrebbe essere necessario ridurre il timeout predefinito di 30 minuti per lo scenario.
  2. Esaminare il modo in cui l'applicazione crea la connettività in uscita, ad esempio la revisione del codice o l'acquisizione di pacchetti.
  3. Determinare se questa attività è un comportamento previsto o se l'applicazione non funziona correttamente. Usare metriche e log in Monitoraggio di Azure per verificare i risultati. Ad esempio, usare la categoria "Failed" per la metrica delle connessioni SNAT.
  4. Valutare se vengono seguiti i modelli appropriati.
  5. Valutare se l'esaurimento delle porte SNAT deve essere mitigato con più indirizzi IP in uscita e più porte in uscita allocate.

Schemi progettuali

Sfruttare il riutilizzo della connessione e il pool di connessioni quando possibile. Questi modelli consentono di evitare problemi di esaurimento delle risorse e comportano un comportamento prevedibile. Le primitive per questi modelli sono reperibili in molti framework e librerie di sviluppo.

  • Le richieste atomiche (una richiesta per connessione) in genere non sono una buona scelta di progettazione. Tali anti-pattern limitano la scalabilità, riducono le prestazioni e riducono l'affidabilità. Riutilizzare invece le connessioni HTTP/S per ridurre il numero di connessioni e delle porte SNAT associate. La scalabilità delle applicazioni aumenta e migliora le prestazioni a causa di handshake, sovraccarichi e costi delle operazioni di crittografia ridotti quando si usa TLS.
  • Se si usa un DNS fuori cluster/personalizzato o server upstream personalizzati in coreDNS, tenere presente che DNS può introdurre molti flussi singoli al volume quando il client non memorizza nella cache il risultato dei resolver DNS. Assicurarsi di personalizzare prima coreDNS invece di usare server DNS personalizzati e definire un buon valore di memorizzazione nella cache.
  • I flussi UDP (ad esempio, le ricerche DNS) allocano le porte SNAT durante il timeout di inattività. Più è lungo il timeout di inattività, maggiore è la pressione sulle porte SNAT. Usare un timeout di inattività breve, ad esempio 4 minuti.
  • Usare i pool di connessioni per definire il volume di connessioni.
  • Non abbandonare mai un flusso TCP e non fare affidamento sui timer TCP per pulire il flusso. Se non si consente a TCP di chiudere in modo esplicito la connessione, lo stato rimane allocato a sistemi e endpoint intermedi e rende le porte SNAT non disponibili per altre connessioni. Questo schema può generare errori dell'applicazione e l'esaurimento SNAT.
  • Non cambiare i valori del timer correlati alla chiusura TCP a livello di sistema operativo se non se ne conosce perfettamente l'impatto. Mentre lo stack TCP viene ripristinato, le prestazioni dell'applicazione possono essere influenzate negativamente quando gli endpoint di una connessione non corrispondono alle aspettative. L'intenzione di modificare i timer è in genere un segno di un problema di progettazione sottostante. Esaminare le raccomandazioni seguenti.

Passaggio da un servizio di bilanciamento del carico SKU Basic allo SKU Standard

Se si dispone di un cluster esistente con il servizio di bilanciamento del carico dello SKU Basic , esistono importanti differenze comportamentali da notare durante la migrazione al servizio di bilanciamento del carico dello SKU Standard .

Ad esempio, l'esecuzione di distribuzioni blu/verde per la migrazione dei cluster è una pratica comune in base al load-balancer-sku tipo di cluster e può essere definita solo in fase di creazione del cluster. Tuttavia, i servizi di bilanciamento del carico sku Basic usano indirizzi IP sku Basic, che non sono compatibili con i servizi di bilanciamento del carico dello SKU Standard. I servizi di bilanciamento del carico dello SKU Standard richiedono indirizzi IP dello SKU Standard . Quando si esegue la migrazione dei cluster per aggiornare gli SKU del servizio di bilanciamento del carico, è necessario un nuovo indirizzo IP con uno SKU di indirizzo IP compatibile.

Per altre considerazioni su come eseguire la migrazione dei cluster, vedere la documentazione sulle considerazioni sulla migrazione.

Limiti

Quando si creano e si gestiscono cluster del servizio Azure Kubernetes che supportano un'istanza di bilanciamento del carico con SKU Standard, si applicano le limitazioni seguenti:

  • È necessario almeno un indirizzo IP pubblico o un prefisso dell'indirizzo IP per consentire il traffico in uscita dal cluster del servizio Azure Kubernetes. L'indirizzo IP pubblico o il prefisso dell'indirizzo IP è necessario per mantenere la connettività tra il piano di controllo e i nodi dell'agente e per mantenere la compatibilità con le versioni precedenti del servizio Azure Kubernetes. Sono disponibili le opzioni seguenti per specificare indirizzi IP pubblici o prefissi IP con un servizio di bilanciamento del carico sku Standard :
    • Specificare gli indirizzi IP pubblici personalizzati.
    • Specificare i prefissi degli indirizzi IP pubblici personalizzati.
    • Specificare un numero massimo di 100 per consentire al cluster del servizio Azure Kubernetes di creare molti INDIRIZZI IP pubblici dello SKU Standard nello stesso gruppo di risorse del cluster del servizio Azure Kubernetes. Questo gruppo di risorse viene in genere denominato con MC_ all'inizio. Il servizio Azure Kubernetes assegna l'indirizzo IP pubblico all'istanza di bilanciamento del carico con SKU Standard. Per impostazione predefinita, un indirizzo IP pubblico viene creato automaticamente nello stesso gruppo di risorse del cluster del servizio Azure Kubernetes se non viene specificato alcun indirizzo IP pubblico, prefisso IP pubblico o numero di INDIRIZZI IP. È necessario anche consentire gli indirizzi pubblici ed evitare di creare criteri di Azure che vietino la creazione di IP.
  • Non è possibile riutilizzare un indirizzo IP pubblico creato dal servizio Azure Kubernetes come indirizzo IP pubblico personalizzato. Gli utenti devono creare e gestire tutti gli indirizzi IP personalizzati.
  • La definizione dello SKU per un servizio di bilanciamento del carico può essere eseguita solo quando si crea un cluster del servizio Azure Kubernetes. Non è possibile modificare lo SKU dell'istanza di bilanciamento del carico dopo la creazione di un cluster del servizio Azure Kubernetes.
  • È possibile usare un solo tipo di SKU del servizio di bilanciamento del carico (Basic o Standard) in un singolo cluster.
  • I servizi di bilanciamento del carico dello SKU Standard supportano solo gli indirizzi IP dello SKU Standard .

Passaggi successivi

Per altre informazioni sui servizi Kubernetes, vedere la documentazione dei servizi Kubernetes.

Per altre informazioni sull'uso del servizio di bilanciamento del carico interno per il traffico in ingresso, vedere la documentazione del servizio di bilanciamento del carico interno del servizio Azure Kubernetes.