Share via

Domande frequenti su problemi comuni durante l'esecuzione o la scalabilità di cluster del servizio Azure Kubernetes di grandi dimensioni

  • Articolo

Questo articolo risponde alle domande frequenti sui problemi comuni che possono verificarsi quando si eseguono o si ridimensionano cluster di grandi dimensioni in Microsoft servizio Azure Kubernetes (servizio Azure Kubernetes). Un cluster di grandi dimensioni è qualsiasi cluster eseguito su una scala di più di 500 nodi.

Viene visualizzato un errore "quota superata" durante la creazione, l'aumento o l'aggiornamento

Per risolvere questo problema, creare una richiesta di supporto nella sottoscrizione in cui si sta tentando di creare, ridimensionare o aggiornare e richiedere una quota per il tipo di risorsa corrispondente. Per altre informazioni, vedere Quote di calcolo a livello di area.

Viene visualizzato un errore "insufficientSubnetSize" quando si distribuisce un cluster del servizio Azure Kubernetes che usa la rete avanzata

Questo errore indica che una subnet in uso per un cluster non dispone più di indirizzi IP disponibili all'interno del cidr per l'assegnazione corretta delle risorse. Questo problema può verificarsi durante gli aggiornamenti, le scale out o la creazione del pool di nodi. Questo problema si verifica perché il numero di indirizzi IP gratuiti nella subnet è minore del risultato della formula seguente:

numero di nodi richiesti * valore del pool --max-pod di nodi

Prerequisiti

Soluzione

Poiché non è possibile aggiornare l'intervallo CIDR di una subnet esistente, è necessario disporre dell'autorizzazione per creare una nuova subnet per risolvere il problema. attenersi alla seguente procedura:

  1. Ricompilare una nuova subnet con un intervallo CIDR più ampio sufficiente per gli obiettivi operativi.

  2. Create una nuova subnet con un nuovo intervallo non sovrapposto.

  3. Create un nuovo pool di nodi nella nuova subnet.

  4. Svuotare i pod dal pool di nodi precedente che si trova nella subnet precedente che verrà sostituita.

  5. Eliminare la subnet precedente e il pool di nodi precedente.

Si verificano sporadici errori di connettività in uscita a causa dell'esaurimento delle porte SNAT

Per i cluster eseguiti su scala relativamente grande (più di 500 nodi), è consigliabile usare il gateway NAT (Managed Network Address Translation) del servizio Azure Kubernetes per una maggiore scalabilità. Il gateway NAT di Azure consente fino a 64.512 flussi di traffico UDP e TCP in uscita per indirizzo IP e un massimo di 16 indirizzi IP.

Se non si usa NAT gestito, vedere Risolvere i problemi di esaurimento e timeout della connessione SNAT (Source Network Address Translation) per comprendere e risolvere i problemi di esaurimento delle porte SNAT.

Non è possibile ridimensionare fino a 5.000 nodi usando il portale di Azure

Usare l'interfaccia della riga di comando di Azure per scalare fino a un massimo di 5.000 nodi seguendo questa procedura:

  1. Create un numero minimo di pool di nodi nel cluster (perché il limite massimo del nodo del pool di nodi è 1.000) eseguendo il comando seguente:

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. Aumentare i pool di nodi uno alla volta. Idealmente, impostare cinque minuti di sospensione tra scale-up consecutivi di 1.000. Eseguire il comando riportato di seguito:

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

L'aggiornamento è in esecuzione, ma è lento

Nella configurazione predefinita, il servizio Azure Kubernetes aumenta durante un aggiornamento eseguendo le azioni seguenti:

  • Creazione di un nuovo nodo.
  • Ridimensionamento del pool di nodi oltre il numero desiderato di nodi di un nodo.

Per le impostazioni di aumento massimo, un valore predefinito di un nodo significa che il servizio Azure Kubernetes crea un nuovo nodo prima di svuotare le applicazioni esistenti e sostituire un nodo con versioni precedenti. Questo nodo aggiuntivo consente al servizio Azure Kubernetes di ridurre al minimo l'interruzione del carico di lavoro.

Quando si aggiornano i cluster con molti nodi, l'aggiornamento dell'intero cluster può richiedere diverse ore se si usa il valore predefinito di max-surge. È possibile personalizzare la max-surge proprietà per ogni pool di nodi per abilitare un compromesso tra la velocità di aggiornamento e l'interruzione dell'aggiornamento. Aumentando il valore di picco massimo, si abilita il processo di aggiornamento per completare prima. Tuttavia, un valore elevato per l'aumento massimo potrebbe anche causare interruzioni durante il processo di aggiornamento.

Eseguire il comando seguente per aumentare o personalizzare il picco massimo per un pool di nodi esistente:

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

L'aggiornamento sta raggiungendo il limite di quota (5.000 cluster)

Per risolvere questo problema, vedere Aumentare le quote di vCPU a livello di area.

La creazione del servizio interno in più di 750 nodi è lenta o non riesce a causa di un errore di timeout

Load Balancer Standard (SLB) gli aggiornamenti del pool back-end sono un collo di bottiglia noto per le prestazioni. Stiamo lavorando a una nuova funzionalità che consentirà di creare più rapidamente servizi e SLB su larga scala. Per inviare commenti e suggerimenti su questo problema, vedere Supporto di Azure Kubernetes per il servizio di bilanciamento del carico con il pool back-end basato su IP.

Soluzione

È consigliabile ridurre il cluster a meno di 750 nodi e quindi creare un servizio di bilanciamento del carico interno per il cluster. Per creare un servizio di bilanciamento del carico interno, creare un tipo di servizio e azure-load-balancer-internal un'annotazioneLoadBalancer, in base alla procedura di esempio seguente.

Passaggio 1: Create un servizio di bilanciamento del carico interno

Per creare un servizio di bilanciamento del carico interno, creare un manifesto del servizio denominato internal-lb.yaml che contiene il LoadBalancer tipo di servizio e l'annotazione azure-load-balancer-internal , come illustrato nell'esempio seguente:

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Passaggio 2: Distribuire il servizio di bilanciamento del carico interno

Distribuire il servizio di bilanciamento del carico interno usando il kubectl apply comando e specificare il nome del manifesto YAML, come illustrato nell'esempio seguente:

kubectl apply -f internal-lb.yaml

Dopo aver creato il cluster, è anche possibile effettuare il provisioning di un servizio di bilanciamento del carico interno (in base a questa procedura) e mantenere in esecuzione un servizio interno con carico bilanciato. In questo modo è possibile aggiungere altri servizi al servizio di bilanciamento del carico su larga scala.

La creazione del servizio SLB su larga scala richiede ore per l'esecuzione

Gli aggiornamenti del pool back-end SLB rappresentano un collo di bottiglia noto per le prestazioni. Si sta lavorando a una nuova funzionalità che consentirà di eseguire servizi con carico bilanciato su larga scala con prestazioni notevolmente più veloci per le operazioni di creazione, aggiornamento ed eliminazione. Per inviare commenti e suggerimenti, vedere Supporto di Azure Kubernetes per il servizio di bilanciamento del carico con il pool back-end basato su IP.

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.