☰

Gcloud：更新到区域集群后没有可用的卷区域

tag-icon • tag-icon kubernetes google-kubernetes-engine
Gcloud：更新到区域集群后没有可用的卷区域

我在此时间点上对三倍镜像的区域集群执行了以下命令：

gcloud container clusters update proto-cluster-ha-1 --zone europe-north1 --node-locations europe-north1-a

执行之前，集群在区域 europe-north1-a / europe-north1-b / europe-north1-c 之间进行了镜像。

执行后集群仅在单个区域 europe-north1-a 运行。

问题：

自更新以来，我的卷挂载不再能够挂载，因为：

2 node(s) had no available volume zone

尽管 PVC 显示为 BOUND：

csi-pvc-mounting         Bound

如果我删除安装并重新创建它，一切都会正常。但是我怎样才能恢复这样的卷安装而不破坏它呢？

我已经将新创建的安装的连接 yaml 与不想绑定的旧安装进行了比较，但我没有发现任何差异。

答案1

这个问题有点老了，但是如果有人仍然遇到类似的问题，那么关于这个主题的文档已经更新得很好了。

我尝试重现此行为，但是使用此命令的输出按设计工作。

当你使用

$ gcloud container clusters update proto-cluster-ha-1 --zone europe-north1 --node-locations europe-north1-a

您已更新集群proto-cluster-ha-1以仅使用一个区域europe-north1-a。

在--节点位置范围。

应在其中复制指定节点覆盖范围的地区集。所有地区都必须与集群的主节点位于同一区域，由 --zone 或 --region 标志指定。此外，对于区域集群，--node-locations 必须包含集群的主要地区。如果未指定，则所有节点都将位于集群的主要地区（对于区域集群）或分布在集群区域内随机选择的三个地区（对于区域集群）。

如果您想要更新多个区域中的配置，则需要指定它。示例如下：

$ kubectl describe node | grep zone
                    failure-domain.beta.kubernetes.io/zone=us-central1-c
                    failure-domain.beta.kubernetes.io/zone=us-central1-b
                    failure-domain.beta.kubernetes.io/zone=us-central1-a
                    
$ gcloud container clusters update regio --zone us-central1 --node-locations us-central1-a,us-central1-b
Updating regio...done.
Updated [https://container.googleapis.com/v1/projects/XXXXXXX/zones/us-central1/clusters/regio].
To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/us-central1/regio?project=XXXXXXXX
$ kubectl describe node | grep zone
                    failure-domain.beta.kubernetes.io/zone=us-central1-b
                    failure-domain.beta.kubernetes.io/zone=us-central1-a

关于音量，你没有提到你是如何创造的Volume，什么回收政策被使用。

PersistentVolumes可以有各种回收策略，包括Retain、Recycle和Delete。对于动态配置的PersistentVolumes，默认回收策略是Delete。这意味着当用户删除相应的时，动态配置的卷会自动删除PersistentVolumeClaim。如果卷包含宝贵的数据，则此自动行为可能不合适。在这种情况下，使用“保留”策略更合适。使用策略RetainPersistentVolumeClaim , if a user deletes aPersistentVolume`, the corresponding不会被删除。相反，它会被移动到已发布阶段，在此阶段可以手动恢复其所有数据。

**取决于你能否：**

回收

当用户不再使用卷时，他们可以通过允许回收资源的 API 删除 PVC 对象。持久卷的回收策略会告知集群在释放对卷的认领后该如何处理该卷。目前，卷可以保留、回收或删除。

或者

保持

保留回收策略允许手动回收资源。删除 PersistentVolumeClaim 后，PersistentVolume 仍然存在，并且卷被视为“已释放”。但由于先前的申索者的数据仍保留在卷上，因此尚无法对其进行其他申索。管理员可以按照以下步骤手动回收卷。

目前您可以创建区域持久磁盘以避免这种情况。

相关内容