Kubernetes DaemonSet：チュートリアル・ユースケース・ベストプラクティス

Kubernetes DaemonSetチュートリアル

このチュートリアルでは、DaemonSetの作成方法と使い方を解説します。内容はKubernetesドキュメントを基にしています。

1. Kubernetes DaemonSetを作成する

Kubernetes DaemonSetを作成するには、apiVersion: apps/v1とkind: DaemonSetを使用してYAMLマニフェストで定義します。マニフェストには、metadataやspecといった標準的なKubernetesフィールドに加えて、.spec.template配下のPodテンプレートを含める必要があります。DaemonSetの.spec.selectorはPodテンプレートに割り当てられたラベルと一致していなければならず、DaemonSetの作成後にこのセレクターを変更することはできません。また、Podの再起動ポリシーは、明示的に指定するかデフォルト設定によって、Alwaysである必要があります。

たとえば、次のマニフェストは、対象となる各ノードでコンテナを実行するシンプルなDaemonSetを作成します。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: example-daemonset
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: pause
        image: registry.k8s.io/pause

管理者は、リソースリクエスト、ボリュームマウント、toleration、ノードセレクター、ノードアフィニティなどのオプションでPodテンプレートを拡張できます。これらの設定は、DaemonSetのPodの実行方法と、スケジューリング制約が指定されている場合にはどのノードがPodをホストできるかを決定します。Kubernetesドキュメントでは、DaemonSetが該当するすべてのノードにPodを1つずつスケジュールする基本的な例が紹介されています。

2. DaemonSetをデプロイする

DaemonSetのマニフェストを作成したら、kubectl applyでクラスターにデプロイします。マニフェストをローカルにdaemonset.yamlとして保存している場合は、次のように実行します。

kubectl apply -f daemonset.yaml

Kubernetesドキュメントでは、Web上で公開されているYAMLマニフェストから直接DaemonSetを適用する例も示されています。たとえば次のとおりです。

kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml

kubectl applyコマンドは設定をKubernetes APIに送信し、その後DaemonSetコントローラーが対象ノードを判定して必要なPodを作成します。対象となるノードが新たにクラスターに参加すると、コントローラーはそれらのノードに対しても自動的にDaemonSetのPodを作成します。削除されたノードに関連付けられていたPodは、その後ガベージコレクションされます。

デプロイ後のDaemonSetへの変更は、通常、マニフェストを修正して再度kubectl applyを実行することで管理できます。RollingUpdate戦略を使用するDaemonSetでは、Podテンプレートの変更によって管理対象Podのローリングアップデートがトリガーされます。既存のPodを手動で削除した後にのみ置き換えのPodを作成したい場合に備えて、KubernetesはOnDelete更新戦略もサポートしています。

3. DaemonSetのPodを確認する

DaemonSetのデプロイ後は、そのPodが想定どおりのノードで実行されているかを確認します。Kubernetesドキュメントでは、各Podに割り当てられたノードが表示される-o wideオプションを付けてPodを一覧表示することを推奨しています。

kubectl get pods -o wide

クラスター全体で実行することを意図したDaemonSetであれば、出力には対象となる各ノードにDaemonSetのPodが表示されるはずです。NODE列を見れば、Podが想定どおりに分散されていることを簡単に確認できます。

多くのワークロードが存在する環境では、DaemonSetのPodテンプレートで定義したラベルを使って結果を絞り込みます。先ほどの例であれば、コマンドは次のようになります。

kubectl get pods -l app.kubernetes.io/name=example -o wide

DaemonSetリソース自体を確認することもできます。

kubectl get daemonset example-daemonset

または省略形のリソース名を使用します。

kubectl get ds example-daemonset

DaemonSetのステータスを見れば、望ましいPod数と、現在稼働中・Ready・利用可能なPod数を比較できます。個々のPodが正しく実行されていない場合は、kubectl describe pod <pod-name>やkubectl logs <pod-name>などのコマンドで、スケジューリングやコンテナレベルの問題を調査できます。Kubernetesの基本的なDaemonSetチュートリアルでは、該当するすべてのノードに対してPodが1つずつ存在することをPod一覧で確認することで、デプロイの成功を検証しています。

Kubernetes DaemonSetのベストプラクティス

1. CPUとメモリのrequests/limitsをライトサイジングする

適切なCPUおよびメモリのrequestsとlimitsの設定は、DaemonSetの安定性にとって極めて重要です。requestsはPodが必要とする最小リソースを定義し、limitsは消費できる最大量を設定します。過剰なプロビジョニングはリソースの無駄になり、リソースに制約のあるノードでスケジューリングが失敗する原因にもなります。一方、プロビジョニングが不足すると、Podの退避やパフォーマンス低下のリスクがあります。ワークロードのリソースプロファイルを分析して妥当なデフォルト値を決定し、各DaemonSetのPodが対象となるすべてのノードに無理なく収まるようにしましょう。

アプリケーションの進化に合わせて、リソース設定を定期的に見直し、調整してください。新機能の追加、負荷の増加、基盤インフラの変更などにより、リソース要件は変わる可能性があります。動的なKubernetes環境では、requestsとlimitsを定期的にチューニングすることでリソースの競合を防ぎ、クラスターの効率的な利用を支えられます。継続的な最適化のため、リソースの見直しを変更管理プロセスに組み込みましょう。

2. 過去の使用実績に基づいてリソースを設定する

リソースリクエストは、初期の見積もりだけに頼るのではなく、実際のワークロード下でのDaemonSet Podの挙動を反映すべきです。Prometheus、Grafana、またはクラウドの監視プラットフォームなどのツールから得られる過去のCPUとメモリのメトリクスを活用し、通常時の使用量、ピーク時の需要、ノード間の差異を把握しましょう。requestsは通常運用を支えるのに十分な高さに設定しつつ、対象となるすべてのノードで不要なリソース予約が発生しないようにします。

短期的な平均値ではなく、代表的な期間にわたるパーセンタイルベースのメトリクスを確認してください。CPUリクエストは多くの場合、バースト用の余裕を持たせた持続的な使用量を基準にでき、メモリリクエストは観測されたピークを考慮する必要があります。DaemonSetはリソースフットプリントがノード数分だけ増幅されるため、Pod単位の設定をわずかに改善するだけでも、クラスター容量を大きく解放できます。

3. メモリはCPUよりも保守的に扱う

Kubernetesでは、CPUとメモリのlimitsの障害モードが異なります。コンテナがCPU limitに達すると、KubernetesはCPU使用をスロットリングするため、通常は処理が遅くなるだけです。しかし、コンテナがメモリlimitを超えると、カーネルによってOOM（out-of-memory）エラーで強制終了される可能性があります。ノードレベルのエージェントの場合、再起動の繰り返しによって、ロギング、監視、セキュリティのカバレッジに空白が生じかねません。

一時的なスパイクやワークロードの増加を見込んで、メモリのrequestsとlimitsに十分な余裕を持たせましょう。割り当てを削減する前に、ピーク時のメモリ使用量とOOMイベントを監視してください。メモリ要件が予測しにくいエージェントの場合、厳しすぎるメモリlimitは適度な過剰割り当てよりも大きな混乱を招く可能性があるため、本番環境の使用パターンに照らしてlimitsを検証しましょう。

4. 適切な更新戦略を使用する

DaemonSetはRollingUpdateとOnDeleteの更新戦略をサポートしています。デフォルトのRollingUpdateでは、DaemonSetのPodテンプレートが変更されると既存のPodが自動的に置き換えられます。maxUnavailableやmaxSurgeといった設定で、更新中に利用できなくなるPod数や一時的に追加されるPod数を制御できます。

Podの置き換えを明示的に制御する必要がある場合はOnDeleteを使用します。この戦略では、Podテンプレートを更新しても既存のPodは自動的に置き換えられず、管理者が削除した後に初めてKubernetesが新しいテンプレートからPodを作成します。どちらの戦略を選ぶ場合でも、更新中にエージェントが一時的に利用できなくなることが、ロギング、監視、ネットワーク、セキュリティのカバレッジに与える影響を考慮してください。

5. クラスターの変化に合わせて効率を継続的に監視する

DaemonSetのリソース消費は、対象ノード数の増加とともに増大します。1つのノードでは控えめなリソースしか使わないPodでも、大規模クラスターでは合計で相当量のCPUとメモリを消費することになります。Pod単位の使用量と各DaemonSetが消費するリソースの総量の両方を追跡し、クラスター容量への影響を把握しましょう。

ノードタイプ、ワークロード、クラスターサイズが変化したときは、DaemonSetを再評価してください。未使用のリソースリクエスト、CPUスロットリング、メモリ逼迫、OOMイベント、再起動、スケジュールに失敗するPodに注意を払いましょう。継続的な監視により、リソース設定やスケジューリングルールが実際の運用状況と合わなくなったタイミングを特定できます。

PerfectScaleでDaemonSetのリソース使用を最適化

DaemonSetは対象となるすべてのノードにPodを配置するため、わずかな過剰・過少プロビジョニングでもクラスター全体で何倍にも膨らみます。PerfectScale by DoiTは、Helmコマンド1つでデプロイできるKubernetes最適化プラットフォームで、K8sスタック全体にわたって実用的なインサイトと自律的な最適化を提供します。これにより、ログコレクター、監視エクスポーター、セキュリティデーモンといったノードレベルのエージェントが、実際に必要なリソースで稼働するようになります。

PerfectScaleの主な機能：

• 自律的なワークロードのライトサイジング： Podfitは、クラスターの健全性とコストをきめ細かく可視化し、対応が必要な領域に優先順位を付け、データに基づくライトサイジングの推奨事項（自動適用も可能）によってワークロードを自律的に最適化します。
• ノード使用率の最適化： Infrafitは、ノード使用率を包括的に可視化し、きめ細かなインサイトによってアイドル状態のノード容量を特定・排除するとともに、ワークロードに最適なノードの選択を支援します。
• オートスケーラーとの連携： HPA、KEDA、Karpenter、Cluster Autoscaler、EKS Auto Mode、Fargate、Node Auto Provisioning、Google Autopilotと併用でき、それらの設定を改善するための実用的な推奨事項を提供します。
• 優先順位付きのリアルタイムアラート： 高度な自動優先順位付けにより、最も影響の大きいレジリエンスリスク、コスト急増、異常を、ユーザーやクラウド料金に影響が及ぶ前に検出し、Slack、Datadog、MS Teams、PagerDutyにアラートを配信します。
• トレンド・ガバナンスレポート： Trendsレポートは、クラスター、ノードグループ、名前空間、ワークロードを横断して、コスト、無駄、リスクのメトリクスを時系列で詳細に可視化し、予測や根本原因分析を支援します。
• 幅広い環境サポート： OpenShift、EKS、GKE、AKSを含むオンプレミスおよびクラウドベースのクラスターで動作し、Windowsベースのコンテナ、エフェメラルワークロード、MLワークロードもサポートします。

PerfectScaleプラットフォームの詳細を見る