KubernetesでWorker Nodeのメトリクスを取るmetrics-serverの謎

 Posted on July 28, 2019  |  4 minutes  |  2001 words  |  Yu Ichijo

Kubernetesの記事の書きたい内容があまり思いつかない問題

クソザコエンジニアのjaramonです。（これは自戒の念を込めて毎回言おうかと思います。）

初めてKubernetesの記事を書こうと思うのですが、正直言うと全てが新鮮な知識なので何から書けばいいか分からなくなってます。 それに最近はKubernetesの記事をたくさんの方が書いていますので、内容が被るなぁと。 ありがたいことに、それらの記事は「こういう手順で導入すればうまくいくよー！」という記事ばかり。

でも世の中そんなにすんなりいかない！！！

そんなすんなりいかないこと、困っていることも記事にしようと思いました。 と言うわけで、今回の記事は最終的にまじ分からんくて困っていますという結論になっていますのでご了承くださいｗｗｗ

（読者対象はKubernetesの基本的な用語を知っている方を想定しているため、詳細の説明は割愛させていただきます。）

metrics-serverって？

Kubernetesには HorizontalPodAutoscaler(HPA) というAPIがあります。 Podを管理するReplicaSetやDeploymentなどをターゲットとして、CPUなどのメトリクスを条件にPodの数を動的にすることが出来る強力な機能です。

このHPAを使用するに当たり、各種メトリクスを取得する必要があるのですが、metrics-server はその名の通りメトリクスを取ってきてくれるツールです。

謎って？

このmetrics-serverを導入したところ、ちゃんとPodがメトリクスに応じて増減して感動しました。 ですが、そんなmetrics-serverにも秘密があったのです。

hpaのメトリクスが<unknown>になる

metrics-server導入直後に kubectl get hpa では正しくCPUが取得できていたのですが、ある時からCPUが <unknown>/20% と表示されるようになりました。 導入手順はAWSさんの記事通り。なんだこれはと思って色々調べました。

  • Aさん < 証明書がうんたらこーたらでこのオプションつけたらうまくいったよー！
  • Bさん < いやーそのオプションはそもそもあまり推奨してないけど本当にそれで大丈夫？

えぇ。。。怖いよ。。。

エラーの内容たくさん調べたけど、どこでも↑の内容がGitHubのissueで議論されていて、何が正解か分からなくなりました。 そしてふとDeploymentのPodたちを見ると、 CrashLoopBackOff と書かれているPodが。。。

（あれ、Deploy失敗したかぁ。。。多分アプリ側のエラーだしまた連携してあげなky。。。 いや待てよ。。。犯人こいつじゃね？）

まだ未熟な環境だったので、k8sのデプロイに失敗しても気づくことが出来ない状態だったのですが、調べると１週間くらい前からこの状態だったっぽいです。 アプリ側の修正をしてもらい、正常なPodがデプロイされてから確認したところ、無事にCPUの値が取得できてました！！

RunningのPodだけが存在する状態じゃないと取得できないそうです。 （ちなみにこの仕様はちゃんと書いてありました。ごめんなさい。）

metrics-serverのログに謎エラー

これがまじ分からん状態のお話です。 unknownになっていたのでちゃんと kubectl logs でmetrics-serverのログを見てみると

E0728 18:54:20.604877       1 reststorage.go:147] unable to fetch pod metrics for pod hoge/fugafuga: no metrics known for pod
E0728 18:54:20.604912       1 reststorage.go:147] unable to fetch pod metrics for pod hoge/peropero: no metrics known for pod
E0728 19:15:49.026173       1 reststorage.go:128] unable to fetch node metrics for node "mojamoja": no metrics known for node

こんなのがズラーっと並んでおりました。 それでも、 kubectl top node や kubectl top pod コマンドは正しく取得できています。

？？？

これもたくさん調べて、以下の内容を確認してみようと言われました。

  • metrics-serverのcommandsに --kubelet-insecure-tls の引数を追加して起動したらうまくいくよ！
  • metrics-serverのcommandsに --kubelet-preferred-address-types=InternalIP の引数を追加して起動したらうまくいくよ！
  • EKSのCluster Controle PlaneとWorker Nodeのセキュリティグループに443のインバウンドとアウトバウンドを追加するとうまくいくよ！

全部うまくいきませんでした。結局エラーは出たままです。誰か助けてください。

謎と書きましたが。。。

結局は私の理解不足なんですよね。 エラーについては本当に分からないのですが、無事にオートスケーリングは出来ているからさらに謎が深まるばかりです。 解決したらそれもちゃんと追記しようかと思います。

追記(8⁄28)

少しだけ謎が解けました。 出てきたエラーのPodを確認したところ、またしても CrashLoopBackOff 状態で正しく起動できていないPodでした。 検証はしていませんが、 <unknown> が解消された後にPodの起動に失敗した場合は、 メトリクスが取れないので kubectl top で取得する値が更新できず、最後に取得できた時の値になっているのではないかと予測しております。

CrashLoopBackOff 状態のPodを修正して正しく起動させたらエラーが消えてくれました！！！

Kubernetes