Instalé kubernetes en un servidor de un solo nodo usando kubeadm. Descubrí que al realizar la instalación en un orden específico, todo funciona bien. Esto incluye los componentes principales del sistema Kube (servidor API, proxy, programador, etc.) que se pusieron en marcha y se ejecutaron primero (excepto los coredns), después de lo cual se instaló el complemento cilium CNI usando helm para la conexión en red (lo que dio como resultado que los coredns funcionaran).
Después de esta instalación, pude instalar y utilizar otros servicios como el operador de GPU de NVIDIA y kubeflow con éxito. Sin embargo, después de realizar un reinicio, encuentro que los diferentes componentes entran en un estado de retroceso de bucle de falla.
Creo que esto tiene algo que ver con el orden en que se inicializan los diferentes recursos y la duración de los diferentes tiempos de espera. ¿Hay alguna manera de establecer un orden para que los diferentes componentes se inicien en el arranque? ¿O posiblemente configurar un tiempo de espera predeterminado adecuado o un comportamiento de bloqueo de los pods?
Probablemente se esté produciendo un efecto dominó en el que el fallo de un componente provoca la aparición de otro, lo que conduce a tiempos de espera cada vez mayores y, en última instancia, a un clúster que no responde.
Para obtener información adicional, he conservado las reglas de iptables para que se apliquen al arrancar. Además, normalmente todos los componentes principales entran en estado de ejecución, excepto el programador de Kube, que permanece en el bucle de bloqueo. Luego, los otros componentes también comienzan a fallar en lo que parece ser un efecto dominó.
Hasta ahora, he intentado principalmente actualizar los archivos de manifiesto en /etc/kubernetes/manifests/ para usar diferentes tiempos de espera y umbrales de falla para los pods del sistema Kubernetes; sin embargo, esto no pareció resolver el problema. Podría replicar el comportamiento de reinicio del servidor deteniendo primero el servicio de kubelet y destruyendo todos los pods/contenedores en ejecución y luego reiniciando kubelet.
Respuesta1
Resulta que este problema es muy similar al descrito en este GitHub.asunto. Esencialmente sin especificar la SystemdCgroup = trueopción para mi tiempo de ejecución CRI en contenedor (que era elnvidiatiempo de ejecución del contenedoren lugar del valor predeterminado de runc), los pods iban a seguir fallando inexplicablemente. Esto sucedió debido a una violación de la regla de escritor único de cgroups, ya que el controlador predeterminado para administrar cgroups cgroupfsno es interoperable con systemd. Puedes ver eldocumentaciónpara más detalles. También incluye una especificación completa de la configuración del complemento CRI.aquí.
Otros recursos en contenedores relevantes son: