EKS production ready! part.2

awsにはeksというKubernetesのマネージドサービスが存在しています。このeksを本番環境で動かすまでに色々な問題が発生したので紹介したいと思います。part.1ではNodeが”NotReady”になってしまう問題を紹介しました。part.2ではcniに関する問題を紹介したいと思います。

Avaliable IP is “0”

今回紹介する問題はサブネットで利用可能なipが０になってしまった問題です。サブネットで利用可能なipが０になってしまうと新しくインスタンスが立ち上がらなくなったりと、運用する上で非常に危険な状態になってしまいます。eksを利用する前は80個くらいIPに余裕があったのに、eksを使い始めた瞬間、利用可能なIPが０になったのはなぜでしょうか？

amazon-vpc-cni-k8s

aws/amazon-vpc-cni-k8s

eksではデフォルトのcniとしてamazon-vpc-cni-k8sというものが使われています。このcniの特徴としてflannelのような仮想ネットワークを作るのではなく、vpc内の実際のIPをpodにアタッチするように働きます。よってvpcのIPを用いて直接podにアクセスするなんてことも可能になります。

このcniの挙動をざっくりと説明します。cniはec2インスタンスにアタッチされているeni毎にあらかじめ決められた個数のセカンダリIPをNodeの起動時にアタッチします。つまり一台のNodeが複数のvpcのIPアドレスを持つ状態にします。その後podがスケジュールされればそのセカンダリIPをpodにアタッチするといった動作をします。

この「セカンダリIPをあらかじめNodeにアタッチしておく」という仕様が今回の原因でした。

アタッチされるセカンダリIPの数はインスタンスタイプによって決まっていて以下から読み取ることができます。

Elastic Network Interface

ここから各インスタンスタイプのネットワークインターフェイスあたりの IP アドレス数を調べることができます。例としてm5.xlargeをみてみると一つのeniあたり15個のセカンダリIPをアタッチすることできるため、cniはその上限の15個のIPをサブネットから取得します。

つまりamazon-vpc-cni-k8sを利用している際にNodeとしてm5.xlargeを利用しているとNode一台あたりで16個のIPをサブネットから使われてしまいます。私が利用可能なIPが０になった時はm5.4xlargeが5台立つようになっていたので155個のIPがeksに持って行かれ、IP枯渇に陥りました。

対策

対策としてamazon-vpc-cni-k8sの1.5>からWARM_IP_TARGET という環境変数を設定するとIPの枯渇問題に立ち向かうことができます。

aws/amazon-vpc-cni-k8s

詳しくはリリース情報をみていただくと良いのですが、ざっくり説明するとWARM_IP_TARGETを設定すると使われてないIPをサブネットに返却します。これを設定するだけでかなり多くのIPを確保することができました。実際の設定例は以下のようになります。

containers:
  - image: 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.5.3
    imagePullPolicy: Always
    ports:
      - containerPort: 61678
        name: metrics
    name: aws-node
    readinessProbe:
      exec:
        command: ["/app/grpc_health_probe", "-addr=:50051"]
      initialDelaySeconds: 25
    livenessProbe:
      exec:
        command: ["/app/grpc_health_probe", "-addr=:50051"]
      initialDelaySeconds: 25
    env:
      - name: AWS_VPC_K8S_CNI_LOGLEVEL
        value: DEBUG
      - name: WARM_IP_TARGET
        value: "7"
      - name: AWS_VPC_K8S_CNI_LOG_FILE
        value: "stdout"
      - name: MY_NODE_NAME
        valueFrom:
          fieldRef:
            fieldPath: spec.nodeName

まとめ

vpcのIPをpodにアタッチするおかげで通信のオーバーヘッドが減ったり、既存のec2に乗っているアプリケーションから直接Podにアクセスできたりとメリットもありますが、cniの管理が必要になるというのはeksのあまりイケていない点だと思います。

[EKS]: Next Generation AWS VPC CNI Plugin · Issue #398 · aws/containers-roadmap

ですが、ロードマップのissueにもこの問題は出ているので今後に期待していきたいと思います。