A detailed explanation of the Job class log collection scheme in the K8s environment

背景

K8s の豊富なコントローラは、コンテナオーケストレーションに大きな利便性をもたらします。単発タスクや定期タスクのニーズに対し、K8s は job および CronJob コントローラを提供し、非常駐コンテナのオーケストレーションに対応します。この非常駐特性により、タスクコンテナの生存時間は非常に短くなる可能性があり（履歴データの定期クリーンアップタスクなど）、起動直後に失敗するタスクもあるため、ジョブログの収集に大きな課題をもたらします。

本稿では、高性能かつ軽量なオブザーバビリティコレクタである iLogtail を用いた各種ジョブログ収集方式について論じ、各方式が異なるシナリオでどのようにログ収集の安定性を確保し、どのように最適化できるかを分析します。

ジョブコンテナの特徴

便宜上、本稿ではジョブコントローラに制御されるビジネスコンテナを「ジョブコンテナ」と呼びます。他のタイプのコンテナと比較して、ジョブコンテナには以下の特徴があります。

1. 作成・削除の高頻度：ジョブコンテナは定期的またはオンデマンドでスケジューリングされ、実行完了時に終了するため、他のタイプのコンテナよりも作成・削除の頻度が著しく高くなります。

2. 短いライフサイクル：ジョブコンテナの期待動作はタスク実行後の終了であり、サービスに常駐しないため、ライフサイクルは比較的短くなります。履歴データの単純削除に使用されるジョブもあり、そのライフサイクルは数秒程度です。

3. 大規模なバースト同時実行：ジョブコンテナはバッチタスクやテストシナリオのオーケストレーションによく使用されます。このようなシナリオでは、多数のジョブコンテナインスタンスが瞬時に生成され、大量のログが伴って生成されることがよくあります。

ジョブログ収集方式の選定における重要な検討事項

したがって、以下の 3 つの検討事項がジョブログ収集において重要です。

コンテナ検出速度：ジョブコンテナは頻繁に追加・削除されます。コンテナ検出速度が遅すぎると、コンテナが破棄される前に発見できず、データ収集は到底不可能になります。

収集開始遅延：ジョブコンテナのライフサイクルは非常に短い場合があります。K8s の Pod が破棄されると、その配下のすべてのコンテナデータが削除されます。タイムリーに収集を開始しないと、ファイルハンドルをロックできず、削除されたファイルのデータを収集できません。

弾性スケーリングのサポート：ジョブコンテナの突発的高同時実行特性は、弾性リソースを活用したコスト削減に最適です。そのため、収集方式も弾性スケーリングに対応できることが求められます。

同時に、ソリューション選定時にはコンテナログ収集の一般的な要件も考慮する必要があります。

リソースコスト：リソースコストが低いほど費用を抑えられ、ログ収集がビジネスのリソース使用に与える影響も軽減されます。

メタ情報の付与：メタ情報はログの出所を識別するために使用され、豊富なメタ情報はログの発見と活用に役立ちます。

侵入性：侵入性はログ収集の開発コストを左右します。同時に、侵入性が強いほどログ収集とビジネスの結合度が高まり、将来の方式変更やアップグレードに潜在的なコストをもたらします。

iLogtail コンテナ収集方式の比較

DaemonSet 収集方式

DaemonSet 収集方式は、K8s の DaemonSet コントローラを利用して各ノードに iLogtail コンテナを 1 つデプロイし、そのノード上のすべてのコンテナのログ収集を行います。このデプロイ方式では、コンテナランタイムの docker.sock または containerd.sock と通信してノード上のすべてのコンテナを検出し、返されたコンテナ情報からコンテナの標準出力パスとストレージパスを取得し、ホストパスをマウントしてデータを収集します。

この収集方式の利点は非常に明確です。各ノードに収集コンテナを 1 つだけデプロイすればよく、アプリケーションコンテナの数とは無関係でリソースを節約できます。完全なコンテナメタ情報を取得でき、アプリケーションは収集コンテナを認識せず、侵入性がありません。

一方で、ジョブログ収集に関連する重要な 3 ポイントにおいては平均的です。DaemonSet 経由で iLogtail をデプロイする場合、iLogtail のコンテナ検出メカニズムは docker.sock または containerd.sock との通信に依存します。Docker には独自の EventListener メカニズムがあり、コンテナの作成・削除イベントをリアルタイムで取得できますが、containerd にはこのメカニズムがなく、ポーリングでしかコンテナの作成・削除を検知できません。最新バージョンでは、ポーリング間隔は 1 秒です。したがって、iLogtail がコンテナを検出するまでの遅延は 1 秒と考えられます。コンテナ検出からデータ収集開始までに 3〜6 秒の遅延があります。標準出力収集の遅延は標準出力収集プラグイン内部のポーリング間隔に起因し、コンテナファイル収集の遅延は docker_file プラグインのポーリング間隔と C++ コアでの最新コンテナ構成のロード頻度制限に起因します。これらの処理時間を考慮すると、DaemonSet モードでのコンテナログ収集遅延は約 5〜8 秒と見積もられます。弾性スケーリングの面では、DaemonSet でデプロイされた iLogtail は動的なノード拡張をサポートできますが、物理ノードを伴わない弾性コンテナ拡張は直接サポートできません。

Sidecar 収集モード

Sidecar 収集モードは、K8s の同じ Pod 内のコンテナがストレージボリュームを共有できる機能を利用し、ビジネス Pod 内にビジネスコンテナと収集コンテナを同時にデプロイしてビジネスデータを収集します。この収集方式では、ビジネスコンテナが収集対象ディレクトリをマウントして収集コンテナと共有する必要があります。収集コンテナはローカルファイルを収集することでビジネスコンテナのログを収集します。

本質的に、この方式はホスト収集と大きな違いはなく、コンテナ検出の問題は懸念する必要がありません。同時に、収集コンテナが終了しない限り、Pod は Running 状態を維持し、共有ストレージボリューム上のファイルは削除されないため、収集遅延によるデータ損失を心配する必要はありません。Sidecar はビジネスコンテナ Pod と共にデプロイされるため、さまざまな弾性スケーリング方式にも柔軟に対応でき、ジョブコンテナ収集の重要な 3 ポイントにおいて優れた性能を示します。

ただし、DaemonSet と比較して Sidecar はそれほど普及していません。コンテナの標準出力を直接収集できないことに加えて、使用範囲を制限するいくつかの欠点があります。まず、リソース消費が高いことです。各 Pod に Sidecar 収集コンテナが必要で、リソースコストはビジネス Pod の数に比例します。次に、収集の原理はホスト収集と同じため、コンテナのメタ情報を自動収集できず、環境変数を通じて収集コンテナに公開する必要があります。最後に、各ビジネス Pod で収集対象データの共有ストレージを構成し、収集コンテナへの終了通知メカニズムを考慮する必要があるため、侵入性があります。

ECI 弾性コンテナプロダクト収集方式

ECI は弾性コンテナインスタンス（Elastic Container Instance）の略称です（詳細は Alibaba Cloud の公式紹介を参照）。使用後に破棄される小規模な仮想マシンに相当し、物理ノードを持ちません。突発的高同時実行シナリオに対してコストと柔軟性の利点があり、これはまさに一部のジョブコンテナシナリオの特徴と合致します。ECI プロダクト収集方式の原理は DaemonSet 収集方式と似ています。異なる点は、ECI 内の iLogtail コンテナが Kube Scheduler ではなく ECI によって制御され、ユーザーからは見えないことです。iLogtail のコンテナ検出方式は docker.sock や containerd.sock との通信ではなく、静的なコンテナ情報から収集対象コンテナを検出します。コンテナデータ取得をサポートするため、ECI は ECI 上のパスを iLogtail コンテナにマウントします。これは DaemonSet がホストパスをマウントする原理と同じです。

ECI プロダクト収集方式は弾性スケーリングを自然にサポートします。収集原理が DaemonSet と類似しているため、ECI 収集方式は DaemonSet 収集の特性の一部を継承しています。メタ情報を完全に取得できることや、コンテナ検出と収集開始の遅延などが該当します。ただし、ECI プロダクト収集方式は静的ファイルベースのコンテナ検出方式を使用しているため、起動後すぐにコンテナを検出でき、実際の遅延は DaemonSet よりもはるかに小さくなります。

コスト面では、各 Pod に iLogtail Pod が付属する ECI インスタンスが起動しますが、高同時実行のジョブシナリオでは、オンデマンド弾性コンテナリソースにより自建ノードよりも低コストになる可能性があります。ECI はデータ収集が必要なコンテナに対してのみ iLogtail コンテナを作成するため、ビジネスコンテナのログ収集要求を判定する手段が必要です。現在、CRD（K8s Operator）と環境変数がサポートされています。CRD モードは現在推奨されるアクセス方式で、ビジネスコンテナへの侵入がなく、より豊富な収集構成をサポートします。環境変数モードを採用した場合、ある程度の侵入性があります。

同一コンテナ収集方式

同一コンテナ収集方式とは、収集プロセスとビジネスプロセスを同じコンテナ内にデプロイする方式で、コンテナを仮想マシンとして扱うデプロイ方式に相当します。したがって、収集原理はホスト収集と完全に同じです。

この方式は非常に煩雑で侵入性が高いように見えますが、レガシービジネスのコンテナ化過程では非常に一般的です。同一コンテナデプロイを採用する場合、ジョブデータを失わないためには、コンテナの終了メカニズムを慎重に設計し、データ収集完了後にのみ終了を実行する必要があります。

収集プロセスとビジネスプロセスが同じコンテナ内で動作するため、この収集方式にはコンテナ検出や収集開始の遅延がなく、あらゆる弾性方式を完全にサポートします。

リソースコスト面では、各ビジネスコンテナが追加の収集プロセスのリソースを消費するため、リソース消費が高くなります。コンテナのメタ情報を収集するには、環境変数などを通じてビジネスコンテナ内で公開する必要があり、自動ラベリングはできません。

独立ストレージ収集方式

独立ストレージとは、コンテナが収集対象データを共有 PV または hostPath のマウントパスに出力し、収集コンテナは PV または hostPath 上のデータを収集するだけの収集方式を指します。一部のジョブスケジューラでは各ジョブのログパスを指定できるため、同じ共有ボリュームにログを出力できます。共有 PV を使用する場合は収集コンテナ 1 つで全データを収集でき、hostPath を使用する場合は DaemonSet で収集コンテナをデプロイして各ノードに収集コンテナを 1 つずつ配置します。

独立ストレージを使用すると、データのライフサイクルがコンテナのライフサイクルから分離されます。収集コンテナはストレージ上のデータをパスに従って収集するだけで、コンテナ検出や収集開始遅延の問題はありません。この収集方式のその他の利点として、収集コンテナの数がビジネスコンテナに比例して増えず、リソース消費が極めて低く、ビジネスコンテナへの侵入がないことが挙げられます。

ただし、弾性スケーリングの面では独立ストレージ収集方式の性能は劣ります。PV を使用して収集コンテナ 1 つがそれに対応する場合、収集コンテナのスループットが収集パフォーマンスのボトルネックになります。hostPath と DaemonSet デプロイを使用する場合、弾性コンテナをサポートできません。この収集方式はメタ情報の取得においてもサポートが弱く、データストレージパスにメタ情報を埋め込むことで一部のメタ情報を公開することしかできません。たとえば、ボリュームマウント時に SubPathExpr を `logs/$(POD_NAMESPACE)_$(POD_NAME)_$(POD_IP)_$(NODE_IP)_$(NODE_NAME)` に設定します。

まとめ

以下の表は、前述の 5 つの収集方式をまとめたものです。

ご覧のとおり、各方式にはそれぞれ長所と短所があり、異なるジョブコンテナ収集シナリオとデータ整合性の要件に適しています。以下に典型的なジョブコンテナ収集シナリオと推奨される収集方式を示します。

代表的なシナリオ

ライフサイクルの短いジョブ

タスクの実行時間が長い場合（たとえば 1 分以上）、収集側に与えられるジョブコンテナデータ収集のタイムウィンドウが大きくなります。この場合、収集方式のコンテナ検出遅延や収集開始遅延に敏感ではないため、DaemonSet 収集方式を使用しても問題ありません。ただし、ジョブのライフサイクルが 1 分未満の場合、デフォルトの収集パラメータではログ欠落が発生する可能性があります。ジョブコンテナのライフサイクルが 10 秒以上であれば、DaemonSet 収集方式を継続使用できます。いくつかのパラメータを調整するだけで、データの完全な収集を確保できます。標準出力収集とコンテナファイル収集では原理が異なるため、調整が必要なパラメータも異なります。

1. Docker の起動パラメータ `docker_config_update_interval` を調整して、コンテナ検出後の有効遅延を短縮します。たとえば、バージョン 1.0.34 以前ではデフォルトの 10 秒から 3 秒に調整し（以降のバージョンではデフォルト 3 秒）、コンテナ検出後にファイルをロックできない可能性を低減します。

2. ポーリング時間を調整して収集開始遅延を短縮し、ファイルハンドルを事前にロックして Pod 削除後のデータ収集失敗を防止します。標準出力の場合、収集構成（ローカル収集構成が有効）を調整する必要があります。パラメータ名は `FlushIntervalMs` で、たとえばデフォルトの 3000 ms から 1000 ms に変更します。ファイル収集の場合、起動パラメータ（グローバルに有効）を調整する必要があります。パラメータ名は `max_docker_config_update_interval` で、たとえばデフォルトの 3 分の頻度制御 10 を 60 に調整します。

4. ジョブ起動時に大量のログが出力される場合、ファイル検出後の収集開始位置を調整して、開始位置がファイルの先頭にならないことによるログ欠落を防止できます。標準出力の場合、収集構成（ローカル収集構成が有効）を調整する必要があります。パラメータ名は `StartLogMaxOffset` で、たとえばデフォルトの 131072 B から 13107200 B に変更します。ファイル収集の場合、収集構成（ローカル収集構成が有効）を調整する必要があります。パラメータ名は `tail_size_kb` で、たとえばデフォルトの 1024 KB から 10240 KB に変更します。

5. チェックジョブ完了後、すぐにクリーンアップされないこと、すなわち終了直後のコンテナ標準出力ログがまだ読み取り可能であることを確認します。内蔵 CronJob スケジューリングを使用する場合、CronJob の `.spec.successfulJobsHistoryLimit` および `.spec.failedJobsHistoryLimit` が未構成または > 0 であることを確認します。カスタムスケジューラーを使用する場合、ジョブの `.spec.ttlSecondsAfterFinished` が未構成または > 0 であり、独自のロジックが完了したジョブをすぐにクリーンアップしないことを確認します。

秒レベルフォールバックジョブ

コンテナのライフサイクルが非常に短い場合（10 秒未満、あるいはそれ以下）、DaemonSet 方式では避けられないコンテナ検出遅延により、このようなジョブコンテナのデータ収集が容易に失われます。この場合、以下の 2 つの方式のいずれかの使用を推奨します。

1. コンテナ標準出力を使用する。コンテナログの出力先を標準出力に変更し、ログローテーションのリクエストを kubelet に処理させます。K8s の GC メカニズムは通常、各 Pod の最後のコンテナのメタ情報と標準出力ログレコードを保持します。これにより、コンテナが終了しても、Pod が削除されていない限り、コンテナを発見して標準出力ログを収集できます。この方式でも、前述の JobsHistoryLimit に注意し、ログ収集前に Pod が破棄されないようにする必要があります。

2. Sidecar または ECI を使用してデータ収集を行い、データ収集の整合性を確保します。通常のコンテナログ収集とは異なり、ジョブコンテナで Sidecar を使用してログを収集する場合、終了メカニズムに注意が必要です。通常のコンテナの終了はコントローラが Pod の終了を要求するため、Pod 内のすべてのコンテナが SIGTERM シグナルを受信します。しかし、ジョブコンテナは通常タスク実行後に自動終了するため、収集コンテナは SIGTERM シグナルを受信しません。そのため、ビジネスコンテナから収集コンテナに終了を通知する必要があります。シンプルな実装方法は、共有ボリューム上のファイルを通じて通知することです。

まとめと展望

ジョブコンテナ収集は、作成・削除の高頻度、短いライフサイクル、大規模なバースト同時実行という特徴により、ログ収集方式に特別な要件を課しています。本稿ではこれらの特徴に基づき、3 つの主要検討事項と 3 つの副次検討事項から 5 つの収集方式の長所と短所を分析し、典型的なジョブシナリオと組み合わせて具体的な収集解決策を提示しました。議論の結果から、各種ジョブシナリオでデータを失わないためには、収集コンテナのパラメータ調整が必要になることが多いことがわかります。ECI モードでのジョブ実行とログ収集は、その弾性スケーリングとシンプルな収集構成により、将来のクラウドネイティブジョブ実行のベストプラクティスになる可能性があります。

iLogtail にとって、コンテナ検出と収集開始遅延をさらに短縮し、ユーザーによる手動パラメータ調整の必要性をなくすことが、次の最適化ステップです。SLS プロダクトにとって、突発的な大規模トラフィックへの対応とユーザー介入コストの削減も、検討すべき最適化ポイントです。