1.はじめに
Red Hat が提供する Kubernetes のパッケージである OpenShift では、ログ収集用のセットを [Cluster Logging] (https://docs.openshift.com/container-platform/4.5/logging/cluster-logging.html)と呼んでいます。
Cluster Logging の実体は、Elastic Search、Kibana、fluentdとCuratorです。OpenShiftでは、この Cluster Loggingを導入する事で、基本的なログ収集環境ができあがるようになっています。
ここでは、商用版の OpenShift4.5を使用して、Cluster Loggingを導入していきます。
2.サイジング
Cluster Loggingを導入するには、メモリのスペックとして32GB の Workerノード x 3 が必要とされています。
テストした限りでは、16GB ノードの場合は、メモリの不足でコンテナのスケジュールが失敗すると思います。
必要なディスク領域は、ログ容量に依存するいので、基準はありませんがここではノード辺り200G用意する事にします。
| サーバー | vCPU(HT-on) | Memory | OS Disk | OS | ホスト名 | IP Address |
|---|---|---|---|---|---|---|
| Infraノード 1 | 4vCPU | 32GByte | 120G | CoreOS | i1.ocp45.example.localdomain | 172.16.0.51 |
| Infraノード 2 | 4vCPU | 32GByte | 120G | CoreOS | i2.ocp45.example.localdomain | 172.16.0.52 |
| Infraノード 3 | 4vCPU | 32GByte | 120G | CoreOS | i3.ocp45.example.localdomain | 172.16.0.53 |
この手順では、Cluster Logging用のWorkerノードを、インフラコンポーネント用のノードという意味でInfraノードと呼ぶ事にします。(この呼び方は、OpenShift独自の呼び方です）
3.環境の設計
Cluster Loggingは、比較的重たいコンポーネントであるため、ユーザーコンテナ向けのワークロードとは被らないようにスケジュールするのが理想です。
そのためにInfraノードという専用のWorkerノードを準備します。
実環境を考えた場合いにlabelやnodeSelector、taintを使って、Podを配置していく必要があり、そのための設計が必要になります。
この手順では、以下のような環境に、Cluster Loggingをインストールする事を考えます。
Cluster Loggingのメインのコンポーネントは、緑色の三本のノードにnodeSelectorを指定してインストールします。
一方で、この三本のノードに他のコンポーネントがスケジュールされないようにtaintを付ける必要があります。同時に自分自身がそのtaintの影響を受けないようにする必要があります。
Log収集用のfluentdは、全てのノードにインストールする必要があるので、taintが付いているノードに対するtolerationが必要になってきます。
例えば上記の例では、OCS(Open Container Storage) が、自分のノードにユーザーのアプリケーションコンテナが配置されないようにtaintを付けていますが、fluetndは配置する必要があるので、fluentdに対してOCSノードが付けているtaintに対するtolerationを付けてあげる必要があります。
この例でMasterノードにtaintが付いてますが、このtaintについては、デフォルトで考慮されているので、ユーザーがCluster Loggingのインストール時に考慮する必要はありません。
補則
taintやtolerationの話は最初は複雑なのでガイドから抜いていたのですが、実運用を考えると必ず必要で、私自身がやってみてかなり嵌まったので、事前に考えるべき事として、この項目を入れました。もし、テスト環境などで、まず動かしてみたいという方は、特にPodを追い出したり動きを制限するtaintの部分は全てスキップするのが良いと思います。思わぬ環境破壊につながる事があります。
4.環境の準備
4.1.Cluster Logging インストールのための前提
Cluster Loggingをインストールするための前提が２つあります。
-
ElasticSearch用のPV(Persistent Volume)が作成できるようになっている事 - 専用の
Workerノードが3本、準備されている事
1.に関しては、この手順ではOCS(OpenShift Container Storage)が存在している事が前提になっていますが、PVが作成できる環境であれば、PVCを行う時のStorage Class名が異なる以外は同じ手順になります。
2.に関しては、ユーザーアプリケーションのコンテナが動くWorkerノードにインストールする事も可能ですが、実運用を考えると現実的な選択とは言えないため、この手順では、2.サイジングに書いてある通り、専用のWorkerノードが用意されているものとします。
4.2.1.Cluster Logging 用Workerノードに infra Role のラベルを貼る
※この作業は既に行っている場合は必要ありません。
Cluster Logging用のWorkerノードに対して、Infraノードとしてのラベルを振ります。
このラベルがある所にCluster Loggingの幾つかのコンポーネントをnodeSelectorを使ってスケジュールします。
また、このラベルはユーザーの目に見える部分で動作に影響するものではありませんが、OpenShiftが内部的に、ユーザーアプリケーション用のWorkerノードと区別するために使われます。
以下のコマンドを実行します。
# oc label node i1.ocp45.example.localdomain node-role.kubernetes.io/infra=
# oc label node i2.ocp45.example.localdomain node-role.kubernetes.io/infra=
# oc label node i3.ocp45.example.localdomain node-role.kubernetes.io/infra=
infraのラベルが貼られている事を確認します。
[root@bastion openshift]# oc get nodes
NAME STATUS ROLES AGE VERSION
i1.ocp45.example.localdomain Ready infra,worker 15h v1.18.3+47c0e71
i2.ocp45.example.localdomain Ready infra,worker 15h v1.18.3+47c0e71
i3.ocp45.example.localdomain Ready infra,worker 15h v1.18.3+47c0e71
m1.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
m2.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
m3.ocp45.example.localdomain Ready master 15h v1.18.3+47c0e71
s1.ocp45.example.localdomain Ready infra,worker 66m v1.18.3+47c0e71
s2.ocp45.example.localdomain Ready infra,worker 66m v1.18.3+47c0e71
s3.ocp45.example.localdomain Ready infra,worker 66m v1.18.3+47c0e71
w1.ocp45.example.localdomain Ready worker 15h v1.18.3+47c0e71
w2.ocp45.example.localdomain Ready worker 15h v1.18.3+47c0e71
w3.ocp45.example.localdomain Ready worker 15h v1.18.3+47c0e71
[root@bastion openshift]#
OpenShiftでは、kubernetesと違い、Workerノードの部分に明示的にworkerというroleが振られています。
Webを検索するとworkerとしてのラベルを外す手順が出てくる場合がありますが、worker Role のラベルはここでは外さないでそのままにしておきます。(workerのラベルは、OpenShiftが提供している特殊なOperatorが認識に使用しているため、外す場合は、Maching Config Poolという追加リソースを作成する必要がでてきます。)
5.Cluster Loggingのインストール
5.1 Elasticsearch Operator のインストール
OperatorHub から、Elasticsearch Operatorを探します。
Installボタンをクリックします。
Installation Mode が 「All namespaces on the cluster」である事を確します。(デフォルト）
Installed Namespace は、「openshift-operators-redhat」である事を確認します。（デフォルト）
Enable operator recommended cluster monitoring on this namespace にチェックを入れます。
後はInstallボタンを押します。
Installed Operatorで、Elasticsearch Operator が SucceededになっていればOKです。
5.2. Cluster Logging Operator のインストール
OperatorHub から、Cluster Logging Operatorを探します。
Installをクリックします。
Installed Namepsace は、openshift-loggingにします。（デフォルト）
Enable operator recommended cluster monitoring on this namespace のチェックを入れます。
後は、Installをクリックします。
Installed Operatorで、Cluster Logging が SucceededになっていればOKです。
5.3. Cluster Logging のインスタンスを作成する
Administration → Custom Resource Definitions から ClusterLogging という CRD(Custom Resource Definition)を探します。
Create ClusterLogging をクリックして、ClusterLoggingのインスタンスを作成します。
デフォルトの YAMLを以下のような YAMLに書き替えます。YAMLのラベルの前の部分には、全角やタブが入らないように注意します。
また、このYAML内からPVC(Persistent Volume Claim)を行って、ログ収集用のボリュームを作成しています。PVCをするだけで、PVが作成される(動的プロビジョニング(Dynamic Volume Provisioning)環境である事が前提になっています。
ClusterLoggingのインスタンス名(name:)が、instanceと、かなり直球な名前になっていますが、マニュアルなどの例がinstanceとなっているので、参照時にわかりやすいようにそのまま使う事にします。
apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
name: "instance"
namespace: "openshift-logging"
spec:
managementState: "Managed"
logStore:
type: "elasticsearch"
retentionPolicy: #(1) ログの保管期間
application:
maxAge: 1d
infra:
maxAge: 7d
audit:
maxAge: 7d
elasticsearch:
nodeSelector: # (1) スケジュールする node を指定
node-role.kubernetes.io/infra: '' # Infra node を指定
tolerations: # (2) tolerationの指定
- effect: NoSchedule #
key: infra #
value: reserved #
- effect: NoExecute #
key: infra #
value: reserved #
nodeCount: 3 # (3) ElasticSerachのノード数。通常3 です。
storage:
storageClassName: "ocs-storagecluster-cephfs" # (4) PVを作るStorage Class名。環境によって異なる。
size: 200G # (5) PVのサイズは 200G に設定
redundancyPolicy: "SingleRedundancy"
visualization:
type: "kibana"
kibana:
nodeSelector: # (1) スケジュールする node を指定
node-role.kubernetes.io/infra: '' # Infra node を指定
tolerations: # (2) tolerationの指定
- effect: NoSchedule #
key: infra #
value: reserved #
- effect: NoExecute #
key: infra #
value: reserved #
replicas: 1
curation:
type: "curator"
curator:
nodeSelector: # (1) スケジュールする node を指定
node-role.kubernetes.io/infra: '' # Infra node を指定
tolerations: # (2) tolerationの指定
- effect: NoSchedule #
key: infra #
value: reserved #
- effect: NoExecute #
key: infra #
value: reserved #
resources: null
schedule: "30 3 * * *"
collection:
logs:
type: "fluentd"
fluentd:
tolerations: # (6) Infra Node用 tolerationの指定
- effect: NoSchedule #
key: infra #
value: reserved #
- effect: NoExecute #
key: infra #
value: reserved #
- effect: NoSchedule # (7) Storage Node用 tolerationの指定
key: node.ocs.openshift.io/storage #
value: "true" #
(1)のnodeSelectorを使ってInfraノードにコンポーネントをインストールするように指定します。
(2)``Infraノードには他のコンポーネントのPodがスケジュールされないようにtaintが付けてあります。taintを無視するようにtolearationを付けています。
(4) のStorage Class名は、環境によって異なります。この例は、OCSをした時に自動で追加されるStorage Class、ocs-storagecluster-cephfs (CephFS)を使っています。AWSのIPIインストール環境では、"gp2"がデフォルトで使用できます。
Storage Classは、PVCが削除された時のデータの扱い(Reclaim Ploicy)も定義しています。上記のStorage Class、ocs-storagecluster-cephfsは、Deleteですので、もしRetain等がよければ別のStorage Classを作成します。
(6)``fluentdは、Log収集のため全てのコンポーネントに配置される必要があります。そのためこの環境でノードに付けられているtaintに対するtolerationを指定しています。Masterノードについては、デフォルトで考慮されているため、指定する必要はありません。
yaml を貼り付けた後は、Createをクリックします。
参考:3.1. About the Cluster Logging Custom Resource
5.4.Cluser Logging コンポーネントのデプロイの確認
5.4.1.PVのデプロイの確認
Storage -> Persistent Volumes で、elasticsearch-elasticearchi-cdm-... という PVC名と紐付いたVolumeが3つデプロイされているを確認します。
5.4.2.Podのデプロイの確認
Workloads -> Pods で、Project名で openshift-loggingを選択し、Podが全て Running になるのを待ちます。
Podが全て起動していれば、全てのコンポーネントのインストールが完了です。
コマンドラインでも同様に確認できます。
[root@bastion ~]# oc get pod -n openshift-logging
NAME READY STATUS RESTARTS AGE
cluster-logging-operator-d5566bd54-mww66 1/1 Running 0 6h57m
elasticsearch-cdm-2wa40yud-1-7d9ff5446f-lgrrw 2/2 Running 0 6h26m
elasticsearch-cdm-2wa40yud-2-f4f44fc9d-pm8b6 2/2 Running 0 6h26m
elasticsearch-cdm-2wa40yud-3-7fcd6c6f6c-v7bp2 2/2 Running 0 6h26m
elasticsearch-delete-app-1603892700-n6ndg 0/1 Completed 0 14m
elasticsearch-delete-audit-1603892700-sbd9p 0/1 Completed 0 14m
elasticsearch-delete-infra-1603892700-2q6kz 0/1 Completed 0 14m
elasticsearch-rollover-app-1603892700-brd9f 0/1 Completed 0 14m
elasticsearch-rollover-audit-1603892700-td8jk 0/1 Completed 0 14m
elasticsearch-rollover-infra-1603892700-f4kz9 0/1 Completed 0 14m
fluentd-666q4 1/1 Running 0 6h27m
fluentd-8xgkj 1/1 Running 0 6h27m
fluentd-9nhsn 1/1 Running 0 6h27m
fluentd-bjjzp 1/1 Running 0 6h27m
fluentd-bntmp 1/1 Running 0 6h27m
fluentd-bvxwj 1/1 Running 0 6h27m
fluentd-ffrjm 1/1 Running 0 6h27m
fluentd-fk7sr 1/1 Running 0 6h27m
fluentd-hb6hk 1/1 Running 0 6h27m
fluentd-l8bzv 1/1 Running 0 6h27m
fluentd-t9zvw 1/1 Running 0 6h27m
fluentd-vp5qn 1/1 Running 0 6h27m
kibana-5475bd69c4-n4rkd 2/2 Running 0 6h27m
[root@bastion ~]#
ログ収集用のfluentd-xxxxのPodの数は、全てのノード本数分あるはずです。
fluentd以外のコンポーネントがどこに配置されているか確認してみます。
[root@bastion ~]# oc describe pods cluster-logging-operator-d5566bd54-mww66 -n openshift-logging | grep Node:
Node: w1.ocp45.example.localdomain/172.16.0.31
[root@bastion ~]# oc describe pods elasticsearch-cdm-2wa40yud-1-7d9ff5446f-crdgc -n openshift-logging | grep Node:
Node: i1.ocp45.example.localdomain/172.16.0.41
[root@bastion ~]# oc describe pods elasticsearch-cdm-2wa40yud-2-f4f44fc9d-vr642 -n openshift-logging | grep Node:
Node: i2.ocp45.example.localdomain/172.16.0.42
[root@bastion ~]# oc describe pods elasticsearch-cdm-2wa40yud-3-7fcd6c6f6c-f4l72 -n openshift-logging | grep Node:
Node: i3.ocp45.example.localdomain/172.16.0.43
[root@bastion ~]# oc describe pods elasticsearch-delete-app-1603948500-bmct2 -n openshift-logging | grep Node:
Node: i1.ocp45.example.localdomain/172.16.0.41
[root@bastion ~]# oc describe pods elasticsearch-delete-audit-1603948500-fmq7v -n openshift-logging | grep Node:
Node: i2.ocp45.example.localdomain/172.16.0.42
[root@bastion ~]# oc describe pods elasticsearch-delete-infra-1603948500-phjsj -n openshift-logging | grep Node:
Node: i1.ocp45.example.localdomain/172.16.0.41
[root@bastion ~]# oc describe pods elasticsearch-rollover-app-1603948500-mx4hm -n openshift-logging | grep Node:
Node: i1.ocp45.example.localdomain/172.16.0.41
[root@bastion ~]# oc describe pods elasticsearch-rollover-audit-1603948500-wxsgk -n openshift-logging | grep Node:
Node: i3.ocp45.example.localdomain/172.16.0.43
[root@bastion ~]# oc describe pods elasticsearch-rollover-infra-1603948500-8c2th -n openshift-logging | grep Node:
Node: i2.ocp45.example.localdomain/172.16.0.42
[root@bastion ~]# oc describe pods kibana-5475bd69c4-n4rkd -n openshift-logging | grep Node:
Node: i3.ocp45.example.localdomain/172.16.0.43
[root@bastion ~]#
cluster-logging-operator-が、Workerノードにスケジュールされている以外は、Infraノードにスケジュールされています。
少し気持ち悪いですが、Elasticsearch、Kibanaと言った負荷の高いコンポーネントがInfraノードに配置されているので、一旦、これで良しとします。
5.4.3.Kibana へのアクセス確認
Kibanaにアクセスしてみます。
Networking -> Routes に Kibanaという名前の Route が出てきているはずです。表示されているリンクをクリックします。ログインウィンドウが出ますが、Userid / Password は、OpenShift のIDがそのまま使えます。
OAuthの許可画面です。現在のユーザーに、表示されているアクセスを許可します。
Kibanaの画面が表示されれば OKです。
6.環境の再作成について
環境の構築に失敗した場合は、以下の手順で Operatorの導入直後 (この手順だと5.3.Cluster Loggingのインスタンスを作成する の直前まで)戻る事ができます。
- ClusterLogging のインスタンスを削除する
oc delete clusterlogging instance -n openshift-logging
- 作成した PVC を削除する
7.リソースの使用量について
導入した環境では、クラスターを作成したわけではなく、特にアプリケーションを動かしているわけでは無いので、ほぼ無負荷だと思うのですが、メモリに関してはかなり消費しています。
elasticsearch-cdm-jthway98-xxxxに関しては、Elasticsearchを構成する3ノードにそれぞれ配置されるPodですが、おのおののPodがMemoryを10GByte程度使用しているので、十分なリソースを確保した環境にインストールする必要がある事がわかります。
