概要

OpenShift (以下OCP)のロギング 5.5で、LokiStackがGAになっていました。

OCP 4.11 Docs / ロギング / 1. ロギングのリリースノート / 1.5. Logging 5.5 / 1.5.1. 機能拡張

今回の更新では、'LokiOperator' Operator および Vector コレクターがテクニカルプレビュー機能から一般提供機能 (GA) に移行します。以前のリリースとの完全な機能パリティーに関しては作業中で、一部の API はテクニカルプレビュー機能のままです。詳細については LokiStack を使用したロギングのセクションを参照してください。

また、Logging 5.3のリリースノートで、Elasticsearch Operatorは非推奨となり、今のところ時期はわかりませんが、将来的には削除されていくようです。

OCP 4.11 Docs / ロギング / 1. ロギングのリリースノート / 1.10. Logging 5.4.3 / 1.10.1. Elasticsearch Operator の非推奨通知

1.10.1. Elasticsearch Operator の非推奨通知
logging サブシステム 5.4.3 では、Elasticsearch Operator は非推奨となり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

(補足) ライフサイクルポリシーの方には、特に関連した記載はなさそうでした。

Red Hat OpenShift Container Platform Life Cycle Policy / OpenShift Logging

今までロギングとしてOpenShift Elasticsearch Operatorと、Red Hat OpenShift Logging Operatorを使用してEFKスタックを導入していた人にとって、いつかは移行する必要があるかもしれません。
永続ボリューム(PV)をLocal Storage Operatorのみで構成していたような人とかも対応が必要です。

Lokistackでは、前提として、オブジェクトストレージが必要ですが、オンプレミスではオブジェクトストレージを用意するのはなかなか大変です。

そこで、ベアメタル UPIの方法でオンプレミスにOCPを導入している環境で、オブジェクトストレージとして新規にOpenShift Data Foudation (ODF)をインストールしてみました。(minioとかでも良いみたいですが、サポートのあるODFを使用しました。)

今回は、そのODFで作成したオブジェクトストレージを使用して、LokiStack + Vectorを導入してみたのでその際のメモを記載します。

((注)ちなみにオブジェクトストレージは必要なのですが、幾つかのコンポーネントでBlock(volumeMode: Filesystem)の永続ボリュームも合わせて作成されていました。ですので、なおさら、ODFが必要なのかなと思います。)

今回は、検証時に最新だったLogging ５.5.5 を使用しています。

OCP

OCP	version	notes
OCP	4.11.16

Operators

Operator	version	notes
Local Storage	4.11.0	For Storage (Prerequise of ODF on on-pre env)
OpenShift Data Foundation	4.11.4	For Storage (Block and Object)
Loki Operator	5.5.5	For Logging (Lokistack)
Red Hat OpenShift Logging	5.5.5	For Logging (ClusterLogging and Vector)

参考リンク

LokiStack

OpenShift Data Foudation (ODF)

ODF 4.11 Docs

OpenShift Data Foudation (ODF) - (MultiCloud Gateway (MCG))

Loki Document

Loki + ODF の場合の設定例

Lokiのコンポーネントの概要

Grafana Loki / Fundamentals / Architecture / Components

その他参考

検証環境

OCP構成

今回の検証環境の、OCPクラスタの構成は、以下のリンク先でインストールしたOCP 4.11 の構成となります。

(参考) Qiita / OpenShift 4.10 ベアメタルUPI (iPXE) インストール

OCP 4.10をベアメタルのUPIでインストールしています。
ベアメタルのUPIの構成ですが、node自体はVMwareの仮想マシンで作成しています。
その後、OCP 4.10からOCP 4.11にアップデートした環境を使用します。

[root@bastion-01 ~]# oc version
Client Version: 4.11.16
Kustomize Version: v4.5.4
Server Version: 4.11.16
Kubernetes Version: v1.24.6+5157800
[root@bastion-01 ~]#

Infra node

Infra nodeは以下の手順で作成しています。
OCP内部レジストリ、ルーター、モニタリング、ロギングの運用コンポーネント用をInfra nodeで稼働させています。

Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成する

ODF

OpenShift Data Foudation (ODF)は、ODF専用のInfra nodeに導入し、ODFクラスタを作成しています。

Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールする

ノード構成

Infra node専用のMCPを作成しています。

[root@bastion-01 ~]# oc get mcp
NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
infra    rendered-infra-bd0eb2d6bddaa13bd9a1fe95217a0e88    True      False      False      6              6                   6                     0                      149d
master   rendered-master-60815c158d00703013c8ffa0f9090be0   True      False      False      3              3                   3                     0                      149d
worker   rendered-worker-bd0eb2d6bddaa13bd9a1fe95217a0e88   True      False      False      2              2                   2                     0                      149d
[root@bastion-01 ~]#

Infra nodeとして、運用コンポーネント(内部レジストリ、ルーター、モニタリング、ロギング)用のInfra nodeと、ODF専用のInfra node (storage node)を作成しています。

[root@bastion-01 ~]# oc get node
NAME         STATUS   ROLES    AGE    VERSION
infra-01     Ready    infra    149d   v1.24.6+5157800        # Infra node (運用コンポーネント用)
infra-02     Ready    infra    149d   v1.24.6+5157800        # 同上
infra-03     Ready    infra    149d   v1.24.6+5157800        # 同上
master-01    Ready    master   149d   v1.24.6+5157800        # Master node
master-02    Ready    master   149d   v1.24.6+5157800        # 同上
master-03    Ready    master   149d   v1.24.6+5157800        # 同上
storage-01   Ready    infra    3d2h   v1.24.6+5157800        # Infra node (ODF専用) 
storage-02   Ready    infra    3d2h   v1.24.6+5157800        # 同上
storage-03   Ready    infra    3d2h   v1.24.6+5157800        # 同上
worker-01    Ready    worker   149d   v1.24.6+5157800        # Worker node
worker-02    Ready    worker   149d   v1.24.6+5157800        # 同上
[root@bastion-01 ~]#

Operator

事前に以下のバージョンのOperatorを導入しています。

(上述のInfra node欄、ODF欄の(参考)のリンクの中で導入していました。Operatorの導入手順はそちらをご参照ください。)

Operator	Channel	更新承認ストラテジー	CSV	備考
Local Storage	`stable`	Manual	`local-storage-operator.4.11.0-202211072116`
OpenShift Data Foundation	`stable-4.11`	Manual	`odf-operator.v4.11.4`

Operator	Channel	更新承認ストラテジー	CSV	備考
Red Hat OpenShift Logging	`stable-5.5`	Manual	`cluster-logging.5.5.5`	以前は`Cluster Logging Operator`という名称だったが変更されたもの
(※)OpenShift Elasticsearch Operator	`stable-5.5`	Manual	`elasticsearch-operator.5.5.5`	(すでに導入されていたが今回は不要。新規の場合は導入不要。)

(補足)

ロギングとして、「OpenShift Elasticsearch Operator」と、「Cluster Logging Operator」は、Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成するのロギングの方法で導入していました。
その時点では elasticsearch-operator.5.4.2 ( stable-5.4 Channel)と cluster-logging.5.4.2 ( stable-5.4 Channel)を導入していたので、検証時点では、その時点で最新 elasticsearch-operator.5.5.5 ( stable-5.5 Channel)と cluster-logging.5.5.5 (stable-5.5 Channel)にアップデートしています。
(手順は OCP 4.11 Docs / ロギング / 11. OpenShift Logging について / 11.2. Logging を現在のバージョンに更新するに記載があるので、ここでは割愛します。)

今回は、この記事の手順の中で、「Loki Operator」を Infra node (運用コンポーネント用) にデプロイします。

Operator	Channel	更新承認ストラテジー	CSV	備考
Loki Operator	`stable-5.5`	Manual	`loki-operator.5.5.5`

手順の流れ

ベアメタルUPIのOCPに、ODFを導入してODFクラスタを作成します。

ODFクラスタから、LokiStack用のオブジェクトバケットを作成し、LokiStackとClusterLoggingをデプロイします(Loki + Vector)。

今回は LokiStack は Infra node (運用コンポーネント用) にデプロイします。

手順の流れは以下になります。

(事前準備)

(1) 既存のロギングサブシステム(Elasticsearch、Fluentd、Kibana)のアンインストール

前提の確認

(1) デプロイメントのサイズ

ODFクラスタの作成

(1) ODFクラスタの作成

オブジェクトストレージの準備

(1) バッキングストアの作成
(2) バケットクラスの作成
(3) Object Bucket Claimの作成
(4) オブジェクトバケット接続用のSecretの作成

LokiStackのデプロイ

(1) Loki Operatorの導入
(2) LokiStackカスタムリソースの作成
(3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化)
(4) ログコンソールプラグインの有効化

実際の手順

(事前準備)

(1) 既存のロギングサブシステム(Elasticsearch、Fluentd、Kibana)のアンインストール

必要に応じて、すでに導入していたロギングサブシステム(Elasticsearch、Fluentd、Kibana)をアンインストールします。

また、Elasticsearch用のPVも削除します。

(今回の環境では、(せっかく導入しているのにまだODFのPVを使っておらず)、Local Storage OperatorでPVを作成していたので、必要に応じてLocalVolumeリソースを削除することになります。)

この場合の流れは以下になります。

ClusterLoggingリソースの削除
- Kind: ClusterLogging (LogStore: elasticsearch、visualization: kibana, collection: fluentd)
Operatorの削除(Elasticsearch Operator)
- (Elasticsearch Operatorは必要に応じて削除してください。)
- (※) Cluster Logging Operatorは、この後も使用するので削除しません。
PVCの削除(Elasticsearch用)
LocalVolume(Elasticsearch用)、PV (Elasticsearch用)の削除
- (※) Local Storage Operatorも、ODFで使用しているので、削除しないこと。

手順自体は以下のリンクに記載があるので、ここでは割愛します。

前提の確認

(1) デプロイメントのサイズ

サイジングの指標は以下に記載があります。

Lokiのサイズは、1x.extra-small、1x.small、1x.mediumのあります。

1x.extra-smallはデモ用でサポートされない、とのことなので、今回は1x.smallを導入することにしました。

OCP 4.11 Docs / ロギング / 5. Loki / 5.1. LokiStack / 5.1.1. デプロイメントのサイズ

	1x.extra-small	1x.small	1x.medium
Data transfer	Demo use only.	500GB/day	2TB/day
Queries per second (QPS)	Demo use only.	25-50 QPS at 200ms	25-75 QPS at 200ms
Replication factor	None	2	3
Total CPU requests	5 vCPUs	36 vCPUs	54 vCPUs
Total Memory requests	7.5Gi	63Gi	139Gi
Total Disk requests	150Gi	300Gi	450Gi

1x.smallなので、レプリカ数が2のようです。

レプリカ数が2だと、Infra node x2 で、Total CPU requests と Total Memory requestsを賄えば良いのか？と思えますので、Infra node 1台あたり、18 vCPUs、32Gi Memoryが必要？かもしれません。

ディスクはODFから賄うので1TB使えるので大丈夫と思われます。

また元々のInfra nodeのサイジングも併せて検討する必要があります。

OCP 4.11 Docs / スケーラビリティーおよびパフォーマンス / 2. ホストについての推奨されるプラクティス / 2.11. インフラストラクチャーノードのサイジング

これらを合わせると、Infra node 1台当たり 24 vCPU、48 GBに一旦してみました。

(ちょっと大きすぎて検証環境的にはなかなか厳しい・・・本当にこんなに必要なのか・・・？)

(RHCOSのシステム領域のDiskは40GBは最小要件を満たしていないですが、これは検証環境のリソース的にとりあえず稼働するので元から少なくしていますので無視して下さい。)

(変更前)

Server	vCPU	Memory	Disk	Disk2	notes
infra #1	8	48GB	40GB		infra node
infra #2	8	48GB	40GB		infra node
infra #3	8	48GB	40GB		infra node
storage #1	16	32GB	40GB	1024GB	infra node (for ODF)
storage #2	16	32GB	40GB	1024GB	infra node (for ODF)
storage #3	16	32GB	40GB	1024GB	infra node (for ODF)

(変更後)

Server	vCPU	Memory	Disk	Disk2	notes
infra #1	24	48GB	40GB		infra node
infra #2	24	48GB	40GB		infra node
infra #3	24	48GB	40GB		infra node
storage #1	16	32GB	40GB	1024GB	infra node (for ODF)
storage #2	16	32GB	40GB	1024GB	infra node (for ODF)
storage #3	16	32GB	40GB	1024GB	infra node (for ODF)

(補足)

最終的にやってみてわかったことですが、オブジェクトストレージ以外に、Lokiの幾つかのコンポーネントでBlock (volumeMode: Filesystem)のPVCがさ作成されていました。

(ODFのocs-storagecluster-ceph-rbdのストレージクラスを指定して動的に作成)

ですので、オブジェクトストレージだけで300Gなのか、それらも合わせて300Gなのかはちょっと分かりませんでした。。

一応、今回はログ保管領域としてのオブジェクトストレージはLoki専用に300GiB のバッキングストアを作成しました。
これに加えて自動で作成される永続ボリュームを合わせて、最終的にはストレージとしては以下のものができていました。

オブジェクトストレージ

バッキングストア	size	notes
Loki用バッキングストア	300GiB	最小要件は300GiBだが、念の為少し余裕を持って400GiBなどとかも要検討

永続ボリューム(Block (volumeMode: Filesystem))

(ODFのocs-storagecluster-ceph-rbdのストレージクラスを指定して動的に作成)
合計 430GiB

Loki's component	Statefulset name	replicas	PVC name	size
Ingester	logging-lokistack-ingester	2	storage-logging-lokistack-ingester-[0,1]	10 x2 = 20GiB
			wal-logging-lokistack-ingester-[0,1]	150 x2 = 300GiB
Index Gateway	logging-lokistack-index-gateway	2	storage-logging-lokistack-index-gateway-[0,1]	50 x2 = 100 GiB
Compactor	logging-lokistack-compactor	1	storage-logging-lokistack-compactor-0	10 x1 GiB = 10GiB

合計

オブジェクトストレージ 300GiB + 永続ボリューム 430GiB = 730GiB ...
かなり大きい。。

実際には、PVの方はそこまで容量を使用していないようだったので本当はここまで必要ないのかもしれません。
但し、volumeClaimTemplatesは、Operator側で自動で指定されているため自動で作成されてしまいます。また変更方法はわかりませんでした。。

ですので、1x.smallを選んだ際はそこそこディスクの容量が必要ということを覚悟しておく必要はあるかなと思います。

今回は Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールするで、1TBのストレージを作成していたので、これらの容量を賄えていました。

ODFクラスタの作成

(1) ODFクラスタの作成

OpenShift Data Foudation (ODF)は、ODF専用のInfra nodeに導入し、ODFクラスタを作成しました。

構成は以下のリンク先の通りとなります。

Qiita / ベアメタルUPIのOpenShift (OCP) 4.11に、OpenShift Data Foudation (ODF)をインストールする

オブジェクトストレージの準備

(1) バッキングストアの作成

ODFではデフォルトでnoobaa-default-backing-storeというバッキングストアが作成されていましたが、今回はLoki専用にloki-backingstoreという名前のバッキングストアを作成しておくことにします。

(補足)ODFのMultiCloud gateway(MCG)を使用すると、ローカルのPVをバックエンドにオブジェクトストレージのバケットを提供できる、というのは、赤帽ブログ / OpenShiftにおけるMultiCloud Gateway(MCG)とレジストリの説明が分かりやすかったです。

今回はバッキングストアはOCPコンソールから作成しました、設定値の説明としては、以下が参考になります。

ODF 4.11 Docs / 4. ハイブリッドまたはマルチクラウド用のストレージリソースの追加 / 4.2. MCG コマンドラインインターフェースを使用したハイブリッドまたはマルチクラウドのストレージリソースの追加 / 4.2.5. ローカル永続ボリュームでサポートされるバッキングストアの作成

(抜粋)

設定箇所	内容	notes
`spec.type`	pv-pool
`spec.pvPool.numVolumes`	`<NUMBER OF VOLUMES>`	作成するボリューム数に置き換えます。ボリュームの数を増やすと、ストレージが拡大することに注意してください。
`spec.pvPool.resources.requests.storage`	`<VOLUME SIZE>`	各ボリュームに必要なサイズ (GB 単位) に置き換えます。文字`G`はそのままにする必要があることに注意してください。
`spec.pvPool.storageClass`	`<LOCAL STORAGE CLASS>`	ローカルストレージクラスに置き換えます。これは、`ocs-storagecluster-ceph-rbd` を使用する際に推奨されます。

サイジングのところで見たように、300GiBにしようとする場合、ボリュームのサイズと数は、以下のような選択肢があると思われます。

300Gi x 1
100Gi x 3
...

一応、100Giづつ増やせた方が柔軟性があるかな、と思い、今回は100Gi x3 で作成してみました。

以降の作業は全てcluster-adminロールのあるユーザーでログインして実行しています。

OCPコンソールの左側のメニューから、ストレージ -> Data Foundation 画面の「バッキングストア」タブを選択し、「作成 Backing Store」をクリックします。

「新規バッキングストアの作成」画面で以下の値を入力し、「バックバックストアの作成」をクリックします。

field	default	設定値	notes
バッキングストア名	blank	`loki-backingstore`	任意の名前
プロバイダー	AWS S3	PVC	MCG経由で利用するオブジェクトストレージのバックエンドとしてODFのPVを使用するための設定
ボリューム数	1	3
ボリュームのサイズ	50 GiB Unit	100 GiB Unit	100GiB x 3 で 300GiB
blank field (storage class)	blank	`ocs-storagecluster-ceph-rbd`	`spec.pvPool.storageClass`の説明で推奨とあった`ocs-storagecluster-ceph-rbd`を指定

「バッキングストア」タブで作成したloki-backingstoreのエントリーが追加されたことを確認します。

[root@bastion-01 ~]# oc get backingstore -n openshift-storage
NAME                           TYPE            PHASE   AGE
loki-backingstore              pv-pool         Ready   2m27s
noobaa-default-backing-store   s3-compatible   Ready   35m
[root@bastion-01 ~]#

(補足)
pvPoolで指定したocs-storagecluster-ceph-rbdのストレージクラスから、100GiBのPVが3つ作成されています。

(ここではやっていませんが、例えばボリューム数(spec.pvPool.numVolumes)を4に変更すると、100GiBのPVがもう一つ追加されてバッキングストアの容量が大きくなるようです。)

[root@bastion-01 ~]# oc get pvc -n openshift-storage
NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
db-noobaa-db-pg-0                        Bound    pvc-c437bda3-1431-4124-82ae-662ee2a54a33   50Gi       RWO            ocs-storagecluster-ceph-rbd   37m
loki-backingstore-noobaa-pvc-3fea5969    Bound    pvc-a5937d8a-6bbb-4914-b8c9-cccf3048f87e   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
loki-backingstore-noobaa-pvc-40a78edf    Bound    pvc-43fca63a-21cf-4b88-936b-bec1fa58a027   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
loki-backingstore-noobaa-pvc-933a9ff4    Bound    pvc-63859b3f-ad89-4470-a481-e9bfaf5aaa03   100Gi      RWO            ocs-storagecluster-ceph-rbd   2m41s
ocs-deviceset-localblock-0-data-022zww   Bound    local-pv-6b3c4558                          1Ti        RWO            localblock                    38m
ocs-deviceset-localblock-0-data-1mpknn   Bound    local-pv-d94c27a1                          1Ti        RWO            localblock                    38m
ocs-deviceset-localblock-0-data-2mz7zn   Bound    local-pv-faa39169                          1Ti        RWO            localblock                    38m
[root@bastion-01 ~]#

(注)3つのPVCを使用しているPodが全て同じnode上にいました...。これは設定をする箇所が見当たらなかったので一旦このままにしています。

[root@bastion-01 ~]# oc get pod -n openshift-storage -o wide | grep loki-backingstore
loki-backingstore-noobaa-pod-3fea5969                             1/1     Running     0             4m31s   10.130.4.23     storage-03   <none>           <none>
loki-backingstore-noobaa-pod-40a78edf                             1/1     Running     0             4m31s   10.130.4.24     storage-03   <none>           <none>
loki-backingstore-noobaa-pod-933a9ff4                             1/1     Running     0             4m31s   10.130.4.25     storage-03   <none>           <none>
[root@bastion-01 ~]#

(2) バケットクラスの作成

バケットクラスの作成をします。

ODF 4.11 Docs / 4. ハイブリッドまたはマルチクラウド用のストレージリソースの追加 / 4.4. 新規バケットクラスの作成

OCPコンソールの左側のメニューから、ストレージ -> Data Foundation 画面の「バケットクラス」タブを選択し、「作成 Bucket Class」をクリックします。

「新規バケットクラスの作成」ウィザードの「一般」セクションで以下を指定して「次へ」をクリックします。

field	default	設定値	notes
バケットクラスのタイプ	標準	標準	標準/namespace。Multicloud Object Gateway (MCG)の場合は標準を指定
バケットクラス名	blank	`loki-bucket-class`	任意のバケットクラス名
説明(オプション)	blank	blank

「配置ポリシー」セクションで以下を指定して「次へ」をクリックします。

field	default	設定値	notes
階層1 - ポリシータイプ	分散	分散	分散/ミラー。バッキングストアが1つの場合はとりあえず分散にしておく必要がある模様
階層の追加	-	-	バッキングストアは1つなので何も指定しない

「リソース」セクションでは以下を指定して「次へ」をクリックします。

field	default	設定値	notes
階層1 - バッキングストア (Spread)
1つ以上のバッキングストアリソースの選択	blank	`loki-backingstore` にチェック	作成した`loki-backingstore`とODFのデフォルトの`noobaa-default-backing-store`があったが、今回は作成したものだけ指定

「確認」セクションで確認をして「バケットクラスの作成」をクリックします。

バケットクラスが作成されたことを確認します。

(3) Object Bucket Claimの作成

作成したバッキングストアのバケットクラスを使用して、Lokiで使用するバケット(Object Bucket Claim)を作成します。

ODF 4.11 Docs / ハイブリッドおよびマルチクラウドリソースの管理 / 10. Object Bucket Claim（オブジェクトバケット要求） / 10.3. OpenShift Web コンソールを使用した Object Bucket Claim（オブジェクトバケット要求）の作成

OCPコンソールの左側のメニューから、ストレージ -> Object Bucket Claims を選択し、表示された「ObjectBucketClaims」画面を表示します。

左上のプルダウンから、ObjectBucketClaimを作成するNamespace(Project)を指定します。

バケットはLokistackからしか使用しないのでopenshift-logging namespaceに作成するのが良いのか、一応ストレージ用のopenshift-storage namespaceに作成した方が良いのか悩みましたが、openshift-storage以外を指定した際にどこかの画面で何かの情報が拾えなかった？気がしたので、今回はopenshift-storage namespaceを指定してみました。(気のせいかもしれません。)

プロジェクトをopenshift-storageを指定したら、「オブジェクトバケット要求の作成」をクリックします。

「オブジェクトバケット要求の作成」画面で以下を指定して「作成」をクリックします。

ストレージクラスは、上述リンクのドキュメントに「openshift-storage.noobaa.io は Multicloud Object Gateway (MCG) を使用します。」と書いてて、今回はMCG経由でバケットを作成するので、openshift-storage.noobaa.ioを指定しました。

field	default	設定値	notes
オブジェクトバケット要求の名前	blank	`loki-object-bucket`	任意の名前でバケットのprefixになってた
ストレージクラス	blank	`openshift-storage.noobaa.io`	候補として`openshift-storage.noobaa.io`と`ocs-storagecluster-ceph-rgw`が表示されるが、MCGを使用するので`openshift-storage.noobaa.io`を選択
バケットクラス	blank	`loki-bucket-class`	先ほど作成したバケットクラス名を指定

オブジェクトバケット要求が作成されたことを確認します。

画面下部の「オブジェクトバケット要求データ」のEndpointや、Bucket Name、Access Key、Secret Keyの情報を指定して、このバケットを使用することができるようになります。
右側の「値を表示する」をクリックして、Endpint、Bucket Name、Access Key、Secret Keyの値を控えておきます。

(4) オブジェクトバケット接続用のSecretの作成

Lokiから作成したオブジェクトバケットに使用するために、このバケットのEndpointや、Bucket Name、Access Key、Secret Key 情報を含んだSecretを作成します。

OCPのドキュメントには、AWS S3用のSecretの例しか記載がありませんでした。。

OCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイ

以下の、Loki Operatorのドキュメントには、ODFで作成したバケットを使用する場合のSecretの作成方法が記載されていたので、今回はそちらを参考にSecretを作成します。

Loki Operator Docs / LOKISTACK / Object Storage / OpenShift Data Foudation

Secretをコマンドで作成する例しか載っていませんが、指定するKeyは載っているのでSecretのマニフェストファイルを作成してこれを適用します。

(注)一点だけ、bucketnameのKeyだけは、OCPのドキュメントのS3の例にあるbacketnamesと複数形でないといけなかったです。。。どっちも情報不足でなかなかハードルが高い。。。

[root@bastion-01 logging]# vi secret-loki-object-bucket.yaml
[root@bastion-01 logging]# cat secret-loki-object-bucket.yaml

Secretの名前は任意なので今回はloki-object-bucketとしておきました。

apiVersion: v1
kind: Secret
metadata:
  name: loki-object-bucket
  namespace: openshift-logging
stringData:
  access_key_id: "xxxxxxxxxxxxxxxxx"                                     # 作成したオブジェクトバケット要求の`Access Key`の値
  access_key_secret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"          # 作成したオブジェクトバケット要求の`Secret Key`の値
  bucketnames: "loki-object-bucket-xxxxxxx-xxxx-xxxxx-xxxx-xxxxxxxxxx"   # 作成したオブジェクトバケット要求の`Bucket Name`の値 (注)Keyは`bucketnames`
  endpoint: "https://s3.openshift-storage.svc:443"             # (注)作成したオブジェクトバケット要求の`Endoint`の値を`https://<Endpoint>:443`としたURLを記載

Secretのマニフェストを適用します。

oc apply -f secret-loki-object-bucket.yaml
oc get secret -n openshift-logging

(出力例)

[root@bastion-01 logging]# oc apply -f secret-loki-object-bucket.yaml
secret/loki-object-bucket created
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get secret -n openshift-logging
NAME                                       TYPE                                  DATA   AGE
builder-dockercfg-pzl47                    kubernetes.io/dockercfg               1      176d
builder-token-c72mt                        kubernetes.io/service-account-token   4      176d
builder-token-lf7m7                        kubernetes.io/service-account-token   4      176d
cluster-logging-operator-dockercfg-lz7sp   kubernetes.io/dockercfg               1      176d
cluster-logging-operator-token-7bwmn       kubernetes.io/service-account-token   4      176d
cluster-logging-operator-token-7zcpm       kubernetes.io/service-account-token   4      176d
default-dockercfg-29s4l                    kubernetes.io/dockercfg               1      176d
default-token-n7xdb                        kubernetes.io/service-account-token   4      176d
default-token-qg2p5                        kubernetes.io/service-account-token   4      176d
deployer-dockercfg-fkz4p                   kubernetes.io/dockercfg               1      176d
deployer-token-trvxd                       kubernetes.io/service-account-token   4      176d
deployer-token-zb7cl                       kubernetes.io/service-account-token   4      176d
loki-object-bucket                         Opaque                                4      16s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get secret -n openshift-logging loki-object-bucket
NAME                 TYPE     DATA   AGE
loki-object-bucket   Opaque   4      30s
[root@bastion-01 logging]#

LokiStackのデプロイ

LokiStack用のオブジェクトストレージのバケットの準備ができたので、LokiStackを使用してCluster Loggingのインスタンスを作成します。

(なお、前述したように、LokiStackの幾つかのコンポーネントはオブジェクトストレージだけでなく、volumeMode: Filesystemの永続ボリュームも使用)

(1) Loki Operatorの導入

Loki Operatorをインストールします。

OCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイ

Operator	Channel	更新承認ストラテジー	CSV	備考
Loki Operator	`stable-5.5`	Manual	`loki-operator.5.5.5`

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

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

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

「Operatorのインストール」ページで、「クラスター指定のnamespace」を選択します。デフォルトのopenshift-operators-redhatが表示されており、存在しない場合は自動で作成されます。

その他、「インストールモード」や「更新の承認」などは以下のように設定しました。
設定をしたら「インストール」をクリックします。

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

「承認」をクリックします。

openshift-operators-redhat namespaceにLoki Operatorがインストールされたことを確認します。

[root@bastion-01 ~]# oc get pod -n openshift-operators-redhat -o wide
NAME                                               READY   STATUS    RESTARTS   AGE    IP            NODE        NOMINATED NODE   READINESS GATES
elasticsearch-operator-7dcf99db4d-v2w99            2/2     Running   16         24d    10.131.0.2    worker-02   <none>           <none>
loki-operator-controller-manager-b976b54dc-kmvsc   2/2     Running   0          3m6s   10.128.2.27   infra-02    <none>           <none>
[root@bastion-01 ~]#

(2) LokiStackカスタムリソースの作成

LokiStackのカスタムリソースのマニフェストを作成します。

LokiStackのカスタムリソースの例はOCP 4.11 Docs / ロギング / 5. Loki / 5.2. Lokistack のデプロイにありました。

ドキュメントに記載の設定(ODFの場合)

とりあえずベースの設定はドキュメントに従い以下のようになります。

LokiStackのカスタムリソースの名前はlogging-lokistackとしました。
.spec.sizeは今回はサイジングのところで検討したように1x.smallを指定しました。
.spec.storageClassNameについては、LokiStackはオブジェクトストレージだけではなく、Ingester(logging-lokistack-ingester)、Index Gateway(logging-lokistack-index-gateway)、Compactor(logging-lokistack-compactor)のコンポーネントのStatefulsetがBlock (volumeMode: Filesystem)の永続ボリュームを使用していました。
この永続ボリュームを切りだすためにODFのocs-storagecluster-ceph-rbdのストレージクラスを指定する必要がありました。
作成するnamespaceはopenshift-loggingにしています。
storageのschemasは、Loki OperatorのDocsを見ると、version v12とv11というのがあるようでしたが、OCPのドキュメント通りに記載しています。
.spec.storage.secretは、Loki Operator Docs / LOKISTACK / Object Storage / OpenShift Data Foudationを参照して、LokiStack用のオブジェクトバケットの接続用のSecretの名前を指定します。ODFの場合もtypeはs3を指定します。
ドキュメントにはない設定として、.spec.managementState: Managedを付け加えています。

該当部分の設定(ドキュメント記載部分(ODFの場合))

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
  managementState: Managed
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
  size: 1x.small
  storageClassName: ocs-storagecluster-ceph-rbd

ただし、上述のOCPのロギングのドキュメントの設定だけでは、うまくいきませんでした。追加で必要なのは以下の2点です。

追加設定(1) LokiStackのコンポーネントをInfra node (運用コンポーネント上)で稼働させる

今回、LokiStackのコンポーネントは、Infra node (運用コンポーネント)上で、稼働させたいと思います。

そのためには、LokiStackのコンポーネントに、nodeSelectorの設定と、もしInfra nodeにTaintが付与されていたら、tolerationの設定もする必要があります。

そのやり方はOCPのドキュメントには記載がありませんが、Loki Operatorのドキュメントの方に記載がありました。

Loki Operator Docs / LOKI OPERATOR / API

link	description	notes
Loki Operator Docs / LOKI OPERATOR / API / LokiTemplateSpec	LokiStackのコンポーネントの一覧、このコンポーネント毎にnodeSelector、torelationの設定が必要	LokiStackのコンポーネントは`compactor`、`distributor`、`ingester`、`querier`、`queryFrontend`、`gateway`、`indexGateway`、`ruler`が存在
Loki Operator Docs / LOKI OPERATOR / API / LokiTemplateSpec	コンポーネント毎の`nodeSelector`、`tolerations`の記載方法	今回はInfra node (運用コンポーネント)にTaintをつけていなかったのでnodeSelectorだけ設定

(補足) OCPコンソールのAPI ExprolerでもLokiStackのスキーマを確認することができます。

今回の環境では、Infra nodeとして、運用コンポーネント(内部レジストリ、ルーター、モニタリング、ロギング)用のInfra nodeと、ODF専用のInfra node (storage node)を別個に作成しています。

アプリケーションPodを運用コンポーネント用のInfra nodeとODF専用のInfra node (storage node)で稼働させないようにするために、以下の設定をしていました。

Infra node (運用コンポーネント用) は taintをつけず、nodeSlectorのみで設定 (参考: Qiita / OpenShiftでMachine Config Pool (MCP) を使用してInfra nodeを作成するの(1) nodeSelectorのみを使用参照)
Infra node (ODF専用) もInfra nodeのMCPに属しているため、Infra nodeのnodeSelectorを指定した運用コンポーネントがInfra node (ODF専用)上で稼働しないようにInfra node (ODF専用)にだけ、Taintを付与 (参考: Qiita / ベアメタルUPIのOpenShift 4.11に、OpenShift Data Foudation (ODF)をインストールするの(4) ODF専用のInfra nodeのTaintの設定参照)

従って、今回の環境ではInfra node (運用コンポーネント)にはTaintをつけていなかったので、LokiStackの各コンポーネントを明示的に明記してそれぞれnodeSlectorの設定を入れる必要がありました。

該当部分の設定(nodeSelector)

spec:
  (略)
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""

追加設定(2) オブジェクトバケットのEndpointに接続するためのTLSの設定

最初何も設定しないでLokiStackカスタムリソースを作成してCluster Loggingの構成をしたら以下のようなエラーでオブジェクトバケットへの接続が失敗していました。。

level=error ts=2022-12-29T11:36:20.020307886Z caller=flush.go:146 org_id=infrastructure msg="failed to flush user" err="store put chunk: RequestError: send request failed\ncaused by: Put \"https://s3.openshift-storage.svc:443/loki-object-bucket-a93ab5a3-ce69-4dd1-960c-b896215f48f0/infrastructure/b82cb2425feb7b89%3A1855daab0be%3A1855daab169%3Ac413371f\": x509: certificate signed by unknown authority"

原因は、ODFのオブジェクトバケットのendpointは、https://s3.openshift-storage.svc:443だったので、このendpointに接続するためのTLSの設定が必要だったからのようです。

デフォルトでは、OCPクラスターのサービスCA証明書(service-ca.crt)と同じものを設定する必要があるようでした。

設定箇所は以下に記載があります。

link	description	notes
Loki Operator Docs / LOKI OPERATOR / API / ObjectStorageSpec	`.spec.storage.tls`	オブジェクトバケットのendpointに接続するTLSの設定箇所
Loki Operator Docs / LOKI OPERATOR / API / ObjectStorageTLSSpec	`.spec.storage.tls.caKey` `.spec.storage.tls.caName`	`caKey`: LokiStackと同じnamespaceにあるConfigMap内のサービスCA証明書。デフォルトではOCPのサービスCA証明書(`service-ca.crt`) `caName`: OCPのサービスCA証明書を含むConfigMap名。デフォルトでは`openshift-logging` namespaceも含む、全namespaceに`openshift-service-ca.crt`という名前のConfigMapがあるのでこれを指定。

[root@bastion-01 ~]# oc get configmap -n openshift-logging
NAME                       DATA   AGE
kube-root-ca.crt           1      176d
openshift-service-ca.crt   1      176d
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get configmap -n openshift-logging openshift-service-ca.crt -o yaml
apiVersion: v1
data:
  service-ca.crt: |
    -----BEGIN CERTIFICATE-----
    (略)
    -----END CERTIFICATE-----
kind: ConfigMap
metadata:
  annotations:
    service.beta.openshift.io/inject-cabundle: "true"
  creationTimestamp: "2022-07-12T13:17:54Z"
  name: openshift-service-ca.crt
  namespace: openshift-logging
  resourceVersion: "143840"
  uid: 1ffccb65-2745-44df-88ac-d418a476d324
[root@bastion-01 ~]#

上述を加味すると設定を以下のようにしてみました。

該当部分の設定(TLS)

spec:
  (略)
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
    tls:
      caKey: "service-ca.crt"
      caName: "openshift-service-ca.crt"

最終的な設定

上述を全て合わせたLokiStackのマニフェストファイルは以下のようにしました。

[root@bastion-01 logging]# vi lokistack.yaml
[root@bastion-01 logging]# cat lokistack.yaml

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-lokistack
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
  managementState: Managed
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
  storage:
    storage:
      schemas:
      - version: v12
        effectiveDate: '2022-06-01'
    secret:
      name: loki-object-bucket
      type: s3
    tls:
      caKey: "service-ca.crt"
      caName: "openshift-service-ca.crt"
  size: 1x.small
  storageClassName: ocs-storagecluster-ceph-rbd

(OCPのロギングのドキュメントだけ見てもわからないのはなかなかハードでした。。。)

LokiStackのマニフェストの適用

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

oc apply -f lokistack.yaml

(出力例)

[root@bastion-01 logging]# oc apply -f lokistack.yaml
lokistack.loki.grafana.com/logging-lokistack created
[root@bastion-01 logging]#

確認します。

oc get lokistack -n openshift-logging
oc get pod -n openshift-logging -o wide

oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide

(出力例)

[root@bastion-01 logging]# oc get lokistack -n openshift-logging
NAME                AGE
logging-lokistack   20s
[root@bastion-01 logging]#

[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     61s
logging-lokistack-index-gateway   2/2     61s
logging-lokistack-ingester        0/2     61s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           176d
logging-lokistack-distributor      2/2     2            2           72s
logging-lokistack-gateway          1/1     1            1           72s
logging-lokistack-querier          2/2     2            2           72s
logging-lokistack-query-frontend   2/2     2            2           72s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
No resources found in openshift-logging namespace.
[root@bastion-01 logging]#

[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-d6cd9585b-mvcpv            1/1     Running   8          23d    10.131.0.8    worker-02   <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          108s   10.129.2.18   infra-03    <none>           <none>
logging-lokistack-distributor-7c4ccc589-kppj6       1/1     Running   0          108s   10.129.2.16   infra-03    <none>           <none>
logging-lokistack-distributor-7c4ccc589-zncp8       1/1     Running   0          108s   10.130.2.19   infra-01    <none>           <none>
logging-lokistack-gateway-cbcb87447-49bwj           2/2     Running   0          107s   10.129.2.17   infra-03    <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          108s   10.128.2.30   infra-02    <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          80s    10.129.2.19   infra-03    <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          108s   10.130.2.21   infra-01    <none>           <none>
logging-lokistack-ingester-1                        0/1     Running   0          43s    10.128.2.31   infra-02    <none>           <none>
logging-lokistack-querier-7f7d45c747-l7xd7          1/1     Running   0          108s   10.129.2.15   infra-03    <none>           <none>
logging-lokistack-querier-7f7d45c747-q67vz          1/1     Running   0          108s   10.128.2.28   infra-02    <none>           <none>
logging-lokistack-query-frontend-6f674d9458-ffnzm   1/1     Running   0          108s   10.128.2.29   infra-02    <none>           <none>
logging-lokistack-query-frontend-6f674d9458-l6ckd   1/1     Running   0          108s   10.130.2.20   infra-01    <none>           <none>
[root@bastion-01 logging]#

永続ボリュームは以下のものができていました。

oc get pvc -n openshift-logging

(出力例)

[root@bastion-01 logging]# oc get pvc -n openshift-logging
NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
storage-logging-lokistack-compactor-0       Bound    pvc-a1274593-7864-4ce4-826f-6a1c809dbc76   10Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-index-gateway-0   Bound    pvc-d3d6b2b2-e14d-4a5c-9a46-d1b668ce8bd5   50Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-index-gateway-1   Bound    pvc-3e3abe0f-90fb-4116-b643-f7dcada73612   50Gi       RWO            ocs-storagecluster-ceph-rbd   2m8s
storage-logging-lokistack-ingester-0        Bound    pvc-f97a47b6-b76c-41be-b8d5-0f4273dc2111   10Gi       RWO            ocs-storagecluster-ceph-rbd   2m36s
storage-logging-lokistack-ingester-1        Bound    pvc-5517c083-4115-438d-850e-69e8748f0fb0   10Gi       RWO            ocs-storagecluster-ceph-rbd   91s
wal-logging-lokistack-ingester-0            Bound    pvc-b96220ee-4671-4b6e-bde2-2449c9a5016d   150Gi      RWO            ocs-storagecluster-ceph-rbd   2m36s
wal-logging-lokistack-ingester-1            Bound    pvc-1efa22ea-6ceb-4ca1-96dc-28538c711e6d   150Gi      RWO            ocs-storagecluster-ceph-rbd   91s
[root@bastion-01 logging]#

(3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化)

ClusterLoggingのカスタムリソースを作成します。

ドキュメントに記載の設定

今回はLoki + vectorを導入するので、logStoreとして、lokistack、collectionとしてvectorを指定しています。

.spec.collectionの部分の書き方が少し違いました。(後述)

該当部分の設定(ドキュメント記載部分(ODFの場合))

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: "openshift-logging"
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-lokistack
  collection:
    logs:
      type: "vector"

そしてやはりこれだけではダメでした。

追加設定(1) Torerationsの設定(vector)

考慮点として、vectorはdaemonsetとして全てのnode上で稼働する必要があります。

master node上で稼働するためのtolerationsはデフォルトで入っていましたが、その他のnodeにTaintが入っている場合は、tolerationsの設定を入れる必要があります。

今回はODF専用のInfra nodeにtaintの設定が入っているので、vectorに対してtolerationsの設定が必要でした。

fluetdの場合はtolerationsの設定は OCP 4.11 Docs / ロギング / 4. ロギングデプロイメントの設定 / 4.7. 容認を使用した OpenShift Logging Pod 配置の制御 / 4.7.3. 容認を使用したログコレクター Pod 配置の制御に記載がありましたが、vectorの場合はここと同じように設定してもうまくいきませんでした。。

OCPのドキュメントにも、OCPのコンソールのAPI ExplorerでClusterLoggingのスキーマを見ても設定箇所の記載がありませんでしたが、ClusterLogging OperatorのCSVの中にそれっぽい設定の記載を見つけました。

[root@bastion-01 ~]# oc get csv -n openshift-logging
NAME                           DISPLAY                            VERSION   REPLACES                       PHASE
cluster-logging.5.5.5          Red Hat OpenShift Logging          5.5.5     cluster-logging.5.4.2          Succeeded
elasticsearch-operator.5.5.5   OpenShift Elasticsearch Operator   5.5.5     elasticsearch-operator.5.4.9   Succeeded
loki-operator.5.5.5            Loki Operator                      5.5.5                                    Succeeded
[root@bastion-01 ~]#
[root@bastion-01 ~]# oc get csv -n openshift-logging cluster-logging.5.5.5 -o yaml

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  (略)
  name: cluster-logging.5.5.5
  namespace: openshift-logging
  (略)
spec:
  apiservicedefinitions: {}
  cleanup:
    enabled: false
  customresourcedefinitions:
    (略)
    - description: A Red Hat OpenShift Logging instance. ClusterLogging is the Schema
        for the clusterloggings API
      displayName: Cluster Logging
      kind: ClusterLogging
      name: clusterloggings.logging.openshift.io
      (略)
      specDescriptors:
      - description: Define which Nodes the Pods are scheduled on.
        displayName: Collector Node Selector
        path: collection.logs.nodeSelector
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap
      - description: The resource requirements for the collector
        displayName: Collector Resource Requirements
        path: collection.logs.resources
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:resourceRequirements
      - description: Define the tolerations the Pods will accept
        displayName: Collector Pod Tolerations
        path: collection.logs.tolerations
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Toleration
      - description: Define which Nodes the Pods are scheduled on.
        displayName: Collector Node Selector
        path: collection.nodeSelector
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap
      - description: The resource requirements for the collector
        displayName: Collector Resource Requirements
        path: collection.resources
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:resourceRequirements
      - description: Define the tolerations the Pods will accept
        displayName: Collector Pod Tolerations
        path: collection.tolerations
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Toleration
      - description: The type of Log Collection to configure
        displayName: Collector Implementation
        path: collection.type
        x-descriptors:
        - urn:alm:descriptor:com.tectonic.ui:select:fluentd
        - urn:alm:descriptor:com.tectonic.ui:select:vector
(略)

適当にこの辺を参考にして、今回は試しに以下のように設定してみました。
(正しいかは不明です。.spec.collection.logs.type: "vector"でもうまくいきましたが、tolerationsはcollectionの下にしないダメでした。)

spec:
  (略)
  collection:
    tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      value: "true"
    type: "vector"

最終的な設定

上述を全て合わせたClusterLoggingのマニフェストファイルは以下のようにしました。

[root@bastion-01 logging]# vi clo-instance-5.5-lokistack.yaml
[root@bastion-01 logging]# cat clo-instance-5.5-lokistack.yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: "openshift-logging"
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-lokistack
  collection:
    tolerations:
    - effect: NoSchedule
      key: node.ocs.openshift.io/storage
      value: "true"
    type: "vector"

ClusterLoggingのマニフェストの適用

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

oc apply -f clo-instance-5.5-lokistack.yaml

(出力例)

[root@bastion-01 logging]# oc apply -f clo-instance-5.5-lokistack.yaml
clusterlogging.logging.openshift.io/instance created
[root@bastion-01 logging]#

確認します。

oc get clusterlogging -n openshift-logging

oc get statefulset -n openshift-logging
oc get deployment -n openshift-logging
oc get daemonset -n openshift-logging
oc get pod -n openshift-logging -o wide

(出力例)

[root@bastion-01 logging]# oc get clusterlogging -n openshift-logging
NAME       MANAGEMENT STATE
instance   Managed
[root@bastion-01 logging]#

LokiStackはすでに入っていたので、colectionとしてvectorがdaemonsetとして追加されました。

[root@bastion-01 logging]# oc get statefulset -n openshift-logging
NAME                              READY   AGE
logging-lokistack-compactor       1/1     6m10s
logging-lokistack-index-gateway   2/2     6m10s
logging-lokistack-ingester        2/2     6m10s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get deployment -n openshift-logging
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
cluster-logging-operator           1/1     1            1           176d
logging-lokistack-distributor      2/2     2            2           6m20s
logging-lokistack-gateway          1/1     1            1           6m20s
logging-lokistack-querier          2/2     2            2           6m20s
logging-lokistack-query-frontend   2/2     2            2           6m20s
logging-view-plugin                1/1     1            1           79s
[root@bastion-01 logging]#
[root@bastion-01 logging]# oc get daemonset -n openshift-logging
NAME        DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
collector   11        11        11      11           11          kubernetes.io/os=linux   76s
[root@bastion-01 logging]#

vectorはtolerationsの設定が効いて、ODF専用の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-d6cd9585b-mvcpv            1/1     Running   8          23d     10.131.0.8    worker-02    <none>           <none>
collector-642qp                                     2/2     Running   0          74s     10.128.0.40   master-01    <none>           <none>
collector-64rd4                                     2/2     Running   0          75s     10.129.4.23   storage-02   <none>           <none>
collector-6kbmt                                     2/2     Running   0          74s     10.128.4.24   storage-01   <none>           <none>
collector-dzszj                                     2/2     Running   0          74s     10.129.2.21   infra-03     <none>           <none>
collector-mqj9p                                     2/2     Running   0          75s     10.130.2.23   infra-01     <none>           <none>
collector-ncgcq                                     2/2     Running   0          75s     10.131.2.12   worker-01    <none>           <none>
collector-njxcf                                     2/2     Running   0          74s     10.129.0.44   master-02    <none>           <none>
collector-r6878                                     2/2     Running   0          74s     10.131.0.13   worker-02    <none>           <none>
collector-s6hs7                                     2/2     Running   0          74s     10.130.0.57   master-03    <none>           <none>
collector-sv5hq                                     2/2     Running   0          74s     10.130.4.27   storage-03   <none>           <none>
collector-xhwqj                                     2/2     Running   0          75s     10.128.2.33   infra-02     <none>           <none>
logging-lokistack-compactor-0                       1/1     Running   0          6m45s   10.129.2.18   infra-03     <none>           <none>
logging-lokistack-distributor-7c4ccc589-kppj6       1/1     Running   0          6m45s   10.129.2.16   infra-03     <none>           <none>
logging-lokistack-distributor-7c4ccc589-zncp8       1/1     Running   0          6m45s   10.130.2.19   infra-01     <none>           <none>
logging-lokistack-gateway-cbcb87447-49bwj           2/2     Running   0          6m44s   10.129.2.17   infra-03     <none>           <none>
logging-lokistack-index-gateway-0                   1/1     Running   0          6m45s   10.128.2.30   infra-02     <none>           <none>
logging-lokistack-index-gateway-1                   1/1     Running   0          6m17s   10.129.2.19   infra-03     <none>           <none>
logging-lokistack-ingester-0                        1/1     Running   0          6m45s   10.130.2.21   infra-01     <none>           <none>
logging-lokistack-ingester-1                        1/1     Running   0          5m40s   10.128.2.31   infra-02     <none>           <none>
logging-lokistack-querier-7f7d45c747-l7xd7          1/1     Running   0          6m45s   10.129.2.15   infra-03     <none>           <none>
logging-lokistack-querier-7f7d45c747-q67vz          1/1     Running   0          6m45s   10.128.2.28   infra-02     <none>           <none>
logging-lokistack-query-frontend-6f674d9458-ffnzm   1/1     Running   0          6m45s   10.128.2.29   infra-02     <none>           <none>
logging-lokistack-query-frontend-6f674d9458-l6ckd   1/1     Running   0          6m45s   10.130.2.20   infra-01     <none>           <none>
logging-view-plugin-56865f7d4d-86gcw                1/1     Running   0          104s    10.131.2.10   worker-01    <none>           <none>
[root@bastion-01 logging]#

(4) ログコンソールプラグインの有効化

OCPのコンソールにロギングのメニューを統合するログコンソールプラグインを有効にします。

OCP コンソールの、左側のメニューからOperator -> インストール済みのOperatorを選択します。
左上のプロジェクトをopenshift-loggingに変更し、「RedHat OpenShift Logging」 Operatorを選択します。

「詳細」タブの右側の「コンソールプラグイン」の下の「無効」のリンクをクリックします。

表示される「コンソールプラグインの有効化」の画面で「無効にする」から「有効にする」に変更し「保存」をクリックします。

「コンソールプラグイン」の下の「無効」のリンクが「有効化」という文字列に変わります。
しばらくするとconsoleのPodが再作成されるので「Web コンソールの更新を利用できます。」のメッセーが表示されるので「Webコンソールの更新」のリンクをクリックするか、手動でブラウザを更新します。

OCPコンソールの左側の「監視」メニューの下に「Logs」のメニューが追加されます。
「Logs」をクリックすると「Logs」の画面が表示されます。

確認

(1) ログの確認

ログの種別としてapplications、infrastructure、auditが選択できます。

infrastructureに変更するとinfrastructure関連のログが表示されます。

Content、Namespaces、Pods、Containersなどで検索をすることもできます。

Contentの場合は任意の文字列でログを検索できます。
Namespaces、Pods、Containresを選択した場合はFilterのプルダウンでNamespace、Pod、Containerの一覧が出てくるので、一つまたは複数選択してログをフィルターして確認できます。

Severityもcritical、error、warning、debug、info、trace、unknownなどを一つまたは複数選択できます。

infrastructureの横のShow Resourcesを選択すると、ログのエントリーにログの関連リソースが明記されます。
右上のShow Histogramをクリックするとグラフ表示もされます。

(もう少し時間が経って表示した場合のHistgramの例)

Show Queryをクリックすると上述の選択でどのようなQueryをしているのかが確認できます。

また、アプリケーションPod用のnamespaceのログがあった場合は、ログの種別としてapplicationを選択することで表示することができます。

その他

Object Storageを使っているかは、Data Foudationの画面から確認できます。

(以下は導入から4-5日たった時のキャプチャです。また、バッキングストアの容量を300GiBではなく、余裕を持ってボリューム数を4、ボリュームサイズを100Giの、合計400Giで作成していた時のキャプチャです。)

OCPコンソールの左側のメニューからストレージ -> Data Foudationを選択して「ストレージシステム」タブを選択し、表示されるストレージシステムのエントリー(ocs-storagecluster-storagesystem)をクリックします。

表示されるocs-storagecluster-storagesystem画面の「概要」タブの「ブロック及びファイル」でODFの提供するストレージ全体でどの程度の容量が使用されているかが確認できます。

「Object」タブを選択すると、ObjectStorageのMulticloud Object Gateway 経由で使用しているバケットの容量が確認できます。

LokiStackのコンポーネントのPVCや、ODFのバッキングストアのバックエンドのPVCの容量は、ストレージ -> 永続ボリューム要求画面で確認できます。

参考までにメトリクス欄で使用されている容量を表示すると、以下の感じでした。

メトリクス例 (openshift-storage namespaceのPVC)

sum(kubelet_volume_stats_used_bytes{namespace="openshift-storage"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)

Lokistack用のバッキングストアのバックエンドのPVC x4 のディスク使用量は少しづつ増えている。
アプリケーションPodが何もいない状態で、1週間でトータル70GiB程度。

メトリクス例 (openshift-logging namespaceのPVC)

sum(kubelet_volume_stats_used_bytes{namespace="openshift-logging"}) by (namespace, persistentvolumeclaim) / (1024 * 1024 * 1024)

ログが多くない状況ではそこまで容量は多く使われていないようでした。

なお、何日間かログが貯まった後に、Loggingの画面はLast 1 hoursの場合は、Histgramは表示されるのですが、Last 2 hoursの場合は、タイムアウトのエラーで表示されませんでした。
この辺のチューニング方法はいずれ調べる必要があるかなと思います。

Last 1 hoursの場合

Last 2 hoursの場合

ベアメタルUPIで導入したオンプレのOpenShift 4.11に LokiStack + Vectorを入れてみた

概要

参考リンク

検証環境

手順の流れ

実際の手順

(事前準備)

(1) 既存のロギングサブシステム(Elasticsearch、Fluentd、Kibana)のアンインストール

前提の確認

(1) デプロイメントのサイズ

ODFクラスタの作成

(1) ODFクラスタの作成

オブジェクトストレージの準備

(1) バッキングストアの作成

(2) バケットクラスの作成

(3) Object Bucket Claimの作成

(4) オブジェクトバケット接続用のSecretの作成

LokiStackのデプロイ

(1) Loki Operatorの導入

(2) LokiStackカスタムリソースの作成

ドキュメントに記載の設定(ODFの場合)

追加設定(1) LokiStackのコンポーネントをInfra node (運用コンポーネント上)で稼働させる

追加設定(2) オブジェクトバケットのEndpointに接続するためのTLSの設定

最終的な設定

LokiStackのマニフェストの適用

(3) ClusterLoggingカスタムリソースの作成(lokistackのデプロイ、vectorの有効化)

ドキュメントに記載の設定

追加設定(1) Torerationsの設定(vector)

最終的な設定

ClusterLoggingのマニフェストの適用

(4) ログコンソールプラグインの有効化

確認

(1) ログの確認

その他