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

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

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

このレベルではDynamic provisioningを実現するためDynamic provisonerである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インストール

バイナリをダウンロードしてインストールします。 バックエンドストレージのための setup/backend.json を編集します。以下はサンプルとなります。

$ wget https://github.com/NetApp/trident/releases/download/v18.01.0/trident-installer-18.01.0.tar.gz
$ tar xzf trident*.tar.gz && cd trident-installer
$ cp sample-input/backend-ontap-nas.json setup/backend.json

backend.jsonの設定パラメータ

パラメータ名	説明	設定内容
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"
}

$ ./install_trident.sh -n trident

インストールの進捗を確認します。

$ kubectl get pod -n trident -aw

NAME                READY     STATUS    RESTARTS   AGE
trident-ephemeral   1/1       Running   0          58s

``-aw``オプションをつけることでPodの動きに変化があれば自動的にリロードしてくれます。

上記の状態で止まってしまう場合は、 trident-installer/ 配下に tridentctl というtridentのコマンドラインユーティリティが同梱されています。 このツールを使って状況を確認します。

tridentctlはパスの通った場所に配置します。

$ sudo cp tridentctl /usr/local/bin

以下のように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へバックエンドストレージの登録

インストールが完了したことを確認します。

$ tridentctl -n trident version

+----------------+----------------+
| SERVER VERSION | CLIENT VERSION |
+----------------+----------------+
| 18.01.0        | 18.01.0        |
+----------------+----------------+

バージョンが表示されていればインストール成功です。 作成した setup/backend.json を指定し作成します。

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

+-------------------------+----------------+--------+---------+
|          NAME           | STORAGE DRIVER | ONLINE | VOLUMES |
+-------------------------+----------------+--------+---------+
| ontapnas_192.168.10.200 | ontap-nas      | true   |       0 |
+-------------------------+----------------+--------+---------+

（Troubleshooting) Tridentをアンインストールする

trident-installer にアンインストール用のシェルスクリプトが入っています。 以下の用に -a オプションを付与して実行すると生成した管理用のetcdのデータなどすべてを削除した上でアンインストールします。

$ ./uninstall_trident.sh -n trident -a

インストール時にうまくいかずに試行錯誤した際には一度クリーンアップすることをおすすめします。

例えば、v18.01のTridentでは以下の項目をStorageClassを作成するときに設定できます。

• 性能に関する属性: メディアのタイプ、プロビジョニングのタイプ（シン・シック）、IOPS
• データ保護・管理に関する属性:スナップショット、クローニング、暗号化の有効・向こう
• バックエンドのストレージプラットフォーム

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

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

StorageClassの定義

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

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

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

• ONTAP 9.3

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

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

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

Persistent Volume Claimの作成

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

reclaimPolicy によってポッドがなくなった際のデータの保管ポリシーの設定ができます。 他にもデータ保護、SnapShotの取得ポリシーなどを設定できます。

一覧については以下のURLに記載があります。

• https://netapp-trident.readthedocs.io/en/stable-v18.01/kubernetes/concepts/objects.html#trident-volume-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

デプロイメント実施

アプリケーションから何かしらのデータを保存するようにします。

• アプリケーションからデータを記録
• シンプルにnginxのアクセスログファイルを永続化

アプリケーションの停止

永続化されていることを確認するため、一度アプリケーションを停止します。 可能であればアプリケーションのバージョンアップを行ってみましょう。

Deploymentで必ず１つのポッドは起動するような設定になっているため、 簡単に実施するためにはポッドを削除する手段がとれます。 DeploymentによってPodの起動数は管理されるため新たにポッドが起動します。

再デプロイメント

再起動したPodに対してボリュームがマウントされていることを確認することも可能です。 容易に行える操作としてはDeployment配下にあるPodを削除し、Deploymentによって起動し直させるといったやり方です。

• アプリケーションであれば再度ログインし、保存したデータを確認します。
• 通常運用のリリースに想定するオペレーションをして、外部ストレージにデータ永続化されていることを確認します。

動的にボリュームが作成されていることを確認します。

$ ssh vsadmin@192.168.20.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 を介してクローン機能を利用できます。

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

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: basicclone
  annotations:
    trident.netapp.io/cloneFromPVC: database
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: ontap-gold

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

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

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

まとめ

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

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

本来であればそれぞれで役割がことなるため以下のような分担になるかと思います。

• StorageClassの作成: インフラ・kubernetesクラスタの管理者
• PersistentVolumeClaimの作成: 利用者

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

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