Solución de problemas de Azure Container Storage
Azure Container Storage es un servicio de administración, implementación y orquestación de volúmenes basado en la nube creado de forma nativa para contenedores. Use este artículo para solucionar problemas comunes con Azure Container Storage y encontrar soluciones a los problemas.
Solucionar problemas de instalación
Azure Container Storage no se puede instalar debido a la falta de configuración
Después de ejecutar az aks create, es posible que vea el mensaje Azure Container Storage no se pudo instalar. Se ha creado el clúster de AKS. Ejecute az aks update junto con --enable-azure-container-storage para habilitar el Almacenamiento de contenedores de Azure.
Este mensaje significa que no se ha instalado el Almacenamiento de contenedores de Azure, pero el clúster de AKS (Azure Kubernetes Service) se ha creado correctamente.
Para instalar Azure Container Storage en el clúster y crear un grupo de almacenamiento, ejecute el siguiente comando. Reemplace <cluster-name> y <resource-group> con sus propios valores. Reemplace <storage-pool-type> por azureDisk, ephemeraldisk o elasticSan.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
Azure Container Storage no se puede instalar debido a restricciones de Azure Policy
Es posible que Azure Container Storage no se instale si se aplican restricciones de Azure Policy. Específicamente, el Almacenamiento de contenedores de Azure se basa en contenedores con privilegios. Puede configurar Azure Policy para bloquear los contenedores con privilegios. Cuando se bloquean, la instalación de Almacenamiento de contenedores de Azure puede agotar el tiempo de espera o producir un error, y es posible que vea errores en los registros de gatekeeper-controller, por ejemplo:
$ kubectl logs -n gatekeeper-system deployment/gatekeeper-controller
...
{"level":"info","ts":1722622443.9484184,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: prereq, securityContext: {\"privileged\": true, \"runAsUser\": 0}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-prereq-gt58x","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622443.9839077,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: metrics-exporter, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-metrics-exporter-286np","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0515249,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: csi-node, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-csi-node-7hcd7","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0729053,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: io-engine, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-io-engine-84hwx","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0742755,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-x6q5n","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622449.2412128,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-b5nfg","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
Para resolver los bloqueos, deberá agregar el espacio de nombres acstor a la lista de exclusión de Azure Policy. Azure Policy se usa para crear y aplicar reglas para administrar recursos en Azure, incluidos los clústeres de AKS. En algunos casos, las directivas podrían bloquear la creación de pods y componentes de Azure Container Storage. Para más información sobre cómo trabajar con Azure Policy para Kubernetes, consulte Azure Policy para Kubernetes.
Para agregar el espacio de nombres acstor a la lista de exclusión, siga estos pasos:
- Creación del clúster de Azure Kubernetes.
- Habilite Azure Policy para AKS.
- Cree una directiva que sospeche que está bloqueando la instalación de Azure Container Storage.
- Intente instalar Azure Container Storage en el clúster de AKS.
- Compruebe los registros del pod gatekeeper-controller para confirmar cualquier infracción de directiva.
- Agregue los espacios de nombres
acstoryazure-extensions-usage-systema la lista de exclusión de la directiva. - Vuelva a intentar instalar Azure Container Storage en el clúster de AKS.
No se puede instalar ni habilitar el Almacenamiento de contenedores de Azure en grupos de nodos con intolerancias
Puede configurar intolerancias de nodo en los grupos de nodos para restringir la programación de pods en estos grupos de nodos. Es posible que se bloquee la instalación y habilitación del Almacenamiento de contenedores de Azure en estos grupos de nodos porque no se pueden crear los pods necesarios en estos grupos de nodos. El comportamiento se aplica al grupo de nodos del sistema en la instalación y a los grupos de nodos de usuario en la habilitación.
Puede comprobar las intolerancias de nodo con el ejemplo siguiente:
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
Puede quitar estas intolerancias temporalmente para desbloquearlas y configurarlas de nuevo después de instalarlas y habilitarlas correctamente. Puede ir a Azure Portal > clúster de AKS > grupos de nodos, hacer clic en el grupo de nodos y quitar las intolerancias en la sección "Intolerancias y etiquetas". O bien, puede usar el siguiente comando para quitar las intolerancias y confirmar el cambio.
$ az aks nodepool update -g $resourceGroup --cluster-name $clusterName --name $nodePoolName --node-taints ""
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": null
}
]
Vuelva a intentar la instalación o habilitación después de quitar las intolerancias de nodo correctamente. Una vez completado correctamente, puede volver a configurar las intolerancias de nodo para reanudar las restricciones de programación de pods.
No se puede establecer el tipo de grupo de almacenamiento en NVMe
Si intenta instalar Azure Container Storage con disco efímero, concretamente con NVMe local en un clúster en el que la SKU de la máquina virtual (VM) no tiene unidades NVMe, obtendrá el siguiente mensaje de error: No se puede establecer la opción --storage-pool-option como NVMe, ya que ninguno de los grupos de nodos puede admitir discos NVMe efímeros.
Para corregirlo, cree un grupo de nodos con una SKU de máquina virtual que tenga unidades NVMe e inténtelo de nuevo. Consulte máquinas virtuales optimizadas para almacenamiento.
Solución de problemas del bloque de almacenamiento
Para comprobar el estado de los grupos de almacenamiento, ejecute kubectl describe sp <storage-pool-name> -n acstor. Estos son algunos problemas que podrían surgir.
El grupo de almacenamiento efímero no reclama la capacidad cuando otros daemonsets usan los discos efímeros.
La habilitación de un grupo de almacenamiento efímero en un grupo de nodos con discos SSD temporales o NVMe local podría no reclamar capacidad de estos discos si otros daemonsets los usan.
Ejecute los pasos siguientes para habilitar el Almacenamiento de contenedores de Azure para administrar estos discos locales de forma exclusiva:
Ejecute el siguiente comando para ver la capacidad reclamada por el grupo de almacenamiento efímero:
$ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 0 0 0 0 False 82sEn este ejemplo, se muestra la capacidad cero reclamada por el grupo de almacenamiento
ephemeraldisk-nvme.Ejecute el siguiente comando para confirmar el estado no reclamado de estos dispositivos de bloques locales y comprobar el sistema de archivos existente en los discos:
$ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Unclaimed Active 22m acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Unclaimed Active 23m $ kubectl describe bd -n acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff Name: blockdevice-1f7ad8fa32a448eb9768ad8e261312ff … Filesystem: Fs Type: ext4 …En este ejemplo, se muestra que los dispositivos de bloques están en estado
Unclaimedy hay un sistema de archivos existente en el disco.Confirme que desea usar el Almacenamiento de contenedores de Azure para administrar los discos de datos locales de forma exclusiva antes de continuar.
Detenga y quite los daemonsets o componentes que administran los discos de datos locales.
Inicie sesión en cada nodo que tenga discos de datos locales.
Quite los sistemas de archivos existentes de todos los discos de datos locales.
Reinicie el daemonset para detectar discos de datos locales sin usar.
$ kubectl rollout restart daemonset -l app=ndm -n acstor daemonset.apps/azurecontainerstorage-ndm restarted $ kubectl rollout status daemonset -l app=ndm -n acstor --watch … daemon set "azurecontainerstorage-ndm" successfully rolled outEspere unos segundos y compruebe si el grupo de almacenamiento efímero reclama la capacidad de los discos de datos locales.
$ kubectl wait -n acstor sp --all --for condition=ready storagepool.containerstorage.azure.com/ephemeraldisk-nvme condition met $ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Claimed Active 4d16h acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Claimed Active 4d16h $ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 3840766820352 3812058578944 28708241408 26832871424 True 4d16hEn este ejemplo, se muestra que el grupo de almacenamiento
ephemeraldisk-nvmereclama correctamente la capacidad de los discos NVMe locales de los nodos.
Error al intentar expandir un grupo de almacenamiento de Azure Disks
Si el grupo de almacenamiento existente es inferior a 4 TiB (4096 GiB), solo puede expandirlo hasta 4095 GiB. Si intenta expandir más allá del límite, el PVC interno muestra un mensaje de error sobre las limitaciones del tamaño del disco o el tipo de almacenamiento en caché. Detenga la máquina virtual o desconecte el disco y vuelva a intentar la operación".
Para evitar errores, no intente expandir el grupo de almacenamiento actual más allá de 4095 GiB si era inicialmente menor que 4 TiB (4096 GiB). Los grupos de almacenamiento mayores de 4 TiB se pueden ampliar hasta la capacidad de almacenamiento máxima disponible.
Esta limitación solo se aplica al usar SKU de disco Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS y StandardSSD_ZRS.
Se produce un error en la creación de Elastic SAN
Si intenta crear un grupo de almacenamiento de Elastic SAN, es posible que vea el mensaje Error al crear Azure Elastic SAN: número máximo posible de Elastic SAN para la suscripción ya creada. Esto significa que ha alcanzado el límite en el número de recursos de Elastic SAN que se pueden implementar en una región por suscripción. Puede comprobar el límite aquí: Objetivos de escalabilidad y rendimiento de Elastic SAN. Considere la posibilidad de eliminar los recursos de Elastic SAN existentes en la suscripción que ya no se usen o intente crear el grupo de almacenamiento en otra región.
No se encontró ningún dispositivo de bloqueo
Si ve este mensaje, es probable que intente crear un grupo de almacenamiento de disco efímero en un clúster en el que la SKU de máquina virtual no tenga unidades NVMe.
Para corregirlo, cree un grupo de nodos con una SKU de máquina virtual que tenga unidades NVMe e inténtelo de nuevo. Consulte máquinas virtuales optimizadas para almacenamiento.
Tipo de grupo de almacenamiento ya habilitado
Si intenta habilitar un tipo de grupo de almacenamiento que existe, recibirá el siguiente mensaje: Valor de --enable-azure-container-storage no válido. Azure Container Storage ya está habilitado para el tipo de grupo de almacenamiento <storage-pool-type> en el clúster. Puede comprobar si tiene algún grupo de almacenamiento existente creado mediante la ejecución de kubectl get sp -n acstor.
Deshabilitación de un tipo de bloque de almacenamiento
Al deshabilitar un tipo de grupo de almacenamiento a través de az aks update --disable-azure-container-storage <storage-pool-type> o desinstalar Azure Container Storage a través de az aks update --disable-azure-container-storage all, si hay un grupo de almacenamiento existente de ese tipo, recibirá el siguiente mensaje:
Deshabilitar el Almacenamiento de contenedores de Azure para el tipo de grupo de almacenamiento <storage-pool-type> elimina de forma forzada todos los grupos de almacenamiento del mismo tipo y afecta a las aplicaciones que usan estos grupos de almacenamiento. La eliminación forzada de los grupos de almacenamiento también puede provocar pérdidas de recursos de almacenamiento que se consumen. ¿Desea validar si alguno de los grupos de almacenamiento de tipo <storage-pool-type> se usa antes de deshabilitar Azure Container Storage? (S/n)
Si selecciona S, se ejecuta una validación automática para asegurarse de que no haya volúmenes persistentes creados a partir del grupo de almacenamiento. Al seleccionar n se omite esta validación y se desactiva el tipo de grupo de almacenamiento, eliminando cualquier grupo de almacenamiento existente y afectando potencialmente a su aplicación.
Solucionar problemas de volumen
Creación pendiente de pod debido a que el tamaño del volumen efímero está por encima de la capacidad disponible
Se asigna un volumen efímero en un solo nodo. Al configurar el tamaño de los volúmenes efímeros para los pods, el tamaño debe ser menor que la capacidad disponible del disco efímero de un solo nodo. De lo contrario, la creación del pod está en estado pendiente.
Use el comando siguiente para comprobar si la creación del pod está en estado pendiente.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
En este ejemplo, el pod fiopod está en estado Pending.
Use el siguiente comando para comprobar si el pod tiene el evento de advertencia para la creación de una notificación de volumen persistente.
$ kubectl describe pod fiopod
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s default-scheduler 0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..
En este ejemplo, el pod muestra el evento de advertencia al crear una notificación de volumen persistente fiopod-ephemeralvolume.
Use el siguiente comando para comprobar si la notificación de volumen persistente no se puede aprovisionar debido a una capacidad insuficiente.
$ kubectl describe pvc fiopod-ephemeralvolume
...
Warning ProvisioningFailed 107s (x13 over 20m) containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")
En este ejemplo, Insufficient Storage se muestra como el motivo del error de aprovisionamiento de volúmenes.
Ejecute el siguiente comando para comprobar la capacidad disponible del disco efímero de un solo nodo.
$ kubectl get diskpool -n acstor
NAME CAPACITY AVAILABLE USED RESERVED READY AGE
ephemeraldisk-temp-diskpool-jaxwb 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-wzixx 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-xbtlj 75660001280 75031990272 628011008 560902144 True 21h
En este ejemplo, la capacidad disponible del disco temporal para un solo nodo es de 75031990272 bytes o 69 GiB.
Ajuste el tamaño de almacenamiento del volumen por debajo de la capacidad disponible y vuelva a implementar el pod. Consulte Implementación de un pod con un volumen efímero genérico
El volumen no se puede adjuntar debido a que el almacén de metadatos está sin conexión
Almacenamiento de contenedores de Azure usa etcd, un almacén distribuido y confiable de clave-valor, para almacenar y administrar metadatos de volúmenes para admitir operaciones de orquestación de volúmenes. Para lograr alta disponibilidad y resistencia, etcd se ejecuta en tres pods. Cuando hay menos de dos instancias de etcd en ejecución, el Almacenamiento de contenedores de Azure detiene las operaciones de orquestación de volúmenes al tiempo que permite el acceso a los datos de los volúmenes. Almacenamiento de contenedores de Azure detecta automáticamente cuándo una instancia etcd está sin conexión y la recupera. Sin embargo, si observa errores de orquestación de volúmenes después de reiniciar un clúster de AKS, es posible que una instancia de etcd no se pueda recuperar automáticamente. Siga las instrucciones de esta sección para determinar el estado de mantenimiento de las instancias etcd.
Ejecute el comando siguiente para obtener una lista de pods.
kubectl get pods
Es posible que vea una salida similar a la siguiente.
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
Descripción del pod:
kubectl describe pod fiopod
Normalmente, verá mensajes de error de volumen si el almacén de metadatos está sin conexión. En este ejemplo, fiopodestá en estado ContainerCreating y la advertencia FailedAttachVolume indica que la creación está pendiente debido a un error de asociación del volumen.
Name: fiopod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009
Warning FailedAttachVolume 3m8s (x6 over 23m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
También puede ejecutar el siguiente comando para comprobar el estado de las instancias etcd:
kubectl get pods -n acstor | grep "^etcd"
Debería ver una salida similar a la siguiente, con todas las instancias en estado En ejecución:
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
Si se hay menos de dos instancias en ejecución, el volumen no se asocia porque el almacén de metadatos está sin conexión y se produce un error en la recuperación automatizada. En ese caso, abra una incidencia de soporte técnico con el Soporte técnico de Azure.