このページでは、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 の監査ログは無効にできません。
システムログ（使用可能なログに記載されているログを含む）。
アプリケーション ログには、ユーザーノードで実行されているシステム以外のコンテナによって生成されたすべてのログが含まれます。
次の制限の結果として、アプリケーション ログを Cloud Logging に送信できなくなることがあります。
- JSON ログでは、重複する JSON キーはサポートされません。
streamは GKE ロギング パイプラインでの予約済みキーです。streamキーがアプリケーションの JSON ログの中に存在する場合は、予期しない動作が発生してログが破棄される可能性があります。- Cloud Logging には、LogEntry あたりのサイズの上限があります。このサイズ上限を超える LogEntry は、jsonPayload ログの場合は破棄され、textPayload ログの場合は切り捨てられます。
必要に応じて、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 にエクスポートされます。
また、システムログのみをキャプチャして、アプリケーション ログは収集しないように、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 に送信するエージェントをデプロイして管理するためのマネージド ソリューションが提供されます。ログは fluentbit ベースのエージェントを使用して収集されます。
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 を使用します。
使用可能なログ
Cloud Logging にログを送信する場合は、システムログを送信する必要があります。必要に応じて、追加のソースからログを送信することもできます。
次の表に、create コマンドと update コマンドの --logging フラグでサポートされる値を示します。
| ログソース | --logging 値 |
収集されるログ |
|---|---|---|
| なし | NONE |
Cloud Logging にログは送信されません。クラスタ内にログ収集エージェントがインストールされていません。この値は、GKE Autopilot クラスタではサポートされていません。 |
| システム | SYSTEM |
以下からログを収集します。
Kubernetes イベントも収集します。この値は、すべてのクラスタタイプで必要です。 |
| ワークロード | WORKLOAD |
ユーザーノードで実行されているシステム以外のコンテナによって生成されたすべてのログ。この値はデフォルトでオンになっていますが、すべてのクラスタタイプで省略可能です。 |
| API サーバー | API_SERVER |
kube-apiserver によって生成されたすべてのログ。この値は、すべてのクラスタタイプで省略可能です。 |
| スケジューラ | SCHEDULER |
kube-scheduler によって生成されたすべてのログ。この値は、すべてのクラスタタイプで省略可能です。 |
| コントローラ マネージャー | CONTROLLER_MANAGER |
kube-controller-manager によって生成されたすべてのログ。この値は、すべてのクラスタタイプで省略可能です。 |
| 水平 Pod オートスケーラー | KCP_HPA |
GKE クラスタ内の各 HPA オブジェクトについて、アトミックな推奨と最終的な推奨の両方について推奨決定ログをエクスポートします。 詳しくは、HorizontalPodAutoscaler イベントを表示するをご覧ください。 |
| コントロール プレーンのネットワーク接続 | KCP_CONNECTION |
GKE control plane authority でのみ使用可能 GKE コントロール プレーン インスタンスのインバウンド ネットワーク接続ログ。詳細については、クラスタ コントロール プレーンへの Google 接続を確認するをご覧ください。 |
| コントロール プレーンの SSH イベント | KCP_SSHD |
GKE control plane authority でのみ使用可能 Google の担当者がサポートケース中やその他の管理アクセスのためにクラスタ コントロール プレーン インスタンスに接続したときに発生するすべての SSH イベント（公開鍵の承認やセッションの終了など）用のログを生成します。 詳細については、クラスタ コントロール プレーンへの Google 接続を確認するをご覧ください。 |
デフォルトで有効になっている GKE Enterprise のログ
Trusted Cloud by S3NSで新しい GKE クラスタを作成すると、ワークロード ログがデフォルトではすべての Autopilot クラスタに対して有効になりますが、無効にすることもできます。
GKE Enterprise エディション プロジェクトの場合は、クラスタの作成時にフリートに登録すると、追加の有用なログがデフォルトで有効になります。
次の表のチェックマーク（）は、GKE Enterprise が有効になっているプロジェクトで新しいクラスタを作成して登録するときに、デフォルトで有効になるログを示しています。
| ログ名 | Autopilot | スタンダード |
|---|---|---|
| システム | ||
| ワークロード | ||
| API サーバー | ||
| スケジューラ | ||
| コントローラ マネージャー | ||
| コントロール プレーンのネットワーク接続 | ||
| コントロール プレーンの SSH イベント |
割り当て
コントロール プレーン ログは、Cloud Logging API の「1 分あたりの書き込みリクエスト数」の割り当てを消費します。コントロール プレーン ログを有効にする前に、その割り当ての直近のピーク使用量を確認してください。同じプロジェクトに多くのクラスタがある場合や、すでに割り当ての上限に近づいている場合は、コントロール プレーン ログを有効にする前に割り当ての上限の引き上げをリクエストできます。
アクセス制御
組織内で Kubernetes コントロール プレーン ログへのアクセスを制限する場合は、より制限されたアクセス制御を使用して別のログバケットを作成できます。
アクセスが制限された別のログバケットにログを保存しても、プロジェクトへの roles/logging.viewer アクセス権を持つすべてのユーザーが自動的にログバケット内のコントロール プレーン ログにアクセスできるようにはなりません。また、アクセスが制限されている別のログバケットに保存することで、プライバシーやセキュリティ上の理由から特定のコントロール プレーン ログを削除する場合に、他のコンポーネントまたはサービスのログに影響を与えずにログを削除できます。