‘No se puede conectar Net / http: TLS handshake timeout’ – ¿Por qué no se puede conectar Kubectl al servidor de Azure Kubernetes? (AKS)

Mi pregunta (a MS y a cualquier otra persona) es: ¿por qué ocurre este problema y qué solución pueden implementar los propios usuarios / clientes a diferencia del soporte de Microsoft?

Obviamente ha habido ‘otras’ otras preguntas sobre este tema:

  1. Error de conexión administrado de Azure Kubernetes
  2. No se puede contactar con nuestro kube Azure-AKS – Tiempo de espera de handshake TLS
  3. Azure Kubernetes: tiempo de espera de handshake TLS (este tiene algunos comentarios de Microsoft)

Y múltiples problemas de GitHub publicados en el repository de AKS:

  1. https://github.com/Azure/AKS/issues/112
  2. https://github.com/Azure/AKS/issues/124
  3. https://github.com/Azure/AKS/issues/164
  4. https://github.com/Azure/AKS/issues/177
  5. https://github.com/Azure/AKS/issues/324

Además de algunos hilos de twitter:

  1. https://twitter.com/ternel/status/955871839305261057

TL; DR

Pase a soluciones alternativas en Respuestas a continuación .

La mejor solución actual es publicar un ticket de ayuda – y esperar – o volver a crear su grupo de AKS (tal vez más de una vez, cruzar los dedos, ver debajo …) pero debería haber algo mejor. Al menos, conceda la posibilidad de permitir a los clientes de vista previa de AKS, independientemente del nivel de soporte, actualizar su gravedad de solicitud de soporte para ESTE problema específico.

También puede intentar escalar su Clúster (suponiendo que no rompa su aplicación).

¿Qué pasa con GitHub?

Muchos de los problemas anteriores de GitHub se han cerrado como resueltos, pero el problema persiste. Anteriormente, había un documento de anuncios con respecto al problema, pero actualmente no hay actualizaciones de estado disponibles aunque el problema continúa presentándose:

  1. https://github.com/Azure/AKS/tree/master/annoucements

Estoy publicando esto porque tengo algunas cositas nuevas que no he visto en otros sitios y me pregunto si alguien tiene ideas en cuanto a otras opciones posibles para solucionar el problema.

Uso de recursos de VM / nodo afectado

La primera pieza que no he visto mencionar en otra parte es el uso de Recursos en los nodos / vms / instancias que están siendo afectados por el problema anterior de Kubectl ‘No se puede conectar con el servidor: net / http: TLS handshake timeout’.

Utilización del nodo de producción

Los nodos de mi clúster afectado se ven así:

net / http: tiempo de espera de handshake TLS

La caída en la utilización y la red io se correlaciona fuertemente con el aumento en la utilización del disco Y el período de tiempo que comenzamos a experimentar el problema.

En general, la utilización de Nodo / VM es plana antes de este gráfico en los últimos 30 días con algunos baches relacionados con el tráfico del sitio de producción / actualizaciones, etc.

Métricas después de la mitigación del problema (agregado postmortem)

Para el punto anterior, aquí están las métricas del mismo nodo después de ampliar y luego retroceder (lo que sucedió para aliviar nuestro problema, pero no siempre funciona; consulte las respuestas en la parte inferior):

enter image description here

Observe el ‘Dip’ en la CPU y la red? Ahí es donde el problema de Net / http: TLS nos impactó, y cuando el servidor de AKS no fue accesible desde Kubectl. Parece que no estaba hablando con la VM / Node además de no responder a nuestras solicitudes.

Tan pronto como volvimos (subimos los nódulos en una, y bajamos – ver respuestas para la solución alternativa) las métricas (CPU, etc.) volvieron a la normalidad, y pudimos conectarnos desde Kubectl. Esto significa que probablemente podamos crear una alarma fuera de este comportamiento (y tengo un problema al preguntar sobre esto en el lado de Azure DevOps: https://github.com/Azure/AKS/issues/416 )

Tamaño del nodo Impactos potenciales Frecuencia de emisión

Zimmergren en GitHub indica que tiene menos problemas con instancias más grandes que lo que hizo al ejecutar esqueletos de nodos más pequeños. Esto tiene sentido para mí y podría indicar que la forma en que los servidores AKS dividen la carga de trabajo (consulte la siguiente sección) podría basarse en el tamaño de las instancias.

“El tamaño de los nodos (por ejemplo, D2, A4, etc.) 🙂 He experimentado que al ejecutar A4 y arriba, mi clúster es más saludable que si ejecuta A2, por ejemplo. (Y tengo más de una docena similar experiencias con combinaciones de tamaños y fallas de clúster, desafortunadamente) “. ( https://github.com/Azure/AKS/issues/268#issuecomment-375715435 )

Otras referencias de impacto de tamaño de clúster:

  1. giorgited ( https://github.com/Azure/AKS/issues/268#issuecomment-376390692 )

¿Es posible que un servidor AKS responsable de clusters más pequeños sea golpeado con mayor frecuencia?

Existencia de múltiples ‘servidores’ de gestión AKS en una región Az

Lo siguiente que no he visto mencionar en otra parte es el hecho de que puede tener varios clústeres ejecutándose uno al lado del otro en la misma región donde un clúster (producción para nosotros en este caso) recibe ‘net / http: TLS handshake timeout’ y el otro funciona bien y se puede conectar normalmente a través de Kubectl (para nosotros este es nuestro entorno de ensayo idéntico).

El hecho de que los usuarios (Zimmergren, etc.) parezcan sentir que el tamaño del Nodo afecta la probabilidad de que este problema lo afecte también parece indicar que el tamaño del nodo puede relacionarse con la forma en que las responsabilidades de la subregión están asignadas al AKS subregional. servidores de gestión.

Eso podría significar que volver a crear su clúster con un tamaño de clúster diferente sería más probable que lo coloque en un servidor de administración diferente, aliviando el problema y reduciendo la probabilidad de que se necesiten varias recreaciones.

Puesta en escena de la utilización del clúster

Ambos de nuestros clústeres de AKS se encuentran en el este de EE. UU. Como referencia a las métricas de Cluster de ‘Producción’ anteriores, nuestra utilización de recursos ‘Staging’ Cluster (también US East) no tiene la caída masiva en CPU / Network IO – Y no tiene el aumento en disco, etc. en el mismo período:

net / http: se puede acceder a la instancia de ensayo de tiempo de espera de handshake de TLS a través de kubectl.

Ambientes idénticos se ven afectados de forma diferente

Nuestros dos Clusters funcionan con entradas, servicios, pods y contenedores idénticos, por lo que tampoco es probable que algo que esté haciendo un usuario haga que surja este problema.

La recreación solo es ALGUNAS veces exitosa

La anterior existencia de múltiples responsabilidades subregionales del servidor de administración AKS tiene sentido con el comportamiento descrito por otros usuarios en github ( https://github.com/Azure/AKS/issues/112 ) donde algunos usuarios pueden volver a crear un servidor. clúster (que luego se puede contactar), mientras que otros pueden volver a crear y todavía tienen problemas.

Emergencia podría = Múltiples recreaciones

En una emergencia (es decir, su sitio de producción … como el nuestro … necesita ser administrado) PROBABLEMENTE puede volver a crear hasta que obtenga un clúster en funcionamiento que aterrice en una instancia diferente del servidor de administración AKS (que no sea Impactado), pero tenga en cuenta que esto puede no suceder en su primer bash: la recreación del clúster AKS no es exactamente instantánea.

Eso dijo …

Los recursos en los nodos afectados continúan funcionando

Todos los contenedores / ingresos / recursos en nuestra VM impactada parecen estar funcionando bien y no tengo alarmas que se activen para la monitorización de recursos / tiempo (además de la rareza de utilización enumerada anteriormente en los gráficos)

Quiero saber por qué está ocurriendo este problema y qué solución pueden implementar los propios usuarios en lugar de hacerlo con el Soporte de Microsoft (actualmente tienen un ticket). Si tienes una idea, házmelo saber.

Sugerencias potenciales en la causa

  1. https://github.com/Azure/AKS/issues/164#issuecomment-363613110
  2. https://github.com/Azure/AKS/issues/164#issuecomment-365389154

¿Por qué no GKE?

Entiendo que Azure AKS está en la vista previa y que mucha gente se ha mudado a GKE debido a este problema (). Dicho esto, mi experiencia en Azure no ha sido más que positiva hasta ahora y preferiría aportar una solución si es posible.

Y también … GKE ocasionalmente enfrenta algo similar:

  1. Tiempo de espera de handshake de TLS con kubernetes en GKE

Me interesaría ver si escalar los nodos en GKE también resolvió el problema allí.

Solución 1 (puede no funcionar para todos)

Una solución interesante (que funcionó para mí) para probar es escalar el número de nodos en su clúster, y luego volver a bajar …

enter image description here

  1. Inicie sesión en la Consola Azure: hoja de servicio de Kubernetes.
  2. Escala tu cluster por 1 nodo.
  3. Espere a que se complete la escala e intente conectarse (debe poder).
  4. Escale su clúster al tamaño normal para evitar aumentos de costos.

Alternativamente, puedes (quizás) hacer esto desde la línea de comando:

az aks scale --name --node-count --resource-group

Dado que es un problema complejo y utilicé la interfaz web, no estoy seguro si lo anterior es idéntico o si funcionaría.

Tiempo total que me tomó ~ 2 minutos: para mi situación es mucho mejor que volver a crear / configurar un clúster (potencialmente varias veces …)

Habiendo dicho eso….

Zimmergren saca a relucir algunos puntos buenos que Scaling no es una verdadera solución:

“Funcionó a veces, cuando el clúster se curó por sí mismo un período después del escalado. Falló a veces con los mismos errores. No considero escalar una solución a este problema, ya que causa otros desafíos según cómo se configuren las cosas. no confiaría en esa rutina para una carga de trabajo de GA, eso es seguro. En la vista previa actual, es un poco salvaje oeste (y esperado), y estoy feliz de explotar el clúster y crear uno nuevo cuando esto falla continuamente. ” ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )

Comentarios de soporte de Azure

Como tenía una boleta de soporte abierta en el momento en que me encontré con la solución de escalado anterior, pude obtener retroalimentación (o más bien una conjetura) sobre lo que podría haber funcionado anteriormente, aquí hay una respuesta parafraseada:

“Sé que escalar el clúster a veces puede ser útil si te encuentras en un estado en el que el número de nodos no coincide entre” mostrar azk “y” kubectl obtener nodos “. Esto puede ser similar”.

Referencias de la solución:

  1. El usuario de GitHub ha escalado los nodos desde la consola y solucionó el problema: https://github.com/Azure/AKS/issues/268#issuecomment-375722317

¿La solución no funcionó?

Si esto NO funciona para usted, publique un comentario a continuación, ya que intentaré mantener una lista actualizada de la frecuencia con que surge el problema, si se resuelve solo y si esta solución funciona para los usuarios de Azure AKS (se ve como que no funciona para todos).

Los usuarios escalan hacia arriba / abajo NO funcionó para:

  1. omgsarge ( https://github.com/Azure/AKS/issues/112#issuecomment-395231681 )
  2. Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )
  3. la operación de escala de sercand en sí falló – no estoy seguro si hubiera afectado la capacidad de conexión ( https://github.com/Azure/AKS/issues/268#issuecomment-395301296 )

Escala arriba / abajo HIZO trabajo para:

  1. Yo
  2. LohithChanda ( https://github.com/Azure/AKS/issues/268#issuecomment-395207716 )
  3. Zimmergren ( https://github.com/Azure/AKS/issues/268#issuecomment-395299308 )

Solución 2 Re-Create Cluster (Algo obvio)

Estoy agregando este porque hay algunos detalles para tener en cuenta y, aunque lo toqué en mi Pregunta original, esa cosa se alargó, así que estoy agregando detalles específicos sobre la recreación aquí.

La recreación del clúster no siempre funciona

Por lo anterior en mi pregunta original, hay varias instancias del Servidor AKS que dividen las responsabilidades para una determinada región de Azure (creemos). Algunos, o todos, de estos pueden verse afectados por este error, lo que provoca que su Clúster no sea accesible a través de Kubectl.

Eso significa que si vuelve a crear su Cluster y de alguna manera aterriza en el mismo servidor AKS, probablemente ese nuevo Cluster TAMBIÉN no será accesible, lo que requerirá …

Intentos de recreación adicionales

Probablemente volver a crear varias veces resultará en que eventualmente aterrice su nuevo Cluster en uno de los otros servidores AKS (que funciona bien). Por lo que puedo decir, no veo ninguna indicación de que TODOS los servidores AKS reciban este problema de una vez en mucho tiempo (si es que lo hacen).

Diferente tamaño de nodo de clúster

Si está en un apuro y desea la probabilidad más alta posible ( no lo hemos confirmado ) de que su recreación aterriza en un servidor de administración de AKS diferente, elija un tamaño de Nodo diferente cuando cree su nuevo Clúster (consulte la sección Tamaño del nodo de la pregunta inicial anterior).

Abrí este ticket preguntando a Azure DevOps si el tamaño del nodo está REALMENTE relacionado con la decisión de qué clústeres están administrados por qué servidores de administración AKS: https://github.com/Azure/AKS/issues/416

Soporte Ticket Fix vs Self Healing

Como hay muchos usuarios que indican que el problema se resuelve de vez en cuando y desaparece, creo que es razonable adivinar que Support realmente repara el servidor AKS ofensor (lo que puede hacer que otros usuarios tengan sus Clusters solucionados – ‘Self Heal ‘) a diferencia de la fijación del Clúster de usuario individual.

Crear tickets de soporte

Para mí, lo anterior probablemente significaría que crear un Ticket probablemente sea una buena cosa ya que arreglaría otros Clústeres de usuarios que experimentan el mismo problema; también podría ser un argumento para permitir la escalada de gravedad del problema de soporte para este problema específico.

Creo que esto también es un indicador decente de que tal vez el soporte de Azure aún no ha descubierto cómo alarmar por completo para el problema, en cuyo caso la creación de un ticket de soporte también cumple ese propósito.

También le pregunté a Azure DevOps si tenían alarma para el problema (basado en mi experiencia visualizando fácilmente el problema basado en los cambios métricos de la CPU y la red IO) de su lado: https://github.com/Azure/AKS/issues/416

Si NO ( no he recibido respuesta ), entonces tiene sentido crear un ticket AUN SI usted planea volver a crear su clúster ya que ese boleto haría que Azure DevOps tenga conocimiento del problema, lo que resultaría en una solución para otros usuarios en esa administración del Clúster servidor.

Cosas para hacer la recreación de clúster más fácil

Añadiré a esto (los comentarios / ideas son apreciados) pero fuera de lo común:

  1. Sea diligente (obvio) acerca de cómo almacena todos los archivos YAML utilizados para crear su Clúster (incluso si no se vuelve a implementar con frecuencia para su aplicación por diseño).
  2. Guíe las modificaciones de su DNS para acelerar apuntar a la nueva instancia. Si tiene una aplicación / servicio de cara al público que utiliza DNS (¿Quizás algo como este ejemplo para Google Domains ?: https://gist.github.com/cyrusboadway/ 5a7b715665f33c237996 , documentos completos aquí: https://cloud.google.com/dns/api/v1/ )