pv和pvc,存储卷:
存储卷:
emptyDir 容器内部,随着pod销毁,emptyDir也会消失 不能做数据持久化
hostPath:持久化存储数据 可以和节点上的目录做挂载。pod被销毁了数据还在
NFS:一台机器,提供pod内容器所有的挂载点。
pv和pvc:
pvc就是pod发起的挂载的请求
pv:持久化存储的目录,ReadWriteMany
ReadOnlyMany
ReadWriteOnce
NFS可以支持三种方式
hostPath 只支持ReadWriteOnce
ISCSI 不支持ReadWirteMany
pv的回收策略:
Retain released 需要人工设置,调整回Avaliable
Recycle 回收,自动调整回Available
Delete:删除
静态pv和pvc:
运维负责pv:创建好持久化存储卷,声明好读写和挂载类型 以及可以提供的存储空间
pvc开发做,要和开发沟通好,你期望的读写和挂载类型,以及存储空间。
当我发布一个pvc之后,可以自动生成pv,还可以在共享服务器上直接生成挂载目录。
pvc直接绑定和使用pv。
动态pv需要两个组件:
1、存储卷插件,k8s本身支持的动态pv创建不包括nfs,需要声明和安装一个外部插件。
Provisioner:存储分配器。可以动态创建pv,然后根据pvc的请求自动绑定和使用。
2、StorageClass:来定义pv的属性,存储类型,大小,回收策略。
还是用nfs来实现动态pv。NFS支持的方式NFS-client。Provisioner来适配nfs-client
nfs-client-provisioner卷插件。
准备共享目录
rpcbind
到其他节点查看
回到master节点
serviceAccount:
NFS PRovisioner:是一个插件,没有权限是无法再集群当中获取k8s的消息。插件要有权限能够监听apiserver,获取get,list(获取集群的列表资源)create delete
rbac:Role based ACCESS CONTROL
定义角色在集群中可以使用的资源
查看ServiceAccount的格式
创建 Service Account,用来管理 NFS Provisioner 在 k8s 集群中运行的权限,
设置 nfs-client 对 PV,PVC,StorageClass 等的规则
vim nfs-client-rbac.yaml
#创建 Service Account 账户,用来管理 NFS Provisioner 在 k8s 集群中运行的权限
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
---
#创建集群角色
kubectl explain ClusterRole
#查看Kubernetes RBAC(Role-Based Access Control)的 ClusterRole 配置,
命名为 nfs-client-provisioner-clusterrole。这个 ClusterRole 定义了一组权限规则,
允许一个特定的服务账户(通常是用于 NFS 客户端 Provisioner 的账户)执行一些与存储相关的操作。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: nfs-client-provisioner-clusterrole
rules:
- apiGroups: [""]
#apigroup定义了规则使用哪个API的组,空字符"",直接使用API的核心组的资源。
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
#表示获取权限的动作:获取资源,获取资源列表,监听API,创建,删除pv的信息
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
---
#集群角色绑定 kubectl explain ClusterRoleBinding 查看字段详情
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: nfs-client-provisioner-clusterrolebinding
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-clusterrole
apiGroup: rbac.authorization.k8s.io
查看apiversion的信息
查看如何绑定角色和权限
kubectl apply -f nfs-client-rbac.yaml
apiVersion 和 kind:
apiVersion: rbac.authorization.k8s.io/v1: 表示这是 RBAC API 的版本。
kind: ClusterRole: 表示这是一个 ClusterRole,即集群级别的角色。
metadata:
name: nfs-client-provisioner-clusterrole: 给这个 ClusterRole 起一个名字,方便在集群中引用。
rules:
这是权限规则的列表,定义了该角色拥有的权限。
每个规则(rule)的结构如下:
apiGroups: 定义这个规则适用的 API 组。在这里,使用了空字符串 "" 表示核心 API 组。
resources: 定义了这个规则适用的资源类型。例如,persistentvolumes 表示持久卷,
persistentvolumeclaims 表示持久卷声明,storageclasses 表示存储类,
events 表示事件,
endpoints 表示服务的终结点。
verbs: 定义了这个规则允许的操作,
如 get(获取资源信息)、list(列出资源列表)、
watch(监视资源变化)、create(创建资源)、delete(删除资源)等。
核心 API 组通常是默认的 API 组,无需额外的路径前缀
通过这个 ClusterRoleBinding,服务账户 nfs-client-provisioner 将被
授予 ClusterRole nfs-client-provisioner-clusterrole 中定义的一组权限,
使其能够执行与持久卷、持久卷声明、存储类、事件和服务终结点相关的操作。
角色 权限都已经创建完毕
部署插件:
NFS-privisioner。deployment来创建插件 pod
1.20之后有一个新的机制
selfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连接,self-link是一个唯一标识符号,可以用于标识k8s集群每个资源的对象。
self-link的值是一个URL,指向该资源对象的k8s api的路径。
更好的实现资源对象的查找和引用。
feature-gates=RemoveSelfLink=false
feature-gates:在不破坏现有规则及功能的基础上引入新功能或者修改现有功能的机制。
禁用不影响之前的规则。
部署nfs-provisioner的插件:
nfs的provisioner的客户端以pod的方式运行在集群当中,监听k8s集群当中pv的请求。动态的创建
于NFS服务器相关的pv。
容器里使用的配置,在provisioner当中定义好环境变量,传给容器,storageclass的名称,nfs服务器的地址,nfs的目录。
vim /etc/kubernetes/manifests/kube-apiserver.yaml
spec:
containers:
- command:
- kube-apiserver
- --feature-gates=RemoveSelfLink=false #添加这一行
- --advertise-address=192.168.233.91
Feature Gate 提供了一种在不破坏现有功能的基础上引入新功能或修改现有功能的机制。
通过在 API Server 启动时设置 Feature Gate 选项,可以在集群中启用或禁用特定功能。
kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml
kubectl delete pods kube-apiserver -n kube-system
kubectl get pods -n kube-system | grep apiserver
#创建 NFS Provisioner插件
vim nfs-client-provisioner.yaml
apiVersion:apps/v1
kind:Deployment
metadata:
name: nfs-provisioner
labels:
app: nfs1
spec:
replicas: 1
selector:
matchLabels:
app: nfs1
template:
metadata:
labels:
app: nfs1
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs1
image: quay,io/external_storage/nfs-client-provisioner;latest
volumeMounts:
- name: nfs
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: nfs-storage
#配置provisioner的账户名称,要和storageclass的资源名称一致
- name: NFS_SERVER
#指的是nfs共享服务器的地址
value: 192.168.233.94
- name: nfs
nfs:
server: 192.168.233.94
path: /opt/k8s
vim stroageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client-storageclass
#匹配provisioner: nfs-storage
parameters:
archiveOnDeleate: "false"
#pvc被删除之后,pv的状态,定义的是false,pvc被删除,pv的状态将是released,可以人工调整,继续使用
#如果是true,pv的将是Archived,表示pv不再可用
reclaimPolicy: Retain
#定义pv的回收策略,retain,另一个是delete。不支持回收
allowvolumeExpansion: true
#表示pv的存储空间可以动态的扩缩容。
kubectl apply -f nfs-client
provisioner的作用,创建pv
kubectl get storageclass.storage.k8s.io
name:storageclass的名称
PROVISIONER:对应的创建pv的 PROVISIONER的插件
RECLAIMPOLICY:回收策略,保留
VOLUMEBINDINGMODE:卷绑定模式,immediate表示pvc请求创建pv时,系统会立即绑定一个可用的pv
waitForFirstConsumer:第一个使用者出现之后再绑定pv。
ALLOWVOLUMEEXPANSION:true 表示可以在运行时对pv进行扩容。
10:55
kubectl expalain pvc
定义pvc
vim pvc-pod.yaml
apiversion:v1
kind:PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
storageClassName: nfs-client-storageclass
resources:
requests:
storage: 2Gi
#创建一个pvc,名称为nfs-pvc,使用的pv属性是nfs-client-storageclass定义的属性,创建的pv的大小是2G
---
apiVersion:apps/v1
kind:Deployment
metadata:
name: nginx1
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
matadata:
labels:
app: nginx1
spec:
containers:
- name: nginx1
image: nginx:1.22
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumes:
- name: html
persistentVolumeClaim:
claimName: nfs-pvc
到共享目录上写入信息
回到master查看情况
vim test1.yaml
删除字段
查看
重新apply,查看一下,又可以继续使用
修改回复策略:
改为Recycle,试试是否支持
发现只支持保留和删除策略
改为删除策略:
创建
查看,然后删除,查看状态
变为不可用状态,然后重新创建一下,用的就是删除的策略
查看
删除pvc查看一下状态
pv的共享目录也被删除
动态pv的默认策略是删除。delete
不加默认就是delete
注:一定要先删除原来的storageclass再重新创建
查看,发现动态的默认策略是delete
总结:动态pv
provisioner插件------支持nfs,创建pv目录
storageclass:定义pv的属性
动态pv的默认策略是删除(重要)
动态pv删除pvc之后的状态,最好调整为released
1、创建账号,给卷插件能够在集群内部通信,获取资源,监听事件,创建,删除,更新pv
2、创建卷插件pod,卷插件的pod创建pv
3、storageclass:给pv赋予属性(pvc被删除之后pv的状态,以及回收策略)
4、创建pvc------完成。