K8S初级入门系列之九-共享存储

一、前言

     Pod里面的容器都有自己独立的文件系统，来自容器镜像，用于保存容器运行的数据，但容器的文件存储有两个弊端，一个是无法持久化，其生命周期与容器一致，一旦容器销毁，相关的数据也就随之一起销毁；二是无法共享，Pod里多个容器之间无法共享数据，会导致无法提供完整的服务，比如监控容器需要读取业务容器提供的日志数据，就无法实现。

     为解决以上问题，K8S提供多种类型存储卷。

二、存储卷类型

  实际上，在前面的章节中，已经接触到各种卷，比如在K8S初级入门系列之四-Namespace/ConfigMap/Secret章节中，ConfigMap与Secret就是K8S公开给Pod的特殊类型的卷。K8S支持的存储卷类型有很多。

1、EmptyDir

     emptyDir用于同一Pod下多个容器间的共享存储，其形式是存储临时数据的简单空目录，既然是临时的，一旦Pod删除，其存储的内容也就丢失了。我们来看下面的场景:

      该Pod中有两个容器，分别为write-app和read-app,其中write-app将数据写入到/wite-app/logs文件下，而read-app容器从/read-app/logs文件读取数据。/write-app/logs与/read-app/logs都指向同一个共享存储卷，其类型为emptyDir，这个完成两个容器的数据共享。其yaml如下：

[root@k8s-master yaml]# cat emptydir-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: emptydir-pod
spec:containers:- image: busyboxname: write-appvolumeMounts:- mountPath: /write-app/logsname: shared-dirargs:- /bin/sh- -c- echo this is  write-app >> /write-app/logs/app.log; sleep 60000- image: busyboxname: read-appvolumeMounts:- mountPath: /read-app/logsname: shared-dirargs:- /bin/sh- -c- cat /read-app/logs/app.log; sleep 60000volumes:- name: shared-diremptyDir: {}

其yaml模型解析如下：

    在每个容器中定义挂载点，并指定挂载的本地目录，以及指向的卷名称。再定义一个卷，设置卷名称和类型，这样就通过卷名称将容器的挂载点与该卷进行关联。

    执行该文件，创建Pod后，从read-app容器中查看下log数据

[root@k8s-master yaml]# kubectl apply -f emptydir-pod.yaml 
pod/emptydir-pod created
[root@k8s-master yaml]# kubectl exec emptydir-pod -c read-app cat /read-app/logs/app.log
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
this is write-app

可以看到，正确的读取到了write-app容器写入的字符，从而实现了Pod内的存储共享。

2、HostPath

     EmptyDir是实现Pod内容器间的存储共享，HostPath是实现节点内Pod间的文件共享。以上面的场景为例。

       HostPath是Pod所在节点服务器上的文件存储(即/tmp),该节点上的两个Pod容器，共享该文件存储。将上面的例子分拆成两个Pod，其yaml文件如下：

  • hostpath-write-pod.yaml
[root@k8s-master yaml]# cat hostpath-write-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: hostpath-write-pod
spec:containers:- image: busyboxname: write-appvolumeMounts:- mountPath: /write-app/logsname: shared-dirargs:- /bin/sh- -c- echo this is  write-app >> /write-app/logs/app.log; sleep 60000volumes:- name: shared-dirhostPath: path: /tmp
  • hostpath-read-pod.yaml内容如下:
[root@k8s-master yaml]# cat hostpath-read-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: hostpath-read-pod
spec:containers:- image: busyboxname: read-appvolumeMounts:- mountPath: /read-app/logsname: shared-dirargs:- /bin/sh- -c- cat /read-app/logs/app.log; sleep 60000volumes:- name: shared-dirhostPath: path: /tmp

       执行文件，创建Pod成功后，进入到read-app的Pod的容器，查看数据读取。

[root@k8s-master tmp]# kubectl exec hostpath-read-pod -c read-app cat /read-app/logs/app.log
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
this is write-app

        如EmptyDir类型一样，能正确的读取到数据。按照HostPath的定义，这个app.log的实体文件应该位于所在节点服务器的/tmp目录下，我们查看下。

[root@k8s-node1 ~]# cd /tmp
[root@k8s-node1 tmp]# ll
total 12
-rw-r--r-- 1 root root   18 Apr 21 20:53 app.log
[root@k8s-node1 tmp]# cat app.log 
this is write-app

       可以看到，确实在Pod所在的节点(这两个Pod调度到了node1,非master)上的/tmp目录下写入了app.log，内容正是write-app写入的字符串。

      当删除这两个Pod后，该节点上的app.log文件还在，从而也实现了持久化存储。

      由于HostPath可以将容器的文件目录映射到节点的目录，从而无需每次都进入容器查看数据，要方便很多。比如我们在使用Ngnix容器时，就可以将其配置文件和日志文件映射到节点的文件中，直接在节点的文件系统就可以进行配置和查看。

3、NFS

    在多个节点间，如何共享存储卷呢？K8S提供了多种方式：

  • 基于云计算厂商的特定存储，比如Google的GCE持久化存储卷，AWS的EBS，微软的azureDisk等。
  • 基于网络文件存储，如NFS，CephFS，GlusterFS等。

下面就以NFS为例介绍节点间的共享存储，我们来改造上面的例子。

      NFS的服务端安装到master节点上，并配置/nfs/data的作为NFS的挂载路径，安装过程这里就省略了，可以自行查询相关文档。下面看下两个改造后的Pod的yaml文件

  • nfs-write-pod.yaml
[root@k8s-master yaml]# cat nfs-write-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: nfs-write-pod
spec:tolerations:- key: "node-role.kubernetes.io/master"operator: "Exists"effect: "NoSchedule"containers:- image: busyboxname: write-appvolumeMounts:- mountPath: /write-app/logsname: shared-nfs-dirargs:- /bin/sh- -c- echo this is  write-app >> /write-app/logs/app.log; sleep 60000volumes:- name: shared-nfs-dirnfs:server: 192.168.16.4path: /nfs/data

     该pod将volumes的类型改为nfs，并配置nfs的server(master节点ip)和path路径。为了将该Pod调度到master节点，增加了tolerations属性，这方面的内容可以参考K8S初级入门系列之五-Pod的高级特性

  • nfs-read-pod.yaml 
[root@k8s-master yaml]# cat nfs-read-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: nfs-read-pod
spec:containers:- image: busyboxname: read-appvolumeMounts:- mountPath: /read-app/logsname: shared-nfs-dirargs:- /bin/sh- -c- cat /read-app/logs/app.log; sleep 60000volumes:- name: shared-nfs-dirnfs:server: 192.168.16.4path: /nfs/data

     执行以上yaml文件，创建pod并查看pod状态：

[root@k8s-master yaml]# kubectl get pod -o wide
NAME                                     READY   STATUS             RESTARTS          AGE     IP               NODE         NOMINATED NODE   READINESS GATES
nfs-read-pod                             1/1     Running            0                 23m     10.244.36.72     k8s-node1    <none>           <none>
nfs-write-pod                            1/1     Running            0                 24m     10.244.235.199   k8s-master   <none>           <none>

       可以看到，nfs-write-pod按照要求调度到master节点上，而nfs-read-pod调度到node1节点上，进入nfs-read-pod读取日志文件。

[root@k8s-master data]# kubectl exec nfs-read-pod -c read-app cat /read-app/logs/app.log
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
this is write-app

       可以正确的读取到日志内容。由于NFS配置的是master节点的/nfs/data目录。进入该目录看下内容

[root@k8s-master yaml]# cd /nfs/data
[root@k8s-master data]# ll
total 4
-rw-r--r-- 1 root root 18 Apr 29 20:30 app.log
[root@k8s-master data]# cat app.log 
this is write-app

日志内容也已经写入了该文件。

三、PV/PVC

     前面所介绍的分配存储的方式都是命令式的，按照既定的指令创建存储。这里存在一个问题，在实际工程中，Pod的yaml文件一般是由开发人员维护，而存储卷作为底层资源，一般是由运维管理员维护，这种方式导致各方的工作无法解耦，这显然不符合K8S的设计理念。为了解决该问题，K8S提供了PV和PVC对象。如下图所示：

    管理员根据现有卷资源申明式创建PV(Persisten Volume，持久卷)，指定PV的大小和所支持的访问模式，注意的是，这里仅是申明，并没有分配实际的物理存储。开发人员根据需求申请PVC(Persistent VolumeClaim),指定所需的最小容量和访问模式，并将PVC作为卷使用到Pod中。K8S根据PVC的申请找到匹配的PV，并绑定到PVC，此时PVC就可以作为持久卷在Pod中使用了。

     可以将PV看做Class类，而PVC是该Class的Object对象实现。

下面我们就来实现下上面的过程。

1、PV的创建

首先申明一个PV（名为nfs-pv），其yaml如下：

[root@k8s-master yaml]# cat nfs-pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:name: nfs-pvlabels:pv: nfs-pv
spec:capacity:storage: 1GivolumeMode: FilesystemstorageClassName: my-storageaccessModes:- ReadWriteManypersistentVolumeReclaimPolicy: Recyclenfs:path: /nfs/dataserver: 192.168.16.4

我们来看下里面的核心属性:

1、capactity,定义PV的存储容量。

2、volumeMode，卷模式，包括以下两种:

  • Filesystem(文件系统)，会被Pod挂载到某个目录，默认的模式。
  • Block(块)，将卷作为原始块设备来使用，该模式以块设备的方式交给 Pod 使用，其上没有任何文件系统

3、storageClassName，存储类别，如果PV设定该类别，那么只有请求了该类别的PVC才能与之绑定，关于storyClass我们在第四节将专门介绍。

4、accessModes,访问模式，有以下几种模式，不同的卷插件类型，支持的模式也不同。

  • ReadWriteOnce(RWO)，可以被一个节点以读写方式挂载。
  • ReadOnlyMany(ROX)，可以被多个节点以只读方式挂载。
  • ReadWriteMany(RWX)，可以被多个节点以读写方式挂载。

5、persistentVolumeReclaimPolicy,当PV被释放后，回收策略，包括以下 几种：

  • Retain ，保留，需要手动回收。
  • Recycle ，回收空间，清除相关的文件。仅 NFS 和 HostPath 支持回收。本例的NFS就使用这种模式进行演示。
  • Delete， AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷这类关联存储资产也被删除。

6、卷插件，目前主要支持以下类型：

  • cephfs - CephFS volume
  • csi - 容器存储接口 (CSI)
  • fc - Fibre Channel (FC) 存储
  • hostPath - HostPath 卷 （仅供单节点测试使用；不适用于多节点集群；请尝试使用 local 卷作为替代）
  • iscsi - iSCSI (SCSI over IP) 存储
  • local - 节点上挂载的本地存储设备
  • nfs - 网络文件系统 (NFS) 存储
  • rbd - Rados 块设备 (RBD) 卷

    其他的卷插件如EBS，azureDisk，gcePersistentDisk等会在未来的版本中移除。本例中我们使用前面创建NFS类型。

    执行该yaml文件，完成PV创建，并查看其状态

[root@k8s-master yaml]# kubectl get pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv   1Gi        RWO            Recycle          Available           my-storage              29m

      这里我们关注下字段status为Available,表明当前的状态为可用，后面我们会讲到PV的生命周期。

2、PVC的创建

接下来我们创建PVC(名为nfs-pvc)，其yaml内容如下：

[root@k8s-master yaml]# cat nfs-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs-pvc
spec:storageClassName: my-storageaccessModes:- ReadWriteManyresources:requests:storage: 1Giselector:matchLabels:pv: nfs-pv

同样，我们也来看下核心属性参数：

1、storageClassName，卷类型，可以指定需要绑定的特定的PV卷类型，比如例子中的my-storage类型的PV，也可以设置为"",则被视为要请求的是没有设置存储类的 PV 卷。

2、accessModes,访问模式，与PV的模式类型一致。

3、resources，请求资源，对所需资源的描述，目前仅支持requests.storage

4、selector,对于PV的选择器，通过对于Label Selector的设置，可以实现对于已存在的PV筛选。

     执行该yaml文件，创建该PVC，并查看状态。

[root@k8s-master yaml]# kubectl get pvc
NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc   Bound    nfs-pv   1Gi        RWX            my-storage     7s

      可以看到，K8S已经为该PVC找到到合适的PV（即前面创建的nfs-pv），其PVC的状态的为Bound(绑定状态)。我们再来看下PV(nfs-pv)的状态

[root@k8s-master yaml]# kubectl get pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS   REASON   AGE
nfs-pv   1Gi        RWX            Recycle          Bound    default/nfs-pvc   my-storage              16m

此时，PV也变成为Bound状态。

3、使用PVC创建Pod

    最后，我们创建Pod，并使用上面创建的PVC作为卷。还以上面的场景为例，对Pod进行改造。

  •  pvc-read-pod.yaml
[root@k8s-master yaml]# cat pvc-read-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: pvc-read-pod
spec:containers:- image: busyboxname: read-appvolumeMounts:- mountPath: /read-app/logsname: shared-pvc-dirargs:- /bin/sh- -c- cat /read-app/logs/app.log; sleep 60000volumes:- name: shared-pvc-dirpersistentVolumeClaim:claimName: nfs-pvc

 将volumes修改为PVC，并指定名称为刚创建的nfs-pvc。

  • pvc-read-pod.yaml
[root@k8s-master yaml]# cat pvc-read-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: pvc-read-pod
spec:containers:- image: busyboxname: read-appvolumeMounts:- mountPath: /read-app/logsname: shared-pvc-dirargs:- /bin/sh- -c- cat /read-app/logs/app.log; sleep 60000volumes:- name: shared-pvc-dirpersistentVolumeClaim:claimName: nfs-pvc

同样将volumes修改为PVC。执行yaml文件，创建Pod，并查看状态

[root@k8s-master yaml]# kubectl get pod -o wide
NAME                                     READY   STATUS              RESTARTS            AGE    IP               NODE         NOMINATED NODE   READINESS GATES
pvc-read-pod                             1/1     Running             0                   80s    10.244.36.74     k8s-node1    <none>           <none>
pvc-write-pod                            1/1     Running             0                   89s    10.244.235.200   k8s-master   <none>           <none>

Pod成功创建，我们查看下NFS挂载的目录(即master节点的/data/nfs/)

[root@k8s-master yaml]# cd /nfs/data/
[root@k8s-master data]# ll
total 4
-rw-r--r-- 1 root root 18 Apr 30 21:07 app.log
[root@k8s-master data]# cat app.log 
this is write-app

该目录下正确的生成了app.log文件，并写入了正确的内容。

继续进入到nfs-read-pod，读取该文件的内容。

[root@k8s-master data]# kubectl exec pvc-read-pod -c read-app cat /read-app/logs/app.log
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
this is write-app

一切正常，至此，创建的PVC已经挂载到Pod上，并正常提供了卷服务。

4、生命周期

我们先总结下前面的生命周期状态的变化：

 接下来，我们删除PVC，看下PV

[root@k8s-master data]# kubectl delete pvc nfs-pvc
[root@k8s-master data]# kubectl get pv
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv   1Gi        RWX            Recycle          Available           my-storage              3h27m

在看下之前创建的文件，切换到/nfs/data目录

[root@k8s-master data]# cd /nfs/data/
[root@k8s-master data]# ll
total 0

      由于我们配置PV的persistentVolumeReclaimPolicy: Recycle(回收空间),所以PVC删除后，文件被删除，空间回收，PV重新变为了Available状态，可以再次被利用。补充以上的状态机图

 四、StorageClass

      通过PV和PVC，完美地解耦了运维管理员和开发人员的工作，但是也带来了新的问题，一个K8S集群中，有成千上万的PV，运维人员需要手动创建出来，而且在业务的迭代过程中，需要根据不断提交的PVC来实现PV，否则就可能PVC无法绑定PV，导致创建失败。那有没有方式，能根据PVC的申请来自动创建PV呢？这样就可以进一步解放运维管理员的生产力，投入到更有意义的工作中。

      答案就是StorageClass对象，它可以指定一个可以自动配置存储的插件，我们叫它制备器(Provisioner),根据PVC的资源需求，自动创建一个符合条件的PV，分配实际存储资源，并进行PVC绑定。

    运维管理员仅配置StorageClass，其他的过程都是K8S配合制备器自动完成。上面的协同模型就可以修改为以下：

      这种方式创建存储卷相比手动创建，我们称之为"动态存储卷"。我们看下StorageClass的核心参数。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: standard
provisioner: kubernetes.io/aws-ebs
parameters:type: gp2
  • provisioner，制备器，可以看做是每种卷插件的后端存储驱动。比如EBS的制备器可以制备EBS类型的卷。K8S为常用的卷插件提供内置的provisioner，比如EBS，AzureFile，GCEPersistentDisk，Glusterfs等，一般是以"kubernetes.io"开头，当然用户也可以按照规范自定义三方的制备器。
  • parameters，参数，provisioner的参数，不同的provisioner，参数也不同。

下面就以NFS为例，实现StorageClass的创建和使用过程。

1、创建NFS的StorageClass

       由于NFS没有内置的 Provisioner 对象，需要使用开源的，其以Pod的方式运行，GitHub的地址为：GitHub - kubernetes-sigs/nfs-subdir-external-provisioner: Dynamic sub-dir volume provisioner on a remote NFS server.

      下载deploy目录下的rbac.yaml,class.yaml,deploy.yaml，修改一些内容，使其与我们的NFS环境保持一致。修改后重新命名为 storage-nfs-rbac.yaml，storage-nfs-class.yaml，storage-nfs-deploy.yaml，其内容参见文章后面的附录，执行以上三个yaml文件，完成StorageClass的创建,名称为nfs-client。

kubectl apply -f storage-nfs-rbac.yaml
kubectl apply -f storage-nfs-class.yaml
kubectl apply -f storage-nfs-deployment.yaml

2、创建指定StorageClass的PVC

   接下来我们创建PVC，并指定StorageClass(nfs-client),其yaml内容如下

[root@k8s-master yaml]# cat nfs-storage-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs-storage-pvc
spec:# 这里使用刚创建的storage namestorageClassName: nfs-clientaccessModes:- ReadWriteManyresources:requests:storage: 1Gi

    执行该文件，创建PVC，查看状态：

[root@k8s-master yaml]# kubectl apply -f nfs-storage-pvc.yaml 
persistentvolumeclaim/nfs-storage-pvc created
[root@k8s-master yaml]# kubectl get pvc
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-storage-pvc   Bound    pvc-f795e09b-1583-436b-869b-88a68d28ce64   1Gi        RWX            nfs-client     5s

   可以看到已经创建完成，并处于Bound状态，这就说明已经有PV绑定了。在查看下PV的状态

[root@k8s-master yaml]# kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                     STORAGECLASS   REASON   AGE
pvc-f795e09b-1583-436b-869b-88a68d28ce64   1Gi        RWX            Delete           Bound       default/nfs-storage-pvc   nfs-client              10s

果然，NFS的provisioner已经自动创建PV，并完成了绑定。

3、创建使用PVC的Pod

接下来，使用之前的Pod用例来验证下写入功能，我们修改下yaml内容

[root@k8s-master yaml]# cat storageclass-write-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: storageclass-write-pod
spec:tolerations:- key: "node-role.kubernetes.io/master"operator: "Exists"effect: "NoSchedule"containers:- image: busyboxname: write-appvolumeMounts:- mountPath: /write-app/logsname: shared-storageclass-dirargs:- /bin/sh- -c- echo this is  write-app >> /write-app/logs/app.log; sleep 60000volumes:- name: shared-storageclass-dirpersistentVolumeClaim:claimName: nfs-storage-pvc

      将PVC的claimName修改为本次的PVC，名称nfs-storage-pvc，执行该文件，创建Pod成功后，我们是否写入到NFS的挂载目录

[root@k8s-master yaml]# cd /nfs/data
[root@k8s-master data]# ll
total 4
drwxrwxrwx 2 root root 4096 May  1 22:36 default-nfs-storage-pvc-pvc-f795e09b-1583-436b-869b-88a68d28ce64
[root@k8s-master data]# cd default-nfs-storage-pvc-pvc-f795e09b-1583-436b-869b-88a68d28ce64/
[root@k8s-master default-nfs-storage-pvc-pvc-f795e09b-1583-436b-869b-88a68d28ce64]# ll
total 4
-rw-r--r-- 1 root root 18 May  1 22:36 app.log
[root@k8s-master default-nfs-storage-pvc-pvc-f795e09b-1583-436b-869b-88a68d28ce64]# cat app.log 
this is write-app

    可以看到在/nfs/data下，K8S自动创建一个PVC名称加上随机数的文件夹，Pod写入的日志文件app.log位于该目录下。 

五、总结  

本章节我们介绍了K8S的共享存储。

1、同一Pod的容器间共享存储，可以使用EmptyDir。

2、同一节点的Pod的共享存储，可以使用HostPath。

3、不同节点间Pod的共享存储，可以使用云计算厂商提供的特定存储，也可以使用标准的网络文件存储，这里重点介绍了NFS。

4、为了解耦开发和运维人员的工作，K8S设计了PV和PVC，运维人员根据资源总量，申明式创建大量的PV，预先分配，开发人员提交PVC申请，K8S根据申请的资源，自动找到合适的PV，并进行绑定和实际资源分配。

5、为了进一步解放运维的工作，K8S设计了StorageClass对象，实现了动态创建存储卷。根据开发人员提供的PVC需求，K8S配合制备器可以自动完成PV的创建和绑定，从而省去预先创建PV的工作。

 附:

K8S初级入门系列之一-概述

K8S初级入门系列之二-集群搭建

K8S初级入门系列之三-Pod的基本概念和操作

K8S初级入门系列之四-Namespace/ConfigMap/Secret

K8S初级入门系列之五-Pod的高级特性

K8S初级入门系列之六-控制器(RC/RS/Deployment)

K8S初级入门系列之七-控制器(Job/CronJob/Daemonset)

K8S初级入门系列之八-网络

K8S初级入门系列之九-共享存储

K8S初级入门系列之十-控制器(StatefulSet)

K8S初级入门系列之十一-安全

K8S初级入门系列之十二-计算资源管理

附件

  • storage-nfs-rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: 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: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: ClusterRolename: nfs-client-provisioner-runnerapiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: leader-locking-nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: 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# replace with namespace where provisioner is deployednamespace: default
subjects:- kind: ServiceAccountname: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
roleRef:kind: Rolename: leader-locking-nfs-client-provisionerapiGroup: rbac.authorization.k8s.io
  • storage-nfs-class.yaml 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: nfs-client
# 这是为provisioner名称，需要与deploy的env的PROVISIONER_NAME保持一致
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:archiveOnDelete: "false"
  • storage-nfs-deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisionerlabels:app: nfs-client-provisioner# replace with namespace where provisioner is deployednamespace: default
spec:replicas: 1strategy:type: Recreateselector:matchLabels:app: nfs-client-provisionertemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisionercontainers:- name: nfs-client-provisioner# 修改如下镜像地址image: chronolaw/nfs-subdir-external-provisioner:v4.0.2volumeMounts:- name: nfs-client-rootmountPath: /persistentvolumesenv:# 这是为provisioner名称，需要与StorageClass的PROVISIONER_NAME保持一致- name: PROVISIONER_NAMEvalue: k8s-sigs.io/nfs-subdir-external-provisioner- name: NFS_SERVER# 修改此处的ip为nfs server ipvalue: 192.168.16.4- name: NFS_PATH# 修改此处的path为nfs 挂载的目录 ipvalue: /nfs/datavolumes:- name: nfs-client-rootnfs:server: 192.168.16.4path: /nfs/data

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/news/9612.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

Hive内部表和外部表

Hive内部表和外部表

表类型详解 表分类 在Hive中,表类型主要分为两种 第一种&#xff1a;内部表 也叫管理表表目录会创建在集群上的{hive.metastore.warehouse.dir}下的相应的库对应的目录中。默认创建的表就是内部表 第二种&#xff1a;外部表 外部表需要使用关键字"external"&#xff…
阅读更多...
【Docker】基于Dockerfile搭建LNMP架构

【Docker】基于Dockerfile搭建LNMP架构

一、项目环境 公司在实际的生产环境中，需要使用Docker 技术在一台主机上创建LNMP服务并运行Wordpress网站平台。然后对此服务进行相关的性能调优和管理工作。 1. 环境配置 主机操作系统IP地址主要软件DockerCentOS 7.3 x86_64192.168.145.15Docker 19.03容器ip地址规划 ngin…
阅读更多...
SpringBoot第8讲：SpringBoot添加Logback日志

SpringBoot第8讲：SpringBoot添加Logback日志

SpringBoot第8讲&#xff1a;SpringBoot添加Logback日志 本文是SpringBoot第8讲&#xff0c;对SpringBoot添加Logback日志。SpringBoot开发中如何选用日志框架呢&#xff1f; 出于性能等原因&#xff0c;Logback 目前是springboot应用日志的标配&#xff1b; 当然有时候在生产环…
阅读更多...
264. 丑数 II

264. 丑数 II

题目描述&#xff1a; 主要思路&#xff1a; 利用动态规划的思想&#xff0c;记录2 3 5分别乘到了哪里&#xff0c;然后取最小作为新的数字。 class Solution { public:int nthUglyNumber(int n) {int dp[n1];dp[1]1;int p21,p31,p51;for(int i2;i<n;i){int num2 dp[p2]*…
阅读更多...
走进Linux世界【九、Linux的软件安装】

走进Linux世界【九、Linux的软件安装】

Linux系统学习 走进Linux世界【一、Linux概述】 走进Linux世界【二、VM与Linux安装】 走进Linux世界【三、Linux文件与路径】 走进Linux世界【四、Linux基本命令一】 走进Linux世界【五、Linux基本命令二】 走进Linux世界【六、Linux编辑器vim】 走进Linux世界【七、Lin…
阅读更多...
说一说java中的自定义注解之设计及实现

说一说java中的自定义注解之设计及实现

一、需求背景 比如我们需要对系统的部分接口进行token验证&#xff0c;防止对外的接口裸奔。所以&#xff0c;在调用这类接口前&#xff0c;先校验token的合法性&#xff0c;进而得到登录用户的userId/role/authority/tenantId等信息&#xff1b;再进一步对比当前用户是否有权…
阅读更多...
蓝牙协议栈之蓝牙HID基础知识

蓝牙协议栈之蓝牙HID基础知识

蓝牙协议栈之蓝牙HID基础知识 一&#xff1a;定义 HID是Human Interface Device的缩写&#xff0c;由其名称可以了解HID设备是直接与人交互的设备&#xff0c;例如键盘、鼠标与游戏手柄等。 蓝牙HID 是属于蓝牙协议里面的一个profile, 不管在蓝牙2.0 2.1 3.0还是4.0&#xff0c…
阅读更多...
【ESP32】Espressif-IDE及ESP-IDF安装

【ESP32】Espressif-IDE及ESP-IDF安装

一、下载Espressif-IDE 2.10.0 with ESP-IDF v5.0.2 1.打开ESP-IDF 编程指南 2.点击快速入门–>安装–>手动安装–>Windows Installer–>Windows Installer Download 3.点击下载Espressif-IDE 2.10.0 with ESP-IDF v5.0.2 二、安装Espressif-IDE 2.10.0 wit…
阅读更多...
分布式I/O，IT和OT融合少不了它

分布式I/O，IT和OT融合少不了它

长期以来信息技术IT和操作运营技术OT是相互隔离的&#xff0c;随着大数据分析和边缘计算业务的对现场级实时数据的采集需求&#xff0c;IT和OT有了逐渐融合的趋势。IT与OT融合&#xff0c;它赋予工厂的管理者监控运行和过程的能力大为增强&#xff0c;甚至可以预测到可能发生的…
阅读更多...
探索和实践：基于Python的TD-PSOLA语音处理算法应用与优化

探索和实践：基于Python的TD-PSOLA语音处理算法应用与优化

今天我将和大家分享一个非常有趣且具有挑战性的主题：TD-PSOLA语音处理算法在Python中的应用。作为一种在语音合成和变换中广泛使用的技术，TD-PSOLA (Time-Domain Pitch-Synchronous Overlap-Add) 提供了一种改变语音音高和时间长度而不产生显著失真的有效方法。在本篇博客中，…
阅读更多...
TypeScript -- 类

TypeScript -- 类

文章目录 TypeScript -- 类TS -- 类的概念创建一个简单的ts类继承 public / private / protected-- 公共/私有/受保护的public -- 公共private -- 私有的protected -- 受保护的 其他特性readonly -- 只读属性静态属性 -- static修饰ts的getter /setter抽象类abstract TypeScrip…
阅读更多...
[开发|java] java 将json转化java对象

[开发|java] java 将json转化java对象

使用Jackson库将JSON转换为Java对象&#xff1a; 安装依赖 <!-- Jackson Core --> <dependency><groupId>com.fasterxml.jackson.core</groupId><artifactId>jackson-core</artifactId><version>2.12.5</version> </depen…
阅读更多...
KnowStreaming系列教程第三篇——调度任务模块

KnowStreaming系列教程第三篇——调度任务模块

前一篇文章KnowStreaming系列教程第二篇——项目整体架构分析_诸葛子房_的博客-CSDN博客 讲述了KS的整体项目目录&#xff0c;这边文章来讲述下KS在调度模块里面对于指标采集和元数据同步 一、调度模块代码主要在km-task里面 public class TaskClusterAddedListener impleme…
阅读更多...
opengauss安装

opengauss安装

opengauss安装 系统环境 Redhat版本&#xff1a;redhat7.6 虚拟机ip&#xff1a;192.168.5.144 Gauss版本&#xff1a;openGauss-5.0.0-CentOS-64bit-all.tar.gz 企业版 一&#xff0e;准备软硬件环境 1.1 安装依赖包 yum -y install bzip2 python3 libaio-devel flex bis…
阅读更多...
hive 相关总结

hive 相关总结

1、表复制(五分区表复制) create table t1 as select name,age from t2 where ds>2022-06-04 2、表覆盖(先清空表中的原有数据&#xff0c;再向表中插入数据) insert overwrite TABLE t1 select name,age from t2 where ds>2022-06-04 3、表分区覆盖&#xff08;先清空表…
阅读更多...
LeetCode中删除数组元素

LeetCode中删除数组元素

26&#xff0c;80 题是删除 有序数组 中的 重复项 对于此类问题&#xff0c;我们应该进行如下考虑&#xff1a; 由于是保留 k 个相同数字&#xff0c;对于前 k 个数字&#xff0c;我们可以直接保留。对于后面的任意数字&#xff0c;能够保留的前提是&#xff1a;与当前写入的位…
阅读更多...
题目：2119.反转两次的数字

题目：2119.反转两次的数字

​​题目来源&#xff1a; leetcode题目&#xff0c;网址&#xff1a;2119. 反转两次的数字 - 力扣&#xff08;LeetCode&#xff09; 解题思路&#xff1a; 当该数字不为 0 且最低位为 0 时&#xff0c;反转两次不是本身&#xff0c;返回 false&#xff0c;否则&#xff0c;反…
阅读更多...
shiro的优点

shiro的优点

shiro是一个强大的java安全框架&#xff0c;它的优点有以下&#xff1a; shiro就是权限管理&#xff1a;包括两部分&#xff1a;身份验证、授权 一、它提供了身份验证、授权、密码和会话管理等功能&#xff0c;可以满足各种应用程序的安全需求。 身份认证就是&#xff1a;验证是…
阅读更多...
Python面试：技巧与实践

Python面试：技巧与实践

Python面试&#xff1a;技巧与实践 在当今的IT行业中&#xff0c;Python已经成为了一种非常流行的编程语言。它以其简洁明了的语法、强大的库支持和广泛的应用领域&#xff0c;吸引了无数的开发人员。然而&#xff0c;掌握Python并不是一件容易的事情&#xff0c;尤其是在面试…
阅读更多...
mybatisPlus入门篇

mybatisPlus入门篇

文章目录 初窥门径1.1 初识MybatisPlus1.2 MybatisPlus的特性1.3 MybatisPlus的架构模型 入门案例2.1 准备相关开发环境2.2 搭建springboot工程2.3 创建数据库2.4 引入相关依赖2.5 创建实体类2.6 集成MybatisPlus2.7 单元测试2.8 springboot日志优化 初窥门径 1.1 初识Mybatis…
阅读更多...
最新文章

Copyright @ 2022~2023