第1章 クラスターロギングおよび OpenShift Container Platform について

クラスターロギングコンポーネントは Elasticsearch、Fluentd、Kibana (EFK) に基づいています。コレクターの Fluentd は、OpenShift Container Platform クラスターの各ノードにデプロイされます。これはすべてのノードおよびコンテナーのログを収集し、それらを Elasticsearch (ES) に書き込みます。Kibana は、ユーザーおよび管理者が集計されたデータを使って高度な視覚化およびダッシュボードを作成できる中央の Web UI です。

現時点で、4 種類のクラスターロギングコンポーネントがあります。

本書では、特筆されない限り、logStore と Elasticsearch、visualization と Kibana、curation と Curator、collection と Fluentd を区別せずに使用する場合があります。

OpenShift Container Platform は Elasticsearch (ES) を使用して Fluentd からのログデータを、データストアまたは インデックス に編成します。

Elasticsearch は、各インデックスを シャード と呼ばれる複数の部分に細分化し、Elasticsearch クラスター内の Elasticsearch ノードセット全体に分散します。Elasticsearch を レプリカ というシャードのコピーを作成するように設定できます。さらに、Elasticsearch はレプリカを Elactisearch ノード全体に分散します。ClusterLogging カスタムリソースにより、カスタムリソース定義 (CRD) にレプリケーションポリシーを指定して、データの冗長性および耐障害性を提供することができます。

Cluster Logging Operator および Elasticsearch Operator は、各 Elasticsearch ノードが独自のストレージボリュームを含む一意の Deployment を使用してデプロイされるようにします。クラスターロギングのカスタムリソース (CR) を使用して Elasticsearch ノードの数を増やすことができます。以下に示すように、ストレージおよびネットワークの場所を選択する際の留意事項については、Elastic のドキュメント を参照してください。

詳細は「Elasticsearch (ES)」を参照してください。

OpenShift Container Platform は Fluentd を使用してクラスターについてのデータを収集します。

Fluentd は、Pod を各 OpenShift Container Platform ノードにデプロイする OpenShift Container Platform の DaemonSet としてデプロイされます。

Fluentd は journald をシステムログソースとして使用します。これらは、オペレーティングシステム、コンテナーランタイム、および OpenShift Container Platform からのログメッセージです。

コンテナーランタイムは、プロジェクト、Pod 名、およびコンテナー ID などのログメッセージのソースを特定するための最小限の情報を提供します。この情報だけでは、ログのソースを一意に特定することはできません。ログコレクターがログを処理する前に、指定された名前およびプロジェクトを持つ Pod が削除される場合、ラベルやアノテーションなどの API サーバーからの情報は利用できません。そのため、似たような名前の Pod やプロジェクトからログメッセージを区別したり、ログのソースを追跡することができない場合があります。この制限により、ログの収集および正規化は ベストエフォート ベースであると見なされます。

詳細情報は、「 Fluentd」を参照してください。

OpenShift Container Platform は Kibana を使用して、Fluentd によって収集され、Elasticsearch によってインデックス化されるログデータを表示します。

Kibana は、ヒストグラム、線グラフ、円グラフ、ヒートマップ、ビルトインされた地理空間サポート、その他の視覚化機能を使用して Elasticsearch データをクエリーし、検出し、視覚化するためのブラウザーベースのコンソールインターフェースです。

詳細は、「Kibana」を参照してください。

Elasticsearch Curator ツールは、グローバルに、またはプロジェクトごとにスケジュールされたメンテナンス操作を実行します。Curator はその設定に基づき、日次ベースで動作を実行します。Elasticsearch クラスターあたり 1 つの Curator Pod のみの使用が推奨されます。

spec:
  curation:
  type: "curator"
  resources:
  curator:
    schedule: "30 3 * * *" 1

詳細は「Curator」を参照してください。

イベントルーターは、OpenShift Container Platform イベントをクラスターロギングに転送する Pod です。イベントルーターは手動でデプロイする必要があります。

イベントルーターはイベントを収集し、それらを JSON 形式に変換します。この形式では、イベントの取得後、それらを STDOUT にプッシュします。Fluentd はイベントを .operations インデックスにインデックス化します。

Cluster Logging Operator のカスタムリソース定義 (CRD) は、ログを収集し、保存し、視覚化するためのロギングスタックのすべてのコンポーネントが含まれる完全なクラスターロギングデプロイメントを定義します。

この CRD を変更する必要は一切ありません。デプロイメントを変更するには、特定のカスタムリソース (CR) を作成し、変更します。CR の作成または変更方法については、このドキュメントで適宜説明されます。

以下は、クラスターロギングの通常のクラスターリソースの例です。

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: openshift-logging
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 2
      resources:
        limits:
          memory: 2Gi
        requests:
          cpu: 200m
          memory: 2Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources:
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  curation:
    type: "curator"
    curator:
      resources:
        limits:
          memory: 200Mi
        requests:
          cpu: 200m
          memory: 200Mi
      schedule: "*/10 * * * *"
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 200m
            memory: 1Gi