WaitForFirstConsumer PersistentVolumeClaim 在绑定之前等待创建第一个消费者
WaitForFirstConsumer PersistentVolumeClaim waiting for first consumer to be created before binding
我在单个节点中设置了一个新的 k8s，它被感染了。但是 PersistentVolume 无法成功创建，当我尝试创建一个简单的 PostgreSQL.
下面有一些详细信息。
StorageClass复制自官方页面：https://kubernetes.io/docs/concepts/storage/storage-classes/#local
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
StatefulSet是：
kind: StatefulSet
apiVersion: apps/v1beta1
metadata:
name: postgres
spec:
serviceName: postgres
replicas: 1
...
volumeClaimTemplates:
- metadata:
name: postgres-data
spec:
storageClassName: local-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
关于 运行 StorageClass:
$ kubectl describe storageclasses.storage.k8s.io
Name: local-storage
IsDefaultClass: No
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"local-storage"},"provisioner":"kubernetes.io/no-provisioner","volumeBindingMode":"WaitForFirstConsumer"}
Provisioner: kubernetes.io/no-provisioner
Parameters: <none>
AllowVolumeExpansion: <unset>
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events: <none>
关于 运行 PersistentVolumeClaim:
$ kubectl describe pvc
Name: postgres-data-postgres-0
Namespace: default
StorageClass: local-storage
Status: Pending
Volume:
Labels: app=postgres
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal WaitForFirstConsumer <invalid> (x2 over <invalid>) persistentvolume-controller waiting for first consumer to be created before binding
K8s 版本：
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
应用程序正在等待 Pod，而 Pod 正在等待 PersistentVolumeClaim 的 PersistentVolume。
但PersistentVolume用户在使用前需自行准备
我以前的 YAML 缺少这样的 PersistentVolume：
kind: PersistentVolume
apiVersion: v1
metadata:
name: postgres-data
labels:
type: local
spec:
storageClassName: local-storage
capacity:
storage: 1Gi
local:
path: /data/postgres
persistentVolumeReclaimPolicy: Retain
accessModes:
- ReadWriteOnce
storageClassName: local-storage
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: app
operator: In
values:
- postgres
本地路径/data/postgres使用前要准备好。
Kubernetes 不会自动创建它。
已接受的答案对我不起作用。我认为这是因为在部署 StatefulSet 的 Pods 之前不会设置应用密钥，从而阻止了 PersistentVolumeClaim匹配nodeSelector（防止Pods开始报错didn't find available persistent volumes to bind.).为了解决这个僵局，我为每个节点定义了一个 PersistentVolume（这可能不理想，但它有效）：
apiVersion: v1
kind: PersistentVolume
metadata:
name: postgres-data-node1
labels:
type: local
spec:
[…]
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node1
我自己 运行 陷入了困境，直到我意识到 StorageClass 的 VolumeBindingMode 被设置为 WaitForFirstConsumer 符合我的预期Immediate 的值。该值是不可变的，因此您必须：
获取存储class yaml:
kubectl get storageclasses.storage.k8s.io gp2 -o yaml > gp2.yaml
或者您也可以只复制 the docs here 中的示例（确保元数据名称匹配）。这是我配置的内容：
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- debug
volumeBindingMode: Immediate
并删除旧的 StorageClass，然后将新的 volumeBindingMode 设置为 Immediate。
重新创建它
注意： EKS 集群可能需要 perms 才能创建 EBS 或 EFS 等云资源。假设 EBS 你应该擅长 arn:aws:iam::aws:policy/AmazonEKSClusterPolicy.
完成此操作后，您应该可以毫无问题地创建和使用 dynamically provisioned PVs。
对我来说，问题是 PV 和 PVC 中的 accessModes 字段不匹配。 PVC 请求 RWX/ReadWriteMany 而 PV 提供 RWO/ReadWriteOnce.
waitforfirstconsumer-persistentvolumeclaim，即需要此 PVC 的 POD 未被安排。 describe pods 可能会提供更多线索。在我的案例中，节点无法安排此 POD，因为节点中的 Pod 限制为 110，并且部署超出了它。希望它有助于更快地识别问题。增加 pod 限制，在节点中重启 kubelet 解决它。
在我的例子中，我 claimRef 没有指定命名空间。
正确的语法是：
claimRef:
namespace: default
name: my-claim
StatefulSet 也阻止了初始化，我不得不用部署来代替它
这是一个 f5g 头痛
我自己也陷入了这个恶性循环。
我正在尝试创建一个 kubegres 集群（根据我的理解，它依赖于动态配置）。
我在类似本地服务器的设置上使用 RKE。
我遇到了与最初提到的相同的日程安排问题。
注意 PVC 的访问模式（由 kubegres 创建）根据以下输出设置为无。
[rke@rke-1 manifests]$ kubectl get pv,PVC
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/local-vol 20Gi RWO Delete Available local-storage 40s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/local-vol-mypostgres-1-0 Pending local-storage 6m42s
persistentvolumeclaim/postgres-db-mypostgres-1-0 Pending local-storage 6m42s
作为更新，在我的案例中，问题是 PVC 没有找到应该是动态的正确 PV提供。但是对于本地存储 类，此功能尚不支持，因此我不得不使用第三方解决方案来解决我的问题。
https://github.com/rancher/local-path-provisioner
当您在 Deployment/Pod 规范中定义 nodeName 时，此问题主要发生在 WaitForFirstConsumer 上。请确保您没有定义 nodeName 并通过它硬绑定 pod。删除 nodeName 后应该解决。
我相信这可能是一条有效消息，表示没有启动的容器具有绑定到持久卷声明的卷。
我在 Rancher 桌面上遇到过这个问题。原来问题是 rancher 在 macOS 升级后没有 运行 正确引起的。容器未启动，将保持挂起状态。
重置 rancher 桌面后（使用 UI），容器能够正常启动并且消息消失。
我在单个节点中设置了一个新的 k8s，它被感染了。但是 PersistentVolume 无法成功创建，当我尝试创建一个简单的 PostgreSQL.
下面有一些详细信息。
StorageClass复制自官方页面：https://kubernetes.io/docs/concepts/storage/storage-classes/#local
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
StatefulSet是：
kind: StatefulSet
apiVersion: apps/v1beta1
metadata:
name: postgres
spec:
serviceName: postgres
replicas: 1
...
volumeClaimTemplates:
- metadata:
name: postgres-data
spec:
storageClassName: local-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
关于 运行 StorageClass:
$ kubectl describe storageclasses.storage.k8s.io
Name: local-storage
IsDefaultClass: No
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"local-storage"},"provisioner":"kubernetes.io/no-provisioner","volumeBindingMode":"WaitForFirstConsumer"}
Provisioner: kubernetes.io/no-provisioner
Parameters: <none>
AllowVolumeExpansion: <unset>
MountOptions: <none>
ReclaimPolicy: Delete
VolumeBindingMode: WaitForFirstConsumer
Events: <none>
关于 运行 PersistentVolumeClaim:
$ kubectl describe pvc
Name: postgres-data-postgres-0
Namespace: default
StorageClass: local-storage
Status: Pending
Volume:
Labels: app=postgres
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal WaitForFirstConsumer <invalid> (x2 over <invalid>) persistentvolume-controller waiting for first consumer to be created before binding
K8s 版本：
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
应用程序正在等待 Pod，而 Pod 正在等待 PersistentVolumeClaim 的 PersistentVolume。
但PersistentVolume用户在使用前需自行准备
我以前的 YAML 缺少这样的 PersistentVolume：
kind: PersistentVolume
apiVersion: v1
metadata:
name: postgres-data
labels:
type: local
spec:
storageClassName: local-storage
capacity:
storage: 1Gi
local:
path: /data/postgres
persistentVolumeReclaimPolicy: Retain
accessModes:
- ReadWriteOnce
storageClassName: local-storage
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: app
operator: In
values:
- postgres
本地路径/data/postgres使用前要准备好。
Kubernetes 不会自动创建它。
已接受的答案对我不起作用。我认为这是因为在部署 StatefulSet 的 Pods 之前不会设置应用密钥，从而阻止了 PersistentVolumeClaim匹配nodeSelector（防止Pods开始报错didn't find available persistent volumes to bind.).为了解决这个僵局，我为每个节点定义了一个 PersistentVolume（这可能不理想，但它有效）：
apiVersion: v1
kind: PersistentVolume
metadata:
name: postgres-data-node1
labels:
type: local
spec:
[…]
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node1
我自己 运行 陷入了困境，直到我意识到 StorageClass 的 VolumeBindingMode 被设置为 WaitForFirstConsumer 符合我的预期Immediate 的值。该值是不可变的，因此您必须：
获取存储class yaml:
kubectl get storageclasses.storage.k8s.io gp2 -o yaml > gp2.yaml或者您也可以只复制 the docs here 中的示例（确保元数据名称匹配）。这是我配置的内容：
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gp2 provisioner: kubernetes.io/aws-ebs parameters: type: gp2 reclaimPolicy: Delete allowVolumeExpansion: true mountOptions: - debug volumeBindingMode: Immediate并删除旧的
重新创建它StorageClass，然后将新的volumeBindingMode设置为Immediate。
注意： EKS 集群可能需要 perms 才能创建 EBS 或 EFS 等云资源。假设 EBS 你应该擅长 arn:aws:iam::aws:policy/AmazonEKSClusterPolicy.
完成此操作后，您应该可以毫无问题地创建和使用 dynamically provisioned PVs。
对我来说，问题是 PV 和 PVC 中的 accessModes 字段不匹配。 PVC 请求 RWX/ReadWriteMany 而 PV 提供 RWO/ReadWriteOnce.
waitforfirstconsumer-persistentvolumeclaim，即需要此 PVC 的 POD 未被安排。 describe pods 可能会提供更多线索。在我的案例中，节点无法安排此 POD，因为节点中的 Pod 限制为 110，并且部署超出了它。希望它有助于更快地识别问题。增加 pod 限制，在节点中重启 kubelet 解决它。
在我的例子中，我 claimRef 没有指定命名空间。
正确的语法是：
claimRef:
namespace: default
name: my-claim
StatefulSet 也阻止了初始化，我不得不用部署来代替它
这是一个 f5g 头痛
我自己也陷入了这个恶性循环。
我正在尝试创建一个 kubegres 集群（根据我的理解，它依赖于动态配置）。
我在类似本地服务器的设置上使用 RKE。
我遇到了与最初提到的相同的日程安排问题。
注意 PVC 的访问模式（由 kubegres 创建）根据以下输出设置为无。
[rke@rke-1 manifests]$ kubectl get pv,PVC
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/local-vol 20Gi RWO Delete Available local-storage 40s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/local-vol-mypostgres-1-0 Pending local-storage 6m42s
persistentvolumeclaim/postgres-db-mypostgres-1-0 Pending local-storage 6m42s
作为更新，在我的案例中，问题是 PVC 没有找到应该是动态的正确 PV提供。但是对于本地存储 类，此功能尚不支持，因此我不得不使用第三方解决方案来解决我的问题。 https://github.com/rancher/local-path-provisioner
当您在 Deployment/Pod 规范中定义 nodeName 时，此问题主要发生在 WaitForFirstConsumer 上。请确保您没有定义 nodeName 并通过它硬绑定 pod。删除 nodeName 后应该解决。
我相信这可能是一条有效消息，表示没有启动的容器具有绑定到持久卷声明的卷。
我在 Rancher 桌面上遇到过这个问题。原来问题是 rancher 在 macOS 升级后没有 运行 正确引起的。容器未启动，将保持挂起状态。
重置 rancher 桌面后（使用 UI），容器能够正常启动并且消息消失。