Kubernetes存储系统-NFS Server的Helm部署

• 本文翻译根据 https://github.com/kubernetes/charts/tree/master/stable/nfs-server-provisioner
• 本文地址 https://my.oschina.net/u/2306127/blog/1820434，By openthings，2018.05.29.

其它参考：

• Helm Charts仓库，https://github.com/kubernetes/charts
• Jupyter Hub on Kubernetes Part II: NFS ，https://my.oschina.net/u/2306127/blog/1818470
• kunbernetes存储系统-基于NFS的PV服务，https://my.oschina.net/u/2306127/blog/1819620

NFS Server Provisioner 是Kubernetes源码外部的动态存储提供者，底层是通过NFS（网络文件系统）来提供的。你可以通过它快速地部署一个几乎可以在任何地方使用的网络共享存储。

该Helm chart 将会部署一个Kubernetes的 external-storage projects nfs 提供者，包含一个内建的NFS server，但是不会连接到一个已经存在的NFS server上（可以通过PV直接使用）。连接到已有的 NFS Server可以通过 NFS Client Provisioner 来访问。

$ helm install stable/nfs-server-provisioner

警告：上面的命令按照缺省参数安装，这虽然能够工作，但是存储在该卷上的数据将不会被持久保存到磁盘上。

注意：在运行时上面的命令之前，建议运行helm repo update来更新charts库到最新版本。如果通过代理访问，可以使用如下的命令（修改https_proxy为自己的代理服务地址）：

sudo https_proxy=http://192.168.199.99:9999 helm repo update

简介

本项目的chart启动了一个nfs-server-provisioner部署，在Kubernetes集群上使用Helm包管理器来安装。

安装Chart

安装 chart ，版本名称去为 my-release，如下：

$ helm install stable/nfs-server-provisioner --name my-release

该命令使用缺省配置在Kubernetes上安装nfs-server服务器。该 configuration 节的参数列表可以在安装期间进行配置。

卸载 Chart

为了卸载/删除 my-release deployment，运行：

$ helm delete my-release

该命令将删除所有安装到kuubernetes中的组件。

配置

下面的表格列出了可以配置的参数：

$ helm install stable/nfs-server-provisioner --name my-release \
  --set=image.tag=v1.0.8,resources.limits.cpu=200m

可选的方法，通过YAML文件来指定这些参数，例如：

$ helm install stable/nfs-server-provisioner --name my-release -f values.yaml

提示: 你可以使用缺省的 values.yaml作为例子。

持久化

该 nfs-server-provisioner 镜像文件存储了它的配置数据，更重要的是， 其 dynamic volumes 所管理的 /export 路径。

The chart mounts a Persistent Volume volume at this location. The volume can be created using dynamic volume provisioning. However, it is highly recommended to explicitly specify a storageclass to use rather than accept the clusters default, or pre-create a volume for each replica.

If this chart is deployed with more than 1 replica, storageClass.defaultClass=true and persistence.storageClass, then the 2nd+ replica will end up using the 1st replica to provision storage - which is likely never a desired outcome.

建议的持久化配置例子

下面是一个建议的配置例子，当另外的storage class存在用于提供持久化：

persistence:
  enabled: true
  storageClass: "standard"
  size: 200Gi

storageClass:
  defaultClass: true

在很多集群上，cloud provider集成将创建一个 "standard" storage class，其将创建一个 volume (e.g. a Google Compute Engine Persistent Disk or Amazon EBS volume) 来提供持久性。

下面是没有另外的 storage class提供持久化的例子：

persistence:
  enabled: true
  storageClass: "-"
  size: 200Gi

storageClass:
  defaultClass: true

在这个配置中， PersistentVolume 必须为每一个复制创建，使其可用。安装Helm chart，然后查看 PersistentVolumeClaim 将会创建并为你的 PersistentVolume绑定提供需要的名称。

必要的 PersistentVolume例子：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: data-nfs-server-provisioner-0
spec:
  capacity:
    storage: 200Gi
  accessModes:
    - ReadWriteOnce
  gcePersistentDisk:
    fsType: "ext4"
    pdName: "data-nfs-server-provisioner-0"
  claimRef:
    namespace: kube-system
    name: data-nfs-server-provisioner-0

下面是运行在裸机上的配置例子，使用hostPath存储卷类型：

persistence:
  enabled: true
  storageClass: "-"
  size: 200Gi

storageClass:
  defaultClass: true

nodeSelector:
  kubernetes.io/hostname: {node-name}

在这个配置中， PersistentVolume 必须为每一个复制创建，使其可用。安装 Helm chart，然后查看 PersistentVolumeClaim's已经创建并为 PersistentVolume 的绑定提供需要的名称。

必要的 PersistentVolume的例子：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: data-nfs-server-provisioner-0
spec:
  capacity:
    storage: 200Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /srv/volumes/data-nfs-server-provisioner-0
  claimRef:
    namespace: kube-system
    name: data-nfs-server-provisioner-0

警告： hostPath volumes 不能在Kubernetes集群的不同节点机器间迁移。 因此，我们限制来了 nfs-server-provisioner pod运行在单个node上。这对于产品生产环境的部署来说不一定合适。