システム指標のトラブルシューティング

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）クラスタでシステム指標関連の問題を解決する方法について説明します。

さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。

クラスタの指標が Cloud Monitoring に表示されない

プロジェクトで Monitoring API と Logging API が有効になっていることを確認します。また、Google Cloud コンソールの Cloud Monitoring の概要でプロジェクトを表示できることを確認する必要があります。

問題が解決しない場合は、次の原因が考えられます。

クラスタでモニタリングが有効になっていますか？

Google Cloud コンソールと Google Cloud CLI で作成したクラスタでは、モニタリングがデフォルトで有効になります。これを確認するには、Google Cloud コンソールでクラスタの詳細情報をクリックするか、次のコマンドを実行します。
```
gcloud container clusters describe CLUSTER_NAME
```
このコマンドの出力では、次のように、monitoringConfig セクションの enableComponents のリストに SYSTEM_COMPONENTS が含まれているはずです。
```
monitoringConfig:
  componentConfig:
    enableComponents:
    - SYSTEM_COMPONENTS
```
モニタリングが有効になっていない場合は、次のコマンドを実行して有効にします。
```
gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
```
クラスタを作成してから、またはモニタリングを有効にしてからどれくらいの時間が経過していますか？

新しいクラスタの指標が Cloud Monitoring に表示されるまでに最長で 1 時間かかります。
heapster または gke-metrics-agent（OpenTelemetry Collector）がクラスタの kube-system Namespace で実行されていますか？

クラスタのリソースが不足しているため、Pod がワークロードのスケジュールに失敗している可能性があります。kubectl get pods --namespace=kube-system を実行し、名前に heapster または gke-metrics-agent が含まれる Pod があるか調べて、Heapster または OpenTelemetry が実行されているかどうかを確認してください。
クラスタのコントロールプレーンはノードと通信できますか？

Cloud Monitoring はこの通信に依存しています。コントロールプレーンがノードと通信しているかどうかを確認するには、次のコマンドを実行します。
```
kubectl logs POD_NAME
```
このコマンドがエラーを返した場合は、SSH トンネルで問題が発生している可能性があります。トラブルシューティングの手順については、SSH の問題のトラブルシューティングをご覧ください。
ノードのサービスアカウントは指標を書き込むことができますか？

各 GKE ノードには、Google Cloud APIs や Cloud Monitoring などのサービスへの認証に使用するサービスアカウントがあります。デフォルトでは、カスタムサービスアカウントを指定しない限り、GKE はノードに Compute Engine のデフォルトのサービスアカウントを使用します。組織のポリシーによっては、Compute Engine のデフォルトのサービスアカウントに Cloud Monitoring への書き込み権限が不足している場合があります。
1. ノードが使用するサービスアカウントがわからない場合は、サービスアカウントを見つけます。Autopilot クラスタの場合、サービスアカウントはクラスタの全体的な詳細に表示されます。Standard クラスタの場合、サービスアカウントはノードプールごとに指定されます。
  コンソール
  1. 関連するプロジェクトが選択された状態で、Google Cloud コンソールの GKE の [クラスタ] ページに移動します。
    
    [クラスタ] に移動
  2. クラスタを選択して詳細ページを表示します。
  3. クラスタモードに応じて、次のいずれかを行います。
    
    Autopilot クラスタの場合は、[セキュリティ] セクションで [サービスアカウント] の値を確認します。
    
    Standard クラスタの場合は、[ノード] タブに移動し、関連するノードプールの名前をクリックします。ノードプールの詳細ページで、[セキュリティ] セクションの [サービスアカウント] の値を確認します。
  gcloud
  Autopilot クラスタの場合は、次のコマンドを実行します。
  gcloud container clusters describe CLUSTER_NAME \ --location= LOCATION\ --flatten=nodeConfig \ --format='value(serviceAccount)'
  Standard クラスタの場合は、次のコマンドを実行します。これにより、クラスタ内のすべてのノードプールとそのサービスアカウントが返されます。
  gcloud container clusters describe CLUSTER_NAME \ --location=LOCATION \ --flatten=nodePools \ --format='table(nodePools.name,nodePools.config.serviceAccount)'
  次のように置き換えます。
  - CLUSTER_NAME: クラスタの名前
  - LOCATION: クラスタのロケーション
  - サービスアカウントが default として表示されている場合、ノードは Compute Engine のデフォルトのサービスアカウントを使用します。そのメールアドレスは PROJECT_NUMBER-compute@developer.gserviceaccount.com です。
  - 別のメールアドレスが表示されている場合は、ノードがカスタムサービスアカウントを使用しています。
2. サービスアカウントに Cloud Monitoring の書き込み権限（または任意の権限）があるかどうかを確認するには、次の操作を行います。
  コンソール
  1. 関連するプロジェクトが選択された状態で、Google Cloud コンソールの IAM ページに移動します。
    
    [IAM] に移動
  2. [プリンシパル] 列で、ノードサービスアカウントのメールアドレスを探します。リストにサービスアカウントのメールアドレスがない場合、ノードのサービスアカウントには権限がありません。アカウントがリストにある場合は、[ロール] 列に表示されているロールと、そのロールに Cloud Monitoring の書き込み権限が含まれているかどうかを確認します。
  gcloud
  次のコマンドを実行して、特定したサービスアカウントに付与されているすべてのロールを一覧取得します。
  gcloud projects get-iam-policy PROJECT_ID \ --flatten=bindings \ --filter=bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL\ --format='value(bindings.role)'
  SERVICE_ACCOUNT_EMAIL: ノードのサービスアカウントのメールアドレスに置き換えます。
  
  出力が空の場合、ノードのサービスアカウントには権限がないことを意味します。出力にロールが含まれている場合は、これらのロールに Cloud Monitoring の書き込み権限が含まれているかどうかを確認します。
これらの手順を完了しても必要な権限が表示されない場合は、サービスアカウントに関連するロールを付与するか、別のサービスアカウントを使用する新しいクラスタまたはノードプールにワークロードを移行します。システム指標の書き込みに必要な最小ロールは roles/monitoring.metricWriter です。GKE に必要な最小ロールの詳細については、クラスタを強化するをご覧ください。

指標エージェントに十分なメモリがあることを確認する

上記のトラブルシューティングの手順を試しても指標が表示されない場合は、指標エージェントにメモリが不足している可能性があります。

ほとんどの場合、GKE 指標エージェントのリソースはデフォルトの割り当てで十分です。ただし、DaemonSet が頻繁にクラッシュする場合は、次の手順で終了の理由を確認できます。

GKE 指標エージェントの Pod の名前を取得します。

kubectl get pods -n kube-system -l component=gke-metrics-agent

ステータスが CrashLoopBackOff の Pod を見つけます。

出力は次のようになります。

NAME                    READY STATUS           RESTARTS AGE
gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m

ステータスが CrashLoopBackOff の Pod の説明を取得します。
```
kubectl describe pod POD_NAME -n kube-system
```
POD_NAME は、前の手順の Pod の名前に置き換えます。

Pod の終了の理由が OOMKilled の場合、エージェントに追加のメモリが必要です。

出力は次のようになります。
```
  containerStatuses:
  ...
  lastState:
    terminated:
      ...
      exitCode: 1
      finishedAt: "2021-11-22T23:36:32Z"
      reason: OOMKilled
      startedAt: "2021-11-22T23:35:54Z"
```
失敗した指標エージェントを含むノードにノードラベルを追加します。永続的または一時的なノードラベルを使用できます。20 MB を追加してみることをおすすめします。それでもエージェントがクラッシュし続ける場合は、より大容量の追加メモリをリクエストするノードラベルに置き換えて、もう一度このコマンドを実行します。

永続ラベルを持つノードプールを更新するには、次のコマンドを実行します。
```
gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
    --location=COMPUTE_LOCATION
```
次のように置き換えます。
- NODEPOOL_NAME: ノードプールの名前。
- CLUSTER_NAME: 既存のクラスタの名前。
- ADDITIONAL_MEMORY_NODE_LABEL: 追加するメモリのノードラベル。次のいずれかの値を使用します。
  - 10 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=10
  - 20 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=20
  - 50 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=50
  - 100 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=100
  - 200 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=200
  - 500 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=500
- COMPUTE_LOCATION: クラスタの Compute Engine のロケーション。
または、次のコマンドを使用して、アップグレード後に保持されない一時的なノードラベルを追加することもできます。
```
kubectl label node/NODE_NAME \
ADDITIONAL_MEMORY_NODE_LABEL --overwrite
```
次のように置き換えます。
- NODE_NAME: 影響を受ける指標エージェントのノードの名前。
- ADDITIONAL_MEMORY_NODE_LABEL: 追加するメモリのノードラベル。上記の例のいずれかの値を使用します。

次のステップ

Cloud Logging エージェントに関連する問題が発生している場合は、エージェントのトラブルシューティングのドキュメントをご覧ください。
さらにサポートが必要な場合は、Cloud カスタマーケアにお問い合わせください。