GKE ログの管理

このページでは、Google Kubernetes Engine(GKE)で利用可能なロギング オプションの概要について説明します。

概要

クラスタで Kubernetes Engine オペレーションに Cloud LoggingCloud Monitoringを統合すると、ログは専用の永続データストアに保存されます。GKE 自体もログを保存しますが、これらのログは永続的に保存されません。たとえば、GKE のコンテナログは、ホスト Pod が削除されたとき、保存先ディスクの容量が不足したとき、または新しいログに置き換えられたときに削除されます。システムログは、新しいログの領域を確保するために定期的に削除されます。クラスタ イベントは、1 時間後に削除されます。

コンテナログとシステムログに対応するために、GKE はコンテナログを読み取り、有用なメタデータを追加して保存する、ノード単位の Logging エージェントをデプロイしています。このロギング エージェントは、次のソースのコンテナログをチェックします。

  • コンテナ化されたプロセスの標準出力ログと標準エラーログ

  • kubelet とコンテナのランタイムログ

  • VM 起動スクリプトなどのシステム コンポーネントのログ

イベントについては、GKE は kube-system 名前空間内の Deployment を使用します。この Deployment で、イベントを自動的に収集して Logging に送信します。

収集されるログ

デフォルトでは、GKE はクラスタにデプロイされたシステム ワークロードとアプリケーション ワークロードの両方のログを収集します。

  • システムログ - このログには、管理アクティビティ ログ、データアクセス ログ、イベントログなど、クラスタの監査ログが含まれます。GKE の監査ログの詳細については、GKE の監査ログのドキュメントをご覧ください。一部のシステムログは、kube-system などのコンテナとして実行されます。詳細については、アプリケーション ログの収集の制御をご覧ください。

  • アプリケーション ログ – Kubernetes コンテナは、STDOUTSTDERR に書き込まれたワークロードのログを収集します。

ログの収集

新しい GKE クラスタを作成すると、デフォルトで Kubernetes Engine オペレーションに Cloud Logging と Cloud Monitoring が統合されます。

以前の Cloud Logging では、こちらのドキュメントに従うと、Logging の統合を有効化または無効化できます。

ロギングのデフォルト

ロギングが有効のときは、専用のエージェントが自動的にデプロイされて管理されます。GKE ノード上でログを収集して、コンテナ、Pod、クラスタに関する有用なメタデータを追加し、ログを Cloud Logging に送信します。この場合、システムログとワークロードのアプリケーション ログの両方が、Cloud Logging のログルーターに送られます。

そこから、ログは Cloud Logging に取り込まれるか、除外されます。ログルーターは、BigQuery、Pub/Sub、Cloud Storage にログをエクスポートすることも可能です。

カスタマイズしてシステムログのみ収集する

GKE バージョン 1.15.7 以降では、Kubernetes Engine オペレーションを構成して、システムログのみを取得し、アプリケーション ログを収集しないようにできます。

カスタムの fluentd によるログ収集

GKE のデフォルトのロギング エージェントによって、クラスタのログを Cloud Logging に送信するエージェントをデプロイして管理するためのマネージド ソリューションが提供されます。fluentd エージェントのデフォルトの動作を変更する場合は、カスタマイズされた fluentd エージェントを実行します。

一般的な使用例:

  • ログから機密データを削除する

  • STDOUT または STDERR に書き込まれない追加的なログの収集

GKE ノードの Linux auditd ログの収集

Container-Optimized OSを実行している Google Kubernetes Engine ノードで、詳細なオペレーティング システムの監査ログを有効にできます。ノード上のオペレーティング システムのログには、エラーメッセージ、ログインの試行、バイナリ実行など、クラスタとワークロードの状態に関する有益な情報が含まれています。この情報は、問題のデバッグやセキュリティ インシデントの調査に使用できます。

詳細については、GKE ノードで Linux の auditd ログを有効にするをご覧ください。

GKE 監査ログ

Kubernetes クラスタに適用されるログエントリと GKE クラスタ オペレーションのリソースの種類に関する詳細は、監査ロギングをご覧ください。

ロギングのアクセス制御

ロギングのアクセス制御には、アプリケーション アクセスとユーザー アクセスの 2 つの側面があります。Cloud Logging では、適切なアクセス権を付与するために使用できる IAM ロールが用意されています。

アプリケーション アクセス

アプリケーションには、アプリケーションのサービス アカウントに IAM ロール roles/logging.logWriter を割り当てることによって付与される、ログの書き込み権限が必要です。GKE クラスタを作成すると、roles/logging.logWriter ロールがデフォルトで有効になります。

ユーザー表示アクセス

プロジェクトのログを表示するには、roles/logging.viewer ロールが必要です。データアクセス ログへのアクセス権が必要な場合は、logging.privateLogViewer IAM 権限が必要です。

権限とロールの詳細については、アクセス制御ガイドをご覧ください。Cloud 監査ログのベスト プラクティスに関するドキュメントもご覧ください。このドキュメントは、Cloud Logging 全般にも当てはまります。

ユーザー管理者アクセス

IAM ロールの roles/logging.configWriterroles/logging.admin は、管理に関わる権限を提供します。roles/logging.configWriter IAM ロールは、ログを特定のプロジェクトや一元管理されたプロジェクトに転送するために一般的に使用されるログシンクを作成するために必要です。たとえば、ログシンクとログフィルタを使用して、名前空間のすべてのログを一元化されたログバケットに振り向けることができます。

詳細については、Cloud Logging のアクセス制御ガイドをご覧ください。

おすすめ

  • 構造化ロギング: 標準出力または標準エラーに書き込まれた一行の JSON 文字列は、構造化ログエントリとして Google Cloud に読み込まれます。詳細については、構造化ロギングをご覧ください。高度なログフィルタを使用すると、フィールドに基づいてログをフィルタリングできます。
  • 重大度: デフォルトでは、標準出力に書き込まれるログは INFO レベルであり、標準エラーに書き込まれるログは ERROR レベルです。構造化ログには、ログの重大度を定義する severity フィールドを含めることができます。
  • BigQuery へのエクスポート: BigQuery や Pub/Sub などの外部サービスにログをエクスポートして、さらにログを分析できます。BigQuery にエクスポートされたログでは、その形式と構造が保持されます。詳細については、ログのエクスポートの概要をご覧ください。
  • アラート: ログベースの指標を使用して、Logging が予期しない動作をログに記録した場合のアラート ポリシーを設定できます。例については、カウンタ指標での簡単なアラート ポリシーの作成をご覧ください。ログベースの指標について詳しくは、ログベースの指標の概要をご覧ください。
  • エラーレポート: Error Reporting を使用して、クラスタ内で発生したエラーを収集できます。