スキップしてコンテンツを表示
AWS re:Postを使用することにより、以下に同意したことになります AWS re:Post 利用規約
AWS re:Postre:Post
re:Postに関して

Amazon EKS のメトリクスサーバーを使用してコンテナ、ポッド、またはノードからメトリクスを収集できない理由を教えてください。

所要時間4分
0

Amazon Elastic Kubernetes Service (Amazon EKS) クラスター内のメトリクスサーバーを使用して、コンテナ、ポッド、またはノードからメトリクスを収集できません。

解決策

Amazon EKS はメトリクスサーバーを自動的にインストールしません。クラスターを最近作成したのにメトリクスサーバーを使用してメトリクスを収集できない場合は、メトリクスサーバーアプリケーションをクラスターにデプロイしたことを確認してください。

それでもメトリクスサーバーでメトリクスを収集できない場合は、次のセクションの手順を実行します。

注: メトリクスサーバーは、アプリケーションとクラスターのパフォーマンスを長期的にモニタリングするための最適な手段ではありません。長期的なモニタリングについては、Kubernetes ウェブサイトの「Resource management for pods and containers」(ポッドとコンテナのリソース管理) を参照してください。Kubernetes コミュニティはメトリクスサーバーを管理し、GitHub ページで問題を報告しています。詳細については、メトリクスサーバーの GitHub ページにある「Issues」(問題) を参照してください。

クラスターのノードとポッドからメトリクスを取得できるかどうかを確認する

クラスターのノードとポッドからメトリクスを取得できるかどうかを確認するには、次のコマンドを実行します。

kubectl top nodes
kubectl top pods

注: どちらのコマンドからもエラーが表示されない場合は、「APIService が利用可能で、リクエストを処理できるかどうかを確認する」セクションを参照してください。

上記のコマンドからエラーを受け取った場合は、受け取ったエラーに基づいて、次のいずれかのセクションの手順を実行します。

"Error from server (Forbidden)" エラーメッセージ

ロールベースのアクセスコントロール (RBAC) 認証に問題がある場合は、"Error from server (Forbidden)" エラーメッセージが表示されます。

このエラーを解決するには、次の手順を実行します。

  • ServiceAccount がデプロイに正しくアタッチされていることを確認します。
  • ClusterRole/Role および ClusterRoleBinding/RoleBindings がメトリクスサーバーの正しい RBAC アクセス許可を使用しているようにしてください。詳細については、Kubernetes のウェブサイトで「Using RBAC authorization」(RBAC 認可を使用する) を参照してください。

aws-auth ConfigMap で定義されたロールを介してクラスターにアクセスする場合は、username フィールドとマッピングを設定していることを確認します。

次の手順を実行します。

  1. aws-auth ConfigMap の内容を表示するには、次のコマンドを実行します。

    kubectl describe -n kube-system configmap aws-auth

  2. 上記のコマンドの出力を確認して、username フィールドがクラスターにアクセスするロールに設定されていることを確認します。
    出力例:

    Name:         aws-auth
Namespace:    kube-system
Labels:       
Annotations:  <none>

Data
===
mapRoles:
----
...
- groups:
  - system:masters
  rolearn: arn:aws:iam::123456789123:role/kubernetes-devops
  username: devops:`SessionName`

    出力で username が指定されていることを確認してください。

"Error from server (ServiceUnavailable)" エラーメッセージ

メトリクスサーバーが正しく設定されていない場合、"Error from server (ServiceUnavailable)" というエラーメッセージが表示されます。

クラスター内のメトリクスサーバーサービスアプリケーションの設定に問題がないか確認するには、以下のコマンドを実行します。

kubectl describe apiservices v1beta1.metrics.k8s.io

出力例:

Name:         v1beta1.metrics.k8s.io
Namespace:
Labels:       app=metrics-server
...
Status:
  Conditions:
    Last Transition Time:  2020-01-09T13:57:23Z
    Message:               all checks passed
    Reason:                Passed
    Status:                True
    Type:                  Available
Events:                    <none>

メトリクスサーバーサービスが利用可能で、チェックに合格すると、Status は True に設定されます。

注: Status を True に設定しても問題が解決しない場合は、「APIService が利用可能で、リクエストを処理できるかどうかを確認する」セクションを参照してください。

Status が False に設定されている場合は、出力の Reason コードで、人間が判読できる Conditions についての Message を探します。

失敗した APIService の例:

...
Status:
  Conditions:
    Last Transition Time:  2020-01-09T14:40:28Z
    Message:               no response from https://10.0.35.231:443: Get https://10.0.35.231:443: dial tcp 10.0.35.231:443: connect: connection refused
    Reason:                FailedDiscoveryCheck
    Status:                False
    Type:                  Available

注: Reason が FailedDiscoveryCheck でない場合は、「その他の APIServer 条件障害の理由」セクションを参照してください。APIServer Conditions Message に Client.Timeout exceeded while awaiting headers が含まれている場合は、「"Client.Timeout exceeded while awaiting headers" というエラーを解決する」セクションを参照してください。APIServer Conditions Message に Connection refused が含まれている場合は、「"Connection refused" エラーを解決する」セクションを参照してください。

"Client.Timeout exceeded while awaiting headers" というエラーを解決する

セキュリティグループまたはネットワークアクセスコントロールリスト (ネットワーク ACL) を正しく設定しなかった場合、APIService に "Client.Timeout exceeded will awaiting headers" というエラーメッセージが表示されます。この場合、metrics-server ポッドにアクセスできなくなります。

このエラーを解決するには、セキュリティグループが Amazon EKS の最小トラフィック要件を満たしていることを確認します。

"Connection refused" エラーを解決する

コンテナが間違ったポートでリッスンすると、"Connection refused" というエラーメッセージが表示されます。

このエラーを解決するには、次のコマンドを実行して、metrics-server デプロイの ports、image、および command の値が正しいことを確認します。

kubectl describe deployment metrics-server -n kube-system

出力例:

Name:                   metrics-server
Namespace:              kube-system
CreationTimestamp:      Wed, 08 Jan 2020 11:48:45 +0200
Labels:                 app=metrics-server
...
  Containers:
   metrics-server:
    Image:      gcr.io/google_containers/metrics-server-amd64:v0.3.6
    Port:       443/TCP
    Command:
    - /metrics-server
    - --logtostderr
    - --secure-port=443
...

注: Command と Image の値は、メトリクスサーバーのデプロイ方法とイメージの保存場所によって異なります。Command に --secure-port パラメータが含まれている場合、ポッドによって公開されるポートはこのパラメータと一致する必要があります。Command に --secure-port パラメータが含まれていない場合、ポートはデフォルトで 443 になります。

その他の APIServer 条件障害の理由

APIService の次のコードのいずれかを受け取った場合は、関連するエラーメッセージに基づいて対応します。 ServiceNotFound、ServiceAccessError、ServicePortError、EndpointsNotFound、EndpointsAccessError、または MissingEndpoints。

これらのエラーを解決するには、次の手順を実行します。

  1. エラーが発生したサービスの情報を取得するには、以下のコマンドを実行します。

    kubectl get service -n kube-system

    この出力で、Kubernetes サービスの名前と名前空間が、APIService.Spec.Service で定義されているものと同じであることを確認します。次に、ポートが 443/TCP に設定されていることを確認します。
    出力例:

    NAME                             TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
metrics-server                   ClusterIP   172.20.172.133   <none>        443/TCP    65m

  2. 次のコマンドを実行して、すべてのエンドポイントを一覧表示します。

    kubectl get endpoints metrics-server -n kube-system

    この出力で、metrics-server サービスのエンドポイントが少なくとも 1 つあることを確認します。
    出力例:

    NAME             ENDPOINTS         AGE
metrics-server   10.0.35.231:443   76m

  3. 次のコマンドを実行して、デプロイが存在し、ラベルが metrics-server サービスのラベルと一致していることを確認します。

    kubectl describe deploy metrics-server -n kube-system

    この出力で、デプロイに少なくとも 1 つのレプリカがあることを確認します。
    出力例:

    Name:                   metrics-server
Namespace:              kube-system
CreationTimestamp:      Wed, 08 Jan 2020 11:48:45 +0200
Labels:                 app=metrics-server
                        release=metrics-server
...
Selector:               app=metrics-server,release=metrics-server
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
...
Pod Template:
  Labels:           app=metrics-server
                    release=metrics-server
  Service Account:  metrics-server
  Containers:
   metrics-server:
    Image:      gcr.io/google_containers/metrics-server-amd64:v0.3.6
...

それでもメトリクスサーバーでメトリクスを収集できない場合は、「APIService が利用可能で、リクエストを処理できるかどうかを確認する」セクションを参照してください。

APIService が利用可能で、リクエストを処理できるかどうかを確認する

次のコマンドを実行して、メトリクスサーバーポッドからログを抽出します。

kubectl logs -n namespace -l app=metrics-server

注: namespace を実際の名前空間に置き換えてください。
エラーログの例:

E0610 23:13:28.247604       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:13:43.260069       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-nv8sz: no metrics known for pod "default/php-apache-b5f58cc5f-nv8sz"
E0610 23:16:13.346070       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-cj67b: no metrics known for pod "default/php-apache-b5f58cc5f-cj67b"
E0610 23:16:13.346087       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-sqc6l: no metrics known for pod "default/php-apache-b5f58cc5f-sqc6l"
E0610 23:16:13.346091       1 reststorage.go:98] unable to fetch pod metrics for pod default/php-apache-b5f58cc5f-4cpwk: no metrics known for pod "default/php-apache-b5f58cc5f-4cpwk"

注: メトリクスサーバーのエラーログには、メトリクスサーバーデプロイコマンドの設定上の問題がある、またはメトリクスサーバーコンテナのバグがあることが示されます。エラーメッセージがはっきりしない場合や、バグの疑いがある場合は、「GitHub で一般的な問題を確認する」セクションの手順を実行してください。

GitHub で一般的な問題を確認する

それでもコンテナ、ポッド、またはノードからメトリクスを収集できない場合は、メトリクスサーバーに関する一般的な問題を GitHub で確認します。詳細については、メトリクスサーバーの GitHub ページにある「Issues」(問題) を参照してください。

不明なメトリクスについて、HorizontalPodAutoscaler (HPA) とアプリケーションリソースリクエストを確認するには、次の手順を実行します。

  1. 次のコマンドを実行して HPA の設定を確認します。

    kubectl get hpa -n namespace 2048-deployment

    注: namespace と 2048-deployment をアプリケーションの HPA 設定値に置き換えてください。
    <unknown> が出力の Target 列の下に表示される場合があります。
    出力例:

    NAME              REFERENCE                    TARGETS         MINPODS   MAXPODS   REPLICAS   AGE  
2048-deployment   Deployment/2048-deployment   <unknown>/80%   1         2         2          10s

  2. 数分待ってから、手順 1 のコマンドを繰り返します。
    それでも "<unknown>" エラーが発生する場合は、以下のコマンドを実行します。

    kubectl describe hpa -n namespace 2048-deployment

    注: namespace を実際の名前空間に置き換えてください。
    次に、出力の Events セクションで詳細を確認します。
    出力例:

    Name:                                                  2048-deployment
Namespace:                                             2048-game
...
Metrics:                                               ( current / target )
  resource cpu on pods  (as a percentage of request):  <unknown> / 80%
Min replicas:                                          1
Max replicas:                                          2
Deployment pods:                                       2 current / 2 desired
Conditions:
  Type           Status  Reason                   Message
  ----           ------  ------                   -------
  AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
  ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: missing request for cpu
Events:
  Type     Reason                   Age                     From                       Message
  ----     ------                   ----                    ----                       -------
  Warning  FailedGetResourceMetric  3m29s (x4333 over 19h)  horizontal-pod-autoscaler  missing request for cpu

    注: Message 列に missing request for [x] が表示される場合は、デプロイや ReplicaSet の仕様に合ったリソースリクエストを宣言していない可能性があります。ポッド内のすべてのコンテナにリクエストが宣言されていることを確認します。リクエストを省略すると、HPA のメトリクスは <unknown> レスポンスを返します。
    詳細については、Kubernetes ウェブサイトの「Resource management for pods and containers」(ポッドとコンテナのリソース管理)、「Deployments」(デプロイ)、および「ReplicaSet」を参照してください。

トピック
Containers
タグ
Amazon Elastic Kubernetes Service
言語
日本語
AWS公式更新しました 6ヶ月前
コメントはありません

関連するコンテンツ