kubernetes – PodとReplicaSetとDeployment Workload

Workloadのリソースは合計7種類ありますが、すべて一括ご紹介しても、消火不良になりやすいので、段階を踏んで、3回に分けて説明していきたいと思います。

まず、今回は、Pod、ReplicaSet、Deploymentについて話していきます。

Workloads リソースの概要
Pod
1. Pod manifest 例
ReplicaSet
1. ReplicaSet manifest 例
Deployment
1. Pod,ReplicaSet,Deployment の関係
2. Deployment manifest 例
最後に

Workloads リソースの概要

Pod：Workloadsリソースの最小単位
ReplicaSet(旧ReplicationController)：Podのレプリカを作成し、指定した数のPodを維持し続けるリソースです。
Deployment：ローリングアップデートやロールバックなどを実現するリソースです。
DaemonSet(ReplicaSet亜種)：各ノードにPodを一つずつ配置するリソースです。
StatefulSet(ReplicaSet亜種)：ステートフルなPodを作成できるリソースです。
Job：Podを利用して、指定回数のみ処理を実行させるリソースです。(使い捨てPod)
CronJob：Jobを管理するリソースです。

Pod

Podは一言でいうと、コンテナを格納するリソースです。

特徴：

Podごとに、k8sの内部IPを持っている。ただしIPは動的割り振られる
複数コンテナを格納可能
同じPod内のコンテナは同じホストにいるような感じ
- 127.0.0.1(localhost)でお互いに通信可能
Pod名：
- 英文字、数字、-、.が使用可能
- 先頭と最後は英文字、数字である

Pod manifest 例

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod  # Pod名
  labels:
    app: myapp  # Podのラベル、ラベルはk8sを識別するための重要な属性です。
spec:
  containers:  # コンテナの設定
  - name: myapp-container  # コンテナ名
    image: busybox  # コンテナを作成するためのイメージ
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']  # コンテナ起動コマンド

ReplicaSet

ReplicaSetは一言でいうと、Podを管理するためのリソースです。※冗長化、セルフヒーリング。

特徴：

何個Podのレプリカを作るかを定義する
Podレプリカ数を管理する
- 基本はPodのlabel属性でレプリカ数をカウントする
  - 注意：クラスタ内すべてのpodのlabelを見ているので、labelが間違って他のpodに付けたらカウントされる
- *equality-based,set-based条件でのレプリカ管理でも可能です。
- Podが死んだら、レプリカ数を維持するために新Podを作成する
- Podが作り過ぎたら、削除する
- 削除するPodはランダムで行われる
作成されたPod名は<ReplicaSet名>-<ランダムな文字列>

ReplicaSet manifest 例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3  # レプリカ数指定
  selector:
    matchLabels:  # ラベルでPodをコントロールする
      tier: frontend
    matchExpressions:  # 条件でPodをコントロールする
      - {key: tier, operator: In, values: [frontend]}
  template:  # Podの設定
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:  # コンテナの設定
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:  # コンテナの環境変数の設定
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

※公式ドキュメント例を使用

Deployment

Deploymentは一言でいうと、アップデート時、ReplicaSetの動きを管理するためのリソースです。主にアップデートの方法のコントロールです。

これまで紹介したリソース関係をいうと、以下になります。
Deployment　(管理)→　ReplicaSet　(管理)→　Pod

k8sとしては、コンテナの起動方法はDeploymentを推奨しています。
例えばコンテナ一つだけでも、PodやReplicaSetで作成するのではなく、Deploymentで作成することです。

特徴：

ローリングアップデートの方法を定義する
ローリングアップデートの条件
- manifestファイル(設定ファイル)のspec.template部分が変更されると、自動的にアップデートが開始される
ローリングアップデート
- アップデート時に、新規ReplicaSetを作成する
- 現行ReplicaSetのPodを削除しながら、新規ReplicaSetに新Podを作成
- 戦略(strategy)が定義可能spec.strategy.type
  - Recreate：旧ReplicaSetのPodを全部削除してから、新ReplicaSetにPodを作成する。ダウンタイムあり
  - RollingUpdate(デフォルト)：maxUnavailable(使用不可Pod数)とmaxSurge(超過可能Pod数)を定義して、アップデートさせる。
アップデートのロールバックは可能
アップデートの一時停止と再開も可能
PodがReady状態になってから、次にPodがアップデート可能の遅延時間の指定
ロールバック可能な履歴数の指定
アップデート失敗し、ロールバックしていいまでの判断時間指定

Pod,ReplicaSet,Deployment の関係

イメージとしては、このような関係です。

Deployment manifest 例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment  # Deployment名
  labels:
    app: nginx
spec:  # ReplicaSetの設定
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:  # Podの設定
    metadata:
      labels:
        app: nginx
    spec:
      containers:  # コンテナの設定
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

※公式ドキュメント例を使用

最後に

今回は、階層関係のあるワークロード3種類をご紹介しました。
Kubernetesでは、直接PodやReplicaSetを作って使用するのは推奨されていません。
例えコンテナ一個だけでも、できるだけDeploymentを作成した方がいいでしょう。