kubernetes1.5.2-0.7存储Volume mounts

最新推荐文章于 2023-11-08 16:47:50 发布

Michaelwubo

最新推荐文章于 2023-11-08 16:47:50 发布

阅读量1.3k

点赞数

本文链接：https://blog.csdn.net/Michaelwubo/article/details/107998395

版权

kubernetes-master-1.5.2-0.7 版本测试的

https://www.jianshu.com/p/99e610067bc8

https://www.jianshu.com/p/25b5e9faed2a

https://blog.csdn.net/cloudman6/article/details/79846892

volume中的本地本地数据卷和网络数据卷：

1.本地数据卷：emptyDir、hostPath
2.网络数据卷：NFS

3.GCE Persistent Disk、AWS Elastic Block Store，Ceph

4.PersistentVolume & PersistentVolumeClaim

本节我们讨论 Kubernetes 的存储模型 Volume，学习如何将各种持久化存储映射到容器。

我们经常会说：容器和 Pod 是短暂的。
其含义是它们的生命周期可能很短，会被频繁地销毁和创建。容器销毁时，保存在容器内部文件系统中的数据都会被清除。

为了持久化保存容器的数据，可以使用 Kubernetes Volume。

Volume 的生命周期独立于容器，Pod 中的容器可能被销毁和重建，但 Volume 会被保留。

本质上，Kubernetes Volume 是一个目录，这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod，Pod 中的所有容器都可以访问这个 Volume。Kubernetes Volume 也支持多种 backend 类型，包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等，完整列表可参考 https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes

Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说，所有类型的 Volume 都只是一个目录。

我们将从最简单的 emptyDir 开始学习 Kubernetes Volume。

emptyDir

emptyDir 是最基础的 Volume 类型。正如其名字所示，一个 emptyDir Volume 是 Host 上的一个空目录。且无需指定宿主机上对应的目录，kubernetes会自动分配一个随机的目录。

emptyDir Volume 对于容器来说是持久的，对于 Pod 则不是。当 Pod 从节点删除时，Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在，则 Volume 不受影响。

也就是说：emptyDir Volume 的生命周期与 Pod 一致。

Pod 中的所有容器都可以共享 Volume，它们可以指定各自的 mount 路径。下面通过例子来实践 emptyDir，配置文件如下：

apiVersion: v1
kind: Pod
metadata:
  name: producer-consumer
spec:
  containers:
  - image: busybox
    name: producer
    volumeMounts:
    - mountPath: /producer_dir
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - echo "hello world" > /producer_dir/hello ; sleep 30000

  - image: busybox
    name: consumer
    volumeMounts:
    - mountPath: /consumer_dir
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - cat /consumer_dir/hello ; sleep 30000

  volumes:
  - name: shared-volume
    emptyDir: {}

这里我们模拟了一个 producer-consumer 场景。Pod 有两个容器 producer和 consumer，它们共享一个 Volume。producer 负责往 Volume 中写数据，consumer 则是从 Volume 读取数据。

① 文件最底部 volumes 定义了一个 emptyDir 类型的 Volume shared-volume。

② producer 容器将 shared-volume mount 到 /producer_dir 目录。

③ producer 通过 echo 将数据写到文件 hello 里。

④ consumer 容器将 shared-volume mount 到 /consumer_dir 目录。

⑤ consumer 通过 cat 从文件 hello 读数据。

执行如下命令创建 Pod：

kubectl apply -f emptyDir.yml

kubectl logs 显示容器 consumer 成功读到了 producer 写入的数据，验证了两个容器共享 emptyDir Volume。

[root@master1] ~$ kubectl logs producer-consumer consumer
hello world

因为 emptyDir 是 Docker Host 文件系统里的目录，其效果相当于执行了 docker run -v /producer_dir 和 docker run -v /consumer_dir。通过 docker inspect 查看容器的详细配置信息，我们发现两个容器都 mount 了同一个目录：

#producer
{
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/29371fb1-246b-11e9-be96-00505638a42b/volumes/kubernetes.io~empty-dir/shared-volume",
                "Destination": "/producer_dir",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },

#consumer
{
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/29371fb1-246b-11e9-be96-00505638a42b/volumes/kubernetes.io~empty-dir/shared-volume",
                "Destination": "/consumer_dir",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            },

这里 /var/lib/kubelet/pods/3e6100eb-a97a-11e7-8f72-0800274451ad/volumes/kubernetes.io~empty-dir/shared-volume 就是 emptyDir 在 Host 上的真正路径。

emptyDir 是 Host 上创建的临时目录，其优点是能够方便地为 Pod 中的容器提供共享存储，不需要额外的配置。但它不具备持久性，如果 Pod 不存在了，emptyDir 也就没有了。根据这个特性，emptyDir 特别适合 Pod 中的容器需要临时共享存储空间的场景，比如前面的生产者消费者用例。

hostPath Volume
hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。

比如 kube-apiserver 和 kube-controller-manager 就是这样的应用，通过

kubectl edit --namespace=kube-system pod kube-apiserver-master1.hanli.com
查看 kube-apiserver Pod 的配置，下面是 Volume 的相关部分：

volumeMounts:
    - mountPath: /etc/ssl/certs
      name: ca-certs
      readOnly: true
    - mountPath: /etc/pki
      name: etc-pki
      readOnly: true
    - mountPath: /etc/kubernetes/pki
      name: k8s-certs
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  hostNetwork: true
  nodeName: master1.hanli.com
  priority: 2000000000
  priorityClassName: system-cluster-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    operator: Exists
  volumes:
  - hostPath:
      path: /etc/ssl/certs
      type: DirectoryOrCreate
    name: ca-certs
  - hostPath:
      path: /etc/pki
      type: DirectoryOrCreate
    name: etc-pki
  - hostPath:
      path: /etc/kubernetes/pki
      type: DirectoryOrCreate
    name: k8s-certs

这里定义了三个 hostPath volume k8s、certs 和 pki，分别对应 Host 目录 /etc/kubernetes、/etc/ssl/certs 和 /etc/pki。

如果 Pod 被销毁了，hostPath 对应的目录也还会被保留，从这点看，hostPath 的持久性比 emptyDir 强。不过一旦 Host 崩溃，hostPath 也就没法访问了。

hostPath

root@localhost:~/work/k8s/pods/kuber/volumeTest # cat hostpath.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: test-hostpath
spec:
  containers:
  - image: hub.c.163.com/sachiel/webserver:last
    name: test-hostpath-container
    volumeMounts:
    - mountPath: /hostpath
      name: hostpath
  volumes:
  - name: hostpath
    hostPath:
      path: /hostpath

下一节我们将学习具备真正持久性的 Volume。

NFS

yum install -y nfs-utils

[root@master volume]# cat /etc/export
/opt/container_data 192.168.1.0/24(rw,no_root_squash)

此时，我们在客户端的时候，不用刻意去用mount 挂载，因为k8s会帮我们自动挂载
nfs部署yaml文件：

[root@master volume]# cat nfs.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        #启用数据卷的名字为wwwroot,并挂载到nginx的html目录下
        volumeMounts:
        - name: wwwroot
          mountPath: /usr/share/nginx/html
        ports:
        - containerPort: 80
    #定义数据卷名字为wwwroot,类型为nfs
      volumes:
      - name: wwwroot
        nfs:
          server: 192.168.1.39
          path: /opt/container_data

kubectl create -f nfs.yaml

ceph

如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上，可以直接使用云硬盘作为 Volume，下面是 AWS Elastic Block Store 的例子：

要在 Pod 中使用 ESB volume，必须先在 AWS 中创建，然后通过 volume-id 引用。其他云硬盘的使用方法可参考各公有云厂商的官方文档。

在这里插入图片描述

Kubernetes Volume 也可以使用主流的分布式存，比如 Ceph、GlusterFS 等，下面是 Ceph 的例子：

Ceph 文件系统的 /some/path/in/side/cephfs 目录被 mount 到容器路径 /test-ceph。

相对于 emptyDir 和 hostPath，这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。

当然，运维这样的存储系统通常不是项简单的工作，特别是对可靠性、高可用和扩展性有较高要求时。

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。下一节我们将学习具有更高管理性的存储方案：PersistentVolume & PersistentVolumeClaim。

PersistentVolume & PersistentVolumeClaim。

Volume 提供了非常好的数据持久化方案，不过在可管理性上还有不足。

拿前面 AWS EBS 的例子来说，要使用 Volume，Pod 必须事先知道如下信息：

当前 Volume 来自 AWS EBS。

EBS Volume 已经提前创建，并且知道确切的 volume-id。

Pod 通常是由应用的开发人员维护，而 Volume 则通常是由存储系统的管理员维护。开发人员要获得上面的信息：

要么询问管理员。

要么自己就是管理员。

这样就带来一个管理上的问题：应用开发人员和系统管理员的职责耦合在一起了。如果系统规模较小或者对于开发环境这样的情况还可以接受。但当集群规模变大，特别是对于生成环境，考虑到效率和安全性，这就成了必须要解决的问题。

Kubernetes 给出的解决方案是 PersistentVolume 和 PersistentVolumeClaim。

PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。

PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

有了 PersistentVolumeClaim，用户只需要告诉 Kubernetes 需要什么样的存储资源，而不必关心真正的空间从哪里分配，如何访问等底层细节信息。这些 Storage Provider 的底层信息交给管理员来处理，只有管理员才应该关心创建 PersistentVolume 的细节信息。

Kubernetes 支持多种类型的 PersistentVolume，比如 AWS EBS、Ceph、NFS 等，完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

NFS

下节我们用 NFS 来体会 PersistentVolume 的使用方法。
上一节我们介绍了 PV 和 PVC，本节通过 NFS 实践。

作为准备工作，我们已经在 master1 节点上搭建了一个 NFS 服务器，目录为 /opt/software,并在目录中创建一个pv1文件夹

下面创建一个 PV mypv1，配置文件 nfs-pv1.yml 如下：

root@localhost:~/work/k8s/pods/kuber/volumeTest # cat nfs-pv1.yml 
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv1
  labels:
    name: mypv1
spec: 
  capacity: 
    storage: 5Gi 
  accessModes:
    - ReadWriteOnce #ReadWriteOnce:能以 read-write 模式 mount 到单个节点;ReadOnlyMany:能以 read-only 模式 mount 到多个节点,ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle #指定当 PV 的回收策略.Retain :需要管理员手工回收;Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。Delete:删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等
  #storageClassName: slow #slow #storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
  nfs: 
    path: /home/pv #指定 PV 在 NFS 服务器上对应的目录
    server: 10.10.3.197
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv2
  labels:
    name: mypv2
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/pv/pv2
    server: 10.10.3.197
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv3
  labels:
    name: mypv3
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/pv/pv3
    server: 10.10.3.197
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv4
  labels:
    name: mypv4
spec:
  capacity:
    storage: 7Gi
  accessModes:
    - ReadWriteOnce
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /home/pv/pv4
    server: 10.10.3.197

① capacity 指定 PV 的容量为 1G。

② accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。

③ persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain – 需要管理员手工回收。
Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

④ storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。

⑤ 指定 PV 在 NFS 服务器上对应的目录。

创建 mypv1：

kubectl apply -f nfs-pv1.yml

STATUS 为 Available，表示 mypv1 就绪，可以被 PVC 申请。

接下来创建 PVC mypvc1，配置文件 nfs-pvc1.yml 如下：

root@localhost:~/work/k8s/pods/kuber/volumeTest # cat nfs-pvc1.yml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata: 
  namespace: kube-system
  name: mypvc1
spec: 
  accessModes: 
    - ReadWriteOnce
    - ReadWriteMany
  resources:
    requests: 
      storage: 2Gi
  selector:
    matchLabels: 
      name: mypv1

PVC 就很简单了，只需要指定 PV 的容量，访问模式和 class。

这里遇到一个问题，开始建立的pv死活claim为空，查看pv以及pvc的配置发现并没有任何名称上的关联，继续研究，发现纯粹是通过storage大小进行匹配的，之前因为照抄书本，一个是5G,一个是8G所以就无法匹配了，修改后成功

创建 mypvc1：

kubectl apply -f nfs-pvc1.yml

从 kubectl get pvc 和 kubectl get pv 的输出可以看到 mypvc1 已经 Bound 到 mypv1，申请成功。

接下来就可以在 Pod 中使用存储了，Pod 配置文件 pod1.yml 如下：

root@localhost:~/work/k8s/pods/kuber/volumeTest # cat pod1.yml                                                                                                                                                                    kind: Pod
apiVersion: v1
metadata:
  namespace: kube-system
  name: mypod1
spec:
  containers:
    - name: mypod1
      image: harbor.superred.com/kubernetes/busybox
      args:
      - /bin/sh
      - -c
      - touch /mydata/wubo&&sleep 30000
      volumeMounts:
      - mountPath: /mydata
        name: mydata
        subPath: mysubpath
    - name: php
      image: php
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
  volumes:
    - name: mydata
      persistentVolumeClaim:
        claimName: mypvc1

注意PV没有namespace，pvc有namespace，pod的namespace要和pvc的namespace一样才可以在pod中使用pvc

subPath：作用会在

与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 mypvc1 申请的 Volume。

创建 mypod1：mypvc1对应的磁盘卷上创建两个目录mysubpath和html，两个容器bind一个卷会造成数据混乱，所以分开目录了

kubectl apply -f pod1.yml

验证 PV 是否可用：

[root@master1] /opt/software$ kubectl exec mypod1 touch /mydata/hello

[root@master1] /opt/software$ ls /opt/softwar/pv1/
hello

可见，在 Pod 中创建的文件 /mydata/hello 确实已经保存到了 NFS 服务器目录 /nfsdata/pv1 中。

PV的生命周期
PV的生命周期包括 5 个阶段：

Provisioning，即 PV 的创建，可以直接创建 PV（静态方式），也可以使用 StorageClass 动态创建
Binding，将 PV 分配给 PVC
Using，Pod 通过 PVC 使用该 Volume，并可以通过准入控制 StorageProtection（1.9及以前版本为PVCProtection）阻止删除正在使用的 PVC
Releasing，Pod 释放 Volume 并删除 PVC
Reclaiming，回收 PV，可以保留 PV 以便下次使用，也可以直接从云存储中删除
Deleting，删除 PV 并从云存储中删除后段存储
根据这 5 个阶段，PV 的状态有以下 4 种

Available：可用
Bound：已经分配给 PVC
Released：PVC 解绑但还未执行回收策略
Failed：发生错误
一个PV从创建到销毁的具体流程如下：

一个PV创建完后状态会变成Available，等待被PVC绑定。
一旦被PVC邦定，PV的状态会变成Bound，就可以被定义了相应PVC的Pod使用。
Pod使用完后会释放PV，PV的状态变成Released。
变成Released的PV会根据定义的回收策略做相应的回收工作。有三种回收策略，Retain、Delete 和 Recycle。Retain就是保留现场，K8S什么也不做，等待用户手动去处理PV里的数据，处理完后，再手动删除PV。Delete 策略，K8S会自动删除该PV及里面的数据。Recycle方式，K8S会将PV里的数据删除，然后把PV的状态变成Available，又可以被新的PVC绑定使用。

如果不再需要使用 PV，可用删除 PVC 回收 PV，下节我们详细讨论。

root@localhost:~/work/k8s/pods/kuber/volumeTest # kubectl delete -f pod1.yml                             
pod "mypod1" deleted
root@localhost:~/work/k8s/pods/kuber/volumeTest # kubectl delete -f nfs-pvc1.yml 
persistentvolumeclaim "mypvc1" deleted

Every 2.0s: kubectl get pv,pvc -o wide                                                                                                                                                                        Fri Aug 14 03:20:02 2020

NAME	  CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM                REASON    AGE
mypv1     3Gi        RWO,RWX	   Retain          Released    kube-system/mypvc1             28m
mypv2     2Gi        RWO,RWX	   Retain          Available                                  28m
mypv3     5Gi        RWO,RWX	   Retain          Available                                  28m
mypv4     7Gi        RWO,RWX	   Retain          Available                                  28m

此时Released 状态是pvc释放了但是pv没有任何操作呢。PVC 被删除，但是资源还未被集群重新声明。还不可以pvc申请pv使用，需要把状态Released转化为Available才可以

以下是转换

KUBE_EDITOR="vim" kubectl edit pv mypv1  --output-version=v1


# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/bound-by-controller: "yes"
  creationTimestamp: 2020-08-14T06:51:50Z
  labels:
    name: mypv1
  name: mypv1
  resourceVersion: "125451"
  selfLink: /api/v1/persistentvolumes/mypv1
  uid: a10b7413-ddfa-11ea-8d86-52540002328d
spec:
  accessModes:
  - ReadWriteOnce
  - ReadWriteMany
  capacity:
    storage: 3Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: mypvc1
    namespace: kube-system
    resourceVersion: "125449"
    uid: 0eff70c9-ddfc-11ea-8d86-52540002328d
  nfs:
    path: /home/pv/pv1
    server: 10.10.3.197
  persistentVolumeReclaimPolicy: Retain
status:
  phase: Bound

把claimRef到nfs全都删除，此时就变成了Available状态了

清理pc pcv 策略

https://blog.csdn.net/cloudman6/article/details/79846892

https://www.cnblogs.com/zhenyuyaodidiao/p/6632600.html

清理策略

Retain – 需要管理员手工回收。安全不会删除但是需要手动处理pv状态上面有介绍
Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。插件：nfs和hostpath支持，其余不支持。不安全删除pvc pv对应的数据也都删除了
Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等

测试案例

上面创建ok之后

会在nfs下面发现文件

此时pv的策略是Recycle。然后执行kubectl delete -f nfs-pvc1.yml，此时会下载

已经绑定的pv可以被删除，删除后对应的pvc仍为Bound状态。如有pod正在使用则仍可使用。如无pod使用，则创建pod时会出现错误。
pv可以在绑定后被编辑（如访问模式，容量），导致信息与对应的pvc不一致。
使用Recycle策略回收nfs pv时，k8s会创建一个pod，该pod使用gcr.io/google_containers/busybox镜像和command [“/bin/sh”, “-c”, ‘test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z “$(ls -A /scrub)” || exit 1’]来清除数据。目前没找到官方的修改该pod的方法，或许可通过kube-controller-manager的–pv-recycler-pod-template-filepath-nfs选项来设置。

root@localhost:/etc/kubernetes # cat controller-manager 
###
# The following values are used to configure the kubernetes controller-manager

# defaults from config and apiserver should be adequate

# Add your own!
KUBE_CONTROLLER_MANAGER_ARGS="--pv-recycler-pod-template-filepath-nfs=/etc/kubernetes/recycler.yaml --pv-recycler-pod-template-filepath-hostpath=/etc/kubernetes/recycler.yaml"

root@localhost:/etc/kubernetes # cat recycler.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler-
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "harbor.superred.com/google/busybox:latest"
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

systemctl restart kube-controller-manager;systemctl status kube-controller-manager

此时重新在执行kubectl delete -f nfs-pvc1.yml就可以删除数据而且pv的状态也会变成Available状态，但是数据没有了不安全呀~~~

注意pv回收策略且只有删除pvc的时候数据才会删除。删除pv和pod数据都不会删除且pv的状态也不会发生变化

Michaelwubo

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
kubernetes1.5.2-0.7存储Volume mounts

kubernetes-master-1.5.2-0.7 版本测试的https://www.jianshu.com/p/99e610067bc8volume中的本地本地数据卷和网络数据卷：1.本地数据卷：emptyDir、hostPath2.网络数据卷：NFS3.GCE Persistent Disk、AWS Elastic Block Store，Ceph4.PersistentVolume & PersistentVolumeClaim本节我们讨论 Kubernet.
复制链接

扫一扫