¿Por qué veo un UnresponsiveMountHelperContainerUtility error paraFile Storage for VPC ?

Nube privada virtual

Tu aplicación, que utiliza el cifrado en tránsito (EIT) con un perfil zonal de dp2 File Storage for VPC, falla y muestra el error UnresponsiveMountHelperContainerUtility.

Soluciona los problemas de los sistemas de almacenamiento de archivos VPC que no responden con EIT (Encrypted In Transit).

Aparece un mensaje de error similar al del siguiente ejemplo:

Code: UnresponsiveMountHelperContainerUtility,
Description: Failed to mount target because unable to make connection to mount helper container service.,
BackendError: Failed to send EIT based request. Failed with error:
  Post "http://unix/api/mount": dial unix /var/lib/ibmshare.sock: connect: no such file or directory,
Action: Check if EIT is enabled from storage operator.
  Run command 'kubectl edit configmap addon-vpc-file-csi-driver-configmap -n kube-system'
  and set 'ENABLE_EIT' flag to 'true'.

O bien EIT no está habilitado en tus grupos de trabajadores, o bien el pod de tu aplicación se ha programado en un nodo de un grupo de trabajadores en el que EIT no está habilitado. Se cumple una de las siguientes condiciones:

  • ENABLE_EIT ¿ false o EIT_ENABLED_WORKER_POOLS están vacíos en el configmap?
  • El grupo de trabajadores en el que se está ejecutando el pod no aparece en EIT_ENABLED_WORKER_POOLS.
  • En los nodos de trabajo de RHCOS, los paquetes EIT están instalados, pero aún no se ha reiniciado el nodo para activarlos.
  • En los nodos de trabajo de RHCOS, se llevó a cabo un ciclo previo de desinstalación y reinstalación sin reiniciar el sistema entre ambas operaciones, lo que dejó el paquete en un estado defectuoso de «ya superpuesto».

Resolución del problema

Sigue los siguientes pasos para identificar y resolver la causa.

Comprueba qué nodos tienen activada la función EIT

Revisa el mapa de configuración « file-csi-driver-status » para ver qué nodos tienen instalados los paquetes EIT y comprueba que la configuración sea correcta.

  1. Describe el «configmap» de estado para ver qué nodos tienen habilitado el EIT. Busca la clave « EIT_ENABLED_WORKER_NODES », que recoge los nombres de los grupos de trabajadores y las direcciones IP de los nodos en los que se ha completado la instalación de EIT.

    oc describe cm file-csi-driver-status -n kube-system

    Salida de ejemplo:

    EIT_ENABLED_WORKER_NODES:
----
default:
- 10.240.0.89
- 10.240.0.87
- 10.240.0.88

    Un valor vacío significa que aún no se ha instalado EIT en ningún nodo.

  2. Comprueba que la opción « ENABLE_EIT » esté configurada en « true » y que el grupo de trabajadores de destino aparezca en la lista de EIT_ENABLED_WORKER_POOLS.

    oc describe cm addon-vpc-file-csi-driver-configmap -n kube-system

Comprueba que el pod de tu aplicación se esté ejecutando en un nodo compatible con EIT

Haz una lista de tus pods para averiguar en qué nodo están programados y, a continuación, compáralos con la lista de la sección anterior.

  1. Enumera tus pods y anota la dirección IP del nodo en el que se ejecuta cada uno de ellos.

    oc get pods -A -o wide

  2. Comprueba que la dirección IP del nodo coincida con la lista de EIT_ENABLED_WORKER_NODES del paso 1. Si el pod se encuentra en un nodo que no figura en esa lista, realiza una de las siguientes acciones:

    • Mueve el pod a un nodo compatible con EIT utilizando selectores de nodo o reglas de afinidad.
    • Añade el grupo de trabajadores que contiene ese nodo a « EIT_ENABLED_WORKER_POOLS » en el configmap y espera a que el operador realice la reconciliación.

Consideraciones específicas del sistema operativo

Los paquetes necesarios se instalan de forma diferente según el sistema operativo del nodo de trabajo.

Ubuntu y RHEL

No es necesario reiniciar. Los paquetes se activan inmediatamente después de la instalación. Si la dirección IP del nodo aparece en EIT_ENABLED_WORKER_NODES y el pod se encuentra en ese nodo, el EIT debería funcionar correctamente. Si el socket sigue sin aparecer, comprueba los registros del pod del operador de almacenamiento para ver si hay errores de instalación.

oc logs -n kube-system -l app=ibm-vpc-file-csi-operator --tail=100

RHCOS / CoreOS

RHCOS es un sistema operativo inmutable. Los paquetes no se activan hasta que se reinicie el nodo, aunque la dirección IP del nodo ya figure en EIT_ENABLED_WORKER_NODES.

Node Aparece como compatible con EIT, pero el montaje sigue fallando

Si la dirección IP del nodo aparece en EIT_ENABLED_WORKER_NODES pero sigues viendo el error « UnresponsiveMountHelperContainerUtility », significa que el nodo no se ha reiniciado desde que se instalaron los paquetes. El socket /var/lib/ibmshare.sock no existe hasta después de reiniciar el sistema.

Para confirmar que hay un reinicio pendiente, ejecuta los siguientes comandos en el nodo afectado:

  1. Abre un shell de depuración en el nodo afectado mediante la CLI de « OpenShift ».

    oc debug node/<nodeName>

  2. En el shell de depuración, comprueba si hay paquetes EIT preparados pero aún no activos.

    chroot /host
rpm-ostree status

    En el resultado, busca una capa pendiente o en fase de preparación que incluya mount-helper y mount-helper-container. Si los paquetes aparecen en una capa que no está marcada como « (booted) », es necesario reiniciar el sistema para activarlos.

    Ejemplo de salida que muestra los paquetes preparados para el próximo arranque:

    State: idle
Deployments:
  ● ostree-unverified-registry:...
    ...
    LayeredPackages: mount-helper mount-helper-container
  ostree-unverified-registry:...  (booted)
    ...

Para solucionar este problema, vacíe y reinicie el nodo RHCOS afectado para evitar que las cargas de trabajo en ejecución se vean afectadas.

  1. Busca los ID de los trabajadores correspondientes a los nodos que aparecen en EIT_ENABLED_WORKER_NODES, identificándolos por sus direcciones IP.

    ibmcloud ks workers --cluster CLUSTER_ID

  2. Vacíe el nodo para cerrar de forma segura todos los pods en ejecución antes de reiniciar el sistema.

    oc drain <node-name> --ignore-daemonsets --delete-emptydir-data

  3. Reinicia el nodo que se ha quedado sin energía.

    ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID

  4. Una vez que el nodo vuelva a estar en línea y en estado « Ready », desactivá el «uncordon» para que se puedan volver a programar cargas de trabajo en él.

    oc uncordon <node-name>

La instalación falla con el error «ya está en capas» en RHCOS

Si anteriormente desinstalaste EIT en un grupo de trabajadores de RHCOS y luego lo volviste a habilitar sin reiniciar el nodo entre medias, es posible que la tarea de instalación del operador de almacenamiento falle con un error similar al siguiente:

error: Packages are already layered: mount-helper-<version>.rpm mount-helper-container-<version>.rpm

Esto ocurre porque « rpm-ostree uninstall » solo prepara la eliminación. Los paquetes siguen estando presentes en la capa de arranque actual hasta que se reinicia el sistema. Cuando el operador intenta volver a ejecutar « rpm-ostree install », el sistema detecta que los paquetes ya están instalados.

Para solucionar esto:

  1. Vacíe el nodo para cerrar de forma segura todos los pods en ejecución antes de reiniciar el sistema.

    oc drain <node-name> --ignore-daemonsets --delete-emptydir-data

  2. Reinicia el nodo RHCOS para aplicar la desinstalación pendiente.

    ibmcloud ks worker reboot --cluster CLUSTER_ID --worker WORKER_ID

  3. Una vez que el nodo vuelva a estar en línea y en estado « Ready », desactivá el «uncordon» para que se puedan volver a programar cargas de trabajo en él.

    oc uncordon <node-name>

  4. Una vez que el nodo vuelve a estar operativo, los paquetes instalados anteriormente han desaparecido. El operador del almacén los vuelve a instalar automáticamente en el siguiente ciclo de conciliación, normalmente en unos minutos.

  5. Una vez que el operador haya indicado que el nodo es compatible con EIT en EIT_ENABLED_WORKER_NODES, vacíe el nodo y reinícielo de nuevo para activar los paquetes recién instalados; a continuación, desactive el cordón de seguridad.

El ciclo completo para desinstalar y volver a instalar RHCOS es el siguiente: reiniciar tras la desinstalación → el operador vuelve a instalar el programa → reiniciar de nuevo para activarlo.

Nuevos nodos añadidos a un grupo de trabajadores compatible con EIT

Cuando un nuevo nodo se incorpora a un grupo de trabajadores que ya figura en EIT_ENABLED_WORKER_POOLS, el operador de almacenamiento instala automáticamente los paquetes de EIT en el nuevo nodo durante su siguiente ciclo de reconciliación. No es necesario actualizar el configmap.

En el caso de los nodos RHCOS, es necesario vaciar y reiniciar el nodo tras la instalación para que EIT se active. Vacíe el nodo, reinícielo y, a continuación, desconéctelo para reducir el impacto en las cargas de trabajo en ejecución. Hasta que se reinicie el nodo, cualquier pod que utilice un PVC con EIT habilitado y esté programado en ese nuevo nodo mostrará el mismo error « UnresponsiveMountHelperContainerUtility ». Ubuntu Los nodos (IKS) y RHEL (ROKS) no necesitan reiniciarse cuando se añade un nuevo nodo.