Project Calicoとはなにか

はじめに

著者が所属する沖縄オープンラボラトリでは、SDNやクラウドコンピューティング技術の普及のための基盤技術研究を行っています。現在の研究活動としては、OPNFVのコミュニティ活動を通してOPNFVの活性化とすそ野拡大を目指す「OPNFV」やONOS/CORDのユースケース検証を行う「ONOS/CORD検証」、ネットワークテスト自動化を目指す「ネットワーク自動テストシステム」、といったプロジェクトが活動しています。こういった取り組みの一環として、2017年度に「Project Calico」について調査・検証を行ってきました。

Project Calicoはピュアレイヤー３アプローチのネットワークであり、従来のネットワークやSDNとは少し特性が異なります。本連載ではProject Calicoが登場した背景や技術的な特徴などに加え、Calicoを使ったKubernetes環境の構築方法や使い方を解説していきたいと思います。

Project Calico概要

Project Calicoとは

Project Calico（以降、Calicoと呼称する）は、コンテナや仮想マシンなどに対してシンプルでスケーラブルなネットワークとセキュリティポリシーの機能を提供するオープンソースプロジェクトです。Calicoはオーケストレータとともに使用することが前提となっており、OpenStackやKubernetes、Mesos、Docker、rktといったプロジェクトとインテグレーションされています。特に、セキュリティポリシーの機能は、KubernetesのネットワークポリシーやサービスメッシュのIstioなどの実装としても注目されています。Calicoは2014年にイギリスのMetaswitch社によってOSSプロジェクトとして発表され、GitHub上でソースコードが公開されました。現在は、CoreOS社（後にRed Hatに買収された）とともに設立されたTigera社がCalicoの開発を主導しています。

Project Calicoが登場した背景

Calicoが登場した背景として運用面やスケーラビリティの課題、さらにはコンテナ技術の盛り上がりといったトレンドなどがあると考えられます。

オーバーレイネットワークによる運用の複雑化

オーバーレイネットワークはOpenStackなどのクラウド環境で多く利用されています。具体的にはVXLANやGREなどがあり、オーバーレイを使用することによって、VLANの規格上の最大値である4096よりも大きな仮想ネットワークを作成できるようになりました。しかし、物理ネットワークとは独立した仮想的なネットワークが作成されるため、運用やトラブルシューティングが複雑化するという課題が出てきました。

スケーラビリティの課題

オーバーレイネットワークを使用すると、L2セグメントが複数のサーバー及びデータセンター全体に広がることになります。物理ネットワークに依存しないのは利点ではあるのですが、問題になるのがBUMトラフィックやEast-Westトラフィックです。大規模な環境ほどより多くのARPパケットが飛び交うようになり、スケーラビリティに影響してきます。

クラウドネイティブのトレンド

KubernetesはCNCFのプロジェクトにもなっており、クラウドネイティブコンピューティングの基盤として注目されています。クラウドネイティブ環境で実行されるコンテナのライフサイクルは、分または秒単位というように非常に高速なものになっています。その高速なライフサイクルに合わせてネットワークも柔軟に追従する必要性が出てきました。

これらの課題やトレンドに対して、Calicoではオーバーレイを使わず、フルフラットなL3ネットワークというアプローチをとっています。

Calicoの技術的な特徴

Project Calicoホームページより引用

SDNコントローラが不要

Calicoの大きな特徴の一つとしてSDNコントローラが存在しないことがあげられます。一般的なSDNでは、SDNコントローラが物理スイッチまたは仮想スイッチを中央集権的に制御しています。Calicoではすべてのノード間の経路情報がBGP（Border Gateway Protocol）によってノード間で交換されており、中央集権的なSDNコントローラが不要になっています。

オーバーレイを使わない

OpenStackでCalicoプラグインを使用した場合、Neutron上では同一サブネットに属していても実際はIP通信になります。MACアドレスを解決する必要が無いので、ARPパケットは飛び交いません。Kubernetesでも、すべてのPod間はIP通信を行います。これによって、オーバーレイで課題となったBUMトラフィックやEast-Westトラフィックを無くすことができます。さらに、オーバーレイではカプセル化のCPUオーバーヘッドやヘッダ情報が付加されることでMTU値が小さくなってしまう問題がありましたが、Calicoにおいてはこういった問題による性能低下は発生しません。オーバーレイを使用しないことによりトラブルシュートがしやすいというメリットもあります。

ネットワークポリシー

Calicoはネットワークポリシーというファイアウォール機能を持っています。ネットワークポシリーを使用することで、インターフェースに対して柔軟なアクセス制限をかけられるようになっています。例えば、Webサーバコンテナに対するアクセス制限としてHTTP 80番ポートへのアクセスを許可したり、仮想マシンに対するICMP（Ping）を拒否したりといったルールが設定できます。OpenStackのセキュリティグループやKubernetesのネットワークポリシーの実装にも使われます。

Calicoはこれらの特徴によってネットワークのシンプルさとスケーラビリティ、さらにはセキュリティまで高められるようなアーキテクチャになっています。

ただし、Calicoはどんな環境でも有効というわけではありません。L2ネットワークが必要な環境、例えば死活監視やサービスディスカバリにARPを使用している場合には使えません。IPアドレス空間がフラットなL3ネットワークであるため、IPアドレスが重複できません。このため、マルチテナント環境におけるIPアドレス重複が使用できないといった制限があります。こういった制限の影響がなく、シンプルでスケーラブルなネットワークが必要な環境にCalicoは適しています。

Calicoの事例

事例を2つほどご紹介します。いずれもKubernetesでCalicoを使用している事例になります（以下で紹介するもの以外にもCalicoのサイトにいくつかの事例が掲載されています）。

Mirantis

「Mirantis Cloud Platform」（https://www.mirantis.com/software/mcp/）より

Mirantisが提供するMirantis Cloud Platform（MCP）では、Container as a ServiceのSDNとしてCalicoを採用しています。MCPではOpenStackのSDNとしてはOpenContrailを使用していますが、KubernetesのSDNとしては高いスケーラビリティやセキュアな面からCalicoを採用していると説明されています。

Google Kubernetes Engine（GKE）の事例

「Introducing Network Policy support for Google Container Engine, with Project Calico and Tigera」Google Cloud Platform Blogより

Google Cloud PlatformのマネージドなコンテナオーケストレーションサービスであるGoogle Kubernetes Engine（GKE）ではネットワークポリシーを有効化したクラスタを作成できます。GKEではそのネットワークポリシーの制御にCalicoを使用しています。

今回は、Calicoの概要と特徴、そしていくつかの事例について説明しました。次回はそれらの特徴を実現しているCalicoのアーキテクチャについて見ていきたいと思います。