AWS
PR

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

saratogax
記事内に商品プロモーションを含む場合があります

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 インスタンスが起動できなかったとのことでした。

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.

原因の特定

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

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

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

対処法

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

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

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

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

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

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

まとめ

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

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

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

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

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

EKS のマネージドノードグループまわりでは、以下の記事もあわせてどうぞ。

あわせて読みたい
EKS(Kubernetes)でマネージド型ノードグループに複数のEC2インスタンスタイプを指定する
EKS(Kubernetes)でマネージド型ノードグループに複数のEC2インスタンスタイプを指定する
あわせて読みたい
EKSでマネージドノードグループに使用しているEC2のディスク使用量を確認する
EKSでマネージドノードグループに使用しているEC2のディスク使用量を確認する

EKS のネットワーク周りでは、VPC CNI plugin のエラーにも遭遇しやすいです。

あわせて読みたい
Amazon VPC CNI pluginで「Logger.check error: failed to get caller」
Amazon VPC CNI pluginで「Logger.check error: failed to get caller」

ロードバランサ周りでは、AWS Load Balancer Controller のアップグレードも要注意です。

あわせて読みたい
AWS Load Balancer Controller v2.4系からのアップグレード完全ガイド
AWS Load Balancer Controller v2.4系からのアップグレード完全ガイド

EKS クラスタの操作に使う eksctl の安全なインストール方法は、以下の記事を参照してください。

あわせて読みたい
Macのbrewを使ったeksctlインストールは非推奨に!安全なインストール方法
Macのbrewを使ったeksctlインストールは非推奨に!安全なインストール方法
ABOUT ME
saratoga
saratoga
フリーランスエンジニア
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
記事URLをコピーしました