メインコンテンツへスキップ
  1. Blogs/

nfs-csi-driverではPVCのCapacityが機能しない問題

·1203 文字·
Memo Kubernetes
hiroki
著者
hiroki
クラウドを作るお仕事をしてます。
目次

はじめに
#

kubernetesのPersistent Volume(PV)として、csi-driver-nfsを使っていると、Persistent Volume Claim(PVC)でCapacityを指定しても反映されない。

同様の事例はissueで結構公開されている

1. 問題
#

実際に何が問題なのか見てみる。

1. 2GiのCapacityを指定

kubectl describe pvc datadir-mysql-cluster-0 -n dev
Name:          datadir-mysql-cluster-0
Namespace:     dev
StorageClass:  nfs-csi
Status:        Bound
Volume:        pvc-0d5ef0cf-be39-4fe4-8c7d-ba2fcb53229d

### 省略 ###

Capacity:      2Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Used By:       mysql-cluster-0

2. 容量が2Giではない

NFSの全容量が公開されている + 2Gi以上も問題なく利用できる。

kubectl exec -it mysql-cluster-0 -n dev -c mysql -- /bin/bash

bash-4.4$ df -h
Filesystem                                                             Size  Used Avail Use% Mounted on
### 省略 ###
192.168.1.204:/mnt/tank/lun1/pvc-0d5ef0cf-be39-4fe4-8c7d-ba2fcb53229d  872G   17G  856G   2% /var/lib/mysql

2. 原因
#

NFSの以下の仕様のため。

  • PVCはノード/ポッドにマウントされたNFS内のフォルダーで、NFSの特定のディレクトリをマウントしてもファイルシステム全体の使用状況が表示される。
  • NFS自体には特定のフォルダの容量制限をするquota機能が存在しない。従って、Capacityの制限を実装できない。

PVCはNFSのフォルダである

以下を見るように、NFSの特定のフォルダがpod内(今回は/var/lib/mysql)にマウントされおり、容量は872G。

bash-4.4$ df -h
Filesystem                                                             Size  Used Avail Use% Mounted on
192.168.1.204:/mnt/tank/lun1/pvc-0d5ef0cf-be39-4fe4-8c7d-ba2fcb53229d  872G   17G  856G   2% /var/lib/mysql

利用しているNFS(TrueNAS)では確かに/mnt/tank/lun1は872Gでvolumeを作成している。

root@truenas[~]# df -h
Filesystem                                               Size    Used   Avail Capacity  Mounted on
tank/lun0                                                865G    8.7G    856G     1%    /mnt/tank/lun0
tank/lun1                                                872G     16G    856G     2%    /mnt/tank/lun1
tank/lun2                                                936G     80G    856G     9%    /mnt/tank/lun2

更に利用している/mnt/tank/lun1を見てみると、複数のPVがフォルダとして作成されていることが分かる。

root@truenas[/mnt/tank/lun1]# ls -al | grep pvc | head -n 10
drwxrwsr-x    5 root  1000      7 Aug 24 03:13 pvc-02746503-d9d9-425c-a833-d626dd8b7c6d
drwx--S---    8 27    27       38 Apr 18 23:39 pvc-05c6524f-3b5b-4fb8-9854-49ea0c47a9c1
drwxrwsr-x    5 root  1000      7 Aug 24 06:36 pvc-05f7474d-2394-4af5-93a2-0926b9c6f42a
drwx--S---    8 27    27       35 Apr 13 19:25 pvc-0730e5a5-bd13-4c6a-970b-b2c00e4180e8
drwx--S---    8 27    27       35 Apr 21 00:32 pvc-07a95b07-11e4-42f9-bb48-27e115f54411
drwxr-xr-x    2 root  wheel     2 Jun 22 09:02 pvc-07aad2bb-c1c3-40e4-8fef-e82659272d41

ということで、PVとしてこのフォルダがマウントされるだけなので、Capacity制限が効果がない + 全容量が見えてしまう。

NFS自体にはquota機能がない

フォルダがマウントされるならフォルダに容量制限を実施すれば良いと思うが、残念ながらNFSのプロトコル自体にはquota(容量制限)機能がない。

従ってフォルダごとの容量制限ができず、Capacity制限が効果がない + 全容量が見えてしまう。

NFS自体には容量制限機能がないが、サーバーのフォルダ毎に容量制限をかけるrquotadなどのサービスはは存在する。[redhat公式docs]

これを使うことで容量制限は実現できるが、あくまでNFSサーバーで稼働しているだけなので、クライアント側(pod)ではこの制限がかかっているか確認はできない。

おわりに
#

podに払い出した容量と、実際の容量が乖離して監視が正常に機能しないので注意が必要

自分の環境では、ElasticSearchのpodのPVとしてNFSを利用していた。しかし容量が実際と乖離している + 同じNFSから払い出しているので3倍の2.6TBあるように見えてしまっている。
alt text

Related

ElasticSearchを使ったlog収集4 -kubernetes integration-
·2800 文字
Blog ElasticSearch Kubernetes
Gitlab CI/CDでrepositoryにpushする方法
·1257 文字
Memo Gitlab
MySQL InnoDB Cluster3 -helmで利用できるoption-
·1613 文字
Blog Kubernetes Mysql