第8章 クラスターロギングの更新
OpenShift Container Platform クラスターを 4.4 から 4.5 に更新した後に、Elasticsearch Operator および Cluster Logging Operator を 4.4 から 4.5 に更新できます。
クラスターロギング 4.5 では、新規 Elasticsearch バージョン Elasticsearch 6.8.1 および Elasticsearch の強化されたセキュリティープラグイン Open Distro が導入されています。新規 Elasticsearch バージョンでは、新規 Elasticsearch データモデルが導入されました。この場合、Elasticsearch データはタイプ (インフラストラクチャー、アプリケーション、および監査) でのみインデックス化されます。以前のバージョンでは、データはタイプ (インフラストラクチャーおよびアプリケーション) およびプロジェクトでインデックス化されていました。
新規データモデルにより、更新により、既存のカスタム Kibana インデックスパターンおよびビジュアライゼーションは新規バージョンに移行しません。更新後、Kibana インデックスパターンおよびビジュアライゼーションを、新規インデックスに一致させるように再作成する必要があります。
これらの変更の性質上、クラスターロギングを 4.5 に更新する必要はありません。ただし、OpenShift Container Platform 4.6 に更新する場合は、その時点でクラスターロギングを 4.6 に更新する必要があります。
8.1. クラスターロギングの更新
OpenShift Container Platform クラスターの更新後に、Elasticsearch Operator および Cluster Logging Operator のサブスクリプションを変更して、クラスターロギングを 4.4 から 4.5 に更新できます。
更新時に以下を行います。
- Cluster Logging Operator を更新する前に Elasticsearch Operator を更新する必要があります。
Elasticsearch Operator と Cluster Logging Operator の両方を更新する必要があります。
Elasticsearch Operator が更新されても、Cluster Logging Operator が更新されない場合、Kibana は使用できなくなります。
Elasticsearch Operator の前に Cluster Logging Operator を更新する場合、Kibana は更新されず、Kibana カスタムリソース (CR) は作成されません。この問題を回避するには、Cluster Logging Operator Pod を削除します。Cluster Logging Operator Pod が再デプロイされると、Kibana CR が作成されます。
クラスターロギングのバージョンが 4.4 よりも前の場合、クラスターロギングを 4.5 に更新する前に 4.4 にアップグレードする必要があります。
前提条件
- OpenShift Container Platform クラスターを 4.4 から 4.5 に更新します。
クラスターロギングのステータスが正常であることを確認します。
-
すべての Pod が
Ready
状態にある。 - Elasticsearch クラスターが正常である。
-
すべての Pod が
- Elasticsearch および Kibana データをバックアップします。
内部 Elasticsearch インスタンスが永続ボリューム要求 (PVC) を使用する場合、PVC には
logging-cluster:elasticsearch
ラベルが含まれる必要があります。ラベルがない場合、アップグレード時にガベージコレクションプロセスではそれらの PVC が削除され、Elasticsearch Operator は新規 PVC を作成します。バージョン 4.4.30 より前の OpenShift Container Platform バージョンから更新する場合は、ラベルを Elasticsearch PVC に手動で追加する必要があります。
たとえば、以下のコマンドを使用してラベルをすべての Elasticsearch PVC に追加できます。
$ oc label pvc --all -n openshift-logging logging-cluster=elasticsearch
- OpenShift Container Platform 4.4.30 以降では、Elasticsearch Operator はラベルを PVC に自動的に追加します。
手順
Elasticsearch Operator を更新します。
-
Web コンソールで Operators
Installed Operators をクリックします。 -
openshift-operators-redhat
プロジェクトを選択します。 - Elasticsearch Operatorをクリックします。
-
Subscription
Channel をクリックします。 - Change Subscription Update Channel ウィンドウで 4.5 を選択し、Save をクリックします。
数秒待ってから Operators
Installed Operators をクリックします。 Elasticsearch Operator が 4.5 と表示されます。以下は例になります。
Elasticsearch Operator 4.5.0-202007012112.p0 provided by Red Hat, Inc
Status フィールドで Succeeded を報告するのを待機します。
-
Web コンソールで Operators
Cluster Logging Operator を更新します。
-
Web コンソールで Operators
Installed Operators をクリックします。 -
openshift-logging
プロジェクトを選択します。 - Cluster Logging Operatorをクリックします。
-
Subscription
Channel をクリックします。 - Change Subscription Update Channel ウィンドウで 4.5 を選択し、Save をクリックします。
数秒待ってから Operators
Installed Operators をクリックします。 Cluster Logging Operator は 4.5 として表示されます。以下は例になります。
Cluster Logging 4.5.0-202007012112.p0 provided by Red Hat, Inc
Status フィールドで Succeeded を報告するのを待機します。
-
Web コンソールで Operators
ロギングコンポーネントを確認します。
すべての Elasticsearch Pod が Ready ステータスであることを確認します。
$ oc get pod -n openshift-logging --selector component=elasticsearch
出力例
NAME READY STATUS RESTARTS AGE elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk 2/2 Running 0 31m elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk 2/2 Running 0 30m elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc 2/2 Running 0 29m
Elasticsearch クラスターが正常であることを確認します。
$ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- es_cluster_health
{ "cluster_name" : "elasticsearch", "status" : "green", } ...
Elasticsearch cron ジョブが作成されていることを確認します。
$ oc project openshift-logging
$ oc get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE elasticsearch-im-app */15 * * * * False 0 <none> 56s elasticsearch-im-audit */15 * * * * False 0 <none> 56s elasticsearch-im-infra */15 * * * * False 0 <none> 56s
ログストアが 4.5 に更新され、インデックスが
green
であることを確認します。$ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices
出力に
app-00000x
、infra-00000x
、audit-00000x
、.security
インデックス が含まれることを確認します。例8.1 緑色のステータスのインデックスを含む出力例
Tue Jun 30 14:30:54 UTC 2020 health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open infra-000008 bnBvUFEXTWi92z3zWAzieQ 3 1 222195 0 289 144 green open infra-000004 rtDSzoqsSl6saisSK7Au1Q 3 1 226717 0 297 148 green open infra-000012 RSf_kUwDSR2xEuKRZMPqZQ 3 1 227623 0 295 147 green open .kibana_7 1SJdCqlZTPWlIAaOUd78yg 1 1 4 0 0 0 green open infra-000010 iXwL3bnqTuGEABbUDa6OVw 3 1 248368 0 317 158 green open infra-000009 YN9EsULWSNaxWeeNvOs0RA 3 1 258799 0 337 168 green open infra-000014 YP0U6R7FQ_GVQVQZ6Yh9Ig 3 1 223788 0 292 146 green open infra-000015 JRBbAbEmSMqK5X40df9HbQ 3 1 224371 0 291 145 green open .orphaned.2020.06.30 n_xQC2dWQzConkvQqei3YA 3 1 9 0 0 0 green open infra-000007 llkkAVSzSOmosWTSAJM_hg 3 1 228584 0 296 148 green open infra-000005 d9BoGQdiQASsS3BBFm2iRA 3 1 227987 0 297 148 green open infra-000003 1-goREK1QUKlQPAIVkWVaQ 3 1 226719 0 295 147 green open .security zeT65uOuRTKZMjg_bbUc1g 1 1 5 0 0 0 green open .kibana-377444158_kubeadmin wvMhDwJkR-mRZQO84K0gUQ 3 1 1 0 0 0 green open infra-000006 5H-KBSXGQKiO7hdapDE23g 3 1 226676 0 295 147 green open infra-000001 eH53BQ-bSxSWR5xYZB6lVg 3 1 341800 0 443 220 green open .kibana-6 RVp7TemSSemGJcsSUmuf3A 1 1 4 0 0 0 green open infra-000011 J7XWBauWSTe0jnzX02fU6A 3 1 226100 0 293 146 green open app-000001 axSAFfONQDmKwatkjPXdtw 3 1 103186 0 126 57 green open infra-000016 m9c1iRLtStWSF1GopaRyCg 3 1 13685 0 19 9 green open infra-000002 Hz6WvINtTvKcQzw-ewmbYg 3 1 228994 0 296 148 green open infra-000013 KR9mMFUpQl-jraYtanyIGw 3 1 228166 0 298 148 green open audit-000001 eERqLdLmQOiQDFES1LBATQ 3 1 0 0 0 0
ログコレクターが 4.5 に更新されていることを確認します。
$ oc get ds fluentd -o json | grep fluentd-init
出力に
fluentd-init
コンテナーが含まれていることを確認します。"containerName": "fluentd-init"
Kibana CRD を使用してログビジュアライザーが 4.5 に更新されていることを確認します。
$ oc get kibana kibana -o json
出力に
ready
ステータスの Kibana Pod が含まれることを確認します。例8.2 準備状態にある Kibana Pod の出力例
[ { "clusterCondition": { "kibana-5fdd766ffd-nb2jj": [ { "lastTransitionTime": "2020-06-30T14:11:07Z", "reason": "ContainerCreating", "status": "True", "type": "" }, { "lastTransitionTime": "2020-06-30T14:11:07Z", "reason": "ContainerCreating", "status": "True", "type": "" } ] }, "deployment": "kibana", "pods": { "failed": [], "notReady": [] "ready": [] }, "replicaSets": [ "kibana-5fdd766ffd" ], "replicas": 1 } ]
Curator が 4.5 に更新されていることを確認します。
$ oc get cronjob -o name
cronjob.batch/curator cronjob.batch/elasticsearch-delete-app cronjob.batch/elasticsearch-delete-audit cronjob.batch/elasticsearch-delete-infra cronjob.batch/elasticsearch-rollover-app cronjob.batch/elasticsearch-rollover-audit cronjob.batch/elasticsearch-rollover-infra
出力に
elasticsearch-delete-*
およびelasticsearch-rollover-*
インデックスが含まれることを確認します。
8.1.1. 更新後のタスク
Kibana を使用する場合、Elasticsearch Operator および Cluster Logging Operator が完全に 4.5 に更新された後に、Kibana インデックスパターンおよびビジュアライゼーションを再作成する必要があります。セキュリティープラグインの変更により、クラスターロギングのアップグレードではインデックスパターンが自動的に作成されません。