Kubernetesロギングとは
Kubernetesでは、ログがアプリケーションの挙動を把握し、クラスターの問題を解決するための主要な手段となります。Podは一時的な存在であるため、Kubernetesはコンテナのstdoutおよびstderrストリームを取得し、ノード上に一時ファイルとして保存することでログを管理します。
ロギングアーキテクチャ
Kubernetesにはログ向けの永続ストレージが標準で備わっておらず、主に次の3つのアーキテクチャパターンに依存します。
- ノードレベルのロギング: コンテナランタイムが標準出力を取得し、ホストノードの /var/log/pods/ に保存します。
- ログ転送用のサイドカーコンテナ: Pod内のセカンダリコンテナがアプリケーションのログを収集し、自身のstdoutまたは直接ロギングバックエンドへ流します。
- クラスターレベルのロギング: Fluentd、Fluent Bit、Filebeat などの専用エージェントを、全ノードにDaemonSetとして稼働させます。ローカルのログファイルを収集し、Elasticsearch、Grafana Loki、あるいはAWS CloudWatch、Google Cloud Logging(GKEで採用)、Azure Monitorといったクラウド固有サービスなどの集中ストレージへ転送します。
Kubernetesログの種類(それぞれ後述します)
- アプリケーションログ: 最も一般的な種類で、Pod内で動作するコードが生成します。
- システムコンポーネントログ: APIサーバー、スケジューラー、kubeletといったKubernetesのコアサービスが生成します。
- 監査ログ: Kubernetes APIサーバーへのすべての呼び出しを記録し、主にセキュリティとコンプライアンスに用いられます。
- イベント: 厳密にはログではありませんが、クラスター内の状態変化(例:Podの起動失敗)をタイムスタンプ付きで記録したものです。
kubectl get eventsで確認できます。
本記事の内容
- Kubernetesロギングアーキテクチャを理解する
- Kubernetesログの種類
- 押さえておきたいkubectl logsコマンド
- Kubernetesロギングの主なユースケース
- Kubernetesロギングのベストプラクティス
Kubernetesロギングアーキテクチャを理解する
ノードレベルのロギング
Kubernetesにおけるノードレベルのロギングとは、ホストマシン上でログを取得する仕組みを指し、コンテナランタイムがそのノードで稼働するすべてのコンテナのログを保存します。デフォルトでは、KubernetesノードはコンテナランタイムのロギングメカニズムDockerのJSONロギングドライバーなど)を利用し、各コンテナのstdoutとstderrを /var/log/containers/ など標準的な場所のログファイルに書き出します。
メリット
- コンテナが短命だったりクラッシュしたりしても、ログがノード上に保持されます。
- トラブルシューティング用のローカルなログソースとして機能します。
制約
- ノードレベルのロギングだけに頼るのは望ましくありません。
- ノードが削除されたり、ログがローテーションや削除されたりするとデータが失われる可能性があります。
- ノードレベルのログは分断されたままになるため、ノードをまたいだイベントの相関分析や、集約による横断的な分析が困難です。
- 単一ノードを超えた可視性が得られず、クラスター全体のワークロードの健全性、リソースの経時的な傾向、あるログイベントと別ノードのCPUスパイクとの関係といった問いには答えられません。
本番環境では通常、ノードレベルのロギングに加え、外部システムへログを収集・エクスポートして保持・検索・分析するクラスター全体のソリューションを併用します。
ログ転送用のサイドカーコンテナ
サイドカーコンテナは、同じPod内でメインのアプリケーションコンテナと並行して別のコンテナを動かすKubernetesのアーキテクチャパターンです。ロギングの文脈では、サイドカーの役割はあくまでログ転送にあります。メインのアプリケーションコンテナが生成するログファイルやストリームを読み取り、外部のロギングバックエンドへ送信します。これは、他のコンテナと同様にサイドカーコンテナから単にログを書き出すこととは異なります。この設計によりロギングロジックをアプリケーションコードから分離でき、workloads全体でログ収集を標準化できます。
メリット
- ロギングにサイドカーコンテナを用いると、柔軟性と一貫性が得られます。
- サイドカーはログローテーション、フォーマット整形、メタデータでの拡充、集中ログストレージへの安全な送信といったタスクを担えます。
- アプリケーションが構造化ロギングをネイティブにサポートしていない場合や、ログを複数の宛先に送る必要がある場合に有効です。
制約
- リソースのオーバーヘッドと運用上の複雑さが増します。
- 各Podでサイドカーコンテナのライフサイクル管理と設定が必要になります。
- サイドカーパターンが対応するのはログ収集であり、ログ分析ではありません。ログを完璧に転送できたとしても、コンテナ内で起きたこととクラスターレベルのイベント(スケジューリング判断、リソース逼迫、ノードの状態)を突き合わせるには、別途ツールが必要です。
クラスターレベルのロギング
クラスターレベルのロギングでは、Kubernetesクラスター内のすべてのノード、Pod、コンポーネントからログを集約し、集中システムへエクスポートします。一般的にはFluentd、Logstash、FilebeatといったログコレクションエージェントをDaemonSetとして展開し、各ノードでコンテナのログファイルやjournaldシステムからログを収集します。集めたログはElasticsearch、Splunk、クラウドベースのロギングサービスなど外部プラットフォームへ転送され、保存・インデックス化・クエリの対象となります。
これはマネージドKubernetesサービスがデフォルトで実装しているパターンです。GKE ではGoogle Cloud Logging(旧Stackdriver)が標準で有効になっており、Fluent BitベースのエージェントがDaemonSetとして展開され、Cloud Loggingへログを送信します。EKS でも、AWS for Fluent Bitアドオン経由でCloudWatch Logsへ転送する同様の構成が用意されています。マネージドKubernetesサービスを利用していれば、すでにクラスターレベルのロギングを使っている可能性が高く、問題はそれをどこまで活用できているかです。
メリット
- ノードやPodの一時性という課題に対し、workloadsの再スケジューリングやインフラ変更が起きてもログが保持されることを担保します。
- クラスターコンポーネント全体での検索、相関、分析が可能になり、アプリケーションの健全性監視、インシデントのデバッグ、コンプライアンス要件への対応が容易になります。
- 本番Kubernetes環境ではクラスターレベルのロギングがベストプラクティスとされ、オブザーバビリティのスケーラブルな基盤となります。
制約
- クラスターレベルのロギングを導入しても、ログだけでは全容は見えません。アプリケーションが報告した内容は記録できても、なぜPodが再スケジュールされたのか、ノードがメモリ逼迫状態だったのか、リソース消費が時系列でどう推移したのかまではわかりません。ログイベントとインフラメトリクスを突き合わせるには、ログ集約パイプラインだけでは不十分で、通常は追加のツールが必要です。
Kubernetesログの種類
1. アプリケーションログ
アプリケーションログは、コンテナ内で動作するコードが生成します。情報メッセージ、エラー、警告、デバッグ出力など、アプリケーションプロセスからの出力を捉えます。開発者はアプリケーションログを通じて実行時の挙動を把握し、リクエストを追跡し、ビジネスロジックや外部依存に起因する問題を診断します。アプリケーションログは通常stdoutとstderrに書き出されるため、Kubernetesのロギング機構からアクセスできます。
考慮事項
- コンテナの動的な性質から、Kubernetesでのアプリケーションログ管理には課題が伴います。コンテナ外で収集・永続化しなければ、Podが終了または再スケジュールされた際に情報が失われる可能性があります。
- ログはJSONなどの構造化フォーマットで出力し、コンテナ内にログファイルを書き込むのは避けるべきです。
- 集中ロギングソリューションにより、トラブルシューティングや監視のためのログ保持と検索が可能になります。
- アプリケーションログはコードが何をしたかは示しますが、KubernetesがなぜPodを終了させたのか、ノードがリソース逼迫状態だったのか、同時刻にクラスターで何が変化したのかまでは示しません。根本原因分析(RCA)において、アプリケーションログは出発点であり全体像ではありません。
2. システムコンポーネントログ
システムコンポーネントログは、Kubernetesクラスターのコアインフラが生成します。kubelet、kube-apiserver、kube-controller-manager、kube-scheduler、コンテナランタイムからのログが含まれます。これらはKubernetesのコントロールプレーンとノードエージェントの動作を可視化し、スケジューリング判断、ヘルスチェック、認証試行、プラットフォーム内のエラー状態などのイベントを記録します。
考慮事項
- システムコンポーネントログへのアクセスと分析は、クラスターの運用者や管理者にとって不可欠です。
- これらのログはクラスター構成に応じて、ホストファイルシステム上に保存されるか、systemd journald経由でアクセスされることが多くなります。
- システムコンポーネントログをアプリケーションログと併せて集中管理することで、インフラレベルのイベントとアプリケーションの問題を突き合わせやすくなり、RCAやKubernetes環境のプロアクティブな監視が可能になります。
- GKEやEKSのようなマネージドサービスでは、コントロールプレーンコンポーネントのログの大半がクラウドプロバイダのロギングプラットフォーム経由で利用できます。GKEではkube-apiserver、kube-scheduler、controller-managerのログがCloud Loggingに直接表示されます。これによりファイルシステムへの直接アクセスは不要になりますが、ログを能動的に監視・クエリする必要性まで消えるわけではありません。
3. 監査ログ
Kubernetesの監査ログは、APIサーバーへのすべてのリクエストを記録し、誰が、いつ、どこから、どんな操作を行ったかを詳細に捉えます。改ざん検知が可能なユーザー・システム活動の証跡となるため、セキュリティ、コンプライアンス、フォレンジック調査を支えます。Kubernetesの監査ログは設定可能で、ポリシーに基づきどのイベントをどの粒度で記録・保持するかを管理者が制御できます。
考慮事項
- 監査ログはアプリケーションログやシステムログとは異なり、API操作とアクセス制御イベントに焦点を当てます。
- 不正アクセスの検知、機密操作の監視、規制遵守の証明に役立ちます。
- 監査ログを安全で改変不可能なストレージに保存し、SIEMやセキュリティ分析プラットフォームと統合することが、Kubernetes環境のセキュリティを維持するための推奨プラクティスです。
- GKEでは監査ログはCloud Audit Logsで管理され、管理者活動についてはデフォルトで有効です。EKSではCloudTrailがAPIサーバーの活動を記録します。いずれの場合も収集はプロバイダ側が担いますが、分析、アラート、保持ポリシーは意図的に設定する必要があります。
イベント
Kubernetesのイベントは、クラスター内の重要な出来事(Podの作成、スケジューリング失敗、再起動、リソースクォータ違反など)をタイムスタンプ付きで記録したものです。従来型のログではなく、Kubernetesオブジェクトの状態遷移やライフサイクルの変化を把握するための通知として機能します。kubectl get events で確認でき、リアルタイムのデバッグや運用上の可視化に役立ちます。
考慮事項
- イベントは一時的な性質を持ち、Kubernetes APIサーバー内では短期間(デフォルトでは1時間)しか保持されません。
- トラブルシューティングの文脈情報としては有用ですが、監査や診断情報の唯一の情報源として使うべきではありません。
- より広範な可視化のためには、イベントを外部の監視・ロギングシステムに収集・エクスポートし、アプリケーションログやシステムログと突き合わせる必要があります。
押さえておきたいkubectl logsコマンド
kubectl logs コマンドは、ターミナルからコンテナのログを取得するための標準ツールです。
Podのログを表示する
kubectl logs コマンドは、KubernetesでPodのログを表示する最も基本的な手段です。コンテナのstdoutとstderrストリームからログを取得し、運用者や開発者がコマンドラインからアプリケーションの挙動を確認できます。最もシンプルな使い方は次の通りです。
kubectl logs <pod-name>このコマンドは指定したPodのデフォルトコンテナのログを表示します。Podにコンテナが1つしかなければ、Kubernetesが自動で選択します。コンテナをホストするノードに直接アクセスせずに、アプリケーションのエラー、起動失敗、想定外の挙動をトラブルシューティングするのに便利です。
ログをフォロー/ストリーミングする
Kubernetesは -f または --follow フラグでリアルタイムのログストリーミングに対応しています。Linuxの tail -f コマンドに似た挙動で、コンテナが生成する新しいログエントリを継続的に出力し続けます。
kubectl logs -f <pod-name>ログのストリーミングは、デバッグセッションや、デプロイ・アプリケーション起動プロセスを監視する際に役立ちます。ライブイベントを観察し、失敗を検知し、設定やコードの変更後にアプリケーションが正しく動作しているかを確認できます。
特定のコンテナのログ
Podに複数のコンテナが含まれる場合、どのコンテナのログを表示するかをKubernetesに指定する必要があります。これはサイドカーコンテナをロギング、プロキシ、監視エージェントとして用いるPodで一般的です。
kubectl logs <pod-name> -c <container-name>-c フラグでPod内の対象コンテナを指定します。このオプションを付けないと、複数コンテナが存在する場合にKubernetesがエラーを返すことがあります。マルチコンテナPodで特定のコンポーネントのログだけを切り出すのに有用です。
クラッシュした/以前のPodのログ
Kubernetesは --previous フラグを使って、以前に終了したコンテナのログを取得できます。コンテナがクラッシュして再起動し、元のログを確認する前に上書きされてしまう場合に便利です。
kubectl logs --previous <pod-name>複数コンテナのPodでは -c でコンテナ名も指定できます。以前のログにアクセスできることで、クラッシュループ、起動失敗、現在のコンテナインスタンスには現れない一時的なアプリケーションエラーの診断に役立ちます。
出力を制限する
大量のログは分析が難しいため、Kubernetesは出力量を制限するオプションを用意しています。--tail フラグは直近のログ行だけを表示します。
kubectl logs --tail=100 <pod-name>このコマンドは直近100行のログを返すため、過剰な出力をスクロールせずに最近のイベントに集中できます。
時間で絞り込む
Kubernetesは --since と --since-time フラグで時間ベースのログ絞り込みに対応します。インシデント調査時に、対象の時間帯にログを絞り込むのに役立ちます。
kubectl logs --since=1h <pod-name>上の例は直近1時間に生成されたログを返します。正確なタイムスタンプも指定できます。
kubectl logs --since-time=2026-05-28T10:00:00Z <pod-name>時間ベースの絞り込みは、デプロイ、障害、アラートとログを突き合わせるのに有用です。
Kubernetesロギングの主なユースケース
Kubernetesロギングの代表的なユースケースをいくつか紹介します。
- クラッシュするPodのデバッグ: ロギングは、繰り返しクラッシュしたり CrashLoopBackOff 状態に陥るPodを診断するうえで重要です。アプリケーションログは、設定ミス、依存関係の欠落、データベース接続失敗、実行時例外といった根本原因を示すことが多くあります。
kubectl logs --previousなどのコマンドを使えば、再起動前の終了済みコンテナのログを確認できます。 - 失敗したデプロイの調査: デプロイの失敗は、無効なコンテナイメージ、Readinessプローブの失敗、リソース制約、設定の不備などで発生します。Kubernetesのログは、新たにデプロイしたworkloadsが起動しない、あるいは健全な状態にならない理由の把握に役立ちます。アプリケーションログとKubernetesイベント、コントローラーログを組み合わせることで、デプロイのライフサイクル全体を可視化できます。
- アプリケーションエラーの監視: アプリケーションログは、本番環境での実行時エラーの監視やパフォーマンス問題の特定に使われます。ロギングシステムは全インスタンスのログを集約し、繰り返される例外、HTTP 500応答、タイムアウトエラーといったパターンを検出できます。これによりユーザー影響が出る前にインシデントを特定できます。
- ユーザー・システム活動の監査: Kubernetesの監査ログは、APIサーバーに対する操作の詳細な記録を提供します。これらのログを使って、ユーザー活動の追跡、管理上の変更の監視、セキュリティインシデントの調査が行えます。監査ログには、認証ユーザー、リクエスト種別、アクセスされたリソース、応答ステータスなどが記録されます。
- ノード・ランタイムの問題のトラブルシューティング: ノードとコンテナランタイムのログは、Kubernetes workloadsに影響するインフラレベルの問題の診断に役立ちます。kubeletの障害、ネットワーク問題、ディスク逼迫、コンテナランタイムのクラッシュといった問題は、通常クラスターノード上のシステムコンポーネントログから特定できます。
Kubernetesロギングのベストプラクティス
Kubernetes環境でロギング戦略を改善するための実践方法を紹介します。
1. クラスター、ネームスペース、workloadsを横断してログを集中管理する
ロギングの集中化はKubernetes環境におけるベストプラクティスであり、特に複数のクラスターやチームを抱える組織で重要です。ログを単一のプラットフォームに集約することで、ネームスペース、workloads、インフラコンポーネントを横断したイベントの検索、分析、相関分析が可能になります。集中ロギングがなければ、ログがノードやクラスターに分散したままとなり、トラブルシューティングが難しくなります。
一般的にはFluent Bit、Vector、Logstashなどのツールでログを収集し、Elasticsearch、Loki、Splunk、クラウドネイティブなロギングプラットフォームといった集中バックエンドへ転送します。集中化により運用上の可視性が高まり、インシデント対応が簡素化され、workloadsの再スケジュールやノードの終了が起きてもログにアクセスできる状態が保たれます。
なお、GKEやEKSは単一クラスター内の集中ログ収集をデフォルトで提供しますが、複数クラスター間での集中化 — たとえば本番クラスターのレイテンシスパイクをステージングクラスターのデプロイと突き合わせるような分析 — はクラウドプロバイダが自動でやってくれるわけではありません。これには意図的な集約戦略とツール選定が必要です。
2. ログとKubernetesリソースメトリクスを突き合わせる
ログは、Pod、ノード、デプロイメント、コンテナといったKubernetesリソースのメトリクスと組み合わせることで価値が増します。CPU使用率、メモリ消費量、再起動回数、ネットワークメトリクスとログを突き合わせることで、パフォーマンス問題や障害の根本原因を素早く特定できます。
たとえば、アプリケーションエラーの急増がノードのメモリ枯渇やレイテンシ増加と一致することがあります。ロギングシステムをPrometheusやGrafanaのようなオブザーバビリティプラットフォームと統合すれば、ログとメトリクスを併せて分析でき、クラスターの挙動やアプリケーションの健全性をより包括的に把握できます。
この領域は、マネージドKubernetesサービスが橋渡ししてくれない部分です。GKEのCloud LoggingやEKSのCloudWatch Logsはログの保存とクエリには対応しますが、同一ノード上のCPUスロットリングイベントやメモリ逼迫状態と、そのときのログイベントを自動で結びつけてはくれません。この相関分析にはKubernetes向けの専用オブザーバビリティツールが依然として必要で、そこにこそ最も価値ある診断シグナルが眠っていることが多いのです。
3. Kubernetesメタデータを含む構造化ロギングを使う
構造化ロギングは、ログを機械可読なデータ(通常はJSON)としてフォーマットすることで、検索性と自動化を高めます。非構造化テキストに頼るのではなく、タイムスタンプ、重要度、リクエストID、サービス名といったフィールドを一貫したフォーマットで出力します。
Kubernetesメタデータを含めることでオブザーバビリティが向上します。ログコレクターはPod名、ネームスペース、ノード名、コンテナイメージ、ラベルといった情報でログを拡充できます。これによりworkloads、環境、アプリケーションのオーナーごとにログをフィルタでき、大規模なKubernetes環境でのトラブルシューティングや分析が効率化されます。
GKE上で運用している場合、その多くは自動で処理されます。Cloud Loggingは構造化JSONログをネイティブに取り込み、ネームスペース、Pod名、クラスターなどのKubernetesリソースメタデータで拡充します。EKSのCloudWatch Container Insightsでも同様の拡充が行われます。とはいえ根底にある原則は理解しておく価値があります。各ログエントリに付与されるメタデータが豊かであるほど、大規模なマルチテナントクラスターで関連シグナルを素早く特定できるのです。
4. 再起動・退避・削除されたPodのログを保持する
KubernetesのコンテナやPodは一時的な存在であり、workloadsの再起動、クラッシュ、削除でログが消えてしまう可能性があります。データ損失を防ぐため、ログは生成され次第、耐久性のある外部ストレージへエクスポートすべきです。
一般的にはDaemonSetとしてログコレクターを展開し、ノードから集中ストレージシステムへログを送信します。クラスター外にログを保持することで、元のworkloadsが存在しなくなった後も、トラブルシューティング、監査、コンプライアンス、事後分析に必要な履歴データを利用し続けられます。
5. ログ量を制御してオブザーバビリティの無駄をなくす
過剰なロギングはストレージコストを膨らませ、ネットワーク帯域を消費し、オブザーバビリティプラットフォームの効率を低下させます。大規模なKubernetes環境では、特に本番環境でアプリケーションが詳細なデバッグレベルのログを出力すると、膨大なログデータが生成されます。
チームは適切なログレベル、保持期間、フィルタリングルールを定めたロギングポリシーを導入すべきです。不要なログの削減、繰り返し発生するイベントのサンプリング、価値の低いデータの除外により、有用なオブザーバビリティデータを維持しながら運用コストを抑制できます。
6. workloadsのオーナーシップとFinOpsラベルにログを揃える
workloadsに一貫したラベルとメタデータを付与することで、Kubernetes環境での説明責任とコストの可視性が高まります。オーナー情報、チーム識別子、環境、コスト配分ラベルで拡充されたログがあれば、どのアプリケーションが最もログデータを生成しているかを把握できます。
これはオブザーバビリティの支出を理解し、リソース利用を最適化するというFinOpsの取り組みを後押しします。また、ビジネスユニット、サービス、デプロイ環境ごとにログをフィルタできるため、運用ワークフローも簡素化されます。一貫したラベリング戦略は、Kubernetesプラットフォーム全体でガバナンス、トラブルシューティング効率、コスト管理を向上させます。
ログの先へ — PerfectScaleでKubernetesをプロアクティブにトラブルシュート
ここまで見てきたように、ログはKubernetesオブザーバビリティの基盤レイヤーですが、明確な限界もあります。コンテナ内で何が起きたかは捉えても、なぜPodが退避されたのか、OOMイベント前のリソース消費がどう推移していたのか、CPUスロットリング下でどのworkloadsが静かに劣化しているのかまでは示しません。ログ収集の大半が自動化されているGKEやEKSであっても、一時的なPod、ノード、ネームスペースを横断して生のログ出力を迅速な根本原因分析へとつなげる段階で、チームは行き詰まりがちです。
PerfectScale by DoiT は、AIガイド付きのKubernetes可視化とガバナンスを提供し、クラスター、ネームスペース、workloads、ノードグループを横断して、オブザーバビリティ、監視、そしてパフォーマンス・無駄・リソースメトリクスの継続分析を一体化します。ログ、トレース、メトリクスといったテレメトリを併せて分析することで、何が失敗しているかだけでなく、なぜそうなっているのかをチームが理解できるよう支援し、手作業の調査を大幅に減らしながら未知の問題の発見とRCAを可能にします。
PerfectScaleの主な機能
- フルスタックの可視化とオブザーバビリティ: クラスター、ネームスペース、workloads、ノードグループを横断してリアルタイムおよび過去のメトリクスを継続的に分析し、包括的な可視化、イベント追跡、深いインサイトにより、環境の健全性を常にコントロール下に保ちます。
- テレメトリからの根本原因分析: あらかじめ定義されたダッシュボードを超え、ログ、トレース、メトリクスといったテレメトリデータを分析することで、なぜ問題が起きているのかを説明し、未知の問題の発見とRCAの遂行を支援します。
- インパクトを意識したアラート: 自動的な課題の優先順位付けと予算ガードレールにより、アラートのノイズを排除し、最も重要でインパクトのある領域にチームを集中させます。
- アノマリ検知: コストとレジリエンスのアノマリ検知でチームに即座に通知し、ユーザーに影響が及ぶ前に障害や予期せぬ請求を防ぎます。
- プロアクティブな問題修復: AI駆動の予測インテリジェンスにより、CPUスロットリング、OOM、不適切なrequests/limits、非効率なスケーリングといったリスクを、Podの再起動、性能劣化、ダウンタイムを引き起こす前に検出・対処し、99.99%のシステム稼働率を維持します。
- 既存スタックとの連携: すでに利用しているコラボレーション、チケッティング、オブザーバビリティツールに接続し、最適化とトラブルシューティングをチームの既存ワークフローにシームレスに組み込みます。
ログデータをプロアクティブで強靭な運用へと変える準備はできていますか? PerfectScaleのAIガイド付きKubernetes可視化とガバナンスを見る。