OpenShift 4 - 在单节点的 OpenShift 上用 NFS Operator 实现以 RWX 访问存储

dawnsky.liu

已于 2023-02-03 09:29:37 修改

阅读量693

点赞数

分类专栏： OpenShift 4 存储文章标签： openshift 存储 docker

于 2023-02-01 11:38:35 首次发布

本文链接：https://blog.csdn.net/weixin_43902588/article/details/126793876

版权

OpenShift 4 同时被 2 个专栏收录

271 篇文章 78 订阅

订阅专栏

存储

7 篇文章 0 订阅

订阅专栏

《OpenShift / RHEL / DevSecOps 汇总目录》
文本已在 OpenShift Local 4.12 环境中进行验证。

OpenShift 支持的存储访问模式

红帽 OpenShift 4 内置支持的 PV 插件和访问模式如下表。另外 OpenShift 也可支持其他第三方存储，一般是通过 OperatorHub 进行安装。
根据下表可以看出 ReadWriteOnce - RWO 模式支持也为最广泛，而 ReadWriteMany - RWX 模式却只有少量插件才支持。而在支持 RWX 的环境中 NFS 无疑是最容易获得的，因为其他支持 RWX 存储要么只能在公有云上使用，要么就是通常需要较为复杂的存储硬件和软件才能支持。
在这里插入图片描述

用 NFS Provisioner Operator 实现 RWX 访问存储

下面介绍如何通过 NFS Provisioner Operator 在单节点 OpenShift 中（例如 OpenShift Local）使用节点的本地存储提供基于 NFS 的 PV。

安装 NFS Operator

可以在 OpenShift 控制台的 OperatorHub 中找到 NFS Provisioner Operator，然后使用缺省配置安装该 Operator。

也可运行以下命令通过 nfs-provisioner-operator 订阅安装。

$ cat << EOF | oc apply -f -  
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: nfs-provisioner-operator
  namespace: openshift-operators
spec:
  channel: alpha
  installPlanApproval: Automatic
  name: nfs-provisioner-operator
  source: community-operators
  sourceNamespace: openshift-marketplace
EOF

安装成功后可查看 Operator 的状态。

解决安装 Operator 过程无法访问谷歌 gcr.io 上的容器镜像

由于在安装过程会用到谷歌 gcr.io 上的容器镜像，因此在国内安装 NFS Operator 的时候会遇到失败的情况。解决方案如下：

运行命令查看在 nfs-provisioner-operator 中使用到来自谷歌的镜像，应该有 kube-rbac-proxy 和 kube-rbac-proxy 两个镜像。

$ oc get ClusterServiceVersion
NAME                              DISPLAY                      VERSION      REPLACES                          PHASE
nfs-provisioner-operator.v0.0.7   NFS Provisioner Operator     0.0.7        nfs-provisioner-operator.v0.0.6   Installing
 
$ oc get ClusterServiceVersion nfs-provisioner-operator.v0.0.7 -oyaml | grep gcr.io
              "image": "k8s.gcr.io/sig-storage/nfs-provisioner@sha256:e943bb77c7df05ebdc8c7888b2db289b13bf9f012d6a3a5a74f14d4d5743d439",
                image: gcr.io/kubebuilder/kube-rbac-proxy@sha256:e10d1d982dd653db74ca87a1d1ad017bc5ef1aeb651bdea089debf16485b080b
  - image: k8s.gcr.io/sig-storage/nfs-provisioner@sha256:e943bb77c7df05ebdc8c7888b2db289b13bf9f012d6a3a5a74f14d4d5743d439
  - image: gcr.io/kubebuilder/kube-rbac-proxy@sha256:e10d1d982dd653db74ca87a1d1ad017bc5ef1aeb651bdea089debf16485b080b

在 OpenShift 控制台的 OperatorHub 中进入 NFS Provisioner Operator，然后在 YAML 中替换以下用到的 2 个镜像，最后保存。
1）将 gcr.io/kubebuilder/kube-rbac-proxy@sha256:e10d1d982dd653db74ca87a1d1ad017bc5ef1aeb651bdea089debf16485b080b
替换为 quay.io/dawnskyliu/kube-rbac-proxy:latest
2）将 k8s.gcr.io/sig-storage/nfs-provisioner@sha256:e943bb77c7df05ebdc8c7888b2db289b13bf9f012d6a3a5a74f14d4d5743d439
替换为 quay.io/dawnskyliu/nfs-provisioner:latest
由于前面部署 nfs-provisioner-operator-controller-manager 用的是谷歌镜像，因此即便是在更换镜像后可能还一直不会 READY。

$ oc get deployment nfs-provisioner-operator-controller-manager -n openshift-operators

这是由于 nfs-provisioner-operator-controller-manager 部署的生命周期是由 NFS Provisioner Operator 维护的，因此可执行以下命令先删除 nfs-provisioner-operator-controller-manager 部署，稍后 NFS Provisioner Operator 会自动根据前面更新的镜像重新创建该部署。

$ oc delete deployment nfs-provisioner-operator-controller-manager -n openshift-operators

查看 nfs-provisioner-operator-controller-manager 部署的状态到 READY 即可。

$ oc get deployment -n openshift-operators
NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
nfs-provisioner-operator-controller-manager   1/1     1            1           9m

确认 NFS Provisioner Operator 已经安装成功。

$ oc get clusterserviceversion
NAME                              DISPLAY                    VERSION   REPLACES                          PHASE
nfs-provisioner-operator.v0.0.7   NFS Provisioner Operator   0.0.7     nfs-provisioner-operator.v0.0.6   Succeeded

配置 NFSProvisioner

执行命令，对节点打标签。

$ target_node=$(oc get node --no-headers -o name|cut -d'/' -f2)
$ oc label node/${target_node} app=nfs-provisioner
node/crc-pbwlw-master-0 labeled

执行命令进入集群的节点内部。

$ oc debug node/${target_node}
Starting pod/crc-pbwlw-master-0-debug ...
To use host binaries, run `chroot /host`

Pod IP: 192.168.126.11
If you don't see a command prompt, try pressing enter.

在节点内部创建 NFS 使用的目录，然后退出。

sh-4.4# chroot /host
sh-4.4# mkdir -p /home/core/nfs
sh-4.4# chcon -Rvt svirt_sandbox_file_t /home/core/nfs
changing security context of '/home/core/nfs'
sh-4.4# exit
exit
sh-4.4# exit
exit

Removing debug pod ...

创建 NFSProvisioner 对象，会创建对应的 deployment 和 storageclass 对象。

$ oc new-project nfsprovisioner-operator
$ cat << EOF | oc apply -f -  
apiVersion: cache.jhouse.com/v1alpha1
kind: NFSProvisioner
metadata:
  name: nfsprovisioner-sample
  namespace: nfsprovisioner-operator
spec:
  nodeSelector: 
    app: nfs-provisioner
  hostPathDir: "/home/core/nfs"
EOF

$ oc get deployment
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
nfs-provisioner   1/1     1            1           5h18m

注意：如果是在国内部署而前面采用了手动修改的 NFS Provisioner Operator 的配置，此处还需额外手动修改 nfs-provisioner 部署的配置。
将 k8s.gcr.io/sig-storage/nfs-provisioner@sha256:e943bb77c7df05ebdc8c7888b2db289b13bf9f012d6a3a5a74f14d4d5743d439
替换为 quay.io/dawnskyliu/nfs-provisioner:latest
查看集群包含的 storageclass 对象。

$ oc get storageclass
NAME                                     PROVISIONER                        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
crc-csi-hostpath-provisioner (default)   kubevirt.io.hostpath-provisioner   Delete          WaitForFirstConsumer   false                  36d
nfs                                      example.com/nfs                    Delete          Immediate              false                  3m38s

由上一步的结果可知，名为 nfs 的 storageclass 不是集群缺省的，而 crc-csi-hostpath-provisioner 是缺省的 storageclass。可以执行下面命令将 nfs 设为缺省的 storageclass。

$ oc patch storageclass crc-csi-hostpath-provisioner -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
$ oc patch storageclass nfs -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

$ oc get storageclass
NAME                                     PROVISIONER                        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
crc-csi-hostpath-provisioner             kubevirt.io.hostpath-provisioner   Delete          WaitForFirstConsumer   false                  36d
nfs (default)                            example.com/nfs                    Delete          Immediate              false                  4m20s

验证

执行命令，创建测试 PVC。

$ cat << EOF | oc apply -f -  
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: nfs-pvc-example
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Mi
  storageClassName: nfs
EOF

确认 PV 和 PVC 已经是可用状态。

$ oc get pvc
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc-example   Bound    pvc-1399650c-8c58-4057-8693-1c4f4d80efa0   1Mi        RWX            nfs            35s

$ oc get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                 STORAGECLASS                   REASON   AGE
pvc-1399650c-8c58-4057-8693-1c4f4d80efa0   1Mi        RWX            Delete           Bound    nfsprovisioner-operator/nfs-pvc-example               nfs                                     32s