DaemonSets — ノードごとに 1 つのポッド__HTMLTAG_66___
クラスター内の_すべてのノード (またはノードの特定のサブセット) でポッドを実行する必要がある場合、__HTMLTAG_70___DaemonSet が答えです。レプリカに Pod を分散する Deployment とは異なり、DaemonSet は各ノード (セレクターに一致する) が常に独自の Pod を持つことを保証します。新しいノードがクラスターに追加されると、DaemonSet はそのノード上にポッドを自動的に作成します。ノードが削除されると、ポッドもガベージ コレクションされます。
1. DaemonSet とは何ですか?ノードごとに 1 つのポッドのメカニズム
DaemonSet コントローラーは次のことを継続的に保証します:
- 一致する各ノードでは、DaemonSet ポッドが 1 つだけ実行されます
- 新しいノードがクラスターに参加すると → 新しいポッドが自動的に作成されます
- クラスターからノードが削除された場合 → ポッドが削除された場合
- DaemonSet を削除すると、作成されたすべての Pod がクリーンアップされます
最も基本的な DaemonSet:
コードブロック_0
2.実際の使用例
DaemonSet はインフラストラクチャ エージェントに広く使用されています:
2.1 ロギング エージェント__HTMLTAG_94___
- Grafana Alloy: 各ノードの標準出力ファイルとコンテナからログを収集
- Fluent Bit: 軽量のログ フォワーダー、Elasticsearch/Loki にログを転送
- Fluentd: 出荷前にログを集約して変換
2.2 モニタリング エージェント
- Prometheus ノード エクスポーター: ノードの CPU、メモリ、ディスク、ネットワーク メトリクスをエクスポート
- _Datadog Agent: 完全な可観測性 — メトリクス、ログ、トレース、プロセス
- Elastic エージェント: 統合 Elastic Stack エージェント
2.3 ネットワーク プラグイン (CNI)
- Cilium: eBPF ベースのネットワーキング、セキュリティ、可観測性
- Calico: ネットワーク ポリシーの適用
- _Weave Net: シンプルなオーバーレイ ネットワーク
2.4 ストレージ (CSI ノード プラグイン)
- AWS EBS CSI ドライバー ノード プラグイン: EC2 ノードに EBS ボリュームをマウント
- Longhorn: 分散ブロック ストレージ — エンジンは各ノードで実行
- OpenEBS: クラウドネイティブ ストレージ
2.5 セキュリティ
- Falco: eBPF を使用したランタイム脅威検出 (レッスン 26 を参照)
- NeuVector: コンテナ セキュリティ プラットフォーム
- _Sysdig エージェント: セキュリティとパフォーマンスの監視
3. DaemonSet とデプロイメント: いつどちらを使用するか?
FAQ: 「DaemonSet の代わりに レプリカ: N を使用したデプロイメントを使用してみてはいかがでしょうか?」
_DaemonSet を使用する場合:
- ノード リソース (ファイル システム、ネットワーク インターフェイス、ハードウェア) への直接アクセスが必要
- N 個のポッドではなく、__HTMLTAG_187___各特定のノード__HTMLTAG_188___ にポッドが必要です__HTMLTAG_189___
- エージェントは、どのノードで実行されているか (ホスト名、ノード IP) を正確に把握する必要があります。
- インフラストラクチャ エージェント: ロギング、モニタリング、CNI、CSI
次の場合にデプロイメントを使用します
- ノードの数とは関係なくレプリカの数をスケールする必要がある
- ノード固有のアクセスを持たないステートレス アプリケーション
- Web サーバー、API サーバー、一般的なマイクロサービス
4.ノードの選択 — DaemonSet のノードを選択
DaemonSet は、必ずしもクラスター全体で実行する必要はありません。さまざまな方法で制限できます。
4.1 ノードセレクター__HTMLTAG_212___
特定のラベルを持つノードにのみデプロイします:
コードブロック_1
4.2 ノード アフィニティ
nodeSelector よりも複雑で、In、NotIn、Exists などの演算子をサポートします:
コードブロック_2
4.3 許容 — 汚染されたノードへのデプロイ
ノードには__HTMLTAG_222___taintsを設定して、通常のポッドがそこでスケジュールされるのを防ぐことができます。 DaemonSet は、これらのテイントをバイパスするために、特にコントロール プレーン ノードで実行するためにtolerations を必要とすることがよくあります:
コードブロック_3
最後の 2 つの許容範囲 (not-ready および unreachable) は、インフラストラクチャ エージェントにとって非常に重要です。ノードに問題がある場合でも、ロギング/モニタリングを実行し続けて、その問題のログを取得する必要があります。
5.更新戦略_
DaemonSet には 2 つの更新戦略があります:
5.1 ローリングアップデート (デフォルト)
コードブロック_4
_RollingUpdate を使用すると、Kubernetes は各ポッドを 1 つずつ (または maxUnavailable に従って) 更新します。古いポッドが削除され、新しいポッドが同じノード上に作成されます。
5.2 削除時
コードブロック_5
OnDelete を使用すると、DaemonSet は Pod を自動的に更新しません。新しいポッド (新しい仕様) は、古いポッドを手動で削除した場合にのみ作成されます。更新プロセスを完全に制御したい場合に使用します。
6.実用的な例: Grafana 合金ノード エージェント
Grafana Alloy は、古い Grafana Agent に代わる、Grafana Labs の OpenTelemetry ネイティブ コレクターです。 Alloy を DaemonSet としてデプロイして、各ノードからログとメトリクスを収集します:
コードブロック_6
合金構成のConfigMap:
コードブロック_7
7.例: Prometheus メトリクスのノード エクスポーター
Node Exporter はノードのハードウェアと OS メトリクスを収集し、Prometheus のスクレイピングに公開します:
コードブロック_8
8。 DaemonSet をデプロイするときの優先順位: PriorityClass
ロギングやモニタリングなどのインフラストラクチャ エージェントは、ノードがメモリ不足に陥っている場合でも、アプリケーション ポッドよりも前にスケジュールする必要があります。 PriorityClass を使用して、
を確保します。コードブロック_9
次に、PriorityClass を DaemonSet に割り当てます:
コードブロック_10
Kubernetes には多数の組み込み優先度クラスがあります:
system-cluster-critical: 2000000000 — CoreDNS、kube-proxy の場合
system-node-critical: 2000001000 — kubelet に隣接するコンポーネント用
9。 DaemonSet のテストとデバッグ
コードブロック_11
10. DaemonSet のベスト プラクティス
- 合理的なリソース: DaemonSet はすべてのノードで実行されます。各ポッドが 500m の CPU を使用すると、クラスター全体の容量が大幅に失われます__HTMLTAG_285___
- 完全な許容範囲:__HTMLTAG_289___not-ready および
unreachableの許容範囲を追加して、ノードに問題が発生した場合でもエージェントが動作し続けるようにします__HTMLTAG_293___ - PriorityClass: スケジュール を確保するために、通常のワークロードよりも高い優先度を割り当てます。
- readOnlyRootFilesystem: 可能な場合は有効にし、書き込むデータには emptyDir または hostPath を使用してください__HTMLTAG_301___
- RollingUpdate maxUnavailable: 同時に多くのノードのカバレッジを失わないように、1 または小さな数値に保ってください__HTMLTAG_305___
- 名前空間の分離: DaemonSet を別の名前空間にデプロイします (例:
monitoring、__HTMLTAG_311___logging) - アプリケーションのワークロードと混合しないでください
DaemonSet は、すべての Kubernetes クラスターの運用に不可欠なツールです。 DaemonSet の適切な使用方法を理解すると、Kubernetes プラットフォーム上に強固なインフラストラクチャの可観測性とセキュリティ層を構築するのに役立ちます。