OVN-Kubernetes 네트워크 플러그인


OpenShift Container Platform 4.19

OpenShift Container Platform의 OVN-Kubernetes 네트워크 플러그인에 대한 심층적인 구성 및 문제 해결

Red Hat OpenShift Documentation Team

초록

이 문서에서는 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 플러그인을 사용하는 클러스터는 각 노드에서 Open vSwitch(OVS)도 실행합니다. OVN은 각 노드에서 선언된 네트워크 구성을 구현하도록 OVS를 구성합니다.

참고

OVN-Kubernetes는 OpenShift Container Platform과 단일 노드 OpenShift 배포를 위한 기본 네트워킹 솔루션입니다.

OVS 프로젝트에서 파생된 OVN-Kubernetes는 오픈 플로우 규칙 등 동일한 구조를 많이 사용하여 패킷이 네트워크를 통해 전송되는 방식을 결정합니다. 자세한 내용은 Open Virtual Network 웹사이트를 참조하세요.

OVN-Kubernetes는 가상 네트워크 구성을 OpenFlow 규칙으로 변환하는 OVS용 데몬 시리즈입니다. OpenFlow 는 네트워크 스위치 및 라우터와 통신하기 위한 프로토콜로, 네트워크 장치에서 네트워크 트래픽 흐름을 원격으로 제어할 수 있는 수단을 제공합니다. 즉, 네트워크 관리자는 네트워크 트래픽 흐름을 구성, 관리하고 감시할 수 있습니다.

OVN-Kubernetes는 OpenFlow 에서 사용할 수 없는 고급 기능을 더 많이 제공합니다. OVN은 분산 가상 라우팅, 분산 논리 스위치, 액세스 제어, DHCP(동적 호스트 구성 프로토콜), DNS를 지원합니다. OVN은 개방형 흐름과 동일한 논리 흐름 내에서 분산 가상 라우팅을 구현합니다. 예를 들어, 네트워크의 DHCP 서버로 DHCP 요청을 보내는 포드가 있는 경우, 요청의 논리 흐름 규칙은 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) 대신 Generic Network Virtualization Encapsulation(Geneve) 프로토콜을 사용합니다.

OVN-Kubernetes 네트워크 플러그인은 다음 기능을 지원합니다.

  • Linux와 Microsoft Windows 워크로드를 모두 실행할 수 있는 하이브리드 클러스터입니다. 이러한 환경을 하이브리드 네트워킹 이라고 합니다.
  • 호스트 중앙 처리 장치(CPU)에서 호환되는 네트워크 카드와 데이터 처리 장치(DPU)로 네트워크 데이터 처리를 오프로드합니다. 이것을 하드웨어 오프로딩 이라고 합니다.
  • 베어 메탈, VMware vSphere, IBM Power®, IBM Z® 및 Red Hat OpenStack Platform(RHOSP) 플랫폼에서 IPv4 기본 듀얼 스택 네트워킹을 지원합니다.
  • RHOSP 및 베어 메탈 플랫폼에서의 IPv6 단일 스택 네트워킹.
  • 베어 메탈, VMware vSphere 또는 RHOSP 플랫폼에서 실행되는 클러스터를 위한 IPv6 기본 듀얼 스택 네트워킹입니다.
  • 탈출 방화벽 장치 및 탈출 IP 주소.
  • 리다이렉트 모드로 작동하는 출구 라우터 장치.
  • 클러스터 내부 통신의 IPsec 암호화.

Red Hat은 OVN-Kubernetes 네트워크 플러그인을 사용하는 다음의 설치 후 구성을 지원하지 않습니다.

  • NMState 연산자를 사용하여 인터페이스에 대한 본딩을 구성하는 것을 포함하여 기본 네트워크 인터페이스를 구성합니다.
  • Open vSwitch(OVS) 또는 OVN-Kubernetes br-ex 브리지 네트워크를 사용하는 네트워크 장치에서 하위 인터페이스나 추가 네트워크 인터페이스를 구성합니다.
  • 기본 네트워크 인터페이스에 추가 가상 LAN(VLAN)을 생성합니다.
  • 클러스터 설치 중에 노드에 대해 생성한 eth0 또는 bond0 과 같은 기본 네트워크 인터페이스를 사용하여 추가적인 보조 네트워크를 생성합니다.

Red Hat은 OVN-Kubernetes 네트워크 플러그인을 사용하는 다음과 같은 설치 후 구성을 지원합니다.

  • 클러스터 설치 중에 노드에 대한 VLAN으로 기본 네트워크 인터페이스를 구성한 경우 eth0.100 과 같은 기본 물리적 인터페이스에서 추가 VLAN을 생성합니다. 이 방법은 Open vSwitch(OVS) 브리지가 eth0.100 과 같은 초기 VLAN 하위 인터페이스에 연결되어 새로운 구성에 기본 물리적 인터페이스를 사용할 수 있도록 하기 때문에 가능합니다.
  • 로컬 넷 토폴로지 네트워크로 추가 OVN 보조 네트워크를 생성하려면 NodeNetworkConfigurationPolicy (NNCP) 개체에서 보조 네트워크를 정의해야 합니다. 네트워크를 생성한 후에는 Pod 또는 가상 머신(VM)을 네트워크에 연결할 수 있습니다. 이러한 보조 네트워크는 VLAN 태그를 사용할 수도 있고 사용하지 않을 수도 있는 물리적 네트워크에 전용 연결을 제공합니다. 호스트에 필수 설정(필수 네트워크 설정 등)이 없는 노드의 호스트 네트워크에서는 이러한 네트워크에 액세스할 수 없습니다.

1.2. OVN-Kubernetes IPv6 및 듀얼 스택 제한

OVN-Kubernetes 네트워크 플러그인에는 다음과 같은 제한 사항이 있습니다.

  • 듀얼 스택 네트워킹을 위해 구성된 클러스터의 경우 IPv4 및 IPv6 트래픽은 모두 기본 게이트웨이와 동일한 네트워크 인터페이스를 사용해야 합니다.

    이 요구 사항이 충족되지 않으면 ovnkube-node 데몬 세트의 호스트에 있는 포드가 CrashLoopBackOff 상태로 전환됩니다.

    oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml 과 같은 명령으로 포드를 표시하는 경우 다음 출력에서 볼 수 있듯이 상태 필드에 기본 게이트웨이에 대한 두 개 이상의 메시지가 표시됩니다.

    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 Toggle word wrap

    유일한 해결책은 호스트 네트워킹을 재구성하여 두 IP 제품군 모두 기본 게이트웨이에 대해 동일한 네트워크 인터페이스를 사용하도록 하는 것입니다.

  • 듀얼 스택 네트워킹을 위해 구성된 클러스터의 경우 IPv4 및 IPv6 라우팅 테이블에 모두 기본 게이트웨이가 포함되어야 합니다.

    이 요구 사항이 충족되지 않으면 ovnkube-node 데몬 세트의 호스트에 있는 포드가 CrashLoopBackOff 상태로 전환됩니다.

    oc get pod -n openshift-ovn-kubernetes -l app=ovnkube-node -o yaml 과 같은 명령으로 포드를 표시하는 경우 다음 출력에서 볼 수 있듯이 상태 필드에 기본 게이트웨이에 대한 두 개 이상의 메시지가 표시됩니다.

    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 Toggle word wrap

    유일한 해결책은 호스트 네트워킹을 재구성하여 두 IP 제품군 모두에 기본 게이트웨이가 포함되도록 하는 것입니다.

  • 클러스터의 MachineConfig 사용자 정의 리소스(CR)의 kernelArgument 섹션에서 ipv6.disable 매개변수를 1 로 설정하면 OVN-Kubernetes Pod가 CrashLoopBackOff 상태로 전환됩니다. 또한 네트워크 운영자가 저하된 상태로 남아 있기 때문에 클러스터를 OpenShift Container Platform의 최신 버전으로 업데이트하는 데 실패합니다. Red Hat은 클러스터에 대한 IPv6 주소 비활성화를 지원하지 않으므로 ipv6.disable 매개변수를 1 로 설정하지 마세요.

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) - OVN 통합을 위한 CMS 특정 플러그인을 제공하는 OVN용 플랫폼 특정 클라이언트입니다. 이 플러그인은 CMS 구성 데이터베이스에 CMS 특정 형식으로 저장된 논리적 네트워크 구성에 대한 클라우드 관리 시스템의 개념을 OVN이 이해하는 중간 표현으로 변환합니다.
  • OVN Northbound 데이터베이스( nbdb ) 컨테이너 - CMS 플러그인에서 전달된 논리적 네트워크 구성을 저장합니다.
  • OVN Southbound 데이터베이스( sbdb ) 컨테이너 - 각 노드의 Open vSwitch(OVS) 시스템에 대한 물리적 및 논리적 네트워크 구성 상태를 저장하며, 이를 바인딩하는 테이블도 포함합니다.
  • OVN 북쪽 데몬( ovn-northd ) - 이것은 nbdb 컨테이너와 sbdb 컨테이너 사이의 중개 클라이언트입니다. nbdb 컨테이너에서 가져온 기존 네트워크 개념에 따른 논리적 네트워크 구성을 sbdb 컨테이너의 논리적 데이터 경로 흐름으로 변환합니다. ovn-northd 데몬의 컨테이너 이름은 northd 이고 ovnkube-node 포드에서 실행됩니다.
  • ovn-controller - OVS 및 하이퍼바이저와 상호 작용하여 sbdb 컨테이너에 필요한 정보나 업데이트를 제공하는 OVN 에이전트입니다. ovn-controller는 sbdb 컨테이너에서 논리적 흐름을 읽고, 이를 OpenFlow 흐름으로 변환한 후 노드의 OVS 데몬으로 전송합니다. 컨테이너 이름은 ovn-controller 이고 ovnkube-node 포드에서 실행됩니다.

OVN northd, northbound 데이터베이스, southbound 데이터베이스는 클러스터의 각 노드에서 실행되며 대부분 해당 노드에 대한 로컬 정보를 포함하고 처리합니다.

OVN 북쪽 데이터베이스에는 클라우드 관리 시스템(CMS)을 통해 전달된 논리적 네트워크 구성이 있습니다. OVN 북쪽 데이터베이스에는 네트워크의 현재 원하는 상태가 포함되어 있으며, 이는 논리적 포트, 논리적 스위치, 논리적 라우터 등의 컬렉션으로 표현됩니다. ovn-northd ( northd 컨테이너)는 OVN 북쪽 데이터베이스와 OVN 남쪽 데이터베이스에 연결됩니다. 이는 OVN 북쪽 데이터베이스에서 가져온 기존 네트워크 개념에 따른 논리적 네트워크 구성을 OVN 남쪽 데이터베이스의 논리적 데이터 경로 흐름으로 변환합니다.

OVN 남쪽 방향 데이터베이스에는 네트워크의 물리적, 논리적 표현과 이를 연결하는 바인딩 테이블이 있습니다. 여기에는 노드의 섀시 정보와 클러스터의 다른 노드에 연결하는 데 필요한 원격 전송 스위치 포트와 같은 기타 구성 요소가 포함됩니다. OVN 남쪽 데이터베이스에는 모든 논리 흐름도 포함되어 있습니다. 논리 흐름은 각 노드에서 실행되는 ovn-controller 프로세스와 공유되고, ovn-controller는 이를 Open vSwitch (OVS)를 프로그래밍하기 위한 OpenFlow 규칙으로 변환합니다.

Kubernetes 제어 평면 노드에는 클러스터의 각 노드에 대한 중앙 IP 주소 관리(IPAM) 할당을 수행하는 별도 노드에 두 개의 ovnkube-control-plane 포드가 포함되어 있습니다. 언제나 단일 ovnkube-control-plane 포드가 리더입니다.

2.2. OVN-Kubernetes 프로젝트의 모든 리소스 나열

OVN-Kubernetes 프로젝트에서 실행되는 리소스와 컨테이너를 찾는 것은 OVN-Kubernetes 네트워킹 구현을 이해하는 데 중요합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 OVN-Kubernetes 프로젝트의 모든 리소스, 엔드포인트 및 ConfigMap을 가져옵니다.

    $ oc get all,ep,cm -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    Warning: apps.openshift.io/v1 DeploymentConfig is deprecated in v4.14+, unavailable in v4.10000+
    NAME                                         READY   STATUS    RESTARTS       AGE
    pod/ovnkube-control-plane-65c6f55656-6d55h   2/2     Running   0              114m
    pod/ovnkube-control-plane-65c6f55656-fd7vw   2/2     Running   2 (104m ago)   114m
    pod/ovnkube-node-bcvts                       8/8     Running   0              113m
    pod/ovnkube-node-drgvv                       8/8     Running   0              113m
    pod/ovnkube-node-f2pxt                       8/8     Running   0              113m
    pod/ovnkube-node-frqsb                       8/8     Running   0              105m
    pod/ovnkube-node-lbxkk                       8/8     Running   0              105m
    pod/ovnkube-node-tt7bx                       8/8     Running   1 (102m ago)   105m
    
    NAME                                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)             AGE
    service/ovn-kubernetes-control-plane   ClusterIP   None         <none>        9108/TCP            114m
    service/ovn-kubernetes-node            ClusterIP   None         <none>        9103/TCP,9105/TCP   114m
    
    NAME                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
    daemonset.apps/ovnkube-node   6         6         6       6            6           beta.kubernetes.io/os=linux   114m
    
    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/ovnkube-control-plane   3/3     3            3           114m
    
    NAME                                               DESIRED   CURRENT   READY   AGE
    replicaset.apps/ovnkube-control-plane-65c6f55656   3         3         3       114m
    
    NAME                                     ENDPOINTS                                               AGE
    endpoints/ovn-kubernetes-control-plane   10.0.0.3:9108,10.0.0.4:9108,10.0.0.5:9108               114m
    endpoints/ovn-kubernetes-node            10.0.0.3:9105,10.0.0.4:9105,10.0.0.5:9105 + 9 more...   114m
    
    NAME                                 DATA   AGE
    configmap/control-plane-status       1      113m
    configmap/kube-root-ca.crt           1      114m
    configmap/openshift-service-ca.crt   1      114m
    configmap/ovn-ca                     1      114m
    configmap/ovnkube-config             1      114m
    configmap/signer-ca                  1      114m
    Copy to Clipboard Toggle word wrap

    클러스터의 각 노드에는 ovnkube-node 포드가 하나씩 있습니다. ovnkube-config 구성 맵에는 OpenShift Container Platform OVN-Kubernetes 구성이 있습니다.

  2. 다음 명령을 실행하여 ovnkube-node 포드의 모든 컨테이너를 나열합니다.

    $ oc get pods ovnkube-node-bcvts -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    예상 출력

    ovn-controller ovn-acl-logging kube-rbac-proxy-node kube-rbac-proxy-ovn-metrics northd nbdb sbdb ovnkube-controller
    Copy to Clipboard Toggle word wrap

    ovnkube-node 포드는 여러 개의 컨테이너로 구성됩니다. 북쪽 방향 데이터베이스( nbdb 컨테이너), 남쪽 방향 데이터베이스( sbdb 컨테이너), 북쪽 데몬( northd 컨테이너), ovn-controllerovnkube-controller 컨테이너를 호스팅하는 역할을 합니다. ovnkube-controller 컨테이너는 포드, 송신 IP, 네임스페이스, 서비스, 엔드포인트, 송신 방화벽, 네트워크 정책과 같은 API 객체를 감시합니다. 또한 해당 노드에 사용 가능한 서브넷 풀에서 Pod IP를 할당하는 역할도 합니다.

  3. 다음 명령을 실행하여 ovnkube-control-plane 포드의 모든 컨테이너를 나열합니다.

    $ oc get pods ovnkube-control-plane-65c6f55656-6d55h -o jsonpath='{.spec.containers[*].name}' -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    예상 출력

    kube-rbac-proxy ovnkube-cluster-manager
    Copy to Clipboard Toggle word wrap

    ovnkube-control-plane 포드에는 각 OpenShift Container Platform 노드에 상주하는 컨테이너( ovnkube-cluster-manager )가 있습니다. ovnkube-cluster-manager 컨테이너는 클러스터의 각 노드에 Pod 서브넷, 전송 스위치 서브넷 IP, 조인 스위치 서브넷 IP를 할당합니다. kube-rbac-proxy 컨테이너는 ovnkube-cluster-manager 컨테이너의 메트릭을 모니터링합니다.

2.3. OVN-Kubernetes 북쪽 데이터베이스 콘텐츠 나열

각 노드는 해당 노드의 ovnkube-node 포드에서 실행되는 ovnkube-controller 컨테이너에 의해 제어됩니다. OVN 논리적 네트워킹 엔터티를 이해하려면 해당 노드의 ovnkube-node 포드 내부에서 컨테이너로 실행되는 북쪽 데이터베이스를 조사하여 보고자 하는 노드에 어떤 개체가 있는지 확인해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
프로세스

클러스터에서 ovn nbctl 또는 sbctl 명령을 실행하려면 해당 노드의 nbdb 또는 sbdb 컨테이너에 원격 셸을 열어야 합니다.

  1. 다음 명령을 실행하여 포드를 나열하세요.

    $ oc get po -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS      AGE
    ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m
    ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m
    ovnkube-node-55xs2                       8/8     Running   0             26m
    ovnkube-node-7r84r                       8/8     Running   0             16m
    ovnkube-node-bqq8p                       8/8     Running   0             17m
    ovnkube-node-mkj4f                       8/8     Running   0             26m
    ovnkube-node-mlr8k                       8/8     Running   0             26m
    ovnkube-node-wqn2m                       8/8     Running   0             16m
    Copy to Clipboard Toggle word wrap

  2. 선택 사항: 노드 정보와 함께 포드를 나열하려면 다음 명령을 실행하세요.

    $ oc get pods -n openshift-ovn-kubernetes -owide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
    ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
    ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
    ovnkube-node-55xs2                       8/8     Running   0             26m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
    ovnkube-node-7r84r                       8/8     Running   0             17m   10.0.128.3   ci-ln-t487nnb-72292-mdcnq-worker-b-wbz7z   <none>           <none>
    ovnkube-node-bqq8p                       8/8     Running   0             17m   10.0.128.2   ci-ln-t487nnb-72292-mdcnq-worker-a-lh7ms   <none>           <none>
    ovnkube-node-mkj4f                       8/8     Running   0             27m   10.0.0.5     ci-ln-t487nnb-72292-mdcnq-master-0         <none>           <none>
    ovnkube-node-mlr8k                       8/8     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
    ovnkube-node-wqn2m                       8/8     Running   0             17m   10.0.128.4   ci-ln-t487nnb-72292-mdcnq-worker-c-przlm   <none>           <none>
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 북쪽 방향의 데이터베이스를 살펴보려면 포드로 이동하세요.

    $ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 북쪽 데이터베이스의 모든 객체를 표시합니다.

    $ ovn-nbctl show
    Copy to Clipboard Toggle word wrap

    출력 내용이 너무 길어서 여기에 모두 나열할 수 없습니다. 목록에는 NAT 규칙, 논리 스위치, 로드 밸런서 등이 포함됩니다.

    다음 선택적 명령을 사용하면 특정 구성 요소를 좁히고 집중적으로 살펴볼 수 있습니다.

    1. 다음 명령을 실행하여 논리 라우터 목록을 표시합니다.

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c northd -- ovn-nbctl lr-list
      Copy to Clipboard Toggle word wrap

      출력 예

      45339f4f-7d0b-41d0-b5f9-9fca9ce40ce6 (GR_ci-ln-t487nnb-72292-mdcnq-master-2)
      96a0a0f0-e7ed-4fec-8393-3195563de1b8 (ovn_cluster_router)
      Copy to Clipboard Toggle word wrap

      참고

      이 출력에서 각 노드에 라우터가 있고 ovn_cluster_router 가 있는 것을 볼 수 있습니다.

    2. 다음 명령을 실행하여 논리 스위치 목록을 표시합니다.

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c nbdb -- ovn-nbctl ls-list
      Copy to Clipboard Toggle word wrap

      출력 예

      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 Toggle word wrap

      참고

      이 출력에서 각 노드에 대한 ext 스위치, 노드 이름을 가진 스위치, join 스위치가 있음을 알 수 있습니다.

    3. 다음 명령을 실행하여 로드 밸런서 목록을 표시합니다.

      $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
      -c nbdb -- ovn-nbctl lb-list
      Copy to Clipboard Toggle word wrap

      출력 예

      UUID                                    LB                  PROTO      VIP                     IPs
      7c84c673-ed2a-4436-9a1f-9bc5dd181eea    Service_default/    tcp        172.30.0.1:443          10.0.0.3:6443,169.254.169.2:6443,10.0.0.5:6443
      4d663fd9-ddc8-4271-b333-4c0e279e20bb    Service_default/    tcp        172.30.0.1:443          10.0.0.3:6443,10.0.0.4:6443,10.0.0.5:6443
      292eb07f-b82f-4962-868a-4f541d250bca    Service_openshif    tcp        172.30.105.247:443      10.129.0.12:8443
      034b5a7f-bb6a-45e9-8e6d-573a82dc5ee3    Service_openshif    tcp        172.30.192.38:443       10.0.0.3:10259,10.0.0.4:10259,10.0.0.5:10259
      a68bb53e-be84-48df-bd38-bdd82fcd4026    Service_openshif    tcp        172.30.161.125:8443     10.129.0.32:8443
      6cc21b3d-2c54-4c94-8ff5-d8e017269c2e    Service_openshif    tcp        172.30.3.144:443        10.129.0.22:8443
      37996ffd-7268-4862-a27f-61cd62e09c32    Service_openshif    tcp        172.30.181.107:443      10.129.0.18:8443
      81d4da3c-f811-411f-ae0c-bc6713d0861d    Service_openshif    tcp        172.30.228.23:443       10.129.0.29:8443
      ac5a4f3b-b6ba-4ceb-82d0-d84f2c41306e    Service_openshif    tcp        172.30.14.240:9443      10.129.0.36:9443
      c88979fb-1ef5-414b-90ac-43b579351ac9    Service_openshif    tcp        172.30.231.192:9001     10.128.0.5:9001,10.128.2.5:9001,10.129.0.5:9001,10.129.2.4:9001,10.130.0.3:9001,10.131.0.3:9001
      fcb0a3fb-4a77-4230-a84a-be45dce757e8    Service_openshif    tcp        172.30.189.92:443       10.130.0.17:8440
      67ef3e7b-ceb9-4bf0-8d96-b43bde4c9151    Service_openshif    tcp        172.30.67.218:443       10.129.0.9:8443
      d0032fba-7d5e-424a-af25-4ab9b5d46e81    Service_openshif    tcp        172.30.102.137:2379     10.0.0.3:2379,10.0.0.4:2379,10.0.0.5:2379
                                                                  tcp        172.30.102.137:9979     10.0.0.3:9979,10.0.0.4:9979,10.0.0.5:9979
      7361c537-3eec-4e6c-bc0c-0522d182abd4    Service_openshif    tcp        172.30.198.215:9001     10.0.0.3:9001,10.0.0.4:9001,10.0.0.5:9001,10.0.128.2:9001,10.0.128.3:9001,10.0.128.4:9001
      0296c437-1259-410b-a6fd-81c310ad0af5    Service_openshif    tcp        172.30.198.215:9001     10.0.0.3:9001,169.254.169.2:9001,10.0.0.5:9001,10.0.128.2:9001,10.0.128.3:9001,10.0.128.4:9001
      5d5679f5-45b8-479d-9f7c-08b123c688b8    Service_openshif    tcp        172.30.38.253:17698     10.128.0.52:17698,10.129.0.84:17698,10.130.0.60:17698
      2adcbab4-d1c9-447d-9573-b5dc9f2efbfa    Service_openshif    tcp        172.30.148.52:443       10.0.0.4:9202,10.0.0.5:9202
                                                                  tcp        172.30.148.52:444       10.0.0.4:9203,10.0.0.5:9203
                                                                  tcp        172.30.148.52:445       10.0.0.4:9204,10.0.0.5:9204
                                                                  tcp        172.30.148.52:446       10.0.0.4:9205,10.0.0.5:9205
      2a33a6d7-af1b-4892-87cc-326a380b809b    Service_openshif    tcp        172.30.67.219:9091      10.129.2.16:9091,10.131.0.16:9091
                                                                  tcp        172.30.67.219:9092      10.129.2.16:9092,10.131.0.16:9092
                                                                  tcp        172.30.67.219:9093      10.129.2.16:9093,10.131.0.16:9093
                                                                  tcp        172.30.67.219:9094      10.129.2.16:9094,10.131.0.16:9094
      f56f59d7-231a-4974-99b3-792e2741ec8d    Service_openshif    tcp        172.30.89.212:443       10.128.0.41:8443,10.129.0.68:8443,10.130.0.44:8443
      08c2c6d7-d217-4b96-b5d8-c80c4e258116    Service_openshif    tcp        172.30.102.137:2379     10.0.0.3:2379,169.254.169.2:2379,10.0.0.5:2379
                                                                  tcp        172.30.102.137:9979     10.0.0.3:9979,169.254.169.2:9979,10.0.0.5:9979
      60a69c56-fc6a-4de6-bd88-3f2af5ba5665    Service_openshif    tcp        172.30.10.193:443       10.129.0.25:8443
      ab1ef694-0826-4671-a22c-565fc2d282ec    Service_openshif    tcp        172.30.196.123:443      10.128.0.33:8443,10.129.0.64:8443,10.130.0.37:8443
      b1fb34d3-0944-4770-9ee3-2683e7a630e2    Service_openshif    tcp        172.30.158.93:8443      10.129.0.13:8443
      95811c11-56e2-4877-be1e-c78ccb3a82a9    Service_openshif    tcp        172.30.46.85:9001       10.130.0.16:9001
      4baba1d1-b873-4535-884c-3f6fc07a50fd    Service_openshif    tcp        172.30.28.87:443        10.129.0.26:8443
      6c2e1c90-f0ca-484e-8a8e-40e71442110a    Service_openshif    udp        172.30.0.10:53          10.128.0.13:5353,10.128.2.6:5353,10.129.0.39:5353,10.129.2.6:5353,10.130.0.11:5353,10.131.0.9:5353
      Copy to Clipboard Toggle word wrap

      참고

      잘린 출력에서 많은 OVN-Kubernetes 로드 밸런서가 있음을 알 수 있습니다. OVN-Kubernetes의 로드 밸런서는 서비스를 나타냅니다.

  5. ovn-nbctl 명령으로 사용할 수 있는 옵션을 표시하려면 다음 명령을 실행하세요.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
    -c nbdb ovn-nbctl --help
    Copy to Clipboard Toggle word wrap

다음 표에서는 ovn-nbctl 과 함께 사용하여 북쪽 데이터베이스의 내용을 조사할 수 있는 명령줄 인수를 설명합니다.

참고

내용을 보고 싶은 포드에서 원격 셸을 열고 ovn-nbctl 명령을 실행합니다.

Expand
표 2.1. 북쪽 데이터베이스 내용을 조사하기 위한 명령줄 인수
인수설명

ovn-nbctl 쇼

특정 노드에서 본 북쪽 방향 데이터베이스 콘텐츠의 개요입니다.

ovn-nbctl show <switch_or_router>

지정된 스위치나 라우터와 관련된 세부 정보를 표시합니다.

ovn-nbctl lr-list

논리적 라우터를 보여줍니다.

ovn-nbctl lrp-list <router>

ovn-nbctl lr-list 의 라우터 정보를 사용하여 라우터 포트를 표시합니다.

ovn-nbctl lr-nat-list <router>

지정된 라우터에 대한 네트워크 주소 변환 세부 정보를 표시합니다.

ovn-nbctl ls-list

논리적 스위치 표시

ovn-nbctl lsp-list <switch>

ovn-nbctl ls-list 의 스위치 정보를 사용하여 스위치 포트를 표시합니다.

ovn-nbctl lsp-get-type <port>

논리 포트의 유형을 가져옵니다.

ovn-nbctl lb-list

로드 밸런서를 표시합니다.

2.5. OVN-Kubernetes 사우스바운드 데이터베이스 콘텐츠 나열

각 노드는 해당 노드의 ovnkube-node 포드에서 실행되는 ovnkube-controller 컨테이너에 의해 제어됩니다. OVN 논리적 네트워킹 엔터티를 이해하려면 해당 노드의 ovnkube-node 포드 내부에서 컨테이너로 실행되는 북쪽 데이터베이스를 조사하여 보고자 하는 노드에 어떤 개체가 있는지 확인해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
프로세스

클러스터에서 ovn nbctl 또는 sbctl 명령을 실행하려면 해당 노드의 nbdb 또는 sbdb 컨테이너에 원격 셸을 열어야 합니다.

  1. 다음 명령을 실행하여 포드를 나열합니다.

    $ oc get po -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS      AGE
    ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m
    ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m
    ovnkube-node-55xs2                       8/8     Running   0             26m
    ovnkube-node-7r84r                       8/8     Running   0             16m
    ovnkube-node-bqq8p                       8/8     Running   0             17m
    ovnkube-node-mkj4f                       8/8     Running   0             26m
    ovnkube-node-mlr8k                       8/8     Running   0             26m
    ovnkube-node-wqn2m                       8/8     Running   0             16m
    Copy to Clipboard Toggle word wrap

  2. 선택 사항: 노드 정보와 함께 포드를 나열하려면 다음 명령을 실행하세요.

    $ oc get pods -n openshift-ovn-kubernetes -owide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
    ovnkube-control-plane-8444dff7f9-4lh9k   2/2     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
    ovnkube-control-plane-8444dff7f9-5rjh9   2/2     Running   0             27m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
    ovnkube-node-55xs2                       8/8     Running   0             26m   10.0.0.4     ci-ln-t487nnb-72292-mdcnq-master-2         <none>           <none>
    ovnkube-node-7r84r                       8/8     Running   0             17m   10.0.128.3   ci-ln-t487nnb-72292-mdcnq-worker-b-wbz7z   <none>           <none>
    ovnkube-node-bqq8p                       8/8     Running   0             17m   10.0.128.2   ci-ln-t487nnb-72292-mdcnq-worker-a-lh7ms   <none>           <none>
    ovnkube-node-mkj4f                       8/8     Running   0             27m   10.0.0.5     ci-ln-t487nnb-72292-mdcnq-master-0         <none>           <none>
    ovnkube-node-mlr8k                       8/8     Running   0             27m   10.0.0.3     ci-ln-t487nnb-72292-mdcnq-master-1         <none>           <none>
    ovnkube-node-wqn2m                       8/8     Running   0             17m   10.0.128.4   ci-ln-t487nnb-72292-mdcnq-worker-c-przlm   <none>           <none>
    Copy to Clipboard Toggle word wrap

  3. 남쪽 방향 데이터베이스를 보려면 포드로 이동하세요.

    $ oc rsh -c sbdb -n openshift-ovn-kubernetes ovnkube-node-55xs2
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 southbound 데이터베이스에 있는 모든 객체를 표시합니다.

    $ ovn-sbctl show
    Copy to Clipboard Toggle word wrap

    출력 예

    Chassis "5db31703-35e9-413b-8cdf-69e7eecb41f7"
        hostname: ci-ln-9gp362t-72292-v2p94-worker-a-8bmwz
        Encap geneve
            ip: "10.0.128.4"
            options: {csum="true"}
        Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-worker-a-8bmwz
    Chassis "070debed-99b7-4bce-b17d-17e720b7f8bc"
        hostname: ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Encap geneve
            ip: "10.0.128.2"
            options: {csum="true"}
        Port_Binding k8s-ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding rtoe-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding openshift-monitoring_alertmanager-main-1
        Port_Binding rtoj-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding etor-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding cr-rtos-ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding openshift-e2e-loki_loki-promtail-qcrcz
        Port_Binding jtor-GR_ci-ln-9gp362t-72292-v2p94-worker-b-svmp6
        Port_Binding openshift-multus_network-metrics-daemon-mkd4t
        Port_Binding openshift-ingress-canary_ingress-canary-xtvj4
        Port_Binding openshift-ingress_router-default-6c76cbc498-pvlqk
        Port_Binding openshift-dns_dns-default-zz582
        Port_Binding openshift-monitoring_thanos-querier-57585899f5-lbf4f
        Port_Binding openshift-network-diagnostics_network-check-target-tn228
        Port_Binding openshift-monitoring_prometheus-k8s-0
        Port_Binding openshift-image-registry_image-registry-68899bd877-xqxjj
    Chassis "179ba069-0af1-401c-b044-e5ba90f60fea"
        hostname: ci-ln-9gp362t-72292-v2p94-master-0
        Encap geneve
            ip: "10.0.0.5"
            options: {csum="true"}
        Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-0
    Chassis "68c954f2-5a76-47be-9e84-1cb13bd9dab9"
        hostname: ci-ln-9gp362t-72292-v2p94-worker-c-mjf9w
        Encap geneve
            ip: "10.0.128.3"
            options: {csum="true"}
        Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-worker-c-mjf9w
    Chassis "2de65d9e-9abf-4b6e-a51d-a1e038b4d8af"
        hostname: ci-ln-9gp362t-72292-v2p94-master-2
        Encap geneve
            ip: "10.0.0.4"
            options: {csum="true"}
        Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-2
    Chassis "1d371cb8-5e21-44fd-9025-c4b162cc4247"
        hostname: ci-ln-9gp362t-72292-v2p94-master-1
        Encap geneve
            ip: "10.0.0.3"
            options: {csum="true"}
        Port_Binding tstor-ci-ln-9gp362t-72292-v2p94-master-1
    Copy to Clipboard Toggle word wrap

    이 자세한 출력은 섀시와 섀시에 연결된 포트를 보여줍니다. 이 경우 모든 라우터 포트와 호스트 네트워킹처럼 실행되는 모든 것이 표시됩니다. 모든 포드는 SNAT(소스 네트워크 주소 변환)를 사용하여 더 넓은 네트워크와 통신합니다. IP 주소는 포드가 실행 중인 노드의 IP 주소로 변환된 후 네트워크로 전송됩니다.

    사우스바운드 데이터베이스에는 섀시 정보 외에도 모든 논리 흐름이 저장되어 있으며, 해당 논리 흐름은 각 노드에서 실행되는 ovn-controller 로 전송됩니다. ovn-controller는 논리 흐름을 개방형 흐름 규칙으로 변환하고 궁극적으로 OpenvSwitch를 프로그래밍하여 포드가 개방형 흐름 규칙을 따르고 네트워크에서 벗어날 수 있도록 합니다.

  5. ovn-sbctl 명령으로 사용할 수 있는 옵션을 표시하려면 다음 명령을 실행하세요.

    $ oc exec -n openshift-ovn-kubernetes -it ovnkube-node-55xs2 \
    -c sbdb ovn-sbctl --help
    Copy to Clipboard Toggle word wrap

다음 표에서는 ovn-sbctl 과 함께 사용하여 southbound 데이터베이스의 내용을 조사할 수 있는 명령줄 인수를 설명합니다.

참고

내용을 보고 싶은 포드에서 원격 셸을 열고 ovn-sbctl 명령을 실행합니다.

Expand
표 2.2. 사우스바운드 데이터베이스 내용을 조사하기 위한 명령줄 인수
인수설명

ovn-sbctl 쇼

특정 노드에서 본 남쪽 방향 데이터베이스 콘텐츠의 개요입니다.

ovn-sbctl 목록 Port_Binding <포트>

지정된 포트에 대한 사우스바운드 데이터베이스의 내용을 나열합니다.

ovn-sbctl 덤프 흐름

논리적 흐름을 나열하세요.

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 주소 수가 줄어듭니다.
패치 포트가 있는 논리 스위치
패치 포트가 있는 논리적 스위치는 네트워크 스택을 가상화하는 데 사용됩니다. 그들은 터널을 통해 원격 논리 포트를 연결합니다.
로컬넷 포트가 있는 논리 스위치
로컬넷 포트가 있는 논리적 스위치는 OVN을 물리적 네트워크에 연결하는 데 사용됩니다. 로컬넷 포트를 사용하여 패킷을 직접 연결된 물리적 L2 세그먼트에 브리징하여 원격 논리 포트를 연결합니다.
패치 포트
패치 포트는 논리적 스위치와 논리적 라우터 간, 그리고 피어 논리적 라우터 간의 연결을 나타냅니다. 단일 연결에는 각 연결 지점에 패치 포트 한 쌍이 있으며, 각 측면에 하나씩 있습니다.
l3게이트웨이 포트
l3gateway 포트는 게이트웨이 라우터에서 사용되는 논리적 패치 포트에 대한 ovn-sbdb 의 포트 바인딩 항목입니다. 이러한 포트는 게이트웨이 라우터 자체와 마찬가지로 섀시에 바인딩되어 있다는 사실을 나타내기 위해 패치 포트가 아닌 l3gateway 포트라고 불립니다.
로컬넷 포트
localnet 포트는 각 ovn-controller 인스턴스에서 로컬로 접근 가능한 네트워크에 연결할 수 있도록 하는 브리지 논리 스위치에 있습니다. 이는 논리적 스위치에서 물리적 네트워크로의 직접 연결을 모델링하는 데 도움이 됩니다. 논리적 스위치에는 하나의 로컬넷 포트만 연결할 수 있습니다.

2.7.1. 로컬 호스트에 네트워크 도구 설치

OpenShift Container Platform 클러스터 네트워크 문제를 디버깅하는 데 사용할 수 있는 도구 모음을 만들려면 로컬 호스트에 network-tools를 설치하세요.

프로세스

  1. 다음 명령을 사용하여 network-tools 저장소를 워크스테이션에 복제합니다.

    $ git clone git@github.com:openshift/network-tools.git
    Copy to Clipboard Toggle word wrap
  2. 방금 복제한 저장소의 디렉토리로 변경하세요.

    $ cd network-tools
    Copy to Clipboard Toggle word wrap
  3. 선택 사항: 사용 가능한 모든 명령을 나열합니다.

    $ ./debug-scripts/network-tools -h
    Copy to Clipboard Toggle word wrap

2.7.2. 네트워크 도구 실행

network-tools를 실행하여 논리적 스위치와 라우터에 대한 정보를 얻습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 로컬 호스트에 네트워크 도구를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 라우터를 나열하세요.

    $ ./debug-scripts/network-tools ovn-db-run-command ovn-nbctl lr-list
    Copy to Clipboard Toggle word wrap

    출력 예

    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 Toggle word wrap

  2. 다음 명령을 실행하여 localnet 포트를 나열하세요.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=localnet
    Copy to Clipboard Toggle word wrap

    출력 예

    _uuid               : d05298f5-805b-4838-9224-1211afc2f199
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : f3c2c959-743b-4037-854d-26627902597c
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : br-ex_ci-ln-54932yb-72292-kd676-worker-c-rzj99
    mac                 : [unknown]
    mirror_rules        : []
    nat_addresses       : []
    options             : {network_name=physnet}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 2
    type                : localnet
    up                  : false
    virtual_parent      : []
    
    [...]
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 l3gateway 포트를 나열하세요.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=l3gateway
    Copy to Clipboard Toggle word wrap

    출력 예

    _uuid               : 5207a1f3-1cf3-42f1-83e9-387bbb06b03c
    additional_chassis  : []
    additional_encap    : []
    chassis             : ca6eb600-3a10-4372-a83e-e0d957c4cd92
    datapath            : f3c2c959-743b-4037-854d-26627902597c
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : etor-GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99
    mac                 : ["42:01:0a:00:80:04"]
    mirror_rules        : []
    nat_addresses       : ["42:01:0a:00:80:04 10.0.128.4"]
    options             : {l3gateway-chassis="84737c36-b383-4c83-92c5-2bd5b3c7e772", peer=rtoe-GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 1
    type                : l3gateway
    up                  : true
    virtual_parent      : []
    
    _uuid               : 6088d647-84f2-43f2-b53f-c9d379042679
    additional_chassis  : []
    additional_encap    : []
    chassis             : ca6eb600-3a10-4372-a83e-e0d957c4cd92
    datapath            : dc9cea00-d94a-41b8-bdb0-89d42d13aa2e
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : jtor-GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99
    mac                 : [router]
    mirror_rules        : []
    nat_addresses       : []
    options             : {l3gateway-chassis="84737c36-b383-4c83-92c5-2bd5b3c7e772", peer=rtoj-GR_ci-ln-54932yb-72292-kd676-worker-c-rzj99}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 2
    type                : l3gateway
    up                  : true
    virtual_parent      : []
    
    [...]
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 패치 포트를 나열하세요.

    $ ./debug-scripts/network-tools ovn-db-run-command \
    ovn-sbctl find Port_Binding type=patch
    Copy to Clipboard Toggle word wrap

    출력 예

    _uuid               : 785fb8b6-ee5a-4792-a415-5b1cb855dac2
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : f1ddd1cc-dc0d-43b4-90ca-12651305acec
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : stor-ci-ln-54932yb-72292-kd676-worker-c-rzj99
    mac                 : [router]
    mirror_rules        : []
    nat_addresses       : ["0a:58:0a:80:02:01 10.128.2.1 is_chassis_resident(\"cr-rtos-ci-ln-54932yb-72292-kd676-worker-c-rzj99\")"]
    options             : {peer=rtos-ci-ln-54932yb-72292-kd676-worker-c-rzj99}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 1
    type                : patch
    up                  : false
    virtual_parent      : []
    
    _uuid               : c01ff587-21a5-40b4-8244-4cd0425e5d9a
    additional_chassis  : []
    additional_encap    : []
    chassis             : []
    datapath            : f6795586-bf92-4f84-9222-efe4ac6a7734
    encap               : []
    external_ids        : {}
    gateway_chassis     : []
    ha_chassis_group    : []
    logical_port        : rtoj-ovn_cluster_router
    mac                 : ["0a:58:64:40:00:01 100.64.0.1/16"]
    mirror_rules        : []
    nat_addresses       : []
    options             : {peer=jtor-ovn_cluster_router}
    parent_port         : []
    port_security       : []
    requested_additional_chassis: []
    requested_chassis   : []
    tag                 : []
    tunnel_key          : 1
    type                : patch
    up                  : false
    virtual_parent      : []
    [...]
    Copy to Clipboard Toggle word wrap

3장. OVN-Kubernetes 문제 해결

OVN-Kubernetes에는 다양한 기본 제공 상태 점검 및 로그 소스가 있습니다. 이 섹션의 지침에 따라 클러스터를 검사하세요. 지원 사례가 필요한 경우 지원 가이드 에 따라 필수 수집을 통해 추가 정보를 수집하세요. 지원팀의 지시가 있을 때에만 --gather_network_logs를 사용하세요.

3.1. 준비 프로브를 사용하여 OVN-Kubernetes 상태 모니터링

ovnkube-control-planeovnkube-node 포드에는 준비 프로브가 구성된 컨테이너가 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • jq를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 ovnkube-node 준비 프로브의 세부 정보를 검토하세요.

    $ oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node \
    -o json | jq '.items[0].spec.containers[] | .name,.readinessProbe'
    Copy to Clipboard Toggle word wrap

    ovnkube-node 포드의 북쪽 및 남쪽 데이터베이스 컨테이너에 대한 준비 프로브는 데이터베이스와 ovnkube-controller 컨테이너의 상태를 확인합니다.

    ovnkube-node 포드의 ovnkube-controller 컨테이너에는 OVN-Kubernetes CNI 구성 파일의 존재 여부를 확인하는 준비 프로브가 있습니다. 해당 파일이 없으면 포드가 실행 중이 아니거나 포드 구성 요청을 수락할 준비가 되지 않았음을 나타냅니다.

  2. 다음 명령을 사용하여 네임스페이스에 대한 프로브 실패를 포함한 모든 이벤트를 표시합니다.

    $ oc get events -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
  3. 특정 포드에 대한 이벤트만 표시합니다.

    $ oc describe pod ovnkube-node-9lqfk -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
  4. 클러스터 네트워크 운영자의 메시지와 상태를 표시합니다.

    $ oc get co/network -o json | jq '.status.conditions[]'
    Copy to Clipboard Toggle word wrap
  5. 다음 스크립트를 실행하여 ovnkube-node 포드에 있는 각 컨테이너의 준비 상태를 표시합니다.

    $ 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 Toggle word wrap
    참고

    모든 컨테이너 상태가 true 로 보고될 것으로 예상됩니다. 준비 프로브에 실패하면 상태가 false 로 설정됩니다.

3.2. 콘솔에서 OVN-Kubernetes 알림 보기

경고 UI는 경고 및 관리 경고 규칙과 음소거에 대한 자세한 정보를 제공합니다.

사전 요구 사항

  • 개발자로 또는 메트릭을 확인하는 프로젝트에 대한 보기 권한이 있는 사용자로 클러스터에 액세스할 수 있습니다.

프로세스(UI)

  1. 관리자 화면에서 모니터링경고를 선택합니다. 이 관점에서 경고 UI의 세 가지 주요 페이지는 경고, 음소거경고 규칙 페이지입니다.
  2. 관찰알림알림 규칙을 선택하여 OVN-Kubernetes 알림에 대한 규칙을 확인하세요.

3.3. CLI에서 OVN-Kubernetes 알림 보기

명령줄에서 알림과 해당 알림 규칙 및 알림 음소거에 대한 정보를 얻을 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • jq를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 활성화된 경고나 실행 중인 경고를 확인하세요.

    1. 다음 명령을 실행하여 경고 관리자 경로 환경 변수를 설정합니다.

      $ ALERT_MANAGER=$(oc get route alertmanager-main -n openshift-monitoring \
      -o jsonpath='{@.spec.host}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 Alert Manager 경로 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)"'
      Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 알림 규칙을 확인하세요.

    $ 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 Toggle word wrap

3.4. CLI를 사용하여 OVN-Kubernetes 로그 보기

OpenShift CLI( oc )를 사용하여 ovnkube-masterovnkube-node 포드의 각 포드에 대한 로그를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)에 액세스합니다.
  • jq를 설치했습니다.

프로세스

  1. 특정 Pod의 로그를 확인합니다.

    $ oc logs -f <pod_name> -c <container_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    -f
    선택 사항: 출력에서 로그에 기록되는 내용을 따르도록 지정합니다.
    <pod_name>
    pod 이름을 지정합니다.
    <container_name>
    선택 사항: 컨테이너의 이름을 지정합니다. Pod에 여러 컨테이너가 있는 경우 컨테이너 이름을 지정해야 합니다.
    <namespace>
    Pod가 실행 중인 네임스페이스를 지정합니다.

    예를 들면 다음과 같습니다.

    $ oc logs ovnkube-node-5dx44 -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap
    $ oc logs -f ovnkube-node-5dx44 -c ovnkube-controller -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    로그 파일의 내용이 출력됩니다.

  2. ovnkube-node 포드의 모든 컨테이너에서 가장 최근 항목을 조사합니다.

    $ 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 Toggle word wrap
  3. 다음 명령을 사용하여 ovnkube-node Pod의 모든 컨테이너에 있는 모든 로그의 마지막 5줄을 확인하세요.

    $ oc logs -l app=ovnkube-node -n openshift-ovn-kubernetes --all-containers --tail 5
    Copy to Clipboard Toggle word wrap

3.5. 웹 콘솔을 사용하여 OVN-Kubernetes 로그 보기

웹 콘솔에서 ovnkube-masterovnkube-node 포드의 각 포드에 대한 로그를 볼 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.

프로세스

  1. OpenShift Container Platform 콘솔에서 워크로드Pod로 이동하거나 조사하려는 리소스를 통해 Pod로 이동합니다.
  2. 드롭다운 메뉴에서 openshift-ovn-kubernetes 프로젝트를 선택합니다.
  3. 조사할 Pod 이름을 클릭합니다.
  4. 로그를 클릭합니다. 기본적으로 ovnkube-master 의 경우 northd 컨테이너와 관련된 로그가 표시됩니다.
  5. 아래쪽 메뉴를 사용하여 각 컨테이너에 대한 로그를 차례로 선택하세요.

3.5.1. OVN-Kubernetes 로그 수준 변경

OVN-Kubernetes의 기본 로그 수준은 4입니다. OVN-Kubernetes를 디버깅하려면 로그 수준을 5로 설정하세요. 이 절차에 따라 OVN-Kubernetes의 로그 수준을 높여서 문제를 디버깅하세요.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

프로세스

  1. OVN-Kubernetes 프로젝트의 모든 포드에 대한 자세한 정보를 얻으려면 다음 명령을 실행하세요.

    $ oc get po -o wide -n openshift-ovn-kubernetes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS       AGE    IP           NODE                                       NOMINATED NODE   READINESS GATES
    ovnkube-control-plane-65497d4548-9ptdr   2/2     Running   2 (128m ago)   147m   10.0.0.3     ci-ln-3njdr9b-72292-5nwkp-master-0         <none>           <none>
    ovnkube-control-plane-65497d4548-j6zfk   2/2     Running   0              147m   10.0.0.5     ci-ln-3njdr9b-72292-5nwkp-master-2         <none>           <none>
    ovnkube-node-5dx44                       8/8     Running   0              146m   10.0.0.3     ci-ln-3njdr9b-72292-5nwkp-master-0         <none>           <none>
    ovnkube-node-dpfn4                       8/8     Running   0              146m   10.0.0.4     ci-ln-3njdr9b-72292-5nwkp-master-1         <none>           <none>
    ovnkube-node-kwc9l                       8/8     Running   0              134m   10.0.128.2   ci-ln-3njdr9b-72292-5nwkp-worker-a-2fjcj   <none>           <none>
    ovnkube-node-mcrhl                       8/8     Running   0              134m   10.0.128.4   ci-ln-3njdr9b-72292-5nwkp-worker-c-v9x5v   <none>           <none>
    ovnkube-node-nsct4                       8/8     Running   0              146m   10.0.0.5     ci-ln-3njdr9b-72292-5nwkp-master-2         <none>           <none>
    ovnkube-node-zrj9f                       8/8     Running   0              134m   10.0.128.3   ci-ln-3njdr9b-72292-5nwkp-worker-b-v78h7   <none>           <none>
    Copy to Clipboard Toggle word wrap

  2. 다음 예제와 유사한 ConfigMap 파일을 만들고 env-overrides.yaml 과 같은 파일 이름을 사용합니다.

    예제 ConfigMap 파일

    kind: ConfigMap
    apiVersion: v1
    metadata:
      name: env-overrides
      namespace: openshift-ovn-kubernetes
    data:
      ci-ln-3njdr9b-72292-5nwkp-master-0: | 
    1
    
        # This sets the log level for the ovn-kubernetes node process:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for ovn-controller:
        OVN_LOG_LEVEL=dbg
      ci-ln-3njdr9b-72292-5nwkp-master-2: |
        # This sets the log level for the ovn-kubernetes node process:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for ovn-controller:
        OVN_LOG_LEVEL=dbg
      _master: | 
    2
    
        # This sets the log level for the ovn-kubernetes master process as well as the ovn-dbchecker:
        OVN_KUBE_LOG_LEVEL=5
        # You might also/instead want to enable debug logging for northd, nbdb and sbdb on all masters:
        OVN_LOG_LEVEL=dbg
    Copy to Clipboard Toggle word wrap

    1
    디버그 로그 수준을 설정할 노드의 이름을 지정합니다.
    2
    ovnkube-master 구성 요소의 로그 수준을 설정하려면 _master를 지정하세요.
  3. 다음 명령을 사용하여 ConfigMap 파일을 적용합니다.

    $ oc apply -n openshift-ovn-kubernetes -f env-overrides.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    configmap/env-overrides.yaml created
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 사용하여 ovnkube 포드를 다시 시작하여 새 로그 수준을 적용합니다.

    $ 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 Toggle word wrap
    $ 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 Toggle word wrap
    $ oc delete pod -n openshift-ovn-kubernetes -l app=ovnkube-node
    Copy to Clipboard Toggle word wrap
  5. `ConfigMap` 파일이 특정 Pod의 모든 노드에 적용되었는지 확인하려면 다음 명령을 실행하세요.

    $ oc logs -n openshift-ovn-kubernetes --all-containers --prefix ovnkube-node-<xxxx> | grep -E -m 10 '(Logging config:|vconsole|DBG)'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <XXXX>

    이전 단계의 포드에 대한 무작위 문자 시퀀스를 지정합니다.

    출력 예

    [pod/ovnkube-node-2cpjc/sbdb] + exec /usr/share/ovn/scripts/ovn-ctl --no-monitor '--ovn-sb-log=-vconsole:info -vfile:off -vPATTERN:console:%D{%Y-%m-%dT%H:%M:%S.###Z}|%05N|%c%T|%p|%m' run_sb_ovsdb
    [pod/ovnkube-node-2cpjc/ovnkube-controller] I1012 14:39:59.984506   35767 config.go:2247] Logging config: {File: CNIFile:/var/log/ovn-kubernetes/ovn-k8s-cni-overlay.log LibovsdbFile:/var/log/ovnkube/libovsdb.log Level:5 LogFileMaxSize:100 LogFileMaxBackups:5 LogFileMaxAge:0 ACLLoggingRateLimit:20}
    [pod/ovnkube-node-2cpjc/northd] + exec ovn-northd --no-chdir -vconsole:info -vfile:off '-vPATTERN:console:%D{%Y-%m-%dT%H:%M:%S.###Z}|%05N|%c%T|%p|%m' --pidfile /var/run/ovn/ovn-northd.pid --n-threads=1
    [pod/ovnkube-node-2cpjc/nbdb] + exec /usr/share/ovn/scripts/ovn-ctl --no-monitor '--ovn-nb-log=-vconsole:info -vfile:off -vPATTERN:console:%D{%Y-%m-%dT%H:%M:%S.###Z}|%05N|%c%T|%p|%m' run_nb_ovsdb
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.552Z|00002|hmap|DBG|lib/shash.c:114: 1 bucket with 6+ nodes, including 1 bucket with 6 nodes (32 nodes total across 32 buckets)
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.553Z|00003|hmap|DBG|lib/shash.c:114: 1 bucket with 6+ nodes, including 1 bucket with 6 nodes (64 nodes total across 64 buckets)
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.553Z|00004|hmap|DBG|lib/shash.c:114: 1 bucket with 6+ nodes, including 1 bucket with 7 nodes (32 nodes total across 32 buckets)
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.553Z|00005|reconnect|DBG|unix:/var/run/openvswitch/db.sock: entering BACKOFF
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.553Z|00007|reconnect|DBG|unix:/var/run/openvswitch/db.sock: entering CONNECTING
    [pod/ovnkube-node-2cpjc/ovn-controller] 2023-10-12T14:39:54.553Z|00008|ovsdb_cs|DBG|unix:/var/run/openvswitch/db.sock: SERVER_SCHEMA_REQUESTED -> SERVER_SCHEMA_REQUESTED at lib/ovsdb-cs.c:423
    Copy to Clipboard Toggle word wrap

  6. 선택 사항: 다음 명령을 실행하여 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
    Copy to Clipboard Toggle word wrap

    출력 예

    ---- ovnkube-node-2dt57 ----
    60981 /usr/bin/ovnkube --init-ovnkube-controller xpst8-worker-c-vmh5n.c.openshift-qe.internal --init-node xpst8-worker-c-vmh5n.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 4
    ---- ovnkube-node-4zznh ----
    178034 /usr/bin/ovnkube --init-ovnkube-controller xpst8-master-2.c.openshift-qe.internal --init-node xpst8-master-2.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 4
    ---- ovnkube-node-548sx ----
    77499 /usr/bin/ovnkube --init-ovnkube-controller xpst8-worker-a-fjtnb.c.openshift-qe.internal --init-node xpst8-worker-a-fjtnb.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 4
    ---- ovnkube-node-6btrf ----
    73781 /usr/bin/ovnkube --init-ovnkube-controller xpst8-worker-b-p8rww.c.openshift-qe.internal --init-node xpst8-worker-b-p8rww.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 4
    ---- ovnkube-node-fkc9r ----
    130707 /usr/bin/ovnkube --init-ovnkube-controller xpst8-master-0.c.openshift-qe.internal --init-node xpst8-master-0.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 5
    ---- ovnkube-node-tk9l4 ----
    181328 /usr/bin/ovnkube --init-ovnkube-controller xpst8-master-1.c.openshift-qe.internal --init-node xpst8-master-1.c.openshift-qe.internal --config-file=/run/ovnkube-config/ovnkube.conf --ovn-empty-lb-events --loglevel 4
    Copy to Clipboard Toggle word wrap

3.6. OVN-Kubernetes Pod 네트워크 연결 확인

OpenShift Container Platform 4.10 이상 버전의 연결 확인 컨트롤러는 클러스터에서 연결 확인 확인을 조율합니다. 여기에는 Kubernetes API, OpenShift API 및 개별 노드가 포함됩니다. 연결 테스트의 결과는 openshift-network-diagnosticsPodNetworkConnectivity 오브젝트에 저장됩니다. 연결 테스트는 병렬로 1분마다 수행됩니다.

사전 요구 사항

  • OpenShift CLI(oc)에 액세스합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • jq를 설치했습니다.

프로세스

  1. 현재 PodNetworkConnectivityCheck 오브젝트를 나열하려면 다음 명령을 입력합니다.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 사용하여 각 연결 개체의 최근 성공 여부를 확인하세요.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.successes[0]'
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 사용하여 각 연결 개체의 최근 실패를 확인하세요.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.failures[0]'
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 사용하여 각 연결 개체의 가장 최근 중단을 확인하세요.

    $ oc get podnetworkconnectivitychecks -n openshift-network-diagnostics \
    -o json | jq '.items[]| .spec.targetEndpoint,.status.outages[0]'
    Copy to Clipboard Toggle word wrap

    연결성 검사 컨트롤러는 이러한 검사에서 얻은 측정 항목을 Prometheus에 기록합니다.

  5. 다음 명령을 실행하여 모든 메트릭을 확인하세요.

    $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
    promtool query instant  http://localhost:9090 \
    '{component="openshift-network-diagnostics"}'
    Copy to Clipboard Toggle word wrap
  6. 지난 5분 동안 소스 포드와 OpenShift API 서비스 간의 대기 시간을 확인하세요.

    $ oc exec prometheus-k8s-0 -n openshift-monitoring -- \
    promtool query instant  http://localhost:9090 \
    '{component="openshift-network-diagnostics"}'
    Copy to Clipboard Toggle word wrap

3.7. CLI를 사용하여 OVS 샘플링으로 OVN-Kubernetes 네트워크 트래픽 확인

중요

OVS 샘플링을 사용하여 OVN-Kubernetes 네트워크 트래픽을 확인하는 것은 기술 미리 보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OVN-Kubernetes 네트워크 트래픽은 다음 네트워크 API에 대한 CLI를 통해 OVS 샘플링으로 볼 수 있습니다.

  • NetworkPolicy
  • AdminNetworkPolicy
  • BaselineNetworkPolicy
  • 사용자 정의 네트워크 격리
  • EgressFirewall
  • 멀티캐스트 ACL.

이러한 네트워킹 이벤트에 대한 스크립트는 각 OVN-Kubernetes 노드의 /usr/bin/ovnkube-observ 경로에서 찾을 수 있습니다.

네트워크 관찰 연산자와 OVS 샘플링을 통한 OVN-Kubernetes 네트워크 트래픽 검사는 모두 디버깅에 유용하지만, 네트워크 관찰 연산자는 네트워크 이벤트를 관찰하기 위한 것입니다. 또는 CLI를 사용하여 OVS 샘플링으로 OVN-Kubernetes 네트워크 트래픽을 검사하면 패킷 추적에 도움이 됩니다. Network Observability Operator가 설치된 동안에도 사용할 수 있지만, 필수 사항은 아닙니다.

관리자는 --add-ovs-collect 옵션을 추가하여 노드 전체의 네트워크 트래픽을 보거나, 추가 플래그를 전달하여 특정 포드에 대한 결과를 필터링할 수 있습니다. 추가 플래그는 "OVS 샘플링 플래그를 사용한 OVN-Kubernetes 네트워크 트래픽" 섹션에서 찾을 수 있습니다.

CLI를 사용하여 OVN-Kubernetes 네트워크 트래픽을 보려면 다음 절차를 따르세요.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 소스 포드와 대상 포드를 생성하고 두 포드 간에 트래픽을 실행했습니다.
  • 다음 네트워크 API 중 하나 이상을 생성했습니다: NetworkPolicy , AdminNetworkPolicy , BaselineNetworkPolicy , UserDefinedNetwork 격리, 멀티캐스트 또는 송신 방화벽.

프로세스

  1. OVS 샘플링 기능을 사용하여 OVNObservability를 활성화하려면 다음 명령을 입력하여 FeatureGate CR이라는 클러스터 에서 TechPreviewNoUpgrade 기능 세트를 활성화합니다.

    $ oc patch --type=merge --patch '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' featuregate/cluster
    Copy to Clipboard Toggle word wrap

    출력 예

    featuregate.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 OVNObservability 기능이 활성화되었는지 확인하세요.

    $ oc get featuregate cluster -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

      featureGates:
    # ...
        enabled:
        - name: OVNObservability
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 관련 네트워크 API 중 하나를 생성한 네임스페이스 내의 포드 목록을 가져옵니다. 다음 단계에서 사용되므로 포드의 NODE 이름을 기록해 두세요.

    $ oc get pods -n <namespace> -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              READY   STATUS    RESTARTS   AGE     IP            NODE                                       NOMINATED NODE   READINESS GATES
    destination-pod   1/1     Running   0          53s     10.131.0.23   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>           <none>
    source-pod        1/1     Running   0          56s     10.131.0.22   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>           <none>
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 입력하여 OVN-Kubernetes 포드 목록을 얻고 이전 단계의 포드와 동일한 NODE를 공유하는 포드를 찾습니다.

    $ oc get pods -n openshift-ovn-kubernetes -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME
    ...                             READY   STATUS    RESTARTS      AGE   IP           NODE                                       NOMINATED NODE
    ovnkube-node-jzn5b              8/8     Running   1 (34m ago)   37m   10.0.128.2   ci-ln-1gqp7b2-72292-bb9dv-worker-a-gtmpc   <none>
    ...
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 입력하여 ovnkube-node 포드 내부에서 bash 셸을 엽니다.

    $ oc exec -it <pod_name> -n openshift-ovn-kubernetes -- bash
    Copy to Clipboard Toggle word wrap
  6. ovnkube-node 포드 내부에 있는 동안 ovnkube-observ -add-ovs-collector 스크립트를 실행하면 OVS 수집기를 사용하여 네트워크 이벤트를 표시할 수 있습니다. 예를 들면 다음과 같습니다.

    # /usr/bin/ovnkube-observ -add-ovs-collector
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    2024/12/02 19:41:41.327584 OVN-K message: Allowed by default allow from local node policy, direction ingress
    2024/12/02 19:41:41.327593 src=10.131.0.2, dst=10.131.0.6
    
    2024/12/02 19:41:41.327692 OVN-K message: Allowed by default allow from local node policy, direction ingress
    2024/12/02 19:41:41.327715 src=10.131.0.6, dst=10.131.0.2
    ...
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 -filter-src-ip 플래그와 Pod의 IP 주소와 함께 입력하여 소스 Pod와 같은 유형별로 콘텐츠를 필터링할 수 있습니다. 예를 들면 다음과 같습니다.

    # /usr/bin/ovnkube-observ -add-ovs-collector -filter-src-ip <pod_ip_address>
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    Found group packets, id 14
    2024/12/10 16:27:12.456473 OVN-K message: Allowed by admin network policy allow-egress-group1, direction Egress
    2024/12/10 16:27:12.456570 src=10.131.0.22, dst=10.131.0.23
    
    2024/12/10 16:27:14.484421 OVN-K message: Allowed by admin network policy allow-egress-group1, direction Egress
    2024/12/10 16:27:14.484428 src=10.131.0.22, dst=10.131.0.23
    
    2024/12/10 16:27:12.457222 OVN-K message: Allowed by network policy test:allow-ingress-from-specific-pod, direction Ingress
    2024/12/10 16:27:12.457228 src=10.131.0.22, dst=10.131.0.23
    
    2024/12/10 16:27:12.457288 OVN-K message: Allowed by network policy test:allow-ingress-from-specific-pod, direction Ingress
    2024/12/10 16:27:12.457299 src=10.131.0.22, dst=10.131.0.23
    ...
    Copy to Clipboard Toggle word wrap

    /usr/bin/ovnkube-observ 와 함께 전달될 수 있는 플래그의 전체 목록은 "OVS 샘플링 플래그를 사용한 OVN-Kubernetes 네트워크 트래픽"을 참조하세요.

3.7.1. OVS 샘플링 플래그를 사용한 OVN-Kubernetes 네트워크 트래픽

다음 플래그는 CLI를 사용하여 OVN-Kubernetes 네트워크 트래픽을 보는 데 사용할 수 있습니다. ovnkube-node 포드 내부에서 bash 셸을 연 후 터미널에서 다음 구문에 이러한 플래그를 추가합니다.

명령 구문

# /usr/bin/ovnkube-observ <flag>
Copy to Clipboard Toggle word wrap

Expand
플래그설명

-h

usr/bin/ovnkube-observ 명령과 함께 사용할 수 있는 전체 플래그 목록을 반환합니다. `

-add-ovs-collector

샘플링을 활성화하려면 OVS 수집기를 추가하세요. 주의해서 사용하십시오. 다른 사람이 관찰성을 사용하지 않는지 확인하세요.

-enable-enrichment

NBDB 데이터로 샘플을 풍부하게 만듭니다. 기본값은 true 입니다.

-filter-dst-ip

지정된 대상 IP로의 패킷만 필터링합니다.

-filter-src-ip

지정된 소스 IP의 패킷만 필터링합니다.

-log-cookie

psample group_id로 원시 샘플 쿠키를 인쇄합니다.

-output-file

샘플을 쓸 출력 파일입니다.

-print-full-packet

받은 패킷 전체를 인쇄하세요. false인 경우 모든 샘플에 소스 및 대상 IP만 인쇄됩니다.

4장. ovnkube-trace를 사용하여 Openflow 추적

OVN 및 OVS 트래픽 흐름은 ovnkube-trace 라는 단일 유틸리티에서 시뮬레이션할 수 있습니다. ovnkube-trace 유틸리티는 ovn-trace , ovs-appctl ofproto/traceovn-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 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 다음 명령을 사용하여 pod 변수를 만듭니다.

    $  POD=$(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-control-plane -o name | head -1 | awk -F '/' '{print $NF}')
    Copy to Clipboard Toggle word wrap
  2. 로컬 호스트에서 다음 명령을 실행하여 ovnkube-control-plane 포드에서 바이너리를 복사합니다.

    $  oc cp -n openshift-ovn-kubernetes $POD:/usr/bin/ovnkube-trace -c ovnkube-cluster-manager ovnkube-trace
    Copy to Clipboard Toggle word wrap
    참고

    ovnkube-trace 도구를 실행하기 위해 Red Hat Enterprise Linux(RHEL) 8을 사용하는 경우 /usr/lib/rhel8/ovnkube-trace 파일을 로컬 호스트에 복사해야 합니다.

  3. 다음 명령을 실행하여 ovnkube-trace를 실행 가능하게 만듭니다.

    $  chmod +x ovnkube-trace
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 ovnkube-trace 에서 사용할 수 있는 옵션을 표시합니다.

    $  ./ovnkube-trace -help
    Copy to Clipboard Toggle word wrap

    예상 출력

    Usage of ./ovnkube-trace:
      -addr-family string
        	Address family (ip4 or ip6) to be used for tracing (default "ip4")
      -dst string
        	dest: destination pod name
      -dst-ip string
        	destination IP address (meant for tests to external targets)
      -dst-namespace string
        	k8s namespace of dest pod (default "default")
      -dst-port string
        	dst-port: destination port (default "80")
      -kubeconfig string
        	absolute path to the kubeconfig file
      -loglevel string
        	loglevel: klog level (default "0")
      -ovn-config-namespace string
        	namespace used by ovn-config itself
      -service string
        	service: destination service name
      -skip-detrace
        	skip ovn-detrace command
      -src string
        	src: source pod name
      -src-namespace string
        	k8s namespace of source pod (default "default")
      -tcp
        	use tcp transport protocol
      -udp
        	use udp transport protocol
    Copy to Clipboard Toggle word wrap

    지원되는 명령줄 인수는 네임스페이스, 포드, 서비스와 같은 익숙한 Kubernetes 구성 요소이므로 MAC 주소, 대상 노드의 IP 주소 또는 ICMP 유형을 찾을 필요가 없습니다.

    로그 수준은 다음과 같습니다.

    • 0 (최소 출력)
    • 2(추적 명령의 결과를 보여주는 더 자세한 출력)
    • 5 (디버그 출력)

4.2. ovnkube-trace 실행

ovn-trace를 실행하여 OVN 논리 네트워크 내에서 패킷 전달을 시뮬레이션합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 로컬 호스트에 ovnkube-trace를 설치했습니다.

예: 배포된 Pod에서 DNS 확인이 작동하는지 테스트

이 예제에서는 클러스터에서 실행되는 핵심 DNS 포드에 대한 배포된 포드의 DNS 확인을 테스트하는 방법을 보여줍니다.

프로세스

  1. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다.

    $ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  2. openshift-dns 네임스페이스에서 실행 중인 포드를 나열하세요.

    oc get pods -n openshift-dns
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                  READY   STATUS    RESTARTS   AGE
    dns-default-8s42x     2/2     Running   0          5h8m
    dns-default-mdw6r     2/2     Running   0          4h58m
    dns-default-p8t5h     2/2     Running   0          4h58m
    dns-default-rl6nk     2/2     Running   0          5h8m
    dns-default-xbgqx     2/2     Running   0          5h8m
    dns-default-zv8f6     2/2     Running   0          4h58m
    node-resolver-62jjb   1/1     Running   0          5h8m
    node-resolver-8z4cj   1/1     Running   0          4h59m
    node-resolver-bq244   1/1     Running   0          5h8m
    node-resolver-hc58n   1/1     Running   0          4h59m
    node-resolver-lm6z4   1/1     Running   0          5h8m
    node-resolver-zfx5k   1/1     Running   0          5h
    Copy to Clipboard Toggle word wrap

  3. 다음 ovnkube-trace 명령을 실행하여 DNS 확인이 작동하는지 확인하세요.

    $ ./ovnkube-trace \
      -src-namespace default \ 
    1
    
      -src web \ 
    2
    
      -dst-namespace openshift-dns \ 
    3
    
      -dst dns-default-p8t5h \ 
    4
    
      -udp -dst-port 53 \ 
    5
    
      -loglevel 0 
    6
    Copy to Clipboard Toggle word wrap
    1
    소스 포드의 네임스페이스
    2
    소스 포드 이름
    3
    목적지 포드의 네임스페이스
    4
    목적지 포드 이름
    5
    UDP 전송 프로토콜을 사용합니다. 포트 53은 DNS 서비스가 사용하는 포트입니다.
    6
    로그 수준을 0으로 설정합니다(0은 최소이고 5는 디버그입니다)

    src&dst pod가 같은 노드에 도착하는 경우의 출력 예

    ovn-trace source pod to destination pod indicates success from web to dns-default-p8t5h
    ovn-trace destination pod to source pod indicates success from dns-default-p8t5h to web
    ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-p8t5h
    ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-p8t5h to web
    ovn-detrace source pod to destination pod indicates success from web to dns-default-p8t5h
    ovn-detrace destination pod to source pod indicates success from dns-default-p8t5h to web
    Copy to Clipboard Toggle word wrap

    src&dst pod가 다른 노드에 도착하는 경우의 출력 예

    ovn-trace source pod to destination pod indicates success from web to dns-default-8s42x
    ovn-trace (remote) source pod to destination pod indicates success from web to dns-default-8s42x
    ovn-trace destination pod to source pod indicates success from dns-default-8s42x to web
    ovn-trace (remote) destination pod to source pod indicates success from dns-default-8s42x to web
    ovs-appctl ofproto/trace source pod to destination pod indicates success from web to dns-default-8s42x
    ovs-appctl ofproto/trace destination pod to source pod indicates success from dns-default-8s42x to web
    ovn-detrace source pod to destination pod indicates success from web to dns-default-8s42x
    ovn-detrace destination pod to source pod indicates success from dns-default-8s42x to web
    Copy to Clipboard Toggle word wrap

    출력은 배포된 포드에서 DNS 포트로의 성공과 반대 방향으로의 회신도 성공함을 나타냅니다. 따라서 웹 포드가 핵심 DNS에서 DNS 확인을 수행하려는 경우 UDP 포트 53에서 양방향 트래픽이 지원된다는 것을 알 수 있습니다.

예를 들어 이 방법이 효과가 없고 ovn-trace , proto/traceovs-appctl , ovn-detrace , 그리고 더 많은 디버그 유형 정보를 얻고 싶다면 로그 수준을 2로 높이고 다음과 같이 명령을 다시 실행하세요.

$ ./ovnkube-trace \
  -src-namespace default \
  -src web \
  -dst-namespace openshift-dns \
  -dst dns-default-467qw \
  -udp -dst-port 53 \
  -loglevel 2
Copy to Clipboard Toggle word wrap

이렇게 증가된 로그 수준에서 발생하는 출력은 여기에 모두 나열하기에는 너무 많습니다. 장애 상황에서 이 명령의 출력은 어떤 흐름이 해당 트래픽을 삭제하는지 보여줍니다. 예를 들어, 해당 트래픽을 허용하지 않는 유입 또는 유출 네트워크 정책이 클러스터에 구성될 수 있습니다.

예: 디버그 출력을 사용하여 구성된 기본 거부 확인

이 예제에서는 디버그 출력을 사용하여 수신 기본 거부 정책이 트래픽을 차단한다는 것을 식별하는 방법을 보여줍니다.

프로세스

  1. 모든 네임스페이스의 모든 포드에서 들어오는 트래픽을 거부하는 기본 거부 정책을 정의하는 다음 YAML을 만듭니다. deny-by-default.yaml 파일에 YAML을 저장합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: deny-by-default
      namespace: default
    spec:
      podSelector: {}
      ingress: []
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    networkpolicy.networking.k8s.io/deny-by-default created
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다.

    $ oc run web --namespace=default --image=quay.io/openshifttest/nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 실행하여 prod 네임스페이스를 만듭니다.

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다.

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap
  6. 다음 명령을 실행하여 prod 네임스페이스에 alpine 이미지를 배포하고 셸을 시작합니다.

    $ oc run test-6459 --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap
  7. 다른 터미널 세션을 엽니다.
  8. 이 새로운 터미널 세션에서 ovn-trace를 실행하여 네임스페이스 prod 에서 실행되는 소스 포드 test-6459기본 네임스페이스에서 실행되는 대상 포드 간 통신에 오류가 있는지 확인합니다.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 0
    Copy to Clipboard Toggle word wrap

    출력 예

    ovn-trace source pod to destination pod indicates failure from test-6459 to web
    Copy to Clipboard Toggle word wrap

  9. 다음 명령을 실행하여 실패 이유를 파악하려면 로그 수준을 2로 높이세요.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 2
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    ------------------------------------------------
     3. ls_out_acl_hint (northd.c:7454): !ct.new && ct.est && !ct.rpl && ct_mark.blocked == 0, priority 4, uuid 12efc456
        reg0[8] = 1;
        reg0[10] = 1;
        next;
     5. ls_out_acl_action (northd.c:7835): reg8[30..31] == 0, priority 500, uuid 69372c5d
        reg8[30..31] = 1;
        next(4);
     5. ls_out_acl_action (northd.c:7835): reg8[30..31] == 1, priority 500, uuid 2fa0af89
        reg8[30..31] = 2;
        next(4);
     4. ls_out_acl_eval (northd.c:7691): reg8[30..31] == 2 && reg0[10] == 1 && (outport == @a16982411286042166782_ingressDefaultDeny), priority 2000, uuid 447d0dab
        reg8[17] = 1;
        ct_commit { ct_mark.blocked = 1; }; 
    1
    
        next;
    ...
    Copy to Clipboard Toggle word wrap

    1
    기본 거부 정책이 적용되어 유입 트래픽이 차단됩니다.
  10. 특정 네임스페이스에 있는 모든 포드의 트래픽을 허용하는 정책을 purpose=production 레이블로 만듭니다. web-allow-prod.yaml 파일에 YAML을 저장합니다.

    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: web-allow-prod
      namespace: default
    spec:
      podSelector:
        matchLabels:
          app: web
      policyTypes:
      - Ingress
      ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              purpose: production
    Copy to Clipboard Toggle word wrap
  11. 다음 명령을 입력하여 정책을 적용합니다.

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap
  12. 다음 명령을 입력하여 ovnkube-trace를 실행하여 트래픽이 이제 허용되는지 확인하세요.

    $ ./ovnkube-trace \
     -src-namespace prod \
     -src test-6459 \
     -dst-namespace default \
     -dst web \
     -tcp -dst-port 80 \
     -loglevel 0
    Copy to Clipboard Toggle word wrap

    예상 출력

    ovn-trace source pod to destination pod indicates success from test-6459 to web
    ovn-trace destination pod to source pod indicates success from web to test-6459
    ovs-appctl ofproto/trace source pod to destination pod indicates success from test-6459 to web
    ovs-appctl ofproto/trace destination pod to source pod indicates success from web to test-6459
    ovn-detrace source pod to destination pod indicates success from test-6459 to web
    ovn-detrace destination pod to source pod indicates success from web to test-6459
    Copy to Clipboard Toggle word wrap

  13. 6단계에서 열린 셸에서 다음 명령을 실행하여 nginx를 웹 서버에 연결합니다.

     wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

    <!DOCTYPE html>
    <html>
    <head>
    <title>Welcome to nginx!</title>
    <style>
      body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
      }
    </style>
    </head>
    <body>
    <h1>Welcome to nginx!</h1>
    <p>If you see this page, the nginx web server is successfully installed and
    working. Further configuration is required.</p>
    
    <p>For online documentation and support please refer to
    <a href="http://nginx.org/">nginx.org</a>.<br/>
    Commercial support is available at
    <a href="http://nginx.com/">nginx.com</a>.</p>
    
    <p><em>Thank you for using nginx.</em></p>
    </body>
    </html>
    Copy to Clipboard Toggle word wrap

5장. IPv4/IPv6 듀얼 스택 네트워킹으로 변환

클러스터 관리자는 IPv4 단일 스택 클러스터를 IPv4 및 IPv6 주소 제품군을 지원하는 듀얼 네트워크 클러스터 네트워크로 변환할 수 있습니다. 듀얼 스택 네트워킹으로 변환한 후에는 새 Pod와 기존 Pod 모두 듀얼 스택 네트워킹이 활성화됩니다.

중요

IPv6가 필요한 듀얼 스택 네트워킹을 사용하는 경우 ::FFFF:198.51.100.1 과 같은 IPv4 매핑 IPv6 주소를 사용할 수 없습니다.

5.1. 듀얼 스택 클러스터 네트워크로 변환

클러스터 관리자는 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.

중요

클러스터를 듀얼 스택 네트워킹으로 변환한 후에는 IPv6 주소를 수신할 수 있도록 기존 Pod를 다시 만들어야 합니다. 새로운 Pod에만 IPv6 주소가 할당되기 때문입니다.

단일 스택 클러스터 네트워크를 듀얼 스택 클러스터 네트워크로 변환하는 작업은 패치를 생성하고 이를 클러스터의 네트워크와 인프라에 적용하는 작업으로 구성됩니다. 설치 프로그램 제공 인프라 또는 사용자 제공 인프라에서 실행되는 클러스터의 경우 듀얼 스택 클러스터 네트워크로 변환할 수 있습니다.

참고

clusterNetwork , serviceNetwork , apiServerInternalIPsingressIP 객체를 변경하는 각 패치 작업은 클러스터를 다시 시작합니다. MachineNetworks 객체를 변경해도 클러스터가 재부팅되지 않습니다.

설치 프로그램에서 제공하는 인프라에서만 API 및 Ingress 서비스에 대한 IPv6 가상 IP(VIP)를 기존 듀얼 스택 구성 클러스터에 추가해야 하는 경우 클러스터의 네트워크가 아닌 인프라에만 패치를 적용하면 됩니다.

중요

클러스터를 OpenShift Container Platform 4.16 이상으로 업그레이드했고 단일 스택 클러스터 네트워크를 이중 스택 클러스터 네트워크로 변환해야 하는 경우 YAML 구성 패치 파일의 install-config.yaml 파일에서 API 및 Ingress 서비스에 대한 기존 IPv4 machineNetwork 네트워크 구성을 지정해야 합니다. 이 구성은 IPv4 트래픽이 기본 게이트웨이와 동일한 네트워크 인터페이스에 존재하도록 보장합니다.

machineNetwork 네트워크에 대한 IPv4 주소 블록이 추가된 YAML 구성 파일 예

- op: add
  path: /spec/platformSpec/baremetal/machineNetworks/- 
1

  value: 192.168.1.0/24
  # ...
Copy to Clipboard Toggle word wrap

1
귀하의 기계가 작동하는 machineNetwork 네트워크에 대한 주소 블록을 지정해야 합니다. 머신 네트워크에 대해 API 및 Ingress IP 주소를 모두 선택해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 귀하의 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
  • 클러스터 노드에는 IPv6 주소가 있습니다.
  • 귀하의 인프라에 따라 IPv6 지원 라우터를 구성했습니다.

프로세스

  1. 클러스터 및 서비스 네트워크에 대한 IPv6 주소 블록을 지정하려면 다음 예와 유사한 구성을 갖는 YAML 구성 패치 파일을 만듭니다.

    - op: add
      path: /spec/clusterNetwork/-
      value: 
    1
    
        cidr: fd01::/48
        hostPrefix: 64
    - op: add
      path: /spec/serviceNetwork/-
      value: fd02::/112 
    2
    Copy to Clipboard Toggle word wrap
    1
    cidrhostPrefix 매개변수로 객체를 지정합니다. 호스트 접두사는 64 이상이어야 합니다. IPv6 클래스 없는 도메인 간 라우팅(CIDR) 접두사는 지정된 호스트 접두사를 수용할 만큼 충분히 커야 합니다.
    2
    접두사가 112인 IPv6 CIDR을 지정합니다. Kubernetes는 가장 낮은 16비트만 사용합니다. 접두사 112의 경우 IP 주소는 112비트에서 128비트로 할당됩니다.
  2. CLI에 다음 명령을 입력하여 클러스터 네트워크 구성에 패치를 적용하세요.

    $ oc patch network.config.openshift.io cluster \
    1
    
      --type='json' --patch-file <file>.yaml
    Copy to Clipboard Toggle word wrap
    1
    여기서 file은 생성한 YAML 파일의 이름을 지정합니다.

    출력 예

    network.config.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

  3. API 및 Ingress 서비스에 대한 IPv6 VIP를 추가한 설치 프로그램 제공 인프라에서 다음 단계를 완료하세요.

    1. 클러스터의 API 및 Ingress 서비스에 대한 IPv6 VIP를 지정합니다. 다음 예제와 유사한 구성을 갖는 YAML 구성 패치 파일을 만듭니다.

      - op: add
        path: /spec/platformSpec/baremetal/machineNetworks/- 
      1
      
        value: fd2e:6f44:5dd8::/64
      - op: add
        path: /spec/platformSpec/baremetal/apiServerInternalIPs/- 
      2
      
        value: fd2e:6f44:5dd8::4
      - op: add
        path: /spec/platformSpec/baremetal/ingressIPs/-
        value: fd2e:6f44:5dd8::5
      Copy to Clipboard Toggle word wrap
      1
      귀하의 기계가 작동하는 machineNetwork 네트워크에 대한 주소 블록을 지정해야 합니다. 머신 네트워크에 대해 API 및 Ingress IP 주소를 모두 선택해야 합니다.
      2
      플랫폼에 따라 각 파일 경로를 지정해야 합니다. 이 예제에서는 베어 메탈 플랫폼의 파일 경로를 보여줍니다.
    2. CLI에 다음 명령을 입력하여 인프라에 패치를 적용하세요.

      $ oc patch infrastructure cluster \
        --type='json' --patch-file <file>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <file>

      생성된 YAML 파일의 이름을 지정합니다.

      출력 예

      infrastructure/cluster patched
      Copy to Clipboard Toggle word wrap

검증

  1. CLI에 다음 명령을 입력하여 클러스터 네트워크 구성을 표시합니다.

    $ oc describe network
    Copy to Clipboard Toggle word wrap
  2. YAML 파일에서 지정한 IPv6 주소 블록을 클러스터 네트워크 구성에서 인식하는지 확인하여 네트워크 구성에 패치가 성공적으로 설치되었는지 확인합니다.

    출력 예

    # ...
    Status:
      Cluster Network:
        Cidr:               10.128.0.0/14
        Host Prefix:        23
        Cidr:               fd01::/48
        Host Prefix:        64
      Cluster Network MTU:  1400
      Network Type:         OVNKubernetes
      Service Network:
        172.30.0.0/16
        fd02::/112
    # ...
    Copy to Clipboard Toggle word wrap

  3. 설치 프로그램 제공 인프라에서 실행되는 클러스터에 대해 다음 추가 작업을 완료하세요.

    1. CLI에 다음 명령을 입력하여 클러스터 인프라 구성을 표시합니다.

      $ oc describe infrastructure
      Copy to Clipboard Toggle word wrap
    2. YAML 파일에서 지정한 IPv6 주소 블록을 인프라가 인식하는지 확인하여 클러스터 인프라에 패치가 성공적으로 설치되었는지 확인합니다.

      출력 예

      # ...
      spec:
      # ...
        platformSpec:
          baremetal:
            apiServerInternalIPs:
            - 192.168.123.5
            - fd2e:6f44:5dd8::4
            ingressIPs:
            - 192.168.123.10
            - fd2e:6f44:5dd8::5
      status:
      # ...
        platformStatus:
          baremetal:
            apiServerInternalIP: 192.168.123.5
            apiServerInternalIPs:
            - 192.168.123.5
            - fd2e:6f44:5dd8::4
            ingressIP: 192.168.123.10
            ingressIPs:
            - 192.168.123.10
            - fd2e:6f44:5dd8::5
      # ...
      Copy to Clipboard Toggle word wrap

5.2. 단일 스택 클러스터 네트워크로 변환

클러스터 관리자는 듀얼 스택 클러스터 네트워크를 단일 스택 클러스터 네트워크로 변환할 수 있습니다.

중요

원래 IPv4 단일 스택 클러스터 네트워크를 듀얼 스택 클러스터로 변환한 경우 IPv4 단일 스택 클러스터로만 다시 변환할 수 있으며 IPv6 단일 스택 클러스터 네트워크로는 다시 변환할 수 없습니다. 동일한 제한은 IPv6 단일 스택 클러스터 네트워크로 다시 변환하는 경우에도 적용됩니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 귀하의 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
  • 클러스터 노드에는 IPv6 주소가 있습니다.
  • 듀얼 스택 네트워킹을 활성화했습니다.

프로세스

  1. 다음 명령을 실행하여 networks.config.openshift.io 사용자 정의 리소스(CR)를 편집합니다.

    $ oc edit networks.config.openshift.io
    Copy to Clipboard Toggle word wrap
  2. "듀얼 스택 클러스터 네트워크로 변환" 절차 단계를 완료하면서 cidrhostPrefix 매개변수에 추가한 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":
        {"ipv4":{"internalJoinSubnet": "<join_subnet>"},
        "ipv6":{"internalJoinSubnet": "<join_subnet>"}}}}}'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <join_subnet>
    OVN-Kubernetes에서 내부적으로 사용할 IP 주소 서브넷을 지정합니다. 서브넷은 클러스터의 노드 수보다 커야 하며 클러스터의 노드당 하나의 IP 주소를 수용할 수 있을 만큼 커야 합니다. 이 서브넷은 OpenShift Container Platform이나 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. IPv4의 기본값은 100.64.0.0/16 이고 IPv6의 기본값은 fd98::/64 입니다.

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

  • 구성이 활성화되었는지 확인하려면 다음 명령을 입력하세요.

    $ oc get network.operator.openshift.io \
      -o jsonpath="{.items[0].spec.defaultNetwork}"
    Copy to Clipboard Toggle word wrap

    이 변경 사항이 적용되려면 명령 작업이 최대 30분 정도 걸릴 수 있습니다.

    출력 예

    {
      "ovnKubernetesConfig": {
        "ipv4": {
          "internalJoinSubnet": "100.64.1.0/16"
        },
      },
      "type": "OVNKubernetes"
    }
    Copy to Clipboard Toggle word wrap

6.2. 설치 후 작업으로 OVN-Kubernetes 마스커레이드 서브넷 구성

OVN-Kubernetes에서 사용하는 마스커레이드 서브넷을 설치 후 작업으로 변경하면 환경에서 이미 사용 중인 기존 서브넷과의 충돌을 피할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  • 클러스터의 마스커레이드 서브넷을 변경하세요.

    • 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>"}}}}}}'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      ipv4_masquerade_subnet
      IPv4 마스커레이드 서브넷으로 사용할 IP 주소를 지정합니다. 이 범위는 OpenShift Container Platform이나 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. OpenShift Container Platform 4.17 이전 버전에서는 IPv4의 기본값이 169.254.169.0/29 였으며, 버전 4.17로 업그레이드된 클러스터는 이 값을 유지합니다. 버전 4.17부터 시작하는 새 클러스터의 경우 기본값은 169.254.0.0/17 입니다.
      ipv6_masquerade_subnet
      IPv6 마스커레이드 서브넷으로 사용할 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>"}}}}}}'
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      ipv4_masquerade_subnet :: IPv4 마스커레이드 서브넷으로 사용될 IP 주소를 지정합니다. 이 범위는 OpenShift Container Platform이나 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. OpenShift Container Platform 4.17 이전 버전에서는 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":
        {"ipv4":{"internalTransitSwitchSubnet": "<transit_subnet>"},
        "ipv6":{"internalTransitSwitchSubnet": "<transit_subnet>"}}}}}'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <transit_subnet>
    동서 트래픽을 가능하게 하는 분산형 전송 스위치에 대한 IP 주소 서브넷을 지정합니다. 이 서브넷은 OVN-Kubernetes 또는 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. IPv4의 기본값은 100.88.0.0/16 이고 IPv6의 기본값은 fd97::/64 입니다.

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

  • 구성이 활성화되었는지 확인하려면 다음 명령을 입력하세요.

    $ oc get network.operator.openshift.io \
      -o jsonpath="{.items[0].spec.defaultNetwork}"
    Copy to Clipboard Toggle word wrap

    변경 사항이 적용되려면 최대 30분이 걸릴 수 있습니다.

    출력 예

    {
      "ovnKubernetesConfig": {
        "ipv4": {
          "internalTransitSwitchSubnet": "100.88.1.0/16"
        },
      },
      "type": "OVNKubernetes"
    }
    Copy to Clipboard Toggle word wrap

7장. 게이트웨이 모드 구성

클러스터 관리자는 gatewayConfig 객체를 구성하여 외부 트래픽이 클러스터에서 나가는 방식을 관리할 수 있습니다. 로컬 모드의 경우 routingViaHost 사양을 true 로 설정하고, 공유 모드의 경우 false로 설정하면 됩니다.

로컬 게이트웨이 모드에서는 트래픽이 호스트를 통해 라우팅되고 결과적으로 호스트의 라우팅 테이블에 적용됩니다. 공유 게이트웨이 모드에서는 트래픽이 호스트를 통해 라우팅되지 않습니다. 대신, OVS(Open vSwitch)는 트래픽을 노드 IP 인터페이스로 직접 출력합니다.

7.1. 로컬 및 공유 게이트웨이 모드 설정

클러스터 관리자는 클러스터 네트워크 운영자의 gatewayConfig 사양을 사용하여 게이트웨이 모드를 구성할 수 있습니다. 다음 절차를 사용하면 로컬 모드의 경우 routingViaHost 필드를 true 로, 공유 모드의 경우 false로 설정할 수 있습니다.

OVN-Kubernetes와 관련이 없는 트래픽에 대한 라우터 역할을 노드의 호스트 네트워크가 수행해야 하는 경우, 선택 사항인 4단계를 따라 로컬 게이트웨이 모드와 함께 IP 전달을 활성화할 수 있습니다. 예를 들어, 로컬 게이트웨이 모드와 IP 전달을 결합하는 가능한 사용 사례는 다음과 같습니다.

  • 모든 Pod 이그레스 트래픽이 노드의 IP를 통해 전달되도록 구성
  • 외부 네트워크 주소 변환(NAT) 장치와 OVN-Kubernetes CNI 통합
  • 커널 라우팅 테이블을 사용하도록 OVN-Kubernetes CNI 구성

사전 요구 사항

  • 관리자 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 기존 네트워크 구성을 백업합니다.

    $ oc get network.operator cluster -o yaml > network-config-backup.yaml
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 로컬 게이트웨이 모드에 대해 routingViaHost 매개변수를 true 로 설정합니다.

    $ oc patch networks.operator.openshift.io cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"routingViaHost": true}}}}}'
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 로컬 게이트웨이 모드가 설정되었는지 확인하세요.

    $ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    # ...
    gatewayConfig:
            ipv4: {}
            ipv6: {}
            routingViaHost: true 
    1
    
          genevePort: 6081
          ipsecConfig:
    # ...
    Copy to Clipboard Toggle word wrap

    1
    true 값은 로컬 게이트웨이 모드를 설정하고 false 값은 공유 게이트웨이 모드를 설정합니다. 로컬 게이트웨이 모드에서는 트래픽이 호스트를 통해 라우팅됩니다. 공유 게이트웨이 모드에서는 트래픽이 호스트를 통해 라우팅되지 않습니다.
  4. 선택 사항: 다음 명령을 실행하여 IP 전달을 전역적으로 활성화합니다.

    $ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}'
    Copy to Clipboard Toggle word wrap
    1. 다음 명령을 실행하여 ipForwarding 사양이 글로벌 로 설정되었는지 확인하세요.

      $ oc get networks.operator.openshift.io cluster -o yaml | grep -A 5 "gatewayConfig"
      Copy to Clipboard Toggle word wrap

      출력 예

      apiVersion: operator.openshift.io/v1
      kind: Network
      metadata:
        name: cluster
      # ...
      gatewayConfig:
              ipForwarding: Global
              ipv4: {}
              ipv6: {}
              routingViaHost: true
            genevePort: 6081
      # ...
      Copy to Clipboard Toggle word wrap

8장. 기본 네트워크에서 외부 게이트웨이 구성

클러스터 관리자는 기본 네트워크에서 외부 게이트웨이를 구성할 수 있습니다.

이 기능은 다음과 같은 이점을 제공합니다.

  • 네임스페이스별로 이탈 트래픽에 대한 세부적인 제어
  • 정적 및 동적 외부 게이트웨이 IP 주소의 유연한 구성
  • IPv4 및 IPv6 주소 패밀리 모두 지원

8.1. 사전 요구 사항

  • 귀하의 클러스터는 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
  • 귀하의 인프라는 보조 외부 게이트웨이에서 트래픽을 라우팅하도록 구성되어 있습니다.

k8s.ovn.org API 그룹의 AdminPolicyBasedExternalRoute 사용자 정의 리소스(CR)를 사용하여 보조 외부 게이트웨이를 구성합니다. CR은 외부 게이트웨이의 IP 주소를 지정하기 위한 정적 및 동적 접근 방식을 지원합니다.

AdminPolicyBasedExternalRoute CR이 대상으로 하는 각 네임스페이스는 다른 AdminPolicyBasedExternalRoute CR에 의해 선택될 수 없습니다. 네임스페이스에는 동시에 보조 외부 게이트웨이가 있을 수 없습니다.

정책 변경 사항은 컨트롤러에서 격리됩니다. 정책이 적용되지 않으면 다른 정책을 변경하더라도 다른 정책을 다시 시도하지 않습니다. 정책 자체나 대상 네임스페이스, Pod 게이트웨이 또는 동적 홉에서 이를 호스팅하는 네임스페이스와 같은 정책과 관련된 개체에 대한 업데이트가 이루어질 때에만 정책은 변경으로 인해 발생할 수 있는 차이점을 적용하여 다시 평가됩니다.

정적 할당
IP 주소를 직접 지정합니다.
동적 할당

네임스페이스 및 포드 선택기와 선택적 네트워크 연결 정의를 사용하여 간접적으로 IP 주소를 지정합니다.

  • 네트워크 연결 정의의 이름이 제공되는 경우 네트워크 연결의 외부 게이트웨이 IP 주소가 사용됩니다.
  • 네트워크 연결 정의의 이름이 제공되지 않으면 포드 자체의 외부 게이트웨이 IP 주소가 사용됩니다. 하지만 이 방법은 Pod가 hostNetwork를 true 로 설정하여 구성된 경우에만 작동합니다.

8.3. AdminPolicyBasedExternalRoute 객체 구성

다음 속성을 사용하여 클러스터 범위의 AdminPolicyBasedExternalRoute 객체를 정의할 수 있습니다. 네임스페이스는 한 번에 하나의 AdminPolicyBasedExternalRoute CR에서만 선택할 수 있습니다.

Expand
표 8.1. AdminPolicyBasedExternalRoute object
필드유형설명

metadata.name

string

AdminPolicyBasedExternalRoute 개체의 이름을 지정합니다.

spec.from

string

라우팅 정책이 적용되는 네임스페이스 선택기를 지정합니다. 외부 트래픽에는 namespaceSelector 만 지원됩니다. 예를 들면 다음과 같습니다.

from:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
Copy to Clipboard Toggle word wrap

네임스페이스는 하나의 AdminPolicyBasedExternalRoute CR에서만 타겟으로 지정될 수 있습니다. 두 개 이상의 AdminPolicyBasedExternalRoute CR에서 네임스페이스를 선택한 경우 동일한 네임스페이스를 대상으로 하는 두 번째 CR과 그 이후 CR에서 실패 오류 상태가 발생합니다. 업데이트를 적용하려면 정책 자체나 정책과 관련된 개체(예: 대상 네임스페이스, Pod 게이트웨이 또는 동적 홉에서 이를 호스팅하는 네임스페이스)를 변경해야 정책이 다시 평가되고 변경 사항이 적용됩니다.

spec.nextHops

object

패킷이 전달되는 대상을 지정합니다. 정적 이거나 동적 이어야 합니다. 적어도 하나의 다음 홉을 정의해야 합니다.

Expand
표 8.2. nextHops 객체
필드유형설명

static

array

정적 IP 주소의 배열을 지정합니다.

dynamic

array

외부 게이트웨이 대상으로 사용하기 위해 네트워크 연결 정의로 구성된 Pod에 해당하는 Pod 선택기 배열을 지정합니다.

Expand
표 8.3. nextHops.static object
필드유형설명

ip

string

다음 대상 홉의 IPv4 또는 IPv6 주소를 지정합니다.

bfdEnabled

boolean

선택 사항: 네트워크에서 양방향 전달 감지(BFD)가 지원되는지 여부를 지정합니다. 기본값은 false입니다.

Expand
표 8.4. nextHops.dynamic object
필드유형설명

podSelector

string

네임스페이스에서 이 네트워크 구성과 일치하는 포드를 필터링하기 위해 [집합 기반]( https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement ) 레이블 선택기를 지정합니다.

namespaceSelector

string

podSelector가 적용되는 네임스페이스를 필터링하기 위한 세트 기반 선택기를 지정합니다. 이 필드에 값을 지정해야 합니다.

bfdEnabled

boolean

선택 사항: 네트워크에서 양방향 전달 감지(BFD)가 지원되는지 여부를 지정합니다. 기본값은 false입니다.

networkAttachmentName

string

선택 사항: 네트워크 연결 정의의 이름을 지정합니다. 이름은 Pod에 연결된 논리적 네트워크 목록과 일치해야 합니다. 이 필드가 지정되지 않으면 Pod의 호스트 네트워크가 사용됩니다. 하지만 호스트 네트워크를 사용하려면 포드를 호스트 네트워크 포드로 구성해야 합니다.

8.3.1. 보조 외부 게이트웨이 구성 예시

다음 예에서 AdminPolicyBasedExternalRoute 객체는 kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059 레이블이 있는 네임스페이스의 포드에 대한 외부 게이트웨이로 두 개의 정적 IP 주소를 구성합니다.

apiVersion: k8s.ovn.org/v1
kind: AdminPolicyBasedExternalRoute
metadata:
  name: default-route-policy
spec:
  from:
    namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: novxlan-externalgw-ecmp-4059
  nextHops:
    static:
    - ip: "172.18.0.8"
    - ip: "172.18.0.9"
Copy to Clipboard Toggle word wrap

다음 예에서 AdminPolicyBasedExternalRoute 개체는 동적 외부 게이트웨이를 구성합니다. 외부 게이트웨이에 사용되는 IP 주소는 선택된 각 포드와 연결된 추가 네트워크 연결에서 파생됩니다.

apiVersion: k8s.ovn.org/v1
kind: AdminPolicyBasedExternalRoute
metadata:
  name: shadow-traffic-policy
spec:
  from:
    namespaceSelector:
      matchLabels:
        externalTraffic: ""
  nextHops:
    dynamic:
    - podSelector:
        matchLabels:
          gatewayPod: ""
      namespaceSelector:
        matchLabels:
          shadowTraffic: ""
      networkAttachmentName: shadow-gateway
    - podSelector:
        matchLabels:
          gigabyteGW: ""
      namespaceSelector:
        matchLabels:
          gatewayNamespace: ""
      networkAttachmentName: gateway
Copy to Clipboard Toggle word wrap

다음 예에서 AdminPolicyBasedExternalRoute 개체는 정적 및 동적 외부 게이트웨이를 모두 구성합니다.

apiVersion: k8s.ovn.org/v1
kind: AdminPolicyBasedExternalRoute
metadata:
  name: multi-hop-policy
spec:
  from:
    namespaceSelector:
      matchLabels:
        trafficType: "egress"
  nextHops:
    static:
    - ip: "172.18.0.8"
    - ip: "172.18.0.9"
    dynamic:
    - podSelector:
        matchLabels:
          gatewayPod: ""
      namespaceSelector:
        matchLabels:
          egressTraffic: ""
      networkAttachmentName: gigabyte
Copy to Clipboard Toggle word wrap

8.4. 보조 외부 게이트웨이 구성

클러스터의 네임스페이스에 대해 기본 네트워크에서 외부 게이트웨이를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. AdminPolicyBasedExternalRoute 개체가 포함된 YAML 파일을 만듭니다.
  2. 관리자 정책 기반 외부 경로를 생성하려면 다음 명령을 입력하세요.

    $ oc create -f <file>.yaml
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <file>
    이전 단계에서 만든 YAML 파일의 이름을 지정합니다.

    출력 예

    adminpolicybasedexternalroute.k8s.ovn.org/default-route-policy created
    Copy to Clipboard Toggle word wrap

  3. 관리자 정책 기반 외부 경로가 생성되었는지 확인하려면 다음 명령을 입력하세요.

    $ oc describe apbexternalroute <name> | tail -n 6
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <name>
    AdminPolicyBasedExternalRoute 개체의 이름을 지정합니다.

    출력 예

    Status:
      Last Transition Time:  2023-04-24T15:09:01Z
      Messages:
      Configured external gateway IPs: 172.18.0.8
      Status:  Success
    Events:  <none>
    Copy to Clipboard Toggle word wrap

8.5. 추가 리소스

9장. 송신 IP 주소 구성

클러스터 관리자는 OVN-Kubernetes 컨테이너 네트워크 인터페이스(CNI) 네트워크 플러그인을 구성하여 네임스페이스 또는 네임스페이스의 특정 포드에 하나 이상의 송신 IP 주소를 할당할 수 있습니다.

9.1. 송신 IP 주소 아키텍처 설계 및 구현

OpenShift Container Platform 송신 IP 주소 기능을 사용하면 하나 이상의 네임스페이스에 있는 하나 이상의 Pod에서 발생하는 트래픽의 소스 IP 주소가 클러스터 네트워크 외부 서비스에 일관되게 표시되도록 할 수 있습니다.

예를 들어 클러스터 외부 서버에서 호스팅되는 데이터베이스를 주기적으로 쿼리하는 Pod가 있을 수 있습니다. 서버에 대한 액세스 요구 사항을 적용하기 위해 패킷 필터링 장치는 특정 IP 주소의 트래픽만 허용하도록 구성됩니다. 특정 Pod에서만 서버에 안정적으로 액세스할 수 있도록 허용하려면 서버에 요청하는 Pod에 대해 특정 송신 IP 주소를 구성하면 됩니다.

네임스페이스에 할당된 송신 IP 주소는 특정 대상으로 트래픽을 전송하는 데 사용되는 송신 라우터와 다릅니다.

일부 클러스터 구성에서는 애플리케이션 포드와 인그레스 라우터 포드가 동일한 노드에서 실행됩니다. 이 시나리오에서 애플리케이션 프로젝트에 대한 송신 IP 주소를 구성하는 경우 애플리케이션 프로젝트에서 경로로 요청을 보낼 때 해당 IP 주소는 사용되지 않습니다.

중요

송신 IP 주소는 ifcfg-eth0과 같은 Linux 네트워크 구성 파일에서 구성하지 않아야 합니다.

9.1.1. 플랫폼 지원

다음 표에는 다양한 플랫폼의 송신 IP 주소 기능에 대한 지원이 요약되어 있습니다.

Expand
플랫폼지원됨

베어 메탈

제공됨

VMware vSphere

제공됨

Red Hat OpenStack Platform (RHOSP)

제공됨

AWS(Amazon Web Services)

제공됨

GCP(Google Cloud Platform)

제공됨

Microsoft Azure

제공됨

IBM Z® 및 IBM® LinuxONE

제공됨

Red Hat Enterprise Linux(RHEL) KVM용 IBM Z® 및 IBM® LinuxONE

제공됨

IBM Power®

제공됨

Nutanix

제공됨

중요

Amazon Web Services(AWS)에서 프로비저닝된 클러스터에서는 EgressIP 기능을 사용하여 제어 평면 노드에 송신 IP 주소를 할당하는 것이 지원되지 않습니다. (BZ#2039656).

9.1.2. 퍼블릭 클라우드 플랫폼 고려 사항

일반적으로 퍼블릭 클라우드 제공업체는 이탈 IP에 제한을 둡니다. 즉, 퍼블릭 클라우드 인프라에 프로비저닝된 클러스터의 경우 노드당 할당 가능한 IP 주소의 절대 수에 제약이 있습니다. 노드당 할당 가능한 IP 주소의 최대 수 또는 IP 용량은 다음 공식으로 설명할 수 있습니다.

IP capacity = public cloud default capacity - sum(current IP assignments)
Copy to Clipboard Toggle word wrap

Egress IP 기능은 노드당 IP 주소 용량을 관리하지만 배포 시 이러한 제약 조건을 계획하는 것이 중요합니다. 예를 들어, 퍼블릭 클라우드 제공자가 노드당 IP 주소 용량을 10개로 제한하고 노드가 8개인 경우, 할당 가능한 IP 주소의 총 수는 80개에 불과합니다. 더 높은 IP 주소 용량을 확보하려면 추가 노드를 할당해야 합니다. 예를 들어, 할당 가능한 IP 주소가 150개 필요한 경우 7개의 추가 노드를 할당해야 합니다.

퍼블릭 클라우드 환경에서 모든 노드의 IP 용량과 서브넷을 확인하려면 oc get node <노드 이름> -o yaml 명령을 입력하면 됩니다. cloud.network.openshift.io/egress-ipconfig 주석에는 노드의 용량 및 서브넷 정보가 포함되어 있습니다.

주석 값은 기본 네트워크 인터페이스에 대한 다음 정보를 제공하는 필드가 있는 단일 객체가 있는 배열입니다.

  • interface : AWS 및 Azure의 인터페이스 ID와 GCP의 인터페이스 이름을 지정합니다.
  • ifaddr : 하나 또는 두 개의 IP 주소 패밀리에 대한 서브넷 마스크를 지정합니다.
  • 용량 : 노드의 IP 주소 용량을 지정합니다. AWS에서는 IP 주소 용량이 IP 주소 패밀리별로 제공됩니다. Azure와 GCP에서는 IP 주소 용량에 IPv4 주소와 IPv6 주소가 모두 포함됩니다.

노드 간 트래픽에 대한 이그레스 IP 주소를 자동으로 연결하고 분리할 수 있습니다. 이를 통해 네임스페이스의 여러 포드에서 발생하는 트래픽이 클러스터 외부 위치로 일관된 소스 IP 주소를 가질 수 있습니다. 이는 또한 OpenShift Container Platform 4.19의 Red Hat OpenShift Networking의 기본 네트워킹 플러그인인 OpenShift SDN 및 OVN-Kubernetes도 지원합니다.

참고

RHOSP 송신 IP 주소 기능은 egressip-<IP 주소> 라는 Neutron 예약 포트를 생성합니다. OpenShift Container Platform 클러스터 설치에 사용된 것과 동일한 RHOSP 사용자를 사용하면 이 예약 포트에 부동 IP 주소를 할당하여 송신 트래픽에 대한 예측 가능한 SNAT 주소를 가질 수 있습니다. 예를 들어 노드 장애 조치로 인해 RHOSP 네트워크의 송신 IP 주소가 한 노드에서 다른 노드로 이동되면 Neutron 예약 포트가 제거되고 다시 생성됩니다. 즉, 플로팅 IP 연결이 끊어졌고 플로팅 IP 주소를 새 예약 포트에 수동으로 다시 할당해야 합니다.

참고

RHOSP 클러스터 관리자가 예약 포트에 플로팅 IP를 할당하면 OpenShift Container Platform은 예약 포트를 삭제할 수 없습니다. CloudPrivateIPConfig 개체는 RHOSP 클러스터 관리자가 예약 포트에서 플로팅 IP를 할당 해제할 때까지 삭제 및 이동 작업을 수행할 수 없습니다.

다음 예는 여러 퍼블릭 클라우드 공급자의 노드에서 주석을 설명한 것입니다. 가독성을 위해 주석은 들여쓰기되어 있습니다.

AWS의 cloud.network.openshift.io/egress-ipconfig 주석 예시

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"eni-078d267045138e436",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ipv4":14,"ipv6":15}
  }
]
Copy to Clipboard Toggle word wrap

GCP의 cloud.network.openshift.io/egress-ipconfig 주석 예시

cloud.network.openshift.io/egress-ipconfig: [
  {
    "interface":"nic0",
    "ifaddr":{"ipv4":"10.0.128.0/18"},
    "capacity":{"ip":14}
  }
]
Copy to Clipboard Toggle word wrap

다음 섹션에서는 용량 계산에 사용할 수 있는 지원되는 퍼블릭 클라우드 환경의 IP 주소 용량을 설명합니다.

9.1.2.1. Amazon Web Services(AWS) IP 주소 용량 제한

AWS에서 IP 주소 할당에 대한 제약은 구성된 인스턴스 유형에 따라 달라집니다. 자세한 내용은 인스턴스 유형별 네트워크 인터페이스당 IP 주소를 참조하세요.

9.1.2.2. Google Cloud Platform(GCP) IP 주소 용량 제한

GCP에서 네트워킹 모델은 IP 주소 할당이 아닌 IP 주소 별칭을 통해 추가 노드 IP 주소를 구현합니다. 그러나 IP 주소 용량은 IP 별칭 용량에 직접 매핑됩니다.

IP 별칭 할당에는 다음과 같은 용량 제한이 있습니다.

  • 노드당 IP 별칭의 최대 개수는 IPv4와 IPv6 모두 100개입니다.
  • VPC당 IP 별칭의 최대 개수는 지정되어 있지 않지만, OpenShift Container Platform 확장성 테스트 결과 최대 개수가 약 15,000개로 나타났습니다.

자세한 내용은 인스턴스당 할당량 및 별칭 IP 범위 개요를 참조하세요.

9.1.2.3. Microsoft Azure IP 주소 용량 제한

Azure에서는 IP 주소 할당에 대해 다음과 같은 용량 제한이 있습니다.

  • NIC당 할당 가능한 IP 주소의 최대 수는 IPv4와 IPv6 모두 256입니다.
  • 가상 네트워크당 할당된 IP 주소의 최대 수는 65,536을 초과할 수 없습니다.

자세한 내용은 네트워킹 제한을 참조하세요.

OpenShift Container Platform에서 송신 IP는 관리자에게 네트워크 트래픽을 제어할 수 있는 방법을 제공합니다. 탈출 IP는 br-ex Open vSwitch(OVS) 브리지 인터페이스 및 IP 연결이 활성화된 모든 물리적 인터페이스와 함께 사용할 수 있습니다.

다음 명령을 실행하여 네트워크 인터페이스 유형을 검사할 수 있습니다.

$ ip -details link show
Copy to Clipboard Toggle word wrap

기본 네트워크 인터페이스에는 서브넷 마스크도 포함된 노드 IP 주소가 지정됩니다. 클러스터 내의 각 노드에 대한 Kubernetes 노드 개체에서 k8s.ovn.org/node-primary-ifaddr 주석을 검사하여 이 노드 IP 주소에 대한 정보를 검색할 수 있습니다. 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는 특정 네임스페이스와 포드에서 나가는 네트워크 트래픽을 제어하고 지시하는 메커니즘을 제공합니다. 이렇게 하면 특정 네트워크 인터페이스와 특정 출구 IP 주소를 통해 클러스터에서 나갈 수 있습니다.

기본 네트워크 인터페이스가 아닌 네트워크 인터페이스에 출구 IP를 할당하기 위한 요구 사항

기본 네트워크 인터페이스가 아닌 특정 인터페이스를 통해 송신 IP 및 트래픽을 라우팅하려는 사용자의 경우 다음 조건을 충족해야 합니다.

  • OpenShift Container Platform은 베어 메탈 클러스터에 설치됩니다. 이 기능은 클라우드나 하이퍼바이저 환경에서는 비활성화됩니다.
  • OpenShift Container Platform 포드가 호스트 네트워크 로 구성되지 않았습니다.
  • 네트워크 인터페이스가 제거되거나, 인터페이스에서 송신 IP를 호스팅할 수 있게 하는 IP 주소와 서브넷 마스크가 제거되면 송신 IP가 재구성됩니다. 따라서 출구 IP는 다른 노드와 인터페이스에 할당될 수 있습니다.
  • 보조 네트워크 인터페이스 카드(NIC)에서 Egress IP 주소를 사용하는 경우 노드 튜닝 운영자를 사용하여 보조 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 주소가 사용될지 보장할 수 없습니다. 예를 들어, 포드가 두 개의 송신 IP 주소( 10.10.20.110.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 오브젝트

네임스페이스는 다음 매니페스트에 정의됩니다.

네임스페이스 오브젝트

apiVersion: v1
kind: Namespace
metadata:
  name: namespace1
  labels:
    env: prod
---
apiVersion: v1
kind: Namespace
metadata:
  name: namespace2
  labels:
    env: prod
Copy to Clipboard Toggle word wrap

EgressIP 오브젝트

다음 EgressIP 오브젝트는 env 라벨이 prod로 설정된 모든 포드를 선택하는 구성을 설명합니다. 선택한 포드의 송신 IP 주소는 192.168.126.10192.168.126.102입니다.

EgressIP 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egressips-prod
spec:
  egressIPs:
  - 192.168.126.10
  - 192.168.126.102
  namespaceSelector:
    matchLabels:
      env: prod
status:
  items:
  - node: node1
    egressIP: 192.168.126.10
  - node: node3
    egressIP: 192.168.126.102
Copy to Clipboard Toggle word wrap

이전 예제의 구성에 대해 OpenShift Container Platform은 두 송신 IP 주소를 사용 가능한 노드에 할당합니다. status 필드는 송신 IP 주소가 할당되었는지 여부와 위치를 반영합니다.

9.2. EgressIP 오브젝트

다음 YAML에서는 EgressIP 오브젝트의 API를 설명합니다. 오브젝트의 범위는 클러스터 전체이며 네임스페이스에 생성되지 않습니다.

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: <name> 
1

spec:
  egressIPs: 
2

  - <ip_address>
  namespaceSelector: 
3

    ...
  podSelector: 
4

    ...
Copy to Clipboard Toggle word wrap
1
EgressIPs 오브젝트의 이름입니다.
2
하나 이상의 IP 주소로 이루어진 배열입니다.
3
송신 IP 주소를 연결할 네임스페이스에 대해 하나 이상의 선택기입니다.
4
선택사항: 지정된 네임스페이스에서 송신 IP 주소를 연결할 Pod에 대해 하나 이상의 선택기입니다. 이러한 선택기를 적용하면 네임스페이스 내에서 Pod 하위 집합을 선택할 수 있습니다.

다음 YAML은 네임스페이스 선택기에 대한 스탠자를 설명합니다.

네임스페이스 선택기 스탠자

namespaceSelector: 
1

  matchLabels:
    <label_name>: <label_value>
Copy to Clipboard Toggle word wrap

1
네임스페이스에 대해 일치하는 하나 이상의 규칙입니다. 둘 이상의 일치 규칙이 제공되면 일치하는 모든 네임스페이스가 선택됩니다.

다음 YAML은 Pod 선택기에 대한 선택적 스탠자를 설명합니다.

Pod 선택기 스탠자

podSelector: 
1

  matchLabels:
    <label_name>: <label_value>
Copy to Clipboard Toggle word wrap

1
선택사항: 지정된 namespaceSelector 규칙과 일치하는 네임스페이스의 Pod에 대해 일치하는 하나 이상의 규칙입니다. 지정된 경우 일치하는 Pod만 선택됩니다. 네임스페이스의 다른 Pod는 선택되지 않습니다.

다음 예에서 EgressIP 오브젝트는 192.168.126.11192.168.126.102 송신 IP 주소를 app 라벨을 web으로 설정하고 env 라벨을 prod로 설정한 네임스페이스에 있는 포드와 연결합니다.

EgressIP 오브젝트의 예

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group1
spec:
  egressIPs:
  - 192.168.126.11
  - 192.168.126.102
  podSelector:
    matchLabels:
      app: web
  namespaceSelector:
    matchLabels:
      env: prod
Copy to Clipboard Toggle word wrap

다음 예에서 EgressIP 오브젝트는 192.168.127.30192.168.127.40 송신 IP 주소를 environment 레이블이 development로 설정되지 않은 모든 Pod와 연결합니다.

EgressIP 오브젝트의 예

apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
  name: egress-group2
spec:
  egressIPs:
  - 192.168.127.30
  - 192.168.127.40
  namespaceSelector:
    matchExpressions:
    - key: environment
      operator: NotIn
      values:
      - development
Copy to Clipboard Toggle word wrap

9.3. egressIPConfig 객체

Egress IP의 기능으로, reachabilityTotalTimeoutSeconds 매개변수는 EgressIP 노드 도달성 검사 총 시간 초과를 초 단위로 구성합니다. 이 제한 시간 내에 EgressIP 노드에 도달할 수 없는 경우 해당 노드는 다운된 것으로 선언됩니다.

egressIPConfig 개체의 구성 파일에서 reachabilityTotalTimeoutSeconds 값을 설정할 수 있습니다. 큰 값을 설정하면 EgressIP 구현이 노드 변경에 느리게 반응할 수 있습니다. 문제가 발생하여 접근할 수 없는 EgressIP 노드의 경우 구현이 느리게 반응합니다.

egressIPConfig 객체에서 reachabilityTotalTimeoutSeconds 매개변수를 생략하면 플랫폼은 시간이 지남에 따라 변경될 수 있는 합리적인 기본값을 선택합니다. 현재 기본값은 1 초입니다. 값 0 은 EgressIP 노드에 대한 도달성 검사를 비활성화합니다.

다음 egressIPConfig 객체는 reachabilityTotalTimeoutSeconds 를 기본 1 초 프로브에서 5 초 프로브로 변경하는 방법을 설명합니다.

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  defaultNetwork:
    ovnKubernetesConfig:
      egressIPConfig: 
1

        reachabilityTotalTimeoutSeconds: 5 
2

      gatewayConfig:
        routingViaHost: false
      genevePort: 6081
Copy to Clipboard Toggle word wrap
1
egressIPConfigEgressIP 개체의 옵션에 대한 구성을 보관합니다. 이러한 구성을 변경하면 EgressIP 객체를 확장할 수 있습니다.
2
reachabilityTotalTimeoutSeconds 값은 0 ~ 60 까지의 정수 값을 허용합니다. 값 0 은 egressIP 노드의 도달성 검사를 비활성화합니다. 1 에서 60 사이의 값을 설정하면 프로브가 노드에 도달 가능성 확인을 보내는 데 걸리는 시간 제한(초)에 해당합니다.

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="" 
    1
    Copy to Clipboard Toggle word wrap
    1
    레이블을 지정할 노드 이름입니다.
    작은 정보

    다음 YAML을 적용하여 노드에 레이블을 추가할 수 있습니다.

    apiVersion: v1
    kind: Node
    metadata:
      labels:
        k8s.ovn.org/egress-assignable: ""
      name: <node_name>
    Copy to Clipboard Toggle word wrap

9.5. 다음 단계

10장. 송신 IP 주소 할당

클러스터 관리자는 네임스페이스 또는 네임스페이스의 특정 Pod에서 클러스터를 떠나는 트래픽에 송신 IP 주소를 할당할 수 있습니다.

10.1. 네임스페이스에 송신 IP 주소 할당

하나 이상의 송신 IP 주소를 네임스페이스 또는 네임스페이스의 특정 Pod에 할당할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인합니다.
  • 송신 IP 주소를 호스팅할 하나 이상의 노드를 구성합니다.

프로세스

  1. EgressIP 오브젝트를 만듭니다.

    1. <egressips_name>.yaml 파일을 만듭니다. 여기서 <egressips_name>은 오브젝트 이름입니다.
    2. 생성한 파일에서 다음 예와 같이 EgressIPs 오브젝트를 정의합니다.

      apiVersion: k8s.ovn.org/v1
      kind: EgressIP
      metadata:
        name: egress-project1
      spec:
        egressIPs:
        - 192.168.127.10
        - 192.168.127.11
        namespaceSelector:
          matchLabels:
            env: qa
      Copy to Clipboard Toggle word wrap
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다.

    $ oc apply -f <egressips_name>.yaml 
    1
    Copy to Clipboard Toggle word wrap
    1
    <egressips_name>을 오브젝트 이름으로 변경합니다.

    출력 예

    egressips.k8s.ovn.org/<egressips_name> created
    Copy to Clipboard Toggle word wrap

  3. 선택사항: 나중에 변경할 수 있도록 <egressips_name>.yaml 파일을 저장합니다.
  4. 송신 IP 주소가 필요한 네임스페이스에 레이블을 추가합니다. 1단계에서 정의한 EgressIP 개체의 네임스페이스에 레이블을 추가하려면 다음 명령을 실행합니다.

    $ oc label ns <namespace> env=qa 
    1
    Copy to Clipboard Toggle word wrap
    1
    <네임스페이스>를 출구 IP 주소가 필요한 네임스페이스로 바꾸세요.

검증

  • 클러스터에서 사용 중인 모든 송신 IP를 표시하려면 다음 명령을 입력하세요.

    $ oc get egressip -o yaml
    Copy to Clipboard Toggle word wrap
    참고

    oc get egressip 명령어는 구성된 주소 수에 관계없이 하나의 송신 IP 주소만 반환합니다. 이는 버그가 아니며 Kubernetes의 제한 사항입니다. 해결 방법으로 -o yaml 또는 -o json 플래그를 전달하여 사용 중인 모든 송신 IP 주소를 반환할 수 있습니다.

    출력 예

    # ...
    spec:
      egressIPs:
      - 192.168.127.10
      - 192.168.127.11
    # ...
    Copy to Clipboard Toggle word wrap

11장. 이그레스 서비스 구성

클러스터 관리자는 송신 서비스를 사용하여 로드 밸런서 서비스 뒤에 있는 포드에 대한 송신 트래픽을 구성할 수 있습니다.

중요

탈출 서비스는 기술 미리보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음과 같은 방법으로 EgressService 사용자 정의 리소스(CR)를 사용하여 이그레스 트래픽을 관리할 수 있습니다.

  • 로드 밸런서 서비스 뒤에 있는 포드의 송신 트래픽에 대한 소스 IP 주소로 로드 밸런서 서비스 IP 주소를 할당합니다.

    이 컨텍스트에서 로드 밸런서 IP 주소를 소스 IP 주소로 할당하면 단일 출구 및 입구 지점을 제공하는 데 유용합니다. 예를 들어, 일부 시나리오에서는 로드 밸런서 서비스 뒤에 있는 애플리케이션과 통신하는 외부 시스템은 애플리케이션의 소스 및 대상 IP 주소가 동일할 것으로 예상할 수 있습니다.

    참고

    서비스 뒤에 있는 포드의 송신 트래픽에 로드 밸런서 서비스 IP 주소를 할당하면 OVN-Kubernetes는 수신 및 송신 지점을 단일 노드로 제한합니다. 이는 MetalLB가 일반적으로 제공하는 트래픽 부하 분산을 제한합니다.

  • 로드 밸런서 뒤에 있는 포드의 송신 트래픽을 기본 노드 네트워크가 아닌 다른 네트워크에 할당합니다.

    이는 로드 밸런서 뒤에 있는 애플리케이션의 송신 트래픽을 기본 네트워크가 아닌 다른 네트워크에 할당하는 데 유용합니다. 일반적으로 다양한 네트워크는 네트워크 인터페이스와 연결된 VRF 인스턴스를 사용하여 구현됩니다.

11.1. Egress 서비스 사용자 정의 리소스

EgressService 사용자 정의 리소스에서 egress 서비스에 대한 구성을 정의합니다. 다음 YAML은 송신 서비스 구성을 위한 필드를 설명합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressService
metadata:
  name: <egress_service_name> 
1

  namespace: <namespace> 
2

spec:
  sourceIPBy: <egress_traffic_ip> 
3

  nodeSelector: 
4

    matchLabels:
      node-role.kubernetes.io/<role>: ""
  network: <egress_traffic_network> 
5
Copy to Clipboard Toggle word wrap
1
출구 서비스의 이름을 지정합니다. EgressService 리소스의 이름은 수정하려는 로드 밸런서 서비스의 이름과 일치해야 합니다.
2
송신 서비스에 대한 네임스페이스를 지정합니다. EgressService 의 네임스페이스는 수정하려는 로드 밸런서 서비스의 네임스페이스와 일치해야 합니다. 송신 서비스는 네임스페이스 범위입니다.
3
서비스 뒤에 있는 포드의 송신 트래픽의 소스 IP 주소를 지정합니다. 유효한 값은 LoadBalancerIP 또는 Network 입니다. LoadBalancerIP 값을 사용하여 LoadBalancer 서비스 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 지정합니다. 네트워크 인터페이스 IP 주소를 송신 트래픽의 소스 IP 주소로 지정하려면 네트워크를 지정합니다.
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와 일치하는지 확인하세요. 네트워크 사양을 포함하지 않으면 송신 서비스는 기본 호스트 네트워크를 사용합니다.

예시 탈출 서비스 사양

apiVersion: k8s.ovn.org/v1
kind: EgressService
metadata:
  name: test-egress-service
  namespace: test-namespace
spec:
  sourceIPBy: "LoadBalancerIP"
  nodeSelector:
    matchLabels:
      vrf: "true"
  network: "2"
Copy to Clipboard Toggle word wrap

11.2. 이그레스 서비스 배포

LoadBalancer 서비스 뒤에 있는 Pod의 송신 트래픽을 관리하기 위해 송신 서비스를 배포할 수 있습니다.

다음 예제에서는 LoadBalancer 서비스의 수신 IP 주소와 동일한 소스 IP 주소를 갖도록 송신 트래픽을 구성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • MetalLB BGPPeer 리소스를 구성했습니다.

프로세스

  1. 서비스에 필요한 IP로 IPAddressPool CR을 만듭니다.

    1. 다음 예시와 같은 내용을 포함하는 ip-addr-pool.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: example-pool
        namespace: metallb-system
      spec:
        addresses:
        - 172.19.0.100/32
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 IP 주소 풀에 대한 구성을 적용합니다.

      $ oc apply -f ip-addr-pool.yaml
      Copy to Clipboard Toggle word wrap
  2. 서비스EgressService CR을 만듭니다.

    1. 다음 예시와 같은 내용을 포함하는 service-egress-service.yaml 과 같은 파일을 만듭니다.

      apiVersion: v1
      kind: Service
      metadata:
        name: example-service
        namespace: example-namespace
        annotations:
          metallb.io/address-pool: example-pool 
      1
      
      spec:
        selector:
          app: example
        ports:
          - name: http
            protocol: TCP
            port: 8080
            targetPort: 8080
        type: LoadBalancer
      ---
      apiVersion: k8s.ovn.org/v1
      kind: EgressService
      metadata:
        name: example-service
        namespace: example-namespace
      spec:
        sourceIPBy: "LoadBalancerIP" 
      2
      
        nodeSelector: 
      3
      
          matchLabels:
            node-role.kubernetes.io/worker: ""
      Copy to Clipboard Toggle word wrap
      1
      LoadBalancer 서비스는 MetalLB가 example-pool IP 주소 풀에서 할당한 IP 주소를 사용합니다.
      2
      이 예제에서는 LoadBalancerIP 값을 사용하여 LoadBalancer 서비스의 수신 IP 주소를 송신 트래픽의 소스 IP 주소로 지정합니다.
      3
      LoadBalancerIP 값을 지정하면 단일 노드가 LoadBalancer 서비스의 트래픽을 처리합니다. 이 예에서는 작업자 레이블이 있는 노드만 트래픽을 처리하도록 선택할 수 있습니다. 노드가 선택되면 OVN-Kubernetes는 다음 형식으로 노드 에 egress-service.k8s.ovn.org/<svc-namespace>-<svc-name>: "" 레이블을 지정합니다.
      참고

      sourceIPBy: "LoadBalancerIP" 설정을 사용하는 경우 BGPAdvertisement 사용자 정의 리소스(CR)에서 로드 밸런서 노드를 지정해야 합니다.

    2. 다음 명령을 실행하여 서비스 및 송신 서비스에 대한 구성을 적용합니다.

      $ oc apply -f service-egress-service.yaml
      Copy to Clipboard Toggle word wrap
  3. 서비스를 광고하려면 BGPAdvertisement CR을 만드세요.

    1. 다음 예시와 같은 내용을 포함하는 service-bgp-advertisement.yaml 과 같은 파일을 만듭니다.

      apiVersion: metallb.io/v1beta1
      kind: BGPAdvertisement
      metadata:
        name: example-bgp-adv
        namespace: metallb-system
      spec:
        ipAddressPools:
        - example-pool
        nodeSelectors:
        - matchLabels:
            egress-service.k8s.ovn.org/example-namespace-example-service: "" 
      1
      Copy to Clipboard Toggle word wrap
      1
      이 예에서 EgressService CR은 부하 분산 장치 서비스 IP 주소를 사용하도록 송신 트래픽의 소스 IP 주소를 구성합니다. 따라서 포드에서 발생한 트래픽에 대해 동일한 반환 경로를 사용하도록 반환 트래픽에 대한 로드 밸런서 노드를 지정해야 합니다.

검증

  1. 다음 명령을 실행하여 MetalLB 서비스 뒤에서 실행되는 포드의 애플리케이션 엔드포인트에 액세스할 수 있는지 확인하세요.

    $ curl <external_ip_address>:<port_number> 
    1
    Copy to Clipboard Toggle word wrap
    1
    애플리케이션 엔드포인트에 맞게 외부 IP 주소와 포트 번호를 업데이트합니다.
  2. 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 주소를 사용해야 하는 클라이언트 포드는 대상 IP에 직접 연결하는 대신 송신 라우터의 서비스에 액세스하도록 구성해야 합니다. curl 명령을 사용하면 애플리케이션 포드에서 대상 서비스와 포트에 액세스할 수 있습니다. 예를 들면 다음과 같습니다.

$ curl <router_service_IP> <port>
Copy to Clipboard Toggle word wrap
참고

이그레스 라우터 CNI 플러그인은 리디렉트 모드만 지원합니다. 이그레스 라우터 CNI 플러그인은 HTTP 프록시 모드나 DNS 프록시 모드를 지원하지 않습니다.

12.1.2. 송신 라우터 Pod 구현

송신 라우터 구현은 송신 라우터 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용합니다. 이 플러그인은 포드에 보조 네트워크 인터페이스를 추가합니다.

송신 라우터는 두 개의 네트워크 인터페이스가 있는 포드입니다. 예를 들어 포드에는 eth0net1 네트워크 인터페이스가 있을 수 있습니다. eth0 인터페이스는 클러스터 네트워크에 있으며 포드는 일반 클러스터 관련 네트워크 트래픽에 대한 인터페이스를 계속 사용합니다. net1 인터페이스는 보조 네트워크에 있으며 해당 네트워크에 대한 IP 주소 및 게이트웨이가 있습니다. OpenShift Container Platform 클러스터의 다른 포드는 송신 라우터 서비스에 액세스할 수 있으며, 서비스를 통해 포드가 외부 서비스에 액세스할 수 있습니다. 송신 라우터는 포드와 외부 시스템 간의 브리지 역할을 합니다.

송신 라우터를 종료하는 트래픽은 노드를 통해 종료되지만 패킷에는 송신 라우터 포드에서 net1 인터페이스의 MAC 주소가 있습니다.

송신 라우터 사용자 정의 리소스를 추가하면 Cluster Network Operator에서 다음 오브젝트를 생성합니다.

  • pod의 net1 보조 네트워크 인터페이스에 대한 네트워크 연결 정의입니다.
  • 출력 라우터에 대한 배포입니다.

송신 라우터 사용자 정의 리소스를 삭제하는 경우 Operator는 송신 라우터와 연결된 이전 목록에서 두 개의 오브젝트를 삭제합니다.

12.1.3. 배포 고려 사항

송신 라우터 Pod는 노드의 기본 네트워크 인터페이스에 추가 IP 주소와 MAC 주소를 추가합니다. 따라서 추가 주소를 허용하도록 하이퍼바이저 또는 클라우드 공급자를 구성해야 할 수 있습니다.

Red Hat 오픈스택 플랫폼(RHOSP)

RHOSP에서 OpenShift Container Platform을 배포하는 경우 OpenStack 환경에서 송신 라우터 포드의 IP 및 MAC 주소의 트래픽을 허용해야 합니다. 트래픽을 허용하지 않으면 통신이 실패합니다.

$ openstack port set --allowed-address \
  ip_address=<ip_address>,mac_address=<mac_address> <neutron_port_uuid>
Copy to Clipboard Toggle word wrap
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> 명령을 사용하거나 다음 예와 같이 파일을 생성합니다.

apiVersion: v1
kind: Service
metadata:
  name: app-egress
spec:
  ports:
  - name: tcp-8080
    protocol: TCP
    port: 8080
  - name: tcp-8443
    protocol: TCP
    port: 8443
  - name: udp-80
    protocol: UDP
    port: 80
  type: ClusterIP
  selector:
    app: egress-router-cni
Copy to Clipboard Toggle word wrap

13장. 리디렉션 모드에서 송신 라우터 Pod 배포

클러스터 관리자는 예약된 소스 IP 주소에서 지정된 대상 IP 주소로 트래픽을 리디렉션하도록 송신 라우터 포드를 배포할 수 있습니다.

송신 라우터 구현은 송신 라우터 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용합니다.

13.1. 송신 라우터 사용자 정의 리소스

송신 라우터 사용자 정의 리소스에서 송신 라우터 Pod에 대한 구성을 정의합니다. 다음 YAML은 리디렉션 모드에서 송신 라우터 구성을 위한 필드를 설명합니다.

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: <egress_router_name>
  namespace: <namespace>  
1

spec:
  addresses: [  
2

    {
      ip: "<egress_router>",  
3

      gateway: "<egress_gateway>"  
4

    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [  
5

      {
        destinationIP: "<egress_destination>",
        port: <egress_router_port>,
        targetPort: <target_port>,  
6

        protocol: <network_protocol>  
7

      },
      ...
    ],
    fallbackIP: "<egress_destination>" 
8

  }
Copy to Clipboard Toggle word wrap
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 주소로 전송됩니다. 이 필드를 지정하지 않으면 송신 라우터는 규칙에 정의되지 않은 네트워크 포트에 대한 연결을 거부합니다.

송신 라우터 사양의 예

apiVersion: network.operator.openshift.io/v1
kind: EgressRouter
metadata:
  name: egress-router-redirect
spec:
  networkInterface: {
    macvlan: {
      mode: "Bridge"
    }
  }
  addresses: [
    {
      ip: "192.168.12.99/24",
      gateway: "192.168.12.1"
    }
  ]
  mode: Redirect
  redirect: {
    redirectRules: [
      {
        destinationIP: "10.0.0.99",
        port: 80,
        protocol: UDP
      },
      {
        destinationIP: "203.0.113.26",
        port: 8080,
        targetPort: 80,
        protocol: TCP
      },
      {
        destinationIP: "203.0.113.27",
        port: 8443,
        targetPort: 443,
        protocol: TCP
      }
    ]
  }
Copy to Clipboard Toggle word wrap

13.2. 리디렉션 모드에서 송신 라우터 배포

송신 라우터 pod를 배포하여 자체 예약된 소스 IP 주소에서 하나 이상의 대상 IP 주소로 트래픽을 리디렉션할 수 있습니다.

송신 라우터 pod를 추가한 후 예약된 소스 IP 주소를 사용해야 하는 클라이언트 pod는 대상 IP에 직접 연결하는 대신 송신 라우터에 연결하도록 수정해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 송신 라우터 정의를 생성합니다.
  2. 다른 포드에서 송신 라우터 pod의 IP 주소를 찾을 수 있도록 하려면 다음 예제와 같이 송신 라우터를 사용하는 서비스를 만듭니다.

    apiVersion: v1
    kind: Service
    metadata:
      name: egress-1
    spec:
      ports:
      - name: web-app
        protocol: TCP
        port: 8080
      type: ClusterIP
      selector:
        app: egress-router-cni 
    1
    Copy to Clipboard Toggle word wrap
    1
    송신 라우터의 레이블을 지정합니다. 표시된 값은 Cluster Network Operator에서 추가하며 구성 불가능합니다.

    서비스를 생성한 후 포드가 서비스에 연결할 수 있습니다. 송신 라우터 pod는 트래픽을 대상 IP 주소의 해당 포트로 리디렉션합니다. 이 연결은 예약된 소스 IP 주소에서 시작됩니다.

검증

Cluster Network Operator가 송신 라우터를 시작했는지 확인하려면 다음 절차를 완료합니다.

  1. 송신 라우터에 대해 Operator가 생성한 네트워크 연결 정의를 확인합니다.

    $ oc get network-attachment-definition egress-router-cni-nad
    Copy to Clipboard Toggle word wrap

    네트워크 연결 정의의 이름은 구성할 수 없습니다.

    출력 예

    NAME                    AGE
    egress-router-cni-nad   18m
    Copy to Clipboard Toggle word wrap

  2. 송신 라우터 pod에 대한 배포를 확인합니다.

    $ oc get deployment egress-router-cni-deployment
    Copy to Clipboard Toggle word wrap

    배포 이름은 구성할 수 없습니다.

    출력 예

    NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
    egress-router-cni-deployment   1/1     1            1           18m
    Copy to Clipboard Toggle word wrap

  3. 송신 라우터 pod의 상태를 확인합니다.

    $ oc get pods -l app=egress-router-cni
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                            READY   STATUS    RESTARTS   AGE
    egress-router-cni-deployment-575465c75c-qkq6m   1/1     Running   0          18m
    Copy to Clipboard Toggle word wrap

  4. 송신 라우터 pod의 로그 및 라우팅 테이블을 확인합니다.
  1. 송신 라우터 pod에 대한 노드 이름을 가져옵니다.

    $ POD_NODENAME=$(oc get pod -l app=egress-router-cni -o jsonpath="{.items[0].spec.nodeName}")
    Copy to Clipboard Toggle word wrap
  2. 대상 노드에서 디버그 세션으로 들어갑니다. 이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

    $ oc debug node/$POD_NODENAME
    Copy to Clipboard Toggle word wrap
  3. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. 루트 디렉터리를 /host로 변경하면 호스트의 실행 경로에서 바이너리를 실행할 수 있습니다.

    # chroot /host
    Copy to Clipboard Toggle word wrap
  4. chroot 환경 콘솔에서 송신 라우터 로그를 표시합니다.

    # cat /tmp/egress-router-log
    Copy to Clipboard Toggle word wrap

    출력 예

    2021-04-26T12:27:20Z [debug] Called CNI ADD
    2021-04-26T12:27:20Z [debug] Gateway: 192.168.12.1
    2021-04-26T12:27:20Z [debug] IP Source Addresses: [192.168.12.99/24]
    2021-04-26T12:27:20Z [debug] IP Destinations: [80 UDP 10.0.0.99/30 8080 TCP 203.0.113.26/30 80 8443 TCP 203.0.113.27/30 443]
    2021-04-26T12:27:20Z [debug] Created macvlan interface
    2021-04-26T12:27:20Z [debug] Renamed macvlan to "net1"
    2021-04-26T12:27:20Z [debug] Adding route to gateway 192.168.12.1 on macvlan interface
    2021-04-26T12:27:20Z [debug] deleted default route {Ifindex: 3 Dst: <nil> Src: <nil> Gw: 10.128.10.1 Flags: [] Table: 254}
    2021-04-26T12:27:20Z [debug] Added new default route with gateway 192.168.12.1
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p UDP --dport 80 -j DNAT --to-destination 10.0.0.99
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8080 -j DNAT --to-destination 203.0.113.26:80
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat PREROUTING -i eth0 -p TCP --dport 8443 -j DNAT --to-destination 203.0.113.27:443
    2021-04-26T12:27:20Z [debug] Added iptables rule: iptables -t nat -o net1 -j SNAT --to-source 192.168.12.99
    Copy to Clipboard Toggle word wrap

    로깅 파일 위치 및 로깅 수준은 이 프로세스에 설명된 대로 EgressRouter 오브젝트를 생성하여 송신 라우터를 시작할 때 구성되지 않습니다.

  5. chroot 환경 콘솔에서 컨테이너 ID를 가져옵니다.

    # crictl ps --name egress-router-cni-pod | awk '{print $1}'
    Copy to Clipboard Toggle word wrap

    출력 예

    CONTAINER
    bac9fae69ddb6
    Copy to Clipboard Toggle word wrap

  6. 컨테이너의 프로세스 ID를 확인합니다. 이 예에서 컨테이너 ID는 bac9fae69ddb6입니다.

    # crictl inspect -o yaml bac9fae69ddb6 | grep 'pid:' | awk '{print $2}'
    Copy to Clipboard Toggle word wrap

    출력 예

    68857
    Copy to Clipboard Toggle word wrap

  7. 컨테이너의 네트워크 네임스페이스를 입력합니다.

    # nsenter -n -t 68857
    Copy to Clipboard Toggle word wrap
  8. 라우팅 테이블을 표시합니다.

    # ip route
    Copy to Clipboard Toggle word wrap

    다음 예제 출력에서 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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    작은 정보

    다음 YAML을 적용하여 주석을 추가할 수도 있습니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/multicast-enabled: "true"
    Copy to Clipboard Toggle word wrap

검증

프로젝트에 멀티 캐스트가 활성화되어 있는지 확인하려면 다음 절차를 완료합니다.

  1. 멀티 캐스트를 활성화한 프로젝트로 현재 프로젝트를 변경합니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc project <project>
    Copy to Clipboard Toggle word wrap
  2. 멀티 캐스트 수신자 역할을 할 pod를 만듭니다.

    $ cat <<EOF| oc create -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: mlistener
      labels:
        app: multicast-verify
    spec:
      containers:
        - name: mlistener
          image: registry.access.redhat.com/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat hostname && sleep inf"]
          ports:
            - containerPort: 30102
              name: mlistener
              protocol: UDP
    EOF
    Copy to Clipboard Toggle word wrap
  3. 멀티 캐스트 발신자 역할을 할 pod를 만듭니다.

    $ cat <<EOF| oc create -f -
    apiVersion: v1
    kind: Pod
    metadata:
      name: msender
      labels:
        app: multicast-verify
    spec:
      containers:
        - name: msender
          image: registry.access.redhat.com/ubi9
          command: ["/bin/sh", "-c"]
          args:
            ["dnf -y install socat && sleep inf"]
    EOF
    Copy to Clipboard Toggle word wrap
  4. 새 터미널 창이나 탭에서 멀티캐스트 리스너를 시작합니다.

    1. Pod의 IP 주소를 가져옵니다.

      $ POD_IP=$(oc get pods mlistener -o jsonpath='{.status.podIP}')
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 입력하여 멀티캐스트 리스너를 시작합니다.

      $ oc exec mlistener -i -t -- \
          socat UDP4-RECVFROM:30102,ip-add-membership=224.1.0.1:$POD_IP,fork EXEC:hostname
      Copy to Clipboard Toggle word wrap
  5. 멀티 캐스트 송신기를 시작합니다.

    1. Pod 네트워크 IP 주소 범위를 가져옵니다.

      $ CIDR=$(oc get Network.config.openshift.io cluster \
          -o jsonpath='{.status.clusterNetwork[0].cidr}')
      Copy to Clipboard Toggle word wrap
    2. 멀티 캐스트 메시지를 보내려면 다음 명령을 입력합니다.

      $ 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 Toggle word wrap

      멀티 캐스트가 작동하는 경우 이전 명령은 다음 출력을 반환합니다.

      mlistener
      Copy to Clipboard Toggle word wrap

15장. 프로젝트에 대한 멀티 캐스트 비활성화

15.1. Pod 간 멀티 캐스트 비활성화

프로젝트의 Pod 간 멀티 캐스트를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할을 가진 사용자로 클러스터에 로그인해야 합니다.

프로세스

  • 다음 명령을 실행하여 멀티 캐스트를 비활성화합니다.

    $ oc annotate namespace <namespace> \ 
    1
    
        k8s.ovn.org/multicast-enabled-
    Copy to Clipboard Toggle word wrap
    1
    멀티 캐스트를 비활성화하려는 프로젝트의 namespace입니다.
    작은 정보

    다음 YAML을 적용하여 주석을 삭제할 수도 있습니다.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: <namespace>
      annotations:
        k8s.ovn.org/multicast-enabled: null
    Copy to Clipboard Toggle word wrap

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)에서 네트워크 흐름 수집기를 구성하는 필드는 다음 표에 표시되어 있습니다.

Expand
표 16.1. 네트워크 흐름 구성
필드유형설명

metadata.name

string

CNO 개체 이름입니다. 이 이름은 항상 cluster입니다.

spec.exportNetworkFlows

object

netFlow,sFlow 또는 ipfix 중 하나 이상입니다.

spec.exportNetworkFlows.netFlow.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

spec.exportNetworkFlows.sFlow.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

spec.exportNetworkFlows.ipfix.collectors

array

최대 10개의 컬렉터에 대한 IP 주소 및 네트워크 포트 쌍 목록입니다.

CNO에 다음 매니페스트를 적용한 후 Operator는 클러스터의 각 노드에서 OVS(Open vSwitch)를 구성하여 네트워크 흐름 레코드를 192.168.1.99:2056에서 수신 대기 중인 NetFlow 수집기에 전송합니다.

네트워크 흐름 추적을 위한 구성 예

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  exportNetworkFlows:
    netFlow:
      collectors:
        - 192.168.1.99:2056
Copy to Clipboard Toggle word wrap

16.2. 네트워크 흐름 수집기 추가

클러스터 관리자는 클러스터 네트워크 운영자(CNO)가 네트워크 흐름 수집기에 Pod 네트워크에 대한 네트워크 흐름 메타데이터를 전송하도록 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 흐름 수집기가 있고 수신 대기하는 IP 주소와 포트를 알고 있습니다.

프로세스

  1. 네트워크 흐름 수집기 유형과 컬렉터의 IP 주소 및 포트 정보를 지정하는 패치 파일을 생성합니다.

    spec:
      exportNetworkFlows:
        netFlow:
          collectors:
            - 192.168.1.99:2056
    Copy to Clipboard Toggle word wrap
  2. 네트워크 흐름 수집기를 사용하여 CNO를 구성합니다.

    $ oc patch network.operator cluster --type merge -p "$(cat <file_name>.yaml)"
    Copy to Clipboard Toggle word wrap

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

검증

일반적으로 검증은 필요하지 않습니다. 다음 명령을 실행하여 각 노드의 OVS(Open vSwitch)가 하나 이상의 컬렉터에 네트워크 흐름 레코드를 전송하도록 구성되어 있는지 확인할 수 있습니다.

  1. Operator 구성을 보고 exportNetworkFlows 필드가 구성되었는지 확인합니다.

    $ oc get network.operator cluster -o jsonpath="{.spec.exportNetworkFlows}"
    Copy to Clipboard Toggle word wrap

    출력 예

    {"netFlow":{"collectors":["192.168.1.99:2056"]}}
    Copy to Clipboard Toggle word wrap

  2. 각 노드에서 OVS의 네트워크 흐름 구성을 확인합니다.

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node -o jsonpath='{range@.items[*]}{.metadata.name}{"\n"}{end}');
      do ;
        echo;
        echo $pod;
        oc -n openshift-ovn-kubernetes exec -c ovnkube-controller $pod \
          -- bash -c 'for type in ipfix sflow netflow ; do ovs-vsctl find $type ; done';
    done
    Copy to Clipboard Toggle word wrap

    출력 예

    ovnkube-node-xrn4p
    _uuid               : a4d2aaca-5023-4f3d-9400-7275f92611f9
    active_timeout      : 60
    add_id_to_interface : false
    engine_id           : []
    engine_type         : []
    external_ids        : {}
    targets             : ["192.168.1.99:2056"]
    
    ovnkube-node-z4vq9
    _uuid               : 61d02fdb-9228-4993-8ff5-b27f01a29bd6
    active_timeout      : 60
    add_id_to_interface : false
    engine_id           : []
    engine_type         : []
    external_ids        : {}
    targets             : ["192.168.1.99:2056"]-
    
    ...
    Copy to Clipboard Toggle word wrap

16.3. 네트워크 흐름 수집기의 모든 대상 삭제

클러스터 관리자는 클러스터 네트워크 운영자(CNO)가 네트워크 흐름 메타데이터를 네트워크 흐름 수집기로 전송하는 것을 중지하도록 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.

프로세스

  1. 모든 네트워크 흐름 수집기를 제거합니다.

    $ oc patch network.operator cluster --type='json' \
        -p='[{"op":"remove", "path":"/spec/exportNetworkFlows"}]'
    Copy to Clipboard Toggle word wrap

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

17장. 하이브리드 네트워킹 구성

클러스터 관리자는 Red Hat OpenShift Networking OVN-Kubernetes 네트워크 플러그인을 구성하여 Linux 및 Windows 노드가 각각 Linux 및 Windows 워크로드를 호스팅하도록 할 수 있습니다.

17.1. OVN-Kubernetes로 하이브리드 네트워킹 구성

OVN-Kubernetes 네트워크 플러그인을 사용하면 클러스터가 하이브리드 네트워킹을 사용하도록 구성할 수 있습니다. 이를 통해 다양한 노드 네트워킹 구성을 지원하는 하이브리드 클러스터를 사용할 수 있습니다.

참고

이 구성은 동일한 클러스터에서 Linux와 Windows 노드를 모두 실행하는 데 필요합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터가 OVN-Kubernetes 네트워크 플러그인을 사용하는지 확인하세요.

프로세스

  1. OVN-Kubernetes 하이브리드 네트워크 오버레이를 구성하려면 다음 명령을 입력하세요.

    $ oc patch networks.operator.openshift.io cluster --type=merge \
      -p '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "hybridOverlayConfig":{
                "hybridClusterNetwork":[
                  {
                    "cidr": "<cidr>",
                    "hostPrefix": <prefix>
                  }
                ],
                "hybridOverlayVXLANPort": <overlay_port>
              }
            }
          }
        }
      }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    cidr
    추가 오버레이 네트워크의 노드에 사용되는 CIDR 구성을 지정합니다. 이 CIDR은 클러스터 네트워크 CIDR과 겹치면 안 됩니다.
    hostPrefix
    각 개별 노드에 할당할 서브넷 접두사 길이를 지정합니다. 예를 들어 hostPrefix23으로 설정하면 지정된 cidr 이외 /23 서브넷이 각 노드에 할당되어 510(2^(32 - 23) - 2) Pod IP 주소가 허용됩니다. 외부 네트워크에서 노드에 액세스해야 하는 경우 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.
    hybridOverlayVXLANPort

    추가 오버레이 네트워크에 대한 사용자 정의 VXLAN 포트를 지정합니다. 이는 vSphere에 설치된 클러스터에서 Windows 노드를 실행해야 하며 다른 클라우드 공급자에 대해 구성해서는 안 됩니다. 사용자 정의 포트는 기본 4789 포트를 제외한 모든 오픈 포트일 수 있습니다. 이 요구 사항에 대한 자세한 내용은 Microsoft 설명서에서 호스트 간 Pod 간 연결이 끊어졌습니다를 참조하세요.

    참고

    Windows Server LTSC(Long-Term Servicing Channel): Windows Server 2019는 사용자 지정 hybridOverlayVXLANPort 값이 있는 클러스터에서 지원되지 않습니다. 이 Windows 서버 버전은 사용자 지정 VXLAN 포트를 선택하는 것을 지원하지 않기 때문입니다.

    출력 예

    network.operator.openshift.io/cluster patched
    Copy to Clipboard Toggle word wrap

  2. 구성이 활성 상태인지 확인하려면 다음 명령을 입력합니다. 업데이트가 적용되려면 몇 분 정도 걸릴 수 있습니다.

    $ oc get network.operator.openshift.io -o jsonpath="{.items[0].spec.defaultNetwork.ovnKubernetesConfig}"
    Copy to Clipboard Toggle word wrap

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.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat