要約

  • Spiro Stathakis は isp6 の注文管理基盤を IPv6 の EKS に載せ、互換性のために IPv4 サブネットを当初 /28 に絞った。
  • ノードの主インターフェースと二重スタックのエンドポイントがその枠を消費し、公開側は /27、非公開側は /26 に広げた。

「IPv6 のクラスタ」と呼べば、IPv4 は片隅に追いやれるように見える。isp6 の Spiro Stathakis は、まさにその片隅を /28 にした。RIPE Labs に寄せた本人の運用記録によると、注文管理基盤の EKS では Pod に自社割当ての IPv6 を与え、IPv4 は旧来の接続用として最小限にした。しかしアプリケーションより先に、周辺のインターフェースが枠を使い切った。

本人が選んだ /28 は AWS が認める最小の IPv4 サブネットで、総数は 16 アドレス。AWS は先頭の四つと最後の一つを予約するため、利用できるのは 11 だ。Stathakis は、ノードの主インターフェースと二重スタックのサービスエンドポイント用インターフェースがその余地を奪ったと報告する。結果として公開サブネットを /27、非公開サブネットを /26 にした。公開されたのは設計変更までで、各サブネットの現在の ENI 数は示されていない。

EKS の公式説明を読むと、IPv6 という指定の範囲が分かる。Pod とサービスは IPv6 を受け取る。一方、IPv4 しかない宛先へ出る Pod にはノード内だけで使う IPv4 も与えられ、送信元はノードの主 IPv4 に変換される。古い接続先でもアプリケーションは動き続けるが、その成功だけでは IPv4 経路が消えたことにならない。クラスタの IP ファミリーは作成時に決まり、後から変更できない。

Stathakis は IPv4 が必要な宛先のため NAT ゲートウェイを一つ残した。二重スタックの一部エンドポイントでは 443 番への入口を IPv6 に限定し、クライアントが A レコードを選んだ場合は黙って IPv4 に戻らず失敗させた。NAT のフローログは残る依存先を探す手掛かりになったという。現在の負荷を測るには、日付付きの ENI 台帳とフローログの実例が要る。

この事例で主役なのは設定画面ではなく、住所録の余白だ。Pod の IPv6 化は達成できる。ノードとエンドポイントの IPv4 使用量は、別の勘定として残る。最初の /28 は方針だった。必要なインターフェース数が実寸を決めた。