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
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
Actualice el plugin de CSI y utilice el StorageClass
alicloud-disk-topology-alltype, o bien cree un StorageClass personalizado con varios tipos de discos en la nube. Consulte Use a dynamically provisioned disk volume.Agregue varias zonas al clúster. Consulte High-availability configuration recommendations for disk volumes.
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
Actualice el plugin de CSI y utilice el StorageClass
alicloud-disk-topology-alltype, o bien cree un StorageClass personalizado con varios tipos de discos en la nube. Consulte Use a dynamically provisioned disk volume.Agregue varias zonas al clúster. Consulte High-availability configuration recommendations for disk volumes.
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
nodeNameen 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ónWaitForFirstConsumer.Ningún pod hace referencia al PVC actual.
Solución
Elimine el campo
nodeNamedel 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-XXXXno 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
-
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_PORTal 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.
-
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
La versión del clúster y la versión del plugin de CSI no coinciden.
El clúster utiliza el plugin de almacenamiento FlexVolume.
Solución
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.
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.
Para conocer los rangos de capacidad por tipo de disco, consulte Block storage performance.
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.
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
driversea correcto y no tenga errores tipográficos. Un nombre dedriverincorrecto 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
fsGroupChangePolicyenOnRootMismatch. 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ámetrofsGroupChangePolicy, consulte Configure a Security Context for a Pod or Container. Si esto no basta, utilice uninitContainerpara 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.
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:
Espere a que el plugin de CSI reintente automáticamente. Una vez que finalicen las demás tareas de ECS, el montaje se completa correctamente.
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:
-
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.
-
Inicie sesión en el host del pod y ejecute
fsck -y /dev/xxxxxpara reparar el sistema de archivos.Reemplace
/dev/xxxxxcon 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_PERNODEdel 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.
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_PERNODEdel 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.
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.
-
Agregue las siguientes etiquetas durante la creación (no pueden agregarse después):
createdByProduct:efloattachToHpnZone:XX(reemplaceXXcon el valor real deHpnZone. Puede ejecutar un comando para query nodes y obtener el HpnZone).
Consulte Create an empty data disk.
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.
Identifique el PVC a partir de la definición
VolumeMountdel pod para el directorio de montaje afectado.Ejecute
kubectl get pvc <pvc-name>para comprobar el estado del PVC y anote el PV vinculado.Obtenga el ID del disco en la nube desde el campo
volumeHandleen el YAML del PV.-
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.
NotaEl 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 reviseUsedBypara confirmarlo. -
Si no se encuentra el disco en la nube, se liberó y no es posible recuperarlo.
ImportanteAl 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.
-
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
fsGroupChangePolicyenOnRootMismatch. 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 uninitContainerpara 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.
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 seatrue. 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
storageClassNameen 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
allowVolumeExpansionestá establecido enfalse. Por lo tanto, no se admite la expansión.
Solución
Solución para la causa 1: Revise la configuración de
storageClassNamedel 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 configureallowVolumeExpansion: true.Solución para la causa 2: Las StorageClass son inmutables. Cree una nueva StorageClass con el parámetro
allowVolumeExpansionestablecido entrue. 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
podManagementPolicydel StatefulSet a OrderedReady o elimine el campopodManagementPolicy: "Parallel".-
Para clústeres pequeños:
Marque el nodo del pod como no programable con
cordon.Elimine el pod y espere a que su estado cambie a Pending.
Quite el
cordondel 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
-
Busque el dispositivo de bloque bajo la ruta de montaje correspondiente.
mount | grep <mount-path> /dev/vdtest <mount-path> -
Obtenga el ID del proceso que utiliza el dispositivo de bloque.
fuser -m /dev/vdtest -
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
reclaimPolicydel PV esRetain, 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
reclaimPolicyse establece enRetain, 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
-
Consulte los pods que hacen referencia al PVC.
kubectl describe pvc <pvc-name> -n kube-system 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 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 campovolumeHandlecontiene dicho ID.