c# msi中加入驱动_Kubernetes 中部署 NFS Provisioner 为 NFS 提供动态分配卷上篇

本文介绍了NFS Provisioner在Kubernetes中的作用,它是如何动态配置NFS服务器作为持久卷,并详细阐述了外部NFS驱动的工作原理,特别是nfs-client。文章还提供了使用nfs-client-provisioner部署NFS服务的步骤,强调了前提条件和授权配置的重要性。
摘要由CSDN通过智能技术生成
ac75beefbf1badb2cbc5b123f66c6bf6.png

一、NFS Provisioner 简介

NFS Provisioner 是一个自动配置卷程序,它使用现有的和已配置的 NFS 服务器来支持通过持久卷声明动态配置 Kubernetes 持久卷。

  • 持久卷被配置为:namespace−{pvcName}-${pvName}。

二、External NFS 驱动的工作原理

K8S 的外部 NFS 驱动,可以按照其工作方式(是作为 NFS server 还是 NFS client)分为两类:

1、nfs-client

  • 也就是我们接下来演示的这一类,它通过 K8S 的内置的NFS驱动挂载远端的 NFS 服务器到本地目录;然后将自身作为 storage provider,关联 storage class。当用户创建对应的 PVC 来申请 PV 时,该 provider 就将 PVC 的要求与自身的属性比较,一旦满足就在本地挂载好的 NFS 目录中创建 PV 所属的子目录,为 Pod 提供动态的存储服务。

2、nfs

  • 与 nfs-client 不同,该驱动并不使用 k8s 的 NFS 驱动来挂载远端的 NFS 到本地再分配,而是直接将本地文件映射到容器内部,然后在容器内使用ganesha.nfsd 来对外提供 NFS 服务;在每次创建 PV 的时候,直接在本地的 NFS 根目录中创建对应文件夹,并 export 出该子目录。利用NFS动态提供 Kubernetes 后端存储卷
  • 本文将介绍使用 nfs-client-provisioner 这个应用,利用 NFS Server 给 Kubernetes 作为持久存储的后端,并且动态提供 PV。前提条件是有已经安装好的 NFS 服务器,并且 NFS 服务器与 Kubernetes 的 Slave 节点都能网络连通。将 nfs-client 驱动做一个 deployment 部署到 K8S 集群中,然后对外提供存储服务。

nfs-client-provisioner 是一个 Kubernetes 的简易NFS的外部 provisioner,本身不提供 NFS,需要现有的 NFS 服务器提供存储。

三、部署服务

1、配置授权

现在的 Kubernetes 集群大部分是基于 RBAC 的权限控制,所以创建一个一定权限的 ServiceAccount 与后面要创建的 “NFS Provisioner” 绑定,赋予一定的权限。

# 清理rbac授权kubectl delete -f nfs-rbac.yaml -n kube-system​# 编写yamlcat >nfs-rbac.yaml<

2、部署 nfs-client-provisioner

首先克隆仓库获取 yaml 文件

git clone https://github.com/kubernetes-incubator/external-storage.gitcp -R external-storage/nfs-client/deploy/ /root/cd deploy

3、部署 NFS Provisioner

修改 deployment.yaml 文件,这里修改的参数包括 NFS 服务器所在的 IP 地址(10.198.1.155),以及 NFS 服务器共享的路径(/data/nfs/),两处都需要修改为你实际的 NFS 服务器和共享目录。另外修改 nfs-client-provisioner 镜像从七牛云拉取。

设置 NFS Provisioner 部署文件,这里将其部署到 “kube-system” Namespace 中。

# 清理NFS Provisioner资源kubectl delete -f nfs-provisioner-deploy.yaml -n kube-system​export NFS_ADDRESS='10.198.1.155'export NFS_DIR='/data/nfs'​# 编写deployment.yamlcat >nfs-provisioner-deploy.yaml<


4、创建 StorageClass

storage class 的定义,需要注意的是:provisioner 属性要等于驱动所传入的环境变量 PROVISIONER_NAME 的值。否则,驱动不知道知道如何绑定storage class。 此处可以不修改,或者修改 provisioner 的名字,需要与上面的deployment 的 PROVISIONER_NAME 名字一致。

# 删除命令空间kubectl delete ns kube-public# 创建命名空间kubectl create ns kube-public# 清理pvckubectl delete -f test-claim.yaml -n kube-public# 编写yamlcat >test-claim.yaml<

四、创建 PVC

01、创建一个新的 namespace,然后创建 pvc 资源

# 清理storageclass资源kubectl delete -f nfs-storage.yaml# 编写yamlcat >nfs-storage.yaml<

五、创建测试 Pod

# 清理资源kubectl delete -f test-pod.yaml -n kube-public# 编写yamlcat > test-pod.yaml <

01、进入 NFS Server 服务器验证是否创建对应文件

进入 NFS Server 服务器的 NFS 挂载目录,查看是否存在 Pod 中创建的文件:

$ cd /data/nfs/$ lsarchived-kube-public-test-claim-pvc-2dd4740d-f2d1-4e88-a0fc-383c00e37255 kube-public-test-claim-pvc-ad304939-e75d-414f-81b5-7586ef17db6carchived-kube-public-test-claim-pvc-593f241f-a75f-459a-af18-a672e5090921 kube-system-test1-claim-pvc-f84dc09c-b41e-4e67-a239-b14f8d342efcarchived-kube-public-test-claim-pvc-b08b209d-c448-4ce4-ab5c-1bf37cc568e6 pv001default-test-claim-pvc-4f18ed06-27cd-465b-ac87-b2e0e9565428 pv002# 可以看到已经生成 SUCCESS 该文件,并且可知通过 NFS Provisioner 创建的目录命名方式为 “namespace名称-pvc名称-pv名称”,pv 名称是随机字符串,所以每次只要不删除 PVC,那么 Kubernetes 中的与存储绑定将不会丢失,要是删除 PVC 也就意味着删除了绑定的文件夹,下次就算重新创建相同名称的 PVC,生成的文件夹名称也不会一致,因为 PV 名是随机生成的字符串,而文件夹命名又跟 PV 有关,所以删除 PVC 需谨慎。

参考文档:

https://blog.csdn.net/qq_25611295/article/details/86065053 k8s pv 与pvc 持久化存储(静态与动态)

https://blog.csdn.net/networken/article/details/86697018 kubernetes部署 NFS 持久存储

https://www.jianshu.com/p/5e565a8049fc kubernetes 部署 NFS 持久存储(静态和动态)

出处:https://dwz.cn/qcjgGS7F

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值