k8s存储卷-动态PV

这篇具有很好参考价值的文章主要介绍了k8s存储卷-动态PV。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

pv和PVC,存储卷:

存储卷:

EmptyDir:容器内部,随着pod销毁,emptyDir也会消失,不能做数据持久化

HostPath:持久化存储数据,可以和节点上目录做挂载,pod被销毁了数据还在

NFS:一台机器,提供pod发起的挂载的请求

PV和PVC:

PVC就是pid发起挂载的反请求:

PV持久化存储的目录,ReadWriteMary

                     ReadOnlyMany

                     ReadwriteOnce

Nfs:可以支持三种方式

HostPath ReadwriteOnce

Iscsi不支持ReadwriteMany

pv的回收策略:

Retain released需要人工设置,调整回available

              Recyc 回收,自动调整回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卷插件

架构图:

k8s存储卷-动态PV,kubernetes,容器,云原生

实验演示:

k8s存储卷-动态PV,kubernetes,容器,云原生

/opt/k8s 20.0.0.0/24(rw,no_root_squash,sync)

k8s存储卷-动态PV,kubernetes,容器,云原生

vim /etc/exports

systemctl restart rpcbind

systemctl restart nfs

showmount -e

k8s存储卷-动态PV,kubernetes,容器,云原生

其他节点查看:

showmount -e 20.0.0.74

k8s存储卷-动态PV,kubernetes,容器,云原生

、创建 Service Account,用来管理 NFS Provisioner 在 k8s 集群中运行的权限,

设置 nfs-client 对 PV,PVC,StorageClass 等的规则

回到master节点:

创建serviceAccount:

Nfs provisioner:是一个插件,没有权限是无法再集群当中获取k8s的消息,插件要有权限能够监听apiserver,获取Get,list(获取集群的列表资源)创建一个资源账户

Rbac:Role-base ACCESS CONTORL 定义角色在集群当中可以使用的权限

#创建集群角色

kubectl explain ClusterRole  

#查看Kubernetes RBAC(Role-Based Access Control)的 ClusterRole 配置,

命名为 nfs-client-provisioner-clusterrole。这个 ClusterRole 定义了一组权限规则,

允许一个特定的服务账户(通常是用于 NFS 客户端 Provisioner 的账户)执行一些与存储相关的操作。

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

#创建集群角色

kubectl explain ClusterRole  

#查看Kubernetes RBAC(Role-Based Access Control)的 ClusterRole 配置,

命名为 nfs-client-provisioner-clusterrole。这个 ClusterRole 定义了一组权限规则,

允许一个特定的服务账户(通常是用于 NFS 客户端 Provisioner 的账户)执行一些与存储相关的操作。

k8s存储卷-动态PV,kubernetes,容器,云原生

vim nfs-client-rbac.yaml

apiVersion: v1

kind: ServiceAccount

metadata:

  name: nfs-client-provisioner

---

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  name: nfs-client-provisioner-clusterrole

rules:

  - 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: ["list", "watch", "create", "update", "patch"]

  - apiGroups: [""]

    resources: ["endpoints"]

    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]

---

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

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

部署插件:

NFS-privisioner , deployment来创建插件pod

1.20之后有一个新的机制

SelfLink:API的资源对象之一,表示资源对象在集群当中自身的一个连结,self-Link是一个唯一的标识号,可以用于标识k8s集群当中的每个资源的对象

Self Link的值是一个URL,指向该资源对象的k8s API路径

更好的实现资源对象的查找和引用

部署插件之前操作:

vim /etc/kubernetes/manifests/kube-apiserver.yaml

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

- --feature-gates=RemoveSelfLink=false

--feature-gates:在不破坏现有规则以及功能基础上引入新功能或者修改现有功能的机制,禁用不影响规则

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

k8s存储卷-动态PV,kubernetes,容器,云原生

#创建 NFS Provisioner

接下来部署NFS-privisioner插件:

NFS的provisionner的客户端以pod的方式运行在集群当中,监听k8s集群当中PV的请求,然后动态的创建于NFS相关的PV

容器里使用的配置,在provisioner当中定义好环境变量,传给容器,storageclass的名称,NFS服务器的地址,NFS的目录

vim nfs-client-provisioner.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: nfs1

spec:

  replicas: 1

  selector:

    matchLabels:

      app: nfs1

  strategy:

    type: Recreate

  template:

    metadata:

      labels:

        app: nfs1

    spec:

      serviceAccountName: nfs-client-provisioner          #指定Service Account账户

      containers:

        - name: nfs1

          image: quay.io/external_storage/nfs-client-provisioner:latest

          imagePullPolicy: IfNotPresent

          volumeMounts:

            - name: nfs

              mountPath: /persistentvolumes

          env:

            - name: PROVISIONER_NAME

              value: nfs-storage                #配置provisioner的Name,

            - name: NFS_SERVER

              value: 20.0.0.74             #配置绑定的nfs服务器

            - name: NFS_PATH

              value: /opt/k8s                   #配置绑定的nfs服务器目录

      volumes:                                  #申明nfs数据卷

        - name: nfs

          nfs:

            server: 20.0.0.74

            path: /opt/k8s

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

运行脚本

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

定义存储卷相关的请求数据,创建 StorageClass,负责建立 PVC 并调用 NFS provisioner 进行预定的工作,并让 PV 与 PVC 建立关联

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: nfs-client-storageclass

provisioner: nfs-storage

parameters:

  archiveOnDelete: "false"

reclaimPolicy: Retain

allowVolumeExpansion: true

vim nfs-client-storageclass.yaml

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

解析:

NAME: storageclass的名称

PROVISIONER: 对应的创建PV的provision的插件

RECLAIMPOLICY:回收策略,保留

VOLUMEBINDINGMODE:卷绑定模式,immediate表示PVC请求创建PV时,系统会立即绑定一个可用的PV

WaitForFirstConsumer:第一个使用出现之后再绑定PV

ALLOWVOLUMEEXPANSION:表示可以在运行时对PV进行扩容

创建 PVC 和 Pod 测试

k8s存储卷-动态PV,kubernetes,容器,云原生

vim test-pvc-pod.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: nfs-pvc

spec:

  accessModes:

    - ReadWriteMany

  storageClassName: nfs-client-storageclass

  resources:

    requests:

      storage: 2Gi

---

apiVersion: apps/v1

kind: Deployment

metadata:

  name: test-storageclass-deployment

  labels:

    app: nginx1

spec:

  replicas: 1

  selector:

    matchLabels:

      app: nginx1

  template:

    metadata:

      labels:

        app: nginx1

    spec:

      containers:

      - name: nginx1

        image: nginx:1.22

        volumeMounts:

        - name: nfs-pvc

          mountPath: /usr/share/nginx/html

      volumes:

      - name: nfs-pvc

        persistentVolumeClaim:

          claimName: nfs-pvc

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

测试

k8s存储卷-动态PV,kubernetes,容器,云原生

共享成功

k8s存储卷-动态PV,kubernetes,容器,云原生

//查看 NFS 服务器上是否生成对应的目录,

自动创建的 PV 会以 ${namespace}-${pvcName}-${pvName} 的目录格式放到 NFS 服务器上

ls /opt/k8s/

k8s存储卷-动态PV,kubernetes,容器,云原生

再添加一条测试,看是否能够同时绑定多条

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

共享服务器查看

k8s存储卷-动态PV,kubernetes,容器,云原生

如何删除恢复

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

再次使用时数据并没有删除

如何修改回收策略

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

没有回收策略

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

k8s存储卷-动态PV,kubernetes,容器,云原生

动态PV的默认策略是删除,共享目录也会被删除

k8s存储卷-动态PV,kubernetes,容器,云原生

总结:动态PV

Provisioner插件---支持NFS

Stroageclass:定义PV的属性

动态PV的默认策略是删除,动态策略没有回收

动态PV删除PVC之后的状态,released

总的来说:文章来源地址https://www.toymoban.com/news/detail-797549.html

  1. 创建账号,给卷插件能够在集群内部运行,获取资源,监听时间,创建,删除,更新PV
  2. 创建插件pod,卷插件的pod创建PV
  3. Storageclass:给PV赋予权限(PVC被删除之后的状态,以及回收策略)
  4. 创建PVC----完成

到了这里,关于k8s存储卷-动态PV的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • K8S临时存储-本地存储-PV和PVC的使用-动态存储(StorageClass)

    容器中的文件在磁盘上是临时存放的,当容器崩溃或停止时容器上面的数据未保存, 因此在容器生命周期内创建或修改的所有文件都将丢失。 在崩溃期间,kubelet 会以干净的状态重新启动容器。 当多个容器在一个 Pod 中运行并且需要共享文件时,会出现另一个问题,跨所有容

    2024年04月16日
    浏览(50)
  • 【K8S 存储卷】K8S的存储卷+PV/PVC

    目录 一、K8S的存储卷 1、概念: 2、挂载的方式: 2.1、emptyDir: 2.2、hostPath: 2.3、NFS共享存储: 二、PV和PVC: 1、概念 2、请求方式 3、静态请求流程图: 4、PV和PVC的生命周期 5、PV的状态: 6、PV的读写挂载方式: 7、回收策略: 三、PV和PVC静态请求实验: 1、默认的Retain保留策

    2024年02月02日
    浏览(57)
  • Kubernetes(k8s)安装NFS动态供给存储类并安装KubeSphere

    它是一款全栈的 Kubernetes 容器云 PaaS 解决方案(来源于官网),而我觉得它是一款强大的Kubernetes图形界面,它继承了如下组件 (下面这段内容来自官网): Kubernetes DevOps 系统 基于 Jenkins 为引擎打造的 CI/CD,内置 Source-to-Image 和 Binary-to-Image 自动化打包部署工具 基于 Istio 的微

    2024年02月09日
    浏览(41)
  • K8S动态PV

    pv和pvc存储卷 存储卷: emptyDir容器内部,随着pod销毁,emptyDir也会消失,不能做数据持久化 hostPath:持久化存储数据,可以和节点上目录做挂载。pod被销毁了数据还在 NFS:一台机器,提供pod内容器所有的挂载点 pv和pvc: pvc就是pod发起得挂载得请求 pv:持久化存储得目录,Re

    2024年01月23日
    浏览(50)
  • k8s ------存储卷(PV、PVC)

    目录 一:为什么需要存储卷? 二:emptyDir存储卷  ​三:hostPath存储卷  四:nfs共享存储卷   五:PVC 和 PV 1、PVC 和 PV介绍 2、PV和PVC之间的相互作用遵循的生命周期 3、PV 的4 种状态 4、一个PV从创建到销毁的具体流程 六:静态创建pv和pvc资源由pod运用过程 ​1、配置nfs存储 ​

    2024年02月13日
    浏览(47)
  • k8s 存储卷和pvc,pv

    存储卷---数据卷 容器内的目录和宿主机的目录进行挂载。 容器在系统上的生命周期是短暂的,deletek8s用控制器创建的pod,delete相当于重启,容器的状态也会回复到初始状态。 一旦回到初始状态,所有的后天编辑的文件的都会消失。 容器容器和节点之间创建一个可以持久化保

    2024年01月16日
    浏览(51)
  • k8s中的PV和PVC存储介绍

    目录 一.PV介绍 1.含义 2.关键配置参数 二.PVC介绍 1.含义 2.关键参数配置 三.PV和PVC的生命周期问题 1.PV的生命周期会有4个阶段 2.用户申请空间PV的周期流程 3.PV和PVC的使用/释放/回收 四.案例演示 1.NFS配置 2.新建PV 3.新建PVC 4.新建Pod测试 5.模拟删除Pod后后端目录内数据不会受影响

    2024年03月15日
    浏览(50)
  • K8S持久化存储--- PVC和PV的存储

    PersistentVolume ( PV )是群集中的一块存储,由管理员配置或使用存储类动态配置。 它是集群中的资源,就像 pod 是 k8s 集群资源一样。 PV是容量插件,如 Volumes ,其生命周期独立于使用 PV 的任何单个 pod 。 PersistentVolumeClaim ( PVC )是一个持久化存储卷,我们在创建 pod 时可以

    2023年04月10日
    浏览(51)
  • k8s--动态pvc和pv

    目录 前情回顾 动态pv 实验模拟 步骤一:在stor01节点上安装nfs,并配置nfs服务 接下来在matser01上配置 步骤二:创建 Service Account,用来管理 NFS Provisioner 在 k8s 集群中运行的权限和动态规则 步骤三:使用 Deployment 来创建 NFS Provisioner  部署nfs-provisioners插件: 步骤四:创建 St

    2024年01月24日
    浏览(52)
  • 【云原生】K8S存储卷:PV、PVC详解

    容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题。首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次,在Pod中同时运行多个容器时,这些容器之间通常需要共

    2024年02月12日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包