[備忘]非エンジニアのためのKubernetes入門：製品トラブル時に理解しておくべき基礎知識

Posted at 2026-01-14

※本記事は学習メモをもとに、AIの補助を活用して執筆しています。

この記事でわかること

この記事を読むことで、以下の内容が理解できるようになります。

✅ Kubernetesの基本概念

Kubernetesとは何か、なぜ必要なのか
「港と船」の例えで理解する構成要素
Pod、Deployment、Serviceなど主要な用語の意味

✅ DockerとKubernetesの違い

それぞれの役割と関係性
どのような場面で使い分けるか
実際のユースケース

✅ Kubernetesがもたらす価値

障害時の自動復旧の仕組み
手動管理との具体的な比較
導入による業務改善効果

✅ 製品不具合時の対応方法

非エンジニアができる初動対応
エンジニアへの適切な情報共有方法
よくあるエラーパターンと対処法

✅ 日常的なモニタリングのポイント

定期的に確認すべき項目
異常のサインの見分け方
エスカレーションの判断基準

対象読者: 自社製品でKubernetesを使用しているが、技術的な詳細は分からない方、製品トラブル時に状況把握や初動対応を行う必要がある非エンジニアの方

はじめに

自社製品でKubernetesを使用している場合、製品不具合が発生した際に非エンジニアでもある程度の状況把握ができることは非常に重要です。
本記事では、
Kubernetesの基本概念からトラブル時の対応まで、非エンジニアの方でも理解できるように解説します。

1. Kubernetesとは何か？（非エンジニア向けに解説）

1-1. 一言で表すと

Kubernetes（クーベネティス、通称k8s）は、「コンテナという小さなアプリケーションの箱を、たくさん管理してくれる自動化ツール」。

名前の由来はギリシャ語で「舵取り」を意味し、ロゴが船の舵輪になっているのもこの理由からきている。Kubernetesの"K"と"s"の間に8文字あることから「k8s」と略される。

1-2. なぜ必要なのか

例えば、あなたの会社で運営しているWebサービスがあるとします。このサービスは複数の機能（ログイン機能、商品検索機能、決済機能など）で構成されている。

従来の課題

サーバーがダウンしたら、誰かが手動で再起動する必要がある
アクセスが急増した時、手動でサーバーを増やす必要がある
どのサーバーで何が動いているか管理が複雑になる
システム更新時にサービスを一時停止する必要がある

Kubernetesが解決すること

サーバーがダウンしたら自動的に再起動してくれる
アクセスが増えたら自動的にサーバーを増やす（スケーリング）
複雑な管理を自動化してくれる
サービスを止めずに更新できる（ローリングアップデート）

2. Kubernetesの仕組みと構成

2-1. 港と船に例えると分かりやすい

Kubernetesを理解するには、港湾システムに例えるとイメージしやすい。

Kubernetesの用語	港の例え	説明
クラスター	港全体	Kubernetesが管理する全体のシステム
ノード	埠頭（バース）	実際にアプリケーションが動く場所（サーバー）
Pod（ポッド）	コンテナ船	アプリケーションが入っている最小単位
Deployment	船舶管理会社	「常に○隻の船を配備する」という管理役
Service（サービス）	固定埠頭番号	船が入れ替わっても同じ場所でアクセスできる仕組み
kubectl	港湾管制端末	管理者が命令を出すツール

2-2. 基本的な構成要素

Kubernetesは大きく2つの部分で構成されている。

① Control Plane（コントロールプレーン）：司令塔

クラスター全体を管理する「港湾管制センター」のような存在。

どのノードでPodを動かすか決定する
システム全体の状態を監視する
問題が起きたら自動修復する

② Worker Node（ワーカーノード）：作業現場

実際にアプリケーション（Pod）が動作する「埠頭」のような存在。

Control Planeからの指示を受けてPodを実行する
複数のPodを同時に動かすことができる

2-3. 動作の流れ

【ユーザーのアクセスの流れ】

ユーザーがアプリにアクセス
↓
Ingress（入口管理）がリクエストを受け取る
↓
Service（案内係）が適切なPodに振り分ける
↓
Pod（アプリ本体）が処理してレスポンスを返す
↓
ユーザーに結果が表示される

【裏側で常に動いている仕組み】

Deployment: 「Podは常に3個動いている状態」を維持
もしPodが1個落ちたら → 自動的に新しいPodを起動
アクセスが増えたら → 自動的にPodを増やす

3. DockerとKubernetesの違い

3-1. Dockerとは

Dockerは「コンテナを作るツール」。アプリケーションとその実行環境を1つの箱（コンテナ）にまとめて、どこでも同じように動かせるようになる。

例え: お弁当箱を作る道具

3-2. Kubernetesとは

Kubernetesは「大量のコンテナを管理・運用するツール」。Dockerで作ったコンテナを、たくさん動かして管理する。

例え: お弁当屋さん全体の経営管理システム

3-3. 関係性

項目	Docker	Kubernetes
役割	コンテナを作る・動かす	大量のコンテナを管理する
対象	単体のコンテナ	複数のコンテナの集合
スケール	小規模（数個のコンテナ）	大規模（数百〜数千のコンテナ）
自動化	基本的に手動	高度な自動化

ポイント: DockerとKubernetesは対立するものではなく、Dockerで作ったコンテナをKubernetesで管理するという関係。

3-4. どのようなユースケースで使うか

Dockerが適しているケース

開発環境の構築
小規模なアプリケーション（1〜5個程度のコンテナ）
個人プロジェクトや検証環境
チーム内での環境統一

Kubernetesが必要なケース

本番環境での大規模運用（10個以上のコンテナ）
高い可用性が求められるサービス（24時間365日稼働）
トラフィックの変動が激しいサービス
マイクロサービスアーキテクチャの採用
複数のサーバーでの分散処理

判断基準: 「常に誰かが監視していないと不安」「手動での管理が限界」と感じたらKubernetesの導入を検討すべきタイミング。

4. Kubernetesがない世界ではどうなるか

4-1. 深夜2時のサーバーダウン

Kubernetesがない場合

【午前2時】
サーバーA: ダウン！
      ↓
監視システムがアラートを発信
      ↓
担当者の携帯が鳴る（起こされる）
      ↓
担当者がパソコンを開いてログイン
      ↓
手動でサーバーを再起動
      ↓
【午前3時】ようやく復旧

→ この間、ユーザーはサービスを利用できない
→ 担当者は睡眠を奪われる

Kubernetesがある場合

【午前2時】
Pod（サーバーの一部）: ダウン！
      ↓
Kubernetes: 「あれ？Podが足りない」
      ↓
Kubernetes: 自動的に新しいPodを起動
      ↓
【午前2時01分】復旧完了

→ ユーザーはほとんど影響を受けない
→ 担当者は朝まで熟睡できる

4-2. アクセス急増時の対応

ニュース番組で紹介された！アクセスが10倍に！

Kubernetesがない場合

サーバーの負荷が急上昇
      ↓
レスポンスが遅くなる・エラーが発生
      ↓
緊急対応会議
      ↓
新しいサーバーを手動で追加
      ↓
設定を手動で調整
      ↓
ロードバランサーの設定を変更
      ↓
【2〜3時間後】ようやく対応完了

→ せっかくのビジネスチャンスを逃す

Kubernetesがある場合

サーバーの負荷が急上昇
      ↓
Kubernetes: 「負荷が高いな、Pod増やそう」
      ↓
自動的にPodを3個→10個に増加
      ↓
【5分後】対応完了

→ ビジネスチャンスを逃さない
→ ユーザー体験も維持される

4-3. システム更新時

Kubernetesがない場合

【お知らせ】
サービスが停止するため、お客様にも不便がかかり、エンジニアの工数もかかる。

Kubernetesがある場合

ローリングアップデート実行
      ↓
古いPod: 新しいPodを起動してから停止
      ↓
1個ずつ段階的に入れ替え
      ↓
ユーザーは気づかずに新バージョンを利用

→ サービスを止めずに更新完了

5. 非エンジニアが押さえておくべきポイント

5-1. 重要な概念（最低限これだけは覚えよう）

① Pod（ポッド）

意味: アプリケーションが動いている最小単位
例え: 1台のコンテナ船
非エンジニア向け: 「サービスの1つの機能」と考えてOK

② Deployment（デプロイメント）

意味: Podを管理する仕組み
例え: 「常に3隻の船を配備する」という管理契約
非エンジニア向け: 「何個のPodを動かすか」を決めるもの

③ Service（サービス）

意味: Podへのアクセス窓口
例え: 固定された埠頭番号
非エンジニア向け: 「サービスの入口」「受付カウンター」

④ Node（ノード）

意味: 物理的なサーバーまたは仮想サーバー
例え: 埠頭（バース）
非エンジニア向け: 「Podが動く場所」

⑤ クラスター

意味: Kubernetes全体のシステム
例え: 港全体
非エンジニア向け: 「全部ひっくるめたシステム全体」

5-2. よく聞く用語の意味

用語	意味	覚え方
kubectl	Kubernetesを操作するコマンドツール	「クーベコントロール」と読む、管制端末
namespace	環境を分ける仕組み	「部屋の仕切り」開発環境と本番環境を分ける
ConfigMap	設定情報	「設定ファイルの置き場」
Secret	機密情報（パスワードなど）	「金庫」に入れた秘密情報
Ingress	外部からのアクセスを振り分ける	「入口の案内係」
ヘルスチェック	正常に動いているか確認する仕組み	「健康診断」
ローリングアップデート	サービスを止めずに段階的に更新	「ころころ転がすように少しずつ」

5-3. 状態（ステータス）の見方

Podには様々な状態があり、エンジニアとコミュニケーションする際に役立つ。

ステータス	意味	対応の緊急度
Running	正常に動いている	✅ 問題なし
Pending	起動準備中	⚠️ しばらく待つ、長時間続く場合は要確認
ContainerCreating	コンテナを作成中	⚠️ 起動中、通常は数秒〜数分
CrashLoopBackOff	起動→クラッシュを繰り返している	🚨 要対応：設定エラーやバグの可能性
Error	エラーが発生している	🚨 要対応
ImagePullBackOff	コンテナイメージの取得に失敗	🚨 要対応：イメージ名の間違いなど
Completed	処理が完了した（バッチ処理など）	✅ 正常終了
Terminating	終了処理中	⚠️ 停止作業中

5-4. スケーリングの考え方

水平スケーリング（Horizontal Scaling）

Podの数を増やす
例：3個→10個に増やす
Kubernetesが得意な方法

垂直スケーリング（Vertical Scaling）

1つのPodのリソース（CPUやメモリ）を増やす
例：2コア→4コアに増やす
上限があるため限界がある

Kubernetesでは主に水平スケーリングを使うのが基本。

6. Kubernetesでエラーが起きたときの確認・対応フロー

6-1. 非エンジニアができる初動対応

製品不具合が発生した際、エンジニアに正確な情報を伝えることで、迅速な対応が可能になる。

ステップ1：現象の記録

以下の情報を記録。

【記録すべき情報】
□ いつ発生したか（日時）
□ どの機能で発生したか
□ エラーメッセージの内容（スクリーンショット推奨）
□ 影響範囲（全ユーザー？特定ユーザー？）
□ 再現するか（何度やっても発生する？）

ステップ2：ステータス確認の依頼

エンジニアに以下の確認を依頼。

「以下の状況確認をお願いします」

1. Podの状態確認
   → 「CrashLoopBackOff」や「Error」になっていないか？

2. ログの確認
   → エラーログに異常がないか？

3. リソース状況
   → CPU・メモリが上限に達していないか？

4. 最近の変更
   → デプロイや設定変更があったか？

6-2. エンジニアが使う主要コマンド

非エンジニアの方も、エンジニアが何をしているか理解できると、コミュニケーションがスムーズになる。

① 全体状況の確認

# Podの一覧と状態を確認
kubectl get pods -n [namespace名]

# 出力例：
# NAME                     READY   STATUS    RESTARTS   AGE
# webapp-abc123-xxxxx      1/1     Running   0          5m
# webapp-abc123-yyyyy      0/1     Error     3          2m

見方のポイント

READY: 1/1なら正常、0/1なら起動していない
STATUS: Runningなら正常、それ以外は要確認
RESTARTS: 再起動回数、多いと問題あり

② 詳細情報の確認

# 特定のPodの詳細を確認
kubectl describe pod [Pod名] -n [namespace名]

確認ポイント

Events欄：最近何が起きたか
State欄：現在の状態
Message欄：エラーメッセージ

③ ログの確認

# Podのログを確認
kubectl logs [Pod名] -n [namespace名]

確認ポイント

エラーメッセージ
スタックトレース（エラーの詳細情報）
最後に出力された時刻

④ リソース使用状況の確認

# リソース使用状況を確認
kubectl top pods -n [namespace名]

確認ポイント

CPU使用率
メモリ使用率

7. 日常的なモニタリングのポイント

7-1. 定期的に確認すべき項目

非エンジニアでも、以下の項目を定期的に確認することで、問題の早期発見につながる。

① サービスの応答速度

毎日決まった時間に自社サービスにアクセスしてみる
- 表示が遅くなっていないか
- エラーが出ていないか

② ダッシュボードの確認

監視ツールのダッシュボードを見る（エンジニアに見方を教えてもらう）
- CPU使用率
- メモリ使用率
- エラー率
- レスポンスタイム

③ ログの概要確認

エラーログの件数を確認
- 急激に増えていないか
- 新しいタイプのエラーが出ていないか

7-2. 異常のサイン

以下のような兆候があれば、エンジニアに共有

⚠️ 注意が必要な兆候
- サービスの応答が普段より遅い
- 特定の時間帯に負荷が高い
- ログのエラー件数が増えている
- Pod再起動の頻度が増えている
- ユーザーからの問い合わせが増えている

8. まとめ

8-1. 非エンジニアが理解すべき核心

Kubernetesは「自動管理システム」
- 手動でやっていたことを自動化してくれる
- 24時間365日、休まず監視・管理してくれる
「あるべき状態」を維持する仕組み
- 「Podは常に3個動いている」という状態を勝手に維持
- 1個落ちても自動で復旧
Dockerとは役割が違う
- Docker：コンテナを作る
- Kubernetes：コンテナを管理する
エラー時は情報収集が重要
- いつ、どこで、何が起きたかを記録
- ステータスやログの確認を依頼

8-2. 導入のメリット（再確認）

✅ 障害時の自動復旧 → 深夜対応が不要に
✅ 自動スケーリング → アクセス増加に自動対応
✅ サービス無停止更新 → ユーザー体験が向上
✅ 効率的なリソース活用 → コスト削減
✅ 運用の標準化 → 属人化の解消

8-3. 次のステップ

本記事でKubernetesの基本を理解できたら、次は以下のステップで学習実施

初級レベル

実際のダッシュボードを見てみる
エンジニアにkubectlコマンドの実行を見せてもらう
自社のPod構成を確認する

中級レベル

kubectl get podsコマンドを自分で実行してみる
ログの見方を学ぶ
簡単なトラブルシューティングに挑戦

上級レベル

YAMLファイルの基本を理解する
デプロイの流れを理解する
モニタリングツールの使い方を学ぶ

参考リンク

本記事は以下の記事を参考に作成しました。より詳しく学びたい方はぜひご覧ください。

おわりに

Kubernetesは一見複雑に見え、抵抗感が強いかもですが基本的な概念を理解すれば非エンジニアでも十分にコミュニケーションが取れるようになると思われる。

特に製品不具合が発生した際に、この記事の内容を思い出して、適切な情報収集と報告ができれば、迅速な問題解決に繋がるため、その一歩として学んだ内容をまとめてみました。

この記事が少しでもお役に立てれば嬉しいです。

【補足1】Kubernetes概要図

【補足2】用語集

最後に、本記事で登場した主要な用語を振り返れるようにまとめてみる。

用語	読み方	意味
Kubernetes	クーベネティス	コンテナオーケストレーションツール
k8s	ケーエイツ	Kubernetesの略称
Pod	ポッド	アプリケーションが動く最小単位
Deployment	デプロイメント	Podを管理する仕組み
Service	サービス	Podへのアクセス窓口
Node	ノード	Podが動く物理・仮想サーバー
Cluster	クラスター	Kubernetes全体のシステム
kubectl	クーベコントロール	Kubernetesを操作するツール
namespace	ネームスペース	環境を分離する仕組み
Ingress	イングレス	外部からのアクセスを振り分ける
ConfigMap	コンフィグマップ	設定情報を管理
Secret	シークレット	機密情報を管理
Container	コンテナ	アプリケーションを包む箱
Image	イメージ	コンテナの元になる設計図
Rolling Update	ローリングアップデート	サービスを止めずに更新
Scaling	スケーリング	サーバー数を増減させる
Health Check	ヘルスチェック	正常稼働の確認

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up