네트워킹 개요

Google Distributed Cloud (GDC) 에어 갭의 가상 네트워킹 레이어는 GDC 조직에서 실행되는 가상 머신과 포드 간의 연결, 방화벽, 서비스 검색, 부하 분산, 관측 가능성을 관리합니다.

GDC 네트워킹 모델

GDC에는 조직과 프로젝트라는 두 가지 수준의 멀티 테넌시 개념이 포함되어 있습니다. 프로젝트는 조직 내에 있으며, 모든 가상화 및 컨테이너화된 워크로드를 조직 내의 특정 프로젝트에 배포합니다.

조직 네트워킹

GDC의 각 조직에는 자체 격리된 가상 네트워크가 있습니다. 조직 내 가상 네트워크는 플랫 IP 공간이므로 조직의 모든 워크로드가 서로 직접 IP 주소로 연결됩니다. 프로젝트 네트워크 정책을 사용하면 조직의 여러 프로젝트에 있는 워크로드 간 액세스를 제어할 수 있습니다.

GDC는 네트워크 수준에서 각 조직을 다른 모든 조직과 격리합니다. 한 조직의 워크로드는 다른 조직의 워크로드에 직접 IP 주소로 연결되지 않습니다.

조직에는 내부 범위와 외부 범위라는 두 가지 IP 범위가 있습니다. 외부 IP 범위는 조직 외부에서 연결할 수 있으며 내부 IP 범위는 조직 내에서만 액세스할 수 있습니다. 워크로드에는 항상 조직의 내부 범위에서 IP 주소가 할당되므로 기본적으로 조직 외부에서 액세스할 수 없습니다. 프로젝트 네트워킹 섹션에 설명된 인그레스 및 이그레스 제약 조건을 사용하여 워크로드의 인바운드 및 아웃바운드 트래픽을 명시적으로 사용 설정해야 합니다.

프로젝트 네트워킹

모든 가상 머신 (VM)과 컨테이너화된 워크로드를 프로젝트에 배포합니다. 프로젝트는 조직 내에서 네트워크 세분화 경계를 제공합니다.

프로젝트 내 워크로드는 서로 직접 통신할 수 있습니다. 하지만 기본 네트워크 정책은 서로 다른 프로젝트의 워크로드 간 통신을 방지합니다. 프로젝트 네트워크 정책 (ProjectNetworkPolicy)을 사용하면 조직의 프로젝트가 서로 통신할 수 있도록 구성할 수 있습니다. 프로젝트 네트워크 정책이 허용하는 경우 조직의 워크로드가 각 IP 주소를 사용하여 L3 네트워크 계층에서 서로 연결할 수 있습니다. 인바운드 또는 아웃바운드 트래픽이 필요한 각 워크로드에 대해 조직과의 인그레스이그레스 제약 조건을 명시적으로 사용 설정해야 합니다.

부하 분산기 구성

부하 분산기는 애플리케이션의 백엔드 워크로드에 트래픽을 분산하여 안정성과 가용성을 보장합니다. 포드 및 VM 워크로드용 외부 및 내부 부하 분산기를 만듭니다. GDC는 부하 분산기를 구성하는 세 가지 방법을 제공합니다. 자세한 내용은 부하 분산기 관리를 참고하세요.

인그레스 제약 조건

조직 외부에서 워크로드를 노출하는 데 사용되는 메커니즘은 워크로드가 VM 기반인지 컨테이너 기반인지에 따라 다릅니다.

VM 외부 액세스 기능을 사용하여 조직 외부에서 VM 기반 워크로드를 노출합니다. 각 VM에 대해 이 기능을 사용 설정합니다. 각 VM은 조직의 외부 범위에서 자체 IP 주소를 가져옵니다.

반면 외부 부하 분산기 기능을 사용하면 조직 외부에서 컨테이너화된 워크로드를 노출할 수 있습니다. 외부 부하 분산기를 만들면 GDC에서 외부 IP 주소를 할당합니다. 그런 다음 트래픽을 백엔드 포드 워크로드 집합에 부하 분산할 수 있습니다.

이그레스 제약 조건

조직 외부와 통신하려면 각 프로젝트와 워크로드에 대해 아웃바운드 트래픽을 명시적으로 사용 설정해야 합니다. 아웃바운드 트래픽을 사용 설정하면 조직 외부에서 연결할 때 워크로드의 IP가 네트워크 주소 변환 (NAT)을 사용하여 외부 IP로 변경됩니다. 아웃바운드 트래픽 허용에 대한 자세한 내용은 조직의 아웃바운드 트래픽 관리하기를 참고하세요.

네트워크 정책 적용 모델

조직 내 워크로드의 보안 상태는 기본 프로젝트 네트워크 정책과 사용자가 만든 프로젝트 네트워크 정책의 합집합입니다.

정책 시행은 레이어 3 및 레이어 4 트래픽 흐름을 기반으로 합니다. 흐름은 5-튜플 연결을 다음과 같이 설명합니다.

  • 소스 IP 주소
  • 대상 IP 주소
  • 소스 포트
  • 대상 포트
  • 프로토콜(예: TCP 또는 UDP)

네트워크 정책은 소스 워크로드를 호스팅하는 노드에서 트래픽에 대한 아웃바운드 트래픽 적용을 실행하고, 트래픽이 대상 워크로드를 호스팅하는 노드에 도착하면 인바운드 트래픽 적용을 실행합니다. 따라서 연결을 설정하려면 정책이 소스를 떠나 목적지로 이동하고 소스에서 목적지로 도착하도록 허용해야 합니다.

SYN 세그먼트에 응답하는 SYN-ACK (동기화-확인) 세그먼트와 같은 응답 트래픽에는 시행이 적용되지 않습니다. 따라서 시작 트래픽이 허용되면 항상 응답 트래픽이 허용됩니다. 따라서 연결을 시작하는 클라이언트의 정책 시행으로 인한 연결 제한 시간만 관찰됩니다. 거부된 트래픽은 소스 노드에서 아웃바운드 데이터 전송 중에 또는 대상 노드에서 인바운드 데이터 전송 중에 폐기됩니다. 수신 워크로드는 연결을 관찰하지 않습니다.

적용은 허용 기반 정책 규칙을 기반으로 하며, 이러한 규칙은 누적됩니다. 워크로드에 대한 결과 시행은 해당 워크로드에 적용된 모든 정책의 합집합에 대한 트래픽 흐름의 '일치'입니다. 정책이 여러 개 있는 경우 각 워크로드에 적용되는 규칙이 가산적으로 결합되어 규칙 중 하나라도 일치하면 트래픽이 허용됩니다. 거부 규칙이 없고 허용 규칙만 있습니다.

네트워크 정책에서 흐름을 거부하면 응답 패킷이 수신되지 않고 연결 제한 시간이 표시됩니다. 따라서 거부되거나 재설정된 프로토콜 수준 연결 또는 HTTP 오류는 네트워킹 시행의 직접적인 결과가 아닙니다.

Kubernetes 네트워크 정책에 관한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation을 참고하세요.