DaemonSet

DaemonSetの基本機能と動作原理

DaemonSetの主要な機能は、ノードレベルでの排他的かつ継続的なPodの配置保証にある。通常のDeploymentが、クラスター全体で指定数のレプリカを動かし、どのノードに配置するかをKubernetesスケジューラーに任せるのに対し、DaemonSetは「ノード」を配置の単位として指定する。

DaemonSetコントローラーは、クラスター内のノードの状態を常に監視している。クラスターに新しいノードが追加された場合、DaemonSetの仕様（Podテンプレート）に基づき、自動的にそのノード上に新しいPodをスケジューリングする。逆に、ノードがメンテナンスや障害によってクラスターから削除された場合、対応するPodは自動的にガベージコレクションされ、リソースが解放される。この自動的なライフサイクル管理により、管理者はノード数の増減に煩わされることなく、インフラストラクチャレベルのサービスの一貫性を保つことができる。

配置対象とするノードは、ノードセレクター（nodeSelector）やノードアフィニティを利用して細かく制御可能である。例えば、高性能GPUを搭載した特定のノード群にのみ、データ処理用のアクセラレータデーモンを配置するといった柔軟な運用が可能となる。また、Podが何らかの理由で終了した場合や再起動が必要になった場合も、DaemonSetは既存のノードに対して「Exactly One（正確に一つ）」のPodが存在し続けることを常に保証する。これは、システム全体の安定稼働に不可欠なサービスを提供する上で極めて重要な特性である。

具体的な使用例・デプロイシーン

DaemonSetは、ノードごとに固有の機能を提供する必要があるユースケースで不可欠であり、主にインフラストラクチャ層の基盤サービスに利用される。

1. ログ収集エージェント

最も代表的な使用例として、ログ収集エージェントのデプロイが挙げられる。Fluentd、Logstash、またはFilebeatといったエージェントをDaemonSetとして各ノードに配置することで、全てのノードのローカルなログファイル（多くの場合/var/log以下）にアクセスし、それらを中央のロギングシステム（ElasticsearchやS3など）に確実に転送することが可能となる。もしこのエージェントがDeploymentとしてデプロイされた場合、一部のノードにPodが配置されず、ログ収集に漏れが生じるリスクがある。DaemonSetはこのリスクを完全に排除する。

2. モニタリングエージェント

ノードの健全性やリソース利用状況を把握するためのモニタリングエージェントもDaemonSetで運用される。Prometheus Node ExporterやDatadog Agent、New Relic Infrastructure Agentなど、ノードのCPU負荷、メモリ使用率、ディスクI/O、ネットワークトラフィックといったメトリクスを収集するエージェントを全ノードに配置することで、クラスター全体のインフラストラクチャの状態を偏りなく把握できる。

3. ストレージおよびネットワークコンポーネント

Kubernetesクラスターの基盤となるコンポーネントもDaemonSetとして実行されることが多い。 分散ファイルシステム（例：CephやGlusterFS）において、各ノードがストレージを提供する、あるいはクライアントとしてアクセスするためのデーモンやプラグインを配置する場合に利用される。また、Kubernetesのネットワークプラグイン（CNI：Container Network Interface）の実装（例：Calico, Flannel, Cilium）も、多くの場合、DaemonSetとしてデプロイされ、各ノードにおけるIPアドレス管理、ネットワークポリシーの適用、パケットルーティングなどを担う。

4. セキュリティエージェント

ノードレベルの脆弱性スキャンやランタイムセキュリティ監視を行うエージェント（例：Falco）も、潜在的な脅威の監視漏れを防ぐため、全てのノードで実行される必要があることからDaemonSetが採用される。

DeploymentやStatefulSetとの相違点

Kubernetesの主要なワークロードコントローラーであるDeployment、StatefulSet、DaemonSetは、それぞれが異なる目的と保証を提供する。DaemonSetの特性を理解するには、これらとの相違点を明確にすることが重要である。

Deploymentは、主にステートレスなアプリケーションを対象とし、クラスター全体で望ましいレプリカ数が常に稼働していることを保証する。Podがどのノードに配置されるかはスケジューラーに委ねられ、ノードの障害が発生した場合、Podは健全な別のノードに再スケジュールされることでサービスの継続性を保つ。

一方、DaemonSetはノードとPodを1対1で強固に結びつける。Podは特定のノードから離れることはなく、そのノードのリソースやファイルシステムに直接アクセスする前提で設計される。Deploymentが「クラスター全体でN個」のPodを保証するのに対し、DaemonSetは「ノードごとに1個」のPodを保証する。

StatefulSetは、永続的なアイデンティティ（ホスト名、PVC）と厳密なデプロイ順序を必要とするステートフルなアプリケーション（データベースなど）のために設計されている。DaemonSetはステートフル性を扱わず、あくまでノードレベルのサービス配置に特化している。DaemonSetの核心は「ノードカバレッジの完全な保証」にあると言える。

管理と運用の留意点

DaemonSetを運用する上では、ノードリソースの適切な管理が最も重要な留意点となる。DaemonSetのPodは全てのノードに常駐するため、Podが必要とするリソース（CPU、メモリ）は、クラスター全体のノード数に比例して増加する。リソース要求（requests）や制限（limits）の設定が不適切であると、基盤サービスであるDaemonSetが、本来実行されるべきアプリケーションのPodのリソースを奪い、ノードリソースの枯渇（ノードプレッシャー）を引き起こす可能性がある。そのため、DaemonSetのPodは、通常QoSクラスをGuaranteedに設定するか、少なくとも適切なリミットを設定することが推奨される。

次に、Podの更新戦略である。DaemonSetはDeploymentと同様にローリングアップデート（Rolling Update）戦略をサポートしているが、ノード数が非常に多い大規模クラスターにおいては、更新プロセスに時間がかかる場合がある。更新戦略には、自動的に次々とPodを更新していく「RollingUpdate」モードと、Podを手動で削除しない限り更新が行われない「OnDelete」モードが存在し、サービスの特性に応じて選択する必要がある。

特に、ログ収集やセキュリティ監視など、わずかな時間も停止が許されないクリティカルなサービスの場合、ローリングアップデートの実行中にノードカバレッジが瞬間的に喪失する可能性を許容できるかどうかの判断が重要となる。また、ノード障害時に再配置は試みられない（ノードが復旧するか、完全に削除されるまで待機する）ため、ノード自体が長期間ダウンした場合、そのノードに対応するDaemonSet Podは長期間Unready状態となる点も、監視上理解しておくべきである。

由来・語源

「DaemonSet（デーモンセット）」という名称は、伝統的なUNIX系オペレーティングシステム（OS）における「デーモン（Daemon）」プロセスに由来する。デーモンとは、システム起動時から常駐し、バックグラウンドで特定のサービスやタスクを継続的に提供し続けるプログラムを指す。ネットワークの接続受付、印刷キューの管理、リソースの監視などがこれにあたる。

KubernetesにおけるDaemonSetも、このOSのデーモンの概念を踏襲している。すなわち、アプリケーション本体の処理ではなく、インフラストラクチャを支える常駐型コンポーネントの管理を意図しており、クラスター内の「全ての」あるいは「特定の」ノード上で、常にそのサービス（Pod）が実行状態にあることを目的とする。この命名は、単にレプリカ数を指定するDeploymentとは異なり、ノード単位でのサービス継続性とカバレッジを保証する役割を明確に示している。

使用例

(記述募集中)

関連用語

• (なし)