Délais d’expiration TCP lorsque kubectl ou d’autres outils tiers se connectent au serveur d’API
Cet article explique comment résoudre les délais d’attente TCP qui se produisent lorsque kubectl ou d’autres outils tiers sont utilisés pour se connecter au serveur d’API dans Microsoft Azure Kubernetes Service (AKS). Pour garantir ses objectifs de niveau de service et ses contrats de niveau de service (SLA), AKS utilise des plans de contrôle haute disponibilité (HA) qui s’adapte verticalement et horizontalement, en fonction du nombre de cœurs.
Symptômes
Vous rencontrez des délais de connexion répétés.
Cause 1 : Les pods responsables de la communication de plan de nœud à contrôle ne sont pas en cours d’exécution
Si seulement quelques-unes de vos commandes d’API expirent de façon cohérente, les pods suivants peuvent ne pas être dans un état d’exécution :
konnectivity-agenttunnelfrontaks-link
Note
Dans les versions plus récentes d’AKS et tunnelfront aks-link remplacées konnectivity-agentpar , vous verrez donc uniquement konnectivity-agent.
Ces pods sont responsables de la communication entre un nœud et le plan de contrôle.
Solution : réduire l’utilisation ou le stress des hôtes de nœud
Assurez-vous que les nœuds qui hébergent ces pods ne sont pas trop utilisés ou sous contrainte. Envisagez de déplacer les nœuds vers leur propre pool de nœuds système.
Pour vérifier le nœud sur lequel le konnectivity-agent pod est hébergé et l’utilisation du nœud, exécutez les commandes suivantes :
# Check which node the konnectivity-agent pod is hosted on
$ kubectl get pod -n kube-system -o wide
# Check the usage of the node hosting the pod
$ kubectl top node
Cause 2 : L’accès est bloqué sur certains ports, noms de domaine complets et adresses IP requis
Si les ports requis, les noms de domaine complets (FQDN) et les adresses IP ne sont pas tous ouverts, plusieurs appels de commande peuvent échouer. La communication sécurisée et tunnelée sur AKS entre le serveur d’API et le kubelet (via le konnectivity-agent pod) nécessite que certains de ces éléments fonctionnent correctement.
Solution : ouvrir les ports, noms de domaine complets et adresses IP nécessaires
Pour plus d’informations sur les ports, noms de domaine complets et adresses IP à ouvrir, consultez les règles de réseau sortant et de nom de domaine complet pour les clusters Azure Kubernetes Service (AKS).
Cause 3 : L’extension TLS de négociation du protocole application-couche est bloquée
Pour établir une connexion entre le plan de contrôle et les nœuds, le konnectivity-agent pod requiert l’extension TLS (Transport Layer Security) pour la négociation de protocole de couche application (ALPN). Vous avez peut-être déjà bloqué cette extension.
Solution : Activer l’extension ALPN
Activez l’extension ALPN sur le konnectivity-agent pod pour empêcher les délais d’attente TCP.
Cause 4 : Les plages d’adresses IP autorisées du serveur d’API ne couvrent pas votre adresse IP actuelle
Si vous utilisez des plages d’adresses IP autorisées sur votre serveur d’API, vos appels d’API sont bloqués si votre adresse IP n’est pas incluse dans les plages autorisées.
Solution : modifiez les plages d’adresses IP autorisées afin qu’elles couvrent votre adresse IP
Modifiez les plages d’adresses IP autorisées afin que votre adresse IP soit couverte. Pour plus d’informations, consultez Mettre à jour les plages d’adresses IP autorisées du serveur d’API d’un cluster.
Cause 5 : Un client ou une application fuite d’appels vers le serveur d’API
Les appels GET fréquents peuvent accumuler et surcharger le serveur d’API.
Solution : utilisez des montres plutôt que des appels GET, mais assurez-vous que l’application ne fuit pas ces appels.
Veillez à utiliser des montres au lieu d’appels GET fréquents au serveur d’API. Vous devez également vous assurer que vos applications tierces n’ont pas de fuite de connexions de surveillance ou d’appels GET. Par exemple, dans l’architecture de microservice Istio, un bogue dans l’application mixer crée une connexion espion du serveur d’API chaque fois qu’un secret est lu en interne. Étant donné que ce comportement se produit à intervalles réguliers, les connexions de surveillance s’accumulent rapidement. Ces connexions entraînent finalement la surcharge du serveur d’API, quel que soit le modèle de mise à l’échelle.
Cause 6 : Trop de versions dans vos déploiements Helm
Si vous utilisez trop de versions dans vos déploiements de Helm (gestionnaire de package Kubernetes), les nœuds commencent à consommer trop de mémoire. Cela entraîne également une grande quantité d’objets (données de ConfigMap configuration), ce qui peut entraîner des pics d’utilisation inutiles sur le serveur d’API.
Solution : limiter le nombre maximal de révisions pour chaque version
Étant donné que le nombre maximal de révisions pour chaque version est infini par défaut, vous devez exécuter une commande pour définir ce nombre maximal sur une valeur raisonnable. Pour Helm 2, la commande est helm init. Pour Helm 3, la commande est helm upgrade. Définissez le --history-max <value> paramètre lorsque vous exécutez la commande.
| Version | Commande |
|---|---|
| Helm 2 | helm init --history-max <maximum-number-of-revisions-per-release> ... |
| Helm 3 | helm upgrade ... --history-max <maximum-number-of-revisions-per-release> ... |
Cause 7 : Le trafic interne entre les nœuds est bloqué
Il peut y avoir des blocages de trafic interne entre les nœuds de votre cluster AKS.
Solution : Résoudre les problèmes liés à l’erreur « dial tcp <Node_IP> :10250 : délai d’expiration d’e/s »
Cause 8 : Votre cluster est privé
Votre cluster est un cluster privé, mais le client à partir duquel vous essayez d’accéder au serveur d’API se trouve dans un réseau public ou différent qui ne peut pas se connecter au sous-réseau utilisé par AKS.
Solution : Utiliser un client qui peut accéder au sous-réseau AKS
Étant donné que votre cluster est privé et que son plan de contrôle se trouve dans le sous-réseau AKS, il ne peut pas être connecté au serveur d’API, sauf s’il se trouve dans un réseau qui peut se connecter au sous-réseau AKS. Il s’agit d’un comportement attendu.
Dans ce cas, essayez d’accéder au serveur d’API à partir d’un client dans un réseau qui peut communiquer avec le sous-réseau AKS. En outre, vérifiez que les groupes de sécurité réseau (NSG) ou d’autres appliances entre les réseaux ne bloquent pas les paquets.
Exclusion de responsabilité de tiers
Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.
Contactez-nous pour obtenir de l’aide
Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.