本页面介绍了如何解决部署在 Google Kubernetes Engine (GKE) 集群上的卷的问题。
错误 400：无法将 RePD 附加到优化虚拟机
区域永久性磁盘限制在内存优化机器或计算优化机器中使用。
若并非硬性要求，请考虑使用非区域永久性磁盘存储类别。若难以使用区域永久性磁盘，请考虑安排污点和容忍等策略，以确保需要区域永久性磁盘的 Pod 被调度到节点池非优化机器。
排查磁盘性能的问题
启动磁盘的性能非常重要，因为 GKE 节点的启动磁盘不仅用于操作系统，还用于以下各项：
- Docker 映像
- 未装载为卷的容器文件系统（即叠加文件系统），通常包含
/tmp等目录。 - 磁盘支持的
emptyDir卷，除非节点使用本地 SSD。
节点上磁盘类型相同的所有磁盘的性能都是共享的。例如，如果您有一个 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
创建使用本地 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 磁盘，它们须与所需的机器类型匹配。对于第三代机器系列，您必须省略本地 SSD count 标志，系统会自动配置正确的值。