Network Load Balancer for VPC

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

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

• 표준 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에 포함된 하이픈(-)이 제거됩니다.

• 지속적 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는 클러스터의 모든 존에 걸쳐 다양한 워커 노드에 있는 앱 파드 간에 요청을 라우팅합니다.

Application Load Balancer for VPC

클러스터에 있는 앱으로의 수신 요청에 대한 외부 입력점 역할을 수행하는 7계층 다중 구역 Application Load Balancer for VPC(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를 통해 인터넷에서 앱에 액세스하는 방법을 보여줍니다.

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

포트 범위를 사용하여 NLB 설정

포트 범위는 각각 별도의 포트 번호에서 청취하는 다중 백엔드 애플리케이션이 있는 단일 호스트 이름에서 서비스를 호스트해야 하는 경우 공용 NLB에서 사용할 수 있습니다. Kubernetes 클러스터에서 포트 범위를 사용하려면 일부 수동 구성을 수행해야 합니다. 먼저 ibm-load-balancer-cloud-provider-vpc-port-range 옵션을 설정해야 합니다. 하나 또는 여러 범위를 포함할 수 있으며 각각 쉼표로 구분됩니다. spec.ports.port 값도 포트 범위의 최소값으로 설정해야 합니다.

다음 예제에서는 30000-30010 의 포트 범위가 사용됩니다.

NLB 서비스가 요청을 전달하는 각 배치에 대해 노드 포트 서비스를 수동으로 작성해야 합니다. 이러한 각 노드 포트 서비스의 포트 번호는 NLB 서비스에서 구성된 포트 범위 내에 있어야 합니다.

다음 예제 다이어그램에서 포트 30000을 사용하는 Nodeport 서비스는 배치 1에 대해 작성되고 포트 30001을 사용하는 Nodeport 서비스는 배치 2에 대해 작성됩니다.

사용자는 포트 범위를 포함하는 NLB의 포트 30001에 대한 요청을 작성합니다. 이 요청은 포트 30001 (이 경우에는 배치 2에 해당) 에서도 청취 중인 클러스터의 Nodeport 서비스로 요청을 지정하는 VPC NLB 서비스로 경로 지정됩니다. 그런 다음 Nodeport 서비스는 배치 2의 선택된 팟 (Pod) 의 대상 포트로 요청을 지정합니다.

다음 예제를 사용하여 포트 범위를 사용하는 NLB를 작성하십시오. 상태 검사가 성공을 리턴하고 데이터가 포트 범위의 포트에 전달되도록 선택기 및 백엔드 팟 (Pod) 이 포트 범위 로드 밸런서 서비스와 연관되어야 합니다. 포트 범위를 사용하려면 로드 밸런서 서비스에서 정의한 범위의 포트 값을 갖는 추가 NodePort 서비스를 작성해야 합니다.

1. 다음 예제 LoadBalancer 구성을 loadbalancer.yaml 라는 파일로 저장하십시오.

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-port-range: 30000-30010
     name: nlb-port-range
   spec:
     externalTrafficPolicy: Cluster
     ports:
     - port: 30000 # Must match min from the port range
       protocol: TCP
       nodePort: 30011 # Can be port in range or not
       targetPort: 8080
     selector:
       app: echo-server  # Must be valid for health checks to work
     type: LoadBalancer
   

2. 서비스를 작성하십시오.

   oc apply -f loadbalancer.yaml
   

3. 이전에 작성한 LoadBalancer 에 지정된 포트 범위에 있는 포트 값으로 NodePort 서비스를 작성하십시오.

   apiVersion: v1
   kind: Service
   metadata:
     name: echo-server-node-port
   spec:
     ports:
     - port: 80
       protocol: TCP # The protocol of the port range
       nodePort: 30003 # Node port in the port range
       targetPort: 8080
     selector:
       app: echo-server
     type: NodePort
   

4. NodePort 서비스를 생성합니다.

   oc apply -f nodeport.yaml
   

5. NLB에서 제공하는 범위에 있는 포트에 액세스합니다.

   curl https://<public ip assigned to NLB>:30003
   

   • 30003 = 요청에 응답하는 범위의 노드 포트입니다.
   • 범위에 있는 다른 포트는 추가 노드 포트 서비스가 작성되지 않으면 응답하지 않습니다.

사설 VPC NLB 설정

클러스터의 각 구역에서 Kubernetes LoadBalancer 서비스를 설정하여 사설 네트워크 트래픽에 앱을 노출하십시오. Kubernetes LoadBalancer 서비스를 작성하면 요청을 앱으로 라우팅하는 사설 Network Load Balancer for VPC(VPC NLB)가 클러스터의 외부에 있는 VPC에서 자동으로 작성됩니다.

시작하기 전에

• VPC NLB용 Kubernetes LoadBalancer 서비스를 배포할 네임스페이스에 대해 Writer 또는 Manager IBM Cloud IAM 서비스 액세스 역할이 부여되어 있는지 확인하십시오.
• VPC VPN 연결 등을 통해 VPC 사설 네트워크에 연결하십시오.
• Red Hat OpenShift 클러스터에 액세스하십시오.
• VPC NLB를 보려면 infrastructure-service 플러그인을 설치하십시오. 명령을 실행하기 위한 접두부는 ibmcloud is입니다.

  ibmcloud plugin install infrastructure-service
  

앱이 사설 네트워크 요청을 수신할 수 있도록 하려면 다음 작업을 수행하십시오.

1. VPC NLB 전용의 VPC 서브넷을 작성하십시오. 이 서브넷은 클러스터와 동일한 VPC 및 위치에 있어야 하지만 클러스터 또는 작업자 노드에 연결될 수 없습니다.

   1. VPC 서브넷 대시보드 에서 [ 새 서브넷 ]을 클릭합니다.
   2. 서브넷의 이름을 입력하십시오.
   3. 클러스터가 있는 위치와 VPC NLB를 작성할 구역을 선택하십시오.
   4. 클러스터가 있는 VPC의 이름을 선택하십시오.
   5. 작성할 IP 주소의 수를 지정하십시오. 이 서브넷은 VPC NLB 전용이므로 더 작은 크기(예: 16)를 선택할 수 있습니다. VPC 서브넷에 있는 IP 수를 나중에 변경할 수 없습니다. 특정 IP 범위를 입력하는 경우 예약 범위 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 및 172.20.0.0/16을 사용하지 마십시오.
   6. 서브넷 작성을 클릭하십시오. 서브넷이 프로비저닝된 후 ID를 기록해 두십시오.

2. VPC NLB를 통해 앱에 연결해야 하는 클라이언트가 전용 VPC 서브넷을 작성한 VPC 및 구역의 외부에 있는 경우에는 사용자 정의 Ingress 라우팅 테이블을 작성해야 합니다. 사설 VPC NLB는 몇 가지 장애 조건에 대해 서비스 가용성을 보장하기 위해 사용자 정의 라우팅 테이블에 규칙을 추가할 수 있습니다. 자세한 정보는 알려진 제한사항의 표와 라우팅 테이블 및 라우트 정보를 참조하십시오.

   1. VPC 라우팅 테이블 대시보드 에서 [ 만들기 ]를 클릭합니다.
   2. 라우팅 테이블의 이름을 입력하십시오.
   3. 전용 서브넷을 작성한 위치 및 구역을 선택하십시오.
   4. 서브넷이 있는 VPC의 이름을 선택하십시오.
   5. 트래픽 유형으로 Ingress를 선택하십시오.
   6. 클라이언트가 앱에 액세스하는 위치에 따라 트래픽 소스를 선택하십시오. VPC 사설 네트워크에 대한 연결 설정과 관련된 자세한 정보는 IBM Cloud VPC VPN, Transit Gateway 또는 Direct Link for VPC 연결 선택에 대한 문서를 참조하십시오.
      • 온프레미스 네트워크: Direct Link
      • 다른 VPC 또는 클래식 인프라: Transit Gateway
      • 동일 VPC 내의 다른 구역: VPC 구역

3. 클러스터에 앱을 배치하십시오. 배치 구성 파일의 메타데이터 섹션에서 레이블을 추가했는지 확인하십시오. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.

4. Kubernetes LoadBalancer 서비스의 구성 YAML 파일을 작성하십시오. <app_name>-vpc-nlb-<VPC_zone> 형식으로 서비스의 이름 지정을 고려하십시오.

   apiVersion: v1
   kind: Service
   metadata:
     name: <app_name>-vpc-nlb-<VPC_zone>
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp: "<tcp_port"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
     type: LoadBalancer
     selector:
       <selector_key>: <selector_value>
     ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   선택사항. VPC 로드 밸런서가 지속적이 되도록 고유한 이름을 포함하십시오. 지속적 VPC 로드 밸런서는 속해 있는 클러스터가 삭제될 때 삭제되지 않습니다. 자세한 정보는 지속적 VPC 로드 밸런서 를 참조하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "nlb"

   필수: VPC NLB를 작성하는 어노테이션입니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"

   필수: 사설 요청을 승인하는 서비스를 지정하는 어노테이션입니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   필수: VPC NLB가 배치되는 전용 서브넷을 지정하는 어노테이션입니다. 이 값은 VPC 서브넷 ID, VPC 서브넷 이름 또는 VPC 서브넷 CIDR로 지정할 수 있습니다. 하나의 서브넷만 지정해야 합니다. 이 서브넷은 클러스터와 동일한 VPC 및 클러스터에 작업자 노드가 있는 구역에 있어야 하지만 이 서브넷에 작업자 노드를 연결할 수는 없습니다. 이 서브넷과 동일한 구역에 있는 작업자 노드가 VPC NLB로부터 트래픽을 수신하도록 구성됩니다. 모든 리소스 그룹의 서브넷을 보려면 ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>을 실행하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   선택사항: 작업자 노드 레이블 선택기를 지정하는 어노테이션입니다. VPC NLB의 전용 서브넷과 같은 구역 내에서, 지원되는 레이블 선택기 키 중 하나를 선택하여 트래픽을 수신하도록 특정 작업자 노드를 구성할 수 있습니다. 어노테이션에는 하나의 레이블 선택기만 포함시킬 수 있으며 해당 선택기는 "key=value" 형식으로 지정해야 한다는 점을 참고하십시오. 이 어노테이션이 지정되지 않은 경우에는 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets 어노테이션에 지정된 VPC 서브넷과 동일한 구역에 있는 모든 작업자 노드가 VPC NLB로부터 트래픽을 수신하도록 구성됩니다. 지정된 경우에는 작업자 노드의 모든 dedicated: edge 레이블이 무시됩니다.

   다음 키가 허용됩니다. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp

   선택 사항: UDP 로드 밸런서에서 TCP 상태 점검에 사용할 TCP 노드 포트를 지정합니다. externalTrafficPolicy 가 Cluster 로 설정된 UDP 로드 밸런서의 경우 필수입니다. 포트 값을 설정하기 전에 고려해야 할 추가 사항에 대해서는 “ UDP 로드 밸런서를 위한 TCP 상태 확인 구성”을 참조하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   선택사항: 이 어노테이션은 Kubernetes 로드 밸런서 서비스와 연관된 VPC 로드 밸런서 리소스에서 상태 검사 프로토콜을 설정합니다. 일반적으로 VPC LB 상태 검사 프로토콜은 Kubernetes 로드 밸런서 서비스 스펙의 externalTrafficPolicy 설정 값으로 판별됩니다. 이 어노테이션은 해당 로직을 대체합니다. 이 어노테이션은 Kubernetes및 특히 kube-proxy가 externalTrafficPolicy 의 다양한 설정과 관련하여 작동하는 방법을 변경하지 않습니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   선택사항. 상태 확인에 사용되는 TCP 포트입니다. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 도 지정된 경우에만 적용됩니다.

   • 지정된 TCP 포트가 Kubernetes 노드 포트 범위(30,000~32,767)를 벗어날 경우, 클러스터 워커 노드에 적용된 VPC 보안 그룹을 수정하여 해당 포트에 대한 인바운드 트래픽을 허용해야 합니다.
   • 이 어노테이션이 VPC ALB와 연결된 Kubernetes 로드 밸런서 서비스에 적용되는 경우, VPC ALB에 할당된 보안 그룹의 아웃바운드 규칙을 수정하여 지정된 TCP 포트로의 아웃바운드 트래픽을 허용해야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   선택사항. HTTP 및 HTTPS 상태 점검에 대한 상태 점검 경로: URL. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 가 http 또는 https 로 설정된 경우에만 적용됩니다.

   • URL 경로는 원본-형식 요청 대상 형식을 따라야 합니다.
   • 이 어노테이션이 지정되지 않고 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 어노테이션이 http 또는 https 로 설정되면 기본값 / 가 적용됩니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   선택사항. 상태 검사 시도 사이에 대기하는 시간 (초) 입니다. 기본적으로 이 값은 5 로 설정되며 최소값은 2 이고 최대값은 60 입니다. 이 값은 ibm-load-balancer-cloud-provider-vpc-health-check-timeout 값 (기본적으로 2 로 설정됨) 보다 커야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   선택사항. 상태 검사에 대한 응답을 기다리는 시간 (초) 입니다. 기본적으로 이 값은 2 로 설정되며 최소값은 1 이고 최대값은 59 입니다. 이 값은 기본적으로 5 로 설정되는 ibm-load-balancer-cloud-provider-vpc-health-check-delay 보다 작아야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   VPC 로드 밸런서에 대한 최대 상태 검사 재시도 수입니다. 기본적으로 이 값은 2 로 설정되며 최소 1 및 최대 10 를 갖습니다.

   selector

   앱 배치 YAML의 spec.template.metadata.labels 섹션에서 사용한 레이블 키(<selector_key>) 및 값(<selector_value>)입니다. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.

   port

   서비스가 청취하는 포트입니다.

   targetPort

   선택사항: 서비스가 트래픽을 지정하는 대상 포트입니다. 포드에서 실행 중인 애플리케이션은 이 대상 포트에서 들어오는 TCP 트래픽을 수신 대기해야 합니다. 대상 포트는 종종 애플리케이션 팟 (Pod) 에서 실행 중인 이미지에 정적으로 정의됩니다. 팟 (Pod) 에 구성된 대상 포트는 서비스의 노드 포트와 다르며 VPC LB에 구성된 외부 포트와도 다를 수 있습니다.

   externalTrafficPolicy

   필수. 지정하다 Local 또는 Cluster.

   앱으로 전송되는 클라이언트 요청의 소스 IP 주소를 유지하려면 Local 로 설정하십시오. 이 설정은 수신 트래픽이 다른 노드로 전달되지 않도록 합니다. 이 옵션은 또한 ‘ HTTP ’ 상태 확인을 구성합니다.

   Cluster 가 설정된 경우, DSR은 VPC NLB가 수신 요청을 처음 전달한 워커 노드에서만 구현됩니다. 수신 요청이 도착하면 다른 구역에 있을 수 있는 앱 팟 (Pod) 을 포함하는 작업자 노드로 요청이 전달됩니다. 앱 팟(Pod)의 응답이 원래 작업자 노드로 전송되고 이 작업자 노드는 DSR을 사용하여 응답을 다시 클라이언트로 보내며 이때 VPC NLB를 우회합니다. 이 옵션은 TCP 상태 확인도 설정합니다. UDP 로드 밸런서의 경우, ‘ Cluster ’ 옵션을 선택하면 ‘ service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ’이 필요합니다. 자세한 내용은 ‘ UDP 로드 밸런서에 대한 TCP 상태 확인 구성’을 참조하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   선택사항입니다. 로드밸런서가 라우팅하는 영역당 작업자 노드 수입니다. 기본값은 8입니다. 3개의 영역에 워커 노드가 있는 클러스터의 경우, 이렇게 하면 로드 밸런서가 총 24개의 워커 노드로 라우팅하게 됩니다. 로드 밸런서가 라우팅하는 모든 영역의 총 작업자 노드 수는 50개를 초과할 수 없습니다. 클러스터의 워커 노드가 모든 영역에 걸쳐 50개 미만인 경우, 0을 지정하여 영역의 모든 워커 노드로 라우팅합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   선택사항입니다. VPC 부하 분산 장치에 추가할 고객 관리형 보안 그룹입니다. IBM-관리되는 보안 그룹 을 사용하지 않으려면 소유하고 관리하는 보안 그룹을 지정하세요. 이 옵션은 IBM으로 관리되는 보안 그룹을 제거하고 지정한 보안 그룹으로 바꿉니다. 기존 로드 밸런서에서 어노테이션을 제거하면 추가한 보안 그룹이 IBM 관리 보안 그룹으로 바뀝니다. 이 주석은 언제든지 추가하거나 삭제할 수 있습니다. 보안 그룹을 관리하고 최신 상태로 유지할 책임은 회원님에게 있습니다.

5. 클러스터에 Kubernetes LoadBalancer 서비스를 작성하십시오.

   oc apply -f <filename>.yaml -n <namespace>
   

6. 클러스터에서 Kubernetes LoadBalancer 서비스가 작성되었는지 확인하십시오. 서비스가 작성되면 LoadBalancer Ingress 필드는 VPC NLB가 지정하는 외부 IP 주소로 채워집니다.

VPC에서 VPC NLB를 프로비저닝하는 데 수 분이 소요됩니다. Kubernetes LoadBalancer 서비스의 외부 IP 주소는 VPC NLB가 완전히 프로비저닝될 때까지 pending 상태일 수 있습니다.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
사설 `LoadBalancer` 서비스에 대한 CLI 출력 예:
```sh {: screen}
NAME:                     myvpcnlb
Namespace:                default
Labels:                   <none>
Annotations:              service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: nlb
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
                          service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.204.12
LoadBalancer Ingress:     10.XXX.XXX.XXX
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  32022/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     30882
Events:
    Type     Reason                           Age                  From                Message
----     ------                           ----                 ----                -------
Warning  SyncLoadBalancerFailed           13m (x5 over 15m)    service-controller  Error syncing load balancer: failed to ensure load balancer: kube-bqcssbbd0bsui62odcdg-2d93b07decf641d2ad3f9c2985122ec1 for service default/myvpcnlb is busy: offline/create_pending
Normal   EnsuringLoadBalancer             9m27s (x7 over 15m)  service-controller  Ensuring load balancer
Normal   EnsuredLoadBalancer              9m20s                service-controller  Ensured load balancer
Normal   CloudVPCLoadBalancerNormalEvent  8m17s                ibm-cloud-provider  Event on cloud load balancer myvpcnlb for service default/myvpcnlb with UID 2d93b07d-ecf6-41d2-ad3f-9c2985122ec1: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

7. VPC에 VPC NLB가 작성되었는지 확인하십시오. 출력에서 VPC NLB의 운영 상태가 online이고 프로비저닝 상태가 active인지 확인하십시오.

   ibmcloud is load-balancers
   

   다음 CLI 출력 예에서는 kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e로 이름 지정된 VPC NLB가 Kubernetes LoadBalancer 서비스에 대해 작성되었습니다.

   ID                                     Name                                                         Created          Host Name                                  Is Public   Listeners                               Operating Status   Pools                                   Private IPs              Provision Status   Public IPs                    Subnets                                Resource Group
   06496f64-a689-4693-ba23-320959b7b677   kube-bh077ne10vqpekt0domg-046e0f754d624dca8b287a033d55f96e   8 minutes ago    1234abcd-us-south.lb.appdomain.cloud       no         95482dcf-6b9b-4c6a-be54-04d3c46cf017    online             717f2122-5431-403c-b21d-630a12fc3a5a    10.XXX.XXX.XXX           active             -               c6540331-1c1c-40f4-9c35-aa42a98fe0d9   00809211b934565df546a95f86160f62
   

8. VPC 사설 네트워크에 대한 연결에서, 6단계에서 찾은 Kubernetes LoadBalancer 서비스의 IP 주소 및 앱 포트(<external_IP>:<app_port> 형식)에 액세스하십시오.

9. 선택사항: 앱을 노출할 각 구역에 사설 VPC NLB를 배치하려면 이러한 단계를 반복하십시오. 그런 다음 하나의 DNS 하위 도메인으로 각 구역에 VPC NLB의 외부 IP주소를 등록할 수 있습니다.

DNS 레코드 및 TLS 인증서 등록

VPC NLB는 앱에 액세스할 수 있는 정적 외부 IP 주소를 제공합니다. HTTPS를 지원하도록 앱 도메인에 대한 SSL 인증서를 등록하려면 IBM 제공 하위 도메인을 작성하거나 사용자 정의 도메인을 사용할 수 있습니다.

예를 들어, 다중 구역 클러스터가 있다고 가정하고 클러스터의 각 구역에 있는 작업자 노드에서 앱의 복제본을 실행합니다. 앱 복제본을 노출하기 위해 구역당 하나의 VPC NLB를 작성합니다. 그런 다음 하나의 DNS 항목을 사용하여 각 VPC NLB에서 제공되는 외부 IP 주소를 등록할 수 있습니다.

VPC NLB 호스트 이름에 대한 DNS 하위 도메인을 작성한 후에는 nlb-dns health-monitor 명령을 사용하여 사용자 정의 상태 검사를 작성할 수 없습니다. 대신 기본 VPC 상태 검사가 사용됩니다. 자세한 정보는 VPC 문서를 참조하십시오.

• 앱에 대해 구역당 하나의 VPC NLB를 작성하십시오. VPC NLB를 구성하는 Kubernetes LoadBalancer 서비스에서 HTTP 포트를 정의했는지 확인하십시오.
• HTTPS를 통해 앱에 액세스하는 데 SSL 인증서를 사용하려면 앱이 TLS 연결을 종료할 수 있어야 합니다.

VPC NLB IP 주소를 DNS 하위 도메인에 등록하려면 다음 작업을 수행하십시오.

1. 로드 밸런서의 외부 IP 주소를 검색하십시오.

   oc get svc -o wide
   

   출력 예

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)            AGE      SELECTOR
   ...
   myapp-vpc-nlb-jp-tok-3    LoadBalancer   172.21.xxx.xxx   169.xx.xxx.xx     8080:30532/TCP     1d       run=webserver
   

2. IP 주소에 대해 사용자 정의 또는 IBM 제공 DNS 서브도메인을 작성하십시오.

   • 사용자 정의 도메인:

     1. DNS(Domain Name Service) 제공자 또는 IBM Cloud DNS를 통해 사용자 정의 도메인을 등록하십시오.
     2. 로드 밸런서 IP 주소를 A 레코드로 지정하여 사용자 정의 도메인의 별명을 정의하십시오.

   • IBM 제공 하위 도메인: IP 주소에 대한 SSL 인증서로 하위 도메인을 생성하려면 nlb-dns 명령을 사용하십시오. IBM Cloud는 사용자 대신 하위 도메인의 와일드카드 SSL 인증서를 생성 및 유지보수합니다.

     1. DNS 하위 도메인 및 SSL 인증서를 작성하십시오.

        ibmcloud oc nlb-dns create vpc-gen2 --type public --cluster <cluster_name_or_id> --ip <vpc_nlb1_ip> --ip <vpc_nlb2_ip> --ip <vpc_nlb3_ip>
        

     2. 하위 도메인이 작성되었는지 확인하십시오. 자세한 정보는 하위 도메인 포맷 이해를 참조하십시오.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        출력 예

        Subdomain                                                                               IP(s)                                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     169.46.xx.x,169.48.xxx.xx,169.48.xxx.xx      None             created                   <certificate>
        

3. 웹 브라우저를 열고 URL을 입력하여 하위 도메인을 통해 앱에 액세스하십시오.

HTTPS를 통해 앱에 액세스하는 데 SSL 인증서를 사용하려면 Kubernetes LoadBalancer 서비스에서 HTTPS 포트를 정의했는지 확인하십시오. curl -v --insecure https://<domain>을 실행하여 HTTPS 포트를 통해 요청이 올바르게 라우팅되는지 확인할 수 있습니다. 서비스에 HTTPS 포트가 열려 있지 않다는 연결 오류가 표시됩니다. 또한 앱을 사용하여 TLS 연결을 종료할 수 있는지 확인하십시오. curl -v https://<domain>을 행하여 앱이 TLS를 올바르게 종료하는지 확인할 수 있습니다. 앱이 TLS 연결을 올바르게 종료하지 않는다는 인증서 오류가 표시됩니다.

공용 또는 사설 VPC ALB 설정

시작하기 전에

• VPC NLB용 Kubernetes LoadBalancer 서비스를 배포할 네임스페이스에 대해 Writer 또는 Manager IBM Cloud IAM 서비스 액세스 역할이 부여되어 있는지 확인하십시오.
• Red Hat OpenShift 클러스터에 액세스하십시오.
• VPC ALB를 보려면 infrastructure-service 플러그인을 설치하십시오. 명령을 실행하기 위한 접두부는 ibmcloud is입니다.

  ibmcloud plugin install infrastructure-service
  

앱이 공용 또는 개인용 요청을 수신할 수 있도록 하려면 다음 작업을 수행하십시오.

1. 클러스터에 앱을 배치하십시오. 배치 구성 파일의 메타데이터 섹션에서 레이블을 추가했는지 확인하십시오. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.

2. Kubernetes LoadBalancer 서비스용 구성 YAML 파일을 작성하고 파일 이름을 myloadbalancer.yaml로 지정하십시오.

   apiVersion: v1
   kind: Service
   metadata:
     name: myloadbalancer
     annotations:
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "<public_or_private>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector: "<key>=<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets: "<subnet1_ID,subnet2_ID>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "<zone>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol: "<protocol>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port: "<port>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path: "<url_path>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota: "<value>"
       service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group: "<security-group>"
   spec:
    type: LoadBalancer
    selector:
       <selector_key>: <selector_value>
    ports:
      - name: http
        protocol: TCP
        port: 8080
        targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
      - name: https
        protocol: TCP
        port: 443
        targetPort: 443 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.
     externalTrafficPolicy: Local # Specify Local or Cluster.
   

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"

   선택사항. VPC 로드 밸런서가 지속적이 되도록 고유한 이름을 포함하십시오. 지속적 VPC 로드 밸런서는 속해 있는 클러스터가 삭제될 때 삭제되지 않습니다. 자세한 정보는 지속적 VPC 로드 밸런서 를 참조하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol"

   선택 사항: PROXY 프로토콜을 활성화합니다. 로드 밸런서는 요청 헤더의 클라이언트 IP 주소, 프록시 서버 IP 주소 및 두 포트 번호를 포함한 클라이언트 연결 정보를 백엔드 앱에 전달합니다. 백엔드 앱이 PROXY 프로토콜을 허용하도록 구성되어야 합니다. 예를 들어, 다음 단계를 따라 NGINX 앱이 PROXY 프로토콜을 수락하도록 설정할 수 있습니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type

   공용 또는 개인용 요청을 승인하는 서비스를 지정하는 어노테이션입니다. 이 어노테이션을 포함하지 않으면 공용 LoadBalancer가 작성됩니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-node-selector

   워커 노드 레이블 선택기를 지정하기 위한 어노테이션. 사용자는 트래픽을 수신하는 작업자 노드를 식별하기 위해 지원되는 레이블 선택기 키 중 하나를 선택할 수 있습니다. 어노테이션에는 하나의 레이블 선택기만 포함시킬 수 있으며 해당 선택기는 "key=value" 형식으로 지정해야 한다는 점을 참고하십시오. 이 어노테이션이 지정되지 않으면 클러스터의 모든 작업자 노드가 VPC ALB로부터 트래픽을 수신하도록 구성됩니다. 지정된 경우 이 어노테이션은 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone 어노테이션보다 우선하며 작업자 노드의 모든 dedicated: edge 레이블이 무시됩니다.

   다음과 같은 키가 허용됩니다. - ibm-cloud.kubernetes.io/internal-ip - ibm-cloud.kubernetes.io/machine-type - ibm-cloud.kubernetes.io/os - ibm-cloud.kubernetes.io/region - ibm-cloud.kubernetes.io/subnet-id - ibm-cloud.kubernetes.io/worker-pool-id - ibm-cloud.kubernetes.io/worker-pool-name - ibm-cloud.kubernetes.io/zone - kubernetes.io/arch - kubernetes.io/hostname - kubernetes.io/os - node.kubernetes.io/instance-type - topology.kubernetes.io/region - topology.kubernetes.io/zone

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-subnets

   VPC ALB 서비스가 배포될 하나 이상의 서브넷을 지정하는 주석입니다. 지정된 경우 이 어노테이션은 service.kubernetes.io/ibm-load-balancer-cloud-provider-zone 어노테이션보다 우선합니다. 동일한 VPC에서 클러스터가 연결된 서브넷과 다른 서브넷을 지정할 수 있다는 점을 참고하십시오. 이 경우 VPC ALB는 동일한 VPC의 다른 서브넷에 배치되지만 VPC ALB는 여전히 동일한 구역에 있는 클러스터 서브넷의 작업자 노드에 트래픽을 라우팅할 수 있습니다. 모든 리소스 그룹의 서브넷을 보려면 ibmcloud oc subnets --provider vpc-gen2 --vpc-id <vpc> --zone <zone>을 실행하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-zone

   클러스터가 연결된 VPC 구역을 지정하는 어노테이션입니다. 이 어노테이션에 구역을 지정하면 두 개의 프로세스가 발생합니다.

   1. 작업자 노드가 연결된 구역의 동일한 서브넷에 VPC ALB가 배치됩니다.
   2. 이 구역에 있는 클러스터의 작업자 노드만 VPC ALB로부터 트래픽을 수신하도록 구성됩니다.

   구역을 보려면 ibmcloud oc zone ls --provider vpc-gen2를 실행하십시오.

   특정 구역에 로드 밸런서를 배치하려면 로드 밸런서를 작성하는 이 어노테이션을 지정해야 합니다. 이 어노테이션을 나중에 다른 구역으로 변경하는 경우 로드 밸런서 자체는 새 구역으로 이동되지 않습니다. 그러나 로드 밸런서가 새 구역의 작업자 노드로만 트래픽을 전송하도록 재구성됩니다.

   작업자 노드에 dedicated: edge 레이블이 설정되어 있고 이 어노테이션을 지정하면 지정된 영역의 에지 노드만 트래픽을 수신하도록 구성됩니다. 다른 구역의 에지 노드 및 지정된 구역의 에지가 아닌 노드는 로드 밸런서에서 트래픽을 수신하지 않습니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

   선택사항: 이 어노테이션은 Kubernetes 로드 밸런서 서비스와 연관된 VPC 로드 밸런서 리소스에서 상태 검사 프로토콜을 설정합니다. 일반적으로 VPC LB 상태 검사 프로토콜은 Kubernetes 로드 밸런서 서비스 스펙의 externalTrafficPolicy 설정 값으로 판별됩니다. 이 어노테이션은 해당 로직을 대체합니다. 이 어노테이션은 Kubernetes및 특히 kube-proxy가 externalTrafficPolicy 의 다양한 설정과 관련하여 작동하는 방법을 변경하지 않습니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

   선택사항. 상태 확인에 사용되는 TCP 포트입니다. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 도 지정된 경우에만 적용됩니다.

   • 지정된 TCP 포트가 Kubernetes 노드 포트 범위(30,000~32,767)를 벗어날 경우, 클러스터 워커 노드에 적용된 VPC 보안 그룹을 수정하여 해당 포트에 대한 인바운드 트래픽을 허용해야 합니다.
   • 이 어노테이션이 VPC ALB와 연결된 Kubernetes 로드 밸런서 서비스에 적용되는 경우, VPC ALB에 할당된 보안 그룹의 아웃바운드 규칙을 수정하여 지정된 TCP 포트로의 아웃바운드 트래픽을 허용해야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

   선택사항. HTTP 및 HTTPS 상태 점검에 대한 상태 점검 경로: URL. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 가 http 또는 https 로 설정된 경우에만 적용됩니다.

   • URL 경로는 원본-형식 요청 대상 형식을 따라야 합니다.
   • 이 어노테이션이 지정되지 않고 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 어노테이션이 http 또는 https 로 설정되면 기본값 / 가 적용됩니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

   선택사항. 상태 검사 시도 사이에 대기하는 시간 (초) 입니다. 기본적으로 이 값은 5 로 설정되며 최소값은 2 이고 최대값은 60 입니다. 이 값은 ibm-load-balancer-cloud-provider-vpc-health-check-timeout 값 (기본적으로 2 로 설정됨) 보다 커야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

   선택사항. 상태 검사에 대한 응답을 기다리는 시간 (초) 입니다. 기본적으로 이 값은 2 로 설정되며 최소값은 1 이고 최대값은 59 입니다. 이 값은 기본적으로 5 로 설정되는 ibm-load-balancer-cloud-provider-vpc-health-check-delay 보다 작아야 합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

   VPC 로드 밸런서에 대한 최대 상태 검사 재시도 수입니다. 기본적으로 이 값은 2 로 설정되며 최소 1 및 최대 10 를 갖습니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-idle-connection-timeout

   선택사항. 리스너의 유휴 연결 제한시간(초 단위)입니다. 기본 유휴 제한시간은 계정 설정에 따라 다릅니다. 일반적으로 이 값은 50 입니다. 그러나 일부 허용 목록에 있는 계정에는 더 큰 제한시간 설정이 있습니다. 어노테이션을 설정하지 않으면 로드 밸런서가 계정의 제한시간 설정을 사용합니다. 이 어노테이션을 설정하여 제한시간을 명시적으로 지정할 수 있습니다. 최소값은 50입니다. 최대값은 7200 입니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

   선택사항입니다. 해당 버전의 프라이빗 VPC ALB에만 적용 가능4.15 또는 나중에. 이 로드 밸런서에 연결할 DNS instance 입니다. 자세한 내용은 다음을 참조하세요.개인 DNS 레코드 등록.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

   선택사항입니다. 해당 버전의 프라이빗 VPC ALB에만 적용 가능4.15 또는 나중에. 이 로드 밸런서에 연결할 DNS zone 입니다. 자세한 내용은 다음을 참조하세요.개인 DNS 레코드 등록.

   selector

   앱 배치 YAML의 spec.template.metadata.labels 섹션에서 사용한 레이블 키(<selector_key>) 및 값(<selector_value>)입니다. 이 사용자 정의 레이블은 앱이 실행되는 모든 팟(Pod)을 식별하여 로드 밸런싱에 포함시킵니다.

   port

   서비스가 청취하는 포트입니다.

   targetPort

   선택사항: 서비스가 트래픽을 지정하는 대상 포트입니다. 포드에서 실행 중인 애플리케이션은 이 대상 포트에서 들어오는 TCP 트래픽을 수신 대기해야 합니다. 대상 포트는 종종 애플리케이션 팟 (Pod) 에서 실행 중인 이미지에 정적으로 정의됩니다. 팟 (Pod) 에 구성된 대상 포트는 서비스의 노드 포트와 다르며 VPC LB에 구성된 외부 포트와도 다를 수 있습니다.

   externalTrafficPolicy

   필수. Local 또는 Cluster 를 지정합니다.

   앱으로 전송되는 클라이언트 요청의 소스 IP 주소를 유지하려면 Local 로 설정하십시오. 이 설정은 수신 트래픽이 다른 노드로 전달되지 않도록 합니다. 이 옵션은 또한 ‘ HTTP ’ 상태 확인을 구성합니다. UDP 로드 밸런서의 경우, ‘ Cluster ’ 옵션을 선택하면 ‘ service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp ’이 필요합니다. 자세한 내용은 ‘ UDP 로드 밸런서에 대한 TCP 상태 점검 구성’을 참조하십시오.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-member-quota

   선택사항입니다. 로드밸런서가 라우팅하는 영역당 작업자 노드 수입니다. 기본값은 8입니다. 3개의 영역에 워커 노드가 있는 클러스터의 경우, 이렇게 하면 로드 밸런서가 총 24개의 워커 노드로 라우팅하게 됩니다. 로드 밸런서가 라우팅하는 모든 영역의 총 작업자 노드 수는 50개를 초과할 수 없습니다. 클러스터의 워커 노드가 모든 영역에 걸쳐 50개 미만인 경우, 0을 지정하여 영역의 모든 워커 노드로 라우팅합니다.

   service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group

   선택사항입니다. VPC 부하 분산 장치에 추가할 고객 관리형 보안 그룹입니다. IBM-관리되는 보안 그룹 을 사용하지 않으려면 소유하고 관리하는 보안 그룹을 지정하세요. 이 옵션은 IBM으로 관리되는 보안 그룹을 제거하고 지정한 보안 그룹으로 바꿉니다. 기존 로드 밸런서에서 어노테이션을 제거하면 추가한 보안 그룹이 IBM 관리 보안 그룹으로 바뀝니다. 이 주석은 언제든지 추가하거나 삭제할 수 있습니다. 보안 그룹을 관리하고 최신 상태로 유지할 책임은 회원님에게 있습니다.

3. 클러스터에 Kubernetes LoadBalancer 서비스를 작성하십시오.

   oc apply -f myloadbalancer.yaml -n <namespace>
   

4. 클러스터에서 Kubernetes LoadBalancer 서비스가 작성되었는지 확인하십시오. 서비스가 작성되면 LoadBalancer Ingress 필드는 VPC ALB가 지정하는 호스트 이름으로 채워집니다.

VPC에서 VPC ALB를 프로비저닝하는 데 수 분이 소요됩니다. VPC ALB가 완전히 프로비저닝될 때까지 Kubernetes LoadBalancer 서비스의 호스트 이름을 사용하여 앱에 액세스할 수 없습니다.

```sh {: pre}
oc describe svc myloadbalancer -n <namespace>
```
공용 `LoadBalancer` 서비스의 CLI 출력 예:
```sh {: screen}
NAME:                     myvpcalb
Namespace:                default
Labels:                   <none>
Annotations:              
Selector:                 app=echo-server
Type:                     LoadBalancer
IP:                       172.21.XX.XX
LoadBalancer Ingress:     1234abcd-us-south.lb.appdomain.cloud
Port:                     tcp-80  80/TCP
TargetPort:               8080/TCP
NodePort:                 tcp-80  30610/TCP
Endpoints:                172.17.17.133:8080,172.17.22.68:8080,172.17.34.18:8080 + 3 more...
Session Affinity:         None
External Traffic Policy:  Local
HealthCheck NodePort:     31438
Events:
    Type    Reason                           Age   From                Message
----    ------                           ----  ----                -------
Normal  EnsuringLoadBalancer             16m   service-controller  Ensuring load balancer
Normal  EnsuredLoadBalancer              15m   service-controller  Ensured load balancer
Normal  CloudVPCLoadBalancerNormalEvent  13m   ibm-cloud-provider  Event on cloud load balancer myvpcalb for service default/myvpcalb with UID 08cbacf0-2c93-4186-84b6-c4ab88a2faf9: The VPC load balancer that routes requests to this Kubernetes LoadBalancer service is currently online/active.
```

5. VPC에 VPC ALB가 작성되었는지 확인하십시오. 출력에서 VPC ALB의 운영 상태가 online이고 프로비저닝 상태가 active인지 확인하십시오.

   LoadBalancer 서비스에 대해 자동으로 작성되는 VPC ALB의 이름을 바꾸지 마십시오. VPC ALB의 이름을 바꾸면 Red Hat OpenShift on IBM Cloud는 LoadBalancer 서비스에 대한 다른 VPC ALB를 자동으로 작성합니다.

   ibmcloud is load-balancers
   

   다음 CLI 출력 예에서는 kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306으로 이름 지정된 VPC ALB가 Kubernetes LoadBalancer 서비스에 대해 작성되었습니다.

   ID                                          Name                                                         Family        Subnets               Is public   Provision status   Operating status   Resource group
   r006-d044af9b-92bf-4047-8f77-a7b86efcb923   kube-bsaucubd07dhl66e4tgg-1f4f408ce6d2485499bcbdec0fa2d306   Application   mysubnet-us-south-3   true        active             online             default
   

6. 공용 LoadBalancer 서비스를 작성한 경우, 4단계에서 찾은 VPC ALB가 지정한 Kubernetes LoadBalancer 서비스의 호스트 이름에 대해 curl을 실행하십시오. 예:

   curl 06496f64-us-south.lb.appdomain.cloud:8080
   

   출력 예

   Hello world from hello-world-deployment-5fd7787c79-sl9hn! Your app is up and running in a cluster!
   

   사설 LoadBalancer 서비스를 작성한 경우, 사설 VPC 네트워크에 연결하여 호스트 이름을 curl해야 합니다.

클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

Kubernetes 이나 OpenShift 클러스터에 연결되어 있지 않은 VPC ALB 및 NLB는 'ibmcloud is' 명령어나 콘솔의 VPC 인프라 섹션을 사용하여 직접 업데이트할 수 있습니다. 예를 들어, 프론트 엔드 리스너의 포트 또는 상태 검사 제한시간 값을 변경하십시오. 그러나 Kubernetes 또는 OpenShift 클러스터에 연결된 VPC 로드 밸런서의 경우, 해당 로드 밸런서에 대한 모든 업데이트는 Ingress 구성의 어노테이션을 통해 수행해야 합니다. IBM Cloud 공급자는 연결된 모든 VPC ALB 및 NLB와 주기적으로 재동기화를 수행하여, 실행 중인 로드 밸런서가 Ingress의 예상 구성에 부합하는지 확인합니다. 따라서 Ingress 어노테이션을 사용하는 대신 VPC를 통해 직접 이러한 로드 밸런서를 변경하면 해당 변경사항이 다시 되돌려집니다.

DNS 레코드 및 TLS 인증서 등록

Application Load Balancer for VPC(VPC ALB)는 앱에 액세스하는 데 사용할 수 있는 1234abcd-<region>.lb.appdomain.cloud 형식의 기본 HTTP 호스트 이름을 제공합니다. 그러나 앱 도메인에 대한 TLS 인증서가 HTTPS를 지원하도록 하려는 경우에는 공용 및 사설 VPC ALB 모두에 대해 IBM 제공 하위 도메인을 작성하거나 사용자 정의 도메인을 사용할 수 있습니다.

VPC ALB 호스트 이름에 대한 DNS 하위 도메인을 작성한 후에는 nlb-dns health-monitor 명령을 사용하여 사용자 정의 상태 검사를 작성할 수 없습니다. 대신 기본 VPC ALB 호스트 이름에 대해 제공되는 기본 VPC 로드 밸런서 상태 확인이 사용됩니다. 자세한 정보는 VPC 문서를 참조하십시오.

시작하기 전에

• VPC ALB를 설정하십시오. VPC ALB를 구성하는 Kubernetes LoadBalancer 서비스에서 HTTP 포트를 정의했는지 확인하십시오.
• HTTPS를 통해 앱에 액세스하는 데 TLS 인증서를 사용하려면 앱이 TLS 연결을 종료할 수 있어야 합니다.

VPC ALB 호스트 이름을 DNS 하위 도메인에 등록하려면 다음 작업을 수행하십시오.

1. get svc 명령을 실행하여 VPC ALB의 호스트 이름을 검색하십시오. 출력의 EXTERNAL-IP 열에서 호스트 이름을 찾으십시오. 예: 1234abcd-us-south.lb.appdomain.cloud.

   oc get svc -o wide
   

   출력 예

   NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                            PORT(S)     AGE       SELECTOR
   ...
   webserver-lb    LoadBalancer   172.21.xxx.xxx   1234abcd-us-south.lb.appdomain.cloud   8080:30532/TCP     1d       run=webserver
   

2. 로드 밸런서 호스트 이름에 대해 사용자 정의 또는 IBM 제공 DNS 서브도메인을 작성하십시오.

   • 사용자 지정 도메인: 사용자 지정 도메인을 입력하고, 로드 밸런서의 외부 IP를 1234abcd-us-south.lb.appdomain.cloud 형식으로 지정하여 CNAME(Canonical Name) 레코드로 별칭을 설정하십시오.

     1. DNS(Domain Name Service) 제공자 또는 IBM Cloud DNS를 통해 사용자 정의 도메인을 등록하십시오.
     2. 로드 밸런서의 외부 IP를 정규 이름 레코드(CNAME)로 지정하여 사용자 지정 도메인의 별칭을 정의하십시오. 다음 예제에서 외부 IP가 1234abcd-us-south.lb.appdomain.cloud 인 로드 밸런서는 www.your-custom-domain.com 에서 도달할 수 있습니다.

     호스트/서비스

     앱에 연결하려는 접두부입니다 (예: www).

     리소스 유형

     CNAME을(를) 선택하십시오.

     TTL

     TTL (Time to Live) 을 선택하십시오.

     값/대상

     이전에 검색한 LoadBalancer 외부 IP입니다. 예를 들어, 1234abcd-us-south.lb.appdomain.cloud. 입니다. IBM Cloud DNS를 사용하는 경우 후행 마침표를 입력해야 합니다.

   • IBM 제공 하위 도메인: VPC ALB 호스트 이름에 대한 TLS 인증서로 하위 도메인을 생성하려면 nlb-dns 명령을 사용하십시오. IBM Cloud는 사용자 대신 하위 도메인의 와일드카드 TLS 인증서를 생성 및 유지보수합니다.

     1. DNS 하위 도메인 및 TLS 인증서를 작성하십시오.

        ibmcloud oc nlb-dns create vpc-gen2 --cluster <cluster_name_or_id> --lb-host <vpc_lb_hostname> --type (public|private)
        

     2. 하위 도메인이 작성되었는지 확인하십시오. 자세한 정보는 하위 도메인 포맷 이해를 참조하십시오.

        ibmcloud oc nlb-dns ls --cluster <cluster_name_or_id>
        

        출력 예

        Subdomain                                                                               Load Balancer Hostname                        Health Monitor   SSL Cert Status           SSL Cert Secret Name
        mycluster-a1b2cdef345678g9hi012j3kl4567890-0001.us-south.containers.appdomain.cloud     ["1234abcd-us-south.lb.appdomain.cloud"]      None             created                   <certificate>
        

3. 공개 VPC ALB에 대한 서브도메인을 생성한 경우, 웹 브라우저를 열고 URL 을 입력하여 예시와 같이 www.your-custom-domain.com 과 같은 서브도메인을 통해 앱에 접속할 수 있습니다. 사설 VPC ALB의 하위 도메인을 작성한 경우에는 하위 도메인에 대한 액세스를 테스트하려면 사설 VPC 네트워크에 연결되어 있어야 합니다.

HTTPS를 통해 앱에 액세스하는 데 SSL 인증서를 사용하려면 Kubernetes LoadBalancer 서비스에서 HTTPS 포트를 정의했는지 확인하십시오. curl -v --insecure https://<domain>을 실행하여 HTTPS 포트를 통해 요청이 올바르게 라우팅되는지 확인할 수 있습니다. 서비스에 HTTPS 포트가 열려 있지 않다는 연결 오류가 표시됩니다. 또한 앱을 사용하여 TLS 연결을 종료할 수 있는지 확인하십시오. curl -v https://<domain>을 행하여 앱이 TLS를 올바르게 종료하는지 확인할 수 있습니다. 앱이 TLS 연결을 올바르게 종료하지 않는다는 인증서 오류가 표시됩니다.

프라이빗 VPC ALB에 대한 프라이빗 DNS 레코드 등록

버전에서4.15 또는 나중에 다음 선택적 주석을 사용하여 자체 DNS를 연결할 수 있습니다 instance 맞춤 DNS를 제공하는 zone 프라이빗 VPC ALB를 사용합니다. 이를 위해서는 두 가지 선택적 주석을 모두 설정해야 합니다. 지정되지 않은 경우 DNS A 이 로드 밸런서의 기록 hostname 속성이 공용 DNS 영역에 추가됩니다.lb.appdomain.cloud.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "private-dns-crn"

이 로드 밸런서에 연결할 DNS instance 입니다. 지정된 인스턴스는 IAM 정책에 따라 다른 지역이나 계정에 있을 수 있습니다. 가능한 값: 9 ≤ 길이 ≤ 512

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "dns-zone-id"

이 로드 밸런서에 연결할 DNS zone 입니다. 지정된 영역은 IAM 정책에 따라 다른 지역이나 계정에 있을 수 있습니다. 허용되는 값: 1 ≤ 길이 ≤ 128, 값은 다음 정규 표현식과 일치해야 합니다. ^[1]*[a-z0-9]$

이 기능을 사용하려면 사전 요구 사항으로 다음을 수행해야 합니다.

• 로드 밸런서에 바인딩할 수 있는 DNS 영역 생성
• VPC LB와 서비스 간 인증을 활성화합니다.DNS Services
• 영역의 허용된 네트워크에 클러스터의 VPC를 추가합니다.

자세한 내용은 ‘애플리케이션 로드 밸런서를 IBM Cloud DNS Services 와 통합하기’ 및 ‘DNS 영역에 허용된 네트워크로 VPC 추가하기’ 문서를 참조하십시오.

예:

apiVersion: v1
kind: Service
metadata:
  name: myloadbalancer
  annotations:
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name: "my-load-balancer"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-instance-crn: "crn:v1:bluemix:public:dns-svcs:global:a/bb1b52262f7441a586f49068482f1e60:f761b566-030a-4696-8649-cc9d09889e88::"
    service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-private-dns-zone-id: "d66662cc-aa23-4fe1-9987-858487a61f45"
spec:
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 169.60.115.164
...

클러스터에서 VPC 로드 밸런서 분리

VPC 로드 밸런서는 생성 시 지정한 ‘ Kubernetes ’ LoadBalancer 서비스 정의와 연결됩니다. 클러스터에서 지속적 VPC 로드 밸런서를 분리하려면 VPC 로드 밸런서의 이름을 바꾸거나 원래 LoadBalancer 서비스 정의에서 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name 어노테이션을 제거하여 LoadBalancer 서비스와의 링크를 끊어야 합니다. 클러스터를 삭제 하여 클러스터에서 지속적 VPC 로드 밸런서를 분리할 수도 있습니다.

어노테이션을 제거하면 원래 LoadBalancer 서비스가 원래 클러스터에서 비지속적 VPC 로드 밸런서를 되돌리고 작성합니다. 이 비지속적 VPC 로드 밸런서는 kube-<cluster_ID>-<kubernetes_lb_service_UID> 이름 지정 규칙을 따릅니다.

클러스터에 VPC 로드 밸런서 연결

영구 VPC 로드 밸런서가 클러스터에서 분리된 후에는, 해당 VPC 로드 밸런서를 참조하는 새로운 ‘ Kubernetes ’ LoadBalancer 서비스 정의를 생성하여 다른 클러스터에 연결할 수 있습니다.

새 클러스터에서 새 LoadBalancer 서비스를 작성할 때 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-lb-name 어노테이션을 사용하여 연결할 VPC 로드 밸런서의 이름을 지정할 수 있습니다.

LoadBalancer 서비스를 작성할 때 VPC 로드 밸런서 유형 (ALB, NLB) 및 IP 유형 (public, private) 은 LoadBalancer 서비스의 스펙과 일치해야 합니다. 예를 들어, NLB 유형을 지정하는 새 클러스터의 기존 LoadBalancer 서비스는 클러스터에 VPC ALB를 첨부하는 데 사용할 수 없습니다. 로드 밸런서 유형 및 IP 유형을 지정하는 어노테이션은 각각 service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features 및 service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type 입니다.

LoadBalancer 서비스에 지정된 포트 및 노드 포트는 VPC 로드 밸런서가 작성된 포트 및 노드 포트와 일치할 필요가 없습니다. VPC 로드 밸런서는 새 클러스터에서 연관된 LoadBalancer 서비스의 포트 정의를 사용하여 다시 구성합니다.

VPC 로드 밸런서에 대한 상태 검사 사용자 정의

VPC 로드 밸런서 상태 검사에 대한 추가 제어를 위해 선택적 어노테이션을 사용하여 테스트 간격, 제한시간 및 재시도에 대한 고급 구성으로 상태 검사를 사용자 정의할 수 있습니다. 언제든지 이러한 사용자 정의를 변경하거나 제거할 수 있습니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-protocol

선택사항: 이 어노테이션은 Kubernetes 로드 밸런서 서비스와 연관된 VPC 로드 밸런서 리소스에서 상태 검사 프로토콜을 설정합니다. 일반적으로 VPC LB 상태 검사 프로토콜은 Kubernetes 로드 밸런서 서비스 스펙의 externalTrafficPolicy 설정 값으로 판별됩니다. 이 어노테이션은 해당 로직을 대체합니다. 이 어노테이션은 Kubernetes및 특히 kube-proxy가 externalTrafficPolicy 의 다양한 설정과 관련하여 작동하는 방법을 변경하지 않습니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-port

선택사항. 상태 확인에 사용되는 TCP 포트입니다. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 도 지정된 경우에만 적용됩니다.

• 지정된 TCP 포트가 Kubernetes 노드 포트 범위(30,000~32,767)를 벗어날 경우, 클러스터 워커 노드에 적용된 VPC 보안 그룹을 수정하여 해당 포트에 대한 인바운드 트래픽을 허용해야 합니다.
• 이 어노테이션이 VPC ALB와 연결된 Kubernetes 로드 밸런서 서비스에 적용되는 경우, VPC ALB에 할당된 보안 그룹의 아웃바운드 규칙을 수정하여 지정된 TCP 포트로의 아웃바운드 트래픽을 허용해야 합니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-path

선택사항. HTTP 및 HTTPS 상태 점검에 대한 상태 점검 경로: URL. 이 어노테이션은 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 가 http 또는 https 로 설정된 경우에만 적용됩니다.

• URL 경로는 원본-형식 요청 대상 형식을 따라야 합니다.
• 이 어노테이션이 지정되지 않고 ibm-load-balancer-cloud-provider-vpc-health-check-protocol 어노테이션이 http 또는 https 로 설정되면 기본값 / 가 적용됩니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-delay

선택사항. 상태 검사 시도 사이에 대기하는 시간 (초) 입니다. 기본적으로 이 값은 5 로 설정되며 최소값은 2 이고 최대값은 60 입니다. 이 값은 ibm-load-balancer-cloud-provider-vpc-health-check-timeout 값 (기본적으로 2 로 설정됨) 보다 커야 합니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-timeout

선택사항. 상태 검사에 대한 응답을 기다리는 시간 (초) 입니다. 기본적으로 이 값은 2 로 설정되며 최소값은 1 이고 최대값은 59 입니다. 이 값은 ibm-load-balancer-cloud-provider-vpc-health-check-delay 값보다 작아야 합니다. 이 값은 기본적으로 5 로 설정됩니다.

service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-retries

VPC 로드 밸런서에 대한 최대 상태 검사 재시도 수입니다. 기본적으로 이 값은 2 로 설정되며 최소 1 및 최대 10 를 갖습니다.

UDP 로드 밸런서에 대한 TCP 상태 확인 기능 활성화

UDP 상태 확인 기능이 제공되지 않으므로, TCP 상태 확인 기능을 사용하는 UDP 부하 분산기는 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp 어노테이션과 함께 TCP 포트를 추가로 지정해야 합니다.

클러스터 내에서 실행 중인 다른 로드 밸런서나 NodePort 에 대한 TCP 노드 포트를 지정할 수 있습니다. 그러나 노드 포트가 30000-32767 범위 밖에 있는 경우 지정된 포트에 대한 수신 트래픽을 허용하도록 VPC 클러스터 보안 그룹을 수정 kube-<cluster-ID> 해야 합니다.

지정된 포트 값이 예기치 않게 중단되거나 포트 값이 재구성된 서비스에 해당하는 경우, 해당 서비스가 다시 가동되거나 service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-health-check-udp 어노테이션에 새로운 TCP 포트 값을 재설정할 때까지 TCP 상태 확인 기능이 작동하지 않는다는 점에 유의하십시오. 이를 방지하기 위해 서비스 중단이 발생하지 않는 정적 포트 값인 kubelet 포트 10250 를 지정할 수 있습니다. 그러나 kubelet 포트에서 수신되는 트래픽을 승인하려면 VPC 클러스터 보안 그룹을 수정 kube-<cluster-ID> 해야 합니다.

UDP 로드 밸런서에서 상태 점검을 위해 추가적인 TCP 포트를 지정해야 하는 번거로움을 피하고 싶으신가요? 추가 포트 지정이 필요 없는 HTTP 상태 확인 기능을 사용하려면 externalTrafficPolicy 을 Local 으로 설정하십시오.