本页面介绍了如何解决 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 标志，系统会自动配置正确的值。