로드 밸런서 유형

다음 표는 각 로드 밸런싱 옵션의 기본 특성에 대해 설명합니다.

Application Load Balancer for VPC

클러스터에 있는 앱으로의 수신 요청에 대한 외부 입력점 역할을 수행하는 7계층 다중 구역 Application Load Balancer for VPC(VPC ALB)를 설정하십시오. VPC ALB 설정을 계획할 때 다음 사항을 염두에 두세요.

Application Load Balancer for VPC를 Red Hat OpenShift on IBM Cloud Ingress 애플리케이션 로드 밸런서와 혼동하지 마십시오. Application Load Balancers for VPC(VPC ALB)는 VPC에 있는 클러스터의 외부에서 실행되며 작성된 Kubernetes LoadBalancer 서비스에 의해 구성됩니다. Ingress 애플리케이션 로드 밸런서(ALB)는 클러스터에 있는 작업자 노드에서 실행되는 Ingress 제어기입니다.

• VPC ALB 이름에는 kube-<cluster_ID>-<kubernetes_lb_service_UID> 형식이 있습니다. 클러스터 ID를 보려면 ibmcloud oc cluster get --cluster <cluster_name>을(를) 실행하십시오. Kubernetes LoadBalancer 서비스 UID를 보려면 oc get svc myloadbalancer -o yaml을 실행하고 출력에서 metadata.uid 필드를 찾으십시오. 하이픈(-)은 VPC ALB 이름에서 Kubernetes LoadBalancer 서비스 UID에서 제거됩니다.

• 기본적으로, 클러스터에 있는 앱에 대해 Kubernetes LoadBalancer 서비스를 작성하면 Application Load Balancer for VPC가 클러스터 외부의 VPC에 작성됩니다. VPC ALB는 작업자 노드에서 자동으로 열린 사설 NodePort를 통해 앱에 대한 요청을 라우팅합니다.

• 공용 Kubernetes LoadBalancer 서비스를 작성하는 경우 VPC ALB가 1234abcd-<region>.lb.appdomain.cloud 형식으로 Kubernetes LoadBalancer 서비스에 지정한 호스트 이름을 통해 인터넷에서 앱에 액세스할 수 있습니다. 작업자 노드가 사설 VPC 서브넷에만 연결되어 있는 경우에도 VPC ALB는 앱을 노출하는 서비스에 대한 공용 요청을 수신하고 라우팅할 수 있습니다. VPC ALB에 대한 공용 요청을 허용하기 위해 VPC 서브넷에 퍼블릭 게이트웨이가 필요하지는 않다는 점을 참고하십시오. 그러나 앱이 공용 URL에 액세스해야 하는 경우에는 작업자 노드가 연결된 VPC 서브넷에 퍼블릭 게이트웨이를 연결해야 합니다.

• 사설 Kubernetes LoadBalancer 서비스를 작성하는 경우, 동일한 지역 및 VPC 내의 사설 서브넷에 연결된 시스템에서만 앱에 액세스할 수 있습니다. 사설 VPC 네트워크에 연결된 경우에는 VPC ALB가 1234abcd-<region>.lb.appdomain.cloud 형식으로 LoadBalancer 서비스에 지정한 호스트 이름을 통해 앱에 액세스할 수 있습니다.

• VPC ALB의 이름을 변경하여 다른 클러스터에서 기존 VPC ALB를 사용할 수 있습니다.

다음 다이어그램은 사용자가 VPC ALB를 통해 인터넷에서 앱에 액세스하는 방법을 보여줍니다.

1. 앱에 대한 요청은 VPC ALB가 Kubernetes LoadBalancer 서비스에 지정한 호스트 이름(예: 1234abcd-<region>.lb.appdomain.cloud)을 사용합니다.
2. 요청은 VPC ALB에 의해 자동으로 작업자 노드의 노드 포트 중 하나로 전달된 후 앱 팟(Pod)의 사설 IP 주소로 전달됩니다.
3. 앱 인스턴스가 클러스터의 여러 작업자 노드에 배치되는 경우 로드 밸런서는 다양한 작업자 노드에 있는 앱 팟(Pod) 간의 요청을 라우팅합니다. 또한 다중 구역 클러스터가 있는 경우 VPC ALB는 요청을 클러스터의 모든 서브넷과 구역에 있는 작업자 노드로 라우팅합니다.

VPC용 네트워크 로드 밸랜서

VPC 클러스터에서 각 영역에 layer-4 Network Load Balancer for VPC (VPC NLB)를 클러스터의 각 영역에 설정하여 앱으로 들어오는 요청의 외부 진입점 역할을 하도록 합니다.

VPC NLB는 직접 서버 리턴(DSR)을 활용하여 높은 처리량과 향상된 성능을 제공하는 것과 같은 몇 가지 장점을 제공합니다. DSR을 사용하면 작업자 노드는 앱 응답 패킷을 클라이언트 IP 주소로 직접 전송하고 VPC NLB를 건너뛰어 VPC NLB가 처리해야 하는 트래픽의 양을 줄일 수 있습니다. 또한 externalTrafficPolicy: Local 사양을 포함시켜 모든 클라이언트 요청에 소스 IP 주소 보존을 포함하도록 VPC NLB를 구성할 수 있습니다.

• 표준 VPC NLB 이름은 kube-<cluster_ID>-<kubernetes_lb_service_UID> 형식입니다. 클러스터 ID를 보려면 ibmcloud oc cluster get --cluster <cluster_name>을(를) 실행하십시오. Kubernetes LoadBalancer 서비스 UID를 보려면 oc get svc myloadbalancer -o yaml을 실행하고 출력에서 metadata.uid 필드를 찾으십시오. VPC NLB 이름의 Kubernetes LoadBalancer 서비스 UID에서 하이픈(-)이 제거됩니다.

• 클러스터에서 앱에 대한 Kubernetes LoadBalancer 서비스를 작성하고 service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb" 어노테이션을 포함하는 경우, VPC NLB가 클러스터 외부의 VPC에서 작성됩니다. VPC NLB는 작업자 노드에서 자동으로 열린 사설 NodePort를 통해 앱에 대한 요청을 라우팅합니다.

• 공용 Kubernetes LoadBalancer 서비스를 작성하는 경우, VPC NLB가 Kubernetes LoadBalancer 서비스에 지정하는 외부 공용 IP 주소를 통해 인터넷에서 앱에 액세스할 수 있습니다. 작업자 노드가 사설 VPC 서브넷에만 연결되어 있는 경우에도 VPC NLB는 앱을 노출하는 서비스에 대한 공용 요청을 수신하고 라우팅할 수 있습니다. VPC NLB에 대한 공용 요청을 허용하기 위해 VPC 서브넷에 퍼블릭 게이트웨이가 필요하지는 않다는 점을 참고하십시오. 그러나 앱이 공용 URL에 액세스해야 하는 경우에는 작업자 노드가 연결된 VPC 서브넷에 퍼블릭 게이트웨이를 연결해야 합니다.

• 사설 Kubernetes LoadBalancer 서비스를 작성하는 경우, 동일한 지역 및 VPC 내의 사설 서브넷에 연결된 시스템에서만 앱에 액세스할 수 있습니다. 사설 VPC 네트워크에 연결되어 있는 경우에는 VPC NLB에서 Kubernetes LoadBalancer 서비스에 지정하는 외부 사설 IP 주소를 통해 사용자 앱에 액세스할 수 있습니다.

다음 다이어그램은 사용자가 VPC NLB를 통해 인터넷에서 앱에 액세스하는 방법을 보여줍니다.

1. 앱에 대한 요청은 VPC NLB가 Kubernetes LoadBalancer 서비스에 지정한 외부 IP 주소를 사용합니다.
2. 요청은 VPC NLB에 의해 자동으로 작업자 노드의 노드 포트 중 하나로 전달된 후 앱 팟(Pod)의 사설 IP 주소로 전달됩니다.
3. 앱 인스턴스가 클러스터의 여러 작업자 노드에 배포된 경우, VPC NLB는 클러스터의 모든 영역에 걸쳐 다양한 작업자 노드의 앱 포드 간에 요청을 라우팅합니다.

제한사항

다음 기본 설정 및 제한사항을 검토하십시오.

• VPC ALB에 대한 알려진 제한사항 및 VPC NLB에 대한 알려진 제한사항을 검토하십시오.
• 사설 VPC ALB는 RFC 1918 트래픽만 허용하며, 그 외 트래픽은 허용하지 않습니다.
• 사설 VPC NLB는 클러스터와 동일한 VPC 및 위치에 있어야 하는 전용 VPC 서브넷에 작성되어야 하지만, 이 서브넷은 클러스터 또는 작업자 노드에 연결될 수 없습니다.
• Red Hat OpenShift: Kubernetes SCTP 프로토콜는 일반적으로 Kubernetes 커뮤니티 릴리스에서 사용할 수 있지만, 이 프로토콜을 사용하는 로드밸런서를 생성하는 것은 IBM Cloud Kubernetes Service 클러스터에서 지원되지 않습니다.
• 작성하는 각 Kubernetes LoadBalancer 서비스마다 하나의 VPC 로드 밸런서가 작성되며 요청을 해당 Kubernetes LoadBalancer 서비스로만 라우팅합니다. VPC에 있는 모든 VPC 클러스터에서 최대 50개의 VPC 로드 밸런서를 작성할 수 있습니다. 자세한 정보는 VPC 할당량 문서를 참조하십시오.
• VPC 로드 밸런서는 제한된 수의 작업자 노드로 요청을 라우팅할 수 있습니다. 요청을 라우팅할 수 있는 최대 노드 수는 externalTrafficPolicy 어노테이션을 설정하는 방법에 따라 달라집니다.
  • 로드 밸런서 구성에서 externalTrafficPolicy: Cluster 을 설정한 경우:
    • VPC 로드 밸런서는 각 영역에서 발견된 처음 8개의 작업자 노드로 라우팅합니다. 3개의 영역에 워커 노드가 있는 클러스터의 경우, 이렇게 하면 로드 밸런서가 총 24개의 워커 노드로 라우팅하게 됩니다. 단일 영역 클러스터의 경우 로드 밸런서는 총 8개의 워커 노드로 라우팅합니다. service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota 을 사용하여 로드 밸런서가 라우팅하는 영역당 작업자 노드 수를 변경할 수 있지만 모든 영역의 총 수는 50개를 초과할 수 없습니다. 클러스터의 워커 노드가 모든 영역에 걸쳐 50개 미만인 경우, 0을 지정하여 영역의 모든 워커 노드로 라우팅합니다. kube-proxy 는 워커 노드에서 들어오는 트래픽을 애플리케이션 파드가 상주하는 노드의 애플리케이션 파드로 라우팅하도록 IP 테이블을 구성합니다.
  • 로드 밸런서 구성에서 externalTrafficPolicy: Local 을 설정하면 클러스터에 작업자 노드가 50개 이하인 경우에만 VPC 로드 밸런서가 만들어집니다. 이 제한은 VPC 로드 밸런서 풀당 50명의 풀 멤버로 제한되는 VPC 할당량 제한에 의해 설정됩니다. 이 제한을 피하려면 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector 어노테이션을 사용하여 로드 밸런서 풀에 있는 워커 노드를 제한하세요. 예를 들어 이 어노테이션을 사용하여 들어오는 트래픽을 특정 워커 풀로 강제 전송할 수 있습니다. 이 어노테이션을 사용하여 특정 워커 풀로 트래픽을 강제 전송하는 경우 애플리케이션 파드도 동일한 워커 풀에서 실행되는지 확인해야 합니다.
• Kubernetes LoadBalancer 서비스에 대한 구성 YAML 파일을 정의하는 경우, 다음 어노테이션 및 설정은 지원되지 않습니다.
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vlan: "<vlan_id>"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "ipvs"
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-ipvs-scheduler: "<algorithm>"
  • spec.loadBalancerIP
  • spec.loadBalancerSourceRanges
  • VPC NLB에만 해당: service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
  • VPC ALB에만 해당: externalTrafficPolicy: Local 설정이 지원되지만 설정에서 요청의 소스 IP를 유지하지 않습니다.
• VPC 클러스터를 삭제하면 해당 클러스터의 Kubernetes LoadBalancer 서비스에 대해 kube-<cluster_ID>-<kubernetes_lb_service_UID> 형식으로 이름이 지정되고 Red Hat OpenShift on IBM Cloud 에 의해 자동으로 생성되는 비영구 VPC 부하 분산 장치도 자동으로 삭제됩니다. 그러나 고유한 이름을 가진 퍼시스턴트 로드 밸런서 와 VPC에서 수동으로 생성한 VPC 로드 밸런서는 삭제되지 않습니다.
• VPC 로드 밸런서 호스트 이름에 대해 최대 128개의 하위 도메인을 등록할 수 있습니다. 지원 케이스를 열어 이 제한사항을 해제할 수 있습니다.
• VPC 부하 분산 장치에 등록하는 하위 도메인은 130자 이하로 제한됩니다.
• 특정 노드로 트래픽을 제한하는 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets 또는 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone 어노테이션으로 Kubernetes 로드밸런서 서비스가 생성되지 않는 한, VPC ALB는 클러스터 워커 노드가 할당된 것과 동일한 VPC 서브넷에서 수신 대기한다.
  • VPC ALB의 서브넷과 영역은 ALB가 생성된 후 업데이트하거나 수정할 수 있습니다. 클러스터에 더 많은 영역을 추가하거나 Kubernetes 로드밸런서 서비스를 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets 또는 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone 어노테이션으로 업데이트하면 VPC ALB가 새 서브넷에서 수신하도록 업데이트됩니다.
• VPC NLB는 단일 영역의 단일 VPC 서브넷에서만 수신합니다. 여러 VPC 서브넷에서 수신하거나 여러 영역에서 수신하도록 구성할 수 없습니다. service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets 또는 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone 어노테이션을 사용하여 수신 대기할 NLB의 단일 서브넷을 지정할 수 있습니다.
  • service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector 또는 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone annotations 를 사용하여 수신 트래픽을 특정 작업자 노드로 제한하지 않는 한 VPC NLB는 클러스터의 모든 작업자 노드로 수신 트래픽을 전달합니다. 특정 영역으로 트래픽을 제한하려면 이러한 어노테이션을 사용하여 해당 영역의 워커 노드를 지정할 수 있습니다.
• 로드 밸런서 NodePort 할당을 비활성화하는 것은 VPC 로드 밸런서에 대해 지원되지 않습니다.
• 동일한 VPC LB에서 UDP 및 TCP 모두에 VPC NLB를 설정할 수 있지만 수신 포트는 서로 달라야 합니다.