3.3. Loki の信頼性とパフォーマンスの強化
実稼働環境で Loki の信頼性と効率性を確保するには、次の設定を使用します。
3.3.1. Loki Pod の配置 リンクのコピーリンクがクリップボードにコピーされました!
Pod の toleration またはノードセレクターを使用して、Loki Pod が実行するノードを制御し、他のワークロードがそれらのノードを使用しないようにできます。
LokiStack カスタムリソース (CR) を使用して toleration をログストア Pod に適用し、ノード仕様を使用して taint をノードに適用できます。ノードのテイントは、テイントを容認しないすべての Pod を拒否するようノードに指示する key:value pair です。他の Pod にはない特定の key:value ペアを使用すると、ログストア Pod のみがそのノードで実行できるようになります。
ノードセレクターを使用する LokiStack の例
ノードセレクターと toleration を使用する LokiStack CR の例
LokiStack (CR) の nodeSelector フィールドと tolerations フィールドを設定するには、oc explain コマンドを使用して、特定のリソースの説明とフィールドを表示します。
oc explain lokistack.spec.template
$ oc explain lokistack.spec.template
出力例
詳細情報用に、特定のフィールドを追加できます。
oc explain lokistack.spec.template.compactor
$ oc explain lokistack.spec.template.compactor
出力例
3.3.2. ノードの障害を許容するための Loki の設定 リンクのコピーリンクがクリップボードにコピーされました!
ロギング 5.8 以降のバージョンでは、Loki Operator は、同じコンポーネントの Pod がクラスター内の異なる使用可能なノードにスケジュールされるように要求する Pod 非アフィニティールールの設定をサポートします。
アフィニティーとは、スケジュールするノードを制御する Pod の特性です。非アフィニティーとは、Pod がスケジュールされることを拒否する Pod の特性です。
OpenShift Container Platform では、Pod のアフィニティー と Pod の非アフィニティー によって、他の Pod のキー/値ラベルに基づいて、Pod のスケジュールに適したノードを制限できます。
Operator は、すべての Loki コンポーネントに対して、デフォルトの優先 podAntiAffinity ルールを設定します。これには、コン パク ター、ディストリビューター、ゲートウェイ、indexGateway、イン ジェスト、クエリーフロッター、queryFrontend、および ruler コンポーネントが含まれます。
requiredDuringSchedulingIgnoredDuringExecution フィールドに必要な設定を指定して、Loki コンポーネントの希望の podAntiAffinity 設定を上書きできます。
インジェスターコンポーネントのユーザー設定の例
3.3.3. Loki でストリームベースの保持の有効化 リンクのコピーリンクがクリップボードにコピーされました!
ログストリームに基づいて保持ポリシーを設定できます。これらのルールは、グローバル、テナントごと、またはその両方で設定できます。両方で設定すると、グローバルルールの前にテナントルールが適用されます。
s3 バケットまたは LokiStack カスタムリソース (CR) に保存期間が定義されていない場合、ログは削除されず、s3 バケットに永久に残り、s3 ストレージがいっぱいになる可能性があります。
スキーマ v13 が推奨されます。
手順
LokiStackCR を作成します。次の例に示すように、ストリームベースの保持をグローバルに有効にします。
AWS のグローバルストリームベースの保持の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- すべてのログストリームの保持ポリシーを設定します。注記: このフィールドは、オブジェクトストレージに保存されたログの保持期間には影響しません。
- 2
- このブロックが CR に追加されると、クラスターで保持が有効になります。
- 3
- ログ stream.spec: 制限を定義するために使用される LogQL クエリー が含まれます。
次の例に示すように、テナントごとにストリームベースの保持を有効にします。
AWS のテナントごとのストリームベースの保持の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- テナントごとの保持ポリシーを設定します。有効なテナントタイプは、
application、audit、およびinfrastructureです。 - 2
- ログストリームの定義に使用される LogQL クエリー が含まれています。
LokiStackCR を適用します。oc apply -f <filename>.yaml
$ oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.4. メンバーリストの作成の失敗を許容する Loki の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターでは、管理者は通常、非プライベート IP ネットワーク範囲を使用します。その結果、LokiStack メンバーリストはデフォルトでプライベート IP ネットワークのみを使用するため、LokiStack メンバーリストの設定は失敗します。
管理者は、メンバーリスト設定の Pod ネットワークを選択できます。LokiStack カスタムリソース (CR) を変更して、hashRing 仕様で podIP アドレスを使用できます。LokiStack CR を設定するには、以下のコマンドを使用します。
oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
$ oc patch LokiStack logging-loki -n openshift-logging --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP"},"type":"memberlist"}}}'
podIP を含める LokiStack の例
3.3.5. クラスターの再起動中の LokiStack 動作 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform クラスターが再起動されると、LokiStack の取り込みとクエリーパスは、ノードで使用可能な CPU およびメモリーリソース内で引き続き動作します。つまり、OpenShift Container Platform クラスターの更新中に LokiStack でダウンタイムは発生しません。この動作は、PodDisruptionBudget リソースを使用して実現されます。Loki Operator は、Loki に PodDisruptionBudget リソースをプロビジョニングします。このリソースは、特定の条件下で通常の操作ができるようにコンポーネントごとに使用可能でなければならない Pod の最小数を決定します。