Partager via

Résolution des problèmes liés à Kubernetes

  • Article

Cette page décrit plusieurs problèmes courants liés à la configuration, à la mise en réseau et aux déploiements Kubernetes.

Conseil

Suggèrez un élément faq en générant une demande de tirage dans notre référentiel de documentation.

Cette page est subdivisée dans les catégories suivantes :

  1. Questions générales
  2. Erreurs réseau courantes
  3. Erreurs Windows courantes
  4. Erreurs principales Kubernetes courantes

Questions générales

Comment faire connaissez Kubernetes sur Windows correctement ?

Vous devez voir kubelet, kube-proxy et (si vous avez choisi Flannel comme solution de mise en réseau) les processus flanneld host-agent s’exécutant sur votre nœud. En plus de cela, votre nœud Windows doit être répertorié en tant que « Prêt » dans votre cluster Kubernetes.

Puis-je configurer pour exécuter tout cela en arrière-plan ?

À compter de Kubernetes version 1.11, kubelet &kube-proxy peut être exécuté en tant que services Windows natifs. Vous pouvez également utiliser d’autres gestionnaires de services comme nssm.exe pour toujours exécuter ces processus (flanneld, kubelet &kube-proxy) en arrière-plan.

Erreurs réseau courantes

Les équilibreurs de charge sont plombés de manière incohérente sur les nœuds du cluster

Sur Windows, kube-proxy crée un équilibreur de charge HNS pour chaque service Kubernetes du cluster. Dans la configuration kube-proxy (par défaut), les nœuds des clusters contenant de nombreux équilibreurs de charge (généralement 100+) peuvent manquer de ports TCP éphémères disponibles (a.k.a. plage de ports dynamiques, qui couvrent par défaut les ports 49152 à 65535). Cela est dû au nombre élevé de ports réservés sur chaque nœud pour chaque équilibreur de charge (non-DSR). Ce problème peut se manifester par le biais d’erreurs dans kube-proxy, par exemple :

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

Les utilisateurs peuvent identifier ce problème en exécutant le script CollectLogs.ps1 et en consultant les *portrange.txt fichiers.

Il CollectLogs.ps1 imite également la logique d’allocation HNS pour tester la disponibilité de l’allocation de pool de ports dans la plage de ports TCP éphémère, et signaler la réussite/l’échec dans reservedports.txt. Le script réserve 10 plages de 64 ports éphémères TCP (pour émuler le comportement HNS), compte les réussites de réservation et les échecs, puis libère les plages de ports allouées. Un nombre de réussite inférieur à 10 indique que le pool éphémère manque d’espace libre. Un résumé heuristique du nombre de réservations de ports de 64 blocs qui sont approximativement disponibles sera également généré dans reservedports.txt.

Pour résoudre ce problème, quelques étapes peuvent être effectuées :

  1. Pour une solution permanente, l’équilibrage de charge kube-proxy doit être défini sur le mode DSR. Le mode DSR est entièrement implémenté et disponible sur Windows Server Insider build 18945 ou version ultérieure uniquement.
  2. Pour contourner ce problème, les utilisateurs peuvent également augmenter la configuration Windows par défaut des ports éphémères disponibles à l’aide d’une commande telle que netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. AVERTISSEMENT : La substitution de la plage de ports dynamiques par défaut peut avoir des conséquences sur d’autres processus/services sur l’hôte qui s’appuient sur les ports TCP disponibles à partir de la plage non éphémère. Cette plage doit donc être sélectionnée avec soin.
  3. Il existe une amélioration de l’extensibilité des équilibreurs de charge en mode non DSR à l’aide du partage de pool de ports intelligent inclus dans la mise à jour cumulative KB4551853 (et toutes les mises à jour cumulatives plus récentes).

La publication HostPort ne fonctionne pas

Pour utiliser la fonctionnalité HostPort, vérifiez que vos plug-ins CNI sont version v0.8.6 ou ultérieure, et que le fichier de configuration CNI dispose des portMappings fonctionnalités définies :

"capabilities": {
    "portMappings":  true
}

Je vois des erreurs telles que « hnsCall failed in Win32 : The wrong diskette is in the drive ».

Cette erreur peut se produire lors de la modification personnalisée d’objets HNS ou lors de l’installation de windows Update qui introduit les modifications apportées à HNS sans détruire les anciens objets HNS. Il indique qu’un objet HNS créé précédemment avant qu’une mise à jour ne soit incompatible avec la version HNS actuellement installée.

Sur Windows Server 2019 (et versions antérieures), les utilisateurs peuvent supprimer des objets HNS en supprimant le fichier HNS.data

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

Les utilisateurs doivent pouvoir supprimer directement les points de terminaison ou réseaux HNS incompatibles :

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

Les utilisateurs sur Windows Server, version 1903 peuvent accéder à l’emplacement de Registre suivant et supprimer les cartes réseau commençant par le nom du réseau (par exemple vxlan0 , ou cbr0) :

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

Les conteneurs sur mon déploiement flannel host-gw sur Azure ne peuvent pas atteindre Internet

Lors du déploiement de Flannel en mode host-gw sur Azure, les paquets doivent passer par le commutateur vSwitch de l’hôte physique Azure. Les utilisateurs doivent programmer des itinéraires définis par l’utilisateur de type « appliance virtuelle » pour chaque sous-réseau affecté à un nœud. Cela peut être effectué via le Portail Azure (voir un exemple ici) ou via az Azure CLI. Voici un exemple d’UDR portant le nom « MyRoute » à l’aide de commandes az pour un nœud avec IP 10.0.0.4 et le sous-réseau de pod respectif 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 

Conseil

Si vous déployez Kubernetes sur des machines virtuelles Azure ou IaaS à partir d’autres fournisseurs de cloud vous-même, vous pouvez également l’utiliser overlay networking à la place.

Mes pods Windows ne peuvent pas effectuer un test ping sur les ressources externes

Les pods Windows n’ont pas de règles de trafic sortant programmés pour le protocole ICMP aujourd’hui. Toutefois, TCP/UDP est pris en charge. Lorsque vous essayez de démontrer la connectivité aux ressources en dehors du cluster, remplacez ping <IP> par les commandes correspondantes curl <IP> .

Si vous rencontrez toujours des problèmes, probablement votre configuration réseau dans cni.conf mérite une attention supplémentaire. Vous pouvez toujours modifier ce fichier statique, la configuration sera appliquée à toutes les ressources Kubernetes nouvellement créées.

Pourquoi ? L’une des exigences de mise en réseau Kubernetes (voir le modèle Kubernetes) est que la communication de cluster se produit sans NAT en interne. Pour respecter cette exigence, nous disposons d’une exceptionList pour toutes les communications où nous ne voulons pas que la nat sortante se produise. Toutefois, cela signifie également que vous devez exclure l’adresse IP externe que vous essayez d’interroger à partir de l’ExceptionList. Seul le trafic provenant de vos pods Windows est correctement utilisé pour recevoir une réponse provenant du monde extérieur. À cet égard, votre ExceptionList doit cni.conf se présenter comme suit :

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

Mon nœud Windows ne peut pas accéder à un service NodePort

L’accès NodePort local à partir du nœud lui-même peut échouer. Il s’agit d’un écart de fonctionnalité connu avec la mise à jour cumulative KB4571748 (ou version ultérieure). L’accès NodePort fonctionne à partir d’autres nœuds ou clients externes.

Mon nœud Windows arrête le routage thourgh NodePorts après avoir réduit mes pods

En raison d’une limitation de conception, il doit y avoir au moins un pod s’exécutant sur le nœud Windows pour que le transfert NodePort fonctionne.

Après un certain temps, les cartes réseau virtuelles et les points de terminaison HNS des conteneurs sont supprimés

Ce problème peut être provoqué lorsque le hostname-override paramètre n’est pas passé à kube-proxy. Pour le résoudre, les utilisateurs doivent passer le nom d’hôte à kube-proxy comme suit :

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

En mode Flannel (vxlan), mes pods rencontrent des problèmes de connectivité après avoir rejoint le nœud

Chaque fois qu’un nœud précédemment supprimé est joint au cluster, flannelD tente d’affecter un nouveau sous-réseau de pod au nœud. Les utilisateurs doivent supprimer les anciens fichiers de configuration de sous-réseau de pod dans les chemins suivants :

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

Après le lancement de Kubernetes, Flanneld est bloqué dans « Attente de la création du réseau »

Ce problème doit être résolu avec Flannel v0.12.0 (et versions ultérieures). Si vous utilisez une version antérieure de Flanneld, il existe une condition de concurrence connue qui peut se produire de telle sorte que l’adresse IP de gestion du réseau flannel n’est pas définie. Une solution de contournement consiste simplement à relancer FlannelD manuellement.

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

Mes pods Windows ne peuvent pas être lancés en raison de l’absence de /run/flannel/subnet.env

Cela indique que Flannel n’a pas lancé correctement. Vous pouvez essayer de redémarrer flanneld.exe ou vous pouvez copier manuellement les fichiers à partir du /run/flannel/subnet.env maître C:\run\flannel\subnet.env Kubernetes vers le nœud Worker Windows et modifier la FLANNEL_SUBNET ligne sur le sous-réseau affecté. Par exemple, si le sous-réseau de nœud 10.244.4.1/24 a été affecté :

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

Plus souvent que non, il existe un autre problème qui peut entraîner cette erreur qui doit d’abord être examinée. Il est recommandé de laisser flanneld.exe générer ce fichier pour vous.

La connectivité pod-à-pod entre les hôtes est interrompue sur mon cluster Kubernetes s’exécutant sur vSphere

Étant donné que vSphere et Flannel réservent le port 4789 (port VXLAN par défaut) pour la mise en réseau de superposition, les paquets peuvent être interceptés. Si vSphere est utilisé pour la mise en réseau de superposition, il doit être configuré pour utiliser un autre port afin de libérer jusqu’à 4789.

Mes points de terminaison/adresses IP fuitent

Il existe 2 problèmes connus qui peuvent entraîner la fuite des points de terminaison.

  1. Le premier problème connu est un problème dans Kubernetes version 1.11. Évitez d’utiliser Kubernetes version 1.11.0 - 1.11.2.
  2. Le deuxième problème connu qui peut entraîner la fuite de points de terminaison est un problème d’accès concurrentiel dans le stockage des points de terminaison. Pour recevoir le correctif, vous devez utiliser Docker EE 18.09 ou version ultérieure.

Mes pods ne peuvent pas démarrer en raison des erreurs « réseau : échec de l’allocation pour plage »

Cela indique que l’espace d’adressage IP sur votre nœud est utilisé. Pour nettoyer les points de terminaison fuites, migrez les ressources sur les nœuds affectés et exécutez les commandes suivantes :

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

Mon nœud Windows ne peut pas accéder à mes services à l’aide de l’adresse IP du service

Il s’agit d’une limitation connue de la pile réseau actuelle sur Windows. Toutefois, les podsWindows peuvent accéder à l’adresse IP du service.

Aucune carte réseau n’est trouvée lors du démarrage de Kubelet

La pile de mise en réseau Windows a besoin d’une carte virtuelle pour que la mise en réseau Kubernetes fonctionne. Si les commandes suivantes ne retournent aucun résultat (dans un interpréteur de commandes d’administration), la création du réseau HNS , un prérequis nécessaire pour que Kubelet fonctionne, a échoué :

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

Il est souvent utile de modifier le paramètre InterfaceName du script start.ps1, dans les cas où la carte réseau de l’hôte n’est pas « Ethernet ». Sinon, consultez la sortie du script pour voir s’il existe des erreurs lors de la start-kubelet.ps1 création du réseau virtuel.

Je vois toujours des problèmes. Que dois-je faire ?

Il peut y avoir des restrictions supplémentaires sur votre réseau ou sur les hôtes empêchant certains types de communication entre les nœuds. Assurez-vous que :

  • vous avez correctement configuré votre topologie de réseau choisie (l2bridge ou overlay)
  • le trafic qui semble provenir de pods est autorisé
  • Le trafic HTTP est autorisé, si vous déployez des services web
  • Les paquets provenant de différents protocoles (ie ICMP et TCP/UDP) ne sont pas supprimés

Conseil

Pour obtenir des ressources d’aide autonome supplémentaires, il existe également un guide de résolution des problèmes réseau Kubernetes pour Windows disponible ici.

Erreurs Windows courantes

Mes pods Kubernetes sont bloqués sur « ContainerCreating »

Ce problème peut avoir de nombreuses causes, mais l’une des causes les plus courantes est que l’image de pause a été mal configurée. Il s’agit d’un symptôme de haut niveau du problème suivant.

Lors du déploiement, les conteneurs Docker continuent de redémarrer

Vérifiez que votre image de pause est compatible avec votre version du système d’exploitation. Kubernetes suppose que le système d’exploitation et les conteneurs ont des numéros de version de système d’exploitation correspondants. Si vous utilisez une build expérimentale de Windows, telle qu’une build Insider, vous devez ajuster les images en conséquence. Reportez-vous au référentiel Docker de Microsoft pour les images.

Erreurs principales Kubernetes courantes

Le débogage du maître Kubernetes se trouve dans trois catégories principales (dans l’ordre de probabilité) :

  • Un problème se produit avec les conteneurs système Kubernetes.
  • Quelque chose ne va pas avec la façon dont il est en cours kubelet d’exécution.
  • Quelque chose ne va pas avec le système.

Exécutez kubectl get pods -n kube-system pour voir les pods créés par Kubernetes . Cela peut donner des informations sur les points particuliers qui se bloquent ou ne démarrent pas correctement. Ensuite, exécutez docker ps -a pour voir tous les conteneurs bruts qui sauvegardent ces pods. Enfin, exécutez docker logs [ID] sur le ou les conteneurs qui sont soupçonnés d’entraîner le problème pour voir la sortie brute des processus.

Impossible de se connecter au serveur d’API à l’adresse https://[address]:[port]

Plus souvent que non, cette erreur indique des problèmes de certificat. Vérifiez que vous avez généré correctement le fichier de configuration, que les adresses IP qu’elle contient correspondent à celle de votre hôte et que vous l’avez copiée dans le répertoire monté par le serveur d’API.

Les emplacements appropriés pour trouver ce fichier de configuration sont les suivants :

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

Sinon, reportez-vous au fichier manifeste du serveur d’API pour vérifier les points de montage.