このページは Cloud Translation API によって翻訳されました。

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

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 は、ノードに接続されている IAM サービスアカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。少なくとも、これらのノードサービスアカウントには、プロジェクトに対する Kubernetes Engine デフォルトノードサービスアカウント（roles/container.defaultNodeServiceAccount）ロールが必要です。デフォルトでは、GKE はプロジェクトで自動的に作成される Compute Engine のデフォルトのサービスアカウントをノードサービスアカウントとして使用します。

組織で iam.automaticIamGrantsForDefaultServiceAccounts 組織のポリシー制約が適用されている場合、プロジェクトのデフォルトの Compute Engine サービスアカウントに GKE に必要な権限が自動的に付与されないことがあります。

問題を特定するには、クラスタのシステムモニタリングワークロードで 401 エラーを確認します。
```
[[ $(kubectl logs -l k8s-app=gke-metrics-agent -n kube-system -c gke-metrics-agent | grep -cw "Received 401") -gt 0 ]] && echo "true" || echo "false"
```
出力が true の場合、システムワークロードで 401 エラーが発生しています。これは、権限がないことを示します。出力が false の場合は、残りの手順をスキップして、別のトラブルシューティングの手順を試します。

Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与する手順は次のとおりです。

console

[ようこそ] ページに移動します。
[ようこそ] に移動
[プロジェクト番号] フィールドで、 [クリップボードにコピー] をクリックします。
[IAM] ページに移動します。
[IAM] に移動
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに次の値を指定します。
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
```
PROJECT_NUMBER は、コピーしたプロジェクト番号に置き換えます。
[ロールを選択] メニューで、[Kubernetes Engine のデフォルトノードサービスアカウント] ロールを選択します。
[保存] をクリックします。

gcloud

Google Cloud プロジェクト番号を確認します。
```
gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"
```
PROJECT_ID を実際のプロジェクト ID に置き換えます。

出力は次のようになります。
```
12345678901
```
Compute Engine のデフォルトサービスアカウントに roles/container.defaultNodeServiceAccount ロールを付与します。
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAccount"
```
PROJECT_NUMBER は、前の手順で取得したプロジェクト番号に置き換えます。

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

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

ほとんどの場合、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 カスタマーケアにお問い合わせください。