k8s 十之PV和PVC

L*YUEYUE

已于 2022-03-03 10:43:25 修改

阅读量631

点赞数

分类专栏： linux企业学习文章标签： linux 运维

于 2021-10-06 22:03:28 首次发布

本文链接：https://blog.csdn.net/weixin_41708548/article/details/120621556

版权

linux企业学习专栏收录该内容

48 篇文章 3 订阅

订阅专栏

文章目录

PV及PVC介绍
创建NFS的PV和PVC示例
StorageClass
StatefulSet

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，我们发现仍可以访问原来的资源，即体现了持久化。

首先清理环境
在这里插入图片描述
创建多个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

在这里插入图片描述

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

🍎注意：别忘记systemctl start nfs 否则可能容器无法正常运行！

运行pvc.yaml

查看/nfsdata，此时目录还是default。

接下来删除pvc.yaml

出现archived

默认的StorageClass

默认的 StorageClass 将被用于动态的为没有特定 storage class 需求的 PersistentVolumeClaims 配置存储：（只能有一个默认StorageClass）
如果没有默认StorageClass，PVC 也没有指定storageClassName 的值，那么意味着它只能够跟 storageClassName 也是“ ”的 PV 进行绑定。

1.当没有sc时
vim demo.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-claim-2
spec:
#  storageClassName: managed-nfs-storage
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 5Gi

kubectl apply -f demo.yaml
kubectl get pvc

2.设置默认的sc
kubectl delete -f demo.yaml
kubectl patch storageclass managed-nfs-storage -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
kubectl get sc

3.运行文件并查看pvc
kubectl apply -f demo.yaml
kubectl get pvc

当没有StorageClass时
在这里插入图片描述
发现pvc处于pending状态

开始设置默认的StorageClass

StatefulSet

这篇文章写得很好可以参考~

StatefulSet将应用状态抽象成了两种情况：、
（1）拓扑状态：应用实例必须按照某种顺序启动，新创建的Pod必须和原来Pod的网络标识一样。
（2）存储状态：应用的多个实例分别绑定了不同存储数据
StatefulSet给所有的Pod进行了编号，编号规则是：$ (statefulset名称)-$ (序号)，从0开始。
StatefulSet还会为每一个Pod分配并创建一个同样编号的PVC。这样，kubernetes就可以通过Persistent Volume机制为这个PVC绑定对应的PV，从而保证每一个Pod都拥有一个独立的Volume。
Pod被删除后重建，重建Pod的网络标识也不会改变，Pod的拓扑状态按照Pod的“名字+编号”的方式固定下来，并且为每个Pod提供了一个固定且唯一的访问入口，即Pod对应的DNS记录。

注意清理环境
1.创建目录
mkdir statefulset
cd statefulset

2.编写文件
vim svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

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

4.查看svc
kubectl get svc

5.编写文件
vim deploy.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: web
spec:
 serviceName: "nginx-svc"
 replicas: 2              
 selector:
  matchLabels:
   app: nginx
 template:
  metadata:
   labels:
    app: nginx
  spec:
   containers:
   - name: nginx
     image: myapp:v1          
     ports:
     - containerPort: 80
       name: web

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

7.查看pod以及svc
kubectl get pod
kubectl get svc
kubectl describe svc nginx-svc 

8.测试
dig -t A nginx-svc.default.svc.cluster.local @10.96.0.10

实验截图

首先清理环境：删除pvc和/nfsdata下的所有文件接着创建无头服务
在这里插入图片描述

没有ip怎么访问呢？根据域名访问，会根据域名解析到后端两个ip。

解决报错

注意在这里dig报错了，我们将resolv.conf中的nameserver全部注释掉，就好了。
在这里插入图片描述

dig成功

改进

给原来的deploy.yaml添加一点东西

1.编辑文件
vim deploy.yaml
     volumeMounts:         
       - name: www
         mountPath: /usr/share/nginx/html
 volumeClaimTemplates:
  - metadata:
     name: www
    spec:
     storageClassName: managed-nfs-storage    ##sc
     accessModes:
     - ReadWriteOnce
     resources:
      requests:
       storage: 1Gi

2.运行文件
kubectl delete -f deploy.yaml
kubectl apply -f deploy.yaml

3.查看pv以及pvc
kubectl get pvc
kubectl get pv

4.测试前准备
cd /nfsdata
echo web-0 > default-www-web-0-pvc-xxxxxx/index.html
echo web-1 > default-www-web-1-pvc-xxxxxx/index.html

5.测试
kubectl run demo --image=busybox:1.28 -it 
nslookup nginx-svc
nslookup web-0.nginx-svc
nslookup web-1.nginx-svc

在这里插入图片描述

容器使用集群的dns ，如下还没找到原因。

补充

1.kubectl 弹缩
首先，想要弹缩的StatefulSet，需先清楚是否能弹缩该应用。
kubectl get statefulsets <stateful-set-name>

2.改变StatefulSet副本数量:
kubectl scale statefulsets <stateful-set-name> --replicas=<new-replicas>

3.如果StatefulSet开始由 kubectl apply 或 kubectl create --save-config 创建,更新StatefulSet manifests中的 .spec.replicas, 然后执行命令 kubectl apply:

4.也可以通过命令 kubectl edit 编辑该字段
kubectl edit statefulsets <stateful-set-name>

5.使用 kubectl patch
kubectl patch statefulsets <stateful-set-name> -p '{"spec":{"replicas":<new-replicas>}}'

6.使用statefullset部署mysql主从集群:
详细见官网(https://kubernetes.io/zh/docs/tasks/run-application/run-replicated-stateful-application)

L*YUEYUE

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
k8s 十之PV和PVC

PV及PVC介绍创建NFS的PV和PVC示例StorageClassStorageClass介绍StorageClass部署默认的StorageClassStatefulSet实验截图解决报错改进补充
复制链接

扫一扫