Condividi tramite

Risoluzione dei problemi di Kubernetes

  • Articolo

Questa pagina illustra diversi problemi comuni relativi alla configurazione, alla rete e alle distribuzioni di Kubernetes.

Suggerimento

Suggerire un elemento di domande frequenti generando una richiesta pull al repository della documentazione.

Questa pagina è suddivisa nelle categorie seguenti:

  1. Domande generali
  2. Errori di rete comuni
  3. Errori comuni di Windows
  4. Errori comuni del master Kubernetes

Domande generali

Ricerca per categorie sapere che Kubernetes in Windows è stato completato correttamente?

Verranno visualizzati kubelet, kube-proxy e (se si è scelto Flannel come soluzione di rete) flanneld processi dell'agente host in esecuzione nel nodo. Oltre a questo, il nodo Windows deve essere elencato come "Pronto" nel cluster Kubernetes.

È possibile configurare per eseguire tutto questo in background?

A partire da Kubernetes versione 1.11, kubelet & kube-proxy può essere eseguito come servizi Windows nativi. È anche possibile usare sempre gestori di servizi alternativi come nssm.exe per eseguire sempre questi processi (flanneld, kubelet e kube-proxy) in background.

Errori di rete comuni

I servizi di bilanciamento del carico vengono distribuiti in modo incoerente tra i nodi del cluster

In Windows kube-proxy crea un servizio di bilanciamento del carico HNS per ogni servizio Kubernetes nel cluster. Nella configurazione kube-proxy (predefinita) i nodi nei cluster che contengono molti servizi di bilanciamento del carico (in genere 100+) potrebbero esaurire le porte TCP temporanee disponibili (a.k.a. intervallo di porte dinamiche, che per impostazione predefinita copre le porte da 49152 a 65535). Ciò è dovuto al numero elevato di porte riservate in ogni nodo per ogni servizio di bilanciamento del carico (non DSR). Questo problema può manifestarsi tramite errori in kube-proxy, ad esempio:

Policy creation failed: hcnCreateLoadBalancer failed in Win32: The specified port already exists.

Gli utenti possono identificare questo problema eseguendo lo script CollectLogs.ps1 e consultando i *portrange.txt file.

Simula CollectLogs.ps1 inoltre la logica di allocazione HNS per testare la disponibilità dell'allocazione del pool di porte nell'intervallo di porte TCP temporaneo e segnalare l'esito positivo/negativo in reservedports.txt. Lo script riserva 10 intervalli di 64 porte temporanee TCP (per emulare il comportamento HNS), conta i successi e gli errori delle prenotazioni, quindi rilascia gli intervalli di porte allocati. Un numero di operazione riuscita minore di 10 indica che il pool temporaneo esaurisce lo spazio disponibile. Un riepilogo euristico del numero di prenotazioni di porte a 64 blocchi approssimativamente disponibili verrà generato anche in reservedports.txt.

Per risolvere questo problema, è possibile eseguire alcuni passaggi:

  1. Per una soluzione permanente, il bilanciamento del carico kube-proxy deve essere impostato sulla modalità DSR. La modalità DSR è completamente implementata e disponibile solo nella build più recente di Windows Server Insider 18945 (o versione successiva).
  2. Come soluzione alternativa, gli utenti possono anche aumentare la configurazione predefinita di Windows delle porte temporanee disponibili usando un comando come netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. AVVISO: l'override dell'intervallo di porte dinamiche predefinito può avere conseguenze su altri processi/servizi nell'host che si basano sulle porte TCP disponibili dall'intervallo non temporaneo, quindi questo intervallo deve essere selezionato attentamente.
  3. È stato apportato un miglioramento della scalabilità ai servizi di bilanciamento del carico in modalità non DSR usando la condivisione intelligente del pool di porte inclusa nell'aggiornamento cumulativo KB4551853 (e tutti gli aggiornamenti cumulativi più recenti).

La pubblicazione di HostPort non funziona

Per usare la funzionalità HostPort, verificare che i plug-in CNI siano v0.8.6 o versioni successive e che il file di configurazione CNI abbia le portMappings funzionalità impostate:

"capabilities": {
    "portMappings":  true
}

Vengono visualizzati errori come "hnsCall failed in Win32: The wrong diskette is in the drive".

Questo errore può verificarsi quando si apportano modifiche personalizzate agli oggetti HNS o si installa un nuovo Windows Update che introduce modifiche a HNS senza rimuovere gli oggetti HNS precedenti. Indica che un oggetto HNS creato in precedenza prima di un aggiornamento non è compatibile con la versione HNS attualmente installata.

In Windows Server 2019 (e versioni precedenti) gli utenti possono eliminare gli oggetti HNS eliminando il file HNS.data

Stop-Service HNS
rm C:\ProgramData\Microsoft\Windows\HNS\HNS.data
Start-Service HNS

Gli utenti devono essere in grado di eliminare direttamente eventuali endpoint o reti HNS incompatibili:

hnsdiag list endpoints
hnsdiag delete endpoints <id>
hnsdiag list networks
hnsdiag delete networks <id>
Restart-Service HNS

Gli utenti di Windows Server versione 1903 possono passare al percorso del Registro di sistema seguente ed eliminare le schede di interfaccia di rete a partire dal nome di rete (ad esempio vxlan0 o cbr0):

\\Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList

I contenitori nella distribuzione host-gw flannel in Azure non possono raggiungere Internet

Quando si distribuisce Flannel in modalità host-gw in Azure, i pacchetti devono passare attraverso il vSwitch dell'host fisico di Azure. Gli utenti devono programmare route definite dall'utente di tipo "appliance virtuale" per ogni subnet assegnata a un nodo. Questa operazione può essere eseguita tramite il portale di Azure (vedere un esempio qui) o tramite l'interfaccia az della riga di comando di Azure. Ecco un esempio di route definita dall'utente con nome "MyRoute" usando i comandi az per un nodo con IP 10.0.0.4 e la rispettiva subnet pod 10.244.0.0/24:

az network route-table create --resource-group <my_resource_group> --name BridgeRoute 
az network route-table route create  --resource-group <my_resource_group> --address-prefix 10.244.0.0/24 --route-table-name BridgeRoute  --name MyRoute --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4 

Suggerimento

Se si distribuisce Kubernetes in macchine virtuali Azure o IaaS da altri provider di servizi cloud, è anche possibile usare overlay networking in alternativa.

I pod Windows non possono eseguire il ping di risorse esterne

I pod Windows non dispongono di regole in uscita programmate per il protocollo ICMP. Tuttavia, TCP/UDP è supportato. Quando si tenta di dimostrare la connettività alle risorse esterne al cluster, sostituire ping <IP> con i comandi corrispondenti curl <IP> .

Se si verificano ancora problemi, è probabile che la configurazione di rete in cni.conf meriti un'attenzione aggiuntiva. È sempre possibile modificare questo file statico, la configurazione verrà applicata a tutte le risorse Kubernetes appena create.

Perché? Uno dei requisiti di rete di Kubernetes (vedere il modello Kubernetes) è che la comunicazione del cluster venga eseguita senza NAT internamente. Per rispettare questo requisito, è disponibile un oggetto ExceptionList per tutte le comunicazioni in cui non si vuole che si verifichi NAT in uscita. Tuttavia, ciò significa anche che è necessario escludere l'indirizzo IP esterno che si sta tentando di eseguire una query da ExceptionList. Solo allora il traffico proveniente dai pod Windows sarà correttamente SNAT per ricevere una risposta dal mondo esterno. A questo proposito, ExceptionList in cni.conf dovrebbe essere simile al seguente:

"ExceptionList": [
  "10.244.0.0/16",  # Cluster subnet
  "10.96.0.0/12",   # Service subnet
  "10.127.130.0/24" # Management (host) subnet
]

Il nodo Windows non può accedere a un servizio NodePort

L'accesso NodePort locale dal nodo stesso potrebbe non riuscire. Si tratta di un divario di funzionalità noto risolto con l'aggiornamento cumulativo KB4571748 (o versione successiva). L'accesso nodePort funzionerà da altri nodi o client esterni.

Il nodo Di Windows arresta il routing di NodePorts dopo aver ridimensionato i pod

A causa di una limitazione della progettazione, deve essere presente almeno un pod in esecuzione nel nodo Windows per il funzionamento dell'inoltro NodePort.

Dopo qualche tempo, le schede di interfaccia di rete virtuale e gli endpoint HNS dei contenitori vengono eliminati

Questo problema può essere causato quando il hostname-override parametro non viene passato a kube-proxy. Per risolverlo, gli utenti devono passare il nome host a kube-proxy come indicato di seguito:

C:\k\kube-proxy.exe --hostname-override=$(hostname)

In modalità Flannel (vxlan) i pod riscontrano problemi di connettività dopo la ricongiunzione del nodo

Ogni volta che un nodo eliminato in precedenza viene aggiunto nuovamente al cluster, flannelD tenterà di assegnare una nuova subnet pod al nodo. Gli utenti devono rimuovere i file di configurazione della subnet pod precedenti nei percorsi seguenti:

Remove-Item C:\k\SourceVip.json
Remove-Item C:\k\SourceVipRequest.json

Dopo l'avvio di Kubernetes, Flanneld è bloccato in "In attesa della creazione della rete"

Questo problema deve essere risolto con Flannel v0.12.0 (e versioni successive). Se si usa una versione precedente di Flanneld, esiste una race condition nota che può verificarsi in modo che l'INDIRIZZO IP di gestione della rete flannel non sia impostato. Una soluzione alternativa consiste semplicemente nel riavviare FlannelD manualmente.

PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "<Windows_Worker_Hostname>")
PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface=<Windows_Worker_Node_IP> --ip-masq=1 --kube-subnet-mgr=1

Impossibile avviare i pod Windows a causa di /run/flannel/subnet.env mancanti

Ciò indica che Flannel non è stato avviato correttamente. È possibile provare a riavviare flanneld.exe oppure copiare manualmente i file dal /run/flannel/subnet.env master Kubernetes a C:\run\flannel\subnet.env nel nodo di lavoro di Windows e modificare la FLANNEL_SUBNET riga nella subnet assegnata. Ad esempio, se è stata assegnata la subnet del nodo 10.244.4.1/24:

FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.4.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

Più spesso, esiste un altro problema che potrebbe causare questo errore che deve essere esaminato per primo. È consigliabile consentire flanneld.exe la generazione di questo file automaticamente.

La connettività da pod a pod tra host viene interrotta nel cluster Kubernetes in esecuzione in vSphere

Poiché sia vSphere che Flannel riservano la porta 4789 (porta VXLAN predefinita) per la rete di sovrapposizione, i pacchetti possono finire per essere intercettati. Se vSphere viene usato per la rete di sovrapposizione, deve essere configurato per usare una porta diversa per liberare 4789.

Gli endpoint o gli indirizzi IP stanno perdono

Esistono 2 problemi attualmente noti che possono causare perdite di endpoint.

  1. Il primo problema noto è un problema in Kubernetes versione 1.11. Evitare di usare Kubernetes versione 1.11.0 - 1.11.2.
  2. Il secondo problema noto che può causare la perdita di endpoint è un problema di concorrenza nell'archiviazione degli endpoint. Per ricevere la correzione, è necessario usare Docker EE 18.09 o versione successiva.

Impossibile avviare i pod a causa di errori di "rete: non è stato possibile allocare per intervallo"

Ciò indica che lo spazio degli indirizzi IP nel nodo viene usato. Per pulire eventuali endpoint persi, eseguire la migrazione di tutte le risorse nei nodi interessati ed eseguire i comandi seguenti:

c:\k\stop.ps1
Get-HNSEndpoint | Remove-HNSEndpoint
Remove-Item -Recurse c:\var

Il nodo Windows non può accedere ai servizi usando l'INDIRIZZO IP del servizio

Si tratta di una limitazione nota dello stack di rete corrente in Windows. I pod Windows sono tuttavia in grado di accedere all'INDIRIZZO IP del servizio.

Non viene trovata alcuna scheda di rete all'avvio di Kubelet

Per il funzionamento della rete Kubernetes, lo stack di rete Di Windows richiede una scheda virtuale. Se i comandi seguenti non restituiscono risultati (in una shell di amministrazione), la creazione di rete HNS, un prerequisito necessario per il funzionamento di Kubelet, non è riuscita:

Get-HnsNetwork | ? Name -ieq "cbr0"
Get-HnsNetwork | ? Name -ieq "vxlan0"
Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"

Spesso è utile modificare il parametro InterfaceName dello script start.ps1, nei casi in cui la scheda di rete dell'host non è "Ethernet". In caso contrario, consultare l'output dello script per verificare se sono presenti errori durante la start-kubelet.ps1 creazione della rete virtuale.

Vedo ancora problemi. Cosa devo fare?

Potrebbero essere presenti restrizioni aggiuntive sulla rete o sugli host che impediscono determinati tipi di comunicazione tra nodi. Assicurarsi che:

  • è stata configurata correttamente la topologia di rete scelta (l2bridge o overlay)
  • il traffico simile a quello proveniente dai pod è consentito
  • Il traffico HTTP è consentito, se si distribuiscono servizi Web
  • I pacchetti da protocolli diversi (ie ICMP e TCP/UDP) non vengono eliminati

Suggerimento

Per altre risorse self-help, è disponibile qui anche una guida alla risoluzione dei problemi di rete di Kubernetes per Windows.

Errori comuni di Windows

I pod Kubernetes sono bloccati in "ContainerCreating"

Questo problema può avere molte cause, ma una delle più comuni è che l'immagine di sospensione è stata configurata in modo errato. Si tratta di un sintomo generale del prossimo problema.

Durante la distribuzione, i contenitori Docker continuano a riavviare

Verificare che l'immagine di sospensione sia compatibile con la versione del sistema operativo. Kubernetes presuppone che sia il sistema operativo che i contenitori abbiano numeri di versione del sistema operativo corrispondenti. Se si usa una build sperimentale di Windows, ad esempio una build Insider, sarà necessario modificare le immagini di conseguenza. Per le immagini, vedere il repository Docker di Microsoft.

Errori comuni del master Kubernetes

Il debug del master Kubernetes rientra in tre categorie principali (in ordine di probabilità):

  • Si è verificato un problema con i contenitori di sistema Kubernetes.
  • C'è qualcosa che non va nel modo in cui kubelet è in esecuzione.
  • C'è qualcosa che non va nel sistema.

Eseguire kubectl get pods -n kube-system per visualizzare i pod creati da Kubernetes. Ciò potrebbe fornire informazioni dettagliate su quali particolari elementi si arrestano in modo anomalo o non vengono avviati correttamente. Eseguire quindi docker ps -a per visualizzare tutti i contenitori non elaborati che eseguono il backup di questi pod. Infine, eseguire docker logs [ID] nei contenitori sospetti che causano il problema per visualizzare l'output non elaborato dei processi.

Impossibile connettersi al server API all'indirizzo https://[address]:[port]

Più spesso, questo errore indica problemi di certificato. Assicurarsi di aver generato correttamente il file di configurazione, che gli indirizzi IP in esso contenuti corrispondano a quello dell'host e che sia stato copiato nella directory montata dal server API.

I punti validi per trovare questo file di configurazione sono:

  • ~/kube/kubelet/
  • $HOME/.kube/config
  • /etc/kubernetes/admin.conf

in caso contrario, fare riferimento al file manifesto del server API per controllare i punti di montaggio.