Kubernetes - pod有未绑定的立即PersistentVolumeClaims
Kubernetes - pod有未绑定的立即PersistentVolumeClaims
提问于 2020-03-20 12:30:45
我使用mysql状态集，我将PVs映射到主机目录(CentOS 8 VM)，但是得到了“pod已解除绑定的立即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存储类是defaulr，并且在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"存储类是默认的
get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localstorage (default) kubernetes.io/no-provisioner Delete Immediate true 35mPVC也没有显示任何事件：
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有人能指出这里还应该做些什么吗，谢谢
回答 2
Stack Overflow用户
回答已采纳
发布于 2020-03-20 13:20:49
如果不存在匹配的PersistentVolumeClaims，则PersistentVolume将无限期地保持未绑定状态。PersistentVolume与accessModes和capacity匹配。在这种情况下，PV是capacity，而PVC是capacity of 3Gi。
PV中的capacity需要与索赔(即3Gi )中的相同，以修复unbound immediate PersistentVolumeClaims问题。
Stack Overflow用户
发布于 2020-11-09 00:01:32
上述错误可能是由于多种原因引起的-下面是我遇到的几个选项。
示例1
persistentvolume-controller未能找到容量大小为等于或高于PVC中指定的值的。
所以如果我们以这个例子为例：
# PVC
resources:
requests:
storage: 3Gi
# PV
capacity:
storage: 10Gi 所以：
如果PV capacity >= PVC capacity，那么PVC应该绑定到PV。
如果没有，那么在描述PVC时，我们将得到unbound immediate PersistentVolumeClaims级和no volume plugin matched name的错误。
示例2
PVC的数量高于PV。
例如，如果只创建一个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。
在使用本地卷时，管理员必须手动执行清理，并每次重新设置本地卷以进行重用。
(*)创建这本地静态提供程序是为了帮助PV生命周期。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/60774220
复制相关文章
相似问题
腾讯云开发者
