Docker や Podman を使っていると、コンテナは stop して、必要になったら start するものだと考えがちです。しかし Kubernetes では、Docker / Podman と同じ意味での「停止して残しておく」「あとで同じものを起動する」という感覚はあまり合いません。
Kubernetes はコンテナ単体を手元で起動停止する道具ではなく、宣言した望ましい状態を維持するための仕組みです。この違いを理解しないと、データ永続化や障害時の挙動を誤解しやすくなります。
Docker / Podman の stop/start との違い
Docker や Podman では、コンテナを停止しても削除しない限りコンテナの writable layer は残ります。そのため、検証や一時利用では、ボリュームを明示的に用意しなくても、停止後に同じコンテナを再開できるように見えます。
| 観点 | Docker / Podman | Kubernetes |
|---|---|---|
| 操作対象 | コンテナ単体 | Pod、Deployment、StatefulSet などのリソース |
| 停止の感覚 | stop / start で同じコンテナを再利用しやすい | Pod は消され、必要なら新しい Pod として作られる |
| 状態管理 | ローカルコンテナの writable layer に残ることがある | Pod の一時領域は Pod ライフサイクルに依存する |
| 運用思想 | 手元のコンテナを操作する | 望ましい状態を宣言し、制御ループが維持する |
Kubernetes は望ましい状態を維持する
Kubernetes では、Deployment や StatefulSet などに「どの Pod を、いくつ、どの設定で動かしたいか」を宣言します。Kubernetes はその desired state と実際の状態を比較し、差があれば近づけようとします。
たとえば Deployment の replicas が 1 なら、Kubernetes は Pod が 1 個動いている状態を維持しようとします。Pod を手動で削除しても、Deployment が残っていれば新しい Pod が作られます。
kubectl get deploy
kubectl get pod
# Pod を消しても Deployment が残っていれば再作成される
kubectl delete pod POD_NAME
kubectl get podこれは Docker / Podman の docker stop や podman stop と同じ操作感ではありません。Kubernetes では、動かしたい状態を保つことが中心です。
停止したい場合は replicas を 0 にする
Kubernetes でアプリケーションを止めたい場合、Pod を直接止めるのではなく、Deployment などの replicas を 0 にするのが基本的な考え方です。
kubectl scale deployment my-app --replicas=0
# 再開する場合
kubectl scale deployment my-app --replicas=1この操作は「同じコンテナを停止して再開する」というより、「必要な Pod 数を 0 にする」「必要な Pod 数を 1 に戻す」という意味です。再開時には新しい Pod が作られる可能性があり、Pod 内の一時データが残ることは期待できません。
Pod 内のデータは永続化されない前提で考える
Kubernetes の Pod は、作られ、動き、消えるものです。Pod の中に書き込んだデータは、Pod の再作成やノード移動で失われる前提で考える必要があります。
そのため、データを保持したい場合は、PersistentVolume / PersistentVolumeClaim、外部データベース、オブジェクトストレージなど、Pod のライフサイクルと独立した保存先を用意します。
- アプリケーションの設定は ConfigMap / Secret に分ける
- DB データは Pod 内ではなく永続ボリュームや外部 DB に置く
- アップロードファイルは PVC やオブジェクトストレージに置く
- ログは Pod 内にためず、ログ基盤へ送る
- Pod の writable layer を永続データ置き場として扱わない
emptyDir と PersistentVolume の違い
Kubernetes には emptyDir のような一時ボリュームもあります。これはコンテナ再起動では残る場合がありますが、Pod が削除されると失われます。永続データを置く場所ではありません。
| 種類 | ライフサイクル | 用途 |
|---|---|---|
| container filesystem | コンテナに依存 | 一時的な書き込み。永続データには向かない |
| emptyDir | Pod に依存 | 同じ Pod 内の一時作業領域 |
| PersistentVolume / PVC | Pod とは独立 | DB、アップロードファイル、永続データ |
| 外部 DB / Object Storage | Kubernetes 外部または別管理 | 状態をアプリケーション Pod から分離する |
状態を持つアプリケーションは設計が必要
Kubernetes で状態を持つアプリケーションを動かす場合、単に Deployment に入れるだけでは不十分です。DB、ファイル、セッション、キャッシュ、バックアップ、リストアまで含めて設計する必要があります。
たとえば WordPress であれば、WordPress 本体の Pod、アップロードファイル、テーマ、プラグイン、MariaDB、Redis、キャッシュの責務を分ける必要があります。Pod を止めて再開すれば元通り、という発想ではなく、状態をどこに置くかを最初に決めるべきです。
まとめ
Docker / Podman では、コンテナを stop/start して同じコンテナを再利用する感覚があります。しかし Kubernetes では、Pod は一時的な実行単位であり、Deployment や StatefulSet が望ましい状態を維持します。
そのため、Kubernetes では「コンテナを止めて再開する」より、「必要な replicas を変更する」「Pod は再作成されるものとして扱う」「データは Pod の外に永続化する」と考える方が自然です。
Kubernetes を Docker / Podman の延長として見ると、データ永続化や停止・再開の感覚でつまずきます。Kubernetes はコンテナ操作ツールではなく、アプリケーションの望ましい状態を維持するための基盤として見るべきです。
書籍
Kubernetes完全ガイド 第2版
Kubernetes の仕組み、リソース、ネットワーク、運用観点を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
参考
- Kubernetes Documentation – Workloads
- Kubernetes Documentation – Pod Lifecycle
- Kubernetes Documentation – Persistent Volumes
- Kubernetes Documentation – Managing Workloads
Related posts:
Docker と Podman はどっちを使うべき？用途別に整理する
Ubuntu 22.04 Kubernetes 管理ツールのインストール – kubectl / Helm / calicoctl を整理する
Kubernetes MetalLB の導入
Kubernetes Harbor の導入 – Helm でコンテナレジストリを構築する
Kubernetes MetalLB導入 Helm版
Kubernetes クラスタの初期化 – kubeadm reset の基本
Kubernetes で systemd を実行可能な CentOS コンテナを動かす
Kubernetes Nginx コンテナと Service LoadBalancer
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
Kubernetes で送信元アドレスが変わる問題 – externalTrafficPolicy、hostNetwork、BGP 経路広告で考える
Kubernetes Calico eBPF の設計メモ – kube-proxy 代替、DualStack、高可用性をどう見るか
Kubernetes kubeconfig の管理