目录
一、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、测试
容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod中同时运行多个容器时,这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题。Pod中的容器通过Pause容器共享Volume。
pv : 相当于磁盘分区
pvc: 相当于磁盘请求
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 的自动回收失败
有三种回收策略,Retain、Delete和Recycle。
查看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
PV和PVC中的spec关键字段要匹配,比如存储(storage)大小、访问模式(accessModes)、存储类名称(storageClassName)
kubectl explain pvc.spec
spec:
accessModes: (定义访问模式,必须是PV的访问模式的子集)
resources:
requests:
storage: (定义申请资源的大小)
storageClassName: (定义存储类名称,此配置用于绑定具有相同类别的PVC和PV)
这里有两种 PV 的提供方式:静态或者动态
静态 —》直接固定存储空间
动态 —》通过存储类进行动态创建存储空间
环境准备
nfs-server | k8s-master(192.168.48.22) |
---|---|
nfs-client | k8s-node1(192.168.58.19),k8s-node2(192.168.58.13) |
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
所有服务器启动NFS服务
#手动加载 NFS 共享服务时,应该先启动 rpcbind,再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
#查看 rpcbind 端口是否开启,rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind
查看本机发布的共享目录
showmount -e
echo '11111' > /nfsdata1/index.html
echo '22222' > /nfsdata2/index.html
echo '33333' > /nfsdata3/index.html
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
创建并查看
kubectl apply -f pv-demo.yaml
kubectl get pv
这里定义了 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
发布并查看
kubectl apply -f pvc-demo.yaml
kubectl get pvc
可以看到 pv003 设定的 pvc 请求存储卷是 2Gi 并且多路可读可写。
访问 pv003
kubectl get pod -o wide
curl 10.150.2.56
# curl 访问,显示的内容与共享的目录内一致
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 进行测试,查看是否共享存储卷,多路读写
前面的例子中,我们提前创建了 PV,然后通过 PVC 申请 PV 并在 Pod 中使用,这种方式叫做静态供给(Static Provision)。
与之对应的是动态供给(Dynamical Provision),即如果没有满足 PVC 条件的 PV,会动态创建 PV。相比静态供给,动态供给有明显的优势:不需要提前创建 PV,减少了管理员的工作量,效率高。
在 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 则需要借助第三方接口完成这样的请求。
Kubernetes支持动态供给的存储插件:https://kubernetes.io/docs/concepts/storage/storage-classes/
因为NFS不支持动态存储,所以我们需要借用这个存储插件。
nfs动态相关部署可以参考:https://github.com/kubernetes-incubator/external-storage/tree/master/nfs-client/deploy
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
查看
#查看storageclass
kubectl get sc
#查看sa
kubctl get sa
#查看deploy控制器
kubctl get deploy
#查看pod
kubctl get pod
部署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
发布查看
kubectl get pvc,pv
我们可以看到,我们在没有创建pv的时候,只是创建了一个pvc,他就会配置要求自动创建一个符合要求的pv
进入共享目录,创建一个文件
删除web-0,检查文件是否存在
在有状态服务中,数据至关重要,通过测试,我们可以发现,虽然pod被删除重建,但是重建后的pod内的文件依然存在,保证了数据的安全性