はじめに
こんにちは、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を利用する事が第一の選択肢になると考えています。
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ワーカーノードの新規追加に失敗する
対策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ワーカーノード配置を平準化する対応を合せて実施した方が良いと思います。
対策2. VPC CNIプラグインのカスタムネットワーク機能を使用する
VPC CNIプラグインのカスタムネットワーク機能を有効化する事で、Podが利用できるサブネットをEKSワーカーノードのサブネットとは別に用意する事が可能です。
詳細な手順は以下のAWSドキュメントをご参照頂ければと思いますが、大まかな流れは以下となります。
- 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は起動されなくなる点についても、サブネットの効率的な利用の観点から意識する必要があります。
対策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クラスタ運用におけるIPアドレス枯渇のメカニズムとその対策について述べました。 自分の経験からもサービスイン後にIPアドレス枯渇の対策を行うのは色々大変でしたので、EKSクラスタの設計段階から考慮しておくのが一番だと思い、今回ブログを執筆しました。
事前にどれだけPodを起動するのかを十分把握しつつ、そこから十二分に余裕を持ったサブネットを用意しておく事がシンプルですが一番重要だと考えています。このブログが皆様のEKSクラスタ設計や運用にお役に立てれば幸いです。お困りのことなどありましたらお問い合わせ先までお気軽にご相談ください。
お問い合わせ
atlax では、ソリューション・サービス全般に関するご相談やお問い合わせを承っております。
関連リンク・トピックス
・atlax / クラウドの取り組み / AWS(Amazon Web Services)
-
採用情報
NRIの IT基盤サービスでは、キャリア採用を実施しています。様々な職種で募集しておりますので、ご興味を持たれた方は キャリア採用ページも ぜひご覧ください。
※ 記載された会社名 および ロゴ、製品名などは、該当する各社の登録商標または商標です。