Kubernetes - pod 具有未绑定的即时 PersistentVolumeClaims
Kubernetes - pod has unbound immediate PersistentVolumeClaims
我正在使用 mysql Kubernetes statefulset，我将 PV 映射到主机目录（CentOS 8 VM）但是得到“pod has unbound immediate PersistentVolumeClaims”
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql-container
spec:
serviceName: mysql
replicas: 1
selector:
matchLabels:
app: mysql-container
template:
metadata:
labels:
app: mysql-container
spec:
containers:
- name: mysql-container
image: mysql:dev
imagePullPolicy: "IfNotPresent"
envFrom:
- secretRef:
name: prod-secrets
ports:
- containerPort: 3306
# container (pod) path
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pvc
volumeClaimTemplates:
- metadata:
name: data
spec:
storageClassName: localstorage
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 3Gi
selector:
matchLabels:
type: local
存储 class 是默认的并且 PV
中没有事件
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: localstorage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
reclaimPolicy: Delete
allowVolumeExpansion: True
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-01
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql01"
---
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-02
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql02"
存储class是默认的
get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localstorage (default) kubernetes.io/no-provisioner Delete Immediate true 35m
PVC 也没有显示任何事件：
Name: data-mysql-0
Namespace: default
StorageClass: localstorage
Status: Pending
Volume: mysql-storage
Labels: app=mysql
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 0
Access Modes:
VolumeMode: Filesystem
Mounted By: mysql-0
Events: <none>
Name: mysql-01
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-01"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql01
HostPathType:
Events: <none>
Name: mysql-02
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-02"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql02
HostPathType:
Events: <none>
Pod 处于挂起状态：
> Events:
> Type Reason Age From Message
> ---- ------ ---- ---- -------
> Warning FailedScheduling 27s (x2 over 27s) default-scheduler error while running >"VolumeBinding" filter plugin for pod "mysql-0": pod has unbound immediate PersistentVolumeClaims
Can someone point out what else should be done here, thanks
如果匹配的 PersistentVolume 不存在，PersistentVolumeClaims 将无限期保持未绑定状态。 PersistentVolume 与 accessModes 和 capacity 匹配。在这种情况下 capacity PV 是 10Gi 而 PVC 有 capacity of 3Gi.
PV 中的 capacity 需要与声明中的相同，即 3Gi 以修复 unbound immediate PersistentVolumeClaims 问题。
上述错误可能由多种原因引起 - 以下是我遇到的几个选项。
示例 1
persistentvolume-controller 未能找到容量大小 等于或大于 的 PV PVC.
所以如果我们举这个例子：
# PVC
resources:
requests:
storage: 3Gi
# PV
capacity:
storage: 10Gi
所以：
如果 PV capacity >= PVC capacity 那么 PVC 应该绑定到 PV。
如果不是，那么我们将在 pod 级别和 no volume plugin matched name 描述 PVC 时得到 unbound immediate PersistentVolumeClaims 错误。
示例 2
PVC数大于PV数
例如如果只创建了一个PV（或者其他的都被删除了）：
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mongo-local-pv 50Gi RWO Retain Bound default/mongo-persistent-storage-mongo-0 local-storage 106m
我们可以看到某些工作负载（Pods 或有状态集）将停留在待定状态：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo-0 2/2 Running 0 3m38s
mongo-1 0/2 Pending 0 3m23s
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mongo-persistent-storage-mongo-0 Bound mongo-local-pv 50Gi RWO local-storage 80m
mongo-persistent-storage-mongo-1 Pending local-storage 45m
我们将在挂起的资源上收到上述错误。
示例 3
如果调度程序未能将节点与 PV 匹配。
当使用本地卷时，PV 的nodeAffinity是必需的并且应该是现有节点的值集群：
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-mongo-pv
.
.
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node-which-doesnt-exists # <----- Will lead to the error
示例 4
集群上已经存在同名不同配置的旧PV，新的PVC是根据它们创建的。
使用本地卷时，管理员必须手动清理并每次重新设置本地卷以供重复使用。
(*) This 本地静态供应器的创建是为了帮助 PV 生命周期。
我正在使用 mysql Kubernetes statefulset，我将 PV 映射到主机目录（CentOS 8 VM）但是得到“pod has unbound immediate PersistentVolumeClaims”
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql-container
spec:
serviceName: mysql
replicas: 1
selector:
matchLabels:
app: mysql-container
template:
metadata:
labels:
app: mysql-container
spec:
containers:
- name: mysql-container
image: mysql:dev
imagePullPolicy: "IfNotPresent"
envFrom:
- secretRef:
name: prod-secrets
ports:
- containerPort: 3306
# container (pod) path
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pvc
volumeClaimTemplates:
- metadata:
name: data
spec:
storageClassName: localstorage
accessModes: ["ReadWriteOnce"]
resources:
requests:
storage: 3Gi
selector:
matchLabels:
type: local
存储 class 是默认的并且 PV
中没有事件apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: localstorage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: Immediate
reclaimPolicy: Delete
allowVolumeExpansion: True
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-01
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql01"
---
kind: PersistentVolume
apiVersion: v1
metadata:
name: mysql-02
labels:
type: local
spec:
storageClassName: localstorage
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/mysql02"
存储class是默认的
get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localstorage (default) kubernetes.io/no-provisioner Delete Immediate true 35m
PVC 也没有显示任何事件：
Name: data-mysql-0
Namespace: default
StorageClass: localstorage
Status: Pending
Volume: mysql-storage
Labels: app=mysql
Annotations: <none>
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 0
Access Modes:
VolumeMode: Filesystem
Mounted By: mysql-0
Events: <none>
Name: mysql-01
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-01"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql01
HostPathType:
Events: <none>
Name: mysql-02
Labels: type=local
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"labels":{"type":"local"},"name":"mysql-02"},"spec":{"accessMode...
Finalizers: [kubernetes.io/pv-protection]
StorageClass: localstorage
Status: Available
Claim:
Reclaim Policy: Retain
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 10Gi
Node Affinity: <none>
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /mnt/mysql02
HostPathType:
Events: <none>
Pod 处于挂起状态：
> Events:
> Type Reason Age From Message
> ---- ------ ---- ---- -------
> Warning FailedScheduling 27s (x2 over 27s) default-scheduler error while running >"VolumeBinding" filter plugin for pod "mysql-0": pod has unbound immediate PersistentVolumeClaims
Can someone point out what else should be done here, thanks
PersistentVolume 不存在，PersistentVolumeClaims 将无限期保持未绑定状态。 PersistentVolume 与 accessModes 和 capacity 匹配。在这种情况下 capacity PV 是 10Gi 而 PVC 有 capacity of 3Gi.
PV 中的 capacity 需要与声明中的相同，即 3Gi 以修复 unbound immediate PersistentVolumeClaims 问题。
上述错误可能由多种原因引起 - 以下是我遇到的几个选项。
示例 1
persistentvolume-controller 未能找到容量大小 等于或大于 的 PV PVC.
所以如果我们举这个例子：
# PVC
resources:
requests:
storage: 3Gi
# PV
capacity:
storage: 10Gi
所以：
如果 PV capacity >= PVC capacity 那么 PVC 应该绑定到 PV。
如果不是，那么我们将在 pod 级别和 no volume plugin matched name 描述 PVC 时得到 unbound immediate PersistentVolumeClaims 错误。
示例 2
PVC数大于PV数
例如如果只创建了一个PV（或者其他的都被删除了）：
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mongo-local-pv 50Gi RWO Retain Bound default/mongo-persistent-storage-mongo-0 local-storage 106m
我们可以看到某些工作负载（Pods 或有状态集）将停留在待定状态：
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo-0 2/2 Running 0 3m38s
mongo-1 0/2 Pending 0 3m23s
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mongo-persistent-storage-mongo-0 Bound mongo-local-pv 50Gi RWO local-storage 80m
mongo-persistent-storage-mongo-1 Pending local-storage 45m
我们将在挂起的资源上收到上述错误。
示例 3
如果调度程序未能将节点与 PV 匹配。
当使用本地卷时，PV 的nodeAffinity是必需的并且应该是现有节点的值集群：
apiVersion: v1
kind: PersistentVolume
metadata:
name: local-mongo-pv
.
.
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node-which-doesnt-exists # <----- Will lead to the error
示例 4
集群上已经存在同名不同配置的旧PV，新的PVC是根据它们创建的。
使用本地卷时，管理员必须手动清理并每次重新设置本地卷以供重复使用。
(*) This 本地静态供应器的创建是为了帮助 PV 生命周期。