スケーリングのための Deployment

はじめに

これまでの実験では、単一の Pod を作成しました。Pod は基本的な構成要素ですが、手作業で管理するのは大変です。Pod が停止した場合は、手動で再起動しなければなりません。Pod の数を増やしたい場合も、手動で追加の Pod を作成する必要があります。

そこで登場するのが Deployment です。

Deployment は、ReplicaSet と Pod を代わりに管理してくれる、より上位のコントローラーです。必要なレプリカ数と使用する Pod テンプレートを宣言すると、Kubernetes は実際の状態がその宣言どおりになるように維持します。

ここで重要なのは、個々の Pod を管理することから、繰り返し実行できるワークロードを管理することへの転換です。単一の Pod は 1 つのインスタンスにすぎないため、障害に弱い存在です。Deployment では、Pod を作成するためのパターンと、存在すべき Pod の目標数を定義します。このパターンによって、スケーリングとセルフヒーリングが可能になります。

この実験では、次のことを学びます。

明確な目標（3 レプリカ）を持つ厳格な Manager（Deployment）を作成する。
Manager がワーカー（Pod）を作成する様子を確認する。
ワーカーを 1 つ「停止」させ、Manager の反応（セルフヒーリング）を確認する。
Manager にさらにワーカーを作成させる（スケーリング）。

Deployment の YAML を作成する

このステップでは、Manager の作業指示書を作成します。これは、実行するイメージと必要なコピー数（レプリカ数）を定義する YAML ファイルです。

通常の Pod マニフェストと比べて、構造が追加されていることに注目してください。Deployment には selector と template が含まれます。selector は、どの Pod がこの Deployment に属するかを Kubernetes に伝えます。template は、新しい Pod の作成方法を定義します。この 2 つの設定は一致していなければなりません。一致しない場合、Deployment は意図した Pod を正しく管理できません。

まず、プロジェクトディレクトリにいることを確認します。

cd ~/project

nano を使用して、deployment.yaml という名前の新しいファイルを作成します。

nano deployment.yaml

次の設定をファイルに貼り付けます。replicas: 3 の行に注意してください。この行でチームの人数を定義します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

保存するには、Ctrl+X、Y、Enter の順に押します。

このファイルは Kubernetes に次の内容を指示します。「nginx-deployment という名前の Deployment を作成する。nginx:1.14.2 イメージを実行する Pod を常に 3 個維持する。これらの Pod を探すときは、app: nginx というラベルが付いた Pod を対象にする。」

適用して確認する

作業指示書を作成できたので、Manager を採用しましょう。設定をクラスターに適用します。

Deployment を作成すると、Kubernetes は通常、内部で ReplicaSet という別のオブジェクトも作成します。ReplicaSet は、要求された数の Pod を稼働させ続ける役割を直接担うコンポーネントです。現時点では、初心者が ReplicaSet を直接管理する必要はありません。ただし、コマンドの出力で ReplicaSet をよく見かけるため、存在を知っておくと役立ちます。

kubectl apply -f deployment.yaml

Kubernetes は次のメッセージを表示して、作成を確認します。deployment.apps/nginx-deployment created

Deployment（Manager）はすぐに 3 個の Pod の作成を開始します。Pod をすぐに確認するには、次のコマンドを実行します。

kubectl get pods

名前がすべて nginx-deployment- で始まる、異なる Pod が 3 個表示されます。

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-66b6c48dd5-8j64w   1/1     Running   0          5s
nginx-deployment-66b6c48dd5-d95l2   1/1     Running   0          5s
nginx-deployment-66b6c48dd5-lzr5w   1/1     Running   0          5s

Deployment 自体の状態も確認できます。

kubectl get deployments

READY 3/3 と表示されれば、要求した 3 個のレプリカがすべて起動して稼働していることを確認できます。

セルフヒーリングをテストする

Kubernetes の最も強力な機能の 1 つが セルフヒーリング（Self-Healing） です。Deployment は、実際に存在する Pod 数が常に目標数（3 個）と一致するように維持します。Pod が 1 個なくなると、すぐに置き換えます。

これは、Kubernetes が実際の状態と目標状態を常に照合しているために機能します。Pod を 1 個削除しても、Deployment に保存されているレプリカの目標数は変わりません。そのため、システムは削除を状態のずれとして認識し、代わりの Pod を作成します。

Pod を 1 個手動で削除して、この動作をテストします。

まず、Pod の一覧をもう一度表示します。

kubectl get pods

Pod の いずれか 1 個 の完全な名前をコピーします（例：nginx-deployment-66b6c48dd5-8j64w）。

次に、その Pod を削除します。

kubectl delete pod <paste-pod-name-here>

Kubernetes は Pod が削除されたことを表示します。続けて、もう一度 kubectl get pods を実行します。

kubectl get pods

次のような変化を確認できます。

古い Pod が終了処理中になる（または表示されなくなる）。
名前が異なり、Age が非常に短い（例：2 秒）新しい Pod がすでに表示される。

Deployment はワーカーが 1 個不足したことを検知し、チームの人数を 3 個に保つため、すぐに新しいワーカーを作成しました。これにより、個々のサーバーやコンテナに障害が発生しても、アプリケーションをオンラインのまま維持できます。

スケールアップする

Web サイトの人気が高まったと想像してください。Web サーバー 3 台では足りず、5 台必要になりました。新しいファイルを手動で作成したり、急いで Pod を作成したりする必要があるでしょうか。

Deployment のスケーリングでは、現在稼働しているプロセスだけでなく、宣言された目標数を変更します。そのため、新しいサイズは一度の手動操作が終わった後も維持されます。コントローラーは、再度変更するまで、更新されたレプリカ数を正しい状態として扱い続けます。

いいえ。Manager に人数を増やすよう伝えるだけです。

kubectl scale コマンドを使用すると、稼働中にレプリカ数を変更できます。

レプリカ数を 3 から 5 に変更します。

kubectl scale deployment/nginx-deployment --replicas=5

次に、変更を確認します。

kubectl get pods

5 個の Pod が稼働していることを確認できます。新しい要求を満たすために、2 個の Pod が追加で起動しています。

スケールダウンすることもできます。トラフィックが減った場合は、Pod 数を減らしてリソースを節約できます。

kubectl scale deployment/nginx-deployment --replicas=2

もう一度 kubectl get pods を実行すると、Kubernetes が余分な Pod を終了させ、最終的に 2 個だけ残ることを確認できます。

このように動的にスケーリングできることが、企業が Kubernetes を好む理由です。

まとめ

この実験では、アプリケーションを稼働させ続けるインテリジェントな Manager である Deployment について学びました。

次の操作を成功させました。

ワーカー Pod 3 個を持つ Deployment を作成した。
Deployment が障害のある Pod を自動的に置き換えること（セルフヒーリング）を確認した。
1 つのコマンドでレプリカ数を増減させた（スケーリング）。

これで、スタンドアロンの Pod を作成することがほとんどない理由を理解できました。Deployment は信頼性と柔軟性を提供し、スケジューリングや再起動といった複雑な作業を代わりに管理してくれます。