Kubernetes ログ転送で直面する 4 つの課題

[51CTO.com クイック翻訳] Kubernetes を使用しており、ログ記録を行う必要がある場合、仮想マシンやベアメタル環境とは異なるいくつかの問題や課題に直面する可能性があります。

過去 3 か月間、私は PKS の可観測性機能に取り組んできました。 ***、Kubernetes のロギング システムに焦点を当てました。

ログを収集し、ログ サーバーに送信します。単純で普通の仕事のように思えますね。時々そうなるかも知れません。しかし、VM やベアメタル環境と比較して、コンテナを使用する場合のログ記録に関していくつかの新たな課題があることに気付きました。

以下に要約します。それをチェックしてください！ Kubernetes プロジェクトで同じ問題が発生するかどうかを確認してください。

この記事の目的は、問題点と技術的な困難さを説明することです。それをどう解決するかということではありません。ここに不適切な点があれば、必要に応じて変更します。

一般的に、ログ転送ワークフローはアクティブとパッシブに分けられます。

アクティブ モード:プロセスはログ メッセージをリモート syslog サーバーにアクティブに送信します。通常、データのエンコード形式は rfc5424 です。

パッシブ モード:各プロセスに対して、デフォルトのログ パスまたはファイル パターンを指定します。ログ エージェント システムは定期的にログをスキャンし、キャプチャしたログ メッセージをログ サーバーに送信します。

問題は解決したと思うかもしれません!まだですよ、友人たち。

コンテナ内でサービスを実行することは、仮想マシンまたはベアメタル上でサービスを実行することとは異なります。私たちが直面している新たな傾向は次のとおりです。

1. プロセスが短くなります。
2. プロセスの展開はより分散化されます。

これはコンテナのログ記録にとって何を意味するのでしょうか?

課題I: 重要なログをすべて収集できない

問題が発生した場合、ポッド (コンテナのコレクション) は削除されるか、すぐに再作成される可能性があります。その結果、ポッド/コンテナに関連付けられたログ ファイルはすぐに削除または再作成されます。

ただし、Fluentd や log stash などのログ エージェントは通常、フォルダーまたはログ パターンを定期的にスキャンして新しいログ ファイルを検出します。デフォルトのスキャン間隔は 60 秒です (下の図を参照)。スキャン間隔が長すぎて、短期間のコンテナ ログをキャプチャできない可能性があります。時間間隔を 1 秒など短く設定するとどうなるでしょうか?明らかに、これによりパフォーマンスのオーバーヘッドが高くなります。

これは、仮想マシンの古い世界では問題にならなかったでしょう。何らかの理由でプロセスが再起動されると、ログ ファイルが削除されるのではなくローテーションされる可能性があります。この時点で、ユーザーがログを受信する速度が単純に遅くなる可能性があります。ただし、問題プロセスの重要なログは失われません。

この問題をどうやって解決すればいいでしょうか?現時点ではいわゆるベストプラクティスというものはなく、我々も模索中です。おそらく、ポッド イベントをサブスクライブする Kubernetes コントローラーを起動できるでしょう。ポッド作成イベントがトリガーされるたびに、ログ エージェントにすぐに通知されます。 honeycomb-kubernetes-agent は、このアイデアを実装する興味深い GitHub プロジェクトです。より良い解決策があれば、コメントを残してください。

ただし、すべてのログが stdout/stderr にリダイレクトされるわけではありません。ポッド内のプロセスが stdout/stderr ではなくローカル ファイルにログを書き込む場合、ログ プロキシ システムはこれらのログを取得できません。

なぜ？ログ エージェント システムは、以下に示すように、ポッドに関連するログ ファイルのみを監視します。このログ ファイルは、コンテナーの stdout/stderr のみをキャプチャします。

 # ls -1 /var/lib/docker/containers/*/*-json.log
 ls -1 /var/lib/docker/containers/*/*-json.log
 /var/lib/docker/containers/0470.../0470...-json.log
 /var/lib/docker/containers/0645.../0645...-json.log
 /var/lib/docker/containers/12d2.../12d2...-json.log
 ...
 ...

はい、このログ記録動作は、Kubernetes の世界では確かにアンチパターンです。しかし、クラウドネイティブの動きの発展にはまだ時間がかかり、誰もがそのトレンドに追いつけるわけではありません。これは特にデータベース サービスに当てはまります。

VM の世界と比較すると、ポッドは異なるワーカーノード間で頻繁に移動される可能性があります。 K8s クラスターでポッドが変更されるたびに、ログ エージェントを再読み込みまたは再起動する必要はまったくありません。これは新たな挑戦ですよね？

課題 II: ログ名前空間におけるマルチテナント

Kubernetes ワークロードは通常、共有ワーカー仮想マシンで実行されます。異なるプロジェクトのワークロードは、異なる名前空間に分割されます。

プロジェクトによってログ記録の設定が異なる場合があります。ログの保存場所、ログを管理するツールなどはすべて、追加のセキュリティ リスクなしに簡単な方法で構成する必要があります。

この点では、Kubernetes CRD (CustomResourceDefinition) が非常に優れたツールであることがわかります。

1. 学ぶ必要があるのは、標準の kubectl コマンドだけです。 (kubectl チートシートを参照してください)。
2. ここで RBAC を使用してリソースをカスタマイズできます。安全性も保証できます。

PKS では、この機能をリソース シンクと呼びます。注: このアイデアは Kubernetes コミュニティに提出されました。近いうちに Kubernetes アップストリームに統合されることを期待します。

課題 III: 異なる名前空間に対して異なるログ SLA をサポートする

便宜上、通常はログ エージェントを Kubernetes デーモンセットとしてデプロイするだけです。つまり、Kubernetes ワーカーノードごとにポッドは 1 つだけ存在します。何らかの理由でこのポッドを再ロードまたは再スケジュールする必要がある場合、このワーカーノード内のすべてのポッドに影響します。

K8s v1.12 以降では、ノードごとに 100 個のポッドを実行できます。したがって、ログ エージェントがすべてのポッドからログを収集するのに十分な速度であることを確認する必要があります。

他の共有環境と同様に、騒音を出す隣人の問題に遭遇する可能性があります。 1 つのポッドの誤動作により、同じワーカー ノード内の他のすべてのポッドが危険にさらされる可能性があります。問題のある名前空間のログ記録を無効にしたいですか?ログ記録システム全体は簡単にオフにできますが、必要なログを収集できなくなります。

さらに、ディスク速度が遅いと、ログ転送に大幅な遅延が発生する可能性があります。ログのバックプレッシャーをタイムリーに処理できないと、ログ プロキシの DDoS が発生する可能性があります。

課題4: 異なるレイヤーからのログ処理

下の図に示すように、ポッド ログ、K8s ログ、プラットフォーム ログがあります。 「ポッド ログ」の場合でも、標準ワークロードまたは K8s アドオンからのログがあります。

ご想像のとおり、ログの種類によって特性や優先順位が異なります。レイヤー間だけでなく、同じレイヤー内でも異なる SLA が存在する場合があります。

K8s ソリューションを提供するために、この問題をどのように解決すればよいでしょうか?セキュリティ リスクを最小限に抑えながら、プロジェクト マネージャーと開発者が問題の根本原因を迅速に見つけられるように支援する必要があります。

PKSとは何ですか? PKS は、VMware と Pivotal が提供するエンタープライズ グレードの Kubernetes ソリューションです。

元のアドレス: Kubernetes ログ転送における 4 つの課題、著者: Denny Zhang

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。