コンテナのネットワークインターフェースの選択

仮想プライベートクラウド

コンテナネットワークインターフェース（CNI）を選択する際は、以下の情報を確認してください。

IBM Cloud Kubernetes Service のバージョン 4.20 以降では、 Calico がデフォルトのCNIとなっていますが、RHCOSワーカーノードを使用するVPCクラスターでは、クラスターのCNIとしてOpen Virtual Network (OVN) を選択するオプションがあります。

Calico デフォルト
Calico これは、クラウド、オンプレミス、エッジのいずれにおいても、あらゆる Kubernetes ディストリビューション向けの、ネットワーキング、ネットワークセキュリティ、および可観測性を実現する単一のプラットフォームです。 Kubernetes を導入したばかりの方でも、大規模に運用している方でも、 Calico のオープンソース版、エンタープライズ版、クラウド版は、お客様が必要とするネットワーク機能、セキュリティ、可観測性を提供します。 詳細については、 Calico のドキュメントを参照してください。
OVN - Kubernetes (OVN) 4.20 およびそれ以降のバージョン RHCOS ワーカーノードのみ
OVN- Kubernetes は、Open Virtual Network（OVN）を基盤としており、オーバーレイ方式のネットワーク実装を提供します。 OVN- Kubernetes プラグインを使用するクラスターでは、各ノード上でOpen vSwitch （OVS）も実行されます。 OVNは、宣言されたネットワーク構成を実装するために、各ノード上でOVSを設定します。 詳細については、『 Red Hat 』のドキュメントを参照してください

Calico とOVNの比較

以下の表を確認し、 Calico とOVNの機能や特長を比較してください。

OVN を使用する際は、VPC のサブネットが、以下の表に指定されている追加のサブネットと重複しないようにする必要があります。 サブネットの重複がある場合、Pod間のネットワーク通信は失敗します。

Layer2 また、 layer3 のユーザー定義ネットワーク（UDN）は、 OpenShift Virtualizationの仮想マシンなど、DHCPを使用するワークロードではサポートされていません。

Calico およびOVN比較表
コンポーネント Calico OVN- Kubernetes
カプセル化
  • IP in IPプロトコル（ UDP や TCP ではない）
  • 異なるサブネットにあるノード上で実行されているポッド間のトラフィックのみをカプセル化します。
  • ジュネーブ： UDP ポート6081のプロトコル
  • すべてのポッド間トラフィックをカプセル化する
デフォルトのクラスタネットワーク／ポッドのMTU デフォルトでは1480バイト（20バイトの IPinIP ヘッダーを含む）。 これは変更可能です。 デフォルトでは1400バイト（100バイトのGeneveヘッダーを含む）。 これは変更可能です。 Daemonsetでは、単に ip link set dev ens3 mtu`` を実行するだけでなく、NetworkManager ファイルを作成する必要があります。 また、新しいワーカーノードも再起動する必要があります。
Pod IPAM Calico 当初、新しいノードごとに /26 サブネット（64 個の IP アドレス。通常、少なくとも 1 個は tunl0 の IP アドレスとして使用され、残りはポッド用に利用可能）が割り当てられます。 /26 サブネット内のすべてのポッド IP アドレスが使用された場合、 Calico は、そのノードに 2 つ目の /26 サブネットを割り当て、必要に応じてさらに多くのサブネットを割り当てます。 calicoctl ipam check を使用すると、各ノードに割り当てられたサブネットを確認できます。 OVNは、新しいクラスターノードごとに、最初に/24のポッドサブネット（256個のIPアドレス）を割り当てます。 ポッドのサブネットをこれ以上追加するオプションはありません。 また、新しいノードごとにジョインサブネットのIPアドレスを割り当て、これはOVN内部で使用されます
ポッド間ルーティング
  • Linuxのroutesを使用します。
  • BGPを使用してルーティング情報を配布します。
  • 各ノードに tunl0 インターフェースを設置し、カプセル化を行います。
  • 各ノード上で vSwitch （OVS）が動作し、ポッド間のトラフィックをルーティングします。
  • OVNは、OVSのフローを設定して、ポッド間のルーティングを定義します。
  • 各ノード上には、 ovs-system、 genev_sys_6081、 ovn-k8s-mp0、 br-int、 br-ex など、他にも多くのインターフェースが作成され、OVNおよびOVSによって使用されます
Kubernetes ネットワーク・ポリシー
  • calico-node により、iptables ルールを追加して実装されました。
  • ネットワークポリシーによってブロックされたトラフィックのログ記録は可能ですが、手順が複雑です。 これには、「Log」アクションを使用する追加の Calico ポリシーが必要であり、これらのLogアクションをどこに、いつ配置するかについて、十分な検討と計画が必要です。
  • ワーカーノードの syslog にログが記録されますが、このログの取得は困難な場合があります。
  • ログには、どのポリシーがトラフィックを許可またはブロックしたかという情報が含まれていません。
  • OVS では、論理ポート上の ACL を使用して実装されています（iptables ではありません）。
  • アノテーションを使用することで、ネットワークポリシーによるドロップおよび／または許可されたトラフィックのログ記録がはるかに簡単になります。
  • ポリシーアクティビティのログを記録したいネームスペースにアノテーションを付け、許可、拒否、あるいはその両方のログを記録するかどうかを指定します。
  • ログは、 ovnkube-node ポッド内の /var/log/ovn/acl-audit-log.log ファイルに送信されます。
  • これらのログを他のログ出力先へ送信するための設定オプションがあります。
  • ログには、どのポリシーがトラフィックを許可したかが含まれますが、ポリシーは許可のみを扱うため、どのポリシーがトラフィックを拒否したかは含まれません。
  • 許可されたトラフィックをログに記録するには、少なくとも1つのポリシーが設定されている必要があります。
ホストネットワークポリシー Calico GlobalNetworkPolicies なし
追加のサブネット なし
  • サブネットへの参加 ： 100.64.0.0/16 （ OpenShift がデフォルト）。
  • マスカレードサブネット ： 169.254.64.0/18。 これは、 OpenShift のデフォルト設定である 169.254.0.0/17 とは異なります。 この違いは、ローカルレジストリのHAProxyで使用されている 169.254.2.0/24 のIPアドレスとの競合を避けるためです。
  • トランジットサブネット ：100.88.0.0/16 （ OpenShift がデフォルト）。
APIサーバーの監視
  • calico-typha はリソースウォッチを登録し、 calico-node のポッドに対するプロキシとして機能して、変更を通知します。
  • calico-node は、 calico-typha のポッドのいずれかに接続し、リソースの変更に関する通知を受け取るように登録します。
  • コントロールプレーン上の「 ovnkube-cluster-manager 」コンテナは、新しいノードの検出を行います。
  • 各クラスタノード上の「 ovnkube-controller 」コンテナは、リソースを監視し、それらをnbdb内のOVN論理エントリに変換します。
CNI calico および calico-ipam の CNI バイナリは、 calico-node ポッド上の install-cni initContainer によって各ノードにコピーされます。 ovnkube-node ポッドの ovnkube-controller コンテナは、addおよびdeleteの呼び出しに対してCNIバイナリを実行します。
リソースが作成されました
  • calico-apiserver ネームスペース
  • calico-apiserver (デプロイメント、2 ポッド)
  • calico-system ネームスペース
  • calico-node (各ノード)
  • calico-typha (デプロイメント、2 ～ 10 ポッド)。
  • calico-kube-controllers (1ノード)。
  • openshift-kube-proxy ネームスペース。
  • openshift-kube-proxy (各ノード)。
  • tigera-operator ネームスペース。
  • tigera-operator (デプロイメント、1ポッド)。
  • calico CNIバイナリ、 calico-ipam CNIバイナリ、およびその他の各種CNIバイナリは、 calico-node 上の install-cni initContainer によって各ノードにコピーされます。
  • openshift-ovn-kubernetes ネームスペース、各ノード上の ovnkube-node には 8 つのコンテナがあり、 ovnkube-controller がリソースを監視し、ポッドの IP を割り当て、リソースを nbdb 内の OVN 論理エントリに変換します。 また、CNIの追加および削除も処理します。
  • nbdb は、論理エントリを保存します。
  • northd は、 nbdb にある論理エントリを、 sbdb にある論理フローに変換します。
  • sbdb は、論理フローを保存します。
  • ovn-controller は、 sbdb にある論理フローを変換し、OVSスイッチをプログラムします。
  • ovn-acl-logging。
  • kube-rbac-proxy-node は、ノードメトリクスを保護し、承認されたユーザーのみがそれらをスクレイピングできるようにします。
  • kube-rbac-proxy-ovn-metrics は、OVNメトリクスを保護し、承認されたユーザーのみがそれらをスクレイピングできるようにします。
ポッド間の接続
  • 「 calico-node 」ポッドは、最初に、 TCP 172.20.0.1:2040 でリスニングしているプロキシポッド内のローカルハプロキシを経由して kube apiserver に接続し、 calico-typha のポッド一覧を取得します。
  • calico-node ポッドは、 TCP のポート 5473 上で、 calico-typha ポッドのいずれかに接続し、クラスタリソースの更新をリッスンします。
  • calico-node ポッドは、bird BGP デーモンを実行し、 TCP のポート 179 上で、他のすべての calico-node bird BGP デーモンとフルメッシュで接続します。
  • 同じサブネット内のノード上のポッド間では、ポッド間のトラフィックが直接行われます。
  • 異なるサブネット上のノードにあるPod間のトラフィックは、 IPinIP によるカプセル化（または Satellite クラスタの場合は VxLAN ）を使用してカプセル化されます。
  • 各ノード上の ovnkube-controller コンテナは、 TCP でリスニングしているプロキシポッド内のローカルhaproxyを経由してkube apiserverに接続します。リソースウォッチについては、 172.20.0.1:2040 を参照してください。
  • ポッド間のすべてのトラフィックはGeneveを使用してカプセル化され、 UDP のポート6081を経由して送信されます。
  • 詳細については、 「ファイアウォールの設定」を参照してください。