发生了什么：
我正在进行一个规模测试，在一段时间内创建了约8 PV/s。我观察到POST持久卷延迟开始增长。
我已经调试过了：

• kube-controller-manager 在 GCE 中创建了 PD 对象
• 由于速率限制错误，它无法获取新磁盘的标签：https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/gcepd/gce_util.go#L191
• PersistentVolumeLabel admission controller 试图添加缺失的 GCE 标签，但由于相同的速率限制错误而失败(这也导致请求处理中的显著延迟)

你期望发生什么：
POST persistentvolume 延迟在测试期间保持恒定。
可以通过以下方式实现：

• 从 https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/gcepd/gce_util.go#L188 中删除 cloud.GetAutoLabelsForZonalPD 调用
• 这样一来，在对象创建后就没有可能失败的 API 调用了
• 因为我们刚刚成功创建了一个 PD,所以我们知道该 PD 的所有参数(区域、区域、未来可能会有其他磁盘的属性等),我们可以使用这些信息进行标签计算，没有必要验证它是否仍然存在。
• 为 cloud.GetAutoLabelsForPD 调用实现适当的重试策略，以便在 kube-controller-manager 过载时不将负载转移到 kube-apiserver。
• (部分)通过在 https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/gcepd/gce_util.go#L188 中传递 zone 参数，我们可以在zonal磁盘的情况下将其减少3-4倍，但这只是一种缓解措施

对我来说，第一种方法是最合理的(我已经为此提交了一些草稿),但在我开始清理 PR 之前，我想听听你的意见。
这种方法的可能缺点是：

• 目前，如果具有给定名称的磁盘已经存在，我们只是重用该磁盘(https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/legacy-cloud-providers/gce/gce_disks.go#L732)。在这种情况下，实际上我们并不知道用于创建该 PD 的 replicationZones,因此我们需要在那里获取它们。我们可以限制只在这种情况下进行调用。

如何尽可能精确地最小化地复现它？
只需一起创建很多 pvs。
还需要了解其他任何信息吗？
环境：

• Kubernetes 版本(使用 kubectl version):
• 云提供商或硬件配置：
• OS(例如：cat /etc/os-release):
• 内核(例如：uname -a):
• 安装工具：
• 网络插件和版本(如果这是一个与网络相关的 bug):
• 其他：