21.2. 사용자 정의 네트워크 이해


중요

UserDefinedNetwork 는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OVN-Kubernetes CNI 플러그인은 보조 Pod 네트워크에 대해 layer2,layer3localnet 토폴로지를 지원합니다. 그러나 기본 네트워크 또는 모든 Pod가 연결된 기본 네트워크의 경우 계층3 토폴로지만 지원됩니다. 이를 통해 클러스터의 모든 Pod가 동일한 글로벌 계층3 네트워크의 일부인 네트워크 모델을 사용할 수 있지만 기본 네트워크 구성을 사용자 지정하는 기능이 제한됩니다.

사용자 정의 네트워크를 사용하면 클러스터 관리자와 사용자는 사용자가 고유한 네트워크 토폴로지를 정의하고, 네트워크 격리를 확인하고, 워크로드에 대한 IP 주소 지정을 관리하고, 고급 네트워킹 기능을 활용할 수 있는 기능을 제공하는 네트워크 구성 옵션을 제공합니다. 사용자 정의 네트워크는 네트워킹 유연성, 보안 및 성능을 개선하는 데 도움이 됩니다.

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

  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으로 애플리케이션을 마이그레이션할 수 있습니다.

21.2.1. UserDefinedNetwork 사용자 정의 리소스에 대한 제한 사항

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가 정상으로 표시되지만 기본 인터페이스에서 연결이 끊어진 시나리오는 사용자 정의 네트워크를 사용할 수 있습니다.
  • 네트워크 정책 제한: 다른 사용자 정의 기본 네트워크에 연결된 네임스페이스 간 트래픽을 활성화하는 네트워크 정책은 적용되지 않습니다. 이러한 트래픽 정책은 격리된 네트워크 간에 연결이 없기 때문에 적용되지 않습니다.

21.2.2. UserDefinedNetwork의 모범 사례

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

  • OpenShift-* 네임스페이스는 UDN을 설정하는 데 사용해서는 안 됩니다.
  • 사용자 정의 네트워크에는 2개의 masquerade IP 주소가 필요합니다. 필요한 네트워크 수를 보유할 수 있을 만큼 충분히 커지도록 마스커레이드 서브넷을 재구성해야 합니다.

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

21.2.3. UserDefinedNetwork 사용자 정의 리소스 생성

다음 절차에서는 네임스페이스 범위가 지정된 사용자 정의 네트워크를 생성합니다. 사용 사례에 따라 Layer2 토폴로지 유형에 대한 my-layer-two-udn.yaml 예제 또는 Layer3 토폴로지 유형에 대한 my-layer-three-udn.yaml 예제를 사용하여 요청을 생성합니다.

프로세스

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

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

    $ oc apply -f <my_layer_two_udn.yaml>

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

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

    $ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml

    여기서 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: NetworkReady

21.2.3.1. UserDefinedNetworks CR에 대한 추가 구성 세부 정보

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

표 21.1. UserDefinedNetworks 선택적 구성
필드유형설명

spec.joinSubnets

object

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

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

spec.IPAMLifecycle

object

IPAMLifecycle 필드는 IP 주소 관리 시스템(IPAM)을 구성합니다. 가상 워크로드에 이 필드를 사용하여 영구 IP 주소를 보장할 수 있습니다. 이 필드는 토폴로지layer2 인 경우 허용됩니다. subnets 필드는 이 필드가 지정될 때 지정해야 합니다. 영구 값을 설정하면 재부팅 및 마이그레이션 시 가상 워크로드에 영구 IP 주소가 있는지 확인합니다. 컨테이너 네트워크 인터페이스(CNI)에서 할당하며 OVN-Kubernetes에서 Pod IP 주소를 프로그래밍하는 데 사용됩니다. Pod 주석에는 이 값을 변경할 수 없습니다.

spec.layer2.mtuspec.layer3.mtu

integer

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.