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

프로세스

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

      기본 또는 보조 역할을 지정합니다.

      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

      기본 또는 보조 역할을 지정합니다.

      5

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

      • subnets 필드는 필수입니다.

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

        • CIDR 은 클러스터의 clusterNetwork 구성 설정과 동일합니다. CIDR의 IP 주소는 사용자 정의 네트워크의 포드에 배포됩니다. 이 매개변수는 문자열 값을 허용합니다.
        • 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",
         "namespace": "namespace2", 1
         "type": "host-device",
         "device": "eth1",
         "ipam": {
           "type": "dhcp"
         }
       }

   1

   선택 사항: CryostatD가 적용되는 네임스페이스를 지정할 수 있습니다. CryostatD를 배포해야 하는 네임스페이스에서 작업하는 경우 이 사양은 필요하지 않습니다.

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

   $ oc apply -f <file>.yaml

   다음과 같습니다.

   <file>

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