初版: 2021/4/16
2021/8/10 関連投稿一覧を追記
2021/10/3,2022/2/2 新しい記事のリンクを追加
関連投稿一覧
- NetApp Tridentとは 【本投稿】
- NetApp Astra とは
- NetApp Astra Service を使ってみる ①GKE事前準備編
- NetApp Astra Service を使ってみる ②AKS事前準備編
- NetApp Astra Service を使ってみる ③Astra UI操作編
- NetApp Astra Control のインストール
- NetApp Astra Control を使ってみる ①UIの操作編
- NetApp Astra Data Store とは
はじめに
NetApp Tridentは、KubernetesとNetAppのストレージを接続するためのプラグインです。
Kubernetesのようなコンテナオーケストレーションツールとストレージプロバイダをつなぐ標準インターフェースとしてCSI(Container Storage Interface)という仕様がありますが、TridentはこのCSIに対応したDriverです。
Tridentを使用することで、ストレージを気にすることなくストレージリソースをオンデマンドにプロビジョニング・管理することができます。
プロビジョニングできるバックエンドのストレージは以下です。
NetApp AFF/FAS、E/EFシリーズ、ONTAP Select、Cloud Volumes ONTAP、NetApp Elementソフトウェア(SolidFire)
プロトコルは、NFSとiSCSIが利用できます。
Tridentは、Kubernetes 1.4から導入されたStorageClassオブジェクトを使用して、Persistent Volume Claim(PVC) オブジェクトの作成時に、Persistent Volume(PV) を動的にプロビジョニングし、マウントします。
Tridentを使うと何がいいの?
ではこのTridentを使うと何が便利になるのか、みてみましょう。
動的プロビジョニングを使用しない場合
下の図は、K8sのストレージをプロビジョニングする際に、動的プロビジョニングを「使わない」フローの例です。
動的プロビジョニングの仕組みを使わない場合は、この図のようにPVを事前に作成しておく必要があります。
例えば組織がインフラ部門とアプリケーション部門に分かれている場合、PVはストレージの仮想リソースとなるので、インフラ部門が作成することになるかと思います。
よって、アプリケーション開発者は、都度PVの作成依頼をインフラ部門に依頼する必要があります。
もしくはあらかじめPVを作成しておくことでその手間を省くことはできますが、アプリケーション開発者がPersistentVolumeClaimを使って要求した容量サイズより大きいPVがマウントされることもありリソースの無駄が発生する場合があります。
また、例えばアプリケーション開発者が、 既に作成済みのPVのサイズより大きい容量を要求した場合は、割り当てに失敗します。
動的プロビジョニングを行わない場合の操作手順は以下のようになります。
1. PVを作成
# test-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: test-volume
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: /home/mirorin/test
上記例では簡単にするためにhostPathを使用しています。該当ディレクトリに、index.htmlを用意しておきます。
$ kubectl apply -f test-pv.yaml
$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-volume 10Gi RWO Retain Available standard 39s
2. PVCを作成してPVをBind
# test-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
namespace: test
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
$ kubectl create namespace test
$ kubectl apply -f test-pvc.yaml
$ kubectl get pv,pvc -n test
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/test-volume 10Gi RWO Retain Bound test/test-pvc 92s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/test-pvc Bound test-volume 10Gi RWO 92s
STATUSがBoundとなりました。PVCの要求は5Giですが、10GiのPVをつかんでいますね。
3. Podを作成する
# test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: test
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: test-storage
mountPath: /usr/share/nginx/html
volumes:
- name: test-storage
persistentVolumeClaim:
claimName: test-pvc
$ kubectl apply -f test-pod.yaml
$ kubectl get pod -n test
NAME READY STATUS RESTARTS AGE
test-pod 1/1 Running 0 56s
マウントされたことを確認します。
$ kubectl exec -it test-pod -n test -- ls -la /usr/share/nginx/html/
total 12
drwxrwxrwx 2 1000 1000 4096 Apr 13 04:50 .
drwxr-xr-x 3 root root 4096 Apr 10 07:32 ..
-rw-rw-r-- 1 1000 1000 34 Apr 13 04:50 index.html
動的プロビジョニングを使用する場合
動的プロビジョニングを使うことで、PVCが作成された際に、自動的にPVが作成されます。
よってこの図のようにインフラ部門はアプリケーション開発者からの依頼の都度PVを作る必要もなく、割り当てられるボリュームのサイズに無駄が出ることもなくなります。
動的プロビジョニングを行うためのProvisionerにTridentを使用した際の操作例は以下のようになります。
事前1. Kubernetes ClusterにTridentをインストール
Tridentのインストール方法は、こちらを参照ください。
TridentもK8sのPodの形でデプロイされます。
$ kubectl get pod -n trident
NAME READY STATUS RESTARTS AGE
trident-csi-6885d67477-4s94l 6/6 Running 6 83d
trident-csi-sdgx8 2/2 Running 2 83d
Tridentに関する操作は、tridentctlを使って行います。※ 2021年4月現在の最新バージョンは、21.01.2です。
$ tridentctl -n trident version
+----------------+----------------+
| SERVER VERSION | CLIENT VERSION |
+----------------+----------------+
| 20.10.1 | 20.10.1 |
+----------------+----------------+
事前2. StorageBackend を作成
Storage Backendと呼ばれるオブジェクトを作成します。
Storage Backendは、ストレージのエンドポイントやログインユーザ情報を記載したJSONファイルを用いて作成します。
以下の例では、NetAppのSolidFireというストレージを使ってBackendを作成しています。
サンプルのjsonファイルは次のようになります。
# backend-solidfire.json
{
"version": 1,
"storageDriverName": "solidfire-san",
"Endpoint": "https://admin:solidfire$@10.128.211.50/json-rpc/12.2",
"SVIP": "192.168.0.50:3260",
"BackendName": "mbox",
"TenantName": "account01",
"UseCHAP": true,
"Types": [{"Type": "Bronze", "Qos": {"minIOPS": 100, "maxIOPS": 200, "burstIOPS": 500}},
{"Type": "Silver", "Qos": {"minIOPS": 1000, "maxIOPS": 2000, "burstIOPS": 4000}},
{"Type": "Gold", "Qos": {"minIOPS": 3000, "maxIOPS": 4000, "burstIOPS": 6000}}],
"InitiatorIFace": "default"
}
パラメータ | 値 |
---|---|
version | 1 |
storageDriverName | solidfire-san |
Endpoint | https://[ストレージクラスタのログインユーザ]:[ストレージクラスタのログインパスワード]@[ストレージクラスタの管理用VIP]/json-rpc/[Elementバージョン] |
SVIP | ストレージクラスタのストレージVIP |
BackendName | このBackendにつける名前です。任意の名前を指定します。 |
TenantName | ボリュームにアクセスする際のアカウント名です。存在しない場合は自動で作成されます |
UseCHAP | trueを指定。iSCSI認証にCHAPを使用します。SolidFireのVolumeのiSCSIの認証方式としては「Volume Access Group」※がありますが、Volume Access GroupはTridentの従来の非CSIのフレームワークでのみでサポートされます。(CSIモードで動作するように構成されている場合、TridentはCHAPを使用します) ※「Volume Access Group」はVolumeとInitiatorをグループ化する機能で、グループに属するInitiatorを持つホストは該当Volumeへのアクセスが許可されます。 |
Types | QoSのタイプを記述 |
InitiatorIFace | iSCSI initiatorを記載することで、接続を特定のホストのみからに制限することができます。ホストを指定しない場合は"default"と記述します。 |
Backendの作成は、以下のように実施します。
$ tridentctl create backend -f backend-solidfire.json -n trident
+------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+------+----------------+--------------------------------------+--------+---------+
| mbox | solidfire-san | 7983351d-cf97-4884-830b-15ab1da01879 | online | 0 |
+------+----------------+--------------------------------------+--------+---------+
$ tridentctl get backend -n trident
+-------+----------------+--------------------------------------+--------+---------+
| NAME | STORAGE DRIVER | UUID | STATE | VOLUMES |
+-------+----------------+--------------------------------------+--------+---------+
| mbox | solidfire-san | 6e33be49-c3f1-4272-b3e9-55a9e52b7126 | online | 0 |
+-------+----------------+--------------------------------------+--------+---------+
事前3. StorageClass を作成
StorageClassは、ストレージの種類を表すK8sのオブジェクトです。
サンプルのYAMLファイルは次のようになります。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: solidfire-gold
provisioner: netapp.io/trident
parameters:
snapshots: "true"
storagePools: "mbox:Gold"
「parameters」に記載した値がStorage ProvisionerであるTridentに渡され、Tridentはこの情報を元にどのStorage Backendを使用するかを判断します。
Backendを直接指定する場合は、上記のように「storagePools」パラメータにBackend名を記載します。「storagePools」パラメータを指定した場合、他のパラメータは「storagePools」パラメータの値に上書きされます。
以下のようにBackendを直接指定せず最適なBackendを選択することも可能です。
parameters:
backendType: "solidfire-san"
IOPS: "1500"
fsType: "ext4"
yamlファイルを元に、StorageClassを作成します。
$ kubectl apply -f storage-class-solidfire-gold.yaml
storageclass.storage.k8s.io/solidfire-gold created
$ kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
solidfire-gold csi.trident.netapp.io Delete Immediate false 52s
少し面倒なように感じられるかもしれませんが、ここまで実施すれば後は利用者がPVCを作成する都度、自動でPVを作ってくれるようになるので、日々の運用の手間を省くことができます。
操作の手順は、以下のようになります。
1. PVCを作成
# test-pvc-2.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc-2
namespace: test2
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: solidfire-gold
$ kubectl create namespace test2
$ kubectl apply -f test-pvc-2.yaml
persistentvolumeclaim/test-pvc-2 created
$ kubectl get pv,pvc -n test2
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/pvc-531acf30-5371-4e4c-86e1-d175fb126e2d 5Gi RWO Delete Bound test2/test-pvc-2 solidfire-gold 4s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/test-pvc-2 Bound pvc-531acf30-5371-4e4c-86e1-d175fb126e2d 5Gi RWO solidfire-gold 4s
PVCの作成とともにPVが作成されました。「CAPACITY」を見ると、要求通り5Giで作成されていますね。
SolidFireのWebUIからも、このPVのVolumeが作成されたことが確認できます。
QoSも正しく反映されていますね。
2. Podの作成
Podの作成は通常と同様です。
# test-pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: test2
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: test-storage
mountPath: /usr/share/nginx/html
volumes:
- name: test-storage
persistentVolumeClaim:
claimName: test-pvc-2
$ kubectl apply -f test-pod-2.yaml
pod/test-pod created
$ kubectl get pod -n test2
NAME READY STATUS RESTARTS AGE
test-pod 1/1 Running 0 37s
おわりに
Tridentを使って、PVを動的に管理する仕組みの動的プロビジョニングについてご紹介しました。
Trident以外も様々なストレージベンダやクラウドサービスのprovisionerを利用し色々なタイプのボリュームを動的に作成し、割り当てることができます。
今度はTridentを使ったボリュームのバックアップについても記載していこうと思います。