Antrea 네트워크의 NSX Kubernetes 클러스터와 VM 간의 트래픽을 보호하기 위한 방화벽 정책

NSX 4.1부터 Antrea Kubernetes 클러스터로 들어오거나 나가는 트래픽과 일치시킬 동적 멤버 자격 조건의 Kubernetes 멤버 유형으로 일반 그룹을 생성할 수 있습니다.

그런 다음, 분산 방화벽 규칙 또는 게이트웨이 방화벽 규칙에서 이러한 일반 그룹을 사용하여 NSX 환경의 VM과 Antrea Kubernetes 클러스터의 포드 간의 트래픽을 보호할 수 있습니다.

중요: 다중 테넌트 NSX 환경에서 Kubernetes 클러스터 리소스는 프로젝트 인벤토리에 노출되지 않습니다. 따라서 프로젝트 내에서는 동적 멤버 자격 조건의 Kubernetes 멤버 유형으로 일반 그룹을 생성할 수 없습니다. NSX의 기본 보기(기본 공간)에서 그룹을 생성한 다음, 기본 공간 아래의 분산 방화벽 규칙 또는 게이트웨이 방화벽 규칙에서 사용해야 합니다.

Antrea의 NSX Kubernetes 클러스터에서 VM으로의 트래픽 보호

Antrea Kubernetes 클러스터에서 NSX로의 트래픽을 일치시키려면 방화벽 규칙에서 다음 Kubernetes 멤버 유형(리소스)을 기준으로 일반 그룹을 추가할 수 있습니다.

• Kubernetes 노드
• Antrea 송신
• Antrea IP 풀

다음 다이어그램은 Antrea Kubernetes 클러스터에서 NSX 논리적 네트워크의 VM으로의 일반적인 트래픽 흐름을 보여 줍니다.

이 트래픽 흐름 다이어그램에 표시된 것처럼 Antrea Kubernetes 클러스터에서 나가는 트래픽을 일치시키기 위해 다음과 같은 시나리오가 가능합니다.

시나리오 1: 송신을 통한 SNAT(게이트웨이 노드)

Antrea Kubernetes 클러스터에 송신 리소스를 배포할 수 있습니다. 송신 리소스의 매니페스트 파일에서 송신 리소스가 적용되는 포드의 그룹화 조건을 선택합니다. 매니페스트 파일에서 송신 IP를 수동으로 지정하거나 Antrea CNI가 ExternalIPPool 사용자 지정 리소스에서 송신 IP를 할당할 수 있습니다.

중요: 송신 IP 주소는 물리적 네트워크에서 라우팅할 수 있어야 하며 K8s 클러스터의 모든 노드에서 연결할 수 있어야 합니다.

Antrea CNI는 선택한 포드에서 게이트웨이 노드로 송신 트래픽을 전송합니다. 게이트웨이 노드는 SNAT(소스 주소 변환)를 수행하여 소스 IP(포드 IP)를 송신 IP로 변환합니다.

예를 들어 앞의 트래픽 흐름 다이어그램에서는 node1에서 실행되는 pod1 및 pod2의 송신 트래픽이 게이트웨이 노드로 전송됩니다. 게이트웨이 노드는 포드 IP 주소를 egress1 IP로 변환합니다.

송신 리소스에 대한 자세한 내용은 Antrea 설명서 포털에서 송신 가이드를 참조하십시오.

게이트웨이 노드로 사용할 수 있는 클러스터 노드는 물리적 네트워크 관리자 또는 IaaS 네트워크 관리자가 제어하는 노드 네트워크 토폴로지에 따라 달라집니다. 게이트웨이 노드에는 다음과 같은 두 가지 특성이 있습니다.

• 물리적 네트워크를 사용하면 노드의 라우팅 가능 IP가 외부 네트워크에 액세스하기 위한 소스 IP로 사용될 수 있습니다.
• 필요한 경우 물리적 게이트웨이의 물리적 방화벽이 게이트웨이 노드에서 나가는 트래픽을 필터링하도록 구성됩니다.

다음과 같은 예를 고려해 보십시오.

• 예제 1: Antrea Kubernetes 클러스터에 node1, node2 및 node3의 3개 노드가 있다고 가정합니다. 클러스터의 node1 및 node2는 두 개의 네트워크 인터페이스가 할당되었기 때문에 특수한 노드라고 가정해 보겠습니다. 이러한 두 네트워크 인터페이스는 K8s 클러스터 통신을 위한 인터페이스와 외부 네트워크에 연결하기 위한 인터페이스입니다. Node3에는 클러스터 통신을 위한 하나의 네트워크 인터페이스만 지정됩니다. 이 시나리오에서는 node1 및 node2만 게이트웨이 노드로 사용할 수 있습니다.
• 예제 2: K8s 클러스터의 3개 노드 모두에 하나의 네트워크 인터페이스만 할당되고 네트워크 관리자가 node-1 및 node-2 MAC 주소만 인터넷에 연결될 수 있도록 물리적 방화벽을 구성했다고 가정합니다. 이 시나리오에서는 node1 및 node2를 게이트웨이 노드로 사용할 수 있습니다.
• 예제 3: 3개의 노드가 모두 인터넷에 연결될 수 있다고 가정합니다. 네트워크 관리자가 물리적 게이트웨이에 물리적 방화벽을 구성했으며 방화벽은 특정 송신 IP에서 트래픽을 필터링하려고 합니다. 이 시나리오에서는 3개의 노드를 모두 게이트웨이 노드로 사용할 수 있습니다.

다음 단락에서는 구현별 제한 사항에 대해 설명합니다.

Antrea Kubernetes 클러스터 외부에 있는 물리적 호스트 또는 VM은 포드의 송신 트래픽을 터널링하기 위한 게이트웨이 노드로 사용할 수 없습니다. 이유는 Antrea 에이전트가 송신 IP 주소를 유지하고 이 에이전트는 K8s 클러스터의 각 노드에서 포드로 실행되기 때문입니다. 따라서 게이트웨이 노드로 사용하려는 물리적 호스트 또는 VM은 K8s 클러스터의 일부여야 합니다.

시나리오 2: 노드를 통한 SNAT

이 시나리오에서 포드는 송신 리소스의 매니페스트 파일에서 명시적으로 선택되지 않습니다.

포드의 송신 트래픽이 노드 IP로 가장된 다음, 트래픽이 IaaS 네트워크로 전송됩니다. 예를 들어, 이전 트래픽 흐름 다이어그램에서는 SNAT 규칙은 소스 IP(pod3 IP, pod4 IP)를 node2 IP로 변환한 다음, 포드의 송신 트래픽이 IaaS 네트워크로 전송됩니다.

시나리오 3: IaaS 네트워크에 직접 브리징되는 라우팅 가능한 포드

라우팅 가능한 포드는 포드에 언더레이 네트워크에서 라우팅 가능한 IP 주소가 할당됨을 의미합니다. 일반적으로 포드에는 노드에 구성된 PodCIDR 속성의 개인 IP 주소가 할당됩니다. 포드가 K8s 클러스터 외부에 있는 네트워크에 액세스하려는 경우 트래픽이 전송되려면 소스 IP(포드 IP)를 라우팅 가능한 IP로 변환하기 위한 SNAT 작업이 필요합니다.

Antrea Kubernetes 클러스터가 TKGS(Tanzu Kubernetes Grid Service)를 사용하여 NSX 오버레이 네트워크에 배포된 경우 TKC(Tanzu Kubernetes 클러스터) 노드가 NSX에서 라우팅 가능한 서브넷을 요청하고 이 라우팅 가능한 서브넷을 노드의 PodCIDR 속성으로 사용하는 메커니즘이 있습니다. 그런 다음, 포드는 라우팅 가능한 IP 주소를 획득할 수 있습니다. 라우팅 가능한 포드 네트워크를 사용하여 TKC를 구성하는 방법에 대한 자세한 내용은 "VMware vSphere with Tanzu" 설명서를 참조하십시오.

Antrea Kubernetes 클러스터가 NSX 오버레이 네트워크에 배포되지 않은 경우 Kubernetes 관리자는 라우팅 가능한 서브넷 또는 라우팅 가능한 IP 범위가 언더레이 네트워크에 예약되어 있는지 확인할 수 있습니다. 관리자는 IPPool 사용자 지정 리소스의 매니페스트 파일에서 서브넷 또는 IP 범위를 구성할 수 있습니다. 그런 다음, Antrea CNI는 라우팅 가능한 IP 주소를 포드에 할당할 수 있습니다.

예를 들어 이전 트래픽 흐름 다이어그램에서 node5에서 실행되는 pod5는 IPPool 사용자 지정 리소스에서 라우팅 가능한 IP를 가져옵니다.

IPPool 사용자 지정 리소스에 대한 자세한 내용은 Antrea 설명서 포털에서 Antrea IPAM 가이드를 참조하십시오.

NSX의 VM에서 Antrea Kubernetes 클러스터로의 트래픽 보호

NSX에서 Antrea Kubernetes 클러스터로의 트래픽을 일치시키려면 방화벽 규칙에서 다음 Kubernetes 멤버 유형(리소스)을 기준으로 일반 그룹을 추가할 수 있습니다.

• Kubernetes 서비스
• Kubernetes 수신
• Kubernetes 게이트웨이
• Antrea IP 풀

다음 다이어그램은 NSX 논리적 네트워크의 VM에서 Antrea Kubernetes 클러스터로의 일반적인 트래픽 흐름을 보여 줍니다.

이 트래픽 흐름 다이어그램에 표시된 것처럼 Antrea Kubernetes 클러스터로 들어가는 트래픽을 일치시키기 위해 다음과 같은 시나리오가 가능합니다.

시나리오 1: 가상 IP 및 포트를 통해 외부 트래픽에 포드 노출

다음과 같은 네이티브 Kubernetes 리소스로 타사 로드 밸런서 솔루션을 구현하여 외부 트래픽에 포드를 노출할 수 있습니다.

• 수신: 계층 7 로드 밸런서로 작동합니다. 수신 리소스는 VIP(가상 IP 주소)를 제공하고 일부 포트(TCP/UDP)를 노출합니다.
• 게이트웨이: 계층 4 및 계층 7 로드 밸런서로 작동합니다. 게이트웨이 리소스는 VIP를 제공하고 일부 포트(TCP/UDP)를 노출합니다.
• LoadBalancer 유형의 서비스: 계층 4 로드 밸런서로 작동합니다. 서비스는 VIP를 제공하고 일부 포트(TCP/UDP)를 노출합니다.

참고: 수신 및 게이트웨이 리소스는 계층 7 로드 밸런서로 작동할 수 있지만 NSX의 분산 방화벽 규칙 및 게이트웨이 방화벽 규칙에서는 IP 주소 및 포트를 사용하여 수신 트래픽과 일치시킴으로써 계층 3 또는 계층 4 로드 밸런서로 나타납니다.

시나리오 2: 노드 IP 및 포트를 통해 외부 트래픽에 포드 노출

• NodePort 유형의 Kubernetes 서비스: K8s 클러스터의 모든 노드가 각 서비스 포트에 대한 노드에서 포트를 열도록 트리거합니다. 노드 IP 및 포트를 통해 서비스에 연결할 수 있습니다. 노드는 트래픽에 대해 SNAT 및 DNAT를 수행합니다.
• NodePortLocal 기능이 사용되도록 설정된 ClusterIP 유형의 Kubernetes 서비스: Antrea 에이전트에서 NodePortLocal 기능을 사용하도록 설정하고 Kubernetes 서비스의 매니페스트 파일에 주석을 추가해야 합니다. Antrea CNI는 주석을 인식하고 포드가 실행 중인 노드의 각 포드에 대한 포트를 엽니다. NodePortlLocal은 K8s 클러스터의 모든 노드에서 포트를 열지 않도록 하여 사용 가능한 포트 범위를 절약합니다. 또한 SNAT 작업을 방지하고 원래 클라이언트 IP를 유지합니다.

  NodePortLocal 기능에 대한 자세한 내용은 Antrea 설명서 포털에서 NodePortLocal 가이드를 참조하십시오.

시나리오 3: 라우팅 가능한 포드 IP 주소를 통해 외부 트래픽에 포드 노출

Antrea는 Antrea Kubernetes 클러스터에 IPPool 사용자 지정 리소스를 배포하여 포드에 라우팅 가능한 IP 주소를 할당하도록 지원합니다. 포드는 이 풀에서 할당된 IP 주소이며 IaaS 네트워크에 직접 브리징됩니다.

지원되는 IaaS 네트워크

Antrea Kubernetes 클러스터는 다음 IaaS 플랫폼에 배포될 수 있습니다.

• vSphere 기반 온-프레미스 데이터 센터: Tanzu Kubernetes Grid Service를 사용하여 생성된 Tanzu Kubernetes 클러스터로. 이러한 클러스터는 TKG(Tanzu Kubernetes Grid) 2.0 및 vSphere에서 관리됩니다.
• VMware Cloud: TKG 2.0 및 VMC SDDC에서 관리하는 Tanzu Kubernetes 클러스터로.
• 공용 클라우드: 공용 클라우드 플랫폼에서 관리되는 Kubernetes 클러스터로.
• 물리적 서버: 베어메탈 서버의 Kubernetes 클러스터로.
• OpenShift:
  • Antrea CNI는 OpenShift 클러스터에 배포되고 OpenShift는 IPI(설치 관리자 프로비저닝 인프라) 모드 또는 UPI(사용자 프로비저닝 인프라) 모드로 배포됩니다.
  • 인프라 제공자는 vSphere, AWS(Amazon Web Services), Azure, OpenStack, GCP(Google Cloud Platform), 베어메탈 중 하나일 수 있습니다.

중요: IaaS 네트워크는 Antrea Kubernetes 클러스터와 VM 간의 트래픽을 담당합니다. 온-프레미스 데이터 센터, VMC 및 공용 클라우드 등의 다른 사이트 간 트래픽에는 IaaS별 VPN이 사용될 수 있습니다. 모든 경우에 IaaS 네트워크가 적용되는 SNAT 작업이 있을 수 있습니다. NSX 관리자가 소스 또는 대상 IP 주소가 라우팅 가능한지 확인해야 방화벽 규칙에서 VM과 Kubernetes 클러스터 간의 트래픽을 보호하는 데 이러한 주소를 사용할 수 있습니다.

방화벽 정책을 적용하기 위한 권장 방식

분산 방화벽과 게이트웨이 방화벽을 모두 사용하면 방화벽 규칙의 소스 및 대상에서 Kubernetes 멤버 유형이 있는 일반 그룹을 지정할 수 있습니다. 따라서 분산 방화벽의 그룹과 게이트웨이 방화벽의 그룹 중 어떤 그룹을 참조할지를 유연하게 결정할 수 있습니다.

VMware는 다음과 같은 권장 사항을 제공합니다.

• NSX 게이트웨이 방화벽을 사용하여 Antrea Kubernetes 클러스터에서 NSX 네트워크에 있는 VM으로의 트래픽을 허용하거나 차단합니다.

  이 방법을 사용하면 트래픽이 NSX 오버레이 네트워크로 들어가는 가장 빠른 시점에 트래픽을 필터링할 수 있습니다.

• NSX 분산 방화벽을 사용하여 NSX 네트워크에 있는 VM에서 Antrea Kubernetes 클러스터로의 트래픽을 허용하거나 차단합니다.

  이 방법을 사용하면 트래픽이 NSX 오버레이 네트워크에서 VM을 떠나는 가장 빠른 시점에 트래픽을 필터링할 수 있습니다.

방화벽 정책의 사용에 대한 Kubernetes 멤버 유형 요약

다음 표에는 방화벽 규칙의 트래픽을 일치시키기 위해 NSX 일반 그룹에서 사용할 수 있는 Kubernetes 멤버 유형이 요약되어 있습니다.

멤버 유형	범위	방화벽 정책의 사용
Kubernetes 클러스터	클러스터	특정 클러스터의 리소스를 일치시키기 위한 AND 조건으로 동적 그룹 조건에 나타납니다.
Kubernetes 네임스페이스	네임스페이스	특정 네임스페이스의 리소스를 일치시키기 위한 AND 조건으로 동적 그룹 조건에 나타납니다.
Antrea 송신	클러스터	소스 IP가 송신 IP인 Antrea Kubernetes 클러스터의 송신 트래픽을 일치시킵니다.
Antrea IP 풀	클러스터	소스 IP가 IP 범위에 있는 Antrea Kubernetes 클러스터의 송신 트래픽을 일치시킵니다. 대상 IP가 IP 범위에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.
Kubernetes 노드	클러스터	소스 IP가 클러스터 노드 IP 주소 중 하나인 Antrea Kubernetes 클러스터의 송신 트래픽을 일치시킵니다.
Kubernetes 수신	네임스페이스	대상 IP가 수신 IP 주소에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.
Kubernetes 게이트웨이	네임스페이스	대상 IP가 게이트웨이 IP 주소에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.
Kubernetes 서비스(type=LoadBalancer)	네임스페이스	대상 IP가 LoadBalancer IP 주소에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.
Kubernetes 서비스(type=NodePort)	네임스페이스	대상 IP + 포트가 노드 IP 주소 + NodePort 범위에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.
Kubernetes 서비스(type=ClusterIP)	네임스페이스	없음
Kubernetes 서비스(type=ClusterIP) 및 NodePortLocal 기능 사용	네임스페이스	대상 IP + 포트가 노드 IP 주소 + NodePortLocal 범위에 있는 Antrea Kubernetes 클러스터로 들어오는 트래픽을 일치시킵니다.