Kubernetes DaemonSet とは何ですか? また、どのように使用しますか?

DaemonSet は、クラスター内のすべてのノードに同じ Pod を複製する Kubernetes API オブジェクトの一種です。

この記事では、DaemonSet とは何か、どのように機能するか、いつ使用すべきかについて詳しく説明します。また、独自のクラスターに DaemonSet をデプロイする方法を示す簡単なチュートリアルも提供します。

Kubernetes DaemonSet とは何ですか?

写真

DaemonSet は、各ノード上で Pod をデーモン プロセスとして実行できるようにする Kubernetes API オブジェクトです。新しいノードがクラスターに追加されると、DaemonSet に属する Pod が自動的に実行されます。同様に、ノードがオフラインの場合、このノードで実行されている DaemonSet の Pod もリサイクルされます。 DaemonSet は通常、ノード監視やログ収集エージェントなどの長時間実行されるバックグラウンド サービスに使用されます。

デフォルトでは、DaemonSet は常に各ノードで 1 つの Pod インスタンスを実行します。もちろん、DaemonSet の構成をカスタマイズして、指定されたノードでのみ Pod をスケジュールできるようにすることもできます。

DaemonSet は各ノードで 1 つの Pod を確実に実行するように設計されているため、通常は新しい Pod のスケジュールが妨げられる状況でもスケジュールを続行できるようにするデフォルトの「許容範囲」があります。たとえば、ターゲット ノードがリソース制約に直面していたり​​、新しい Pod を受け入れなかったりする場合でも、DaemonSet の Pod はスケジュールされます。

Pod、ReplicaSets、Deployment、StatefulSets、DaemonSets の違いは何ですか?

ポッドは Kubernetes の基本的な単位で、クラスター内で実行されている 1 つ以上のコンテナのコレクションを表します。

ReplicaSets は、指定された数の Pod レプリカが特定の時間に実行されることを保証する構造を提供することで、この基盤を構築します。デプロイメントにより、ReplicaSets の宣言的な管理が可能になり、Kubernetes でほとんどのステートレス アプリケーションがデプロイされるようになります。一方、StatefulSets により、永続的なデータ ストレージを必要とするステートフル ワークロードの使用が簡素化されます。

DaemonSet は、独自のスケジュール動作を持つという点で他のワークロード タイプとは異なります。必要な数のレプリカが実行されるまで、ポッド、レプリカセット、デプロイメントは利用可能なノードに自動的にスケジュールされます。アフィニティ ルールを設定しない限り、Pod がどのノードで実行されているかを知る方法はありません。 DaemonSet は、すべてのノードが Pod を実行することを保証します。

DaemonSet の適用シナリオは何ですか?

ノード監視エージェントの実行

たとえば、Prometheus を使用してノード リソースを監視する場合、通常は node_exporter をデプロイして各ノードのリソース情報を収集します。こちらのほうが適しています。 DaemonSet は特別な構成なしで上記の要件を実現できます。

ノードログを収集する

同様に、DaemonSet を使用して、ノード レベルのログ (Kubelet およびカーネル ログ、実行中のポッド ログなど) を収集することもできます。たとえば、監視システム Loki は、次の図に示すように、各ノードにログ収集用の promtail を展開します。

写真

写真

ノードデータのバックアップ

バックアップは DaemonSet のもう 1 つのアプリケーション シナリオです。 DaemonSet を使用すると、ノードが変更されたときにバックアップ サービスを拡張または再構成することなく、すべてのノード データがバックアップされます。一部のノードをバックアップする必要がない場合は、マークされたノードのみを上書きするように DaemonSet をカスタマイズできます。

DaemonSet の例

DaemonSets の原理を紹介したので、簡単な例を実行してみましょう。

DaemonSets は複数のノードに Pod をデプロイするため、マルチノードの Kubernetes クラスターが必要です。以下は私のクラスターの 1 つです。生徒は自分でそれを構築できます。

写真

DaemonSetを作成する方法

apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd spec: selector: matchLabels: name: fluentd template: metadata: labels: name: fluentd spec: containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:latest

テンプレートは、DaemonSet が実行するコンテナを定義する通常の Kubernetes Pod 仕様です。次に、それを適用して展開します。

 kubectl apply -f fluentd.yaml

写真

DaemonSet Podが起動するのを待ってから、Podとそれらがデプロイされているノードをクエリします。

 kubectl get pods -l name=fluentd -o wide

写真

Kubernetes がクラスター内の 3 つのノードに Fluentd Pod を自動的にスケジュールしたことがわかります。

kubectl get daemonsets コマンドは、クラスター内の現在のノード数に対して実行するために必要な Pod の数や、現在準備が完了して使用可能かどうかなど、DaemonSet オブジェクトのステータスを表示します。

写真

DaemonSet を更新する方法

DaemonSet は、他の Kubernetes オブジェクトと同じ方法で更新されます。コマンドやYAMLファイルを編集してコマンドを繰り返して宣言的な更新を行うこともできます。具体的なコマンドは次のようになります。

 kubectl update kubectl patch kubectl apply

DaemonSetを削除する方法

標準の Kubernetes 削除は DaemonSet にも適用されます。次のコマンドを使用して、DaemonSet によって作成されたすべての Pod を停止して削除し、その後 DaemonSet オブジェクト自体を削除できます: kubectl delete

写真

あるいは、Pod を実行したまま DaemonSet オブジェクトだけを削除することもできます。削除コマンドを発行するときは、--cascade=orphan を指定します。

写真

ポッドが既存のノード上でまだ実行されていることがわかります。同じ名前の別の DaemonSet を作成すると、上記の Pod に自動的に関連付けられます。

写真

DaemonSet タイプの Pod を実行するノードを指定します

アフィニティ ルールを使用して、クラスター内の特定のノードで Pod を実行するように DaemonSet を構成できます。これらの制約は

spec.template.spec.nodeSelector または spec.template.spec.affinity を設定する

以下は Fluentd DaemonSet マニフェストの修正バージョンです。

 apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd spec: selector: matchLabels: name: fluentd template: metadata: labels: name: fluentd spec: nodeSelector: log-collection-enabled: "true" containers: - name: fluentd-elasticsearch image: quay.io/fluentd_elasticsearch/fluentd:latest

上記は、ノード ラベルが log-collection-enabled: "true" の場合にのみ実行されることを意味します。次に、マークするラベルを選択して実行します

kubectl label node xxx.58 log-collection-enabled=true

次に、DaemonSet マニフェストを更新します。

 kubectl apply -f fluentd2.yaml

写真

ノードセレクターが有効になっていることがわかります。対応するラベルがタグ付けされているノードが 1 つだけであるため、DaemonSet の現在の利用可能な Pod 数は 1 として表示されます。

写真

DaemonSet をスケールする方法

Kubernetes では、DaemonSet の役割は、各ノードで Pod を実行し、クラスター内の各ノードに対応する Pod インスタンスがあることを保証することです。 DaemonSet を 0 にスケールダウンする、つまり、すべてのノードで関連付けられている Pod インスタンスの実行を停止するには、DaemonSet の nodeSelector をどのノードにも一致しない値に設定します。

kubectl patch コマンドを使用して DaemonSet の設定を変更し、nodeSelector をどのノードにも一致しないプレースホルダー値に設定できます。たとえば、次のコマンドは、DaemonSet の nodeSelector を dummy-nodeselector: abc に設定します。

 kubectl patch daemonset fluentd -p '{"spec": {"template": {"spec": {"nodeSelector": {"dummy-nodeselector": "abc"}}}}}'

これにより、DaemonSet はどのノードでも新しい Pod インスタンスをスケジュールしなくなり、0 にスケールダウンする効果が実現されます。

DaemonSet のベストプラクティス

以下は、パフォーマンスと信頼性を最大限に高めるのに役立つ DaemonSet の使用に関するベスト プラクティスです。

DaemonSet は、Pod のスケーリングがノードの数に関連付けられている場合にのみ使用します。

DaemonSet は、ノード間で Pod ノードをスケーリングするように設計されています。クラスター内のノード数に関係なくポッドをデプロイする必要がある場合は、ReplicaSet や Deployment などの通常のワークロード オブジェクトを使用する必要があります。

すべての DaemonSet Pod に正しい再起動戦略があることを確認する

DaemonSet 内の Pod の再起動ポリシーは Always に設定する必要があります。この値を指定すると、Pod はノードとともに再起動されます。

DaemonSet Podを手動で管理しないでください

DaemonSet の一部として作成されたポッドは、手動で編集または削除しないでください。 DaemonSet の外部で変更を行うと、Pod が孤立する可能性があります。

ロールバックを使用して、DaemonSet の変更をすばやく元に戻します。

DaemonSets をクラスターのバックグラウンド サービスとして使用する利点の 1 つは、何か問題が発生した場合に、以前のバージョンに簡単にロールバックできることです。ロールバックを開始する方が、手動で回復して新しいデプロイメントを作成するよりも高速で信頼性が高くなります。