fluentd-kubernetes-daemonset：Kubernetesノードのログ収集イメージを読む
Kubernetes 用の Fluentd デーモンセットとその Docker イメージ。これは、hub.docker.com での自動ビルドの数に制限があったためです。
ひと目でわかる
- これは何？
- fluent/fluentd-kubernetes-daemonsetが提供するイメージタグ、設定、CRIログ処理をREADMEの範囲で整理します。
- 誰に向いている？
- 既存のKubernetesログ基盤に、このイメージのタグと設定を明示的に固定して組み込みたい運用者向けです。最初に1ノードだけへ適用し、DaemonSetのマウント、CRI parserの結果、バッファ、出力側の到達性を順に観察してください。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 14 日前です。
- 何の言語で書かれている？
- 主に Ruby です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
DaemonSetとして配置するログ収集イメージ
このリポジトリは、Kubernetes 向けの Fluentd daemonset と、その daemonset が実行する Docker イメージを提供します。README は冒頭で、README.md 自体が templates/README.md.erb から生成されるため、編集はテンプレートファイルに対して行うべきだと注意しています。このプロジェクトは Ruby で書かれ、Apache-2.0 でライセンスされ、デフォルトブランチは master です。リポジトリメタデータの時点で、スター 1,296、フォーク 969、未解決 issue 17 件でした。
このリポジトリは、Kubernetesノード上でFluentdを動かすためのコンテナイメージ群を整理しています。アプリケーションのログを収集するにはDaemonSet、ホストのログディレクトリ、出力先の設定が別途必要です。イメージを選ぶことと、収集パイプラインが完成していることは同じではありません。
タグ名から読むFluentdとOSの組み合わせ
README は、Debian ベースのイメージのサポートタグを 3 つのグループに分けて列挙しています: マルチアーキテクチャ、x86_64、arm64 です。各バリアントは Fluentd のバージョンと送信先プラグインを組み合わせています: azureblob、cloudwatch、datadog、elasticsearch7、elasticsearch8、elasticsearch9、forward、gcs、graylog、kafka、kafka2、kinesis、logentries、loggly、logzio、opensearch、papertrail、s3、syslog です。タグは v1.19.3-debian-azureblob-1.1 のような形式で、v1-debian-PLUGIN タグは最新の v1 イメージを指します。README は本番では予期しない更新を避けるため厳密なタグを使うよう勧めています。
READMEのタグ規約は、Fluentdの世代、ベースOS、プラグインや機能の差を追うための手掛かりです。latest相当の曖昧なタグに依存すると、基盤更新とログ挙動の変更を切り分けにくくなります。使用するタグを固定し、対応するDockerfileとGitHub Actionsの生成経路まで確認してからクラスタへ配布します。
configmapと環境変数が決める起動内容
v1.17.0 以降、コンテナイメージのビルドプロセスは hub.docker.com の自動ビルドから GitHub Actions に移行しました。hub.docker.com には自動ビルドの数に制限があったためです。README は、ビルドパイプラインの数に制限がなくなったと述べています。また、v1.16.5 以前のイメージに関する制限も記録されています: papertrail と syslog イメージは公開されず、logentries、loggly、logzio、s3 の arm64 イメージも公開されません。これらのイメージが必要なユーザーは、保守されている Dockerfile から自分でビルドできます。
設定ファイルはConfigMapなどでマウントし、環境変数はイメージ側の起動処理と組み合わせて使います。READMEの例に出るパス、ボリューム、コンテナユーザーを自分のDaemonSetと照合してください。設定を変更した際はPodの再作成後にFluentdの起動ログを読み、入力プラグインが実際に開いたファイルを確認します。
CRI形式のログをどう解釈するか
各イメージにはデフォルトの設定ファイルが同梱されています: 送信先設定用の fluent.conf、k8s 固有の tail 入力と kubernetes_metadata フィルタ用の kubernetes.conf、/var/log/containers/*.log の解析用の tail_container_parse.conf、モニタリング用の prometheus.conf、systemd-journal 用の systemd.conf です。ユーザーは ConfigMap を使ってこれらのファイルを上書きできます。README が記録する環境変数には、v0.12 イメージ用の FLUENT_UID、コンテナログフォルダを変更する FLUENT_CONTAINER_TAIL_PATH、v1.9.3 以降で特定のログを除外する FLUENT_CONTAINER_TAIL_EXCLUDE_PATH、複数の fluentd インスタンスが同じ pos ファイルを共有しないようにする FLUENT_POS_EXTRA_DIR があります。
コンテナランタイムが書くCRIログは、アプリケーションが直接出した形式と異なります。CRIパーサーを使う構成では、時刻、ストリーム、分割されたログ行が後段へどう渡るかが要点です。READMEの設定断片だけで既存のparser設定との併用を推測せず、代表的なstdoutログを一件流して解析結果を確認します。
systemdとPrometheusの切り替え
デフォルトでは、これらのイメージは /var/log/containers/ ファイルに json パーサーを使います。Docker が JSON 形式のログを生成するためです。containerd と cri-o は異なる形式を使うため、v1.12.0-xxx-1.1 以降、ユーザーは ConfigMap 経由で tail_container_parse.conf を cri パーサーで上書きできます。README は @type cri の設定例を示し、詳細は fluent-plugin-parser-cri リポジトリへのリンクを提供しています。
メモリアロケータ、systemd入力、Prometheusメトリクスは、同じイメージを使えば自動で有効になる機能ではありません。READMEに記載された環境変数やタグの選択が、どの設定ファイルを選ぶかを決めます。メトリクスを公開する場合はサービスやNetworkPolicyも含め、意図したポートだけが見える状態にします。
OpenShiftと複数Fluentdの注意点
v1.17.0-1.3 と v1.16.5-1.3 以降、jemalloc メモリアロケータはデフォルトで無効になっています。systemd プラグインと jemalloc の組み合わせが free(): invalid pointer というクラッシュバグを引き起こしたためです。systemd プラグインを使わないユーザーは、LD_PRELOAD=/usr/lib/libjemalloc.so.2 で jemalloc を明示的に有効にできます。README はまた、FLUENTD_SYSTEMD_CONF を disable に設定して systemd の警告を抑えること、FLUENTD_PROMETHEUS_CONF を disable に設定して prometheus 入力プラグインを無効にすること、古い elasticsearch イメージでは FLUENT_ELASTICSEARCH_SED_DISABLE を true に設定して読み取り専用マウントで起動中の sed 実行を避けることを記録しています。
OpenShiftでは権限、セキュリティコンテキスト、ホストパスの扱いが通常のKubernetesと異なることがあります。複数のFluentdを同じノードへ置く構成も、ファイルの読み取り競合や重複送信を起こし得ます。READMEが説明していないクラスタポリシーや出力先の信頼性は、プロジェクトの保証に含めません。
クラスタへ適用する前の差分確認
OpenShift の場合、この daemonset はサービスアカウント fluentd で /var/log をマウントし、特権コンテナとして実行する必要があります。README は oc コマンドの手順を提供しています。異なる送信先にプッシュする複数の fluentd インスタンスの場合、FLUENT_POS_EXTRA_DIR が pos ファイル用の追加ディレクトリを追加します。README は、kafka イメージが zookeeper パラメータをサポートしないこと（zookeeper gem が Debian 10 で動作しないため）を指摘し、debian-kafka よりも debian-kafka2 を推奨しています。後者は非推奨の out_kafka_buffered プラグインを使うためです。このリポジトリは Windows k8s daemonset をサポートしておらず、README は代わりにコミュニティのフォークへのリンクを提供しています。
既存のKubernetesログ基盤に、このイメージのタグと設定を明示的に固定して組み込みたい運用者向けです。最初に1ノードだけへ適用し、DaemonSetのマウント、CRI parserの結果、バッファ、出力側の到達性を順に観察してください。対応タグを更新する際はDockerfileの差分とリリース履歴を同時に確認します。
編集部の結論
既存のKubernetesログ基盤に、このイメージのタグと設定を明示的に固定して組み込みたい運用者向けです。最初に1ノードだけへ適用し、DaemonSetのマウント、CRI parserの結果、バッファ、出力側の到達性を順に観察してください。対応タグを更新する際はDockerfileの差分とリリース履歴を同時に確認します。 READMEにない性能、互換性、運用保証は文書未記載として判断を分けます。
コミュニティノート