有三种回收策略,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 <string>
kind <string>
metadata <Object>
spec <Object>
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.14) |
---|---|
nfs-client | k8s-node1(192.168.48.13),k8s-node2(192.168.48.11) |
yum install -y nfs-utils rpcbind
以下操作均在NFS服务器上操作
mkdir /nfsdata1
mkdir /nfsdata2
mkdir /nfsdata3
chmod 777 /nfsdata1
chmod 777 /nfsdata2
chmod 777 /nfsdata3
vim /etc/exports
/nfsdata1 192.168.48.0/24(rw,no_root_squash,sync)
/nfsdata2 192.168.48.0/24(rw,no_root_squash,sync)
/nfsdata3 192.168.48.0/24(rw,no_root_squash,sync)
exportfs -rv
#手动加载 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.48.14
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /nfsdata2
server: 192.168.48.14
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /nfsdata3
server: 192.168.48.14
accessModes: ["ReadWriteMany","ReadWriteOnce"]
capacity:
storage: 2Gi
创建并查看
kubectl apply -f pv-demo.yaml
kubectl get pv
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.1.127
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的内容是否要备份
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
image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/nfs-subdir-external-provisioner:v4.0.2
# 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.48.14
- name: NFS_PATH
value: /opt/data
volumes:
- name: nfs-client-root
nfs:
server: 192.168.48.14
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内的文件依然存在,保证了数据的安全性