当前位置: 首页 > 知识库问答 >
问题:

Kubernetes - pod 具有未绑定的即时 PersistentVolumeClaims

劳亦
2023-03-14

我正在使用mysql Kubernetes statefulset,我将PV映射到主机目录(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"

存储类为默认存储类 1

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

有人可以指出这里还应该做什么吗,谢谢

共有2个答案

毕浩渺
2023-03-14

上述错误可能由多种原因引起 - 以下是我遇到的几个选项。

例 1

持久卷控制器无法找到容量大小等于或大于 PVC 中指定的值的 PV

因此,如果我们举这个例子:

  # PVC
  resources:
     requests:
       storage: 3Gi


  # PV
  capacity:
    storage: 10Gi 

所以:
如果光伏容量

如果不是,那么我们将在 pod 级别收到未绑定的即时 PersistentVolumeClaims 错误,并且在描述 PVC 时没有与名称匹配的卷插件

例 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 的节点关联性是必需的,并且应该是群集中现有节点的值:

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 生命周期。

郭均
2023-03-14

如果匹配的 PersistentVolume 不存在,则 PersistentVolumeClaims 将无限期地保持未绑定状态。持久卷访问模式容量相匹配。在这种情况下,PV的容量10Gi,而PVC的容量3Gi

PV 中的容量需要与声明中的容量相同,即 3Gi 以修复未绑定的即时 PersistentVolumeClaims 问题。

 类似资料:
  • 我已经定义了以下复制控制器JSON: 使用“docker run-t-I-p 0 . 0 . 0 . 0:9021:80-v/mnt/NFS/WordPress _ a:/mnt/NFS/WordPress _ a:rw internal user/PHP 53”运行时,容器正确启动。 /mnt/nfs/wordpress_a是一个nfs共享,安装在所有的minions上。每个minion都有完全

  • 我正在尝试在DigitalOcean的Kubernetes中运行一个Redis集群。作为一个poc,我只是尝试运行了我在网上找到的一个示例(https://github.com/sanderploegsma/redis-cluster/blob/master/redis-cluster.yml),该示例能够在使用Minikube本地运行时适当地旋转POD。 然而,当在Digital Ocean上运

  • 由于绑定是在绑定模块中定义的,Google Guice 会在需要注入依赖项时使用它们。如果不存在绑定,它可以尝试创建即时绑定。绑定模块中存在的绑定称为显式绑定并且具有更高的优先级,而即时绑定称为隐式绑定。如果两种类型的绑定都存在,则考虑使用显式绑定进行映射。 以下是三种类型的即时绑定的示例。 绑定类型 描述 可注入的构造函数 非私有、无参数构造函数有资格进行即时绑定。另一种方法是使用@Inject

  • 《Kubernetes权威指南第五版 4.5.2节》 在这个yaml文件中创建了一个 pod,并指定了hostname和subdomain 同时创建了一个service, 书中提到 service的名称必须要和subdomain保持一致。 测试发现如果不保持一致 那么在其他Pod的容器中执行 wget webapp-1.mysubdomain.default.svc.cluster.local:8

  • 由于绑定是在绑定模块中定义的,因此只要需要注入依赖关系,Guice就会使用它们。 如果不存在绑定,它可以尝试创建即时绑定。 绑定模块中存在的绑定称为显式绑定,具有更高的优先级,而即时绑定称为隐式绑定。 如果存在两种类型的绑定,则考虑使用显式绑定进行映射。 以下是三种即时绑定的示例。 Sr.No. 绑定类型和描述 1 可注射的构造函数 非私有,无参数构造函数符合即时绑定的条件。 另一种方法是使用@I

  • Kubernetes中需要考虑三个级别的度量集合—节点、Pod和在Pod中运行的应用程序。 对于节点和应用程序指标,我有非常有效的解决方案,但我仍停留在pod指标上。 我尝试过cAdvisor和Kube状态指标,但它们都没有给我想要的东西。Kube状态指标仅提供已知的信息,例如pod CPU限制和请求。cAdvisor不会将pod标签插入容器名称,因此我无法知道哪个pod行为不端。 给定一个pod

  • Kubernetes Pod Chaos Monkey This repository contains a Dockerfile and associated Kubernetes configuration for a Deployment that will randomly delete pods in a given namespace. This is implemented in B

  • 我希望一个应用程序从队列中提取一个项目,在队列中处理该项目,然后销毁它自己。拉->过程->破坏。 我已经研究了使用作业模式队列和每个工作项的Pod,因为这适合于使用,但是,当我需要作业在队列为空时自动缩放AKA0/1 Pod,并且在添加项时缩放到某个点时,这是不合适的。我能看到的唯一方法是通过部署,但这将删除每个工作项带有Pod的队列模式。每个项目必须有一个新鲜容器。 有没有一种方法可以让每个工作