Google Distributed Cloud（GDC）エアギャップの仮想ネットワーキング レイヤは、GDC 組織で実行されている仮想マシンと Pod 間の接続、ファイアウォール、サービス検出、ロード バランシング、オブザーバビリティを制御します。
GDC ネットワーキング モデル
GDC には、組織とプロジェクトの 2 つのレベルのマルチテナンシーのコンセプトがあります。プロジェクトは組織内に存在し、すべての仮想化ワークロードとコンテナ化ワークロードを組織内の特定のプロジェクトにデプロイします。
組織のネットワーキング
GDC の各組織には、独自の分離された仮想ネットワークがあります。組織内の仮想ネットワークはフラットな IP 空間です。つまり、組織内のすべてのワークロードは、互いに直接 IP アドレスで接続されています。プロジェクト ネットワーク ポリシーを使用すると、組織内の異なるプロジェクトのワークロード間のアクセスを制御できます。
GDC は、ネットワーク レベルで各組織を他のすべての組織から分離します。ある組織のワークロードは、別の組織のワークロードに直接 IP アドレス接続できません。
組織には、内部範囲と外部範囲の 2 つの異なる IP 範囲があります。外部 IP 範囲には組織外からアクセスでき、内部 IP 範囲には組織内からのみアクセスできます。ワークロードには、常に組織の内部範囲の IP アドレスが割り当てられます。つまり、デフォルトでは組織外からアクセスできません。プロジェクト ネットワーキング セクションで説明されている上り（内向き）と下り（外向き）の制約を使用して、ワークロードの上り（内向き）と下り（外向き）のトラフィックを明示的に有効にする必要があります。
プロジェクト ネットワーキング
すべての仮想マシン（VM）とコンテナ化されたワークロードをプロジェクトにデプロイします。プロジェクトは、組織内のネットワーク セグメンテーション境界を提供します。
プロジェクト内のワークロードは、相互に直接通信できます。ただし、デフォルトのネットワーク ポリシーでは、異なるプロジェクトのワークロード間の通信は禁止されています。プロジェクト ネットワーク ポリシー（ProjectNetworkPolicy）を使用すると、組織内のどのプロジェクトが相互に通信できるかを構成できます。プロジェクト ネットワーク ポリシーで許可されている場合、組織内のワークロードはそれぞれの IP アドレスを使用して L3 ネットワーク レイヤで相互にアクセスできます。インバウンド トラフィックまたはアウトバウンド トラフィックを必要とするワークロードごとに、組織との間の上り（内向き）と下り（外向き）の制約を明示的に有効にする必要があります。
ロードバランサを構成する
ロードバランサは、アプリケーションのバックエンド ワークロード間でトラフィックを分散し、安定性と可用性を確保します。Pod と VM ワークロード用の外部ロードバランサと内部ロードバランサを作成します。GDC には、ロードバランサを構成する 3 つの方法があります。詳細については、ロードバランサを管理するをご覧ください。
上り（内向き）の制約
ワークロードを組織外に公開するために使用されるメカニズムは、ワークロードが VM ベースかコンテナ ベースかによって異なります。
VM 外部アクセス機能を使用して、組織外に VM ベースのワークロードを公開します。この機能は VM ごとに有効にします。各 VM は、組織の外部範囲から独自の IP アドレスを取得します。
一方、外部ロードバランサ機能を使用して、コンテナ化されたワークロードを組織外に公開します。外部ロードバランサを作成すると、GDC によって外部 IP アドレスが割り当てられます。これにより、トラフィックは一連のバックエンド Pod ワークロード間でロードバランスされます。
下り（外向き）の制約
組織外と通信するには、プロジェクトとワークロードごとに送信トラフィックを明示的に有効にする必要があります。アウトバウンド トラフィックを有効にすると、組織外に接続するときに、ワークロードの IP がネットワーク アドレス変換（NAT）を使用して外部 IP に変更されます。アウトバウンド トラフィックの許可の詳細については、組織からのアウトバウンド トラフィックを管理するをご覧ください。
ネットワーク ポリシーの適用モデル
組織内のワークロードのセキュリティ ポスチャーは、デフォルトのプロジェクト ネットワーク ポリシーとユーザーが作成したプロジェクト ネットワーク ポリシーの和集合です。
ポリシーの適用は、レイヤ 3 とレイヤ 4 のトラフィック フローに基づいています。フローは、次のように 5 タプルの接続を記述します。
- 送信元 IP アドレス
- 宛先 IP アドレス
- 送信元ポート
- 宛先ポート
TCPやUDPなどのプロトコル
ネットワーク ポリシーは、送信元ワークロードをホストするノードのトラフィックに対してアウトバウンド トラフィックの適用を行い、宛先ワークロードをホストするノードにトラフィックが到達するとインバウンド トラフィックの適用を行います。したがって、接続を確立するには、ポリシーが移行元から移行先に移動し、移行元から移行先に到達できるようにする必要があります。
SYN セグメントに応答する SYN-ACK（同期-確認応答）セグメントなどの返信トラフィックは、適用対象外です。したがって、開始トラフィックが許可されている場合、応答トラフィックは常に許可されます。そのため、接続を開始したクライアントからのポリシー適用による接続タイムアウトのみが観測されます。拒否されたトラフィックは、送信元ノードからのアウトバウンド データ転送中、または宛先ノードでのインバウンド データ転送中に破棄されます。受信側のワークロードは接続を監視しません。
適用は、付加的な許可ベースのポリシー ルールに基づきます。ワークロードに適用されるすべてのポリシーの結合に対して、ワークロードのトラフィック フローが「一致」した場合、そのワークロードに適用されるポリシーが適用されます。複数のポリシーが存在する場合、各ワークロードに適用されるルールは加算的に結合され、少なくとも 1 つのルールに一致するトラフィックが許可されます。拒否ルールはなく、許可ルールのみがあります。
ネットワーク ポリシーがフローを拒否すると、レスポンス パケットが受信されず、接続タイムアウトが発生します。このため、拒否またはリセットされたプロトコル レベルの接続や HTTP エラーは、ネットワークの適用による直接的な結果ではありません。
Kubernetes ネットワーク ポリシーの詳細については、https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation をご覧ください。