k8s nfs-client 添加挂载参数 —— 筑梦之路

背景介绍

  1. 为什么要使用noresvport参数挂载NAS?不重新挂载会有什么后果?

    如果发生网络切换或者后端服务的HA倒换,小概率会造成NFS文件系统阻塞,那就可能需要几分钟时间连接才会自动恢复,极端情况下甚至需要重启ECS才能恢复。使用noresvport参数后,这个恢复几秒就可以自动完成。

  2. 什么情况会引发网络切换或者后端服务的HA倒换?

    NAS服务是稳定的,网络切换或者后端服务的HA倒换都是罕见情况。

    后端服务升级会触发上述切换,但导致客户端阻塞的概率很低,并且在升级之前我们会提前通知相关集群的用户,留出充足时间使用noresvport参数。

    其他可能引发切换的场景,还有负载均衡调整、服务端硬件故障等情况,有一定的不可预测性,所以即使服务端没有升级安排,也请尽快使用noresvport参数避免这样的风险。

  3. 为什么需要重新挂载?还有没有其他的方案?

    需要重新挂载的原因是要把之前没有使用noresvport参数的TCP连接断掉,然后使用noresvport参数挂载时,会建立新的TCP连接。

    为了把老的TCP连接断掉,就必须把NAS相关的业务都停掉,然后执行umount卸载。

    如果不希望重新挂载,可以考虑新建NAS挂载点,使用noresvport参数挂载到新的本地路径,然后把业务进程逐步迁移过去,最后废弃老的挂载路径和挂载点。

NFS挂载示例

静态PV

bash 复制代码
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-v3
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 2Gi
  mountOptions:
  - vers=3
  - nolock,tcp,noresvport
  nfs:
    path: /nfs-v3
    server: nas_server
  persistentVolumeReclaimPolicy: Retain
bash 复制代码
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs-v4.0
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 2Gi
  mountOptions:
  - vers=4.0
  - noresvport
  nfs:
    path: /nfs-v4.0
    server: nas_server
  persistentVolumeReclaimPolicy: Retain

动态pvc

假设集群已经部署了nfs-client-provisioner用来实现在动态提供PersistentVolume

bash 复制代码
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfsv3-sc
mountOptions:
- vers=3
- nolock,tcp,noresvport
provisioner: fuseim.pri/ifs
reclaimPolicy: Retain


---------------

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfsv4-sc
mountOptions:
- vers=4.0
- nolock,tcp,noresvport
provisioner: fuseim.pri/ifs
reclaimPolicy: Retain

PVC

bash 复制代码
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfsv3-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfsv3-sc
  volumeMode: Filesystem


---------------

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfsv4-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfsv4-sc
  volumeMode: Filesystem

测试

bash 复制代码
kind: Pod
apiVersion: v1
metadata:
  name: test-nfs-pod
  namespace: default
spec:
  containers:
  - name: test-nfs-pod
    image: busybox:1.24
    command:
    - "/bin/sh"
    args:
    - "-c"
    - "while true; do sleep 99999;done"
    volumeMounts:
    - name: nfsv3-pvc
      mountPath: "/mnt/nfsv3"
    - name: nfsv4-pvc
      mountPath: "/mnt/nfsv4"
  restartPolicy: "Never"
  volumes:
  - name: nfsv3-pvc
    persistentVolumeClaim:
      claimName: nfsv3-pvc
  - name: nfsv4-pvc
    persistentVolumeClaim:
      claimName: nfsv4-pvc

检查验证

bash 复制代码
mount | grep nfs
相关推荐
小毅&Nora几秒前
【云计算】【Kubernetes】 ⑥ K8S Pod优雅下线全解析:从preStop到Eureka下线实战
kubernetes·云计算·优雅下线
会飞的小蛮猪14 分钟前
K8s-1.29.2二进制安装-第三章(Master组件安装)
云原生·容器·kubernetes
没有bug.的程序员15 分钟前
微服务的本质:不是拆服务,而是拆复杂度
java·jvm·spring·微服务·云原生·容器·架构
sean90816 分钟前
Colima 下 docker pull 失败自查流程
macos·docker·容器·colima
古城小栈23 分钟前
云原生架构:微服务 vs 单体应用的选择
微服务·云原生·架构
百锦再28 分钟前
Kubernetes与开发语言:重新定义.NET Core与Java的云原生未来
开发语言·云原生·kubernetes
IT界的奇葩28 分钟前
康威定律对微服务的启示
微服务·云原生·架构
极限实验室9 小时前
APM(一):Skywalking 与 Easyearch 集成
数据库·云原生
_oP_i13 小时前
Docker 整体架构
docker·容器·架构
ascarl201014 小时前
Kubernetes 环境 NFS 卡死问题排查与解决纪要
云原生·容器·kubernetes