Red Hat OpenShift Virtualization: 외부 네트워크를 사용하도록 가상 머신 설정

Red Hat OpenShift의 네트워킹 아키텍처는 수많은 컨테이너화된 애플리케이션을 위한 강력하고 확장 가능한 프론트엔드를 제공합니다. 서비스는 포드 태그를 기반으로 간단한 부하 분산을 제공하고, 경로는 이러한 서비스를 외부 네트워크에 노출합니다. 이러한 개념은 마이크로서비스에 매우 효과적이지만 OpenShift Virtualization의 가상 시스템에서 실행되는 애플리케이션에는 어려울 수 있습니다. 이 경우 기존 서버 관리 인프라가 이미 마련되어 있으며 가상 시스템에 대한 전체 액세스를 항상 사용할 수 있다고 가정합니다.

이전 문서에서 OpenShift Virtualization을 설치하고 구성하는 방법과 기본 가상 시스템을 실행하는 방법을 보여주었습니다. 이 문서에서는 널리 사용되는 다른 하이퍼바이저와 매우 유사한 방식으로 가상 시스템이 외부 네트워크에 액세스할 수 있도록 OpenShift Virtualization 클러스터를 구성하는 다양한 옵션에 대해 설명합니다.

OpenShift를 외부 네트워크에 연결

내부 포드 네트워크 외에도 외부 네트워크에 액세스하도록 OpenShift를 구성할 수 있습니다. 이 작업은 OpenShift 클러스터에서 NMState 연산자를 사용하여 수행됩니다. OpenShift Operator Hub에서 NMState 운영자를 설치할 수 있습니다.

NMState 운영자는 OpenShift용 CNI 플러그인인 Multus와 함께 작동하므로 포드가 여러 네트워크와 통신할 수 있습니다. 이미 Multus에 관한 훌륭한 기사가 있으므로, 여기서 자세한 설명은 생략하고 대신 NMState와 Multus를 사용하여 가상 머신을 여러 네트워크에 연결하는 방법에 중점을 두겠습니다.

NMState 구성 요소 개요

NMState 운영자를 설치하고 나면 클러스터 노드에서 네트워크 인터페이스를 구성할 수 있는 세 개의 CRD(CustomResoureDefinitions)가 추가됩니다. OpenShift 노드에서 네트워크 인터페이스를 구성할 때 이러한 오브젝트와 상호 작용합니다.

• NodeNetworkState

  (nodenetworkstates. nmstate.io)는 각 클러스터 노드에 대해 하나의 NNS(NodeNetworkState) 오브젝트를 설정합니다. 오브젝트의 내용은 해당 노드의 현재 네트워크 상태를 자세히 설명합니다.

• NodeNetworkConfigurationPolicies

  (nodenetworkconfigurationpolicies. nmstate.io)는 NMState 운영자에게 노드 그룹에서 다양한 네트워크 인터페이스를 구성하는 방법을 알려주는 정책입니다. 즉, OpenShift 노드에 대한 구성 변경 사항을 나타냅니다.

• NodeNetworkConfigurationEnactments

  (nodenetworkconfigurationenactments. nmstate.io)는 적용된 각 NNCP(NodeNetworkConfigurationPolicy)의 결과를 NNCE(NodeNetworkConfigurationEnactment) 오브젝트에 저장합니다. 각 NNCP에 대해 각 노드에 대해 하나의 NNCE가 있습니다.

이러한 정의를 제거하고 OpenShift 노드에서 네트워크 인터페이스 구성으로 이동할 수 있습니다. 이 문서에서 사용하는 랩의 하드웨어 구성에는 3개의 네트워크 인터페이스가 포함되어 있습니다. 첫 번째는 enp1s0이며, 브리지 br-ex를 사용하여 클러스터 설치 중에 이미 구성되어 있습니다. 아래의 옵션 #1에서 사용하는 브리지 및 인터페이스입니다. 두 번째 인터페이스인 enp2s0은 enp1s0과 동일한 네트워크에 있으며, 이 인터페이스를 사용하여 아래의 옵션 #2에서 OVS 브리지 br0를 구성합니다. 마지막으로 인터페이스 enp8s0은 인터넷 액세스 및 DHCP 서버 없이 별도의 네트워크에 연결됩니다. 이 인터페이스를 사용하여 아래의 옵션 #3에서 Linux 브리지 br1 을 구성합니다.

옵션 #1: 단일 NIC로 외부 네트워크 사용

OpenShift 노드에 네트워킹을 위한 단일 NIC만 있는 경우 가상 시스템을 외부 네트워크에 연결하는 유일한 옵션은 OVN-Kubernetes 클러스터에서 실행 중인 모든 노드의 기본값인 br-ex 브리지를 재사용하는 것입니다. 즉, 이전 Openshift-SDN을 사용하는 클러스터에서는 이 옵션을 사용하지 못할 수 있습니다.

클러스터의 기본 작업에 부정적인 영향을 주지 않고 br-ex 브리지를 완전히 재구성할 수 없으므로 대신 해당 브리지에 로컬 네트워크를 추가해야 합니다. 다음NodeNetworkConfigurationPolicy 설정을 사용하여 이 작업을 수행할 수 있습니다.

$ cat br-ex-nncp.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br-ex-network
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: br-ex-network
        bridge: br-ex 
        state: present

대부분의 경우 위의 예제는 br-ex 브리지에 로컬 네트워크를 추가하는 모든 환경에서 동일합니다. 일반적으로 변경되는 유일한 부분은 NNCP의 이름(.metadata.name)과 localnet의 이름(.spec.desiredstate.ovn.bridge-mappings)입니다. 이 예제에서는 둘 다 br-ex-network이지만, 이름은 임의적이며 서로 같을 필요는 없습니다. NetworkAttachmentDefinition를 구성할 때 localnet에 사용된 값이 필요하므로 나중에 사용할 수 있도록 해당 값을 기억하십시오!

NNCP 구성을 클러스터 노드에 적용합니다.

$ oc apply -f br-ex-nncp.yaml
nodenetworkconfigurationpolicy.nmstate.io/br-ex-network

다음 명령을 사용하여 NNCP 및 NNCE의 진행 상황을 확인합니다.

$ oc get nncp
NAME            STATUS        REASON
br-ex-network   Progressing   ConfigurationProgressing
$ oc get nnce
NAME                               STATUS        STATUS AGE   REASON
lt01ocp10.matt.lab.br-ex-network   Progressing   1s          ConfigurationProgressing
lt01ocp11.matt.lab.br-ex-network   Progressing   3s           ConfigurationProgressing
lt01ocp12.matt.lab.br-ex-network   Progressing   4s           ConfigurationProgressing

이 경우 br-ex-network 라는 단일 NNCP가 각 노드에 대해 NNCE를 생성했습니다. 몇 초 후에 프로세스가 완료됩니다.

$ oc get nncp
NAME            STATUS      REASON
br-ex-network   Available   SuccessfullyConfigured
$ oc get nnce
NAME                               STATUS      STATUS AGE   REASON
lt01ocp10.matt.lab.br-ex-network   Available   83s          SuccessfullyConfigured
lt01ocp11.matt.lab.br-ex-network   Available   108s         SuccessfullyConfigured
lt01ocp12.matt.lab.br-ex-network   Available   109s         SuccessfullyConfigured

이제 가상 시스템을 방금 만든 새 네트워크에 연결하는 방법을 정의하는 NetworkAttachmentDefinition으로 이동할 수 있습니다.

NetworkAttachmentDefinition 구성

OpenShift 콘솔에서NetworkAttachmentDefinition을 생성하려면 가상 시스템(이 예제에서는 vmtest)을 생성하는 프로젝트를 선택하고 Networking > NetworkAttachmentDefinitions로 이동합니다. 그런 다음 Create network attachment definition(네트워크 연결 정의 생성) 파란색 버튼을 클릭합니다.

콘솔은 NetworkAttachmentDefinition을 생성하는 데 사용할 수 있는 양식을 제공합니다.

Name 필드는 임의적이지만 이 예제에서는 NNCP(br-ex-network)에 사용한 것과 동일한 이름을 사용합니다. Network Type(네트워크 유형)에서 OVN Kubernetes secondary localnet network를 선택해야 합니다.

브리지 매핑 필드에 이전에 구성한 localnet의 이름을 입력합니다(이 예제에서는 br-ex-network이기도 함). 필드에서 "브리지 매핑"을 요청하기 때문에 "br-ex"를 입력하고 싶을 수 있지만, 실제로는 br-ex에 이미 연결되어 있는 생성한 localnet을 사용해야 합니다.

또는 콘솔 대신 YAML 파일을 사용하여NetworkAttachmentDefinition를 생성할 수 있습니다.

$ cat br-ex-network-nad.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: br-ex-network
  namespace: vmtest
spec:
  config: '{
            "name":"br-ex-network",
            "type":"ovn-k8s-cni-overlay",
            "cniVersion":"0.4.0",
            "topology":"localnet",
            "netAttachDefName":"vmtest/br-ex-network"
          }'
$ oc apply -f br-ex-network-nad.yaml
networkattachmentdefinition.k8s.cni.cncf.io/br-ex-network created

위의 NetworkAttachmentDefinition YAML에서 .spec.config의 name 필드는 NNCP의 localnet 이름이며, netAttachDefName은 네임스페이스/이름 형식으로  .metadata 섹션에 있는 두 개의 동일한 필드와 일치해야 하는 입니다(이 경우vmtest/br-ex-network).

가상 시스템은 IP 주소 지정에 정적 IP 또는 DHCP를 사용하므로 NetworkAttachmentDefinition의 IP 주소 관리(IPAM)는 가상 시스템에서 작동하지 않으며 지원되지 않습니다.

가상 시스템 NIC 구성

가상 시스템에서 새 외부 네트워크를 사용하려면 가상 시스템의 네트워크 인터페이스 섹션을 수정하고 새 vmtest/br-ex-network를 네트워크 유형으로 선택합니다. 이 형식으로 MAC 주소를 사용자 지정할 수도 있습니다.

평소와 같이 가상 시스템을 계속 생성합니다. 가상 시스템이 부팅되면 가상 NIC가 외부 네트워크에 연결됩니다. 이 예제에서 외부 네트워크에는 DHCP 서버가 있으므로 IP 주소가 자동으로 할당되고 네트워크에 대한 액세스가 허용됩니다.

br-ex에서 NetworkAttachmentDefinition 및 localnet 삭제

위의 단계를 실행 취소하려면 먼저 NetworkAttachmentDefinition를 사용하는 가상 시스템이 없는지 확인한 다음 콘솔을 사용하여 삭제합니다. 또는 명령을 사용합니다.

$ oc delete network-attachment-definition/br-ex-network -n vmtest
networkattachmentdefinition.k8s.cni.cncf.io "br-ex-network" deleted

그런 다음 NodeNetworkConfigurationPolicy를 삭제합니다. 정책을 삭제해도 OpenShift 노드의 변경 사항은 실행 취소되지 않습니다!

$ oc delete nncp/br-ex-network
nodenetworkconfigurationpolicy.nmstate.io "br-ex-network" deleted

NNCP를 삭제하면 연결된 모든 NNCE도 삭제됩니다.

$ oc get nnce
No resources found

마지막으로 이전에 사용한 NNCP YAML 파일을 수정하되, 브리지 매핑 상태를 present(있음)에서 absent(없음)으로 변경합니다.

$ cat br-ex-nncp.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br-ex-network
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: '' 
  desiredState:
    ovn:
      bridge-mappings:
      - localnet: br-ex-network
        bridge: br-ex 
        state: absent  # Changed from present

업데이트된 NNCP를 다시 적용합니다.

$ oc apply -f br-ex-nncp.yaml
nodenetworkconfigurationpolicy.nmstate.io/br-ex-network
$ oc get nncp
NAME            STATUS      REASON
br-ex-network   Available   SuccessfullyConfigured
$ oc get nnce
NAME                               STATUS      STATUS AGE   REASON
lt01ocp10.matt.lab.br-ex-network   Available   2s           SuccessfullyConfigured
lt01ocp11.matt.lab.br-ex-network   Available   29s          SuccessfullyConfigured
lt01ocp12.matt.lab.br-ex-network   Available   30s          SuccessfullyConfigured

localnet 구성이 이제 제거되었습니다. NNCP를 안전하게 삭제할 수 있습니다.

옵션 #2: 전용 NIC에서 OVS 브리지와 함께 외부 네트워크 사용

OpenShift 노드는 서로 다른 물리적 NIC를 사용하는 여러 네트워크에 연결할 수 있습니다. 많은 구성 옵션(예: 본딩 및 VLAN)이 있지만 이 예제에서는 전용 NIC를 사용하여 OVS 브리지를 구성합니다. 본드 생성 또는 VLAN 사용과 같은 고급 구성 옵션에 대한 자세한 내용은 설명서를 참조하십시오.

이 명령어를 사용하면 모든 노드 인터페이스를 볼 수 있습니다 (편의를 위해 출력은 여기서 생략되었습니다).

$ oc get nns/lt01ocp10.matt.lab -o jsonpath='{.status.currentState.interfaces[3]}' | jq
{
…
  "mac-address": "52:54:00:92:BB:00",
  "max-mtu": 65535,
  "min-mtu": 68,
  "mtu": 1500,
  "name": "enp2s0",
  "permanent-mac-address": "52:54:00:92:BB:00",
  "profile-name": "Wired connection 1",
  "state": "up",
  "type": "ethernet"
}

이 예제에서 모든 노드에서 사용되지 않은 네트워크 어댑터는 enp2s0입니다.

이전 예제와 마찬가지로 사용되지 않은 NIC( 이 예제에서는 enp2s0)를 사용하여 노드에 br0라는 새 OVS 브리지를 생성하는 NNCP로 시작합니다. NNCP는 다음과 같이 표시됩니다.

$ cat br0-worker-ovs-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br0-ovs
spec:
  nodeSelector: 
    node-role.kubernetes.io/worker: ""
  desiredState:
    interfaces:
    - name: br0 
      description: |-
        A dedicated OVS bridge with enp2s0 as a port
        allowing all VLANs and untagged traffic
      type: ovs-bridge
      state: up
      bridge:
        options:
          stp: true
        port:
        - name: enp2s0
    ovn:
      bridge-mappings:
      - localnet: br0-network
        bridge: br0 
        state: present

위의 예제에서 가장 먼저 주목해야 할 사항은 임의적이며 NNCP의 이름을 식별하는 .metadata.name 필드입니다. 또한 파일의 끝 부분에서 단일 NIC 예제에서 br-ex와 마찬가지로 localnet 브리지 매핑을 새 br0 브리지에 추가하고 있음을 확인할 수 있습니다.

br-ex를 브리지로 사용하는 이전 예제에서는 모든 OpenShift 노드에 이 이름의 브리지가 있다고 가정하는 것이 안전하므로 모든 작업자 노드에 NNCP를 적용했습니다. 그러나 현재 시나리오에서는 동일한 네트워크에 대해 NIC 이름이 다른 이기종 노드가 있을 수 있습니다. 이 경우 각 노드 유형에 레이블을 추가하여 구성을 식별해야 합니다. 그런 다음 위의 예에서 .spec.nodeSelector를 사용하여 이 구성을 사용할 노드에만 구성을 적용할 수 있습니다. 다른 노드 유형의 경우 기본 NIC 이름이 다른 경우에도 NNCP 및 nodeSelector를 수정하고 해당 노드에 동일한 브리지를 만들 수 있습니다.

이 예제에서 NIC 이름은 모두 동일하므로 모든 노드에 동일한 NNCP를 사용할 수 있습니다.

이제 단일 NIC 예제와 마찬가지로 NNCP를 적용합니다.

$ oc apply -f br0-worker-ovs-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br0-ovs created

이전과 마찬가지로 NNCP 및 NNCE는 성공적으로 생성하고 적용하는 데 다소 시간이 걸립니다. NNS에서 새 브리지를 확인할 수 있습니다.

$ oc get nns/lt01ocp10.matt.lab -o jsonpath='{.status.currentState.interfaces[3]}' | jq
{
…
    "port": [
      {
        "name": "enp2s0"
      }
    ]
  },
  "description": "A dedicated OVS bridge with enp2s0 as a port allowing all VLANs and untagged traffic",
…
  "name": "br0",
  "ovs-db": {
    "external_ids": {},
    "other_config": {}
  },
  "profile-name": "br0-br",
  "state": "up",
  "type": "ovs-bridge",
  "wait-ip": "any"
}

NetworkAttachmentDefinition 구성

OVS 브리지에 대한 NetworkAttachmentDefinition을 생성하는 프로세스는 단일 NIC를 사용하는 이전 예제와 동일합니다. 두 경우 모두 OVN 브리지 매핑을 생성하기 때문입니다. 현재 예제에서 브리지 매핑 이름은 br0-network이므로 NetworkAttachmenDefinition 생성 양식에서 이를 사용하면 됩니다.

또는, YAML 파일을 사용하여NetworkAttachmentDefinition를 생성할 수 있습니다.

$ cat br0-network-nad.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: br0-network
  namespace: vmtest
spec:
  config: '{
            "name":"br0-network",
            "type":"ovn-k8s-cni-overlay",
            "cniVersion":"0.4.0",
            "topology":"localnet",
            "netAttachDefName":"vmtest/br0-network"
          }'
$ oc apply -f br0-network-nad.yaml
networkattachmentdefinition.k8s.cni.cncf.io/br0-network created

가상 시스템 NIC 구성

이전과 마찬가지로 NIC 네트워크에 대해 vmtest/br0-network라는 새로운NetworkAttachmentDefinition을 사용하여 가상 시스템을 정상적으로 생성합니다.

가상 시스템이 부팅되면 NIC는 노드에서 br0 브리지를 사용합니다. 이 예제에서 br0의 전용 NIC는 br-ex 브리지와 동일한 네트워크에 있으므로 이전과 동일한 서브넷에서 IP 주소를 가져오고 네트워크 액세스가 허용됩니다.

NetworkAttachmentDefinition 및 OVS 브리지 삭제

NetworkAttachmentDefinition 및 OVS 브리지를 삭제하는 프로세스는 대부분 이전 예제와 동일합니다. NetworkAttachmentDefinition를 사용하는 가상 시스템이 없는지 확인한 다음 Console 또는 명령줄에서 삭제합니다.

$ oc delete network-attachment-definition/br0-network -n vmtest
networkattachmentdefinition.k8s.cni.cncf.io "br0-network" deleted

그런 다음 NodeNetworkConfigurationPolicy를 삭제합니다(정책을 삭제해도 OpenShift 노드의 변경 사항이 취소되지 않음).

$ oc delete nncp/br0-ovs
nodenetworkconfigurationpolicy.nmstate.io "br0-ovs" deleted

NNCP를 삭제하면 연결된 NNCE도 삭제됩니다.

$ oc get nnce
No resources found

마지막으로, 이전에 사용된 NNCP YAML 파일을 수정하되, 인터페이스 상태를 "up"에서 "absent"로, 브리지 매핑 상태를 "present"에서 "absent"로 변경합니다.

$ cat br0-worker-ovs-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br0-ovs
spec:
  nodeSelector: 
    node-role.kubernetes.io/worker: ""
  desiredState:
    Interfaces:
    - name: br0 
      description: |-
        A dedicated OVS bridge with enp2s0 as a port
        allowing all VLANs and untagged traffic
      type: ovs-bridge
      state: absent      # Change this from “up” to “absent”
      bridge:
        options:
          stp: true
        port:
        - name: enp2s0
    ovn:
      bridge-mappings:
      - localnet: br0-network
        bridge: br0 
        state: absent  # Changed from present

업데이트된 NNCP를 다시 적용합니다. NNCP에서 성공적으로 처리한 후에는 삭제할 수 있습니다.

$ oc apply -f br0-worker-ovs-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br0-ovs created

옵션 #3: 전용 NIC에서 Linux 브리지로 외부 네트워크 사용

Linux 네트워킹에서 OVS 브리지와 Linux 브리지는 모두 동일한 용도로 사용됩니다. 둘 중 하나를 사용하는 것은 결국 환경의 요구 사항에 따라 결정됩니다. 두 브리지 유형의 장단점을 설명하는 문서가 인터넷에 많이 있습니다. 즉, Linux 브리지는 OVS 브리지보다 완성도가 높고 단순하지만 기능이 풍부하지 않습니다. OVS 브리지는 Linux 브리지보다 더 많은 터널 유형과 기타 현대적인 기능을 제공한다는 장점이 있지만 문제를 해결하기가 조금 더 어렵습니다. OpenShift Virtualization의 경우 MultiNetworkPolicy와 같은 이유로 Linux 브리지를 통해 OVS 브리지를 사용하도록 기본 설정해야 하지만, 두 옵션 중 하나를 사용하여 배포할 수 있습니다.

가상 시스템 인터페이스가 OVS 브리지에 연결된 경우 기본 MTU는 1400입니다. 가상 시스템 인터페이스가 Linux 브리지에 연결된 경우 기본 MTU는 1500입니다. 클러스터 MTU 크기에 대한 자세한 내용은 공식 설명서에서 확인할 수 있습니다.

노드 구성

이전 예제와 마찬가지로 전용 NIC를 사용하여 새 Linux 브리지를 생성합니다. 계속해서, DHCP 서버가 없는 네트워크에 Linux 브리지를 연결합니다. 그러면 해당 네트워크에 연결된 가상 시스템에 어떤 영향을 주는지 확인할 수 있습니다.

이 예제에서는 인터넷 액세스 또는 DHCP 서버가 없는 172.16.0.0/24 네트워크에 연결된enp8s0] 인터페이스에서br1 라는 Linux 브리지를 생성합니다. NNCP는 다음과 같이 표시됩니다.

$ cat br1-worker-linux-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-linux-bridge
spec:
  nodeSelector: 
    node-role.kubernetes.io/worker: ""
  desiredState:
    interfaces:
      - name: br1 
        description: Linux bridge with enp8s0 as a port 
        type: linux-bridge 
        state: up 
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: enp8s0
$ oc apply -f br1-worker-linux-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br1-worker created

이전과 마찬가지로 NNCP 및 NNCE는 성공적으로 생성하고 적용하는 데 몇 초가 걸립니다.

NetworkAttachmentDefinition 구성

Linux 브리지에 대한NetworkAttachmentDefinition을 생성하는 프로세스는 이번에는 OVN localnet에 연결하지 않기 때문에 이전 예제와 약간 다릅니다. Linux 브리지 연결의 경우 새 브리지에 직접 연결합니다. 다음은 NetworkAttachmenDefinition 생성 양식입니다.

이 경우 CNV Linux 브리지의 Network Type(네트워크 유형)을 선택하고 실제 브리지 이름을 Bridge name(브리지 이름) 필드에 입력합니다. 이 예제에서는 br1 입니다.

가상 시스템 NIC 구성

이제 다른 가상 시스템을 생성하되, NIC 네트워크에 대해 vmtest/br1-network 라는 새로운NetworkAttachmentDefinition을 사용합니다. 그러면 NIC가 새 Linux 브리지에 연결됩니다.

가상 시스템이 부팅되면 NIC는 노드에서 br1 브리지를 사용합니다. 이 예제에서 전용 NIC는 DHCP 서버와 인터넷 액세스가 없는 네트워크에 있으므로 nmcli를 사용하여 NIC에 수동 IP 주소를 제공하고 로컬 네트워크에서만 연결을 확인합니다.

NetworkAttachmentDefinition 및 Linux 브리지 삭제

이전 예제와 마찬가지로 NetworkAttachmentDefinition 및 Linux 브리지를 삭제하려면 먼저 NetworkAttachmentDefinition를 사용하는 가상 시스템이 없는지 확인합니다. Console 또는 명령줄에서 삭제합니다.

$ oc delete network-attachment-definition/br1-network -n vmtest
networkattachmentdefinition.k8s.cni.cncf.io "br1-network" deleted

그런 다음NodeNetworkConfigurationPolicy:를 삭제합니다.

$ oc delete nncp/br1-linux-bridge
nodenetworkconfigurationpolicy.nmstate.io "br1-linux-bridge" deleted

NNCP를 삭제하면 연결된 모든 NNCE도 삭제됩니다(정책을 삭제해도 OpenShift 노드의 변경 사항이 취소되지 않음).

$ oc get nnce
No resources found

마지막으로 인터페이스 상태를 up에서 absent:

로 변경하여 NNCP YAML 파일을 수정합니다.

$ cat br1-worker-linux-bridge.yaml
apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: br1-linux-bridge
spec:
  nodeSelector: 
    node-role.kubernetes.io/worker: ""
  desiredState:
    interfaces:
      - name: br1 
        description: Linux bridge with enp8s0 as a port 
        type: linux-bridge 
        state: absent  # Changed from up
        bridge:
          options:
            stp:
              enabled: false
          port:
            - name: enp8s0

업데이트된 NNCP를 다시 적용합니다. NNCP에서 성공적으로 처리한 후에는 삭제할 수 있습니다.

$ oc apply -f br1-worker-linux-bridge.yaml
nodenetworkconfigurationpolicy.nmstate.io/br1-worker created

OpenShift Virtualization의 고급 네트워킹

많은 OpenShift Virtualization 사용자는 Red Hat OpenShift에 이미 내장된 다양한 고급 네트워킹 기능의 이점을 누릴 수 있습니다. 그러나 더 많은 워크로드가 기존 하이퍼바이저에서 마이그레이션됨에 따라 기존 인프라를 활용하고자 할 수 있습니다. 따라서 OpenShift Virtualization 워크로드를 외부 네트워크에 직접 연결해야 할 수 있습니다. NMState 오퍼레이터와 Multus 네트워킹은 기존 하이퍼바이저에서 Red Hat OpenShift Virtualization으로 쉽게 전환할 수 있도록 성능과 연결성을 확보할 수 있는 유연한 방법을 제공합니다.

OpenShift Virtualization에 대해 자세히 알아보려면 주제에 대한 내 블로그의 다른 블로그 포스트를 확인하거나 Red Hat 웹사이트에서 제품을 참조하세요. 이 문서에서 다루는 네트워킹 주제에 대한 자세한 내용은 Red Hat OpenShift 설명서에서 필요한 모든 세부 정보를 확인할 수 있습니다. 마지막으로, 데모를 보거나 OpenShift Virtualization을 직접 사용하려면 어카운트 담당자에게 문의하세요.