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
の数は変更できません。
1x.demo | 1x.extra-small | 1x.small | 1x.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 コンソールにアクセスできる。
手順
-
OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Operators
OperatorHub に移動します。 Filter by keyword フィールドに Loki Operator と入力します。使用可能な Operator のリストで Loki Operator をクリックし、Install をクリックします。
重要Community Loki Operator は Red Hat ではサポートされていません。
Update channel として stable または stable-x.y を選択します。
注記stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-x.y に変更する必要があります。
x.y
は、インストールしたログのメジャーバージョンとマイナーバージョンを表します。たとえば、stable-5.7 です。Loki Operator はグローバルオペレーターグループ namespace である
openshift-operators-redhat
にデプロイする必要があるため、Installation mode と Installed Namespace がすでに選択されています。この namespace がない場合は、自動的に作成されます。Enable operator-recommended cluster monitoring on this namespace. を選択します。
このオプションは、
Namespace
オブジェクトにopenshift.io/cluster-monitoring: "true"
ラベルを設定します。クラスターモニタリングがopenshift-operators-redhat
namespace を収集できるように、このオプションを選択する必要があります。Update approva で Automatic を選択し、Install をクリックします。
サブスクリプションの承認ストラテジーが Automatic に設定されている場合、アップグレードプロセスは、選択したチャネルで新規 Operator バージョンが利用可能になるとすぐに開始します。承認ストラテジーが Manual に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。
検証
-
Operators
Installed Operators に移動します。 - openshift-logging プロジェクトが選択されていることを確認します。
- 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 がインストールされている。
手順
-
OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Workloads
Secrets に移動します。 - Create ドロップダウンリストから、From YAML を選択します。
access_key_id
フィールドとaccess_key_secret
フィールドを使用して認証情報を指定し、bucketnames
、endpoint
、および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 がインストールされている。
手順
-
Operators
Installed Operators ページに移動します。All instances タブをクリックします。 - Create new ドロップダウンリストから、LokiStack を選択します。
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-small
、1x.small
、または1x.medium
です。重要デプロイメントサイズの
1x
の数は変更できません。 - 3
- ログストレージに使用するシークレットを指定します。
- 4
- 対応するストレージタイプを指定します。
- 5
- 一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。 - 6
- LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
- 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。
手順
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
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
) がインストールされている。
手順
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-small
、1x.small
、または1x.medium
です。重要デプロイメントサイズの
1x
の数は変更できません。 - 2
- ログストアシークレットの名前を指定します。
- 3
- ログストアシークレットのタイプを指定します。
- 4
- 一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。 - 5
- LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
次のコマンドを実行して、
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 だけでなく、Minio や OpenShift Data Foundation などの他の S3 互換オブジェクトストアもサポートしています。Azure、GCS、および Swift もサポートされています。
Loki ストレージの推奨命名法は、logging-loki-<your_storage_provider>
です。
次の表は、各ストレージプロバイダーの LokiStack
カスタムリソース (CR) 内の type
値を示しています。詳細は、ストレージプロバイダーに関するセクションを参照してください。
ストレージプロバイダー | シークレットの type 値 |
---|---|
AWS | s3 |
Azure | azure |
Google Cloud | gcs |
Minio | s3 |
OpenShift Data Foundation | s3 |
Swift | swift |
10.2.2.1. AWS ストレージ
前提条件
- Loki Operator がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 - AWS 上に バケット を作成している。
- AWS IAM ポリシーと IAM ユーザー を作成している。
手順
次のコマンドを実行して、
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
- サポートされている環境値は、
AzureGlobal
、AzureChinaCloud
、AzureGermanCloud
、AzureUSGovernment
です。
10.2.2.3. Google Cloud Platform ストレージ
前提条件
手順
-
GCP から受け取ったサービスアカウントの認証情報を
key.json
という名前のファイルにコピーします。 次のコマンドを実行して、
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 ストレージ
前提条件
手順
次のコマンドを実行して、
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 ストレージ
前提条件
- Loki Operator がインストールされている。
-
OpenShift CLI (
oc
) がインストールされている。 - OpenShift Data Foundation がデプロイされている。
- OpenShift Data Foundation クラスターを オブジェクトストレージ用 に設定している。
手順
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
次のコマンドを実行して、関連付けられた
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}')
次のコマンドを実行して、関連付けられたシークレットからバケットアクセスキーを取得します。
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)
次のコマンドを実行して、
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 ブロックボリュームを使用できません。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub をクリックします。 - 利用可能な Operator のリストから OpenShift Elasticsearch Operator、Install の順にクリックします。
- All namespaces on the cluster が Installation mode で選択されていることを確認します。
openshift-operators-redhat が Installed Namespace で選択されていることを確認します。
openshift-operators-redhat
namespace を指定する必要があります。openshift-operators
namespace にはコミュニティーの Operator が含まれている場合があります。コミュニティーの Operator は信頼されたものではなく、OpenShift Container Platform のメトリクスと同じ名前のメトリクスを公開する可能性があります。これにより、競合が発生することがあります。Enable operator recommended cluster monitoring on this namespace を選択します。
このオプションは、
Namespace
オブジェクトにopenshift.io/cluster-monitoring: "true"
ラベルを設定します。クラスターモニタリングがopenshift-operators-redhat
namespace を収集できるように、このオプションを選択する必要があります。- Update Channel として stable-5.x を選択します。
Update approval strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
検証
-
Operators
Installed Operators ページに切り替えて、OpenShift Elasticsearch Operator がインストールされていることを確認します。 - Status が Succeeded の状態で、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
) がインストールされている。
手順
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 を収集できるように、このラベルを上記のように指定する必要があります。
次のコマンドを実行して、
Namespace
オブジェクトを適用します。$ oc apply -f <filename>.yaml
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 を指定する必要があります。
以下のコマンドを実行して
OperatorGroup
オブジェクトを適用します。$ oc apply -f <filename>.yaml
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
を指定すると、最新の安定したリリースの現行バージョンがインストールされます。stable
をinstallPlanApproval: "Automatic"
とともに使用すると、Operator が最新の安定したメジャーリリースとマイナーリリースに自動的にアップグレードされます。stable-x.y
を指定すると、特定のメジャーリリースの現在のマイナーバージョンがインストールされます。stable-x.y
をinstallPlanApproval: "Automatic"
と併せて使用すると、Operator がメジャーリリース内の最新の stable マイナーリリースに自動的にアップグレードされます。次のコマンドを実行して、サブスクリプションを適用します。
$ oc apply -f <filename>.yaml
OpenShift Elasticsearch Operator は
openshift-operators-redhat
namespace にインストールされ、クラスター内の各プロジェクトにコピーされます。
検証
以下のコマンドを実行します。
$ oc get csv -n --all-namespaces
出力を観察し、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 を参照してください。
手順
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: {} # ...
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 # ...
次のコマンドを実行して、
ClusterLogging
CR を適用します。$ oc apply -f <filename>.yaml