k8s 十之PV和PVC_k8s 等待pv完成再运行

PV及PVC介绍

• PersistentVolume（持久卷，简称PV） 是集群内，由管理员提供的网络存储的一部分。就像集群中的节点一样，PV也是集群中的一种资源。它也像Volume一样，是一种volume插件，但是它的生命周期却是和使用它的Pod相互独立的。PV这个API对象，捕获了诸如NFS、ISCSI、或其他云存储系统的实现细节。
• PersistentVolumeClaim（持久卷声明，简称PVC） 是用户的一种存储请求。它和Pod类似，Pod消耗Node资源，而PVC消耗PV资源。Pod能够请求特定的资源（如CPU和内存）。PVC能够请求指定的大小和访问的模式（可以被映射为一次读写或者多次只读）。
• 有两种PV提供的方式： 静态和动态
  （1）静态PV：集群管理员创建多个PV，它们携带着真实存储的详细信息，这些存储对于集群用户是可用的。它们存在于Kubernetes API中，并可用于存储使用。
  （2）动态PV：当管理员创建的静态PV都不匹配用户的PVC时，集群可能会尝试专门地供给volume给PVC。这种供给基于StorageClass。
• PVC与PV的绑定是一对一的映射 没找到匹配的PV，那么PVC会无限期得处于unbound未绑定状态。
• 使用
  Pod使用PVC就像使用volume一样。集群检查PVC，查找绑定的PV，并映射PV给Pod。对于支持多种访问模式的PV，用户可以指定想用的模式。一旦用户拥有了一个PVC，并且PVC被绑定，那么只要用户还需要，PV就一直属于这个用户。用户调度Pod，通过在Pod的volume块中包含PVC来访问PV。
• 释放
  当用户使用PV完毕后，他们可以通过API来删除PVC对象。当PVC被删除后，对应的PV就被认为是已经是“released”了，但还不能再给另外一个PVC使用。前一个PVC的属于还存在于该PV中，必须根据策略来处理掉。
• 回收
  PV的回收策略告诉集群，在PV被释放之后集群应该如何处理该PV。当前，PV可以被Retained（保留）、 Recycled（再利用）或者Deleted（删除）。保留允许手动地再次声明资源。对于支持删除操作的PV卷，删除操作会从Kubernetes中移除PV对象，还有对应的外部存储（如AWS EBS，GCE PD，Azure Disk，或者Cinder volume）。动态供给的卷总是会被删除。
• 访问模式
  （1）ReadWriteOnce – 该volume只能被单个节点以读写的方式映射
  （2）ReadOnlyMany – 该volume可以被多个节点以只读方式映射
  （3）ReadWriteMany – 该volume可以被多个节点以读写的方式映射
  在命令行中，访问模式可以简写为：
  （1）RWO - ReadWriteOnce
  （2）ROX - ReadOnlyMany
  （3）RWX - ReadWriteMany
• 回收策略
  （1）Retain：保留，需要手动回收。
  （2）Recycle：回收，自动删除卷中数据。
  （3）Delete：删除，相关联的存储资产，如AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷都会被删除。
  （4）当前，只有NFS和HostPath支持回收利用，AWS EBS，GCE PD，Azure Disk，or OpenStack Cinder卷支持删除操作。
• 状态
  （1）Available：空闲的资源，未绑定给PVC。
  （2）Bound：绑定给了某个PVC
  （3）Released：PVC已经删除了，但是PV还没有被集群回收。
  （4）Failed：PV在自动回收中失败了
  （5）命令行可以显示PV绑定的PVC名称

创建NFS的PV和PVC示例

注意：在做实验前需要安装配置NFS服务 详细内容见上节k8s九。
1.首先清理环境
kubectl get pod 
kubectl delete -f nfs.yaml
kubectl get pod 
kubectl get pv
kubectl get pvc

2.编写文件
vim pv.yaml  
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  mountOptions: 
    - hard 
    - nfsvers=4.1
  nfs:
    path: /nfsdata
    server: 192.168.20.10      
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv2
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  mountOptions: 
    - hard 
    - nfsvers=4.1
  nfs:
    path: /nfsdata
    server: 192.168.20.10  
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv3
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadOnlyMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  mountOptions: 
    - hard 
    - nfsvers=4.1
  nfs:
    path: /nfsdata
    server: 192.168.20.10

3.运行文件
kubectl apply -f pv.yaml

4.查看pv
kubectl get pv

5.创建pvc
vim pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim       ##pvc模式
metadata:
  name: pvc1
spec:
  storageClassName: nfs
  accessModes:
    - ReadWriteOnce               ##单点读写
  resources:
    requests:
      storage: 5Gi

6.运行文件
kubectl apply -f pvc.yaml 

7.查看pvc和pv
kubectl get pvc
kubectl get pv

8.创建pod
vim pod1.yaml
apiVersion: v1                    ## 创建pod
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: myapp:v1
    name: nginx
    volumeMounts:
    - mountPath: /usr/share/nginx/html
      name: pv1
  volumes:
  - name: pv1
    persistentVolumeClaim:
      claimName: pvc1

9.运行文件
kubectl apply -f pod1.yaml

10.查看pod
kubectl get pod
kubectl get pod -o wide

11.测试
curl 10.244.1.84

12.修改容器内页面
kubectl exec -it test-pd -- sh
cd /usr/share/nginx/html
echo www.linux.org > index.html

13.查看/nfsdata
发现/nfsdata同步发生了变化

14.删除pod再重建
kubectl delete pod test-pd
kubectl apply -f pod1.yaml
kubectl get pod
kubectl get pod -o wide

15.测试
curl 10.244.1.85
当删除pod后再重建pod，我们发现仍可以访问原来的资源，即体现了持久化。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139

首先清理环境

创建多个pv





pvc1和pv1已经成功绑定

创建pod


在上一篇博客时已经添加了首页，这里直接用。

访问成功

我们可以修改容器内页面

发现/nfsdata同步发生了变化

当删除pod后再重建pod，我们发现仍可以访问原来的资源，即体现了持久化。

StorageClass

StorageClass介绍

• StorageClass提供了一种描述存储类（class）的方法，不同的class可能会映射到不同的服务质量等级和备份策略或其他策略等。
• 每个 StorageClass 都包含 provisioner、parameters 和 reclaimPolicy 字段， 这些字段会在StorageClass需要动态分配 PersistentVolume 时会使用到。
• StorageClass的属性
  （1）Provisioner（存储分配器）： 用来决定使用哪个卷插件分配 PV，该字段必须指定。可以指定内部分配器，也可以指定外部分配器。外部分配器的代码地址为： kubernetes-incubator/external-storage，其中包括NFS和Ceph等。
  （2）Reclaim Policy（回收策略）： 通过reclaimPolicy字段指定创建的Persistent Volume的回收策略，回收策略包括：Delete 或者 Retain，没有指定默认为Delete。
  （3）更多属性： 查看 storage-classes官网
• NFS Client Provisioner是一个automatic provisioner，使用NFS作为存储，自动创建PV和对应的PVC，本身不提供NFS存储，需要外部先有一套NFS存储服务。
  （1）PV以 $ {namespace}-$ {pvcName}-$ {pvName}的命名格式提供（在NFS服务器上）
  （2）PV回收的时候以 archieved-$ {namespace}-$ {pvcName}-$ {pvName} 的命名格式（在NFS服务器上）
  （3）nfs-client-provisioner源码地址

StorageClass部署

1.创建目录
mkdir nfs
cd nfs

2.创建ns
kubectl create namespace nfs-client-provisioner
kubectl get namespaces

3.编写文件
vim nfs-client-provisioner.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: nfs-client-provisioner
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: nfs-subdir-external-provisioner:v4.0.0
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 192.168.20.10
            - name: NFS_PATH
              value: /nfsdata
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.20.10
            path: /nfsdata
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "true"

4.拉取镜像并放到仓库（没有harbor的直接本地拉取，我这次是直接本地下载拉取的）
docker pull heegor/nfs-subdir-external-provisioner:v4.0.0
docker tag heegor/nfs-subdir-external-provisioner:v4.0.0 www.lyueyue.org/library/nfs-subdir-external-provisioner:v4.0.0
docker push www.lyueyue.org/library/nfs-subdir-external-provisioner:v4.0.0

5.运行文件
kubectl apply -f nfs-client-provisioner.yaml

6.查看pod和StorageClass
kubectl get pod -n nfs-client-provisioner
kubectl get sc    

7.编写pvc.yaml
vim pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim
spec:
  storageClassName: managed-nfs-storage
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

8.运行pvc.yaml
kubectl apply -f pvc.yaml

9.查看pv和pvc
kubectl get pv
kubectl get pvc 

10.删除pvc.yaml
kubectl delete -f pvc.yaml

11.测试
查看/nfsdata
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162

注意：记得server2和server3也要拉取镜像如下