今回は、DaemonSetとStatefulSetについて、話していきたいと思います。
この2つのリソースは、ReplicaSetと似てPodを管理するものですが、それぞれの特徴によって、特別なリソースの作成に必要なものとなります。
Workloads リソースの概要
- Pod:Workloadsリソースの最小単位
- ReplicaSet(旧ReplicationController):Podのレプリカを作成し、指定した数のPodを維持し続けるリソースです。
- Deployment:ローリングアップデートやロールバックなどを実現するリソースです。
- DaemonSet(ReplicaSet亜種):各ノードにPodを一つずつ配置するリソースです。
- StatefulSet(ReplicaSet亜種):ステートフルなPodを作成できるリソースです。
- Job:Podを利用して、指定回数のみ処理を実行させるリソースです。(使い捨てPod)
- CronJob:Jobを管理するリソースです。
DaemonSet
DaemonSetは、各ノードにPodを一つずつ配置するリソースです。
ReplicaSetと似ていて、どれもPodのレプリカを管理するものとなります。
また、指定のノードだけ配置させないことも可能です。(nodeSelectorやNode Anti-Affinityで実現可能)
特徴:
- 一つのノードに複数のレプリカ(同一のPod)を作成できない
- アップデートの条件は2typeがある
- OnDelete:手動でPod削除するまで、更新されない。
- manifestファイル(設定ファイル)修正しても、更新されません。
- RollingUpdate:Deploymentと同じように、manifestファイルの更新で自動アップデートする
- maxUnavailable(使用不可Pod数)のみ指定可能。その理由は一つ目の特徴にある。
- OnDelete:手動でPod削除するまで、更新されない。
- レプリカ数の定義は必要ない。(ノードごとに一個だから)
- その他の特徴はReplicaSetと同じ。
UseCase:
- 各Podが出力するログをノード単位で収集するPod。Fluentd(ログ収集ツール)を実行するPodなど
- Podのリソース使用状態やノードの状態をモニタリングするPod。Datadog(モニタリングツール)を実行するPodなど
DaemonSetのイメージ図
DaemonSet manifest 例
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd-elasticsearch # DaemonSet名
namespace: kube-system # Namespace指定、今後説明
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd-elasticsearch
template: # Podの設定
metadata:
labels:
name: fluentd-elasticsearch
spec:
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
containers: # コンテナの設定
- name: fluentd-elasticsearch
image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
resources:
limits:
memory: 200Mi
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
terminationGracePeriodSeconds: 30
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
※公式ドキュメント例を使用
StatefulSet
StatefulSetは、特別なReplicaSetです。
StatefulSetで作成されたPodは、規則のあるPod名で作成されます。
StatefulSetは名前通り、ステートフル(状態維持する)なワークロードに対応するためのリソースです。
例えば、データベースなどに使用する。
特徴:
- 作成されたPodは
<pod名>-0,<pod名>-1,<pod名>-2...
のような番号のついた名前を使う - データを永続化するための仕組みを有している
- Podが再作成しても名前が変わらない
- Podにマウントしている永続化ディスクは、Podが再作成してもそのまま接続され続ける。
- StatefulSetが削除しても、永続化ディスクリソースは削除されることはありません。
- レプリカ数の変更によるスケーリング(Pod数の拡張と収縮):
- ReplicaSetやDaemonSetと違い、ディフォルトでは1個ずつ作成/削除する
spec.podManagementPolicy: Parallel
の設定によって、並行で作成、削除も可能spec.podManagementPolicy: OrderedReady
がデフォルト値
- 作成は若い番号から作成していく
- 削除は大きい番号から削除していく
- ReplicaSetやDaemonSetと違い、ディフォルトでは1個ずつ作成/削除する
- アップデートの条件
spec.updateStrategy
は2種類がある- OnDelete:DaemonSetと同じ
- RollingUpdate:DaemonSetと同じ
- maxUnavailable(使用不可Pod数)のみ指定可能。その理由は永続データを持っているため拡張できない。
- RollingUpdateの場合、
spec.podManagementPolicy: Parallel
設定は更新時に無視される。 - 何番Podまで更新しないという設定が可能:
spec.updateStrategy.rollingUpdate.partition
- その他の特徴はReplicaSetと同じ
StatefulSet manifest 例
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web # StatefulSet名
spec:
selector:
matchLabels:
app: nginx # .spec.template.metadata.labelsの値と一致する必要があります
serviceName: "nginx"
replicas: 3 # デフォルト値は 1
template: # Podの設定
metadata:
labels:
app: nginx # .spec.selector.matchLabelsの値と一致する必要があります
spec:
terminationGracePeriodSeconds: 10
containers: # コンテナの設定
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates: # データ領域をマウント
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
※公式ドキュメント例を使用
最後に
今回は、DaemonSetとStatefulSetについて、話しました。
DaemonSetは、ノードの使用状況監視などで、よくつかわれるワークロードです。
また、StatefulSetは、データベースや永続化ディスクを持たせるワークロードによく使われています。どちらもk8sにおいてよく使われるタイプのリソースです。
コメント