18.2. 기본 네트워크

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. 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 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2 및 Layer3 입니다. Layer2 토폴로지 유형을 지정하면 모든 노드에서 공유하는 하나의 논리 스위치가 생성됩니다.

      3

      이 필드는 토폴로지 구성을 지정합니다. layer2 또는 layer3 일 수 있습니다.

      4

      기본 또는 보조를 지정합니다. primary 는 4.17에서 지원되는 유일한 역할 사양입니다.

      5

      Layer2 토폴로지 유형의 경우 다음은 subnet 필드에 대한 구성 세부 정보를 지정합니다.

      • subnets 필드는 선택 사항입니다.
      • subnets 필드는 문자열 유형이며 IPv4 및 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다.
      • subnets 필드에는 하나 또는 두 개의 항목을 사용할 수 있습니다. 두 가지 면에서는 다른 가족이어야 합니다. 예를 들어 서브넷 값은 10.100.0.0/16 및 2001: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 필드는 네트워크 구성을 설명합니다. 허용되는 값은 Layer2 및 Layer3 입니다. Layer3 토폴로지 유형을 지정하면 노드당 계층 2 세그먼트가 생성되며 각각 다른 서브넷이 있습니다. 계층 3 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.

      3

      이 필드는 토폴로지 구성을 지정합니다. 유효한 값은 layer2 또는 layer3 입니다.

      4

      기본 또는 보조 역할을 지정합니다. primary 는 4.17에서 지원되는 유일한 역할 사양입니다.

      5

      Layer3 토폴로지 유형의 경우 다음에서는 subnet 필드에 대한 구성 세부 정보를 지정합니다.

      • subnets 필드는 필수입니다.

      • subnets 필드의 유형은 cidr 및 hostSubnet:입니다.

        • 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

프로세스

1. 선택 사항: 추가 네트워크의 네임스페이스를 생성합니다.

   $ oc create namespace <namespace_name>

2. CNO 구성을 편집하려면 다음 명령을 입력합니다.

   $ oc edit networks.operator.openshift.io cluster

3. 다음 예제 CR과 같이 생성 중인 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     # ...
     additionalNetworks:
     - name: tertiary-net
       namespace: namespace2
       type: Raw
       rawCNIConfig: |-
         {
           "cniVersion": "0.3.1",
           "name": "tertiary-net",
           "type": "ipvlan",
           "master": "eth1",
           "mode": "l2",
           "ipam": {
             "type": "static",
             "addresses": [
               {
                 "address": "192.168.1.23/24"
               }
             ]
           }
         }

4. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

프로세스

1. 다음 예와 같이 추가 네트워크 구성을 사용하여 YAML 파일을 생성합니다.

   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     name: next-net
   spec:
     config: |-
       {
         "cniVersion": "0.3.1",
         "name": "work-network",
         "type": "host-device",
         "device": "eth1",
         "ipam": {
           "type": "dhcp"
         }
       }

2. 추가 네트워크를 생성하려면 다음 명령을 입력합니다.

   $ oc apply -f <file>.yaml

   다음과 같습니다.

   <file>

   YAML 매니페스트가 포함된 파일의 이름을 지정합니다.