10.2. ログストレージのインストール


OpenShift CLI (oc) または OpenShift Container Platform Web コンソールを使用して、OpenShift Container Platform クラスターにログストアをデプロイできます。

注記

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 を参照してください。

10.2.1. Loki ログストアのデプロイ

Loki Operator を使用して、OpenShift Container Platform クラスターに内部 Loki ログストアをデプロイできます。Loki Operator をインストールした後、シークレットを作成することで Loki オブジェクトストレージを設定し、LokiStack カスタムリソース (CR) を作成する必要があります。

10.2.1.1. Loki デプロイメントのサイズ

Loki のサイズは 1x.<size> の形式に従います。この場合の 1x はインスタンスの数を、<size> は性能を指定します。

重要

デプロイメントサイズの 1x の数は変更できません。

表10.1 Loki のサイズ
 1x.demo1x.extra-small1x.small1x.medium

Data transfer

デモ使用のみ

100 GB/日

500 GB/日

2 TB/日

1 秒あたりのクエリー数 (QPS)

デモ使用のみ

200 ミリ秒で 1 - 25 QPS

200 ミリ秒で 25 - 50 QPS

200 ミリ秒で 25 - 75 QPS

レプリケーション係数

なし

2

2

2

合計 CPU 要求

なし

仮想 CPU 14 個

仮想 CPU 34 個

仮想 CPU 54 個

ルーラーを使用する場合の合計 CPU リクエスト

なし

仮想 CPU 16 個

仮想 CPU 42 個

仮想 CPU 70 個

合計メモリー要求

なし

31 Gi

67 Gi

139 Gi

ルーラーを使用する場合の合計メモリーリクエスト

なし

35Gi

83Gi

171Gi

合計ディスク要求

40Gi

430 Gi

430 Gi

590Gi

ルーラーを使用する場合の合計ディスクリクエスト

80Gi

750Gi

750Gi

910Gi

10.2.1.2. OpenShift Container Platform Web コンソールを使用して MTV Operator をインストールする

OpenShift Container Platform クラスターにロギングをインストールして設定するには、追加の Operator をインストールする必要があります。これは、Web コンソールの Operator Hub から実行できます。

OpenShift Container Platform Operator は、カスタムリソース (CR) を使用してアプリケーションとそのコンポーネントを管理します。高レベルの構成と設定は、CR 内でユーザーが指定します。Operator は、Operator のロジック内に組み込まれたベストプラクティスに基づいて、高レベルのディレクティブを低レベルのアクションに変換します。カスタムリソース定義 (CRD) は CR を定義し、Operator のユーザーが使用できるすべての設定をリストします。Operator をインストールすると CRD が作成され、CR の生成に使用されます。

前提条件

  • サポートされているオブジェクトストア (AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation) にアクセスできる。
  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators OperatorHub に移動します。
  2. Filter by keyword フィールドに Loki Operator と入力します。使用可能な Operator のリストで Loki Operator をクリックし、Install をクリックします。

    重要

    Community Loki Operator は Red Hat ではサポートされていません。

  3. Update channel として stable または stable-x.y を選択します。

    注記

    stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-x.y に変更する必要があります。x.y は、インストールしたログのメジャーバージョンとマイナーバージョンを表します。たとえば、stable-5.7 です。

    Loki Operator はグローバルオペレーターグループ namespace である openshift-operators-redhat にデプロイする必要があるため、Installation modeInstalled Namespace がすでに選択されています。この namespace がない場合は、自動的に作成されます。

  4. Enable operator-recommended cluster monitoring on this namespace. を選択します。

    このオプションは、Namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

  5. Update approvaAutomatic を選択し、Install をクリックします。

    サブスクリプションの承認ストラテジーが Automatic に設定されている場合、アップグレードプロセスは、選択したチャネルで新規 Operator バージョンが利用可能になるとすぐに開始します。承認ストラテジーが Manual に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。

検証

  1. Operators Installed Operators に移動します。
  2. openshift-logging プロジェクトが選択されていることを確認します。
  3. Status 列に、緑色のチェックマークおよび InstallSucceeded と、Up to date というテキストが表示されていることを確認します。
注記

インストールが完了する前に、Operator に Failed ステータスが表示される場合があります。InstallSucceeded メッセージが表示されて Operator のインストールが完了した場合は、ページを更新します。

10.2.1.3. Web コンソールを使用して Loki オブジェクトストレージのシークレットを作成する

Loki オブジェクトストレージを設定するには、シークレットを作成する必要があります。OpenShift Container Platform Web コンソールを使用してシークレットを作成できます。

前提条件

  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Loki Operator がインストールされている。

手順

  1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Workloads Secrets に移動します。
  2. Create ドロップダウンリストから、From YAML を選択します。
  3. access_key_id フィールドと access_key_secret フィールドを使用して認証情報を指定し、bucketnamesendpoint、および region フィールドを使用してオブジェクトの保存場所を定義するシークレットを作成します。次の例では、AWS が使用されています。

    Secret オブジェクトの例

    apiVersion: v1
    kind: Secret
    metadata:
      name: logging-loki-s3
      namespace: openshift-logging
    stringData:
      access_key_id: AKIAIOSFODNN7EXAMPLE
      access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
      bucketnames: s3-bucket-name
      endpoint: https://s3.eu-central-1.amazonaws.com
      region: eu-central-1

10.2.1.4. Web コンソールを使用して LokiStack カスタムリソースを作成する

OpenShift Container Platform Web コンソールを使用して、LokiStack カスタムリソース (CR) を作成できます。

前提条件

  • 管理者権限がある。
  • OpenShift Container Platform Web コンソールにアクセスできる。
  • Loki Operator がインストールされている。

手順

  1. Operators Installed Operators ページに移動します。All instances タブをクリックします。
  2. Create new ドロップダウンリストから、LokiStack を選択します。
  3. YAML view を選択し、次のテンプレートを使用して LokiStack CR を作成します。

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki 1
      namespace: openshift-logging
    spec:
      size: 1x.small 2
      storage:
        schemas:
        - version: v12
          effectiveDate: '2022-06-01'
        secret:
          name: logging-loki-s3 3
          type: s3 4
      storageClassName: <storage_class_name> 5
      tenants:
        mode: openshift-logging 6
    1
    logging-loki という名前を使用します。
    2
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    重要

    デプロイメントサイズの 1x の数は変更できません。

    3
    ログストレージに使用するシークレットを指定します。
    4
    対応するストレージタイプを指定します。
    5
    一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
    6
    LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
  4. Create をクリックします。

10.2.1.5. CLI を使用して Loki Operator をインストールする

OpenShift Container Platform クラスターにロギングをインストールして設定するには、追加の Operator をインストールする必要があります。これは、OpenShift Container Platform CLI から実行できます。

OpenShift Container Platform Operator は、カスタムリソース (CR) を使用してアプリケーションとそのコンポーネントを管理します。高レベルの構成と設定は、CR 内でユーザーが指定します。Operator は、Operator のロジック内に組み込まれたベストプラクティスに基づいて、高レベルのディレクティブを低レベルのアクションに変換します。カスタムリソース定義 (CRD) は CR を定義し、Operator のユーザーが使用できるすべての設定をリストします。Operator をインストールすると CRD が作成され、CR の生成に使用されます。

前提条件

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。
  • サポートされているオブジェクトストアにアクセスできる。例: AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation。

手順

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

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: loki-operator
      namespace: openshift-operators-redhat 1
    spec:
      channel: stable 2
      name: loki-operator
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace
    1
    openshift-operators-redhat namespace を指定する必要があります。
    2
    チャネルとして stable または stable-5.<y> を指定します。
    3
    redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。
  2. Subscription オブジェクトを適用します。

    $ oc apply -f <filename>.yaml

10.2.1.6. CLI を使用して Loki オブジェクトストレージのシークレットを作成する

Loki オブジェクトストレージを設定するには、シークレットを作成する必要があります。これは、OpenShift CLI (oc) を使用して実行できます。

前提条件

  • 管理者権限がある。
  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを使用して、証明書とキーファイルが含まれるディレクトリーにシークレットを作成できます。

    $ oc create secret generic -n openshift-logging <your_secret_name> \
     --from-file=tls.key=<your_key_file>
     --from-file=tls.crt=<your_crt_file>
     --from-file=ca-bundle.crt=<your_bundle_file>
     --from-literal=username=<your_username>
     --from-literal=password=<your_password>
注記

最良の結果を得るには、generic または opaque シークレットを使用してください。

検証

  • 次のコマンドを実行して、シークレットが作成されたことを確認します。

    $ oc get secrets

10.2.1.7. CLI を使用して LokiStack カスタムリソースを作成する

OpenShift CLI (oc) を使用して、LokiStack カスタムリソース (CR) を作成できます。

前提条件

  • 管理者権限がある。
  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. LokiStack CR を作成します。

    LokiStack CR の例

    apiVersion: loki.grafana.com/v1
    kind: LokiStack
    metadata:
      name: logging-loki
      namespace: openshift-logging
    spec:
      size: 1x.small 1
      storage:
        schemas:
        - version: v12
          effectiveDate: "2022-06-01"
        secret:
          name: logging-loki-s3 2
          type: s3 3
      storageClassName: <storage_class_name> 4
      tenants:
        mode: openshift-logging 5

    1
    デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは 1x.extra-small1x.small、または 1x.medium です。
    重要

    デプロイメントサイズの 1x の数は変更できません。

    2
    ログストアシークレットの名前を指定します。
    3
    ログストアシークレットのタイプを指定します。
    4
    一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses コマンドを使用してリスト表示できます。
    5
    LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
  2. 次のコマンドを実行して、LokiStack CR を適用します。

    $ oc apply -f <filename>.yaml

検証

  • 次のコマンドを実行して出力を観察し、openshift-logging プロジェクト内の Pod をリスト表示してインストールを確認します。

    $ oc get pods -n openshift-logging

    次のリストのように、ロギングコンポーネント用の Pod が複数表示されていることを確認します。

    出力例

    NAME                                           READY   STATUS    RESTARTS   AGE
    cluster-logging-operator-78fddc697-mnl82       1/1     Running   0          14m
    collector-6cglq                                2/2     Running   0          45s
    collector-8r664                                2/2     Running   0          45s
    collector-8z7px                                2/2     Running   0          45s
    collector-pdxl9                                2/2     Running   0          45s
    collector-tc9dx                                2/2     Running   0          45s
    collector-xkd76                                2/2     Running   0          45s
    logging-loki-compactor-0                       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-25j9g       1/1     Running   0          8m2s
    logging-loki-distributor-b85b7d9fd-xwjs6       1/1     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-hjhl4          2/2     Running   0          8m2s
    logging-loki-gateway-7bb86fd855-qjtlb          2/2     Running   0          8m2s
    logging-loki-index-gateway-0                   1/1     Running   0          8m2s
    logging-loki-index-gateway-1                   1/1     Running   0          7m29s
    logging-loki-ingester-0                        1/1     Running   0          8m2s
    logging-loki-ingester-1                        1/1     Running   0          6m46s
    logging-loki-querier-f5cf9cb87-9fdjd           1/1     Running   0          8m2s
    logging-loki-querier-f5cf9cb87-fp9v5           1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-lfvbc   1/1     Running   0          8m2s
    logging-loki-query-frontend-58c579fcb7-tjf9k   1/1     Running   0          8m2s
    logging-view-plugin-79448d8df6-ckgmx           1/1     Running   0          46s

10.2.2. Loki オブジェクトストレージ

Loki Operator は、AWS S3 だけでなく、MinioOpenShift Data Foundation などの他の S3 互換オブジェクトストアもサポートしています。AzureGCS、および Swift もサポートされています。

Loki ストレージの推奨命名法は、logging-loki-<your_storage_provider> です。

次の表は、各ストレージプロバイダーの LokiStack カスタムリソース (CR) 内の type 値を示しています。詳細は、ストレージプロバイダーに関するセクションを参照してください。

表10.2 シークレットタイプのクイックリファレンス
ストレージプロバイダーシークレットの type

AWS

s3

Azure

azure

Google Cloud

gcs

Minio

s3

OpenShift Data Foundation

s3

Swift

swift

10.2.2.1. AWS ストレージ

前提条件

手順

  • 次のコマンドを実行して、logging-loki-aws という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-aws \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<aws_bucket_endpoint>" \
      --from-literal=access_key_id="<aws_access_key_id>" \
      --from-literal=access_key_secret="<aws_access_key_secret>" \
      --from-literal=region="<aws_region_of_your_bucket>"

10.2.2.2. Azure ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Azure 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-azure という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-azure \
      --from-literal=container="<azure_container_name>" \
      --from-literal=environment="<azure_environment>" \ 1
      --from-literal=account_name="<azure_account_name>" \
      --from-literal=account_key="<azure_account_key>"
    1
    サポートされている環境値は、AzureGlobalAzureChinaCloudAzureGermanCloudAzureUSGovernment です。

10.2.2.3. Google Cloud Platform ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Google Cloud Platform (GCP) 上に プロジェクト を作成している。
  • 同じプロジェクト内に バケット を作成している。
  • 同じプロジェクト内に GCP 認証用の サービスアカウント を作成している。

手順

  1. GCP から受け取ったサービスアカウントの認証情報を key.json という名前のファイルにコピーします。
  2. 次のコマンドを実行して、logging-loki-gcs という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-gcs \
      --from-literal=bucketname="<bucket_name>" \
      --from-file=key.json="<path/to/key.json>"

10.2.2.4. Minio ストレージ

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Minio がクラスターにデプロイされている。
  • Minio 上に バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-minio という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-minio \
      --from-literal=bucketnames="<bucket_name>" \
      --from-literal=endpoint="<minio_bucket_endpoint>" \
      --from-literal=access_key_id="<minio_access_key_id>" \
      --from-literal=access_key_secret="<minio_access_key_secret>"

10.2.2.5. OpenShift Data Foundation ストレージ

前提条件

手順

  1. openshift-logging namespace に ObjectBucketClaim カスタムリソースを作成します。

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: loki-bucket-odf
      namespace: openshift-logging
    spec:
      generateBucketName: loki-bucket-odf
      storageClassName: openshift-storage.noobaa.io
  2. 次のコマンドを実行して、関連付けられた ConfigMap オブジェクトからバケットのプロパティーを取得します。

    BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
    BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
    BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')
  3. 次のコマンドを実行して、関連付けられたシークレットからバケットアクセスキーを取得します。

    ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
    SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
  4. 次のコマンドを実行して、logging-loki-odf という名前のオブジェクトストレージシークレットを作成します。

    $ oc create -n openshift-logging secret generic logging-loki-odf \
    --from-literal=access_key_id="<access_key_id>" \
    --from-literal=access_key_secret="<secret_access_key>" \
    --from-literal=bucketnames="<bucket_name>" \
    --from-literal=endpoint="https://<bucket_host>:<bucket_port>"

10.2.2.6. Swift ストレージ:

前提条件

  • Loki Operator がインストールされている。
  • OpenShift CLI (oc) がインストールされている。
  • Swift 上で バケット を作成している。

手順

  • 次のコマンドを実行して、logging-loki-swift という名前のオブジェクトストレージシークレットを作成します。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>"
  • 必要に応じて、次のコマンドを実行して、プロジェクト固有のデータ、リージョン、またはその両方を指定できます。

    $ oc create secret generic logging-loki-swift \
      --from-literal=auth_url="<swift_auth_url>" \
      --from-literal=username="<swift_usernameclaim>" \
      --from-literal=user_domain_name="<swift_user_domain_name>" \
      --from-literal=user_domain_id="<swift_user_domain_id>" \
      --from-literal=user_id="<swift_user_id>" \
      --from-literal=password="<swift_password>" \
      --from-literal=domain_id="<swift_domain_id>" \
      --from-literal=domain_name="<swift_domain_name>" \
      --from-literal=container_name="<swift_container_name>" \
      --from-literal=project_id="<swift_project_id>" \
      --from-literal=project_name="<swift_project_name>" \
      --from-literal=project_domain_id="<swift_project_domain_id>" \
      --from-literal=project_domain_name="<swift_project_domain_name>" \
      --from-literal=region="<swift_region>"

10.2.3. Elasticsearch ログストアのデプロイ

OpenShift Elasticsearch Operator を使用して、OpenShift Container Platform クラスターに内部 Elasticsearch ログストアをデプロイできます。

注記

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 を参照してください。

10.2.3.1. Elasticsearch のストレージに関する考慮事項

永続ボリュームがそれぞれの Elasticsearch デプロイメント設定に必要です。OpenShift Container Platform では、これは永続ボリューム要求 (PVC) を使用して実行されます。

注記

永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

OpenShift Elasticsearch Operator は Elasticsearch リソース名を使用して PVC に名前を付けます。

Fluentd は systemd ジャーナル および /var/log/containers/*.log から Elasticsearch にログを送信します。

Elasticsearch では、大規模なマージ操作を実行するのに十分なメモリーが必要です。十分なメモリーがない場合は、応答しなくなります。この問題を回避するには、必要なアプリケーションのログデータの量を評価し、空き容量の約 2 倍を割り当てます。

デフォルトで、ストレージ容量が 85% に達すると、Elasticsearch は新規データのノードへの割り当てを停止します。90% になると、Elasticsearch は可能な場合に既存のシャードをそのノードから他のノードに移動しようとします。ただし、空き容量のレベルが 85% 未満のノードがない場合、Elasticsearch は新規インデックスの作成を拒否し、ステータスは RED になります。

注記

これらの基準値 (高い値および低い値を含む) は現行リリースにおける Elasticsearch のデフォルト値です。これらのデフォルト値は変更できます。アラートは同じデフォルト値を使用しますが、これらの値をアラートで変更することはできません。

10.2.3.2. Web コンソールを使用した OpenShift Elasticsearch Operator のインストール

OpenShift Elasticsearch Operator は、OpenShift Logging によって使用される Elasticsearch クラスターを作成し、管理します。

前提条件

  • Elasticsearch はメモリー集約型アプリケーションです。それぞれの Elasticsearch ノードには、ClusterLogging カスタムリソースで指定しない限り、メモリー要求および制限の両方に 16GB 以上のメモリーが必要です。

    初期設定の OpenShift Container Platform ノードのセットは、Elasticsearch クラスターをサポートするのに十分な大きさではない場合があります。その場合、推奨されるサイズ以上のメモリー (各 Elasticsearch ノードに最大 64GB) を使用して実行できるようにノードを OpenShift Container Platform クラスターに追加する必要があります。

    Elasticsearch ノードはこれより低い値のメモリー設定でも動作しますが、これは実稼働環境には推奨されません。

  • Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

手順

  1. OpenShift Container Platform Web コンソールで、Operators OperatorHub をクリックします。
  2. 利用可能な Operator のリストから OpenShift Elasticsearch OperatorInstall の順にクリックします。
  3. All namespaces on the clusterInstallation mode で選択されていることを確認します。
  4. openshift-operators-redhatInstalled Namespace で選択されていることを確認します。

    openshift-operators-redhat namespace を指定する必要があります。openshift-operators namespace にはコミュニティーの Operator が含まれている場合があります。コミュニティーの Operator は信頼されたものではなく、OpenShift Container Platform のメトリクスと同じ名前のメトリクスを公開する可能性があります。これにより、競合が発生することがあります。

  5. Enable operator recommended cluster monitoring on this namespace を選択します。

    このオプションは、Namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

  6. Update Channel として stable-5.x を選択します。
  7. Update approval strategy を選択します。

    • Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
    • Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
  8. Install をクリックします。

検証

  1. Operators Installed Operators ページに切り替えて、OpenShift Elasticsearch Operator がインストールされていることを確認します。
  2. StatusSucceeded の状態で、OpenShift Elasticsearch Operator がすべてのプロジェクトにリスト表示されていることを確認します。

10.2.3.3. CLI を使用して OpenShift Elasticsearch Operator をインストールする

OpenShift CLI (oc) を使用して、OpenShift Elasticsearch Operator をインストールできます。

前提条件

  • Elasticsearch の必要な永続ストレージがあることを確認します。各 Elasticsearch ノードには独自のストレージボリュームが必要であることに注意してください。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: block で記述される raw ブロックボリュームを使用しないでください。Elasticsearch は raw ブロックボリュームを使用できません。

    Elasticsearch はメモリー集約型アプリケーションです。デフォルトで、OpenShift Container Platform はメモリー要求および 16 GB の制限を持つ 3 つの Elasticsearch ノードをインストールします。OpenShift Container Platform ノードの最初の 3 つのセットには、Elasticsearch をクラスター内で実行するのに十分なメモリーがない可能性があります。Elasticsearch に関連するメモリーの問題が発生した場合は、既存ノードのメモリーを増やすのではなく、Elasticsearch ノードをクラスターにさらに追加します。

  • 管理者権限がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 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 が含まれている場合があります。コミュニティーの Operator は信頼されたものではなく、メトリクスと同じ名前のメトリクスを公開する可能性があります。これにより、競合が発生することがあります。
    2
    String。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このラベルを上記のように指定する必要があります。
  2. 次のコマンドを実行して、Namespace オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  3. OperatorGroup オブジェクトを、YAML ファイルとして作成します。

    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: openshift-operators-redhat
      namespace: openshift-operators-redhat 1
    spec: {}
    1
    openshift-operators-redhat namespace を指定する必要があります。
  4. 以下のコマンドを実行して OperatorGroup オブジェクトを適用します。

    $ oc apply -f <filename>.yaml
  5. OpenShift Elasticsearch Operator に namespace をサブスクライブするための Subscription オブジェクトを作成します。

    Subscription の例

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

    1
    openshift-operators-redhat namespace を指定する必要があります。
    2
    チャネルとして stable または stable-x.y を指定します。以下の注意点を参照してください。
    3
    Automatic により、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。Manual には、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
    4
    redhat-operators を指定します。OpenShift Container Platform クラスターが、非接続クラスターとも呼ばれるネットワークが制限された環境でインストールされている場合、Operator Lifecycle Manager (OLM) の設定時に作成される CatalogSource オブジェクトの名前を指定します。
    注記

    stable を指定すると、最新の安定したリリースの現行バージョンがインストールされます。stableinstallPlanApproval: "Automatic" とともに使用すると、Operator が最新の安定したメジャーリリースとマイナーリリースに自動的にアップグレードされます。

    stable-x.y を指定すると、特定のメジャーリリースの現在のマイナーバージョンがインストールされます。stable-x.yinstallPlanApproval: "Automatic" と併せて使用すると、Operator がメジャーリリース内の最新の stable マイナーリリースに自動的にアップグレードされます。

  6. 次のコマンドを実行して、サブスクリプションを適用します。

    $ oc apply -f <filename>.yaml

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

検証

  1. 以下のコマンドを実行します。

    $ oc get csv -n --all-namespaces
  2. 出力を観察し、OpenShift Elasticsearch Operator の Pod が各 namespace に存在することを確認します。

    出力例

    NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
    default                                            elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-node-lease                                    elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-public                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    kube-system                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    non-destructive-test                               elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver-operator                       elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    openshift-apiserver                                elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
    ...

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

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
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.