5.5. インストール後のタスク


Red Hat OpenShift Logging Operator をインストールした後、ClusterLogging カスタムリソース (CR) を作成および変更してデプロイメントを設定できます。

ヒント

Elasticsearch ログストアを使用していない場合は、内部 Elasticsearch logStore および Kibana visualization コンポーネントを ClusterLogging カスタムリソース (CR) から削除できます。これらのコンポーネントの削除はオプションですが、これによりリソースを節約できます。Elasticsearch ログストアを使用しない場合の未使用コンポーネントの削除 を参照してください。

5.5.1. ClusterLogging カスタムリソースについて

ロギング環境を変更するには、ClusterLogging カスタムリソース (CR) を作成し、変更します。

ClusterLogging カスタムリソース (CRD) のサンプル

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance 1
  namespace: openshift-logging 2
spec:
  managementState: Managed 3
# ...

1
CR の名前は instance である必要があります。
2
CR は openshift-logging namespace にインストールされる必要があります。
3
Red Hat OpenShift Logging Operator の管理状態。状態が Unmanaged に設定されている場合、Operator はサポート対象外となり、更新は受け取りません。

5.5.2. ログストレージの設定

ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログストレージのタイプを設定できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator と内部ログストア (LokiStack または Elasticsearch) がインストールされている。
  • ClusterLogging CR が作成されている。
注記

Logging 5.9 リリースに、OpenShift Elasticsearch Operator の更新バージョンは含まれていません。ロギング 5.8 でリリースされた OpenShift Elasticsearch Operator を現在使用している場合、Logging 5.8 の EOL まで引き続き Logging で機能します。OpenShift Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。Logging のライフサイクルの日付の詳細は、Platform Agnostic Operator を参照してください。

手順

  1. ClusterLogging CR の logStore 仕様を変更します。

    ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      logStore:
        type: <log_store_type> 1
        elasticsearch: 2
          nodeCount: <integer>
          resources: {}
          storage: {}
          redundancyPolicy: <redundancy_type> 3
        lokistack: 4
          name: {}
    # ...

    1
    ログストアのタイプを指定します。これは lokistack または elasticsearch のいずれかです。
    2
    Elasticsearch ログストアの任意の設定オプション。
    3
    冗長性のタイプを指定します。この値には、ZeroRedundancySingleRedundancyMultipleRedundancy、または FullRedundancy を指定できます。
    4
    LokiStack の任意の設定オプション。

    LokiStack をログストアとして指定する ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
      name: instance
      namespace: openshift-logging
    spec:
      managementState: Managed
      logStore:
        type: lokistack
        lokistack:
          name: logging-loki
    # ...

  2. 次のコマンドを実行して、ClusterLogging CR を適用します。

    $ oc apply -f <filename>.yaml

5.5.3. ログコレクターの設定

ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログコレクターのタイプを設定できます。

注記

Fluentd は非推奨となっており、今後のリリースで削除される予定です。Red Hat は、現在のリリースのライフサイクル中にこの機能のバグ修正とサポートを提供しますが、この機能は拡張されなくなりました。Fluentd の代わりに、Vector を使用できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • ClusterLogging CR が作成されている。

手順

  1. ClusterLogging CR の collection 仕様を変更します。

    ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      collection:
        type: <log_collector_type> 1
        resources: {}
        tolerations: {}
    # ...

    1
    ロギングに使用するログコレクターのタイプ。これは、vector または fluentd にすることができます。
  2. 次のコマンドを実行して、ClusterLogging CR を適用します。

    $ oc apply -f <filename>.yaml

5.5.4. ログビジュアライザーの設定

ClusterLogging カスタムリソース (CR) を変更することで、ロギングで使用するログビジュアライザーのタイプを設定できます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • Red Hat OpenShift Logging Operator がインストールされている。
  • ClusterLogging CR が作成されている。
重要

可視化に OpenShift Container Platform Web コンソールを使用する場合は、ロギングコンソールプラグインを有効にする必要があります。「Web コンソールによるログの可視化」に関するドキュメントを参照してください。

手順

  1. ClusterLogging CR の visualization 仕様を変更します。

    ClusterLogging CR の例

    apiVersion: logging.openshift.io/v1
    kind: ClusterLogging
    metadata:
    # ...
    spec:
    # ...
      visualization:
        type: <visualizer_type> 1
        kibana: 2
          resources: {}
          nodeSelector: {}
          proxy: {}
          replicas: {}
          tolerations: {}
        ocpConsole: 3
          logsLimit: {}
          timeout: {}
    # ...

    1
    ロギングに使用するビジュアライザーのタイプ。これは、kibana または ocp-console のいずれかです。Kibana コンソールは Elasticsearch ログストレージを使用するデプロイメントとのみ互換性があり、OpenShift Container Platform コンソールは LokiStack デプロイメントとのみ互換性があります。
    2
    Kibana コンソールの任意の設定。
    3
    OpenShift Container Platform Web コンソールの任意の設定。
  2. 次のコマンドを実行して、ClusterLogging CR を適用します。

    $ oc apply -f <filename>.yaml

5.5.5. ネットワークの分離が有効になっている場合のプロジェクト間のトラフィックの許可

クラスターネットワークプラグインによって、ネットワークの分離が実施される場合があります。その場合は、OpenShift Logging によってデプロイされる Operator が含まれるプロジェクト間のネットワークトラフィックを許可する必要があります。

ネットワークの分離は、異なるプロジェクトにある Pod およびサービス間のネットワークトラフィックをブロックします。ロギングは、OpenShift Elasticsearch Operatoropenshift-operators-redhat プロジェクトにインストールし、Red Hat OpenShift Logging Operatoropenshift-logging プロジェクトにインストールします。したがって、これら 2 つのプロジェクト間のトラフィックを許可する必要があります。

OpenShift Container Platform は、ネットワークプラグインとして、OpenShift SDN と OVN-Kubernetes の 2 つのサポートされた選択肢を提供します。これら 2 つのプロバイダーはさまざまなネットワーク分離ポリシーを実装します。

OpenShift SDN には 3 つのモードがあります。

network policy (ネットワークポリシー)
これはデフォルトモードになります。ポリシーが定義されていない場合は、すべてのトラフィックを許可します。ただし、ユーザーがポリシーを定義する場合、通常はすべてのトラフィックを拒否し、例外を追加して開始します。このプロセスでは、異なるプロジェクトで実行されているアプリケーションが破損する可能性があります。そのため、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可します。
multitenant (マルチテナント)
このモードは、ネットワークの分離を実行します。2 つのロギング関連のプロジェクトを結合して、それらのプロジェクト間のトラフィックを許可します。
subnet (サブネット)
このモードでは、すべてのトラフィックを許可します。ネットワーク分離は実行しません。アクションは不要です。

OVN-Kubernetes は常に ネットワークポリシー を使用します。そのため、OpenShift SDN の場合と同様に、ポリシーを明示的に設定し、1 つのロギング関連のプロジェクトから他のプロジェクトへの egress のトラフィックを許可する必要があります。

手順

  • multitenant モードで OpenShift SDN を使用している場合は、2 つのプロジェクトに参加します。以下に例を示します。

    $ oc adm pod-network join-projects --to=openshift-operators-redhat openshift-logging
  • または、network policy の OpenShift SDN および OVN-Kubernetes の場合は、以下の操作を実行します。

    1. openshift-operators-redhat namespace にラベルを設定します。以下に例を示します。

      $ oc label namespace openshift-operators-redhat project=openshift-operators-redhat
    2. openshift-operators-redhatopenshift-monitoring、およびopenshift-ingressプロジェクトから openshift-logging プロジェクトへの入力を許可する、openshift-logging namespace にネットワークポリシーオブジェクトを作成します。以下に例を示します。

      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring-ingress-operators-redhat
      spec:
        ingress:
        - from:
          - podSelector: {}
        - from:
          - namespaceSelector:
              matchLabels:
                project: "openshift-operators-redhat"
        - from:
          - namespaceSelector:
              matchLabels:
                name: "openshift-monitoring"
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: ingress
        podSelector: {}
        policyTypes:
        - Ingress
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.