はじめに
Red Hat OpenShift on IBM Cloud（ROKS/RHOIC）のワーカーノードは、コンテナ実行の基盤として重要な役割を担います。その中でもディスクは、OSやコンテナイメージ、ログなどを保持するために不可欠です。今回はIBM Cloud Docsの記述からは読み取りにくいディスクの構成についてまとめていきます。
ROKSのワーカーノードはクラスターが稼働するインフラストラクチャー、ワーカーノードOSの種類やバージョンにより、若干構成が異なります。今回は最も一般的なVirtual Private Cloud上で稼働するクラスターにおいて、ワーカーノードは仮想サーバーとなっている最も標準的な構成を対象に説明します。また、ワーカーノードOSはRed Hat Enterprise Linux Core OS (RHCOS)を選択しましたが、Red Hat Enterprise Linux 9.x (RHEL9)を選択した場合も同様の構成です。
1. 標準的なノードのディスク構成
ROKSではワーカーノードを選択する際に主にCPU、メモリ、ディスク量の組み合わせ、GPUの有無、ワーカーノードで利用するOSの種類とバージョンなどを選択します。(図1参照)
ディスクについては多少の自由度があり、簡単にまとめます。
- 現在ROKSで利用できるワーカーノードには 100GB の1次ディスクが設定されています。この1次ディスクはBlock Storage for VPCサービスを使って実装されています。どの種類のフレーバーを選択した場合も必ず1次ディスクは必ず存在します。サイズやIOPS値などを変更することはできません
- 第3世代のワーカーノード(
bx3d.4x20やcx3d.8x20などフレーバーのIDの2文字目および3文字目がx3となっているもの)は、フレーバーのサイズに応じたインスタンス・ストレージを持ちます。他のフレーバーではインスタンス・ストレージは存在しません - 各ワーカーノードにはオプションで 2次ディスクを設定することが可能です。この2次ディスクはBlock Storage for VPCサービスを使って実装されており、永続的なストレージとして利用することができます。あらかじめ定義されているサイズ、速度(IOPS)を選択します。(下図参照)
具体的にいくつかのノードにおけるディスクの構成とマウントポイントの設定を見ていきましょう。
注)以下の図表内の価格は2025年12月時点での東京リージョンの価格です。最新の情報はご自身の環境でその都度ご確認ください。
図1. ワーカーノード・フレーバーの選択
図2. 2次ディスク・スペックの選択
2. 標準的なノードの構成の詳細
ROKSのクラスターに以下に挙げるケース1からケース4の4つの種類のワーカーノードをプロビジョニングして、ブロックデバイスとマウントポイントの構成を見ていきます。リソース量の小さいワーカーノードについて調べていますが、大きなワーカーノードも同様の構成です。
また、もう少し整理して表記すべき内容だと思いますが、コマンドの実行結果については加工せずそのまま掲載します。
ケース1 bx2.4x16 (1次ディスク 100GB)
sh-5.1# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 100G 0 disk
|-vda1
| 252:1 0 1M 0 part
|-vda2
| 252:2 0 127M 0 part
|-vda3
| 252:3 0 384M 0 part /boot
`-vda4
252:4 0 99.5G 0 part /var/data/criorootstorage/overlay/099ce08b9137699f4abda2a1a01feba75c2f9397eb119c84cc3190208d1c6185/merged/run/.containerenv
/var/data/criorootstorage/overlay/099ce08b9137699f4abda2a1a01feba75c2f9397eb119c84cc3190208d1c6185/merged/etc/hostname
/var/data/criorootstorage/overlay/099ce08b9137699f4abda2a1a01feba75c2f9397eb119c84cc3190208d1c6185/merged/etc/resolv.conf
/var/data/kubelet/pods/78b4df9a-c05d-44c0-aac4-9234414d0c57/volume-subpaths/nginx-conf/networking-console-plugin/1
/var/data/kubelet/pods/87385c7c-6d17-4b51-a634-d40fdd49f303/volume-subpaths/tigera-ca-bundle/calico-kube-controllers/1
/var/data/kubelet/pods/d201e517-48e8-4c8b-923c-fea364b1dc89/volume-subpaths/tigera-ca-bundle/calico-typha/1
/var/data/kubelet/pods/3443f50d-256e-4802-8e63-604afb40d437/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet/pods/78b4df9a-c05d-44c0-aac4-9234414d0c57/volume-subpaths/nginx-conf/networking-console-plugin/1
/var/lib/kubelet/pods/87385c7c-6d17-4b51-a634-d40fdd49f303/volume-subpaths/tigera-ca-bundle/calico-kube-controllers/1
/var/lib/kubelet/pods/d201e517-48e8-4c8b-923c-fea364b1dc89/volume-subpaths/tigera-ca-bundle/calico-typha/1
/var/lib/kubelet/pods/3443f50d-256e-4802-8e63-604afb40d437/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet
/var/log/pods
/var
/sysroot/ostree/deploy/rhcos/var
/sysroot
/usr
/etc
/
vdb 252:16 0 374K 0 disk
vdc 252:32 0 44K 0 disk
boot関連を除くすべてのデータが vda/vda4 (1次ディスク) に配置されています。
ケース2 bx2.4x16 (1次ディスク 100GB + 2次ディスク 300GB)
sh-5.1# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 100G 0 disk
|-vda1
| 252:1 0 1M 0 part
|-vda2
| 252:2 0 127M 0 part
|-vda3
| 252:3 0 384M 0 part /boot
`-vda4
252:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/rhcos/var
/sysroot
/usr
/etc
/
vdb 252:16 0 300G 0 disk /var/lib/kubelet/pods/12d82093-cde2-4914-8fe6-5d0b6f470d4d/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet
/var/log/pods
/var/data/criorootstorage/overlay/e0e232c534f1c8868f2685904eef06c6eb2657b0f0c165716f00e6e95920768a/merged/run/.containerenv
/var/data/criorootstorage/overlay/e0e232c534f1c8868f2685904eef06c6eb2657b0f0c165716f00e6e95920768a/merged/etc/hostname
/var/data/criorootstorage/overlay/e0e232c534f1c8868f2685904eef06c6eb2657b0f0c165716f00e6e95920768a/merged/etc/resolv.conf
/var/data/kubelet/pods/12d82093-cde2-4914-8fe6-5d0b6f470d4d/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/data
vdc 252:32 0 374K 0 disk
vdd 252:48 0 44K 0 disk
コンテナの稼働に関わるデータ /var/lib/kubelet /var/data/kubelet/pods/* /var/data/criorootstorage/*、ログ /var/log/pods、可変データ /var/data が vdb の 2次ディスク に配置されています。今回の調査では300GBの容量を指定して2次ディスクを作成しましたが、あらかじめ決められた範囲でもっと大きな容量とすることも可能です。
ケース3 bx3d.4x20 (1次ディスク 100GB + インスタンス・ストレージ 130GB)
sh-5.1# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 100G 0 disk
|-vda1
| 252:1 0 1M 0 part
|-vda2
| 252:2 0 127M 0 part
|-vda3
| 252:3 0 384M 0 part /boot
`-vda4
252:4 0 99.5G 0 part /var/data/criorootstorage/overlay/12bcd0a1b2d6da2791f497475bfaa4bd2a4193b6606e14355456eb2021d7ca89/merged/run/.containerenv
/var/data/criorootstorage/overlay/12bcd0a1b2d6da2791f497475bfaa4bd2a4193b6606e14355456eb2021d7ca89/merged/etc/hostname
/var/data/criorootstorage/overlay/12bcd0a1b2d6da2791f497475bfaa4bd2a4193b6606e14355456eb2021d7ca89/merged/etc/resolv.conf
/var/data/kubelet/pods/bb6a08d6-608b-4fb6-9f27-89acd8100486/volume-subpaths/tigera-ca-bundle/calico-typha/1
/var/data/kubelet/pods/433eb56f-493a-4c0c-992b-64e29a2562f1/volume-subpaths/nginx-conf/networking-console-plugin/1
/var/data/kubelet/pods/d42a791d-bc1f-4ee6-93b3-339e90440e39/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet/pods/bb6a08d6-608b-4fb6-9f27-89acd8100486/volume-subpaths/tigera-ca-bundle/calico-typha/1
/var/lib/kubelet/pods/433eb56f-493a-4c0c-992b-64e29a2562f1/volume-subpaths/nginx-conf/networking-console-plugin/1
/var/lib/kubelet/pods/d42a791d-bc1f-4ee6-93b3-339e90440e39/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet
/var/log/pods
/var
/sysroot/ostree/deploy/rhcos/var
/sysroot
/usr
/etc
/
vdb 252:16 0 121.1G 0 disk
vdc 252:32 0 374K 0 disk
vdd 252:48 0 44K 0 disk
boot関連を除くすべてのデータが vda/vda4 (1次ディスク) に配置されています。
vdb の2次ディスクは使用されていません。
ケース4 bx3d.4x20 (1次ディスク 100GB + インスタンス・ストレージ 130GB + 2次ディスク 300GB)
sh-5.1# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 100G 0 disk
|-vda1
| 252:1 0 1M 0 part
|-vda2
| 252:2 0 127M 0 part
|-vda3
| 252:3 0 384M 0 part /boot
`-vda4
252:4 0 99.5G 0 part /var
/sysroot/ostree/deploy/rhcos/var
/sysroot
/usr
/etc
/
vdb 252:16 0 121.1G 0 disk
vdc 252:32 0 300G 0 disk /var/lib/kubelet/pods/6f5e6562-0746-46e1-a596-8afe140617b1/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/lib/kubelet
/var/log/pods
/var/data/criorootstorage/overlay/923bba0f9c199171c174da249cf84a9780e91a8c8989576a6f932d9a17ccaf92/merged/run/.containerenv
/var/data/criorootstorage/overlay/923bba0f9c199171c174da249cf84a9780e91a8c8989576a6f932d9a17ccaf92/merged/etc/hostname
/var/data/criorootstorage/overlay/923bba0f9c199171c174da249cf84a9780e91a8c8989576a6f932d9a17ccaf92/merged/etc/resolv.conf
/var/data/kubelet/pods/6f5e6562-0746-46e1-a596-8afe140617b1/volume-subpaths/tigera-ca-bundle/calico-node/1
/var/data
vdd 252:48 0 374K 0 disk
vde 252:64 0 44K 0 disk
ケース2と同じくコンテナの稼働に関わるデータ /var/lib/kubelet /var/data/kubelet/pods/* /var/data/criorootstorage/*、ログ /var/log/pods、可変データ /var/data が vdc の 2次ディスク に配置されています。
ケース3と同じく vdb の2次ディスクは使用されていません。
これらをまとめると4種類の構成情報から、以下のことが言えます。
- 2次ディスクはあらかじめマウントされている。
- コンテナイメージのキャッシュ、コンテナ内部のファイルシステム、ログの出力先などの用途で使用されている。
- インスタンス・ストレージはマウントされていない。
3. インスタンス・ストレージの使い道
ここで改めてストレージの揮発性の有無をベースにストレージの主な特徴を整理します。
揮発性のあるストレージ：
- ワーカーノードのローカルディスク
- ノード消失時にデータも消える。
- EmptyDirやコンテナキャッシュなど重要度の低いデータを保存で利用可能
永続ストレージ（揮発性なし）：
- Block Storage for VPC や Object Storage などのリモートディスク
- ノードが消失してもデータは保持される
- データベースやストレージクラスターのデータを保存で利用可能
各ワーカーノードにおいて標準で構成されている状態からマウントポイントを変更することは可能ですが、再起動やノードの置換時などに設定が失われていまいます。一般的なOpenShiftにおいて、バージョン4.13以降では MachineConfig を使って起動時にマウントする方法があるのですが、ROKS では MachineConfig をサポートしていないので、起動時に自動的にマウントするような方式を利用することはできないので、このあたりはサービス側の今後の機能強化を期待します。
ROKSでは揮発性のあるストレージは基本的には使われていませんが、前章のケース3, ケース4で説明した通り、インスタンス・ストレージを持っているワーカーノードではそれをマウントしていない状態でプロビジョニングされています。それを利用することも可能で揮発性のあるストレージなので、無くなっても構わないデータに利用することが推奨されます。アプリケーション/Podが一時ファイルなどを保存する際に利用するのが望ましいでしょう。
一点注意が必要です。OpenShift Data Foundation(ODF) などストレージクラスターを稼働させる際には永続的なストレージを必要とします。インスタンスストレージをそのデータ領域として使用することがないように注意する必要があります。たとえばROKSで提供されているODFのプラグイン導入時にはディスクのディスカバリー機能を使い未フォーマットのディスクを検索しますが、その際にインスタンス・ストレージが条件にあうディスクとして認識されてしまうので、使い方を誤るとODFのデータ領域が揮発性のあるディスクに作成されています。これは利用者側で注意して避けたい状況ですね。インスタンス・ストレージに対し、ODFを構成する前にマウントしてしまえば、誤ってODFのディスク領域として利用されることはなくなります。
4. まとめ
ROKSのワーカーノードのストレージは永続的なストレージを使用するように構成されています。一方でインスタンス・ストレージを備えたフレーバーも存在します。アプリケーションの一時ファイルなどは、どの領域を利用するかを意識して、所望のディスクにデータを保存するよう設計する必要があります。