问题标签 [persistent-volume-claims]

我想知道同一个 Kubernetes 集群中的多个 Pod 是否可以访问使用 Google 云永久磁盘上的永久卷配置的数据库。

目前我正在构建一个微服务架构 Web 应用程序，它在不同的 pod 中有 3 个节点 api，它们都访问同一个数据库。那么我如何使用 kubernetes 实现这一点。

请让我知道我的架构是否也正确

我正在使用具有 ReadWriteOnce 访问模式的 PVC，它由 logstash 部署使用，该部署将运行有状态应用程序并使用此 PVC。部署中的每个 pod 将尝试绑定到相同的持久卷声明。如果replicas > 1，它将失败（因为它支持ReadWriteOnce，只有第一个能够成功绑定）。如何指定每个 pod 绑定到单独的 PV。

我不想为每个 logstash 副本/实例定义 3 个单独的 yaml

需要一种方法将不同的 PV 卷挂载到不同的 pod 副本。

我想知道是否有可能多个 PersistentVolumeClaims 绑定到同一个本地持久卷。

我的用例如下：我想构建一个守护程序集，它将在集群上的每个节点（在节点的本地磁盘上）上写入一些数据（实际上是相同的数据）。然后，在任何节点上调度的任何其他 pod 都应该能够读取该数据。基本上是节点级别的一种一次写入多次读取的策略。

我知道我可以使用hostPath类型的卷来做到这一点，但是管理起来有点困难，所以我发现本地存储会是一种更好的方法。

我的愿望是：

• 使用ReadWriteOnce和ReadOnlyMany访问模式创建本地 Persistent Volume（名为 pv）
• 使用ReadWriteOnce访问模式创建第一个持久卷声明 (pvc1)，并在将数据写入卷中的 DaemonSet 中使用它。所以pvc1应该绑定到pv
• 使用ReadOnlyMany访问模式创建第二个持久卷声明 (pvc2)，该访问模式在读取该数据的任何其他 pod 中使用（因此pvc2也应该绑定到pv）

这可能吗？

我读到如果 PVC 绑定到 PV，则该 PV 被“锁定”，这意味着没有其他 PVC 可以绑定到它。这真的是这样吗？如果对于那种场景来说似乎有点限制，我们有一次写入多次读取的操作。

谢谢！

我正在尝试创建两个部署，一个用于 Wordpress，另一个用于 MySQL，它们引用两个不同的持久卷。

有时，在删除和重新创建卷和部署时，MySQL 部署会填充 Wordpress 卷（以wordpress-volume目录中的数据库结束）。

当你这样做时，这会更清楚kubectl get pv --namespace my-namespace：

.

我很确定设置没问题。请在下面找到 yaml 文件。

持久卷声明 + 持久卷

部署

显然，关于 PV 的 kubelet 指标在 K8s v1.12 中不可用

它曾经是你可以刮取：

我们的集群运行 v1.13.3，我们在 Kubernetes 中使用 PVC 运行 Kafka、Prometheus、InfluxDB 和 MongoDB，因此获取这些卷的使用统计信息非常重要。

有没有人找到其他方法来收集这些指标？我听说有可能在每个使用 PVC 的容器上加载带有节点导出器的边车容器。可以做到，但我更喜欢更优雅的解决方案。

Kubernetes 版本：1.13.4（1.13.2 上同样的问题）。

我在 digitalocean 上自行托管集群。

操作系统：coreos 2023.4.0

我在一个节点上有 2 个卷：

并且 2 pvc 在同一个节点上使用它们。这是一个：

一切正常。

kubectl get pv --all-namespaces输出：

kubectl get pvc --all-namespaces输出：

问题是我每 2 分钟从 kube-controller-manager 获取这些日志消息：

它们为什么会出现？我怎样才能解决这个问题？

我正在尝试使用 Kubernetes 在 Digital Ocean 上设置 MySQL pod。

我不断收到此错误：

我的 yaml 有很多东西，但对这部分配置感兴趣的行如下。

如果我在部署配置中注释掉 PVC 和与 PVC 相关的行，一切正常。

另外，如果我改变

到

有用。但我显然需要/var/lib/mysql...

它也发生在全新的集群上。

任何的想法？

我在 AWS 中有一个 kubernetes 集群，在以下 AZ 中有 ec2 工作节点，每个 AZ 中有相应的 PersistentVolume。

我的问题是我想创建一个带有引用 PersistentVolumeClaim 的卷挂载的 Deployment，并保证它们位于同一个 AZ，因为现在很幸运，Deployment 和 PersistentVolumeClaim 最终都在同一个 AZ 中。如果它们不在同一个 AZ 中，则部署无法找到卷挂载。

我通过在每个 AZ 中手动创建 EBS 卷并将 ID 复制到规范来创建 4 个 PersistentVolume。

我想扩展我的持久卷，以便在运行 v1.12.5 的 GKE 集群上进行部署。我更改了存储类以启用卷扩展：

之后我更改了 PVC 的大小：

删除 pod 后，我像这样检查了 pvc 的状态。然后在几秒钟内，部署中的副本设置重新启动了 pod：

所以它似乎只等待文件系统调整大小。如前所述，我多次删除了 pod，并将副本值设置为 0 以终止 pod，但文件系统大小调整没有启动。

我究竟做错了什么？

在我使用api.PersistentVolumeClaims(namespace).Create(createOpts)调用后使用 go-client API 时，PersistentVolumeClaim 显示为资源，但仍处于 Pending 状态。使用时我没有看到任何事件kubectl describe pvc，也没有看到正在创建的任何卷等。

我正在使用的代码如下：

我试图找到使用具有持久卷的 Create API 的好示例，但大多数示例似乎是针对观察者等的，因此我花了很长时间尝试对代码进行逆向工程，引导我明确设置，Status但这似乎影响为零。我还尝试在 Spec 中默认 VolumeMode，但没有帮助。

我读过的例子来自：

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/volume/persistentvolume/framework_test.go
https://godoc.org/k8s.io/api/core/v1#PersistentVolumeSpec
https:// github.com/vladimirvivien/k8s-client-examples/tree/master/go/pvcwatch
https://medium.com/programming-kubernetes/building-stuff-with-the-kubernetes-api-part-4-using-go -b1d0e3c1c899

有谁知道这些 API 的实际示例代码超出了 _test.go 文件中的单元测试，或者任何人都可以提供有关如何让创建过程在集群中实际滚动的任何提示？我假设当我尝试创建 Claim 资源时，会自动配置所需的下游资源，例如 Volume 等。

非常感谢您看一看，如果您走到这一步...