Kubernetes ロギングの 6 つのベスト プラクティス

Kubernetes は、Pod にデプロイされた数百のコンテナのライフサイクルの管理に役立ちます。高度に分散されており、その部分は動的です。実装された Kubernetes 環境には通常、ワークロードに基づいて継続的に起動および破棄される数百のコンテナをホストするクラスターとノードを含む複数のシステムが含まれます。

Kubernetes で多数のコンテナ化されたアプリケーションやワークロードを処理する場合、エラーを積極的に監視してデバッグすることが重要です。これらのエラーは、コンテナ内、コンテナ、ノード、またはクラスタ レベルで確認できます。 Kubernetes のロギング メカニズムは、サービスとインフラストラクチャの管理と監視に使用できる非常に重要なコンポーネントです。 Kubernetes では、ログを使用してエラーを追跡したり、アプリケーションをホストしているコンテナのパフォーマンスを調整したりすることもできます。

[[329567]]

stdout (標準出力) と stderr (標準エラー) データ ストリームを構成する

最初のステップは、ログがどのように生成されるかを理解することです。 Kubernetes では、ログは stdout と stderr の 2 つのストリームに送信されます。これらのデータ ストリームは JSON ファイルに書き込まれ、このプロセスは Kubernetes によって内部的に処理されます。どのログをどのデータ ストリームに送信するかを設定できます。ベスト プラクティスとして、すべてのアプリケーション ログを stdout に送信し、すべてのエラー ログを stderr に送信することが推奨されます。

サイドカーモデルを使用するかどうかの決定

Kubernetes では、ログを収集するためにサイドカー コンテナを使用することを推奨しています。このアプローチでは、各アプリケーション コンテナーに隣接する「ストリーミング コンテナー」があり、すべてのログを stdout と stderr にストリーミングします。サイドカー モデルを使用すると、ノード レベルでログが公開されるのを回避でき、コンテナー レベルでログを制御できるようになります。

しかし、このモデルの問題は、少量のログ記録にしか適しておらず、大規模なログ記録に直面した場合、多くのリソースが占有される可能性があることです。したがって、実行中のアプリケーション コンテナーごとに個別のログ コンテナーを実行する必要があります。 Kubernetes のドキュメントでは、サイドカー モデルには「大きなオーバーヘッドはほとんどない」と説明されています。このモデルを試してみて、選択する前に消費されるリソースの種類を確認するのはあなた次第です。

別の方法としては、ノード レベルでログを収集するログ エージェントを使用する方法があります。これによりオーバーヘッドが削減され、ログが安全に処理されるようになります。 Fluentd は、Kubernetes ログを大規模に集約するための最良の選択肢として浮上しました。これは、Kubernetes と、Kubernetes ログを使用する任意の数のエンドポイントとの間のブリッジとして機能します。また、アプリ ストアに Fluentd が統合されている Rancher などの Kubernetes 管理プラットフォームを選択することもできます。これにより、最初からインストールして構成する必要がなくなります。

Fluentd がログ データをより適切に集約およびルーティングできることを確認したら、次のステップはログ データをどのように保存および分析するかを決定することです。

ログ分析ツールの選択: EFK または専用ログ

従来、ローカル サーバー中心のシステムでは、アプリケーション ログはシステム上のログ ファイルに保存されます。これらのファイルは、定義された場所で確認することも、中央サーバーに移動することもできます。しかし、Kubernetes では、すべてのログはディスク上の /var/log 内の JSON ファイルに送信されます。ノード内のポッドは一時的かつ短命である可能性があるため、このタイプのログ集約は安全ではありません。 Pod を削除すると、ログ ファイルは失われます。部分的なログ データ損失のトラブルシューティングを行う必要がある場合、これは困難になる可能性があります。

Kubernetes では、すべてのログを Elasticsearch に送信するか、任意のサードパーティのログ ツールを使用するかという 2 つのオプションが公式に推奨されています。ここでも、潜在的な選択肢があります。 Elasticsearch ルートを選択するには、Elasticsearch、Fluentd、Kibana を含むフルスタックの EFK スタックを購入する必要があります。各ツールには独自の役割があります。前述のように、Fluentd はログを集約してルーティングできます。 Elasticsearch は、生のログ データを分析し、読み取り可能な出力を提供する強力なプラットフォームです。 Kibana は、ログ データから美しいカスタム ダッシュボードを作成できるオープン ソースのデータ視覚化ツールです。これは完全にオープンソースのスタックであり、Kubernetes を使用したログ記録のための強力なソリューションです。

それでも、心に留めておくべきことがいくつかあります。 Elasticsearch は Elastic と呼ばれる組織によって構築および保守されているだけでなく、大規模なオープンソース開発者コミュニティによっても貢献されています。大規模なデータクエリの処理において高速かつ強力であることが証明されていますが、大規模に操作する際にはいくつかの問題が発生する可能性があります。自己管理型の Elasticsearch を使用している場合は、大規模なプラットフォームを構築する方法を理解する必要があります。

別の方法としては、クラウドベースのログ分析ツールを使用して Kubernetes ログを保存および分析する方法があります。 Sumo Logic や Splunk などのツールが良い例です。これらのツールの中には、Fluentd を利用してログをプラットフォームにルーティングするものもあれば、Kubernetes のノード レベルに独自のカスタム ログ エージェントを配置するものもあります。これらのツールはセットアップが非常に簡単で、これを使用してダッシュボードをゼロから構築し、最短時間でログを表示できます。

RBACを使用してログへのアクセスを制御する

Kubernetes の認証メカニズムでは、ロールベースのアクセス制御 (RBAC) を使用して、ユーザーのアクセスとシステム権限を検証します。操作中に生成された監査ログには、ユーザーが権限を持っているかどうか (authorization.k8s.io/decision) と、ユーザーに権限が付与された理由 (authorization.k8s.io/reason) に基づいて注釈が付けられます。デフォルトでは、監査ログは有効になっていません。認証の問題を追跡するにはこれを有効にすることをお勧めします。これは kubectl を使用して設定できます。

ログの形式を一定に保つ

Kubernetes ログは、Kubernetes アーキテクチャのさまざまな部分によって生成されます。これらの集約されたログは、Fluentd や FluentBit などのログ集約ツールが簡単に処理できるように、一貫した形式にする必要があります。これは、stdout と stderr を構成するときや、Fluentd を使用してラベルとメタデータを割り当てるときなどに留意する必要があります。この構造化されたログは Elasticsearch に送られ、ログ分析中の遅延が短縮されます。

ログ収集デーモンのリソース制限の設定

大量のログが生成されるため、クラスターレベルでのログの管理が困難になります。 DaemonSet は Linux と同様に Kubernetes でも​​使用されます。特定のタスクを実行するためにバックグラウンドで実行されます。 Fluentd と filebeat は、ログ収集用に Kubernetes によってサポートされている 2 つのデーモンです。利用可能なシステム リソースに基づいてログ ファイルの収集を最適化するには、各デーモンにリソース制限を設定する必要があります。

結論は

Kubernetes は複数のレイヤーとコンポーネントで構成されているため、それらを適切に監視および追跡することで、障害が発生しても冷静さを保つことができます。 Kubernetes では、シームレスな統合によるログ記録に外部の「Kubernetes ネイティブ」ツールの使用を推奨しており、管理者がログを取得しやすくなります。この記事で説明されているプラ​​クティスは、どのような状況でも適切に機能する堅牢なログ記録アーキテクチャを実現するために重要です。コンピューティング リソースを最適化された方法で消費し、Kubernetes 環境を安全かつパフォーマンスの高い状態に保ちます。