Amazon Elastic Kubernetes Service利用時におけるIPアドレス枯渇の原因とその対策について

高棹大樹

はじめに

こんにちは、NRIの高棹(たかさお)です。金融機関様向けのAmazon Elastic Kubernetes Service(以下EKS)を用いたマイクロサービス共通基盤のインフラを数年担当しています。

今回のブログでは比較的大規模なEKSクラスタを運用する上で考慮が必要である、IPアドレスの枯渇とその対策について解説します。

NRIでもEKSを用いた事例が増えてきており、社内から相談を受けることもあります。本ブログが現在EKS導入をご検討されている方、既にEKSクラスタ関連の業務に従事されている方の参考になればと思います。

Kubernetes・EKSについて

本題に入る前に少しKubernetes、EKSについて説明します。

Kubernetesとは

Kubernetesは複数のコンテナを効率良く管理するための所謂コンテナオーケストレーションツールです。Kubernetesの公式サイト(概要 | Kubernetes)では以下の様に紹介されています。

Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。Kubernetesは巨大で急速に成長しているエコシステムを備えており、それらのサービス、サポート、ツールは幅広い形で利用可能です。

Kubernetes自体非常に機能が豊富で拡張性も高く、またサードパーティのプロダクトも豊富であり、まさに1つのエコシステムを形成していると言えます。

その反面、構成コンポーネントが複数ありそれらが連動して稼働するため学習コストが高いプロダクトとも言われています。また約3ヶ月に1度のペースでリリースされる新バージョンにも追従する必要があるため、インフラ管理の負荷は比較的高いと考えられます。

EKSとは

その高い管理負荷を軽減すべく、各クラウドベンダーはKubernetesのマネージドサービスを提供しています。AWSはAmazon Elastic Kubernetes Service(EKS)という名前でサービスを提供しています。

EKSの主なメリットは、コントロールプレーンがAWSマネージドでありユーザ側の管理が不要、およびAWS IAMと認証処理を統合できる点が挙げられます。また、EKSはKubernetesバージョンの延長サポートを提供しており、追加費用は必要になりますがKubernetesの早いバージョンアップに追従する負荷を軽減する事が可能になっています。

AWS上でKubernetesクラスタを構築するのであれば、EKSを利用する事が第一の選択肢になると考えています。

EKSの利用イメージ

IPアドレスの枯渇について

ここからは本題のIPアドレスの枯渇について説明します。 EKSはクラスタ上で稼働するコンテナ(正確にはKubernetesリソースの1つであるPod)毎にIPアドレスを付与します。

また、EKSのデフォルトのContainer Networking InterfaceプラグインであるAmazon VPC CNI plugin for Kubernetes(以下VPC CNIプラグイン) は、Podに割り振るIPアドレスをAWS VPC上のサブネットから取得します。そのため、Podを複数起動する分サブネット内のIPアドレスを消費する事になります。

加えてEKSクラスタ内の各ワーカーノードは、その上でPodが起動するより先回りしてIPアドレスを複数確保する仕様となっています。これらが原因でサブネット内のIPアドレスが全て払い出されてしまうと新規で払出すIPアドレスがない、いわゆるIPアドレス枯渇状態になります。

IPアドレスが枯渇すると以下の症状が出てしまい、Podの追加リリースやEKSワーカーノード・Podのスケールアウトが正常に行えない状況になってしまいます。

「failed to assign an IP address to container」というメッセージを出力してPodが正常起動しない
EKSワーカーノードの新規追加に失敗する

IPアドレスが枯渇する流れ

対策1.EKSワーカーノードの起動サブネット追加

IPアドレス枯渇が発生してしまった場合の対策の1つとしてEKSワーカーノードが起動する対象のサブネットを追加する対応が挙げられます。EKSワーカーノードをセルフマネージド型ノードとして起動している場合に実行できる対策となります。マネージド型で起動している場合、サブネットの追加登録は行えません。

具体的にはサブネットをEKSワーカーノードのEC2 Auto Scalingグループに追加登録します。これによりEKSワーカーノードは追加したサブネットでも起動される様になります。ただし、この対策は以下の理由からIPアドレス枯渇のリスクが残ります。

EKSワーカーノードはEC2 Auto Scalingに登録されたサブネットの中の1つから起動されるが、対象サブネットの選定にIPアドレスの空き状況は考慮されない
EKSワーカーノードは単一のサブネットからネットワークインターフェース(Elastic network interface 以下ENI)を作成する仕様
※これはVPC CNIプラグインのデフォルトの挙動です。VPC CNIプラグインのカスタムネットワーキング機能を有効にする事で、2つ目以降のENIを1つ目のENIとは別のサブネットに作成する事が可能です。こちらについては次項で述べます。

そのためサブネットを追加しても、EKSワーカーノードがあるサブネットに偏ってしまい、それによって結局IPアドレスの枯渇が発生する可能性が残ります。特に、サービスイン後のEKSクラスタにサブネットを追加する場合、EKSワーカーノードが起動しているサブネットと新規のサブネットで既に空きIPアドレスに偏りが発生している状況になりますので、サブネット間のEKSワーカーノード配置を平準化する対応を合せて実施した方が良いと思います。

EKSワーカーノードの起動サブネットを追加した構成

対策2. VPC CNIプラグインのカスタムネットワーク機能を使用する

VPC CNIプラグインのカスタムネットワーク機能を有効化する事で、Podが利用できるサブネットをEKSワーカーノードのサブネットとは別に用意する事が可能です。

詳細な手順は以下のAWSドキュメントをご参照頂ければと思いますが、大まかな流れは以下となります。

docs.aws.amazon.com

VPC CNIプラグインのデプロイ先であるaws-node Pod(正確にはDaemonSet)に以下の環境変数を追加する
AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
Pod用に割り当てるサブネットを記載したVPC CNIプラグインの設定(kind: ENIConfigというKubernetesリソース)をデプロイする
EKSワーカーノードを起動する
Podをデプロイする

この機能を使う事でIPアドレス枯渇を解消させる事ができる可能性があります。ただし、VPC CNIプラグインの設定変更によりEKSワーカーノードのENI構成を変更する事になりますので、サービスイン後のEKSクラスタに対して実施する場合は検証環境で十分なノンデグ確認や移行手順検証が必要になると考えています。またカスタムネットワーク機能を有効化する事で、EKSワーカーノード用サブネットにはPodは起動されなくなる点についても、サブネットの効率的な利用の観点から意識する必要があります。

VPC CNIプラグインのカスタムネットワーク機能を使用する構成

対策3.EKSワーカーノードのIPアドレス事前確保設定チューニング

先述のとおり、EKSワーカーノードはPod起動を先回りしてIPアドレスを複数確保します。VPC CNIプラグインが持つパラメータの値を変更する事で、このIPアドレス確保の挙動をチューニングする事が可能です。具体的には以下のパラメータがあります。

「WARM_ENI_TARGET」

EKSワーカーノードが確保する余剰ENI数
デフォルトは1
余剰ENIとはそれに紐付くIPアドレスを持ったPodが1つも起動していないENIを指す
そのため、1つでもPodが起動すると余剰ENIが追加される

「WARM_IP_TARGET」

EKSワーカーノードに最低限確保したいIPアドレス数
デフォルトは指定無しで、ENIの最大IPアドレス数を確保する(m5.4xlarge だと30個)
小規模なクラスタや、Pod の起動停止が少ないことが想定される場合に設定
AWSのベストプラクティスとしては「小規模なクラスタや、Pod の起動停止が少ないことが想定される場合に設定」とのこと

「MINIMUM_IP_TARGET」

EKSワーカーノードが確保する余剰ENI数
デフォルトは指定無し
AWSのベストプラクティスとしては「あらかじめノード上にて起動される Pod の数が予測できる場合には、予測される Pod の数より少々多めに設定」とのこと

デフォルトの挙動はIPアドレスをやや過剰に確保していると個人的には思いますが、今後EKSクラスタに載ってくるPod数や起動停止数を事前に把握する事が難しいケースもあり、設定変更には注意が必要です。

対策4.十分大きな単一サブネットをEKSノードグループに登録

EKSクラスタやノードグループを新規構築するタイミングがあれば、十分大きな1つのサブネットをAZ毎に用意し、それをノードグループに登録する対応をとることができます。

これより、EKSワーカーノードの偏りも心配が無くなりますので、運用面を考慮すると一番良いと考えています。AWSもこの方針を推奨しています。 VPCのCIDRの追加(セカンダリCIDR)も行う事ができるので、既存のCIDRに空きが無い様でしたらこちらを利用する事も可能です。大きなサブネットを用意しておく事で、その後の維持・運用フェーズでIPアドレスの枯渇に悩まされる可能性を十分に低くする事ができるのでおすすめです。

大きい単一サブネットをEKSノードグループに登録する構成