Help us understand the problem. What is going on with this article?

K8s on Vagrant の NFS 永続ボリュームの利用メモ

More than 1 year has passed since last update.

この投稿は、Vagrantの仮想サーバーで構築したK8sクラスタの4回目で、NFSを利用した、永続ボリュームの利用についてのメモです。

これまでのk8s on vagrant 記事のリンクを以下にあげておきますので、必要に応じて参照いただければ幸いです。

システム構成

図の左端に表したk8sクラスタの外側にNFSサーバーを設定して、図中の中央にあるワーカーノード(k8s2,k8s3)のポッドからマウントできる様にします。 NFSサーバーは、外部ストレージ・システムを想定して、パブリック・ネットワークにデプロイします。 もちろん、自宅環境にストレージ・システムを持つのはお金が掛かりますから、Vagrantで模擬的なストレージシステムを作ります。

スクリーンショット 2018-04-21 23.34.34.png

NFSサーバーでエクスポートしたファイルシステムを k8sのクラスタの永続ボリュームとして定義してポッドから利用します。

ワーカーノードへのNFSクライアントモジュールの追加

コンテナは、カーネルのサポートを必要としていますから、NFSのクライアント機能がインストールされていないと、ポッドはNFSサーバーのボリュームをマウントすることができません。 このため、ワーカーノードである k8s2, k8s3にNFSクライアントのパッケージをインストールします。

root@k8s2:~# apt-get install nfs-common
root@k8s3:~# apt-get install nfs-common

NFSサーバーのセットアップ

vagrantの仮想サーバーとして、NFSサーバーをセットアップします。

NFSサーバーのディレクトリを作成して、移動します。

$ mkdir nfsserver
$ cd nfsserver

次のVagrantfileを作成します。 パブリックIPアドレスは、環境に合わせて変更してくださいね。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.hostname = "nfsserver"
  #
  public_ip = "192.168.1.98"
  config.vm.network :public_network, ip: public_ip, bridge: "en0: Ethernet"
  #
  config.vm.provider "virtualbox" do |vb|
    vb.gui = false
    vb.memory = "512"
  end
  #
  config.vm.provision "shell", inline: <<-SHELL
apt-get update
apt-get install -y nfs-kernel-server
mkdir -p /export/users
cat >> /etc/exports <<EOF
/export       192.168.1.0/24(rw,fsid=0,insecure,no_subtree_check,async)
/export/users 192.168.1.0/24(rw,nohide,insecure,no_subtree_check,async)
EOF
exportfs -a
SHELL

end

以下のコマンドで、NFSサーバーが起動すると、ポッドからNFSマウントできる状態になります。

$ vagrant up

ストレージについて

ストレージを管理する仕組みは、ポッドやデプロイメントを管理する仕組みから独立しています。 このストレージのサブシステムである PersistantVolumeサブシステムは、永続ボリュームを提供する方法を抽象化して、ユーザーが共通の方法で永続ボリュームを利用できる様にします。このために、二つのAPIが提供されており、それぞれの概要は以下になります。

PersistentVolume(PV)は、k8sクラスタの管理者によってプロビジョニングされたk8sクラスタ内のストレージです。 この記事の例では、管理者によってプロビジョニングされたNFSのボリュームをk8sクラスタで利用できる様に定義します。 具体的には固有の情報となり、ボリュームの提供方法であるNFSを指定, NFSサーバーのIPアドレス、そして、認証情報などを設定します。

PersistentVolumeClaim(PVC)は、ユーザによるストレージの要求(クレーム)です。このクレームは、サイズとアクセスモードを要求することができます。ただし、今回の例の様に、プロビジョニング時点でキャパシティが決められている場合には、PVCの指定は効力がありません。そして、アクセスモードとは以下の指定をすることができますが、今回はPVのNFSと結びつける様に設定しますから、形だけのものになります。

  • ReadWriteOnce – the volume can be mounted as read-write by a single node
  • ReadOnlyMany – the volume can be mounted read-only by many nodes
  • ReadWriteMany – the volume can be mounted as read-write by many nodes

このPersistentVolumeClaimsは、ユーザが抽象的な記憶資源を利用することを可能しますが、NFS、GlusterFs, iSCSIなど様々な実装方法があり、このアクセスモードやサイズの指定では、ユーザーがボリュームの実装の詳細を考慮することなく、適切なボリュームを割り当てるためのStorageClassのリソースが提供されています。

参考資料: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

PVの作成

ここでは前述の様に、k8sクラスタ内から利用できる様に、NFSへのアクセスに関する詳細な設定に名前(nfs-1)を付与して定義します。 今回の例では、詳細はIPアドレスとエクスポートのパスです。 NFSサーバーのアクセス制御は、IPアドレス範囲で指定したので、ユーザーIDやパスワードの設定はありません。 また、サイズの指定していますが効力は無く、NFSサーバーでexportしたファイルシステムの容量が優先されます。

PVCからPVを明示的に指定できる様に、metadata.labels.nameを設定します。 PVCではセレクターの設定にこのラベルを利用します。

nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-1
  labels:
    name: pv-nfs-1
spec:
  capacity:
    storage: 100Mi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.1.98
    path: "/export"

PV作成のYAML適用と確認は、以下の様にします。

$ kubectl create -f pv-nfs.yaml 
persistentvolume "nfs-1" created

$ kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
nfs-1     100Mi      RWX            Retain           Available                                      5s

PVCの作成

ユーザーがポッドに指定するための設定と、事前にプロビジョニングしたPVを対応づける設定します。 spec.accessModesやspec.resources.requestsの指定は、ここでは有効に利用される事はありません。 ポッドの作成時に、metadata.name:の nfs-1 を指定してPVCをアクセスします。

pvc-nfs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-1
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: "100Mi"
  selector:
    matchLabels:
      name: pv-nfs-1

PVC作成も同意な方法で、以下の様に実行します。

$ kubectl create -f pvc-nfs.yaml 
persistentvolumeclaim "nfs-1" created

$ kubectl get pvc
NAME      STATUS    VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-1     Bound     nfs-1     100Mi      RWX                           4s

ポッドからのマウント

次のYAMLは、ReplicationController を利用していて、Version 1.10 を利用する現在では、Deploymentを利用するべきと思いますが、そのまま利用できますので、これを利用して、PVC nfs-1 を利用するNFSクライアントのポッドを2つ作成します。 PVCのnfs-1の指定は、このYAMLの最終行にあり、claimNameの値にあります。

apiVersion: v1
kind: ReplicationController
metadata:
  name: nfs-web
spec:
  replicas: 2
  selector:
    role: web-frontend
  template:
    metadata:
      labels:
        role: web-frontend
    spec:
      containers:
      - name: web
        image: nginx
        ports:
          - name: web
            containerPort: 80
        volumeMounts:
            - name: nfs
              mountPath: "/usr/share/nginx/html"
      volumes:
      - name: nfs
        persistentVolumeClaim:
          claimName: nfs-1

次のコマンドで実行します。

$ kubectl create -f nfs-client.yaml 
replicationcontroller "nfs-web" created

replicas: 2 を指定したので、k8s2とk8s3のワーカーノード上にそれぞれ、ポッドが作成されていることが判ります。

vagrant@k8s1:/vagrant/yaml$ kubectl get pods -o wide
NAME                               READY     STATUS    RESTARTS   AGE       IP            NODE
nfs-web-2slrx                      1/1       Running   0          7m        10.244.2.57   k8s3
nfs-web-8g9zr                      1/1       Running   0          7m        10.244.1.73   k8s2
<省略>

ポッドの一つで、対話的にシェルを動かして、NFSサーバーがマウントされている事を確認します。 ボリュームの容量に注目してください。 100Miの指定は有効でない事を確認してみてください。

$ kubectl exec -it nfs-web-2slrx sh
# df -h
Filesystem            Size  Used Avail Use% Mounted on
none                  9.7G  2.0G  7.7G  21% /
tmpfs                1001M     0 1001M   0% /dev
tmpfs                1001M     0 1001M   0% /sys/fs/cgroup
/dev/sda1             9.7G  2.0G  7.7G  21% /etc/hosts
shm                    64M     0   64M   0% /dev/shm
192.168.1.98:/export  9.7G  1.1G  8.6G  11% /usr/share/nginx/html
tmpfs                1001M   12K 1001M   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                1001M     0 1001M   0% /sys/firmware
# 

まとめ

NFSサーバーのファイル・システムを、PersistentVolumeとして詳細を定義して、PersistentVolumeClaimで抽象化レイアを指定して、ポッドからNFSマウントできる事を確認しました。 そして、ポッドは、コンテナをホストしているカーネルのサポートを必要としますから、 パブリック・クラウド や k8sソフトウェア製品では、自動的にセットアップされるので、心配ないと思いますが、今回の例の様に、CNCFからダウンロードするケースでは、ワーカーノード k8s2, k8s3にNFSクライアントのパッケージを追加しなければならない事に注意を払う必要があることが判りました。

やっぱり、PVCだけで実行するダイナミック・プロビジョニングも試してみたいですね。。。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away