Red Hat Blog를 보다가 관심 가는 글이 보여서 AI번역+약간 교정해 보았습니다.
출처: https://www.redhat.com/en/blog/user-defined-networks-red-hat-openshift-virtualization
Red Hat OpenShift 4.18 릴리스에서 가장 기대되는 기능 중 하나는 OpenShift Virtualization에서 개별 사용자 정의 네트워크를 사용할 수 있는 기능입니다. 이 기능이 도입되기 전에는 네트워킹을 위한 유일한 옵션은 공유 OpenShift Pod 네트워크, 네임스페이스 내의 라우팅 불가능한 레이어 2 네트워크 연결 정의, 또는 외부 네트워크를 사용하도록 가상 머신을 구성하는 것이 었습니다 .
사용자 정의 네트워크를 사용하면 이제 자체 네임스페이스 내에서 또는 다른 네트워크와 분리된 여러 네임스페이스에 걸쳐 프라이빗 네트워크를 생성할 수 있습니다. 이 기능을 통해 조직의 요구에 가장 적합한 방식으로 가상 머신(VM)을 연결할 수 있는 유연성을 확보할 수 있습니다.
OpenShift Virtualization을 위한 사용자 정의 네트워크 생성 및 관리에 대한 자세한 내용은 공식 문서 에서 확인할 수 있습니다. 이 글에서는 사용자 환경에서 사용할 수 있는 구체적인 작업 예시를 제공합니다.
사용자 정의 네트워크 유형
사용자 정의 네트워크 custom resources (CR)에는 두 가지 유형이 있으며, 이에 대해서는 아래에서 설명합니다.
UserDefinedNetwork
UserDefinedNetwork(UDN)는 동일한 네임스페이스 내 테넌트 간의 네트워크 격리를 제공하는 CR입니다. 즉, UserDefinedNetwork를 생성하면 VM 간 통신에 사용되는 임의의 서브넷을 가진 네트워크가 생성됩니다. 이 네트워크 네임스페이스는 다른 네트워크와 분리되며 해당 네임스페이스에 지정된 VM에서만 사용할 수 있습니다.
위 다이어그램에서 볼 수 있듯이 네임스페이스당 하나의 UserDefinedNetwork를 가질 수 있으며, 해당 네임스페이스의 VM만 해당 UDN에서 통신할 수 있습니다. udn-1 UDN의 VM은 다른 UDN의 VM과 통신할 수 없습니다. 이를 통해 네트워크 테넌트와 네임스페이스가 완전히 분리됩니다.
UserDefinedNetwork를 생성하는 단계는 다음과 같습니다.
UserDefinedNetwork에 대한 네임스페이스 생성
네임스페이스에 UserDefinedNetwork를 생성하면 Pod 네트워크가 사용자가 생성한 UDN으로 사실상 대체됩니다. 따라서 UDN이 생성되면 VM이 Pod 네트워크에 액세스할 수 없습니다.
시작하려면 UDN을 만들려는 네임스페이스에 다음 레이블을 적용해야 합니다.
k8s.ovn.org/primary-user-defined-network=""
이 레이블이 없으면 UDN이 생성되지 않습니다. 또한, 네임스페이스가 생성될 때 레이블을 적용해야 합니다. 네임스페이스를 먼저 생성한 후 레이블을 적용할 수는 없습니다. 네임스페이스가 생성된 후에 레이블을 적용하려고 하면 오류 메시지가 표시되고 명령이 실패합니다.
$ oc label namespace/vmtest k8s.ovn.org/primary-user-defined-network="" The namespaces "vmtest" is invalid: : ValidatingAdmissionPolicy 'user-defined-networks-namespace-label' with binding 'user-defined-networks-namespace-label-binding' denied request: The 'k8s.ovn.org/primary-user-defined-network' label cannot be added/removed after the namespace was created
레이블이 있는 네임스페이스를 만들려면 YAML 파일과 함께 OpenShift 명령줄을 사용하세요. 이 예시에서 네임스페이스는 udn-dev 입니다.
$ cat udn-dev-ns.yaml
apiVersion: v1
kind: Namespace
metadata:
name: udn-dev
labels:
k8s.ovn.org/primary-user-defined-network: ""
$ oc create -f udn-dev-ns.yaml
namespace/udn-dev createdUserDefinedNetwork 생성
이제 네임스페이스가 제대로 생성되었으므로 YAML 파일을 사용하여 UserDefinedNetwork를 생성할 수 있습니다.
$ cat udn-dev.yaml
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
name: udn-dev
namespace: udn-dev
spec:
layer2:
ipam:
lifecycle: Persistent
role: Primary
subnets:
- 10.200.0.0/16
topology: Layer2위 예제 파일에서 udn-dev라는 이름과 10.200.0.0/16이라는 서브넷을 가진 2계층 UDN을 정의했습니다. UDN에는 원하는 고유한 이름을 사용할 수 있으며, 서브넷 구성도 자유롭게 변경할 수 있습니다. UDN은 서로 분리되어 있으므로 네임스페이스 간 CIDR 중복에 대한 우려가 없습니다. 즉, 한 네임스페이스에는 CIDR이 10.200.0.0/16이고 다른 네임스페이스에는 10.200.10.0/24인 UDN을 사용하는 것은 두 네임스페이스가 서로 통신하지 않으므로 유효한 구성입니다.
위 예에서 IPAM(IP 주소 관리)은 영구적으로 설정되어 있습니다. 이렇게 하면 재부팅 후에도 VM의 IP 주소가 동일하게 유지됩니다.
UDN의 이름을 지정하고 기본 설정에 따라 서브넷 CIDR을 설정한 후 YAML 파일에서 UDN을 만들 수 있습니다.
$ oc create -f udn-dev.yaml userdefinednetwork.k8s.ovn.org/udn-dev created The UDN creation completes very quickly and you are able to examine the resulting CR: $ oc get userdefinednetwork -n udn-dev NAME AGE udn-dev 30s
UDN이 생성된 후 세부 정보를 보고 생성 중에 오류가 없었는지 확인하고 상태를 검증합니다.
$ oc get userdefinednetwork/udn-dev -o yaml -n udn-dev
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
creationTimestamp: "2025-02-26T21:55:54Z"
finalizers:
- k8s.ovn.org/user-defined-network-protection
generation: 1
name: udn-dev
namespace: udn-dev
resourceVersion: "1162536"
uid: 035f9159-d02e-44ed-b61f-14d73d2558f7
spec:
layer2:
ipam:
lifecycle: Persistent
role: Primary
subnets:
- 10.200.0.0/16
topology: Layer2
status:
conditions:
- lastTransitionTime: "2025-02-26T21:55:55Z"
message: NetworkAttachmentDefinition has been created
reason: NetworkAttachmentDefinitionCreated
status: "True"
type: NetworkCreated
- lastTransitionTime: "2025-02-26T21:55:55Z"
message: Network allocation succeeded for all synced nodes.
reason: NetworkAllocationSucceeded
status: "True"
type: NetworkAllocationSucceeded위 출력에서 status: 부분에는 UDN 상태에 대한 중요한 정보가 포함되어 있으므로 특히 주의 깊게 살펴보세요. 우리가 보고 싶은 첫 번째 메시지는 다음을 나타내는 마지막 메시지입니다.
message: Network allocation succeeded for all synced nodes.
이는 UDN이 성공적으로 생성되었음을 알려줍니다. 다른 메시지는 이 UDN에 대한 NetworkAttachmentDefinition도 성공적으로 생성되었음을 알려줍니다.
message: NetworkAttachmentDefinition has been created
NetworkAttachmentDefinition은 이 네임스페이스에서 생성된 모든 VM에서 자동으로 사용됩니다. NetworkAttachmentDefinition과 직접 상호 작용할 필요는 없지만, 해당 정의의 존재 여부와 이름을 확인하는 것이 좋습니다.
$ oc get network-attachment-definitions -n udn-dev NAME AGE udn-dev 107s
UserDefinedNetwork에 가상 머신을 만듭니다.
이제 네임스페이스와 UserDefinedNetwork가 생성되었으니 가상 머신을 생성할 준비가 되었습니다. 가상 머신을 생성하는 자세한 단계는 이 글에서 다루지 않지만, 다른 블로그 게시물에서 가상 머신 생성 방법을 확인할 수 있습니다 . 이 글에서는 사용자 지정 없이 간단한 가상 머신을 생성하는 방법을 보여드리겠습니다.
이 가상 머신이 생성된 네임스페이스에 k8s.ovn.org/primary-user-defined-network: "" 레이블이 있으므로, VM은 앞서 생성한 UDN을 사용하도록 자동으로 구성됩니다.
사용자 환경에서 가상 머신을 자유롭게 사용자 지정할 수 있지만, 네트워크 구성은 수정하지 않는 것이 중요합니다. 네임스페이스가 사용자 정의 네트워크를 사용하도록 이미 구성되어 있으므로 가상 머신 네트워크도 적절하게 구성되어 있으며, 네트워크 구성을 수정하면 가상 머신이 UDN에 연결되지 않을 수 있습니다.
가상 머신이 부팅되면 로그인하여 네트워크 인터페이스가 UserDefinedNetwork 구성에 지정된 CIDR의 DHCP에서 IP 주소를 수신하고 라우터와 외부 네트워크 액세스를 받았음을 확인할 수 있습니다. 사용자 정의 네트워크를 사용하는 경우 가상 머신의 NIC에서 DHCP 클라이언트를 활성화하는 것이 중요합니다. 적절한 네트워크에 있더라도 다른 IP 주소를 수동으로 설정하려고 하면 네트워크 트래픽이 허용되지 않습니다. DHCP를 통해 제공되는 IP 주소를 직접 코딩할 수는 있지만, DHCP 임대가 만료되어 다른 IP로 갱신되면 네트워크 연결이 중단될 수 있으므로 권장하지 않습니다.
네트워크 인터페이스는 UDN의 DHCP 서버로부터 10.200.0.3의 IP 주소를 수신했습니다.
[rhel@rhel9-udndev-01 ~]$ ip address show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1342 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:58:0a:c8:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.200.0.3/16 brd 10.200.255.255 scope global dynamic noprefixroute eth0
valid_lft 3039sec preferred_lft 3039secUDN이 2계층 네트워크임에도 불구하고 네트워크에서 소프트웨어 정의 라우터를 사용할 수 있습니다.
[rhel@rhel9-udndev-01 ~]$ ip route default via 10.200.0.1 dev eth0 proto dhcp src 10.200.0.3 metric 100 10.200.0.0/16 dev eth0 proto kernel scope link src 10.200.0.3 metric 100
결과적으로 VM은 외부 리소스와 통신할 수 있습니다.
[rhel@rhel9-udndev-01 ~]$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=7.06 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=6.02 ms
이 네임스페이스에서 생성된 모든 가상 머신은 UDN에 NIC를 갖게 되며 네임스페이스의 다른 VM과 통신할 수 있습니다.
클러스터 사용자 정의 네트워크
ClusterUserDefinedNetwork는 UserDefinedNetwork와 유사하지만 여러 네임스페이스에서 사용할 수 있다는 점이 다릅니다. 즉, ClusterUserDefinedNetwork(클러스터 UDN)를 사용하면 서로 다른 네임스페이스에 있는 VM이 클러스터 UDN을 통해 서로 통신할 수 있습니다. ClusterUserDefinedNetwork를 사용하는 모든 VM은 네임스페이스와 관계없이 동일한 클러스터 UDN을 사용하지 않는 한 다른 VM과 분리됩니다. ClusterUserDefinedNetwork는 클러스터 관리자만 생성할 수 있습니다.
위의 다이어그램에서 볼 수 있듯이 클러스터 UDN은 두 개 이상의 네임스페이스에 걸쳐 있을 수 있으므로 서로 다른 네임스페이스에 있는 VM이 동일한 클러스터 UDN에 연결되지 않은 다른 VM과 네트워크 격리를 유지하면서 서로 통신할 수 있습니다.
ClusterUserDefinedNetwork에 대한 네임스페이스를 만듭니다.
UserDefinedNetworks와 마찬가지로 적절한 레이블을 사용하여 네임스페이스를 생성해야 하며, 해당 레이블은 기존 네임스페이스에 적용되지 않을 수 있습니다. 따라서 OpenShift 명령줄 인터페이스와 YAML 파일을 사용하여 올바른 레이블을 사용하여 네임스페이스를 생성하는 것이 가장 쉬운 방법일까요? 이 예시에서는 두 개의 네임스페이스를 생성한 다음 VM이 두 네임스페이스 간 통신을 수행할 수 있도록 클러스터 UDN을 생성합니다.
먼저 udn-prod 네임스페이스를 만듭니다.
$ cat udn-prod.yaml
apiVersion: v1
kind: Namespace
metadata:
name: udn-prod
labels:
k8s.ovn.org/primary-user-defined-network: “”
$ oc create -f udn-prod.yaml
namespace/udn-prod created그런 다음 이름을 제외하고는 동일한 udn-pre-prod 네임스페이스를 만듭니다.
$ cat udn-pre-prod.yaml
apiVersion: v1
kind: Namespace
metadata:
name: udn-pre-prod
labels:
k8s.ovn.org/primary-user-defined-network: “”
$ oc create -f udn-pre-prod.yaml
namespace/udn-pre-prod createdClusterUserDefinedNetwork를 생성하기 전에 새 네임스페이스에 몇 가지 추가 레이블을 적용합니다. 반드시 필요한 것은 아니지만, 나중에 클러스터 UDN을 정의할 때 네임스페이스를 선택하는 데 도움이 됩니다. 이 예에서 클러스터 UDN은 프로덕션 서버용이므로, 네임스페이스에 적절한 설명 레이블을 지정합니다. 레이블은 임의적이며, 나중에 클러스터 UDN 정의의 NamespaceSelector와 일치하기만 하면 됩니다. 프로덕션 네임스페이스를 식별하기 위해 cluster-udn=prod 레이블을 사용합니다.
$ oc label namespace/udn-prod cluster-udn=prod namespace/udn-prod labeled $ oc label namespace/udn-pre-prod cluster-udn=prod namespace/udn-pre-prod labeled
UserDefinedNetwork 생성
이제 네임스페이스가 생성되고 올바르게 레이블이 지정되었으므로 YAML 파일을 사용하여 ClusterUserDefinedNetwork를 생성할 수 있습니다.
$ cat cluster-udn-prod.yaml
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
name: cluster-udn-prod
spec:
namespaceSelector:
matchLabels:
cluster-udn: prod
network:
layer2:
ipam:
lifecycle: Persistent
role: Primary
subnets:
- 10.100.0.0/16
topology: Layer2위 예제 파일에서는 cluster-udn-prod 이름과 서브넷 10.100.0.0/16을 갖는 2계층 클러스터 UDN을 정의했습니다. 클러스터 UDN에는 원하는 이름을 사용할 수 있으며, 서브넷 구성도 자유롭게 변경할 수 있습니다. 중요한 점은, 앞서 네임스페이스에 부여한 레이블을 포함하는 namespaceSelector도 포함시켰다는 것입니다. 이를 통해 클러스터 UDN이 생성된 후 적절한 네임스페이스에서 사용할 수 있게 됩니다.
위 예에서 IPAM(IP Address Management)은 영구적으로 설정되어 있습니다. 이렇게 하면 재부팅 후에도 VM의 IP 주소가 동일하게 유지됩니다.
클러스터 UDN의 이름을 지정하고 서브넷 CIDR을 설정하면 YAML 파일에서 클러스터 UDN을 만들 수 있습니다.
$ oc create -f cluster-udn-prod.yaml clusteruserdefinednetwork.k8s.ovn.org/cluster-udn-prod created
클러스터 UDN이 생성된 후에는 생성 중에 오류가 없었는지 확인하고 상태를 검증하기 위해 세부 정보를 볼 수 있습니다.
$ oc get clusteruserdefinednetwork/cluster-udn-prod -o yaml
apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
creationTimestamp: "2025-02-26T21:36:35Z"
finalizers:
- k8s.ovn.org/user-defined-network-protection
generation: 1
name: cluster-udn-prod
resourceVersion: "1149053"
uid: 3dfdb159-889d-4ac4-ae0b-44b65fe881f4
spec:
namespaceSelector:
matchLabels:
cluster-udn: prod
network:
layer2:
ipam:
lifecycle: Persistent
role: Primary
subnets:
- 10.100.0.0/16
topology: Layer2
status:
conditions:
- lastTransitionTime: "2025-02-26T21:36:35Z"
message: 'NetworkAttachmentDefinition has been created in following namespaces:
[udn-pre-prod, udn-prod]'
reason: NetworkAttachmentDefinitionCreated
status: "True"
type: NetworkCreated위 출력에서 가장 중요한 부분은 status: 섹션의 텍스트입니다. type: 필드는 NetworkCreated를 나타내며, message: 필드는 udn-pre-prod 및 udn-prod로 명명된 두 네임스페이스 각각에 NetworkAttachmentDefinition이 생성되었음을 나타냅니다.
NetworkAttachmentDefinitions는 선택한 네임스페이스에 생성된 모든 VM에서 자동으로 사용됩니다. NetworkAttachmentDefinitions와 직접 상호 작용할 필요는 없지만, 존재 여부와 이름을 확인하는 것이 좋습니다.
$ oc get network-attachment-definitions -A NAMESPACE NAME AGE udn-pre-prod cluster-udn-prod 22h udn-prod cluster-udn-prod 22h
클러스터 UDN이 생성된 각 네임스페이스에 대해 하나의 NetworkAttachmentDefinition이 생성되었습니다. 각 네임스페이스의 새 VM은 기본 네트워크 인터페이스에 이 NetworkAttachmentDefinition을 사용합니다.
클러스터 UDN이 생성되면 위와 동일한 절차에 따라 사용자 정의 네트워크 활성화에 적합한 레이블을 가진 네임스페이스를 생성하고 cluster-udn: prod 레이블을 추가하여 새 네임스페이스를 추가할 수 있습니다. 적절한 레이블이 지정되면 새 네임스페이스에 클러스터 UDN이 자동으로 확장됩니다.
ClusterUserDefinedNetwork에 가상 머신을 만듭니다.
네임스페이스와 ClusterUserDefinedNetwork가 생성되었으니 이제 가상 머신을 생성할 준비가 되었습니다. 가상 머신을 생성하는 자세한 단계는 이 문서의 범위를 벗어나지만, 다른 블로그 게시물에서 가상 머신 생성 방법을 확인할 수 있습니다. 이 문서에서는 사용자 지정 없이 udn-prod 네임스페이스에 간단한 가상 머신을 생성하는 방법을 보여드립니다.
이 가상 머신이 생성된 네임스페이스에 k8s.ovn.org/primary-user-defined-network: "" 레이블이 있으므로, VM은 앞서 생성한 클러스터 UDN을 사용하도록 자동으로 구성됩니다.
사용자 환경에서 가상 머신을 자유롭게 사용자 지정할 수 있지만, 네트워크 구성은 수정하지 않는 것이 중요합니다. 네임스페이스가 사용자 정의 네트워크를 사용하도록 이미 구성되어 있으므로 가상 머신 네트워크도 적절하게 구성되어 있으며, 수정 시 가상 머신이 UDN에 연결되지 않을 수 있습니다.
가상 머신이 부팅된 후 로그인하면 네트워크 인터페이스에 UserDefinedNetwork 구성에 지정된 CIDR의 IP 주소와 라우터, 그리고 외부 네트워크 액세스 권한이 있는 것을 확인할 수 있습니다. 사용자 정의 네트워크를 사용하는 경우 가상 머신의 NIC에서 DHCP 클라이언트를 활성화하는 것이 중요합니다. 적절한 네트워크에 있더라도 다른 IP 주소를 수동으로 설정하려고 하면 네트워크 트래픽이 허용되지 않습니다. DHCP를 통해 제공되는 IP 주소를 직접 코딩할 수는 있지만, DHCP 임대가 만료되어 다른 IP로 갱신될 경우 네트워크 연결이 중단될 수 있으므로 권장하지 않습니다.
네트워크 인터페이스는 클러스터 UDN의 DHCP 서버로부터 10.100.0.3의 IP 주소를 수신했습니다.
[rhel@rhel9-udnprod-01 ~]$ ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1342 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:58:0a:64:00:03 brd ff:ff:ff:ff:ff:ff
inet 10.100.0.3/16 brd 10.100.255.255 scope global dynamic noprefixroute eth0
valid_lft 1843sec preferred_lft 1843secUDN이 2계층 네트워크임에도 불구하고 네트워크에서 소프트웨어 정의 라우터를 사용할 수 있습니다.
[rhel@rhel9-udnprod-01 ~]$ ip route default via 10.100.0.1 dev eth0 proto dhcp src 10.100.0.3 metric 100 10.100.0.0/16 dev eth0 proto kernel scope link src 10.100.0.3 metric 100
결과적으로 VM은 외부 리소스와 통신할 수 있습니다.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=12.1 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=7.39 ms
클러스터 UDN은 Layer2 네트워크로 정의되었지만, VM이 외부 네트워크에 액세스할 수 있도록 라우터가 자동으로 생성됩니다.
위 가상 머신은 udn-prod 네임스페이스에서 생성되었습니다. udn-prod와 동일한 클러스터 UDN을 공유하는 udn-pre-prod 네임스페이스에 동일한 VM을 생성하면, 마찬가지로 구성되어 있으며 생성한 VM과 클러스터 UDN을 통해 통신할 수 있음을 확인할 수 있습니다.
새 VM의 네트워크 인터페이스는 클러스터 UDN의 DHCP 서버로부터 10.100.0.4의 IP 주소를 수신했습니다.
[rhel@rhel9-udnpreprod-01 ~]$ ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1342 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:58:0a:64:00:04 brd ff:ff:ff:ff:ff:ff
inet 10.100.0.4/16 brd 10.100.255.255 scope global dynamic noprefixroute eth0
valid_lft 2724sec preferred_lft 2724secudn-pre-prod 네임스페이스의 새 VM은 udn-prod 네임스페이스의 첫 번째 VM과 동일한 클러스터 UDN을 공유하므로 통신할 수 있습니다. 참고로, udn-pre-prod 네임스페이스에 있는 이 VM의 IP 주소는 10.100.0.4이며, 동일한 클러스터 UDN에 속하지만 udn-prod 네임스페이스에 있는 다른 VM의 IP 주소는 10.100.0.3입니다. 네임스페이스 간 통신이 성공적으로 이루어지고 있음을 확인할 수 있습니다.
[rhel@rhel9-udnpreprod-01 ~]$ ping 10.100.0.3 PING 10.100.0.3 (10.100.0.3) 56(84) bytes of data. 64 bytes from 10.100.0.3: icmp_seq=1 ttl=64 time=4.97 ms 64 bytes from 10.100.0.3: icmp_seq=2 ttl=64 time=2.90 ms
가상 머신 네트워크 정의를 검토하세요
위 단계에서는 OpenShift Virtualization에서 사용자 정의 네트워크를 배포하고 사용하는 방법을 살펴보았습니다. 아래 섹션에서는 위에서 생성한 VM의 네트워크 구성을 살펴보고 UDN을 사용할 때 VM 구성이 어떻게 달라지는지 살펴보겠습니다. UserDefinedNetworks를 사용하든 ClusterUserDefinedNetworks를 사용하든 VM의 네트워크 정의는 동일합니다.
VM의 .spec.template.spec.domain.devices 파일에는 클러스터 UDN에 대한 정의가 있습니다. 현재 가상 머신에 유효한 옵션은 l2bridge뿐입니다.
spec:
template:
spec:
domain:
devices:
interfaces:
- binding:
name: l2bridge
name: default또한 VM 정의 section .spec.template.spec.networks에는 동일한 인터페이스에 대한 참조가 있으며, 이 경우 이름은 default 입니다.
spec:
template:
spec:
networks:
- name: default
pod: {}네트워크 이름과 인터페이스 이름이 일치해야 합니다.
결론
가상 머신을 위한 사용자 정의 네트워킹은 OpenShift 4.18의 많은 기대를 모았던 새로운 기능으로, 많은 OpenShift Virtualization 사용자에게 더 큰 유연성을 제공합니다. Red Hat은 OpenShift 4.19와 4.20에서 사용자 정의 네트워크에 대한 더 많은 유연성과 사용 사례를 계획하고 있습니다.
사용자 정의 네트워크는 자체 네임스페이스 내부 또는 클러스터 UDN을 사용하는 여러 네임스페이스에 자체 테넌트 네트워크를 구축하려는 OpenShift Virtualization 사용자에게 큰 이점을 제공합니다. 클러스터 관리자는 클러스터나 네임스페이스가 아닌 테넌트별로 네트워크 트래픽을 관리할 수 있으며, 사용자는 자체 격리된 네트워크 공간을 통해 보안과 사용 편의성을 누릴 수 있습니다.
이 문서에서는 사용자 정의 네트워크를 구축하여 VM이 격리된 테넌트 네트워크에서 통신할 수 있도록 하는 방법을 알아보았습니다. OpenShift Virtualization의 기능에 대해 자세히 알아보려면 OpenShift Virtualization 랜딩 페이지 를 방문하여 Red Hat 제품이 귀사에 어떤 이점을 제공하는지 살펴보세요.
