製品プロフィール

Kubernetes

Google → CNCF / コンテナオーケストレーション

大量のコンテナを自動で配置・復旧・スケールする“司令塔”。宣言的に「あるべき状態」を保ち続ける。

3つの要点
TL;DR
  1. コンテナを自動配置・復旧・スケールする司令塔。
  2. 宣言的にあるべき状態を保つ、事実上の業界標準。
  3. 大規模・マイクロサービス向け。小規模には過剰で学習も重い。

基本情報

仕様と立ち位置

Kubernetes のロゴ
製品・技術の概要Kubernetes大量のコンテナを自動で配置・復旧・スケールする“司令塔”。宣言的に「あるべき状態」を保ち続ける。
種別
コンテナオーケストレーション
提供元
Google → CNCF
ライセンス
オープンソースApache 2.0)
登場
2014年
最大の強み
自動スケール / 自己修復宣言的で再現性が高い
代表的な用途
大規模なコンテナ運用マイクロサービス / マルチクラウド

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. 自動スケール / 自己修復
  2. 宣言的で再現性が高い
  3. クラウド非依存の事実上の標準

事前に確認する条件

考慮すべき点

  1. 学習コストが非常に高い
  2. 運用が複雑(→ マネージドが定番)
  3. 小規模にはオーバースペック

詳しい解説

もっと詳しく

どんなツールか

Kubernetes(K8s)は、多数のコンテナを束ねて運用するための「コンテナオーケストレーション」基盤です。複数サーバーにまたがってコンテナを配置し、その状態を維持し続けます。

「結局なに?」を一言でいえば、コンテナを大規模に動かすための管制塔です。Docker などで作ったコンテナを、本番でまとまった台数まわすときに力を発揮します。

横にスクロール

Kubernetesが宣言をAPI Server経由でetcdへ保存し、controllerとschedulerが調整・配置し、NodeのkubeletがPodを実行してServiceとVolumeを接続する流れ
KubernetesではAPI Serverが唯一の窓口となり、controllerは望ましい状態との差を繰り返し調整し、schedulerは未割当PodのNodeを決めます。kubeletが割当済みPodを実行し、ServiceはReadyな接続先へ通信を導き、VolumeはPodの寿命とデータの寿命を分けます。障害時は同じコンテナの再起動と別Podの作成を区別し、自動復旧しない容量・権限・ストレージ障害を切り分けます。

特徴・仕組み

最大の特徴は宣言的なアプローチと調整ループです。「コンテナを 3 つ動かす」といった“あるべき状態”をマニフェスト(YAML)で定義しておくと、Kubernetes が実際の状態を常にそれへ収束させ続けます。

構成は大きく 2 層に分かれます。

  • コントロールプレーン: 全体の頭脳。API サーバー(唯一の入口)、状態を保存する etcd、配置を決める スケジューラ、あるべき状態へ寄せる各種 コントローラからなる。
  • ノード(ワーカー): 実際にコンテナを動かす側。各ノードの kubelet がコンテナを起動・監視し、kube-proxy が通信を振り分ける。

主な部品は、コンテナの最小単位 Pod、複製数と更新を管理する Deployment、安定した接続先を与える Service、設定・機密の ConfigMap/Secret など。これらを組み合わせて、自動スケール・自己修復・ローリング更新を実現します。

得意・不得意

  • 大規模・マイクロサービス構成の運用に強く、事実上の標準になっている。
  • スケール・障害復旧・無停止更新を自動でこなせる。移植性が高くマルチクラウドでも通用する。
  • 反面、概念が多く学習・運用コストが高い。小規模な用途には過剰になりがち。

Docker との違い

観点DockerKubernetes
役割コンテナを作って動かす多数のコンテナを群として運用
対象規模一台・少数複数ノード・大規模
自動化限定的スケール・自己修復・更新を自動
学習コスト低め高い

Docker が「コンテナを作って動かす」のに対し、Kubernetes は「多数のコンテナを群として面倒みる」役割です。一台で少数のコンテナなら Docker のみのほうが運用は軽く済みます。

使いどころ・注意点

マネージド K8s から始める

自前でコントロールプレーンを運用するのは負担が大きいため、EKS・GKE・AKS などのマネージド Kubernetes から始めると、etcd 運用やアップグレードの手間を軽減できます。監視は Prometheus、パッケージ管理は Helm、宣言運用は GitOps と組み合わせるのが定番です。

総じて Kubernetes は、宣言的な調整ループでコンテナ群を大規模・堅牢に運用する、コンテナ時代の標準オーケストレータです。

実装・運用の視点

Kubernetesを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

大規模なコンテナ運用

比較で見る軸

種別: コンテナオーケストレーション / 提供元: Google → CNCF / ライセンス: オープンソース(Apache 2.0)

導入後に効く点

宣言的で再現性が高い

先に潰すリスク

学習コストが非常に高い

数字・仕様の読み方
種別
コンテナオーケストレーション
提供元
Google → CNCF
ライセンス
オープンソース(Apache 2.0)
登場
2014年

判断チェックリスト

  • 自社の用途が「大規模なコンテナ運用 / マイクロサービス」に近いか確認する。
  • 強みである「自動スケール / 自己修復」が本当に評価軸になるか確認する。
  • 注意点の「学習コストが非常に高い」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

大規模なコンテナ運用マイクロサービスマルチクラウド

向いている用途

こんな用途に向く

大規模なコンテナ運用マイクロサービスマルチクラウド
公式サイト