Jetson NanoでK3sクラスター（Deployment編）
前回に引き続き、Jetson Nanoモジュールを搭載したSeeed製 reComputer J1020を使用してK3sクラスターで遊んでいきます。今回はDeploymentを作成して複数のPodを統合管理する方法についてです。
前回記事: Jetson NanoでK3sクラスター（構築編）
Deploymentとは
例によってDeploymentの特徴についてまとめてみたいと思います。正確な詳細に関しては公式ドキュメントを参照してください。
- Podの管理: 複数のPodレプリカを管理し、それらのライフサイクルを制御します
- スケーリング: Podは単独でスケーリングできません。Deploymentはレプリカ数を指定することでPodのスケーリングを実現します
- アップデート: Podを直接アップデートすることは出来ません。Deploymentを更新すると新しいPodが作成され古いPodが段階的に置き換えられます（ローリングアップデート）。また、Deploymentのロールバックも可能です
- 障害耐性: Podが異常終了した場合、Deploymentは自動的に新しいPodを作成し、定義されたレプリカ数を維持しようとします
- 宣言的管理: 目的の状態を定義することでKubernetesは自動的にその状態に遷移するために必要な操作を実行します（IaCにかなり近い）
- ロードバランシング: DeploymentはPodのセットを管理し、それらの間でトラフィックを分散することで負荷分散を実現します
Deploymentの作成
さて、早速Deploymentを作成してみましょう。
実験用のコンテナイメージを作成
今回は単にCPU使用率を80%まで上げるだけのコンテナを作成します。Dockerfileは以下の通りです。ビルドして適当なレジストリにpushしておきます。
FROM ubuntu:22.04
RUN apt update -y && apt install -y stress-ng
CMD ["stress-ng", "-c", "1", "-l", "80"]
Deploymentのマニフェストファイルを作成
次にDeploymentのマニフェストファイルを作成します。以下の内容をstress_cpu_deployment.yamlとして保存します。今回はreplicas: 4としてDeploymentが2つのPodを維持するように設定します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: stress-cpu-deployment
spec:
replicas: 4
selector:
matchLabels:
app: stress-cpu
template:
metadata:
labels:
app: stress-cpu
spec:
restartPolicy: Always
containers:
- name: stress-cpu
image: tskawada/k3s-test:stress80
imagePullPolicy: Always
Deploymentを適用
マニフェストファイルを適用しましょう。
sudo k3s kubeclt apply -f stress_cpu_deployment.yaml
Podの状態を確認するとstress-cpu80-deployment-*という名前のPodが4つ作成されていることが確認できます。
sudo k3s kubectl get deployments && sudo k3s kubeclt get pods
> NAME READY UP-TO-DATE AVAILABLE AGE
> stress-cpu-deployment 4/4 4 4 9s
>
> NAME READY STATUS RESTARTS AGE
> stress-cpu-deployment-586d6947db-klj46 1/1 Running 0 9s
> stress-cpu-deployment-586d6947db-5gvmr 1/1 Running 0 9s
> stress-cpu-deployment-586d6947db-qncvl 1/1 Running 0 9s
> stress-cpu-deployment-586d6947db-z56g6 1/1 Running 0 9s
jtopも観てみましょう。Podが正しく動いていそうですね（左上Node-1、右上Node-2、左下Node-3）。
Podを削除してみる
4つあるPodのうち1つを削除してみましょう。DeploymentはPodの数を維持しようとするため、削除されたPodが自動的に再作成されます。
sudo k3s kubectl delete pod stress-cpu-deployment-586d6947db-klj46
stress-cpu-deployment-586d6947db-bs8dnが新たに作成されていますね。
sudo k3s kubectl get pods
> NAME READY STATUS RESTARTS AGE
> stress-cpu-deployment-586d6947db-5gvmr 1/1 Running 0 4m10s
> stress-cpu-deployment-586d6947db-qncvl 1/1 Running 0 4m10s
> stress-cpu-deployment-586d6947db-z56g6 1/1 Running 0 4m10s
> stress-cpu-deployment-586d6947db-bs8dn 1/1 Running 0 8s
ローリングアップデートを試してみる
KubernetesではDeploymentが自動的にローリングアップデートの機能を提供します。マニフェストファイルに特別な改変は必要ありません。動作をカスタマイズしたい場合はspecセクションにstrategyフィールドを追加してrollingUpdateの設定を指定できます。
ここでは例としてDockerイメージの更新をkubectl set imageコマンドで行います。事前に新しいイメージをビルドしてプッシュしておきましょう。今回は新たなイメージとしてtskawada/k3s-test:stress20を使用します。
sudo kubectl set image deployment/stress-cpu-deployment stress-cpu=tskawada/k3s-test:stress20
新しいPodが作成され、古いPodが段階的に置き換えられていく様子が確認できます。
sudo k3s kubectl get deployments && sudo k3s kubectl get pods
> NAME READY UP-TO-DATE AVAILABLE AGE
> stress-cpu-deployment 3/4 4 3 10m
>
> NAME READY STATUS RESTARTS AGE
> stress-cpu-deployment-586d6947db-5gvmr 1/1 Running 0 10m
> stress-cpu-deployment-f4cbd4f44-jt6rq 1/1 Running 0 5s
> stress-cpu-deployment-f4cbd4f44-5j4lz 1/1 Running 0 5s
> stress-cpu-deployment-f4cbd4f44-tlzbw 0/1 ContainerCreating 0 1s
> stress-cpu-deployment-f4cbd4f44-jx755 0/1 ContainerCreating 0 1s
> stress-cpu-deployment-586d6947db-qncvl 0/1 Terminating 0 10m
> stress-cpu-deployment-586d6947db-bs8dn 0/1 Terminating 0 6m16s
まとめ
今回はDeploymentを作成して複数のPodを統合的に管理する方法について扱いました。DeploymentはPodのスケーリングやアップデート、障害耐性などを提供するKubernetesの重要なリソースです。次回はServiceについて紹介した後、実際のアプリケーション構築を通してK3sクラスターの運用方法について考えていきたいと思います。
Discussion