Todos los productos
Search
Centro de documentos

Container Service for Kubernetes:Disk volume FAQ

Última actualización: Sep 21, 2026

Resuelva problemas de creación, montaje, expansión y desmontaje de volúmenes de disco en clústeres de ACK.

Navegación por las preguntas frecuentes

Tipo

Problema

Creación

Montaje

Uso

Expansión

Desmontaje

Otros

Creación

Error al crear un PV dinámico: InvalidDataDiskCatagory.NotSupported

Síntoma

La creación del PV falla con errores y un evento del PVC muestra el mensaje de error InvalidDataDiskCategory.NotSupported.

Causa

El StorageClass especifica un tipo de disco en la nube que no está disponible en la zona actual o cuyo inventario es insuficiente.

Solución

Error al crear un PV dinámico: inventario insuficiente en AZone

Síntoma

La creación del PV falla con errores y un evento del PVC muestra el mensaje de error The specified AZone inventory is insufficient.

Causa

La creación del disco en la nube falla porque el inventario de la zona especificada es insuficiente.

Solución

Error al crear un PV dinámico: tamaño de disco no compatible

Síntoma

La creación dinámica del PV falla con errores y un evento del PVC muestra el mensaje de error disk size is not supported.

Causa

El PVC especifica una capacidad no válida. Los límites mínimos varían según cloud disk type.

Solución

Ajuste la capacidad declarada en el PVC a un valor compatible.

Error al crear un PV dinámico: esperando al primer consumidor

Síntoma

La creación del PV falla cuando se usa un StorageClass con el modo de vinculación WaitForFirstConsumer. Además, un evento del PVC muestra el mensaje de error persistentvolume-controller waiting for first consumer to be created before binding.

Causa

El PVC no ha detectado el nodo donde se programó el pod.

  • Si establece explícitamente nodeName en el YAML de la aplicación, el pod omite el programador. Esto impide que el PVC descubra el nodo y lo hace incompatible con el modo de vinculación WaitForFirstConsumer.

  • Ningún pod hace referencia al PVC actual.

Solución

  • Elimine el campo nodeName del archivo YAML de la aplicación y utilice otro método de programación.

  • Cree un pod que utilice el PVC actual.

Error al crear un PV dinámico: falta la clave de topología en CSINode

Síntoma

La creación del PV falla con errores y un evento del PVC muestra el mensaje de error no topology key found on CSINode node-XXXX.

Causa

  • Causa 1: el plugin de CSI en el nodo correspondiente node-XXXX no logra iniciar.

  • Causa 2: se utiliza para el montaje un controlador que el sistema no admite. De forma predeterminada, el sistema admite los controladores Disk, NAS y OSS.

Solución

  1. Compruebe el estado del pod.

    kubectl get pods -n kube-system -o wide | grep node-XXXX
    • Si el estado es anómalo, revise los registros de error con kubectl logs csi-plugin-xxxx -nkube-system -c csi-plugin. Por lo general, esto se debe a un conflicto de puertos en el nodo. Resuélvalo de la siguiente manera:

      • Finalice el proceso que ocupa el puerto.

      • Agregue la variable de entorno SERVICE_PORT al plugin de CSI para especificar un nuevo puerto.

        kubectl set env -n kube-system daemonset/csi-plugin --containers="csi-plugin" SERVICE_PORT="XXX"
    • Si el estado es normal, continúe con el siguiente paso.

  2. Utilice un controlador predeterminado del sistema, como Disk, NAS u OSS. Consulte la documentación de Storage.

Error al crear un PV dinámico: selfLink vacío

Síntoma

La creación del PV falla con errores y un evento del PVC muestra el mensaje de error selfLink was empty, can't make reference.

Causa

  1. La versión del clúster y la versión del plugin de CSI no coinciden.

  2. El clúster utiliza el plugin de almacenamiento FlexVolume.

Solución

  1. Actualice la versión del plugin de CSI. La versión del plugin debe ser compatible con la versión del clúster. Por ejemplo, un clúster de Kubernetes 1.20 requiere la versión 1.20 o posterior de CSI.

  2. Si su clúster utiliza el plugin de almacenamiento FlexVolume, consulte Migrate from FlexVolume to CSI.

Error al crear un PV dinámico: capacidad del PVC < 20 GiB

Los StorageClass predeterminados de ACK (por ejemplo, alicloud-disk-topology-alltype y alicloud-disk-essd) requieren una capacidad mínima de 20 GiB. Para volúmenes más pequeños, cree un StorageClass personalizado con un tipo de disco que admita menor capacidad, como ESSD AutoPL o ESSD PL0.

Montaje

Error al iniciar el pod: conflicto de afinidad de nodo del volumen

Síntoma

Un pod con un disco en la nube montado no logra iniciar y un evento del pod muestra el mensaje de error had volume node affinity conflict.

Causa

Todos los PV tienen la propiedad nodeaffinity. Este error ocurre cuando la propiedad nodeaffinity del PV entra en conflicto con la propiedad nodeaffinity del pod, lo que impide la programación.

Solución

Asegúrese de que la propiedad nodeaffinity del PV y la propiedad nodeaffinity del pod sean coherentes.

Error al iniciar el pod: no se encuentra el disco

Síntoma

Un pod con un disco en la nube montado no logra iniciar y un evento del pod muestra el mensaje de error can't find disk.

Causa

  • Configuró el PV con un identificador de disco en la nube incorrecto o con uno perteneciente a otra región.

  • Su cuenta carece del permiso para acceder al disco en la nube, posiblemente porque pertenece a otra cuenta.

Solución

  • Si utiliza un disco en la nube aprovisionado de forma estática, compruebe que cumpla los siguientes requisitos:

    • La región del disco en la nube coincide con la región del clúster.

    • El identificador del disco en la nube es correcto.

    • El disco en la nube y el clúster pertenecen a la misma cuenta de Alibaba Cloud.

  • Si el disco en la nube se monta de forma dinámica, compruebe los permisos del plugin de CSI.

    Compruebe si existe un Addon Token en el clúster.

    • Si existe un Addon Token, compruebe la versión del plugin de CSI en el clúster, actualice el plugin a la versión más reciente e inténtelo de nuevo.

    • Si no existe un Addon Token, se utiliza de forma predeterminada la AccessKey personalizada del rol de RAM worker del nodo. En este caso, debe comprobar los permisos de la política de RAM correspondiente.

Error al iniciar el pod: acción de adjuntar en curso

Síntoma

Un pod con un disco en la nube montado muestra Previous attach action is still in process, pero inicia correctamente después de unos segundos.

Causa

Las instancias de ECS adjuntan un disco en la nube a la vez. Cuando varios pods respaldados por discos se ubican en el mismo host, los discos se adjuntan de forma secuencial. Este mensaje indica que hay otra operación de adjuntar en curso.

Solución

No se requiere ninguna acción. El sistema reintenta automáticamente.

Error al iniciar el pod: InvalidInstanceType.NotSupportDiskCategory

Síntoma

Al iniciar un pod con un disco en la nube montado, se muestra el mensaje de error InvalidInstanceType.NotSupportDiskCategory.

Causa

El pod se programa en un nodo de ECS cuyo tipo de instancia no admite este tipo de disco en la nube.

Solución

Pruebe una de las siguientes opciones:

  • Compruebe que el clúster tenga un nodo de ECS cuyo tipo de instancia admita este tipo de disco en la nube y que el pod pueda programarse en él.

  • Si ningún tipo de instancia de nodo admite este tipo de disco en la nube, cambie a un tipo de disco compatible.

Nota

Para conocer la compatibilidad entre discos en la nube y tipos de instancia, consulte Instance families.

Error al iniciar el pod: controlador de CSI no registrado

Síntoma

Al iniciar un pod, se muestra la siguiente advertencia.

Warning  FailedMount       98s (x9 over 3m45s)  kubelet, cn-zhangjiakou.172.20.XX.XX  MountVolume.MountDevice failed for volume "d-xxxxxxx" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name diskplugin.csi.alibabacloud.com not found in the list of registered CSI drivers

Causa

  • Esto suele ocurrir en nodos nuevos, donde el pod de la aplicación intenta montar un volumen antes de que el plugin de CSI termine de registrarse durante su inicio simultáneo.

  • El plugin de CSI en el nodo no logró registrarse, posiblemente debido a un error de inicio.

Solución

  • En un nodo recién agregado, no se requiere ninguna acción. El sistema reintenta automáticamente.

  • Si el plugin de CSI no logra registrarse, compruebe su estado y sus registros. Si el plugin funciona con normalidad, únase al grupo de usuarios de DingTalk (ID: 35532895) para obtener asistencia.

Error al iniciar el pod: error Multi-Attach

Síntoma

Un pod que monta un disco en la nube muestra warning failedAttachVolume xxx xxx Multi-Attach error for volume "xxx" en los eventos. Al ejecutar kubectl describe pvc <pvc-name>, se observa que varios pods hacen referencia al mismo PVC.

Causa

  • Causa 1: sin la función multi-attach habilitada, un disco en la nube solo puede montarse en un pod.

  • Causa 2: se eliminó el pod que usaba el PVC, pero el disco en la nube no se desmontó correctamente.

    En la consola de ECS, busque el nodo al que está adjunto el disco en la nube del PVC. Revise los registros del pod del plugin de CSI en ese nodo. Si aparece Path is mounted, no remove: /var/lib/kubelet/plugins/kubernetes.io/csi/diskplugin.csi.alibabacloud.com/xxx/globalmount, compruebe que el plugin de CSI monte directamente el HostPath /var/run:

    kubectl get ds -n kube-system csi-plugin -ojsonpath='{.spec.template.spec.volumes[?(@.hostPath.path=="/var/run/")]}'

    Una salida con contenido confirma el problema.

Solución

  • Solución para la causa 1:

    Asegúrese de que solo un pod haga referencia al PVC.

  • Solución para la causa 2:

    Aplique manualmente un parche al archivo YAML del plugin de CSI:

    kubectl patch -n kube-system daemonset csi-plugin -p '
    spec:
      template:
        spec:
          containers:
            - name: csi-plugin
              volumeMounts:
                - mountPath: /host/var/run/efc
                  name: efc-metrics-dir
                - mountPath: /host/var/run/ossfs
                  name: ossfs-metrics-dir
                - mountPath: /host/var/run/
                  $patch: delete
          volumes:
            - name: ossfs-metrics-dir
              hostPath:
                path: /var/run/ossfs
                type: DirectoryOrCreate
            - name: efc-metrics-dir
              hostPath:
                path: /var/run/efc
                type: DirectoryOrCreate
            - name: fuse-metrics-dir
              $patch: delete'

Error al iniciar el pod: tiempo de espera agotado en el montaje

Síntoma

Inicia un pod con un volumen montado y un evento del pod muestra el mensaje de error Unable to attach or mount volumes: unmounted volumes=[xxx], unattached volumes=[xxx]: timed out waiting for the condition.

Causa

Este evento es un mensaje de error que reporta el kubelet. El kubelet comprueba periódicamente si los volúmenes que usan los pods en todos los nodos están listos (Ready). Si un volumen no está listo, se muestra el mensaje de error anterior.

Este evento indica que el montaje no se completó al momento de la comprobación. Posibles causas:

  • Causa 1: ocurrió un error de montaje, pero el evento detallado se sobrescribió. Solo queda el evento de error del kubelet.

  • Causa 2: el kubelet agota el tiempo de espera al recuperar configmap/serviceaccount defaulttoken. Se trata de un problema de red del nodo. Debe intentarlo de nuevo en otro nodo.

  • Causa 3: cuando se configura securityContext.fsGroup, el kubelet cambia de forma recursiva la propiedad de todos los archivos durante el montaje. Este proceso es lento en volúmenes con muchos archivos.

  • Causa 4: en volúmenes aprovisionados de forma estática, compruebe que el campo driver sea correcto y no tenga errores tipográficos. Un nombre de driver incorrecto impide que el volumen esté listo.

Solución

  • Solución para la causa 1: reinicie el pod mediante su eliminación. Busque y diagnostique el evento de error real.

  • Solución para la causa 2: reprograme el pod en otro nodo. Consulte Schedule an application to a specified node.

  • Solución para la causa 3: en clústeres con versión 1.20 o posterior, establezca fsGroupChangePolicy en OnRootMismatch. Esto limita los cambios recursivos de propiedad al primer montaje, cuando los permisos del directorio raíz difieren, y normaliza el tiempo de montaje en los reinicios posteriores del pod. Para obtener más información sobre el parámetro fsGroupChangePolicy, consulte Configure a Security Context for a Pod or Container. Si esto no basta, utilice un initContainer para ajustar los permisos.

  • Solución para la causa 4: compruebe y especifique el nombre correcto del controlador. Ejemplos:

    • diskplugin.csi.alibabacloud.com

    • nasplugin.csi.alibabacloud.com

    • ossplugin.csi.alibabacloud.com

Error al iniciar el pod: formato de dispositivo no válido para NVMe

Síntoma

Un pod con un disco en la nube montado no logra iniciar y un evento del pod muestra el mensaje de error validate error Device /dev/nvme1n1 has error format more than one digit locations.

Causa

El nodo corresponde a un tipo de instancia basado en NVMe (como g7se, r7se, c7se o cualquier ECS de octava generación), pero las versiones del clúster y del plugin de CSI son demasiado antiguas para admitirlo.

Solución

Asegúrese de que su clúster de ACK tenga la versión 1.20 o posterior y actualice el plugin de CSI a la versión v1.22.9-30eb0ee5-aliyun o superior. Consulte Manage components.

Nota

El plugin FlexVolume no es compatible. Únase al grupo de usuarios de DingTalk (ID: 35532895) para obtener asistencia con la migración del plugin FlexVolume al plugin de CSI.

Error al iniciar el pod: conflicto de tareas de ECS

Síntoma

Un pod con un disco en la nube montado no logra iniciar y un evento del pod muestra el mensaje de error ecs task is conflicted.

Causa

Algunas tareas de ECS deben ejecutarse de forma secuencial. Cuando se envían varias solicitudes a ECS al mismo tiempo, se produce un error de conflicto de tareas.

Solución

Opciones de solución:

Error al iniciar el pod: sistema de archivos dañado

Síntoma

Un pod con un disco en la nube montado no logra iniciar y un evento del pod muestra el siguiente mensaje de error.

wrong fs type, bad option, bad superblock on /dev/xxxxx  missing codepage or helper program, or other error

Causa

El disco en la nube no puede montarse porque su sistema de archivos está dañado.

Solución

Por lo general, esto se debe a un desmontaje incorrecto. Para resolverlo:

  1. Compruebe que la aplicación cumpla estos requisitos:

    • Como máximo, un pod monta el mismo disco en la nube.

    • No escriba datos durante el proceso de separación del disco.

  2. Inicie sesión en el host del pod y ejecute fsck -y /dev/xxxxx para reparar el sistema de archivos.

    Reemplace /dev/xxxxx con la ruta del dispositivo que aparece en el evento del pod. La reparación modifica los metadatos del sistema de archivos. Si la reparación falla, el sistema de archivos queda dañado de forma permanente.

Error al iniciar el pod: se excedió el número máximo de volúmenes

Síntoma

Un pod con un disco en la nube montado permanece en Pending y no puede programarse, aunque el tipo de instancia de ECS permita adjuntar más discos:

0/1 nodes are available: 1 node(s) exceed max volume count.

Causa

La programación está limitada por la variable de entorno MAX_VOLUMES_PERNODE.

Solución

  • El plugin de CSI v1.26.4-e3de357-aliyun y versiones posteriores admiten la configuración automática del recuento de discos. Elimine la variable de entorno MAX_VOLUMES_PERNODE del DaemonSet del plugin de CSI en kube-system para habilitar la configuración automática según el tipo de instancia de ECS:

    kubectl patch -n kube-system daemonset csi-plugin -p '
    spec:
      template:
        spec:
          containers:
          - name: csi-plugin
            env:
            - name: MAX_VOLUMES_PERNODE
              $patch: delete'
  • Para versiones del plugin de CSI anteriores a v1.26.4-e3de357-aliyun, establezca manualmente esta variable de entorno según el nodo con la menor cantidad de discos de datos que puedan adjuntarse.

Importante
  • La configuración automática se ejecuta solo al iniciar el pod del plugin de CSI. Si adjunta o separa manualmente un disco de datos, vuelva a crear el pod del plugin de CSI en ese nodo para activarla de nuevo.

  • La configuración automática no toma en cuenta los volúmenes de disco aprovisionados de forma estática. Si existen, la cantidad de pods programables podría ser menor de lo esperado.

Error al iniciar el pod: se alcanzó el límite de discos de la instancia

Síntoma

Un pod con un disco en la nube montado permanece en ContainerCreating. Evento del pod:

MountVolume.MountDevice failed for volume "d-xxxx" : rpc error: code = Aborted desc = NodeStageVolume: Attach volume: d-xxxx with error: rpc error: code = Internal desc = SDK.ServerError
ErrorCode: InstanceDiskLimitExceeded
Message: The amount of the disk on instance in question reach its limits

Causa

El valor de la variable de entorno MAX_VOLUMES_PERNODE es demasiado alto.

Solución

  • El plugin de CSI v1.26.4-e3de357-aliyun y versiones posteriores admiten la configuración automática del recuento de discos. Elimine la variable de entorno MAX_VOLUMES_PERNODE del DaemonSet del plugin de CSI en kube-system para habilitar la configuración automática según el tipo de instancia de ECS:

    kubectl patch -n kube-system daemonset csi-plugin -p '
    spec:
      template:
        spec:
          containers:
          - name: csi-plugin
            env:
            - name: MAX_VOLUMES_PERNODE
              $patch: delete'
  • Para versiones del plugin de CSI anteriores a v1.26.4-e3de357-aliyun, establezca manualmente esta variable de entorno según el nodo con la menor cantidad de discos de datos que puedan adjuntarse.

Importante
  • La configuración automática se ejecuta solo al iniciar el pod del plugin de CSI. Si adjunta o separa manualmente un disco de datos, vuelva a crear el pod del plugin de CSI en ese nodo para activarla de nuevo.

  • La configuración automática no toma en cuenta los volúmenes de disco aprovisionados de forma estática. Si existen, la cantidad de pods programables podría ser menor de lo esperado.

Error OperationDenied.HpnZoneMismatch en nodos Lingjun

Al disco en la nube le falta la etiqueta attachToHpnZone:XX obligatoria para el nodo Lingjun. Esta etiqueta solo puede agregarse al crear el disco. Cree un nuevo disco en la nube con dicha etiqueta.

  1. Vaya a Consola de ECS - Block Storage - Disks.

  2. Agregue las siguientes etiquetas durante la creación (no pueden agregarse después):

    • createdByProduct:eflo

    • attachToHpnZone:XX (reemplace XX con el valor real de HpnZone. Puede ejecutar un comando para query nodes y obtener el HpnZone).

    Consulte Create an empty data disk.

  3. Elimine el PV y el PVC antiguos, y luego cree otros nuevos con el disco en la nube de reemplazo. Consulte Use a statically provisioned disk volume o Use a dynamically provisioned disk volume.

Cambiar la configuración predeterminada del StorageClass

El StorageClass predeterminado no puede modificarse.

Después de instalar csi-provisioner, se crea un StorageClass predeterminado (por ejemplo, alicloud-disk-topology-alltype). No modifique los StorageClass predeterminados. En su lugar, Create a new StorageClass con el tipo de volumen o la política de recuperación que prefiera.

Usar un solo volumen de disco para varias aplicaciones

Los discos en la nube proporcionan almacenamiento no compartido. Sin la función multi-attach habilitada, un disco en la nube solo puede montarse en un pod. Consulte Enable NVMe-based multi-attach for cloud disks and configure reservations.

Uso

Error de E/S de la aplicación en el volumen de disco

Síntoma

El disco en la nube se monta correctamente y la aplicación inicia. Sin embargo, poco después reporta un input/output error.

Causa

El disco en la nube que utiliza la aplicación se desmontó o se eliminó.

Solución

Compruebe el estado del disco en la nube y actúe según dicho estado.

  1. Identifique el PVC a partir de la definición VolumeMount del pod para el directorio de montaje afectado.

  2. Ejecute kubectl get pvc <pvc-name> para comprobar el estado del PVC y anote el PV vinculado.

  3. Obtenga el ID del disco en la nube desde el campo volumeHandle en el YAML del PV.

  4. En la página EBS de la consola de ECS, compruebe el estado del disco en la nube con base en su ID.

    • Si el disco en la nube aparece como Available, significa que se desmontó. Reinicie el pod para volver a montarlo.

      Nota

      El pod se encuentra en estado Running, lo que indica que el disco se montó y luego se desmontó. Esto suele deberse a que varios pods hacen referencia al mismo disco. Ejecute kubectl describe pvc <pvc-name> y revise UsedBy para confirmarlo.

    • Si no se encuentra el disco en la nube, se liberó y no es posible recuperarlo.

      Importante

      Al montar un ESSD, utilice instantáneas automáticas para proteger los datos del volumen de disco. Consulte Data loss due to unexpected cloud disk deletion.

Establecer permisos de usuario para el directorio de montaje

No es posible establecer permisos de acceso de usuario directamente en los discos en la nube. Si necesita definir estos permisos para un directorio de montaje, configure el securityContext del pod al crear la aplicación. Para obtener más información, consulte Configure Volume Permission and Ownership Change Policy for Pods.

Importante
  • Cuando configura securityContext.fsgroup, el kubelet modifica de forma recursiva los permisos de los archivos (chmod/chown) al montar un volumen. Este comportamiento aumenta considerablemente el tiempo de montaje en volúmenes con muchos archivos.

    Para clústeres de la versión 1.20 o posterior, se recomienda establecer fsGroupChangePolicy en OnRootMismatch. Esta opción optimiza el rendimiento de montaje, ya que aplica el cambio recursivo de permisos únicamente cuando el volumen se monta por primera vez y los permisos del directorio raíz no coinciden. Si el rendimiento sigue siendo un problema o requiere un control de permisos más detallado, utilice un initContainer para gestionar los permisos antes de que inicie el contenedor de la aplicación.

  • Cuando se reconstruye un pod, este vuelve a montar el disco en la nube original. Si otras restricciones impiden programar el pod en la zona original, permanecerá en estado Pending porque no puede montar el disco en la nube.

Expansión

Expansión automática de volúmenes de disco

Los volúmenes de disco no se expanden automáticamente. Para ampliarlos, actualice la capacidad de almacenamiento del PVC. Consulte Online expansion of disk volumes.

Si desea habilitar la expansión automática, utilice un CRD para ampliar los volúmenes cuando el uso supere un umbral determinado. Consulte Configure automatic expansion.

Nota

En clústeres anteriores a la versión 1.16, o cuando no se cumplen los requisitos de online expansion (por ejemplo, con discos básicos), amplíe el disco en la nube directamente desde la consola de ECS. Los recursos del clúster no se ven afectados; la capacidad del PVC y del PV conserva el tamaño previo a la expansión.

Error de expansión de disco: Waiting for user to restart pod

Síntoma

Después de actualizar la capacidad de almacenamiento del PVC, el campo StorageCapacity en el PVC Status no cambia y el evento del PVC reporta lo siguiente:

 Waiting for user to (re-)start a pod to finish file system resize of volume on node.

Causa

La expansión de un disco en la nube consta de dos pasos: primero se amplía la capacidad del disco mediante la API de ResizeDisk y luego se expande el sistema de archivos. Este error indica que el primer paso se completó, pero el segundo falló debido a un problema en el nodo.

Solución

Determine el tipo del nodo actual.

  • Si el nodo es ECI, ejecute kubectl get configmap -n kube-system eci-profile -o jsonpath="{.data.enablePVCController}" y compruebe que el valor sea true. Consulte eci-profile configuration parameters.

    Si el problema persiste, envíe un ticket para recibir asistencia.

  • Si el nodo es ECS, ejecute kubectl get pods -n kube-system -l app=csi-plugin --field-selector=spec.nodeName=<node-name> para comprobar el estado del plugin de CSI.

    • Si el plugin de CSI funciona correctamente, únase al grupo de usuarios de DingTalk (ID: 35532895) para recibir asistencia.

    • Si presenta anomalías, reinicie el pod del plugin de CSI y vuelva a intentarlo. Si el problema persiste, únase al grupo de usuarios de DingTalk (ID: 35532895) para recibir asistencia.

Error de expansión de disco: Static PVC or resize not allowed

Síntoma

Después de actualizar la capacidad de almacenamiento del PVC, se reporta el siguiente error:

only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize 

Causa

  • Causa 1: El PVC y el PV del volumen de disco se crearon manualmente de forma estática. No se especificó el parámetro storageClassName en el PVC, o bien no existe ninguna StorageClass con ese nombre en el clúster.

  • Causa 2: En la StorageClass a la que hace referencia el PVC, el parámetro allowVolumeExpansion está establecido en false. Por lo tanto, no se admite la expansión.

Solución

  • Solución para la causa 1: Revise la configuración de storageClassName del PVC y asegúrese de que exista una StorageClass con el mismo nombre en el clúster. De no ser así, cree la StorageClass correspondiente según las propiedades del volumen de disco existente y configure allowVolumeExpansion: true.

  • Solución para la causa 2: Las StorageClass son inmutables. Cree una nueva StorageClass con el parámetro allowVolumeExpansion establecido en true. Después, modifique el PVC para que haga referencia a esta nueva StorageClass antes de expandirlo.

Desmontaje

Error al eliminar el pod: Not a portable disk

Síntoma

Al desmontar un disco en la nube, se muestra el mensaje de error The specified disk is not a portable disk.

Causa

El método de facturación del disco en la nube es subscription. Esto ocurre al comprar un disco con suscripción o al convertir el método de facturación durante la actualización de una instancia de ECS.

Solución

Cambie el método de facturación del disco en la nube a pay-as-you-go.

Error al eliminar el pod: falla de desmontaje por un pod huérfano

Síntoma

El desmontaje de un pod falla y los registros del kubelet muestran un pod huérfano que ACK no gestiona.

Causa

El pod finalizó de manera anómala y dejó un punto de montaje de volumen huérfano. En versiones de Kubernetes anteriores a la 1.22, la recolección de elementos no utilizados de volúmenes del kubelet era incompleta, por lo que se requiere una limpieza manual.

Solución

Ejecute el siguiente script en el nodo afectado para limpiar los puntos de montaje residuales.

wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh
sh kubelet.sh

Error al reiniciar el pod: falla de montaje irrecuperable

Síntoma

Tras eliminarlo, el pod no se reinicia y reporta una falla de montaje irrecuperable:

Warning FailedMount 9m53s (x23 over 40m) kubelet MountVolume.SetUp failed for volume “xxxxx” : rpc error: code = Internal desc = stat /var/lib/kubelet/plugins/kubernetes.io/csi/pv/xxxxx/globalmount: no such file or directory

Alcance

  • La versión del clúster de ACK es 1.20.4-aliyun-1.

  • La aplicación utiliza un disco en la nube como medio de almacenamiento.

  • Se emplea un StatefulSet con la propiedad podManagementPolicy: "Parallel" configurada.

Causa

Consulte Pod fails to start after restarting rapidly.

Solución

  • Agregue nodos nuevos y elimine los antiguos. El pod con errores se recupera automáticamente. Consulte Create and manage node pools y Remove a node.

  • Cambie el podManagementPolicy del StatefulSet a OrderedReady o elimine el campo podManagementPolicy: "Parallel".

  • Para clústeres pequeños:

    1. Marque el nodo del pod como no programable con cordon.

    2. Elimine el pod y espere a que su estado cambie a Pending.

    3. Quite el cordon del nodo y espere a que el pod se reinicie.

  • En clústeres grandes, el pod se recupera en cuanto se programa en un nodo distinto.

Error al eliminar el pod: Target is busy

Síntoma

Al eliminar un pod, el evento del pod o el registro del kubelet (/var/log/messages) muestra lo siguiente:

unmount failed, output <mount-path> target is busy

Causa

Un proceso todavía utiliza el dispositivo. Inicie sesión en el host para identificar y finalizar dicho proceso.

Solución

  1. Busque el dispositivo de bloque bajo la ruta de montaje correspondiente.

    mount | grep <mount-path>
    /dev/vdtest <mount-path>
  2. Obtenga el ID del proceso que utiliza el dispositivo de bloque.

    fuser -m /dev/vdtest
  3. Finalice el proceso.

    El disco en la nube se desmonta automáticamente una vez que finaliza el proceso.

El disco en la nube permanece tras eliminar el PVC

Síntoma

Se elimina un PVC, pero el disco en la nube sigue apareciendo en la consola de ECS.

Causa

  • Causa 1: El reclaimPolicy del PV es Retain, por lo que el PV y el disco en la nube se conservan después de eliminar el PVC.

  • Causa 2: El PVC y el PV se eliminaron al mismo tiempo, o bien el PV se eliminó antes que el PVC.

Solución

  • Solución para la causa 1: Cuando reclaimPolicy se establece en Retain, CSI no elimina el PV ni el disco en la nube al borrar el PVC. Elimínelos manualmente.

  • Solución para la causa 2: Si un PV tiene una deleteTimestamp annotation, CSI no recupera el disco en la nube. Consulte controller. En su lugar, elimine el PVC; el PV vinculado se limpia automáticamente.

El PVC permanece después de eliminarlo

Síntoma

La eliminación del PVC falla incluso al usar la bandera --force.

Causa

Un pod todavía utiliza el PVC, por lo que su finalizer impide la eliminación.

Solución

  1. Consulte los pods que hacen referencia al PVC.

    kubectl describe pvc <pvc-name> -n kube-system
  2. Confirme que el pod que hace referencia ya no esté en uso, elimínelo y vuelva a intentar borrar el PVC.

Otros

Cambiar el método de facturación de un volumen a subscription

Los discos en la nube que se utilizan como volúmenes deben emplear facturación pay-as-you-go y no se pueden convertir a subscription.

Identificar el disco en la nube de un volumen en la consola de ECS

Obtenga el ID del disco en la nube (con formato d-********) y búsquelo en la página EBS de la consola de ECS para identificar los discos asociados.

  • En los PV creados dinámicamente, el nombre del PV coincide con el ID del disco en la nube. Consúltelo en la página Volumes > Persistent Volumes del clúster.

  • Si el nombre del PV no corresponde al ID del disco en la nube, ejecute kubectl get pv <pv-name> -o yaml. El campo volumeHandle contiene dicho ID.