Kubernetes完全ガイド 第5章 Workloadsリソース
Pod
ReplicationController
ReplicaSet
Deployment
DaemonSet
StatefulSet
Job
CronJob
Pod
pod内のコンテナはIPアドレスを共有、ローカルホストで通信可能
サブコンテナの例としてプロキシ、設定値の書き換え、ローカルキャッシュ、SSL終端など
podのデザインパターン
サイドカーパターン
メインコンテナの補助的な機能を追加するコンテナを内包
アンバサダーパターン
メインコンテナが外部システムに接続する際に代理で中継を行うコンテナを内包
メインコンテナからはlocalhostでアンバサダーコンテナに接続可能
シャーディングされたDBへの接続。localhostで接続することで疎結合に
アダプタパターン
外部からのリクエストに対して差分を吸収するコンテナを内包
prometheus用にメトリクスをフォーマットしたり
Dockerfile の ENTRYPOINT/CMD は k8s では command/args に対応
pod名の制約は RFC1123 のホスト名の制約
podのDNSサーバ設定は spec.dnsPolicy
ClusterFirst (デフォルト): クラスタ内のDNSサーバに問い合わせ、解決できなければアップストリームに問い合わせ
None: dnsConfig に指定する。コンテナの /etc/resolv.conf が書き換えられる
spec.hostAliases で、/etc/hosts を書き換える、静的な名前解決設定
ReplicaSet/ReplicationController
ReplicationController は廃止 -> ReplicaSet へ
セルフヒーリング: ノードやpodに障害が発生した場合でもpod数が指定数を満たすように起動する
podのlabelをカウントする形で実現
ReplicaSet の selector と pod template でlabelが異なると、永遠にpodが作られてしまう
kubectl apply あるいは kuebctl scale でスケール
Deployment
Deploymentは複数のReplicaSetを管理する
新しいReplicaSetを作成
新しいReplicaSetのpodを徐々に増やす
古いReplicaSetのpodを徐々に減らす
古いReplicaSetはレプリカ数0で保持する
古いReplicaSetは保持されるため、ロールバックが可能 kubectl rollout undo
kubectl rollout pause で一時停止、kubectl rollout resume で再開
アップデート戦略
Recreate: 一度すべてのpodを削除してから再度podを作成。ダウンタイムが発生する。余剰リソースを使わない。早い
RollingUpdate: maxUnavailable(不足するpod数), maxSurge(超過pod数)を設定
アップデートパラメータ
minReadySeconds
revisionHistoryLimit
progressDeadlineSeconds
スケーリング: kubectl scale, kubectl apply
DaemonSet
配置したくないノードがある場合、nodeSelector や Node Anti-Affinity で除外
アップデート戦略
OnDelete: 既存のpodのアップデートは行わない。podが消えて再作成するタイミングでアップデートされる
RollingUpdate: maxUnavailableを指定する。0にはできない
StatefulSet
ステートフルなワークロードのためのリソース
データを永続化するための仕組みを有する
pod名が変わらない(suffixに数字のインデックスがつく)
PVを使う場合、podの再起動時に同じディスクを利用される
インデックスの順番でスケールインスケールアウトされる(ランダムにpodが作成、削除されるReplicaSetと異なる)
1つずつpodが作成、削除される
podManagementPolicy を Parallel に設定することで並列にpodを起動することも可能。デフォルトはOrderedReady
アップデート戦略
RollingUpdate
OnDelete
StatefulSetが削除されてもPVCは解放されない
Job
コンテナを利用して1回限りの処理を実行するリソース
厳密には、N並列で実行しながら指定した回数のコンテナ実行(正常終了)を保証する
restartPolicy
OnFailure: pod障害時には再度同一のpodを利用してJobを再開
Never: pod障害時には新規のpodが作成される
completions: 成功回数を指定
parallelism: 並列度を指定
backoffLimit: 失敗を許容する回数
kubectl scale job は廃止が決定している
One Shot Task: completion 1, parallelism 1 の、1回限りのジョブ
Multi Task: parallelism N, completion M 並列で複数回実行。最終的には N - (M * k) 回実行される
Single WorkQueue: parallelism 1, completions 未指定。特定のタスクを実行し続ける。ワーカーとして動作 (backoffLimitは無制限にできない)
Multi WorkQueue: parallelism N, completion 未指定。N並列で実行し続ける
CronJob
指定した時刻にJobを作成し続ける
suspend (一時停止)が可能 (spec.suspend : true)
同時実行に関する制御
古いjobがまだ実行している場合に新たなjobを実行するか
Allow, Forbid(同時実行を行わない)、Replace(前のJobをキャンセルし新しいJobを実行)
実行開始期限に関する制御
開始時刻の遅れの許容 spec.startingDeadlineSeconds
デフォルトではどんなに開始時刻が遅れてもJobを作成できる
CronJobの履歴
spec.successfulJobsHistoryLimit, spec.failedJobsHistoryLimit
kubectl run --schedule で、cronjobのマニフェストを書かずにCronJobを作成可能