你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 容器存储排除故障
Azure 容器存储是一项基于云的卷管理、部署和业务流程服务，专为容器原生构建。 使用本文排查 Azure 容器存储的常见问题，并查找问题的解决方法。
安装问题疑难解答
Azure 容器存储安装失败
运行 az aks create 后，可能会看到“Azure 容器存储安装失败。AKS 群集已创建。请运行 az aks update 和 --enable-azure-container-storage 来启用 Azure 容器存储”消息。
此消息表示未安装 Azure 容器存储，但已正确创建你的 AKS 群集。
若要再群集上安装 Azure 容器存储和创建存储池，请运行以下命令。 将 <cluster-name> 和 <resource-group> 替换为自己的值。 将 <storage-pool-type> 替换为 azureDisk、ephemeraldisk 或 elasticSan。
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
无法将存储池类型设置为 NVMe
如果尝试使用临时磁盘安装 Azure 容器存储，特别是虚拟机 (VM) SKU 没有 NVMe 驱动器的群集上的本地 NVMe，你会收到以下错误消息：无法将 --storage-pool-option 设置为 NVMe，因为节点池均不支持临时 NVMe 磁盘。
若要修正，请使用具有 NVMe 驱动器的 VM SKU 创建节点池，然后重试。 请参阅存储优化 VM。
排查存储池问题
若要检查存储池的状态，请运行 kubectl describe sp <storage-pool-name> -n acstor。 下面是可能会遇到的一些问题。
尝试扩展 Azure 磁盘存储池时出错
如果现有存储池小于 4 TiB (4,096 GiB)，则最多只能将其扩展到 4,095 GiB。 如果尝试扩展到更大的容量，内部 PVC 将收到一条错误消息，内容类似于“对于大小超过 4095 GB 的磁盘，只支持磁盘缓存类型‘无’”或“大小为 4096 GB (<=4096 GB) 的磁盘‘xxx’在附加到正在运行的 VM 时无法将其大小调整为 16384 GB (>4096 GB)。 请停止 VM 或分离磁盘，然后重试该操作”。
为了避免错误，如果当前存储池最初小于 4 TiB (4,096 GiB)，请不要尝试将其扩展到 4,095 GiB 以上。 容量大于 4 TiB 的存储池可以扩展到可用的最大存储容量。
此限制仅适用于使用 Premium_LRS、Standard_LRS、StandardSSD_LRS、Premium_ZRS 和 StandardSSD_ZRS 磁盘 SKU 时。
弹性 SAN 创建失败
如果尝试创建弹性 SAN 存储池，可能会看到“Azure 弹性 SAN 创建失败: 已创建的订阅的最大弹性 SAN 数”消息。 这意味着，你已达到每个订阅可在一个区域中部署的弹性 SAN 资源数限制。 可在此处查看限制：弹性 SAN 可伸缩性和性能目标。 请考虑删除不再使用的订阅上的所有现有弹性 SAN 资源，或者尝试在其他区域中创建存储池。
找不到块设备
如果看到此消息，则表示你可能尝试在 VM SKU 没有 NVMe 驱动器的群集上创建临时磁盘存储池。
若要修正，请使用具有 NVMe 驱动器的 VM SKU 创建节点池，然后重试。 请参阅存储优化 VM。
已启用存储池类型
如果尝试启用已启用的存储池类型，将收到“--enable-azure-container-storage 值无效。已在群集中为存储池类型 <storage-pool-type> 启用 Azure 容器存储”消息。 可运行 kubectl get sp -n acstor 来检查现在是否已经创建了任何存储池。
禁用存储池类型
通过 az aks update --disable-azure-container-storage <storage-pool-type> 禁用存储池类型或通过 az aks update --disable-azure-container-storage all 卸载 Azure 容器存储时，如果现在有该类型的存储池，你会收到以下消息：
如果禁用存储池类型 <storage-pool-type> 的 Azure 容器存储，将强制删除同一类型的所有存储池，并对使用这些存储池的应用程序产生影响。 强制删除存储池还可能导致正在使用的存储资源泄漏。 是否要在禁用 Azure 容器存储之前验证是否使用了 <storage-pool-type> 类型的存储池？ （是/否）
如果选择“是”，则运行自动验证来确保没有从存储池创建的永久性卷。 如果选择“否”，会绕过此验证并禁用存储池类型，从而删除任何现有存储池并可能影响应用程序。
无法删除包含 AKS 群集的资源组
如果创建了弹性 SAN 存储池，可能无法删除 AKS 群集所在的资源组。
为了解决此问题，请登录到 Azure 门户，然后选择“资源组”。 找到 AKS 创建的资源组（资源组名称以 MC_ 开头）。 选择该资源组中的 SAN 资源对象。 手动删除所有卷和卷组。 然后重试删除包含 AKS 群集的资源组。
排查卷的问题
由于临时卷大小超出可用容量，Pod 创建处于挂起状态
在单个节点上分配临时卷。 为 Pod 配置临时卷的大小时，大小应小于单个节点临时磁盘的可用容量。 否则，Pod 创建将处于挂起状态。
使用以下命令检查 Pod 创建是否处于挂起状态。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
在此示例中，pod fiopod 处于“Pending”状态。
使用以下命令检查 Pod 是否具有关于创建 persistentvolumeclaim 的警告事件。
$ 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..
在此示例中，Pod 显示有关创建永久性卷声明 fiopod-ephemeralvolume 的警告事件。
使用以下命令检查永久性卷声明是否由于容量不足而无法预配。
$ 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 }'")
在此示例中，Insufficient Storage 显示为卷配置失败的原因。
运行以下命令，检查单个节点临时磁盘的可用容量。
$ 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
在此示例中，单个节点临时磁盘的可用容量为 75031990272 字节或 69 GiB。
将卷存储大小调整到可用容量以下，然后重新部署Pod。 请参阅使用通用临时卷部署 Pod。
由于元数据存储脱机，卷无法附加
Azure 容器存储使用 etcd（一种分布式、可靠的键值存储）来存储和管理卷的元数据，以支持卷编排操作。 为了获得高可用性和复原能力，可在三个 Pod 中运行 etcd。 当运行的 etcd 实例少于两个时，Azure 容器存储将停止卷编排操作，但仍允许数据访问卷。 Azure 容器存储会自动检测 etcd 实例是否离线，并将其恢复。 但是，如果在重启 AKS 群集后发现卷编排错误，则可能是 etcd 实例未能自动恢复。 按照本节中的说明确定 etcd 实例的运行状况。
运行以下命令以获取 Pod 列表。
kubectl get pods
将显示类似于下面的输出。
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
描述 Pod：
kubectl describe pod fiopod
通常情况下，如果元数据存储处于离线状态，则会看到卷故障消息。 在此示例中，fiopod 处于 ContainerCreating 状态，FailedAttachVolume 警告指示由于卷附加失败，创建正在等待中。
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
还可以运行以下命令来检查 etcd 实例的状态：
kubectl get pods -n acstor | grep "^etcd"
应会看到类似于以下内容的输出，其中所有实例都处于“正在运行”状态：
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
如果“正在运行”状态下显示的实例少于两个，则可以断定卷由于元数据存储处于离线状态而无法附加，且自动恢复未成功。 如果是这种情况，请向 Azure 支持部门提交支持工单。