Level 2: ステートフルコンテナの実現

目的・ゴール: アプリケーションのデータ永続化を実現

アプリケーションは永続化領域がないとデータの保存ができません。 KubernetesではStatic provisioningとDynamic provisioningの２つの永続化の手法があります。

このレベルではDynamic provisioningを実現するためDynamic provisionerであるTridentをインストールし、 マニフェストファイルを作成しデータの永続化をすることが目標です。

流れ

1. Dynamic storage provisioningを実現(Tridentのインストール)

2. StorageClassの作成

3. PVCをkubernetesマニフェストファイルに追加

   1. 作成したStorageClassを使用する
   2. PVCをkubernetesにリクエストした時点で動的にストレージがプロビジョニングされる

4. アプリケーションを稼働させて永続化ができていることを確認

コンテナでの永続データのカテゴライズ

コンテナ化されたアプリケーション、環境での永続データは 以下のように分類して考え必要な物をリストアップしました。

• データベースのデータファイル、ログファイル
• 各サーバのログファイル
• 設定ファイル
• 共有ファイル

Dynamic provisioning

ステートフルコンテナを実現する上でストレージは重要なコンポーネントになります。

Dynamic volume provisiong はオンデマンドにストレージをプロビジョニングするためのものです。

Static provisioning、Dynamic provisioning それぞれを比較します。

Static provisioningの場合、クラスタの管理者がストレージをプロビジョニングして、PersitentVolumeオブジェクトを作成しkubernetesに公開する必要があります。

Dynamic provisioningの場合、Static provisioningで手動で行っていたステップを自動化し、管理者がおこなっていたストレージの事前のプロビジョニング作業をなくすことができます。

StorageClassオブジェクトで指定したプロビジョナを使用し、動的にストレージリソースをプロビジョニングすることができます。

StorageClassには様々なパラメータを指定することができアプリケーションに適したストレージカタログ、プロファイルを作成することができ、物理的なストレージを抽象化するレイヤとなります。

ネットアップはDynamic provisioningを実現するためのNetApp Tridentというprovisionerを提供しています。

このレベルではTridentでDynamic provisioningを行い、アプリケーションのデータ永続化を実現します。

NetApp Tridentのインストール

Dynamic storage provisioningを実現するためNetApp Tridentを導入します。 TridentはPodとしてデプロイされ通常のアプリケーションと同様に稼働します。

Tridentインストール事前準備

Trident のインストールでk8sクラスタの管理者権限が必要になります。

$ kubectl auth can-i '*' '*' --all-namespaces

バックエンドに登録するマネジメントIPにk8sクラスタのコンテナから疎通が取れるかを確認します。

$ kubectl run -i --tty ping --image=busybox --restart=Never --rm --  ping [ipアドレス]

Tridentインストール

バイナリをダウンロードしてインストールします。(例はバージョン18.07) バックエンドストレージのための setup/backend.json を編集します。

$ wget https://github.com/NetApp/trident/releases/download/v18.07.0/trident-installer-18.07.0.tar.gz

$ tar xzf trident*.tar.gz && cd trident-installer

$ cp sample-input/backend-ontap-nas.json setup/backend.json

backend.jsonの設定パラメータ (NFS ONTAPバックエンド)

パラメータ名	説明	設定内容
managementLIF	ONTAPのクラスタ管理LIFまたはSVM管理LIFを設定	192.168.XX.200
dataLIF	データ通信LIF	192.168.XX.200
svm	tridentから使用するSVM	svmXX
username/password	クラスタ管理者またはSVM管理者のクレデンシャル	SVM管理者を設定: vsadmin/netapp123

「XX」はユーザ環境番号になります。

編集後は以下の通りとなります。 疎通が取れないIPを設定するとtridentデプロイが失敗します。

$ cat setup/backend.json

{
    "version": 1,
    "storageDriverName": "ontap-nas",
    "managementLIF": "192.168.XX.200",
    "dataLIF": "192.168.XX.200",
    "svm": "svmXX",
    "username": "vsadmin",
    "password": "netapp123"
}

tridentctl ユーティリティではドライランモードとデバッグモードがオプションで指定できます。 ２つを設定し、実行すると以下のように必要事項を事前チェックし、その内容をすべて標準出力にプリントします。

まずは、ドライランモードで実行し問題ないことを確認します。以下の出力結果はユーザ14で実施した場合です。

$ ./tridentctl install --dry-run -n trident -d

DEBU Initialized logging.                          logLevel=debug
DEBU Running outside a pod, creating CLI-based client.
DEBU Initialized Kubernetes CLI client.            cli=kubectl flavor=k8s namespace=default version=1.11.0
DEBU Validated installation environment.           installationNamespace=trident kubernetesVersion=
DEBU Parsed requested volume size.                 quantity=2Gi
DEBU Dumping RBAC fields.                          ucpBearerToken= ucpHost= useKubernetesRBAC=true
DEBU Namespace does not exist.                     namespace=trident
DEBU PVC does not exist.                           pvc=trident
DEBU PV does not exist.                            pv=trident
INFO Starting storage driver.                      backend=/home/localadmin/manifest/trident/trident-installer/setup/backend.json
DEBU config: {"backendName":"NFS_ONTAP_Backend","dataLIF":"192.168.14.200","managementLIF":"192.168.14.200","password":"netapp123","storageDriverName":"ontap-nas","svm":"svm14","username":"vsadmin","version":1}
DEBU Storage prefix is absent, will use default prefix.
DEBU Parsed commonConfig: {Version:1 StorageDriverName:ontap-nas BackendName:NFS_ONTAP_Backend Debug:false DebugTraceFlags:map[] DisableDelete:false StoragePrefixRaw:[] StoragePrefix:<nil> SerialNumbers:[] DriverContext:}
DEBU Initializing storage driver.                  driver=ontap-nas
DEBU Addresses found from ManagementLIF lookup.    addresses="[192.168.14.200]" hostname=192.168.14.200
DEBU Using specified SVM.                          SVM=svm14
DEBU ONTAP API version.                            Ontapi=1.130
WARN Could not determine controller serial numbers. API status: failed, Reason: Unable to find API: system-node-get-iter, Code: 13005
DEBU Configuration defaults                        Encryption=false ExportPolicy=default FileSystemType=ext4 NfsMountOptions="-o nfsvers=3" SecurityStyle=unix Size=1G SnapshotDir=false SnapshotPolicy=none SpaceReserve=none SplitOnClone=false StoragePrefix=trident_ UnixPermissions=---rwxrwxrwx
DEBU Data LIFs                                     dataLIFs="[192.168.14.200]"
DEBU Found NAS LIFs.                               dataLIFs="[192.168.14.200]"
DEBU Addresses found from hostname lookup.         addresses="[192.168.14.200]" hostname=192.168.14.200
DEBU Found matching Data LIF.                      hostNameAddress=192.168.14.200
DEBU Configured EMS heartbeat.                     intervalHours=24
DEBU Read storage pools assigned to SVM.           pools="[aggr1_01 aggr2_01]" svm=svm14
DEBU Read aggregate attributes.                    aggregate=aggr1_01 mediaType=ssd
DEBU Read aggregate attributes.                    aggregate=aggr2_01 mediaType=hdd
DEBU Storage driver initialized.                   driver=ontap-nas
INFO Storage driver loaded.                        driver=ontap-nas
INFO Dry run completed, no problems found.

ドライランモードで実施すると最後に問題ない旨(INFO Dry run completed, no problems found.) が表示されれば、インストールに必要な事前要件を満たしていることが確認できます。

上記の状態まで確認できたら実際にインストールを実施します。

$ ./tridentctl install -n trident -d

DEBU Initialized logging.                          logLevel=debug
DEBU Running outside a pod, creating CLI-based client.
DEBU Initialized Kubernetes CLI client.            cli=kubectl flavor=k8s namespace=default version=1.11.0
DEBU Validated installation environment.           installationNamespace=trident kubernetesVersion=
DEBU Parsed requested volume size.                 quantity=2Gi
DEBU Dumping RBAC fields.                          ucpBearerToken= ucpHost= useKubernetesRBAC=true
DEBU Namespace does not exist.                     namespace=trident
DEBU PVC does not exist.                           pvc=trident
DEBU PV does not exist.                            pv=trident
INFO Starting storage driver.                      backend=/home/localadmin/manifest/trident/trident-installer/setup/backend.json
DEBU config: {"backendName":"NFS_ONTAP_Backend","dataLIF":"192.168.14.200","managementLIF":"192.168.14.200","password":"netapp123","storageDriverName":"ontap-nas","svm":"svm14","username":"vsadmin","version":1}
DEBU Storage prefix is absent, will use default prefix.
DEBU Parsed commonConfig: {Version:1 StorageDriverName:ontap-nas BackendName:NFS_ONTAP_Backend Debug:false DebugTraceFlags:map[] DisableDelete:false StoragePrefixRaw:[] StoragePrefix:<nil> SerialNumbers:[] DriverContext:}
DEBU Initializing storage driver.                  driver=ontap-nas
DEBU Addresses found from ManagementLIF lookup.    addresses="[192.168.14.200]" hostname=192.168.14.200
DEBU Using specified SVM.                          SVM=svm14
DEBU ONTAP API version.                            Ontapi=1.130
WARN Could not determine controller serial numbers. API status: failed, Reason: Unable to find API: system-node-get-iter, Code: 13005
DEBU Configuration defaults                        Encryption=false ExportPolicy=default FileSystemType=ext4 NfsMountOptions="-o nfsvers=3" SecurityStyle=unix Size=1G SnapshotDir=false SnapshotPolicy=none SpaceReserve=none SplitOnClone=false StoragePrefix=trident_ UnixPermissions=---rwxrwxrwx
DEBU Data LIFs                                     dataLIFs="[192.168.14.200]"
DEBU Found NAS LIFs.                               dataLIFs="[192.168.14.200]"
DEBU Addresses found from hostname lookup.         addresses="[192.168.14.200]" hostname=192.168.14.200
DEBU Found matching Data LIF.                      hostNameAddress=192.168.14.200
DEBU Configured EMS heartbeat.                     intervalHours=24
DEBU Read storage pools assigned to SVM.           pools="[aggr1_01 aggr2_01]" svm=svm14
DEBU Read aggregate attributes.                    aggregate=aggr1_01 mediaType=ssd
DEBU Read aggregate attributes.                    aggregate=aggr2_01 mediaType=hdd
DEBU Storage driver initialized.                   driver=ontap-nas
INFO Storage driver loaded.                        driver=ontap-nas
INFO Starting Trident installation.                namespace=trident
DEBU Created Kubernetes object by YAML.
INFO Created namespace.                            namespace=trident
DEBU Deleted Kubernetes object by YAML.
DEBU Deleted cluster role binding.
DEBU Deleted Kubernetes object by YAML.
DEBU Deleted cluster role.
DEBU Deleted Kubernetes object by YAML.
DEBU Deleted service account.
DEBU Created Kubernetes object by YAML.
INFO Created service account.
DEBU Created Kubernetes object by YAML.
INFO Created cluster role.
DEBU Created Kubernetes object by YAML.
INFO Created cluster role binding.
DEBU Created Kubernetes object by YAML.
INFO Created PVC.
DEBU Attempting volume create.                     size=2147483648 storagePool=aggr1_01 volConfig.StorageClass=
DEBU Creating Flexvol.                             aggregate=aggr1_01 encryption=false exportPolicy=default name=trident_trident securityStyle=unix size=2147483648 snapshotDir=false snapshotPolicy=none snapshotReserve=0 spaceReserve=none unixPermissions=---rwxrwxrwx
DEBU SVM root volume has no load-sharing mirrors.  rootVolume=svm_root
DEBU Created Kubernetes object by YAML.
INFO Created PV.                                   pv=trident
INFO Waiting for PVC to be bound.                  pvc=trident
DEBU PVC not yet bound, waiting.                   increment=282.430263ms pvc=trident
DEBU PVC not yet bound, waiting.                   increment=907.038791ms pvc=trident
DEBU PVC not yet bound, waiting.                   increment=1.497234254s pvc=trident
DEBU PVC not yet bound, waiting.                   increment=1.182346358s pvc=trident
DEBU PVC not yet bound, waiting.                   increment=3.794274009s pvc=trident
DEBU Logged EMS message.                           driver=ontap-nas
DEBU PVC not yet bound, waiting.                   increment=2.554707984s pvc=trident
DEBU Created Kubernetes object by YAML.
INFO Created Trident deployment.
INFO Waiting for Trident pod to start.
DEBU Trident pod not yet running, waiting.         increment=481.632837ms
DEBU Trident pod not yet running, waiting.         increment=848.840617ms
DEBU Trident pod not yet running, waiting.         increment=1.171028148s
DEBU Trident pod not yet running, waiting.         increment=871.68468ms
DEBU Trident pod not yet running, waiting.         increment=2.784723303s
DEBU Trident pod not yet running, waiting.         increment=3.037298468s
DEBU Trident pod not yet running, waiting.         increment=7.540652793s
DEBU Trident pod not yet running, waiting.         increment=12.611925219s
DEBU Trident pod not yet running, waiting.         increment=18.389729895s
INFO Trident pod started.                          namespace=trident pod=trident-6946fdf6d8-8cb8q
INFO Waiting for Trident REST interface.
DEBU Invoking tunneled command: kubectl exec trident-6946fdf6d8-8cb8q -n trident -c trident-main -- tridentctl -s 127.0.0.1:8000 version -o json
INFO Trident REST interface is up.                 version=18.07.0
INFO Trident installation succeeded.

「INFO Trident installation succeeded.」が出力されればインストール成功です。

また、問題が発生した場合には tridentctl を使用してtridentに関するログをまとめて確認することが出来ます。

$ ./tridentctl -n trident logs

time="2018-02-15T03:32:35Z" level=error msg="API invocation failed. Post https://10.0.1.146/servlets/netapp.servlets.admin.XMLrequest_filer: dial tcp 10.0.1.146:443: getsockopt: connection timed out"
time="2018-02-15T03:32:35Z" level=error msg="Problem initializing storage driver: 'ontap-nas' error: Error initializing ontap-nas driver. Could not determine Data ONTAP API version. Could not read ONTAPI version. Post https://10.0.1.146/servlets/netapp.servlets.admin.XMLrequest_filer: dial tcp 10.0.1.146:443: getsockopt: connection timed out" backend= handler=AddBackend
time="2018-02-15T03:32:35Z" level=info msg="API server REST call." duration=2m10.64501326s method=POST route=AddBackend uri=/trident/v1/backend

Tridentへバックエンドストレージの登録

インストールが完了したらtridentのバージョンを確認します。

$ ./tridentctl  version -n trident

+----------------+----------------+
| SERVER VERSION | CLIENT VERSION |
+----------------+----------------+
| 18.07.0        | 18.07.0        |
+----------------+----------------+

バージョンが表示されていればインストール成功です。 作成した定義ファイル、 setup/backend.json を使用し、バックエンド登録を実行します。 まずは NFS ストレージバックエンドであるONTAPを登録します。

$ ./tridentctl -n trident create backend -f setup/backend.json

+-------------------+----------------+--------+---------+
|       NAME        | STORAGE DRIVER | ONLINE | VOLUMES |
+-------------------+----------------+--------+---------+
| NFS_ONTAP_Backend | ontap-nas      | true   |       0 |
+-------------------+----------------+--------+---------+

つづいて、iSCSI ブロック・ストレージバックエンドのSolidFireを登録します。

NFSバックエンドストレージと同様に setup ディレクトリに solidfire-backend.json を作成します。

基本的な設定項目としては以下の表の通りです。

solidfire-backend.jsonの設定パラメータ (iSCSI SolidFire バックエンド)

パラメータ名	説明	設定内容
Endpoint	SolidFire の管理用IPを設定(MVIP)、URL先頭にユーザーIDとパスワードを付与	10.128.223.240
SVIP	データ通信のIPを設定（クラスタで１つ）	192.168.0.240:3260
TenantName	任意の名称を設定、SolidFire側でのテナントとなる。	今回は環境番号とする(userXX)
Types	ストレージカタログとしてのQoSのリストを指定	1つ以上のminIOPS, maxIOPS, burstIOPSを指定

テンプレートとなるSolidFireのバックエンド定義ファイルは以下の通りです。

{
    "version": 1,
    "storageDriverName": "solidfire-san",
    "Endpoint": "https://ユーザ名:パスワード@マネジメント用IP/json-rpc/8.0",
    "SVIP": "ストレージアクセス用IP:3260",
    "TenantName": "ユーザ環境番号",
    "backendName": "iSCSI_SF_Backend",
    "InitiatorIFace": "default",
    "UseCHAP": true,
    "Types": [
        {
            "Type": "Bronze",
            "Qos": {
                "minIOPS": 1000,
                "maxIOPS": 3999,
                "burstIOPS": 4500
            }
        },
        {
            "Type": "Silver",
            "Qos": {
                "minIOPS": 4000,
                "maxIOPS": 5999,
                "burstIOPS": 6500
            }
        },
        {
            "Type": "Gold",
            "Qos": {
                "minIOPS": 6000,
                "maxIOPS": 8000,
                "burstIOPS": 10000
            }
        }
    ]
}

同様にバックエンド登録を実施します。

$ ./tridentctl -n trident create backend -f setup/solidfire-backend.json

+------------------+----------------+--------+---------+
|       NAME       | STORAGE DRIVER | ONLINE | VOLUMES |
+------------------+----------------+--------+---------+
| iSCSI_SF_Backend | solidfire-san  | true   |       0 |
+------------------+----------------+--------+---------+

今までに登録したストレージバックエンドを確認します。

$ ./tridentctl get backend -n trident

+-------------------+----------------+--------+---------+
|       NAME        | STORAGE DRIVER | ONLINE | VOLUMES |
+-------------------+----------------+--------+---------+
| NFS_ONTAP_Backend | ontap-nas      | true   |       0 |
| iSCSI_SF_Backend  | solidfire-san  | true   |       0 |
+-------------------+----------------+--------+---------+

注釈

tridentctl ユーティリティにはアンインストール用のサブコマンドがあります。

以下のように -a オプションを付与して実行すると生成した管理用のetcdのデータなどすべてを削除した上でアンインストールします。 インストール実行時に失敗したときなど、クリーンに再インストールしたい場合に使います。

$ ./tridentctl uninstall -n trident -a

StorageClassの定義

StorageClassを定義して、ストレージのサービスカタログを作りましょう。

Trident v18.07 ではStorageClassを作成するときに以下の属性を設定できます。 これらの属性のパラメータを組み合わせてストレージサービスをデザインします。

StorageClass の parameters に設定可能な属性

設定可能な属性	例
性能に関する属性	メデイアタイプ(hdd, hybrid, ssd)、プロビジョニングのタイプ（シン、シック)、IOPS
データ保護・管理に関する属性	スナップショット有無、クローニング有効化、暗号化の有効化
バックエンドのストレージプラットフォーム属性	ontap-nas, ontap-nas-economy, ontap-nas-flexgroup, ontap-san, solidfire-san, eseries-iscsi

全てのパラメータ設定については以下のURLに記載があります。

• https://netapp-trident.readthedocs.io/en/stable-v18.07/kubernetes/concepts/objects.html#kubernetes-storageclass-objects

NFSバックエンドのONTAPでのStorageClass

ストレージ構成は以下の通りです。 今回、意識する必要があるところは異なるメディアタイプ(HDDとSSD)のアグリゲートを保有しているところです。

• 各SVMにHDD, SSDのアグリゲートを割り当て済み

  • aggr1_01:SSDのアグリゲート
  • aggr2_01:HDDのアグリゲート

以下のようなイメージでStoageClassを作成しましょう。

• DB 用の高速領域: SSD を使ったストレージサービス
• Web コンテンツ用のリポジトリ: HDDを使ったストレージサービス

以下は上記の「DB 用の高速領域」のStorageClass作成方法のサンプルです。

高速ストレージ用のマニフェストファイル例 StorageClassFastest.yml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ontap-gold
provisioner: netapp.io/trident
parameters:
  backendType: "ontap-nas"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"

ストレージクラスを作成します。

$ kubectl create -f StorageClassFastest.yml

storageclass "ontap-gold" created

$ kubectl get sc

NAME         PROVISIONER         AGE
ontap-gold   netapp.io/trident   10s

同様にブロックデバイスバックエンドとして設定したSolidFireに対応するStorageClassを作成します。

バックエンド登録時に３つの性能別のQoSを作成しました。

それぞれに該当するStoageClassを作成します。StorageClassで指定されたIOPSを実現できるバックエンドのQoSがボリューム作成時に自動設定されます。

1000IOPSの性能が出せるStorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-bronze
provisioner: netapp.io/trident
parameters:
  backendType: "solidfire-san"
  IOPS: "1500"
  fsType: "ext4"

4000IOPSの性能が出せるStoageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-silver
provisioner: netapp.io/trident
parameters:
  backendType: "solidfire-san"
  IOPS: "4000"
  fsType: "ext4"

8000IOPSの性能が出せるStoageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: solidfire-gold
provisioner: netapp.io/trident
parameters:
  backendType: "solidfire-san"
  IOPS: "8000"
  fsType: "ext4"

以降のセクションではここまでで作成したStorageClassを適切に使い分けてすすめましょう。

注釈

デフォルトのStorageClassの設定

StorageClassは記載がないときに使用するStorageClassを指定できます。

kubectl patch storageclass ストレージクラス名 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Persistent Volume Claimの作成

アプリケーションで必要とされる永続化領域の定義をします。 PVCを作成時に独自の機能を有効化することができます。

データの保管ポリシー、データ保護ポリシー、SnapShotの取得ポリシー、クローニングの有効化、暗号化の有効化などを設定できます。

一覧については以下のURLに記載があります。 metadata.annotation 配下に記述することで様々な機能を使用することが可能となります。

• https://netapp-trident.readthedocs.io/en/stable-v18.07/kubernetes/concepts/objects.html#kubernetes-persistentvolumeclaim-objects

デプロイ用のマニフェストファイルにPVCを追加

Level1で作成したマニフェストファイルにPVCの項目を追加し、ダイナミックプロビジョニングを使用しデータを永続化出来るアプリケーションを定義します。

高速ストレージ用の定義ファイルの例 PVCFastest.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pv-claim
  labels:
    app: アプリケーション名
  annotations:
    trident.netapp.io/reclaimPolicy: "Retain"
    trident.netapp.io/exportPolicy: "default"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ontap-gold

デプロイメント実施

上記のPVCの設定が終わったら再度アプリケーションをデプロイします。

その後、アプリケーションからデータを保存するようオペレーションを行います。 WordPressであれば記事を投稿することで簡単に確認ができます。

アプリケーションの停止・起動

永続化されていることを確認するため、一度アプリケーションを停止します。

Deploymentで必要となるポッドは起動するような設定になっているため、 簡単にアプリケーションの停止・起動を行う方法として Deployment 配下の Pod を削除する方法がとれます。

$ kubectl delete pod -l "ラベル名"

$ kubectl get deploy

実行例は以下の通りです。

$ kubectl delete pod -l app=wordpress

pod "wordpress-5bc75fd7bd-kzc5l" deleted
pod "wordpress-mysql-565494758-jjdl4" deleted

$ kubectl get deploy

NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
wordpress         1         1         1            0           31d
wordpress-mysql   1         1         1            0           31d

DeploymentによってPodの起動数は管理されるため新たにPodが起動します。 AVAILABLE の数が正常になるまで待ちましょう。

$ kubectl get deploy

NAME              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
wordpress         1         1         1            1           31d
wordpress-mysql   1         1         1            1           31d

再デプロイメント後の確認

再起動したPodに対して永続化されたデータが使用されていることを確認します。 2つの視点から確認したいと思います。

1. アプリケーションであれば再度ログインして保存したデータを確認します。
2. バックエンドストレージに動的にボリュームが作成されていることを確認します。

$ ssh vsadmin@192.168.XX.20 vol show

Password:
Vserver   Volume       Aggregate    State      Type       Size  Available Used%
--------- ------------ ------------ ---------- ---- ---------- ---------- -----
tridentsvm root        aggr1        online     RW          1GB    972.2MB    5%
tridentsvm trident_trident aggr1    online     RW       1.86GB     1.77GB    5%
tridentsvm trident_trident_basic_f4048 aggr1 online RW     1GB    972.4MB    5%
3 entries were displayed.

Tridentの特徴的な機能: Fast Cloning

Tridentには特徴的な機能であるクローニングの機能が存在します。

巨大なボリュームでも容量消費せずに超高速にデータをコピーする クローニングテクノロジーがkubernetesでも使用可能となります。

ユーザーが既存のボリュームを複製することによって新しいボリュームをプロビジョニングできる機能を提供しています。 PVCアノテーションである、trident.netapp.io/cloneFromPVC を介してクローン機能を利用できます。

引数にPVC名を指定します。

クローニングのマニフェストファイルの例 pvccloning.yml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: basicclone
  annotations:
    trident.netapp.io/cloneFromPVC: database (<-ここにクローンしたい既存のPVC名(ボリューム名）を記述）
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ontap-gold

ここではサンプルでPVC Cloning を活用したOracle Databaseを複数デプロイするデモ動画をご覧ください。

クローニング技術によって実現可能なこと

クローニング技術はシンプルですが非常に多く用途で使用することができます。 例としてあげられるのが以下の用途です。

• プレビルド環境の高速展開
• 本番環境に影響せずに大規模な並列テスト
• 運用時のデータリストアの高速化、瞬時に論理障害を戻す

Tridentの18.07でのアップデート: CSI (Container Storage Interface)への対応

最新のTridentではCSIモードでのデプロイが可能となっています。(インストール時に --csi を付与する） CSIは仕様自体がまだαステージということもあり実験的なモードですが、いち早くCSIをお試しいただくことが可能となっています。

• Trident CSI モードでの動作：https://netapp-trident.readthedocs.io/en/latest/kubernetes/trident-csi.html
• Trident CSI に書かれた記事: https://netapp.io/2018/07/03/netapp-trident-and-the-csi-oh-my/

CSI自体についてはこちら - https://kubernetes.io/blog/2018/01/introducing-container-storage-interface/

注釈

理論的にはCSIの仕様でドライバを実装すれば、そのドライバはkubernetes、Mesos, Docker, Cloud Foundryなど CSIを実装したコンテナオーケストレーターから使用できるようになります。

まとめ

アプリケーションに対して動的に永続化領域をプロビジョニングしデータの永続化を実現しました。

今回はStorageClassの作成からアプリケーションにPersistentVolumeを割り当てるところまでを一連の流れで実現しました。

運用を考えた場合、それぞれのコンポーネントで担当が異なるため以下のような分担になるかと思います。

• StorageClassの作成: インフラ・kubernetesクラスタの管理者
• PersistentVolumeClaimの作成: アプリケーション開発者

今後障害時の動作が気になると思いますが、 Level 4: 運用編 での検討事項とします。

ここまでで Level2 は終了です。