大規模なCNI移行には「技術選定」以上の難所が存在する
移行中に想定していなかった教訓も2つあった。1つ目はMTU（Maximum Transmission Unit：1回の通信に送信できるデータの最大サイズ）にまつわるものだ。移行前はAWS VPC CNIがPodのMTUを9001にハードコードしていたのに対し、Ciliumのデフォルトは1500だった。その結果、UDPベースのDNS応答がCiliumのデフォルトMTUより大きいために、一部のDNSクエリが断続的に失敗する現象が発生した。根本原因がMTUの不一致にあることはすぐには分からず、当初は単なるDNSの問題のように見えたという。原因を特定した後の対処はシンプルで、VPC CNIと同じMTU=9001をCiliumに明示的に設定することで解決した。
2つ目はネットワークポリシーに関するものだ。移行中のリスクを減らすため全クラスタでネットワークポリシーを無効化し、Ciliumがすべてのトラフィックを許可することを期待していた。しかしCiliumの実際の挙動は、ネットワークポリシーを無効化すると内部的にデフォルトのallow-allポリシーを生成する、というものだった。
あるSparkクラスタではレースコンディションによってこのデフォルトのallow-allポリシーの生成に失敗し、Ciliumは「ポリシーが無効」ではなく「デフォルトポリシーが存在しない」状態と解釈してそのPodからの全トラフィックをブロックしてしまった。影響はSparkワークロードの起動失敗にまで及んだ。
この問題への対処として、Airbnbは移行期間中、監査モード（audit mode）を有効にした。たとえデフォルトのallow-allポリシーの生成に失敗しても、監査モードが有効であればトラフィックは引き続き通過を許可されるためだ。
150以上のクラスタ・1万3000を超えるノードを8カ月で移行しきったAirbnbの事例が示すのは、大規模なCNI移行の難所が技術選定そのものよりも、共有インフラの制約（EC2 APIレート制限）を見極めた性能検証、100以上のクラスタへ安全に届けるロールアウト設計、そして本番投入で初めて表面化する細部の設定差異への対応にあるということだ。
Yifei Sun氏は、PDのようなIPAMのチューニング、ノードレベルでのロールアウト制御、そしてMTUやネットワークポリシーといった一見地味な設定項目の見落としが、大規模移行の成否を分けることを一貫して示した。今回得られた教訓が、これから大規模なCilium移行に挑む他のエンジニアの助けになればとYifei Sun氏は語り、セッションを締めくくった。
