2장. 기본 네트워크


2.1. 사용자 정의 네트워크 정보

사용자 정의 네트워크(UDN)를 구현하기 전에는 OpenShift Container Platform용 OVN-Kubernetes CNI 플러그인은 기본 네트워크에서 3계층 토폴로지만 지원했습니다. 쿠버네티스의 설계 원칙에 따라 모든 포드는 메인 네트워크에 연결되고, 모든 포드는 IP 주소를 통해 서로 통신하며, 포드 간 트래픽은 네트워크 정책에 따라 제한됩니다.

Kubernetes 디자인은 간단한 배포에는 유용하지만, 이 계층 3 토폴로지는 특히 최신 멀티 테넌트 배포의 경우 기본 네트워크 세그먼트 구성의 사용자 정의를 제한합니다.

UDN은 사용자 정의 레이어 2 및 레이어 3 네트워크 세그먼트를 활성화하여 Kubernetes Pod 네트워크의 기본 레이어 3 토폴로지의 유연성과 세분화 기능을 개선합니다. 이러한 모든 세그먼트는 기본적으로 격리됩니다. 이러한 세그먼트는 기본 OVN-Kubernetes CNI 플러그인을 사용하는 컨테이너 포드와 가상 머신의 기본 또는 보조 네트워크 역할을 합니다. UDN은 광범위한 네트워크 아키텍처와 토폴로지를 지원하여 네트워크의 유연성, 보안, 성능을 향상시킵니다.

클러스터 관리자는 ClusterUserDefinedNetwork 사용자 정의 리소스(CR)를 활용하여 클러스터 수준에서 여러 네임스페이스에 걸쳐 있는 기본 또는 보조 네트워크를 만들고 정의하기 위해 UDN을 사용할 수 있습니다. 또한, 클러스터 관리자나 클러스터 사용자는 UDN을 사용하여 UserDefinedNetwork CR을 통해 네임스페이스 수준에서 보조 네트워크를 정의할 수 있습니다.

다음 섹션에서는 사용자 정의 네트워크의 이점과 제한 사항, ClusterUserDefinedNetwork 또는 UserDefinedNetwork CR을 생성할 때의 모범 사례, CR을 생성하는 방법, 배포와 관련이 있을 수 있는 추가 구성 세부 정보를 더욱 강조합니다.

2.1.1. 사용자 정의 네트워크의 이점

사용자 정의 네트워크는 다음과 같은 이점을 제공합니다.

  1. 보안을 위한 향상된 네트워크 격리

    • 테넌트 격리 : 네임스페이스는 Red Hat OpenStack Platform(RHOSP)에서 테넌트가 격리되는 방식과 유사하게 자체 격리된 기본 네트워크를 가질 수 있습니다. 이를 통해 테넌트 간 트래픽 위험이 줄어들어 보안이 향상됩니다.
  2. 네트워크 유연성

    • 2계층 및 3계층 지원 : 클러스터 관리자는 기본 네트워크를 2계층 또는 3계층 네트워크 유형으로 구성할 수 있습니다.
  3. 간소화된 네트워크 관리

    • 네트워크 구성의 복잡성 감소 : 사용자 정의 네트워크를 사용하면 서로 다른 네트워크의 작업 부하를 그룹화하여 격리를 달성할 수 있으므로 복잡한 네트워크 정책이 필요 없습니다.
  4. 고급 기능

    • 일관되고 선택 가능한 IP 주소 지정 : 사용자는 다양한 네임스페이스와 클러스터에서 IP 서브넷을 지정하고 재사용하여 일관된 네트워킹 환경을 제공할 수 있습니다.
    • 다중 네트워크 지원 : 사용자 정의 네트워킹 기능을 통해 관리자는 여러 네임스페이스를 단일 네트워크에 연결하거나, 서로 다른 네임스페이스 집합에 대해 별도의 네트워크를 만들 수 있습니다.
  5. Red Hat OpenStack Platform(RHOSP)에서 애플리케이션 마이그레이션 간소화

    • 네트워크 패리티 : 사용자 정의 네트워킹을 사용하면 유사한 네트워크 격리 및 구성 옵션을 제공하여 OpenStack에서 OpenShift Container Platform으로 애플리케이션을 마이그레이션하는 과정이 간소화됩니다.

개발자와 관리자는 사용자 정의 리소스를 사용하여 네임스페이스 범위가 지정된 사용자 정의 네트워크를 만들 수 있습니다. 프로세스 개요는 다음과 같습니다.

  1. 관리자는 k8s.ovn.org/primary-user-defined-network 레이블이 있는 사용자 정의 네트워크에 대한 네임스페이스를 만듭니다.
  2. UserDefinedNetwork CR은 클러스터 관리자나 사용자가 생성합니다.
  3. 사용자는 네임스페이스에 포드를 생성합니다.

2.1.2. 사용자 정의 네트워크의 한계

사용자 정의 네트워크(UDN)는 높은 수준의 사용자 정의가 가능한 네트워크 구성 옵션을 제공하지만, 클러스터 관리자와 개발자는 이러한 네트워크를 구현하고 관리할 때 알아야 할 제한 사항이 있습니다. UDN을 구현하기 전에 다음과 같은 제한 사항을 고려하세요.

  • DNS 제한 사항 :

    • 포드에 대한 DNS 조회는 클러스터 기본 네트워크의 포드 IP 주소로 확인됩니다. 포드가 사용자 정의 네트워크의 일부인 경우에도 DNS 조회는 해당 사용자 정의 네트워크의 포드 IP 주소로 확인되지 않습니다. 그러나 서비스 및 외부 엔터티에 대한 DNS 조회는 예상대로 작동합니다.
    • 포드가 기본 UDN에 할당되면 클러스터의 기본 네트워크에서 Kubernetes API(KAPI) 및 DNS 서비스에 액세스할 수 있습니다.
  • 초기 네트워크 할당 : Pod를 생성하기 전에 네임스페이스와 네트워크를 생성해야 합니다. 포드가 있는 네임스페이스를 새로운 네트워크에 할당하거나 기존 네임스페이스에 UDN을 생성하는 것은 OVN-Kubernetes에서 허용되지 않습니다.
  • 상태 점검 제한 사항 : Kubelet 상태 점검은 클러스터 기본 네트워크에서 수행되므로 Pod의 기본 인터페이스의 네트워크 연결을 확인하지 않습니다. 따라서 기본 네트워크에서는 포드가 정상적으로 보이지만 기본 인터페이스에서는 연결이 끊어지는 시나리오가 사용자 정의 네트워크에서 발생할 수 있습니다.
  • 네트워크 정책 제한 : 서로 다른 사용자 정의 기본 네트워크에 연결된 네임스페이스 간 트래픽을 활성화하는 네트워크 정책은 효과적이지 않습니다. 이러한 트래픽 정책은 이러한 분리된 네트워크 간에 연결성이 없기 때문에 적용되지 않습니다.
  • 생성 및 수정 제한 : ClusterUserDefinedNetwork CR과 UserDefinedNetwork CR은 생성된 후에는 수정할 수 없습니다.
  • 기본 네트워크 서비스 액세스 : 사용자 정의 네트워크 포드는 기본 네트워크와 분리되어 있으므로 대부분의 기본 네트워크 서비스에 액세스할 수 없습니다. 예를 들어, 사용자 정의 네트워크 포드는 현재 OpenShift Container Platform 이미지 레지스트리에 액세스할 수 없습니다. 이러한 제한으로 인해 소스-이미지 빌드는 사용자 정의 네트워크 네임스페이스에서 작동하지 않습니다. 또한, Git 저장소의 소스 코드를 기반으로 애플리케이션을 생성하는 함수(예: oc new-app <command> )와 소스-이미지 빌드를 사용하는 OpenShift Container Platform 템플릿에서 애플리케이션을 생성하는 함수 등 다른 함수는 작동하지 않습니다. 이러한 제한은 다른 openshift-*.svc 서비스에도 영향을 미칠 수 있습니다.
  • 연결 제한 : 사용자 정의 네트워크의 NodePort 서비스는 격리가 보장되지 않습니다. 예를 들어, 동일 노드에 있는 포드에서 서비스로 가는 NodePort 트래픽은 액세스할 수 없지만, 다른 노드에 있는 포드에서 오는 트래픽은 성공합니다.
  • IP 주소 소진에 대한 불분명한 오류 메시지 : 사용자 정의 네트워크의 서브넷에서 사용 가능한 IP 주소가 부족하면 새로운 Pod가 시작되지 않습니다. 이 문제가 발생하면 다음 오류가 반환됩니다. 경고: pod sandbox를 만들지 못했습니다 . 이 오류 메시지는 IP 고갈이 원인임을 명확하게 설명하지 않습니다. 문제를 확인하려면 OpenShift Container Platform 웹 콘솔의 포드 네임스페이스에 있는 이벤트 페이지를 확인하면 됩니다. 이 페이지에는 서브넷 고갈에 대한 명시적 메시지가 보고되어 있습니다.

2.1.3. 2계층 및 3계층 토폴로지

플랫 레이어 2 토폴로지는 클러스터의 모든 노드에 분산된 가상 스위치를 생성합니다. 가상 머신과 포드는 이 가상 스위치에 연결되어 모든 구성 요소가 동일한 서브넷 내에서 서로 통신할 수 있습니다. 플랫 레이어 2 토폴로지는 클러스터에 있는 노드 간에 가상 머신을 라이브 마이그레이션하는 데 유용합니다. 다음 다이어그램은 라이브 마이그레이션을 위해 가상 스위치를 사용하는 두 개의 노드가 있는 플랫 레이어 2 토폴로지를 보여줍니다.

그림 2.1. 구성 요소 통신을 위해 가상 스위치를 사용하는 플랫 레이어 2 토폴로지

2계층 서브넷을 지정하지 않기로 결정한 경우 클러스터의 각 포드에 대한 IP 주소를 수동으로 구성해야 합니다. 2계층 서브넷을 지정하지 않으면 포트 보안은 MAC(Media Access Control) 스푸핑만 방지하는 데 국한되며 IP 스푸핑은 포함되지 않습니다. 2계층 토폴로지는 단일 브로드캐스트 도메인을 생성하는데, 이는 대규모 네트워크 환경에서 문제가 될 수 있으며, 토폴로지로 인해 네트워크 성능이 저하될 수 있는 브로드캐스트 스톰이 발생할 수 있습니다.

네트워크에 대해 구성 가능한 옵션을 더욱 확대하려면 계층 2 토폴로지를 사용자 정의 네트워크(UDN)와 통합할 수 있습니다. 다음 다이어그램은 각 노드에 존재하는 포드를 포함하는 2계층 토폴로지를 갖춘 UDN을 사용하는 두 개의 노드를 보여줍니다. 각 노드에는 두 개의 인터페이스가 포함됩니다.

  • 네트워크 구성요소를 노드에 연결하는 컴퓨팅 노드인 노드 인터페이스입니다.
  • br-ex 와 같은 OVS(Open vSwitch) 브리지는 Pod가 서로 통신하고 리소스를 공유할 수 있도록 2계층 OVN 스위치를 생성합니다.

외부 스위치는 두 인터페이스를 연결하고, 게이트웨이 또는 라우터는 외부 스위치와 2계층 OVN 스위치 간의 라우팅 트래픽을 처리합니다. 노드 내의 VM과 포드는 UDN을 사용하여 서로 통신할 수 있습니다. 2계층 OVN 스위치는 UDN을 통한 노드 트래픽을 처리하므로 VM을 한 노드에서 다른 노드로 라이브 마이그레이션할 수 있습니다.

그림 2.2. 2계층 토폴로지를 사용하는 사용자 정의 네트워크(UDN)

3계층 토폴로지는 클러스터의 각 노드에 대해 고유한 2계층 세그먼트를 생성합니다. 3계층 라우팅 메커니즘은 이러한 세그먼트를 상호 연결하여 서로 다른 노드에 호스팅된 가상 머신과 포드가 서로 통신할 수 있도록 합니다. 3계층 토폴로지는 각 도메인을 특정 노드에 할당하여 대규모 브로드캐스트 도메인을 효과적으로 관리할 수 있으므로 브로드캐스트 트래픽의 범위가 줄어듭니다. 3계층 토폴로지를 구성하려면 cidrhostSubnet 매개변수를 구성해야 합니다.

2.1.4. ClusterUserDefinedNetwork CR에 대하여

ClusterUserDefinedNetwork (UDN) 사용자 정의 리소스(CR)는 관리자에게만 클러스터 범위 네트워크 분할 및 격리를 제공합니다.

다음 다이어그램은 클러스터 관리자가 ClusterUserDefinedNetwork CR을 사용하여 테넌트 간에 네트워크 격리를 생성하는 방법을 보여줍니다. 이 네트워크 구성을 사용하면 네트워크가 여러 네임스페이스에 걸쳐 확장될 수 있습니다. 다이어그램에서 네트워크 격리는 두 개의 사용자 정의 네트워크인 udn-1udn-2 를 생성하여 달성됩니다. 이러한 네트워크는 연결되지 않았으며 spec.namespaceSelector.matchLabels 필드는 다른 네임스페이스를 선택하는 데 사용됩니다. 예를 들어, udn-1은 namespace-1namespace-2 에 대한 통신을 구성하고 격리하는 반면, udn-2는 namespace-3namespace-4 에 대한 통신을 구성하고 격리합니다. 격리된 테넌트(테넌트 1과 테넌트 2)는 네임스페이스를 분리하는 동시에 동일한 네임스페이스에 있는 포드가 통신할 수 있도록 허용하여 생성됩니다.

그림 2.3. ClusterUserDefinedNetwork CR을 사용한 테넌트 격리

2.1.4.1. ClusterUserDefinedNetwork CR에 대한 모범 사례

ClusterUserDefinedNetwork 사용자 정의 리소스(CR)를 설정하기 전에 사용자는 다음 정보를 고려해야 합니다.

  • ClusterUserDefinedNetwork CR은 클러스터 관리자가 사용하도록 의도되었으며 관리자가 아닌 사용자는 사용하면 안 됩니다. 잘못 사용하면 배포 시 보안 문제가 발생하거나 중단이 발생하거나 클러스터 네트워크가 끊어질 수 있습니다.
  • ClusterUserDefinedNetwork CR은 기본 네임스페이스를 선택해서는 안 됩니다. 이로 인해 격리가 이루어지지 않을 수 있으며, 결과적으로 클러스터에 보안 위험이 발생할 수 있습니다.
  • ClusterUserDefinedNetwork CR은 openshift-* 네임스페이스를 선택해서는 안 됩니다.
  • OpenShift Container Platform 관리자는 다음 조건 중 하나가 충족되면 클러스터의 모든 네임스페이스가 선택된다는 사실을 알고 있어야 합니다.

    • matchLabels 선택자는 비어 있습니다.
    • matchExpressions 선택자는 비어 있습니다.
    • namespaceSelector 는 초기화되었지만 matchExpressions 또는 matchLabel을 지정하지 않습니다. 예를 들어: namespaceSelector: {} .
  • 기본 네트워크의 경우 ClusterUserDefinedNetwork CR에 사용되는 네임스페이스에는 k8s.ovn.org/primary-user-defined-network 레이블이 포함되어야 합니다. 이 레이블은 업데이트할 수 없으며, 네임스페이스가 생성될 때만 추가할 수 있습니다. 다음 조건은 k8s.ovn.org/primary-user-defined-network 네임스페이스 레이블에 적용됩니다.

    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 포드가 생성되면, 포드는 기본 네트워크에 연결됩니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 네임스페이스와 일치하는 기본 ClusterUserDefinedNetwork CR이 생성되면 오류가 보고되고 네트워크가 생성되지 않습니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 기본 ClusterUserDefinedNetwork CR이 이미 존재하는 경우 네임스페이스에 포드가 생성되어 기본 네트워크에 연결됩니다.
    • 네임스페이스에 레이블이 있고 기본 ClusterUserDefinedNetwork CR이 없는 경우 ClusterUserDefinedNetwork CR이 생성될 때까지 네임스페이스에 포드가 생성되지 않습니다.
  • ClusterUserDefinedNetwork CR을 사용하여 로컬넷 토폴로지를 생성할 때 관리자를 위한 모범 사례는 다음과 같습니다.

    • CUDN CR을 생성할 때 spec.network.physicalNetworkName 매개변수가 Open vSwitch(OVS) 브리지 매핑에서 구성한 매개변수와 일치하는지 확인해야 합니다. 이렇게 하면 물리적 네트워크의 의도된 세그먼트에 브리징이 이루어집니다. 동일한 브리지 매핑을 사용하여 여러 CUDN CR을 배포하려는 경우 동일한 physicalNetworkName 매개변수를 사용해야 합니다.
    • 물리적 네트워크와 다른 네트워크 인터페이스 사이에 서브넷이 중복되지 않도록 하세요. 중복되는 네트워크 서브넷으로 인해 라우팅 충돌과 네트워크 불안정성이 발생할 수 있습니다. spec.network.localnet.subnets 매개변수를 사용할 때 충돌을 방지하려면 spec.network.localnet.excludeSubnets 매개변수를 사용할 수 있습니다.
    • VLAN(가상 LAN)을 구성할 때는 기본 물리적 인프라(스위치, 라우터 등)와 노드가 모두 VLAN ID(VID)를 허용하도록 올바르게 구성되어 있는지 확인해야 합니다. 즉, 예를 들어 eth1 과 같은 물리적 네트워크 인터페이스를 물리적 스위치를 통해 연결하는 VLAN(예: 20 )에 대한 액세스 포트로 구성한다는 의미입니다. 또한, 물리적 인터페이스가 OVN-Kubernetes에 올바르게 연결되었는지 확인하려면 노드에 OVS 브리지 매핑(예: eth1 )이 있는지 확인해야 합니다.

2.1.4.2. CLI를 사용하여 ClusterUserDefinedNetwork CR 만들기

다음 절차에서는 CLI를 사용하여 ClusterUserDefinedNetwork 사용자 정의 리소스(CR)를 만듭니다. 사용 사례에 따라 Layer2 토폴로지 유형의 경우 cluster-layer-two-udn.yaml 예제를 사용하거나 Layer3 토폴로지 유형의 경우 cluster-layer-three-udn.yaml 예제를 사용하여 요청을 만듭니다.

중요
  • ClusterUserDefinedNetwork CR은 클러스터 관리자가 사용하도록 의도되었으며 관리자가 아닌 사용자는 사용하면 안 됩니다. 잘못 사용하면 배포 시 보안 문제가 발생하거나 중단이 발생하거나 클러스터 네트워크가 끊어질 수 있습니다.
  • OpenShift Virtualization은 Layer2Localnet 토폴로지만 지원합니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 선택 사항: 기본 네트워크를 사용하는 ClusterUserDefinedNetwork CR의 경우 다음 명령을 입력하여 k8s.ovn.org/primary-user-defined-network 레이블이 있는 네임스페이스를 만듭니다.

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: <cudn_namespace_name>
      labels:
        k8s.ovn.org/primary-user-defined-network: ""
    EOF
    Copy to Clipboard Toggle word wrap
  2. Layer2 또는 Layer3 토폴로지 유형 클러스터 전체 사용자 정의 네트워크에 대한 요청을 만듭니다.

    1. 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의하려면 cluster-layer-two-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name> 
      1
      
      spec:
        namespaceSelector: 
      2
      
          matchLabels: 
      3
      
            "<label_1_key>": "<label_1_value>" 
      4
      
            "<label_2_key>": "<label_2_value>" 
      5
      
        network: 
      6
      
          topology: Layer2 
      7
      
          layer2: 
      8
      
            role: Primary 
      9
      
            subnets:
              - "2001:db8::/64"
              - "10.100.0.0/16" 
      10
      Copy to Clipboard Toggle word wrap
      1
      ClusterUserDefinedNetwork CR의 이름입니다.
      2
      클러스터 UDN CR이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default 또는 openshift-* 네임스페이스를 가리켜서는 안 됩니다.
      3
      AND 관계로 용어를 평가하는 matchLabels 선택기 유형을 사용합니다.
      4 5
      matchLabels 선택기 유형이 사용되므로 <label_1_key>=<label_1_value><label_2_key>=<label_2_value> 레이블을 모두 포함하는 네임스페이스가 제공됩니다.
      6
      네트워크 구성을 설명합니다.
      7
      토폴로지 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유되는 하나의 논리적 스위치가 생성됩니다.
      8
      이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 이 될 수 있습니다.
      9
      기본 또는 보조를 지정합니다. Primary는 4.19에서 지원되는 유일한 역할 사양입니다.
      10
      Layer2 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.
      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/162001:db8::/64입니다 .
      • Layer2 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "고정 IP 주소로 Pod 구성"을 참조하세요.
    2. 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의하려면 cluster-layer-three-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name> 
      1
      
      spec:
        namespaceSelector: 
      2
      
          matchExpressions: 
      3
      
          - key: kubernetes.io/metadata.name 
      4
      
            operator: In 
      5
      
            values: ["<example_namespace_one>", "<example_namespace_two>"] 
      6
      
        network: 
      7
      
          topology: Layer3 
      8
      
          layer3: 
      9
      
            role: Primary 
      10
      
            subnets: 
      11
      
              - cidr: 10.100.0.0/16
                hostSubnet: 24
      Copy to Clipboard Toggle word wrap
      1
      ClusterUserDefinedNetwork CR의 이름입니다.
      2
      클러스터 UDN이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default 또는 openshift-* 네임스페이스를 가리켜서는 안 됩니다.
      3
      OR 관계로 용어를 평가하는 matchExpressions 선택기 유형을 사용합니다.
      4
      일치시킬 레이블 키를 지정합니다.
      5
      연산자를 지정합니다. 유효한 값은 다음과 같습니다: In , NotIn , Exists , DoesNotExist .
      6
      matchExpressions 유형이 사용되므로 <example_namespace_one> 또는 <example_namespace_two> 와 일치하는 네임스페이스가 프로비저닝됩니다.
      7
      네트워크 구성을 설명합니다.
      8
      토폴로지 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 다른 서브넷을 갖는 Layer 2 세그먼트가 생성됩니다. 3계층 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.
      9
      이 필드는 토폴로지 구성을 지정합니다. 유효한 값은 layer2 또는 layer3 입니다.
      10
      기본 또는 보조 역할을 지정합니다. Primary는 4.19에서 지원되는 유일한 역할 사양입니다.
      11
      Layer3 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.
      • 서브넷 필드는 필수입니다.
      • 서브넷 필드의 유형은 cidrhostSubnet 입니다.

        • cidr 은 클러스터 서브넷이며 문자열 값을 허용합니다.
        • hostSubnet은 클러스터 서브넷이 분할되는 노드 서브넷 접두사를 지정합니다.
        • IPv6의 경우 hostSubnet 에 대해 /64 길이만 지원됩니다.
  3. 다음 명령을 실행하여 요청을 적용하세요.

    $ oc create --validate=true -f <example_cluster_udn>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <example_cluster_udn>.yaml은 Layer2 또는 Layer3 구성 파일의 이름입니다.

  4. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

    $ oc get clusteruserdefinednetwork <cudn_name> -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 <cudn_name> 은 클러스터 전체 사용자 정의 네트워크에 대해 생성한 이름입니다.

    출력 예

    apiVersion: k8s.ovn.org/v1
    kind: ClusterUserDefinedNetwork
    metadata:
      creationTimestamp: "2024-12-05T15:53:00Z"
      finalizers:
      - k8s.ovn.org/user-defined-network-protection
      generation: 1
      name: my-cudn
      resourceVersion: "47985"
      uid: 16ee0fcf-74d1-4826-a6b7-25c737c1a634
    spec:
      namespaceSelector:
        matchExpressions:
        - key: custom.network.selector
          operator: In
          values:
          - example-namespace-1
          - example-namespace-2
          - example-namespace-3
      network:
        layer3:
          role: Primary
          subnets:
          - cidr: 10.100.0.0/16
        topology: Layer3
    status:
      conditions:
      - lastTransitionTime: "2024-11-19T16:46:34Z"
        message: 'NetworkAttachmentDefinition has been created in following namespaces:
          [example-namespace-1, example-namespace-2, example-namespace-3]'
        reason: NetworkAttachmentDefinitionReady
        status: "True"
        type: NetworkCreated
    Copy to Clipboard Toggle word wrap

2.1.4.3. Localnet 토폴로지에 대한 ClusterUserDefinedNetwork CR 생성

로컬넷 토폴로지는 보조 네트워크를 물리적 언더레이에 연결합니다. 이를 통해 동서 클러스터 트래픽과 클러스터 외부에서 실행되는 서비스에 대한 액세스가 모두 가능해집니다. 이 토폴로지 유형에는 클러스터 노드에서 기본 Open vSwitch(OVS) 시스템의 추가 구성이 필요합니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 로그인했습니다.
  • OVS 브리지를 통해 논리적 OVN-Kubernetes 네트워크를 물리적 노드 네트워크와 연결하기 위해 Open vSwitch(OVS) 브리지 매핑을 만들고 구성했습니다. 자세한 내용은 "로컬넷 스위치 토폴로지 구성"을 참조하세요.

프로세스

  1. Localnet 토폴로지를 사용하여 클러스터 전체 사용자 정의 네트워크를 만듭니다.

    1. 다음 예와 같이 Localnet 토폴로지에 대한 요청을 정의하려면 cluster-udn-localnet.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: ClusterUserDefinedNetwork
      metadata:
        name: <cudn_name> 
      1
      
      spec:
        namespaceSelector: 
      2
      
          matchLabels: 
      3
      
            "<label_1_key>": "<label_1_value>" 
      4
      
            "<label_2_key>": "<label_2_value>" 
      5
      
        network: 
      6
      
          topology: Localnet 
      7
      
          localnet: 
      8
      
            role: Secondary 
      9
      
            physicalNetworkName: test
            ipam: {lifecycle: Persistent}
            subnets: ["192.168.0.0/16", "2001:dbb::/64"] 
      10
      Copy to Clipboard Toggle word wrap
      1
      ClusterUserDefinedNetwork (CUDN) CR의 이름입니다.
      2
      클러스터 CUDN CR이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes MatchLabel 선택기를 사용합니다. default , openshift-* 또는 다른 시스템 네임스페이스를 가리켜서는 안 됩니다.
      3
      AND 관계로 용어를 평가하는 matchLabels 선택기 유형을 사용합니다.
      4 5
      이 예에서 CUDN CR은 <label_1_key>=<label_1_value><label_2_key>=<label_2_value> 레이블을 모두 포함하는 네임스페이스에 배포됩니다.
      6
      네트워크 구성을 설명합니다.
      7
      Localnet 토폴로지 유형을 지정하면 하나의 공급자 네트워크에 직접 연결되는 하나의 논리적 스위치가 생성됩니다.
      8
      이 필드는 로컬넷 토폴로지를 지정합니다.
      9
      네트워크 구성에 대한 역할을 지정합니다. 보조 역할로컬넷 토폴로지에 지원되는 유일한 역할 사양입니다.
      10
      로컬넷 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.
      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 항목은 서로 다른 IP 패밀리에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/162001:db8::/64입니다 .
      • localnet 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "고정 IP 주소로 Pod 구성"을 참조하세요.
  2. 다음 명령을 실행하여 요청을 적용하세요.

    $ oc create --validate=true -f <example_cluster_udn>.yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <example_cluster_udn>.yaml
    Localnet 구성 파일의 이름입니다.
  3. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

    $ oc get clusteruserdefinednetwork <cudn_name> -o yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <cudn_name>
    클러스터 전체 사용자 정의 네트워크에 대해 생성한 이름입니다.

예 2.1. 출력 예

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  creationTimestamp: "2025-05-28T19:30:38Z"
  finalizers:
  - k8s.ovn.org/user-defined-network-protection
  generation: 1
  name: cudn-test
  resourceVersion: "140936"
  uid: 7ff185fa-d852-4196-858a-8903b58f6890
spec:
  namespaceSelector:
    matchLabels:
      "1": "1"
      "2": "2"
  network:
    localnet:
      ipam:
        lifecycle: Persistent
      physicalNetworkName: test
      role: Secondary
      subnets:
      - 192.168.0.0/16
      - 2001:dbb::/64
    topology: Localnet
status:
  conditions:
  - lastTransitionTime: "2025-05-28T19:30:38Z"
    message: 'NetworkAttachmentDefinition has been created in following namespaces:
      [test1, test2]'
    reason: NetworkAttachmentDefinitionCreated
    status: "True"
    type: NetworkCreated
Copy to Clipboard Toggle word wrap

2.1.4.4. 웹 콘솔을 사용하여 ClusterUserDefinedNetwork CR 만들기

OpenShift Container Platform 웹 콘솔에서 Layer2 토폴로지를 사용하여 ClusterUserDefinedNetwork 사용자 정의 리소스(CR)를 생성할 수 있습니다.

참고

현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3 토폴로지를 사용한 ClusterUserDefinedNetwork CR을 생성할 수 없습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • 네임스페이스를 생성하고 k8s.ovn.org/primary-user-defined-network 라벨을 적용했습니다.

프로세스

  1. 관리자 관점에서 네트워킹 사용자 정의 네트워크를 클릭합니다.
  2. ClusterUserDefinedNetwork를 클릭합니다.
  3. 이름 필드에서 클러스터 범위 UDN의 이름을 지정합니다.
  4. 서브넷 필드에 값을 지정합니다.
  5. 프로젝트 일치 레이블 필드에서 클러스터 UDN이 적용되는 네임스페이스를 선택하기 위해 적절한 레이블을 추가합니다.
  6. 생성을 클릭합니다. 클러스터 범위 UDN은 5단계에서 지정한 레이블이 포함된 네임스페이스에 있는 포드의 기본 기본 네트워크 역할을 합니다.

2.1.5. UserDefinedNetwork CR에 대하여

UDN( UserDefinedNetwork ) 사용자 정의 리소스(CR)는 사용자와 관리자에게 고급 네트워크 분할 및 격리 기능을 제공합니다.

다음 다이어그램은 4개의 클러스터 네임스페이스를 보여줍니다. 각 네임스페이스에는 하나의 사용자 정의 네트워크(UDN)가 할당되어 있고, 각 UDN에는 해당 Pod IP 할당을 위한 사용자 정의 서브넷이 할당되어 있습니다. OVN-Kubernetes는 중복되는 UDN 서브넷을 처리합니다. Kubernetes 네트워크 정책을 사용하지 않으면 UDN에 연결된 포드가 해당 UDN의 다른 포드와 통신할 수 있습니다. 기본적으로 이러한 포드는 다른 UDN에 있는 포드와의 통신이 차단됩니다. 마이크로세그먼테이션의 경우 UDN 내에서 네트워크 정책을 적용할 수 있습니다. 네임스페이스에 하나 이상의 UDN을 할당할 수 있지만, 네임스페이스에는 기본 UDN을 하나만 할당하고, UDN에는 하나 이상의 네임스페이스를 할당할 수 있습니다.

그림 2.4. UserDefinedNetwork CR을 사용한 네임스페이스 격리

2.1.5.1. UserDefinedNetwork CR에 대한 모범 사례

UserDefinedNetwork 사용자 정의 리소스(CR)를 설정하기 전에 다음 정보를 고려해야 합니다.

  • openshift-* 네임스페이스는 UserDefinedNetwork CR을 설정하는 데 사용해서는 안 됩니다.
  • UserDefinedNetwork CR은 기본 네임스페이스에 생성되어서는 안 됩니다. 이로 인해 격리가 이루어지지 않을 수 있으며, 결과적으로 클러스터에 보안 위험이 발생할 수 있습니다.
  • 기본 네트워크의 경우 UserDefinedNetwork CR에 사용되는 네임스페이스에는 k8s.ovn.org/primary-user-defined-network 레이블이 포함되어야 합니다. 이 레이블은 업데이트할 수 없으며, 네임스페이스가 생성될 때만 추가할 수 있습니다. 다음 조건은 k8s.ovn.org/primary-user-defined-network 네임스페이스 레이블에 적용됩니다.

    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 포드가 생성되면, 포드는 기본 네트워크에 연결됩니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 네임스페이스와 일치하는 기본 UserDefinedNetwork CR이 생성되면 상태 오류가 보고되고 네트워크가 생성되지 않습니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 기본 UserDefinedNetwork CR이 이미 존재하는 경우 네임스페이스에 포드가 생성되어 기본 네트워크에 연결됩니다.
    • 네임스페이스에 레이블이 있고 기본 UserDefinedNetwork CR이 없는 경우, UserDefinedNetwork CR이 생성될 때까지 네임스페이스에 포드가 생성되지 않습니다.
  • 사용자 정의 네트워크에는 2개의 가면 IP 주소가 필요합니다. 필요한 수의 네트워크를 수용할 만큼 충분히 크게 매스커레이드 서브넷을 재구성해야 합니다.

    중요
    • OpenShift Container Platform 4.17 이상에서는 클러스터가 IPv4의 경우 169.254.0.0/17을 , IPv6의 경우 fd69::/112를 기본 마스커레이드 서브넷으로 사용합니다. 사용자는 이러한 범위를 피해야 합니다. 업데이트된 클러스터의 경우 기본 마스커레이드 서브넷에는 변경 사항이 없습니다.
    • 프로젝트에 대해 사용자 정의 네트워크가 구성된 후에는 클러스터의 마스커레이드 서브넷을 변경하는 것이 지원되지 않습니다. UserDefinedNetwork CR이 설정된 후에 마스커레이드 서브넷을 수정하려고 하면 네트워크 연결이 중단되고 구성 문제가 발생할 수 있습니다.
  • 테넌트가 NetworkAttachmentDefinition (NAD) CR이 아닌 UserDefinedNetwork 리소스를 사용하고 있는지 확인하세요. 이로 인해 세입자 간에 보안 위험이 발생할 수 있습니다.
  • 네트워크 세분화를 생성할 때 UserDefinedNetwork CR을 사용하여 사용자 정의 네트워크 세분화를 완료할 수 없는 경우에만 NetworkAttachmentDefinition CR을 사용해야 합니다.
  • UserDefinedNetwork CR에 대한 클러스터 서브넷 및 서비스 CIDR은 기본 클러스터 서브넷 CIDR과 겹칠 수 없습니다. OVN-Kubernetes 네트워크 플러그인은 네트워크의 기본 조인 서브넷으로 100.64.0.0/16을 사용합니다. 해당 값을 사용하여 UserDefinedNetwork CR의 joinSubnets 필드를 구성해서는 안 됩니다. 클러스터의 네트워크 어디에서나 기본 주소 값이 사용되는 경우 joinSubnets 필드를 설정하여 기본값을 재정의해야 합니다. 자세한 내용은 "사용자 정의 네트워크에 대한 추가 구성 세부 정보"를 참조하세요.

2.1.5.2. CLI를 사용하여 UserDefinedNetwork CR 만들기

다음 절차에서는 네임스페이스 범위가 지정된 UserDefinedNetwork CR을 만듭니다. 사용 사례에 따라 Layer2 토폴로지 유형의 경우 my-layer-two-udn.yaml 예제를 사용하거나 Layer3 토폴로지 유형의 경우 my-layer-three-udn.yaml 예제를 사용하여 요청을 만듭니다.

특권

  • 클러스터 관리자 권한으로 로그인했거나 역할 기반 액세스 제어(RBAC)를 보고 편집할 수 있는 권한이 있습니다.

프로세스

  1. 선택 사항: 기본 네트워크를 사용하는 UserDefinedNetwork CR의 경우 다음 명령을 입력하여 k8s.ovn.org/primary-user-defined-network 레이블이 있는 네임스페이스를 만듭니다.

    $ cat << EOF | oc apply -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: <udn_namespace_name>
      labels:
        k8s.ovn.org/primary-user-defined-network: ""
    EOF
    Copy to Clipboard Toggle word wrap
  2. Layer2 또는 Layer3 토폴로지 유형 사용자 정의 네트워크에 대한 요청을 만듭니다.

    1. 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의하려면 my-layer-two-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-1 
      1
      
        namespace: <some_custom_namespace>
      spec:
        topology: Layer2 
      2
      
        layer2: 
      3
      
          role: Primary 
      4
      
          subnets:
            - "10.0.0.0/24"
            - "2001:db8::/60" 
      5
      Copy to Clipboard Toggle word wrap
      1
      UserDefinedNetwork 리소스의 이름입니다. 이는 기본값이어서 는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.
      2
      토폴로지 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유되는 하나의 논리적 스위치가 생성됩니다.
      3
      이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 이 될 수 있습니다.
      4
      기본 또는 보조 역할을 지정합니다.
      5
      Layer2 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.
      • 서브넷 필드는 선택 사항입니다.
      • 서브넷 필드는 문자열 유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • 서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은 10.100.0.0/162001:db8::/64입니다 .
      • Layer2 서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다.
      • ipamLifecycle 필드가 지정된 경우 Layer2 서브넷 필드는 필수입니다.
    2. 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의하려면 my-layer-three-udn.yaml 과 같은 YAML 파일을 만듭니다.

      apiVersion: k8s.ovn.org/v1
      kind: UserDefinedNetwork
      metadata:
        name: udn-2-primary 
      1
      
        namespace: <some_custom_namespace>
      spec:
        topology: Layer3 
      2
      
        layer3: 
      3
      
          role: Primary 
      4
      
          subnets: 
      5
      
            - cidr: 10.150.0.0/16
              hostSubnet: 24
            - cidr: 2001:db8::/60
              hostSubnet: 64
      # ...
      Copy to Clipboard Toggle word wrap
      1
      UserDefinedNetwork 리소스의 이름입니다. 이는 기본값이어서 는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.
      2
      토폴로지 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 다른 서브넷을 갖는 Layer 2 세그먼트가 생성됩니다. 3계층 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.
      3
      이 필드는 토폴로지 구성을 지정합니다. 유효한 값은 layer2 또는 layer3 입니다.
      4
      기본 또는 보조 역할을 지정합니다.
      5
      Layer3 토폴로지 유형의 경우 다음은 서브넷 필드에 대한 구성 세부 정보를 지정합니다.
      • 서브넷 필드는 필수입니다.
      • 서브넷 필드의 유형은 cidrhostSubnet 입니다.

        • cidr은 클러스터의 clusterNetwork 구성 설정과 동일합니다. CIDR의 IP 주소는 사용자 정의 네트워크의 포드에 배포됩니다. 이 매개변수는 문자열 값을 허용합니다.
        • hostSubnet은 노드별 서브넷 접두사를 정의합니다.
        • IPv6의 경우 hostSubnet 에 대해 /64 길이만 지원됩니다.
  3. 다음 명령을 실행하여 요청을 적용하세요.

    $ oc apply -f <my_layer_two_udn>.yaml
    Copy to Clipboard Toggle word wrap

    여기서 <my_layer_two_udn>.yaml은 Layer2 또는 Layer3 구성 파일의 이름입니다.

  4. 다음 명령을 실행하여 요청이 성공했는지 확인하세요.

    $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
    Copy to Clipboard Toggle word wrap

    여기서 some_custom_namespace 는 사용자 정의 네트워크에 대해 생성한 네임스페이스입니다.

    출력 예

    apiVersion: k8s.ovn.org/v1
    kind: UserDefinedNetwork
    metadata:
      creationTimestamp: "2024-08-28T17:18:47Z"
      finalizers:
      - k8s.ovn.org/user-defined-network-protection
      generation: 1
      name: udn-1
      namespace: some-custom-namespace
      resourceVersion: "53313"
      uid: f483626d-6846-48a1-b88e-6bbeb8bcde8c
    spec:
      layer2:
        role: Primary
        subnets:
        - 10.0.0.0/24
        - 2001:db8::/60
      topology: Layer2
    status:
      conditions:
      - lastTransitionTime: "2024-08-28T17:18:47Z"
        message: NetworkAttachmentDefinition has been created
        reason: NetworkAttachmentDefinitionReady
        status: "True"
        type: NetworkCreated
    Copy to Clipboard Toggle word wrap

2.1.5.3. 웹 콘솔을 사용하여 UserDefinedNetwork 만들기

OpenShift Container Platform 웹 콘솔을 사용하여 Layer2 토폴로지와 기본 역할을 갖춘 UserDefinedNetwork 사용자 지정 리소스(CR)를 만들 수 있습니다.

참고

현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3 토폴로지 또는 보조 역할이 있는 UserDefinedNetwork CR을 생성하는 것은 지원되지 않습니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 네임스페이스를 생성하고 k8s.ovn.org/primary-user-defined-network 라벨을 적용했습니다.

프로세스

  1. 관리자 관점에서 네트워킹 사용자 정의 네트워크를 클릭합니다.
  2. 사용자 정의 네트워크 만들기를 클릭합니다.
  3. 프로젝트 이름 목록에서 이전에 만든 네임스페이스를 선택합니다.
  4. 서브넷 필드에 값을 지정합니다.
  5. 생성을 클릭합니다. 사용자 정의 네트워크는 이 네임스페이스에서 생성하는 포드의 기본 기본 네트워크 역할을 합니다.

2.1.6. 사용자 정의 네트워크에 대한 추가 구성 세부 정보

다음 표에서는 선택 사항인 ClusterUserDefinedNetworkUserDefinedNetwork 사용자 정의 리소스(CR)에 대한 추가 구성을 설명합니다. OVN-Kubernetes 네트워크 토폴로지에 대한 명확한 필요성과 이해가 없이 이러한 필드를 설정하는 것은 권장되지 않습니다.

  1. 사용자 정의 네트워크에 대한 선택적 구성
Expand

CUDN 필드

UDN 필드

유형

설명

spec.network.<topology>.joinSubnets

spec.<topology>.joinSubnets

object

생략하면 플랫폼은 IPv4의 경우 joinSubnets 필드에 기본값을 100.65.0.0/16으로 설정하고 IPv6의 경우 fd99::/64로 설정합니다. 클러스터 네트워크의 어느 곳에서나 기본 주소 값을 사용하는 경우 joinSubnets 필드를 설정하여 해당 값을 재정의해야 합니다. 이 필드를 설정하기로 선택한 경우 클러스터 서브넷, 기본 네트워크 클러스터 서브넷, 마스커레이드 서브넷 등 클러스터의 다른 서브넷과 충돌하지 않는지 확인하세요.

joinSubnets 필드는 사용자 정의 네트워크 내의 서로 다른 세그먼트 간 라우팅을 구성합니다. 듀얼 스택 클러스터는 IP 패밀리마다 하나씩, 총 2개의 서브넷을 설정할 수 있습니다. 그렇지 않은 경우 서브넷은 1개만 허용됩니다. 이 필드는 기본 네트워크에만 허용됩니다.

spec.network.<topology>.excludeSubnets

spec.<topology>.exlcudeSubnets

string

서브넷 필드의 지정된 CIDR에서 제거할 CIDR 목록을 지정합니다. 이 목록에 있는 CIDR은 subnets 에 지정된 하나 이상의 서브넷 범위 내에 있어야 합니다. 생략하면 IP 주소가 제외되지 않으며, 서브넷 필드에 지정된 모든 IP 주소가 할당됩니다. 표준 CIDR 표기법을 사용해야 합니다. 예를 들어, 10.128.0.0/16 . subnets 필드가 설정되지 않았거나 ipam.mode 필드가 Disabled 로 설정된 경우 이 필드는 생략해야 합니다. excludeSubnets 필드에는 최대 25개의 값만 설정할 수 있습니다.

Localnet 토폴로지를 사용하여 보조 네트워크를 배포하는 경우 서브넷에서 IP 중복을 방지하기 위해 물리적 네트워크에서 사용되는 IP 범위를 excludeSubnets 필드에 명시적으로 나열해야 합니다.

spec.network.<topology>.ipam.lifecycle

spec.<topology>.ipam.lifecycle

object

spec.ipam.lifecycle 필드는 IP 주소 관리 시스템(IPAM)을 구성합니다. 가상 워크로드에 대해 이 필드를 사용하여 지속적인 IP 주소를 확보할 수 있습니다. 허용되는 유일한 값은 Persistent 이며, 이를 통해 가상 워크로드가 재부팅 및 마이그레이션 중에도 영구 IP 주소를 갖게 됩니다. 이러한 주소는 컨테이너 네트워크 인터페이스(CNI)에서 할당하고 OVN-Kubernetes에서 Pod IP 주소를 프로그래밍하는 데 사용됩니다. 포드 주석의 경우 이를 변경해서는 안 됩니다.

Persistent 값을 설정하는 것은 ipam.mode 매개변수가 Enabled 로 설정된 경우에만 지원됩니다.

spec.network.<topology>.ipam.mode

spec.<topology>`ipam.mode

object

모드 매개변수는 OVN-Kubernetes가 IP 구성을 얼마나 관리할지 제어합니다. 다음과 같은 옵션을 사용할 수 있습니다.

활성화됨:
이 기능을 활성화하면 OVN-Kubernetes는 SDN 인프라에 IP 구성을 적용하고 선택한 서브넷의 IP 주소를 개별 포드에 할당합니다. 이 설정은 기본 설정입니다. Enabled 로 설정된 경우 서브넷 필드를 정의해야 합니다. 기본 구성은 활성화되어 있습니다.

장애가 있는:
비활성화된 경우, OVN-Kubernetes는 MAC 주소만 할당하고 2계층 통신을 제공하므로 사용자는 IP 주소를 구성할 수 있습니다. 비활성화는 2계층(보조) 네트워크에만 사용할 수 있습니다. IPAM을 비활성화하면 네트워크 정책, 서비스 등 IP를 기준으로 포드를 선택하는 기능이 더 이상 작동하지 않습니다. 또한, 이 네트워크에 연결된 인터페이스의 IP 포트 보안도 비활성화됩니다. spec.ipam.mode 가 Disabled로 설정된 경우 서브넷 필드는 비어 있어야 합니다 .

spec.network.<topology>.mtu

spec.<topology>.mtu

integer

최대 전송 단위(MTU). 기본값은 1400 입니다. IPv4의 경계는 576 이고, IPv6의 경계는 1280 입니다.

spec.network.localnet.vlan

해당 없음

object

이 필드는 선택 사항이며 가상 LAN(Local Area Network) 태그를 구성하고 물리적 네트워크를 여러 개의 독립적인 브로드캐스트 도메인으로 분할할 수 있습니다.

spec.network.localnet.vlan.mode

해당 없음

object

허용되는 값은 Access 입니다. Access 값은 네트워크 인터페이스가 단일 VLAN에 속하고 모든 트래픽이 spec.network.localnet.vlan.mode.access.id 필드에 구성된 ID 로 레이블이 지정됨을 지정합니다. ID는 액세스 포트의 VLAN ID (VID)를 지정합니다. 값은 1~4094 사이의 정수여야 합니다.

spec.network.localnet.physicalNetworkName

해당 없음

string

물리적 네트워크 인터페이스의 이름을 지정합니다. 지정하는 값은 Open vSwitch(OVS) 브리지 매핑에서 제공한 네트워크 이름 매개변수와 일치해야 합니다.

다음과 같습니다.

<topology>
UserDefinedNetwork CR의 경우 layer2 또는 layer3이 될 수 있습니다. ClusterUserDefinedNetwork CR의 경우 토폴로지는 Localnet이 될 수도 있습니다.

2.1.7. 사용자 정의 네트워크 상태 조건 유형

다음 표에서는 리소스를 설명할 때 ClusterUserDefinedNetworkUserDefinedNetwork CR에 대해 반환되는 상태 조건 유형을 설명합니다. 이러한 조건은 배포 문제를 해결하는 데 사용될 수 있습니다.

Expand
표 2.1. NetworkCreated 조건 유형( ClusterDefinedNetwork 및 UserDefinedNetwork CR)
조건 유형상태이유와 메시지

NetworkCreated

True

True인 경우, 다음과 같은 이유와 메시지가 반환됩니다.

이유

메시지

NetworkAttachmentDefinitionCreated

'NetworkAttachmentDefinition이 다음 네임스페이스에 생성되었습니다: [example-namespace-1, example-namespace-2, example-namespace-3]'

NetworkCreated

False

False 인 경우 다음 메시지 중 하나가 반환됩니다.

이유

메시지

SyncError

NetworkAttachmentDefinition을 생성하지 못했습니다.

SyncError

NetworkAttachmentDefinition을 업데이트하지 못했습니다.

SyncError

primary network already exist in namespace "<namespace_name>": "<primary_network_name>"

SyncError

NetworkAttachmentDefinition을 생성하지 못했습니다. NAD 생성 오류

SyncError

원하는 이름을 가진 외부 NetworkAttachmentDefinition이 이미 존재합니다.

SyncError

UserDefinedNetwork에 종료자를 추가하는 데 실패했습니다.

NetworkAttachmentDefinitionDeleted

NetworkAttachmentDefinition is being deleted: [<namespace>/<nad_name>]

Expand
표 2.2. NetworkAllocationSucceeded 조건 유형( UserDefinedNetwork CR)
조건 유형상태이유와 메시지

NetworkAllocationSucceeded

True

True인 경우, 다음과 같은 이유와 메시지가 반환됩니다.

이유

메시지

NetworkAllocationSucceeded

모든 동기화된 노드에 대한 네트워크 할당이 성공했습니다.

NetworkAllocationSucceeded

False

False인 경우 다음 메시지가 반환됩니다.

이유

메시지

InternalError

최소 한 개의 노드 [<node_name>]에 대한 네트워크 할당에 실패했습니다. 자세한 내용은 UDN 이벤트를 확인하세요.

Expand
표 2.3. ClusterUserDefinedNetwork CR에 대한 잘못된 MTU 시나리오 유형
조건 유형이유, 메시지, 해결책

잘못된 MTU

MTU가 잘못 설정되면 다음 메시지 중 하나가 반환됩니다.

이유

메시지

해결

mtu 필드는 65536 보다 높게 설정됩니다.

본문의 spec.network.localnet.mtu는 65536 보다 작아야 합니다.

mtu 필드를 65536 보다 낮게 설정해야 합니다.

mtu 필드는 576 보다 낮게 설정됩니다.

본문의 spec.network.localnet.mtu는 576 이상이어야 합니다.

mtu 필드를 576 이상으로 설정해야 합니다.

IPv6 서브넷을 사용하는 경우 mtu 필드는 최소 1280 이어야 합니다.

IPv6 서브넷을 사용하는 경우 MTU는 1280 이상이어야 합니다.

사용자 정의 네트워크 구성에 IPv6 서브넷이 정의된 경우 MTU 필드를 1280 이상으로 설정해야 합니다.

Expand
표 2.4. ClusterUserDefinedNetwork CR에 대한 잘못된 PhysicalNetworkName 시나리오 유형
조건 유형이유, 메시지, 해결책

invalid PhysicalNetworkName

PhysicalNetworkName이 잘못 설정되면 다음 메시지 중 하나가 반환됩니다.

이유

메시지

해결

물리적 네트워크의 이름이 설정되지 않았습니다.

spec.network.localnet.physicalNetworkName: 필수 값

physicalNetworkName 필드를 설정해야 합니다.

물리적 네트워크의 이름이 최소 길이 요구 사항을 충족하지 않습니다.

본문의 spec.network.localnet.physicalNetworkName은 최소 1자 이상이어야 합니다.

실제 네트워크 이름은 최소 1자 이상으로 설정해야 합니다.

물리적 네트워크 이름이 최대 문자 수인 253자를 초과했습니다.

spec.network.localnet.physicalNetworkName: 너무 깁니다. 253바이트를 넘을 수 없습니다.

물리적 네트워크 이름은 253자를 넘지 않도록 설정해야 합니다.

물리적 네트워크의 이름에는 , 또는 : 이 포함될 수 없습니다.

physicalNetworkName에는 "," 또는 ":" 문자가 포함될 수 없습니다 .

물리적 네트워크 이름에서 , 또는 : 를 제거해야 합니다.

Expand
표 2.5. ClusterUserDefinedNetwork CR에 대한 잘못된 역할 시나리오 유형
조건 유형이유, 메시지, 해결책

역할이 설정되지 않았 거나 역할이 기본임

spec.network.localnet.role 이 잘못 설정되면 다음 메시지 중 하나가 반환됩니다.

이유

메시지

해결

로컬넷 토폴로지에 대한 역할 필드를 설정해야 합니다.

spec.network.localnet.role: 필수 값

역할 필드를 설정해야 합니다.

Primary는 Localnet 토폴로지에 지원되는 값이 아닙니다.

spec.network.localnet.role: 지원되지 않는 값: "Primary": 지원되는 값: "Secondary"

Localnet 토폴로지의 역할 필드를 허용된 값인 Secondary 로 설정해야 합니다.

Expand
표 2.6. ClusterUserDefinedNetwork CR에 대한 잘못된 서브넷 및 IPAM 시나리오 유형
조건 유형이유, 메시지, 해결책

LocalnetInvalidSubnets

spec.network.localnet.subnets 또는 spec.network.localnet.ipam 이 잘못 설정되면 다음 메시지 중 하나가 반환됩니다.

이유

메시지

해결

선택 필드인 subnetsipam.mode 는 함께 설정해야 합니다.

ipam.mode가 활성화되거나 설정되지 않은 경우 서브넷이 필요하고 그렇지 않은 경우 금지됩니다.

spec.network.localnet.ipam.mode가 명시적으로 비활성화되어 있지 않는 한 서브넷 필드를 설정해야 합니다.

이 선택적 필드를 사용할 때 spec.network.localnet.subnets 에는 허용 가능한 값이 있어야 합니다.

ClusterUserDefinedNetwork "localnet-empty-subnets-fail"이 유효하지 않습니다: spec.network.localnet.subnets: 잘못된 값: 0: 본문의 spec.network.localnet.subnets에는 최소 1개의 항목이 있어야 합니다.

spec.network.localnet.subnets 에 대해 허용 가능한 값을 설정해야 합니다. 허용되는 값은 OpenShift Container Platform에서 사용하는 CIDR 범위와 겹치지 않는 IPv4 및 IPv6 Classless Inter-Domain Routing(CIDR) 범위입니다.

선택적 spec.network.localnet.excludeSubnets 필드를 사용하는 경우 서브넷 필드를 설정해야 합니다.

subnets가 설정되지 않은 경우 excludeSubnets도 설정되지 않아야 합니다.

spec.network.localnet.excludeSubnet 필드를 사용하는 경우 spec.network.localnet.subnets 필드 를 설정해야 합니다.

excludeSubnetssubnets 필드 내의 값이어야 합니다.

excludeSubnets는 서브넷 필드에 지정된 네트워크의 하위 네트워크여야 합니다.

excludeSubnets 필드의 값을 subnets 필드 내에 있도록 설정해야 합니다. 예를 들어, 서브넷 값이 192.168.100.0/24 이고 excludeSubnets 값이 192.168.200.1/32 인 것은 유효하지 않습니다.

CIDR 범위가 잘못되었습니다.

ClusterUserDefinedNetwork "localnet-subnets-invalid-ipv4-cidr-fail"이 잘못되었습니다: spec.network.localnet.subnets[0]: 잘못된 값: "string": CIDR이 잘못되었습니다.

spec.network.localnet.subnets 필드에 대해 허용 가능한 CIDR 범위를 설정해야 합니다. 허용되는 값은 OpenShift Container Platform에서 사용되지 않거나 예약되지 않은 IPv4 및 IPv6 CIDR 범위입니다.

ipam.mode가 Enabled 로 설정되어 있거나 IPAM 모드가 설정되지 않은 경우(기본값이 Enabled 이기 때문) 서브넷 필드를 설정해야 합니다.

ipam.mode가 활성화되어 있거나 설정되지 않은 경우 서브넷이 필요하고, 그렇지 않은 경우 금지됩니다 .

spec.network.localnet.ipam.mode가 명시적으로 비활성화되어 있지 않은 한 spec.network.localnet.subnets 필드를 설정해야 합니다.

spec.network.localnet.subnets 필드에 두 개의 CIDR 범위를 설정하려면 하나는 IPv4이고 다른 하나는 IPv6이어야 합니다.

잘못된 값입니다... 2개의 CIDR이 설정되면 서로 다른 IP 패밀리에 속해야 합니다 .

CIDR 범위 중 하나를 다른 IP 패밀리로 변경해야 합니다.

spec.network.localnet.ipam.modeDisabled 이지만 spec.network.localnet.lifecycle 의 값은 Persistent 입니다.

수명 주기 지속성은 ipam.mode가 활성화된 경우에만 지원됩니다.

선택적 필드 lifecycle에 Persistent 값이 있는 경우 ipam.mode를 Enabled 로 설정해야 합니다.

Expand
표 2.7. ClusterUserDefinedNetwork CR에 대한 잘못된 VLAN 시나리오 유형
조건 유형이유, 메시지, 해결책

잘못된 VLAN 또는 잘못된 모드

spec.network.localnet.vlan 이 잘못 설정되면 다음 메시지 중 하나가 반환됩니다.

이유

메시지

해결

spec.network.localnet.vlan.mode 필드를 설정해야 합니다.

spec.network.localnet.vlan.mode: 지원되지 않는 값: "Disabled": 지원되는 값: "Access"

spec.network.localnet.vlan.mode 필드를 액세스 모드로 설정해야 합니다.

spec.network.localnet.vlan.mode가 액세스 모드로 설정된 경우 spec.network.localnet.vlan 필드를 설정해야 합니다.

VLAN 모드가 '액세스'인 경우 VLAN 액세스 구성이 필요하고, 그렇지 않은 경우 금지됩니다 .

액세스 모드를 사용하는 경우 spec.network.localnet.vlan.mode.access 필드를 설정해야 합니다.

액세스 모드를 사용하는 경우 spec.network.localnet.vlan.access.id 값을 설정해야 합니다.

spec.network.localnet.vlan.access.id: 필수 값

spec.network.localnet.mode.access.id 에 대한 값을 설정해야 합니다.

access.id 에 허용되는 값은 1 이상입니다.

본문의 spec.network.localnet.vlan.access.id는 1 이상이어야 합니다.

access.id 필드에는 1 이상의 값을 설정해야 합니다.

access.id 에 허용되는 값은 4094 이하여야 합니다.

본문의 spec.network.localnet.vlan.access.id는 4094 이하여야 합니다.

access.id 필드에는 4094 이하의 값을 설정해야 합니다.

2.1.8. 사용자 정의 네트워크 포드에서 기본 네트워크 포트 열기

기본적으로 사용자 정의 네트워크(UDN)의 포드는 기본 네트워크와 격리됩니다. 즉, Prometheus 또는 Alertmanager와 같은 모니터링 서비스나 OpenShift Container Platform 이미지 레지스트리를 실행하는 기본 네트워크 포드는 UDN 포드에 대한 연결을 시작할 수 없습니다.

기본 네트워크 포드가 사용자 정의 네트워크 포드에 연결되도록 하려면 k8s.ovn.org/open-default-ports 주석을 사용하면 됩니다. 이 주석은 기본 네트워크에서 액세스할 수 있도록 사용자 정의 네트워크 포드의 특정 포트를 엽니다.

다음 Pod 사양은 기본 네트워크에서 포트 80 에서 들어오는 TCP 연결과 포트 53 에서 UDP 트래픽을 허용합니다.

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.ovn.org/open-default-ports: |
      - protocol: tcp
        port: 80
      - protocol: udp
        port: 53
# ...
Copy to Clipboard Toggle word wrap
참고

열려 있는 포트는 UDN 네트워크 IP가 아닌 포드의 기본 네트워크 IP에서 접근할 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat