実はかなり簡単?! NetApp Tridentを試してみる
はじめに
はじめまして。ネットアップ合同会社の大野と申します。
こちらをご覧になっている皆さんはKubernetes環境でダイナミックプロビジョニングを実現するNetApp Trident(以下Trident)を ご存知でしょうか?
今回このブログの場をお借りして、Tridentについての簡単な説明と、その導入方法についてご紹介したいと思います。
Tridentとは?
Kubernetes環境で永続データ=コンテナの短いライフサイクルを超えてデータを保存したい場合、PersistentVolumeというKubernetesオブジェクトを利用します。このPersistentVolumeを、「ユーザのリクエスト(PersistentVolumeClaim)に応じて自動的に作成」する仕組みをダイナミックプロビジョニングと呼びます。
これを実現するためには、Kubernetesにボリュームプラグインが必要で、その一つにContainer Storage Interface(CSI)があります。CSIは 業界標準として定められたインターフェイスで、Kubernetesはこれに対応したソフトウエア=CSI Driver により、対応するストレージを増やす事が出来るようになりました。
このCSI Driverにあたるのが、Trident です。Kubernetes環境にTridentを導入することで、NetAppストレージをKubernetes環境から利用することが可能になります。
CSIで出来る事/Tridentの特徴
CSIはボリュームを作り出して利用するだけではなく、ストレージの機能を使って高速に複製(クローン)したり、 サイズを拡大したり等、従来ストレージ管理者の方に依頼しなければならなかった操作もユーザ側で行うことが可能です。
ただし、CSI Driverはすべての機能を必ずしも提供しているわけではなく、実装により機能の有無が異なります。TridentはCSIボリュームプラグインがKubernetesで利用出来るようになってすぐに対応した事もあり、Kubernetesから利用できる機能を高いレベルで実現しています。
Tridentは弊社ストレージ製品/クラウドサービスのONTAP/SolidFire/E-Series/Cloud Volumes/Azure NetApp Filesに対応しているのでオンプレミス/クラウドで利用する事が可能です。
3ヶ月に一度のKubernetesリリースに合わせて、Tridentも3ヶ月に一度のリリースを行い出来るだけ最新のKubernetes環境を利用出来るようにしています。また、KubernetesだけでなくOpenShift等の各Kubernetesディストリビューションでも利用可能です。
これらに加えてTridentはCSIが想定していないような機能も提供しているため、 例えば仮想マシンの持つデータボリュームをコンテナ環境に取り込んでKubernetes上で利用すること等が簡単に実現できます。
導入から利用まで
Tridentはオープンソースで無償で提供されています。(保守サポートはストレージ製品サポートに紐付いて行われますのでご安心ください)
ONTAPストレージがあればすぐに試す事ができますので、さっそく導入して使ってみましょう!
導入準備
まずは導入を行うKubernetesとストレージの準備からです。
ただ、Kubernetesそのもののセットアップと、ONTAPストレージの初期セットアップについては今回は省略させていただきますので、 皆さんのお手元で環境を準備してみてください。
執筆時点でのTrident最新バージョン21.01(2021年1月リリース)がサポートする環境は以下の通りです。
- Kubernetes 1.11以上
- ONTAP 9.3以上
今回はCSIを利用するため、Kubernetesは1.13以上が必要になり、以下の環境で行っています。 また、追加のソフトウエアとしてHelm(後述)を利用します。
- Kubernetes 1.20.5
- ONTAP 9.8
- Trident 21.01.1
- Helm 3.5.3
CLIによる実行例等を簡単に済ませるためにjqやcurl等を使った処理も紹介しています。無くても問題ありませんが、あると便利かと思います。
Kubernetes側の準備
Tridentのインストール時に、Kubernetesの管理CLIであるkubectlと、Helmを使います。
Helmはパッケージマネージャと呼ばれる物で様々なアプリケーションパッケージをKubernetes上に展開することをサポートします。
Helmの導入
Helmは最低でもバージョン3以上が必要となります。
簡単に最新版を導入したい場合はCLIから以下のコマンドを実行します。
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
実際に実行すると以下のようにコマンドが一つ導入されます。 詳細については公式ドキュメントのHelmのインストールを参照してください。
Tridentの入手
ブラウザ等からGithubにアクセスして(https://github.com/NetApp/trident/releases)からTrident最新版をダウンロードします。
コマンドラインからは以下でダウンロード可能です。
curl -Ls https://api.github.com/repos/netapp/trident/releases/latest | jq ".assets[0].browser_download_url" | xargs -n1 curl -LOJR
NFSクライアントのインストール
これはLinux OSディストリビューションによって異なります。
- RedHat Enterprise Linux / CentOS 等
sudo yum install -y nfs-utils - Debian / Ubuntu 等
sudo apt-get install -y nfs-common
今回はNFSのみで試してみますので、これだけです。iSCSIを利用する場合は、それらのパッケージも必要になります。詳細はTrident公式ドキュメントを確認してください。
ONTAPストレージ側の準備
ここではTrident専用のStorage Virtual Machine(SVM)を作成していきます。
ONTAPストレージはクラスタの中に、仮想化されたストレージ=SVMを作り出し、SVMを一台の独立したストレージの様に扱う事が可能です。TridentからONTAPストレージを利用する場合はTrident専用のSVMを使う事が推奨されています。
SVMを作成する上で下記のIPアドレスや名前等を決めておいていただく必要があります。また、ネットワークインターフェイスの事を ONTAPではLIFと言いますので、LIFと記載いたします。
- SVMの名前
- SVM 管理者パスワード
- SVM 管理用LIFの名前、IPアドレス、ネットマスク
Kubernetesで動くPodから疎通可能なIPで一つ決めておきます - SVM NFS用LIFの名前、IPアドレス、ネットマスク
KubernetesクラスタのノードIPから疎通可能なIPで一つ決めておきます
また、事前に以下を確認しておきます。
- ONTAPクラスタへの管理者ログイン情報
通常admin。SVMの作成時にのみ利用します - Tridentがボリュームを切り出すためのAggregateの名前
ONTAPクラスタの中で事前に作成した物を利用します - KubernetesクラスタのノードIPアドレス範囲
アクセス制御設定に必要です - 管理用LIF、NFS用LIFが利用するネットワークポート
ホームとなるノード名とポート名が必要になります。
Trident専用SVMの準備
ここでは細かな説明は省略させていただきますが、ONTAP管理者ユーザでログインして以下のコマンドを実行していきます。 鉤括弧[]でくくった日本語のところは適宜置き換えてください
- SVM作成
vserver create -vserver [SVMの名前] -aggregate [Aggregateの名前] -language utf8mb4 - SVM管理者 vsadminを有効化
security login password -vserver [SVMの名前] -username vsadmin
※ ここでSVM管理者パスワードを入力
security login unlock -vserver [SVMの名前] -username vsadmin - 管理ネットワークインターフェイスを作成してIPを登録
network interface create -vserver [SVMの名前] -lif [管理LIFの名前] -service-policy default-management -address [管理LIFのIPアドレス] -netmask [管理LIFのネットマスク] -home-node [管理LIFのホームノード] -home-port [管理LIFのホームポート] - データ用ネットワークインターフェイスを作成してIPを登録
network interface create -vserver [SVMの名前] -lif [データLIFの名前] -service-policy default-data-files -address [データLIFのIPアドレス] -netmask [データLIFのネットマスク] -home-node [データLIFのホームノード] -home-port [データLIFの] - Export Policy(アクセス許可)の設定
vserver export-policy rule create -vserver [SVMの名前] -policyname default -clientmatch [KubernetesクラスタのノードIPアドレス範囲] -rorule any -rwrule any - SVMに利用できるAggregateをアサイン
vserver add-aggregates -vserver [SVMの名前] -aggregates [Aggregateの名前] - NFSサービスを開始
vserver nfs modify -vserver [SVMの名前] -showmount disabled
vserver nfs start -vserver [SVMの名前]
Kubernetes内からのアクセス確認
ストレージとKubernetesからネットワーク的に疎通が可能かどうかを確認します。
Kubernetesの各ノードに直接ログインしてping等で疎通を確認します。
ノードのIPからデータLIFへの疎通確認
ping [データLIFのIP] -c 3
Podの中から管理LIFへの疎通確認。
kubectl run -it --rm --image=alpine storage-test -- ping [管理LIFのIPアドレス] -c 3
Trident Operatorによる導入
準備が整ったので いよいよTridentの導入です。といってもここはコマンドを叩くだけなので、さらっと進みます。
- tridentのリリースを展開
tar xzf trident-installer-21.01.1.tar.gz - tridentctlコマンドをインストール sudo install -m 0755 -o root -g root ./trident-installer/tridentctl /usr/local/bin/
- tridentを導入するネームスペースの作成
kubectl create ns trident - trident operatorのインストール
helm install -n trident trident trident-installer/helm/trident-operator-21.01.1.tgz
実行すると、こんなログが出力されるかと思います。
Tridentインストールの完了待ち
tridentのoperatorがDeploymentとDaemonSetのコンテナを展開するのを待ちます。 kubectl get pod -n trident を実行して trident-csi で始まる Podが、すべてRunningになっている事を確認してください。
完全に展開が完了すると tridentctl コマンドでサーバのバージョン等を取得出来るようになります。
tridentctl version -n trident
Tridentの設定
Tridentに、制御対象のストレージにアクセスする方法を教える=バックエンド設定 を行います。
設定は色々細かく出来るので、パラメータを入れたjsonファイルを作成しますが、最小の内容だと以下のようになります。
ファイルが出来たら、backend.json として保存して tridentctlを使って設定します。
tridentctl create backend -n trident -f ./backend.json
※ ストレージが複数ある場合、複数のバックエンドを一つのTridentに登録して利用する事が可能です。
StorageClassの設定
続いてKubernetes側でユーザからの要求とTridentが持つストレージを結びつけるために必要なStorageClassを設定します。
ユーザは管理者が設定したStorageClassから自分の利用条件に合うような物を選択してリクエスト=PersistentVolumeClaimを作成する事になります。
storage-class-nas.yaml という名前で保存したら以下のコマンドを実行します。
kubectl create --save-config -f ./storage-class-nas.yaml
kubectl get storageclass を実行して確認します。
ここまでで管理者側の作業としては、ほぼ完了です。
なお、デフォルトのストレージクラスを設定しておくと、指定が無い場合に自動的にそのストレージクラスが使われる様になります。 デフォルトストレージクラスの設定はアノテーションをつける事で行えます。
kubectl patch storageclass nas -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
PersistentVolumeの利用
あとは利用するだけです。以下の様なPersistentVolumeClaimのマニフェストを作ります。
pvc.yamlという名前で保存したら kubectl create -f ./pvc.yaml を実行します。
以下の様に PersistentVolumeが作成され利用可能になります。
PersistentVolumeの利用/Helm編
これだけだと少し面白くないので、Helmを使って実際に Kubernetes上にデータベースサーバを作ってみたいと思います。
ここでは bitnamiのPostgreSQLパッケージ(Helmでは Chart と言います)を利用します。
以下の二行のコマンドを実行することで sql という名前でインストールします。
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install sql bitnami/postgresql
インストールがうまく行けば Kubernetes上に PostgreSQLが動き始めるはずなのですが、、、
Helmの処理は正常に終わったのですが、この後、待てど暮らせど実際にDBは起動してきません。なぜでしょうか?
STORAGECLASSの項目が空になっているため、PersistentVolumeが準備出来ない事がその理由です。
そこで導入の最後で紹介した、デフォルトストレージクラスを設定してみます。
kubectl patch storageclass nas -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
StorageClassを確認すると (default) という文字が追加されています。
この状態で2つ目のデータベースをインストールすると、今度は無事動き始めます。
helm install sql2 bitnami/postgresql
※ インストールした postgresql のインスタンスを削除するには helm uninstall sql等とした後に kubectl get pvc data-sql-postgresql-0 としてPVCを別途削除が必要なので注意してください。
最後に
インターネット上に公開されているHelmチャート等は、ダイナミックプロビジョニングやロードバランサの利用が可能であればすぐにも使い始める事が出来る物が多くあります。
Tridentを利用し、ダイナミックプロビジョング可能な環境を準備出来ると そういったリソースの活用もしやすくなり、より迅速にアプリケーション環境を作り上げる事が出来るのではないかと思います。
この記事の著者:大野靖夫
これまで サーバ/ストレージ ベンダで、仮想化等のインフラ系ソリューション提案を技術支援す
DevOps Hubのアカウントをフォローして
更新情報を受け取る
-
Like on Facebook
-
Like on Feedly