Kubernetes（k8s）とは？何を解決する仕組みなのかを整理する
- 公開日
- カテゴリ：Kubernetes
- タグ：Kubernetes,学習メモ
Kubernetes（k8s）について、座学から始めてローカル環境で手を動かしながら理解を深めていく。最終目標は、自作の Go API を Kubernetes 上で動かすこと。
この記事では、Kubernetes の使い方に入る前に、そもそも何を解決するための仕組みなのかを整理する。
この記事で整理すること:
- Kubernetes の概要と、必要になった背景
- コンテナオーケストレーションの役割
- Docker と Kubernetes の関係
- 宣言的な管理と Desired State / Current State の考え方
contents
- Kubernetes とは
- なぜ Kubernetes が必要になったのか
- コンテナオーケストレーション
- Docker と Kubernetes の関係
- 宣言的な管理
- Desired State と Current State
- Kubernetes が解決する問題
- Kubernetes が向かない場面
- 用語メモ
- 参考 URL
Kubernetes とは
Kubernetes は、複数のサーバーにまたがって、多数のコンテナを自動で運用するためのプラットフォーム。
- 名前の由来はギリシャ語の「κυβερνήτης（操舵手・パイロット）」。ロゴが船の舵輪なのもこのため
- 日本での一般的な読み方は「クバネティス」
- 「k8s」は、k と s の間に 8 文字（ubernete）あることから来た略称
- Google 社内のクラスタ管理システム Borg の経験をもとに開発され、2014年にオープンソースとして公開。現在の管理団体は CNCF（Cloud Native Computing Foundation）
なぜ Kubernetes が必要になったのか
Docker を使えば、コンテナは次のコマンドで起動できる。
docker run my-api
開発環境ならこれで十分だが、本番環境では次のような要求が出てくる。
- API コンテナの複数起動
- 停止したコンテナの自動復旧
- サーバー停止時の、別サーバーでの再稼働
- サービスを止めないバージョン切り替え
- 負荷に応じたコンテナ数の増減
さらに、マイクロサービス化などでコンテナの数が数十〜数千になると、「どのサーバーに置くか」「落ちたら誰が起動し直すか」「IP が起動のたびに変わるのにどう通信先を見つけるか」といった運用の問題が一気に増える。
デプロイの形は、おおまかに次のように変わってきた。
物理サーバー時代 → 仮想マシン(VM)時代 → コンテナ時代
1台に1アプリ 1台に複数VM 軽量なコンテナを大量に
リソースの無駄 VMごとにOSが重い 起動が速い・可搬性が高い
コンテナによって「動かす」ことは簡単になった。一方で、大量のコンテナを「運用し続ける」ことが新しい課題になった。これを人手やスクリプトで続けるのは現実的ではないため、運用そのものを自動化する仕組みが必要になった、というのが Kubernetes 登場の背景。
コンテナオーケストレーション
Kubernetes のような仕組みは「コンテナオーケストレーション」と呼ばれる。オーケストレーションは「オーケストラの指揮」のことで、たくさんのコンテナを全体として調和するように指揮するというイメージ。
Kubernetes が担う主な仕事は次のとおり。
| 機能 | 内容 |
|---|---|
| スケジューリング | 空きリソースを見て、コンテナを置くサーバーを決める |
| 自己修復 | 落ちたコンテナを作り直し、異常なものを再起動する |
| サービスディスカバリ / 負荷分散 | 変わり続けるコンテナの IP の前に安定した入口を用意する |
| スケーリング | コンテナの数を手動・自動で増減する |
| ローリングアップデート | 少しずつ入れ替えて無停止で更新し、戻すこともできる |
| 設定・機密情報の管理 | アプリ本体と設定を分けて管理する |
Docker と Kubernetes の関係
「Docker と Kubernetes のどちらを使うか」と比べられることがあるが、担当する層が違うので競合関係ではない。
| Docker | Kubernetes | |
|---|---|---|
| 主な役割 | イメージを作り、コンテナを動かす | 大量のコンテナを複数サーバーで運用する |
| 対象範囲 | 基本は1台のホスト | 複数のサーバー（Node）からなるクラスタ |
| 操作の考え方 | 命令的：「これを起動して」 | 宣言的：「この状態にしておいて」 |
| ホストが落ちたら | そのホストのコンテナは止まったまま | 別のサーバーで作り直す |
補足として、次の2点も押さえておく。
Docker にも自動再起動はある
Docker にも --restart=always のような再起動ポリシーがある。ただし、これはそのホストの中だけの話。ホスト自体が落ちたら、そこで動いていたコンテナを別の場所で動かしてくれる存在はいない。Kubernetes はクラスタ全体で状態を守る点が違う。
Kubernetes は Docker Engine を直接は使っていない
Kubernetes は v1.24 で dockershim を削除した。現在は CRI（Container Runtime Interface）という仕組みを通して、containerd や CRI-O といったランタイムでコンテナを動かしている。とはいえ、Docker で作ったイメージは OCI という標準の形式なので、そのまま Kubernetes で動く。「Docker でイメージを作り、Kubernetes で動かす」という関係は今も変わらない。
宣言的な管理
Kubernetes では、リソースを「宣言的」に管理する。まずは、命令的な管理との違いを整理する。
命令的（Imperative） な管理は、手順をひとつずつ指示する。
docker run my-api # 1個目を起動
docker run my-api # 2個目を起動
docker run my-api # 3個目を起動
# 1個落ちた → 人が気づいて、また docker run する
宣言的（Declarative） な管理は、あるべき状態を伝える。
spec:
replicas: 3 # 「常に3個ある状態」にしておいて
宣言的な管理では、「どうやるか」ではなく「どうなっていてほしいか」を書く。そこへ近づけるための手順は Kubernetes が考える。
身近なものに例えると、エアコンの温度設定に近い。「25℃」と設定すれば、暑くなったら冷やし、冷えすぎたら止めることをエアコンが勝手に続けてくれる。「3分間冷房を動かして」と毎回命令する必要はない。
Desired State と Current State
宣言的な管理を支えているのが、Desired State（あるべき状態） と Current State（現在の状態） の2つ。
Kubernetes の中では、次のループがずっと回り続けている。
┌──────────────────────────────┐
↓ │
① 観察: 今の状態(Current)を見る │
↓ │
② 比較: あるべき状態(Desired)との差分 │
↓ │
③ 行動: 差分を埋める(作成/削除など) ─┘
これを調整ループ（Reconciliation Loop）、ループを回す担当をコントローラーと呼ぶ。
たとえば replicas: 3 と宣言した状態で1つが停止すると、次のように動く。
Desired State: Pod × 3
Current State: Pod × 2
↓ 差分を検知して、Kubernetes が1つ作成
Current State: Pod × 3
実際の Kubernetes のリソースも、この2つの状態を分けて持っている。
spec: # Desired State（人間が書く「こうあってほしい」）
replicas: 3
status: # Current State（Kubernetes が書き込む「今こうなっている」）
replicas: 2
人間は spec を書き、Kubernetes が status を観察しながら spec に近づけ続ける、という役割分担になっている。
Kubernetes が解決する問題
最初に挙げた本番環境での要求は、Kubernetes では次のように解決できる。
| 本番環境での要求 | Kubernetes の答え |
|---|---|
| API コンテナを複数起動したい | Deployment の replicas |
| 停止したら自動で復旧したい | 調整ループによる自己修復、Probe |
| サーバー停止時に別サーバーで動かしたい | スケジューラが別の Node に再配置 |
| 無停止でバージョンを切り替えたい | Rolling Update |
| 負荷に応じて Pod を増減したい | Horizontal Pod Autoscaler（HPA） |
どれも、「あるべき状態を宣言し、Kubernetes がそこへ近づけ続ける」という同じ考え方の上に成り立っている。
Kubernetes が向かない場面
公平のために、Kubernetes が「しないこと」「向かない場面」も押さえておく。
- アプリのビルドは対象外：イメージは事前に用意しておくことが前提
- 学習コスト・運用コストの大きさ：小規模なサービスなら Cloud Run や ECS のようなマネージドサービスで十分なことも多く、導入するかどうかの見極めが必要
Kubernetes は「使えば全部解決する」ものではなく、大規模・複数サービス・高可用性が求められる場面に向いた仕組み。
用語メモ
| 用語 | 読み方 | 意味 |
|---|---|---|
| Declarative | デクララティブ | 宣言的 |
| Imperative | インペラティブ | 命令的 |
| Desired State | ディザイアード・ステート | あるべき状態 |
| Current State | カレント・ステート | 現在の状態 |
| Reconciliation Loop | リコンシリエーション・ループ | 調整ループ |
| replicas | レプリカス | 起動しておく Pod の数（会話では「レプリカ数」） |
まとめ
- Kubernetes は、大量のコンテナを複数のサーバーで自動運用するためのプラットフォーム
- コンテナで「動かす」ことが簡単になった結果、「運用し続ける」ことが課題となり、その自動化のために誕生
- Docker とは競合せず、Docker でイメージを作り、Kubernetes で運用するという役割分担
- 特に押さえておきたいのは宣言的な管理。人間が Desired State を宣言し、Kubernetes が Current State をそこへ近づけ続けるという仕組み
この「現在の状態を、宣言された望ましい状態へ近づけ続ける」という考え方を軸に、今後の学習を進めていく。
