GKE ログの管理

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

概要

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

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

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

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

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

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

収集されるログ

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

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

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

ログの収集

新しい GKE クラスタを作成すると、Cloud Logging および Cloud Monitoring と GKE 用 Cloud Operations との統合がデフォルトで有効になります。

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

ロギングのデフォルト

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

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

GKE 1.16-13-gke.400 以降、ノードのシリアルポート出力は Cloud Logging に保存されます。Cloud Logging のシリアルポート出力ロギングを無効にするには、クラスタの作成時に --metadata serial-port-logging-enable=false を設定します。

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

GKE バージョン 1.15.7 以降では、システムログのみをキャプチャし、アプリケーション ログは収集しないように GKE 用 Cloud Operations を構成できます。

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

GKE のデフォルトの Logging エージェントによって、クラスタのログを 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 Audit Logs のベスト プラクティスに関するドキュメントもご覧ください。このドキュメントは、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 を使用して、クラスタ内で発生したエラーを収集できます。