Cilium Cluster Meshについてです。長い記事なので、２つに分けてお送りしています。今回は後半です。Pod Packet FlowやYugaByteDBについてです。 すべてのポッドトラフィックは、ノードから出てノードに入る前に’cilium_vxlan’インタフェースを通過します。 cilium_vxlan デバイスは VXLAN のエンキャップ/デキャップを行います。 CiliumエージェントでBPFプログラムをインストールしてARPリクエストへの応答を行い、ARP応答にはLXCインタフェースMACを使用しています。cluster-atlanta (10.217.0.67)上のポッドからcluster-toronto (10.219.0.25)へのPingを送信します。 基盤となるホストインターフェース — ens3上のVXLANにパケットします。 ‘ cilium_vxlan’ インターフェースの VXLAN パケットをデキャップします。 ポッドに接続されたルートネームスペース上のLXCインタフェースがARPリクエストに応答します。 Testing Multi-cluster Pod Interconnectivity with YugaByteDB YugabyteDB は、フレキシブルなクエリ言語としてのSQL、低レイテンシーの読み取り性能、グローバルに分散された書き込みのスケーラビリティという、クラウドネイティブ・マイクロサービスに必須の3つのニーズを集約した分散型ACID準拠のデータベースです。 YugabyteDBは、同期レプリケーションまたはマルチマスターレプリケーションを使用して、ユーザーがリージョンやクラウドにまたがってデプロイすることを可能にします。以下のトポロジーでは、cluster-singaporeとcluster-torontoのYB-Serversがcluster-atlanta上で稼働しているYB-Masterに入っています。これは単にポッド間の接続性をテストするためのものであり、デフォルト/サポートされているデプロイメントパターンではありません。 YugabyteDBマスターは、同じクラスタ内のローカルサーバとcluster-atlantaに配置されています。 YugabyteDBポータルは、 cluster-atlant上っでマスターとローカルサーバを表示しています。 YugabyteDB サーバは cluster-singapore と cluster-toronto にデプロイされており、両方のサーバは cluster-atlanta 上の YugabyteDB マスターに入るようにコンフィギュアされています。以下に示すように、異なるサブネット(10.218.0.0.0/24と10.219.0.0/24)にあるサーバは、両方ともcluster-atlanta(10.217.0.30)へのアウトバウンド接続を持っています。 YugabyteDBポータルでは、異なるKubernetesクラスタからクラスタ内の他の2つのアクティブなサーバを表示しています。 Multi-Cluster Network Policy — Limiting Pod-Pod Communication between Clusters 各ホスト上で実行されている Cilium Agent は、IP テーブルを管理する代わりに、ネットワークポリシー設定をkernel にロードされ、コンテナの仮想イーサネットデバイスにアタッチされた BPF プログラムに変換します。これらのプログラムは、送受信される各パケットで実行されます。 クラスタメッシュを持つマルチクラスタ環境では、クラスタ名はラベル’io.cilium.k8s.policy.cluster’を介してエクスポーズされ、特定のクラスタにポリシーを制限するために使用することができます。 cluster-atlanta上のYB-Masterとcluster-singaporeおよびcluster-toronto上のYB-Serversとの間のingressおよびegressトラフィックを許可します。 egressは、label:appとcluster:cluster-nameのルールマッチングを許可します。…