このページでは、Google Kubernetes Engine（GKE）で利用可能なロギング オプションの概要について説明します。
概要
Cloud Logging に送信された GKE ログは、専用の永続データストアに保存されます。GKE 自体もログを保存しますが、これらのログは永続的に保存されません。たとえば、GKE のコンテナログは、ホスト Pod が削除されたとき、保存先ディスクの容量が不足したとき、または新しいログに置き換えられたときに削除されます。システムログは、新しいログの領域を確保するために定期的に削除されます。クラスタ イベントは、1 時間後に削除されます。
GKE ロギング エージェント
コンテナログとシステムログに対応するため、GKE はデフォルトでノード単位の Logging エージェントをデプロイします。このエージェントがコンテナログを読み取り、有用なメタデータを追加して Cloud Logging に保存します。この GKE ロギング エージェントは、次のソースのコンテナログをチェックします。
コンテナ化されたプロセスの標準出力ログと標準エラーログ
kubelet とコンテナのランタイムログ
VM 起動スクリプトなどのシステム コンポーネントのログ
イベントについては、GKE は kube-system Namespace の Deployment を使用します。この Deployment で、イベントを自動的に収集して Logging に送信します。
収集されるログ
デフォルトでは、GKE はクラスタから数種類のログを収集し、Cloud Logging に保存します。
監査ログには、管理アクティビティ ログ、データアクセス ログ、イベントログが含まれます。GKE の監査ログの詳細については、GKE 監査ログのドキュメントをご覧ください。GKE の監査ログは無効にできません。
システムログには、次のソースのログが含まれます。
Namespace
kube-system、istio-system、knative-serving、gke-system、config-management-systemで実行中のすべての Pod。コンテナ化されていない重要なサービス:
docker/containerdランタイム、kubelet、kubelet-monitor、node-problem-detector、kube-container-runtime-monitor。ノードのシリアルポート出力（VM インスタンスのメタデータ
serial-port-logging-enableが true に設定されている場合）。GKE 1.16-13-gke.400 以降、ノードのシリアルポート出力は Logging エージェントによって収集されます。シリアルポート出力のロギングを無効にするには、クラスタの作成時に--metadata serial-port-logging-enable=falseを設定します。シリアルポート出力は、GKE ノードでのクラッシュ、ブートの失敗、起動の問題、シャットダウンの問題のトラブルシューティングに役立ちます。これらのログを無効にすると、問題のトラブルシューティングが難しくなることがあります。
アプリケーション ログには、ユーザーノードで実行されているシステム以外のコンテナによって生成されたすべてのログが含まれます。
必要に応じて、GKE は特定の Kubernetes コントロール プレーン コンポーネントから追加のタイプのログを収集して、Cloud Logging に保存できます。
API サーバーログには、Kubernetes API サーバー（
kube-apiserver）で生成されたすべてのログが含まれます。Scheduler ログには、Kubernetes Scheduler（
kube-scheduler）によって生成されたすべてのログが含まれます。Controller Manager ログには、Kubernetes Controller Manager（
kube-controller-manager）によって生成されたすべてのログが含まれます。
これらのコントロール プレーン コンポーネントの詳細については、GKE クラスタ アーキテクチャをご覧ください。
ログの収集
新しい GKE クラスタを作成すると、Cloud Logging との統合がデフォルトで有効になります。
システムログとアプリケーション ログは、Cloud Logging のログルーターに配信されます。
そこから、ログは Cloud Logging に取り込まれるか、除外されるか、BigQuery、Pub/Sub、Cloud Storage にエクスポートされます。
GKE バージョン 1.15.7 以降では、システムログのみをキャプチャし、アプリケーション ログは収集しないように Standard クラスタを構成できます。Autopilot クラスタと Standard クラスタのいずれの場合も、除外フィルタを使用すると、Cloud Logging に送信されるログの量を減らすことができます。
ロギングのスループット
システム ロギングを有効にすると、専用の Cloud Logging エージェントが自動的にデプロイされ、管理されます。これは、クラスタ内のすべての GKE ノード上で実行され、ログを収集します。コンテナ、Pod、クラスタに関する有用なメタデータを追加し、fluentbit ベースのエージェントを使用してログを Cloud Logging に送信します。
いずれかの GKE ノードでデフォルトのログ スループットが必要であり、GKE Standard クラスタでコントロール プレーン バージョン 1.23.13-gke.1000 以降を使用している場合は、ロギング スループットを最大化するように設計された Logging エージェントの代替構成をデプロイするように GKE を構成できます。
詳細については、ログ スループットを調整するをご覧ください。
カスタム fluentd またはカスタム fluentbit によるログ収集
GKE のデフォルトの Logging エージェントによって、クラスタのログを Cloud Logging に送信するエージェントをデプロイして管理するためのマネージド ソリューションが提供されます。GKE コントロール プレーンのバージョンに応じて、fluentd と fluentbit のいずれかを使用してログを収集します。GKE 1.17 以降では、fluentbit ベースのエージェントを使用してログが収集されます。GKE 1.17 より前のバージョンを使用する GKE クラスタでは、fluentd ベースのエージェントを使用します。fluentd エージェントのデフォルトの動作を変更する場合は、カスタマイズした fluentd エージェントまたはカスタマイズした fluentbit エージェントを使用します。
一般的なユースケースには次のものがあります。
ログからの機密データの削除
STDOUTまたはSTDERRに書き込まれない追加のログの収集パフォーマンスに関連する特定の設定の使用
カスタマイズしたログ形式
GKE ノードの Linux auditd ログの収集
Container-Optimized OS を実行している GKE ノードで、詳細なオペレーティング システム監査ログを有効にできます。ノードのオペレーティング システムログには、エラー メッセージ、ログイン試行、バイナリ実行など、クラスタとワークロードの状態に関する重要な情報が記録されます。この情報を活用して、問題のデバッグやセキュリティ インシデントの調査を行えます。
詳細については、GKE ノードでの Linux auditd ログの有効化をご覧ください。
GKE 監査ログ
Kubernetes クラスタに適用されるログエントリと GKE クラスタ オペレーションのリソースの種類に関する詳細は、監査ロギングをご覧ください。
ロギングのアクセス制御
ロギングのアクセス制御には、アプリケーション アクセスとユーザー アクセスの 2 つの側面があります。Cloud Logging には、適切なアクセス権を付与するために使用できる Identity and Access Management（IAM）ロールが用意されています。
アプリケーション アクセス
アプリケーションに、Cloud Logging にログを書き込むための権限が必要です。この権限は、基盤となるノードプールに接続しているサービス アカウントに IAM ロール roles/logging.logWriter を割り当てることで付与されます。
ユーザー表示アクセス
プロジェクトのログを表示するには、roles/logging.viewer ロールが必要です。データアクセス ログへのアクセス権が必要な場合は、logging.privateLogViewer IAM 権限が必要です。
権限とロールの詳細については、アクセス制御ガイドをご覧ください。Cloud Audit Logs のベスト プラクティスもご覧ください。これは、Cloud Logging にも当てはまります。
ユーザー管理者アクセス
IAM ロールの roles/logging.configWriter と roles/logging.admin は、管理に関わる権限を提供します。roles/logging.configWriter ロールは、ログを特定のプロジェクトや一元管理されたプロジェクトに転送するために一般的に使用されるログシンクを作成するために必要です。たとえば、ログシンクとログフィルタを使用して、名前空間のすべてのログを一元化されたログバケットに転送できます。
詳細については、Cloud Logging のアクセス制御ガイドをご覧ください。
ベスト プラクティス
- 構造化ロギング: GKE に統合されたロギング エージェントは、単一行の文字列にシリアル化され、標準出力または標準エラーに書き込まれた JSON ドキュメントを読み取り、構造化ログエントリとして Google Cloud Observability に送信します。
- 重大度: デフォルトでは、標準出力に書き込まれるログは
INFOレベルで、標準エラーに書き込まれるログはERRORレベルです。構造化ログには、ログの重大度を定義するseverityフィールドを含めることができます。 - BigQuery へのエクスポート: BigQuery や Pub/Sub などの外部サービスにログをエクスポートできます。BigQuery にエクスポートされたログでは、その形式と構造が保持されます。詳細については、ルーティングとストレージの概要をご覧ください。
- アラート: Logging によって予期しない動作がログに記録された場合は、ログベースの指標を使用してアラート ポリシーを設定できます。例については、カウンタ指標のアラート ポリシーを作成するをご覧ください。ログベースの指標について詳しくは、ログベースの指標の概要をご覧ください。
- Error Reporting: クラスタで実行されているアプリケーションからエラーを収集するには、Error Reporting を使用します。
コントロール プレーン ログ
Kubernetes API サーバー、Scheduler、Controller Manager が出力したログを Cloud Logging に送信するように GKE クラスタを構成できます。
要件
Kubernetes コントロール プレーン コンポーネントによって出力されたログを Cloud Logging に送信するには、GKE コントロール プレーンのバージョン 1.22.0 以降が必要です。また、システムログの収集が有効になっている必要があります。
コントロール プレーンのログの収集を構成する
新しいクラスタまたは既存のクラスタのロギング サポートを構成する手順をご覧ください。
料金
GKE コントロール プレーン ログは Cloud Logging にエクスポートされます。Cloud Logging の料金が適用されます。
割り当て
コントロール プレーン ログは、Cloud Logging API の「1 分あたりの書き込みリクエスト数」の割り当てを消費します。コントロール プレーン ログを有効にする前に、その割り当ての直近のピーク使用量を確認してください。同じプロジェクトに多くのクラスタがある場合や、すでに割り当ての上限に近づいている場合は、コントロール プレーン ログを有効にする前に割り当ての上限の引き上げをリクエストできます。
アクセス制御
組織内で Kubernetes コントロール プレーン ログへのアクセスを制限する場合は、より制限されたアクセス制御を使用して別のログバケットを作成できます。
アクセスが制限された別のログバケットにログを保存しても、プロジェクトへの roles/logging.viewer アクセス権を持つすべてのユーザーが自動的にログバケット内のコントロール プレーン ログにアクセスできるようにはなりません。また、アクセスが制限されている別のログバケットに保存することで、プライバシーやセキュリティ上の理由から特定のコントロール プレーン ログを削除する場合に、他のコンポーネントまたはサービスのログに影響を与えずにログを削除できます。