K8S存储

949次阅读
没有评论

ConfigMap 描述信息

ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中

读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制的对象

ConfigMap 的创建

1、使用目录创建

使用:

[root@k8s-master01 configmap]# ll /data/volume/configmap/dir/

total 8

-rw-r–r– 1 root root 159 Jun  5 17:50 game.properties

-rw-r–r– 1 root root  84 Jun  5 17:52 ui.properties

[root@k8s-master01 configmap]# cat ./dir/

game.properties  ui.properties   

[root@k8s-master01 configmap]# cat ./dir/*

enemies=aliens

lives=3

enemies.cheat=true

enemies.cheat.level=noGoodRotten

secret.code.passphrase=UUDDLRLRBABAS

secret.code.allowed=true

secret.code.lives=30

color.good=purple

color.bad=yellow

allow.textmode=true

how.nice.to.look=fairlyNice

kubectl create configmap game-config –from-file=./dir/

2、使用文件创建

kubectl create configmap game-config2 –from-file=./dir/game.properties

3、使用字面值创建

kubectl create configmap special-config –from-literal=special.how=very –from-literal=special.type=charm

Pod 中使用 ConfigMap

a、使用 ConfigMap 来替代环境变量

1、先将 cm 写好 (special-config 上文、env-config)

kubctl apply -f env-config.yaml

[root@k8s-master01 configmap]# cat env/env-config.yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: env-config

  namespace: default

data:

  log_level: INFO

2、Pod 调用环境变量

[root@k8s-master01 configmap]# cat pod.yaml

apiVersion: v1

kind: Pod

metadata:

  name: depi-test-pod

spec:

  containers:

    – name: test-container

      image: wangyanglinux/myapp:v1

      command: [“/bin/sh”,”-c”,”env”]

      env:

        – name: SPECIAL_LEVEL_KEY

          valueFrom:

            configMapKeyRef:

              name: special-config

              key: special.how

        – name: SPECIAL_TYPE_KEY

          valueFrom:

            configMapKeyRef:

              name: special-config

              key: special.type

      envFrom:

        – configMapRef:

            name: env-config

  restartPolicy: Never

b、用 ConfigMap 设置命令行参数(延用 special-config、env-config)

[root@k8s-master01 configmap]# cat pod1.yaml

apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod1

spec:

  containers:

    – name: test-container

      image: wangyanglinux/myapp:v1

      command: [“/bin/sh”,”-c”,”echo $(SPECIAL_LEVEL_KEY),$(SPECIAL_TYPE_KEY)” ]

      env:

        – name: SPECIAL_LEVEL_KEY

          valueFrom:

            configMapKeyRef:

              name: special-config

              key: special.how

        – name: SPECIAL_TYPE_KEY

          valueFrom:

            configMapKeyRef:

              name: special-config

              key: special.type

  restartPolicy: Never  

C、通过数据卷插件使用 ConfigMap

[root@k8s-master01 configmap]# cat pod2.yaml

apiVersion: v1

kind: Pod

metadata:

  name: dapi-test-pod2

spec:

  containers:

    – name: test-container

      image: wangyanglinux/myapp:v1

      command: [“/bin/sh”,”-c”,”cat /etc/config/special.how”]

      volumeMounts:

      – name: config-volume

        mountPath: /etc/config  

  volumes:

    – name: config-volume

      configMap:

        name: special-config

  restartPolicy: Never       

ConfigMap 的热更新

配置文件:

[root@k8s-master01 configmap]# cat configmap.yaml

apiVersion: v1

kind: ConfigMap

metadata:

  name: log-config

data:

  log_level: INFO

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-nginx

spec:

  replicas: 2

  selector:

    matchLabels:

      run: my-nginx 

  template:

    metadata:

      labels:

        run: my-nginx

    spec:

      containers:

      – name: my-nginx

        image: wangyanglinux/myapp:v1

        ports:

        – containerPort: 80

        volumeMounts:

        – name: config-volume

          mountPath: /etc/config

      volumes:

        – name: config-volume

          configMap:

            name: log-config

[root@k8s-master01 configmap]# kubectl get pods

NAME                        READY   STATUS    RESTARTS   AGE

my-nginx-74b5f4d6d8-dc2x4   1/1     Running   0          76s

my-nginx-74b5f4d6d8-llgnb   1/1     Running   0          75s

[root@k8s-master01 configmap]# kubectl exec my-nginx-74b5f4d6d8-dc2x4 -it — cat /etc/config/log_level

INFO

2、修改 ConfigMap

[root@k8s-master01 configmap]# kubectl edit configmap log-config

configmap/log-config edited

[root@k8s-master01 configmap]# kubectl exec my-nginx-74b5f4d6d8-dc2x4 -it — cat /etc/config/log_level

DEBUG

ConfigMap 更新后滚动更新 Pod

通过修改 pod annotations 的方式强制触发滚动更新

kubectl patch deployment my-nginx –patch ‘{“spec”: {“template”: {“metadata”: {“annotations”: {“version/config”: “2020605”}}}}}’

这个例子在.spec.template.metadata.annotataions 中添加 version/config,每次通过修改 version/config 来触发滚动更新

Secret 存在意义

Secret 解决了密码、token、密钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。

Secret 可以以 Volume 或者环境变量的方式使用

Secret 有三种类型:

  • Service Account:用来访问 Kubernetes API,由 Kubernetes 自动创建,并且会自动挂载到 Pod 的

/run/secret/kubernetes.io/serviceaccount 目录中

  • Opaque:base64 编码格式的 Secret,用来存储密码、密钥等
  • Kubernetes.io/dockerconfigjson:用来存储私有 docker registry 的认证信息

Service Account

Opaque Secret

1、创建说明

Opaque 类型的数据是一个 map 类型,要求 value 是 base64 编码格式:

[root@k8s-master01 ~]# echo -n “Aa123456” | base64

QWExMjM0NTY=

[root@k8s-master01 ~]# echo -n “admin” | base64

YWRtaW4=

2、yaml 文件

apiVersion: v1

kind: Secret

metadata:

  name: mysecret

type: Opaque

data:

  password: QWExMjM0NTY=

  username: YWRtaW4=

使用方式

1、将 Secret 挂载到 Volume 中

apiVersion: v1

kind: Pod

metadata:

  name: secret-test

  labels:

    name: secret-test

spec:

  volumes:

  – name: secrets

    secret:

      secretName: mysecret

  containers:

  – image: wangyanglinux/myapp:v1

    name: db

    volumeMounts:

    – name: secrets

      mountPath: “/etc/secrets”

      readOnly: true

2、将 Secret 导出到环境变量中

[root@k8s-master01 secret]# cat env.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: pod-deployment

  labels:

    name: secret-test

spec:

  replicas: 2

  selector:

    matchLabels:

      app: pod-deployment

  template:

    metadata:

      labels:

        app: pod-deployment

    spec:

      containers:

      – name: pod-1

        image: wangyanglinux/myapp:v1

        ports:

        – containerPort: 80

        command: [“/bin/sh”,”-c”,”echo $(TEST_USER),$(TEST_PASSWORD)” ]

        env:

        – name: TEST_USER

          valueFrom:

            secretKeyRef:

              name: mysecret

              key: username

        – name: TEST_PASSWORD

          valueFrom:

            secretKeyRef:

              name: mysecret

              key: password

kubernetes.io/dockerconfigjson

使用 kubectl 创建 docker registry 认证的 secret

kubectl create secret docker-registry myregistrykey –docker-server=test.k8s.com –docker-username=admin –docker-password=Harbor12345 –docker-email=[eamiladress]

yaml 文件:

[root@k8s-master01 secret]# cat reg.yaml

apiVersion: v1

kind: Pod

metadata:

  name: registry-test

spec:

  containers:

    – name: registry1

      image: test.k8s.com/test/myapp:v2

  imagePullSecrets:

    – name: myregistrykey

Volume

容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet

会重启它,但是容器中的文件将丢失 —— 容器以干净的状态(镜像最初的状态)重新启动。其次,在 `Pod` 中同时运行多个

容器时,这些容器之间通常需要共享文件。kubernetes 中的 `Volume` 抽象就很好的解决了这些问题

背景

Kubernetes 中的卷有明确的寿命 —- 与封装它的 Pod 相同。所以,卷的生命比 Pod 中的所有容器都长,当这个容器重启时数据仍然

得以保存。当然,当 Pod 不在存在时,卷也将不复存在。还有更重要的是,Kubernetes 支持多种类型的卷,Pod 可以同时使用任意数量的卷

卷的类型:

Kubernetes 支持以下类型的卷:

  • awsElasticBlockStore、azureDisk、azureFile、cephfs、cinder、configMap、csi
  • downwardAPI、emptyDir、fc (fibre channel)、flexVolume、flocker、gcePersistentDisk
  • gitRepo (deprecated)、glusterfs、hostPath、iscsi、local、nfs、persistentVolumeClaim
  • projected、portworxVolume、quobyte、rbd、scaleIO、secret、storageos、vsphereVolume

emptyDir

当 Pod 被分配给节点时,首先创建 `emptyDir` 卷,并且只要该 Pod 在该节点上运行,该卷就会存在。正如卷的

名字所述,它最初是空的。Pod 中的容器可以读取和写入 `emptyDir` 卷中的相同文件,尽管该卷可以挂载到

每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时,`emptyDir` 中的数据将被永久删除

注:容器崩溃不会从节点中移除 pod,因此 `emptyDir` 卷中的数据在容器崩溃时是安全的

emptyDir 的用法有:

  • 暂存空间,例如用于基于磁盘的合并排序
  • 用作长时间计算崩溃恢复时的检查点
  • Web 服务器容器提供数据时,保存内容管理器容器提取的文件

[root@k8s-master01 volume]# cat emptydir.yaml

apiVersion: v1

kind: Pod

metadata:

  name: test-pd1

spec:

  containers:

  – image: wangyanglinux/myapp:v1

    name: test-container

    volumeMounts:

    – mountPath: /cache

      name: cache-volume

  – name: liveness-exec-container

    image: library/busybox

    imagePullPolicy: IfNotPresent

    command: [“/bin/sh”,”-c”,”sleep 3600″]

    volumeMounts:

    – mountPath: /test

      name: cache-volume

  volumes:

  – name: cache-volume

    emptyDir: {}

分别在 Pod 内查看两个容器

kubectl exec test-pd1 -c liveness-exec-container -it — /bin/sh

kubectl exec test-pd1 -c test-container -it — /bin/sh

分别 echo 内容进目录的同一文件,查看验证

/cache # date >> index.html

/cache # cat index.html

Sat Jun  6 14:57:14 UTC 2020

Sat Jun  6 14:58:08 UTC 2020

Sat Jun  6 15:01:44 UTC 2020

/test # date >> index.html

/test #  cat index.html

Sat Jun  6 14:57:14 UTC 2020

Sat Jun  6 14:58:08 UTC 2020

Sat Jun  6 15:01:44 UTC 2020

Sat Jun  6 15:02:15 UTC 2020

hostPath

将主机节点的文件系统中的文件或目录挂载到集群中

hostPath 的用途:

  • 运行需要访问 Docker 内部的容器;使用 `/var/lib/docker` 的 `hostPath`
  • 在容器中运行 CAdvisor;使用 /dev/cgroups 的 hostPath

除了所需的 Path 属性之外,用户还可以为 hostPath 卷指定 type

K8S 存储

使用这种卷类型

  • 具有相同配置(例如从 podTemplate 创建)的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。
  • 当 Kubernetes 按照计划添加资源感知的调度时,这类调度机制将无法考虑由 hostPath 使用的资源。
  • 基础主机上创建的文件或目录只能由 root 用户写入。您需要在 特权容器 中以 root 身份运行进程,或者修改主机上的文件权限以便容器能够写入 hostPath 卷。

1、在所有 node 上创建 /data 目录后再启用 yaml

[root@k8s-master01 volume]# cat hostPath.yaml

apiVersion: v1

kind: Pod

metadata:

  name: test-pd

spec:

  containers:

  – image: wangyanglinux/myapp:v1

    name: test-container

    volumeMounts:

    – mountPath: /test-pd

      name: test-volume

  volumes:

  – name: test-volume

    hostPath:

      # directory location on hots

      path: /data

      # this field is optional

      type: Directory

验证:

在 Pod 的 /test-pd 目录下创建文件,然后在 node 上的 /data 目录看是否存在;在 /data 目录里面创建也可在 Pod 内生效

存储 PV 和 PVC

PV

是由管理员设置的存储,它是集群的一部分。就像节点是集群中的资源一样,PV 也是集群中的资源。PV 是 Volume 之类的

卷插件,但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节,即 NFS、iSCSI 或特定于与供应商的存储系统

PVC

是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源,PVC 消耗 PV 资源。Pod 可以请求特定级别的资源(CPU 和内存)。声明可以请求特定的大小和访问模式(例如,可以以读 / 写一次或只读多次模式挂载)

静态

集群管理员创建一些 PV。它们带有可供集群用户使用的实际存储的细节。它们存在于 Kubernetes API 中,可用于消费

动态

当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时,集群可能会尝试动态的为 PVC 创建卷。此配置基于

StorageClasses:PVC 必须请求 [存储类],并且管理员必须创建并配置该类才能进行动态创建。声明该类为 ”” 可以有效的

禁用其动态配置

要启用基于存储级别的动态存储配置,集群管理员需要启用 API server 上的 DefaultStorageClass[准入控制器]。例如:

通过确保 DefaultStorageClass 位于 API server 组件的 –admission-control 标志,使用逗号分隔的有序值列表中,

可以完成此操作

绑定

master 中的控制环路监视新的 PVC,寻找匹配的 PV(如果可能),并将它们绑定在一起。如果为新的 PVC 动态调配 PV,

则该环路将始终将 PV 绑定到 PVC。否则,用户总会得到他们所请求的存储,但是容量可能超出要求的数量。一旦 PV 和 PVC

绑定后,PersistentVolumeClaim 绑定是排他性的,不管它们是如何绑定的。PVC 跟 PV 绑定是一对一的映射

使用中保护 Storage Object in Use Protection

使用中保护(Storage Object in Use Protection)的目的是确保正在被容器组使用的 PersistentVolumeClaim 以及其绑定的 PersistentVolume 不能被系统删除,以避免可能的数据丢失。

如果用户删除一个正在使用中的 PersistentVolumeClaim,则该 PVC 不会立即被移除掉,而是推迟到该 PVC 不在被任何容器组使用时才移除;同样的如果管理员删除了一个已经绑定到 PVC 的 PersistentVolume,则该 PV 也不会立刻被移除掉,而是推迟到其绑定的 PVC 被删除后才移除掉。

存储卷类型

Kubernetes 支持 20 种存储卷类型(可参考  Types of Persistent Volumes),如下所示:

  • 非持久性存储
    • emptyDir
    • HostPath (只在单节点集群上用做测试目的)
  • 网络连接性存储
    • SAN:iSCSI、ScaleIO Volumes、FC (Fibre Channel)
    • NFS:nfs,cfs
  • 分布式存储
    • Glusterfs
    • RBD (Ceph Block Device)
    • CephFS
    • Portworx Volumes
    • Quobyte Volumes
  • 云端存储
    • GCEPersistentDisk
    • AWSElasticBlockStore
    • AzureFile
    • AzureDisk
    • Cinder (OpenStack block storage)
    • VsphereVolume
    • StorageOS
  • 自定义存储
    • FlexVolume
  • 不推荐

PV 访问模式

PV 可以以资源提供者支持的任何方式挂载到主机上,如下表所示,供应商具有不同的功能,每个 PV 的访问模式都将被设置为该卷支持

的特定模式。例如,NFS 可以支持多个读 / 写客户端,但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来

描述特定功能的访问模式

  • 可被单节点读写 -ReadWriteOnce
  • 可被多节点只读 -ReadOnlyMany
  • 可被多节点读写 -ReadWriteMany
Volume Plugin ReadWriteOnce ReadOnlyMany ReadWriteMany
AWSElasticBlockStore
AzureFile
AzureDisk
CephFS
Cinder
CSI depends on the driver depends on the driver depends on the driver
FC
FlexVolume depends on the driver
Flocker
GCEPersistentDisk
Glusterfs
HostPath
iSCSI
Quobyte
NFS
RBD
VsphereVolume – (works when Pods are collocated)
PortworxVolume
ScaleIO
StorageOS

回收策略

  • 保留 Retain – 手工回收
  • 再利用 Recycle – 清除后重新可用 (rm -rf /thevolume/*)
  • 删除 Delete – 删除 PV 及存储介质

状态

卷可以处于以下的某种状态:

  • Available – 可用的 PV,尚未绑定到 PVC
  • Bound – 已经绑定到 PVC
  • Released – PVC 已经被删除,但是资源还未被集群回收
  • Failed – 自动回收失败

持久化演示:

1、安装 NFS 服务器(harbor 上安装)

 yum install -y nfs-common nfs-utils rpcbind

 mkdir /nfsdata

 chmod 666 /nfsdata/

 chown nfsnobody /nfsdata/

  cat /etc/exports

  /nfsdata *(rw,no_root_squash,no_all_squash,sync)

  systemctl start rpcbind

  systemctl enable rpcbind

  systemctl start nfs

  systemctl enable nfs

2、安装 NFS 客户端(所有节点)

yum install -y nfs-utils rpcbind

验证是否可用

showmount -e

mount -t nfs 192.168.137.198:/nfsdata /data/test

vim /data/test/1.html

umount -lf /data/test/

2、部署 PV

[root@k8s-master01 pv]# cat pv2.yaml

apiVersion: v1

kind: PersistentVolume

metadata:

  name: nfspv2

spec:

  capacity:

    storage: 5Gi

  volumeMode: Filesystem

  accessModes:

  – ReadOnlyMany

  persistentVolumeReclaimPolicy: Recycle

  storageClassName: nfs

  mountOptions:

  – hard

  – nfsvers=4.1

  nfs:

    path: /nfsdata1

    server: 192.168.137.198

apiVersion: v1

kind: PersistentVolume

metadata:

  name: nfspv3

spec:

  capacity:

    storage: 5Gi

  volumeMode: Filesystem

  accessModes:

  – ReadWriteMany

  persistentVolumeReclaimPolicy: Recycle

  storageClassName: slow

  mountOptions:

  – hard

  – nfsvers=4.1

  nfs:

    path: /nfsdata2

    server: 192.168.137.198

apiVersion: v1

kind: PersistentVolume

metadata:

  name: nfspv4

spec:

  capacity:

    storage: 1Gi

  volumeMode: Filesystem

  accessModes:

  – ReadOnlyMany

  persistentVolumeReclaimPolicy: Recycle

  storageClassName: nfs

  mountOptions:

  – hard

  – nfsvers=4.1

  nfs:

    path: /nfsdata3

    server: 192.168.137.198

[root@k8s-master01 pv]# kubectl get pv

NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM               STORAGECLASS   REASON   AGE

nfspv1   10Gi       RWO            Recycle          Bound       default/www-web-0   nfs                     45m

nfspv2   5Gi        ROX            Recycle          Available                       nfs                     30m

nfspv3   5Gi        RWX            Recycle          Available                       slow                    30m

nfspv4   1Gi        ROX            Recycle          Available                       nfs                     30m

创建服务并启用 pvc

[root@k8s-master01 pv]# cat pvc.yaml

apiVersion: v1

kind: Service

metadata:

  name: nginx

  labels:

    app: nginx

spec:

  ports:

  – port: 80

    name: web

  clusterIP: None

  selector:

    app: nginx

apiVersion: apps/v1

kind: StatefulSet

metadata:

  name: web

spec:

  selector:

    matchLabels:

      app: nginx

  serviceName: “nginx”

  replicas: 3

  template:

    metadata:

      labels:

        app: nginx

    spec:

      containers:

      – name: nginx

        image: wangyanglinux/myapp:v2

        ports:

        – containerPort: 80

          name: web

        volumeMounts:

        – name: www

          mountPath: /usr/share/nginx/html

  volumeClaimTemplates:

  – metadata:

      name: www

    spec:

      accessModes: [“ReadWriteOnce”]

      storageClassName: “nfs”

      resources:

        requests:

          storage: 1Gi

创建完成后会发现:处于 Pending 状态

[root@k8s-master01 pv]# kubectl get pods

NAME    READY   STATUS    RESTARTS   AGE

web-0   1/1     Running   0          7m1s

web-1   0/1     Pending   0          6m54s

kubectl describe web-1

  Type     Reason            Age                 From               Message

  —-     ——            —-                —-               ——-

  Warning  FailedScheduling  3s (x8 over 8m43s)  default-scheduler  running “VolumeBinding” filter plugin for pod “web-1”: pod has unbound immediate PersistentVolumeClaims

查看原因为:只有一个 pv 的 mode 是 RWO

将 pv 重新创建 将 storageclass 和 access modes 修改后即可使用

K8S 存储

关于 statefulset 有下面几点说明:

pod 的名称为 <statefulset 名称 >-< 序列号 >,序列号为 0 到 n -1

headless service 为每个 pod 创建了一个独立的域名,格式为 <pod_name>.<headless_service_name>.NAMESPACE.svc.cluster.local

pvc 的命名规则为 <pvc_name>-<pod_name>

删除 pod 不会删除其 pvc,手动删除 pvc 会自动删除 pv

彻底删除

不管是删除 pod 还是 statefulset,持久化的数据都不会消失。那么如果有一天真的想彻底销毁这些数据该如何操作呢?

首先删除 statefulset,直接利用 yaml 文件即可

[root@k8s-master pv]# kubectl delete -f pvc.yaml

service “nginx” deleted

statefulset.apps “web” deleted

[root@k8s-master pv]# kubectl get pod

No resources found.

[root@k8s-master pv]# kubectl get svc

NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE

kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   14d

但是此时 pv 和 pvc 都还在

[root@k8s-master pv]# kubectl get pv

NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                            STORAGECLASS   REASON   AGE

test-pv-nfs1   5Gi        RWO            Retain           Bound    default/www-test-statefulset-1   gold                    8h

test-pv-nfs2   8Gi        RWO            Retain           Bound    default/www-test-statefulset-2   gold                    8h

test-pv-nfs3   10Gi       RWO            Retain           Bound    default/www-test-statefulset-0   gold                    8h

[root@k8s-master pv]# kubectl get pvc

NAME        STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE

www-web-0   Bound    nfspv4   2Gi        RWO            nfs            66m

www-web-1   Bound    nfspv3   5Gi        RWO            nfs            66m

www-web-2   Bound    nfspv1   10Gi       RWO            nfs            66m

然后删除 pvc,之后 pv 变为 Released 状态

[root@k8s-master pv]# kubectl delete pvc –all

persistentvolumeclaim “www-web-0” deleted

persistentvolumeclaim “www-web-1” deleted

persistentvolumeclaim “www-web-2” deleted

[root@k8s-master01 pv]# kubectl get pv

NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE

nfspv1   10Gi       RWO            Recycle          Available           nfs                     71m

nfspv2   5Gi        ROX            Recycle          Available           nfs                     71m

nfspv3   5Gi        RWO            Recycle          Available           nfs                     67m

nfspv4   2Gi        RWO            Recycle          Available           nfs                     67m

若此时这些 pv 还不能变为 Available,需要手动删除 pv 中的 pvc 信息,也就是 claimRef 部分

[root@k8s-master pv]# kubectl edit pv/test-pv-nfs1

persistentvolume/test-pv-nfs1 edited

[root@k8s-master pv]# kubectl get pv

NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                            STORAGECLASS   REASON   AGE

test-pv-nfs1   5Gi        RWO            Retain           Available                                    gold                    8h

test-pv-nfs2   8Gi        RWO            Retain           Released    default/www-test-statefulset-2   gold                    8h

test-pv-nfs3   10Gi       RWO            Retain           Released    default/www-test-statefulset-0   gold                    8h

依次删除 3 个 pv 中的 pvc 信息一直到都为 Available 状态

[root@k8s-master pv]# kubectl get pv

NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE

nfspv1   10Gi       RWO            Recycle          Available           nfs                     164m

nfspv2   5Gi        ROX            Recycle          Available           nfs                     164m

nfspv3   5Gi        RWO            Recycle          Available           nfs                     160m

nfspv4   2Gi        RWO            Recycle          Available           nfs                     160m

正文完
 0
评论(没有评论)
验证码