《OpenShift / RHEL / DevSecOps 汇总目录》
文本已在 OpenShift Local 4.12 环境中进行验证。
文章目录
- OpenShift 支持的存储访问模式
- 用 NFS Provisioner Operator 实现 RWX 访问存储
- 安装 NFS Operator
- 解决安装 Operator 过程无法访问谷歌 gcr.io 上的容器镜像
- 配置 NFSProvisioner
- 验证
- 参考
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
参考
https://developers.redhat.com/articles/2022/04/20/create-and-manage-local-persistent-volumes-codeready-containers#set_up_persistent_volumes_anywhere