「走进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的各种策略一定要注意。不然一不小心就把数据搞丢了。

>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:「走进k8s」Kubernetes1.15.1的持久化存储PVC(32)
上一篇: 下一篇:

发表评论

电子邮件地址不会被公开。 必填项已用*标注