OVN-Kubernetes 네트워크 플러그인
AWS 클래식 아키텍처의 Red Hat OpenShift Service에서 OVN-Kubernetes 네트워크 플러그인에 대한 심층적인 구성 및 문제 해결
초록
1장. OVN-Kubernetes 네트워크 플러그인 정보 링크 복사링크가 클립보드에 복사되었습니다!
AWS의 Red Hat OpenShift Service on AWS 클래식 아키텍처 클러스터는 Pod 및 서비스 네트워크에 가상화된 네트워크를 사용합니다.
Red Hat OpenShift Networking의 일부인 OVN-Kubernetes 네트워크 플러그인은 AWS 클래식 아키텍처에서 Red Hat OpenShift Service의 기본 네트워크 공급자입니다. OVN-Kubernetes는 OVN(Open Virtual Network)을 기반으로 하며 오버레이 기반 네트워킹 구현을 제공합니다. OVN-Kubernetes 플러그인을 사용하는 클러스터는 각 노드에서 OVS(Open vSwitch)도 실행합니다. OVN은 각 노드에서 선언된 네트워크 구성을 구현하도록 OVS를 구성합니다.
OVN-Kubernetes는 AWS 클래식 아키텍처 및 단일 노드 OpenShift 배포에서 Red Hat OpenShift Service의 기본 네트워킹 솔루션입니다.
OVS 프로젝트에서 발생한 OVN-Kubernetes는 공개 흐름 규칙과 같은 많은 동일한 구성을 사용하여 네트워크를 통해 패킷을 이동하는 방법을 결정합니다. 자세한 내용은 Open Virtual Network 웹 사이트를 참조하십시오.
OVN-Kubernetes는 가상 네트워크 구성을 OpenFlow 규칙으로 변환하는 OVS의 일련의 데몬입니다. OpenFlow 는 네트워크 스위치 및 라우터와 통신하기 위한 프로토콜로, 네트워크 장치에서 네트워크 트래픽의 흐름을 원격으로 제어하는 수단을 제공합니다. 즉, 네트워크 관리자는 네트워크 트래픽의 흐름을 구성, 관리 및 조사할 수 있습니다.
OVN-Kubernetes는 OpenFlow 에서 사용할 수 없는 고급 기능을 더 많이 제공합니다. OVN은 분산 가상 라우팅, 분산 논리 스위치, 액세스 제어, DHCP(Dynamic Host Configuration Protocol) 및 DNS를 지원합니다. OVN은 흐름을 여는 논리 흐름 내에서 분산 가상 라우팅을 구현합니다. 예를 들어 네트워크의 DHCP 요청을 네트워크의 DHCP 서버로 보내는 Pod가 있는 경우 요청의 논리 흐름 규칙은 OVN-Kubernetes가 패킷을 처리하는 데 도움이 됩니다. 즉, 서버는 게이트웨이, DNS 서버, IP 주소 및 기타 정보로 응답할 수 있습니다.
OVN-Kubernetes는 각 노드에서 데몬을 실행합니다. 데이터베이스와 모든 노드에서 실행되는 OVN 컨트롤러에 대한 데몬 세트가 있습니다. OVN 컨트롤러는 다음 네트워크 공급자 기능을 지원하기 위해 노드에서 Open vSwitch 데몬을 프로그래밍합니다.
- 송신 IP
- 방화벽
- 하드웨어 오프로드
- 하이브리드 네트워킹
- IPsec(Internet Protocol Security) 암호화
- IPv6
- 멀티 캐스트.
- 네트워크 정책 및 네트워크 정책 로그
- 라우터
1.1. OVN-Kubernetes 용도 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 네트워크 플러그인은 OVN(Open Virtual Network)을 사용하여 네트워크 트래픽 흐름을 관리하는 오픈 소스 완전한 기능을 갖춘 Kubernetes CNI 플러그인입니다. OVN은 커뮤니티에서 개발한 벤더와 무관한 네트워크 가상화 솔루션입니다. OVN-Kubernetes 네트워크 플러그인은 다음 기술을 사용합니다.
- OVN을 사용하여 네트워크 트래픽 흐름을 관리합니다.
- 수신 및 송신 규칙을 포함한 Kubernetes 네트워크 정책 지원 및 로그.
- VXLAN(Virtual Extensible LAN)이 아닌 일반 네트워크 가상화 캡슐화(Geneve) 프로토콜을 사용하여 노드 간에 오버레이 네트워크를 생성합니다.
OVN-Kubernetes 네트워크 플러그인은 다음 기능을 지원합니다.
- Linux 및 Microsoft Windows 워크로드를 모두 실행할 수 있는 하이브리드 클러스터입니다. 이 환경을 하이브리드 네트워킹 이라고 합니다.
- 호스트 CPU(중앙 처리 장치)에서 호환 가능한 네트워크 카드 및 DPDK(데이터 처리 장치)로 네트워크 데이터 처리 오프로드. 이를 하드웨어 오프로드 라고 합니다.
- 베어 메탈, VMware vSphere, IBM Power®, IBM Z® 및 RHOSP(Red Hat OpenStack Platform) 플랫폼에서 IPv4-primary 듀얼 스택 네트워킹.
- RHOSP 및 베어 메탈 플랫폼의 IPv6 단일 스택 네트워킹.
- 베어 메탈, VMware vSphere 또는 RHOSP 플랫폼에서 실행되는 클러스터의 IPv6-primary 듀얼 스택 네트워킹.
- 송신 방화벽 장치 및 송신 IP 주소입니다.
- 리디렉션 모드에서 작동하는 송신 라우터 장치입니다.
- 클러스터 내 통신의 IPsec 암호화
Red Hat은 OVN-Kubernetes 네트워크 플러그인을 사용하는 다음 설치 후 구성을 지원하지 않습니다.
- NMState Operator를 사용하여 인터페이스 본딩을 구성하는 등 기본 네트워크 인터페이스를 구성합니다.
-
OVS(Open vSwitch) 또는 OVN-Kubernetes
br-ex브리지 네트워크를 사용하는 네트워크 장치에서 하위 인터페이스 또는 추가 네트워크 인터페이스 구성. - 기본 네트워크 인터페이스에서 추가 VLAN(가상 로컬 영역 네트워크) 생성.
-
클러스터 설치 중에 노드에 대해 생성한 기본 네트워크 인터페이스(예:
eth0또는bond0)를 사용하여 추가 보조 네트워크를 생성합니다.
Red Hat은 OVN-Kubernetes 네트워크 플러그인을 사용하는 다음 설치 후 구성을 지원합니다.
-
클러스터 설치 중에 노드의 기본 네트워크 인터페이스를 VLAN으로 구성하는
eth0.100과 같은 기본 물리적 인터페이스에서 추가 VLAN을 생성합니다. OVS(Open vSwitch) 브리지는eth0.100과 같은 초기 VLAN 하위 인터페이스에 연결하여 새 구성에 기본 물리적 인터페이스를 사용할 수 있기 때문에 작동합니다. -
localnet토폴로지 네트워크를 사용하여 추가 OVN 보조 네트워크를 생성하려면NNCP(NodeNetworkConfigurationPolicy) 오브젝트에서 보조 네트워크를 정의해야 합니다. 네트워크를 생성한 후 Pod 또는 VM(가상 머신)이 네트워크에 연결할 수 있습니다. 이러한 보조 네트워크는 VLAN 태그 지정을 사용하거나 사용하지 않을 수 있는 물리적 네트워크에 전용 연결을 제공합니다. 호스트에 필요한 네트워크 설정과 같은 필수 설정이 없는 노드의 호스트 네트워크에서 이러한 네트워크에 액세스할 수 없습니다.
1.2. OVN-Kubernetes IPv6 및 듀얼 스택 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 네트워크 플러그인에는 다음과 같은 제한 사항이 있습니다.
듀얼 스택 네트워킹을 위해 구성된 클러스터의 경우 IPv4 및 IPv6 트래픽 모두 기본 게이트웨이와 동일한 네트워크 인터페이스를 사용해야 합니다.
이 요구 사항이 충족되지 않으면
ovnkube-node데몬 세트의 호스트의 Pod가CrashLoopBackOff상태가 됩니다.oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml과 같은 명령으로 Pod를 표시하는 경우status필드에 다음 출력에 표시된 대로 기본 게이트웨이에 대한 메시지가 두 개 이상 있습니다.I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4
I1006 16:09:50.985852 60651 helper_linux.go:73] Found default gateway interface br-ex 192.168.127.1 I1006 16:09:50.985923 60651 helper_linux.go:73] Found default gateway interface ens4 fe80::5054:ff:febe:bcd4 F1006 16:09:50.985939 60651 ovnkube.go:130] multiple gateway interfaces detected: br-ex ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 유일한 해결 방법은 두 IP 제품군이 기본 게이트웨이에 동일한 네트워크 인터페이스를 사용하도록 호스트 네트워킹을 재구성하는 것입니다.
듀얼 스택 네트워킹을 위해 구성된 클러스터의 경우 IPv4 및 IPv6 라우팅 테이블 모두 기본 게이트웨이를 포함해야 합니다.
이 요구 사항이 충족되지 않으면
ovnkube-node데몬 세트의 호스트의 Pod가CrashLoopBackOff상태가 됩니다.oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml과 같은 명령으로 Pod를 표시하는 경우status필드에 다음 출력에 표시된 대로 기본 게이트웨이에 대한 메시지가 두 개 이상 있습니다.I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interface
I0512 19:07:17.589083 108432 helper_linux.go:74] Found default gateway interface br-ex 192.168.123.1 F0512 19:07:17.589141 108432 ovnkube.go:133] failed to get default gateway interfaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 유일한 해결 방법은 두 IP 제품군에 기본 게이트웨이가 포함되도록 호스트 네트워킹을 재구성하는 것입니다.
-
MachineConfigCR(사용자 정의 리소스)의kernelArgument섹션에서ipv6.disable매개변수를1로 설정하면 OVN-Kubernetes Pod가CrashLoopBackOff상태가 됩니다. 또한 Network Operator가Degraded상태에 있기 때문에 클러스터를 최신 버전의 AWS 클래식 아키텍처로 업데이트할 수 없습니다. Red Hat은 클러스터의 IPv6 adddresses 비활성화를 지원하지 않으므로ipv6.disable매개변수를1로 설정하지 마십시오.
1.3. 세션 선호도 링크 복사링크가 클립보드에 복사되었습니다!
세션 선호도는 Kubernetes Service 오브젝트에 적용되는 기능입니다. <service_VIP>:<Port>에 연결할 때마다 트래픽이 항상 동일한 백엔드에 분산되도록 하려면 세션 선호도를 사용할 수 있습니다. 클라이언트의 IP 주소를 기반으로 세션 선호도를 설정하는 방법을 포함한 자세한 내용은 세션 선호도를 참조하십시오.
1.3.1. 세션 선호도에 대한 고정 시간 제한 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처에서 Red Hat OpenShift Service용 OVN-Kubernetes 네트워크 플러그인은 마지막 패킷을 기반으로 클라이언트에서 세션의 고정 시간 초과를 계산합니다. 예를 들어 curl 명령을 10번 실행하면 고정 세션 타이머가 첫 번째 패킷이 아닌 10번째 패킷에서 시작됩니다. 결과적으로 클라이언트가 지속적으로 서비스에 문의하는 경우 세션이 시간 초과되지 않습니다. 서비스가 timeoutSeconds 매개변수에 설정된 시간 양에 대한 패킷을 수신하지 않으면 시간 초과가 시작됩니다.
2장. 송신 IP 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OVN-Kubernetes CNI(Container Network Interface) 네트워크 플러그인을 구성하여 하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.
2.1. 송신 IP 주소 아키텍처 설계 및 구현 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 송신 IP 주소 기능에서 Red Hat OpenShift Service를 사용하면 하나 이상의 네임스페이스에서 하나 이상의 Pod의 트래픽이 클러스터 네트워크 외부의 서비스에 대한 소스 IP 주소가 일관되게 유지되도록 할 수 있습니다.
예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.
네임스페이스에 할당된 송신 IP 주소는 특정 대상으로 트래픽을 보내는 데 사용되는 송신 라우터와 다릅니다.
HCP 클러스터가 있는 ROSA에서 애플리케이션 pod 및 Ingress 라우터 Pod는 동일한 노드에서 실행됩니다. 이 시나리오에서 애플리케이션 프로젝트에 대한 송신 IP 주소를 구성하는 경우 애플리케이션 프로젝트의 경로에 요청을 보낼 때 IP 주소가 사용되지 않습니다.
EgressIP 기능이 있는 컨트롤 플레인 노드에 대한 송신 IP 주소 할당은 지원되지 않습니다.
다음 예제에서는 여러 퍼블릭 클라우드 공급자의 노드의 주석을 보여줍니다. 가독성을 위해 주석을 들여쓰기합니다.
AWS의 cloud.network.openshift.io/egress-ipconfig 주석의 예
다음 섹션에서는 용량 계산에 사용할 지원되는 퍼블릭 클라우드 환경의 IP 주소 용량에 대해 설명합니다.
2.1.1. AWS(Amazon Web Services) IP 주소 용량 제한 링크 복사링크가 클립보드에 복사되었습니다!
AWS에서 IP 주소 할당에 대한 제약 조건은 구성된 인스턴스 유형에 따라 다릅니다. 자세한 내용은 인스턴스 유형당 네트워크 인터페이스당 IP 주소를참조하십시오.
2.1.2. 송신 IP 주소 구성에 대한 아키텍처 다이어그램 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램에서는 송신 IP 주소 구성을 보여줍니다. 다이어그램은 클러스터의 세 개 노드에서 실행 중인 두 개의 다른 네임스페이스에 있는 포드 4개를 설명합니다. 노드는 호스트 네트워크의 192.168.126.0/18 CIDR 블록에서 할당된 IP 주소입니다.
노드 1과 노드 3은 모두 k8s.ovn.org/egress-assignable: ""로 레이블이 지정되어 있으므로 송신 IP 주소 할당에 사용할 수 있습니다.
다이어그램에 있는 점선은 노드 1 및 노드 3에서 클러스터를 나가기 위해 포드 네트워크를 통해 이동하는 pod1, pod2, pod3의 트래픽 흐름을 나타냅니다. 외부 서비스에서 예제의 EgressIP 오브젝트에서 선택한 Pod 중 하나에서 트래픽을 수신하는 경우 소스 IP 주소는 192.168.126.10 또는 192.168.126.102입니다. 트래픽은 이 두 노드 간에 대략적으로 균등하게 분산됩니다.
다이어그램에 따라 다음 매니페스트 파일은 네임스페이스를 정의합니다.
네임스페이스 오브젝트
다음 EgressIP 오브젝트는 다이어그램에 따라 env 레이블이 prod 로 설정된 모든 포드를 선택하는 구성을 설명합니다. 선택한 포드의 송신 IP 주소는 192.168.126.10 및 192.168.126.102입니다.
EgressIP 오브젝트
이전 예제의 구성에 대해 AWS 클래식 아키텍처의 Red Hat OpenShift Service는 두 송신 IP 주소를 사용 가능한 노드에 할당합니다. status 필드는 송신 IP 주소가 할당되었는지 여부와 위치를 반영합니다.
2.2. EgressIP 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
다음 YAML 파일을 보고 요구 사항에 맞게 EgressIP 오브젝트를 효과적으로 구성하는 방법을 파악합니다.
다음 YAML에서는 EgressIP 오브젝트의 API를 설명합니다. 오브젝트의 범위는 클러스터 전체이며 네임스페이스에 생성되지 않습니다.
다음과 같습니다.
<name>-
EgressIPs오브젝트의 이름입니다. <egressIPs>- 하나 이상의 IP 주소로 이루어진 배열입니다.
<namespaceSelector>- 송신 IP 주소를 연결할 네임스페이스에 대해 하나 이상의 선택기입니다.
<podSelector>- 선택적 매개변수입니다. 지정된 네임스페이스에서 송신 IP 주소를 연결할 Pod에 대해 하나 이상의 선택기입니다. 이러한 선택기를 적용하면 네임스페이스 내에서 Pod 하위 집합을 선택할 수 있습니다.
다음 YAML은 네임스페이스 선택기에 대한 스탠자를 설명합니다.
네임스페이스 선택기 스탠자
namespaceSelector:
matchLabels:
<label_name>: <label_value>
namespaceSelector:
matchLabels:
<label_name>: <label_value>
다음과 같습니다.
<namespaceSelector>- 네임스페이스에 대해 일치하는 하나 이상의 규칙입니다. 둘 이상의 일치 규칙이 제공되면 일치하는 모든 네임스페이스가 선택됩니다.
다음 YAML은 Pod 선택기에 대한 선택적 스탠자를 설명합니다.
Pod 선택기 스탠자
podSelector:
matchLabels:
<label_name>: <label_value>
podSelector:
matchLabels:
<label_name>: <label_value>
다음과 같습니다.
<podSelector>-
선택적 매개변수입니다. 지정된
namespaceSelector규칙과 일치하는 네임스페이스의 Pod에 대해 일치하는 하나 이상의 규칙입니다. 지정된 경우 일치하는 Pod만 선택됩니다. 네임스페이스의 다른 Pod는 선택되지 않습니다.
다음 예에서 EgressIP 오브젝트는 192.168.126.11 및 192.168.126.102 송신 IP 주소를 app 라벨을 web으로 설정하고 env 라벨을 prod로 설정한 네임스페이스에 있는 포드와 연결합니다.
EgressIP 오브젝트의 예
다음 예에서 EgressIP 오브젝트는 192.168.127.30 및 192.168.127.40 송신 IP 주소를 environment 레이블이 development로 설정되지 않은 모든 Pod와 연결합니다.
EgressIP 오브젝트의 예
2.3. 네임스페이스, 노드 및 Pod에 송신 IP 할당 링크 복사링크가 클립보드에 복사되었습니다!
하나 이상의 송신 IP를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당하려면 다음 조건을 충족해야 합니다.
-
클러스터에서 하나 이상의 노드에
k8s.ovn.org/egress-assignable: ""레이블이 있어야 합니다. -
네임스페이스의 Pod에서 클러스터를 떠나는 트래픽의 소스 IP 주소로 사용할 하나 이상의 송신 IP 주소를 정의하는
EgressIP오브젝트가 있습니다.
송신 IP 할당을 위해 클러스터의 노드에 레이블을 지정하기 전에 EgressIP 오브젝트를 생성하는 경우 AWS 클래식 아키텍처의 Red Hat OpenShift Service는 k8s.ovn.org/egress-assignable: "" 레이블이 있는 첫 번째 노드에 모든 송신 IP 주소를 할당할 수 있습니다.
송신 IP 주소가 클러스터의 여러 노드에 널리 분산되도록 하려면 EgressIP 오브젝트를 만들기 전에 송신 IP 주소를 호스팅할 노드에 항상 레이블을 적용하십시오.
EgressIP 오브젝트를 생성할 때 k8s.ovn.org/egress-assignable: "" 레이블이 지정된 노드에 다음 조건이 적용됩니다.
- 송신 IP 주소는 한 번에 두 개 이상의 노드에 할당되지 않습니다.
- 송신 IP 주소는 송신 IP 주소를 호스팅할 수 있는 사용 가용한 노드 간에 균형을 이룹니다.
EgressIP오브젝트의spec.EgressIPs배열에서 둘 이상의 IP 주소를 지정하는 경우 다음 조건이 적용됩니다.- 지정된 IP 주소 중 두 개 이상을 호스팅할 노드는 없습니다.
- 지정된 네임스페이스에 대해 지정된 IP 주소 간에 트래픽이 거의 동일하게 분산됩니다.
- 노드를 사용할 수 없게 되면 할당된 모든 송신 IP 주소가 이전에 설명한 조건에 따라 자동으로 재할당됩니다.
Pod가 여러 EgressIP 오브젝트의 선택기와 일치하는 경우 EgressIP 오브젝트에 지정된 송신 IP 주소 중 어느 것이 Pod의 송신 IP 주소로 할당되는지 보장할 수 없습니다.
또한 EgressIP 오브젝트가 여러 송신 IP 주소를 지정하는 경우 송신 IP 주소 중 사용할 수 있는 보장이 없습니다. 예를 들어 Pod가 두 개의 송신 IP 주소 10.10.20.1 및 10.10.20.2 가 있는 EgressIP 오브젝트의 선택기와 일치하는 경우 각 TCP 연결 또는 UDP 대화에 사용할 수 있습니다.
2.4. 네임스페이스에 송신 IP 주소 할당 링크 복사링크가 클립보드에 복사되었습니다!
하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. - 클러스터 관리자로 클러스터에 로그인합니다.
- 송신 IP 주소를 호스팅할 하나 이상의 노드를 구성합니다.
프로세스
EgressIP오브젝트를 생성합니다.-
<egressips_name>.yaml파일을 만듭니다. 여기서<egressips_name>은 오브젝트 이름입니다. 생성한 파일에서 다음 예와 같이
EgressIP오브젝트를 정의합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
오브젝트를 생성하려면 다음 명령을 입력합니다.
oc apply -f <egressips_name>.yaml
$ oc apply -f <egressips_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<egressips_name>-
<egressips_name>을 오브젝트 이름으로 변경합니다.
출력 예
egressips.k8s.ovn.org/<egressips_name> created
egressips.k8s.ovn.org/<egressips_name> createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
선택 사항: 나중에 변경할 수 있도록 <
egressips_name>.yaml파일을 저장합니다. 송신 IP 주소가 필요한 네임스페이스에 라벨을 추가합니다. 1단계에서 정의된
EgressIP오브젝트의 네임스페이스에 라벨을 추가하려면 다음 명령을 실행합니다.oc label ns <namespace> env=qa
$ oc label ns <namespace> env=qaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<namespace>-
&
lt;namespace>를 송신 IP 주소가 필요한 네임스페이스로 바꿉니다.
검증
클러스터에서 사용 중인 모든 송신 IP 주소를 표시하려면 다음 명령을 입력합니다.
oc get egressip -o yaml
$ oc get egressip -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고oc get egressip명령은 구성된 수에 관계없이 하나의 송신 IP 주소만 반환합니다. 이는 버그가 아니며 Kubernetes의 제한 사항입니다. 이 문제를 해결하려면-o yaml또는-o json플래그를 전달하여 사용 중인 모든 송신 IP 주소를 반환할 수 있습니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.5. 송신 IP 주소 호스팅을 위해 노드에 레이블 지정 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처의 Red Hat OpenShift Service가 노드에 하나 이상의 송신 IP 주소를 할당할 수 있도록 k8s.ovn.org/egress-assignable="" 레이블을 클러스터의 노드에 적용할 수 있습니다.
사전 요구 사항
-
ROSA CLI(
rosa)를 설치합니다. - 클러스터 관리자로 클러스터에 로그인합니다.
프로세스
하나 이상의 송신 IP 주소를 호스팅할 수 있도록 노드에 레이블을 지정하려면 다음 명령을 입력합니다.
rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="
$ rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요이 명령은 machinepool의 모든 흥미로운 노드 레이블을 대체합니다. 기존 노드 레이블이 유지되도록
--labels필드에 원하는 라벨을 포함해야 합니다.
3장. OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 클러스터 관리자의 Red Hat OpenShift Service는 OpenShift SDN 네트워크 플러그인에서 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션을 시작하고 ROSA CLI를 사용하여 마이그레이션 상태를 확인할 수 있습니다.
마이그레이션 시작 전에 고려해야 할 몇 가지 사항은 다음과 같습니다.
- 클러스터 버전은 4.16.43 이상이어야 합니다.
- 마이그레이션 프로세스를 중단할 수 없습니다.
- SDN 네트워크 플러그인으로 다시 마이그레이션하는 것은 불가능합니다.
- 마이그레이션 중에 클러스터 노드가 재부팅됩니다.
- 노드 중단에 탄력적인 워크로드에는 영향을 미치지 않습니다.
- 마이그레이션 시간은 클러스터 크기 및 워크로드 구성에 따라 몇 분과 시간마다 다를 수 있습니다.
3.1. ROSA CLI를 사용하여 마이그레이션 시작 링크 복사링크가 클립보드에 복사되었습니다!
버전 4.16.43 이상인 클러스터에서만 마이그레이션을 시작할 수 있습니다.
마이그레이션을 시작하려면 다음 명령을 실행합니다.
rosa edit cluster -c <cluster_id>
$ rosa edit cluster -c <cluster_id>
--network-type OVNKubernetes
--ovn-internal-subnets <configuration>
--network-type 플래그의 값을 정의하지 않으면 명령에 선택적 플래그 --ovn-internal-subnets 를 포함할 수 없습니다.
검증
마이그레이션 상태를 확인하려면 다음 명령을 실행합니다.
rosa describe cluster -c <cluster_id>
$ rosa describe cluster -c <cluster_id>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 마이그레이션 상태를 확인하려면 <
;cluster_id>를 클러스터 ID로 바꿉니다.
4장. 클러스터 전체 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
기존 VPC(Virtual Private Cloud)를 사용하는 경우 AWS 클래식 아키텍처 클러스터 설치 또는 클러스터가 설치된 후 Red Hat OpenShift Service 동안 클러스터 전체 프록시를 구성할 수 있습니다. 프록시를 활성화하면 핵심 클러스터 구성 요소가 인터넷에 대한 직접 액세스가 거부되지만 프록시는 사용자 워크로드에 영향을 미치지 않습니다.
클라우드 공급자 API에 대한 호출을 포함하여 클러스터 시스템 송신 트래픽만 프록시됩니다.
클러스터 전체 프록시를 사용하는 경우 클러스터의 프록시 가용성을 유지 관리해야 합니다. 프록시를 사용할 수 없게 되면 클러스터의 상태 및 지원 가능성에 영향을 미칠 수 있습니다.
4.1. 클러스터 전체 프록시 구성을 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 전체 프록시를 구성하려면 다음 요구 사항을 충족해야 합니다. 이러한 요구 사항은 설치 중 또는 설치 후 프록시를 구성할 때 유효합니다.
4.1.1. 일반 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 클러스터 소유자입니다.
- 계정에는 충분한 권한이 있습니다.
- 클러스터에 대한 기존 VPC(Virtual Private Cloud)가 있습니다.
- 프록시는 클러스터의 VPC 및 VPC의 프라이빗 서브넷에 액세스할 수 있습니다. 클러스터의 VPC와 VPC의 프라이빗 서브넷에서도 프록시에 액세스할 수 있어야 합니다.
VPC 끝점에 다음 끝점을 추가했습니다.
-
ec2.<aws_region>.amazonaws.com -
elasticloadbalancing.<aws_region>.amazonaws.com s3.<aws_region>.amazonaws.com이러한 끝점은 노드에서 AWS EC2 API로 요청을 완료하는 데 필요합니다. 프록시는 노드 수준이 아닌 컨테이너 수준에서 작동하므로 이러한 요청을 AWS 프라이빗 네트워크를 통해 AWS EC2 API로 라우팅해야 합니다. 프록시 서버의 허용 목록에 EC2 API의 공용 IP 주소를 추가하는 것만으로는 충분하지 않습니다.
중요클러스터 전체 프록시를 사용하는 경우
게이트웨이유형으로s3.<aws_region>.amazonaws.com끝점을 구성해야 합니다.
-
4.1.2. 네트워크 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
프록시에서 송신 트래픽을 다시 암호화하는 경우 OpenShift에 필요한 여러 도메인 및 포트 조합에 대한 제외를 생성해야 합니다.
프록시는 다음 OpenShift URL을 다시 암호화하도록 제외해야 합니다.
| address | protocol/Port | 함수 |
|---|---|---|
|
| https/443 | 필수 항목입니다. Managed OpenShift 관련 Telemetry에 사용됩니다. |
|
| https/443 |
https://console.redhat.com/openshift 사이트에서는 |
4.2. 추가 신뢰 번들의 역할 링크 복사링크가 클립보드에 복사되었습니다!
추가 신뢰 번들을 제공하는 경우 다음 요구 사항을 담당합니다.
- 추가 신뢰 번들의 콘텐츠가 유효한지 확인
- 추가 신뢰 번들에 포함된 중간 인증서를 포함한 인증서가 만료되지 않았는지 확인
- 추가 신뢰 번들에 포함된 인증서에 대해 만료 추적 및 필요한 갱신 수행
- 업데이트된 추가 신뢰 번들을 사용하여 클러스터 구성 업데이트
4.3. 설치 중 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service를 기존 VPC(Virtual Private Cloud)에 설치할 때 HTTP 또는 HTTPS 프록시를 구성할 수 있습니다. Red Hat OpenShift Cluster Manager 또는 ROSA CLI(rosa)를 사용하여 설치 중에 프록시를 구성할 수 있습니다.
4.3.1. OpenShift Cluster Manager를 사용하여 설치 중 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service를 기존 VPC(Virtual Private Cloud)에 설치하는 경우 Red Hat OpenShift Cluster Manager를 사용하여 설치 중에 클러스터 전체 HTTP 또는 HTTPS 프록시를 활성화할 수 있습니다.
설치하기 전에 VPC에서 클러스터를 설치할 때 프록시에 액세스할 수 있는지 확인해야 합니다. VPC의 프라이빗 서브넷에서도 프록시에 액세스할 수 있어야 합니다.
OpenShift Cluster Manager를 사용하여 설치 중에 클러스터 전체 프록시를 구성하는 자세한 단계는 OpenShift Cluster Manager 를 사용하여 사용자 지정으로 클러스터 생성 을 참조하십시오.
4.3.2. CLI를 사용하여 설치 중 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service를 기존 VPC(Virtual Private Cloud)에 설치하는 경우 ROSA CLI(rosa)를 사용하여 설치 중에 클러스터 전체 HTTP 또는 HTTPS 프록시를 활성화할 수 있습니다.
다음 절차에서는 설치 중에 클러스터 전체 프록시를 구성하는 데 사용되는 ROSA CLI(rosa) 인수에 대한 세부 정보를 제공합니다.
ROSA CLI를 사용하는 일반적인 설치 단계는 CLI를 사용하여 사용자 지정으로 클러스터 생성을 참조하십시오.
사전 요구 사항
- VPC에서 클러스터가 설치 중인지 프록시에 액세스할 수 있는지 확인했습니다. VPC의 프라이빗 서브넷에서도 프록시에 액세스할 수 있어야 합니다.
프로세스
클러스터를 생성할 때 프록시 구성을 지정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 4 6
additional-trust-bundle-file,http-proxy및https-proxy인수는 모두 선택 사항입니다.- 2
additional-trust-bundle-file인수는 모두 함께 연결된 PEM 인코딩 X.509 인증서 번들을 가리키는 파일 경로입니다. 프록시의 ID 인증서를 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들의 기관에서 서명하지 않는 한 TLS-inspecting 프록시를 사용하는 사용자에게는 additional-trust-bundle-file 인수가 필요합니다. 이는 프록시가 투명하든 http-proxy 및 https-proxy 인수를 사용하여 명시적 구성이 필요한지 여부와 관계없이 적용됩니다.- 3 5 7
http-proxy및https-proxy인수는 유효한 URL을 가리켜야 합니다.- 8
- 프록시를 제외할 대상 도메인 이름, IP 주소 또는 네트워크 CIDR의 쉼표로 구분된 목록입니다.
하위 도메인과 일치하려면 도메인 앞에
.을 입력합니다. 예를 들어,.y.com은x.y.com과 일치하지만y.com은 일치하지 않습니다.*를 사용하여 모든 대상에 대해 프록시를 바이패스합니다.networking.machineNetwork[].cidr필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.httpProxy와httpsProxy필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.
4.4. 설치 후 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service를 기존 VPC(Virtual Private Cloud)에 설치한 후 HTTP 또는 HTTPS 프록시를 구성할 수 있습니다. Red Hat OpenShift Cluster Manager 또는 ROSA CLI(rosa)를 사용하여 설치 후 프록시를 구성할 수 있습니다.
4.4.1. OpenShift Cluster Manager를 사용하여 설치 후 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift Cluster Manager를 사용하여 VPC(Virtual Private Cloud)의 기존 Red Hat OpenShift Service에 클러스터 전체 프록시 구성을 추가할 수 있습니다.
OpenShift Cluster Manager를 사용하여 기존 클러스터 전체 프록시 구성을 업데이트할 수도 있습니다. 예를 들어 프록시의 네트워크 주소를 업데이트하거나 프록시의 인증 기관이 만료되는 경우 추가 신뢰 번들을 교체해야 할 수 있습니다.
클러스터는 컨트롤 플레인 및 컴퓨팅 노드에 프록시 구성을 적용합니다. 구성을 적용하는 동안 각 클러스터 노드는 예약할 수 없는 상태로 임시로 배치되고 워크로드가 드레이닝됩니다. 각 노드는 프로세스의 일부로 다시 시작됩니다.
사전 요구 사항
- AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service가 있습니다.
- 클러스터가 VPC에 배포됩니다.
프로세스
- OpenShift Cluster Manager 로 이동하여 클러스터를 선택합니다.
- 네트워킹 페이지의 VPC(Virtual Private Cloud) 섹션의 Edit cluster-wide proxy 를 클릭합니다.
클러스터 전체 프록시 편집 페이지에서 프록시 설정 세부 정보를 제공합니다.
다음 필드 중 하나 이상에 값을 입력합니다.
- 유효한 HTTP 프록시 URL 을 지정합니다.
- 유효한 HTTPS 프록시 URL 을 지정합니다.
additional trust bundle 필드에 PEM 인코딩 X.509 인증서 번들을 제공합니다.
기존 신뢰 번들 파일을 교체하는 경우 파일 교체를 선택하여 필드를 확인합니다. 번들이 클러스터 노드의 신뢰할 수 있는 인증서 저장소에 추가됩니다. 프록시의 ID 인증서가 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들의 기관에서 서명되지 않는 한 TLS 지정 프록시를 사용하는 경우 추가 신뢰 번들 파일이 필요합니다. 이 요구 사항은 프록시가 투명했는지 또는
http-proxy인수 및https-proxy인수를 사용하여 명시적 구성이 필요한지 여부와 관계없이 적용됩니다.
- 확인을 클릭합니다.
검증
- 네트워킹 페이지의 VPC(Virtual Private Cloud) 섹션에서 클러스터의 프록시 구성이 예상대로 있는지 확인합니다.
4.4.2. CLI를 사용하여 설치 후 프록시 구성 링크 복사링크가 클립보드에 복사되었습니다!
ROSA CLI(rosa)를 사용하여 VPC(Virtual Private Cloud)의 기존 ROSA 클러스터에 클러스터 전체 프록시 구성을 추가할 수 있습니다.
rosa 를 사용하여 기존 클러스터 전체 프록시 구성을 업데이트할 수도 있습니다. 예를 들어 프록시의 네트워크 주소를 업데이트하거나 프록시의 인증 기관이 만료되는 경우 추가 신뢰 번들을 교체해야 할 수 있습니다.
클러스터는 컨트롤 플레인 및 컴퓨팅 노드에 프록시 구성을 적용합니다. 구성을 적용하는 동안 각 클러스터 노드는 예약할 수 없는 상태로 임시로 배치되고 워크로드가 드레이닝됩니다. 각 노드는 프로세스의 일부로 다시 시작됩니다.
사전 요구 사항
-
설치 호스트에 최신 ROSA(
rosa) 및 OpenShift(oc) CLI를 설치하고 구성했습니다. - VPC에 배포된 AWS 클래식 아키텍처 클러스터에 Red Hat OpenShift Service가 있습니다.
프로세스
클러스터 구성을 편집하여 클러스터 전체 프록시 세부 정보를 추가하거나 업데이트합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 4 6
additional-trust-bundle-file,http-proxy및https-proxy인수는 모두 선택 사항입니다.- 2
additional-trust-bundle-file인수는 모두 함께 연결된 PEM 인코딩 X.509 인증서 번들을 가리키는 파일 경로입니다. additional-trust-bundle-file 인수는 모두 함께 연결된 PEM 인코딩 X.509 인증서 번들을 가리키는 파일 경로입니다. 프록시의 ID 인증서를 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들의 기관에서 서명하지 않는 한 TLS-inspecting 프록시를 사용하는 사용자에게는 additional-trust-bundle-file 인수가 필요합니다. 이는 프록시가 투명하든http-proxy및https-proxy인수를 사용하여 명시적 구성이 필요한지 여부와 관계없이 적용됩니다.중요클러스터의 프록시 또는 추가 신뢰 번들 구성을 직접 변경하지 마십시오. 모든 변경 사항은 ROSA CLI(
rosa) 또는 Red Hat OpenShift Cluster Manager를 사용하여 적용해야 합니다. 클러스터의 관리 리소스에 직접 변경한 내용은 자동으로 되돌아갑니다.- 3 5 7
http-proxy및https-proxy인수는 유효한 URL을 가리켜야 합니다.- 8
- 프록시를 제외할 대상 도메인 이름, IP 주소 또는 네트워크 CIDR의 쉼표로 구분된 목록입니다.
하위 도메인과 일치하려면 도메인 앞에
.을 입력합니다. 예를 들어,.y.com은x.y.com과 일치하지만y.com은 일치하지 않습니다.*를 사용하여 모든 대상에 대해 프록시를 바이패스합니다.networking.machineNetwork[].cidr필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.httpProxy와httpsProxy필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.
검증
머신 구성 풀의 상태를 나열하고 업데이트되었는지 확인합니다.
oc get machineconfigpools
$ oc get machineconfigpoolsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-d9a03f612a432095dcde6dcf44597d90 True False False 3 3 3 0 31h worker rendered-worker-f6827a4efe21e155c25c21b43c46f65e True False False 6 6 6 0 31h
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-d9a03f612a432095dcde6dcf44597d90 True False False 3 3 3 0 31h worker rendered-worker-f6827a4efe21e155c25c21b43c46f65e True False False 6 6 6 0 31hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 프록시 구성을 표시하고 세부 정보가 예상대로 있는지 확인합니다.
oc get proxy cluster -o yaml
$ oc get proxy cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5. 클러스터 전체 프록시 제거 링크 복사링크가 클립보드에 복사되었습니다!
ROSA CLI를 사용하여 클러스터 전체 프록시를 제거할 수 있습니다. 클러스터를 제거한 후 클러스터에 추가된 신뢰 번들도 제거해야 합니다.
4.5.1. CLI를 사용하여 클러스터 전체 프록시 제거 링크 복사링크가 클립보드에 복사되었습니다!
ROSA CLI인 rosa 를 사용하여 클러스터에서 프록시 주소를 제거해야 합니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야합니다.
-
ROSA CLI(
rosa)를 설치했습니다.
프로세스
rosa edit명령을 사용하여 프록시를 수정합니다. 클러스터에서 프록시를 지우려면 빈 문자열을--http-proxy및--https-proxy인수에 전달해야 합니다.rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""
$ rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고프록시는 프록시 인수 중 하나만 사용할 수 있지만 빈 필드는 무시되므로
--http-proxy및--https-proxy인수 모두에 빈 문자열을 전달해도 문제가 발생하지 않습니다.출력 예
I: Updated cluster <cluster_name>
I: Updated cluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
rosa describe명령을 사용하여 프록시가 클러스터에서 제거되었는지 확인할 수 있습니다.$ rosa describe cluster -c <cluster_name>
$ rosa describe cluster -c <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 제거하기 전에 프록시 IP가 프록시 섹션에 표시됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프록시를 제거한 후 proxy 섹션이 제거됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.2. AWS 클래식 아키텍처 클러스터의 Red Hat OpenShift Service에서 인증 기관 제거 링크 복사링크가 클립보드에 복사되었습니다!
ROSA CLI, rosa 를 사용하여 클러스터에서 CA(인증 기관)를 제거할 수 있습니다.
사전 요구 사항
- 클러스터 관리자 권한이 있어야합니다.
-
ROSA CLI(
rosa)를 설치했습니다. - 클러스터에 인증 기관이 추가되었습니다.
프로세스
rosa edit명령을 사용하여 CA 신뢰 번들을 수정합니다. 클러스터에서 신뢰 번들을 지우려면--additional-trust-bundle-file인수에 빈 문자열을 전달해야 합니다.rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""
$ rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
I: Updated cluster <cluster_name>
I: Updated cluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
rosa describe명령을 사용하여 신뢰 번들이 클러스터에서 제거되었는지 확인할 수 있습니다.$ rosa describe cluster -c <cluster_name>
$ rosa describe cluster -c <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 제거하기 전에 추가 신뢰 번들 섹션이 표시되고 보안 목적으로 해당 값을 수정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프록시를 제거한 후 추가 신뢰 번들 섹션이 제거됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5장. 프로젝트에 멀티 캐스트 사용 링크 복사링크가 클립보드에 복사되었습니다!
5.1. 멀티 캐스트 정보 링크 복사링크가 클립보드에 복사되었습니다!
IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.
- 현재 멀티 캐스트는 고 대역폭 솔루션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다.
-
기본적으로 네트워크 정책은 네임스페이스의 모든 연결에 영향을 미칩니다. 그러나 멀티캐스트는 네트워크 정책의 영향을 받지 않습니다. 네트워크 정책과 동일한 네임스페이스에서 멀티 캐스트를 활성화하면
모든 네트워크 정책이 거부된 경우에도 항상 허용됩니다. 클러스터 관리자는 활성화하기 전에 네트워크 정책에서 멀티 캐스트에 미치는 영향을 고려해야 합니다.
AWS 클래식 아키텍처 Pod에서 Red Hat OpenShift Service 간 멀티 캐스트 트래픽은 기본적으로 비활성화되어 있습니다. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 프로젝트별로 멀티 캐스트를 활성화할 수 있습니다.
5.2. Pod 간 멀티 캐스트 활성화 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트의 Pod 간 멀티 캐스트를 활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin또는dedicated-admin역할이 있는 사용자로 클러스터에 로그인해야 합니다.
프로세스
다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로
<namespace>를 바꿉니다.oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true$ oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 작은 정보다음 YAML을 적용하여 주석을 추가할 수도 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
프로젝트에 멀티 캐스트가 활성화되어 있는지 확인하려면 다음 절차를 완료합니다.
멀티 캐스트를 활성화한 프로젝트로 현재 프로젝트를 변경합니다.
<project>를 프로젝트 이름으로 바꿉니다.oc project <project>
$ oc project <project>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 멀티 캐스트 수신자 역할을 할 pod를 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 멀티 캐스트 발신자 역할을 할 pod를 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 터미널 창 또는 탭에서 멀티 캐스트 리스너를 시작합니다.
Pod의 IP 주소를 가져옵니다.
POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')$ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 멀티 캐스트 리스너를 시작합니다.
oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname$ oc exec mlistener -i -t -- \ socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostnameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
멀티 캐스트 송신기를 시작합니다.
Pod 네트워크 IP 주소 범위를 가져옵니다.
CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')$ CIDR=$(oc get Network.config.openshift.io cluster \ -o jsonpath='{.status.clusterNetwork[0].cidr}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 멀티 캐스트 메시지를 보내려면 다음 명령을 입력합니다.
oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"$ oc exec msender -i -t -- \ /bin/bash -c "echo | socat STDIO UDP4-DATAGRAM:224.1.0.1:30102,range=$CIDR,ip-multicast-ttl=64"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 멀티 캐스트가 작동하는 경우 이전 명령은 다음 출력을 반환합니다.
mlistener
mlistenerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
링크 복사링크가 클립보드에 복사되었습니다!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.