Comprehensive Analysis of Kubernetes Log Collection Principle

概要

コンテナオーケストレーション分野の実装標準として、Kubernetes (K8s) はますます多くのシナリオで利用されています。可観測性構築の重要な構成要素として、ログは詳細なアクセスリクエストやエラー情報を記録でき、問題特定に非常に役立ちます。Kubernetes 上のアプリケーション、Kubernetes コンポーネント自体、ホストなど、さまざまな種類のログデータが生成されます。SLS はこれらのデータの収集と分析を完全にサポートしています。本記事では、SLS による Kubernetes ログ収集の基本原則を主に紹介します。これにより、実際の使用をより適切に計画できます。

Kubernetes ログ収集方式

K8s では、ログ収集は一般的に Sidecar と DaemonSet に分かれます。中小規模のクラスターでは DaemonSet の使用が推奨されています。Sidecar は超大規模クラスター（複数ビジネスパーティ向けサービス提供、各パーティに特定のログ収集要件があり、収集設定数が 500 を超える場合）での使用が推奨されています。

• DaemonSet モードでは、各ノードで 1 つのログエージェントのみが実行され、このノード上のすべてのログを収集します。DaemonSet のリソース消費ははるかに少ないですが、スケーラビリティとテナント分離は限られています。単一機能またはビジネスが多くないクラスターに適しています。

• Sidecar 方式では、各 Pod ごとにログエージェントを個別にデプロイし、1 つのビジネスアプリケーションのログ収集のみを担当します。Sidecar は比較的リソースを消費しますが、柔軟でマルチテナント分離が可能です。大規模な K8s クラスターまたは複数のビジネスパーティにサービスを提供する PaaS プラットフォームとしてのクラスターでは、この方式の使用が推奨されています。

SLS ログ収集原則

ログ収集プロセスは通常、エージェントのデプロイ、エージェントの設定、設定に基づくエージェントの動作の 3 部分で構成されます。SLS のログ収集プロセスも基本的に同様で、オープンソース収集ソフトウェアよりも多くのデプロイ、設定、収集方法を提供しています。K8s では、デプロイ方法は主に DaemonSet と Sidecar に分かれます。設定方法には、CRD 設定、環境変数設定、コンソール設定、API 設定などがあります。収集方法では、コンテナファイル収集、コンテナ標準出力収集、標準ファイル収集をサポートしています。全体のプロセスは次のとおりです。

1. Logtail のデプロイ：DaemonSet と Sidecar のデプロイ方法をサポートしています（第 1 部分では、これら 2 つの方式の収集原則を紹介します）。

2. 収集設定の作成：CRD 設定、環境変数設定、コンソール設定、API 設定などの方法をサポートしています（第 2 部分では、これらの設定の長所と短所、および適用シナリオを紹介します）。

3. Logtail が設定に基づいてデータを収集：Logtail はステップ 2 で作成された収集設定を取得し、設定内容に従って動作します。

• 注：デフォルトの DaemonSet および Sidecar モードはすべてカスタムマシングループを使用し、ノード/コンテナの自動拡張シナリオに適用されます。すべての収集設定はマシングループに添付されてから有効になります。

• 注：Logtail の収集設定はサーバーから取得されます。Logtail がサーバーに接続されると、マシングループに関連付けられた収集設定が自動的にローカルに同期され、動作を開始します。

DaemonSet ログ収集原則

DaemonSet（関連ドキュメントは DaemonSet を参照）、Deployment、StatefulSet は、Kubernetes の Pod に対する高度なオーケストレーション方式（コントローラー）です。Deployment と StatefulSet は多数のレプリカを定義し、K8s はレプリカ数に従ってスケジュールします。ただし、DaemonSet はコピー数を指定する必要がありません。デフォルトでは、各ノードで 1 つずつ起動し、通常はログ収集、モニタリング、ディスククリーンアップなどの運用保守関連作業に使用されます。したがって、Logtail のデフォルト推奨ログ収集方式は DaemonSet です。

DaemonSet モードでは、デフォルトでインストールされる Logtail は kube-system 名前空間に配置されます。DaemonSet 名は logtail-ds です。各ノードの Logtail の Pod は、このノード上のすべての実行中の Pod（標準出力とファイルを含む）のデータを収集する責任があります。

• 次のコマンドで logtail-ds が実行されている Pod の状態を確認できます：kubectl get pod -n kube-system | grep logtail-ds

前提条件

Logtail が他の Pod/コンテナを収集するための前提条件は、ホスト上のコンテナランタイムと他のコンテナのデータにアクセスできることです。

• コンテナランタイムへのアクセス：Logtail コンテナは、ホスト上のコンテナランタイム（Docker Engine/ContainerD）のソケットをコンテナディレクトリにマウントするため、Logtail コンテナはこのノードの Docker Engine/ContainerD にアクセスできます。

• 他のコンテナのデータへのアクセス：Logtail コンテナはホストのルートディレクトリ（'/' ディレクトリ）をコンテナの /logtail_host マウントポイントにマウントするため、/logtail_host ディレクトリを使用して他のコンテナのデータにアクセスできます（ただし、コンテナランタイムのファイルシステムが通常のファイルシステム形式でホストに保存されている場合に限ります。一般的には overlayfs、またはコンテナのログディレクトリが hostPath や emptyDir などでホストにマウントされている場合です）。

ワークフロー

これら 2 つの前提条件が満たされると、Logtail は SLS サーバーから収集設定をロードし、動作を開始します。コンテナログ収集の場合、Logtail 起動後のワークフローは主に 2 部分に分かれます。

1. プロセスは主に次のとおりです。

A. コンテナランタイム（Docker Engine/ContainerD）からすべてのコンテナとその設定情報を取得します。コンテナ名、ID、マウントポイント、環境変数、ラベルなどです。

B. 収集設定の IncludeEnv、ExcludeEnv、IncludeLabel、ExcludeLabel に従って収集対象のコンテナを特定します。収集設定のマッピング関係により、収集対象を正確に特定できます。すべてのコンテナを収集すると、リソースの浪費やデータの分散などの問題が発生します。次の図に示すように、Env が Pre のコンテナを収集する設定 1、APP が APP1 のコンテナを収集する設定 2、ENV が Pre 以外のコンテナを収集する設定 3 です。これら 3 つの設定は、異なるデータを異なる Logstore に収集します。

2. コンテナデータの収集は主に次のとおりです。

A. 収集対象コンテナのデータアドレスを特定します。標準出力とファイル収集アドレスが含まれます。この情報は主にコンテナの設定にあります。たとえば、標準出力の LogPath とコンテナファイルの保存パスは次の図に示されています。注：

ⅰ. 標準出力：コンテナの標準出力は収集前にファイルに保存する必要があります。DockerEngine と ContainerD の場合、LogDriver を設定する必要があり、json-file または local に設定できます（一般的にはデフォルト設定でファイルに保存されるため、ほとんどの場合 concern する必要はありません）。

ⅱ. コンテナファイル：コンテナファイルのシステムが overlay の場合、UpperDir に従ってすべてのコンテナのファイルが自動的に検出されます。ただし、ContainerD のデフォルト設定は devicemapper です。この場合、ログを HostPath または EmptyDir にマウントして対応するパスを見つける必要があります。

B. 対応するアドレスに従ってデータを収集します。標準出力は特殊なため、標準出力ファイルを解析してユーザーの実際の標準出力を取得する必要があります。

C. 設定された解析規則に従って元のログを解析します。これには、行頭正規表現、フィールド抽出（正規表現、区切り文字、JSON、アンカーなど）、フィルタリング/破棄、データマスキングなどがあります。

D. データを SLS にアップロードします。

Sidecar ログ収集原則

K8s では、1 つの Pod が複数のコンテナを実行でき、これらのコンテナは名前空間を共有します。一般的に、コア作業コンテナをメインコンテナ、その他のコンテナをサイドカーコンテナと呼びます。サイドカーコンテナは一般的に補助機能として使用され、共有ボリュームを通じて、ファイルの同期、モニタリング/ログの収集、ファイルのクリーンアップなどの機能を実現します。Logtail のサイドカー収集も同じ原則が適用されます。サイドカーモードでは、メインビジネスコンテナに加えて、Logtail のサイドカーコンテナも実行されます。Logtail コンテナとメインコンテナはログのボリュームを共有します。収集プロセスは次のとおりです。

1. ビジネスコンテナはログを共有ボリュームに出力します（ファイルのみ、標準出力は共有ボリュームに書き込めません）。

2. Logtail は共有ボリュームを介してログの変更を検出すると、SLS に収集します。

サイドカーモードのベストプラクティスについては、サイドカーによるログ収集と Kubernetes ファイル収集実践：サイドカー+HostPath ボリュームを参照してください。

収集設定の原理

SLS ログ収集 Logtail は、CRD 設定、環境変数設定、コンソール設定、API 設定などの方法をサポートしています。異なる設定シナリオに応じて、推奨事項は次のとおりです。

1. CI/CD 自動デプロイと運用保守の要件が高いユーザーには、CRD 設定方式の使用を推奨します。

2. 環境が比較的静的なシナリオ（パブリッシュがあまり頻繁でなく、ログ収集戦略の変更がまれな場合）には、コンソール設定方式の使用を推奨します。

3. 上級ユーザーは API カスタム設定を検討できます。

4. 環境変数の設定方式は比較的制約が多く機能が弱いため、一般的には推奨されません。

CRD（Operator）設定方式

Log Service は、K8s 用に AliyunLogConfig という名前の CustomResourceDefinition 拡張を追加しました。同時に、AliyunLogConfig イベントをリッスンし、Logtail の収集設定を自動的に作成するために alibaba-log-controller が開発されました。ユーザーが AliyunLogConfig リソースを作成/削除/変更すると、alibaba-log-controller はリソースの変更をリッスンし、Log Service 上で対応する収集設定を作成/削除/変更します。これにより、K8s 内の AliyunLogConfig と Log Service 内の収集設定の関連付けが実現されます。

CRD AliyunLogConfig 実装方式

前述の図に示すように、Log Service は K8s 用に AliyunLogConfig という名前の CustomResourceDefinition 拡張を追加しました。同時に、AliyunLogConfig イベントをリッスンするために alibaba-log-controller が開発されました。

ユーザーが AliyunLogConfig リソースを作成/削除/変更すると、alibaba-log-controller はリソースの変更をリッスンし、Log Service 上で対応する収集設定を作成/削除/変更します。これにより、K8s 内の AliyunLogConfig と Log Service 内の収集設定の関連付けが実現されます。

alibaba-log-controller の内部実装

alibaba-log-controller は主に 6 つのモジュールで構成されています。各モジュールの機能と依存関係は前述の図に示されています。

• EventListener：AliyunLogConfig の CRD リソースのモニタリングを担当します。この EventListener は広義のリスナーです。主な機能は次のとおりです。

• 初期化時にすべての AliyunLogConfig リソースをリストします。

• AliyunLogConfig を登録し、変更イベントをリッスンします。

• イベントの欠落や処理失敗を防ぐために、AliyunLogConfig リソースの全量を定期的に再スキャンします。

• イベントをパッケージ化して EventHandler に送信して処理します。

• EventHandler：対応する Create/Update/Delete イベントの処理を担当します。Controller のコアモジュールとして、主な機能は次のとおりです。

• まず ConfigMapManager 内の対応するチェックポイントを確認します。イベントが既に処理されている場合（バージョン番号が同じでステータスが 200）、直接スキップします。

• 過去イベントが処理結果に干渉するのを防ぐために、サーバーから最新のリソースステータスをプルし、同じバージョンかどうかを確認します。バージョンが一貫していない場合は、サーバーバージョンで置き換えます。

• LogSDK の基本フォーマット要件を満たすようにイベントを前処理します。

• LogSDKWrapper を呼び出して、Log Service Logstore の対応する設定を作成/更新/削除します。

• 上記の処理結果に従って、対応する AliyunLogConfig リソースのステータスを更新します。

• ConfigMapManager：K8s の ConfigMap メカニズムに依存して、コントローラーのチェックポイント管理を実装します。次の機能が含まれます。

• チェックポイントと ConfigMap のマッピング関係を維持します。

• 基本的なチェックポイントの追加、削除、変更、クエリインターフェイスを提供します。

• LogSDKWrapper：Alibaba Cloud LOG golang sdk に基づくセカンダリパッケージで、次の機能が含まれます。

• Log Service リソースの初期化と作成。Project、MachineGroup、Operation Logstore などです。

• CRD リソースを対応する Log Service リソース操作に変換します。これは 1 対多の関係です。

• SDK インターフェイスをパッケージ化し、ネットワーク例外、サーバー例外、権限例外を自動的に処理します。

• 権限管理を担当します。ロールの自動取得、sts トークンの更新などです。

• ScheduledSyner：プロセス/ノード障害時のイベント欠落を防ぎ、設定管理の最終的な一貫性を確保するためのバックグラウンドの定期同期モジュールです。

• すべてのチェックポイントと AliyunLogConfig を定期的にリフレッシュします。

• チェックポイントと AliyunLogConfig リソースのマッピング関係を確認します。チェックポイントに存在しない設定がある場合、対応するリソースを削除します。

• Monitor：alibaba-log-controller はローカル実行ログを stdout に出力するだけでなく、リモートトラブルシューティングのためにログを直接 Log Service に収集します。収集ログの種類は次のとおりです。

• k8s api の内部例外ログ

• alibaba-log-controller のオペレーションログ

• alibaba-log-controller の内部例外データ（自動集約）

環境変数設定方式

環境変数の設定が最も簡単です。ユーザーは Pod を設定する際に、特殊フィールド aliyun_logs で始まる環境変数を追加するだけで、設定とデータ収集の定義を完了できます。この方式は Logtail により実装されます。

1. Logtail はコンテナランタイム（Docker Engine/ContainerD）からすべてのコンテナのリストを取得します。

2. 実行中のコンテナについて、環境変数に aliyun_logs で始まる環境変数が含まれているかを確認します。

3. aliyun_logs で始まる環境変数を SLS Logtail 収集設定にマッピングし、SLS インターフェイスを呼び出して収集設定を作成します。

4. Logtail はサーバーの収集設定を取得し、動作を開始します。

推奨される使用法

K8s ログ収集方式はさまざまな方法で実装でき、複雑さと効果が異なります。一般的に、収集方式と設定方式を選択する必要があります。ここでは、次の使用法を推奨します。

• 収集方式

• DaemonSet：単一機能またはサービスが多くないクラスターに適しています。クラスター全体の収集設定数を 500 以下に抑える必要があります。超えると Logtail のリソース消費が増加します。

• Sidecar：大規模な K8s クラスターまたは複数のビジネスパーティにサービスを提供する PaaS プラットフォームとしてのクラスターにこの方式の使用を推奨します。典型的な指標は収集設定数が 500 を超える場合です。

• 混在モード：コンテナの標準出力、システムログ、および一部のビジネスログには DaemonSet モードを使用します。ログ収集の信頼性が高いことが必要な一部の Pod には Sidecar モードを使用します。

• 設定方式

• CI/CD 自動デプロイと運用保守の要件が高いユーザーには、CRD 設定方式の使用を推奨します。

• 環境が比較的静的なシナリオ（パブリッシュがあまり頻繁でなく、ログ収集戦略の変更がまれな場合）には、コンソール設定方式の使用を推奨します。

• 上級ユーザーは API カスタム設定を検討できます。