2024.07.04 aws

Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説

Kubernetes（クバネティス／クーベネティス、略称K8s）とは、多数のコンテナの配置・稼働・復旧・増減を自動で管理するオープンソースの基盤（コンテナオーケストレーションツール）です。コンテナを「作って動かす」のがDockerなら、その大量のコンテナを複数のサーバーにまたがって束ね、望ましい状態を保ち続ける“司令塔”がKubernetesにあたります。この記事では、Kubernetesとは何かという役割から、Dockerとの違い、Pod・クラスタといった仕組み、つまずきやすい読み方・語源、そして学習の始め方までを、専門用語をかみくだいて順に解説します。

まとめ

先に結論です。Kubernetesとは、コンテナ化したアプリのデプロイ・スケーリング・障害復旧・更新を自動化するオープンソースのプラットフォーム（コンテナオーケストレーションツール）です。あらかじめ「アプリのコピーを常に3つ動かす」といった望ましい状態を宣言しておくと、Kubernetesが現状と照らし合わせ、自動でその状態へ近づけ・維持し続けます。

Dockerとは競合ではなく役割分担する補完関係で、コンテナを作るのがDocker、大量のコンテナを複数サーバーで管理するのがKubernetesです。読み方は「クーベネティス／クバネティス」など複数が併存し、略称K8s（ケーエイツ）はKとsの間の8文字に由来します。本体は無料ですが運用負荷が高いため、初心者はGKE・AKS・EKSといったマネージドサービスから始めるのが現実的です。以下、役割・違い・仕組み・読み方・始め方の順に見ていきます。

Kubernetes（クバネティス）とは？コンテナを束ねる「司令塔」

Kubernetesは、Googleが社内で使っていた「Borg」というシステムをもとに開発し、2014年にオープンソースとして公開したソフトウェアです。現在はGoogleの手を離れ、クラウドネイティブ技術を推進する非営利団体CNCF（Cloud Native Computing Foundation）が中立的に開発・運営しています。

役割を理解する前提が「コンテナ」です。コンテナとは、アプリと、それを動かすのに必要なライブラリや設定を一つの箱にまとめ、どの環境でも同じように動かせるようにした軽量な仮想化技術のこと。基礎はコンテナ技術とは何か：仮想化との違いや基本概念を解説で扱っています。この「箱」を大量に、しかも安定して動かす段になって初めてKubernetesが必要になります。

なぜKubernetesが必要になるのか

コンテナが1つや2つなら手作業でも管理できます。しかし本番サービスでは、数十〜数百のコンテナを複数のサーバーにまたがって動かすことになり、次のような作業が一気に煩雑になります。

どのサーバーにどのコンテナを配置するか（空きリソースを見た割り当て）
コンテナやサーバーが落ちたときの検知と再起動・再配置
アクセス急増に合わせたコンテナの増減
停止せずに新バージョンへ入れ替える更新作業

この「大量のコンテナをまとめて面倒みる」仕事を自動化するのがKubernetesの役割です。あらかじめ「望ましい状態」を宣言しておくと、現状と照らし合わせて自動でその状態へ近づけ、維持し続けます。こうした役割のツールを総称してコンテナオーケストレーションと呼び、Kubernetesはその事実上の標準（デファクトスタンダード）になっています。

KubernetesとDockerの違いは？

初心者が最もつまずくのが「KubernetesとDockerは何が違うのか」です。結論から言うと、両者は“どちらか一方を選ぶもの”ではなく、役割が異なり、組み合わせて使う補完関係にあります。

Dockerはコンテナを「作る・動かす」ためのツールで、基本的に1台のサーバー（単一ノード）の上で動きます。一方Kubernetesは、Dockerなどで用意したコンテナを複数サーバー（クラスタ）にまたがって配置・管理するオーケストレーターです。Dockerでアプリを箱詰めし、その大量の箱をKubernetesが束ねて運ぶ、という分担になります。

観点	Docker	Kubernetes
主な役割	コンテナ化・実行	コンテナの運用管理
実行範囲	単一ノード	クラスタ（複数ノード）
得意なこと	環境の再現・配布	自動スケール・自己修復
関係	補完関係（組み合わせて使う）

そのため「Kubernetes対Docker」という対立軸はあまり意味がありません。小規模ならDocker単体やDocker Composeで十分なケースも多く、規模が大きくなった段階でKubernetesの出番になります。Dockerそのものの仕組みはDockerの仕組みを原理から理解する（コンテナ隔離・VMとの違い）で確認できます。

Kubernetesの仕組みとアーキテクチャ（Pod・Node・クラスタ）

Kubernetesを理解するうえで欠かせない用語を、最小限にしぼって整理します。まず押さえたいのは、Kubernetesではコンテナを単体ではなく「Pod（ポッド）」という単位で扱う点です。

用語	役割（ざっくり）
Pod（ポッド）	1つ以上のコンテナをまとめた最小単位
Node（ノード）	Podが動くサーバー（物理/仮想）
Cluster（クラスタ）	複数Nodeの集合体。実行環境全体
Control Plane	クラスタ全体を制御する司令塔
`kubectl`	クラスタを操作するコマンド

Podは、密接に連携する1つ以上のコンテナをひとまとめにした、Kubernetes最小のデプロイ単位です。Pod内のコンテナは同じネットワークやストレージを共有できます。ただしその共有ストレージはPodの寿命で消えるため、Podをまたいでデータを残すにはPV・PVC・StorageClassによる永続化ストレージの設計が要ります。その永続ボリュームをクラスタのリソース定義ごとまとめて退避・復元する手段はVeleroによるKubernetesのバックアップと移行で解説しています。Pod同士やServiceをまたぐ通信の設計はService・Ingress・Pod間通信とCNI選定の実装判断で整理しています。そのPodが実際に動くサーバーがNodeで、Nodeを複数まとめた全体がClusterです。

Control Plane（コントロールプレーン）とNodeの構成

クラスタは、頭脳にあたるControl Planeと、実際にPodを動かすWorker Nodeに分かれます。それぞれの主なコンポーネントは次のとおりです。ここを押さえると「宣言した状態がなぜ自動で保たれるのか」が具体的に見えてきます。

層	コンポーネント	担当
Control Plane	kube-apiserver	全操作の受付口（唯一の入り口）
	etcd	クラスタ状態を保存するデータストア
	kube-scheduler	新しいPodの配置先Nodeを決定
	controller-manager	現状をあるべき状態へ調整し続ける
Node	kubelet	Node上でPodを起動・監視
	kube-proxy	Podへの通信を振り分ける
	コンテナランタイム	コンテナを実際に動かす実体（containerd等）

利用者はkube-apiserverに対して「あるべき状態」を登録し、controller-managerが現状との差分を埋め、kube-schedulerが配置を決め、各Nodeのkubeletがその通りにコンテナを起動します。なお、Nodeでコンテナを動かす実体はcontainerdなどのコンテナランタイムで、Docker専用の連携層（dockershim）はKubernetes 1.24（2022年）で削除済みです。Docker自体でビルドしたイメージは今も問題なく動きます。

宣言的（Declarative）な管理とkubectl

Kubernetesの大きな特徴は「宣言的」な管理方式です。「どう操作するか」を一手ずつ命令するのではなく、設定ファイルに「こういう状態であってほしい」というゴールだけを書きます。たとえば下のようにアプリのコピー数（レプリカ）を3と宣言しておけば、あるコンテナが落ちて2つに減っても自動で1つ起動して3つに戻します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3        # 常に3つ動かしたい、という「あるべき状態」
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.27

このファイルをクラスタへ反映したり状態を確認したりする操作は、コマンドラインツールkubectlで行います（例：kubectl apply -f web.yaml、kubectl get pods）。kubectlと、独自リソースを実装するときのkubebuilderとの使い分けはkubectlとkubebuilderの違いと使い分けで、apiserverが公開するリソース構造はKubernetes APIの仕組み・リソース・CRD拡張で掘り下げています。

Kubernetesでできること（主な機能とメリット）

宣言的な管理を土台に、Kubernetesは運用の手間を大きく減らす機能を備えています。代表的なものは次の4つです。

自動スケーリング：CPU使用率やアクセス量に応じてPod数を自動で増減し、急なトラフィックにも過剰なサーバー費用にも傾かないよう調整する。
自己修復（セルフヒーリング）：コンテナやNodeに障害が起きても、自動で再起動・再配置して稼働を保つ。正常性の判定にはLiveness/Readinessといったコンテナのヘルスチェック（Liveness Probe）を使う。
ローリングアップデート／ロールバック：サービスを止めずに新バージョンへ段階的に更新し、問題があればひとコマンドで前のバージョンへ戻せる。
負荷分散・サービスディスカバリ：複数のPodにリクエストを振り分け、Podが入れ替わっても安定したアクセス先を提供する。振り分け方式の基礎はロードバランサーの仕組み・種類・振り分け方式で解説している。

要するに、Kubernetesの価値は「速さ」や「豊富な機能」そのものではなく、人手で張り付いていた運用作業（配置・復旧・増減・更新）を宣言で自動化し、夜間の障害でも自動で立て直せることにあります。

Kubernetesの使いどころと、あえて使わない判断

こうした強みから、Kubernetesはマイクロサービス（多数の小さなサービスを組み合わせる構成）や、頻繁なリリースを自動化するCI/CDパイプライン、可用性が重視される大規模な本番システムと特に相性がよいといえます。トラフィックの波が大きいサービスや、複数チームが独立してデプロイする組織でも効果が出ます。

一方で、Kubernetesを入れれば良いというものではありません。次のような場合はむしろ過剰で、Docker ComposeやPaaS（Cloud Runなど）のほうが速く安全に運用できます。導入判断では「規模と運用体制に見合うか」を先に問うべきです。

コンテナが数個で、負荷の波もほとんどない小規模アプリ
クラスタを継続的に面倒みる運用担当（SRE）を置けない体制
学習・構築にかける時間より、まず動かして検証したいフェーズ

Kubernetesは機能が豊富なぶん学習コストが高く、宣言ファイルやネットワーク、権限（RBAC）の設計まで含めると習得に時間がかかります。「いま自分の規模に本当に必要か」を見極めてから選ぶことが、遠回りを避ける近道です。

Kubernetesの学習と開発環境の始め方

「Kubernetesの開発を始めたい」「入門したい」という段階では、いきなり本番クラスタを自前構築せず、次の順で触るのが挫折しにくい進め方です。

コンテナとDockerの基礎を先に固める：Kubernetesはコンテナが前提。Dockerでイメージのビルドと実行を一通り体験しておく。
ローカルに小さなクラスタを立てる：minikubeやkind（Kubernetes in Docker）を使えば、自分のPC1台に検証用クラスタを作れる。Pod・Deployment・Serviceをkubectlで作って壊す練習に向く。
マネージドサービスで運用に近い形を試す：本格運用は、構築・アップグレード・監視を肩代わりしてくれるマネージドKubernetesが現実的。代表格はGoogleのGKE、Microsoft AzureのAKS、AWSのEKS。

マネージドの具体像はAKS（Azure Kubernetes Service）とは｜できること・料金・始め方が参考になります。学習に使うバージョンは、非推奨機能でつまずかないようKubernetesの新バージョン・変更点とEOLで最新のサポート状況を確認しておくと安全です。まずローカルのminikube／kindで概念を手を動かして覚え、次にマネージドで運用の感覚をつかむ。kindでクラスタを作り、DeploymentとServiceを適用して壊す手順はk8sをローカルで動かす手順にコマンド付きでまとめています。この順に進むと、非推奨機能や課金でつまずく前に基礎が固まります。

Kubernetesの読み方とK8s・名前の由来

Kubernetesには、公式に「これが正解」と定められた唯一の日本語読みはありません。英語の発音は koo-ber-net-ees（クーバネティス） に近く、共同開発者の一人であるBrendan Burns氏も、開発チームの多くは「koo-ber-net-ees」もしくは略称の「k-eights（ケーエイツ）」と呼ぶと述べています。これを日本語のカタカナに置き換える過程でゆれが生じ、複数の表記が併存しているのが実情です。

表記	主な読み方	備考
Kubernetes	クーベネティス	比較的よく使われる
	クバネティス	カタカナ表記で多い
	クーバネティス	英語発音に近い
K8s	ケーエイツ	略称。最も手軽

略称のK8sは、先頭の「K」と末尾の「s」の間にある8文字（ubernete）を数字の「8」で置き換えたものです。「i18n（internationalization）」や「a11y（accessibility）」と同じ、長い英単語を縮める数字略記（numeronym）の一種です。

名前の語源はギリシャ語のκυβερνήτης（kubernḗtēs）で、「操舵手」「水先案内人（パイロット）」を意味します。英語で「人工頭脳学」を指すcybernetics（サイバネティクス）の語源でもある言葉です。コンテナという“積み荷”を載せた船を安全に導く舵取り役、というイメージが名前に込められており、公式ロゴが船の舵をかたどっているのもこのためです。ちなみにGoogle社内での当初のコードネームは「Project Seven」で、これはスタートレックのキャラクター“セブン・オブ・ナイン”に由来し、ロゴの輪にある7本のスポークにその名残があります。

Kubernetesの歴史とエコシステム・最新動向

Kubernetesは、Googleが十数年かけて運用してきた大規模コンテナ基盤「Borg」の知見をもとに生まれ、2014年の公開後まもなくコンテナ運用の標準として広がりました。2015年に発足したCNCFへ最初のプロジェクトとして移管され、以後はベンダー中立で開発が続いています。

本体だけでなく、周辺のエコシステムが充実しているのもKubernetesの強みです。たとえばRed HatのOpenShiftは、Kubernetesに開発者向けの機能やセキュリティ設定を加えた商用ディストリビューションで、企業導入で広く使われています。ほかにも設定を束ねるHelm、GitOpsを実現するArgo CD、サービス間通信を制御するIstioなど、目的別のツールが揃っています。クラスタへ入るリソースの設定自体にルールを課す領域では、Kyvernoとは？Kubernetesのポリシー適用の仕組みとCEL移行を解説で扱うポリシーエンジンも選択肢になります。

なお、Kubernetes本体はおおむね年3回のペースで新バージョンがリリースされ、機能の追加・非推奨化が活発に進みます。各バージョンには保守期限（EOL）があるため、学習や導入の際は入門知識を土台にしつつ、バージョン依存の仕様や最新機能・サポート期限は必ず公式ドキュメントで確認してください。直近の変更点はKubernetesの新バージョンの新機能・変更点とEOL解説にまとめています。

よくある質問（FAQ）

Kubernetesの読み方は？

「クーベネティス」「クバネティス」「クーバネティス」などと読みます。公式に唯一の読み方は定められていません。略称のK8sは「ケーエイツ」と読みます。

なぜK8sと略すのですか？

「Kubernetes」の先頭Kと末尾sの間に8文字（ubernete）あることから、その8文字を「8」に置き換えてK8sと表記します。長い単語を数字で縮める略記法（numeronym）の一種です。

Pod（ポッド）とは何ですか？

Podは、1つ以上のコンテナをまとめたKubernetes最小のデプロイ単位です。Kubernetesではコンテナを単体ではなくPodという単位で扱い、同じPod内のコンテナはネットワークやストレージを共有できます。そのPodが動くサーバーがNode（ノード）、Nodeを複数まとめた全体がCluster（クラスタ）です。