概要

OCP 4.10環境で、Local Storage Operatorを使用して、ロギング、モニタリングの永続ボリューム(PV)を作成した際のメモを記載します。

ロギング、モニタリングのPVはブロックボリュームが推奨です。

OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 10. ストレージの最適化 / 10.2. 設定可能な推奨のストレージ技術

ブロックスボリュームのサポートは以下のようなものがあります。

OCP 4.10 Docs / ストレージ / 3. 永続ストレージについて / 3.5. ブロックボリュームのサポート

オンプレで検証環境を作る際には、CIS対応のストレージ製品がなかったり、OpenShift Data Foundationを構成するためのスペックのnodeまでは用意できない場合もあります。また、検証環境のvCenterの管理者ユーザーを使用させてもらえずvSphereのCSIドライバーのPVも使用できなかったりで、ブロックボリュームのPVを準備するのがなかなか難しいことがあります。

そのような場合でも、local-storage operatorを使用すると、オンプレミスでブロックボリュームのPVを作成することができます。
今回は、local-storage operatorのLocalVolumeリソースによるブロックボリュームのPVを使用して、ロギング、モニタリングを構成する手順のメモを記載します。

OCP 4.10 Docs / ストレージ / 4. CONFIGURING PERSISTENT STORAGE / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング

構成

OCP構成

この記事でのOCPクラスタの前提の構成は以下のリンク先でインストールしたOCP 4.10の構成となります。

Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール
- OCP 4.10をベアメタルのUPIでインストールしています。
- ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。

インフラノード

インフラノードは以下の手順で作成しています。

Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する
- モニタリングは、デフォルトのモニタリング(prometheusk8s、alertmanager)のみで、ユーザーワークロードモニタリングはここでは入れていません。
- クラスターロギングは、このリンク先で導入したElasticsearch、Fluentd、Kibanaの構成です。

構成図

今回のinfra nodeと仮想ハードディスク、LocalVolumeによるPVの構成図は以下になります。

ディスク構成(仮想マシン)

(補足) 仮想マシン設定(disk.EnableUUID (/dev/disk/by-id))

LocalVolumeリソースの、devicePathsは、/dev/disk/by-id/で定義することが推奨されています。
ですので、今回は/dev/disk/by-idで指定します。

vSphere環境の仮想マシンでは、ゲストOSのRHCOSで/dev/disk/by-idを認識するためには、仮想マシンの詳細設定でdisk.EnableUUIDはTRUEにしておく必要がある模様です。
(今回はベアメタルのUPIの手順ですが、OCP 4.10 DocsのvSphereのUPIのインストールガイドの場合も、disk.enableUUID: TRUEの設定が必要との記載もありました。)

KB / How to get the WWID of the disk within a RHEL guest on VMware ESX host?
KB / How to check and set the disk.EnableUUID parameter from VM in vSphere for Openshift Container Platform.
Qiita / OCS(OpenShift Container Storage)をインターナルモードで作成する

ですので、今回もこの設置をしておきます。

一応、localvolumeでPVを作成するのはロギング、モニタリング用のPVで、infra nodeだけなのですが、アプリケーションPod用のPVもlocalvolumeで作成することもあるかもしれないため、一律全ノードの仮想マシンでこの設置はしておきます。

仮想マシンの「設定の編集」画面を表示
「設定の編集」画面の「仮想マシンオプション」タブを表示
「仮想マシンオプション」タブの「詳細」->「設定パラメータ」欄の「設定の編集」のリンクをクリック
-　表示される「設定のパラメータ」画面で「設定の追加」をクリックし、以下を入力してOKをクリック
- 名前: disk.EnableUUID
- 値: TRUE
設定されていることを確認

(補足) VMwareの仮想マシンの仮想ハードディスクとLinux上でのデバイスの認識

VMwareのVirtual Machineの仮想ディスクとLinux上でのデバイスの認識は以下が参考になります。

VMware におけるSCSIコントローラの認識順序
KB / 仮想マシンの SCSI コントローラを変更すると VMware vSphere ESXi でハードディスクの順序が変わる (2135969)

上述のリンク先の情報から、VMwareの仮想マシンの仮想ハードディスクに関しては、同一SCSIコントローラー内であればSCSIアドレスの順番通りに仮想ハードディスク番号がOSに認識され、OSからは/dev/sdxのxはアルファベット順に認識されます。
今回はRHCOSのOS領域は、infra nodeのVMの、仮想ハードディスク #1 (SCSI(0: 0))で/dev/sdaになり、ロギング、モニタリングの仮想ハードディスクはSCSIコントローラー0の中でSCSIアドレスが順番通りになるように作成しています。
(何も意識をせずに、仮想ハードディスクを追加していけば普通はそのようになっているので、実際はあまり意識しなくても良いかと思います。)

(例) infra-01のディスク構成

(補足)
LocalVolumeリソースのdevicePathsは/dev/sdbなどのデバイス名でも設定できます。特に今回は上述のようにSCSIコントローラーとアドレスを意識して仮想ハードディスクを作成するのでudevで認識される/dev/sdbなどもずれることはないのですが、今回は推奨通りに/dev/disk/by-id/で指定することにしています。

ディスク構成(ロギング)

OCP 4.10 Docs / ロギング / 3. OPENSHIFT LOGGING のインストール / 3.1. Web コンソールを使用した OpenShift Logging のインストール
OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定
OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.2. ログ保持時間の設定
OCP 4.10 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.3. ログストアの設定 / 4.3.6. ログストアの永続ストレージの設定

Elasticsearchは、replicasが1のDeploymentが3つできて、infra-0[1-3]の3つのPVをそれぞれBindすることで、3つのPodがそれぞれinfra-0[1-3]上で1つづつ稼働するようになります。

上述のドキュメントを参照すると、インストール時のインスタンスの例としてはelasticsearchのPVCは200Gと記載されており、デフォルトは7dで削除されます。

ログの容量は、実際やってみないと正確にはわかりませんが、今回は検証環境で大きな容量は用意できないので、容量は80Gで、1dで削除するようにしています。
(インデックスサイズは、40 GB x プライマリーシャードの数よりも大きくなります。との記載もありますが、1dで削除するようにするので一旦ここはそこまで気にしないことにしています。)

(ロギング)

用途	node	VMの仮想ハードディスク	SCSIアドレス	OSでのデバイス名	/dev/disk/by-id/xxx	容量(GiB)
Elasticsearch	infra-0[1-3]	ハードディスク 2	SCSI(0: 1)	/dev/sdb	後ほどスクリプトで洗い出し	80

ディスク構成(モニタリング)

prometheusK8sは、replicasが2のStatefulsetが1つできるので、infra-0[1-3]の3つのPVのうち、いずれか2つを使用して、2つのPodがinfra-0[1-3]にいずれか2つのnode上で稼働するようになります。(*1)
alertmanagerMainは、replicasが2のStatefulsetが1つできるので、infra-0[1-3]の3つのPVのうち、いずれか2つを使用して、2つのPodがinfra-0[1-3]にいずれか2つのnode上で稼働するようになります。(*1)

以下を参照すると、ノード数50、Pod数1800の場合に、Prometheusストレージの1日あたりの増加量は6.3GBで、15日では94GBになります。

OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 8. CLUSTER MONITORING OPERATOR のスケーリング / 8.1. Prometheus データベースのストレージ要件

また、以下を参照すると、Prometheusメトリクスデータの保持期間はデフォルトでは15日です。

OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 / 2.8. 永続ストレージの設定

今回は検証環境でノード数もPod数も大きくないので、2.8.2. ローカ永続ボリューム要求 (PVC）の設定のサンプルにあった40Giぐらいにしておきました。
但し、検証環境はそんなにディスク容量があるわけではないので、ディスクの保持期間は3日ぐらいに変更しました。

Alertmanagerはそんなにディスクは使わないので、少なくても良いのですが、上述の「2.8.2.」のサンプルにあった10Giぐらいにしておきました。

(モニタリング)

用途	node	VMの仮想ハードディスク	SCSIアドレス	OSでのデバイス名	/dev/disk/by-id/xxx	容量(GiB)
prometheusK8s	infra-0[1-3]	ハードディスク 3	SCSI(0: 2)	/dev/sdc	後ほどスクリプトで洗い出し	40
alertmanagerMain	infra-0[1-3]	ハードディスク 4	SCSI(0: 3)	/dev/sdd	後ほどスクリプトで洗い出し	10

(参考)今回はユーザーワークロードモニタリングは導入していません。もし追加する場合は、検証環境では例えば以下のようにします。

用途	node	VMの仮想ハードディスク	SCSIアドレス	OSでのデバイス名	/dev/disk/by-id/xxx	容量(GiB)
prometheus	infra-0[1-3]	ハードディスク 5	SCSI(0: 4)	/dev/sde	後ほどスクリプトで洗い出し	40
thanosRuler	infra-0[1-3]	ハードディスク 6	SCSI(0: 5)	/dev/sdf	後ほどスクリプトで洗い出し	10

(*1)
OCP 4.9以前は、alertmanagerMainは、replicasが「3」のStatefulsetが1つできて、infra-0[1-3]の3つのPVをそれぞれBindすることで、3つのPodがそれぞれinfra-0[1-3]上で1つづつ稼働していました。
これが、OCP 4.10からはreplicasが「2」に変更されています。

OCP 4.10 リリースノート参照

1.3.20.7

1.8. 既知の問題

今回のように、infra nodeで全て仮想ハードディスク構成を同じにすると、prometheusK8sとalertmanagerMainはreplica数が「2」なので、いずれか1つのinfra nodeのPV用は余ってしまいます。

今回はLocalVolumeリソースのdevicePathsは/dev/disk/by-id/で指定するので、本来は必要なinfra nodeに必要な個数だけ仮想ハードディスクを作成すれば良いのすが、infra-0[1-3]で仮想ハードディスクの構成が変わってしまいます。
そうすると初期構成時の仮想ハードディスクを作成するときにわかりずらかったり、後ほどKBなどを参考に/dev/disk/by-id/を洗い出す際にも/dev/sdxをキーにして洗い出しているので、今回は分かりやすさのためにinfra-0[1-3]の仮想ハードディスク構成は（例え余ったとしても）あえて同じにしてみました。

RHCOSでのディスクの認識の確認

vCenterからinfra nodeに作成した仮想ハードディスクが、RHCOSのOSから正しく認識されていることを確認します。
(SCSIアドレスの順番通りに/dev/sdb、sdcが並んでいます。)
(ユーザーワークロードモニタリング分の仮想ハードディスクも作成していますが、この記事では構成はしていません。)

[root@bastion-01 ~]# ssh core@infra-01 -- lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  127M  0 part
|-sda3   8:3    0  384M  0 part /boot
`-sda4   8:4    0 39.5G  0 part /sysroot
sdb      8:16   0   80G  0 disk
sdc      8:32   0   40G  0 disk
sdd      8:48   0   10G  0 disk
sde      8:64   0   40G  0 disk
sdf      8:80   0   10G  0 disk
sr0     11:0    1 1024M  0 rom
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-02 -- lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  127M  0 part
|-sda3   8:3    0  384M  0 part /boot
`-sda4   8:4    0 39.5G  0 part /sysroot
sdb      8:16   0   80G  0 disk
sdc      8:32   0   40G  0 disk
sdd      8:48   0   10G  0 disk
sde      8:64   0   40G  0 disk
sdf      8:80   0   10G  0 disk
sr0     11:0    1 1024M  0 rom
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-03 -- lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   40G  0 disk
|-sda1   8:1    0    1M  0 part
|-sda2   8:2    0  127M  0 part
|-sda3   8:3    0  384M  0 part /boot
`-sda4   8:4    0 39.5G  0 part /sysroot
sdb      8:16   0   80G  0 disk
sdc      8:32   0   40G  0 disk
sdd      8:48   0   10G  0 disk
sde      8:64   0   40G  0 disk
sdf      8:80   0   10G  0 disk
sr0     11:0    1 1024M  0 rom
[root@bastion-01 ~]#

/dev/disk/by-id/では、sdbやsdcなどにリンクされているエントリーは3つ表示されます。
(sdbの例)

/dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
/dev/disk/by-id/scsi-SVMware_Virtual_disk_6000c29345d1023bd04cbaba37b62c17
/dev/disk/by-id/wwn-0x6000c29345d1023bd04cbaba37b62c17

今回は、LocalVolumeリソースのdevicePathsでは/dev/disk/by-id/scsi-36000xxxxxxを指定します。

[root@bastion-01 ~]# ssh core@infra-01 -- "ls -l /dev/disk/by-id/ | grep sdb"
lrwxrwxrwx. 1 root root  9 May 25 10:10 scsi-36000c29345d1023bd04cbaba37b62c17 -> ../../sdb
lrwxrwxrwx. 1 root root  9 May 25 10:10 scsi-SVMware_Virtual_disk_6000c29345d1023bd04cbaba37b62c17 -> ../../sdb
lrwxrwxrwx. 1 root root  9 May 25 10:10 wwn-0x6000c29345d1023bd04cbaba37b62c17 -> ../../sdb
[root@bastion-01 ~]#
[root@bastion-01 ~]# ssh core@infra-01 -- "ls -l /dev/disk/by-id/ | grep sdb | grep scsi-36000"
lrwxrwxrwx. 1 root root  9 May 25 10:10 scsi-36000c29345d1023bd04cbaba37b62c17 -> ../../sdb
[root@bastion-01 ~]#

infra-0[1-3]の全ての/dev/sdb、sdcなどをキーにして/dev/disk/by-id/を洗い出す方法は以下のKBがとても参考になります。

KB / How to list the local disk IDs for every OCS worker in Openshift 4.x

(補足)
このKBはOpenShift Data FoundationをLocal Storage Operatorと組み合わせて使用する際に使用できるディスクの/dev/disk/by-id/を洗い出す方法になります。

今回はLocal Storage Operatorだけを使用する予定ですので、OpenShift Data Fundation用のstorage nodeは作成していません。
ですので、KB内に記載のocs-disk-gatherer-own-project.yamlは、少し修正が必要です。

例えば、以下のstorage nodeのnode selectorやtolerationsの値を今回のinfra nodeやworker node用に適宜修正する必要などがあります。
ocs-disk-gatherer-own-project.yaml
    spec:
      nodeSelector:
        cluster.ocs.openshift.io/openshift-storage: ''
      tolerations:
      - key: "node.ocs.openshift.io/storage"
        operator: Equal
        value: "true"

今回は上述のKBの方法を使わないで、普通にinfra nodeに対してgrepなどで/dev/disk/by-id/scsi-36000xxxxxxxxを検索してみました。
(以下のコマンド出力は後ほどLocalVolumeのマニフェストファイルで使用します。そのままコピペして貼れるようにスペースを入れたりして出力を工夫しています。)

[root@bastion-01 ~]# for disk in sd{b..f}; do echo ----------------; echo $disk; for node in infra-0{1..3}; do echo "        - /dev/disk/by-id/$(ssh core@$node -- "ls -l /dev/disk/by-id/ | grep scsi-36000" | grep $disk | awk '{print $9}')"; done; done
----------------
sdb
        - /dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
        - /dev/disk/by-id/scsi-36000c2952611aa4f13bd8198b3340d91
        - /dev/disk/by-id/scsi-36000c298a8b8798a0fdc29981a9bb243
----------------
sdc
        - /dev/disk/by-id/scsi-36000c29a5f70b6bd1f25aca63b360dc6
        - /dev/disk/by-id/scsi-36000c295cf468146795091b2b9f21a1d
        - /dev/disk/by-id/scsi-36000c293a4d6fdfad46a19b223238e5c
----------------
sdd
        - /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
        - /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
        - /dev/disk/by-id/scsi-36000c29f96a0a5aa5dc5a6204d02874a
----------------
sde
        - /dev/disk/by-id/scsi-36000c29ee83b515115cf2ca8e357915d
        - /dev/disk/by-id/scsi-36000c2979c9e48a8beb1d23a7e41d85e
        - /dev/disk/by-id/scsi-36000c29476519e125b18652d21cd3c90
----------------
sdf
        - /dev/disk/by-id/scsi-36000c29d26c476bf6f90b9ee4f7581ef
        - /dev/disk/by-id/scsi-36000c29e6376eae73ad5a02bd0ef5f35
        - /dev/disk/by-id/scsi-36000c2924a75fdc65b262812b3267e29
[root@bastion-01 ~]#

Local Storage Operatorのインストール

下記リンク先の手順に従ってLocal Storage Operatorをインストールします。
今回は、OCPのWebコンソールからインストールしました。

Local Storage Operatorインストール用のProjectの作成

Local Storage OperatorインストールするProjectを作成します。
Project名は、ドキュメント通りに、openshift-local-storageとします。

[root@bastion-01 ~]# oc adm new-project openshift-local-storage
Created project openshift-local-storage
[root@bastion-01 ~]#

(補足)`openshift-local-storage` Peroject(Namespace)の追加設定

この後、openshift-local-storage Peroject(Namespace)にLocalVolumeリソースを作成すると、マニフェストの.spec.nodeSelectorで指定したnode上で、自動でdiskmaker-managerというdaemonsetのPodが稼働しています。

(昔のバージョンでは、LocalVolumeリソースの数だけ<storage class name>-local-diskmakerと<storage class name>-local-provisionerというdaemonsetのPodが作成されていました。ですが、OCP 4.10では、LocalVolumeを作成するnodeにdiskmaker-managerのdaemonsetのPodが1つ作成されているようになっていました。(LocalVolume毎ではなくnode毎に1つ))

モニタリング、ロギングのPVは、LocalVolumeリソースによって、infra nodeのRHCOSのハードディスクに作成されます。
またアプリケーションPod用のPVもLocalVolumeリソースで作成する場合は、worker nodeのRHCOSのハードディスクに作成されます。

そのため、このdiskmaker-manager Podは、infra nodeでもworker nodeでも稼働させる必要があります。

今回はinfra nodeはQiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成するの手順で作成しています。

上述のPodがinfra node、worker nodeのどちらのnodeでも稼働するようにするためには、アプリケーションPodをinfra nodeで稼働させない設定を、どのように設定していたかを確認する必要があります。

今回は「アプリケーションPodをinfra nodeで稼働させない設定」として、「(1) nodeSelectorのみを使用」を使用していました。
この場合は、openshift-local-storage Project(Namespace)にnodeSelectorを明示的に設定しなければ、infra nodeとworker nodeのどちらでも稼働することになります。

ですので今回はあまり必要ないのですが、念のためクラスター単位のデフォルトのnodeSelectorが設定されていた場合に影響されないように、OCPのドキュメント通りにopenshift-local-storage Project(Namespace)にデフォルトのnodeSelectorを無視する設定も入れておきました。

[root@bastion-01 ~]# oc annotate project openshift-local-storage openshift.io/node-selector=''
project.project.openshift.io/openshift-local-storage annotated
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get project openshift-local-storage -o yaml | grep -A 7 " annotations:"
  annotations:
    openshift.io/description: ""
    openshift.io/display-name: ""
    openshift.io/node-selector: ""
    openshift.io/sa.scc.mcs: s0:c26,c15
    openshift.io/sa.scc.supplemental-groups: 1000680000/10000
    openshift.io/sa.scc.uid-range: 1000680000/10000
  creationTimestamp: "2022-05-16T12:10:38Z"
[root@bastion-01 ~]#

(補足) infra nodeにtaintの設定を入れている場合
もし「アプリケーションPodをinfra nodeで稼働させない設定」として、「(2) nodeSelectorとtaint/tolerationを使用」の方法を使用している場合は、infra nodeにtaintがついているので、LocalVolumeリソース内でtoralationの設定を入れる必要があります。

OCP 4.10 Docs / ストレージ / 4. Configuring persistent storage / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.7. ローカルストレージ Operator Pod での容認の使用

Local Storage Operatorのインストール

今回はOCPのWebコンソールからLocal Storage Operatorをインストールします。

OpenShift Container Platform Web コンソールにcluster-admin roleのある管理者ユーザーでログインし、左側のメニューからOperator -> OperatorHubを選択します。

検索ボックスで「Local Storage」という文字列を入力して、Local Storage Operatorを表示し、「Local Storage」をクリックします。

「Local Storage」画面で「インストール」をクリックします。

「Operatorのインストール」ページで、「クラスター指定のnamespace」を選択します。今回は先ほど作成したopenshift-local-storageが表示されています。
その他、「インストールモード」や「更新の承認」などは以下のように設定しました。
設定をしたら「インストール」をクリックします。

設定項目	デフォルト値	設定値	備考
更新チャネル	stable	4.10	案件では通常バージョンを明確に管理する必要があることが多いのでチャネルはバージョン名のものにしておきました。
インストールモード	クラスターの特定のnamespace	デフォルトのまま
インストール済みのnamespace	Operator推奨のnamespace (openshift-local-storage)	デフォルトのまま
更新の承認	自動	デフォルトのまま	(※)実案件ではコンポーネントのバージョンは明確に管理する必要があったり、アップデートするタイミングを業務外にする必要があることがあります。そのような場合には、自動でチャネル内の最新のパッチバージョンに更新されないようにするため「手動」にしたりします。

インストールが完了します。
Local Storage Operatorをが、Web コンソールの Installed Operators セクションに一覧表示されます。

(OperatorのPod自体には特にnodeSelectorなどの設定をしなかったので任意のinfra or worker node上で稼働しています。)

[root@bastion-01 ~]# oc get pod -n openshift-local-storage
NAME                                      READY   STATUS    RESTARTS   AGE
local-storage-operator-68cfffb766-lgs85   1/1     Running   0          2m47s
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME                                      READY   STATUS    RESTARTS   AGE     IP            NODE        NOMINATED NODE   READINESS GATES
local-storage-operator-68cfffb766-lgs85   1/1     Running   0          2m53s   10.131.2.12   worker-01   <none>           <none>
[root@bastion-01 ~]#

LocalVolumeリソースの作成

OCP 4.10 Docs / ストレージ / 4. CONFIGURING PERSISTENT STORAGE / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.2. ローカルストレージ Operator を使用したローカルボリュームのプロビジョニング

マニフェストファイル作成

マニフェストファイルを作成する作業ディレクトリに移動します。

[root@bastion-01 ~]# ls -l work/manifest/
合計 0
drwxr-xr-x. 2 root root 118  3月 26 18:59 chrony
drwxr-xr-x. 2 root root  49  4月  1 21:18 htpasswd
drwxr-xr-x. 2 root root   6  5月 17 14:05 localvolume
drwxr-xr-x. 2 root root  41  5月 16 20:26 logging
drwxr-xr-x. 2 root root  28  5月  9 20:33 mcp
drwxr-xr-x. 2 root root  47  5月 13 19:50 monitoring
drwxr-xr-x. 2 root root  55  5月  9 20:28 pv
[root@bastion-01 ~]#
[root@bastion-01 ~]# cd work/manifest/localvolume/
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 0
[root@bastion-01 localvolume]#

ロギングとモニタリング用のLocalVolumeリソースのマニフェストファイルを作成します。

[root@bastion-01 localvolume]# vi localvolume-elasticsearch.yaml
[root@bastion-01 localvolume]# vi localvolume-prometheusk8s.yaml
[root@bastion-01 localvolume]# vi localvolume-alertmanagermain.yaml
[root@bastion-01 localvolume]# vi localvolume-prometheus.yaml
[root@bastion-01 localvolume]# vi localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 20
-rw-r--r--. 1 root root 648  5月 17 16:16 localvolume-alertmanagermain.yaml
-rw-r--r--. 1 root root 642  5月 17 16:15 localvolume-elasticsearch.yaml
-rw-r--r--. 1 root root 636  5月 17 16:17 localvolume-prometheus.yaml
-rw-r--r--. 1 root root 642  5月 17 16:16 localvolume-prometheusk8s.yaml
-rw-r--r--. 1 root root 638  5月 17 16:17 localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#

ロギング

elasticsearchでは、先ほど確認したinfra-0[1-3]の/dev/sdbの/dev/by-id/scsi-36000xxxxxxを指定します。

localvolume-elasticsearch.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "localvolume-elasticsearch"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - infra-01
          - infra-02
          - infra-03
  storageClassDevices:
    - storageClassName: "local-elasticsearch"
      volumeMode: Filesystem
      fsType: xfs
      devicePaths:
        - /dev/disk/by-id/scsi-36000c29345d1023bd04cbaba37b62c17
        - /dev/disk/by-id/scsi-36000c2952611aa4f13bd8198b3340d91
        - /dev/disk/by-id/scsi-36000c298a8b8798a0fdc29981a9bb243

モニタリング

prometheusK8sでは、先ほど確認したinfra-0[1-3]の/dev/sdcの/dev/by-id/scsi-36000xxxxxxを指定します。

localvolume-prometheusk8s.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "localvolume-prometheusk8s"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - infra-01
          - infra-02
          - infra-03
  storageClassDevices:
    - storageClassName: "local-prometheusk8s"
      volumeMode: Filesystem
      fsType: xfs
      devicePaths:
        - /dev/disk/by-id/scsi-36000c29a5f70b6bd1f25aca63b360dc6
        - /dev/disk/by-id/scsi-36000c295cf468146795091b2b9f21a1d
        - /dev/disk/by-id/scsi-36000c293a4d6fdfad46a19b223238e5c

alertmanagermainでは、先ほど確認したinfra-0[1-3]の/dev/sddの/dev/by-id/scsi-36000xxxxxxを指定します。

localvolume-alertmanagermain.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "localvolume-alertmanagermain"
  namespace: "openshift-local-storage"
spec:
  nodeSelector:
    nodeSelectorTerms:
    - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - infra-01
          - infra-02
          - infra-03
  storageClassDevices:
    - storageClassName: "local-alertmanagermain"
      volumeMode: Filesystem
      fsType: xfs
      devicePaths:
        - /dev/disk/by-id/scsi-36000c292c64adf34d67ff0080ec8686a
        - /dev/disk/by-id/scsi-36000c298ec479efbc44f98d673edc887
        - /dev/disk/by-id/scsi-36000c29f96a0a5aa5dc5a6204d02874a

LocalVolumeリソースの作成

作成したマニフェストファイルを適用します。

適用前はLocalVolumeリソースやPVはまだありません。

[root@bastion-01 ~]# oc get localvolume -n openshift-local-storage
No resources found in openshift-local-storage namespace.
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-local-storage -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP           NODE        NOMINATED NODE   READINESS GATES
local-storage-operator-68cfffb766-lgs85   1/1     Running   2          19h   10.131.2.2   worker-01   <none>           <none>
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pv
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                             STORAGECLASS     REASON   AGE
image-registry-storage   100Gi      RWX            Retain           Bound    openshift-image-registry/image-registry-storage   image-registry            44d
[root@bastion-01 ~]#

LocalVolumeリソースのマニフェストファイルを適用します。

[root@bastion-01 ~]# cd work/manifest/localvolume/
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# ls -l
合計 20
-rw-r--r--. 1 root root 696  5月 17 17:08 localvolume-alertmanagermain.yaml
-rw-r--r--. 1 root root 690  5月 17 17:08 localvolume-elasticsearch.yaml
-rw-r--r--. 1 root root 684  5月 17 17:08 localvolume-prometheus.yaml
-rw-r--r--. 1 root root 690  5月 17 17:08 localvolume-prometheusk8s.yaml
-rw-r--r--. 1 root root 686  5月 17 17:08 localvolume-thanosruler.yaml
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-elasticsearch.yaml
localvolume.local.storage.openshift.io/localvolume-elasticsearch created
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-prometheusk8s.yaml
localvolume.local.storage.openshift.io/localvolume-prometheusk8s created
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc apply -f localvolume-alertmanagermain.yaml
localvolume.local.storage.openshift.io/localvolume-alertmanagermain created
[root@bastion-01 localvolume]#

ロギングとモニタリング用のLocalVolumeリソースが作成され、対応したStorage Class(SC)、PVが作成されます。

[root@bastion-01 localvolume]# oc get localvolume -n openshift-local-storage
NAME                           AGE
localvolume-alertmanagermain   19s
localvolume-elasticsearch      34s
localvolume-prometheusk8s      26s
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get pod -n openshift-local-storage -o wide
NAME                                      READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
diskmaker-manager-bzpfr                   2/2     Running   0          25s   10.128.2.18   infra-02    <none>           <none>
diskmaker-manager-j878w                   2/2     Running   0          19s   10.130.2.18   infra-03    <none>           <none>
diskmaker-manager-xnxgk                   2/2     Running   0          24s   10.131.0.52   infra-01    <none>           <none>
local-storage-operator-68cfffb766-lgs85   1/1     Running   2          20h   10.131.2.2    worker-01   <none>           <none>
[root@bastion-01 localvolume]#
[root@bastion-01 localvolume]# oc get sc
NAME                     PROVISIONER                    RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-alertmanagermain   kubernetes.io/no-provisioner   Delete          WaitForFirstConsumer   false                  35s
local-elasticsearch      kubernetes.io/no-provisioner   Delete          WaitForFirstConsumer   false                  50s
local-prometheusk8s      kubernetes.io/no-provisioner   Delete          WaitForFirstConsumer   false                  42s
[root@bastion-01 localvolume]#

PVはコンポーネント毎にinfra-0[1..3]上に3つ作成されています。

[root@bastion-01 localvolume]# oc get pv
NAME                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM                                             STORAGECLASS             REASON   AGE
image-registry-storage   100Gi      RWX            Retain           Bound       openshift-image-registry/image-registry-storage   image-registry                    44d
local-pv-13e978f0        40Gi       RWO            Delete           Available                                                     local-prometheusk8s               44s
local-pv-476b4e36        80Gi       RWO            Delete           Available                                                     local-elasticsearch               47s
local-pv-6a3a9d54        40Gi       RWO            Delete           Available                                                     local-prometheusk8s               44s
local-pv-6cb91dfa        10Gi       RWO            Delete           Available                                                     local-alertmanagermain            27s
local-pv-aec025c7        80Gi       RWO            Delete           Available                                                     local-elasticsearch               45s
local-pv-e646c476        40Gi       RWO            Delete           Available                                                     local-prometheusk8s               44s
local-pv-e7a740c6        80Gi       RWO            Delete           Available                                                     local-elasticsearch               47s
local-pv-f209ee07        10Gi       RWO            Delete           Available                                                     local-alertmanagermain            37s
local-pv-fc84cac         10Gi       RWO            Delete           Available                                                     local-alertmanagermain            38s
[root@bastion-01 localvolume]#

モニタリングとロギングの永続ボリュームの設定

作成したPVを使用するようにロギング、モニタリングを構成します。

モニタリング

先ほど作成したPVを使用するように、モニタリング設定用のConfigMapのマニフェストファイルを修正します。

修正前のモニタリング設定用のConfigMapのマニフェストファイルは「OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する / 運用コンポーネントのinfra nodeに移動 / モニタリング」に記載のものになります。

今回はprometheusK8sとalertmanagerMainのvolumeClaimTemplate.spec.storageClassNameに先ほどLocalVolumeリソースによって作成されたSC名を定義します。
今回はそんなにディスク容量を大きく取っていないのでretentionの日数は3dにしています。

[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# cp -p cluster-monitoring-configmap.yaml cluster-monitoring-configmap.yaml.bak.20220517
[root@bastion-01 monitoring]# vi cluster-monitoring-configmap.yaml
[root@bastion-01 monitoring]#

cluster-monitoring-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |+
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: local-alertmanagermain
          resources:
            requests:
              storage: 10Gi
    prometheusK8s:
      retention: 3d
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: local-prometheusk8s
          resources:
            requests:
              storage: 40Gi
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    grafana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""

作成したConfigMapのマニフェストファイルを適用します。

[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc apply -f cluster-monitoring-configmap.yaml
configmap/cluster-monitoring-config configured
[root@bastion-01 monitoring]#

設定内容が反映していることを確認します。

[root@bastion-01 monitoring]# oc get configmap -n openshift-monitoring cluster-monitoring-config -o yaml

apiVersion: v1
data:
  config.yaml: |
    alertmanagerMain:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: local-alertmanagermain
          resources:
            requests:
              storage: 10Gi
    prometheusK8s:
      retention: 3d
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      volumeClaimTemplate:
        spec:
          storageClassName: local-prometheusk8s
          resources:
            requests:
              storage: 40Gi
    prometheusOperator:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    grafana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    k8sPrometheusAdapter:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    kubeStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    telemeterClient:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    openshiftStateMetrics:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    thanosQuerier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"config.yaml":"alertmanagerMain:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\n  volumeClaimTemplate:\n    spec:\n      storageClassName: local-alertmanagermain\n      resources:\n        requests:\n          storage: 10Gi\nprometheusK8s:\n  retention: 3d\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\n  volumeClaimTemplate:\n    spec:\n      storageClassName: local-prometheusk8s\n      resources:\n        requests:\n          storage: 40Gi\nprometheusOperator:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\ngrafana:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\nk8sPrometheusAdapter:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\nkubeStateMetrics:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\ntelemeterClient:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\nopenshiftStateMetrics:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\nthanosQuerier:\n  nodeSelector:\n    node-role.kubernetes.io/infra: \"\"\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"cluster-monitoring-config","namespace":"openshift-monitoring"}}
  creationTimestamp: "2022-05-13T10:56:50Z"
  name: cluster-monitoring-config
  namespace: openshift-monitoring
  resourceVersion: "23356132"
  uid: a4c70d4f-d2ec-40e4-b60e-5be1bc6c903d

prometheus-k8sと、alertmanager-mainのPodがPVを使用するようになったかを確認します。
OCP 4.10では両方ともreplicasは「2」です。

[root@bastion-01 monitoring]# oc get statefulsets.apps -n openshift-monitoring
NAME                READY   AGE
alertmanager-main   2/2     2m6s
prometheus-k8s      2/2     2m11s
[root@bastion-01 monitoring]#

Podが再作成され、2つのinfra nodeで稼働しています。(今回はたまたま両方ともinfra-01、02で稼働しています。)

[root@bastion-01 monitoring]# oc get pod -n openshift-monitoring -o wide | grep prometheus-k8s
prometheus-k8s-0                              6/6     Running   0          3m9s    10.128.2.19     infra-02    <none>           <none>
prometheus-k8s-1                              6/6     Running   0          3m9s    10.131.0.59     infra-01    <none>           <none>
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc get pod -n openshift-monitoring -o wide | grep alertmanager-main
alertmanager-main-0                           6/6     Running   0          3m14s   10.128.2.20     infra-02    <none>           <none>
alertmanager-main-1                           6/6     Running   0          3m14s   10.131.0.60     infra-01    <none>           <none>
[root@bastion-01 monitoring]#

PVCがPodの数分作成され、PodにBoundされています。

[root@bastion-01 monitoring]# oc get pvc -n openshift-monitoring
NAME                                       STATUS   VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS             AGE
alertmanager-main-db-alertmanager-main-0   Bound    local-pv-fc84cac    10Gi       RWO            local-alertmanagermain   3m46s
alertmanager-main-db-alertmanager-main-1   Bound    local-pv-6cb91dfa   10Gi       RWO            local-alertmanagermain   3m46s
prometheus-k8s-db-prometheus-k8s-0         Bound    local-pv-13e978f0   40Gi       RWO            local-prometheusk8s      3m51s
prometheus-k8s-db-prometheus-k8s-1         Bound    local-pv-6a3a9d54   40Gi       RWO            local-prometheusk8s      3m51s
[root@bastion-01 monitoring]#

PVは、3つのうちPodが稼働している2つのinfra node上のPVがPVCにBoundされています。

[root@bastion-01 monitoring]# oc get pv | grep local-prometheusk8s
local-pv-13e978f0        40Gi       RWO            Delete           Bound       openshift-monitoring/prometheus-k8s-db-prometheus-k8s-0         local-prometheusk8s               34m
local-pv-6a3a9d54        40Gi       RWO            Delete           Bound       openshift-monitoring/prometheus-k8s-db-prometheus-k8s-1         local-prometheusk8s               34m
local-pv-e646c476        40Gi       RWO            Delete           Available                                                                   local-prometheusk8s               34m
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# oc get pv | grep local-alertmanagermain
local-pv-6cb91dfa        10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-1   local-alertmanagermain            34m
local-pv-f209ee07        10Gi       RWO            Delete           Available                                                                   local-alertmanagermain            34m
local-pv-fc84cac         10Gi       RWO            Delete           Bound       openshift-monitoring/alertmanager-main-db-alertmanager-main-0   local-alertmanagermain            34m
[root@bastion-01 monitoring]#

OCPのWebインターフェースでモニタリングの情報が取得できているかを確認します。
(OCP 4.10では、Grafanaのコンソールはまだ参照できますが、基本的にはOCPのWebインターフェースに統合されたモニタリングのダッシュボードを参照することが推奨です。)

ロギング

先ほど作成したPVを使用するように、ロギング設定用のClusterLoggingリソースのマニフェストファイルを修正します。

修正前のロギング設定用のClusterLoggingのマニフェストファイルは「OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する / 運用コンポーネントのinfra nodeに移動 / ロギング」に記載のものになります。

今回はこのelasticsearchのspec.logStore.elasticsearch.storage.storageClassNameに先ほどLocalVolumeリソースによって作成されたSC名を定義します。
今回はそんなにディスク容量を大きく取っていないのでretentionPolicyの日数は全indexとも1dにしています。

[root@bastion-01 ~]# cd work/manifest/monitoring/
[root@bastion-01 monitoring]#
[root@bastion-01 monitoring]# cp -p clo-instance-5.4-no-pv.yaml clo-instance-5.4-with-pv.yaml
[root@bastion-01 monitoring]# vi clo-instance-5.4-with-pv.yaml

clo-instance-5.4-with-pv.yaml

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
      application:
        maxAge: 1d
      infra:
        maxAge: 1d
      audit:
        maxAge: 1d
    elasticsearch:
      nodeCount: 3
      nodeSelector:
        node-role.kubernetes.io/infra: ''
      storage:
        storageClassName: local-elasticsearch
        size: 80G
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
      nodeSelector:
        node-role.kubernetes.io/infra: ''
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

作成したClusterLoggingのマニフェストファイルを適用します。

[root@bastion-01 ~]# cd work/manifest/logging/
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc apply -f clo-instance-5.4-with-pv.yaml
clusterlogging.logging.openshift.io/instance configured
[root@bastion-01 logging]#

設定内容が反映していることを確認します。

[root@bastion-01 logging]# oc get clusterlogging -n openshift-logging instance -o yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  annotations:
    (略)
  generation: 2
  name: instance
  namespace: openshift-logging
  resourceVersion: "23382994"
  uid: 57757036-7ab9-4327-b829-e215d0dd2445
spec:
  collection:
    logs:
      fluentd: {}
      type: fluentd
  logStore:
    elasticsearch:
      nodeCount: 3
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      redundancyPolicy: SingleRedundancy
      storage:
        size: 80G
        storageClassName: local-elasticsearch
    retentionPolicy:
      application:
        maxAge: 1d
      audit:
        maxAge: 1d
      infra:
        maxAge: 1d
    type: elasticsearch
  managementState: Managed
  visualization:
    kibana:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      replicas: 1
    type: kibana
status:
(略)

マニフェストファイル適用後には、何もしないとelasticsearchのPodは再作成されず、すぐにはPVを使用するようにはなっていませんでした。
(elasticsearch-cdm-xxxxxxの3つのDeploymentのPodが再作成されていない。)

[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator       1/1     1            1           22h
elasticsearch-cdm-hxg5zzyz-1   1/1     1            1           22h
elasticsearch-cdm-hxg5zzyz-2   1/1     1            1           22h
elasticsearch-cdm-hxg5zzyz-3   1/1     1            1           22h
kibana                         1/1     1            1           22h
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pod -n openshift-logging
NAME                                            READY   STATUS      RESTARTS        AGE
cluster-logging-operator-665847fd47-4k8nk       1/1     Running     2               22h
(略)
elasticsearch-cdm-hxg5zzyz-1-6c7cc986d5-r8vtk   2/2     Running     4               22h
elasticsearch-cdm-hxg5zzyz-2-6c459cd687-dd8kr   2/2     Running     4               22h
elasticsearch-cdm-hxg5zzyz-3-6c4c778db5-zttmd   2/2     Running     6               22h
(略)
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pv | grep local-elasticsearch
local-pv-476b4e36        80Gi       RWO            Delete           Available                                                                   local-elasticsearch               88m
local-pv-aec025c7        80Gi       RWO            Delete           Available                                                                   local-elasticsearch               88m
local-pv-e7a740c6        80Gi       RWO            Delete           Available                                                                   local-elasticsearch               88m
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME                                         STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS          AGE
elasticsearch-elasticsearch-cdm-hxg5zzyz-1   Pending                                      local-elasticsearch   3m16s
elasticsearch-elasticsearch-cdm-hxg5zzyz-2   Pending                                      local-elasticsearch   3m16s
elasticsearch-elasticsearch-cdm-hxg5zzyz-3   Pending                                      local-elasticsearch   3m16s
[root@bastion-01 logging]#

Podを再作成するためにはnodeCountを0にしてから3にもどしたり、OCP 4.10 Docs / 4.3.8. Elasticsearch クラスターのローリング再起動の実行の手順など、色々ちゃんと考えてやらないといけないような気がしますが、今回は単純にDeploymentを削除することで再作成しました。

[root@bastion-01 logging]# oc get deploy -n openshift-logging
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator       1/1     1            1           23h
elasticsearch-cdm-hxg5zzyz-1   1/1     1            1           22h
elasticsearch-cdm-hxg5zzyz-2   1/1     1            1           22h
elasticsearch-cdm-hxg5zzyz-3   1/1     1            1           22h
kibana                         1/1     1            1           22h
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc delete deploy -n openshift-logging elasticsearch-cdm-hxg5zzyz-1 elasticsearch-cdm-hxg5zzyz-2 elasticsearch-cdm-hxg5zzyz-3
deployment.apps "elasticsearch-cdm-hxg5zzyz-1" deleted
deployment.apps "elasticsearch-cdm-hxg5zzyz-2" deleted
deployment.apps "elasticsearch-cdm-hxg5zzyz-3" deleted
[root@bastion-01 logging]#

Operatorによって自動でDeploymentが再作成されます。

[root@bastion-01 logging]# oc get deploy -n openshift-logging
NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator       1/1     1            1           23h
elasticsearch-cdm-hxg5zzyz-1   1/1     1            1           2m49s
elasticsearch-cdm-hxg5zzyz-2   1/1     1            1           2m48s
elasticsearch-cdm-hxg5zzyz-3   1/1     1            1           2m47s
kibana                         1/1     1            1           22h
[root@bastion-01 logging]#

Podも再作成され、infra nodeで稼働しています。

[root@bastion-01 logging]# oc get pod -n openshift-logging -o wide
NAME                                            READY   STATUS      RESTARTS        AGE     IP            NODE        NOMINATED NODE   READINESS GATES
cluster-logging-operator-665847fd47-4k8nk       1/1     Running     2               23h     10.131.0.12   infra-01    <none>           <none>
(略)
elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd   2/2     Running     0               3m24s   10.128.2.21   infra-02    <none>           <none>
elasticsearch-cdm-hxg5zzyz-2-75464f4897-rdm89   2/2     Running     0               3m23s   10.131.0.73   infra-01    <none>           <none>
elasticsearch-cdm-hxg5zzyz-3-5cc5765cd4-g95ht   2/2     Running     0               3m22s   10.130.2.19   infra-03    <none>           <none>
(略)

PVCが全てPodにBoundされています。

[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME                                         STATUS   VOLUME              CAPACITY   ACCESS MODES   STORAGECLASS          AGE
elasticsearch-elasticsearch-cdm-hxg5zzyz-1   Bound    local-pv-476b4e36   80Gi       RWO            local-elasticsearch   9m33s
elasticsearch-elasticsearch-cdm-hxg5zzyz-2   Bound    local-pv-e7a740c6   80Gi       RWO            local-elasticsearch   9m33s
elasticsearch-elasticsearch-cdm-hxg5zzyz-3   Bound    local-pv-aec025c7   80Gi       RWO            local-elasticsearch   9m33s
[root@bastion-01 logging]#

PVは、Podが稼働している3つのinfra node上のPVがPVCにBoundされています。

[root@bastion-01 logging]# oc get pv | grep local-elasticsearch
local-pv-476b4e36        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-1    local-elasticsearch               94m
local-pv-aec025c7        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-3    local-elasticsearch               94m
local-pv-e7a740c6        80Gi       RWO            Delete           Bound       openshift-logging/elasticsearch-elasticsearch-cdm-hxg5zzyz-2    local-elasticsearch               94m
[root@bastion-01 logging]#

最後にelasticsearchのクラスターのステータスを確認します。
elasticsearchのPodが全てRunningになっていることを確認します。

[root@bastion-01 logging]# oc get pod -n openshift-logging --selector component=elasticsearch
NAME                                            READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd   2/2     Running   0          8m1s
elasticsearch-cdm-hxg5zzyz-2-75464f4897-rdm89   2/2     Running   0          8m
elasticsearch-cdm-hxg5zzyz-3-5cc5765cd4-g95ht   2/2     Running   0          7m59s
[root@bastion-01 logging]#

またelasticsearchのstatusがgreenになっていることを確認します。

[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- health
Fri May 17 09:40:21 UTC 2022
epoch      timestamp cluster       status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1655462421 09:40:21  elasticsearch green           3         3     20  10    0    0        0             0                  -                100.0%
[root@bastion-01 logging]#

[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- es_cluster_health
{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 10,
  "active_shards" : 20,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}
[root@bastion-01 logging]#

indexも全てgreenになっていることを確認します。

[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- indices
Tue May 17 09:55:26 UTC 2022
health status index        uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   app-000001   weU8Atv-RyShO7CyoBnhjw   3   1          0            0          0              0
green  open   infra-000001 vE6uVwM3SAGvKNCOQ4J45g   3   1      11579            0         19             10
green  open   audit-000001 ktPf9mp3RVev6R7QyrZ8Bg   3   1          0            0          0              0
green  open   .security    _kf4-56uRfK9FVFK-vGVCw   1   1          6            0          0              0
[root@bastion-01 logging]#
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-hxg5zzyz-1-5f58bc7c98-7fvmd -- es_util --query=_cat/indices?
green open app-000001   weU8Atv-RyShO7CyoBnhjw 3 1     0 0  1.5kb 783b
green open infra-000001 vE6uVwM3SAGvKNCOQ4J45g 3 1 12731 0 24.1mb 11mb
green open audit-000001 ktPf9mp3RVev6R7QyrZ8Bg 3 1     0 0  1.5kb 783b
green open .security    _kf4-56uRfK9FVFK-vGVCw 1 1     6 0 66.1kb 33kb
[root@bastion-01 logging]#

Kibana

elasticsearchのDeploymentを削除してPodを作り直すと、Kibanaの画面でログがQuery出来なくなることがあります。
そのような場合には、KibanaのPodも再作成すると良いかもしれません。

KibanaのPodを再作成します。

[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
kibana   1/1     1            1           38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc scale -n openshift-logging --replicas=0 deployment/kibana
deployment.apps/kibana scaled
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
kibana   0/1     1            0           38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc scale -n openshift-logging --replicas=1 deployment/kibana
deployment.apps/kibana scaled
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get deploy -n openshift-logging kibana
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
kibana   1/1     1            1           38h
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get pod -n openshift-logging | grep kibana
kibana-95cdccd9b-7xmpx                          2/2     Running     0             57s
[root@bastion-01 ~]#

Kibanaのコンソールにログインします。
OCPのWebコンソールの右上のApplication Launcherのアイコンをクリックし「Logging」を選択します。

ログイン画面が表示された場合は適宜OCPの管理者ユーザーでログインします。
KibanaのPodを再作成したので、index patternを再作成する必要があります。
今回はinfraとappのindexのログを表示できるように「infra*」、「app*」というindex patternを作成しました。

左側のManagementからCreate index patternをクリックし、Index patternフィールドに「infra*」を入力して「Next step」をクリックします。

Time Filter field nameとして「@timestamp」を選択し、「Create index pattern」をクリックします。

index pattern作成後、左側のメニューから「Discover」を選択すると、作成したindex patternのログが表示されました。
LocalVolumeによるPVを使用し始めた時間からのログが取得できていることがわかります。

補足

今回はlocal-storage operatorだけを使用してロギング、モニタリングのPVを作成しました。
ただ、環境が準備できる場合は、OpenShift Data Foundationを使ってPVを用意した方がより良いと思います。
こちらについては別途やったら記載しようと思います。