「走进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的各种策略一定要注意。不然一不小心就把数据搞丢了。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:
已是最新文章