OVN-Kubernetes 네트워크 플러그인
OpenShift Container Platform의 OVN-Kubernetes 네트워크 플러그인에 대한 심층적인 구성 및 문제 해결
초록
1장. OVN-Kubernetes 네트워크 플러그인 정보 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터는 pod 및 service 네트워크에 가상화된 네트워크를 사용합니다.
Red Hat OpenShift Networking의 일부인 OVN-Kubernetes 네트워크 플러그인은 OpenShift Container Platform의 기본 네트워크 공급자입니다. OVN-Kubernetes는 OVN(Open Virtual Network)을 기반으로 하며 오버레이 기반 네트워킹 구현을 제공합니다. OVN-Kubernetes 플러그인을 사용하는 클러스터는 각 노드에서 OVS(Open vSwitch)도 실행합니다. OVN은 각 노드에서 선언된 네트워크 구성을 구현하도록 OVS를 구성합니다.
OVN-Kubernetes는 OpenShift Container Platform 및 단일 노드 OpenShift 배포를 위한 기본 네트워킹 솔루션입니다.
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 암호화, 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 플랫폼에서 IPv4-primary 듀얼 스택 네트워킹.
- 베어 메탈 플랫폼의 IPv6 단일 스택 네트워킹.
- 베어 메탈, VMware vSphere 또는 RHOSP 플랫폼에서 실행되는 클러스터의 IPv6-primary 듀얼 스택 네트워킹.
- 송신 방화벽 장치 및 송신 IP 주소입니다.
- 리디렉션 모드에서 작동하는 송신 라우터 장치입니다.
- 클러스터 내 통신의 IPsec 암호화
1.2. OVN-Kubernetes IPv6 및 듀얼 스택 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 네트워크 플러그인에는 다음과 같은 제한 사항이 있습니다.
-
MachineConfig
CR(사용자 정의 리소스)의kernelArgument
섹션에서ipv6.disable
매개변수를1
로 설정하면 OVN-Kubernetes Pod가CrashLoopBackOff
상태가 됩니다. 또한 Network Operator가Degraded
상태에 있기 때문에 클러스터를 최신 버전의 OpenShift Container Platform으로 업데이트할 수 없습니다. Red Hat은 클러스터의 IPv6 adddresses 비활성화를 지원하지 않으므로ipv6.disable
매개변수를1
로 설정하지 마십시오.
듀얼 스택 네트워킹을 위해 구성된 클러스터의 경우 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 ens4
Copy 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 interface
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 유일한 해결 방법은 두 IP 제품군에 기본 게이트웨이가 포함되도록 호스트 네트워킹을 재구성하는 것입니다.
1.3. 세션 선호도 링크 복사링크가 클립보드에 복사되었습니다!
세션 선호도는 Kubernetes Service
오브젝트에 적용되는 기능입니다. <service_VIP>:<Port>에 연결할 때마다 트래픽이 항상 동일한 백엔드에 분산되도록 하려면 세션 선호도를 사용할 수 있습니다. 클라이언트의 IP 주소를 기반으로 세션 선호도를 설정하는 방법을 포함한 자세한 내용은 세션 선호도를 참조하십시오.
세션 선호도에 대한 고정 시간 제한
OpenShift Container Platform의 OVN-Kubernetes 네트워크 플러그인은 마지막 패킷을 기반으로 클라이언트에서 세션의 고정 시간 초과를 계산합니다. 예를 들어 curl
명령을 10번 실행하면 고정 세션 타이머가 첫 번째 패킷이 아닌 10번째 패킷에서 시작됩니다. 결과적으로 클라이언트가 지속적으로 서비스에 문의하는 경우 세션이 시간 초과되지 않습니다. 서비스가 timeoutSeconds
매개변수에 설정된 시간 양에 대한 패킷을 수신하지 않으면 시간 초과가 시작됩니다.
2장. OVN-Kubernetes 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
2.1. OVN-Kubernetes 아키텍처 소개 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램은 OVN-Kubernetes 아키텍처를 보여줍니다.
그림 2.1. OVK-Kubernetes 아키텍처
주요 구성 요소는 다음과 같습니다.
- CMS(Cloud Management System) - OVN 통합을 위한 CMS 특정 플러그인을 제공하는 OVN용 플랫폼 특정 클라이언트입니다. 플러그인은 CMS 관련 형식의 CMS 구성 데이터베이스에 저장된 클라우드 관리 시스템의 개념을 OVN에서 이해하는 중간 표현으로 변환합니다.
-
OVN Northbound 데이터베이스(
nbdb
) 컨테이너 - CMS 플러그인에서 전달하는 논리 네트워크 구성을 저장합니다. -
OVN Southbound 데이터베이스(
sbdb
) 컨테이너 - 바인딩 테이블을 포함하여 각 노드의 OVS(Open vSwitch) 시스템의 물리적 및 논리적 네트워크 구성 상태를 저장합니다. -
OVN north 데몬(
ovn-northd
) -nbdb
컨테이너와sbdb
컨테이너 간의 중간 클라이언트입니다.nbdb
컨테이너에서 가져온 기존 네트워크 개념의 관점에서 논리 네트워크 구성을sbdb
컨테이너의 논리 데이터 경로 흐름으로 변환합니다.ovn-northd
데몬의 컨테이너 이름은northd
이며ovnkube-node
Pod에서 실행됩니다. -
OVN-controller -
sbdb
컨테이너에 필요한 정보 또는 업데이트에 대해 OVS 및 하이퍼바이저와 상호 작용하는 OVN 에이전트입니다.ovn-controller
는sbdb
컨테이너에서 논리 흐름을 읽고, 이를OpenFlow
흐름으로 변환하여 노드의 OVS 데몬으로 전송합니다. 컨테이너 이름은ovn-controller
이며ovnkube-node
Pod에서 실행됩니다.
OVN northd, northbound 데이터베이스 및 southbound 데이터베이스는 클러스터의 각 노드에서 실행되며 대부분 해당 노드에 로컬인 정보를 포함하고 처리합니다.
OVN northbound 데이터베이스에는 클라우드 관리 시스템(CMS)에서 전달된 논리적 네트워크 구성이 있습니다. OVN northbound 데이터베이스에는 논리 포트, 논리 스위치, 논리 라우터 등으로 제공되는 현재 원하는 네트워크 상태가 포함되어 있습니다. ovn-northd
(northd
컨테이너)는 OVN northbound 데이터베이스 및 OVN southbound 데이터베이스에 연결됩니다. OVN northbound 데이터베이스에서 가져온 기존 네트워크 개념의 관점에서 논리적 네트워크 구성을 OVN southbound 데이터베이스의 논리 데이터 경로로 변환합니다.
OVN southbound 데이터베이스에는 함께 연결하는 네트워크 및 바인딩 테이블에 대한 물리적 및 논리적 표현이 있습니다. 노드의 섀시 정보와 클러스터의 다른 노드에 연결하는 데 필요한 원격 전송 스위치 포트와 같은 기타 구성이 포함되어 있습니다. OVN southbound 데이터베이스에는 모든 논리 흐름도 포함되어 있습니다. 논리 흐름은 각 노드에서 실행되는 ovn-controller
프로세스와 공유되고 ovn-controller
는 이를 OpenFlow
규칙으로 전환하여 OVS( Open vSwitch
)를 프로그래밍합니다.
Kubernetes 컨트롤 플레인 노드에는 별도의 노드에 두 개의 ovnkube-control-plane
Pod가 포함되어 있으며 클러스터의 각 노드에 대해 IPAM(중앙 IP 주소 관리) 할당을 수행합니다. 언제든지 단일 ovnkube-control-plane
Pod가 리더입니다.
2.2. OVN-Kubernetes 프로젝트의 모든 리소스 나열 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 프로젝트에서 실행되는 리소스와 컨테이너를 찾는 것이 OVN-Kubernetes 네트워킹 구현을 이해하는 데 도움이 됩니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
다음 명령을 실행하여 OVN-Kubernetes 프로젝트에서 모든 리소스, 끝점 및
ConfigMap
을 가져옵니다.oc get all,ep,cm -n openshift-ovn-kubernetes
$ oc get all,ep,cm -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 각 노드에 대해 하나의
ovnkube-node
Pod가 있습니다.ovnkube-config
구성 맵에는 OpenShift Container Platform OVN-Kubernetes 구성이 있습니다.다음 명령을 실행하여
ovnkube-node
Pod의 모든 컨테이너를 나열합니다.oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
$ oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller
ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-node
Pod는 여러 컨테이너로 구성됩니다. northbound 데이터베이스(nbdb
컨테이너), southbound 데이터베이스(sbdb
컨테이너), north 데몬(northd
컨테이너),ovnkube
컨테이너를 호스팅해야 합니다.-controller
ovnkube-controller
컨테이너는 Pod, 송신 IP, 네임스페이스, 서비스, 끝점, 송신 방화벽 및 네트워크 정책과 같은 API 오브젝트를 감시합니다. 또한 해당 노드에 사용 가능한 서브넷 풀에서 Pod IP를 할당해야 합니다.다음 명령을 실행하여
ovnkube-control-plane
Pod의 모든 컨테이너를 나열합니다.oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
$ oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
kube-rbac-proxy ovnkube-cluster-manager
kube-rbac-proxy ovnkube-cluster-manager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-control-plane
Pod에는 각 OpenShift Container Platform 노드에 있는 컨테이너(ovnkube-cluster-manager
)가 있습니다.ovnkube-cluster-manager
컨테이너는 Pod 서브넷, transit switch subnet IP 및 join switch subnet IP를 클러스터의 각 노드에 할당합니다.kube-rbac-proxy
컨테이너는ovnkube-cluster-manager
컨테이너의 지표를 모니터링합니다.
2.3. OVN-Kubernetes northbound 데이터베이스 콘텐츠 나열 링크 복사링크가 클립보드에 복사되었습니다!
각 노드는 해당 노드의 ovnkube-node
Pod에서 실행되는 ovnkube-controller
컨테이너에 의해 제어됩니다. OVN 논리 네트워킹 엔티티를 이해하려면 해당 노드의 ovnkube-node
Pod 내에서 컨테이너로 실행 중인 northbound 데이터베이스를 검사하여 표시하려는 노드에 있는 오브젝트를 확인해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
클러스터에서 ovn nbctl
또는 sbctl
명령을 실행하려면 관련 노드의 nbdb
또는 sbdb
컨테이너에 원격 쉘을 열어야 합니다.
다음 명령을 실행하여 Pod를 나열합니다.
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 노드 정보가 있는 Pod를 나열하려면 다음 명령을 실행합니다.
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 포드로 이동하여 다음 명령을 실행하여 northbound 데이터베이스를 확인합니다.
oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 northbound 데이터베이스의 모든 오브젝트를 표시합니다.
ovn-nbctl show
$ ovn-nbctl show
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력은 여기에 나열하기에는 너무 길 수 있습니다. 목록에는 NAT 규칙, 논리 스위치, 로드 밸런서 등이 포함됩니다.
다음 선택적 명령 중 일부를 사용하여 특정 구성 요소에 대한 범위를 좁히고 집중할 수 있습니다.
다음 명령을 실행하여 논리 라우터 목록을 표시합니다.
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c northd -- ovn-nbctl lr-list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)
45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2) 96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 출력에서 각 노드에 router이 있고
ovn_cluster_router
가 있음을 확인할 수 있습니다.다음 명령을 실행하여 논리 스위치 목록을 표시합니다.
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl ls-list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)
bdd7dc3d-d848-4a74-b293-cc15128ea614 (ci-ln-t487nnb-72292-mdcnq-master-2) b349292d-ee03-4914-935f-1940b6cb91e5 (ext_ci-ln-t487nnb-72292-mdcnq-master-2) 0aac0754-ea32-4e33-b086-35eeabf0a140 (join) 992509d7-2c3f-4432-88db-c179e43592e5 (transit_switch)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 출력에서 노드 이름 자체와 조인 스위치를 사용하여 각 노드에 대해 ext 스위치가 있음을 확인할 수 있습니다.
다음 명령을 실행하여 로드 밸런서 목록을 표시합니다.
oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-list
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb -- ovn-nbctl lb-list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 잘린 출력에서는 많은 OVN-Kubernetes 로드 밸런서가 있음을 확인할 수 있습니다. OVN-Kubernetes의 로드 밸런서는 서비스를 나타냅니다.
다음 명령을 실행하여
ovn-nbctl
: 명령과 함께 사용 가능한 옵션을 표시합니다.oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c nbdb ovn-nbctl --help
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.4. northbound 데이터베이스 콘텐츠를 검사하기 위한 ovn-nbctl의 명령줄 인수 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 ovn-nbctl
과 함께 사용하여 northbound 데이터베이스의 콘텐츠를 검사할 수 있는 명령줄 인수를 설명합니다.
콘텐츠를 확인하려는 포드에서 원격 쉘을 열고 ovn-nbctl
명령을 실행합니다.
인수 | 설명 |
---|---|
| 특정 노드에 표시된 northbound 데이터베이스 콘텐츠에 대한 개요입니다. |
| 지정된 스위치 또는 라우터와 관련된 세부 정보를 표시합니다. |
| 논리 라우터를 표시합니다. |
|
|
| 지정된 라우터에 대한 네트워크 주소 변환 세부 정보를 표시합니다. |
| 논리 스위치 표시 |
|
|
| 논리 포트의 유형을 가져옵니다. |
| 로드 밸런서를 표시합니다. |
2.5. OVN-Kubernetes southbound 데이터베이스 콘텐츠 나열 링크 복사링크가 클립보드에 복사되었습니다!
각 노드는 해당 노드의 ovnkube-node
Pod에서 실행되는 ovnkube-controller
컨테이너에 의해 제어됩니다. OVN 논리 네트워킹 엔티티를 이해하려면 해당 노드의 ovnkube-node
Pod 내에서 컨테이너로 실행 중인 northbound 데이터베이스를 검사하여 표시하려는 노드에 있는 오브젝트를 확인해야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
클러스터에서 ovn nbctl
또는 sbctl
명령을 실행하려면 관련 노드의 nbdb
또는 sbdb
컨테이너에 원격 쉘을 열어야 합니다.
다음 명령을 실행하여 Pod를 나열합니다.
oc get po -n openshift-ovn-kubernetes
$ oc get po -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 노드 정보가 있는 Pod를 나열하려면 다음 명령을 실행합니다.
oc get pods -n openshift-ovn-kubernetes -owide
$ oc get pods -n openshift-ovn-kubernetes -owide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 포드로 이동하여 southbound 데이터베이스를 확인합니다.
oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
$ oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 southbound 데이터베이스의 모든 오브젝트를 표시합니다.
ovn-sbctl show
$ ovn-sbctl show
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 자세한 출력은 섀시 및 섀시에 연결된 포트를 보여줍니다. 이 경우 모든 라우터 포트와 호스트 네트워킹과 같이 실행되는 모든 항목이 표시됩니다. 모든 Pod는 소스 네트워크 주소 변환(SNAT)을 사용하여 광범위한 네트워크에 통신합니다. 해당 IP 주소는 Pod가 실행 중인 노드의 IP 주소로 변환된 다음 네트워크로 전송됩니다.
southbound 데이터베이스에 있는 섀시 정보 외에도 southbound 데이터베이스에는 모든 논리 흐름이 있으며 이러한 논리 흐름은 각 노드에서 실행되는
ovn-controller
로 전송됩니다.ovn-controller
는 논리를 공개 흐름 규칙으로 변환하고 궁극적으로OpenvSwitch
를 프로그램하여 pod가 열린 흐름 규칙을 따르고 네트워크에서 제외할 수 있도록 합니다.다음 명령을 실행하여
ovn-sbctl
명령과 함께 사용할 수 있는 옵션을 표시합니다.oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --help
$ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \ -c sbdb ovn-sbctl --help
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.6. southbound 데이터베이스 콘텐츠를 검사하기 위해 ovn-sbctl의 명령줄 인수 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 ovn-sbctl
과 함께 southbound 데이터베이스의 콘텐츠를 검사하는 데 사용할 수 있는 명령줄 인수를 설명합니다.
콘텐츠를 확인하려는 포드에서 원격 쉘을 열고 ovn-sbctl
명령을 실행합니다.
인수 | 설명 |
---|---|
| 특정 노드에 표시된 대로 southbound 데이터베이스 콘텐츠에 대한 개요입니다. |
| 지정된 포트에 대한 southbound 데이터베이스 내용을 나열합니다. |
| 논리 흐름을 나열합니다. |
2.7. OVN-Kubernetes 논리 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
OVN은 네트워크 가상화 솔루션입니다. 논리 스위치 및 라우터를 생성합니다. 이러한 스위치와 라우터는 상호 연결되어 모든 네트워크 토폴로지를 생성합니다. 2 또는 5로 설정된 로그 수준을 사용하여 ovnkube-trace
를 실행하면 OVN-Kubernetes 논리 구성 요소가 노출됩니다. 다음 다이어그램은 OpenShift Container Platform에서 라우터 및 스위치가 연결된 방법을 보여줍니다.
그림 2.2. OVN-Kubernetes 라우터 및 스위치 구성 요소
패킷 처리와 관련된 주요 구성 요소는 다음과 같습니다.
- 게이트웨이 라우터
-
L3 게이트웨이 라우터라고도 하는 게이트웨이 라우터는 일반적으로 분산 라우터와 물리적 네트워크 간에 사용됩니다. 논리 패치 포트를 포함한 게이트웨이 라우터는 물리적 위치(배포되지 않음) 또는 섀시에 바인딩됩니다. 이 라우터의 패치 포트는 ovn-southbound 데이터베이스(
ovn-sbdb
)의 l3gateway 포트라고 합니다. - 분산 논리 라우터
- 분산 논리 라우터와 그 뒤에 논리 스위치(가상 머신 및 컨테이너가 연결되는 논리 스위치)는 각 하이퍼바이저에 효과적으로 상주합니다.
- 로컬 스위치 참여
- 로컬 스위치 연결은 분산 라우터 및 게이트웨이 라우터를 연결하는 데 사용됩니다. 분산 라우터에 필요한 IP 주소 수를 줄입니다.
- 패치 포트가 있는 논리 스위치
- 패치 포트가 있는 논리 스위치는 네트워크 스택을 가상화하는 데 사용됩니다. 터널을 통해 원격 논리 포트를 연결합니다.
- localnet 포트가 있는 논리 스위치
- localnet 포트가 있는 논리 스위치는 OVN을 물리적 네트워크에 연결하는 데 사용됩니다. 로컬 네트워크 포트를 사용하여 직접 연결된 물리적 L2 세그먼트에 패킷을 브리징하여 원격 논리 포트를 연결합니다.
- 패치 포트
- 패치 포트는 논리 스위치와 논리 라우터와 피어 논리 라우터 간의 연결을 나타냅니다. 단일 연결에는 각 측면에서 하나씩 이러한 연결 지점에 패치 포트가 한 쌍이 있습니다.
- l3gateway 포트
-
l3gateway 포트는 게이트웨이 라우터에 사용되는 논리 패치 포트용
ovn-sbdb
의 포트 바인딩 항목입니다. 이러한 포트는 게이트웨이 라우터 자체와 마찬가지로 이러한 포트가 섀시에 바인딩된다는 사실을 패치 포트 대신 l3gateway 포트라고 합니다. - localnet 포트
-
각
ovn-controller
인스턴스에서 로컬 액세스 네트워크에 연결할 수 있는 브리지된 논리 스위치에 localnet 포트가 있습니다. 이를 통해 논리 스위치에서 물리적 네트워크에 대한 직접 연결을 모델링할 수 있습니다. 논리 스위치에는 단일 localnet 포트만 연결할 수 있습니다.
2.7.1. 로컬 호스트에 network-tools 설치 링크 복사링크가 클립보드에 복사되었습니다!
로컬 호스트에 network-tools
를 설치하여 OpenShift Container Platform 클러스터 네트워크 문제를 디버깅하는 데 필요한 툴 컬렉션을 사용할 수 있도록 합니다.
프로세스
다음 명령을 사용하여
network-tools
리포지토리를 워크스테이션에 복제합니다.git clone git@github.com:openshift/network-tools.git
$ git clone git@github.com:openshift/network-tools.git
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 방금 복제한 리포지토리의 디렉터리로 변경합니다.
cd network-tools
$ cd network-tools
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 사용 가능한 모든 명령을 나열합니다.
./debug-scripts/network-tools -h
$ ./debug-scripts/network-tools -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.2. network-tools 실행 링크 복사링크가 클립보드에 복사되었습니다!
network-tools
를 실행하여 논리 스위치 및 라우터에 대한 정보를 가져옵니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. -
로컬 호스트에
network-tools
를 설치했습니다.
프로세스
다음 명령을 실행하여 라우터를 나열합니다.
./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
$ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)
944a7b53-7948-4ad2-a494-82b55eeccf87 (GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99) 84bd4a4c-4b0b-4a47-b0cf-a2c32709fc53 (ovn_cluster_router)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 localnet 포트를 나열합니다.
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnet
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=localnet
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
l3gateway
포트를 나열합니다../debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gateway
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=l3gateway
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 패치 포트를 나열합니다.
./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patch
$ ./debug-scripts/network-tools ovn-db-run-command \ ovn-sbctl find Port_Binding type=patch
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3장. OVN-Kubernetes 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes에는 기본 제공 상태 점검 및 로그 소스가 많이 있습니다. 다음 섹션의 지침에 따라 클러스터를 검사합니다. 지원 케이스가 필요한 경우 지원 가이드에 따라 must-gather
를 통해 추가 정보를 수집합니다. 지원에서 지시한 경우에만 -- gather_network_logs
를 사용하십시오.
3.1. 준비 상태 프로브를 사용하여 OVN-Kubernetes 상태 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
ovnkube-control-plane
및 ovnkube-node
Pod에는 컨테이너가 준비 프로브로 구성되어 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)에 액세스합니다. -
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다. -
jq
를 설치했습니다.
프로세스
다음 명령을 실행하여
ovnkube-node
준비 상태 프로브의 세부 정보를 검토합니다.oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
$ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \ -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-node
Pod의 northbound 및 southbound 데이터베이스 컨테이너에 대한 준비 상태 프로브는 데이터베이스 및ovnkube-controller
컨테이너의 상태를 확인합니다.ovnkube-node
Pod의ovnkube-controller
컨테이너에는 OVN-Kubernetes CNI 구성 파일이 있는지 확인하기 위한 준비 상태 프로브가 있으며 Pod가 실행 중이 아니거나 Pod 구성 요청을 수락할 준비가 되어 있지 않음을 나타냅니다.다음 명령을 사용하여 네임스페이스에 대한 프로브 오류를 포함한 모든 이벤트를 표시합니다.
oc get events -n openshift-ovn-kubernetes
$ oc get events -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 Pod에 대한 이벤트를 표시합니다.
oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes
$ oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 네트워크 Operator의 메시지 및 상태를 표시합니다.
oc get co/network -o json | jq '.status.conditions[]'
$ oc get co/network -o json | jq '.status.conditions[]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 스크립트를 실행하여
ovnkube-node
Pod에서 각 컨테이너의준비
상태를 표시합니다.for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ done
$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); do echo === $p ===; \ oc get pods -n openshift-ovn-kubernetes $p -o json | jq '.status.containerStatuses[] | .name, .ready'; \ done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고모든 컨테이너 상태가
true
로 보고될 것으로 예상합니다. 준비 상태 프로브가 실패하면 상태가false
로 설정됩니다.
3.2. 콘솔에서 OVN-Kubernetes 경고 보기 링크 복사링크가 클립보드에 복사되었습니다!
경고 UI는 경고 및 관리 경고 규칙과 음소거에 대한 자세한 정보를 제공합니다.
사전 요구 사항
- 개발자로 또는 메트릭을 확인하는 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.
프로세스(UI)
- 관리자 화면에서 모니터링 → 경고를 선택합니다. 이 관점에서 경고 UI의 세 가지 주요 페이지는 경고, 음소거 및 경고 규칙 페이지입니다.
- 모니터링 → 경고 → 경고 규칙을 선택하여 OVN -Kubernetes 경고 규칙을 확인합니다.
3.3. CLI에서 OVN-Kubernetes 경고 보기 링크 복사링크가 클립보드에 복사되었습니다!
명령줄에서 경고 및 관리 경고 규칙 및 음소거에 대한 정보를 얻을 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다. -
jq
를 설치했습니다.
프로세스
다음 명령을 실행하여 활성 또는 실행 경고를 확인합니다.
다음 명령을 실행하여 경고 관리자 경로 환경 변수를 설정합니다.
ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')
$ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \ -o jsonpath='{@.spec.host}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 경고 관리자 경로 API에 대한
curl
요청을 발행하고$ALERT_MANAGER
를Alertmanager
인스턴스의 URL로 교체합니다.curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'
$ curl -s -k -H "Authorization: Bearer $(oc create token prometheus-k8s -n openshift-monitoring)" https://$ALERT_MANAGER/api/v1/alerts | jq '.data[] | "\(.labels.severity) \(.labels.alertname) \(.labels.pod) \(.labels.container) \(.labels.endpoint) \(.labels.instance)"'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 경고 규칙을 확인합니다.
oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'
$ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -s 'http://localhost:9090/api/v1/rules' | jq '.data.groups[].rules[] | select(((.name|contains("ovn")) or (.name|contains("OVN")) or (.name|contains("Ovn")) or (.name|contains("North")) or (.name|contains("South"))) and .type=="alerting")'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. CLI를 사용하여 OVN-Kubernetes 로그 보기 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift CLI(oc
)를 사용하여 ovnkube-master
및 ovnkube-node
Pod에서 각 Pod의 로그를 볼 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)에 액세스합니다. -
jq
를 설치했습니다.
프로세스
특정 Pod의 로그를 확인합니다.
oc logs -f <pod_name> -c <container_name> -n <namespace>
$ oc logs -f <pod_name> -c <container_name> -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
-f
- 선택 사항: 출력에서 로그에 기록되는 내용을 따르도록 지정합니다.
<pod_name>
- pod 이름을 지정합니다.
<container_name>
- 선택 사항: 컨테이너의 이름을 지정합니다. Pod에 여러 컨테이너가 있는 경우 컨테이너 이름을 지정해야 합니다.
<namespace>
- Pod가 실행 중인 네임스페이스를 지정합니다.
예를 들면 다음과 같습니다.
oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes
$ oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes
$ oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 로그 파일의 내용이 출력됩니다.
ovnkube-node
Pod의 모든 컨테이너에서 최신 항목을 검사합니다.for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done
$ for p in $(oc get pods --selector app=ovnkube-node -n openshift-ovn-kubernetes \ -o jsonpath='{range.items[*]}{" "}{.metadata.name}'); \ do echo === $p ===; for container in $(oc get pods -n openshift-ovn-kubernetes $p \ -o json | jq -r '.status.containerStatuses[] | .name');do echo ---$container---; \ oc logs -c $container $p -n openshift-ovn-kubernetes --tail=5; done; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여
ovnkube-node
Pod의 모든 컨테이너에 있는 모든 로그의 마지막 5행을 확인합니다.oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5
$ oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. 웹 콘솔을 사용하여 OVN-Kubernetes 로그 보기 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔에서 ovnkube-master
및 ovnkube-node
Pod에서 각 Pod의 로그를 볼 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)에 액세스합니다.
프로세스
- OpenShift Container Platform 콘솔에서 워크로드 → Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.
-
드롭다운 메뉴에서
openshift-ovn-kubernetes
프로젝트를 선택합니다. - 조사할 Pod 이름을 클릭합니다.
-
로그를 클릭합니다. 기본적으로
ovnkube-master
의 경우northd
컨테이너와 연결된 로그가 표시됩니다. - 아래쪽 메뉴를 사용하여 각 컨테이너의 로그를 차례로 선택합니다.
3.5.1. OVN-Kubernetes 로그 수준 변경 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes의 기본 로그 수준은 4입니다. OVN-Kubernetes를 디버깅하려면 로그 수준을 5로 설정합니다. 문제를 디버깅하는 데 도움이 되도록 OVN-Kubernetes의 로그 수준을 높이려면 다음 절차를 따르십시오.
사전 요구 사항
-
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 OVN-Kubernetes 프로젝트의 모든 Pod에 대한 자세한 정보를 가져옵니다.
oc get po -o wide -n openshift-ovn-kubernetes
$ oc get po -o wide -n openshift-ovn-kubernetes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제와 유사한
ConfigMap
파일을 생성하고env-overrides.yaml
과 같은 파일 이름을 사용합니다.ConfigMap
파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여
ConfigMap
파일을 적용합니다.oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
$ oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
configmap/env-overrides.yaml created
configmap/env-overrides.yaml created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여
ovnkube
Pod를 다시 시작하여 새 로그 수준을 적용합니다.oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-0 -l app=ovnkube-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes \ --field-selector spec.nodeName=ci-ln-3njdr9b-72292-5nwkp-master-2 -l app=ovnkube-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-node
$ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 'ConfigMap' 파일이 특정 pod의 모든 노드에 적용되었는지 확인하려면 다음 명령을 실행합니다.
oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'
$ oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<XXXX>
이전 단계에서 Pod의 임의의 문자 시퀀스를 지정합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
선택 사항: 다음 명령을 실행하여
ConfigMap
파일이 적용되었는지 확인합니다.for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; done
for f in $(oc -n openshift-ovn-kubernetes get po -l 'app=ovnkube-node' --no-headers -o custom-columns=N:.metadata.name) ; do echo "---- $f ----" ; oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $f -- pgrep -a -f init-ovnkube-controller | grep -P -o '^.*loglevel\s+\d' ; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. OVN-Kubernetes Pod 네트워크 연결 확인 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 4.10 이상에서 연결 확인 컨트롤러는 클러스터의 연결 확인 검사를 오케스트레이션합니다. 여기에는 Kubernetes API, OpenShift API 및 개별 노드가 포함됩니다. 연결 테스트의 결과는 openshift-network-diagnostics
의 PodNetworkConnectivity
오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)에 액세스합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
jq
를 설치했습니다.
프로세스
현재
PodNetworkConnectivityCheck
오브젝트를 나열하려면 다음 명령을 입력합니다.oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 각 연결 오브젝트에 대한 최신 성공 상태를 확인합니다.
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 각 연결 오브젝트에 대한 최신 오류를 확인합니다.
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 각 연결 오브젝트에 대한 최신 중단을 확인합니다.
oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
$ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \ -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 연결 검사 컨트롤러는 또한 이러한 검사의 지표를 Prometheus에 기록합니다.
다음 명령을 실행하여 모든 메트릭을 확인합니다.
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'
$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 지난 5분 동안 소스 Pod와 openshift api 서비스 간의 대기 시간을 확인합니다.
oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'
$ oc exec prometheus-k8s-0 -n openshift-monitoring -- \ promtool query instant http://localhost:9090 \ '{component="openshift-network-diagnostics"}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. ovnkube-trace를 사용하여 Openflow 추적 링크 복사링크가 클립보드에 복사되었습니다!
OVN 및 OVS 트래픽 흐름은 ovnkube-trace
라는 단일 유틸리티에서 시뮬레이션할 수 있습니다. ovnkube-trace
유틸리티는 ovn-trace
,ovs-appctl ofproto/trace
및 ovn-detrace
를 실행하고 단일 출력에서 해당 정보와 관련이 있습니다.
전용 컨테이너에서 ovnkube-trace
바이너리를 실행할 수 있습니다. OpenShift Container Platform 4.7 이후 릴리스의 경우 바이너리를 로컬 호스트에 복사하고 해당 호스트에서 실행할 수도 있습니다.
4.1. 로컬 호스트에 ovnkube-trace 설치 링크 복사링크가 클립보드에 복사되었습니다!
ovnkube-trace
툴은 OVN-Kubernetes 기반 OpenShift Container Platform 클러스터의 지점 간 임의의 UDP 또는 TCP 트래픽에 대한 패킷 시뮬레이션을 추적합니다. ovnkube-trace
바이너리를 로컬 호스트에 복사하여 클러스터에 대해 실행할 수 있도록 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
다음 명령을 사용하여 Pod 변수를 생성합니다.
POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')
$ POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 로컬 호스트에서 다음 명령을 실행하여
ovnkube-control-plane
Pod에서 바이너리를 복사합니다.oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace
$ oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고RHEL(Red Hat Enterprise Linux) 8을 사용하여
ovnkube-trace
툴을 실행하는 경우/usr/lib/rhel8/ovnkube-trace
파일을 로컬 호스트에 복사해야 합니다.다음 명령을 실행하여
ovnkube-trace
를 실행 가능하게 만듭니다.chmod +x ovnkube-trace
$ chmod +x ovnkube-trace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ovnkube-trace
에서 사용할 수 있는 옵션을 표시합니다../ovnkube-trace -help
$ ./ovnkube-trace -help
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 지원되는 명령줄 인수는 네임스페이스, 포드, 서비스와 같이 친숙한 Kubernetes 구성이므로 MAC 주소, 대상 노드의 IP 주소 또는 ICMP 유형을 찾을 필요가 없습니다.
로그 수준은 다음과 같습니다.
- 0 (최소 출력)
- 2 (추적 명령의 결과를 보여주는 더 자세한 출력)
- 5 (디버그 출력)
4.2. ovnkube-trace 실행 링크 복사링크가 클립보드에 복사되었습니다!
ovn-trace
를 실행하여 OVN 논리 네트워크 내에서 패킷 전달을 시뮬레이션합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. -
로컬 호스트에
ovnkube-trace
를 설치했습니다.
예: 배포된 Pod에서 DNS 확인이 작동하는지 테스트
이 예에서는 배포된 Pod에서 클러스터에서 실행되는 코어 DNS Pod로 DNS 확인을 테스트하는 방법을 보여줍니다.
프로세스
다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다.
oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
Copy to Clipboard Copied! Toggle word wrap Toggle overflow openshift-dns
네임스페이스에서 실행 중인 Pod를 나열합니다.oc get pods -n openshift-dns
oc get pods -n openshift-dns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
ovnkube-trace
명령을 실행하여 DNS 확인이 작동하는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dst
포드가 동일한 노드에 배치된 경우 출력 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow src&dst
포드가 다른 노드에 배치된 경우 출력 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow ouput은 배포된 Pod에서 DNS 포트로의 성공 여부를 나타내며 다른 방향으로 돌아가고 있음을 나타냅니다. 따라서 웹 pod가 코어 DNS에서 DNS 확인을 수행하는 경우 UDP 포트 53에서 양방향 트래픽이 지원됩니다.
예를 들어 작동하지 않고 ovn-trace
, proto/trace
및 ovn-detrace
의 ovs-appctl
을 가져오고 더 많은 디버그 유형 정보는 로그 수준을 2로 늘리고 다음과 같이 명령을 다시 실행합니다.
이 증가된 로그 수준의 출력은 여기에 나열하기에는 너무 많습니다. 오류가 발생하면 이 명령의 출력에서 해당 트래픽을 삭제하는 흐름이 표시됩니다. 예를 들어 송신 또는 수신 네트워크 정책은 해당 트래픽을 허용하지 않는 클러스터에 구성할 수 있습니다.
예: 디버그 출력을 사용하여 구성된 기본 거부 확인
이 예에서는 Ingress 기본 거부 정책이 트래픽을 차단하는 디버그 출력을 사용하여 식별하는 방법을 보여줍니다.
프로세스
모든 네임스페이스의 모든 포드의 수신을
거부하도록 기본
거부 정책을 정의하는 다음 YAML을 생성합니다. YAML을deny-by-default.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 정책을 적용합니다.
oc apply -f deny-by-default.yaml
$ oc apply -f deny-by-default.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
networkpolicy.networking.k8s.io/deny-by-default created
networkpolicy.networking.k8s.io/deny-by-default created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
기본
네임스페이스에서 웹 서비스를 시작합니다.oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
$ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
prod
네임스페이스를 생성합니다.oc create namespace prod
$ oc create namespace prod
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
prod
네임스페이스에 레이블을 지정합니다.oc label namespace/prod purpose=production
$ oc label namespace/prod purpose=production
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
prod
네임스페이스에alpine
이미지를 배포하고 쉘을 시작합니다.oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
$ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 다른 터미널 세션을 엽니다.
이 새 터미널 세션에서
ovn-trace
를 실행하여 네임스페이스prod
에서 실행되는 소스 Podtest-6459
와default
네임스페이스에서 실행되는 대상 Pod 간의 통신 실패를 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
ovn-trace source pod to destination pod indicates failure from test-6459 to web
ovn-trace source pod to destination pod indicates failure from test-6459 to web
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 실패 이유를 노출하려면 로그 수준을 2로 늘립니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본 거부 정책이 적용되어 수신 트래픽이 차단됩니다.
purpose=production
레이블이 있는 특정 네임스페이스의 모든 Pod의 트래픽을 허용하는 정책을 생성합니다. YAML을web-allow-prod.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 정책을 적용합니다.
oc apply -f web-allow-prod.yaml
$ oc apply -f web-allow-prod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ovnkube-trace
를 실행하여 다음 명령을 입력하여 트래픽이 지금 허용되는지 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 6단계에서 열린 쉘에서 다음 명령을 실행하여 nginx를 web-server에 연결합니다.
wget -qO- --timeout=2 http://web.default
wget -qO- --timeout=2 http://web.default
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5장. IPv4/IPv6 듀얼 스택 네트워킹으로 변환 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 IPv4 단일 스택 클러스터를 IPv4 및 IPv6 주소 제품군을 지원하는 듀얼 네트워크 클러스터 네트워크로 변환할 수 있습니다. 듀얼 스택 네트워킹으로 변환한 후 신규 및 기존 Pod에 듀얼 스택 네트워킹이 활성화됩니다.
IPv6가 필요한 듀얼 스택 네트워킹을 사용하는 경우 ::FFFF:198.51.100.1
과 같은 IPv4 매핑 IPv6 주소를 사용할 수 없습니다.
5.1. 듀얼 스택 클러스터 네트워크로 변환 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.
듀얼 스택 네트워킹을 사용하도록 클러스터를 변환한 후 새 Pod만 IPv6 주소가 할당되므로 IPv6 주소를 수신하도록 기존 Pod를 다시 생성해야 합니다.
단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환하는 것은 패치를 생성하고 클러스터의 네트워크 및 인프라에 적용하는 것으로 구성됩니다. 설치 관리자 프로비저닝 인프라 또는 사용자 프로비저닝 인프라에서 실행되는 클러스터의 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.
clusterNetwork
,serviceNetwork
,apiServerInternalIPs
, ingressIP
오브젝트를 변경하는 각 패치 작업은 클러스터를 다시 시작합니다. MachineNetworks
오브젝트를 변경하면 클러스터가 재부팅되지 않습니다.
설치 관리자 프로비저닝 인프라에서만 API 및 Ingress 서비스의 IPv6 가상 IP(VIP)를 기존 듀얼 스택 구성 클러스터에 추가해야 하는 경우 클러스터의 네트워크가 아닌 인프라만 패치해야 합니다.
클러스터를 OpenShift Container Platform 4.16 이상으로 업그레이드하고 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환해야 하는 경우 YAML 구성 패치 파일의 API 및 Ingress 서비스에 대한 install-config.yaml
파일에서 기존 IPv4 machineNetwork
네트워크 구성을 지정해야 합니다. 이 구성을 사용하면 IPv4 트래픽이 기본 게이트웨이와 동일한 네트워크 인터페이스에 있는지 확인합니다.
machineNetwork
네트워크에 대해 추가된 IPv4 주소 블록이 있는 YAML 구성 파일의 예
- op: add path: /spec/platformSpec/baremetal/machineNetworks/- value: 192.168.1.0/24 # ...
- op: add
path: /spec/platformSpec/baremetal/machineNetworks/-
value: 192.168.1.0/24
# ...
- 1
- 시스템이 작동하는
machineNetwork
네트워크의 주소 블록을 지정해야 합니다. 머신 네트워크의 API 및 Ingress IP 주소를 모두 선택해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
- 클러스터 노드에는 IPv6 주소가 있습니다.
- 인프라를 기반으로 IPv6 지원 라우터를 구성했습니다.
프로세스
클러스터 및 서비스 네트워크에 대한 IPv6 주소 블록을 지정하려면 다음 예와 유사한 구성이 있는 YAML 구성 패치 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI에 다음 명령을 입력하여 클러스터 네트워크 구성을 패치합니다.
oc patch network.config.openshift.io cluster \ --type='json' --patch-file <file>.yaml
$ oc patch network.config.openshift.io cluster \
1 --type='json' --patch-file <file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 여기서
file
은 생성된 YAML 파일의 이름을 지정합니다.
출력 예
network.config.openshift.io/cluster patched
network.config.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow API 및 Ingress 서비스에 대한 IPv6 VIP를 추가한 설치 관리자 프로비저닝 인프라에서 다음 단계를 완료합니다.
API 및 클러스터의 Ingress 서비스에 대한 IPv6 VIP를 지정합니다. 다음 예와 유사한 구성이 있는 YAML 구성 패치 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CLI에 다음 명령을 입력하여 인프라를 패치합니다.
oc patch infrastructure cluster \ --type='json' --patch-file <file>.yaml
$ oc patch infrastructure cluster \ --type='json' --patch-file <file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <file>
생성된 YAML 파일의 이름을 지정합니다.
출력 예
infrastructure/cluster patched
infrastructure/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
CLI에 다음 명령을 입력하여 클러스터 네트워크 구성을 표시합니다.
oc describe network
$ oc describe network
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 네트워크 구성이 YAML 파일에 지정한 IPv6 주소 블록을 인식하는지 확인하여 네트워크 구성에 패치가 설치되었는지 확인합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 설치 관리자가 프로비저닝한 인프라에서 실행되는 클러스터에 대해 다음 추가 작업을 완료합니다.
CLI에 다음 명령을 입력하여 클러스터 인프라 구성을 표시합니다.
oc describe infrastructure
$ oc describe infrastructure
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인프라가 YAML 파일에 지정한 IPv6 주소 블록을 인식하는지 확인하여 클러스터 인프라에 패치가 성공적으로 설치되었는지 확인합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. 단일 스택 클러스터 네트워크로 변환 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 듀얼 스택 클러스터 네트워크를 단일 스택 클러스터 네트워크로 변환할 수 있습니다.
원래 IPv4 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터로 변환한 경우 IPv6 단일 스택 클러스터 네트워크가 아닌 IPv4 단일 스택 클러스터로만 변환할 수 있습니다. IPv6 단일 스택 클러스터 네트워크로 다시 변환하는 데 동일한 제한 사항이 적용됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
- 클러스터 노드에는 IPv6 주소가 있습니다.
- 듀얼 스택 네트워킹을 활성화했습니다.
프로세스
다음 명령을 실행하여
networks.config.openshift.io
CR(사용자 정의 리소스)을 편집합니다.oc edit networks.config.openshift.io
$ oc edit networks.config.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
cidr
및hostPrefix
매개변수에 추가한 IPv4 또는 IPv6 구성을 " 이중 스택 클러스터 네트워크로 변환" 절차 단계를 완료할 수 있습니다.
6장. OVN-Kubernetes 내부 IP 주소 서브넷 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OVN-Kubernetes 네트워크 플러그인이 가입 및 전송 서브넷에 사용하는 IP 주소 범위를 변경할 수 있습니다.
6.1. OVN-Kubernetes 조인 서브넷 구성 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes에서 사용하는 조인 서브넷을 변경하여 환경에서 이미 사용 중인 기존 서브넷과 충돌하지 않도록 할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인합니다.
프로세스
OVN-Kubernetes 조인 서브넷을 변경하려면 다음 명령을 입력합니다.
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":
$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalJoinSubnet": "<join_subnet>"}, "ipv6":{"internalJoinSubnet": "<join_subnet>"}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<join_subnet>
-
OVN-Kubernetes에서 내부적으로 사용할 IP 주소 서브넷을 지정합니다. 서브넷은 클러스터의 노드 수보다 커야 하며 클러스터의 노드당 하나의 IP 주소를 수용할 수 있을 만큼 충분히 커야 합니다. 이 서브넷은 OpenShift Container Platform 또는 호스트 자체에서 사용하는 다른 서브넷과 중복될 수 없습니다. IPv4의 기본값은
100.64.0.0/16
이며 IPv6의 기본값은fd98::/64
입니다.
출력 예
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
구성이 활성화되어 있는지 확인하려면 다음 명령을 입력합니다.
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"
$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 변경 사항을 적용하려면 명령 작업에 최대 30분이 걸릴 수 있습니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2. OVN-Kubernetes masquerade 서브넷을 설치 후 작업으로 구성 링크 복사링크가 클립보드에 복사되었습니다!
환경에서 이미 사용 중인 기존 서브넷과 충돌하지 않도록 OVN-Kubernetes에서 사용한 masquerade 서브넷을 설치 후 작업으로 변경할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
클러스터의 masquerade 서브넷을 변경합니다.
IPv6를 사용하는 듀얼 스택 클러스터의 경우 다음 명령을 실행합니다.
oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipv4":{"internalMasqueradeSubnet": "<ipv4_masquerade_subnet>"},"ipv6":{"internalMasqueradeSubnet": "<ipv6_masquerade_subnet>"}}}}}}'
$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipv4":{"internalMasqueradeSubnet": "<ipv4_masquerade_subnet>"},"ipv6":{"internalMasqueradeSubnet": "<ipv6_masquerade_subnet>"}}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
ipv4_masquerade_subnet
-
IPv4 masquerade 서브넷으로 사용할 IP 주소를 지정합니다. 이 범위는 OpenShift Container Platform 또는 호스트 자체에서 사용하는 다른 서브넷과 중복될 수 없습니다. 4.17 이전 버전의 OpenShift Container Platform에서는 IPv4의 기본값은
169.254.169.0/29
이고 버전 4.17으로 업그레이드된 클러스터는 이 값을 유지 관리합니다. 버전 4.17부터 시작하는 새 클러스터의 경우 기본값은169.254.0.0/17
입니다. ipv6_masquerade_subnet
-
IPv6 masquerade 서브넷으로 사용할 IP 주소를 지정합니다. 이 범위는 OpenShift Container Platform 또는 호스트 자체에서 사용하는 다른 서브넷과 중복될 수 없습니다. IPv6의 기본값은
fd69::/125
입니다.
IPv4를 사용하는 클러스터의 경우 다음 명령을 실행합니다.
oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipv4":{"internalMasqueradeSubnet": "<ipv4_masquerade_subnet>"}}}}}}'
$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipv4":{"internalMasqueradeSubnet": "<ipv4_masquerade_subnet>"}}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
ipv4_masquerade_subnet
:#17squerade 서브넷으로 사용할 IP 주소를 지정합니다. 이 범위는 OpenShift Container Platform 또는 호스트 자체에서 사용하는 다른 서브넷과 중복될 수 없습니다. 4.17 이전 버전의 OpenShift Container Platform에서는 IPv4의 기본값은169.254.169.0/29
이고 버전 4.17으로 업그레이드된 클러스터는 이 값을 유지 관리합니다. 버전 4.17부터 시작하는 새 클러스터의 경우 기본값은169.254.0.0/17
입니다.
6.3. OVN-Kubernetes 전송 서브넷 구성 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes에서 사용하는 전송 서브넷을 변경하여 환경에서 이미 사용 중인 기존 서브넷과 충돌하지 않도록 할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인합니다.
프로세스
OVN-Kubernetes 전송 서브넷을 변경하려면 다음 명령을 입력합니다.
oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig":
$ oc patch network.operator.openshift.io cluster --type='merge' \ -p='{"spec":{"defaultNetwork":{"ovnKubernetesConfig": {"ipv4":{"internalTransitSwitchSubnet": "<transit_subnet>"}, "ipv6":{"internalTransitSwitchSubnet": "<transit_subnet>"}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<transit_subnet>
-
east-west 트래픽을 활성화하는 분산 전송 스위치의 IP 주소 서브넷을 지정합니다. 이 서브넷은 OVN-Kubernetes 또는 호스트 자체에서 사용하는 다른 서브넷과 중복될 수 없습니다. IPv4의 기본값은
100.88.0.0/16
이고 IPv6의 기본값은fd97::/64
입니다.
출력 예
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
구성이 활성화되어 있는지 확인하려면 다음 명령을 입력합니다.
oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"
$ oc get network.operator.openshift.io \ -o jsonpath="{.items[0].spec.defaultNetwork}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 변경 사항을 적용하는 데 최대 30분이 걸릴 수 있습니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7장. 게이트웨이 모드 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 외부 트래픽이 클러스터를 나가는 방법을 관리하도록 gatewayConfig
오브젝트를 구성할 수 있습니다. 공유 모드의 경우 routingViaHost
사양을 true
로 설정하거나 로컬 모드의 경우 false
로 설정합니다.
로컬 게이트웨이 모드에서 트래픽이 호스트를 통해 라우팅되므로 호스트의 라우팅 테이블에 적용됩니다. 공유 게이트웨이 모드에서 트래픽은 호스트를 통해 라우팅되지 않습니다. 대신 OVS(Open vSwitch)가 노드 IP 인터페이스로 직접 트래픽을 출력합니다.
7.1. 로컬 및 공유 게이트웨이 모드 설정 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Cluster Network Operator의 gatewayConfig
사양을 사용하여 게이트웨이 모드를 구성할 수 있습니다. 다음 절차를 사용하여 공유 모드의 경우 routingViaHost
필드를 true
로 설정할 수 있습니다.
OVN-Kubernetes와 관련이 없는 트래픽의 라우터 역할을 위해 노드의 호스트 네트워크가 필요한 경우 선택적 4단계에 따라 로컬 게이트웨이 모드와 함께 IP 전달을 활성화할 수 있습니다. 예를 들어 로컬 게이트웨이 모드와 IP 전달 모드를 결합하는 사용 사례는 다음과 같습니다.
- 노드의 IP를 통해 전달되는 모든 Pod 송신 트래픽 구성
- OVN-Kubernetes CNI와 외부 NAT(네트워크 주소 변환) 장치 통합
- 커널 라우팅 테이블을 사용하도록 OVN-Kubernetes CNI 구성
사전 요구 사항
- 관리자 권한이 있는 사용자로 로그인했습니다.
프로세스
다음 명령을 실행하여 기존 네트워크 구성을 백업합니다.
oc get network.operator cluster -o yaml > network-config-backup.yaml
$ oc get network.operator cluster -o yaml > network-config-backup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 로컬 게이트웨이 모드에 대해
routingViaHost
paramemter를true
로 설정합니다.oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'
$ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 로컬 게이트웨이 모드가 설정되었는지 확인합니다.
oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
true
값은 로컬 게이트웨이 모드를 설정하고false
값은 공유 게이트웨이 모드를 설정합니다. 로컬 게이트웨이 모드에서 트래픽이 호스트를 통해 라우팅됩니다. 공유 게이트웨이 모드에서 트래픽은 호스트를 통해 라우팅되지 않습니다.
선택 사항: 다음 명령을 실행하여 IP 전달을 전역적으로 활성화합니다.
oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'
$ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ipForwarding
사양이Global
로 설정되어 있는지 확인합니다.oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
$ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8장. 기본 네트워크에서 외부 게이트웨이 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 기본 네트워크에서 외부 게이트웨이를 구성할 수 있습니다.
이 기능은 다음과 같은 이점을 제공합니다.
- 네임스페이스별로 송신 트래픽에 대한 세분화된 제어
- 정적 및 동적 외부 게이트웨이 IP 주소의 유연한 구성
- IPv4 및 IPv6 주소 제품군 모두에 대한 지원
8.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
- 인프라는 보조 외부 게이트웨이에서 트래픽을 라우팅하도록 구성됩니다.
8.2. OpenShift Container Platform에서 외부 게이트웨이 IP 주소를 결정하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
k8s.ovn.org
API 그룹에서 AdminPolicyBasedExternalRoute
CR(사용자 정의 리소스)을 사용하여 보조 외부 게이트웨이를 구성합니다. CR은 외부 게이트웨이의 IP 주소를 지정하는 정적 및 동적 접근 방식을 지원합니다.
AdminPolicyBasedExternalRoute
CR 대상의 각 네임스페이스는 다른 AdminPolicyBasedExternalRoute
CR에서 선택할 수 없습니다. 네임스페이스에는 동시 보조 외부 게이트웨이가 있을 수 없습니다.
정책에 대한 변경 사항은 컨트롤러에서 격리됩니다. 정책이 적용되지 않으면 다른 정책에 대한 변경 사항이 다른 정책의 재시도를 트리거하지 않습니다. 정책은 재평가되어 변경에 의해 발생할 수 있는 차이점을 적용하고, 정책 자체 또는 관련 오브젝트에 대한 업데이트가 대상 네임스페이스, pod 게이트웨이 또는 동적 홉에서 호스팅하는 네임스페이스와 같은 정책에 업데이트할 때 적용됩니다.
- 정적 할당
- IP 주소를 직접 지정합니다.
- 동적 할당
네임스페이스 및 Pod 선택기와 선택적 네트워크 연결 정의를 사용하여 IP 주소를 간접적으로 지정합니다.
- 네트워크 연결 정의 이름이 제공되면 네트워크 연결의 외부 게이트웨이 IP 주소가 사용됩니다.
-
네트워크 연결 정의의 이름이 제공되지 않으면 Pod 자체의 외부 게이트웨이 IP 주소가 사용됩니다. 그러나 이 방법은 Pod가
hostNetwork
가true
로 설정된 경우에만 작동합니다.
8.3. AdminPolicyBasedExternalRoute 오브젝트 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 속성을 사용하여 클러스터 범위인 AdminPolicyBasedExternalRoute
오브젝트를 정의할 수 있습니다. 네임스페이스는 한 번에 하나의 AdminPolicyBasedExternalRoute
CR에서만 선택할 수 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
|
|
|
라우팅 정책이 적용되는 네임스페이스 선택기를 지정합니다. from: namespaceSelector: matchLabels: kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
네임스페이스는 하나의 |
|
|
패킷이 전달되는 대상을 지정합니다. |
필드 | 유형 | 설명 |
---|---|---|
|
| 고정 IP 주소 배열을 지정합니다. |
|
| 외부 게이트웨이 대상으로 사용할 네트워크 연결 정의로 구성된 Pod에 해당하는 Pod 선택기 배열을 지정합니다. |
필드 | 유형 | 설명 |
---|---|---|
|
| 다음 대상 홉의 IPv4 또는 IPv6 주소를 지정합니다. |
|
|
선택 사항: 네트워크에서 Bi-Directional Forwarding Detection(BFD)를 지원하는지 여부를 지정합니다. 기본값은 |
필드 | 유형 | 설명 |
---|---|---|
|
| 이 네트워크 구성과 일치하는 네임스페이스의 Pod를 필터링하는 [set-based]( https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) 라벨 선택기를 지정합니다.https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement |
|
|
|
|
|
선택 사항: 네트워크에서 Bi-Directional Forwarding Detection(BFD)를 지원하는지 여부를 지정합니다. 기본값은 |
|
| 선택 사항: 네트워크 연결 정의의 이름을 지정합니다. 이름은 Pod와 연결된 논리 네트워크 목록과 일치해야 합니다. 이 필드를 지정하지 않으면 Pod의 호스트 네트워크가 사용됩니다. 그러나 Pod는 호스트 네트워크를 사용하려면 호스트 네트워크 pod로 구성해야 합니다. |
8.3.1. 보조 외부 게이트웨이 구성 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 예에서 AdminPolicyBasedExternalRoute
오브젝트는 kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
라벨이 있는 네임스페이스에서 Pod의 외부 게이트웨이로 두 개의 고정 IP 주소를 구성합니다.
다음 예에서 AdminPolicyBasedExternalRoute
오브젝트는 동적 외부 게이트웨이를 구성합니다. 외부 게이트웨이에 사용되는 IP 주소는 선택한 각 pod와 연결된 추가 네트워크 연결에서 파생됩니다.
다음 예에서 AdminPolicyBasedExternalRoute
오브젝트는 정적 및 동적 외부 게이트웨이를 모두 구성합니다.
8.4. 보조 외부 게이트웨이 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터의 네임스페이스에 대한 기본 네트워크에서 외부 게이트웨이를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
-
AdminPolicyBasedExternalRoute
오브젝트가 포함된 YAML 파일을 생성합니다. 관리자 정책 기반 외부 경로를 생성하려면 다음 명령을 입력합니다.
oc create -f <file>.yaml
$ oc create -f <file>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<file>
- 이전 단계에서 생성한 YAML 파일의 이름을 지정합니다.
출력 예
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created
adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리자 정책 기반 외부 경로가 생성되었는지 확인하려면 다음 명령을 입력합니다.
oc describe apbexternalroute <name> | tail -n 6
$ oc describe apbexternalroute <name> | tail -n 6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<name>
-
AdminPolicyBasedExternalRoute
오브젝트의 이름을 지정합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5. 추가 리소스 링크 복사링크가 클립보드에 복사되었습니다!
- 추가 네트워크 연결에 대한 자세한 내용은 여러 네트워크 이해를 참조하십시오.
9장. 송신 IP 주소 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OVN-Kubernetes CNI(Container Network Interface) 네트워크 플러그인을 구성하여 하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.
현재 HCP 클러스터의 ROSA에서는 송신 IP 구성이 지원되지 않습니다.
9.1. 송신 IP 주소 아키텍처 설계 및 구현 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 송신 IP 주소 기능을 사용하면 하나 이상의 네임스페이스에 있는 하나 이상의 Pod에서 발생하는 트래픽의 소스 IP 주소가 클러스터 네트워크 외부 서비스에 일관되게 표시되도록 할 수 있습니다.
예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.
네임스페이스에 할당된 송신 IP 주소는 특정 대상으로 트래픽을 보내는 데 사용되는 송신 라우터와 다릅니다.
일부 클러스터 구성에서 애플리케이션 pod 및 수신 라우터 포드는 동일한 노드에서 실행됩니다. 이 시나리오에서 애플리케이션 프로젝트에 대한 송신 IP 주소를 구성하는 경우 애플리케이션 프로젝트의 경로에 요청을 보낼 때 IP 주소가 사용되지 않습니다.
송신 IP 주소는 ifcfg-eth0
과 같은 Linux 네트워크 구성 파일에서 구성하지 않아야 합니다.
9.1.1. 플랫폼 지원 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 다양한 플랫폼의 송신 IP 주소 기능에 대한 지원이 요약되어 있습니다.
플랫폼 | 지원됨 |
---|---|
베어 메탈 | 제공됨 |
VMware vSphere | 제공됨 |
Red Hat OpenStack Platform (RHOSP) | 제공됨 |
AWS(Amazon Web Services) | 제공됨 |
GCP(Google Cloud Platform) | 제공됨 |
Microsoft Azure | 제공됨 |
IBM Z® 및 IBM® LinuxONE | 제공됨 |
IBM Z® 및 IBM® LinuxONE for Red Hat Enterprise Linux (RHEL) KVM | 제공됨 |
IBM Power® | 제공됨 |
Nutanix | 제공됨 |
EgressIP 기능이 있는 컨트롤 플레인 노드에 대한 송신 IP 주소 할당은 AWS(Amazon Web Services)에서 프로비저닝된 클러스터에서 지원되지 않습니다. (BZ#2039656).
9.1.2. 퍼블릭 클라우드 플랫폼 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 퍼블릭 클라우드 공급자는 송신 IP에 제한을 배치합니다. 즉, 퍼블릭 클라우드 인프라에서 프로비저닝된 클러스터의 노드당 할당 가능한 IP 주소 수에 제한이 있습니다. 노드당 할당 가능한 최대 IP 주소 수 또는 IP 용량 은 다음 공식에서 설명할 수 있습니다.
IP capacity = public cloud default capacity - sum(current IP assignments)
IP capacity = public cloud default capacity - sum(current IP assignments)
Egress IP 기능은 노드당 IP 주소 용량을 관리하지만 배포에서 이 제약 조건을 계획하는 것이 중요합니다. 예를 들어, 퍼블릭 클라우드 공급자가 IP 주소 용량을 노드당 10개의 IP 주소로 제한하고 노드가 8개인 경우 할당 가능한 총 IP 주소 수는 80개에 불과합니다. 더 높은 IP 주소 용량을 달성하려면 추가 노드를 할당해야 합니다. 예를 들어 할당 가능한 150개의 IP 주소가 필요한 경우 7개의 추가 노드를 할당해야 합니다.
퍼블릭 클라우드 환경에서 노드의 IP 용량 및 서브넷을 확인하려면 oc get node <node_name> -o yaml
명령을 입력합니다. cloud.network.openshift.io/egress-ipconfig
주석에는 노드의 용량 및 서브넷 정보가 포함됩니다.
주석 값은 기본 네트워크 인터페이스에 다음 정보를 제공하는 필드가 있는 단일 오브젝트가 포함된 배열입니다.
-
Interface
: AWS 및 Azure의 인터페이스 ID와 GCP의 인터페이스 이름을 지정합니다. -
ifaddr
: 하나 또는 두 IP 주소 제품군의 서브넷 마스크를 지정합니다. -
capacity
: 노드의 IP 주소 용량을 지정합니다. AWS에서 IP 주소 용량은 IP 주소 제품군별로 제공됩니다. Azure 및 GCP에서 IP 주소 용량에는 IPv4 및 IPv6 주소가 모두 포함됩니다.
노드 간 트래픽에 대한 송신 IP 주소 자동 연결 및 분리를 사용할 수 있습니다. 이를 통해 네임스페이스의 많은 Pod의 트래픽이 클러스터 외부의 위치로 일관된 소스 IP 주소를 가질 수 있습니다.
RHOSP 송신 IP 주소 기능은 egressip-<IP address>라는 Neutron 예약 포트를 생성합니다
. OpenShift Container Platform 클러스터 설치에 사용된 것과 동일한 RHOSP 사용자를 사용하여 이 예약 포트에 유동 IP 주소를 할당하여 송신 트래픽에 대해 예측 가능한 SNAT 주소를 가질 수 있습니다. 노드 장애 조치(failover)로 인해 RHOSP 네트워크의 송신 IP 주소가 다른 노드로 이동되면 예를 들어 Neutron 예약 포트가 제거되고 다시 생성됩니다. 즉, 유동 IP 연결이 손실되고 유동 IP 주소를 새 예약 포트에 수동으로 다시 할당해야 합니다.
RHOSP 클러스터 관리자가 예약 포트에 유동 IP를 할당하면 OpenShift Container Platform에서 예약 포트를 삭제할 수 없습니다. CloudPrivateIPConfig
오브젝트는 RHOSP 클러스터 관리자가 예약 포트에서 유동 IP를 할당 해제할 때까지 삭제 및 이동 작업을 수행할 수 없습니다.
다음 예제에서는 여러 퍼블릭 클라우드 공급자의 노드의 주석을 보여줍니다. 가독성을 위해 주석을 들여쓰기합니다.
AWS의 cloud.network.openshift.io/egress-ipconfig
주석의 예
GCP의 cloud.network.openshift.io/egress-ipconfig
주석의 예
다음 섹션에서는 용량 계산에 사용할 지원되는 퍼블릭 클라우드 환경의 IP 주소 용량에 대해 설명합니다.
9.1.2.1. AWS(Amazon Web Services) IP 주소 용량 제한 링크 복사링크가 클립보드에 복사되었습니다!
AWS에서 IP 주소 할당에 대한 제약 조건은 구성된 인스턴스 유형에 따라 다릅니다. 자세한 내용은 인스턴스 유형당 네트워크 인터페이스당 IP 주소를참조하십시오.
9.1.2.2. GCP(Google Cloud Platform) IP 주소 용량 제한 링크 복사링크가 클립보드에 복사되었습니다!
GCP에서 네트워킹 모델은 IP 주소 할당 대신 IP 주소 별칭을 통해 추가 노드 IP 주소를 구현합니다. 그러나 IP 주소 용량은 IP 별칭 용량에 직접 매핑됩니다.
IP 별칭 할당에는 다음과 같은 용량 제한이 있습니다.
- 노드당 최대 IP 별칭 수, IPv4 및 IPv6 모두 100입니다.
- VPC당 최대 IP 별칭 수는 지정되지 않았지만 OpenShift Container Platform 확장성 테스트에서는 최대 약 15,000개입니다.
자세한 내용은 Per instance quota and Alias IP ranges overview 를 참조하십시오.
9.1.2.3. Microsoft Azure IP 주소 용량 제한 링크 복사링크가 클립보드에 복사되었습니다!
Azure에서 IP 주소 할당을 위한 다음 용량 제한이 있습니다.
- NIC당 IPv4 및 IPv6 모두에 대해 할당 가능한 최대 IP 주소 수는 256입니다.
- 가상 네트워크당 할당된 최대 IP 주소 수는 65,536을 초과할 수 없습니다.
자세한 내용은 네트워킹 제한을 참조하십시오.
9.1.3. 추가 네트워크 인터페이스에서 송신 IP 사용 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 송신 IP는 관리자에게 네트워크 트래픽을 제어하는 방법을 제공합니다. 송신 IP는 OVS( br-ex
Open vSwitch) 브리지 인터페이스 및 IP 연결이 활성화된 물리적 인터페이스와 함께 사용할 수 있습니다.
다음 명령을 실행하여 네트워크 인터페이스 유형을 검사할 수 있습니다.
ip -details link show
$ ip -details link show
기본 네트워크 인터페이스에는 서브넷 마스크도 포함하는 노드 IP 주소가 할당됩니다. 이 노드 IP 주소에 대한 정보는 k8s.ovn.org/node-primary-ifaddr
주석을 검사하여 클러스터 내의 각 노드의 Kubernetes 노드 오브젝트에서 검색할 수 있습니다. IPv4 클러스터에서 이 주석은 "k8s.ovn.org/node-primary-ifaddr: {"ipv4":"192.168.111.23/24"}"
와 유사합니다.
송신 IP가 기본 네트워크 인터페이스 서브넷의 서브넷에 없는 경우 기본 네트워크 인터페이스 유형이 아닌 다른 Linux 네트워크 인터페이스에서 송신 IP를 사용할 수 있습니다. 이렇게 하면 OpenShift Container Platform 관리자는 라우팅, 주소 지정, 분할 및 보안 정책과 같은 네트워킹 측면에 대한 보다 높은 수준의 제어 기능을 제공합니다. 이 기능을 사용하면 트래픽 분할 또는 특수 요구 사항 충족과 같은 목적으로 워크로드 트래픽을 특정 네트워크 인터페이스를 통해 라우팅할 수 있는 옵션을 제공합니다.
송신 IP가 기본 네트워크 인터페이스의 서브넷 내에 없는 경우 노드에 있는 경우 송신 트래픽에 대한 다른 네트워크 인터페이스를 선택할 수 있습니다.
k8s.ovn.org/host-cidrs
Kubernetes 노드 주석을 검사하여 송신 IP를 지원할 수 있는 다른 네트워크 인터페이스를 확인할 수 있습니다. 이 주석에는 기본 네트워크 인터페이스에 대해 발견된 주소 및 서브넷 마스크가 포함되어 있습니다. 또한 추가 네트워크 인터페이스 주소 및 서브넷 마스크 정보가 포함되어 있습니다. 이러한 주소 및 서브넷 마스크는 가장 긴 접두사 일치 라우팅 메커니즘을 사용하여 송신 IP를 지원하는 네트워크 인터페이스를 결정하는 네트워크 인터페이스에 할당됩니다.
OVN-Kubernetes는 특정 네임스페이스 및 Pod에서 아웃 바운드 네트워크 트래픽을 제어하고 전달하는 메커니즘을 제공합니다. 이렇게 하면 특정 네트워크 인터페이스와 특정 송신 IP 주소를 통해 클러스터를 종료합니다.
기본 네트워크 인터페이스가 아닌 네트워크 인터페이스에 송신 IP 할당 요구 사항
송신 IP 및 트래픽을 기본 네트워크 인터페이스가 아닌 특정 인터페이스를 통해 라우팅하려는 사용자는 다음 조건을 충족해야 합니다.
- OpenShift Container Platform은 베어 메탈 클러스터에 설치되어 있습니다. 이 기능은 클라우드 또는 하이퍼바이저 환경 내에서 비활성화되어 있습니다.
- OpenShift Container Platform Pod는 호스트 네트워크로 구성되지 않습니다.
- 네트워크 인터페이스가 제거되거나 인터페이스에서 송신 IP를 호스팅할 수 있는 IP 주소 및 서브넷 마스크가 제거되면 송신 IP가 재구성됩니다. 결과적으로 송신 IP를 다른 노드 및 인터페이스에 할당할 수 있었습니다.
- 보조 NIC(네트워크 인터페이스 카드)에서 Egress IP 주소를 사용하는 경우 Node Tuning Operator를 사용하여 보조 NIC에서 IP 전달을 활성화해야 합니다.
9.1.4. Pod에 송신 IP 할당 링크 복사링크가 클립보드에 복사되었습니다!
하나 이상의 송신 IP를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당하려면 다음 조건을 충족해야 합니다.
-
클러스터에서 하나 이상의 노드에
k8s.ovn.org/egress-assignable: ""
레이블이 있어야 합니다. -
네임스페이스의 Pod에서 클러스터를 떠나는 트래픽의 소스 IP 주소로 사용할 하나 이상의 송신 IP 주소를 정의하는
EgressIP
오브젝트가 있습니다.
송신 IP 할당을 위해 클러스터의 노드에 레이블을 지정하기 전에 EgressIP
오브젝트를 생성하면 OpenShift Container Platform에서 모든 송신 IP 주소를 k8s.ovn.org/egress-assignable: ""
레이블이 있는 첫 번째 노드에 할당할 수 있습니다.
송신 IP 주소가 클러스터의 여러 노드에 널리 분산되도록 하려면 EgressIP
오브젝트를 만들기 전에 송신 IP 주소를 호스팅할 노드에 항상 레이블을 적용하십시오.
9.1.5. 노드에 송신 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 대화에 사용할 수 있습니다.
9.1.6. 송신 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
입니다. 트래픽은 이 두 노드 간에 대략적으로 균등하게 분산됩니다.
다이어그램의 다음 리소스는 자세히 설명되어 있습니다.
Namespace
오브젝트네임스페이스는 다음 매니페스트에 정의됩니다.
네임스페이스 오브젝트
Copy to Clipboard Copied! Toggle word wrap Toggle overflow EgressIP
오브젝트다음
EgressIP
오브젝트는env
라벨이prod
로 설정된 모든 포드를 선택하는 구성을 설명합니다. 선택한 포드의 송신 IP 주소는192.168.126.10
및192.168.126.102
입니다.EgressIP
오브젝트Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 예제의 구성에 대해 OpenShift Container Platform은 두 송신 IP 주소를 사용 가능한 노드에 할당합니다.
status
필드는 송신 IP 주소가 할당되었는지 여부와 위치를 반영합니다.
9.2. EgressIP 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
다음 YAML에서는 EgressIP
오브젝트의 API를 설명합니다. 오브젝트의 범위는 클러스터 전체이며 네임스페이스에 생성되지 않습니다.
다음 YAML은 네임스페이스 선택기에 대한 스탠자를 설명합니다.
네임스페이스 선택기 스탠자
namespaceSelector: matchLabels: <label_name>: <label_value>
namespaceSelector:
matchLabels:
<label_name>: <label_value>
- 1
- 네임스페이스에 대해 일치하는 하나 이상의 규칙입니다. 둘 이상의 일치 규칙이 제공되면 일치하는 모든 네임스페이스가 선택됩니다.
다음 YAML은 Pod 선택기에 대한 선택적 스탠자를 설명합니다.
Pod 선택기 스탠자
podSelector: matchLabels: <label_name>: <label_value>
podSelector:
matchLabels:
<label_name>: <label_value>
- 1
- 선택사항: 지정된
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
오브젝트의 예
9.3. egressIPConfig 오브젝트 링크 복사링크가 클립보드에 복사되었습니다!
송신 IP의 기능으로 reachabilityTotalTimeoutSeconds
매개변수는 EgressIP 노드 도달 가능성 검사 총 시간(초)을 구성합니다. 이 시간 초과 내에 EgressIP 노드에 도달할 수 없는 경우 노드가 다운됩니다.
egressIPConfig
오브젝트의 구성 파일에서 reachabilityTotalTimeoutSeconds
값을 설정할 수 있습니다. 큰 값을 설정하면 EgressIP 구현이 노드 변경에 천천히 반응할 수 있습니다. 이 구현에서는 문제가 있고 연결할 수 없는 EgressIP 노드에 대해 천천히 반응합니다.
egressIPConfig
오브젝트에서 reachabilityTotalTimeoutSeconds
매개변수를 생략하면 플랫폼은 시간이 지남에 따라 변경될 수 있는 적절한 기본값을 선택합니다. 현재 기본값은 1
초입니다. 값이 0
이면 EgressIP 노드의 도달 가능성 검사를 비활성화합니다.
다음 egressIPConfig
오브젝트는 기본 1
초 프로브에서 5
초 프로브로 reachabilityTotalTimeoutSeconds
를 변경하는 방법을 설명합니다.
9.4. 송신 IP 주소 호스팅을 위해 노드에 레이블 지정 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에서 노드에 하나 이상의 송신 IP 주소를 할당할 수 있도록 k8s.ovn.org/egress-assignable=""
레이블을 클러스터의 노드에 적용할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 클러스터 관리자로 클러스터에 로그인합니다.
프로세스
하나 이상의 송신 IP 주소를 호스팅할 수 있도록 노드에 레이블을 지정하려면 다음 명령을 입력합니다.
oc label nodes <node_name> k8s.ovn.org/egress-assignable=""
$ oc label nodes <node_name> k8s.ovn.org/egress-assignable=""
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 레이블을 지정할 노드 이름입니다.
작은 정보다음 YAML을 적용하여 노드에 레이블을 추가할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.5. 다음 단계 링크 복사링크가 클립보드에 복사되었습니다!
10장. 송신 IP 주소 할당 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 네임스페이스 또는 네임스페이스의 특정 Pod에서 클러스터를 떠나는 트래픽에 송신 IP 주소를 할당할 수 있습니다.
10.1. 네임스페이스에 송신 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>.yaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<egressips_name>
을 오브젝트 이름으로 변경합니다.
출력 예
egressips.k8s.ovn.org/<egressips_name> created
egressips.k8s.ovn.org/<egressips_name> created
Copy 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=qa
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;namespace&
gt;를 송신 IP 주소가 필요한 네임스페이스로 바꿉니다.
검증
클러스터에서 사용 중인 모든 송신 IP를 표시하려면 다음 명령을 입력합니다.
oc get egressip -o yaml
$ oc get egressip -o yaml
Copy 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
11장. 송신 서비스 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 송신 서비스를 사용하여 로드 밸런서 서비스 뒤의 Pod에 대한 송신 트래픽을 구성할 수 있습니다.
송신 서비스는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
EgressService
CR(사용자 정의 리소스)을 사용하여 다음과 같은 방법으로 송신 트래픽을 관리할 수 있습니다.
로드 밸런서 서비스 IP 주소를 로드 밸런서 서비스 뒤의 포드의 송신 트래픽의 소스 IP 주소로 할당합니다.
이 컨텍스트에서 로드 밸런서 IP 주소를 소스 IP 주소로 할당하는 것은 단일 송신 및 수신 지점을 제공하는 데 유용합니다. 예를 들어 일부 시나리오에서는 로드 밸런서 서비스 뒤의 애플리케이션과 통신하는 외부 시스템은 애플리케이션의 소스 및 대상 IP 주소가 같을 것으로 예상할 수 있습니다.
참고서비스 뒤의 pod에 대한 트래픽을 송신하도록 로드 밸런서 서비스 IP 주소를 할당하면 OVN-Kubernetes는 수신 및 송신 지점을 단일 노드로 제한합니다. 이렇게 하면 MetalLB에서 일반적으로 제공하는 트래픽의 로드 밸런싱이 제한됩니다.
로드 밸런서 뒤의 Pod에 대한 송신 트래픽을 기본 노드 네트워크와 다른 네트워크에 할당합니다.
이는 로드 밸런서 뒤의 애플리케이션에 대한 송신 트래픽을 기본 네트워크와 다른 네트워크에 할당하는 데 유용합니다. 일반적으로 다른 네트워크는 네트워크 인터페이스와 연결된 VRF 인스턴스를 사용하여 구현됩니다.
11.1. 송신 서비스 사용자 정의 리소스 링크 복사링크가 클립보드에 복사되었습니다!
EgressService
사용자 정의 리소스에서 송신 서비스에 대한 구성을 정의합니다. 다음 YAML은 송신 서비스 구성에 대한 필드를 설명합니다.
- 1
- 송신 서비스의 이름을 지정합니다.
EgressService
리소스의 이름은 수정할 로드 밸런서 서비스의 이름과 일치해야 합니다. - 2
- 송신 서비스의 네임스페이스를 지정합니다.
EgressService
의 네임스페이스는 수정하려는 로드 밸런서 서비스의 네임스페이스와 일치해야 합니다. 송신 서비스는 네임스페이스 범위입니다. - 3
- 서비스 뒤의 포드에 대한 송신 트래픽의 소스 IP 주소를 지정합니다. 유효한 값은
LoadBalancerIP
또는네트워크입니다
.LoadBalancerIP
값을 사용하여LoadBalancer
서비스 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 할당합니다. 네트워크 인터페이스 IP 주소를 송신 트래픽의 소스 IP 주소로 할당하려면Network
를 지정합니다. - 4
- 선택 사항:
sourceIPBy
사양에LoadBalancerIP
값을 사용하는 경우 단일 노드에서LoadBalancer
서비스 트래픽을 처리합니다.nodeSelector
필드를 사용하여 이 작업을 할당할 수 있는 노드를 제한합니다. 서비스 트래픽을 처리하기 위해 노드를 선택하면 OVN-Kubernetes는 다음 형식으로 노드에 레이블을 지정합니다.egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""
.nodeSelector
필드를 지정하지 않으면 모든 노드에서LoadBalancer
서비스 트래픽을 관리할 수 있습니다. - 5
- 선택 사항: 송신 트래픽에 대한 라우팅 테이블 ID를 지정합니다. 값이
NodeNetworkConfigurationPolicy
리소스에 정의된route-table-id
ID와 일치하는지 확인합니다.네트워크
사양을 포함하지 않으면 송신 서비스에서 기본 호스트 네트워크를 사용합니다.
송신 서비스 사양의 예
11.2. 송신 서비스 배포 링크 복사링크가 클립보드에 복사되었습니다!
송신 서비스를 배포하여 LoadBalancer
서비스 뒤의 Pod에 대한 송신 트래픽을 관리할 수 있습니다.
다음 예제에서는 LoadBalancer
서비스의 수신 IP 주소와 동일한 소스 IP 주소를 갖도록 송신 트래픽을 구성합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. -
MetalLB
BGPPeer
리소스를 구성했습니다.
프로세스
서비스에 원하는 IP를 사용하여
IPAddressPool
CR을 만듭니다.다음 예와 같은 콘텐츠를 사용하여
ip-addr-pool.yaml
과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 IP 주소 풀에 대한 구성을 적용합니다.
oc apply -f ip-addr-pool.yaml
$ oc apply -f ip-addr-pool.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Service
및EgressService
CR을 생성합니다.다음 예와 같은 콘텐츠를 사용하여
service-egress-service.yaml
과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
LoadBalancer
서비스는example-pool
IP 주소 풀에서 MetalLB에서 할당한 IP 주소를 사용합니다.- 2
- 이 예에서는
LoadBalancerIP
값을 사용하여LoadBalancer
서비스의 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 할당합니다. - 3
LoadBalancerIP
값을 지정하면 단일 노드가LoadBalancer
서비스의 트래픽을 처리합니다. 이 예에서는worker
레이블이 있는 노드만 트래픽을 처리하도록 선택할 수 있습니다. 노드를 선택하면 OVN-Kubernetes는 다음 형식의egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: ""
로 노드에 레이블을 지정합니다.
참고sourceIPBy: "LoadBalancerIP"
설정을 사용하는 경우BGPAdvertisement
CR(사용자 정의 리소스)에 로드 밸런서 노드를 지정해야 합니다.다음 명령을 실행하여 서비스 및 송신 서비스에 대한 구성을 적용합니다.
oc apply -f service-egress-service.yaml
$ oc apply -f service-egress-service.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
서비스를 알리기 위해
BGPAdvertisement
CR을 생성합니다.다음 예와 같은 콘텐츠를 사용하여
service-bgp-advertisement.yaml
과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 예에서
EgressService
CR은 로드 밸런서 서비스 IP 주소를 사용하도록 송신 트래픽의 소스 IP 주소를 구성합니다. 따라서 Pod에서 시작되는 트래픽에 대해 동일한 반환 경로를 사용하도록 트래픽을 반환하려면 로드 밸런서 노드를 지정해야 합니다.
검증
다음 명령을 실행하여 MetalLB 서비스 뒤에서 실행 중인 Pod의 애플리케이션 끝점에 액세스할 수 있는지 확인합니다.
curl <external_ip_address>:<port_number>
$ curl <external_ip_address>:<port_number>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 애플리케이션 엔드포인트에 맞게 외부 IP 주소 및 포트 번호를 업데이트합니다.
-
LoadBalancer
서비스의 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 할당한 경우tcpdump
와 같은 툴을 사용하여 외부 클라이언트에서 수신된 패킷을 분석하여 이 구성을 확인합니다.
12장. 송신 라우터 Pod 사용에 대한 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
12.1. 송신 라우터 Pod 정보 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 송신 라우터 포드는 다른 용도로 사용되지 않는 프라이빗 소스 IP 주소에서 지정된 원격 서버로 트래픽을 리디렉션합니다. 송신 라우터 포드를 통해 특정 IP 주소에서만 액세스할 수 있도록 설정된 서버로 네트워크 트래픽을 보낼 수 있습니다.
송신 라우터 Pod는 모든 발신 연결을 위한 것은 아닙니다. 다수의 송신 라우터 Pod를 생성하는 경우 네트워크 하드웨어 제한을 초과할 수 있습니다. 예를 들어 모든 프로젝트 또는 애플리케이션에 대해 송신 라우터 Pod를 생성하면 소프트웨어에서 MAC 주소 필터링으로 돌아가기 전에 네트워크 인터페이스에서 처리할 수 있는 로컬 MAC 주소 수를 초과할 수 있습니다.
송신 라우터 이미지는 Amazon AWS, Azure Cloud 또는 macvlan 트래픽과의 비호환성으로 인해 계층 2 조작을 지원하지 않는 기타 클라우드 플랫폼과 호환되지 않습니다.
12.1.1. 송신 라우터 모드 링크 복사링크가 클립보드에 복사되었습니다!
리디렉션 모드에서는 송신 라우터 포드가 자체 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션하도록 iptables
규칙을 구성합니다. 예약된 소스 IP 주소를 사용해야 하는 클라이언트 Pod는 대상 IP에 직접 연결하는 대신 송신 라우터의 서비스에 액세스하도록 구성해야 합니다. curl
명령을 사용하여 애플리케이션 포드에서 대상 서비스 및 포트에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.
curl <router_service_IP> <port>
$ curl <router_service_IP> <port>
송신 라우터 CNI 플러그인은 리디렉션 모드만 지원합니다. 송신 라우터 CNI 플러그인은 HTTP 프록시 모드 또는 DNS 프록시 모드를 지원하지 않습니다.
12.1.2. 송신 라우터 Pod 구현 링크 복사링크가 클립보드에 복사되었습니다!
송신 라우터 구현에서는 송신 라우터 CNI(Container Network Interface) 플러그인을 사용합니다. 플러그인은 보조 네트워크 인터페이스를 Pod에 추가합니다.
송신 라우터는 두 개의 네트워크 인터페이스가 있는 포드입니다. 예를 들어 포드에는 eth0
및 net1
네트워크 인터페이스가 있을 수 있습니다. eth0
인터페이스는 클러스터 네트워크에 있으며 포드는 일반 클러스터 관련 네트워크 트래픽에 대한 인터페이스를 계속 사용합니다. net1
인터페이스는 보조 네트워크에 있으며 해당 네트워크에 대한 IP 주소 및 게이트웨이가 있습니다. OpenShift Container Platform 클러스터의 다른 포드는 송신 라우터 서비스에 액세스할 수 있으며, 서비스를 통해 포드가 외부 서비스에 액세스할 수 있습니다. 송신 라우터는 포드와 외부 시스템 간의 브리지 역할을 합니다.
송신 라우터를 종료하는 트래픽은 노드를 통해 종료되지만 패킷에는 송신 라우터 포드에서 net1
인터페이스의 MAC 주소가 있습니다.
송신 라우터 사용자 정의 리소스를 추가하면 Cluster Network Operator에서 다음 오브젝트를 생성합니다.
-
pod의
net1
보조 네트워크 인터페이스에 대한 네트워크 연결 정의입니다. - 출력 라우터에 대한 배포입니다.
송신 라우터 사용자 정의 리소스를 삭제하는 경우 Operator는 송신 라우터와 연결된 이전 목록에서 두 개의 오브젝트를 삭제합니다.
12.1.3. 배포 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
송신 라우터 Pod는 노드의 기본 네트워크 인터페이스에 추가 IP 주소와 MAC 주소를 추가합니다. 따라서 추가 주소를 허용하도록 하이퍼바이저 또는 클라우드 공급자를 구성해야 할 수 있습니다.
- Red Hat OpenStack Platform (RHOSP)
RHOSP에서 OpenShift Container Platform을 배포하는 경우 OpenStack 환경에서 송신 라우터 포드의 IP 및 MAC 주소의 트래픽을 허용해야 합니다. 트래픽을 허용하지 않으면 통신이 실패합니다.
openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
$ openstack port set --allowed-address \ ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - VMware vSphere
- VMware vSphere를 사용하는 경우 vSphere 표준 스위치 보안을 위한 VMware 설명서를 참조하십시오. vSphere Web Client에서 호스트 가상 스위치를 선택하여 VMware vSphere 기본 설정을 보고 변경합니다.
특히 다음이 활성화되어 있는지 확인하십시오.
12.1.4. 장애 조치 구성 링크 복사링크가 클립보드에 복사되었습니다!
다운타임을 방지하기 위해 Cluster Network Operator는 송신 라우터 Pod를 배포 리소스로 배포합니다. 배포 이름은 egress-router-cni-deployment
입니다. 배포에 해당하는 포드의 레이블은 app=egress-router-cni
입니다.
배포에 사용할 새 서비스를 생성하려면 oc expose deployment/egress-router-cni-deployment --port <port_number>
명령을 사용하거나 다음 예와 같이 파일을 생성합니다.
13장. 리디렉션 모드에서 송신 라우터 Pod 배포 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 예약된 소스 IP 주소에서 지정된 대상 IP 주소로 트래픽을 리디렉션하도록 송신 라우터 포드를 배포할 수 있습니다.
송신 라우터 구현에서는 송신 라우터 CNI(Container Network Interface) 플러그인을 사용합니다.
13.1. 송신 라우터 사용자 정의 리소스 링크 복사링크가 클립보드에 복사되었습니다!
송신 라우터 사용자 정의 리소스에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 리디렉션 모드에서 송신 라우터 구성을 위한 필드를 설명합니다.
- 1
- 선택 사항:
namespace
필드는 송신 라우터를 생성할 네임스페이스를 지정합니다. 파일 또는 명령줄에 값을 지정하지 않으면default
네임스페이스가 사용됩니다. - 2
address
필드는 보조 네트워크 인터페이스에서 구성할 IP 주소를 지정합니다.- 3
ip
필드는 노드가 송신 라우터 Pod에서 사용할 실제 네트워크의 예약된 소스 IP 주소와 넷마스크를 지정합니다. CIDR 표기법을 사용하여 IP 주소와 넷마스크를 지정합니다.- 4
gateway
필드는 네트워크 게이트웨이의 IP 주소를 지정합니다.- 5
- 선택 사항:
redirectRules
필드는 송신 대상 IP 주소, 송신 라우터 포트 및 프로토콜의 조합을 지정합니다. 지정된 포트 및 프로토콜의 출력 라우터에 대한 수신 연결은 대상 IP 주소로 라우팅됩니다. - 6
- 선택 사항:
targetPort
필드는 대상 IP 주소에 네트워크 포트를 지정합니다. 이 필드를 지정하지 않으면 트래픽이 도달한 동일한 네트워크 포트로 라우팅됩니다. - 7
protocol
필드는 TCP, UDP 또는 SCTP를 지원합니다.- 8
- 선택 사항:
fallbackIP
필드는 대상 IP 주소를 지정합니다. 리디렉션 규칙을 지정하지 않으면 송신 라우터에서 모든 트래픽을 이 폴백 IP 주소로 보냅니다. 리디렉션 규칙을 지정하면 규칙에 정의되지 않은 네트워크 포트에 대한 모든 연결이 송신 라우터에서 이 대체 IP 주소로 전송됩니다. 이 필드를 지정하지 않으면 송신 라우터는 규칙에 정의되지 않은 네트워크 포트에 대한 연결을 거부합니다.
송신 라우터 사양의 예
13.2. 리디렉션 모드에서 송신 라우터 배포 링크 복사링크가 클립보드에 복사되었습니다!
송신 라우터 pod를 배포하여 자체 예약된 소스 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션할 수 있습니다.
송신 라우터 pod를 추가한 후 예약된 소스 IP 주소를 사용해야 하는 클라이언트 pod는 대상 IP에 직접 연결하는 대신 송신 라우터에 연결하도록 수정해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
- 송신 라우터 정의를 생성합니다.
다른 포드에서 송신 라우터 pod의 IP 주소를 찾을 수 있도록 하려면 다음 예제와 같이 송신 라우터를 사용하는 서비스를 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 송신 라우터의 레이블을 지정합니다. 표시된 값은 Cluster Network Operator에서 추가하며 구성 불가능합니다.
서비스를 생성한 후 포드가 서비스에 연결할 수 있습니다. 송신 라우터 pod는 트래픽을 대상 IP 주소의 해당 포트로 리디렉션합니다. 이 연결은 예약된 소스 IP 주소에서 시작됩니다.
검증
Cluster Network Operator가 송신 라우터를 시작했는지 확인하려면 다음 절차를 완료합니다.
송신 라우터에 대해 Operator가 생성한 네트워크 연결 정의를 확인합니다.
oc get network-attachment-definition egress-router-cni-nad
$ oc get network-attachment-definition egress-router-cni-nad
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 네트워크 연결 정의의 이름은 구성할 수 없습니다.
출력 예
NAME AGE egress-router-cni-nad 18m
NAME AGE egress-router-cni-nad 18m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 송신 라우터 pod에 대한 배포를 확인합니다.
oc get deployment egress-router-cni-deployment
$ oc get deployment egress-router-cni-deployment
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 배포 이름은 구성할 수 없습니다.
출력 예
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18m
NAME READY UP-TO-DATE AVAILABLE AGE egress-router-cni-deployment 1/1 1 1 18m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 송신 라우터 pod의 상태를 확인합니다.
oc get pods -l app=egress-router-cni
$ oc get pods -l app=egress-router-cni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18m
NAME READY STATUS RESTARTS AGE egress-router-cni-deployment-575465c75c-qkq6m 1/1 Running 0 18m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 송신 라우터 pod의 로그 및 라우팅 테이블을 확인합니다.
송신 라우터 pod에 대한 노드 이름을 가져옵니다.
POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")
$ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는
<node_name>-debug
라는 디버그 Pod를 인스턴스화합니다.oc debug node/$POD_NODENAME
$ oc debug node/$POD_NODENAME
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 루트 파일 시스템을 마운트합니다. 루트 디렉터리를/host
로 변경하면 호스트의 실행 경로에서 바이너리를 실행할 수 있습니다.chroot /host
# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow chroot
환경 콘솔에서 송신 라우터 로그를 표시합니다.cat /tmp/egress-router-log
# cat /tmp/egress-router-log
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 로깅 파일 위치 및 로깅 수준은 이 프로세스에 설명된 대로
EgressRouter
오브젝트를 생성하여 송신 라우터를 시작할 때 구성되지 않습니다.chroot
환경 콘솔에서 컨테이너 ID를 가져옵니다.crictl ps --name egress-router-cni-pod | awk '{print $1}'
# crictl ps --name egress-router-cni-pod | awk '{print $1}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
CONTAINER bac9fae69ddb6
CONTAINER bac9fae69ddb6
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 컨테이너의 프로세스 ID를 확인합니다. 이 예에서 컨테이너 ID는
bac9fae69ddb6
입니다.crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
# crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
68857
68857
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 컨테이너의 네트워크 네임스페이스를 입력합니다.
nsenter -n -t 68857
# nsenter -n -t 68857
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 라우팅 테이블을 표시합니다.
ip route
# ip route
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제 출력에서
net1
네트워크 인터페이스가 기본 경로입니다. 클러스터 네트워크의 트래픽은eth0
네트워크 인터페이스를 사용합니다.192.168.12.0/24
네트워크의 트래픽은net1
네트워크 인터페이스를 사용하며 예약된 소스 IP 주소192.168.12.99
에서 시작됩니다. 포드는 다른 모든 트래픽을 IP 주소192.168.12.1
의 게이트웨이로 라우팅합니다. 서비스 네트워크의 라우팅이 표시되지 않습니다.출력 예
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1
default via 192.168.12.1 dev net1 10.128.10.0/23 dev eth0 proto kernel scope link src 10.128.10.18 192.168.12.0/24 dev net1 proto kernel scope link src 192.168.12.99 192.168.12.1 dev net1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14장. 프로젝트에 멀티 캐스트 사용 링크 복사링크가 클립보드에 복사되었습니다!
14.1. 멀티 캐스트 정보 링크 복사링크가 클립보드에 복사되었습니다!
IP 멀티 캐스트를 사용하면 데이터가 여러 IP 주소로 동시에 브로드캐스트됩니다.
- 현재 멀티 캐스트는 고 대역폭 솔루션이 아닌 저 대역폭 조정 또는 서비스 검색에 가장 적합합니다.
-
기본적으로 네트워크 정책은 네임스페이스의 모든 연결에 영향을 미칩니다. 그러나 멀티캐스트는 네트워크 정책의 영향을 받지 않습니다. 네트워크 정책과 동일한 네임스페이스에서 멀티 캐스트를 활성화하면
모든 네트워크 정책이 거부
된 경우에도 항상 허용됩니다. 클러스터 관리자는 활성화하기 전에 네트워크 정책에서 멀티 캐스트에 미치는 영향을 고려해야 합니다.
OpenShift Container Platform Pod 간 멀티 캐스트 트래픽은 기본적으로 비활성화되어 있습니다. OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 프로젝트별로 멀티 캐스트를 활성화할 수 있습니다.
14.2. Pod 간 멀티 캐스트 활성화 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트의 Pod 간 멀티 캐스트를 활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할을 가진 사용자로 클러스터에 로그인해야 합니다.
프로세스
다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로
<namespace>
를 바꿉니다.oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true
$ oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled=true
Copy 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:hostname
Copy 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
mlistener
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15장. 프로젝트에 대한 멀티 캐스트 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
15.1. Pod 간 멀티 캐스트 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트의 Pod 간 멀티 캐스트를 비활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할을 가진 사용자로 클러스터에 로그인해야 합니다.
프로세스
다음 명령을 실행하여 멀티 캐스트를 비활성화합니다.
oc annotate namespace <namespace> \ k8s.ovn.org/multicast-enabled-
$ oc annotate namespace <namespace> \
1 k8s.ovn.org/multicast-enabled-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 멀티 캐스트를 비활성화하려는 프로젝트의
namespace
입니다.
작은 정보다음 YAML을 적용하여 주석을 삭제할 수도 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16장. 네트워크 흐름 추적 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 다음 영역을 지원하기 위해 클러스터에서 Pod 네트워크 흐름에 대한 정보를 수집할 수 있습니다.
- pod 네트워크에서 수신 및 송신 트래픽을 모니터링합니다.
- 성능 문제를 해결합니다.
- 용량 계획 및 보안 감사를 위한 데이터를 수집합니다.
네트워크 흐름 컬렉션을 활성화하면 트래픽에 대한 메타데이터만 수집됩니다. 예를 들어 패킷 데이터는 수집되지 않지만 프로토콜, 소스 주소, 대상 주소, 포트 번호, 바이트 수 및 기타 패킷 수준 정보가 수집됩니다.
데이터는 다음 레코드 형식 중 하나로 수집됩니다.
- NetFlow
- sFlow
- IPFIX
하나 이상의 컬렉터 IP 주소와 포트 번호를 사용하여 CNO(Cluster Network Operator)를 구성하는 경우 Operator는 각 노드에 OVS(Open vSwitch)를 구성하여 네트워크 흐름 레코드를 각 컬렉터에 전송합니다.
여러 유형의 네트워크 흐름 수집기로 레코드를 보내도록 Operator를 구성할 수 있습니다. 예를 들어 NetFlow 컬렉터에 레코드를 보내고 레코드를 sFlow 수집기에 전송할 수도 있습니다.
OVS가 수집기에 데이터를 보내면 각 유형의 컬렉터는 동일한 레코드를 수신합니다. 예를 들어 노드의 OVS가 두 개의 NetFlow 컬렉터를 구성하는 경우 두 컬렉터에 동일한 레코드를 보냅니다. 또한 두 개의 sFlow 컬렉터를 구성하는 경우 두 개의 sFlow 수집기는 동일한 레코드를 받습니다. 그러나 각 컬렉터 유형에는 고유한 레코드 형식이 있습니다.
네트워크 흐름 데이터를 수집하고 컬렉터로 레코드를 전송하면 성능에 영향을 미칩니다. 노드는 더 느린 속도로 패킷을 처리합니다. 성능 영향이 너무 크면 컬렉터의 대상을 삭제하여 네트워크 흐름 데이터 수집 및 복원 성능을 비활성화할 수 있습니다.
네트워크 흐름 수집기를 활성화하면 클러스터 네트워크의 전반적인 성능에 영향을 미칠 수 있습니다.
16.1. 네트워크 흐름 추적을 위한 네트워크 오브젝트 구성 링크 복사링크가 클립보드에 복사되었습니다!
CNO(Cluster Network Operator)에서 네트워크 흐름 수집기를 구성하는 필드는 다음 표에 표시되어 있습니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
CNO 개체 이름입니다. 이 이름은 항상 |
|
|
|
|
| 최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다. |
|
| 최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다. |
|
| 최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다. |
CNO에 다음 매니페스트를 적용한 후 Operator는 클러스터의 각 노드에서 OVS(Open vSwitch)를 구성하여 네트워크 흐름 레코드를 192.168.1.99:2056
에서 수신 대기 중인 NetFlow 수집기에 전송합니다.
네트워크 흐름 추적을 위한 구성 예
16.2. 네트워크 흐름 수집기 추가 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Pod 네트워크에 대한 네트워크 흐름 메타데이터를 네트워크 흐름 수집기로 전송하도록 CNO(Cluster Network Operator)를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 네트워크 흐름 수집기가 있고 수신 대기하는 IP 주소와 포트를 알고 있습니다.
프로세스
네트워크 흐름 수집기 유형과 컬렉터의 IP 주소 및 포트 정보를 지정하는 패치 파일을 생성합니다.
spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056
spec: exportNetworkFlows: netFlow: collectors: - 192.168.1.99:2056
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 네트워크 흐름 수집기를 사용하여 CNO를 구성합니다.
oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
$ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
일반적으로 검증은 필요하지 않습니다. 다음 명령을 실행하여 각 노드의 OVS(Open vSwitch)가 하나 이상의 컬렉터에 네트워크 흐름 레코드를 전송하도록 구성되어 있는지 확인할 수 있습니다.
Operator 구성을 보고
exportNetworkFlows
필드가 구성되었는지 확인합니다.oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"
$ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"netFlow":{"collectors":["192.168.1.99:2056"]}}
{"netFlow":{"collectors":["192.168.1.99:2056"]}}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 각 노드에서 OVS의 네트워크 흐름 구성을 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.3. 네트워크 흐름 수집기의 모든 대상 삭제 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 네트워크 흐름 수집기로 네트워크 흐름 메타데이터를 중지하도록 CNO(Cluster Network Operator)를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다.
프로세스
모든 네트워크 흐름 수집기를 제거합니다.
oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'
$ oc patch network.operator cluster --type='json' \ -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17장. 하이브리드 네트워킹 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Linux 및 Windows 노드에서 각각 Linux 및 Windows 워크로드를 호스팅할 수 있도록 Red Hat OpenShift Networking OVN-Kubernetes 네트워크 플러그인을 구성할 수 있습니다.
17.1. OVN-Kubernetes로 하이브리드 네트워킹 구성 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes 네트워크 플러그인에서 하이브리드 네트워킹을 사용하도록 클러스터를 구성할 수 있습니다. 이를 통해 다양한 노드 네트워킹 구성을 지원하는 하이브리드 클러스터를 사용할 수 있습니다.
이 구성은 동일한 클러스터에서 Linux 및 Windows 노드를 모두 실행하려면 필요합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 클러스터에 로그인합니다. - 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인합니다.
프로세스
OVN-Kubernetes 하이브리드 네트워크 오버레이를 구성하려면 다음 명령을 입력합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
cidr
- 추가 오버레이 네트워크의 노드에 사용되는 CIDR 구성을 지정합니다. 이 CIDR은 클러스터 네트워크 CIDR과 겹치지 않아야 합니다.
hostPrefix
-
각 개별 노드에 할당할 서브넷 접두사 길이를 지정합니다. 예를 들어
hostPrefix
를23
으로 설정하면 지정된cidr
이외/23
서브넷이 각 노드에 할당되어 510(2^(32 - 23) - 2) Pod IP 주소가 허용됩니다. 외부 네트워크에서 노드에 액세스해야 하는 경우 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다. hybridOverlayVXLANPort
-
추가 오버레이 네트워크에 대한 사용자 정의 VXLAN 포트를 지정합니다. 이는 vSphere에 설치된 클러스터에서 Windows 노드를 실행해야 하며 다른 클라우드 공급자에 대해 구성해서는 안 됩니다. 사용자 정의 포트는 기본
4789
포트를 제외한 모든 오픈 포트일 수 있습니다. 이 요구 사항에 대한 자세한 내용은 호스트 간의 포드 투 포트 연결 중단에 대한 Microsoft 문서를 참조하십시오.
출력 예
network.operator.openshift.io/cluster patched
network.operator.openshift.io/cluster patched
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 업데이트가 적용되려면 몇 분 정도 걸릴 수 있습니다.
oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"
$ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"
Copy 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.