1台のサーバでいくつのコンテナを稼働させることができるだろうか。「Ubuntu」を開発するCanonicalはOpenStack Summitで、わずか16GバイトのRAMで、1台のIntelサーバ上に536個のLinuxコンテナを稼働できることを示した。これは素晴らしいことだが、ではそれらのコンテナをどうやってネットワークで結べばよいのだろうか。Canonicalは、答えはあると考えている。「Fanネットワーキング」だ。
Canonicalの創設者であるMark Shuttleworth氏は、「コンテナ生成について本当に苛立ちを感じることの1つは、容易にアクセスできるIPアドレスが不足していることだ」と説明している。
Shuttleworth氏はさらに、次のように続けている。「この仮想化全盛の時代に、数を確保するのが難しいというのは奇妙に思える。しかし、そうした制限は現実に存在するものだ。なぜなら、Amazon Web Services(AWS)は、ユーザーが仮想マシン(VM)上のインターフェースに結びつけられるIPアドレスの数を人為的に制限しているからだ。IPアドレスの数を増やしたければ、計算能力を増やす必要がなくても、より大規模なVMを購入する必要がある」
これは新しい問題ではない。1つのアプローチとして、それぞれのコンテナにIPv6アドレスを割り当てることが考えられる。多くのデータセンターは未だに、内部ネットワークにIPv4を使用している。Shuttleworth氏は、「クラウドではIPv6が全く使われていないので、アドレスはそもそも必要とされているよりも少ない」と考えている。
CoreOSは、コンテナのアドレッシングに関する問題の回避方法を生み出した。これは、初めは「rudder」と呼ばれていたが、現在は「flannel」という名前になっている。flannelでは、コンテナとIPアドレス、そしてそれらのホストマッピングについてのetcdデータベースが作成される。これは、任意の2地点間トンネルか、ホストマシン間のルートを作成して、コンテナが互いにやりとりできるようにするために使われる。Canonicalは、移行が必要ではない場合や、オーバーレイアドレスの典型的な番号がシステム内の全てのホストで類似する場合には、Fanネットワークの方がよりシンプルなアプローチだと主張している。
では、Fanはどのような方法をとるのだろうか。基本的に、FanはLinuxのネットワークトンネルドライバを拡張したものである。CanonicalのUbuntuクラウドソリューション担当プロダクトマネージャーであるDustin Kirkland氏は、次のように説明している。
各コンテナホストには「Fanブリッジ」があり、これによって、そのホストのコンテナ全てが、Fanネットワーク上のほかのあらゆるコンテナとのネットワークトラフィックを決定的にマッピングできるようになる。「決定的に」と言うのは、分散型データベースもなく、合意プロトコルもなく、IP間のトンネリング以上のオーバーヘッドもないという意味だ(より詳細な技術的説明はここで読むことができる)。端的に言えば、/16ネットワークが未使用の/8ネットワーク上にマップされ、コンテナトラフィックはホストによってIPトンネル経由で回送されるということだ。