GKE ダッシュボードのトラブルシューティング

[リソース] メニューに [GKE] オプションが表示されない場合は、Cloud Monitoring が有効になっている GKE クラスタがない可能性があります。

ダッシュボードに Kubernetes リソースが表示されない理由

GKE ダッシュボードに Kubernetes リソースが表示されない場合は、以下の点を確認します。

正しい Google Cloud プロジェクトがページの上部で選択されているか。

選択されていない場合は、メニューバーのプルダウンリストからプロジェクトを選択します。データを表示するプロジェクトを選択する必要があります。

プロジェクトにアクティビティがあるかどうか。

クラスタを作成したばかりの場合は、データが入力されるまで数分間かかります。詳細は、モニタリングとロギングのサポートのインストールをご覧ください。

期間が短すぎるかどうか。

ダッシュボードツールバーの [時間] メニューを使用して、他の期間を選択するか、またはカスタム範囲を定義できます。

ダッシュボードの表示に必要な権限があるかどうか。

サービスのデプロイメントの詳細または Google Cloud プロジェクトの指標を表示するときに、次のいずれかの権限拒否エラーメッセージが表示された場合は、Identity and Access Management のロールを更新し、roles/monitoring.viewer または roles/viewer を含める必要があります。

You do not have sufficient permissions to view this page
You don't have permissions to perform the action on the selected resources

詳しくは、事前定義ロールをご覧ください。

クラスタとノードのサービスアカウントに Monitoring と Logging へのデータ書き込み権限があるかどうか。

Google Cloud コンソールの [有効な API とサービス] ページでエラー率が高い場合は、サービスアカウントに次のロールがない可能性があります。

roles/logging.logWriter: Google Cloud コンソールでは、このロールの名前は、ログ書き込みです。Logging のロールの詳細については、Logging アクセス制御ガイドをご覧ください。
roles/monitoring.metricWriter: Google Cloud Console では、このロールの名前は、モニタリング指標の書き込みです。Monitoring のロールの詳細については、Monitoring アクセス制御ガイドをご覧ください。
roles/stackdriver.resourceMetadata.writer: Google Cloud Console では、このロールの名前は、Stackdriver リソースメタデータ書き込みです。このロールは、リソースメタデータへの書き込み専用アクセスを許可し、エージェントがメタデータを送信するのに必要な権限を提供します。Monitoring のロールの詳細については、Monitoring アクセス制御ガイドをご覧ください。

サービスアカウントを一覧表示するには、Google Cloud コンソールで [IAM と管理] に移動し、[サービスアカウント] を選択します。

一部のログが表示されない理由

エージェントが動作しており正常な状態か。

GKE バージョン 1.17 以降では、Fluent Bit を使用してログを取得します。Fluent Bit は、Kubernetes ノードで動作する Logging エージェントです。エージェントが正しく動作しているかどうかを確認するには、以下の手順を行います。

次のコマンドを実行して、エージェントが再起動しているかどうかを確認します。

kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

再起動していない場合、出力は次のようになります。

NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

次のコマンドを実行して、Pod の status.conditions を確認します。

JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

デプロイメントが正常な場合は、次のような形の出力が得られます。

fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

次のコマンドを実行して Pod のステータスを確認します。これにより、デプロイメントが正常かどうかを判断できます。
```
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system
```
デプロイメントが正常な場合は、次のような形の出力が得られます。
```
NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h
```
この出力例では、DESIRED 状態が CURRENT 状態と一致しています。

また、エージェントが動作しており正常な状態であっても、すべてのログが表示されない場合は、エージェントが過負荷状態で、ログが破棄されている可能性があります。

エージェントが過負荷状態になり、ログが破棄されているか。

ログが表示されない理由の 1 つとして、ノードのログボリュームが多く、エージェントが過負荷状態になっていることが考えられます。GKE のデフォルトの Logging エージェント構成では、ノードあたり 100 KiB/秒の速度が設定されています。ボリュームがこの上限を超えると、ログの削除が開始することがあります。

この上限に達しているかどうかを確認するには、次のいずれかのインジケーターを探します。

container_name=fluentbit-gke フィルタを使用して kubernetes.io/container/cpu/core_usage_time 指標を表示し、Logging エージェントの CPU 使用量が 100% に近くになっていないか確認します。
metadata.system_labels.node_name でグループ化して logging.googleapis.com/byte_count の指標を表示して、いずれかのノードが 100 KiB/秒に達しているかどうか確認します。

いずれかの条件に該当する場合は、クラスタにノードを追加して、ノードのログボリュームを減らすことができます。すべてのログボリュームが 1 つの Pod から発生している場合は、その Pod のログボリュームを減らす必要があります。

Logging エージェントの調整パラメータを変更する場合は、コミュニティチュートリアルで Logging エージェントのカスタム構成をデプロイする方法をご覧ください。

GKE のロギング関連の問題の調査と解決については、GKE でのロギングのトラブルシューティングをご覧ください。

インシデントが GKE リソースと一致しない理由

複数の GKE リソースから指標を集約するアラートポリシー条件がある場合、インシデントを特定のエンティティに関連付けるため、ポリシー条件を編集して GKE 階層ラベルを追加しなければならない場合があります。

たとえば、本番環境用とステージング用の GKE クラスタがあり、それぞれにサービス lilbuddy-2 の独自のコピーがあるとします。アラートポリシーの条件で両方のクラスタのコンテナ間で指標が集計されると、GKE Monitoring ダッシュボードで、このインシデントを本番環境のサービスまたはステージングのサービスと一意に関連付けることができません。

この状況を解決するには、ポリシーの [グループ条件] フィールドに namespace、cluster、location を追加して、アラートポリシーを特定のサービスに関連付けます。アラートのイベントカードで、[Update alert policy] リンクをクリックして、関連するアラートポリシーの [アラートポリシーの編集] ページを開きます。ここで、アラートポリシーの情報を更新し、ダッシュボードに関連リソースが表示されるようにします。

アラートポリシーを更新すると、GKE Monitoring ダッシュボードで新たに発生したインシデントを特定のクラスタ内の一意のサービスに関連付け、問題の診断に役立つ追加情報を得ることができます。

ユースケースによっては、[グループ条件] フィールドに追加するときに、一部のラベルをフィルタリングできます。たとえば、本番環境のクラスタに対するアラートのみが必要な場合は、cluster_name でフィルタできます。