'Impossible de se connecter à Net/http: délai de négociation TLS' - Pourquoi Kubectl ne peut-il pas se connecter au serveur Azure Kubernetes? (AKS)
Ma question (à MS et à quiconque) est la suivante: pourquoi ce problème se produit-il et quelle solution de contournement peut être mise en œuvre par les utilisateurs/clients eux-mêmes par opposition au support Microsoft?
Il y a évidemment eu «quelques» autres questions à ce sujet:
- Erreur de connexion gérée Azure Kubernetes
- Impossible de contacter notre kube Azure-AKS - Délai de prise de contact TLS
- Azure Kubernetes: délai de négociation TLS (celui-ci contient des commentaires de Microsoft)
Et plusieurs problèmes GitHub publiés sur le dépôt AKS:
- https://github.com/Azure/AKS/issues/112
- https://github.com/Azure/AKS/issues/124
- https://github.com/Azure/AKS/issues/164
- https://github.com/Azure/AKS/issues/177
- https://github.com/Azure/AKS/issues/324
Plus quelques discussions sur Twitter:
TL; DR
Passer aux solutions de contournement dans les réponses ci-dessous.
La meilleure solution actuelle consiste à poster un ticket d’aide - et d’attendre - ou à recréer votre cluster AKS (peut-être plus d’une fois, croisez les doigts, voir ci-dessous ...), mais il devrait y avoir quelque chose de mieux. Au moins, veuillez autoriser AKS à prévisualiser les clients, quel que soit le niveau de support, à mettre à niveau la gravité de leur demande de support pour CE problème spécifique.
Vous pouvez également essayer de redimensionner votre cluster (en supposant que cela ne casse pas votre application).
Qu'en est-il de GitHub?
Bon nombre des problèmes de GitHub mentionnés ci-dessus ont été résolus mais le problème persiste. Auparavant, il y avait un document d'annonces concernant le problème, mais aucune mise à jour de statut de ce type n'est actuellement disponible, même si le problème persiste:
Je publie ce message car j'ai quelques nouveautés que je n'ai pas vues ailleurs et je me demande si quelqu'un a des idées en ce qui concerne d'autres options potentielles pour résoudre le problème.
Affecté VM/Utilisation des ressources du nœud
Le premier élément que je n'ai pas vu mentionné ailleurs est l'utilisation des ressources sur les noeuds/vms/instances concernés par le problème Kubectl 'Impossible de se connecter au serveur: net/http: net/http: TLS.
Utilisation du noeud de production
Le ou les nœuds de mon cluster impacté ressemblent à ceci:
La baisse d'utilisation et de réseau io est fortement corrélée à la fois à l'augmentation de l'utilisation du disque ET à la période pendant laquelle nous avons commencé à rencontrer le problème.
L’utilisation globale du nœud/VM est généralement stable avant ce graphique pour les 30 derniers jours, avec quelques bosses relatives au trafic sur le site de production, aux mises à jour, etc.
Mesures après limitation du problème(Postmortem ajouté)
Au point ci-dessus, voici les métriques du même nœud après la mise à l'échelle puis à la baisse (ce qui a permis d'atténuer notre problème, mais ne fonctionne pas toujours - voir les réponses en bas):
Notez le "Dip" dans la CPU et le réseau?C'est là que le problème Net/http: TLS nous a touchés - et lorsque le serveur AKS était inaccessible depuis Kubectl. On dirait que cela ne parle pas au VM/Node en plus de ne pas répondre à nos demandes.
Dès que nous sommes revenus (les # nœuds ont été redimensionnés et redescendus - voir les réponses pour les résoudre), les métriques (CPU, etc.) sont revenues à la normale - et nous avons pu nous connecter à partir de Kubectl. Cela signifie que nous pouvons probablement créer une alarme à partir de ce comportement (et j'ai un problème à poser à ce sujet du côté Azure DevOps: https://github.com/Azure/AKS/issues/416 )
La taille des nœuds peut avoir une incidence sur la fréquence des problèmes
Zimmergren sur GitHub indique qu'il a moins de problèmes avec les instances plus volumineuses que dans l'exécution de nœuds plus simples. Cela me semble logique et pourrait indiquer que la manière dont les serveurs AKS répartissent la charge de travail (voir section suivante) pourrait être fonction de la taille des instances.
"La taille des nœuds (par exemple, D2, A4, etc.) :) J'ai constaté par exemple qu'en utilisant A4 et plus, mon cluster est plus sain que si j'étais en A2, par exemple. (Et j'ai plus d'une douzaine de expériences avec des combinaisons de tailles et des échecs de grappes, malheureusement) ". ( https://github.com/Azure/AKS/issues/268#issuecomment-375715435 )
Autres références d'impact de taille de cluster:
_ {Un serveur AKS responsable de plusieurs clusters plus petits peut éventuellement être touché plus souvent?
Existence de plusieurs «serveurs» de gestion AKS dans une région Az
La prochaine chose que je n'ai pas vue mentionnée ailleurs est le fait que vous pouvez avoir plusieurs clusters fonctionnant côte à côte dans la même région, où un cluster (la production pour nous dans ce cas) reçoit le message 'net/http: délai de prise de contact TLS' et l'autre fonctionne bien et peut être connecté normalement via Kubectl (pour nous, c'est notre environnement de transfert identique).
Le fait que les utilisateurs (Zimmergren, etc., ci-dessus) semblent penser que la taille du nœud a un impact sur la probabilité que ce problème vous affecte, semble également indiquer que la taille du nœud peut être liée à la manière dont les responsabilités de la sous-région sont attribuées à l'AKS sous-régional. serveurs de gestion.
Cela pourrait signifier que recréer votre cluster avec une taille de cluster différente risquerait davantage de vous placer sur un serveur de gestion différent, ce qui atténuerait le problème et réduirait la probabilité que plusieurs recréations soient nécessaires.
Utilisation du cluster de staging
Nos deux clusters AKS sont situés aux États-Unis d’Est. En référence aux mesures du cluster 'Production' ci-dessus, l'utilisation des ressources du cluster 'Staging' (ainsi que l'est des États-Unis) ne subit pas la chute massive de la CPU/du réseau IO - ET ne connaît pas l'augmentation du disque, etc. . au cours de la même période:
Les environnements identiques sont touchés différemment
Nos deux clusters utilisent des entrées, des services, des pods et des conteneurs identiques; il est donc également improbable que quoi que ce soit que fasse l'utilisateur provoque ce problème.
La recréation est seulement PARFOIS réussie
L’existence ci-dessus de plusieurs responsabilités sous-régionales de serveur de gestion AKS est logique avec le comportement décrit par d’autres utilisateurs sur github ( https://github.com/Azure/AKS/issues/112 ), où certains utilisateurs peuvent recréer un cluster (qui peut ensuite être contacté) pendant que d'autres recréent et ont toujours des problèmes.
Urgence pourrait = multiples recréations
En cas d’urgence (c’est-à-dire que votre site de production ... comme le nôtre ... doit être géré), vous pouvezPROBABLEMENTsimplement recréer jusqu’à ce que vous obteniez un cluster opérationnel. atterrir sur une autre instance de serveur de gestion AKS (sans l’impact), mais sachez que cela risque de ne pas se produire lors de votre première tentative - la recréation de la grappe AKS n’est pas exactement instantanée.
Cela dit...
Les ressources sur les nœuds concernés continuent à fonctionner
Tous les conteneurs/entrées/ressources sur notre VM impacté semblent bien fonctionner et je ne déclenche aucune alarme pour la surveillance du temps d'indisponibilité/des ressources (autre que l'étrangeté liée à l'utilisation indiquée ci-dessus dans graphiques)
Je veux savoir pourquoi ce problème se produit et quelle solution de contournement peut être mise en œuvre par les utilisateurs eux-mêmes, par opposition au support Microsoft (dispose actuellement d'un ticket). Si vous avez une idée faites le moi savoir.
Indications potentielles sur la cause
- https://github.com/Azure/AKS/issues/164#issuecomment-363613110
- https://github.com/Azure/AKS/issues/164#issuecomment-365389154
Pourquoi pas de GKE?
Je comprends que Azure AKS est en avant-première et que beaucoup de gens sont passés à GKE à cause de ce problème (). Cela dit, mon expérience avec Azure n’a été jusqu’à présent que positive et je préférerais apporter une solution, dans la mesure du possible.
Et aussi ... GKE fait parfois face à quelque chose de similaire:
Je serais intéressé de voir si la mise à l'échelle des nœuds sur GKE a également résolu le problème là-bas.
Solution de contournement 1 (peut ne pas fonctionner pour tout le monde)
Une solution intéressante (qui a fonctionné pour moi) à tester consiste à augmenter le nombre de nœuds de votre cluster, puis à le réduire ...
- Connectez-vous à la lame Service Azure Console - Kubernetes.
- Mettez votre cluster à l'échelle d'un nœud.
- Attendez que la balance se termine et essayez de vous connecter (vous devriez pouvoir le faire).
- Redimensionnez votre cluster à la taille normale pour éviter des augmentations de coûts.
Alternativement, vous pouvez (peut-être) faire ceci à partir de la ligne de commande:
az aks scale --name <name-of-cluster> --node-count <new-number-of-nodes> --resource-group <name-of-cluster-resource-group>
Puisqu'il s'agit d'un problème épineux et que j'ai utilisé l'interface Web, je ne sais pas si ce qui précède est identique ou fonctionnerait.
Temps total qu'il m'a fallu ~ 2 minutes - pour ma situation, c'est BEAUCOUP mieux que de recréer/configurer un cluster (potentiellement plusieurs fois ...)
Cela étant dit....
Zimmergren soulève quelques points positifs: la mise à l'échelle n'est pas une vraie solution:
"Cela a fonctionné parfois, lorsque le cluster a guéri lui-même une période après la mise à l'échelle. Il a parfois échoué avec les mêmes erreurs. Je ne considère pas la mise à l'échelle d'une solution à ce problème, car cela pose d'autres problèmes en fonction de la configuration des choses. I Je ne ferais pas confiance à cette routine pour une charge de travail GA. Dans l'aperçu actuel, il s'agit d'un ouest un peu sauvage (et attendu), et je suis ravi de faire exploser le cluster et d'en créer un nouveau lorsque cela échoue continuellement. " ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
Commentaires du support Azure
Comme j'avais un ticket de support ouvert au moment où j'ai croisé la solution de dimensionnement ci-dessus, j'ai pu obtenir un retour (ou plutôt une supposition) sur ce qui aurait pu fonctionner ci-dessus, voici une réponse paraphrasée:
"Je sais que la mise à l'échelle du cluster peut parfois aider si vous entrez dans un état dans lequel le nombre de nœuds est incompatible entre" az aks show "et" kubectl get node ". Cela peut être similaire."
Références de contournement:
- Utilisateur GitHub Nœuds échelonnés à partir de la console et résolution du problème: https://github.com/Azure/AKS/issues/268#issuecomment-375722317
Solution de contournement n'a pas fonctionné?
Si cela ne fonctionne pas pour vous, publiez un commentaire ci-dessous, car je vais essayer de garder une liste à jour de la fréquence à laquelle le problème se présente, de sa résolution et de son efficacité pour les utilisateurs d'Azure AKS (semble comme ça ne marche pas pour tout le monde).
L'agrandissement/réduction des utilisateurs DID NE fonctionne PAS pour:
- omgsarge ( https://github.com/Azure/AKS/issues/112#issuecomment-395231681 )
- Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
- sercand - Echec de l'opération elle-même - ne sais pas s'il aurait eu un impact sur la connectabilité ( https://github.com/Azure/AKS/issues/268#issuecomment-395301296 )
Mise à l'échelle haut/bas DID fonctionne pour:
- Moi
- LohithChanda ( https://github.com/Azure/AKS/issues/268#issuecomment-395207716 )
- Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
Envoyer un courrier électronique au support spécifique Azure AKS
Si après tout le diagnostic vous avez toujours ce problème, n'hésitez pas à envoyer un courrier électronique à [email protected]
Ajout d'une autre réponse puisqu'il s'agit désormais de la solution officielle Azure Support lorsque les tentatives ci-dessus ne fonctionnent pas. Je n'ai pas rencontré le problème depuis un moment et je ne peux donc pas le vérifier, mais il me semble que cela aurait du sens (d'après l'expérience précédente).
Crédit sur celui-ci/fil complet trouvé ici ( https://github.com/Azure/AKS/issues/14#issuecomment-424828690 )
Vérifier les problèmes de tunneling
- ssh sur le noeud d'agent qui exécute le pod tunnelfront
- obtenir les journaux de tunnelfront: "docker ps" -> "les journaux de docker"
- "nslookup" dont fqdn peut être obtenu à partir de la commande ci-dessus -> si elle résout ip, ce qui signifie que dns fonctionne, passez à l'étape suivante
- "ssh -vv azureuser @ -p 9000" -> si le port fonctionne, passez à l'étape suivante
- "docker exec -it/bin/bash", tapez "ping google.com ", si ce n'est pas une réponse, ce qui signifie que le module frontal du tunnel n'a pas de réseau externe, puis passez à l'étape suivante
- redémarrez kube-proxy en utilisant "kubectl delete po -n kube-system", choisissez le kube-proxy qui s'exécute sur le même nœud que tunnelffront. le client peut utiliser "kubectl get po -n kube-system -o wide"
Je pense que cette solution particulière pourrait PROBABLEMENT être automatisée (bien sûr du côté Azure mais probablement du côté de la communauté).
Envoyer un courrier électronique au support spécifique Azure AKS
Si après tout le diagnostic vous avez toujours ce problème, n'hésitez pas à envoyer un courrier électronique à [email protected]
Solution de contournement 2 Re-Create Cluster (assez évidente)
J'ajoute celui-ci parce qu'il y a quelques détails à garder à l'esprit et même si je l'ai abordé dans ma question initiale, cette chose a pris du temps, alors j'ajoute des détails spécifiques sur la re-création ici.
La recréation de cluster ne fonctionne pas toujours
Conformément à ce qui précède dans ma question initiale, plusieurs instances du serveur AKS divisent les responsabilités pour une région Azure donnée (à notre avis). Ce bogue peut avoir un impact sur tout ou partie de ces problèmes, rendant votre cluster inaccessible via Kubectl.
Cela signifie que si vous recréez votre cluster et que certains atterrissent sur le même serveur AKS, ce nouveau cluster ne sera probablement pas joignable AINSI ne nécessitant pas ...
Tentatives de re-création supplémentaires
Si vous recréez plusieurs fois, votre nouveau cluster sera éventuellement installé sur l’un des autres serveurs AKS (qui fonctionne correctement). Autant que je sache, je ne vois aucune indication selon laquelle TOUS les serveurs AKS sont confrontés à ce problème de temps en temps (si jamais).
Taille de nœud de cluster différente
Si vous êtes dans une situation critique et souhaitez la plus grande probabilité (nous ne l'avons pas encore confirmé _) que votre re-création aboutisse sur un serveur de gestion AKS différent, choisissez une taille de nœud différente lors de la création de votre nouveau cluster. (voir la section Taille du nœud de la question initiale ci-dessus).
J'ai ouvert ce ticket en demandant à Azure DevOps si la taille du nœud est réellement liée au choix des clusters administrés par les serveurs de gestion AKS: https://github.com/Azure/AKS/issues/416
Support Ticket Fix vs Auto-guérison
Étant donné que de nombreux utilisateurs indiquent que le problème se résout parfois et qu'il disparaît, je pense qu'il est raisonnable de supposer que le support technique corrige le serveur AKS incriminé (ce qui peut amener d'autres utilisateurs à faire réparer leurs clusters - 'Self Heal ') par opposition à la réparation du cluster de l'utilisateur individuel.
Création de tickets de support
Pour moi, ce qui précède signifierait probablement que créer un ticket est probablement une bonne chose, car cela permettrait de réparer les clusters d'utilisateurs qui rencontrent le même problème. Cela pourrait également être un argument pour autoriser une escalade de la gravité du problème d'assistance pour ce problème spécifique.
Je pense que cela indique également que le support technique Azure n'a peut-être pas encore trouvé la solution au problème. Dans ce cas, la création d'un ticket de support sert également cet objectif.
J'ai également demandé à Azure DevOps si le problème était résolu (compte tenu de mon expérience, je pouvais facilement visualiser le problème en fonction du processeur et du réseau IO modifications métriques) de leur côté: https://github.com/Azure/AKS/issues/416
Si NOT (pas entendu), il est logique de créer un ticket MÊME SI vous envisagez de recréer votre cluster, car ce ticket mettrait alors Azure DevOps au courant du problème, ce qui résulterait en un correctif. d'autres utilisateurs sur ce serveur de gestion de cluster.
Choses pour faciliter la re-création de cluster
J'ajouterai à cela (les commentaires/idées sont appréciés), mais par coeur:
- Faites preuve de diligence (évidente) quant à la manière dont vous stockez tous les fichiers YAML utilisés pour créer votre cluster (même si vous ne le redéployez pas souvent pour votre application, par conception).
- Script vos modifications DNS afin d'accélérer le pointage vers la nouvelle instance - Si vous avez un service/application public qui utilise DNS (peut-être quelque chose comme cet exemple pour Google Domains ?: https://Gist.github.com/ cyrusboadway/5a7b715665f33c237996 , Documents complets ici: https://cloud.google.com/dns/api/v1/ )
Nous venons d'avoir ce problème pour l'un de nos clusters. Envoyé un ticket de support, un ingénieur a rappelé 5 minutes plus tard, leur demandant si le serveur API pouvait être redémarré. 2 minutes plus tard, ça fonctionnait encore.
Reason était quelque chose à propos des délais d'attente dans leur file d'attente de messagerie.