动态pv策略和组件

本文详细介绍了Kubernetes中的PV(持久化卷)、PVC(持久化卷声明)以及动态PV的创建过程,包括emptyDir、hostPath、NFS等存储选项,StorageClass的定义,以及如何通过Provisioner和rbac授权管理权限。重点强调了动态PV的默认删除策略和回收策略的调整。
摘要由CSDN通过智能技术生成

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------完成。

  • 19
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值