上次学习了 PV 的使用,但是真正使用的时候使用 PVC,类似JAVA我们操作的都是对象的而不是对应的类, Pod 来运行的,而不是 Node。只是 Pod 跑在 Node 上而已。
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,他们就会绑定,因为能满足他的大小。
nginx 的镜像来测试下
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
kubectl apply -f nfs-pvc-deploy.yaml
kubectl get deployment
kubectl get pods
kubectl get svc
http://192.168.86.100:31179/
因为关联的nfs内容没有,所以直接403
cd /data/k8s
echo "Hello.kubernetes~">>index.html
如果以后又有一个新的 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 发现正常
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的各种策略一定要注意。不然一不小心就把数据搞丢了。