TL;DR
- EKSのコンソール画面からノードグループを追加するとき、AMIタイプタイプをAmazon Linux 2023にすると AWS Loadbalancer Controllerが立ち上がらなくなることがある
- 原因は、Amazon Linux 2023から、IMDSv2が必須設定になっておりIMDSv1が使えない
- とりあえずノードグループを作成するときはAmazon Linux 2で作っておくのが良さそう
発生したこと
開発用のEKSクラスターでは、コスト削減のためにスポットインスタンスのみ利用してきました。
ある程度時間がかかるジョブのテストを行うために、オンデマンドインスタンスで新たなノードグループを追加し、スポットインスタンスを利用するノードグループを削除しました。
すると、AWS Loadbalancer ControllerのPodが立ち上がらなくなりました。
ログには以下のようなエラーログが。
failed to introspect region from EC2Metadata, specify --aws-region instead if EC2Metadata is unavailable
原因調査
IMDS
AWS EC2インスタンスにはIMDS（Instance Metadata Service）というものがあります。
これは、EC2インスタンスのメタデータを取得できるものです。
このIMDS経由でIAMロールの一時的な認証情報をとることができるというのがポイントです。
IMDSには２つのバージョンがあります。
-
IMDSv1（旧バージョン）
HTTPリクエストでメタデータに直接アクセス可能（curl http://169.254.169.254/latest/meta-data/）
セキュリティ上のリスク（サーバーサイドリクエストフォージェリ（SSRF）攻撃の可能性） -
IMDSv2（セキュリティ強化版）
セッションベースのトークン認証を導入
PUT リクエストでトークンを取得し、そのトークンを使ってメタデータを取得
IMDSのホップ制限
IMDSv2のPUTリクエストは、ネットワークホップの上限が１となっています。
EC2の中で動くコンテナからのリクエストはネットワークホップが２になってしまうため、認証情報をとることができなくなっています。
IMDSv2の強制
調べてみると、EC2インスタンスのAMIタイプにおいてAmazon Linux 2では、IMDSv1もサポートしていますが、Amazon Linux 2023からはIMDSv1が使えなくなっている様子。
なので認証情報が取れなくなってしまったわけですね。
ノードグループを新たに追加するときに、デフォルト設定が変わっているのでした。
EC2の管理画面で、どうなっているか確認できます。
AMIタイプタイプにAmazon Linux 2023を指定したインスタンスは、IMDSv2しか使えない
AMIタイプにAmazon Linux2を指定したインスタンスは、IMDSv1も使える
解決策の調査
根本的な解決策
根本的な解決策としては、IMDSv2のホップ制限を増やすことです。
しかし残念ながら、EKSのコンソールをぽちぽちしてノードグループを作る際には変更することができません。
既存インスタンスについて、PUTリスポンスホップリミットの設定を変更することができます。
現在、PUT 応答ホップ制限の変更をサポートしているのはAWS CLI と AWS SDK のみです。
パッチ的な解決策
とりあえず、EKSでノードグループを追加するときにはAMIタイプタイプにAmazon Linux2を使い続けましょう。
