EKS on FargateでMetrics Serverをインストールしたらエラーが出た

かずえ

2022.09.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

完全Fargate構成、つまりEC2ノードをゼロにしたEKSクラスターを作成しました。このクラスター上にて、一部のdeploymentのスケールを自動化すべくHPA(Horizontal Pod Autoscaler)を導入しました。しかし、途中問題が発生して結局HPA導入はひとまず断念しました。詳細をリポートします。

HPAのために Metrics Serverをインストールする

HPAは、CPU等のリソース使用率に基づいてdeployment等のPodの数を自動的にスケールする機能です。つまりリソース使用率を把握する必要があります。その役割を担うのがMetrics Serverです。Metrics ServerはEKSクラスターにはデフォルトではインストールされていませんので、HPAを利用するにはまずMetrics Serverをインストールする必要があります。インストール方法は以下を参照ください。

Metrics ServerをインストールしてHPA(Horizontal Pod Autoscaler)を使ってみる | DevelopersIO

Metrics Serverインストール後エラーログが大量発生

Metrics Serverのインストール自体は問題なく終わりました。が、インストール以降Metric ServerのPodが以下のようなログを吐き続けていることに気づきました。

\"Failed to scrape node\" err=\"Get \\\"https://192.168.106.50:10250/metrics/resource\\\": dial tcp 192.168.106.50:10250: connect: connection refused\" node=\"fargate-ip-192-168-106-50.ap-northeast-1.compute.internal\"

1分あたりだいたい10回以上このログを吐いています。Fluent Bit経由でCloudWatch Logsにログを転送していたので課金が気になります…

10250ポートはKubeletのデフォルトポート番号です。 Metrics Serverはリソース使用率をKubeletに問い合わせて取得しています。この問い合わせが失敗していることになります。

Metrics Serverがメトリクスを取得できていると、kubectl top node (node名)でノードのリソース使用率がわかります。が、上記ノードのメトリクス取得は失敗しました。

% kubectl top node fargate-ip-192-168-106-50.ap-northeast-1.compute.internal
Error from server (NotFound): nodemetrics.metrics.k8s.io "fargate-ip-192-168-106-50.ap-northeast-1.compute.internal" not found

※ 他のノードは取得できています。

% kubectl top node fargate-ip-192-168-96-204.ap-northeast-1.compute.internal                            
NAME                                                        CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
fargate-ip-192-168-96-204.ap-northeast-1.compute.internal   28m          1%     191Mi           5%

Metric Server Podが稼働している自身のNodeのKubeletにアクセスできていないことが判明

前述のエラーでアクセス失敗しているNodeは特定の一台のみということがわかりました。さらに調査を続けると、その一台というのが、エラーを吐いているMetric Server Pod自身が稼働しているFargate Nodeであることが判明しました。

% kubectl describe pod metrics-server-5c4bb95695-jhwvp -n kube-system | grep Node:
Node:                 fargate-ip-192-168-106-50.ap-northeast-1.compute.internal/192.168.106.50

さらに調査

さらに調査を続けると、Metrics ServerのGitHubリポジトリのIssueにてこのようなコメントを発見しました。

I had the same issue and opened a ticket with AWS support. This was their reply:

> I was able to replicate the same behaviour when tested in my lab environment. On further checking internally, I came to know that Fargate pods currently cannot ping the kubelet on the same node and this is by design. In other words, local pods cannot directly access the kubelet that is hosting them. Also, it is not planned to support local kubelet curl'ing on fargate nodes at this time. Apologies for the inconvenience that this limitation would have caused. Please help with your use-case so that I can suggest you an alternative workaround/ take your request forward as a feature request.

要約すると、AWSサポートが以下のように回答したとのことでした。