Project Calicoのアーキテクチャを見てみよう

連載 [第2回] :

クラウドネイティブ時代のネットワークOSS Project Calicoを理解する

2018年6月26日(火)

はじめに

第1回ではProject Calicoの概要や登場した背景、技術的な特徴などについて紹介しました。今回は、機能や特徴を実現するためにCalicoがどのようなネットワークを構成するのか、どのようなアーキテクチャになっているか解説していきます。

用語解説

まず、用語について説明します。

ワークロード（Workload）
Calicoネットワークで管理されるコンテナや仮想マシンの総称です。Kubernetesによって起動されるDockerコンテナやOpenStackのNovaインスタンスなどがこれに当たります。今回はわかりやすいようにコンテナと言い換えて説明していきます。
Calicoノード
ワークロードが動作する物理または仮想のサーバ。
ワークロードエンドポイント（Workload Endpoint）
ワークロードが実行されるホスト上にあり、コンテナや仮想マシンが接続されるTAPインターフェースを指します。デフォルトでは以下のようにcaliから始まるインターフェースがこれに当たります。以下は実際のワークロードエンドポイントインターフェースの例になります。

5: cali4896addffb0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7a:c8:2d:b7:0f:88 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::78c8:2dff:feb7:f88/64 scope link
       valid_lft forever preferred_lft forever

ホストエンドポイント（Host Endpoint）
ワークロードが実行されるホストのインターフェースで、ワークロードエンドポイント以外のインターフェースを指します。eth0などのインターフェースがこれに当たります。
Forwarding Information Base（FIB）
Linux Kernel Routerが経路選択に使用する標準の経路制御表のことです。routeコマンドやip routeコマンドで参照できるものと理解して問題ありません。

用語解説

Calicoのネットワークとは

CaicoはピュアL3ネットワークを提供します。つまりCalicoのネットワークでは、全てのワークロードはCalicoノードで動作するルーターを経由したL3通信を行います。また、Calicoネットワーク上の全てのワークロードはユニークなIPアドレスを持ちます。VXLANなどのオーバーレイやIPアドレス変換を行うNAT（Network Address Translation）を使用していません。これが、Calicoネットワークがシンプルであるといわれる理由の一つです。

Calicoネットワークのアーキテクチャ

一般的に、別々のブロードキャストドメインにあるネットワーク機器を通信させる場合、それぞれのネットワーク機器は宛先を中継するネクストホップのMACアドレスとそこへの経路情報が必要になります。送信元は経路情報から得たネクストホップのIPに対応するMACアドレスをARPで問い合わせるため、ネクストホップと送信元が同一サブネットにある必要があります。Calicoにおいても同様に考えることができますが、Calicoで送信元とネクストホップにあたるワークロードとCalicoノードは同一L2ドメインに存在していません。そのため、CalicoではProxy ARPやホストルーティングなどの機能を使用することで、それらが同一L2ドメインに存在していなくてもアドレス解決できるようにしています。

Calicoでワークロード同士が通信するパターンとして、「同一Calicoノード上のワークロード同士の通信」「他Calicoノード上のワークロード同士の通信」があります。それらの通信を隣接機器との通信の範囲で局所化して考えると、ワークロード同士が通信するために必要な要素は以下3つなります。

ワークロードからCalicoノード（Calicoノード上で動作するルーター）へ通信
Calicoノードからワークロードへ通信
Calicoノードから異なるCalicoノードに存在するワークロードへの経路情報（Calicoノード間の接続性に関しては、Calicoを構築する上での前提条件となるためここでは触れません）

まず1つ目に、ワークロードからCalicoノードへ通信するために、ワークロードにはCalicoノードのMACアドレスと、Calicoノードへの経路情報が必要になります。Calicoノードへの経路情報はワークロード起動時に設定されます。しかし、CalicoのワークロードとCalicoノードは同一L2ドメインに存在していないため、ワークロードはCalicoノードのMACアドレスを入手できません。そこで、CalicoではProxy ARPという機能を使用してアドレス解決を行っています。

Proxy ARPとはインターフェースが受信したARPリクエストを転送せずにホストによって代理応答するLinux Kernelの機能です。ワークロードエンドポイントのインターフェースに対してProxy ARPの設定を有効にしておくことで、CalicoノードがワークロードからのすべてのARPリクエストに代理応答することでARPアドレス解決を行っています。

図はKubernetesの例になりますが、全てのコンテナのゲートウェイはデフォルトで169.254.1.1となっており、コンテナはゲートウェイにARPを送信します。caliから始まるワークロードエンドポイントのインターフェースではProxy ARPが有効になっているため、Calicoノード自身のIPアドレス宛のARPリクエストではないでのすが、自身のMACアドレスを返答します。これによってコンテナはゲートウェイのMACアドレスを取得し通信できます。

KubernetesにおけるCalico使用時のARPアドレス解決の流れ

2つ目に、Calicoノードからワークロードへ通信するために、CalicoノードはワークロードのMACアドレスと、ワークロードへの経路情報が必要になります。しかし、CalicoではワークロードとCalicoノードは同一L2ドメインに存在していないため、ワークロードのアドレスを解決できません。

そのためワークロード起動時、Calicoノードに対しワークロードへの経路情報としてホストルーティングの設定、アドレス解決が不要なようにスタティックARPエントリの追加を行います。ホストルーティングとは、ルーティングテーブルにネットマスクの値が255.255.255.255のネットワークIPアドレスを登録してIPルーティングを行うことです。

3つ目に、異なるCalicoノード間のワークロード同士で通信するために、Calicoノードは異なるCalicoノードに存在するワークロードへの経路情報が必要になります。Calicoでは異なるCalicoノード上のワークロードへの経路情報を交換する手段としてBorder Gateway Protocol（BGP）を使用しています。BGPはインターネットで経路交換されているプロトコルとしても知られています。BGPを使用することによってワークロードのライフサイクルに合わせて経路情報を動的に設定することができるようになっています。

Calicoにおける経路交換の流れ

Calico Network Policyとは

Calicoの特徴的な機能の1つとしてネットワークポリシーがあります。ネットワークポリシーはワークロードエンドポイントおよびホストエンドポイントのインターフェースに対して、分散ファイアーウォールを提供する機能です。さっそく、そのネットワークポリシー機能について説明していきます。

Calico Network Policyの特徴

Calicoのネットワークポリシーは、Calicoノードのiptablesによってエンドポイントに対してポリシー制御を行う分散ファイアーウォールです。Calicoで実装されているネットワークポリシーはワークロードエンドポイントに対してだけでなくホストエンドポイントへのトラフィックにも制限をかけることができます。ポリシーの定義ファイルはYAMLによって記述でき、トラフィックの方向（Ingress、Egress）や拒否/許可（Deny/Allow）、プロトコル（TCP/UDP/ICMPなど）、ポート番号などを制限できます。ポリシー設定の方法の違いから以下の2つのネットワークポリシーモデルを持っています。

Policyによる設定
Profileによる設定

2つのネットワークポリシーモデル

まず1つ目のProfileによる設定では、あらかじめ制限したいルールを定義したProfileを作成します。そして、エンドポイントの設定に定義したProfileを紐付けることができます。

2つ目のPolicyによる設定では、Policyに制限したいルールとワークロードに紐づくラベルを定義します。こうすることで指定したラベルに一致するメタデータを持ったエンドポイントに対してポリシーを適用できます。

どちらの方法を使用しても設定できる内容は同じです。2種類の方法が用意されているのは、OpenStackのセキュリティグループやKubernetes Network Policyなどのさまざまなオーケストレーターに合わせて柔軟なポリシー制御が行えるようにされているためだと考えられます。

Project Calicoの構成要素

Calicoはetcdデータストアを中心とした複数のコンポーネントによって構成されています。Calicoのコンポーネントにはオーケストレーターと連携するためのオーケストレータープラグイン、Calicoの中核機能を担うFelix、経路情報を交換するBGPデーモン、データストアなどがあります。それでは、各コンポーネントがどのような役割でどのように振舞っているのかについて解説します。

Project Calicoアーキテクチャ

オーケストレータープラグイン

オーケストレータープラグインは、OpenStackやKubernetesなどのオーケストレーターからCalicoを使用するためのコンポーネントです。このプラグインはオーケストレーターによって定義された仮想ネットワークの情報をCalicoのデータモデルに変換しetcdデータストアに格納する役割を担っています。現在利用できるプラグインとして、KubernetesやMesosからCalicoを利用するためのContainer Network Plugin（CNI）やOpenStackから利用するためのnetworking-calicoなどが開発されています。

etcd

Calicoはデータストアとして分散キーバリューストアの一つであるetcdを使用します。Calicoの機能を提供するのに必要なすべての情報を保持するデータストアとしての役割を持っており、ワークロードのIPアドレスやインターフェース名、ネットワークポリシー、そしてCalico自身の設定値といった情報が格納されます。

Calicoには中央集権的なコントローラーは存在しておらず、etcdに格納された情報を各ホストのCalicoエージェントが取得する分散型アーキテクチャとなっています。etcdはCalicoのネットワークを提供する上で重要なコンポーネントであるので、実際の環境で使用するときはクラスタを組んだり、各Calicoノードでetcdプロキシーを動作させたりして負荷分散やHAを考慮する必要が出てきます。

Felix

Felixはワークロードを実行するすべてのCalicoノードに常駐するプロセスで、Calicoの中核機能を担うProject Calicoで独自開発されたコンポーネントです。Felixは各Calicoノードからetcdを同期し、ルーティングテーブルへの経路情報の設定やiptablesへのアクセスリストの設定、ワークロード起動時のインターフェースに関する設定（ProxyARPの有効化など）を行っています。さらに、経路情報やネットワークポリシーがが正しく設定されているかなどの監視を行うことで、外部からの設定の書き換えなどによって誤った値が設定された際に修正する機能も持っています。

BGPクライアント

BGPクライアントはワークロードを提供するすべてのホストに常駐し、他のホストと経路交換を行うコンポーネントです。BGPクライアントは、他のホストへの経路広告と他のホストから広告された経路情報のルーティング設定を行う役割を持っています。CalicoではデフォルトのBGPクライアントとしてBIRDというBGP Routing Daemonを使用しますが、GoBGPなどに置き換えることも可能になっています。

CalicoはこれらのコンポーネントによりL3ネットワークやネットワークポリシーを構成します。

今回はCalicoの構成要素やアーキテクチャなどについて紹介しました。次回からはKubernetesでCalicoを使用する環境を実際に構築しながら理解を深めていきたいと思います。