Red Hat OpenShift 가상화를 위한 네트워크 설계 IBM Cloud VPC

IBM Cloud VPC 에서 ‘ Red Hat OpenShift ’ 가상화를 위한 네트워크를 설계하고, VPC 네트워킹, OpenShift 소프트웨어 정의 네트워킹(SDN), 그리고 Open Virtual Networking(OVN) 사용자 정의 네트워크를 다루십시오.

Red Hat OpenShift 가상화( IBM Cloud VPC )의 네트워크 설계에는 다음과 같은 뚜렷한 계층이 있습니다.

  • VPC 네트워킹
  • Red Hat OpenShift 네트워킹
  • OVN 네트워킹

주요 네트워크 아키텍처 요소는 다음 다이어그램에 나와 있습니다.

Red Hat OpenShift IBM Cloud 네트워크의 가상화 네트워크의 가상화 네트워크의 가상화 네트워크의 가상화 네트워크의 가상화
Red Hat OpenShift IBM Cloud

IBM Cloud VPC 네트워킹

IBM Cloud VPC 네트워킹을 사용하여 클라우드 리소스를 배포하고 관리합니다. 가상 서버, 컨테이너, 베어메탈 배포 등 워크로드를 위한 기반을 제공하여 네트워크 세분화, 보안, 확장성을 보장할 수 있습니다.

Red Hat® OpenShift® 를 프로비저닝하려면 VPC를 생성해야 합니다. Kubernetes Service 클러스터.

서브넷이 포함된 기본 프라이빗 네트워킹

Red Hat OpenShift Kubernetes Service 클러스터를 프로비저닝하려면 하나 이상의 가용 영역에 VPC 서브넷을 만들어야 합니다. 자세한 내용은 서브넷을 사용한 기본 비공개 네트워킹을 참조하세요.

로드 밸런서

외부 네트워크 트래픽의 인그레스 엔드포인트 역할을 하는 Red Hat OpenShift 인그레스 컨트롤러가 Red Hat OpenShift Kubernetes Service 클러스터에 배포됩니다. Red Hat OpenShift Kubernetes Service 클러스터에서는 VPC 애플리케이션 로드 밸런서가 클러스터별로 자동으로 생성되어 인그레스 컨트롤러를 노출합니다. 자세한 내용은 로드 밸런서를 참조하세요.

Red Hat OpenShift Kubernetes Service 는 다음과 같은 기능을 수행합니다.

  • DNS 서비스는 경로 하위 도메인을 VPC 로드 밸런서 호스트 이름으로 확인합니다.
  • VPC 로드 밸런서는 VPC 호스트명을, 정상적으로 작동 중인 것으로 보고된 인그레스 컨트롤러 서비스의 사용 가능한 외부 IP 주소로 변환합니다.
  • VPC 로드 밸런서는 요청을 인그레스 컨트롤러 서비스로 보냅니다.
  • Ingress 제어기가 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 해당 요청을 전달합니다.

가상 사설 엔드포인트

Red Hat OpenShift Kubernetes Service 환경의 VPE(가상 사설 엔드포인트)는 주로 공용 인터넷을 통과하는 네트워크 트래픽 없이 Red Hat OpenShift 클러스터와 IBM Cloud 플랫폼 서비스 간의 프라이빗 연결을 활성화하는 데 사용됩니다.

다음 표에는 필수 클러스터 작업을 위해 IBM Cloud 에서 자동으로 프로비저닝하는 모든 가상 사설 엔드포인트가 나열되어 있습니다.

클러스터 운영을 위해 프로비저닝되는 가상 사설 엔드포인트입니다.
가상 사설 엔드포인트 관리자 설명
iks-api Kubernetes Service API
  • IBM Cloud Kubernetes Service API에 대한 비공개 액세스
  • 클러스터 관리 작업(kubectl, oc 명령어)
  • 플레인 통신을 제어하는 워커 노드
  • IBM Cloud CLI 작업(ibmcloud ks 명령어)
  • 비공개 전용 클러스터 구성 활성화
iks-리아스 VPC 인프라 서비스
  • VPC 인프라 API에 대한 비공개 액세스
  • 워커 노드 프로비저닝 및 수명 주기 관리
  • 스토리지 볼륨 연결 및 관리
  • VPC 네트워킹 작업(로드 밸런서, 보안 그룹)
  • 인프라 리소스 관리
  • IBM Cloud 클러스터 오토스케일러, 볼륨 작업용 스토리지 CSI 드라이버, 로드 밸런서 프로비저닝 서비스, 워커 노드 수명 주기 컨트롤러에서 사용함
iks-등록 Container registry
  • IBM Cloud Container Registry
  • 공용 인터넷 없이 컨테이너 이미지 풀링
  • 공용 및 비공개 레지스트리 네임스페이스에 액세스
  • 이미지 풀링에 대한 공용 이그레스 요금 제거
iks-<클러스터_ID> 특정 클러스터 인스턴스
  • 클러스터 인스턴스 전용 프라이빗 엔드포인트
  • 직접 클러스터 API 액세스
  • 프라이빗 전용 클러스터 구성에 사용
  • 리전 API 엔드포인트의 대안
  • 직접 클러스터 액세스, VPC 내 서비스 간 통신, 프라이빗 클러스터 액세스 패턴이 필요한 도구에서 사용됨
iks-cos-config Cloud Object Storage (구성)
  • IBM Cloud Object Storage 구성 API에 대한 비공개 액세스
  • 버킷 관리 및 구성 작업
  • IAM 정책 및 접근 제어 관리
  • 서비스 자격 증명 작업
iks-cos Cloud Object Storage (데이터)
  • IBM Cloud Object Storage S3 API
  • 오브젝트 스토리지 데이터 플레인 작업(PUT/GET/삭제)
  • 백업 및 복원 데이터 전송
  • 애플리케이션 데이터 스토리지 액세스

Red Hat OpenShift 가상화 네트워킹

Red Hat OpenShift 가상화는 Red Hat OpenShift 네트워킹 기능을 사용하여 컨테이너화된 워크로드와 함께 실행되는 가상 서버에 유연한 소프트웨어 정의 네트워킹을 제공합니다. 가상 서버 네트워킹과 포드 네트워킹의 차이점을 이해하는 것이 중요합니다. 각 가상 서버는 항상 기본 포드 네트워크에 연결된 virt-launcher 포드 내에서 실행됩니다.

┌────────────────────────────────┐
│          Worker Node           │
│  ┌──────────────────────────┐  │
│  │      virt-launcher       │  │  ← Kubernetes Pod Security Context
│  │          pod             │  │
│  │  ┌────────────────────┐  │  │
│  │  │   virtual server   │  │  │  ← KVM/QEMU Hypervisor Isolation
│  │  │       (QEMU)       │  │  │
│  │  └────────────────────┘  │  │
│  └──────────────────────────┘  │
└────────────────────────────────┘

가상 서버를 프로비저닝하고 설정하는 방법에 따라 포드 네트워크를 공유하거나 multus)를 사용하여 다른 네트워크에 연결할 수 있습니다.

다음 예는 Red Hat OpenShift 의 기본 파드 네트워킹을 설명하며, OVN- Kubernetes 네트워킹으로 수정할 수 있습니다.

포드 네트워크(클러스터 네트워크)

  • 각 포드는 클러스터 네트워크의 CIDR(Classless Inter-Domain Routing)에서 사설 IP 주소를 할당받습니다
  • 노드 간 파드 간 통신 제공
  • 파드는 클러스터 내에서 프라이빗 IP를 사용하여 직접 통신한다
  • 네트워크 정책은 레이어 3/4에서 파드 간 트래픽을 제어합니다
  • 플랫 네트워크 모델 - 모든 파드가 기본적으로 통신 가능
  • 파드 간 NAT 없음(파드 간 직접 통신)
  • 네트워크 정책으로 세분화 및 보안 제공
  • 클러스터 내 DNS 기반 서비스 검색
  • 가상 서버가 virt-launcher 파드 내에서 실행될 때, 해당 서버의 IP 주소는 virt-launcher 파드의 IP 주소를 통해 NAT(네트워크 주소 변환) 처리됩니다

IP 마스커레이딩 (소스 NAT (SNAT))

  • 파드가 외부 네트워크에 대한 아웃바운드 연결을 시작할 때, 소스 IP가 가장된다
  • 요청 패킷의 발신 IP 주소는 포드가 실행되는 워커 노드의 IP 주소로 변경됩니다
  • 파드 IP는 클러스터 외부로 라우팅할 수 없으므로 IP 마스킹이 필요하다
  • 리턴 트래픽은 원래 포드 IP로 다시 위장됩니다
  • 외부 서비스는 파드 IP가 아닌 워커 노드 IP에서 오는 요청을 확인한다

ClusterIP 서비스

서비스는 안정적인 엔드포인트와 파드에 대한 로드 밸런싱을 제공합니다. 포드 IP를 추상화하고 애플리케이션에 일관된 액세스 포인트를 제공합니다. ClusterIP 서비스는 다음과 같은 기능을 제공합니다.

  • 클러스터 내에서만 액세스할 수 있는 가상 IP( ClusterIP )를 생성합니다
  • ClusterIP 지정하지 않은 경우 기본 서비스 유형입니다
  • 백엔드 포드 전반에 걸쳐 내부 로드 밸런싱 제공
  • 트래픽 분산을 위해 kube-proxy 또는 OVN- Kubernetes 사용

다음은 ClusterIP 사용 사례의 예입니다.

  • 내부 마이크로서비스 커뮤니케이션
  • 외부 액세스가 필요 없는 백엔드 서비스
  • 클러스터 워크로드만 액세스하는 데이터베이스 서비스
  • 포드 간 서비스 검색

NodePort 서비스

서비스는 안정적인 엔드포인트와 파드에 대한 로드 밸런싱을 제공합니다. 포드 IP를 추상화하고 애플리케이션에 일관된 액세스 포인트를 제공합니다. NodePort 서비스는 다음과 같은 기능을 제공합니다.

  • 각 워커 노드의 정적 포트(30000-32767 범위)에 서비스를 노출합니다
  • 다음을 통해 서비스에 액세스할 수 있습니다 <NodeIP>:<NodePort>
  • ClusterIP 서비스 자동 생성
  • 모든 NodePort 포워드로의 트래픽이 서비스로 전달됩니다

다음 예는 NodePort 트래픽 흐름을 보여줍니다.

  • 외부 클라이언트는 다음에 연결합니다 <WorkerNodeIP>:<NodePort>
  • 노드는 트래픽을 ClusterIP 서비스로 전달합니다
  • 이 서비스는 백엔드 파드로의 부하를 분산시킵니다
  • 응답은 SNAT(소스 네트워크 주소 변환)을 통해 역방향 경로를 따라 전송됩니다

다음 사용 사례는 NodePorts 의 사용 예시입니다.

  • 개발 및 테스트 환경
  • 로드 밸런서 없이 빠른 외부 접속
  • 외부 로드밸런서와의 통합
  • 맞춤형 로드 밸런싱 솔루션

로드 밸런서 서비스

IBM Cloud Red Hat OpenShift Kubernetes Service 에서 로드 밸런서 서비스는 VPC 네트워크 로드 밸런서 또는 애플리케이션 로드 밸런서를 자동으로 프로비저닝합니다. 로드 밸런서 서비스는 다음과 같은 기능을 제공합니다.

  • 외부 로드 밸런서 자동 프로비저닝
  • 서비스에 외부 IP 또는 호스트 이름을 할당합니다
  • NodePort 및 ClusterIP 서비스를 자동으로 생성합니다
  • 서비스 백엔드에 레이어 4 로드 밸런싱 제공

다음 예는 VPC의 트래픽 흐름을 보여줍니다.

  • 외부 클라이언트가 VPC 로드밸런서 IP 또는 호스트 이름에 연결합니다
  • VPC 로드 밸런서가 워커 노드에 배포합니다 NodePorts
  • Node 서비스 포워딩 ClusterIP
  • 이 서비스는 백엔드 파드로의 부하를 분산시킵니다

다음 사용 사례는 로드 밸런서가 어떤 용도로 사용되는지 보여주는 예시입니다.

  • 전용 외부 액세스가 필요한 프로덕션 애플리케이션
  • 비 HTTP 프로토콜( TCP 또는 UDP 서비스)
  • 안정적인 외부 IP가 필요한 애플리케이션
  • 인그레스 또는 라우팅 계층을 우회하는 서비스

Red Hat OpenShift 노선

Red Hat OpenShift 라우트는 완전 지정 도메인 이름(FQDN)을 백엔드 서비스에 매핑하여 외부 네트워크 트래픽에 서비스를 노출시킴으로써, 클러스터 외부에서도 애플리케이션에 접근할 수 있게 합니다. 다음 목록은 Red Hat OpenShift 경로의 주요 기능을 보여줍니다.

  • 레이어 7 라우팅 - HTTP / HTTPS 호스트 이름 기반 라우팅을 사용하는 트래픽
  • 자동 DNS - 경로가 클러스터 하위 도메인을 사용합니다: <route-name>-<namespace>.apps.<cluster-domain>
  • 보안되지 않은 경로 ( HTTP )
  • TLS 종료
    • 에지 종단 경로(라우터에서 TLS )
    • 패스스루 경로( TLS (포드에서))
    • 경로 재암호화(라우터와 파드에서 TLS )
  • HAProxy-기반은 Red Hat OpenShift 인그레스 컨트롤러(라우터)에 의해 구현됩니다
  • 트래픽 관리 - 경로 기반 라우팅, 트래픽 분할 및 세션 선호도

개방형 가상 네트워킹(OVN)

OVN- Kubernetes 컨테이너 네트워크 인터페이스(CNI) 플러그인은 Red Hat OpenShift 가상화를 위한 권장 네트워킹 옵션으로, 기존 포드 네트워킹과 병행하여 실행되는 가상 서버 네트워킹 사용 사례를 지원합니다. OVN- Kubernetes 는 Open Virtual Networking(OVN)을 기반으로 하며, 모든 워커 노드에서 Open vSwitch (OVS)를 사용합니다. 멀티테넌시, NetworkPolicies,, 하이브리드 가상 서버 및 포드 네트워킹을 지원합니다. Red Hat OpenShift on IBM Cloud VPC는 기본 네트워킹 플러그인으로 OVN( Kubernetes )을 지원합니다.

VMware vSphere 및 NSX-T에 익숙한 관리자의 경우, OVN 개념과 vSphere 의 해당 개념 간의 대응 관계를 확인하려면 ‘ vSphere ’ 관리자를 위한 ‘ OpenShift ’의 OVN 네트워킹 섹션을 참조하십시오.

Red Hat OpenShift 에서 다음 세 가지 네트워킹 토폴로지는 파드와 가상 서버에 보조 네트워크 연결을 제공합니다.

  • 레이어 2 ( L2 )- Geneve 인캡슐레이션을 사용한 소프트웨어 정의 L2 브로드캐스트 도메인
  • 레이어 3 ( L3 )- 사용자 지정 IP 서브넷이 있는 라우팅된 네트워크 세그먼트입니다. L3 네트워크는 노드마다 별도의 CIDR(Classless Inter-Domain Routing)을 갖습니다.
  • 로컬넷 - 기본 물리적 네트워크 VLAN에 대한 직접 액세스

Red Hat OpenShift 에서 가상화 IBM Cloud, OVN 레이어 2 및 OVN 로컬넷은 사용자 정의 네트워크(UDN)와 함께 사용되는 두 가지 기본 토폴로지입니다.

  • OVN 레이어 2는 Geneve 캡슐화를 사용하여 클러스터 전체에 소프트웨어 정의 L2 브로드캐스트 도메인을 생성함으로써 NSX 오버레이 세그먼트와 유사한 오버레이 네트워킹을 제공합니다. 이러한 네트워크는 VPC 서브넷으로부터 격리되어 있습니다. VPC 서브넷과 VPC 경로에 대한 수신 및 발신을 제공하기 위해 OVN 로컬넷에 연결된 게이트웨이 포드 또는 가상 서버가 필요합니다.
  • OVN 로컬넷은 기본 VPC 네트워크에 대한 VLAN 액세스를 제공하며 NSX VLAN 지원 세그먼트와 유사합니다. IBM Cloud VPC 에서 이 직접 연결을 통해 가상 서버와 파드는 VNI(가상 네트워크 인터페이스) 및 VLAN 연결을 사용하여 VPC 서브넷에 직접 연결할 수 있습니다.

다음 다이어그램은 OVN 및 multus 을 사용한 가상 서버 네트워킹의 개요를 보여줍니다. 기본적으로 Kubernetes (및 Red Hat OpenShift )는 기본 CNI 플러그인(예: OVN- Kubernetes )을 사용하여 각 파드에 단일 네트워크 인터페이스를 할당합니다. Multus( Red Hat OpenShift )는 파드 및 가상 서버를 위한 다중 네트워크 인터페이스를 지원하는 CNI 플러그인입니다.

멀티유스를 통한 OVN 네트워킹
멀티유스를 통한 OVN 네트워킹

처음에는 OVN 레이어 2 네트워킹만 사용할 수 있습니다.

OVN 사용자 정의 네트워크

Red Hat OpenShift 가상화

Red Hat OpenShift 의 UDN(사용자 정의 네트워크)은 OVN- Kubernetes 에서 제공하는 사용자 정의 네트워크입니다. UDN은 자체 IP 서브넷, 게이트웨이 및 라우팅 도메인이 있는 네트워크를 만드는 데 사용하는 기본 클러스터 네트워크(기본 포드 네트워크라고도 함) UDN을 대체합니다. UDN은 기본 포드 네트워크와 독립적이며 워크로드에 다음 기능이 필요할 때 일반적으로 사용됩니다.

  • 클러스터의 다른 애플리케이션으로부터 네트워크 격리
  • 사용자 지정 IP 주소 범위 또는 겹치는 서브넷
  • 선택한 네임스페이스 또는 워크로드 간 횡방향 트래픽에 대한 직접 제어
  • 여러 네트워크 인터페이스가 필요한 가상 서버( Red Hat OpenShift 가상화)와의 통합
  • 보안 또는 규정 준수 요건을 위한 전용 네트워크 세그먼트

기본 파드 네트워크와 달리 UDN은 네임스페이스에 명시적으로 연결됩니다. 각 UDN은 OVN에 추가 논리적 스위치를 생성합니다. UDN이 네임스페이스의 기본 사용자 정의 네트워크로 레이블이 지정되면 해당 네임스페이스의 모든 파드와 가상 서버는 클러스터 기본값 대신 기본 네트워크로 사용합니다.

클러스터 사용자 정의 네트워크(CUDN)는 특정 네임스페이스에 속하지 않는 클러스터 범위의 리소스를 제공함으로써 UDN 개념을 확장합니다. CUDN이 생성되고 하나 이상의 네임스페이스와 연결됩니다. 네임스페이스당 하나씩 필요한 네임스페이스 범위가 지정된 NetworkAttachmentDefinition (NAD) 리소스와 달리 CUDN은 네임스페이스가 CUDN 정의에 추가되면 네임스페이스에 자동으로 NAD를 생성합니다.

UDN은 범위, 연결 방법, 토폴로지에 따라 유연한 네트워킹 옵션을 제공합니다:

네트워크 범위

  • 네임스페이스 범위 UDN - 단일 네임스페이스로 제한되는 네트워크 정의로, 네임스페이스당 별도의 NetworkAttachmentDefinitions 가 필요합니다
  • 클러스터 범위 CUDN - 클러스터 전체에서 네트워크 정의를 사용할 수 있으며, 선택한 네임스페이스에 NetworkAttachmentDefinitions 를 자동으로 생성합니다

첨부 방법

  • 기본 네트워크 - 네임스페이스의 모든 파드/가상 서버의 기본 네트워크 역할을 하며 클러스터 기본 네트워크를 대체한다
  • 보조 네트워크 - Multus CNI를 통해 연결하여 기본 네트워크와 함께 파드/가상 서버에 추가 네트워크 인터페이스를 제공합니다

네트워크 토폴로지

  • 레이어 2 - Geneve 캡슐화를 사용하여 소프트웨어 정의된 L2 브로드캐스트 도메인을 구현함으로써, 주소 확인 프로토콜(ARP) 기반의 탐색 및 MAC 간 통신을 가능하게 합니다
  • 레이어 3 - 사용자 지정 IP 서브넷 및 게이트웨이가 있는 라우팅된 네트워크 세그먼트
  • 로컬넷 - VNI(가상 네트워크 인터페이스) 연결을 사용하여 기본 VPC 서브넷에 대한 직접 VLAN 액세스

이러한 특성을 결합하여 맞춤형 네트워킹 솔루션을 만들 수 있습니다. 예를 들어, 로컬넷 토폴로지를 사용하는 클러스터 범위의 CUDN은 여러 네임스페이스에 기본 또는 보조 네트워크로서 직접 VPC 서브넷 액세스를 제공할 수 있습니다.

OVN 레이어 2 네트워크

OVN 레이어 2 네트워크는 NSX 오버레이 세그먼트 또는 기존 VLAN과 유사한 소프트웨어 정의 레이어 2 브로드캐스트 도메인입니다. 레이어 2는 클러스터의 기존 네트워크 인프라를 통해 Geneve 캡슐화를 사용하여 OVN 내에서 전적으로 구현됩니다. 레이어 2 네트워크를 사용하면 파드와 가상 서버가 마치 동일한 이더넷 세그먼트에 있는 것처럼 통신할 수 있으며 ARP 검색, 브로드캐스트, 멀티캐스트 및 직접 MAC-to-MAC 통신을 지원합니다.

Red Hat OpenShift 클러스터에는 파드와 가상 서버가 OVN을 통해 라우팅되는 기본 클러스터 CIDR에서 IP를 수신하는 기본 클러스터 네트워크가 있습니다. ClusterUserDefinedNetwork (CUDN) 또는 네임스페이스 범위가 지정된 UDN을 통해 보조 레이어 2 네트워크를 정의합니다. 보조 레이어 2 네트워크는 기본 포드 네트워크 외에 추가로 생성하는 네트워크입니다.

다음 항목은 레이어 2 네트워크의 주요 특징입니다.

  • OVN에서 생성한 레이어 2 브로드캐스트 도메인에 IPAM, MAC 할당 및 연결을 제공합니다
  • 보조 네트워크에서 포드 이름에 대한 기본 제공 DNS 확인 없음
  • 주 레이어 2 네트워크에서 발생하는 트래픽은 가상 서버를 빠져나갈 때 소스 네트워크 주소가 변환(NAT)되며, 또한 FRR-K8s 및 VPC 경로를 사용하여 구성할 수 있는 레이어 2 네트워크로 라우팅됩니다
  • 보조 레이어 2 네트워크는 명시적으로 구성하지 않는 한 기본적으로 인터넷에 직접 액세스하지 않고 격리되어 있습니다
  • 클러스터 내 가상 서버 간 통신 및 멀티캐스트 종속 애플리케이션에 적합합니다

OVN 로컬넷 네트워크

OVN 로컬넷 네트워크는 가상 서버와 파드에 기본 VPC 네트워크 인프라에 대한 직접 VLAN 액세스를 제공합니다. OVN 로컬넷은 가상 서버와 파드가 가상 네트워크 인터페이스(VNI) 및 VLAN 연결을 사용하여 VPC 서브넷에 연결할 수 있게 해줍니다.

VLAN 연결을 사용하면 Red Hat OpenShift 가상화에서 실행되는 가상 서버를 VPC 서브넷에 직접 연결할 수 있습니다. 이 접근 방식을 사용하면 워크로드 전반에 걸쳐 일관된 네트워킹을 제공함으로써 신규 또는 마이그레이션된 가상 서버에 기존 VPC 서브넷 설계를 사용할 수 있습니다.

로컬넷 네트워킹을 사용하려면 VPC 서브넷에 연결된 각 가상 서버 NIC에 다음 요구 사항이 필요합니다:

  • VPC 서브넷에서 예약된 IP 주소와 VNI에 대한 인바운드 및 아웃바운드 트래픽을 제어하는 하나 이상의 보안 그룹을 정의하는 VNI(가상 네트워크 인터페이스) 리소스입니다.
  • 베어메탈 서버 VLAN 연결. 가상 서버가 다른 워커 노드로 라이브 마이그레이션되려면, 해당 VLAN 연결이 워커 노드 간에 이동할 수 있는지 여부를 결정하는 ‘플로팅’ 기능이 활성화되어 있어야 합니다.
  • VLAN ID. VLAN 태그는 워커 노드의 PCI 인터페이스를 연결합니다. 일반적으로 이 연결은 VLAN ID와 VPC 서브넷 간의 일대일 매핑입니다.

로컬넷 네트워크에 대한 보안 그룹 규칙을 설계할 때는 일부 네트워크 스위칭이 작업자 노드의 OVS 내에서 발생하고 VPC 인프라에 도달하지 않는다는 점을 고려하세요. 보안 그룹 규칙은 VPC 네트워크 패브릭을 통과하는 트래픽에만 적용됩니다. 동일한 작업자 노드에 있는 가상 서버 간의 트래픽은 VPC 보안 제어를 우회할 수 있습니다.

다음은 Localnet의 사용 사례입니다.

  • 기존 VPC 서브넷 IP 주소가 필요한 마이그레이션된 가상 서버
  • 기존 VPC 보안 그룹 및 네트워크 정책과의 통합
  • 다른 VPC 리소스에 직접 연결
  • VPC 서브넷을 사용한 네트워크 세분화에 대한 규정 준수 요구 사항
  • VPC 및 Red Hat OpenShift 가상화 전반에 걸쳐 일관된 IP 주소 지정이 필요한 하이브리드 아키텍처

다음 단계

이제 Red Hat OpenShift 가상화를 위한 네트워킹 설계를 이해했으니 관련 주제를 살펴보세요: