Corrección de problemas conocidos y errores al administrar el almacenamiento en AKS Arc

Este error de permiso denegado indica que la clase de almacenamiento predeterminada puede no ser adecuada para las cargas de trabajo y se produce en cargas de trabajo de Linux que se ejecutan sobre la versión 1.19.x de Kubernetes o posterior. Siguiendo los procedimientos recomendados de seguridad, muchas cargas de trabajo de Linux especifican la configuración securityContext fsGroup de un pod. Las cargas de trabajo no se inician en AKS en Azure Local, ya que la clase de almacenamiento predeterminada no especifica el fstype (=ext4) parámetro , por lo que Kubernetes no puede cambiar la propiedad de los archivos y los volúmenes persistentes en función de los fsGroup solicitados por la carga de trabajo.

Para resolver este problema, defina una clase de almacenamiento personalizada que pueda usar para aprovisionar las PVC.

Se creó un nuevo clúster de cargas de trabajo de Kubernetes con la versión 1.16.10 de Kubernetes y, a continuación, se actualizó a la versión 1.16.15. Después de la actualización, el pod csi-msk8scsi-node-9x47m se bloqueó en el estado ContainerCreating, y el pod kube-proxy-qqnkr se bloqueó en el estado Terminating, tal como se muestra en la salida siguiente:

Error: kubectl.exe get nodes  
NAME              STATUS     ROLES    AGE     VERSION 
moc-lf22jcmu045   Ready      <none>   5h40m   v1.16.15 
moc-lqjzhhsuo42   Ready      <none>   5h38m   v1.16.15 
moc-lwan4ro72he   NotReady   master   5h44m   v1.16.15

\kubectl.exe get pods -A 

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE 
    5h38m 
kube-system   csi-msk8scsi-node-9x47m     0/3     ContainerCreating   0          5h44m 
kube-system   kube-proxy-qqnkr            1/1     Terminating         0          5h44m  

Dado que kubelet terminó en un estado incorrecto y ya no puede comunicarse con el servidor de API, la única solución es reiniciar el servicio kubelet. Después del reinicio, el clúster entra en un estado de ejecución.

El almacenamiento en disco se puede rellenar a partir de los registros de volcado de memoria que se crean. Esto se debe a un certificado de cliente de agente de Geneva expirado. Los síntomas pueden ser los siguientes:

• Los servicios no se inician.
• Los pods, implementaciones, etc. de Kubernetes no se inician debido a que no hay recursos suficientes.

Este problema puede afectar a cualquier operación que implique asignar espacio en disco o escribir archivos nuevos, por lo que cualquier error de "espacio o recursos en disco insuficiente" es una buena sugerencia. Para comprobar si este problema está presente en un nodo determinado, ejecute el siguiente comando de shell:

clouduser@moc-lwm2oudnskl $ sudo du -h /var/lib/systemd/coredump/

Este comando informa del espacio de almacenamiento consumido por los archivos de diagnóstico.

Causa principal

La expiración del certificado de cliente usado para autenticar al agente de Ginebra en el punto de conexión de servicio hace que el agente se bloquee, lo que da lugar a un volcado de memoria. El bucle de bloqueo o reintento del agente es de aproximadamente 5 segundos al inicio inicial y no hay tiempo de espera. Esto significa que se crea un nuevo archivo (aproximadamente 330 MB) en el sistema de archivos del nodo cada pocos segundos, lo que puede consumir rápidamente el almacenamiento en disco.

Mitigación

La mitigación preferida es actualizar a la versión más reciente, versión 1.10.18.10425, que tiene un certificado actualizado. Para ello, actualice primero manualmente los clústeres de carga de trabajo a cualquier versión secundaria compatible antes de actualizar el host local de Azure.

Para más información sobre las versiones de AKS Arc y todas las noticias más recientes de AKS en Azure Local, suscríbase a la página de versiones de AKS.

Si la actualización no es una opción, puede desactivar el servicio mdsd . Para cada nodo mariner:

1. Desactive el agente de Ginebra con los siguientes comandos de shell:

   sudo systemctl disable --now mdsd
   

2. Compruebe que el agente de Ginebra se deshabilitó correctamente:

   sudo systemctl status mdsd
   

3. Elimine los archivos acumulados con el siguiente comando:

   sudo find /var/lib/systemd/coredump/ -type f -mmin +1 -exec rm -f {} \;
   sudo find /run/systemd/propagate -name 'systemd-coredump@*' -delete
   sudo journalctl --rotate && sudo journalctl --vacuum-size=500M
   

4. Reinicie el nodo:

   sudo reboot
   

Se puede producir un error si tiene un controlador SMB o NFS CSI instalado en la implementación y actualiza a la compilación de mayo a partir de una versión anterior. Uno de los parámetros, denominado createSubDir, ya no se acepta. Si esto se aplica a la implementación, siga las instrucciones siguientes para resolver el error de la clase de almacenamiento.

Si experimenta este error, el pod de almacenamiento se bloquea y los registros indican que el createSubDir parámetro no es válido.

Vuelva a crear la clase de almacenamiento.

Después de eliminar un volumen persistente o una notificación de volumen persistente en un entorno de AKS Arc, se crea un nuevo volumen persistente para asignarlo al mismo recurso compartido. Sin embargo, al intentar montar el volumen, se produce un error en el montaje y se agota el tiempo de espera del pod con el error NewSmbGlobalMapping failed.

Para evitar este error al montar el nuevo volumen, puede usar SSH en el nodo de Windows, ejecutar Remove-SMBGlobalMapping y proporcionar el recurso compartido correspondiente al volumen. Después de ejecutar este comando, los intentos de montar el volumen deberían realizarse correctamente.

Pasos siguientes

• Introducción a la solución de problemas
• Problemas conocidos de Windows Admin Center