Kubernetes(k8s)PV、PVC

目录

一、PV和PVC

1、PV 概念

2、PVC概念

3、PV 与 PVC

3.1、PV 与 PVC 之间的关系

3.2、PV和PVC的生命周期

3.3、一个PV从创建到销毁的具体流程

3.4、三种回收策略

3.5、查看pv、pvc的定义方式、规格

4、PV的提供方式

二、基于NFS创建静态 PV、PVC

2.1、NFS服务部署

 2.2、创建PV

2.3、定义PVC

2.4、多路读写测试

三、基于动态 storageclass 创建 PV、PVC

3.1、storageclass 定义

 3.2、storageclass 用途

3.3、基于NFS动态创建PV、PVC

3.4、测试


Kubernetes(k8s)PV、PVC_第1张图片

容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题。Pod中的容器通过Pause容器共享Volume。

一、PV和PVC

1、PV 概念

  1. PersistentVolume(PV) 是集群中由管理员配置的一段网络存储。集群中的资源就像一个节点是一个集群资源,可以从远程的NFS 或分布式对象存储系统中创建得来(PV 存储空间大小、访问方式)。
  2. PV 是诸如卷之类的卷插件,但是只有独立于使用 PV 的任何单个 pod 的生命周期。
  3. 该 API 对象捕获存储的实现细节,即 NFS,ISCSI 或云提供商特定的存储系统。
  4. PV 就是从存储设备中的空间创建出一个存储资源。

2、PVC概念

  1. PersistentVolumeClaim(PVC) 是用户存储的请求。PVC 的使用逻辑:在 pod 中定义一个存储卷(该存储卷类型为PVC),定义的时候直按指定大小,PVC 必须与对应的 PV 建立关系,PVC 会根据定义去 PV 申请,而 PV是由存储空间创建出来的。PV 和 PVC 是 kubernetes 抽象出来的一种存储资源。
  2. 虽然 PersistentVolumeClaims 允许用户使用抽象存储资源,但是常见的需求是,用户需要根据不同的需求去创建PV,用于不同的场景。而此时需要集群管理员提供不同需求的 PV,而不仅仅是 PV 的大小和访问模式,但又不需要用户了解这些卷的实现细节。
  3. 对于这样的需求,此时可以采用 storageclass 资源。
     
pv : 相当于磁盘分区
 
pvc: 相当于磁盘请求

3、PV 与 PVC

3.1、PV 与 PVC 之间的关系

PV 是集群中的资源,PVC 是对这些资源的请求,也是对资源的索引检查。

3.2、PV和PVC的生命周期

PV 和 PVC 之间的相互作用遵循这个生命周期:
Provisioning(配置) —> Binding(绑定) —> Using(使用) —> Releasing(释放) —> Recycling(回收)

Provisioning,即 PV 的创建,可以直接创建 PV(静态方式),也可以使用 StorageClass 动态创建

Binding,将 PV 分配给 PVC

Using,Pod 通过 PVC 使用该Volume,并可以通过准入控制StorageProtection(1.9及以前版本为PVCProtection) 阻止删除正在使用的PVC

Releasing,Pod 释放 Volume 并删除 PVC

Recycling,回收 PV,可以保留 PV 以便下次使用,也可以直接从云存储中删除

根据这 5 个阶段,PV 的状态有以下 4 种:

  • Available(可用):表示可用状态,还未被任何 PVC 绑定

  • Bound(已绑定):表示 PV 已经绑定到 PVC

  • Released(已释放):表示 PVC 被删掉,但是资源尚未被集群回收

  • Failed(失败):表示该 PV 的自动回收失败

3.3、一个PV从创建到销毁的具体流程

  1. 一个PV创建完后状态会变成Available,等待被PVC绑定。
  2. 一旦被PVC邦定,PV的状态会变成Bound,就可以被定义了相应PVC的Pod使用。
  3. Pod使用完后会释放PV,PV的状态变成Released。
  4. 变成Released的PV会根据定义的回收策略做相应的回收工作。

3.4、三种回收策略

有三种回收策略,Retain、Delete和Recycle。

  1. Retain就是保留现场,K8S集群什么也不做,等待用户手动去处理PV里的数据,处理完后,再手动删除PV。
  2. Delete策略,K8S会自动删除该PV及里面的数据。
  3. Recycle方式,K8S会将PV里的数据删除,然后把PV的状态变成Available,又可以被新的PVC绑定使用。

3.5、查看pv、pvc的定义方式、规格

查看pv的定义方式
kubectl explain pv

FIELDS:
	apiVersion: v1
	kind: PersistentVolume
	metadata:    #由于 PV 是集群级别的资源,即 PV 可以跨 namespace 使用,所以 PV 的 metadata 中不用配置 namespace
	  name: 
	spec

查看pv定义的规格
kubectl explain pv.spec

spec:
  nfs:(定义存储类型)
    path:(定义挂载卷路径)
    server:(定义服务器名称)
  accessModes:(定义访问模型,有以下三种访问模型,以列表的方式存在,也就是说可以定义多个访问模式)
    - ReadWriteOnce          #(RWO)存储可读可写,但只支持被单个 Pod 挂载
	- ReadOnlyMany           #(ROX)存储可以以只读的方式被多个 Pod 挂载
	- ReadWriteMany          #(RWX)存储可以以读写的方式被多个 Pod 共享
#nfs 支持全部三种;iSCSI 不支持 ReadWriteMany(iSCSI 就是在 IP 网络上运行 SCSI 协议的一种网络存储技术);HostPath 不支持 ReadOnlyMany 和 ReadWriteMany。
  capacity:(定义存储能力,一般用于设置存储空间)
    storage: 2Gi (指定大小)
  storageClassName: (自定义存储类名称,此配置用于绑定具有相同类别的PVC和PV)
  persistentVolumeReclaimPolicy: Retain    #回收策略(Retain/Delete/Recycle)
#Retain(保留):当删除与之绑定的PVC时候,这个PV被标记为released(PVC与PV解绑但还没有执行回收策略)且之前的数据依然保存在该PV上,但是该PV不可用,需要手动来处理这些数据并删除该PV。
#Delete(删除):删除与PV相连的后端存储资源(只有 AWS EBS, GCE PD, Azure Disk 和 Cinder 支持)
#Recycle(回收):删除数据,效果相当于执行了 rm -rf /thevolume/* (只有 NFS 和 HostPath 支持)

查看PVC的定义方式
kubectl explain pvc

KIND:     PersistentVolumeClaim
VERSION:  v1
FIELDS:
   apiVersion	
   kind	  
   metadata	
   spec	
 
  

PV和PVC中的spec关键字段要匹配,比如存储(storage)大小、访问模式(accessModes)、存储类名称(storageClassName)

kubectl explain pvc.spec
spec:
  accessModes: (定义访问模式,必须是PV的访问模式的子集)
  resources:
    requests:
      storage: (定义申请资源的大小)
  storageClassName: (定义存储类名称,此配置用于绑定具有相同类别的PVC和PV)

4、PV的提供方式

这里有两种 PV 的提供方式:静态或者动态

静态 —》直接固定存储空间

  • 集群管理员创建一些 PV。它们携带可供集群用户使用的真实存储的详细信息。它们存在于 Kubernetes API 中,可用于消费。

动态 —》通过存储类进行动态创建存储空间

  • 当管理员创建的静态 PV 都不匹配用户的 PVC 时,集群可能会尝试动态地为 PVC 配置卷。此配置基于
    StorageClasses:PVC必须请求存储类,并且管理员必须已创建并配置该类才能进行动态配置。要求该类的声明有效地为自己禁用动态配置。

二、基于NFS创建静态 PV、PVC

Kubernetes(k8s)PV、PVC_第2张图片

 环境准备

nfs-server k8s-master(192.168.48.22)
nfs-client k8s-node1(192.168.58.19),k8s-node2(192.168.58.13)

2.1、NFS服务部署

  • 所有节点安装nfs
yum install -y nfs-utils rpcbind

以下操作均在NFS服务器上操作

  • 创建共享目录,并授权
mkdir /nfsdata1
mkdir /nfsdata2
mkdir /nfsdata3

chmod 777 /nfsdata1
chmod 777 /nfsdata2
chmod 777 /nfsdata3
  • 配置权限

编辑 exports 文件

vim /etc/exports
/nfsdata1 192.168.58.0/24(rw,no_root_squash,sync)
/nfsdata2 192.168.58.0/24(rw,no_root_squash,sync)
/nfsdata3 192.168.58.0/24(rw,no_root_squash,sync)

exportfs -rv

Kubernetes(k8s)PV、PVC_第3张图片

Kubernetes(k8s)PV、PVC_第4张图片

 Kubernetes(k8s)PV、PVC_第5张图片

 所有服务器启动NFS服务

#手动加载 NFS 共享服务时,应该先启动 rpcbind,再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启,rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind

Kubernetes(k8s)PV、PVC_第6张图片

查看本机发布的共享目录

showmount -e

 Kubernetes(k8s)PV、PVC_第7张图片

  • 创建访问页面供测试用
echo '11111' > /nfsdata1/index.html
echo '22222' > /nfsdata2/index.html
echo '33333' > /nfsdata3/index.html

Kubernetes(k8s)PV、PVC_第8张图片

 2.2、创建PV

  • 创建PV
    定义 3 个 PV,并且定义挂载的路径以及访问模式,还有 PV 划分的大小。
    vim pv-demo.yaml
    注意自己的共享目录和主机IP
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /nfsdata1
    server: 192.168.58.22
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /nfsdata2
    server: 192.168.58.22
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /nfsdata3
    server: 192.168.58.22
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

Kubernetes(k8s)PV、PVC_第9张图片

创建并查看

kubectl apply -f pv-demo.yaml 
kubectl get pv

Kubernetes(k8s)PV、PVC_第10张图片

2.3、定义PVC

  •  定义PVC

这里定义了 PVC 的访问模式为多路读写,该访问模式必须在前面 PV 定义的访问模式之中。定义 PVC 申请的大小为 2Gi,此时 PVC 会自动去匹配多路读写且大小为 2Gi 的 PV ,匹配成功获取 PVC 的状态即为 Bound。

vim pvc-demo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes: ["ReadWriteMany"]
  resources:
    requests:
      storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: pv-pvc
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/html
  volumes:
  - name: html
    persistentVolumeClaim:
      claimName: mypvc

Kubernetes(k8s)PV、PVC_第11张图片

 发布并查看

kubectl apply -f pvc-demo.yaml
kubectl get pvc

Kubernetes(k8s)PV、PVC_第12张图片

可以看到 pv003 设定的 pvc 请求存储卷是 2Gi 并且多路可读可写。

 访问 pv003

kubectl get pod -o wide
curl 10.150.2.56 
# curl 访问,显示的内容与共享的目录内一致

Kubernetes(k8s)PV、PVC_第13张图片

2.4、多路读写测试

1. 我们通过相同的存储卷,只修改 pod 的名称
cp pvc-demo.yaml 1.yaml
cp pvc-demo.yaml 2.yaml
2. 修改 pod 的名称后,apply 执行创建
kubectl apply -f 1.yaml
kubectl apply -f 2.yaml
3. 查看 ip
kubectl get pod -o wide 
4. curl 进行测试,查看是否共享存储卷,多路读写

Kubernetes(k8s)PV、PVC_第14张图片

Kubernetes(k8s)PV、PVC_第15张图片

Kubernetes(k8s)PV、PVC_第16张图片

三、基于动态 storageclass 创建 PV、PVC

3.1、storageclass 定义

前面的例子中,我们提前创建了 PV,然后通过 PVC 申请 PV 并在 Pod 中使用,这种方式叫做静态供给(Static Provision)。
与之对应的是动态供给(Dynamical Provision),即如果没有满足 PVC 条件的 PV,会动态创建 PV。相比静态供给,动态供给有明显的优势:不需要提前创建 PV,减少了管理员的工作量,效率高。
Kubernetes(k8s)PV、PVC_第17张图片

Kubernetes(k8s)PV、PVC_第18张图片

 3.2、storageclass 用途

在 PV 和 PVC 使用过程中存在的问题,在 PVC 申请存储空间时,未必就有现成的 PV 符合 PVC 申请的需求,上面 nfs 在做 PVC 可以成功的因素是因为我们做了指定的需求处理。当 PVC 申请的存储空间不一定有满足 PVC 要求的 PV 时,Kubernetes 为管理员提供了描述存储 “class(类)” 的方法(StorageClass)。
举个例子,在存储系统中划分一个 1TB 的存储空间提供给 Kubernetes 使用,当用户需要一个 10G 的 PVC 时,会立即通过 restful 发送请求,从而让存储空间创建一个 10G 的 image,之后在我们的集群中定义成 10G 的 PV 供给给当前的 PVC 作为挂载使用。在此之前我们的存储系统必须支持 restful 接口,比如 ceph 分布式存储,而 glusterfs 则需要借助第三方接口完成这样的请求。

3.3、基于NFS动态创建PV、PVC

Kubernetes支持动态供给的存储插件:https://kubernetes.io/docs/concepts/storage/storage-classes/

因为NFS不支持动态存储,所以我们需要借用这个存储插件。

nfs动态相关部署可以参考:​​​​​​https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy

  • 定义一个storageclass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "true"  ## 删除pv的时候,pv的内容是否要备份

授权
因为storage自动创建pv需要经过kube-apiserver,所以要进行授权
创建1个sa(serviceaccount)
创建1个clusterrole,并赋予应该具有的权限,比如对于一些基本api资源的增删改查;
创建1个clusterrolebinding,将sa和clusterrole绑定到一起;这样sa就有权限了;
然后pod中再使用这个sa,那么pod再创建的时候,会用到sa,sa具有创建pv的权限,便可以自动创建pv;

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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
    namespace: default
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
  namespace: default
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
  namespace: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

注意:如果名称空间不是default,请自行修改

  • 创建一个
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
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
          # resources:
          #    limits:
          #      cpu: 10m
          #    requests:
          #      cpu: 10m
          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.58.22
            - name: NFS_PATH
              value: /opt/data
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.58.22
            path: /opt/data
strategy:
type: Recreate Recreate:设置spec.strategy.type=Recreate,该策略下将杀掉正在运行的Pod,然后创建新的。

RollingUpdate:设置spec.strategy.type=RollingUpdate,滚动更新,即逐渐减少旧Pod的同时逐渐增加新Pod。

其中默认的RollingUpdate滚动更新策略的“边删除边更新”保证了在更新期间的服务可用性,在使用这个策略时,有两个可定义参数:
spec.strategy.RollingUpdate.maxUnavailable:更新过程中Pod数量可以低于Pod期望副本的数量或百分比(默认25%)
spec.strategy.RollingUpdate.maxSurge:更新过程中Pod数量可以超过Pod期望副本的数量或百分比(默认25%)
  • 部署
#我这儿将上面的所有文件都放在了一个配置文件中,如果是分开的文件,请一个个创建
kubectl apply -f nfs.yaml 

Kubernetes(k8s)PV、PVC_第19张图片

查看

#查看storageclass
kubectl get sc
#查看sa
kubctl get sa
#查看deploy控制器
kubctl get deploy
#查看pod
kubctl get pod

Kubernetes(k8s)PV、PVC_第20张图片

3.4、测试

部署nginx服务,测试自动创建pv

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
   matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-storage"
      resources:
        requests:
          storage: 1Gi

Kubernetes(k8s)PV、PVC_第21张图片

 发布查看

Kubernetes(k8s)PV、PVC_第22张图片 

kubectl get pvc,pv

Kubernetes(k8s)PV、PVC_第23张图片

我们可以看到,我们在没有创建pv的时候,只是创建了一个pvc,他就会配置要求自动创建一个符合要求的pv

进入共享目录,创建一个文件

Kubernetes(k8s)PV、PVC_第24张图片

 删除web-0,检查文件是否存在

Kubernetes(k8s)PV、PVC_第25张图片

 在有状态服务中,数据至关重要,通过测试,我们可以发现,虽然pod被删除重建,但是重建后的pod内的文件依然存在,保证了数据的安全性

你可能感兴趣的:(kubernetes,java,容器)