2장. 기본 네트워크


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

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

Kubernetes 설계는 간단한 배포에 유용하지만 이 계층 3 토폴로지는 특히 최신 다중 테넌트 배포에 대해 기본 네트워크 세그먼트 구성의 사용자 지정을 제한합니다.

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

참고

cgroupv1 Linux Control Groups(cgroup)를 사용하는 노드는 사용자 정의 네트워크를 생성하기 전에 cgroupv1 에서 cgroupv2 로 재구성해야 합니다. 자세한 내용은 Linux cgroup 구성을 참조하십시오.

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

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

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

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

  1. 보안을 위한 네트워크 격리 개선

    • 테넌트 격리: 네임스페이스는 RHOSP(Red Hat OpenStack Platform)에서 테넌트를 분리하는 방법과 유사하게 격리된 기본 네트워크를 보유할 수 있습니다. 이렇게 하면 교차 테넌트 트래픽의 위험을 줄임으로써 보안이 향상됩니다.
  2. 네트워크 유연성

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

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

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

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

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

  1. 관리자는 k8s.ovn.org/primary-user-defined-network 레이블을 사용하여 사용자 정의 네트워크의 네임스페이스를 생성합니다.
  2. UserDefinedNetwork CR은 클러스터 관리자 또는 사용자가 생성합니다.
  3. 사용자는 네임스페이스에 Pod를 생성합니다.

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

UDN(사용자 정의 네트워크)은 사용자 정의 네트워크 구성 옵션을 제공하지만 클러스터 관리자와 개발자는 이러한 네트워크를 구현하고 관리할 때 알고 있어야 하는 제한 사항이 있습니다. UDN을 구현하기 전에 다음 제한 사항을 고려하십시오.

  • DNS 제한 사항:

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

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

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

그림 2.1. 구성 요소 통신에 가상 스위치를 사용하는 플랫 계층 2 토폴로지

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

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

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

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

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

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

2.1.4. ClusterUserDefinedNetwork CR 정보

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

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

그림 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 레이블이 없고 Pod가 생성된 경우 Pod가 기본 네트워크에 직접 연결됩니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 네임스페이스와 일치하는 기본 ClusterUserDefinedNetwork CR이 생성되면 오류가 보고되고 네트워크가 생성되지 않습니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 기본 ClusterUserDefinedNetwork CR이 이미 존재하는 경우 네임스페이스의 Pod가 생성되어 기본 네트워크에 연결됩니다.
    • 네임스페이스에 라벨이 있고 기본 ClusterUserDefinedNetwork CR이 없으면 ClusterUserDefinedNetwork CR이 생성될 때까지 네임스페이스의 Pod가 생성되지 않습니다.

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은 Layer2 토폴로지만 지원합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  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. cluster-layer-two-udn.yaml 과 같은 YAML 파일을 생성하여 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의합니다.

      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
      terms가 AND 관계로 평가되는 matchLabels 선택기 유형을 사용합니다.
      4 5
      matchLabels 선택기 유형이 사용되므로 <label_1_key>=< label_1_value> 및 <label_2_key >=< label_2_value > 라벨이 모두 포함된 네임스페이스를 프로비저닝합니다.
      6
      네트워크 구성을 설명합니다.
      7
      topology 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다.
      8
      이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 일 수 있습니다.
      9
      기본 또는 보조를 지정합니다. primary 는 4.18에서 지원되는 유일한 역할 사양입니다.
      10
      Layer2 토폴로지 유형의 경우 다음은 subnet 필드에 대한 구성 세부 정보를 지정합니다.
      • subnets 필드는 선택 사항입니다.
      • subnets 필드는 문자열 유형이며 IPv4 및 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • subnets 필드에는 하나 또는 두 개의 항목을 사용할 수 있습니다. 두 가지 면에서는 다른 가족이어야 합니다. 예를 들어 서브넷 값은 10.100.0.0/162001:db8::/64 입니다.
      • Layer2 서브넷은 생략할 수 있습니다. 생략하면 사용자는 Pod의 고정 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "정정 IP 주소를 사용하여 Pod 구성"을 참조하십시오.
    2. cluster-layer-three-udn.yaml 과 같은 YAML 파일을 생성하여 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의합니다.

      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
      terms는 OR 관계로 평가되는 matchExpressions 선택기 유형을 사용합니다.
      4
      일치시킬 레이블 키를 지정합니다.
      5
      Operator를 지정합니다. 유효한 값에는 in,NotIn,ExistsDoesNotExist 가 있습니다.
      6
      matchExpressions 유형이 사용되므로 또는 <example_namespace_two> 와 일치하는 <example_namespace_one> 네임스페이스를 프로비저닝합니다.
      7
      네트워크 구성을 설명합니다.
      8
      topology 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 계층 2 세그먼트가 생성되며 각각 다른 서브넷이 있습니다. 계층 3 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.
      9
      이 필드는 토폴로지 구성을 지정합니다. 유효한 값은 layer2 또는 layer3 입니다.
      10
      기본 또는 보조 역할을 지정합니다. primary 는 4.18에서 지원되는 유일한 역할 사양입니다.
      11
      Layer3 토폴로지 유형의 경우 다음에서는 subnet 필드에 대한 구성 세부 정보를 지정합니다.
      • subnets 필드는 필수입니다.
      • subnets 필드의 유형은 cidrhostSubnet:입니다.

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

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

    여기서 <example_cluster_udn>.yamlLayer2 또는 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. 웹 콘솔을 사용하여 ClusterUserDefinedNetwork CR 생성

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

참고

현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3 토폴로지를 사용하여 ClusterUserDefinedNetwork CR 생성은 지원되지 않습니다.

사전 요구 사항

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

프로세스

  1. 관리자 화면에서 네트워킹 사용자 정의 네트워크를 클릭합니다.
  2. ClusterUserDefinedNetwork 를 클릭합니다.
  3. 이름 필드에서 클러스터 범위의 UDN을 지정합니다.
  4. Subnet 필드에 값을 지정합니다.
  5. Project(s) Match Labels 필드에서 적절한 레이블을 추가하여 클러스터 UDN이 적용되는 네임스페이스를 선택합니다.
  6. 생성을 클릭합니다. 클러스터 범위 UDN은 5단계에서 지정한 라벨이 포함된 네임스페이스에 있는 Pod의 기본 기본 네트워크 역할을 합니다.

2.1.5. UserDefinedNetwork CR 정보

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

다음 다이어그램에서는 각 네임스페이스에 하나의 할당된 사용자 정의 네트워크(UDN)가 할당되고 각 UDN에는 Pod IP 할당에 대해 사용자 지정 서브넷이 할당되는 네 가지 클러스터 네임스페이스를 보여줍니다. OVN-Kubernetes는 겹치는 UDN 서브넷을 처리합니다. Kubernetes 네트워크 정책을 사용하지 않으면 UDN에 연결된 Pod는 해당 UDN의 다른 Pod와 통신할 수 있습니다. 기본적으로 이러한 Pod는 다른 UDN에 존재하는 Pod와 통신하지 않습니다. 마이크로 세분화의 경우 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 레이블이 없고 Pod가 생성된 경우 Pod가 기본 네트워크에 직접 연결됩니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 네임스페이스와 일치하는 기본 UserDefinedNetwork CR이 생성되면 상태 오류가 보고되고 네트워크가 생성되지 않습니다.
    • 네임스페이스에 k8s.ovn.org/primary-user-defined-network 레이블이 없고 기본 UserDefinedNetwork CR이 이미 존재하는 경우 네임스페이스의 Pod가 생성되어 기본 네트워크에 연결됩니다.
    • 네임스페이스에 라벨이 있고 기본 UserDefinedNetwork CR이 없으면 UserDefinedNetwork CR이 생성될 때까지 네임스페이스의 Pod가 생성되지 않습니다.
  • 사용자 정의 네트워크에는 2개의 masquerade IP 주소가 필요합니다. 필요한 네트워크 수를 보유할 수 있을 만큼 충분히 커지도록 마스커레이드 서브넷을 재구성해야 합니다.

    중요
    • OpenShift Container Platform 4.17 이상의 경우 클러스터는 IPv4에 169.254.0.0/17 을 사용하고 IPv6의 경우 fd69::/112 를 기본 masquerade 서브넷으로 사용합니다. 이러한 범위는 사용자가 피해야 합니다. 업데이트된 클러스터의 경우 기본 masquerade 서브넷이 변경되지 않습니다.
    • 프로젝트에 대해 사용자 정의 네트워크를 구성한 후에는 클러스터의 masquerade 서브넷을 변경할 수 없습니다. UserDefinedNetwork CR을 설정한 후 masquerade 서브넷을 수정하면 네트워크 연결이 중단되고 구성 문제가 발생할 수 있습니다.
  • 테넌트가 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 예제를 사용하여 요청을 생성합니다.

perquisites

  • cluster-admin 권한으로 로그인했거나 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. my-layer-two-udn.yaml 과 같은 YAML 파일을 생성하여 다음 예와 같이 Layer2 토폴로지에 대한 요청을 정의합니다.

      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(Cluster Network Operator)에서 생성한 글로벌 네임스페이스를 복제해서는 안 됩니다.
      2
      topology 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다.
      3
      이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 일 수 있습니다.
      4
      기본 또는 보조 역할을 지정합니다.
      5
      Layer2 토폴로지 유형의 경우 다음은 subnet 필드에 대한 구성 세부 정보를 지정합니다.
      • subnets 필드는 선택 사항입니다.
      • subnets 필드는 문자열 유형이며 IPv4 및 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • subnets 필드에는 하나 또는 두 개의 항목을 사용할 수 있습니다. 두 가지 면에서는 다른 가족이어야 합니다. 예를 들어 서브넷 값은 10.100.0.0/162001:db8::/64 입니다.
      • Layer2 서브넷은 생략할 수 있습니다. 생략하면 사용자는 Pod의 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다.
      • ipamLifecycle 필드가 지정되면 Layer2 subnets 필드는 필수입니다.
    2. my-layer-three-udn.yaml 과 같은 YAML 파일을 생성하여 다음 예와 같이 Layer3 토폴로지에 대한 요청을 정의합니다.

      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(Cluster Network Operator)에서 생성한 글로벌 네임스페이스를 복제해서는 안 됩니다.
      2
      topology 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 계층 2 세그먼트가 생성되며 각각 다른 서브넷이 있습니다. 계층 3 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.
      3
      이 필드는 토폴로지 구성을 지정합니다. 유효한 값은 layer2 또는 layer3 입니다.
      4
      기본 또는 보조 역할을 지정합니다.
      5
      Layer3 토폴로지 유형의 경우 다음에서는 subnet 필드에 대한 구성 세부 정보를 지정합니다.
      • subnets 필드는 필수입니다.
      • subnets 필드의 유형은 cidrhostSubnet:입니다.

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

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

    여기서 <my_layer_two_udn>.yamlLayer2 또는 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 CR 생성

OpenShift Container Platform 웹 콘솔을 사용하여 Layer2 토폴로지 및 Primary 역할을 사용하여 UserDefinedNetwork CR(사용자 정의 리소스)을 생성할 수 있습니다.

참고

현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3 토폴로지 또는 Secondary 역할을 사용하여 UserDefinedNetwork CR을 생성할 수 없습니다.

사전 요구 사항

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

프로세스

  1. 관리자 화면에서 네트워킹 사용자 정의 네트워크를 클릭합니다.
  2. Create UserDefinedNetwork 를 클릭합니다.
  3. 프로젝트 이름 목록에서 이전에 생성한 네임스페이스를 선택합니다.
  4. Subnet 필드에 값을 지정합니다.
  5. 생성을 클릭합니다. 사용자 정의 네트워크는 이 네임스페이스에서 생성하는 Pod의 기본 기본 네트워크 역할을 합니다.

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

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

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

CUDN 필드

UDN 필드

유형

설명

spec.network.<topology>.joinSubnets

spec.<topology>.joinSubnets

object

생략하면 플랫폼에서는 IPv4의 경우 100.65.0.0/16, IPv6의 경우 fd99::/64joinSubnets 필드의 기본값을 설정합니다. 기본 주소 값이 클러스터의 네트워크 어디에서나 사용되는 경우 joinSubnets 필드를 설정하여 재정의해야 합니다. 이 필드를 설정하도록 선택하는 경우 클러스터 서브넷, 기본 네트워크 클러스터 서브넷 및 masquerade 서브넷과 같은 클러스터의 다른 서브넷과 충돌하지 않는지 확인합니다.

joinSubnets 필드는 사용자 정의 네트워크 내의 다양한 세그먼트 간 라우팅을 구성합니다. 듀얼 스택 클러스터는 각 IP 제품군에 대해 2개의 서브넷을 설정할 수 있습니다. 그렇지 않으면 서브넷은 1개만 허용됩니다. 이 필드는 기본 네트워크에만 허용됩니다.

spec.network.<topology>.ipam.lifecycle

spec.<topology>.ipam.lifecycle

object

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

ipam.mode 매개변수가 Enabled 로 설정된 경우에만 Persistent 값을 설정할 수 있습니다.

spec.network.<topology>.ipam.mode

spec.network.<topology>.ipam.mode

object

mode 매개변수는 OVN-Kubernetes에서 관리하는 IP 구성의 양을 제어합니다. 다음 옵션을 사용할 수 있습니다.

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

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

spec.network.<topology>.mtu

spec.<topology>.mtu

integer

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

다음과 같습니다.

<topology>
layer2 또는 layer3 중 하나입니다.

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을 생성하지 못했습니다: CryostatD 오류를 생성합니다.

SyncError

원하는 이름의 외래 NetworkAttachmentDefinition이 이미 존재합니다.

SyncError

UserDefinedNetwork에 종료자를 추가하지 못했습니다

NetworkAttachmentDefinitionDeleted

NetworkAttachmentDefinition이 삭제되고 있습니다: [<namespace>/<nad_name>]

Expand
표 2.2. NetworkAllocationSucceeded 조건 유형 (사용자 정의 네트워크 CR)
조건 유형상태이유 및 메시지

NetworkAllocationSucceeded

True

True 인 경우 다음 이유 및 메시지가 반환됩니다.

이유

메시지

NetworkAllocationSucceeded

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

NetworkAllocationSucceeded

False

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

이유

메시지

InternalError

하나 이상의 노드에 대해 네트워크 할당에 실패했습니다. [<node_name>], UDN 이벤트에서 자세한 정보를 확인합니다.

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

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

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

다음 Pod 사양에서는 기본 네트워크에서 포트 53 의 포트 80 및 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가 아닌 Pod의 기본 네트워크 IP에서 액세스할 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat