このページでは、Kubernetes DaemonSet オブジェクトと、Google Kubernetes Engine でのその使い方について説明します。
DaemonSet とは何か
他のワークロード オブジェクトと同様に、DaemonSet は、複製されたポッドのグループを管理します。ただし、DaemonSet は、クラスタ全体またはノードのサブセットに渡って、ノードあたり 1 つのポッドのモデルを維持しようとします。ノードプールにノードが追加されると、DaemonSet は必要に応じて自動的に新しいノードにポッドを追加します。
DaemonSet は、ポッド テンプレートを使用します。これには、そのポッドの仕様が含まれています。ポッドの仕様によって、各ポッドの外観、つまり、コンテナ内で実行するアプリケーション、マウントするボリューム、ラベルとセレクタなどが決定されます。
使用パターン
DaemonSet は、すべてのノードまたは特定のノードで実行する必要があり、ユーザーの介入を必要としない、進行中のバックグラウンド タスクのデプロイに便利です。このようなタスクの例として、ceph などのストレージ デーモン、fluentd などのログ収集デーモン、および collectd などのノード モニタリング デーモンが挙げられます。
たとえば、すべてのノードでデーモンのタイプごとに DaemonSet を実行することができます。または、1 つのタイプのデーモンに対して複数の DaemonSet を実行することもできますが、ハードウェア タイプやリソースニーズによって異なる設定を使用することもできます。
DaemonSet の作成
DaemonSet は、kubectl apply または kubectl create を使用して作成できます。
DaemonSet マニフェスト ファイルの例を以下に示します。
apiVersion: v1/beta2 # For Kubernetes version 1.9 and later, use apps/v1
kind: DaemonSet
metadata:
name: fluentd
spec:
selector:
matchLabels:
name: fluentd # Label selector that determines which Pods belong to the DaemonSet
template:
metadata:
labels:
name: fluentd # Pod template's label selector
spec:
nodeSelector:
type: prod # Node label selector that determines on which nodes Pod should be scheduled
# In this case, Pods are only scheduled to nodes bearing the label "type: prod"
containers:
- name: fluentd
image: gcr.io/google-containers/fluentd-elasticsearch:1.20
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
この例では、次のとおりです。
metadata: nameフィールドで指定された、fluentdという名前の DaemonSet が作成されます。- DaemonSet のポッドには
fluentdというラベルが付けられます。 - ノードラベル セレクタ（
type: prod）は、DaemonSet がそのポッドをスケジュールするラベル付きノードで宣言します。 - ポッドのコンテナは、バージョン
1.20のfluentd-elasticsearchイメージを pull します。コンテナ イメージは Container Registry によってホストされます。 - コンテナは 100 m の CPU と 200 Mi のメモリをリクエストします。コンテナは自身のメモリ使用量の合計を 200 Mi 以内に制限します。
要約すると、ポッド仕様には次の手順が含まれています。
- ポッドに
fluentdというラベルを付けます。 - ノードラベル セレクタ
type: prodを使用して、一致するノードに合わせてポッドをスケジュールします。ラベルセレクタに対応していないノードに対してスケジュールしないでください（または、すべてのノードに対してスケジュールする場合は、nodeSelectorフィールドを省略します）。 - バージョン
1.20のfluentd-elasticsearchを実行します。 - メモリリソースと CPU リソースを要求します。
DaemonSet 設定の詳細については、DaemonSet API リファレンスをご覧ください。
DaemonSet の更新
DaemonSet を更新するには、ポッド仕様、リソースの要求と制限、ラベル、および注釈を変更します。
更新の処理方法を決定するために、DaemonSet は spec: updateStrategy で定義された更新戦略を使用します。OnDelete と RollingUpdate の 2 つの戦略があります。
OnDeleteは、オブジェクトの構成が変更されたときに DaemonSet ポッドを自動的に削除して再作成しません。代わりに、ポッドを手動で削除することにより、変更が反映された新しいポッドをコントローラに作成させる必要があります。RollingUpdateは、DaemonSet ポッドを自動的に削除して再作成します。この戦略では、有効な変更によって自動的にロールアウトがトリガーされます。これは DaemonSet のデフォルトの更新戦略です。
更新ロールアウトは、次のコマンドを実行してモニタリングできます。
kubectl rollout status ds [DAEMONSET_NAME]
DaemonSet の更新の詳細については、Kubernetes ドキュメントの DaemonSet でローリング更新を実行するをご覧ください。
