本页面介绍了如何解决 Google Kubernetes Engine (GKE) 集群上的存储相关问题。
如果您需要其他帮助，请与 Cloud Customer Care 联系。错误 400：无法将 RePD 附加到优化虚拟机
区域永久性磁盘限制在内存优化机器或计算优化机器中使用。
若并非硬性要求，请考虑使用非区域永久性磁盘存储类别。若难以使用区域永久性磁盘，请考虑安排污点和容忍等策略，以确保需要区域永久性磁盘的 Pod 被调度到节点池非优化机器。
排查磁盘性能的问题
启动磁盘的性能非常重要，因为 GKE 节点的启动磁盘不仅用于操作系统，还用于以下用途：
- Docker 映像。
- 未作为卷装载的内容的容器文件系统（即叠加文件系统），通常包含
/tmp之类的目录。 - 磁盘支持的
emptyDir卷，除非节点使用本地固态硬盘。
节点上磁盘类型相同的所有磁盘的性能都是共享的。例如，如果您有一个 100 GB 的 pd-standard 启动磁盘和一个具有大量活动的 100 GB pd-standard PersistentVolume，则该启动磁盘的性能将为 200 GB 的磁盘。此外，如果 PersistentVolume 上有大量活动，这也会影响启动磁盘的性能。
如果您的节点上遇到如下所示的消息，这可能表示磁盘性能低：
INFO: task dockerd:2314 blocked for more than 300 seconds.
fs: disk usage and inodes count on following dirs took 13.572074343s
PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s
如需帮助解决此类问题，请查看以下内容：
- 确保您已查阅存储磁盘类型比较，并根据自己的需求选择永久性磁盘类型。
- 使用大小小于 200 GB 的标准永久性磁盘的节点通常会出现此问题。请考虑增加磁盘大小或切换到 SSD，尤其是对于生产环境中使用的集群。
- 考虑在节点池上为临时存储启用本地 SSD。如果您的容器经常使用
emptyDir卷，这种做法尤其有效。
由于 fsGroup 设置，装载卷停止响应
可能导致 PersistentVolume 装载失败的一个问题是 Pod 配置了 fsGroup 设置。通常，装载会自动重试，而且装载失败会自行解决。但是，如果 PersistentVolume 包含大量文件，kubelet 将尝试更改文件系统上每个文件的所有权，这可能会增加卷装载延迟时间。
Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition
如需确认装载失败错误是否是由 fsGroup 设置引起的，您可以检查 Pod 的日志。如果问题与 fsGroup 设置相关，您会看到以下日志条目：
Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699
如果 PersistentVolume 未在几分钟内装载，请尝试执行以下步骤来解决此问题：
- 减少卷中的文件数。
- 停止使用
[fsGroup]设置。 - 将应用
fsGroupChangePolicy更改为OnRootMismatch。
磁盘操作缓慢导致 Pod 创建失败
如需了解详情，请参阅 containerd 问题 #4604。
受影响的 GKE 节点版本：1.18、1.19、1.20.0 至 1.20.15-gke.2100、1.21.0 至 1.21.9-gke.2000、1.21.10 至 1.21.10-gke.100、1.22.0 至 1.22.6-gke.2000、1.22.7 至 1.22.7-gke.100、1.23.0 至 1.23.3-gke.700、1.23.4 至 1.23.4-gke.100
k8s_node container-runtime 日志中可能会显示以下示例错误：
Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"
应对措施
- 如果 Pod 失败，请考虑在 PodSpec 中使用
restartPolicy:Always或restartPolicy:OnFailure。 - 增加启动磁盘 IOPS（例如，升级磁盘类型或增加磁盘大小）。
修复
此问题已在 containerd 1.6.0+ 中得到修复。具有此修复的 GKE 版本为 1.20.15-gke.2100+、1.21.9-gke.2000+、1.21.10-gke.100+、1.22.6-gke.2000+、1.22.7-gke.100+、1.23.3-gke.1700+ 和 1.23.4-gke.100+
卷扩展更改未反映在容器文件系统中
执行卷扩展时，请务必更新 PersistentVolumeClaim。直接更改 PersistentVolume 可能会导致卷扩展不会发生。这可能会导致以下情况之一：
如果直接修改 PersistentVolume 对象，则 PersistentVolume 和 PersistentVolumeClaim 值都会更新为新值，但文件系统大小不会反映在容器中，并且仍然使用旧的卷大小。
如果直接修改 PersistentVolume 对象，然后更新 PersistentVolumeClaim（将
status.capacity字段更新为新大小），则可能会导致 PersistentVolume 更改，但 PersistentVolumeClaim 或容器文件系统不会更改。
如需解决此问题，请完成以下步骤：
- 保持修改后的 PersistentVolume 对象不变。
- 修改 PersistentVolumeClaim 对象，并将
spec.resources.requests.storage设置为高于 PersistentVolume 中使用的值。 - 验证 PersistentVolume 的大小是否已调整为新值。
完成这些更改后，kubelet 应该会自动调整 PersistentVolume、PersistentVolumeClaim 和容器文件系统的大小。
验证更改是否反映在 Pod 中。
kubectl exec POD_NAME -- /bin/bash -c "df -h"
将 POD_NAME 替换为附加到 PersistentVolumeClaim 的 Pod。
所选机器类型应具有本地 SSD
创建使用本地固态硬盘的集群或节点池时，您可能会遇到以下错误：
The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.
在错误消息中，您可能会看到 LocalNvmeSsdBlockConfig，而不是 EphemeralStorageLocalSsdConfig，具体取决于您指定的值。
当指定的本地 SSD 磁盘数量与机器类型中包含的本地 SSD 磁盘数量不匹配时，就会发生此错误。
如需解决此问题，请指定多个本地 SSD 磁盘，它们须与所需的机器类型匹配。对于第三代机器系列，您必须省略本地固态硬盘 count 标志，系统会自动配置正确的值。
Hyperdisk 存储池：创建集群或节点池失败
在 Hyperdisk 存储池中，当您尝试将 Hyperdisk Balanced 磁盘预配为节点的启动磁盘或挂接磁盘时，可能会遇到 ZONE_RESOURCE_POOL_EXHAUSTED 错误或类似的 Compute Engine 资源错误。
当您尝试在资源即将用尽的可用区中创建 GKE 集群或节点池时，会发生这种情况，例如：
- 该可用区可能没有足够可用的 Hyperdisk Balanced 磁盘。
- 该可用区可能没有足够的容量来创建您指定的机器类型的节点，例如
c3-standard-4。
要解决此问题，请执行以下操作：
- 选择同一区域内容量足以满足所选机器类型且提供 Hyperdisk Balanced 存储池的新可用区。
- 删除现有存储池，然后在新可用区中重新创建该存储池。这是因为存储池是可用区级资源。
- 在新可用区中创建集群或节点池。