ここでは、Kubernetesの中で最小のデプロイ単位であるPodと、ReplicaSet, Deploymentとの関係についてまとめます。
Contents
Pod
Pod は、Kubernetesアプリケーションの基本的な実行単位です。これは、作成またはデプロイするKubernetesオブジェクトモデルの中で最小かつ最も単純な単位です。Podは、クラスターで実行されているプロセスを表します。
Podの概観 | Kubernetes
同じPod内のアプリケーションは、同一のIPアドレス、ポート、ホスト名を持っています。KubernetesではこのPodに対してlivenessProbeやreadinessProbeといったヘルスチェックや、CPU・メモリリソースの要求量、上限量を設定できます。
このPodを複数、一括で管理するのがReplicaSetです。
ReplicaSet: Podの管理
ReplicaSetは、事前にPodテンプレートに従って正しい数のPodが常に稼働しているように調整する、k8sクラスタ全体での「Pod管理人」です。このReplicaSetで管理されたPodは、k8sノードに障害が起こった時に、自動的に他のノードへ再割り当てされます。
ReplicaSetは、Labelセレクタと呼ばれる方法で自らが管理すべきPodの集まり（replicas）を識別します。例として、以下のサンプルManifestを見ていきましょう。
apiVersion: apps/v1kind: ReplicaSetmetadata: name: sample-replicasetspec: replicas: 10 selector: matchLabels:app: nginx template: metadata:labels: app: nginx spec:containers:- image: nginx name: nginxこのサンプルManifestでは、.spec.selector.matchLabelsで指定している”app: nginx”というキーバリューに一致するLabelを持ったPodを管理対象とします（これには.spec.template以下の実装をもとに作成されるPodが該当します。.metadata.labelsに”app: nginx”を持っているからですね）。
ちなみにここでのselectorとして利用しているmatchLabelsは、等価ベースの比較をするものです（つまり、指定したキーバリューに完全一致したLabelを持つPodしか管理対象にしません）。もし、より柔軟な選択をしたい場合、matchExpressionsが利用できます。これはその中で指定するoperatorの値によって４種類ほど書き方があるので、以下でまとめて紹介しておきますね。
# "app: nginx"または"app: rails"のLabelを持つものが対象matchExpressions:- key: app operator: In values: [nginx, rails]# "app: nginx"または"app: rails"のLabelを持たないものが対象matchExpressions:- key: app operator: NotIn values: [nginx, rails]# "app"のキーが存在するLabelを持つものが対象matchExpressions:- key: app operator: Exists# "app"のキーが存在しないLabelを持つものが対象matchExpressions:- key: app operator: NotExistsさて、KubernetesにはこのPod群（replicas）を管理するReplicaSetをさらに管理するものがあります。それこそがDeploymentです。
Deployment: ReplicaSetを管理
改めて、DeploymentはPodを管理するReplicaSetを管理します。会社のポストで譬えると、
- Pod ＝ 現場の社員
- ReplicaSet ＝ 中間管理職
- Deployment ＝ 執行役員
といった感じでしょうか。このDeploymentに変更があった際＝役員が変わった際には、新しいReplicaSetが作成され、Podが置き換わっていきます。
少し、Deployment manifestの例を見てみましょう。
apiVersion: apps/v1kind: Deploymentmetadata: name: sample-deploymentspec: replicas: 10 selector: matchLabels:app: nginx strategy: rollingUpdate:maxSurge: 50%maxUnavailable: 0% template: metadata:labels: app: nginx spec:containers:- image: nginx name: nginxDeploymentは、ReplicaSetがLabelセレクタで管理すべきPodを識別したのと同様に、Labelセレクタでマネージ対象のReplicaSetを選びます（.spec.selector以下で指定していますね）。
その一方で、ReplicaSetにはなかった.spec.strategyという設定値もあります。これはPodのデプロイ戦略を指定するもので、シンプルに「古いバージョンのPodを全部止めて→新しいバージョンのPodをデプロイする」Recreateと、無停止更新を可能にするRollingUpdateとがあります。２つの中でも特にRollingUpdateは、サービスインしたWebサービスでは利用されることが多いです。デプロイ戦略としてこのrollingUpdateを選択した場合は、さらにその中でmaxSurgeとmaxUnavailableを指定します。
maxSurgeはreplicasで指定した数よりも増やしていい最大Pod数、maxUnavailableはreplicasで指定した数よりも減らしていい最大Pod数です。
KubernetesでDeploymentの色々なアップデート方法 | SIOS Tech. Lab
２つの設定値の詳しい説明は、上で引用したこちらの記事がわかりやすいのでそちらに譲りますが、maxSurgeを100%、maxUnavailableを0%と指定すると「もともと稼働しているPod数以下にはせず（maxUnavailable=0%）、そしてPod数をもともと稼働している数の100%まで増やす（maxSurge=100%）」という設定になるので、世に言うブルーグリーンデプロイ（Blue-Green Deployment）が実現できます。
まとめ
- Podを管理するのがReplicaSet、ReplicaSetを管理するのがDeployment
