概要
OCP 4.10環境で、Local Storage Operatorを使用して、ロギング、モニタリングの永続ボリューム(PV)を作成した際のメモを記載します。
ロギング、モニタリングのPVはブロックボリュームが推奨です。
ブロックスボリュームのサポートは以下のようなものがあります。
オンプレで検証環境を作る際には、CIS対応のストレージ製品がなかったり、OpenShift Data Foundationを構成するためのスペックのnodeまでは用意できない場合もあります。また、検証環境のvCenterの管理者ユーザーを使用させてもらえずvSphereのCSIドライバーのPVも使用できなかったりで、ブロックボリュームのPVを準備するのがなかなか難しいことがあります。
そのような場合でも、local-storage operatorを使用すると、オンプレミスでブロックボリュームのPVを作成することができます。
今回は、local-storage operatorのLocalVolumeリソースによるブロックボリュームのPVを使用して、ロギング、モニタリングを構成する手順のメモを記載します。
構成
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になります。
また、以下を参照すると、Prometheusメトリクスデータの保持期間はデフォルトでは15日です。
今回は検証環境でノード数も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 リリースノート参照
今回のように、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は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.yamlspec: 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コンソールからインストールしました。
- OCP 4.10 Docs / ストレージ / 4. Configuring persistent storage / 4.10. ローカルボリュームを使用した永続ストレージ
- OCP 4.10 Docs / ストレージ / 4. Configuring persistent storage / 4.10. ローカルボリュームを使用した永続ストレージ / 4.10.1. ローカルストレージ Operator のインストール
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の設定を入れる必要があります。
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リソースの作成
マニフェストファイル作成
マニフェストファイルを作成する作業ディレクトリに移動します。
[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を指定します。
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を指定します。
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を指定します。
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を使用するようにロギング、モニタリングを構成します。
モニタリング
- OCP 4.10 Docs / スケーラビリティーおよびパフォーマンス / 8. CLUSTER MONITORING OPERATOR のスケーリング / 8.1. Prometheus データベースのストレージ要件
- OCP 4.10 Docs / モニタリング / 2. モニタリングスタックの設定 / 2.8. 永続ストレージの設定
- OCP 4.10 Docs / モニタリング / 2.8. 永続ストレージの設定 / 2.8.2. ローカ永続ボリューム要求 (PVC）の設定
- OCP 4.10 Docs / モニタリング / 2.8. 永続ストレージの設定 / 2.8.3. Prometheus メトリクスデータの保持期間の変更
先ほど作成した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]#
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インターフェースに統合されたモニタリングのダッシュボードを参照することが推奨です。)
ロギング
- 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. ログストアの永続ストレージの設定
先ほど作成した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
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を用意した方がより良いと思います。
こちらについては別途やったら記載しようと思います。