Calico は、コンテナーと仮想マシン用のネットワーキングを提供するオープン・ソース・コミュニティー・プロジェクトです。
Calico は、開放型システム間相互接続 (OSI) モデルの 3 番目の層 (レイヤー 3 またはネットワーク層としても知られる) の上に構築されています。 Calico は、Border Gateway Protocol (BGP) を使用して、エージェント・ノード間の通信を容易にするルーティング・テーブルを構築します。 このプロトコルを使用することで、Calico ネットワークはパフォーマンスとネットワーク分離を向上させます。
Calico は、Kubernetes コンテナー・ネットワーク・インターフェース (CNI) をプラグインとして実装しており、コンテナーとポッド用のネットワーキングを提供するための Kubernetes 用のエージェントを提供します。
Calico は、フラットなレイヤー 3 ネットワークを作成して、自由にルーティング可能な IP アドレスをすべてのポッドに割り当てます。 これは、単一の大きいネットワーク CIDR を複数の小さい IP アドレス・ブロックに分割して、これらの小さいブロックの 1 つ以上をクラスター内のノードに割り当てます。 この分割は、CIDR 表記の config.yaml 内の network_cidr パラメーターを使用して、IBM Cloud Private
のインストール時に行われます。
Calico はデフォルトで、クラスターのすべてのノードの間に BGP メッシュを作成して、コンテナー・ネットワークの経路をすべてのワーカー・ノードにブロードキャストします。 各ノードは、サブネットのレイヤー 3 ゲートウェイとして機能するように構成されています。 サブネットは、ワーカー・ノードに割り当てられて、ホスト上でホストされているポッド・サブネットへの接続を提供します。 すべてのノードは BGP メッシュに参加し、BGP メッシュによって、ワーカー・ノードが所有しているすべてのローカル経路が他のすべてのノードに通知されます。 クラスターの外部の BGP ピアも参加できますが、クラスターのサイズは、これらの外部ピアが受信できる BGP 通知の数に影響を及ぼします。 クラスターのスケールが特定のサイズを超える場合は、ルート・リフレクターが必要になることがあります。
詳しくは、Configuring BGP Peers を参照してください。
ポッド・トラフィックをルーティングする際に、Calico はノードのローカル経路テーブルや iptables などのシステム機能を利用します。 すべてのポッド・トラフィックは iptables ルールを全探索してから、宛先にルーティングされます。
Calico の状態は、etcd キー/値ストアを使用して保持されます。 IBM Cloud Private では、Calico はデフォルトで Kubernetes と同じ etcd キー/値ストアを使用して、ポリシーとネットワーク構成の状態を保管します。
IP-in-IP トンネリングを使用してまたは使用せずにポッドが相互通信することを許可するように、Calico を構成できます。 IP-in-IP を使用すると、カプセル化の一環としてすべてのパケットの追加ヘッダーが追加されますが、コンテナーは、ほぼどの非重複アンダーレー・ネットワークを通じても、コンテナー自体のオーバーレイ・ネットワーク上で通信できるようになります。
アンダーレー・サブネットのアドレス・スペースが制約されており、追加の IP プールを追加するためのアクセス権がない一部の環境では、一部のパブリック・クラウドと同様に、Calico が適合します。 ただし、オーバーレイを必要としない環境では、IP-in-IP トンネリングを無効にすることで、パケット・カプセル化のオーバーヘッドを解消して、任意の物理ルーティング・インフラストラクチャーが遵守と監査のためのパケット検査を実行できるようにする必要があります。 このようなシナリオでは、アンダーレー・ネットワークのルーターを BGP メッシュに追加することで、アンダーレー・ネットワークによって追加のポッド・サブネットが認識されるようにすることができます。 複数のノードが別々のネットワーク・セグメントに配置されている場合の Calico ネットワークについて詳しくは、複数のネットワーク・セグメントにまたがる Calico ネットワークを参照してください。
Calico には以下のコンポーネントがあります。
ノードが Calico のシステム要件を満たしていることを確認するには、ノードの準備の情報を参照してください。

このエンティティーは、felix、bird、および confd という 3 つのコンポーネントで構成されています。
felix の主な役割は、ホストの IPtables と経路をプログラムして、そのホスト上のポッドとの間で必要な接続を提供することです。 bird は、ホスト間でルーティング情報を交換するために使用される Linux® 用のオープン・ソース BGP エージェントです。 felix によってプログラムされる経路は、bird によって選択されて、クラスター・ホストの間で分配されます。 confd は etcd データ・ストアを監視して、IPAM 情報や AS 番号などの BGP 構成が変更されていないか確認します。 これは bird の構成ファイルも変更して、bird をトリガーして各ホスト上でこれらのファイルを再ロードします。 calico/node agent は、ポッド・ネットワーク名前空間をホストのデフォルト・ネットワーク名前空間に接続するための veth-pairs
を作成します。CNI プラグインは、ノード上でホストされているポッドの IP アドレスをプロビジョンすることで、IP アドレス管理 (IPAM) 機能を提供します。
calico/kube-controller は、Kubernetes NetworkPolicy オブジェクトを監視して、Calico データ・ストアを Kubernetes オブジェクトと同期した状態に保ちます。 各ノード上で実行されている calico/node は、Calico etcd データ・ストア内の情報を使用してローカル
iptables をプログラムします。
calicoctl は、Calico のネットワーク、セキュリティー・ポリシーおよびその他の Calico 構成を管理するために使用できるコマンド・ライン・ツールです。 このツールは etcd と直接通信してデータ・ストアを操作します。 いくつかのリソース管理コマンドが用意され、Calico ネットワークの問題をトラブルシューティングするために使用できます。 Calico CLI をセットアップするには、Calico CLI (calicoctl) のインストールを参照してください。
複数のノードが別々のネットワーク・セグメント上にある場合は、これらのノードはアンダーレーおよびインフラストラクチャー・ネットワーク内のルーターによって接続されます。 異なるサブネット上の 2 つのノード間のトラフィックは、これらのサブネットのゲートウェイであるこのルーターを通過します。 このルーターは、ポッド・サブネットを認識していない場合はホスト間でパケットを転送できません。

この状況に対処するには、次の 2 つの方法があります。
ノード上でホストされているすべてのサブネット用に、各ノード上で IP-in-IP トンネル・エンドポイントを作成するように Calico を構成できます。 ポッドによって生成されて、ノードから egress されるすべてのパケットは、IP-in-IP ヘッダーを使用してカプセル化されて、ノードの IP アドレスが送信元として使用されます。 このようにすることで、インフラストラクチャー・ルーター側ではポッドの IP アドレスが認識されません。
IP-in-IP トンネリングを使用すると、各エンドポイントでパケットをカプセル化およびカプセル化解除するための追加のパケット処理が実行されるため、ネットワークのスループットと待ち時間が増大します。 ベアメタルでは、特定のネットワーク処理がネットワーク・インターフェース・カードにオフロードされるため、オーバーヘッドは大きくなりません。 ただし、仮想マシンでは、オーバーヘッドが大きくなる可能性があるとともに、ハイパーバイザーによって構成および使用される CPU コアとネットワーク入出力テクノロジーの数がオーバーヘッドに影響を及ぼす可能性もあります。 小さめの最大伝送単位 (MTU) サイズが使用されている場合は、パケットのフラグメント化が生じることがあるため、パケットのカプセル化に伴う追加のオーバーヘッドも大きくなる可能性があります。 可能な場合は常に、ジャンボ・フレームを有効にする必要があります。
2 つ目の方法は、インフラストラクチャー・ルーターにポッド・ネットワークを認識させることです。 このためには、ルーター上で BGP を有効にして、クラスターにノードを BGP ピアとして追加します。 これらの操作を実行することで、ルーターとホストは経路情報を交換できるようになります。 このシナリオでは、BGP メッシュの場合と同様、クラスターのサイズが影響を及ぼす可能性があります。 ルーター上で BGP を有効にすると、クラスター内の各ノードはルーターのピアになります。
config.yaml:
network_type: calico
network_cidr: 10.1.0.0/16
calico_ipip_mode: Always
calico_tunnel_mtu: 1430
calico_ip_autodetection_method: can-reach={{ groups['master'][0] }}
network_type: calico を選択して、Calico をコンテナー・ネットワークとしてデプロイします (デフォルトは calico)。
network_cidr: network_cidr: 十分な大きさのプライベート IP サブネットを選択します。このサブネットは、クラスター上でホストされる予定のすべてのワークロードによって使用されます。 この IP 範囲は、既存のホスト・ネットワークや service_cluster_ip_range と競合しないようにする必要があります。 IP の数は、IBM Cloud Private に追加されたコンポーネントの数と、インストールするコンポーネントおよびフィーチャーの数に基づいて、バージョンごとに異なります。
インストールされたすべてのポッドをリストすることによって、現在の合計 IP 数を取得できます。
N 個のワーカー・ノードがあり、P 個のポッドをターゲットにしている場合は、安全な IP 範囲は ( N x P ) + N です。この範囲では、N-1 個のノードが使用不可になっても許容できます。 デフォルト値である 10.1.0.0/16 は、大規模なクラスターをホストするためには十分です。
calico_ipip_mode: このオプションを使用して、IP-in-IP トンネリングを有効にできます。 オーバーレイ・ネットワークを必要とする環境では、このオプションを有効にする必要があります。例えば、egress パケットの送信元 IP がホスト IP と照らし合わせて厳密にチェックされる環境などです (OpenStack など)。 BGP 経路の交換を許可するようにインフラストラクチャー・ルーターを構成できない場合も、このオプションを有効にする必要があります。
このパラメーターを Always に設定した場合は、ip protocol 4 がすべてのノード (OpenStack 内のセキュリティー・グループなど) をまたいでインフラストラクチャー・ファイアウォールを通過できるようにする必要があります。
calico_tunnel_mtu: このパラメーターは、トンネル・デバイス上およびポッド・インターフェース上で適切な MTU を設定します。 このパラメーターを使用すると、インフラストラクチャー・ネットワークのパス MTU (PMTU) に従って MTU を調整して、パケットのフラグメント化を回避できます。 また、一部のケースでは、インフラストラクチャー・ファイアウォールは ICMP PMTU エラー・メッセージの伝搬を許可するようにプログラムされていません。
その結果として、L3 セッション側では PMTU が認識されないため、パケットと接続が失われる可能性があります。
デフォルト値の 1430 は、ほとんどのシナリオおよび OpenStack Neutron VxLAN ネットワークなどの IaaS ネットワークにとって適切です。 この値は、IP-in-IP ヘッダーを格納するために、インターフェースの MTU または PMTU より 20 バイト以上小さい必要があります。
calico_ip_autodetection_method: このパラメーターは、ノード上のインターフェースを選択するために使用されるとともに、ノードにまたがるポッド間のデータ通信に使用されます。 ポッドのデータ・パスの選択に役立つ以下の 3 つの方法を使用できます。
first-found
この方法では、ノード上で最初に検出された有効なインターフェース上の最初の有効な IP アドレスが使用されます。
interface=<interface name list>
このパラメーターは、正規表現の名前のコンマ区切りリストを値として受け入れます。 指定されたインターフェース上で検出された最初の IP アドレスが使用されます。
例:
calico_ip_autodetection_method: interface=eth0
calico_ip_autodetection_method: interface=eth.*
calico_ip_autodetection_method: interface=eth.*,ens.*
注: ネットワーク・インターフェース名は文字列 docker.*、cbr.*、dummy.*、virbr.*、 lxcbr.*、veth.*、lo、cali.*、tunl.*、または flannel.* を含んでいてはなりません。
can-reach=<remote IP address or host name>
can-reach の方法では、ノードのローカル経路テーブルが使用されます。 この方法では、ポッド・ネットワーク・インターフェースを特定するために指定された宛先アドレスへの通信に使用されるインターフェースも使用されます。 このパラメーターは、リモート IP アドレスまたはドメイン・ネームを値として受け入れます。
IP によっては Calico で認識されないものがあります。 インターフェースに以下の範囲の IP がないことを確認してください。
10.0.2.15/24: この IP 範囲は、デフォルト Vagrant/VirtualBox NAT インターフェース・アドレス範囲です。192.168.122.*: この IP 範囲は、デフォルト libvirt VM インターフェース・アドレス範囲です。Calico が使用される IBM Cloud Private のデプロイメント・トポロジーについて詳しくは、IBM Cloud Private デプロイメント・トポロジーを参照してください。
デフォルトでは、管理ノード上で実行されている Prometheus コンポーネントは、IBM Cloud Private で実行されている Calico ノード・エージェントをメトリックのために収集します。 IBM Cloud Private に付随している Grafana ダッシュボードには、Calico から取得されたクラスター・ネットワーク・メトリックがグラフィック表示されます。
また、Felix から収集されたこれらのメトリックを使用してアラートを設定できます。