11.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 を参照してください。
11.2.1. Loki ログストアのデプロイ
Loki Operator を使用して、OpenShift Container Platform クラスターに内部 Loki ログストアをデプロイできます。Loki Operator をインストールした後、シークレットを作成することで Loki オブジェクトストレージを設定し、LokiStack
カスタムリソース (CR) を作成する必要があります。
11.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 |
11.2.1.2. Web コンソールを使用してロギングと Loki Operator をインストールする
OpenShift Container Platform クラスターにログをインストールして設定するには、まずログストレージ用の Loki Operator などの Operator をインストールする必要があります。これは、Web コンソールの Operator Hub から実行できます。
前提条件
- サポートされているオブジェクトストア (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 に設定されている場合は、保留中のアップグレードを手動で承認する必要があります。
Red Hat OpenShift Logging Operator をインストールします。
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub をクリックします。 - 利用可能な Operator のリストから Red Hat OpenShift Logging を選択し、Install をクリックします。
- A specific namespace on the cluster が Installation Mode で選択されていることを確認します。
- Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。
Enable Operator recommended cluster monitoring on this namespace を選択します。
このオプションは、namespace オブジェクトに
openshift.io/cluster-monitoring: "true"
ラベルを設定します。クラスターモニタリングがopenshift-logging
namespace を収集できるように、このオプションを選択する必要があります。- Update Channel として stable-5.y を選択します。
Approval Strategy を選択します。
- Automatic ストラテジーにより、Operator Lifecycle Manager (OLM) は新規バージョンが利用可能になると Operator を自動的に更新できます。
- Manual ストラテジーには、Operator の更新を承認するための適切な認証情報を持つユーザーが必要です。
- Install をクリックします。
-
OpenShift Container Platform Web コンソールで、Operators
-
Operators
Installed Operators ページに移動します。All instances タブをクリックします。 - Create new ドロップダウンリストから、LokiStack を選択します。
YAML view を選択し、次のテンプレートを使用して
LokiStack
CR を作成します。LokiStack
CR の例apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki 1 namespace: openshift-logging 2 spec: size: 1x.small 3 storage: schemas: - version: v12 effectiveDate: "2022-06-01" secret: name: logging-loki-s3 4 type: s3 5 credentialMode: 6 storageClassName: <storage_class_name> 7 tenants: mode: openshift-logging 8
- 1
logging-loki
という名前を使用します。- 2
openshift-logging
namespace を指定する必要があります。- 3
- デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは
1x.extra-small
、1x.small
、または1x.medium
です。 - 4
- ログストアシークレットの名前を指定します。
- 5
- 対応するストレージタイプを指定します。
- 6
- 任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。static は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token は、認証情報ソースから取得された有効期間の短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。token-cco は、Loki がマネージド STS モードで実行し、STS/WIF クラスターで CCO を使用している場合のデフォルト値です。
- 7
- 一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。 - 8
- LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
重要デプロイメントサイズの
1x
の数は変更できません。- Create をクリックします。
OpenShift Logging インスタンスを作成します。
-
Administration
Custom Resource Definitions ページに切り替えます。 - Custom Resource Definitions ページで、ClusterLogging をクリックします。
- Custom Resource Definition details ページで、Actions メニューから View Instances を選択します。
ClusterLoggings ページで、Create ClusterLogging をクリックします。
データを読み込むためにページの更新が必要になる場合があります。
YAML フィールドで、コードを以下に置き換えます。
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance 1 namespace: openshift-logging 2 spec: collection: type: vector logStore: lokistack: name: logging-loki retentionPolicy: application: maxAge: 7d audit: maxAge: 7d infra: maxAge: 7d type: lokistack visualization: type: ocp-console ocpConsole: logsLimit: 15 managementState: Managed
-
Administration
検証
-
Operators
Installed Operators に移動します。 - openshift-logging プロジェクトが選択されていることを確認します。
- Status 列に、緑色のチェックマークおよび InstallSucceeded と、Up to date というテキストが表示されていることを確認します。
インストールが完了する前に、Operator に Failed
ステータスが表示される場合があります。InstallSucceeded
メッセージが表示されて Operator のインストールが完了した場合は、ページを更新します。
11.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
関連情報
11.2.2. 短期認証情報を使用するクラスターに Loki ログストアのデプロイ
一部のストレージプロバイダーでは、インストール時に CCO ユーティリティー (ccoctl
) を使用して、短期認証情報を実装できます。これらの認証情報は、OpenShift Container Platform クラスターの外部で作成および管理されます。コンポーネントの短期認証情報を使用した手動モード
この認証情報ストラテジーを使用するクラスターでは、Loki Operator の新規インストール中に短期認証情報の認証を設定する必要があります。この機能を使用するために、既存のクラスターが別のクレデンシャルストラテジーを使用するように設定することはできません。
11.2.2.1. ワークロードアイデンティティーフェデレーション
ワークロードアイデンティティーフェデレーションを使用すると、有効期間の短いトークンを使用してクラウドベースのログストアに対して認証できます。
前提条件
- OpenShift Container Platform 4.14 以降
- Logging 5.9 以降
手順
-
OpenShift Container Platform Web コンソールを使用して Loki Operator をインストールすると、有効期間が短いトークンを使用するクラスターが自動的に検出されます。プロンプトが表示され、ロールを作成するように求められます。また、Loki Operator が
CredentialsRequest
オブジェクトを作成するのに必要なデータを提供するように求められます。このオブジェクトにより、シークレットが設定されます。 -
OpenShift CLI (
oc
) を使用して Loki Operator をインストールする場合は、次の例に示すように、ストレージプロバイダーに適したテンプレートを使用してサブスクリプションオブジェクトを手動で作成する必要があります。この認証ストラテジーは、指定のストレージプロバイダーでのみサポートされます。
Azure のサンプルサブスクリプション
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: loki-operator namespace: openshift-operators-redhat spec: channel: "stable-5.9" installPlanApproval: Manual name: loki-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: CLIENTID value: <your_client_id> - name: TENANTID value: <your_tenant_id> - name: SUBSCRIPTIONID value: <your_subscription_id> - name: REGION value: <your_region>
AWS のサンプルサブスクリプション
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: loki-operator namespace: openshift-operators-redhat spec: channel: "stable-5.9" installPlanApproval: Manual name: loki-operator source: redhat-operators sourceNamespace: openshift-marketplace config: env: - name: ROLEARN value: <role_ARN>
11.2.2.2. 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: - effectiveDate: '2023-10-15' version: v13 secret: name: logging-loki-s3 3 type: s3 4 credentialMode: 5 storageClassName: <storage_class_name> 6 tenants: mode: openshift-logging
- 1
logging-loki
という名前を使用します。- 2
- デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは
1x.extra-small
、1x.small
、または1x.medium
です。 - 3
- ログストレージに使用するシークレットを指定します。
- 4
- 対応するストレージタイプを指定します。
- 5
- 任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。
static
は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token
は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco
がデフォルト値です。 - 6
- 一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。
11.2.2.3. CLI を使用してロギングと Loki Operator をインストールする
OpenShift Container Platform クラスターにログをインストールして設定するには、まずログストレージ用の Loki Operator などの Operator をインストールする必要があります。これは、OpenShift Container Platform CLI から実行できます。
前提条件
- 管理者権限がある。
-
OpenShift CLI (
oc
) がインストールされている。 - サポートされているオブジェクトストアにアクセスできる。例: AWS S3、Google Cloud Storage、Azure、Swift、Minio、OpenShift Data Foundation。
stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-x.y に変更する必要があります。x.y
は、インストールしたログのメジャーバージョンとマイナーバージョンを表します。たとえば、stable-5.7 です。
Loki Operator の
Namespace
オブジェクトを作成します。Namespace
オブジェクトの例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 をスクレイピングできるようにするために、示されているラベルを指定する文字列値。
次のコマンドを実行して、
Namespace
オブジェクトを適用します。$ oc apply -f <filename>.yaml
Loki Operator の
Subscription
オブジェクトを作成します。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
Red Hat OpenShift Logging Operator の
namespace
オブジェクトを作成します。namespace
オブジェクトの例apiVersion: v1 kind: Namespace metadata: name: openshift-logging 1 annotations: openshift.io/node-selector: "" labels: openshift.io/cluster-logging: "true" openshift.io/cluster-monitoring: "true" 2
次のコマンドを実行して、
namespace
オブジェクトを適用します。$ oc apply -f <filename>.yaml
OperatorGroup
オブジェクトを作成します。OperatorGroup
オブジェクトのサンプルapiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: cluster-logging namespace: openshift-logging 1 spec: targetNamespaces: - openshift-logging
- 1
openshift-logging
namespace を指定する必要があります。
以下のコマンドを実行して
OperatorGroup
オブジェクトを適用します。$ oc apply -f <filename>.yaml
Subscription
オブジェクトを作成します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cluster-logging namespace: openshift-logging 1 spec: channel: stable 2 name: cluster-logging source: redhat-operators 3 sourceNamespace: openshift-marketplace
以下のコマンドを実行して
Subscription
オブジェクトを適用します。$ oc apply -f <filename>.yaml
LokiStack
CR を作成します。LokiStack
CR の例apiVersion: loki.grafana.com/v1 kind: LokiStack metadata: name: logging-loki 1 namespace: openshift-logging 2 spec: size: 1x.small 3 storage: schemas: - version: v12 effectiveDate: "2022-06-01" secret: name: logging-loki-s3 4 type: s3 5 credentialMode: 6 storageClassName: <storage_class_name> 7 tenants: mode: openshift-logging 8
- 1
logging-loki
という名前を使用します。- 2
openshift-logging
namespace を指定する必要があります。- 3
- デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは
1x.extra-small
、1x.small
、または1x.medium
です。 - 4
- ログストアシークレットの名前を指定します。
- 5
- 対応するストレージタイプを指定します。
- 6
- 任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。
static
は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token
は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco
がデフォルト値です。 - 7
- 一時ストレージのストレージクラスの名前を指定します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。 - 8
- LokiStack はデフォルトでマルチテナントモードで実行されます。このデフォルト設定は変更できません。ログの種類 (監査ログ、インフラストラクチャーログ、アプリケーションログ) ごとに 1 つのテナントが提供されます。これにより、個々のユーザーおよびユーザーグループのさまざまなログストリームのアクセス制御が可能になります。
次のコマンドを実行して、
LokiStack CR
オブジェクトを適用します。$ oc apply -f <filename>.yaml
ClusterLogging
CR オブジェクトを作成します。ClusterLogging CR オブジェクトの例
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: name: instance 1 namespace: openshift-logging 2 spec: collection: type: vector logStore: lokistack: name: logging-loki retentionPolicy: application: maxAge: 7d audit: maxAge: 7d infra: maxAge: 7d type: lokistack visualization: type: ocp-console ocpConsole: logsLimit: 15 managementState: Managed
次のコマンドを実行して
ClusterLogging CR
オブジェクトを適用します。$ oc apply -f <filename>.yaml
次のコマンドを実行して、インストールを確認します。
$ oc get pods -n openshift-logging
出力例
$ oc get pods -n openshift-logging NAME READY STATUS RESTARTS AGE cluster-logging-operator-fb7f7cf69-8jsbq 1/1 Running 0 98m collector-222js 2/2 Running 0 18m collector-g9ddv 2/2 Running 0 18m collector-hfqq8 2/2 Running 0 18m collector-sphwg 2/2 Running 0 18m collector-vv7zn 2/2 Running 0 18m collector-wk5zz 2/2 Running 0 18m logging-view-plugin-6f76fbb78f-n2n4n 1/1 Running 0 18m lokistack-sample-compactor-0 1/1 Running 0 42m lokistack-sample-distributor-7d7688bcb9-dvcj8 1/1 Running 0 42m lokistack-sample-gateway-5f6c75f879-bl7k9 2/2 Running 0 42m lokistack-sample-gateway-5f6c75f879-xhq98 2/2 Running 0 42m lokistack-sample-index-gateway-0 1/1 Running 0 42m lokistack-sample-ingester-0 1/1 Running 0 42m lokistack-sample-querier-6b7b56bccc-2v9q4 1/1 Running 0 42m lokistack-sample-query-frontend-84fb57c578-gq2f7 1/1 Running 0 42m
11.2.2.4. 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
関連情報
11.2.2.5. 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 1 namespace: openshift-logging spec: size: 1x.small 2 storage: schemas: - effectiveDate: '2023-10-15' version: v13 secret: name: logging-loki-s3 3 type: s3 4 credentialMode: 5 storageClassName: <storage_class_name> 6 tenants: mode: openshift-logging
- 1
logging-loki
という名前を使用します。- 2
- デプロイメントサイズを指定します。ロギング 5.8 以降のバージョンでは、Loki の実稼働インスタンスでサポートされているサイズオプションは
1x.extra-small
、1x.small
、または1x.medium
です。 - 3
- ログストレージに使用するシークレットを指定します。
- 4
- 対応するストレージタイプを指定します。
- 5
- 任意のフィールド、Logging 5.9 以降。サポートされているユーザー設定値は、次のとおりです。
static
は、シークレットに保存された認証情報を使用する、サポートされているすべてのオブジェクトストレージタイプで使用できるデフォルトの認証モードです。token
は、認証情報ソースから取得される有効期間が短いトークンです。このモードでは、オブジェクトストレージに必要な認証情報が静的設定に格納されません。代わりに、実行時にサービスを使用して認証情報が生成されるため、有効期間が短い認証情報の使用と、よりきめ細かい制御が可能になります。この認証モードは、すべてのオブジェクトストレージタイプでサポートされているわけではありません。Loki がマネージド STS モードで実行されていて、STS/WIF クラスターで CCO を使用している場合、token-cco
がデフォルト値です。 - 6
- 一時ストレージのストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、
oc get storageclasses
コマンドを使用してリスト表示できます。
-
次のコマンドを実行して、
LokiStack
CR を適用します。
検証
次のコマンドを実行して出力を観察し、
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
11.2.3. 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 |
11.2.3.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>"
11.2.3.1.1. STS 対応クラスターの AWS ストレージ
クラスターで STS が有効になっている場合、Cloud Credential Operator (CCO) によって AWS トークンを使用した短期認証がサポートされます。
次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。
$ oc -n openshift-logging create secret generic "logging-loki-aws" \
--from-literal=bucketnames="<s3_bucket_name>" \
--from-literal=region="<bucket_region>" \
--from-literal=audience="<oidc_audience>" 1
- 1
- 任意のアノテーション。デフォルト値は
openshift
です。
11.2.3.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
です。
11.2.3.2.1. Microsoft Entra Workload ID 対応クラスター用の Azure ストレージ
クラスターで Microsoft Entra Workload ID が有効になっている場合、Cloud Credential Operator (CCO) は Workload ID を使用した短期認証をサポートします。
次のコマンドを実行すると、Loki オブジェクトストレージシークレットを手動で作成できます。
$ oc -n openshift-logging create secret generic logging-loki-azure \ --from-literal=environment="<azure_environment>" \ --from-literal=account_name="<storage_account_name>" \ --from-literal=container="<container_name>"
11.2.3.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>"
11.2.3.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>"
11.2.3.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>"
11.2.3.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>"
11.2.4. 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 を参照してください。
11.2.4.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 のデフォルト値です。これらのデフォルト値は変更できます。アラートは同じデフォルト値を使用しますが、これらの値をアラートで変更することはできません。
11.2.4.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 がすべてのプロジェクトにリスト表示されていることを確認します。
11.2.4.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 ...
11.2.5. ログストレージの設定
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