コンテナ事始め(3) OpenShiftにおけるPersistent Volumeについて

前回の投稿「コンテナ事始め(2) OpenShiftをインストールしてみよう」はこちらから。

こんにちは。デル・テクノロジーズでクラウド、コンテナ関連を担当している平原です。前回はIPI (Installer Provisioned Install)と呼ばれる方法でOpenShiftクラスタをデプロイするところまでを行いました。使える環境になるにはもう少し追加ステップが必要なのでこちらを紹介したいと思います。今回はPersistent Volumeについてです。

その前にコンテナの特性についておさらいです。OpenShiftにおいてアプリケーションは、OpenShiftクラスタを構成するCompute (Worker) ノードにPodという形でスケジューリングされます。Podは、OpenShift/Kubernetesで実行できるアプリケーションの最小単位です。基本的にPodは1つのコンテナから構成されますが、複数のコンテナを共存させることもできます。コンテナが詰め込まれたひとつの空間と捉えられます。アプリケーションに何か変更が加わった時、それらの差分データはコンテナ内に保持されますが、ここで注意すべきはコンテナ内のデータは揮発性 (ephemeral) ということです。従来の仮想マシンの世界では、新しいバージョンのアプリケーションを展開する際、現在動いている仮想マシンに対して変更を加える（アップグレードする）というのが一般的かと思いますが、コンテナの世界では新しいアプリケーションをパッケージしたコンテナイメージを再デプロイする形になります。下記の図で説明すると新しいバージョンをPod4としてデプロイした後、これまで動いていたPod1を停止、破棄（削除）するという流れを取ります。しかしこのままではPod1を削除したタイミングでPod1のコンテナ内に保持されている揮発性データは失われることになります。これではよろしくないので、ここでPod1の外部にデータを永続化する必要が出てくる訳です。

データ永続化にはいくつかの方法があります。OpenShift/KubernetesのノードはLinuxベースですから、ノード内のホストファイルシステムをマウントすることでデータを永続化する方法が取れます。こうすれば、新しいバージョンのPod4に永続データが置かれているホストファイルシステムを再マウントすることでデータはアクセス可能となります。

ただ、この方法だと課題もあります。OpenShift/Kubernetesクラスタは複数のComputeノードを持っており、Podスケジューリングは各ノードの利用状況を考慮して動的に行われます。すなわち、この図にあるWorker #1にPod4が配置される限りは永続データのアクセスは可能ですが、Worker #2に配置されてしまうとWorker #1のホストファイルシステムにはアクセスできない事態が発生します。このためクラスタワイドでデータアクセスを可能にするための方法として共有ストレージを使う必要が出てきます。共有ストレージとしてはSANベースのブロックボリューム、NFSファイル共有、VMFSデータストアなどが利用でき、そのために当社を含む各社ストレージベンダーからはOpenShift/Kubernetesと自社ストレージとの間のインターフェースとなるCSI (Container Storage Interface) ドライバがリリースされています。

Dell Technologies CSI driver web page

https://dell.github.io/csm-docs/docs/csidriver/

では、本題に戻りましょう。今回は自宅のvSphere環境なのでVMFSデータストアを使ったPersistent Volumeの動きを見ていきたいと思います。

実はvSphere上にOpenShiftをデプロイした場合、Persistent Volumeを利用可能にするCSIドライバは既に導入済みとなっています。環境を確認してみましょう。

CLIを使ってクラスタ管理者でOpenShiftにログイン（前回の記事を参照ください）
oc get csidrivers.storage.k8s.io コマンドで導入済みのCSIドライバを確認
csi.vsphere.vmware.comが表示されます
oc get sc コマンドでStorageClassを確認
標準でthin-csiという名前のStorageClassが作成されています

ここでStorageClassという聞き慣れない言葉が出てきました。StorageClassはバックエンドにあるストレージを抽象化する概念であり、このStorageClassを通してデータベース要件ならPowerStore、大規模な分析データ保管要件ならPowerScaleのような使い分けを可能にします。物理インフラに馴染みの薄い開発者にとってはどんな種類のストレージがあるのかだけをStorageClassで認識しておけば、最適なPersistent Volumeを要求することが可能になるという訳です。ここでは既にVMFSデータストアにThin ProvisioningのPersistent Volumeを作るStorageClassが存在するので、Thick Provisioning用のStorageClassを作成してみましょう。

vCenterからPersistent Volumeを作成するデータストアにタグ付けをします。ここでは「ocp-thick」というタグ、タグ作成過程で新規カテゴリ「ocp-thick-storage-policy」を作成し、VMFSデータストアにタグ付けします
続けてvCenterから仮想マシンストレージポリシーを作成します。今回は「ocp-pv-thick」というポリシーを作成します。このポリシー名は後のStorageClass作成時に必要になります
ポリシー構造で「VMFSストレージでルールを有効化」「タグベースの配置をルールを有効化」にチェックを入れます
VMFSルールでボリューム割り当てタイプに「完全に初期化されました」を選択します
タグベースの配置でタグカテゴリ「ocp-thick-storage-policy」を選択し、続けてタグを参照で「ocp-thick」を選択します
OpenShiftのWebコンソールにkubeadminでログインし、AdministoratorパースペクティブでStorage-StorageClassesを選択します。画面右上の「Create StorageClass」ボタンをクリックします
StorageClass名に「thick-test」, Reclaim Policyに「Delete」, Volume binding modeに「Immediate」, CSI Provisionerに「csi.vsphere.vmware.com」を設定します
Provisionerを選択するとAdditional Parameterの項目が表示されるので、vCenterで作成した仮想マシンストレージポリシーを設定します。Parameterは「StoragePolicyName」, Valueは「ocp-pv-thick」
パラメータを確認し「Create」ボタンをクリックします

ここまででStorageClassの作成が完了したので、実際にPersistent Volumeを作成してみます。OpenShift上のPodで利用可能なPersistent Volumeを作成するにはPersistent Volume Claim (PVC) という操作が必要です

OpenShiftのWebコンソールの、AdministoratorパースペクティブでStorage-PersitentVolumeClaimを選択します。画面右上の「Create PersitentVolumeClaim」ボタンをクリックします
StrorageClassに作成済みの「thick-test」, 任意のPersisitent Volume Claim名, Access modeは「RWO」, 任意の容量, Volume modeは「Filesystem」を指定し、「Create」ボタンをクリックします
Statusが「Bound」になれば、Persistent Volume Claimの作成完了です
vCenter側でもデータストアをブラウズして確認します。データストア内のfcdフォルダに指定した容量のVMDKが作成されていることが確認できます。これは仮想マシンに紐づかない特殊なVMDKであるFCD (First Class Disk) として作成されています。Thick Privisioningなので15GiBアロケートされているのも確認できました

今回はPersitent Volume単体の作成でしたが、実際にはPodデプロイ時にPVCの記述をマニフェスト (YAMLファイル) に行っておくことで、Podデプロイと同時に開発者が自分のタイミングで希望するストレージを割り当てることが可能になります。コンテナの特性とOpenShift/Kubernetesの永続ストレージ管理があることで、開発者はITチームに都度作業依頼をすることなく自身のペースでアプリケーション開発を進める、まさに（広義な意味での）DevOpsの推進が可能になるのです。

今回はvSphereのストレージを使ったPersistent Volumeの解説でしたが、社内の環境調整が取れれば別の機会にデルストレージとの連携も解説できればと思います。

次回はOpenShift上でのアプリケーション開発に必要なもう一つの機能であるレジストリについて解説します。次回の作業まで行えば、とりあえずはソースコードからOpenShift上にコンテナイメージをビルドし、簡単なアプリケーションが展開できるようになります。

すべて表示

イベントは見つかりませんでした！

ストレージ Wiki

コンテナ事始め(3) OpenShiftにおけるPersistent Volumeについて