Compartir a través de

Solución de problemas de Kubernetes

  • Artículo

En esta página se describen varios problemas comunes con la configuración, las redes y las implementaciones de Kubernetes.

Sugerencia

Sugerir un elemento de preguntas más frecuentes mediante la generación de una solicitud de incorporación de cambios al repositorio de documentación.

Esta página se subdivide en las siguientes categorías:

  1. Preguntas generales
  2. Errores comunes de red
  3. Errores comunes de Windows
  4. Errores de maestro comunes de Kubernetes

Preguntas generales

Cómo saber que Kubernetes en Windows se completó correctamente?

Debería ver kubelet, kube-proxy y (si eligió Flannel como solución de red) procesos flanneld host-agent que se ejecutan en el nodo. Además de esto, el nodo de Windows debe aparecer como "Listo" en el clúster de Kubernetes.

¿Puedo configurar para ejecutar todo esto en segundo plano?

A partir de la versión 1.11 de Kubernetes, kubelet y kube-proxy se pueden ejecutar como servicios nativos de Windows. También puede usar siempre administradores de servicios alternativos como nssm.exe para ejecutar siempre estos procesos (flanneld, kubelet y kube-proxy) en segundo plano.

Errores comunes de red

Los equilibradores de carga se agrupan de forma incoherente entre los nodos del clúster

En Windows, kube-proxy crea un equilibrador de carga de HNS para cada servicio de Kubernetes del clúster. En la configuración de kube-proxy (valor predeterminado), los nodos de clústeres que contienen muchos equilibradores de carga (normalmente 100+) pueden agotarse de puertos TCP efímeros disponibles (a.k.a. intervalo de puertos dinámicos, que de forma predeterminada cubre los puertos 49152 a 65535). Esto se debe al gran número de puertos reservados en cada nodo para cada equilibrador de carga (no DSR). Este problema puede manifestarse a través de errores en kube-proxy, como:

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

Los usuarios pueden identificar este problema ejecutando el script CollectLogs.ps1 y consultando los *portrange.txt archivos.

También CollectLogs.ps1 imitará la lógica de asignación de HNS para probar la disponibilidad de asignación del grupo de puertos en el intervalo de puertos TCP efímero y notificar el éxito o el error en reservedports.txt. El script reserva 10 intervalos de 64 puertos efímeros TCP (para emular el comportamiento de HNS), cuenta los éxitos y errores de reserva y, a continuación, libera los intervalos de puertos asignados. Un número de éxito menor que 10 indica que el grupo efímero se está quedando sin espacio libre. También se generará un resumen heuristico del número de reservas de puertos de 64 bloques aproximadamente disponibles en reservedports.txt.

Para resolver este problema, se pueden realizar algunos pasos:

  1. Para una solución permanente, el equilibrio de carga kube-proxy debe establecerse en modo DSR. El modo DSR está totalmente implementado y disponible solo en la compilación 18945 (o superior) de Windows Server Insider más reciente.
  2. Como solución alternativa, los usuarios también pueden aumentar la configuración predeterminada de Windows de puertos efímeros disponibles mediante un comando como netsh int ipv4 set dynamicportrange TCP <start_port> <port_count>. ADVERTENCIA: Invalidar el intervalo de puertos dinámicos predeterminado puede tener consecuencias en otros procesos o servicios en el host que dependen de los puertos TCP disponibles del intervalo no efímero, por lo que este intervalo debe seleccionarse cuidadosamente.
  3. Hay una mejora de escalabilidad para equilibradores de carga que no son DSR mediante el uso compartido inteligente del grupo de puertos incluido en la actualización acumulativa KB4551853 (y todas las actualizaciones acumulativas más recientes).

La publicación de HostPort no funciona

Para usar la característica HostPort, asegúrese de que los complementos de CNI son la versión v0.8.6 o superior, y de que el archivo de configuración de CNI tiene las portMappings funcionalidades establecidas:

"capabilities": {
    "portMappings":  true
}

Veo errores como "hnsCall failed in Win32: The wrong diskette is in the drive".

Este error se puede producir al realizar modificaciones personalizadas en objetos HNS o instalar una nueva Actualización de Windows que introduce cambios en HNS sin anular objetos HNS antiguos. Indica que un objeto HNS que se creó anteriormente antes de que una actualización no sea compatible con la versión de HNS instalada actualmente.

En Windows Server 2019 (y versiones anteriores), los usuarios pueden eliminar objetos HNS eliminando el archivo HNS.data.

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

Los usuarios deben poder eliminar directamente los puntos de conexión o redes de HNS incompatibles:

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

Los usuarios de Windows Server, versión 1903 pueden ir a la siguiente ubicación del Registro y eliminar cualquier NIC que empiece por el nombre de red (por ejemplo vxlan0 , o cbr0):

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

Los contenedores en la implementación de host-gw de Flannel en Azure no pueden acceder a Internet

Al implementar Flannel en modo host-gw en Azure, los paquetes deben pasar por el vSwitch del host físico de Azure. Los usuarios deben programar rutas definidas por el usuario de tipo "aplicación virtual" para cada subred asignada a un nodo. Esto se puede hacer a través de Azure Portal (consulte un ejemplo aquí) o a través de az la CLI de Azure. Este es un ejemplo de UDR con el nombre "MyRoute" mediante comandos az para un nodo con IP 10.0.0.4 y la subred de pod correspondiente 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 

Sugerencia

Si va a implementar Kubernetes en máquinas virtuales iaaS o de Azure desde otros proveedores de nube, también puede usar overlay networking en su lugar.

Mis pods de Windows no pueden hacer ping a recursos externos

Los pods de Windows no tienen reglas de salida programadas para el protocolo ICMP hoy mismo. Sin embargo, se admite TCP/UDP. Al intentar demostrar la conectividad a los recursos fuera del clúster, sustituya ping <IP> por los comandos correspondientes curl <IP> .

Si sigue teniendo problemas, lo más probable es que la configuración de red en cni.conf merezca cierta atención adicional. Siempre puede editar este archivo estático, la configuración se aplicará a los recursos de Kubernetes recién creados.

¿Por qué? Uno de los requisitos de red de Kubernetes (consulte modelo de Kubernetes) es para que la comunicación del clúster se produzca sin NAT internamente. Para cumplir este requisito, tenemos un exceptionList para toda la comunicación en la que no queremos que se produzca NAT de salida. Sin embargo, esto también significa que debe excluir la dirección IP externa que está intentando consultar de ExceptionList. Solo entonces el tráfico que se origina en los pods de Windows será SNAT correctamente para recibir una respuesta del mundo exterior. En este sentido, la clase ExceptionList en cni.conf debe tener el siguiente aspecto:

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

Mi nodo de Windows no puede acceder a un servicio NodePort

Es posible que se produzca un error en el acceso Local NodePort desde el propio nodo. Se trata de una brecha de características conocida que se aborda con la actualización acumulativa KB4571748 (o posterior). El acceso a NodePort funcionará desde otros nodos o clientes externos.

Mi nodo de Windows detiene el enrutamiento thourgh NodePorts después de reducir verticalmente mis pods

Debido a una limitación de diseño, debe haber al menos un pod que se ejecute en el nodo de Windows para que el reenvío de NodePort funcione.

Después de algún tiempo, se eliminan los puntos de conexión de VNIC y HNS de los contenedores.

Este problema puede deberse a que el hostname-override parámetro no se pasa a kube-proxy. Para resolverlo, los usuarios deben pasar el nombre de host a kube-proxy de la siguiente manera:

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

En el modo Flannel (vxlan), mis pods tienen problemas de conectividad después de volver a unir el nodo

Cada vez que se vuelve a unir un nodo eliminado previamente al clúster, flannelD intentará asignar una nueva subred de pod al nodo. Los usuarios deben quitar los archivos de configuración de subred de pod antiguos en las siguientes rutas de acceso:

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

Después de iniciar Kubernetes, Flanneld está bloqueado en "Esperando a que se cree la red"

Este problema debe solucionarse con Flannel v0.12.0 (y versiones posteriores). Si usa una versión anterior de Flanneld, hay una condición de carrera conocida que puede ocurrir de modo que no se establezca la dirección IP de administración de la red flannel. Una solución alternativa consiste simplemente en volver a iniciar 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

Mis pods de Windows no se pueden iniciar debido a que falta /run/flannel/subnet.env

Esto indica que Flannel no se ha lanzado correctamente. Puede intentar reiniciar flanneld.exe o puede copiar los archivos manualmente desde el maestro de /run/flannel/subnet.env Kubernetes en C:\run\flannel\subnet.env en el nodo de trabajo de Windows y modificar la FLANNEL_SUBNET fila a la subred asignada. Por ejemplo, si se asignó la subred 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

Con más frecuencia que no, hay otro problema que podría estar causando este error que debe investigarse primero. Se recomienda que genere flanneld.exe este archivo automáticamente.

La conectividad de pod a pod entre hosts se interrumpe en el clúster de Kubernetes que se ejecuta en vSphere

Dado que vSphere y Flannel reservan el puerto 4789 (puerto VXLAN predeterminado) para las redes de superposición, los paquetes pueden acabar interceptándose. Si vSphere se usa para las redes de superposición, debe configurarse para usar un puerto diferente para liberar hasta 4789.

Mis puntos de conexión o direcciones IP están filtrando

Existen 2 problemas conocidos actualmente que pueden hacer que los puntos de conexión se filtren.

  1. El primer problema conocido es un problema en la versión 1.11 de Kubernetes. Evite usar Kubernetes versión 1.11.0 - 1.11.2.
  2. El segundo problema conocido que puede hacer que los puntos de conexión se filtren es un problema de simultaneidad en el almacenamiento de puntos de conexión. Para recibir la corrección, debe usar Docker EE 18.09 o superior.

Mis pods no se pueden iniciar debido a errores de "red: no se pudo asignar el intervalo".

Esto indica que el espacio de direcciones IP del nodo se usa. Para limpiar los puntos de conexión filtrados, migre los recursos de los nodos afectados y ejecute los siguientes comandos:

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

Mi nodo de Windows no puede acceder a mis servicios mediante la dirección IP del servicio

Se trata de una limitación conocida de la pila de redes actual en Windows. Sin embargo, los pods de Windows pueden acceder a la dirección IP del servicio.

No se encuentra ningún adaptador de red al iniciar Kubelet

La pila de redes de Windows necesita un adaptador virtual para que funcionen las redes de Kubernetes. Si los siguientes comandos no devuelven ningún resultado (en un shell de administración), se ha producido un error en la creación de red de HNS ( un requisito previo necesario para que Kubelet funcione):

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

A menudo vale la pena modificar el parámetro InterfaceName del script start.ps1, en los casos en los que el adaptador de red del host no es "Ethernet". De lo contrario, consulte la salida del start-kubelet.ps1 script para ver si hay errores durante la creación de la red virtual.

Sigo viendo problemas. ¿Cuál debo hacer?

Puede haber restricciones adicionales en su red o en hosts que impidan determinados tipos de comunicación entre nodos. Asegúrate de que:

  • ha configurado correctamente la topología de red elegida (l2bridge o overlay)
  • se permite el tráfico que parece que procede de pods.
  • Se permite el tráfico HTTP, si va a implementar servicios web
  • No se quitan paquetes de distintos protocolos (ie ICMP frente a TCP/UDP)

Sugerencia

Para obtener más recursos de autoayuda, también hay una guía de solución de problemas de redes de Kubernetes para Windows disponible aquí.

Errores comunes de Windows

Mis pods de Kubernetes están bloqueados en "ContainerCreating"

Este problema puede tener muchas causas, pero una de las más comunes es que la imagen de pausa estaba mal configurada. Este es un síntoma de alto nivel del siguiente problema.

Al implementar, los contenedores de Docker siguen reiniciando

Compruebe que la imagen de pausa es compatible con la versión del sistema operativo. Kubernetes supone que tanto el sistema operativo como los contenedores tienen números de versión del sistema operativo coincidentes. Si usa una compilación experimental de Windows, como una compilación de Insider, deberá ajustar las imágenes en consecuencia. Consulte el repositorio de Docker de Microsoft para obtener imágenes.

Errores de maestro comunes de Kubernetes

La depuración del maestro de Kubernetes se divide en tres categorías principales (en orden de probabilidad):

  • Algo está mal con los contenedores del sistema de Kubernetes.
  • Algo está mal con la forma kubelet en que se está ejecutando.
  • Algo está mal con el sistema.

Ejecute kubectl get pods -n kube-system para ver los pods creados por Kubernetes; esto puede proporcionar información sobre qué puntos concretos se bloquean o no se inician correctamente. A continuación, ejecute docker ps -a para ver todos los contenedores sin procesar que respaldan estos pods. Por último, ejecute docker logs [ID] en los contenedores que se sospecha que están causando el problema para ver la salida sin procesar de los procesos.

No se puede conectar al servidor de API en https://[address]:[port]

Con más frecuencia que no, este error indica problemas de certificado. Asegúrese de que ha generado correctamente el archivo de configuración, de que las direcciones IP de él coinciden con la del host y de que la ha copiado en el directorio montado por el servidor de API.

Buenos lugares para encontrar este archivo de configuración son:

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

De lo contrario, consulte el archivo de manifiesto del servidor de API para comprobar los puntos de montaje.