Kubernetesとは？仕組み・主要構成・使うべき条件 | Guance

Kubernetesとは、コンテナ化されたワークロードとサービスを宣言的に管理し、デプロイ、スケーリング、障害が起きたときの状態調整を自動化する、ポータブルで拡張可能なオープンソース基盤です。日本語ではクーバネティス、略称ではK8sとも表記します。

できるのは、「コンテナを3つ動かす」といった望ましい状態を記述し、現在の状態との差を継続的に調整することです。一方で、ソースコードのビルド、CI/CDの設計、アプリ内部の不具合修正、完成した監視・ログ分析・アラート基盤までをKubernetesが一式で提供するわけではありません。

本稿はオブザーバビリティプラットフォームを提供する Guance が発行しています。Kubernetesの定義と仕組みはKubernetes / CNCFの公式資料に基づき、Guanceの製品に関する説明は自社の公開資料として分けて記載します。GuanceがKubernetesより優れているという比較、導入効果、コスト削減、障害復旧時間は主張しません。

先に押さえる5つの要点

Kubernetesの中心は、手順を上から順に実行することではなく、現在の状態を望ましい状態に近づけ続ける制御ループです。
PodはKubernetesで作成・管理できる最小のデプロイ可能な単位で、通常はDeploymentなどのワークロードリソースから管理します。
自己修復は失敗したコンテナの再起動やレプリカの置換を支援しますが、アプリの計算結果やビジネス処理が正しいことまで保証しません。
Dockerはコンテナイメージの作成や実行に関わるツール群、Kubernetesは複数ノード上のコンテナ化ワークロードを管理する基盤です。「KubernetesがDockerを置き換える」と一括りにすると役割を誤ります。
複数サービスの頻繁な変更やスケールを管理する価値が、ネットワーク、ストレージ、セキュリティ、アップグレード、オブザーバビリティを継続運用する複雑さを上回るときに導入を検討します。

Kubernetesとは何か

Kubernetes公式の日本語概要は、Kubernetesを「宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理する」プラットフォームと説明しています。K8sはKとsの間にある8文字を数えた略称です。

関連ガイドAPMとは？仕組み・監視項目・オブザーバビリティとの違いを実務で解説

ここでいう「宣言的」とは、実行する全手順を順番に命令するのではなく、最終的にどの状態であってほしいかを記述することです。例えばDeploymentに「特定のイメージを使うレプリカを3つ」と記述したら、Kubernetesは現在のレプリカ数と比較し、差があれば調整します。

このモデルでは、一度だけ成功したかではなく、期待する状態と現在の状態の差を継続的に見ます。Kubernetes公式資料も、順序付きのワークフローをそのまま実行するだけの「オーケストレーション」とは区別し、望ましい状態を維持する独立した制御プロセスの集合として説明しています。

望ましい状態はどのように保たれるか

Kubernetesオブジェクトの公式説明では、多くのオブジェクトがspecとstatusを持ちます。specは望ましい状態、statusはKubernetesが把握している現在の状態を表します。コントロールプレーンは両者の差を見つけ、望ましい状態に近づけるよう管理します。

概念的には、次のループで考えられます。これはネットワーク上の全呼び出しを順番に示すパケット図ではありません。

宣言：ManifestやAPI経由でspecに望ましい状態を記録する。
保存と判断：API serverがKubernetes APIを提供し、etcdがクラスター情報を保存する。
差分の調整：controllerが期待状態と現在状態の差に反応する。新しいPodにNodeが割り当てられていなければschedulerが配置先を選ぶ。
実行：各NodeのkubeletがPodSpecに記述されたコンテナを実行状態に保つ。
再観測：新しいstatusがAPIを通じて把握され、差が残っていれば調整を続ける。

各コンポーネントの実際の配置はクラスター構成によって異なります。そのため、この5段階は実装トポロジや時系列を固定する説明ではなく、宣言的制御を理解するための概念モデルです。詳細はKubernetes公式のクラスターアーキテクチャで確認できます。

「望ましい状態」と「ビジネス上の正しさ」は同じではない

Kubernetesが一致させるのは、Kubernetes API上で宣言された期待状態と、Kubernetesが観測した現在状態です。これは重要ですが、利用者の目的まで自動的に正しくなるわけではありません。

レイヤー	望ましい状態の例	その状態だけでは証明できないこと
Kubernetesリソース	Deploymentのレプリカ数、イメージ、配置条件が`spec`どおり	そのリクエストが正しい商品価格や決済結果を返すか
ヘルス判定	構成したヘルスチェックに通過する	ヘルスチェックがユーザーに必要な依存先や業務条件を十分に見ているか
Serviceと経路	Serviceの宛先候補とネットワーク経路が存在する	実ユーザーの地域、画面、トランザクションごとの成功率や待ち時間
ビジネス	注文成功率、決済整合性、データ新鮮度などが合意した水準	この目標はKubernetesリソースの`spec`だけでは定義も検証もできない

上表はKubernetes公式の製品仕様ではなく、Guanceの編集上の責任分解です。Kubernetesが「正常」と見ている状態と、ビジネス上の成功を別々に定義すると、Podの置換は成功したのに利用者の5xxが続いている、といった事象を見逃しにくくなります。

主要コンポーネントとオブジェクトの役割

この表は全APIの参照ガイドではなく、宣言が実行状態に反映される道筋を読むための地図です。実装、構築、バージョン固有のフラグは公式Docsで確認してください。

名称	主な役割	障害調査での問い
Control Plane	クラスター全体の判断と状態調整を担う	API要求は受理され、必要なcontroller / schedulerが進んだか
kube-apiserver	Kubernetes APIを外部に提供するフロントエンド	オブジェクトの変更と参照は成立しているか
etcd	Kubernetesのクラスター情報を保存するキーバリューストア	クラスター状態の保存と可用性に問題がないか
kube-controller-manager	レプリカやNodeなどに関する複数の制御ループを実行する	期待状態との差が検知され、調整が進んだか
kube-scheduler	まだ割り当て先のないPodに実行Nodeを選ぶ	リソース要求、ポリシー、配置条件によるスケジューリング失敗がないか
Node / kubelet	ワーカーNodeはPodをホストし、kubeletがPodSpecに記述されたコンテナの実行を保つ	Nodeは利用可能で、対象コンテナは予期せず終了していないか
Pod	1つまたは複数のコンテナと共有リソースをまとめる最小のデプロイ可能単位	Podの状態、再起動、イベント、ログはどう変化したか
Deployment	アプリのレプリカとロールアウトの期待状態を表すワークロードオブジェクト	どの変更から新しいReplicaSet / Podが生成されたか
Service	変化するPod群への安定したアクセス手段を提供する	期待する宛先にトラフィックが届き、準備できていない宛先が混ざっていないか

Podについては、Kubernetes公式Docsが「Kubernetes内で作成・管理できるコンピューティングの最小のデプロイ可能なユニット」と定義しています。単独Podを手作業で増減させるのではなく、複製や更新を管理するDeploymentなどから扱うことが一般的です。

Kubernetesができること、できないこと

Kubernetesが提供するのは、コンテナ化ワークロードを動かすためのビルディングブロックです。他のツールやチームの責任まで消えるわけではありません。

Kubernetesが提供する機構	条件・限界	引き続き必要な責任
サービスディスカバリと負荷分散	ネットワークプラグイン、Service設計、ヘルス判定に依存する	DNS、入口制御、暗号化、ポリシー、依存先の運用を設計する
ロールアウトとロールバック	適切なヘルス判定、容量、互換性が必要	アプリとデータの互換性、変更承認、データロールバックを別途設計する
スケーリング	リソース要求、スケール指標、Node容量の設計に左右される	何を増減させるか、依存先やコストにどう影響するかを検証する
自己修復	再起動ポリシー、controller、ヘルス判定で検出できる状態に対して動く	アプリ内部のバグ、データ破損、不正な業務処理、利用者影響は個別に検出・修正する
宣言的APIと拡張	正しいリソース設計、権限、ポリシー、バージョン管理が必要	ソースのビルド、CI/CD、セキュリティ審査、アップグレードを運用する

Kubernetesの自己修復に関する公式資料は、コンテナの再起動、失敗したレプリカの置換、利用不能になったNodeからの再スケジューリングなどを説明しています。同時に、永続ボリューム自体が利用できない場合は復旧手順が必要になることや、Kubernetesがコンテナを再起動できてもアプリ内部の問題は別途対処が必要だと明記しています。

Kubernetesは従来型の「全部入り」PaaSではありません。公式の「Kubernetesにないもの」は、Kubernetesがソースコードのデプロイやアプリのビルドを行わず、ロギング、モニタリング、アラートの特定ソリューションも指定しないと説明しています。

Docker、VM、マネージドKubernetesとの違い

対象	主に抽象化・管理するもの	Kubernetesとの関係
コンテナイメージ / コンテナ	イメージはアプリと必要な依存関係をまとめ、コンテナはそのイメージを基に動く実行インスタンスになる	Kubernetesが管理するワークロードの実行単位を構成する
Docker	コンテナイメージの作成・配布・実行に関するツールとエコシステム	KubernetesはDockerだけを前提とせず、CRIを通じてcontainerdやCRI-Oなどのランタイムを扱う
仮想マシン（VM）	仮想ハードウェア上に独立したOSを含むマシン環境を作る	KubernetesのNode自体がVM上で動く構成もあり、二者択一ではない
Kubernetes	複数Node上のコンテナ化ワークロードの期待状態と実行状態	イメージのビルドではなく、配置、レプリカ、更新、Serviceなどを管理する
マネージドKubernetes	クラウドプロバイダーがコントロールプレーンの一部または多くを管理する提供形態	アプリ、ワークロード設定、データ、アクセス権、ネットワーク、コスト、観測の責任すべてが自動的にプロバイダーへ移るわけではない

コンテナとVMの技術的な違いはKubernetes公式の歴史的背景、現行のコンテナランタイムはクラスターアーキテクチャで確認できます。マネージドKubernetesの責任分界はサービスごとに異なるため、契約と公式の責任共有モデルを確認してください。

Kubernetesが向いているケース、導入を再考すべきケース

次の表はKubernetes / CNCFの公式採用基準ではなく、Guanceの編集チームが用意した条件式の判断枠組みです。項目数の合計で結論を決めず、「なぜ必要か」と「誰が運用するか」を記録するために使います。

確認する条件	Kubernetesが候補になりやすい状況	より単純な選択肢も比較する状況
ワークロード	複数のデプロイ単位がコンテナ化され、配置・更新・依存関係を継続的に管理したい	低変更の単一アプリで、一つの管理サービスで必要条件を満たせる
変更とスケール	頻繁なリリース、段階的更新、需要変動、複数環境の一貫性を管理したい	トラフィックも変更頻度も低く、自動調整の価値が運用負担に見合わない
チーム	プラットフォームの責任者がいて、権限、ポリシー、バージョン、コストを継続管理できる	導入プロジェクトの後に日常運用を担う人と時間を確保できない
システム責任	ネットワーク、ストレージ、セキュリティ、バックアップ、観測の担当が明確	マネージドを選べばすべてプロバイダーが管理すると想定している
成功条件	導入で解決したい問題と、可用性・変更・コスト・安全性の検証方法がある	「業界で一般的だから」以外の導入目的を説明できない

判断を決める万能なサービス数、リクエスト数、売上規模はありません。マネージドサービスを使うと運用負担を一部移せますが、ワークロード設計とビジネス上の正しさの責任は残ります。単純なPaaSやマネージドコンテナが同じ必要条件を満たすなら、それらも比較対象です。

障害時に、Kubernetesのどこから利用者影響まで追うか

例として、Deploymentを更新した後、一部の利用者リクエストで500系エラーが増えたものの、Podは置き換えられて実行中に見える状況を考えます。これは調査モデルであり、実在顧客の障害、Guanceでの実測結果、Kubernetesの一般的な復旧時間を示すものではありません。

確認順	見る証拠	証明できること	まだ証明できないこと
1. 変更	Deploymentのリビジョン、イメージ、適用時刻	どの宣言変更が調査対象か	変更がエラーの原因であるか
2. 調整	ReplicaSet、Pod、スケジューリング、Nodeのイベント	新しいワークロードがどこでどの状態になったか	アプリ処理が正しいか
3. トラフィック	readinessの判定、EndpointSlice、Serviceの宛先	影響を受けたPodが通信経路の候補になったか	そのPodが特定ユーザーの失敗要求を処理したか
4. アプリ	同じリクエストに結び付くTrace、エラー、ログ、依存先の待ち時間	どのコード経路や依存先で失敗したかという候補	その相関が因果であるか
5. 利用者とビジネス	実リクエスト成功率、レイテンシ、画面エラー、影響を受けた操作	どの利用者体験や取引に影響があるか	必要な修正と復旧が完了したか
6. 検証	ロールバックまたは修正後の同一指標と同一テスト	変更後に技術状態と利用者結果が戻ったか	別の条件で再発しないか

「PodがRunningに見える」と「利用者のトランザクションが成功する」の間を埋めるには、Kubernetesオブジェクトだけでなく、アプリのテレメトリと利用者結果が必要です。ただし、データが同じ時間帯に変化したことだけで因果を確定せず、安全な再現、変更差分、ロールバック後の回復で仮説を検証します。

Kubernetesとオブザーバビリティの責任境界

Kubernetesはロギング、モニタリング、アラートの特定ソリューションを指定しません。運用側は、クラスターやNode、ワークロードの状態だけでなく、アプリのメトリクス、ログ、Trace、デプロイ変更、ユーザー体験をどのように計装、保存、関連付け、通知するかを選びます。

Guanceの日本語Kubernetes Monitoring Solutionは、クラスター、Node、Namespace、ワークロード、Pod、コンテナの状態を、サービス、Trace、ログ、ユーザー影響と関連付けると説明しています。これはGuance公式の製品表明であり、第三者検証や、あらゆるKubernetes環境で同一結果を保証する証拠ではありません。

実装を検討する場合は、Guance Container Integration（英語ドキュメント）で公開されている収集対象と、自社のKubernetesバージョン、コンテナランタイム、権限、ネットワーク、収集ポリシーを照合してください。公開資料だけで特定環境の対応を推定せず、非本番でデータ到着と欠落、タグ、カーディナリティ、遅延、ロールバックを確認する必要があります。

このページの範囲と次に進む先

本稿が担うのは、「Kubernetesとは何か」「どのように望ましい状態を維持するか」「どの条件で導入候補になるか」という学習タスクです。以下のタスクは別のページが担います。

詳細なアーキテクチャとAPI：Kubernetes公式Docsを参照する。この定義ページはコンポーネントリファレンスの代わりにはならない。
構築、権限、収集、設定、バージョン固有の手順：公式Docsと利用中のディストリビューションのDocsを参照する。
Guanceで本番Kubernetesを監視できるかの評価：Guance Kubernetes Monitoring Solutionで商用ソリューションの範囲を確認する。本稿はソリューションの購入判断を代替しない。
Guanceの具体的な収集範囲と設定：Container Integration（英語Docs）で確認する。本稿から設定値やサポートバージョンを推定しない。

Research statusと公開条件

一次資料

日本語版に更新の遅れが明記されている場合は、日本語の用語を尊重しつつ現行の英語版で技術事実を照合します。以下は2026年8月1日に確認した資料です。

Kubernetes公式 — 概要（日本語） / Overview（英語・現行）：定義、主な機構、Kubernetesが指定しない領域。
Kubernetes公式 — クラスターアーキテクチャ：Control Plane、Node、API server、etcd、scheduler、controller、kubeletの役割。
Kubernetes公式 — Kubernetesオブジェクトを理解する / Objects（英語・現行）：spec、status、望ましい状態。
Kubernetes公式 — Pod / Pods（英語・現行）：Podの定義と共有コンテキスト。
Kubernetes公式 — 自己修復機能 / Self-Healing（英語・現行）：再起動、レプリカ置換、ストレージとアプリ内部エラーの限界。
CNCF — Kubernetes project：プロジェクトの管理情報。
Guance — Kubernetes Monitoring Solution（日本語）：Guanceが公開するKubernetes監視と関連分析の製品範囲。
Guance Docs — Container Integration（英語）：公開された収集対象と実装資料。