IBM Cloud Docs
클래식: 네트워크 로드 밸런서(NLB) 정보

클래식: 네트워크 로드 밸런서(NLB) 정보

네트워크 로드 밸런서는 클래식 클러스터에서만 작성할 수 있습니다. VPC 클러스터에서 로드 밸런싱하려면 VPC용 로드 밸런서를 사용하여 앱 노출을 참조하십시오.

표준 클러스터를 작성하면 Red Hat® OpenShift® on IBM Cloud®에서 포터블 공인 서브넷과 포터블 사설 서브넷을 자동으로 프로비저닝합니다.

  • 포터블 공용 서브넷은 5개의 사용 가능한 IP 주소를 제공합니다. 포터블 공인 IP 주소 1개는 기본 공용 Ingress ALB에 사용됩니다. 나머지 4개의 포터블 공인 IP 주소는 공용 네트워크 로드 밸런서 서비스 또는 NLB 작성을 통해 단일 앱을 인터넷에 노출하는 데 사용할 수 있습니다.
  • 휴대용 개인 서브넷은 5개의 사용 가능한 IP 주소를 제공합니다. 1개의 휴대용 개인 IP 주소는 기본 개인 Ingress ALB 에 의해 사용됩니다. 나머지 4개의 포터블 사설 IP 주소는 사설 로드 밸런서 서비스 또는 NLB 작성을 통해 단일 앱을 사설 네트워크에 노출하는 데 사용할 수 있습니다.

휴대용 공용 및 휴대용 사설 IP 주소 모두를 통해 앱을 액세스할 수 있도록 하려면 공용 NLB와 사설 NLB를 모두 작성해야 합니다. 포터블 공인 및 사설 IP 주소는 정적인 유동 IP이므로 작업자 노드가 제거될 때 변경되지 않습니다. NLB IP 주소가 있는 작업자 노드가 제거되면, IP를 지속적으로 모니터링하는 Keepalive 데몬이 자동으로 IP를 다른 작업자 노드로 이동시킵니다. NLB에 포트를 지정할 수 있습니다. NLB 서비스는 앱의 수신 요청에 대한 외부 시작점 역할을 합니다. 인터넷에서 NLB에 액세스하려면 NLB의 공인 IP 주소와 지정된 포트를 <IP_address>:<port> 형식으로 사용할 수 있습니다. 하위 도메인 없이 NLB IP 주소를 등록하여 NLB에 대한 DNS 항목을 작성할 수도 있습니다.

NLB 서비스를 사용하여 앱을 노출하면 서비스의 NodePorts를 통해 앱이 자동으로 사용 가능해집니다. NodePort는 클러스터 내 모든 작업자 노드의 모든 공용 및 사설 IP 주소에서 액세스 가능합니다. NLB를 사용하는 동안 NodePort에 대한 트래픽을 차단하려면 네트워크 로드 밸런서(NLB) 또는 NodePort 서비스에 대한 인바운드 트래픽 제어를 참조하십시오.

Kubernetes SCTP 프로토콜 은 일반적으로 Kubernetes 커뮤니티 릴리스에서 사용 가능하지만, 이 프로토콜을 사용하는 로드 밸런서 작성은 IBM Cloud Kubernetes Service 클러스터에서 지원되지 않습니다.

버전 1.0 NLB와 2.0 NLB의 기본 및 DSR 로드 밸런싱 비교

NLB를 작성할 때는 기본 로드 밸런싱을 수행하는 버전 1.0 NLB, 또는 DSR(Direct Server Return) 로드 밸런싱을 수행하는 버전 2.0 NLB를 선택할 수 있습니다.

1.0 와 2.0 NLB는 어떤 점이 비슷할까요?
버전 1.0과 2.0 NLB는 둘 다 Linux 커널 영역에 존재하는 계층 4 로드 밸런서입니다. 두 버전 모두 클러스터 내에서 실행되며, 작업자 노드 리소스를 사용합니다. 따라서 NLB의 사용 가능 용량은 항상 사용자 고유의 클러스터에 제공됩니다. 또한 NLB의 두 버전 모두에서 연결이 종료되지 않습니다. 대신 연결을 앱 팟(Pod)으로 전달합니다.
1.0 와 2.0 NLB는 어떻게 다른가요?
클라이언트가 요청을 앱에 전송하면 NLB는 앱 팟(Pod)이 있는 작업자 노드 IP 주소로 요청 패킷을 라우팅합니다. 버전 1.0 NLB는 NAT(Network Address Translation)을 사용하여 요청 패킷의 소스 IP 주소를 로드 밸런서 팟(Pod)이 있는 작업자 노드의 IP에 재작성합니다. 작업자 노드가 앱 응답 패킷을 리턴하면 NLB가 있는 작업자 노드 IP가 사용됩니다. 그러면 NLB는 응답 패킷을 클라이언트에 전송해야 합니다. IP 주소 재작성을 방지하기 위해 소스 IP 보존을 사용으로 설정할 수 있습니다. 그러나 소스 IP 보존을 사용하려면 요청을 다른 작업자로 전달할 필요가 없도록 로드 밸런서 팟(Pod)과 앱 팟(Pod)을 동일한 작업자에서 실행해야 합니다. 노드 친화성 및 결함 허용을 앱 팟(Pod)에 추가해야 합니다. 버전 1.0 NLB를 사용한 기본 로드 밸런싱에 대한 자세한 정보는 NLB 1.0의 컴포넌트 및 아키텍처를 참조하십시오.

버전 1.0 NLB와 반대로, 버전 2.0 NLB는 요청을 다른 작업자의 앱 팟(Pod)에 전달할 때 NAT를 사용하지 않습니다. NLB 2.0은 클라이언트 요청을 라우팅할 때 IPIP(IP over IP)를 사용하여 원래 요청 패킷을 다른 패킷에 캡슐화합니다. 이 캡슐화 IPIP 패킷은 로드 밸런서 팟(Pod)이 있는 작업자 노드의 소스 IP를 제공하므로, 원래 요청 패킷이 클라이언트 IP를 소스 IP 주소로 보존할 수 있습니다. 그러면 작업자 노드는 DSR(Direct Server Return)을 사용하여 앱 응답 패킷을 클라이언트 IP로 전송합니다. 응답 패킷은 NLB를 건너뛰고 클라이언트로 직접 전송되므로 NLB에서 처리해야 하는 트래픽의 양이 줄어듭니다. 버전 2.0 NLB를 사용한 DSR 로드 밸런싱에 대한 자세한 정보는 NLB 2.0의 컴포넌트 및 아키텍처를 참조하십시오.

NLB 1.0의 컴포넌트 및 아키텍처

TCP/UDP 네트워크 로드 밸런서(NLB) 1.0은 Linux 커널 기능인 Iptables를 사용하여 앱 팟(Pod) 전체에서 요청을 로드 밸런싱합니다.

단일 구역 클러스터에서의 트래픽 플로우

다음 다이어그램은 NLB 1.0이 인터넷에서 단일 구역 클러스터의 앱으로 통신을 유도하는 방식을 보여줍니다.

NLB( 1.0 )를 사용하여 단일 영역 클러스터에 앱을 노출합니다.
Expose an app in a single-zone cluster by using an NLB 1.0

  1. 앱에 대한 요청은 작업자 노드에서 지정된 포트와 NLB의 공인 IP 주소를 사용합니다. NLB용 DNS 하위 도메인을 작성하는 경우, 사용자는 대신 NLB의 하위 도메인을 통해 앱에 액세스할 수 있습니다. DNS 시스템 서비스는 NLB의 휴대용 공인 IP 주소로 하위 도메인을 해석합니다.

  2. NLB는 요청을 수신하여 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 전달합니다. 요청 패키지의 소스 IP 주소는 NLB 팟(Pod)이 실행되는 작업자 노드의 공인 IP 주소로 변경됩니다. 여러 앱 인스턴스가 클러스터에 배치되는 경우 NLB는 앱 팟(Pod) 간의 요청을 라우팅합니다.

  3. 앱이 응답 패킷을 리턴하면 클라이언트 요청이 전달된 NLB가 있는 작업자 노드의 IP 주소를 사용합니다. 그러면 NLB는 응답 패킷을 클라이언트에 전송합니다.

다중 구역 클러스터에서의 트래픽 플로우

다음 다이어그램은 네트워크 로드 밸런서(NLB) 1.0이 인터넷에서 다중 구역 클러스터의 앱으로 통신을 유도하는 방식을 보여줍니다.

Use an NLB 1.0 to load balance apps in a multizone cluster
Use an NLB 1.0 to load balance apps in a multizone cluster

  1. 앱에 대한 요청은 NLB의 DNS 하위 도메인을 사용합니다. 또한 작업자 노드의 해당 공인 IP 주소 및 포트를 사용하여 각 구역의 NLB에 액세스할 수 있습니다. 기본적으로 NLB 1.0은 각각 하나의 구역에만 설정됩니다. 고가용성을 얻으려면 앱 인스턴스가 있는 모든 구역에 NLB 1.0을 배치해야 합니다.

  2. DNS 시스템 서비스는 하위 도메인을 NLB 중 하나의 포터블 공인 IP 주소 및 작업자 노드에 할당된 포트로 해석합니다. 요청은 라운드 로빈 주기로 다양한 구역에서 NLB에 의해 처리됩니다.

  3. NLB는 요청을 수신하여 사설 네트워크를 통해 앱 팟(Pod)의 사설 IP 주소로 전달합니다. 요청 패키지의 소스 IP 주소는 NLB 팟(Pod)이 실행되는 작업자 노드의 공인 IP 주소로 변경됩니다. 각 NLB는 자체 구역의 앱 인스턴스와 기타 구역의 앱 인스턴스로 요청을 라우팅합니다. 또한, 여러 앱 인스턴스가 하나의 구역에 배치되는 경우 NLB는 구역의 앱 팟(Pod) 간의 요청을 라우팅합니다.

  4. 앱이 응답 패킷을 리턴하면 클라이언트 요청이 전달된 NLB가 있는 작업자 노드의 IP 주소를 사용합니다. 그러면 NLB는 응답 패킷을 클라이언트에 전송합니다.

NLB 2.0의 컴포넌트 및 아키텍처

NLB 2.0은 Linux 커널의 IP 가상 서버(IPVS)를 사용하는 계층 4 로드 밸런서입니다. NLB 2.0은 TCP 및 UDP를 지원하고, 다중 작업자 노드 앞에 실행되며, IPIP(IP over IP) 터널링을 사용하여 하나의 NLB IP 주소에 도착하는 트래픽을 이러한 작업자 노드에 분산시킵니다.

단일 구역 클러스터에서의 트래픽 플로우

다음 다이어그램은 NLB 2.0이 인터넷에서 단일 구역 클러스터의 앱으로 통신을 유도하는 방식을 보여줍니다.

버전 2.0{: caption="사용하여 Red Hat OpenShift on IBM Cloud 앱 노출버전 2.0 " caption-side="bottom"} 사용하여 Red Hat OpenShift on IBM Cloud 앱 노출

  1. 앱에 대한 클라이언트 요청은 작업자 노드에 지정된 포트와 NLB의 공인 IP 주소를 사용합니다. 이 예제에서 NLB의 가상 IP 주소는 169.61.23.130이고 사설 IP 주소가 10.73.13.25인 작업자 노드에서 실행됩니다. NLB용 DNS 하위 도메인을 작성하는 경우, 사용자는 대신 NLB의 하위 도메인을 통해 앱에 액세스할 수 있습니다. DNS 시스템 서비스는 NLB의 휴대용 공인 IP 주소로 하위 도메인을 해석합니다.

  2. NLB가 클라이언트 요청 패킷(그림에서 "CR"로 레이블 지정됨)을 IPIP 패킷("IPIP"으로 레이블 지정됨) 내에 캡슐화합니다. 클라이언트 요청 패킷은 클라이언트 IP를 소스 IP 주소로 보존합니다. IPIP 캡슐화 패킷은 작업자 노드 IP 10.73.14.25를 소스 IP 주소로 사용합니다.

  3. NLB는 앱 팟(Pod)이 있고 사설 IP 주소가 10.73.13.26인 작업자에게 IPIP 패킷을 라우팅합니다. 여러 앱 인스턴스가 클러스터에 배치된 경우, NLB는 앱 팟(Pod)이 배치된 작업자 간에 요청을 라우팅합니다.

  4. 작업자 10.73.14.26에서 IPIP 캡슐화 패킷을 언팩한 다음 클라이언트 요청 패킷을 언팩합니다. 클라이언트 요청 패킷이 해당 작업자 노드에 있는 앱 팟(Pod)에 전달됩니다.

  5. 작업자 10.73.14.26에서 원래 요청 패킷의 소스 IP 주소(클라이언트 IP)를 사용하여 앱 팟(Pod)의 응답 패킷을 클라이언트로 직접 리턴합니다.

다중 구역 클러스터에서의 트래픽 플로우

다음 다이어그램은 각 구역에 있는 버전 2.0 NLB가 인터넷에서 다중 구역 클러스터의 앱으로 통신을 유도하는 방식을 보여줍니다.

Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0
Expose an app in Red Hat OpenShift on IBM Cloud by using an NLB 2.0

  1. 앱에 대한 요청은 NLB의 DNS 하위 도메인을 사용합니다. 또한 작업자 노드의 해당 공인 IP 주소 및 포트를 사용하여 각 구역의 NLB에 액세스할 수 있습니다. 기본적으로 NLB 2.0은 각각 하나의 구역에만 설정됩니다. 고가용성을 얻으려면 앱 인스턴스가 있는 모든 구역에 NLB 2.0을 배치해야 합니다.

  2. DNS 시스템 서비스는 하위 도메인을 NLB 중 하나의 포터블 공인 IP 주소 및 작업자 노드에 할당된 포트로 해석합니다. 이 예제에서 NLB의 가상 IP 주소는 169.61.23.130이고 사설 IP 주소가 10.73.13.25인 작업자 노드에서 실행됩니다. 요청은 라운드 로빈 주기로 다양한 구역에서 NLB에 의해 처리됩니다.

  3. NLB가 클라이언트 요청 패킷(그림에서 "CR"로 레이블 지정됨)을 IPIP 패킷("IPIP"으로 레이블 지정됨) 내에 캡슐화합니다. 클라이언트 요청 패킷은 클라이언트 IP를 소스 IP 주소로 보존합니다. IPIP 캡슐화 패킷은 작업자 10.73.14.25 IP를 소스 IP 주소로 사용합니다.

  4. NLB는 앱 팟(Pod)이 있고 사설 IP 주소가 10.73.13.26인 작업자에게 IPIP 패킷을 라우팅합니다. 각 NLB는 자체 구역의 앱 인스턴스와 기타 구역의 앱 인스턴스로 요청을 라우팅합니다. 또한, 여러 앱 인스턴스가 하나의 구역에 배치되는 경우 NLB는 구역의 앱 팟(Pod) 간의 요청을 라우팅합니다.

  5. 작업자 10.73.14.26에서 IPIP 캡슐화 패킷을 언팩한 다음 클라이언트 요청 패킷을 언팩합니다. 클라이언트 요청 패킷이 해당 작업자 노드에 있는 앱 팟(Pod)에 전달됩니다.

  6. 작업자 10.73.14.26에서 원래 요청 패킷의 소스 IP 주소(클라이언트 IP)를 사용하여 앱 팟(Pod)의 응답 패킷을 클라이언트로 직접 리턴합니다.