ロギング

1. Elasticsearch Operator の namespace を作成します。

   1. Elasticsearch Operator の namespace オブジェクト YAML ファイル (eo-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-operators-redhat 1
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-monitoring: "true" 2

      1

      openshift-operators-redhat namespace を指定する必要があります。メトリクスとの競合が発生する可能性を防ぐには、Prometheus のクラスターモニタリングスタックを、openshift-operators namespace からではなく、openshift-operators-redhat namespace からメトリクスを収集するように設定する必要があります。openshift-operators namespace には信頼されていないコミュニティー Operator が含まれる可能性があり、OpenShift Container Platform メトリクスと同じ名前でメトリクスを公開する可能性があるため、これによって競合が生じる可能性があります。

      2

      クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このラベルを上記のように指定する必要があります。

   2. namespace を作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f eo-namespace.yaml

2. 以下のオブジェクトを作成して Elasticsearch Operator をインストールします。

   1. Elasticsearch Operator の Operator グループオブジェクトの YAML ファイル (eo-og.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: openshift-operators-redhat
        namespace: openshift-operators-redhat 1
      spec: {}

      1

      openshift-operators-redhat namespace を指定する必要があります。

   2. Operator グループオブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f eo-og.yaml

   3. Subscription オブジェクト YAML ファイル(eo-sub.yaml など) を作成し、namespace を Operator にサブスクライブします。

      サブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: "elasticsearch-operator"
        namespace: "openshift-operators-redhat" 1
      spec:
        channel: "4.2" 2
        installPlanApproval: "Automatic"
        source: "redhat-operators" 3
        sourceNamespace: "openshift-marketplace"
        name: "elasticsearch-operator"

      1

      openshift-operators-redhat namespace を指定する必要があります。

      2

      4.2 をチャネルとして指定します。

      3

      redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれるネットワークが制限された環境でインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成される CatalogSource オブジェクトの名前を指定します。

   4. Subscription オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f eo-sub.yaml

   5. openshift-operators-redhat プロジェクトに切り替えます。

      $ oc project openshift-operators-redhat
      
      Now using project "openshift-operators-redhat"

   6. ロールベースアクセス制御 (RBAC) オブジェクトファイル (eo-rbac.yaml など) を使用して、openshift-operators-redhat namespace にアクセスするための Prometheus パーミッションを付与します。

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: prometheus-k8s
        namespace: openshift-operators-redhat
      rules:
      - apiGroups:
        - ""
        resources:
        - services
        - endpoints
        - pods
        verbs:
        - get
        - list
        - watch
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
        name: prometheus-k8s
        namespace: openshift-operators-redhat
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: Role
        name: prometheus-k8s
      subjects:
      - kind: ServiceAccount
        name: prometheus-k8s
        namespace: openshift-operators-redhat

   7. RBAC オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f eo-rbac.yaml

      Elasticsearch Operator は openshift-operators-redhat namespace にインストールされ、クラスター内の各プロジェクトにコピーされます。

3. Operator のインストールを確認します。

   oc get csv --all-namespaces
   
   NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
   default                                                 elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   kube-node-lease                                         elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   kube-public                                             elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   kube-system                                             elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   openshift-apiserver-operator                            elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   openshift-apiserver                                     elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   openshift-authentication-operator                       elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   openshift-authentication                                elasticsearch-operator.4.2.1-202002032140    Elasticsearch Operator   4.2.1-202002032140               Succeeded
   ...

   それぞれの namespace には Elasticsearch Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。

1. Cluster Logging Operator の namespace を作成します。CLI を使用して namespace を作成する必要があります。

   1. Cluster Logging Operator の namespace オブジェクト YAML ファイル (clo-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-logging 1
        annotations:
          openshift.io/node-selector: "" 2
        labels:
          openshift.io/cluster-logging: "true"
          openshift.io/cluster-monitoring: "true"

      1 2

      これらのラベルを以下のように指定します。

   2. namespace を作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f clo-namespace.yaml

2. Cluster Logging Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Cluster Logging を選択し、Install をクリックします。
   3. Create Operator Subscription ページの A specific Namespace on the cluster の下で openshift-logging を選択します。次に、Subscribe をクリックします。

3. Cluster Logging Operator がインストールされていることを確認します。

   1. Operators → Installed Operators ページに切り替えます。

   2. Cluster Logging が Status が InstallSucceeded の状態で openshift-logging プロジェクトに一覧表示されていることを確認します。

      注記

      インストール時に、 Operator は Failed ステータスを表示する可能性があります。その後に Operator が InstallSucceeded メッセージと共にインストールされる場合、Failed メッセージを安全に無視することができます。

      Operator がインストール済みとして表示されない場合に、さらにトラブルシューティングを実行します。

      • Operators → Installed Operators ページに切り替え、Status 列でエラーまたは失敗の有無を確認します。
      • Workloads → Pods ページに切り替え、openshift-logging および openshift-operators-redhat プロジェクトの Pod で問題を報告しているログの有無を確認します。

4. クラスターロギングのインスタンスを作成します。

   1. Administration → Custom Resource Definitions ページに切り替えます。
   2. Custom Resource Definitions ページで、ClusterLogging をクリックします。
   3. Custom Resource Definition Overview ページで、Actions メニューから View Instances を選択します。

   4. Cluster Loggings ページで、Create Cluster Logging をクリックします。

      データを読み込むためにページを更新する必要がある場合があります。

   5. YAML フィールドで、コードを以下に置き換えます。

      注記

      このデフォルトのクラスターロギング設定は各種の環境をサポートすることが予想されます。クラスターロギングのクラスターに加えることのできる変更についての詳細は、クラスターロギングコンポーネントのチューニングおよび設定についてのトピックを確認してください。

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          elasticsearch:
            nodeCount: 3 4
            storage:
              storageClassName: gp2 5
              size: 200G
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  6
          kibana:
            replicas: 1
        curation:
          type: "curator"  7
          curator:
            schedule: "30 3 * * *"
        collection:
          logs:
            type: "fluentd"  8
            fluentd: {}

      1

      名前は instance である必要があります。

      2

      クラスターロギングの管理状態。ほとんどの場合、クラスターロギングのデフォルト値を変更する場合は、これを Unmanaged (管理外) に設定する必要があります。ただし、管理外のデプロイメントはクラスターロギングが管理対象の状態に戻されるまで更新を受信しません。詳細は「クラスターロギングの管理状態の変更」を参照してください。

      3

      Elasticsearch の設定に必要な設定。CR を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。詳細は「Elasticsearch の設定」を参照してください。

      4

      Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。

      5

      クラスターの各 Elasticsearch ノードが Persistent Volume Claim（永続ボリューム要求、PVC）にバインドされるように指定します。

      6

      Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana ノードの CPU およびメモリーを設定できます。詳細は「Kibana の設定」を参照してください。

      7

      Curator の設定に必要な設定。CR を使用して Curator スケジュールを設定できます。詳細は「Curator の設定」を参照してください。

      8

      Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細は「Fluentd の設定」を参照してください。

      注記

      Elasticsearch マスターノードの最大数は 3 です。3 を超える nodeCount を指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。マスターノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。

      たとえば、nodeCount=4 の場合に、以下のノードが作成されます。

      $ oc get deployment
      
      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    0/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   0/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   0/1     1            0           6m44s

      インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。

   6. Create をクリックします。これにより、クラスターロギングのカスタムリソースおよび Elasticsearch のカスタムリソースが作成されます。これらを編集すると、クラスターロギングのクラスターに変更を加えることができます。

5. インストールを確認します。

   1. Workloads → Pods ページに切り替えます。

   2. openshift-logging プロジェクトを選択します。

      以下の一覧のようなクラスターロギング、Elasticsearch、Fluentd、および Kibana のいくつかの Pod が表示されるはずです。

      • cluster-logging-operator-cb795f8dc-xkckc
      • elasticsearch-cdm-b3nqzchd-1-5c6797-67kfz
      • elasticsearch-cdm-b3nqzchd-2-6657f4-wtprv
      • elasticsearch-cdm-b3nqzchd-3-588c65-clg7g
      • fluentd-2c7dg
      • fluentd-9z7kk
      • fluentd-br7r2
      • fluentd-fn2sb
      • fluentd-pb2f8
      • fluentd-zqgqx
      • kibana-7fb4fd4cc9-bvt4p

1. Cluster Logging Operator の namespace を作成します。

   1. Cluster Logging Operator の namespace オブジェクト YAML ファイル (clo-namespace.yaml など) を作成します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-logging
        annotations:
          openshift.io/node-selector: ""
        labels:
          openshift.io/cluster-logging: "true"
          openshift.io/cluster-monitoring: "true"

   2. namespace を作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f clo-namespace.yaml

2. 以下のオブジェクトを作成して Elasticsearch Logging Operator をインストールします。

   1. Cluster Logging Operator の OperatorGroup オブジェクトの YAML ファイル (eo-og.yaml など) を作成します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        targetNamespaces:
        - openshift-logging 2

      1 2

      openshift-logging namespace を指定する必要があります。

   2. OperatorGroup オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f clo-og.yaml

   3. Subscription オブジェクト YAML ファイル (clo-sub.yaml など) を作成し、namespace を Operator にサブスクライブします。

      サブスクリプションの例

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: cluster-logging
        namespace: openshift-logging 1
      spec:
        channel: "4.2" 2
        name: cluster-logging
        source: redhat-operators 3
        sourceNamespace: openshift-marketplace

      1

      openshift-logging namespace を指定する必要があります。

      2

      4.2 をチャネルとして指定します。

      3

      redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。

   4. Subscription オブジェクトを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f clo-sub.yaml

      Cluster Logging Operator は openshift-logging namespace にインストールされます。

3. Operator のインストールを確認します。

   openshift-logging namespace には Cluster Logging Operator がなければなりません。バージョン番号が表示されるものと異なる場合があります。

   oc get csv --all-namespaces
   
   NAMESPACE                                               NAME                                         DISPLAY                  VERSION               REPLACES   PHASE
   ...
   openshift-logging                                       clusterlogging.4.2.1-202002032140            Cluster Logging          4.2.1-202002032140               Succeeded
   ...

4. クラスターロギングのインスタンスを作成します。

   1. Cluster Logging Operator のインスタンスオブジェクト YAML ファイル (clo-instance.yaml など) を作成します。

      注記

      このデフォルトのクラスターロギング設定は各種の環境をサポートすることが予想されます。クラスターロギングのクラスターに加えることのできる変更についての詳細は、クラスターロギングコンポーネントのチューニングおよび設定についてのトピックを確認してください。

      apiVersion: "logging.openshift.io/v1"
      kind: "ClusterLogging"
      metadata:
        name: "instance" 1
        namespace: "openshift-logging"
      spec:
        managementState: "Managed"  2
        logStore:
          type: "elasticsearch"  3
          elasticsearch:
            nodeCount: 3 4
            storage:
              storageClassName: gp2 5
              size: 200G
            redundancyPolicy: "SingleRedundancy"
        visualization:
          type: "kibana"  6
          kibana:
            replicas: 1
        curation:
          type: "curator"  7
          curator:
            schedule: "30 3 * * *"
        collection:
          logs:
            type: "fluentd"  8
            fluentd: {}

      1

      名前は instance である必要があります。

      2

      クラスターロギングの管理状態。ほとんどの場合、クラスターロギングのデフォルト値を変更する場合は、これを Unmanaged (管理外) に設定する必要があります。ただし、管理外のデプロイメントはクラスターロギングが Managed の状態に戻されるまで更新を受信しません。詳細は「クラスターロギングの管理状態の変更」を参照してください。

      3

      Elasticsearch の設定に必要な設定。CR (Custom Resource) を使用してシャードのレプリケーションポリシーおよび永続ストレージを設定できます。詳細は「Elasticsearch の設定」を参照してください。

      4

      Elasticsearch ノードの数を指定します。この一覧に続く注記を確認してください。

      5

      クラスターの各 Elasticsearch ノードが Persistent Volume Claim（永続ボリューム要求、PVC）にバインドされるように指定します。

      6

      Kibana の設定に必要な設定。CR を使用して、冗長性を確保するために Kibana をスケーリングし、Kibana ノードの CPU およびメモリーを設定できます。詳細は「Kibana の設定」を参照してください。

      7

      Curator の設定に必要な設定。CR を使用して Curator スケジュールを設定できます。詳細は「Curator の設定」を参照してください。

      8

      Fluentd の設定に必要な設定。CR を使用して Fluentd の CPU およびメモリー制限を設定できます。詳細は「Fluentd の設定」を参照してください。

      注記

      Elasticsearch マスターノードの最大数は 3 です。3 を超える nodeCount を指定する場合、OpenShift Container Platform は、マスター、クライアントおよびデータロールを使用して、3 つのマスターとしての適格性のあるノードである Elasticsearch ノードを作成します。追加の Elasticsearch ノードは、クライアントおよびデータロールを使用してデータのみのノードとして作成されます。マスターノードは、インデックスの作成および削除、シャードの割り当て、およびノードの追跡などのクラスター全体でのアクションを実行します。データノードはシャードを保持し、CRUD、検索、および集計などのデータ関連の操作を実行します。データ関連の操作は、I/O、メモリーおよび CPU 集約型の操作です。これらのリソースを監視し、現行ノードがオーバーロードする場合にデータノード追加することが重要です。

      たとえば、nodeCount=4 の場合に、以下のノードが作成されます。

      $ oc get deployment
      
      cluster-logging-operator       1/1     1            1           18h
      elasticsearch-cd-x6kdekli-1    1/1     1            0           6m54s
      elasticsearch-cdm-x6kdekli-1   1/1     1            1           18h
      elasticsearch-cdm-x6kdekli-2   1/1     1            0           6m49s
      elasticsearch-cdm-x6kdekli-3   1/1     1            0           6m44s

      インデックステンプレートのプライマリーシャードの数は Elasticsearch データノードの数と等しくなります。

   2. インスタンスを作成します。

      $ oc create -f <file-name>.yaml

      以下は例になります。

      $ oc create -f clo-instance.yaml

5. openshift-logging プロジェクトに Pod を一覧表示して、インストールを検証します。

   以下の一覧のようなクラスターロギング、Elasticsearch、Fluentd、および Kibana のいくつかの Pod が表示されるはずです。

   oc get pods -n openshift-logging
   
   NAME                                            READY   STATUS    RESTARTS   AGE
   cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
   elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
   elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
   elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
   fluentd-587vb                                   1/1     Running   0          2m26s
   fluentd-7mpb9                                   1/1     Running   0          2m30s
   fluentd-flm6j                                   1/1     Running   0          2m33s
   fluentd-gn4rn                                   1/1     Running   0          2m26s
   fluentd-nlgb6                                   1/1     Running   0          2m30s
   fluentd-snpkt                                   1/1     Running   0          2m28s
   kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s

手順

1. CatalogSourceConfig (CSC) および Subscription オブジェクトを、新規カタログ namespace および Cource を参照するように編集します。

   1. CLI から、Elasticsearch CSC の名前を取得します。

      $ oc get csc --all-namespaces
      NAMESPACE               NAME                                 STATUS      MESSAGE                                       AGE
      openshift-marketplace   certified-operators                  Succeeded   The object has been successfully reconciled   42m
      openshift-marketplace   community-operators                  Succeeded   The object has been successfully reconciled   42m
      openshift-marketplace   elasticsearch                        Succeeded   The object has been successfully reconciled   27m
      openshift-marketplace   installed-redhat-default             Succeeded   The object has been successfully reconciled   26m
      openshift-marketplace   installed-redhat-openshift-logging   Succeeded   The object has been successfully reconciled   18m
      openshift-marketplace   redhat-operators                     Succeeded   The object has been successfully reconciled   42m

   2. 以下のようにファイルを編集します。

      $ oc edit csc elasticsearch -n openshift-marketplace
      
      apiVersion: operators.coreos.com/v1
      kind: CatalogSourceConfig
      metadata:
        creationTimestamp: "2020-02-18T15:09:00Z"
        finalizers:
        - finalizer.catalogsourceconfigs.operators.coreos.com
        generation: 3
        name: elasticsearch
        namespace: openshift-marketplace
        resourceVersion: "17694"
        selfLink: /apis/operators.coreos.com/v1/namespaces/openshift-marketplace/catalogsourceconfigs/elasticsearch
        uid: 97c0cd55-5260-11ea-873c-02939b2f528f
      spec:
        csDisplayName: Custom
        csPublisher: Custom
        packages: elasticsearch-operator
        targetNamespace: openshift-operators-redhat
        source: redhat-operators 1

      1

      現在の値を redhat-operators に変更します。

   3. Elasticsearch Subscription オブジェクトの名前を取得します。

      $ oc get sub
      
      NAME                  PACKAGE                  SOURCE          CHANNEL
      elasticsearch-pj7pf   elasticsearch-operator   elasticsearch   preview

   4. 以下のようにファイルを編集します。

      $ oc edit sub elasticsearch-pj7pf
      
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        creationTimestamp: "2020-02-17T17:51:18Z"
        generateName: elasticsearch-
        generation: 2
        name: elasticsearch-p5k7n
        namespace: openshift-operators-redhat
        resourceVersion: "38098"
        selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-operators-redhat/subscriptions/elasticsearch-p5k7n
        uid: 19f6df33-51ae-11ea-82b9-027dfdb65ec2
      spec:
        channel: "4.2"
        installPlanApproval: Automatic
        name: elasticsearch-operator
        source: redhat-operators 1
        sourceNamespace: openshift-marketplace 2
      ....

      1

      現在の値を redhat-operators に変更します。

      2

      現在の値を openshift-marketplace に変更します。

2. Elasticsearch Operator をアップグレードします。

   1. Web コンソールから、Operator Management をクリックします。
   2. プロジェクトを all projects に変更します。
   3. Elasticsearch サブスクリプションと同じ名前を持つ Elasticsearch Operator をクリックします。
   4. Subscription → Channel をクリックします。
   5. Change Subscription Update Channel ウィンドウで 4.2 を選択し、Save をクリックします。

   6. 数秒待ってから Operators → Installed Operators をクリックします。

      Elasticsearch Operator が 4.2 と表示されます。例:

      Elasticsearch Operator
      4.2.0-201909201915 provided
      by Red Hat, Inc

3. Cluster Logging Operator をアップグレードします。

   1. Web コンソールから、Operator Management をクリックします。
   2. プロジェクトを all projects に変更します。
   3. Cluster Logging Operatorをクリックします。
   4. Subscription → Channel をクリックします。
   5. Change Subscription Update Channel ウィンドウで 4.2 を選択し、Save をクリックします。

   6. 数秒待ってから Operators → Installed Operators をクリックします。

      Cluster Logging Operator は 4.2 として表示されます。例:

      Cluster Logging
      4.2.0-201909201915 provided
      by Red Hat, Inc

4. ロギングコンポーネントを確認します。

   1. Elasticsearch Pod が 4.2 イメージを使用していることを確認します。

      $ oc get pod -o yaml -n openshift-logging --selector component=elasticsearch |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-elasticsearch5:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915

   2. すべての 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

   3. Elasticsearch クラスターが正常であることを確認します。

      oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- es_cluster_health
      
      {
        "cluster_name" : "elasticsearch",
        "status" : "green",
      
      ....

   4. ロギングコレクター Pod が 4.2 イメージを使用していることを確認します。

      $ oc get pod -n openshift-logging --selector logging-infra=fluentd -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-fluentd:v4.2.0-201909201915

   5. Kibana Pod が 4.2 イメージを使用していることを確認します。

      $ oc get pod -n openshift-logging --selector logging-infra=kibana -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.2.0-201909210748
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915
      image: registry.redhat.io/openshift4/ose-logging-kibana5:v4.2.0-201909210748
      image: registry.redhat.io/openshift4/ose-oauth-proxy:v4.2.0-201909201915

   6. Curator CronJob が 4.2 イメージを使用していることを確認します。

      $ $ oc get CronJob curator -n openshift-logging -o yaml |grep 'image:'
      
      image: registry.redhat.io/openshift4/ose-logging-curator5:v4.2.0-201909201915

手順

1. イベントルーターのテンプレートを作成します。

   kind: Template
   apiVersion: v1
   metadata:
     name: eventrouter-template
     annotations:
       description: "A pod forwarding kubernetes events to cluster logging stack."
       tags: "events,EFK,logging,cluster-logging"
   objects:
     - kind: ServiceAccount 1
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
     - kind: ClusterRole 2
       apiVersion: v1
       metadata:
         name: event-reader
       rules:   3
       - apiGroups: [""]
         resources: ["events"]
         verbs: ["get", "watch", "list"]
     - kind: ClusterRoleBinding  4
       apiVersion: v1
       metadata:
         name: event-reader-binding
       subjects:
       - kind: ServiceAccount
         name: eventrouter
         namespace: ${NAMESPACE}
       roleRef:
         kind: ClusterRole
         name: event-reader
     - kind: ConfigMap
       apiVersion: v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
       data:
         config.json: |-
           {
             "sink": "stdout"
           }
     - kind: Deployment
       apiVersion: apps/v1
       metadata:
         name: eventrouter
         namespace: ${NAMESPACE}
         labels:
           component: eventrouter
           logging-infra: eventrouter
           provider: openshift
       spec:
         selector:
           matchLabels:
             component: eventrouter
             logging-infra: eventrouter
             provider: openshift
         replicas: 1
         template:
           metadata:
             labels:
               component: eventrouter
               logging-infra: eventrouter
               provider: openshift
             name: eventrouter
           spec:
             serviceAccount: eventrouter
             containers:
               - name: kube-eventrouter
                 image: ${IMAGE}
                 imagePullPolicy: IfNotPresent
                 resources:
                   limits:
                     memory: ${MEMORY}
                   requests:
                     cpu: ${CPU}
                     memory: ${MEMORY}
                 volumeMounts:
                 - name: config-volume
                   mountPath: /etc/eventrouter
             volumes:
               - name: config-volume
                 configMap:
                   name: eventrouter
   parameters:
     - name: IMAGE 5
       displayName: Image
       value: "registry.redhat.io/openshift4/ose-logging-eventrouter:latest"
     - name: MEMORY 6
       displayName: Memory
       value: "128Mi"
     - name: CPU  7
       displayName: CPU
       value: "100m"
     - name: NAMESPACE  8
       displayName: Namespace
       value: "openshift-logging"

   1

   イベントルーターのサービスアカウントを作成します。

   2

   クラスターロールを作成し、クラスター内のイベントを監視します。

   3

   events リソースの get、watch、および list パーミッションを許可します。

   4

   ClusterRoleBinding を作成し、ClusterRole を ServiceAccount にバインドします。

   5

   イベントルーターのイメージバージョンを指定します。

   6

   イベントルーター Pod のメモリー制限を指定します。デフォルトは '128Mi' になります。

   7

   イベントルーターに割り当てる CPU の最小量を指定します。デフォルトは '100m' になります。

   8

   イベントルーターがデプロイされる namespace を指定します。デフォルトは openshift-logging になります。この値は、ServiceAccount および ClusterRoleBinding に指定された値と同じでなければなりません。プロジェクトは、イベントを見つけることのできる Kibana の場所を示唆します。

   • イベントルーター Pod が、kube-* および openshift-* などのデフォルトプロジェクトでデプロイされる場合、イベントは .operation インデックスの下に見つけることができます。
   • イベントルーター Pod が他のプロジェクトにデプロイされている場合、イベントはプロジェクト namespace を使用してインデックスの下に見つけることができます。

2. 以下のコマンドを使用してテンプレートを処理し、これを適用します。

   $ oc process -f <templatefile> | oc apply -f -

   以下は例になります。

   $ oc process -f eventrouter.yaml | oc apply -f -
   
   serviceaccount/logging-eventrouter created
   clusterrole.authorization.openshift.io/event-reader created
   clusterrolebinding.authorization.openshift.io/event-reader-binding created
   configmap/logging-eventrouter created
   deployment.apps/logging-eventrouter created

3. イベントルーターがインストールされていることを確認します。

   $ oc get pods --selector  component=eventrouter -o name
   
   pod/logging-eventrouter-d649f97c8-qvv8r

   $ oc logs logging-eventrouter-d649f97c8-qvv8r
   
   {"verb":"ADDED","event":{"metadata":{"name":"elasticsearch-operator.v0.0.1.158f402e25397146","namespace":"openshift-operators","selfLink":"/api/v1/namespaces/openshift-operators/events/elasticsearch-operator.v0.0.1.158f402e25397146","uid":"37b7ff11-4f1a-11e9-a7ad-0271b2ca69f0","resourceVersion":"523264","creationTimestamp":"2019-03-25T16:22:43Z"},"involvedObject":{"kind":"ClusterServiceVersion","namespace":"openshift-operators","name":"elasticsearch-operator.v0.0.1","uid":"27b2ca6d-4f1a-11e9-8fba-0ea949ad61f6","apiVersion":"operators.coreos.com/v1alpha1","resourceVersion":"523096"},"reason":"InstallSucceeded","message":"waiting for install components to report healthy","source":{"component":"operator-lifecycle-manager"},"firstTimestamp":"2019-03-25T16:22:43Z","lastTimestamp":"2019-03-25T16:22:43Z","count":1,"type":"Normal"}}

1. ログの場所がファイルまたは CONSOLE (stdout) であるかを判別します。

   $ oc -n openshift-logging set env daemonset/fluentd --list | grep LOGGING_FILE_PATH

2. ログの場所によっては、logging コマンドを実行します。

   • LOGGING_FILE_PATH がファイルを参照する場合、デフォルトで、logs ユーティリティーを Pod が置かれているプロジェクトから使用し、Fluentd ログファイルの内容を出力します。

     $ oc exec <any-fluentd-pod> -- logs 1

     1

     ログコレクター Pod の名前を指定します。logs の前にスペースがあることに注意してください。

     例:

     $ oc exec fluentd-ht42r -n openshift-logging -- logs

   • LOGGING_FILE_PATH=console を使用している場合、ログコレクターはログを stdout/stderr に書き込みます。oc logs [-f] <pod_name> コマンドでログを取得できます (-f はオプション)。

     $ oc logs -f <any-fluentd-pod> -n openshift-logging 1

     1

     ログコレクター Pod の名前を指定します。-f オプションを使用してログに書き込まれている内容をフォローします。

     以下は例になります。

     $ oc logs -f fluentd-ht42r -n openshift-logging

     ログファイルの内容が出力されます。

     デフォルトで、Fluentd はログの末尾または終了部分からログを読み取ります。

1. OpenShift Container Platform コンソールで Workloads → Pods に移動します。
2. ドロップダウンメニューから openshift-logging プロジェクトを選択します。
3. fluentd プレフィックスを使ってロギングコレクター Pod のいずれかをクリックします。
4. Logs をクリックします。

1. OpenShift Container Platform コンソールで、Monitoring → Logging をクリックします。

2. OpenShift Container Platform コンソールにログインするために使用するものと同じ認証情報を使用してログインします。

   Kibana インターフェースが起動します。以下を実行することができます。

   • Discover ページを使用してデータを検索し、参照します。
   • Visualize ページを使用してデータのグラフを表示し、データをマップします。

   • Dashboard ページを使用してカスタムダッシュボードを作成し、表示します。

     Kibana インターフェースの使用および設定については、本書では扱いません。詳細については、Kibana のドキュメントを参照してください。

手順

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. Elasticsearch クラスターのステータスを表示するには、以下を実行します。

   1. Elasticsearch インスタンスの名前を取得します。

      $ oc get Elasticsearch
      
      NAME            AGE
      elasticsearch   5h9m

   2. Elasticsearch のステータスを取得します。

      $ oc get Elasticsearch <Elasticsearch-instance> -o yaml

      以下は例になります。

      $ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml

      出力には、以下のような情報が含まれます。

      status: 1
        cluster: 2
          activePrimaryShards: 30
          activeShards: 60
          initializingShards: 0
          numDataNodes: 3
          numNodes: 3
          pendingTasks: 0
          relocatingShards: 0
          status: green
          unassignedShards: 0
        clusterHealth: ""
        conditions: [] 3
        nodes: 4
        - deploymentName: elasticsearch-cdm-zjf34ved-1
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-2
          upgradeStatus: {}
        - deploymentName: elasticsearch-cdm-zjf34ved-3
          upgradeStatus: {}
        pods: 5
          client:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          data:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
          master:
            failed: []
            notReady: []
            ready:
            - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
            - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
            - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
        shardAllocationEnabled: all

      1

      出力の status スタンザに、クラスターステータスのフィールドが表示されます。

      2

      Elasticsearch クラスターのステータス:

      • アクティブなプライマリーシャードの数
      • アクティブなシャードの数
      • 初期化されるシャードの数
      • Elasticsearch データノードの数
      • Elasticsearch ノードの合計数
      • 保留中のタスクの数
      • Elasticsearch のステータス: green、red、yellow
      • 未割り当てのシャードの数

      3

      ステータスの状況 (ある場合)。Elasticsearch クラスターのステータスは、Pod が配置されていない場合にスケジューラーからの理由を示します。以下の状況に関連したイベントが表示されます。

      • Elasticsearch およびプロキシーコンテナーの両方についてコンテナーが待機中。
      • Elasticsearch およびプロキシーコンテナーの両方についてコンテナーが終了している。
      • Pod がスケジュール対象外である。さらに多数の問題についての状況が表示されます。詳細は、状況メッセージのサンプル を参照してください。

      4

      upgradeStatus のクラスター内の Elasticsearch ノード。

      5

      'failed`、notReady または ready 状態で一覧表示される、クラスターの Elasticsearch クライアント、データおよびマスター Pod。

手順

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. クラスターロギングのステータスを表示するには、以下を実行します。

   1. クラスターロギングのステータスを取得します。

      $ oc get clusterlogging instance -o yaml

      出力には、以下のような情報が含まれます。

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      
      ....
      
      status:  1
        collection:
          logs:
            fluentdStatus:
              daemonSet: fluentd  2
              nodes:
                fluentd-2rhqp: ip-10-0-169-13.ec2.internal
                fluentd-6fgjh: ip-10-0-165-244.ec2.internal
                fluentd-6l2ff: ip-10-0-128-218.ec2.internal
                fluentd-54nx5: ip-10-0-139-30.ec2.internal
                fluentd-flpnn: ip-10-0-147-228.ec2.internal
                fluentd-n2frh: ip-10-0-157-45.ec2.internal
              pods:
                failed: []
                notReady: []
                ready:
                - fluentd-2rhqp
                - fluentd-54nx5
                - fluentd-6fgjh
                - fluentd-6l2ff
                - fluentd-flpnn
                - fluentd-n2frh
        curation:  3
          curatorStatus:
          - cronJobs: curator
            schedules: 30 3 * * *
            suspended: false
        logstore: 4
          elasticsearchStatus:
          - ShardAllocationEnabled:  all
            cluster:
              activePrimaryShards:    5
              activeShards:           5
              initializingShards:     0
              numDataNodes:           1
              numNodes:               1
              pendingTasks:           0
              relocatingShards:       0
              status:                 green
              unassignedShards:       0
            clusterName:             elasticsearch
            nodeConditions:
              elasticsearch-cdm-mkkdys93-1:
            nodeCount:  1
            pods:
              client:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
              data:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
              master:
                failed:
                notReady:
                ready:
                - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
      visualization:  5
          kibanaStatus:
          - deployment: kibana
            pods:
              failed: []
              notReady: []
              ready:
              - kibana-7fb4fd4cc9-f2nls
            replicaSets:
            - kibana-7fb4fd4cc9
            replicas: 1

      1

      出力の status スタンザに、クラスターステータスのフィールドが表示されます。

      2

      Fluentd Pod についての情報

      3

      Curator Pod についての情報

      4

      Elasticsearch クラスターの健全性 (green、yellow、または red) などの Elasticsearch Pod についての情報

      5

      Kibana Pod についての情報

手順

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. クラスターロギングデプロイメントのステータスを表示します。

   $ oc describe deployment cluster-logging-operator

   出力には、以下のようなステータス情報が含まれます。

   Name:                   cluster-logging-operator
   
   ....
   
   Conditions:
     Type           Status  Reason
     ----           ------  ------
     Available      True    MinimumReplicasAvailable
     Progressing    True    NewReplicaSetAvailable
   
   ....
   
   Events:
     Type    Reason             Age   From                   Message
     ----    ------             ----  ----                   -------
     Normal  ScalingReplicaSet  62m   deployment-controller  Scaled up replica set cluster-logging-operator-574b8987df to 1----

3. クラスターロギング ReplicaSet のステータスを表示します。

   1. ReplicaSet の名前を取得します。

      $ oc get replicaset
      NAME                                      DESIRED   CURRENT   READY   AGE
      cluster-logging-operator-574b8987df       1         1         1       159m
      elasticsearch-cdm-uhr537yu-1-6869694fb    1         1         1       157m
      elasticsearch-cdm-uhr537yu-2-857b6d676f   1         1         1       156m
      elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd   1         1         1       155m
      kibana-5bd5544f87                         1         1         1       157m

   2. ReplicaSet のステータスを取得します。

      $ oc describe replicaset cluster-logging-operator-574b8987df

      出力には、以下のようなステータス情報が含まれます。

      Name:           cluster-logging-operator-574b8987df
      
      ....
      
      Replicas:       1 current / 1 desired
      Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
      
      ....
      
      Events:
        Type    Reason            Age   From                   Message
        ----    ------            ----  ----                   -------
        Normal  SuccessfulCreate  66m   replicaset-controller  Created pod: cluster-logging-operator-574b8987df-qjhqv----

手順

1. openshift-logging プロジェクトでクラスターロギングのカスタムリソースを編集します。

   $ oc edit ClusterLogging instance

   apiVersion: logging.openshift.io/v1
   kind: ClusterLogging
   
   ....
   
   spec:
     collection:
       logs:
         fluentd:
           resources: null
         type: fluentd
     curation:
       curator:
         nodeSelector: 1
             node-role.kubernetes.io/infra: ''
         resources: null
         schedule: 30 3 * * *
       type: curator
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
             node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         resources:
           limits:
             cpu: 500m
             memory: 16Gi
           requests:
             cpu: 500m
             memory: 16Gi
         storage: {}
       type: elasticsearch
     managementState: Managed
     visualization:
       kibana:
         nodeSelector: 3
             node-role.kubernetes.io/infra: '' 4
         proxy:
           resources: null
         replicas: 1
         resources: null
       type: kibana
   
   ....

1. openshift-logging プロジェクトに切り替えます。

   $ oc project openshift-logging

2. 以下のコマンドを使用して Elasticsearch から CA 証明書を抽出し、admin-ca ファイルに書き込みます。

   $ oc extract secret/elasticsearch --to=. --keys=admin-ca
   
   admin-ca

3. シャードの同期フラッシュを実行して、シャットダウン前にディスクへの書き込みを待機している保留中の操作がないようにします。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- curl -s --cacert /etc/elasticsearch/secret/admin-ca --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key -XPOST 'https://localhost:9200/_flush/synced'

   以下は例になります。

   oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -- curl -s --cacert /etc/elasticsearch/secret/admin-ca --cert /etc/elasticsearch/secret/admin-cert --key /etc/elasticsearch/secret/admin-key -XPOST 'https://localhost:9200/_flush/synced'

4. OpenShift Container Platform es_util ツールを使用して、ノードを意図的に停止する際のシャードのバランシングを防ぎます。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/settings -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'

   以下は例になります。

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/settings?pretty=true -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'
   
   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "none"
           }
         }
       }
     }

5. 完了したら、ES クラスターのそれぞれのデプロイメントについて、以下を実行します。

   1. デフォルトで、OpenShift Container Platform Elasticsearch クラスターはノードのロールアウトをブロックします。以下のコマンドを使用してロールアウトを許可し、Pod が変更を取得できるようにします。

      $ oc rollout resume deployment/<deployment-name>

      以下は例になります。

      $ oc rollout resume deployment/elasticsearch-cdm-0-1
      deployment.extensions/elasticsearch-cdm-0-1 resumed

      新規 Pod がデプロイされます。Pod が準備状態のコンテナーを持つと、次のデプロイメントに進むことができます。

      $ oc get pods | grep elasticsearch-*
      
      NAME                                            READY   STATUS    RESTARTS   AGE
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h

   2. 完了したら、ロールアウトを許可しないように Pod をリセットします。

      $ oc rollout pause deployment/<deployment-name>

      以下は例になります。

      $ oc rollout pause deployment/elasticsearch-cdm-0-1
      
      deployment.extensions/elasticsearch-cdm-0-1 paused

   3. Elasticsearch クラスターが green 状態にあることを確認します。

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true

      注記

      直前のコマンドで使用した Elasticsearch Pod でロールアウトを実行した場合、Pod は存在しなくなっているため、ここで新規 Pod 名が必要になります。

      以下は例になります。

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      
      {
        "cluster_name" : "elasticsearch",
        "status" : "green", 1
        "timed_out" : false,
        "number_of_nodes" : 3,
        "number_of_data_nodes" : 3,
        "active_primary_shards" : 8,
        "active_shards" : 16,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 1,
        "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
      }

      1

      次に進む前に、このパラメーターが green であることを確認します。

6. Elasticsearch 設定マップを変更した場合、それぞれの Elasticsearch Pod についてこれらの手順を繰り返します。

7. クラスターのすべてのデプロイメントがロールアウトされたら、シャードのバランシングを再度有効にします。

   $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/settings -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "none" } }'

   以下は例になります。

   $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/settings?pretty=true -XPUT 'https://localhost:9200/_cluster/settings' -d '{ "transient": { "cluster.routing.allocation.enable" : "all" } }'
   
   {
     "acknowledged" : true,
     "persistent" : { },
     "transient" : {
       "cluster" : {
         "routing" : {
           "allocation" : {
             "enable" : "all"
           }
         }
       }
     }
   }

1. 以下のコマンドを実行し、現在の OAuthClient を削除します。

   $ oc delete oauthclient/kibana-proxy

1. 以下のコマンドを実行し、現在の OAuthClient を削除します。

   $ oc delete oauthclient/kibana-proxy

1. 以下のコマンドを使用して、デプロイメント時に生成されたすべてのものを削除します。

   $ oc delete clusterlogging instance -n openshift-logging

2. 以下のコマンドを使用して、Operator インスタンスの削除後も保持される Persistent Volume Claim（永続ボリューム要求、PVC）を削除します。

   $ oc delete pvc --all -n openshift-logging