【k8s】Pod, ReplicaSet, Deployment

Categories:Kubernetes

ここでは、Kubernetesの中で最小のデプロイ単位であるPodと、ReplicaSet, Deploymentとの関係についてまとめます。

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/v1
kind: ReplicaSet
metadata:
  name: sample-replicaset
spec:
  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の値によって4種類ほど書き方があるので、以下でまとめて紹介しておきますね。

# "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/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 0%
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx

Deploymentは、ReplicaSetがLabelセレクタで管理すべきPodを識別したのと同様に、Labelセレクタでマネージ対象のReplicaSetを選びます(.spec.selector以下で指定していますね)。

その一方で、ReplicaSetにはなかった.spec.strategyという設定値もあります。これはPodのデプロイ戦略を指定するもので、シンプルに「古いバージョンのPodを全部止めて→新しいバージョンのPodをデプロイする」Recreateと、無停止更新を可能にするRollingUpdateとがあります。2つの中でも特にRollingUpdateは、サービスインしたWebサービスでは利用されることが多いです。デプロイ戦略としてこのrollingUpdateを選択した場合は、さらにその中でmaxSurgeとmaxUnavailableを指定します。

maxSurgeはreplicasで指定した数よりも増やしていい最大Pod数、maxUnavailableはreplicasで指定した数よりも減らしていい最大Pod数です。

KubernetesでDeploymentの色々なアップデート方法 | SIOS Tech. Lab

2つの設定値の詳しい説明は、上で引用したこちらの記事がわかりやすいのでそちらに譲りますが、maxSurgeを100%、maxUnavailableを0%と指定すると「もともと稼働しているPod数以下にはせず(maxUnavailable=0%)、そしてPod数をもともと稼働している数の100%まで増やす(maxSurge=100%)」という設定になるので、世に言うブルーグリーンデプロイ(Blue-Green Deployment)が実現できます。

まとめ

  • Podを管理するのがReplicaSet、ReplicaSetを管理するのがDeployment

参考

返信がありません

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です