🚀 Kubernetesの全ノード管理者: DaemonSetガイド

5月 25, 2026

—

cslab

in IT Security

📋 目次

DaemonSetとは何か？ 🤔
なぜDaemonSetを使うのか？ 💡
実践: DaemonSetを作成する 🛠️
Control Planeにもデプロイしたい場合 (Taint & Toleration) 🔐
まとめと要約 🏁

1. DaemonSetとは何か？ 🤔

Kubernetesにおいて、DaemonSet（デーモンセット）は、すべての（または特定の）ノードにちょうど1つのPodを維持することを保証するコントローラーです。

一般的なDeploymentがノードの空きリソースを見て適切に分散配置する方式であるとすれば、DaemonSetは「新しいノードが追加されれば自動的にそこにもPodを実行する」という一途な管理者と見なすことができます。

2. なぜDaemonSetを使うのか？ 💡

すべてのノードに同じサービスをデプロイする必要があるのはどのような状況でしょうか？主にシステム運用に関連する作業です。

ログ収集: 各ノードのログを収集するfluentdやlogstash。
モニタリング: ノードの状態を監視するPrometheus Node Exporter。
ネットワーク設定: クラスターネットワークを構成するkube-proxyやCalicoのようなCNIプラグイン。

3. 実践: DaemonSetを作成する 🛠️

最も基本的な形式のDaemonSet YAMLファイルを見てみましょう。この例は、すべてのノードで動作するシンプルなnginxデーモンセットです。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2

このファイルを適用すると、一般的なWorker NodeにはPodが1つずつ作成されます。しかし、1つの問題が発生します。それは、Control Plane（Master Node）にはPodが作成されないという点です。

4. Control Planeにもデプロイしたい場合 (Taint & Toleration) 🔐

KubernetesのMasterノード（Control Plane）は非常に重要な場所です。そのため、デフォルトでTaint（テイント、汚染）という設定がされており、一般的なPodが侵入できないように「禁止」しています。

① MasterノードのTaintを確認する

まず、Masterノードにどのような「汚染」が付着しているか確認してみましょう。

kubectl describe node <마스터-노드-이름> | grep Taints

通常、次のような結果が表示されます。Taints: node-role.kubernetes.io/control-plane:NoSchedule

これは「このノードはcontrol-planeの役割なので、許可されていないPodはスケジューリングするな(NoSchedule)」という意味です。

② Toleration（トレラレーション、容認）を構成する

DaemonSetがMasterノードでも実行されるようにするには、この「汚染（Taint）」に耐えられる「耐性（Toleration）」をPod設定に追加する必要があります。

修正されたYAMLのspec部分を確認してください。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
spec:
  # ... (省略)
  template:
    spec:
      # ここが重要です！
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2

key: Masterノードで確認したTaintのキー値です。
operator: Existsは、そのキーが存在するだけでよいという意味です。
effect: NoSchedule状態でも無視して侵入できるようにします。

このように設定すると、DaemonSetは一般的なノードだけでなく、Control Planeノードでも堂々と実行されるようになります。

5. まとめと要約 🏁

DaemonSetは、クラスター全体のメンテナンスと運用を担当する重要な要素です。

DaemonSetはノードごとに1つのPodを保証します。
ノードが増えると自動的に拡張されます。
Control Planeにデプロイするには、該当ノードのTaintを確認し、それに対応するTolerationを設定する必要があります。

これで、クラスターの隅々まで必要なサービスを配置できるようになりました！ 🚀