EKS(Kubernetes)でノードグループのステータスがDEGRADEDになった時の対処法

EKS でノードグループを追加して、既存のノードグループから pod を drain して移す定番作業。

この作業自体は問題なかったのですが、よくよく見てみると新しく追加したノードグループのステータスが「DEGRADED」と見慣れないものになっていました。

今回は、この原因と解決方法を紹介します。

エラーの内容

DEGRADED となる原因は色々とあると思いますが、AWS コンソール上の EKS 画面でノードグループを見てみると、「ヘルスの問題」のタブに以下の記載がありました。

AsgInstanceLaunchFailures Could not launch On-Demand Instances. InsufficientInstanceCapacity – We currently do not have sufficient r6a.xlarge capacity in the Availability Zone you requested (ap-northeast-1a). Our system will be working on provisioning additional capacity. You can currently get r6a.xlarge capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1c, ap-northeast-1d. Launching EC2 instance failed.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html

どうやら「インスタンス容量の不足」ということで、ap-northeast-1a の A/Z から r6a.xlarge の EC2 インスタンスが起動できなかったとのことでした。

原因の特定

サブネットの空き IP アドレスは確認していたのですが、確かに 1c と 1d だけが極端に減っているなとは思いました。

まさか 1a のゾーンだけ r6a.xlarge のインスタンスが在庫切れになっているとは・・・。

確かに起動している EC2 はすべて 1c と 1d のもので、同じ作業を行った別の環境でも同様の事象が発生していました。

対処法

リザーブドインスタンスを契約していたり、キャパシティ予約をして特定のインスタンスタイプを確保していれば問題ないのでしょう。

しかし残念ながら、今回の AWS アカウントでは「Savings Plans」の契約をしているので、そこまでの保証はありません。

そこで、新しく EC2 インスタンスをいくつか起動してみましょう。

これで 1a から起動してこれば、他のゾーンのインスタンスを縮退させてバランスを整えたらいいですからね。

それでも起動してこない場合は状況を見守るしかないですね。

1a から起動が可能になれば、そのうち、この問題は解消されると思わます。
(翌朝には 1a の EC2 インスタンスでノードが立ち上がっていました)

まとめ

ノードグループが「DEGRADED」ステータスになった時の状況について紹介してきました。

今回のケースでは、特定のアベイラビリティゾーンでの特定のインスタンスタイプの EC2 が起動できないというものでした。

幸い 3 つのサブネットでそれぞれ別のゾーンを構成しているので、残り 2 つのゾーンで対処はできました。

しかし、複数のゾーンをまたいで同じ pod を冗長化させたい場合など、片方のゾーンでノードが起動できないとなると困りますよね。

しかもインスタンスタイプはノードグループ単位で設定するので、別のインスタンスタイプにすぐに切り替えることもできないですし・・・。

saratoga

フリーランスエンジニア

XYouTube

仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。