Kubernetes学习(NFS如何实现 Volume Dynamic Provisioning)

发表于 分类于 阅读次数： 本文字数： 6.1k 阅读时长 ≈ 6 分钟

NFS在kubernetes中做为共享存储，用的还是比较多的，之前也就是一直用着，也没有太关注是如何实现Dynamic provisioning，今天花了点时间研究了一下原理，还是挺有意思.

NFS Servers

1
2
3
4
5
6
7
8
9
10
11
12
13
# 安装
apt install yum -y install nfs-utils rpcbind
# 新建目录
mkdir -p /data/nfs
# 加入
echo "/data/nfs/fluentd-conf    *(rw,sync,no_subtree_check,no_root_squash)" >> /etc/export
# 验证
exportfs -r
# 启动nfs
systemctl enable rpcbind
systemctl enable nfs-server
systemctl start rpcbind
systemctl start nfs-server

NFS Client

client端只需要二步即可使用server端share出来的目录

1
2
3
4
5
# 创建目录
mkdir /media/nfs_dir
# mount
mount 192.168.8.150:/data/nfs /media/nfs_dir
# 查看

当然，在kubernetes中主要还是使用Dynamic NFS provisioning为主, 不会直接像上面这样使用nfs

这里还是将3种方式都贴一下.

使用volume

nfs做为volume还是有好几种使用方式的:

做为普通volume

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: redis
spec:
  selector:
    matchLabels:
      app: redis
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      # 应用的镜像
      - image: redis
        name: redis
        imagePullPolicy: IfNotPresent
        # 应用的内部端口
        ports:
        - containerPort: 6379
          name: redis6379
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        - name: REDIS_PASSWORD
          value: "redis"   
        # 持久化挂接位置，在docker中 
        volumeMounts:
        - name: redis-persistent-storage
          mountPath: /data
      volumes:
      # 宿主机上的目录
      - name: redis-persistent-storage
        nfs:
          path: /data/nfs/redis/data
          server: 192.168.8.150

作为persistentVolume

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1 
kind: PersistentVolume 
metadata: 
  name: nfs-pv 
spec: 
  capacity: 
    storage: 5Gi 
  volumeMode: Filesystem 
  accessModes: 
  - ReadWriteOnce 
  persistentVolumeReclaimPolicy: Recycle 
  storageClassName: slow 
  mountOptions: 
  - hard 
  - nfsvers=4.1
  # 此持久化存储卷使用nfs插件 
  nfs:
    # nfs共享目录为/tmp 
    path: /data/nfs/data
    # nfs服务器的地址
    server: 192.168.5.150

上面两种方式在kubernetes用nfs做为持久卷时用的还是比较少，因为需要事先在nfs中创建好相关的目录，存在一些手工操作. 重点在下.

作为Dynamic NFS provisioning

helm部署参考nfs-client-provisioner

这里选择重要的资源对象来阐述nfs是如何实现dynamic provision功能的

首先来看一下storageclass,这个也没什么好说的.

1
2
3
4
5
6
7
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storageclass # IMPORTANT pvc needs to mention this name
provisioner: nfs-test # name can be anything
parameters:
  archiveOnDelete: "false"

还会部署一个deployment资源

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nfs-pod-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-pod-provisioner
    spec:
      serviceAccountName: nfs-pod-provisioner-sa # name of service account created in rbac.yaml
      containers:
        - name: nfs-pod-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-provisioner-v
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME # do not change
              value: nfs-test # SAME AS PROVISONER NAME VALUE IN STORAGECLASS
            - name: NFS_SERVER # do not change
              value: 192.168.1.5 # Ip of the NFS SERVER
            - name: NFS_PATH # do not change
              value: /nfs/data # path to nfs directory setup
      volumes:
       - name: nfs-provisioner-v # same as volumemouts name
         nfs:
           server: 192.168.1.5
           path: /nfs/data

这个deployment其实是做为一个nfs client起作用,它把整个nfs server的共享目录/nfs/data都挂载到了/persistentvolumes下, 这为后面根据pvc自动生成创建pv目录有关.

生成一个pvc

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc-test
spec:
  storageClassName: nfs-storageclass # SAME NAME AS THE STORAGECLASS
  accessModes:
    - ReadWriteMany #  must be the same as PersistentVolume
  resources:
    requests:
      storage: 50Mi

当使用一个pod指定使用使用上面的pvc后，上面的deployment会根据pvc自动生成一个pv, pvc与该pv进行绑定, 且在nfs servers上创建相应的目录,pod将该目录挂载进了自己容器目录中，这样就实现了Dynamic provisioning功能了

1
2
3
4
$ kubectl apply -f  nfs_pvc_dynamic.yaml
nfs-pvc-test   Bound    pvc-620ff5b1-b2df-11e9-a66a-080027db98ca   50Mi       RWX            nfs-storageclass   7s
$ ls /nfs/data/
default-nfs-pvc-test-pvc-620ff5b1-b2df-11e9-a66a-080027db98ca

nfs-pvc-test为pvc, pvc-620ff5b1-b2df-11e9-a66a-080027db98ca为pv, default-nfs-pvc-test-pvc-620ff5b1-b2df-11e9-a66a-080027db98ca即为在nfs-server共享目录下创建的目录，这个目录最后被为使用该pvc的pod挂载.

这个deployment的源码可参考nfs-client-provisioner, deployment核心代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
func (p *nfsProvisioner) Provision(options controller.VolumeOptions) (*v1.PersistentVolume, error) {
	if options.PVC.Spec.Selector != nil {
		return nil, fmt.Errorf("claim Selector is not supported")
	}
	glog.V(4).Infof("nfs provisioner: VolumeOptions %v", options)

	pvcNamespace := options.PVC.Namespace
	pvcName := options.PVC.Name

	pvName := strings.Join([]string{pvcNamespace, pvcName, options.PVName}, "-")

	fullPath := filepath.Join(mountPath, pvName) // 这里指定了生成目录的格式, 其中 mountPath即为/persistentvolumes
	glog.V(4).Infof("creating path %s", fullPath)
	if err := os.MkdirAll(fullPath, 0777); err != nil {
		return nil, errors.New("unable to create directory to provision new pv: " + err.Error())
	}
	os.Chmod(fullPath, 0777)

	path := filepath.Join(p.path, pvName)
	size, err := getNfsCapacity()
	if err != nil {
		return nil, errors.New("unable to get nfs size to provision new pv: " + err.Error())
	}
	fmt.Println("=====", size.Value())

	pv := &v1.PersistentVolume{ // 根据pvc 生成pv
		ObjectMeta: metav1.ObjectMeta{
			Name: options.PVName,
		},
		Spec: v1.PersistentVolumeSpec{
			PersistentVolumeReclaimPolicy: options.PersistentVolumeReclaimPolicy,
			AccessModes:                   options.PVC.Spec.AccessModes,
			MountOptions:                  options.MountOptions,
			Capacity: v1.ResourceList{
				//v1.ResourceName(v1.ResourceStorage): options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)],
				v1.ResourceName(v1.ResourceStorage): *size,
			},
			PersistentVolumeSource: v1.PersistentVolumeSource{
				NFS: &v1.NFSVolumeSource{
					Server:   p.server,
					Path:     path,
					ReadOnly: false,
				},
			},
		},
	}
	return pv, nil
}

因此整个流程为:

pod生成使用一个pvc, 当pvc发布到集群中时, nfs-client-provisioner deployment就会根据该pvc的yaml文件获取namespace, pvc-name等信息在挂载的nfs共享目录下创建新的目录, 然后生成一个pv与该pvc绑定，pod使用该pv就相当于使用nfs server共享目录一样

那nfs server的共享目录是如何做到的呢?

NFS 原理

NFS 使用RPC(Remote Procedure Call)的机制进行实现，RPC使得客户端可以调用服务端的函数。同时，由于有 VFS 的存在，客户端可以像使用其它普通文件系统一样使用 NFS 文件系统。经由操作系统的内核，将 NFS 文件系统的调用请求通过 TCP/IP 发送至服务端的 NFS 服务。NFS服务器执行相关的操作，并将操作结果返回给客户端

我觉得上面那段话说的很明白, nfs实现共享存储还是通过网络将本地操作写入到nfs server端，只不过这个网络操作由RPC来完成, 同时也需要内核的支持.

nfs更加详细的原理，感兴趣的可以参考NFS原理详解

参考文章: