1. はじめに
既存の OpenShift Cluster の中に3本のWorkerノードを使ったOCS(OpenShift Container Storage)のClusterを作成してみます。
OCSのデータ領域は、各Storage Nodeに追加した内蔵ディスクを使用する事にします。
この手順は、OCS(OpenShift Container Storage) 4.5 を元に作成しています。また、公式ドキュメントの ベアメタルインフラストラクチャーを使用した OPENSHIFT CONTAINER STORAGE のデプロイを参考にしました。
この手順で使用したOCSのバージョンは、4.5です。
2. OCSノードのサイジング
OCSのデプロイ方法は、インターナルとエクスターナルがありますが、ここではインターナルモードを使用します。
インターナルとエクスターナルの違いは、既存のOpenShiftクラスターの内部にOCSがあるか外部に独立したクラスターとして存在するかの差です。
インターナルモードでは、OCSのストレージを持ったノードも、既存OpenShiftクラスター内のWorkerノードとして存在しています。
コンピュートもストレージも、OpenShift単一クラスター内のリソースとして扱う事ができ、シンプルな構成になります。
使用する ノードの OSは、Red Hat CoreOSを使用します。
OCSには、最小要件として以下の要件があります。
- 30vCPU(10vCPUx3)
- 72GB(24GB x 3) Memory
- 3(1 x 3) storage device
※ここでの vCPUは、Intel HyperThreading ON 時の仮想コアを示しています。
ですが、このリソースで実際に構成してみると、メモリが足りず、一部のPodが起動しない現象が見て取れたので(細かく確認してませんが、他のPodがOCS用のノードに乱入してきたせいかもしれません) 、もう少し増やして、以下の構成にしました。
- 48vCPU(16vCPUx3)
- 96GB(32GB x 3) Memory
- 3(1 x 3) storage device
さらに言うと、インストールの途中のUser Interfaceで、16CPU 64GB以上のノードを3本用意するように言ってくる部分があります。
が今回は、そこまで富豪な構成は用意できなかったので、メモリに関しては64GB→32GBとしています。
各、ノードに、OSを導入するストレージ領域に追加して、データー領域として１TBの容量を追加しました。
各ノード構成は以下の通りです。
| サーバー | vCPU(HT-on) | Memory | OS Disk | 追加Disk | OS | ホスト名 | IP Address |
|---|---|---|---|---|---|---|---|
| OCSノード 1 | 16vCPU | 32GByte | 60G | 1024G | CoreOS | s1.ocp45.example.localdomain | 172.16.0.51 |
| OCSノード 2 | 16vCPU | 32GByte | 60G | 1024G | CoreOS | s2.ocp45.example.localdomain | 172.16.0.52 |
| OCSノード 3 | 16vCPU | 32GByte | 60G | 1024G | CoreOS | s3.ocp45.example.localdomain | 172.16.0.53 |
Workerノード に、OCSの必要なコンテナを導入したノードをOCSノードと呼ぶ事にします。
この3本のOCSノードがOCSとして分散ストレージを形成します。
OCSでは、最低3本の Workerノードが基本単位として必要になります。ストレージの容量を追加する場合も3本づつWorkerノードを追加していきます。
3. OCSノードのインストール
それでは、OCSノードを作成して行きます。
3.1. VMware を OCSノードに使用する場合の注意点
この手順では、ノードに追加した内蔵ディスクをOCSのデータ領域として構成します。
VMware の仮想マシンを OCSノード に使用する場合「仮想マシンオプション」で、disk.EnableUUID を true にしないと、構成に必要なディスクの by-idが表示されない場合があるようです。
3.2.Workerノードの作成
通常の Workerノード と同様に以下の手順になります。
1.ホスト名とIPアドレスの決定
2.DHCPサーバーに、MACアドレスに結びつけて固定IPを配れるように設定
3.DNSサーバーにOCSノードとして使用するWoker Nodeのホスト名を登録(逆引きも)
4.CoreOSをインストール開始。Workerノードの Inginiton fileを使って Workerノードとして構成
5.Woker NodeのCSRをapprove
Core OSのインストール方法については、ISOイメージからインストールする方法と、iPXE等を使ったネットワークインストールする方法があります。いずれのケースでOpenShiftのWoker Nodeとして構成する必要があります。
通常OCSをインターナルモードで導入する場合は、既にOpenShiftクラスターが存在しており、Workerノードの導入手順は確立していると思いますので、ここでは、CoreOSをインストール・構成してWoker Nodeとして OpenShiftクラスターに追加する方法については省略します。
3.3.OCSインストール対象Nodeのラベリング
Workerノードが完成したら、完成した 3つの Workerノードに以下のコマンドで、ラベルをつけOCSノード化をして行きます。
インストール時に、このラベルがある所に、必要なPodがスケジュールされるようになっています。
oc label nodes <NodeNames> cluster.ocs.openshift.io/openshift-storage=''
この手順では、以下のようにコマンドを実行してラベルをつけます。
oc label nodes s1.ocp45.example.localdomain cluster.ocs.openshift.io/openshift-storage=''
oc label nodes s2.ocp45.example.localdomain cluster.ocs.openshift.io/openshift-storage=''
oc label nodes s3.ocp45.example.localdomain cluster.ocs.openshift.io/openshift-storage=''
ラベルが付いている事を確認します。
# oc get nodes -l cluster.ocs.openshift.io/openshift-storage -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}'
s1.ocp45.example.localdomain
s2.ocp45.example.localdomain
s3.ocp45.example.localdomain
#
以上で、OCSをインストールするOCSノードの準備ができました。
4. OCS Operator のインストール
OperatorHubからOpenShift Container Storageを検索してクリックします。
Installをクリックします。
Install Operatorで必要な項目を入力します。
Enable operator recommended cluster monitoring on this namespace だけは、デフォルトでチェックが入ってないはずなので、チェックします。それ以外はデフォルトのままで大丈夫なはずですが、
Update Channel は、stable-4.5
Installation Mode は、A specific namespace on the cluster
Installed Namespace は、openshift-storage
Approval Strategy は、Automatic (※)
である事を確認します。
※この例ではApproval Strategy は、Automaticを選択しましたが、アップデート時はOCSクラスターが非常に不安定になります。実際の運用を考えるとこの部分は、個人的にはManualにしておき、意図せぬアップデートが起こらないようにしておくのが良いと思います。
確認したらIsntallをクリックします。
Installed Operatorsに自動で画面が遷移するはずです。
環境にも依存しますがOpenShift Container StorageがSuccceededになるまで数分かかるはずです。
5.Local Storage Operator のインストール
続いてLocal Storage Operatorを導入します。
5.1. namespace の作成
OPERATORのインストール前の準備としてlocal-storageというnamespaceを作成します。
Administration->Namespaces に移動して、Create Namespaceをクリックします。
新しく作成する Namespace名として local-storageと入力します。Default Network Policyは、デフォルトでNo restrictionsが選択されていればOKです。
OperatorHubから、Local Storageを検索します。
Installをクリックします。
Install Operatorという画面に遷移します。
Installed Namespaceで、先ほど作成したlcoal-storageというNamespaceが選択されているのを確認します。
それ以外は、基本的にデフォルトで設定されているはずですが、
Update Channelが、4.5
Installation Modeが、A specific namespace on the cluster
Approval Stragegyが、Automatic (※)
である事を確認します。大丈夫であれば、Installをクリックします。
※この例ではApproval Strategy は、Automaticを選択しましたが、アップデート時はOCSクラスターが非常に不安定になります。実際の運用を考えるとこの部分は、個人的にはManualにしておき、意図せぬアップデートが起こらないようにしておくのが良いと思います。
Operators->Installed Operatorsに自動で画面が遷移するはずです。
Local Storageが、Succeededになれば完了です。すぐにSucceededになるはずです。
5.2. LocalVoume の作成
5.2.1. 利用可能なデバイスの検索
各OCSノードから、データ領域に使用するデバイスの情報を集めて行きます。
まず、s1.ocp45.example.localdomain に対して、oc debug node/<OCSノード名>でログインして情報を集めます。
# oc debug node/s1.ocp45.example.localdomain
Starting pod/s1ocp45examplelocaldomain-debug ...
To use host binaries, run `chroot /host`
Pod IP: 172.16.0.51
If you don't see a command prompt, try pressing enter.
sh-4.2# chroot /host <== 入力
sh-4.4# lsblk <== 入力
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 60G 0 disk
|-sda1 8:1 0 384M 0 part /boot
|-sda2 8:2 0 127M 0 part /boot/efi
|-sda3 8:3 0 1M 0 part
`-sda4 8:4 0 59.5G 0 part
`-coreos-luks-root-nocrypt 253:0 0 59.5G 0 dm /sysroot
sdb 8:16 0 1T 0 disk
sr0 11:0 1 1024M 0 rom
上記の例でsdbが、データ領域用に追加したdiskです。このdiskのby-idを調べます。
※1) VMWareの場合は、同じデバイスに対して複数のby-idが表示される事があるようですが、以下のサンプルのフォーマットと同じものをメモして下さい
※2) 記事公開後、by-id の簡単な集め方として、kubectl logsを使用する方法を教えて頂きました！以下のKBが出ています。How to list the local disk IDs for every OCS worker in Openshift 4.x
sh-4.4# ls -l /dev/disk/by-id/ | grep sdb
lrwxrwxrwx. 1 root root 9 Oct 22 15:47 scsi-36000c290ef83f5ddee94f3e43dcb6197 -> ../../sdb
同様の作業を残り２本のOCSノードに対しても行います。
s2.ocp45.example.localdomain に対して同様の確認を行います。
sh-4.4# ls -l /dev/disk/by-id/ | grep sdb
lrwxrwxrwx. 1 root root 9 Oct 22 15:57 scsi-36000c29af3872df29dc0cf11fc1b0e08 -> ../../sdb
sh-4.4#
s3.ocp45.example.localdomain に対して同様の確認を行います。
sh-4.4# ls -l /dev/disk/by-id/ | grep sdb
lrwxrwxrwx. 1 root root 9 Oct 22 15:57 scsi-36000c294793b7f8acdd6584ff588cecc -> ../../sdb
sh-4.4#
以上でそれぞれのOCSノードの diskのby-idがわかりました。
次のステップで使用するのでパスを含めて以下のように整形してメモしておきます。
/dev/disk/by-id/scsi-36000c290ef83f5ddee94f3e43dcb6197 # OCSノード 1
/dev/disk/by-id/scsi-36000c29af3872df29dc0cf11fc1b0e08 # OCSノード 2
/dev/disk/by-id/scsi-36000c294793b7f8acdd6584ff588cecc # OCSノード 3
次のステップでは、集めた情報を使ってyamlファイルを作成します。
5.2.2. Custom Resource (LocalVolume) の作成
前のステップで集めたdiskの情報を使ってOCSのCR(Custom Resource)を作成します。
local-storage-block.yamlという名前の以下のファイルを作成します。
apiVersion: local.storage.openshift.io/v1
kind: LocalVolume
metadata:
name: local-block
namespace: local-storage
labels:
app: ocs-storagecluster
spec:
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: cluster.ocs.openshift.io/openshift-storage
operator: In
values:
- ""
storageClassDevices:
- storageClassName: localblock
volumeMode: Block
devicePaths:
- /dev/disk/by-id/scsi-36000c290ef83f5ddee94f3e43dcb6197 # OCSノード 1
- /dev/disk/by-id/scsi-36000c29af3872df29dc0cf11fc1b0e08 # OCSノード 2
- /dev/disk/by-id/scsi-36000c294793b7f8acdd6584ff588cecc # OCSノード 3
tolerations:
- effect: NoSchedule
key: node.ocs.openshift.io/storage
value: "true"
作成したファイルをapplyします。
oc create -f local-storage-block.yaml
Podが作成されているか確認します。
# oc get pod -n local-storage
NAME READY STATUS RESTARTS AGE
local-block-local-diskmaker-mv5xb 1/1 Running 0 50s
local-block-local-diskmaker-nkfdw 1/1 Running 0 50s
local-block-local-diskmaker-r8gg2 1/1 Running 0 50s
local-block-local-provisioner-542k6 1/1 Running 0 50s
local-block-local-provisioner-cxhcl 1/1 Running 0 50s
local-block-local-provisioner-pnlhb 1/1 Running 0 50s
local-storage-operator-588b4686c6-2kllz 1/1 Running 0 126m
#
PV(Persistent Volume)の作成を確認します。
# oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
local-pv-73dc6977 1Ti RWO Delete Available localblock 51s
local-pv-a3a35d00 1Ti RWO Delete Available localblock 40s
local-pv-b7abec06 1Ti RWO Delete Available localblock 40s
#
locakblockというStorage Classの生成を確認します。
[root@bastion openshift]# oc get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localblock kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 63s
[root@bastion openshift]#
5.3.Cluster Serviceの作成
OpenShiftコンソールに移動し、Installed Operatorsで、Projectで、openshift-storageを選択します。
OpenShift Constainer Storageをクリックします。
Create OCS Cluster Serviceをクリックします。
Create Storage Clusterの設定画面に遷移します。
Select Modeは、Internalが選択されている事を確認します。
Nodesの項目では、OCSノードとして作成した3本のノードが選択されている事を確認します。
Storage Classは、localblockを選択します。
確認ができたらCreateをクリックします。
6. OCS 作成の確認
6.1.Podの起動確認
oc get pod -n openshift-storage で、Pod が RunningかCompletedになるのを確認します。
[root@bastion openshift]# oc get pod -n openshift-storage
NAME READY STATUS RESTARTS AGE
csi-cephfsplugin-7w52w 3/3 Running 0 7m26s
csi-cephfsplugin-b2lcg 3/3 Running 0 7m26s
csi-cephfsplugin-bq8s6 3/3 Running 0 7m26s
csi-cephfsplugin-n68pn 3/3 Running 0 7m26s
csi-cephfsplugin-provisioner-55d77c5b99-knr7h 5/5 Running 0 7m25s
csi-cephfsplugin-provisioner-55d77c5b99-szs29 5/5 Running 0 7m25s
csi-cephfsplugin-qfwhn 3/3 Running 0 7m26s
csi-cephfsplugin-rb6tr 3/3 Running 0 7m26s
csi-rbdplugin-69rll 3/3 Running 0 7m27s
csi-rbdplugin-fcvnb 3/3 Running 0 7m27s
csi-rbdplugin-ffbb7 3/3 Running 0 7m27s
csi-rbdplugin-kjcnq 3/3 Running 0 7m27s
csi-rbdplugin-provisioner-86d4877dd5-f8sl9 5/5 Running 0 7m26s
csi-rbdplugin-provisioner-86d4877dd5-pld7c 5/5 Running 0 7m26s
csi-rbdplugin-r5z7n 3/3 Running 0 7m27s
csi-rbdplugin-xslrh 3/3 Running 0 7m27s
noobaa-core-0 1/1 Running 0 3m34s
noobaa-db-0 1/1 Running 0 3m34s
noobaa-endpoint-65dcff66c5-dlnpf 1/1 Running 0 54s
noobaa-operator-54fd4c8b7b-269bn 1/1 Running 0 33m
ocs-operator-84bdd64c68-g2tqf 0/1 Running 0 33m
rook-ceph-crashcollector-s1.ocp45.example.localdomain-7f976xj2z 1/1 Running 0 6m51s
rook-ceph-crashcollector-s2.ocp45.example.localdomain-75b4vr5hp 1/1 Running 0 6m42s
rook-ceph-crashcollector-s3.ocp45.example.localdomain-57c82x9gk 1/1 Running 0 4m20s
rook-ceph-drain-canary-s1.ocp45.example.localdomain-67b469hmxcr 1/1 Running 0 3m37s
rook-ceph-drain-canary-s2.ocp45.example.localdomain-65f8bbhh8z9 1/1 Running 0 3m38s
rook-ceph-drain-canary-s3.ocp45.example.localdomain-cdd8b5kxrj2 1/1 Running 0 3m36s
rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-5d48864cj72pg 1/1 Running 0 3m20s
rook-ceph-mds-ocs-storagecluster-cephfilesystem-b-6897d49fkfr72 1/1 Running 0 3m19s
rook-ceph-mgr-a-5f558b7854-zxx6w 1/1 Running 0 3m53s
rook-ceph-mon-a-74584cb98-g64dd 1/1 Running 0 6m51s
rook-ceph-mon-b-67c75d95f5-msm98 1/1 Running 0 6m42s
rook-ceph-mon-c-686b895696-pjxfb 1/1 Running 0 4m20s
rook-ceph-operator-75598ffcd9-hxb6b 1/1 Running 0 33m
rook-ceph-osd-0-54f7bccc4f-4fdzr 1/1 Running 0 3m38s
rook-ceph-osd-1-6f8b5c7477-bhwcm 1/1 Running 0 3m37s
rook-ceph-osd-2-7fbffd4fc9-5wbgh 1/1 Running 0 3m36s
rook-ceph-osd-prepare-ocs-deviceset-0-data-0-dz69c-wws8c 0/1 Completed 0 3m49s
rook-ceph-osd-prepare-ocs-deviceset-1-data-0-5jtvr-tlxq4 0/1 Completed 0 3m48s
rook-ceph-osd-prepare-ocs-deviceset-2-data-0-ghnsr-dp7nk 0/1 Completed 0 3m47s
rook-ceph-rgw-ocs-storagecluster-cephobjectstore-a-568854f4fvgq 1/1 Running 0 2m48s
rook-ceph-rgw-ocs-storagecluster-cephobjectstore-b-5479655np5w7 1/1 Running 0 2m46s
[root@bastion openshift]# oc get pod -n openshift-storage | grep -v NAME | wc -l
42
[root@bastion openshift]#
上記の環境では、約8分くらいで全てのPodが起動しました。
csi plugin は、この時点でMasterノード以外の全ノードに配られるので Node数によって出力行数は変わります。上記の環境は (Workerノード x 6, OCSノード x 3) の環境なので、csi-cephfsplugin-xxxx と csi-rbdplugin-xxxx が6個づつ存在しています
各Podの役割については、マニュアルに記載があるので、必要な数が起動してきているか確認します。
特に以下の部分は、比較的後から表示されます。
rook-ceph-osd-xxxxx
rook-ceph-osd-xxxxx
rook-ceph-osd-xxxxx
また、以下のPodは、0/1が最終的に1/1になります。
ocs-operator-84bdd64c68-g2tqf 0/1 Running 0 33m
6.2.OCS Clusterのステータスの確認
OpenShiftコンソールより、OCS Clusterの状態を確認します。
Home->OvervirewからPersistent Storageを選びます。
Detailsに内容が表示されていて、Statusもグリーンになっている事を確認します。
6.3.Multicloud Object Gatewayの正常性の確認
OpenShiftコンソールより、Multicloud Object Gatewayの状態を確認します。
Home->OvervirewからObject Serviceを選びます。
Detailsに内容が表示されていて、Statusもグリーンになっている事を確認します。
6.4.OCS の Storage Class の確認
4つのStorage Classが作成されているはずなので、確認します。
ocs-storagecluster-ceph-rbd
ocs-storagecluster-cephfs
openshift-storage.noobaa.io
ocs-storagecluster-ceph-rgw
が作成されている事を確認します。
Storage->Storage Classesから確認できます。
CLIでも確認できます。その場合は、oc get storageclasses を実行します。
[root@bastion ~]# oc get storageclasses
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
localblock kubernetes.io/no-provisioner Delete WaitForFirstConsumer false 2d10h
ocs-storagecluster-ceph-rbd openshift-storage.rbd.csi.ceph.com Delete Immediate true 2d10h
ocs-storagecluster-ceph-rgw openshift-storage.ceph.rook.io/bucket Delete Immediate false 2d10h
ocs-storagecluster-cephfs openshift-storage.cephfs.csi.ceph.com Delete Immediate true 2d10h
openshift-storage.noobaa.io openshift-storage.noobaa.io/obc Delete Immediate false 2d10h
[root@bastion ~]#
以上でOCSのインストール確認は完了です。
7.ラベル、taint、tolerationの設計
実際の環境には、役割の違うノードが混在します。
ここでは、以下のような構成を考えます。
Masterノード : コントロールプレーン
ユーザーアプリ専用 Node : ユーザーのコンテナが稼働するWorkerノード
Infraノード : 監視やログ収集のコンポーネントが稼働するWorkerノード
OCSノード : OCS(OopenShift Container Storage)が稼働するWokrer Node
で構成されています。
図の中でOCSのノードにcluster.ocs.openshift.io/openshift-storage=''というラベルを貼っていますが、これはセクション「3.3. OCSインストール対象Nodeのラベリング」で、行った手順です。OCSのメインのコンポーネントは、このラベルがある所にインストールされています。
7.1.Infra ラベルを貼る
動作に影響はしませんが、OpenShiftは、ユーザーのアプリケーションを動かすWorkerノードと、運用用途に使われるWorkerノードを内部的に認識しています。
OpenShiftからOCSノードがinfra(Infrastructure)用のノードと認識されるようにinfraと言う role ラベルをつけておきます。
以下のコマンドで、Infraノードとしてのラベルを振ります。
oc label node s1.ocp45.example.localdomain node-role.kubernetes.io/infra=
oc label node s2.ocp45.example.localdomain node-role.kubernetes.io/infra=
oc label node s3.ocp45.example.localdomain node-role.kubernetes.io/infra=
Workerノードとしてのラベルはつけたままにします。Workerノード のラベルを削除する事もできますが、単純に削除しただけだと、OpenShiftからWoker Nodeとみなされなくなるため自動アップデート等の運用に問題が発生します。
[root@bastion openshift]# oc get nodes
NAME STATUS ROLES AGE VERSION
i1.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
i2.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
i3.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
m1.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
m2.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
m3.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
s1.ocp45.example.localdomain Ready infra,worker 27m v1.18.3+47c0e71
s2.ocp45.example.localdomain Ready infra,worker 28m v1.18.3+47c0e71
s3.ocp45.example.localdomain Ready infra,worker 28m v1.18.3+47c0e71
w1.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
w2.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
w3.ocp45.example.localdomain Ready worker 14h v1.18.3+47c0e71
[root@bastion openshift]#
7.2.toleration と taint を付ける
OCSノードに、ユーザーアプリの Podがスケジュールされる可能性があります。
OCSノードにtaintをつける事で、tolerationを持っているPodしかスケジュールされないようにします。
予期せぬ事態を防ぐために、先に toleration をつけて、その後に taint を付ける事をおすすめします。
7.2.1.LocalVolume に toleration を付ける
以前作成したOCSのCR(Custom Resource)であるLocalVolume の local-block を編集して、tolerationを付けます。
oc edit LocalVolume local-block -n local-storage
node.ocs.openshift.io/storage="true":NoSchedule と言うtaintがあってもスケジュールされるように編集します。
実際には、この手順ではLocalVolumeリソースを作成した時に、既にtolerationの定義を追加しているので、定義が存在している事を確認します。
<省略>
name: local-block
namespace: local-storage
resourceVersion: "7632465"
selfLink: /apis/local.storage.openshift.io/v1/namespaces/local-storage/localvolumes/local-block
uid: ef7774a6-1496-484f-b50d-d47bc36456a5
spec:
logLevel: Normal
managementState: Managed
nodeSelector:
nodeSelectorTerms:
- matchExpressions:
- key: cluster.ocs.openshift.io/openshift-storage
operator: In
values:
- ""
storageClassDevices:
- devicePaths:
- /dev/disk/by-id/scsi-36000c290ef83f5ddee94f3e43dcb6197
- /dev/disk/by-id/scsi-36000c29af3872df29dc0cf11fc1b0e08
- /dev/disk/by-id/scsi-36000c294793b7f8acdd6584ff588cecc
storageClassName: localblock
volumeMode: Block
tolerations: # toleration 追加されている事を確認
- effect: NoSchedule # 追加を確認
key: node.ocs.openshift.io/storage # 追加を確認
value: "true" # 追加を確認
<省略>
7.2.2.CSIプラグインPodに toleration を付ける
CSIプラグイン(Pod)は、OCSのストレージにアクセスするためにクラスターの全てのノードに必要なPodです。
taintが付いているノードにもCSIプラグインをインストールするには、tolerationを付けてあげる必要があります。
以下のコマンドで、rook-ceph-operatorのConfigMapを編集します。
oc edit configmap rook-ceph-operator-config -n openshift-storage
#の所がこの手順で変更した所です。
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
CSI_PLUGIN_TOLERATIONS: |2-
- key: node.ocs.openshift.io/storage
operator: Equal
value: "true"
effect: NoSchedule
- key: infra # tolerationの追加
effect: NoSchedule #
value: reserved #
- key: infra #
effect: NoExecute #
value: reserved #
CSI_PROVISIONER_TOLERATIONS: |2-
- key: node.ocs.openshift.io/storage
operator: Equal
value: "true"
effect: NoSchedule
kind: ConfigMap
metadata:
creationTimestamp: "2020-10-28T03:16:56Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
.: {}
f:CSI_PROVISIONER_TOLERATIONS: {}
manager: ocs-operator
operation: Update
time: "2020-10-28T03:16:56Z"
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:data:
f:CSI_PLUGIN_TOLERATIONS: {}
manager: oc
operation: Update
time: "2020-10-28T06:13:35Z"
name: rook-ceph-operator-config
namespace: openshift-storage
resourceVersion: "572973"
selfLink: /api/v1/namespaces/openshift-storage/configmaps/rook-ceph-operator-config
uid: 9db6a13c-abc5-4623-9af3-a447a6dd9588
7.2.3.OCSノードに taint を付ける
node.ocs.openshift.io/storage="true":NoSchedule というtaintをOCSノードに付けます。
以下のコマンドで、OCSノードにtaintを付けます。
oc adm taint node s1.ocp45.example.localdomain node.ocs.openshift.io/storage="true":NoSchedule
oc adm taint node s2.ocp45.example.localdomain node.ocs.openshift.io/storage="true":NoSchedule
oc adm taint node s3.ocp45.example.localdomain node.ocs.openshift.io/storage="true":NoSchedule
taintは以下のコマンドで確認できます。
oc describe node <node名>
<省略>
Annotations: machineconfiguration.openshift.io/currentConfig: rendered-infra-c5316746ee6f0621645031486cad5c02
machineconfiguration.openshift.io/desiredConfig: rendered-infra-c5316746ee6f0621645031486cad5c02
machineconfiguration.openshift.io/reason:
machineconfiguration.openshift.io/state: Done
volumes.kubernetes.io/controller-managed-attach-detach: true
CreationTimestamp: Thu, 22 Oct 2020 22:24:13 +0900
Taints: node.ocs.openshift.io/storage=true:NoSchedule
Unschedulable: false
<省略>
7.2.4.taint の削除
taintを付け間違った時は、最期に-を付ける事で消す事ができます。
oc adm taint node s1.ocp45.example.localdomain node.ocs.openshift.io/storage="true":NoSchedule-
8.補則
インストールを行ってみて、知っておいた方が良いと思った事を書いておきます。
8.1.OCSのuninstall
OCSのインストールは、基本 Operator によるインストールですが、これらの行った手順を単純に取り消しても、ゴミが残ってしまい、基本、元の状態に戻りません。
OCS4.5の時点で、OCSのアンインストールは、例えまだPVCを作成してアプリケーションからボリュームを使用してない状態でも、コマンドラインから行う必要があります。OpenShift Console から、アンインストールをしても、インストール手順を逆になぞるだけでは完全に削除できないので、注意してください。
マニュアルにアンインストールの章があるので、それに沿って作業します。
OPENSHIFT CONTAINER PLATFORM のアンインストール(Red Hat マニュアル)
マニュアルの手順では、local-storageのnamespaceが残るので以下のコマンドで削除します。
oc delete namespace local-storage
8.2. HPA(Horizontal Pod Autoscaler)のWarning
OCS4.5では、インストール暫くすると以下のような、 HPA(Horizontal Pod Autoscaler)が出すWarningがOpenShift Consoleに出る事が確認されています。これはBugとして扱われており、OCS`4.6で一部修正されたような記述が見えますが、4.6用の別のチケットもオープンしており詳細な状況は未確認です。(2020/10/29時点)
コマンドラインでも以下のように oc get events -n openshift-storageで確認できます。
[root@bastion openshift]# oc get events -n openshift-storage
LAST SEEN TYPE REASON OBJECT MESSAGE
70m Warning FailedGetResourceMetric horizontalpodautoscaler/noobaa-endpoint unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: an error on the server ("Internal Server Error: \"/apis/metrics.k8s.io/v1beta1/namespaces/openshift-storage/pods?labelSelector=noobaa-s3%3Dnoobaa\": subjectaccessreviews.authorization.k8s.io is forbidden: User \"system:serviceaccount:openshift-monitoring:prometheus-adapter\" cannot create resource \"subjectaccessreviews\" in API group \"authorization.k8s.io\" at the cluster scope") has prevented the request from succeeding (get pods.metrics.k8s.io)
70m Warning FailedComputeMetricsReplicas horizontalpodautoscaler/noobaa-endpoint invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: an error on the server ("Internal Server Error: \"/apis/metrics.k8s.io/v1beta1/namespaces/openshift-storage/pods?labelSelector=noobaa-s3%3Dnoobaa\": subjectaccessreviews.authorization.k8s.io is forbidden: User \"system:serviceaccount:openshift-monitoring:prometheus-adapter\" cannot create resource \"subjectaccessreviews\" in API group \"authorization.k8s.io\" at the cluster scope") has prevented the request from succeeding (get pods.metrics.k8s.io)
[root@bastion openshift]#
8.3. OCSをインターナルモードで作成する事について
通常時は問題を感じなかったのですが、OCSをインターナルモードで、OpenShfit クラスター内に配置する場合、OpenShift(Kubernetes)のアップデートに OCS自体も影響を受ける事に気づきました。
実際、クラスターのアップデート中は、クラスター全体が不安定な状況になりますが、ストレージであるOCSもインターナルモードで作っている場合は、OpenShiftの一部ですので、Masterノード、Workerノードと一緒にアップデートが走り、ストレージも含めてシステム全体が不安定な状況になります。
一般的にサーバーやアプリのアップデートと、ストレージのファームウェアのアップデートを同時に行うのは、リスク管理として良い方法ではないと思います。
そして現状ではKubernetesは、およそ3ヶ月に1回新しいマイナー・バージョンがリリースされ、一つのマイナーバージョンのサポート期間はおよそ1年です。
ストレージは企業活動の資産でもあるので、こう言った頻繁なアップデートにおけるリスクを減らすためには、OCSインターナルモードを使うのはテスト環境にするか、バックアップを別のストレージシステムに取得している事を前提とするのが良いと感じました。