21.2. 사용자 정의 네트워크 이해
UserDefinedNetwork
는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
OVN-Kubernetes CNI 플러그인은 보조 Pod 네트워크에 대해 layer2
,layer3
및 localnet
토폴로지를 지원합니다. 그러나 기본 네트워크 또는 모든 Pod가 연결된 기본 네트워크의 경우 계층3
토폴로지만 지원됩니다. 이를 통해 클러스터의 모든 Pod가 동일한 글로벌 계층3
네트워크의 일부인 네트워크 모델을 사용할 수 있지만 기본 네트워크 구성을 사용자 지정하는 기능이 제한됩니다.
사용자 정의 네트워크를 사용하면 클러스터 관리자와 사용자는 사용자가 고유한 네트워크 토폴로지를 정의하고, 네트워크 격리를 확인하고, 워크로드에 대한 IP 주소 지정을 관리하고, 고급 네트워킹 기능을 활용할 수 있는 기능을 제공하는 네트워크 구성 옵션을 제공합니다. 사용자 정의 네트워크는 네트워킹 유연성, 보안 및 성능을 개선하는 데 도움이 됩니다.
사용자 정의 네트워크는 다음과 같은 이점을 제공합니다.
네트워크 격리 개선
- 테넌트 격리: 네임스페이스는 RHOSP(Red Hat OpenStack Platform)에서 테넌트를 분리하는 방법과 유사하게 격리된 기본 네트워크를 보유할 수 있습니다. 이렇게 하면 교차 테넌트 트래픽의 위험을 줄임으로써 보안이 향상됩니다.
네트워크 유연성
- 계층 2 및 3 계층 지원: 클러스터 관리자는 기본 네트워크를 계층 2 또는 계층 3 네트워크 유형으로 구성할 수 있습니다. 이렇게 하면 기본 네트워크에 보조 네트워크의 유연성을 제공합니다.
간소화된 네트워크 관리
- 네트워크 구성 복잡성 감소: 사용자 정의 네트워크를 사용하면 서로 다른 네트워크의 워크로드를 그룹화하여 격리를 수행할 수 있으므로 복잡한 네트워크 정책의 필요성이 제거됩니다.
고급 기능
- 일관되고 선택 가능한 IP 주소 지정: 사용자는 다른 네임스페이스 및 클러스터에서 IP 서브넷을 지정 및 재사용할 수 있으므로 일관된 네트워킹 환경을 제공할 수 있습니다.
- 다중 네트워크 지원: 사용자 정의 네트워킹 기능을 사용하면 관리자가 여러 네임스페이스를 단일 네트워크에 연결하거나 네임스페이스 집합마다 별도의 네트워크를 만들 수 있습니다.
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 서브넷을 수정하면 네트워크 연결이 중단되고 구성 문제가 발생할 수 있습니다.
-
OpenShift Container Platform 4.17 이상의 경우 클러스터는 IPv4에
-
테넌트가
NetworkAttachmentDefinition
(NAD) 리소스가 아닌UserDefinedNetwork
리소스를 사용하고 있는지 확인합니다. 이렇게 하면 테넌트 간에 보안 위험이 발생할 수 있습니다. - 네트워크 분할을 생성할 때는 UDN 리소스를 사용하여 사용자 정의 네트워크 분할을 완료할 수 없는 경우에만 192.0.2.D 리소스를 사용해야 합니다.
-
UDN의 클러스터 서브넷 및 서비스 CIDR은 기본 클러스터 서브넷 CIDR과 중복될 수 없습니다. OVN-Kubernetes 네트워크 플러그인은
100.64.0.0/16
을 기본 네트워크의 조인 서브넷으로 사용하므로 해당 값을 사용하여 UDNjoinSubnets
필드를 구성해서는 안 됩니다. 기본 주소 값이 클러스터의 네트워크 어디에서나 사용되는 경우joinSubnets
필드를 설정하여 재정의해야 합니다. 자세한 내용은 "사용자 정의 네트워크 CR에 대한 추가 구성 세부 정보"를 참조하십시오.
21.2.3. UserDefinedNetwork 사용자 정의 리소스 생성
다음 절차에서는 네임스페이스 범위가 지정된 사용자 정의 네트워크를 생성합니다. 사용 사례에 따라 Layer2
토폴로지 유형에 대한 my-layer-two-udn.yaml
예제 또는 Layer3
토폴로지 유형에 대한 my-layer-three-udn.yaml
예제를 사용하여 요청을 생성합니다.
프로세스
Layer2
또는Layer3
토폴로지 유형 사용자 정의 네트워크에 대한 요청을 생성합니다.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
필드는 필수입니다.
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
에서 지원됩니다.
-
-
다음 명령을 실행하여 요청을 적용합니다.
$ oc apply -f <my_layer_two_udn.yaml>
여기서
<my_layer_two_udn.yaml
>은Layer2
또는Layer3
구성 파일의 이름입니다.다음 명령을 실행하여 요청이 성공했는지 확인합니다.
$ 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 네트워크 토폴로지의 명시적 필요 및 이해 없이 이러한 필드를 설정하지 않는 것이 좋습니다.
필드 | 유형 | 설명 |
---|---|---|
| object |
생략하면 플랫폼에서는 IPv4의 경우
|
| object |
|
| integer |
최대 전송 단위(MTU)입니다. 기본값은 |