「走进k8s」Kubernetes1.15.1的持久化存储PVC（32）
上次学习了 PV 的使用，但是真正使用的时候使用 PVC，类似JAVA我们操作的都是对象的而不是对应的类， Pod 来运行的，而不是 Node。只是 Pod 跑在 Node 上而已。
（一）新建PVC
- ① 新建pvc
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-nfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
上次新建的pv，查看了之前的pv的状态，当pvc创建之后的时候，自动关联对应的pv。系统自动帮去匹配的，它会根据声明要求去查找处于 Available 状态的 PV，如果没有找到的话那么 PVC 就会一直处于 Pending 状态，找到了的话当然就会把当前的 PVC 和目标 PV 进行绑定，这个时候状态就会变成 Bound 状态了。
kubectl get pv kubectl create -f pvc-nfs.yaml kubectl get pv
如果没有对应的pv的话，新建pvc的话会是怎么样的
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc2-nfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
selector:
matchLabels:
app: nfs
上面新建的 PVC 是没办法选择到合适的 PV 的
kubectl apply -f pvc2-nfs.yaml kubectl get pvc
新建立一个PV，查看能否自动关联
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2-nfs
labels:
app: nfs
spec:
capacity:
storage: 2Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
server: 192.168.86.100
path: /data/k8s
运行查看pv和pvc的变化。
很快就发现该 PV 是 Bound 状态了，对应的 PVC 是 default/pvc2-nfs，证明上面的 pvc2-nfs 终于找到合适的 PV 进行绑定上了。
kubectl apply -f pv2-nfs.yaml kubectl get pvc kubectl get pv
分析一种情况，如果pv是2个g，pvc是4个g，他们会绑定吗？答案是他们不会被绑定的，因为pv满足不了pvc需求的4个g。如果pv是4个g，pvc是2个g，他们就会绑定，因为能满足他的大小。
（二）使用 PVC
nginx 的镜像来测试下
- ① 创建deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nfs-pvc
spec:
replicas: 3
template:
metadata:
labels:
app: nfs-pvc
spec:
containers:
- name: nginx
image: nginx:1.7.8
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: pvc2-nfs
---
apiVersion: v1
kind: Service
metadata:
name: nfs-pvc
labels:
app: nfs-pvc
spec:
type: NodePort
ports:
- port: 80
targetPort: web
selector:
app: nfs-pvc
- ② 运行deployment
kubectl apply -f nfs-pvc-deploy.yaml
kubectl get deployment
kubectl get pods kubectl get svc
-
③ 测试访问
因为关联的nfs内容没有，所以直接403
cd /data/k8s echo "Hello.kubernetes~">>index.html
- ④ subPath共享分支目录
如果以后又有一个新的 nginx 容器也做了数据目录的挂载，是不是就会有冲突了啊，所以这个时候就不太好区分了，这个时候可以在 Pod 中使用一个新的属性：subPath，该属性可以来解决这个
vi nfs-pvc-deploy.yaml # subPath: nginxpvc-test
kubectl apply -f nfs-pvc-deploy.yaml
更新新的yaml
kubectl apply -f ~/nfs-pvc-deploy.yaml
将index.html 迁移到分支目录下
cd /data/k8s mv index.html ./nginxpvcTest/
访问nginx 发现正常
- ⑤ 删除deployment ,看看共享目录下的文件是否存在
kubectl get deployment kubectl delete deployment nfs-pvc kubectl get deployment ll /data/k8s/nginxpvcTest/ # index.html还存在
重新载入 yaml 查看是否自动加载发现可以正常访问nginx
kubectl apply -f ~/nfs-pvc-deploy.yaml
这证明我们的数据持久化是成功的
PS：如果这时删除了PV和PVC，共享目录中的文件也同时被删除了，这跟设置的回收版本有关系，回收策略是 Recycle，PVC 给删除掉了，然后回收了数据。上次说的PV和PVC的各种策略一定要注意。不然一不小心就把数据搞丢了。
>>原创文章，欢迎转载。转载请注明：转载自，谢谢！>>原文链接地址：上一篇:
已是最新文章
About The Author
