2장. 기본 네트워크
2.1. 사용자 정의 네트워크 정보 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 네트워크(UDN)를 구현하기 전에는 OpenShift Container Platform용 OVN-Kubernetes CNI 플러그인은 기본 네트워크에서 3계층 토폴로지만 지원했습니다. 쿠버네티스의 설계 원칙에 따라 모든 포드는 메인 네트워크에 연결되고, 모든 포드는 IP 주소를 통해 서로 통신하며, 포드 간 트래픽은 네트워크 정책에 따라 제한됩니다.
Kubernetes 디자인은 간단한 배포에는 유용하지만, 이 계층 3 토폴로지는 특히 최신 멀티 테넌트 배포의 경우 기본 네트워크 세그먼트 구성의 사용자 정의를 제한합니다.
UDN은 사용자 정의 레이어 2 및 레이어 3 네트워크 세그먼트를 활성화하여 Kubernetes Pod 네트워크의 기본 레이어 3 토폴로지의 유연성과 세분화 기능을 개선합니다. 이러한 모든 세그먼트는 기본적으로 격리됩니다. 이러한 세그먼트는 기본 OVN-Kubernetes CNI 플러그인을 사용하는 컨테이너 포드와 가상 머신의 기본 또는 보조 네트워크 역할을 합니다. UDN은 광범위한 네트워크 아키텍처와 토폴로지를 지원하여 네트워크의 유연성, 보안, 성능을 향상시킵니다.
클러스터 관리자는 ClusterUserDefinedNetwork
사용자 정의 리소스(CR)를 활용하여 클러스터 수준에서 여러 네임스페이스에 걸쳐 있는 기본 또는 보조 네트워크를 만들고 정의하기 위해 UDN을 사용할 수 있습니다. 또한, 클러스터 관리자나 클러스터 사용자는 UDN을 사용하여 UserDefinedNetwork
CR을 통해 네임스페이스 수준에서 보조 네트워크를 정의할 수 있습니다.
다음 섹션에서는 사용자 정의 네트워크의 이점과 제한 사항, ClusterUserDefinedNetwork
또는 UserDefinedNetwork
CR을 생성할 때의 모범 사례, CR을 생성하는 방법, 배포와 관련이 있을 수 있는 추가 구성 세부 정보를 더욱 강조합니다.
2.1.1. 사용자 정의 네트워크의 이점 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 네트워크는 다음과 같은 이점을 제공합니다.
보안을 위한 향상된 네트워크 격리
- 테넌트 격리 : 네임스페이스는 Red Hat OpenStack Platform(RHOSP)에서 테넌트가 격리되는 방식과 유사하게 자체 격리된 기본 네트워크를 가질 수 있습니다. 이를 통해 테넌트 간 트래픽 위험이 줄어들어 보안이 향상됩니다.
네트워크 유연성
- 2계층 및 3계층 지원 : 클러스터 관리자는 기본 네트워크를 2계층 또는 3계층 네트워크 유형으로 구성할 수 있습니다.
간소화된 네트워크 관리
- 네트워크 구성의 복잡성 감소 : 사용자 정의 네트워크를 사용하면 서로 다른 네트워크의 작업 부하를 그룹화하여 격리를 달성할 수 있으므로 복잡한 네트워크 정책이 필요 없습니다.
고급 기능
- 일관되고 선택 가능한 IP 주소 지정 : 사용자는 다양한 네임스페이스와 클러스터에서 IP 서브넷을 지정하고 재사용하여 일관된 네트워킹 환경을 제공할 수 있습니다.
- 다중 네트워크 지원 : 사용자 정의 네트워킹 기능을 통해 관리자는 여러 네임스페이스를 단일 네트워크에 연결하거나, 서로 다른 네임스페이스 집합에 대해 별도의 네트워크를 만들 수 있습니다.
Red Hat OpenStack Platform(RHOSP)에서 애플리케이션 마이그레이션 간소화
- 네트워크 패리티 : 사용자 정의 네트워킹을 사용하면 유사한 네트워크 격리 및 구성 옵션을 제공하여 OpenStack에서 OpenShift Container Platform으로 애플리케이션을 마이그레이션하는 과정이 간소화됩니다.
개발자와 관리자는 사용자 정의 리소스를 사용하여 네임스페이스 범위가 지정된 사용자 정의 네트워크를 만들 수 있습니다. 프로세스 개요는 다음과 같습니다.
-
관리자는
k8s.ovn.org/primary-user-defined-network
레이블이 있는 사용자 정의 네트워크에 대한 네임스페이스를 만듭니다. -
UserDefinedNetwork
CR은 클러스터 관리자나 사용자가 생성합니다. - 사용자는 네임스페이스에 포드를 생성합니다.
2.1.2. 사용자 정의 네트워크의 한계 링크 복사링크가 클립보드에 복사되었습니다!
사용자 정의 네트워크(UDN)는 높은 수준의 사용자 정의가 가능한 네트워크 구성 옵션을 제공하지만, 클러스터 관리자와 개발자는 이러한 네트워크를 구현하고 관리할 때 알아야 할 제한 사항이 있습니다. UDN을 구현하기 전에 다음과 같은 제한 사항을 고려하세요.
DNS 제한 사항 :
- 포드에 대한 DNS 조회는 클러스터 기본 네트워크의 포드 IP 주소로 확인됩니다. 포드가 사용자 정의 네트워크의 일부인 경우에도 DNS 조회는 해당 사용자 정의 네트워크의 포드 IP 주소로 확인되지 않습니다. 그러나 서비스 및 외부 엔터티에 대한 DNS 조회는 예상대로 작동합니다.
- 포드가 기본 UDN에 할당되면 클러스터의 기본 네트워크에서 Kubernetes API(KAPI) 및 DNS 서비스에 액세스할 수 있습니다.
- 초기 네트워크 할당 : Pod를 생성하기 전에 네임스페이스와 네트워크를 생성해야 합니다. 포드가 있는 네임스페이스를 새로운 네트워크에 할당하거나 기존 네임스페이스에 UDN을 생성하는 것은 OVN-Kubernetes에서 허용되지 않습니다.
- 상태 점검 제한 사항 : Kubelet 상태 점검은 클러스터 기본 네트워크에서 수행되므로 Pod의 기본 인터페이스의 네트워크 연결을 확인하지 않습니다. 따라서 기본 네트워크에서는 포드가 정상적으로 보이지만 기본 인터페이스에서는 연결이 끊어지는 시나리오가 사용자 정의 네트워크에서 발생할 수 있습니다.
- 네트워크 정책 제한 : 서로 다른 사용자 정의 기본 네트워크에 연결된 네임스페이스 간 트래픽을 활성화하는 네트워크 정책은 효과적이지 않습니다. 이러한 트래픽 정책은 이러한 분리된 네트워크 간에 연결성이 없기 때문에 적용되지 않습니다.
-
생성 및 수정 제한 :
ClusterUserDefinedNetwork
CR과UserDefinedNetwork
CR은 생성된 후에는 수정할 수 없습니다. -
기본 네트워크 서비스 액세스 : 사용자 정의 네트워크 포드는 기본 네트워크와 분리되어 있으므로 대부분의 기본 네트워크 서비스에 액세스할 수 없습니다. 예를 들어, 사용자 정의 네트워크 포드는 현재 OpenShift Container Platform 이미지 레지스트리에 액세스할 수 없습니다. 이러한 제한으로 인해 소스-이미지 빌드는 사용자 정의 네트워크 네임스페이스에서 작동하지 않습니다. 또한, Git 저장소의 소스 코드를 기반으로 애플리케이션을 생성하는 함수(예:
oc new-app <command>
)와 소스-이미지 빌드를 사용하는 OpenShift Container Platform 템플릿에서 애플리케이션을 생성하는 함수 등 다른 함수는 작동하지 않습니다. 이러한 제한은 다른openshift-*.svc
서비스에도 영향을 미칠 수 있습니다. - 연결 제한 : 사용자 정의 네트워크의 NodePort 서비스는 격리가 보장되지 않습니다. 예를 들어, 동일 노드에 있는 포드에서 서비스로 가는 NodePort 트래픽은 액세스할 수 없지만, 다른 노드에 있는 포드에서 오는 트래픽은 성공합니다.
-
IP 주소 소진에 대한 불분명한 오류 메시지 : 사용자 정의 네트워크의 서브넷에서 사용 가능한 IP 주소가 부족하면 새로운 Pod가 시작되지 않습니다. 이 문제가 발생하면 다음 오류가 반환됩니다.
경고: pod sandbox를 만들지 못했습니다
. 이 오류 메시지는 IP 고갈이 원인임을 명확하게 설명하지 않습니다. 문제를 확인하려면 OpenShift Container Platform 웹 콘솔의 포드 네임스페이스에 있는 이벤트 페이지를 확인하면 됩니다. 이 페이지에는 서브넷 고갈에 대한 명시적 메시지가 보고되어 있습니다.
2.1.3. 2계층 및 3계층 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
플랫 레이어 2 토폴로지는 클러스터의 모든 노드에 분산된 가상 스위치를 생성합니다. 가상 머신과 포드는 이 가상 스위치에 연결되어 모든 구성 요소가 동일한 서브넷 내에서 서로 통신할 수 있습니다. 플랫 레이어 2 토폴로지는 클러스터에 있는 노드 간에 가상 머신을 라이브 마이그레이션하는 데 유용합니다. 다음 다이어그램은 라이브 마이그레이션을 위해 가상 스위치를 사용하는 두 개의 노드가 있는 플랫 레이어 2 토폴로지를 보여줍니다.
그림 2.1. 구성 요소 통신을 위해 가상 스위치를 사용하는 플랫 레이어 2 토폴로지
2계층 서브넷을 지정하지 않기로 결정한 경우 클러스터의 각 포드에 대한 IP 주소를 수동으로 구성해야 합니다. 2계층 서브넷을 지정하지 않으면 포트 보안은 MAC(Media Access Control) 스푸핑만 방지하는 데 국한되며 IP 스푸핑은 포함되지 않습니다. 2계층 토폴로지는 단일 브로드캐스트 도메인을 생성하는데, 이는 대규모 네트워크 환경에서 문제가 될 수 있으며, 토폴로지로 인해 네트워크 성능이 저하될 수 있는 브로드캐스트 스톰이 발생할 수 있습니다.
네트워크에 대해 구성 가능한 옵션을 더욱 확대하려면 계층 2 토폴로지를 사용자 정의 네트워크(UDN)와 통합할 수 있습니다. 다음 다이어그램은 각 노드에 존재하는 포드를 포함하는 2계층 토폴로지를 갖춘 UDN을 사용하는 두 개의 노드를 보여줍니다. 각 노드에는 두 개의 인터페이스가 포함됩니다.
- 네트워크 구성요소를 노드에 연결하는 컴퓨팅 노드인 노드 인터페이스입니다.
-
br-ex
와 같은 OVS(Open vSwitch) 브리지는 Pod가 서로 통신하고 리소스를 공유할 수 있도록 2계층 OVN 스위치를 생성합니다.
외부 스위치는 두 인터페이스를 연결하고, 게이트웨이 또는 라우터는 외부 스위치와 2계층 OVN 스위치 간의 라우팅 트래픽을 처리합니다. 노드 내의 VM과 포드는 UDN을 사용하여 서로 통신할 수 있습니다. 2계층 OVN 스위치는 UDN을 통한 노드 트래픽을 처리하므로 VM을 한 노드에서 다른 노드로 라이브 마이그레이션할 수 있습니다.
그림 2.2. 2계층 토폴로지를 사용하는 사용자 정의 네트워크(UDN)
3계층 토폴로지는 클러스터의 각 노드에 대해 고유한 2계층 세그먼트를 생성합니다. 3계층 라우팅 메커니즘은 이러한 세그먼트를 상호 연결하여 서로 다른 노드에 호스팅된 가상 머신과 포드가 서로 통신할 수 있도록 합니다. 3계층 토폴로지는 각 도메인을 특정 노드에 할당하여 대규모 브로드캐스트 도메인을 효과적으로 관리할 수 있으므로 브로드캐스트 트래픽의 범위가 줄어듭니다. 3계층 토폴로지를 구성하려면 cidr
및 hostSubnet
매개변수를 구성해야 합니다.
2.1.4. ClusterUserDefinedNetwork CR에 대하여 링크 복사링크가 클립보드에 복사되었습니다!
ClusterUserDefinedNetwork
(UDN) 사용자 정의 리소스(CR)는 관리자에게만 클러스터 범위 네트워크 분할 및 격리를 제공합니다.
다음 다이어그램은 클러스터 관리자가 ClusterUserDefinedNetwork
CR을 사용하여 테넌트 간에 네트워크 격리를 생성하는 방법을 보여줍니다. 이 네트워크 구성을 사용하면 네트워크가 여러 네임스페이스에 걸쳐 확장될 수 있습니다. 다이어그램에서 네트워크 격리는 두 개의 사용자 정의 네트워크인 udn-1
과 udn-2
를 생성하여 달성됩니다. 이러한 네트워크는 연결되지 않았으며 spec.namespaceSelector.matchLabels
필드는 다른 네임스페이스를 선택하는 데 사용됩니다. 예를 들어, udn-1은
namespace-1
과 namespace-2
에 대한 통신을 구성하고 격리하는 반면, udn-2는
namespace-3
과 namespace-4
에 대한 통신을 구성하고 격리합니다. 격리된 테넌트(테넌트 1과 테넌트 2)는 네임스페이스를 분리하는 동시에 동일한 네임스페이스에 있는 포드가 통신할 수 있도록 허용하여 생성됩니다.
그림 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
레이블이 없고 포드가 생성되면, 포드는 기본 네트워크에 연결됩니다. -
네임스페이스에
k8s.ovn.org/primary-user-defined-network
레이블이 없고 네임스페이스와 일치하는 기본ClusterUserDefinedNetwork
CR이 생성되면 오류가 보고되고 네트워크가 생성되지 않습니다. -
네임스페이스에
k8s.ovn.org/primary-user-defined-network
레이블이 없고 기본ClusterUserDefinedNetwork
CR이 이미 존재하는 경우 네임스페이스에 포드가 생성되어 기본 네트워크에 연결됩니다. -
네임스페이스에 레이블이 있고 기본
ClusterUserDefinedNetwork
CR이 없는 경우ClusterUserDefinedNetwork
CR이 생성될 때까지 네임스페이스에 포드가 생성되지 않습니다.
-
네임스페이스에
ClusterUserDefinedNetwork
CR을 사용하여로컬넷
토폴로지를 생성할 때 관리자를 위한 모범 사례는 다음과 같습니다.-
CUDN CR을 생성할 때
spec.network.physicalNetworkName
매개변수가 Open vSwitch(OVS) 브리지 매핑에서 구성한 매개변수와 일치하는지 확인해야 합니다. 이렇게 하면 물리적 네트워크의 의도된 세그먼트에 브리징이 이루어집니다. 동일한 브리지 매핑을 사용하여 여러 CUDN CR을 배포하려는 경우 동일한physicalNetworkName
매개변수를 사용해야 합니다. -
물리적 네트워크와 다른 네트워크 인터페이스 사이에 서브넷이 중복되지 않도록 하세요. 중복되는 네트워크 서브넷으로 인해 라우팅 충돌과 네트워크 불안정성이 발생할 수 있습니다.
spec.network.localnet.subnets
매개변수를 사용할 때 충돌을 방지하려면spec.network.localnet.excludeSubnets
매개변수를 사용할 수 있습니다. -
VLAN(가상 LAN)을 구성할 때는 기본 물리적 인프라(스위치, 라우터 등)와 노드가 모두 VLAN ID(VID)를 허용하도록 올바르게 구성되어 있는지 확인해야 합니다. 즉, 예를 들어
eth1
과 같은 물리적 네트워크 인터페이스를 물리적 스위치를 통해 연결하는 VLAN(예:20
)에 대한 액세스 포트로 구성한다는 의미입니다. 또한, 물리적 인터페이스가 OVN-Kubernetes에 올바르게 연결되었는지 확인하려면 노드에 OVS 브리지 매핑(예:eth1
)이 있는지 확인해야 합니다.
-
CUDN CR을 생성할 때
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
및Localnet
토폴로지만 지원합니다.
사전 요구 사항
-
클러스터 관리자
권한이 있는 사용자로 로그인했습니다.
프로세스
선택 사항: 기본 네트워크를 사용하는
ClusterUserDefinedNetwork
CR의 경우 다음 명령을 입력하여k8s.ovn.org/primary-user-defined-network
레이블이 있는 네임스페이스를 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Layer2
또는Layer3
토폴로지 유형 클러스터 전체 사용자 정의 네트워크에 대한 요청을 만듭니다.다음 예와 같이
Layer2
토폴로지에 대한 요청을 정의하려면cluster-layer-two-udn.yaml
과 같은 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR의 이름입니다.- 2
- 클러스터 UDN CR이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes
MatchLabel
선택기를 사용합니다.default
또는openshift-*
네임스페이스를 가리켜서는 안 됩니다. - 3
AND
관계로 용어를 평가하는matchLabels
선택기 유형을 사용합니다.- 4 5
matchLabels
선택기 유형이 사용되므로<label_1_key>=<label_1_value>
와<label_2_key>=<label_2_value>
레이블을 모두 포함하는 네임스페이스가 제공됩니다.- 6
- 네트워크 구성을 설명합니다.
- 7
토폴로지
필드는 네트워크 구성을 설명합니다. 허용되는 값은Layer2
와Layer3
입니다.Layer2
토폴로지 유형을 지정하면 모든 노드에서 공유되는 하나의 논리적 스위치가 생성됩니다.- 8
- 이 필드는 토폴로지 구성을 지정합니다.
layer2
또는layer3
이 될 수 있습니다. - 9
기본
또는보조를
지정합니다.Primary는
4.19에서 지원되는 유일한역할
사양입니다.- 10
Layer2
토폴로지 유형의 경우 다음은서브넷
필드에 대한 구성 세부 정보를 지정합니다.- 서브넷 필드는 선택 사항입니다.
-
서브넷 필드는
문자열
유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다. -
서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은
10.100.0.0/16
및2001:db8::/64입니다
. -
Layer2
서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "고정 IP 주소로 Pod 구성"을 참조하세요.
다음 예와 같이
Layer3
토폴로지에 대한 요청을 정의하려면cluster-layer-three-udn.yaml
과 같은 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
CR의 이름입니다.- 2
- 클러스터 UDN이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes
MatchLabel
선택기를 사용합니다.default
또는openshift-*
네임스페이스를 가리켜서는 안 됩니다. - 3
OR
관계로 용어를 평가하는matchExpressions
선택기 유형을 사용합니다.- 4
- 일치시킬 레이블 키를 지정합니다.
- 5
- 연산자를 지정합니다. 유효한 값은 다음과 같습니다:
In
,NotIn
,Exists
,DoesNotExist
. - 6
matchExpressions
유형이 사용되므로<example_namespace_one>
또는<example_namespace_two>
와 일치하는 네임스페이스가 프로비저닝됩니다.- 7
- 네트워크 구성을 설명합니다.
- 8
토폴로지
필드는 네트워크 구성을 설명합니다. 허용되는 값은Layer2
와Layer3
입니다.Layer3
토폴로지 유형을 지정하면 노드당 다른 서브넷을 갖는 Layer 2 세그먼트가 생성됩니다. 3계층 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.- 9
- 이 필드는 토폴로지 구성을 지정합니다. 유효한 값은
layer2
또는layer3
입니다. - 10
기본
또는보조
역할을 지정합니다.Primary는
4.19에서 지원되는 유일한역할
사양입니다.- 11
Layer3
토폴로지 유형의 경우 다음은서브넷
필드에 대한 구성 세부 정보를 지정합니다.-
서브넷
필드는 필수입니다. 서브넷
필드의 유형은cidr
및hostSubnet
입니다.-
cidr
은 클러스터 서브넷이며 문자열 값을 허용합니다. -
hostSubnet은
클러스터 서브넷이 분할되는 노드 서브넷 접두사를 지정합니다. -
IPv6의 경우
hostSubnet
에 대해/64
길이만 지원됩니다.
-
-
다음 명령을 실행하여 요청을 적용하세요.
oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
<example_cluster_udn>.yaml은
Layer2
또는Layer3
구성 파일의 이름입니다.다음 명령을 실행하여 요청이 성공했는지 확인하세요.
oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
<cudn_name>
은 클러스터 전체 사용자 정의 네트워크에 대해 생성한 이름입니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.4.3. Localnet 토폴로지에 대한 ClusterUserDefinedNetwork CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
로컬넷
토폴로지는 보조 네트워크를 물리적 언더레이에 연결합니다. 이를 통해 동서 클러스터 트래픽과 클러스터 외부에서 실행되는 서비스에 대한 액세스가 모두 가능해집니다. 이 토폴로지 유형에는 클러스터 노드에서 기본 Open vSwitch(OVS) 시스템의 추가 구성이 필요합니다.
사전 요구 사항
-
클러스터 관리자
권한이 있는 사용자로 로그인했습니다. - OVS 브리지를 통해 논리적 OVN-Kubernetes 네트워크를 물리적 노드 네트워크와 연결하기 위해 Open vSwitch(OVS) 브리지 매핑을 만들고 구성했습니다. 자세한 내용은 "로컬넷 스위치 토폴로지 구성"을 참조하세요.
프로세스
Localnet
토폴로지를 사용하여 클러스터 전체 사용자 정의 네트워크를 만듭니다.다음 예와 같이
Localnet
토폴로지에 대한 요청을 정의하려면cluster-udn-localnet.yaml
과 같은 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterUserDefinedNetwork
(CUDN) CR의 이름입니다.- 2
- 클러스터 CUDN CR이 적용되는 네임스페이스 세트에 대한 레이블 쿼리입니다. 표준 Kubernetes
MatchLabel
선택기를 사용합니다.default
,openshift-*
또는 다른 시스템 네임스페이스를 가리켜서는 안 됩니다. - 3
AND
관계로 용어를 평가하는matchLabels
선택기 유형을 사용합니다.- 4 5
- 이 예에서 CUDN CR은
<label_1_key>=<label_1_value>
와<label_2_key>=<label_2_value>
레이블을 모두 포함하는 네임스페이스에 배포됩니다. - 6
- 네트워크 구성을 설명합니다.
- 7
Localnet
토폴로지 유형을 지정하면 하나의 공급자 네트워크에 직접 연결되는 하나의 논리적 스위치가 생성됩니다.- 8
- 이 필드는
로컬넷
토폴로지를 지정합니다. - 9
- 네트워크 구성에 대한
역할을
지정합니다.보조 역할
은로컬넷
토폴로지에 지원되는 유일한역할
사양입니다. - 10
로컬넷
토폴로지 유형의 경우 다음은서브넷
필드에 대한 구성 세부 정보를 지정합니다.- 서브넷 필드는 선택 사항입니다.
-
서브넷 필드는
문자열
유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다. -
서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 항목은 서로 다른 IP 패밀리에 속해야 합니다. 예를 들어, 서브넷 값은
10.100.0.0/16
및2001:db8::/64입니다
. -
localnet
서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 정적 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. 자세한 내용은 "고정 IP 주소로 Pod 구성"을 참조하세요.
다음 명령을 실행하여 요청을 적용하세요.
oc create --validate=true -f <example_cluster_udn>.yaml
$ oc create --validate=true -f <example_cluster_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<example_cluster_udn>.yaml
-
Localnet
구성 파일의 이름입니다.
다음 명령을 실행하여 요청이 성공했는지 확인하세요.
oc get clusteruserdefinednetwork <cudn_name> -o yaml
$ oc get clusteruserdefinednetwork <cudn_name> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<cudn_name>
- 클러스터 전체 사용자 정의 네트워크에 대해 생성한 이름입니다.
예 2.1. 출력 예
2.1.4.4. 웹 콘솔을 사용하여 ClusterUserDefinedNetwork CR 만들기 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔에서 Layer2
토폴로지를 사용하여 ClusterUserDefinedNetwork
사용자 정의 리소스(CR)를 생성할 수 있습니다.
현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3
토폴로지를 사용한 ClusterUserDefinedNetwork
CR을 생성할 수 없습니다.
사전 요구 사항
-
클러스터 관리자
권한이 있는 사용자로 OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다. -
네임스페이스를 생성하고
k8s.ovn.org/primary-user-defined-network
라벨을 적용했습니다.
프로세스
-
관리자 관점에서 네트워킹
사용자 정의 네트워크를 클릭합니다. - ClusterUserDefinedNetwork를 클릭합니다.
- 이름 필드에서 클러스터 범위 UDN의 이름을 지정합니다.
- 서브넷 필드에 값을 지정합니다.
- 프로젝트 일치 레이블 필드에서 클러스터 UDN이 적용되는 네임스페이스를 선택하기 위해 적절한 레이블을 추가합니다.
- 생성을 클릭합니다. 클러스터 범위 UDN은 5단계에서 지정한 레이블이 포함된 네임스페이스에 있는 포드의 기본 기본 네트워크 역할을 합니다.
2.1.5. UserDefinedNetwork CR에 대하여 링크 복사링크가 클립보드에 복사되었습니다!
UDN( UserDefinedNetwork
) 사용자 정의 리소스(CR)는 사용자와 관리자에게 고급 네트워크 분할 및 격리 기능을 제공합니다.
다음 다이어그램은 4개의 클러스터 네임스페이스를 보여줍니다. 각 네임스페이스에는 하나의 사용자 정의 네트워크(UDN)가 할당되어 있고, 각 UDN에는 해당 Pod IP 할당을 위한 사용자 정의 서브넷이 할당되어 있습니다. OVN-Kubernetes는 중복되는 UDN 서브넷을 처리합니다. Kubernetes 네트워크 정책을 사용하지 않으면 UDN에 연결된 포드가 해당 UDN의 다른 포드와 통신할 수 있습니다. 기본적으로 이러한 포드는 다른 UDN에 있는 포드와의 통신이 차단됩니다. 마이크로세그먼테이션의 경우 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
레이블이 없고 포드가 생성되면, 포드는 기본 네트워크에 연결됩니다. -
네임스페이스에
k8s.ovn.org/primary-user-defined-network
레이블이 없고 네임스페이스와 일치하는 기본UserDefinedNetwork
CR이 생성되면 상태 오류가 보고되고 네트워크가 생성되지 않습니다. -
네임스페이스에
k8s.ovn.org/primary-user-defined-network
레이블이 없고 기본UserDefinedNetwork
CR이 이미 존재하는 경우 네임스페이스에 포드가 생성되어 기본 네트워크에 연결됩니다. -
네임스페이스에 레이블이 있고 기본
UserDefinedNetwork
CR이 없는 경우,UserDefinedNetwork
CR이 생성될 때까지 네임스페이스에 포드가 생성되지 않습니다.
-
네임스페이스에
사용자 정의 네트워크에는 2개의 가면 IP 주소가 필요합니다. 필요한 수의 네트워크를 수용할 만큼 충분히 크게 매스커레이드 서브넷을 재구성해야 합니다.
중요-
OpenShift Container Platform 4.17 이상에서는 클러스터가 IPv4의 경우
169.254.0.0/17을
, IPv6의 경우fd69::/112를
기본 마스커레이드 서브넷으로 사용합니다. 사용자는 이러한 범위를 피해야 합니다. 업데이트된 클러스터의 경우 기본 마스커레이드 서브넷에는 변경 사항이 없습니다. -
프로젝트에 대해 사용자 정의 네트워크가 구성된 후에는 클러스터의 마스커레이드 서브넷을 변경하는 것이 지원되지 않습니다.
UserDefinedNetwork
CR이 설정된 후에 마스커레이드 서브넷을 수정하려고 하면 네트워크 연결이 중단되고 구성 문제가 발생할 수 있습니다.
-
OpenShift Container Platform 4.17 이상에서는 클러스터가 IPv4의 경우
-
테넌트가
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
예제를 사용하여 요청을 만듭니다.
특권
-
클러스터 관리자
권한으로 로그인했거나 역할 기반 액세스 제어(RBAC)를보고
편집할 수 있는
권한이 있습니다.
프로세스
선택 사항: 기본 네트워크를 사용하는
UserDefinedNetwork
CR의 경우 다음 명령을 입력하여k8s.ovn.org/primary-user-defined-network
레이블이 있는 네임스페이스를 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Layer2
또는Layer3
토폴로지 유형 사용자 정의 네트워크에 대한 요청을 만듭니다.다음 예와 같이
Layer2
토폴로지에 대한 요청을 정의하려면my-layer-two-udn.yaml
과 같은 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
리소스의 이름입니다. 이는기본값이어서
는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.- 2
토폴로지
필드는 네트워크 구성을 설명합니다. 허용되는 값은Layer2
와Layer3
입니다.Layer2
토폴로지 유형을 지정하면 모든 노드에서 공유되는 하나의 논리적 스위치가 생성됩니다.- 3
- 이 필드는 토폴로지 구성을 지정합니다.
layer2
또는layer3
이 될 수 있습니다. - 4
기본
또는보조
역할을 지정합니다.- 5
Layer2
토폴로지 유형의 경우 다음은서브넷
필드에 대한 구성 세부 정보를 지정합니다.- 서브넷 필드는 선택 사항입니다.
-
서브넷 필드는
문자열
유형이며 IPv4와 IPv6 모두에 대한 표준 CIDR 형식을 허용합니다. -
서브넷 필드에는 1개 또는 2개의 항목이 허용됩니다. 두 품목은 서로 다른 계열에 속해야 합니다. 예를 들어, 서브넷 값은
10.100.0.0/16
및2001:db8::/64입니다
. -
Layer2
서브넷은 생략될 수 있습니다. 생략하면 사용자는 포드에 대한 IP 주소를 구성해야 합니다. 결과적으로 포트 보안은 MAC 스푸핑만 방지합니다. -
ipamLifecycle
필드가 지정된 경우Layer2
서브넷
필드는 필수입니다.
다음 예와 같이
Layer3
토폴로지에 대한 요청을 정의하려면my-layer-three-udn.yaml
과 같은 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
UserDefinedNetwork
리소스의 이름입니다. 이는기본값이어서
는 안 되며 클러스터 네트워크 운영자(CNO)가 생성한 글로벌 네임스페이스와 중복되어서는 안 됩니다.- 2
토폴로지
필드는 네트워크 구성을 설명합니다. 허용되는 값은Layer2
와Layer3
입니다.Layer3
토폴로지 유형을 지정하면 노드당 다른 서브넷을 갖는 Layer 2 세그먼트가 생성됩니다. 3계층 라우팅은 노드 서브넷을 상호 연결하는 데 사용됩니다.- 3
- 이 필드는 토폴로지 구성을 지정합니다. 유효한 값은
layer2
또는layer3
입니다. - 4
기본
또는보조
역할을 지정합니다.- 5
Layer3
토폴로지 유형의 경우 다음은서브넷
필드에 대한 구성 세부 정보를 지정합니다.-
서브넷
필드는 필수입니다. 서브넷
필드의 유형은cidr
및hostSubnet
입니다.-
cidr은
클러스터의clusterNetwork
구성 설정과 동일합니다. CIDR의 IP 주소는 사용자 정의 네트워크의 포드에 배포됩니다. 이 매개변수는 문자열 값을 허용합니다. -
hostSubnet은
노드별 서브넷 접두사를 정의합니다. -
IPv6의 경우
hostSubnet
에 대해/64
길이만 지원됩니다.
-
-
다음 명령을 실행하여 요청을 적용하세요.
oc apply -f <my_layer_two_udn>.yaml
$ oc apply -f <my_layer_two_udn>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
<my_layer_two_udn>.yaml은
Layer2
또는Layer3
구성 파일의 이름입니다.다음 명령을 실행하여 요청이 성공했는지 확인하세요.
oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
$ oc get userdefinednetworks udn-1 -n <some_custom_namespace> -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 여기서
some_custom_namespace
는 사용자 정의 네트워크에 대해 생성한 네임스페이스입니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.1.5.3. 웹 콘솔을 사용하여 UserDefinedNetwork 만들기 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 Layer2
토폴로지와 기본
역할을 갖춘 UserDefinedNetwork
사용자 지정 리소스(CR)를 만들 수 있습니다.
현재 OpenShift Container Platform 웹 콘솔을 사용하는 경우 Layer3
토폴로지 또는 보조
역할이 있는 UserDefinedNetwork
CR을 생성하는 것은 지원되지 않습니다.
사전 요구 사항
-
OpenShift Container Platform 웹 콘솔에
cluster-admin
권한이 있는 사용자로 로그인합니다. -
네임스페이스를 생성하고
k8s.ovn.org/primary-user-defined-network
라벨을 적용했습니다.
프로세스
-
관리자 관점에서 네트워킹
사용자 정의 네트워크를 클릭합니다. - 사용자 정의 네트워크 만들기를 클릭합니다.
- 프로젝트 이름 목록에서 이전에 만든 네임스페이스를 선택합니다.
- 서브넷 필드에 값을 지정합니다.
- 생성을 클릭합니다. 사용자 정의 네트워크는 이 네임스페이스에서 생성하는 포드의 기본 기본 네트워크 역할을 합니다.
2.1.6. 사용자 정의 네트워크에 대한 추가 구성 세부 정보 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 선택 사항인 ClusterUserDefinedNetwork
및 UserDefinedNetwork
사용자 정의 리소스(CR)에 대한 추가 구성을 설명합니다. OVN-Kubernetes 네트워크 토폴로지에 대한 명확한 필요성과 이해가 없이 이러한 필드를 설정하는 것은 권장되지 않습니다.
- 사용자 정의 네트워크에 대한 선택적 구성
CUDN 필드 | UDN 필드 | 유형 | 설명 |
|
| object |
생략하면 플랫폼은 IPv4의 경우
|
|
| string |
|
|
| object |
Persistent 값을 설정하는 것은 |
|
| object |
활성화됨:
장애가 있는: |
|
| integer |
최대 전송 단위(MTU). 기본값은 |
| 해당 없음 | object | 이 필드는 선택 사항이며 가상 LAN(Local Area Network) 태그를 구성하고 물리적 네트워크를 여러 개의 독립적인 브로드캐스트 도메인으로 분할할 수 있습니다. |
| 해당 없음 | object |
허용되는 값은 |
| 해당 없음 | string |
물리적 네트워크 인터페이스의 이름을 지정합니다. 지정하는 값은 Open vSwitch(OVS) 브리지 매핑에서 제공한 |
다음과 같습니다.
<topology>
-
UserDefinedNetwork
CR의 경우layer2
또는layer3이
될 수 있습니다.ClusterUserDefinedNetwork
CR의 경우 토폴로지는Localnet이
될 수도 있습니다.
2.1.7. 사용자 정의 네트워크 상태 조건 유형 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 리소스를 설명할 때 ClusterUserDefinedNetwork
및 UserDefinedNetwork
CR에 대해 반환되는 상태 조건 유형을 설명합니다. 이러한 조건은 배포 문제를 해결하는 데 사용될 수 있습니다.
조건 유형 | 상태 | 이유와 메시지 | |
---|---|---|---|
|
|
| |
이유 | 메시지 | ||
| 'NetworkAttachmentDefinition이 다음 네임스페이스에 생성되었습니다: [example-namespace-1, example-namespace-2, example-namespace-3]' | ||
|
|
| |
이유 | 메시지 | ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
| ||
|
|
조건 유형 | 상태 | 이유와 메시지 | |
---|---|---|---|
|
|
| |
이유 | 메시지 | ||
|
| ||
|
|
| |
이유 | 메시지 | ||
|
|
조건 유형 | 이유, 메시지, 해결책 | ||
---|---|---|---|
|
| ||
이유 | 메시지 | 해결 | |
|
본문의 |
| |
|
본문의 |
| |
IPv6 서브넷을 사용하는 경우 |
|
사용자 정의 네트워크 구성에 IPv6 서브넷이 정의된 경우 |
조건 유형 | 이유, 메시지, 해결책 | ||
---|---|---|---|
|
| ||
이유 | 메시지 | 해결 | |
물리적 네트워크의 이름이 설정되지 않았습니다. |
|
| |
물리적 네트워크의 이름이 최소 길이 요구 사항을 충족하지 않습니다. |
| 실제 네트워크 이름은 최소 1자 이상으로 설정해야 합니다. | |
물리적 네트워크 이름이 최대 문자 수인 253자를 초과했습니다. |
| 물리적 네트워크 이름은 253자를 넘지 않도록 설정해야 합니다. | |
물리적 네트워크의 이름에는 |
|
물리적 네트워크 이름에서 |
조건 유형 | 이유, 메시지, 해결책 | ||
---|---|---|---|
|
| ||
이유 | 메시지 | 해결 | |
로컬넷 토폴로지에 대한 |
|
| |
|
|
Localnet 토폴로지의 |
조건 유형 | 이유, 메시지, 해결책 | ||
---|---|---|---|
|
| ||
이유 | 메시지 | 해결 | |
선택 필드인 |
|
| |
이 선택적 필드를 사용할 때 |
|
| |
선택적 |
|
| |
|
|
| |
CIDR 범위가 잘못되었습니다. |
|
| |
|
|
| |
|
| CIDR 범위 중 하나를 다른 IP 패밀리로 변경해야 합니다. | |
|
|
선택적 필드 |
조건 유형 | 이유, 메시지, 해결책 | ||
---|---|---|---|
|
| ||
이유 | 메시지 | 해결 | |
|
|
| |
|
|
| |
|
|
| |
|
|
| |
|
|
|
2.1.8. 사용자 정의 네트워크 포드에서 기본 네트워크 포트 열기 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 사용자 정의 네트워크(UDN)의 포드는 기본 네트워크와 격리됩니다. 즉, Prometheus 또는 Alertmanager와 같은 모니터링 서비스나 OpenShift Container Platform 이미지 레지스트리를 실행하는 기본 네트워크 포드는 UDN 포드에 대한 연결을 시작할 수 없습니다.
기본 네트워크 포드가 사용자 정의 네트워크 포드에 연결되도록 하려면 k8s.ovn.org/open-default-ports
주석을 사용하면 됩니다. 이 주석은 기본 네트워크에서 액세스할 수 있도록 사용자 정의 네트워크 포드의 특정 포트를 엽니다.
다음 Pod 사양은 기본 네트워크에서 포트 80
에서 들어오는 TCP 연결과 포트 53
에서 UDP 트래픽을 허용합니다.
열려 있는 포트는 UDN 네트워크 IP가 아닌 포드의 기본 네트워크 IP에서 접근할 수 있습니다.