写在前面:如有问题,以你为准,
目前24年应届生,各位大佬轻喷,部分资料与图片来自网络
内容较长,页面右上角目录方便跳转
概述
保存在容器中的数据也会被清除,所以要实现持久化存储(Volume)
通过将本地目录挂载到pod,一个目录可以挂载到多个pod中的容器
通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储
Volume的生命周期不和Pod中的单个容器的生命周期有关,当容器终止或者重启的时候,Volume中的数据也不会丢失
- kubernetes的Volume支持多种类型,比较常见的有下面的几个:
- 简单存储:EmptyDir、HostPath、NFS。
- 高级存储:PV、PVC。
- 配置存储:ConfigMap、Secret。
EmptyDir:pod中临时存储空间可以被多个容器挂载,实现共享目录,pod删除其也删除
HostPath:将node上的目录挂载到pod里面的容器里面,实现了持久化存储,但是没有实现存储高可用
Kubernetes 目前支持多达 28 种数据卷类型(其中大部分特定于具体的云环境如 GCE/AWS/Azure 等)
非持久性存储:
emptyDir
HostPath
网络连接性存储:
SAN:iSCSI、ScaleIO Volumes、FC (Fibre Channel)
NFS:nfs,cfs
分布式存储
Glusterfs
RBD (Ceph Block Device)
CephFS
Portworx Volumes
Quobyte Volumes
云端存储
GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
Cinder (OpenStack block storage)
VsphereVolume
StorageOS
自定义存储
基本存储
EmptyDir
EmptyDir是最基础的Volume类型,一个EmptyDir就是Host上的一个空目录。
不是持久化数据存储,生命周期跟pod一样,一般是用于多容器共享目录
- EmptyDir是在Pod被分配到Node时创建的,它的初始内容为空,并且无须指定宿主机上对应的目录文件,因为kubernetes会自动分配一个目录,当Pod销毁时,EmptyDir中的数据也会被永久删除。
- EmptyDir的用途如下:
- 一个容器需要从另一个容器中获取数据的目录(多容器共享目录)。
示例
接下来,通过一个容器之间的共享案例来使用描述一个EmptyDir。
在一个Pod中准备两个容器nginx和busybox,然后声明一个volume分别挂载到两个容器的目录中,然后nginx容器负责向volume中写日志,busybox中通过命令将日志内容读到控制台。
apiVersion: v1
kind: Pod
metadata:
name: volume-emptydir
namespace: study
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /var/log/nginx/access.log"]
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录,该目录为/var/log/nginx
- name: logs-volume # 卷名
mountPath: /var/log/nginx # 要挂载到容器的目录,该目录且要容器必须存在
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令,持续读取指定文件
# 读取的时候是前台,而kubectl logs命令就是读取前台日志/dev/stdout和/dev/stderr
volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录,该目录为/logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume,name为logs-volume,类型为emptyDir
- name: logs-volume # 用于挂载时指定的volume名字
emptyDir: {} # 指定volume类型
[root@master k8s]# kubectl apply -f emptydir.yaml
pod/volume-emptydir created
[root@master k8s]# kubectl get pod volume-emptydir -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
volume-emptydir 2/2 Running 0 142m 10.244.104.44 node2 <none> <none>
[root@master k8s]# kubectl describe pod -n study
# 访问nginx,查看busybox挂载的目录是否有信息,有则说明nginx的日志在logs-volume,且busybox也挂载了目录
[root@master k8s]# curl 10.244.104.44
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[root@master k8s]# kubectl logs -f volume-emptydir -n study -c busybox
192.168.100.53 - - [19/Feb/2023:08:15:33 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"
HostPath
HostPath就是将Node主机中的一个实际目录挂载到Pod中,以供容器使用,这样的设计就可以保证Pod销毁了,但是数据依旧可以保存在Node节点主机上
但是一旦Node节点故障了,Pod如果转移到别的Node节点上,又会出现问题
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional
type: Directory # 目录必须存在指定路径
# FileOrCreate 不会创建文件的父目录,如果挂载文件的父目录不存在,则pod启动失败
# DirectoryOrCreate 如果不存在就创建,且权限为0755,与 Kubelet 具有相同的组和所有权
# File 文件必须存在于给定路径
# 如果不写type就跳过检测,则如果目录不存在,yaml创建时候也不会报错,类似于可选项
示例
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath
namespace: study
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录,该目录为/var/log/nginx
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令,动态读取指定文件
volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录,该目录为/logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume,name为logs-volume,类型为hostPath
- name: logs-volume
hostPath:
path: /root/logs
type: DirectoryOrCreate # 目录存在就使用,不存在就先创建再使用
nodeName: master # 测试方便查看hostPath被挂载的目录
[root@master k8s]# kubectl apply -f emptydir.yaml
pod/volume-hostpath created
[root@master k8s]# kubectl get pod -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
volume-hostpath 2/2 Running 0 58s 10.244.219.71 master <none> <none>
[root@master k8s]# curl 10.244.219.71
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[root@master k8s]# cat /root/logs/access.log
192.168.100.53 - - [20/Feb/2023:06:23:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"
subPath
使用 mountPath 挂载 /etc/nginx ,但是我告诉 kubernetes 我挂载那个文件,此时就可以使用 subPath 了,此时 Kubernetes 就只会覆盖 /etc/nginx/nginx.conf 文件
换言之,mountPath 告诉 Kubernetes 我需要覆盖容器中的那个目录,但是有了 subPath ,Kubernetes 就知道了,哦,原来你只需要覆盖 mountPath 下边的子文件啊(subPath )
apiVersion: v1
kind: Pod
metadata:
name: my-lamp-site
spec:
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: "rootpasswd"
volumeMounts:
- mountPath: /var/lib/mysql
name: site-data
subPath: m
- name: php
image: php:7.0-apache
volumeMounts:
- mountPath: /var/www/html
name: site-data
subPath: m
volumes:
- name: site-data
emptyDir: {}
NFS
hostpath可以实现持久化,但是没有实现高可用,但是一旦Node节点故障了,Pod如果转移到别的Node节点上,又会出现问题,而NFS就是为解决持久化存储高可用
Master 搭建 NFS
首先需要准备NFS服务器,这里为了简单,直接在Master节点做NFS服务器。
yum install -y nfs-utils rpcbind
mkdir -pv /root/data/k8s-nfs
vim /etc/exports
# 将共享目录以读写权限暴露给192.168.100.0/24网段中的所有主机
/root/data/k8s-nfs 192.168.100.0/24(rw,no_root_squash)
# 读写权限,不使用root权限
systemctl start rpcbind
systemctl enable rpcbind
systemctl start nfs-server
systemctl enable nfs-server
在Node节点上都安装NFS服务器,目的是为了Node节点可以驱动NFS设备
# 在Node节点上安装NFS服务,不需要启动
yum -y install nfs-utils
showmount -e 192.168.100.53
mount -t nfs 192.168.100.53:/root/data/k8s-nfs /mnt #关机后
mount -t nfs 192.168.100.53:/root/data/k8s-nfs/mnt
示例
apiVersion: v1
kind: Pod
metadata:
name: volume-nfs
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
volumeMounts: # 将logs-volume挂载到nginx容器中对应的目录,该目录为/var/log/nginx
- name: logs-volume
mountPath: /var/log/nginx
- name: busybox
image: busybox:1.30
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","tail -f /logs/access.log"] # 初始命令,动态读取指定文件
volumeMounts: # 将logs-volume挂载到busybox容器中的对应目录,该目录为/logs
- name: logs-volume
mountPath: /logs
volumes: # 声明volume
- name: logs-volume
nfs:
server: 192.168.100.53 # NFS服务器地址
path: /root/data/k8s-nfs # 共享文件路径
[root@master k8s]# kubectl apply -f emptydir.yaml
pod/volume-hostpath created
[root@master k8s]# kubectl get pod -n study -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
volume-hostpath 2/2 Running 0 64s 10.244.104.53 node2 <none> <none>
[root@master k8s]# curl 10.244.104.53
[root@master k8s]# cat /root/data/k8s-nfs/access.log
192.168.100.53 - - [20/Feb/2023:07:15:55 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"
192.168.100.53 - - [20/Feb/2023:07:49:20 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.61.1" "-"
高级存储(pv pvc)
概述架构
此时就要求用户会搭建NFS系统等,并且会在yaml配置nfs
由于kubernetes支持的存储系统有很多,要求客户全部掌握,显然不现实。为了能够屏蔽底层存储实现的细节,方便用户使用,kubernetes引入了PV和PVC两种资源对(类似于资源池化,pv和pvc是抽象的存储资源)
- 使用了PV和PVC之后,工作可以得到进一步的提升:
- 存储:存储工程师维护。
- PV:kubernetes管理员维护。
- PVC:kubernetes用户维护。
生命周期
- PVC和PV是一一对应的,PV和PVC之间的相互作用遵循如下的生命周期。
- 资源供应:管理员手动创建底层存储和PV。
- 资源绑定:
- 用户创建PVC,kubernetes负责根据PVC声明去寻找PV,并绑定在用户定义好PVC之后,系统将根据PVC对存储资源的请求在以存在的PV中选择一个满足条件的。
- 一旦找到,就将该PV和用户定义的PVC进行绑定,用户的应用就可以使用这个PVC了。
- 如果找不到,PVC就会无限期的处于Pending状态,直到系统管理员创建一个符合其要求的PV。
- PV一旦绑定到某个PVC上,就会被这个PVC独占,不能再和其他的PVC进行绑定了。
- 用户创建PVC,kubernetes负责根据PVC声明去寻找PV,并绑定在用户定义好PVC之后,系统将根据PVC对存储资源的请求在以存在的PV中选择一个满足条件的。
- 资源使用:用户可以在Pod中像volume一样使用PVC,Pod使用Volume的定义,将PVC挂载到容器内的某个路径进行使用。
- 资源释放:
- 上一个 pod还有东西存在目录中
- 用户删除PVC来释放PV。
- 当存储资源使用完毕后,用户可以删除PVC,和该PVC绑定的PV将会标记为“已释放”,但是还不能立刻和其他的PVC进行绑定。通过之前PVC写入的数据可能还留在存储设备上,只有在清除之后该PV才能再次使用。
- 资源回收:
- 对于PV,管理员可以设定回收策略,用于设置与之绑定的PVC释放资源之后如何处理遗留数据的问题。只有PV的存储空间完成回收,才能供新的PVC绑定和使用。
理论与使用 PV
一般由kubernetes运维管理人员创建,然后提供给需要使用的人创建pvc
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
# 没有namespace 是集群级别的资源,跨namespace使用
spec:
nfs: # 存储类型,和底层正则的存储对应
path:
server:
capacity: # 存储能力,目前只支持存储空间的设置
storage: 2Gi
accessModes: # 访问模式
- ReadWriteOnce
# ReadOnlyMany
# ReadWriteMany
storageClassName: # 存储类别
persistentVolumeReclaimPolicy: # 回收策略
- 存储类型:底层实际存储的类型,kubernetes支持多种存储类型,每种存储类型的配置有所不同。
- 存储能力(capacity):目前只支持存储空间的设置(storage=1Gi),不过未来可能会加入IOPS、吞吐量等指标的配置。
- 访问模式(accessModes):
- 用来描述用户应用对存储资源的访问权限,访问权限包括下面几种方式:
- ReadWriteOnce(RWO):读写权限,但是只能被单个节点挂载(单pvc挂载)。
- ReadOnlyMany(ROX):只读权限,可以被多个节点挂载。
- ReadWriteMany(RWX):读写权限,可以被多个节点挂载。
- 需要注意的是,底层不同的存储类型可能支持的访问模式不同。
- 用来描述用户应用对存储资源的访问权限,访问权限包括下面几种方式:
- 回收策略( persistentVolumeReclaimPolicy):
- 当PV不再被使用之后,对其的处理方式,目前支持三种策略:
- Retain(保留):保留数据,需要管理员手动清理数据。
- Recycle(回收):清除PV中的数据,效果相当于 rm -rf /volume/*。
- Delete(删除):和PV相连的后端存储完成volume的删除操作,常见于云服务器厂商的存储服务。
- 需要注意的是,底层不同的存储类型可能支持的回收策略不同。
- 当PV不再被使用之后,对其的处理方式,目前支持三种策略:
- 存储类别(storageClassName):PV可以通过storageClassName参数指定一个存储类别。
- 具有特定类型的PV只能和请求了该类别的PVC进行绑定。
- 未设定类别的PV只能和不请求任何类别的PVC进行绑定。
- 状态(status):一个PV的生命周期,可能会处于4种不同的阶段。
- Available(可用):表示可用状态,还未被任何PVC绑定。
- Bound(已绑定):表示PV已经被PVC绑定。
- Released(已释放):表示PVC被删除,但是资源还没有被集群重新释放。
- Failed(失败):表示该PV的自动回收失败。
mkdir -pv /root/data/{pv1,pv2,pv3}
chmod 777 -R /root/data
# 修改 NFS 的配置文件
vim /etc/exports
/root/data/pv1 192.168.18.0/24(rw,no_root_squash)
/root/data/pv2 192.168.18.0/24(rw,no_root_squash)
/root/data/pv3 192.168.18.0/24(rw,no_root_squash)
systemctl restart nfs-server
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv1
spec:
nfs: # 存储类型,和底层正则的存储对应
path: /root/data/pv1
server: 192.168.100.53
capacity: # 存储能力,目前只支持存储空间的设置
storage: 1Gi
accessModes: # 访问模式
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain # 回收策略
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv2
spec:
nfs: # 存储类型,和底层正则的存储对应
path: /root/data/pv2
server: 192.168.100.53
capacity: # 存储能力,目前只支持存储空间的设置
storage: 2Gi
accessModes: # 访问模式
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain # 回收策略
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv3
spec:
nfs: # 存储类型,和底层正则的存储对应
path: /root/data/pv3
server: 192.168.100.53
capacity: # 存储能力,目前只支持存储空间的设置
storage: 3Gi
accessModes: # 访问模式
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain # 回收策略
[root@master k8s]# kubectl apply -f pv.yaml
persistentvolume/pv1 created
persistentvolume/pv2 created
persistentvolume/pv3 created
[root@master k8s]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Available 27s
pv2 2Gi RWX Retain Available 27s
pv3 3Gi RWX Retain Available 27s
CLAIM 如果被使用这里会显示pvc的名字
理论与使用 PVC
PVC是对 PV 资源的申请,用来声明对存储空间、访问模式、存储类别需求信息
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc
namespace: dev
spec:
accessModes: # 访客模式
- ReadWriteMany
selector: # 采用标签对PV选择
storageClassName: # 存储类别
resources: # 请求空间
requests:
storage: 5Gi
- 访客模式(accessModes):用于描述用户应用对存储资源的访问权限。
- 必须和要连接的pv声明的访问模式要一样
- ReadWriteOnce(RWO):读写权限,但是只能被单个节点挂载(单pvc挂载)。
- ReadOnlyMany(ROX):只读权限,可以被多个节点挂载。
- ReadWriteMany(RWX):读写权限,可以被多个节点挂载。
- 必须和要连接的pv声明的访问模式要一样
- 用于描述用户应用对存储资源的访问权限:
- 存储类别(storageClassName):PVC在定义时可以设定需要的后端存储的类别,只有设置了该class的pv才能被系统选出。
- 资源请求(resources):描述对存储资源的请求。
- 优先级为
- pvc(1Gi)= pv(1Gi)
- 同等容量的pv没有了则申请比自己大即可 pvc(1Gi)= pv(2Gi)
- 如果没有比自己大的,也没有相等的即失败
- 优先级为
- ①PVC的空间申请大小比PV的空间要大。
- ②PVC的storageClassName和PV的storageClassName不一致。
- ③PVC的accessModes和PV的accessModes不一致。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc1
namespace: study
spec:
accessModes: # 访客模式
- ReadWriteMany # 和pv一样
resources: # 请求空间
requests:
storage: 1Gi #申请pv1
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc2
namespace: study
spec:
accessModes: # 访客模式
- ReadWriteMany
resources: # 请求空间
requests:
storage: 1Gi # 上面pv1已经被申请了没有同等容量的pv,所以申请pv2(2G)
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc3
namespace: study
spec:
accessModes: # 访客模式
- ReadWriteMany
resources: # 请求空间
requests:
storage: 5Gi # 没有与这个相等也没有比他大的,所以申请失败
[root@master k8s]# kubectl apply -f pvc.yaml
persistentvolumeclaim/pvc1 created
persistentvolumeclaim/pvc2 created
persistentvolumeclaim/pvc3 created
[root@master k8s]# kubectl get pvc -n study
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc1 Bound pv1 1Gi RWX 54s
pvc2 Bound pv2 2Gi RWX 54s
pvc3 Pending 54s
# Bound 被使用
# pvc3 没找到存储容量相等或大于所以一直在ping,可以另外创建新的pv
[root@master k8s]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Bound study/pvc1 23m
pv2 2Gi RWX Retain Bound study/pvc2 23m
pv3 3Gi RWX Retain Available 23m
创建pod连接 PVC
apiVersion: v1
kind: Pod
metadata:
name: pod1
namespace: study
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim: # 这个字段是pvc的kind: PersistentVolumeClaim
claimName: pvc1
readOnly: false # 只读
---
apiVersion: v1
kind: Pod
metadata:
name: pod2
namespace: study
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do echo pod1 >> /root/out.txt; sleep 10; done;"]
volumeMounts:
- name: volume
mountPath: /root/
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc2
readOnly: false
[root@master k8s]# kubectl apply -f pod-pvc.yaml
pod/pod1 created
pod/pod2 created
[root@master k8s]# ls /root/data/pv1/out.txt
/root/data/pv1/out.txt
删除
[root@master k8s]# kubectl delete -f pod-pvc.yaml
pod "pod1" deleted
pod "pod2" deleted
[root@master k8s]# kubectl get pvc -n study
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
pvc1 Bound pv1 1Gi RWX 123m
pvc2 Bound pv2 2Gi RWX 123m
pvc3 Pending 123m
[root@master k8s]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Bound study/pvc1 126m
pv2 2Gi RWX Retain Bound study/pvc2 126m
pv3 3Gi RWX Retain Available 126m
[root@master k8s]# kubectl delete -f pvc.yaml
persistentvolumeclaim "pvc1" deleted
persistentvolumeclaim "pvc2" deleted
persistentvolumeclaim "pvc3" deleted
[root@master k8s]# kubectl get pv -n study
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Released study/pvc1 127m
pv2 2Gi RWX Retain Released study/pvc2 127m
pv3 3Gi RWX Retain Available 127m
# persistentVolumeReclaimPolicy:Retain 所以要手动释放,并重新声明
将pv从Released 变为 Available
使用edit命令删除pv中的pvc的绑定信息即可变为available
[root@master k8s]# kubectl get pv -n study
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Released study/pvc1 129m
pv2 2Gi RWX Retain Released study/pvc2 129m
pv3 3Gi RWX Retain Available 129m
[root@master k8s]# kubectl edit pv pv2 # pv1
# 删除下面字段
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: pvc2
namespace: study
resourceVersion: "849619"
uid: fac30e1d-90a5-4e8b-9092-e6b83fd55d62
persistentvolume/pv2 edited
[root@master k8s]# kubectl get pv -n study
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv1 1Gi RWX Retain Available 134m
pv2 2Gi RWX Retain Available 134m
pv3 3Gi RWX Retain Available 134m
问题
pv创建不会检测nfs的路径是否连上,哪怕nfs都没有这个配置也连不上也能创建,不会报错,甚至后续的pvc和pod连接pvc都不会报错
动态供应
- 静态供应:集群管理员创建若干 PV 卷。这些卷对象带有真实存储的细节信息,并且对集群用户可用(可见)。PV 卷对象存在于 Kubernetes API 中,可供用户消费(使用)。
- 动态供应:集群自动根据 PVC 创建出对应 PV 进行使用
- ① 集群管理员预先创建存储类(StorageClass)。
- ② 用户创建使用存储类的持久化存储声明(PVC:PersistentVolumeClaim)。
- ③ 存储持久化声明通知系统,它需要一个持久化存储(PV: PersistentVolume)。
- ④ 系统读取存储类的信息。
- ⑤ 系统基于存储类的信息,在后台自动创建 PVC 需要的 PV 。
- ⑥ 用户创建一个使用 PVC 的 Pod 。
- ⑦ Pod 中的应用通过 PVC 进行数据的持久化。
- ⑧ PVC 使用 PV 进行数据的最终持久化处理。
https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
设置 NFS 动态供应
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # 指定一个供应商的名字
# or choose another name, 必须匹配 deployment 的 env PROVISIONER_NAME'
parameters:
archiveOnDelete: "false" # 删除 PV 的时候,PV 中的内容是否备份
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
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: ccr.ccs.tencentyun.com/gcr-containers/nfs-subdir-external-provisioner:v4.0.2
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.65.100 # NFS 服务器的地址
- name: NFS_PATH
value: /nfs/data # NFS 服务器的共享目录
volumes:
- name: nfs-client-root
nfs:
server: 192.168.65.100
path: /nfs/data
---
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
测试动态供应
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nginx-pvc
namespace: default
labels:
app: nginx-pvc
spec:
storageClassName: nfs-client # 注意此处
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: default
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.20.2
resources:
limits:
cpu: 200m
memory: 500Mi
requests:
cpu: 100m
memory: 200Mi
ports:
- containerPort: 80
name: http
volumeMounts:
- name: localtime
mountPath: /etc/localtime
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: localtime
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
- name: html
persistentVolumeClaim:
claimName: nginx-pvc
readOnly: false
restartPolicy: Always
设置 SC 为默认驱动
kubectl patch storageclass <your-class-name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
kubectl patch storageclass nfs-client -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nginx-pvc
namespace: default
labels:
app: nginx-pvc
spec:
# storageClassName: nfs-client 不写,就使用默认的
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
---
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: default
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.20.2
resources:
limits:
cpu: 200m
memory: 500Mi
requests:
cpu: 100m
memory: 200Mi
ports:
- containerPort: 80
name: http
volumeMounts:
- name: localtime
mountPath: /etc/localtime
- name: html
mountPath: /usr/share/nginx/html/
volumes:
- name: localtime
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
- name: html
persistentVolumeClaim:
claimName: nginx-pvc
readOnly: false
restartPolicy: Always
展望
特殊存储卷
ConfigMap
ConfigMap是一个比较特殊的存储卷,它的主要作用是用来存储配置信息的
创建configmap
apiVersion: v1
kind: ConfigMap
metadata:
name: configmap-test
namespace: study
data: # 下面都是要存储的数据
info: # 会创建一个名为info文件,文件内容如下
username:admin
password:123456
# 如果更新ConfigMap中的内容,容器中的值也会动态更新
# 更改后重新 apply 或 使用 edit命令
# 注意:需要一定时间
[root@master k8s]# kubectl apply -f configmap.yaml
configmap/configmap-test created
[root@master k8s]# kubectl get cm -n study
NAME DATA AGE
configmap-test 1 22s
kube-root-ca.crt 1 4d21h
创建pod挂载configmap
apiVersion: v1
kind: Pod
metadata:
name: pod-configmap
namespace: study
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts:
- mountPath: /configmap/config
name: config
volumes:
- name: config
configMap:
name: configmap-test # 绑定 configmap
[root@master k8s]# kubectl apply -f configmap.yaml
pod/pod-configmap created
[root@master k8s]# kubectl get pod -n study
NAME READY STATUS RESTARTS AGE
pod-configmap 1/1 Running 0 11s
[root@master k8s]# kubectl exec -it -n study pod-configmap -c nginx /bin/sh
# ls /configmap/config
info
# cat /configmap/config/info
username:admin password:123456
Secret
在kubernetes中,还存在一种和ConfigMap非常类似的对象,称为Secret对象,它主要用来存储敏感信息,例如密码、密钥、证书等等
Secret 是一个用于存储敏感数据的资源,所有的数据要经过base64编码,数据实际会存储在K8s中Etcd,然后通过创建Pod时引用该数据。
查询 Secret 的时候是加密,在pod容器里面显示的是解密后的内容
- 变量注入
- 数据卷挂载
kubectl create secret 支持三种数据类型:
- docker--registry:存储镜像仓库认证信息
- generic:从文件、目录或者字符串创建,例如存储用户名密码
- ts:存储证书,例如HTTPS证书
内置类型 | 用法 |
Opaque | 用户定义的任意数据 |
kubernetes.io/service-account-token | 服务账号令牌 |
kubernetes.io/dockercfg | ~/.dockercfg 文件的序列化形式 |
kubernetes.io/dockerconfigjson | ~/.docker/config.json 文件的序列化形式 |
kubernetes.io/basic-auth | 用于基本身份认证的凭据 |
kubernetes.io/ssh-auth | 用于 SSH 身份认证的凭据 |
kubernetes.io/tls | 用于 TLS 客户端或者服务器端的数据 |
bootstrap.kubernetes.io/token | 启动引导令牌数据 |
yaml 解析
# 准备base64加密数据
echo -n "admin" | base64
echo -n "123456" | base64
apiVersion: v1
kind: Secret
metadata:
name: secret
namespace: dev
type: Opaque
data: # 下面存存储敏感信息,已base64加密
# 这里 username 是一个文件名,这里 password 是一个文件名
username: YWRtaW4=
password: MTIzNDU2
# mysql-root-password:"MTIzNDU2"
stringData: #如果不手动进行编码加密,可以将这个操作让k8s来做,使用stringdata
username: admin
password: "123456"
# 不能直接写数字,不然会报错 cannot convert int64 to string,如果要写数字就加""
注:如果同时使用data和stringData,那么data会被忽略
[root@master k8s]# kubectl apply -f secret.yaml
secret/secret created
[root@master k8s]# kubectl describe secrets -n study
Name: secret
Namespace: study
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 6 bytes
username: 5 bytes
数据卷挂载
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
namespace: study
spec:
containers:
- name: nginx
image: nginx:1.17.1
volumeMounts:
- mountPath: /secret/config
name: secret-config
volumes:
- name: secret-config
secret:
secretName: secret
kubectl exec -it -n study pod-secret -c nginx /bin/sh
# cat /secret/config/password
123456
解码 Secret
kubectl get secret db-user-pass -o jsonpath='{.data}' | base64
变量注入
[root@master cks]# echo -n "123456" | base64
MTIzNDU2
apiVersion: v1
kind: Secret
metadata:
name: mysql
type: Opaque
data:
mysql-root-password: "MTIzNDU2"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql-db
image: mysql:5.7.30
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql
key: mysql-root-password
将 secret 的mysql中的mysql-root-passwd变量注入到 容器中的 MYSQL_ROOT_PASSWORD 变量
[root@master cks]# kubectl exec -it mysql-6c8b6c4d74-vbflz /bin/sh
# mysql -uroot -p123456
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.30 MySQL Community Server (GPL)
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
镜像拉取密码
imagePullSecret:Pod拉取私有镜像仓库的时使用的账户密码,会传递给kubelet,然后kubelet就可以拉取有密码的仓库里面的镜像
kubectl create secret docker-registry docker-harbor-registrykey --docker-server=192.168.18.119:85 \
--docker-username=admin --docker-password=Harbor12345 \
--docker-email=1900919313@qq.com
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: 192.168.18.119:85/yuncloud/redis # 这是Harbor的镜像私有仓库地址
imagePullSecrets:
- name: docker-harbor-registrykey