我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。
上一小节,我们介绍了kubernetes的几种存储类型,并且介绍了PV&PVC两种逻辑概念,本小节我们讲通过实际案例来讲解。
声明PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-local-pv
spec:
capacity:
storage: 100Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: ""
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node01
local:
path: /mnt/pv_disk
这个配置定义了一个名为 my-local-pv
的持久卷,具有 100Gi 的存储容量,卷模式为文件系统,访问模式为 ReadWriteOnce
,回收策略为 Retain
,并且指定了节点亲和性,使得该持久卷只能被调度到标签为 kubernetes.io/hostname=node01
的节点上。持久卷的本地路径为 /mnt/pv_disk
声明PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-local-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
storageClassName: ""
volumeName: my-local-pv
在这个YAML文件中,我们创建了一个名为my-local-pvc
的PVC,它请求100GB的存储容量,并使用ReadWriteOnce
的访问模式。storageClassName
字段为空字符串,表示不使用特定的存储类。通过设置volumeName
字段为my-local-pv
,我们将这个PVC与先前定义的my-local-pv
PV绑定。
请确保my-local-pv
是先前定义的PV的名称,以确保PVC与正确的PV绑定。当创建这个PVC时,Kubernetes将会使用指定的PV来满足PVC的存储需求,当PV和PVC的STATUS为Bound则算是可用使用的。
申请PVC
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx
volumeMounts:
- name: data
mountPath: /data
volumes:
- name: data
persistentVolumeClaim:
claimName: my-local-pvc
实际上这种应用方式,在真实环境基本不会这样使用,因为没什么价值,还需要提前创建,还需要考虑PV和PVC的对应关系。当前的PVC实际在Deployment里面直接挂在HostPath效果是一样的,不过用于理解PV&PVC是有意义的,因为测试用的是本地目录。