はじめに
Kubernetes は強力なコンテナオーケストレーションツールです。しかし「使っているが、正直 ECS でよかったのでは」と感じている現場は少なくないと思います。
私自身、Kubernetes を使っているシステムに携わっていますが、Kubernetes 固有の複雑さだけを引き受けて、その恩恵を十分に受けられていないと感じることがあります。
この記事では、Kubernetes を導入したにもかかわらず恩恵を受けにくくなっているパターンを整理します。「うちも Kubernetes を使うべきか」「今の使い方で大丈夫か」を考える材料として使ってください。
Kubernetes を使うことで増えるもの
Kubernetes を導入すると、次のものが新たに必要になります。
- kubectl の使い方の習得
- マニフェスト（YAML ファイル）の管理
- Node・Pod・Deployment・Service・Ingress などの概念の理解
- クラスターのバージョンアップ運用
- ネットワーク・ストレージ・RBAC などの設定
ECS や App Runner と比べると、同じことをするのに必要な知識量と設定量が格段に多くなります。この複雑さに見合った恩恵を受けられているかどうかが、Kubernetes の採用を評価する基準になります。
Kubernetes の恩恵を受けられていないパターン
スケールを使っていない
Kubernetes の大きな強みの一つは、負荷に応じて Pod 数を自動で増減できることです。HPA（Horizontal Pod Autoscaler）と、その前提となるメトリクス取得の仕組みを整えておけば、CPU 使用率などに応じて Pod 数を自動で増減できます。
しかし実際には、Pod 数を固定したまま運用しているケースがあります。この状態では、Kubernetes のスケール機能を一切使えていません。ECS Fargate でも同等のことができます。
宣言的デプロイを使っていない
Kubernetes の設計思想の一つは「あるべき状態を宣言し、その状態を維持させる」ことです。ArgoCD や Flux などの GitOps ツールと組み合わせると、Git にマニフェストをプッシュするだけでデプロイが走り、本番の状態が常に Git と一致するように管理できます。
この仕組みを使わず、手元から kubectl を叩いてデプロイしている場合、Kubernetes の管理コストだけが増えてデプロイの信頼性は上がりません。CI/CD と組み合わせて初めて、Kubernetes のデプロイ管理の強みが活きます。
リソース制御の設定をしていない
Kubernetes は Pod 単位で CPU・メモリの要求値と上限値を細かく設定できます。
resources:
requests:
cpu: "256m"
memory: "512Mi"
limits:
cpu: "1000m"
memory: "1Gi"
この設定をしていないと、特定の Pod がリソースを使い過ぎてほかの Pod に影響したり、Node のリソースを無駄に余らせたりします。Kubernetes を使うメリットの一つであるリソース効率化が機能しません。
Namespace で環境を分けていない
Kubernetes は Namespace を使って、同じクラスター上で開発・QA・本番などの環境を論理的に分けられます。適切に分離することで、テスト用の変更がほかの環境に影響するリスクを減らせます。
ただし Namespace はあくまで同一クラスター内の論理分離です。本番と非本番を強く分けたい場合は、別クラスターや別アカウントで分離する設計もあります。
Namespace を使わずにすべてを同じ空間で管理していると、Kubernetes の論理分離の仕組みを活かせていません。
Kubernetes が本来できること
Kubernetes の恩恵を受けるには、次のような使い方が必要です。
| 機能 | 使い方 |
|---|---|
| 自動スケール | HPA で負荷に応じて Pod 数を増減 |
| 宣言的デプロイ | ArgoCD・Flux などで Git の状態をそのまま本番に反映 |
| ロールバック |
kubectl rollout undo で直前のバージョンに即座に戻す |
| リソース制御 | Pod 単位で CPU・メモリの上限を指定してリソースを最適化 |
| 環境分離 | Namespace などで環境を論理的に分けて管理 |
これらを使わずに Kubernetes を運用しているなら、ECS や App Runner の方がシンプルで運用コストが低い可能性があります。
まとめ
Kubernetes は使いこなすと強力ですが、導入しただけでは恩恵を受けられません。
次の状態に複数当てはまる場合、Kubernetes の複雑さだけを引き受けている可能性があります。
- Pod 数を固定したままスケールを使っていない
- kubectl を手元から叩くデプロイで CI/CD と連携していない
- リソースの requests・limits を設定していない
- Namespace で環境を分けていない
私自身もこうした状況に近い現場を経験しており、「この規模なら ECS で十分だったのでは」と感じることがあります。ツールの選定と運用の設計は別物です。Kubernetes を使うなら、その強みを活かす運用設計が必要です。
ECS と EKS・Kubernetes の概念的な違いについては「ECS と EKS の違いを Kubernetes から整理する」で整理しています。