kubectl logsとkubectl describeの違い

質問

kubectl logsとkubectl describeの違いを詳細に教えてください。

解答

とても良い質問です。 kubectl logs と kubectl describe はどちらも Kubernetes 上の Pod やコンテナの「状態を確認する」ために使われますが、目的と表示内容がまったく異なります。 以下で、動作原理・出力内容・利用場面・内部的な違いまで詳しく説明します。 ■ 結論の概要 コマンド 主な目的 表示内容 主な対象 kubectl logs コンテナの標準出力／標準エラー出力のログを見る アプリケーションやプロセスの出力 Pod 内のコンテナ kubectl describe Kubernetes が保持するリソースの状態情報を見る Pod のイベント履歴、スケジューリング状況、状態、コンテナの詳細 Pod、Node、Service など Kubernetes オブジェクト全般 ■ 1. kubectl logs の詳細 目的 Pod 内で動作しているコンテナの**アプリケーションログ（stdout, stderr）**を取得します。 つまり「中で動いているプロセスが何を出力しているか」を見るためのコマンドです。 仕組み Kubernetes は、各コンテナランタイム（containerd, CRI-O, Docker など）を通じて 標準出力をログファイルにリダイレクト しています。 kubectl logs は、このログファイルを kubelet 経由で取得 します。 代表的な使い方 # Pod名を指定してログを取得kubectl logs my-pod# Pod内に複数コンテナがある場合、特定のコンテナを指定kubectl logs my-pod -c my-container# 継続的にログを監視（tail -fのように）kubectl logs -f my-pod# 過去のコンテナ（再起動前のログ）を見るkubectl logs my-pod --previous 出力例 [2025-10-29 12:10:43] INFO Server started on port 8080[2025-10-29 12:11:10] ERROR Failed to connect to database 特徴 表示されるのは アプリケーションの出力のみ（Kubernetesシステムイベントは含まれない）。 コンテナが削除された場合はログが消える（永続化されない）。 監視・トラブルシュート時の「アプリ側の挙動確認」に最適。 ■ 2. kubectl describe の詳細 目的 Kubernetes が保持する リソースの状態とイベント履歴 を確認します。 「Podがなぜ動いていないのか／どうスケジュールされたのか」など、クラスタ管理側の情報を得るコマンドです。 仕組み kubectl describe は API サーバーを通じて etcd に保存されたリソース情報を取得し、 それに紐づく イベント(Eventオブジェクト) を kubelet やコントローラーからまとめて表示します。 代表的な使い方 # Podの詳細情報kubectl describe pod my-pod# Nodeの詳細kubectl describe node my-node# Deploymentの詳細kubectl describe deployment my-deployment 出力例（Pod） Name: my-podNamespace: defaultNode: node-1Start Time: Tue, 29 Oct 2025 10:00:00 +0900Labels: app=myappStatus: CrashLoopBackOffContainers: app: Image: myimage:v1 State: Waiting Last State: Terminated Ready: FalseEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 10m default-scheduler Successfully assigned my-pod to node-1 Normal Pulled 9m kubelet Container image pulled Warning BackOff 8m (x3 over 9m) kubelet Back-off restarting failed container 特徴 イベント履歴や状態遷移、イメージPull状況など、Podのライフサイクル全体がわかる。 アプリ側のログ（標準出力）は含まれない。 Podが起動しない・CrashLoopBackOffになる原因調査 に最適。 ■ 3. 実際の使い分け方 シーン 使用するコマンド 理由 アプリケーションが例外で落ちた kubectl logs スタックトレースやエラーを直接確認できる Pod が起動しない、Pending のまま kubectl describe pod スケジューラーやイベントの詳細を確認できる コンテナが再起動を繰り返している kubectl describe pod → kubectl logs --previous 前回のコンテナ実行ログも取得可能 Node にスケジュールされない kubectl describe node 資源制約（CPU/メモリ不足）などを確認 ■ 4. 併用のコツ（トラブルシュート手順例） Podがうまく動かないときの典型的な調査手順は以下のようになります： # 1. Podの状態をざっくり見るkubectl get pods# 2. 詳細を確認してイベント履歴を追うkubectl describe pod <pod-name># 3. コンテナの出力を確認するkubectl logs <pod-name> [-c <container-name>]# 4. 再起動を繰り返す場合は過去ログも確認kubectl logs <pod-name> --previous ■ 5. 補足：内部的な違い 項目 kubectl logs kubectl describe 取得元 Kubelet（コンテナランタイム経由） API Server（etcd経由） データ内容 コンテナのstdout/stderr出力 リソースのメタ情報＋イベント データの保存場所 ノード上のログファイル etcd内のオブジェクト 主な用途 アプリの挙動確認 スケジューリングやKubernetesの判断確認 ■ まとめ kubectl logs：「アプリが何を出力したか」 を確認 kubectl describe：「Kubernetesが何をしたか、何が起こったか」 を確認 この2つを組み合わせることで、 「なぜPodが動かないのか」も「アプリが中で何をしているのか」も両方追跡できます。

Docker & Kubernetesネットワークのしくみ　クラウドネイティブに求められる情報通信の知識【電子書籍】[ 大隈 峻太郎 ] 価格:3300円 (2025/11/4 20:53時点) 感想(0件)

たった1日で基本が身に付く！ Docker/Kubernetes超入門【電子書籍】[ 伊藤 裕一 ] 価格:2838円 (2025/10/29 20:57時点) 感想(0件)