共有VPCという制約の中で、AirbnbがCiliumを選んだ理由
Airbnb Staff Software EngineerのYifei Sun氏は、150以上のKubernetesクラスタをAWS VPC CNIからCiliumへ移行した道のりを語った。
Ciliumを選んだ主な理由は、eBPF（Linuxカーネルに起源を持つ、サンドボックス化されたプログラムを実行できる技術）の上に構築されたKubernetesネイティブなネットワーキングプラットフォームである点、そして活発なオープンソースコミュニティと幅広い業界での採用実績を持ち、長期的なネットワーキング基盤として進化し続けると確信できた点にある。
Airbnbにとって特に価値があった機能として、Yifei Sun氏は以下の5つを挙げる。1つ目は全クラスタにまたがるPodレベルのアクセス制御を可能にするクラスタ全体のネットワークポリシー、2つ目にトラブルシューティングを簡素化するネットワーク可観測性ツールのHubble、3つ目にクラウドプロバイダーのマネージドNATゲートウェイ（VPCなどからインターネットへ安全に通信するための管理型サービス）への依存を減らす、コスト効率の良いCilium egress gateway、4つ目に大規模環境でのボトルネックを避けるためiptables（Linuxパソコンやサーバーで通信を制限するためのファイアウォール機能を設定する仕組み）を取り除くkube-proxyの置き換え、そして最後がKubernetesネイティブなマルチクラスタネットワーキングを実現するマルチクラスタメッシュだ。
Airbnbは150を超えるKubernetesクラスタ、1万3000を超えるワーカーノードを運用しており、VPC CNIからCiliumへの移行をフルフリート全体で約8カ月かけて完了させた。中規模企業としては相応の規模の環境だとYifei Sun氏は振り返る。
ボトルネックはCiliumなのか、Amazon EC2 APIなのか
移行前、AirbnbはCilium operatorの性能テストを実施した。クラスタの大半が同じVPC上にあり、同一のAWSアカウントレベルのEC2 APIレート制限バケットを共有しているという制約の下、control planeの性能に焦点を当てた検証だ。
テストで答えを出したかったのは3つの問いだった。Ciliumがノード起動時間・Pod起動時間・スケジューリングのレイテンシに、特にSparkのようなデータ変更率が非常に高い環境でどう影響するか。大規模なノードプロビジョニングの際、ボトルネックはCilium自体なのか、それともAWS EC2 APIのレート制限なのか。そして、prefix delegation・pre-allocation・minimum allocationを含むIPAM設定（IPアドレス管理）を、最良の性能と効率のためにどうチューニングすべきか、という3点である。
検証では、大規模なノードプロビジョニング下でのノード起動時間を測るため300ノードを同時にプレスケールし、その後kube-burnerを使って10分間、毎秒100Podという持続的な負荷を生成してPod起動時間とスケジューリングのレイテンシを測定した。クラウドAPIの使用量も並行して計測している。
主な発見は3つあった。まず、IPが事前割り当てされている限りPod起動時間は速いままだったが、ノードの起動時間は約50％遅くなった。Ciliumが複数のinitコンテナを含む追加の初期化ロジックをノードのブートストラップ時に実行するためで、「Ciliumは単純にやることが多く、それだけブートストラップすべきことも多い」とYifei Sun氏は説明する。次に、大規模なノードプロビジョニングの際の主なボトルネックは、Cilium自体ではなくAWS EC2 APIのレート制限であることが分かった。そして、Prefix elegationはEC2 APIコールを60％以上削減できることも確認された。
