외부 부하 분산기 구성

외부 부하 분산기 (ELB)는 더 큰 인스턴스 외부 IP 풀에서 조직에 할당된 풀의 IP 주소에서 조직 외부에서 액세스할 수 있도록 서비스를 노출합니다.

ELB 가상 IP (VIP) 주소는 조직 간에 충돌하지 않으며 모든 조직에서 고유합니다. 따라서 조직 외부의 클라이언트가 액세스해야 하는 서비스에만 ELB 서비스를 사용해야 합니다.

조직 내에서 실행되는 워크로드는 워크로드가 조직을 종료하도록 사용 설정하는 한 ELB 서비스에 액세스할 수 있습니다. 이 트래픽 패턴은 내부 서비스로 돌아가기 전에 조직의 아웃바운드 트래픽을 효과적으로 요구합니다.

공유 및 표준 클러스터에 대한 ELB 설정에는 별도의 안내가 있습니다.

공유 클러스터의 외부 부하 분산기 만들기

전역 또는 영역별 ELB를 만들 수 있습니다. 전역 ELB의 범위는 GDC 환경 전반에 걸쳐 있습니다. 영역 ELB의 범위는 생성 시 지정된 영역으로 제한됩니다. 자세한 내용은 전역 및 영역 부하 분산기를 참조하세요.

시작하기 전에

ELB 서비스를 구성하려면 다음을 수행해야 합니다.

  • 부하 분산기를 구성하는 프로젝트를 소유합니다. 자세한 내용은 프로젝트 만들기를 참조하세요.
  • 이 ELB 서비스로의 트래픽을 허용하는 맞춤설정된 ProjectNetworkPolicy (PNP) 인그레스 정책이 있습니다. 자세한 내용은 ELB로의 트래픽을 허용하도록 PNP 구성을 참조하세요.

  • 필요한 ID 및 액세스 역할이 있어야 합니다.

    • 프로젝트 NetworkPolicy 관리자: 프로젝트 네임스페이스에서 프로젝트 네트워크 정책을 관리할 수 있는 액세스 권한이 있습니다. IAM 조직 관리자에게 프로젝트 NetworkPolicy 관리자 (project-networkpolicy-admin) 역할을 부여해 달라고 요청하세요.
    • 부하 분산기 관리자: IAM 조직 관리자에게 부하 분산기 관리자 (load-balancer-admin) 역할을 부여해 달라고 요청합니다.
    • 전역 부하 분산기 관리자: 전역 ELB의 경우 IAM 조직 관리자에게 전역 부하 분산기 관리자 (global-load-balancer-admin) 역할을 부여해 달라고 요청하세요. 자세한 내용은 사전 정의된 역할 설명을 참조하세요.

ELB로의 트래픽을 허용하도록 PNP 구성

ELB 서비스가 작동하려면 이 ELB 서비스의 워크로드에 대한 트래픽을 허용하도록 자체 맞춤설정된 ProjectNetworkPolicy 인그레스 정책을 구성하고 적용해야 합니다. 네트워크 정책은 부하 분산기 자체가 아닌 워크로드에 대한 액세스를 제어합니다. ELB는 워크로드를 고객 네트워크에 노출하므로 8080과 같은 워크로드 포트에 대한 외부 트래픽을 허용하는 명시적인 네트워크 정책이 필요합니다.

이 ELB의 워크로드에 대한 트래픽을 허용할 외부 CIDR 주소를 지정합니다.

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

다음을 바꿉니다.

  • MANAGEMENT_API_SERVER: Management API 서버의 kubeconfig 경로입니다. 대상 영역의 API 서버에 대한 kubeconfig 파일을 아직 생성하지 않은 경우 자세한 내용은 로그인을 참조하세요.
  • PROJECT: GDC 프로젝트의 이름입니다.
  • CIDR: ELB에 액세스해야 하는 외부 CIDR입니다. 외부 부하 분산기는 소스 외부 IP 주소를 보존하고 반환 경로에서 부하 분산기를 우회하는 직접 서버 반환 (DSR)을 사용하므로 이 정책이 필요합니다. 자세한 내용은 조직 외부 트래픽에 대한 전역 인그레스 방화벽 규칙 만들기를 참조하세요.
  • PORT: 부하 분산기 뒤에 있는 포드의 백엔드 포트입니다. 이 값은 Service 리소스의 매니페스트에 있는 .spec.ports[].targetPort 필드에서 찾을 수 있습니다. 이 필드는 선택사항입니다.

GDC에서 세 가지 방법으로 ELB를 만듭니다.

  • gdcloud CLI를 사용하여 전역 또는 영역 ELB를 만듭니다.
  • 네트워킹 Kubernetes 리소스 모델 (KRM) API를 사용하여 전역 또는 영역 ELB를 만듭니다.
  • Kubernetes 클러스터에서 Kubernetes 서비스를 직접 사용합니다. 이 방법은 영역 ELB에만 사용할 수 있습니다.

KRM API 및 gdcloud CLI를 사용하여 포드 또는 VM 워크로드를 타겟팅할 수 있습니다. Kubernetes 클러스터에서 Kubernetes 서비스를 직접 사용하는 경우 Service 객체가 생성된 클러스터의 워크로드만 타겟팅할 수 있습니다.

영역 ELB 만들기

gdcloud CLI, KRM API 또는 Kubernetes 클러스터의 Kubernetes 서비스를 사용하여 영역 ELB를 만듭니다.

gdcloud

gdcloud CLI를 사용하여 포드 또는 VM 워크로드를 타겟팅하는 ELB를 만듭니다.

이 ELB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다.

gdcloud CLI를 사용하여 ELB를 만들려면 다음 단계를 따르세요.

  1. Backend 리소스를 만들어 ELB의 엔드포인트를 정의합니다.

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster-name=CLUSTER_NAME

    다음을 바꿉니다.

    • BACKEND_NAME: 백엔드 리소스에 대해 선택한 이름입니다(예: my-backend).
    • LABELS: 이 백엔드 리소스에 사용할 포드와 VM 간의 엔드포인트를 정의하는 선택기입니다. 예를 들면 app=web입니다.
    • PROJECT_NAME: 프로젝트의 이름
    • ZONE: 이 호출에 사용할 영역입니다. 영역 플래그가 필요한 모든 명령어에 대해 영역 플래그를 미리 설정하려면 gdcloud config set core/zone ZONE를 실행합니다. 영역 플래그는 멀티 영역 환경에서만 사용할 수 있습니다. 이 필드는 선택사항입니다.
    • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.

  2. 이 ELB가 포드 워크로드용인 경우 이 단계를 건너뜁니다. VM 워크로드에 ELB를 구성하는 경우 ELB의 상태 점검 유형을 정의합니다. 예를 들어 TCP 상태 점검을 만들려면 다음과 같이 정의합니다.

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

    다음을 바꿉니다.

    • HEALTH_CHECK_NAME: 상태 점검 리소스에 대해 선택한 이름입니다(예: my-health-check).
    • CHECK_INTERVAL: 한 프로브의 시작부터 다음 프로브의 시작까지의 시간(단위: 초). 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • HEALTHY_THRESHOLD: 엔드포인트가 정상으로 간주되기 위해 통과해야 하는 순차적 프로브 수입니다. 생략하거나 0으로 설정하면 기본값은 5입니다.
    • TIMEOUT: 실패를 선언하기 전에 대기할 시간(초)입니다. 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • UNHEALTHY_THRESHOLD: 엔드포인트가 비정상으로 간주되도록 하기 위해 실패해야 하는 순차적 프로브의 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.
    • PORT: 상태 점검이 수행되는 포트. 기본값은 80입니다. 이 필드는 선택사항입니다.
    • ZONE: 이 ELB를 만들 영역입니다.

  3. BackendService 리소스를 만들고 이전에 만든 Backend 리소스를 추가합니다.

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: 이 백엔드 서비스에 선택한 이름입니다.
    • TARGET_PORT: 이 백엔드 서비스가 변환하는 대상 포트의 쉼표로 구분된 목록입니다. 여기서 각 대상 포트는 프로토콜, 전달 규칙의 포트, 백엔드 인스턴스의 포트를 지정합니다. 여러 대상 포트를 지정할 수 있습니다. 이 필드는 protocol:port:targetport 형식이어야 합니다(예: TCP:80:8080). 이 필드는 선택사항입니다.
    • HEALTH_CHECK_NAME: 상태 점검 리소스의 이름입니다. 이 필드는 선택사항입니다. VM 워크로드에 ELB를 구성하는 경우에만 이 필드를 포함합니다.

  4. 이전에 만든 Backend 리소스에 BackendService 리소스를 추가합니다.

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. 선택사항: ELB에 세션 어피니티를 사용하여 동일한 클라이언트의 요청이 동일한 백엔드로 일관되게 라우팅되도록 합니다. 부하 분산기에 세션 어피니티를 사용 설정하려면 gdcloud compute load-balancer-policy create 명령어를 사용하여 백엔드 서비스 정책을 만듭니다.

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    다음을 바꿉니다.

    • POLICY_NAME: 백엔드 서비스 정책에 대해 선택한 이름입니다.

    • MODE: 세션 어피니티 모드입니다. 두 가지 모드가 지원됩니다.

      • NONE: 세션 어피니티가 사용 중지됩니다. 요청은 사용 가능한 백엔드로 라우팅됩니다. 이는 기본값입니다.
      • CLIENT_IP_DST_PORT_PROTO: 동일한 4튜플 (소스 IP 주소, 대상 IP 주소, 대상 포트, 프로토콜)의 요청이 동일한 백엔드로 라우팅됩니다.

    • RESOURCE_LABEL: 프로젝트 네임스페이스에서 BackendServicePolicy 리소스가 적용되는 백엔드 서비스를 선택하는 라벨 선택기입니다. 여러 BackendServicePolicy 리소스가 동일한 백엔드 서비스와 일치하고 이러한 정책 중 하나 이상에 세션 어피니티가 사용 설정된 경우 이 BackendService 리소스에 세션 어피니티가 사용 설정됩니다.

  6. 서비스를 사용할 수 있는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: 백엔드 서비스 이름입니다.
    • FORWARDING_RULE_EXTERNAL_NAME: 전달 규칙에 대해 선택한 이름입니다.
    • CIDR: 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 영역 IP 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 영역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 대한 자세한 내용은 커스텀 리소스 예시를 참조하세요.
    • PROTOCOL_PORT: 전달 규칙에 노출할 프로토콜 및 포트입니다. 이 필드는 ip-protocol=TCP:80 형식이어야 합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내부에 노출하는 포트와 동일해야 합니다.

  7. 구성된 ELB를 확인하려면 생성된 각 객체에서 Ready 조건을 확인합니다. 부하 분산기의 할당된 IP 주소를 가져오려면 전달 규칙을 설명합니다.

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

    1. 할당된 VIP를 가져오려면 전달 규칙을 설명합니다.

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. 전달 규칙의 PROTOCOL_PORT 필드에 지정된 포트에서 VIP에 대한 curl 요청으로 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT

      다음을 바꿉니다.

      • FORWARDING_RULE_VIP: 전달 규칙의 VIP입니다.
      • PORT: 전달 규칙에 있는 PROTOCOL_PORT 필드의 포트 번호입니다.

API

KRM API를 사용하여 포드 또는 VM 워크로드를 타겟팅하는 ELB를 만듭니다. 이 ELB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다.

KRM API를 사용하여 영역 ELB를 만들려면 다음 단계를 따르세요.

  1. Backend 리소스를 만들어 ELB의 엔드포인트를 정의합니다. 워크로드가 배치된 각 영역에 대해 Backend 리소스를 만듭니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    다음을 바꿉니다.

    • MANAGEMENT_API_SERVER: 영역 Management API 서버의 kubeconfig 경로입니다. 자세한 내용은 영역 컨텍스트로 전환을 참조하세요.
    • PROJECT_NAME: 프로젝트의 이름
    • BACKEND_NAME: Backend 리소스 이름입니다.
    • CLUSTER_NAME: 이 필드는 선택사항입니다. 이 필드는 정의된 선택기의 범위가 제한되는 클러스터를 지정합니다. 이 필드는 VM 워크로드에 적용되지 않습니다. Backend 리소스에 clusterName 필드가 포함되지 않은 경우 지정된 라벨이 프로젝트의 모든 워크로드에 적용됩니다.

  2. 이 ELB가 포드 워크로드용인 경우 이 단계를 건너뜁니다. VM 워크로드에 ELB를 구성하는 경우 ELB의 상태 점검을 정의합니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    다음을 바꿉니다.

    • HEALTH_CHECK_NAME: 상태 점검 리소스에 대해 선택한 이름입니다(예: my-health-check).
    • PORT: 상태 점검이 수행되는 포트. 기본값은 80입니다.
    • TIMEOUT: 실패를 선언하기 전에 대기할 시간(초)입니다. 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • CHECK_INTERVAL: 한 프로브의 시작부터 다음 프로브의 시작까지의 시간(단위: 초). 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • HEALTHY_THRESHOLD: 엔드포인트가 정상으로 간주되기 위해 통과해야 하는 순차적 프로브 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.
    • UNHEALTHY_THRESHOLD: 엔드포인트가 비정상으로 간주되도록 하기 위해 실패해야 하는 순차적 프로브의 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.

  3. 이전에 만든 Backend 리소스를 사용하여 BackendService 객체를 만듭니다. VM 워크로드에 ELB를 구성하는 경우 HealthCheck 리소스를 포함합니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: BackendService 리소스에 대해 선택한 이름입니다.
    • HEALTH_CHECK_NAME: 이전에 만든 HealthCheck 리소스의 이름입니다. 포드 워크로드에 ELB를 구성하는 경우 이 필드를 포함하지 마세요.

  4. 선택사항: ELB에 세션 어피니티를 사용하여 동일한 클라이언트의 요청이 동일한 백엔드로 일관되게 라우팅되도록 합니다. 부하 분산기에 세션 어피니티를 사용 설정하려면 BackendServicePolicy 리소스를 만듭니다. 이 리소스는 세션 어피니티 설정을 정의하고 BackendServicePolicy 리소스를 BackendService 리소스에 적용합니다. BackendServicePolicy 리소스를 만들고 적용합니다.

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    다음을 바꿉니다.

    • POLICY_NAME: 백엔드 서비스 정책에 대해 선택한 이름입니다.

    • MODE: 세션 어피니티 모드입니다. 두 가지 모드가 지원됩니다.

      • NONE: 세션 어피니티가 사용 중지됩니다. 요청은 사용 가능한 백엔드로 라우팅됩니다. 이는 기본값입니다.
      • CLIENT_IP_DST_PORT_PROTO: 동일한 4튜플 (소스 IP 주소, 대상 IP 주소, 대상 포트, 프로토콜)의 요청이 동일한 백엔드로 라우팅됩니다.

    • RESOURCE_LABEL: 프로젝트 네임스페이스에서 BackendServicePolicy 리소스가 적용되는 백엔드 서비스를 선택하는 라벨 선택기입니다. 여러 BackendServicePolicy 리소스가 동일한 백엔드 서비스와 일치하고 이러한 정책 중 하나 이상에 세션 어피니티가 사용 설정된 경우 이 BackendService 리소스에 세션 어피니티가 사용 설정됩니다.

  5. 서비스를 사용할 수 있는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: BackendService 리소스 이름입니다.
    • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal 리소스에 대해 선택한 이름입니다.
    • CIDR_NAME: cidrRef 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 영역 IP 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 영역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 대한 자세한 내용은 커스텀 리소스 예시를 참조하세요.
    • PORT: ports 필드를 사용하여 이 전달 규칙으로 구성된 백엔드로 패킷이 전달되는 L4 포트 배열을 지정합니다. 포트를 하나 이상 지정해야 합니다. port 필드를 사용하여 포트 번호를 지정합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내부에 노출하는 포트와 동일해야 합니다.

    • PROTOCOL: 전달 규칙에 사용할 프로토콜입니다(예: TCP). ports 배열의 항목은 다음과 같이 표시됩니다.

      ports:
- port: 80
  protocol: TCP

  6. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

    1. VIP를 가져오려면 kubectl get를 사용합니다.

      kubectl get forwardingruleexternal -n PROJECT_NAME

      출력은 다음과 같이 표시됩니다.

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 전달 규칙의 PORT 필드에 지정된 포트에서 VIP에 대한 curl 요청으로 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP을 전달 규칙의 VIP로 바꿉니다.

Kubernetes 서비스

Kubernetes 클러스터에서 LoadBalancer 유형의 Kubernetes Service를 만들어 GDC에서 ELB를 만들 수 있습니다.

ELB 서비스를 만들려면 다음을 수행합니다.

  1. LoadBalancer 유형의 Service 정의에 대한 YAML 파일을 만듭니다.

    다음 Service 객체는 ELB 서비스의 예시입니다.

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1235
    protocol: TCP
    targetPort: 1235
  selector:
    k8s-app: my-app
  type: LoadBalancer

    다음을 바꿉니다.

    • ELB_SERVICE_NAME: ELB 서비스의 이름입니다.
    • PROJECT_NAME: 백엔드 워크로드가 포함된 프로젝트의 네임스페이스입니다.

    port 필드는 VIP 주소에 노출하는 프런트엔드 포트를 구성합니다. targetPort 필드는 백엔드 워크로드에서 트래픽을 전달할 백엔드 포트를 구성합니다. 부하 분산기는 네트워크 주소 변환 (NAT)을 지원합니다. 프런트엔드 및 백엔드 포트는 다를 수 있습니다.

  2. Service 정의의 selector 필드에서 포드 또는 가상 머신을 백엔드 워크로드로 지정합니다.

    선택기는 지정한 라벨을 워크로드의 라벨과 일치시켜 이 서비스의 백엔드 워크로드로 사용할 워크로드를 정의합니다. Service는 Service를 정의하는 동일한 프로젝트 및 동일한 클러스터에서만 백엔드 워크로드를 선택할 수 있습니다.

    서비스 선택에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/service/를 참조하세요.

  3. 백엔드 워크로드와 동일한 프로젝트에 Service 정의 파일을 저장합니다.

  4. Service 정의 파일을 클러스터에 적용합니다.

    kubectl apply -f ELB_FILE

    ELB_FILE을 ELB 서비스의 Service 정의 파일 이름으로 바꿉니다.

    ELB를 만들면 서비스에 IP 주소 2개가 할당됩니다. 하나는 동일한 클러스터 내에서만 액세스할 수 있는 내부 IP 주소입니다. 다른 하나는 조직 내부 및 외부에서 액세스할 수 있는 외부 IP 주소입니다. 서비스 상태를 확인하여 ELB 서비스의 IP 주소를 가져올 수 있습니다.

    kubectl -n PROJECT_NAME get svc ELB_SERVICE_NAME

    다음을 바꿉니다.

    • PROJECT_NAME: 백엔드 워크로드가 포함된 프로젝트의 네임스페이스입니다.
    • ELB_SERVICE_NAME: ELB 서비스의 이름입니다.

    다음 예시와 비슷한 출력이 표시됩니다.

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      20.12.1.11      1235:31931/TCP   22h

    EXTERNAL-IP는 조직 외부에서 액세스할 수 있는 서비스의 IP 주소입니다.

    출력이 표시되지 않으면 ELB 서비스를 성공적으로 만들었는지 확인합니다.

전역 ELB 만들기

gdcloud CLI 또는 KRM API를 사용하여 전역 ELB를 만듭니다.

gdcloud

gdcloud CLI를 사용하여 포드 또는 VM 워크로드를 타겟팅하는 ELB를 만듭니다.

이 ELB는 Backend 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다. Backend 커스텀 리소스의 범위는 영역으로 지정되어야 합니다.

gdcloud CLI를 사용하여 ELB를 만들려면 다음 단계를 따르세요.

  1. Backend 리소스를 만들어 ELB의 엔드포인트를 정의합니다.

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster-name=CLUSTER_NAME \
  --zone=ZONE

    다음을 바꿉니다.

    • BACKEND_NAME: 백엔드 리소스에 대해 선택한 이름입니다(예: my-backend).
    • LABELS: 이 백엔드 리소스에 사용할 포드와 VM 간의 엔드포인트를 정의하는 선택기입니다. 예를 들면 app=web입니다.
    • PROJECT_NAME: 프로젝트의 이름
    • CLUSTER_NAME: 정의된 선택기의 범위가 제한되는 클러스터입니다. 이 필드를 지정하지 않으면 지정된 라벨이 있는 모든 엔드포인트가 선택됩니다. 이 필드는 선택사항입니다.
    • ZONE: 이 호출에 사용할 영역입니다. 영역 플래그가 필요한 모든 명령어에 영역 플래그를 미리 설정하려면 gdcloud config set core/zone ZONE를 실행합니다. 영역 플래그는 멀티 영역 환경에서만 사용할 수 있습니다. 이 필드는 선택사항입니다.

  2. 이 ELB가 포드 워크로드용인 경우 이 단계를 건너뜁니다. VM 워크로드에 ELB를 구성하는 경우 ELB의 상태 점검을 정의합니다.

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    다음을 바꿉니다.

    • HEALTH_CHECK_NAME: 상태 점검 리소스에 대해 선택한 이름입니다(예: my-health-check).
    • CHECK_INTERVAL: 한 프로브의 시작부터 다음 프로브의 시작까지의 시간(단위: 초). 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • HEALTHY_THRESHOLD: 실패를 선언하기 전에 대기하는 시간입니다. 생략하거나 0으로 설정하면 기본값은 5입니다.
    • TIMEOUT: 실패를 선언하기 전에 대기할 시간(초)입니다. 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • UNHEALTHY_THRESHOLD: 엔드포인트가 비정상으로 간주되도록 하기 위해 실패해야 하는 순차적 프로브의 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.
    • PORT: 상태 점검이 수행되는 포트. 기본값은 80입니다. 이 필드는 선택사항입니다.

  3. BackendService 리소스를 만들고 이전에 만든 Backend 리소스를 추가합니다.

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: 이 백엔드 서비스에 선택한 이름입니다.
    • TARGET_PORTS: 이 백엔드 서비스가 변환하는 대상 포트의 쉼표로 구분된 목록입니다. 여기서 각 대상 포트는 프로토콜, 전달 규칙의 포트, 백엔드 인스턴스의 포트를 지정합니다. 여러 대상 포트를 지정할 수 있습니다. 이 필드는 protocol:port:targetport 형식이어야 합니다(예: TCP:80:8080). 이 필드는 선택사항입니다.
    • HEALTH_CHECK_NAME: 상태 점검 리소스의 이름입니다. 이 필드는 선택사항입니다. VM 워크로드에 ELB를 구성하는 경우에만 이 필드를 포함합니다.

  4. 이전에 만든 Backend 리소스에 BackendService 리소스를 추가합니다.

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT_NAME \
  --global

  5. 선택사항: ELB에 세션 어피니티를 사용하여 동일한 클라이언트의 요청이 동일한 백엔드로 일관되게 라우팅되도록 합니다. 부하 분산기에 세션 어피니티를 사용 설정하려면 gdcloud compute load-balancer-policy create 명령어를 사용하여 백엔드 서비스 정책을 만듭니다.

     gdcloud compute load-balancer-policy create POLICY_NAME
 --session-affinity=MODE
 --selectors=RESOURCE_LABEL

    다음을 바꿉니다.

    • POLICY_NAME: 백엔드 서비스 정책에 대해 선택한 이름입니다.

    • MODE: 세션 어피니티 모드입니다. 두 가지 모드가 지원됩니다.

      • NONE: 세션 어피니티가 사용 중지됩니다. 요청은 사용 가능한 백엔드로 라우팅됩니다. 이는 기본값입니다.
      • CLIENT_IP_DST_PORT_PROTO: 동일한 4튜플 (소스 IP 주소, 대상 IP 주소, 대상 포트, 프로토콜)의 요청이 동일한 백엔드로 라우팅됩니다.

    • RESOURCE_LABEL: 프로젝트 네임스페이스에서 BackendServicePolicy 리소스가 적용되는 백엔드 서비스를 선택하는 라벨 선택기입니다. 여러 BackendServicePolicy 리소스가 동일한 백엔드 서비스와 일치하고 이러한 정책 중 하나 이상에 세션 어피니티가 사용 설정된 경우 이 BackendService 리소스에 세션 어피니티가 사용 설정됩니다.

  6. 서비스를 사용할 수 있는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT_NAME \
  --global

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: 백엔드 서비스 이름입니다.
    • FORWARDING_RULE_EXTERNAL_NAME: 전달 규칙에 대해 선택한 이름입니다.
    • CIDR: 이 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 대한 자세한 내용은 커스텀 리소스 예시를 참조하세요.
    • PROTOCOL_PORT: 전달 규칙에 노출할 프로토콜 및 포트입니다. 이 필드는 ip-protocol=TCP:80 형식이어야 합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내부에 노출하는 포트와 동일해야 합니다.

  7. 구성된 ELB를 확인하려면 생성된 각 객체에서 Ready 조건을 확인합니다. 부하 분산기의 할당된 IP 주소를 가져오려면 전달 규칙을 설명합니다.

    gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

  8. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

    1. 할당된 VIP를 가져오려면 전달 규칙을 설명합니다.

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME --global

    2. 전달 규칙의 PROTOCOL_PORT 필드에 지정된 포트에서 VIP에 대한 curl 요청으로 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT

      다음을 바꿉니다.

      • FORWARDING_RULE_VIP: 전달 규칙의 VIP입니다.
      • PORT: 전달 규칙의 PROTOCOL_PORT 필드에 있는 포트 번호입니다.

API

KRM API를 사용하여 포드 또는 VM 워크로드를 타겟팅하는 ELB를 만듭니다. 이 ELB는 백엔드 객체에 정의된 라벨과 일치하는 프로젝트의 모든 워크로드를 타겟팅합니다. KRM API를 사용하여 영역 ELB를 만들려면 다음 단계를 따르세요.

  1. Backend 리소스를 만들어 ELB의 엔드포인트를 정의합니다. 워크로드가 배치된 각 영역에 대해 Backend 리소스를 만듭니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    다음을 바꿉니다.

    • MANAGEMENT_API_SERVER: 전역 Management API 서버의 kubeconfig 경로입니다. 자세한 내용은 전역 컨텍스트로 전환을 참조하세요.
    • PROJECT_NAME: 프로젝트의 이름
    • BACKEND_NAME: Backend 리소스 이름입니다.
    • CLUSTER_NAME: 이 필드는 선택사항입니다. 이 필드는 정의된 선택기의 범위가 제한되는 클러스터를 지정합니다. 이 필드는 VM 워크로드에 적용되지 않습니다. Backend 리소스에 clusterName 필드가 포함되지 않은 경우 지정된 라벨이 프로젝트의 모든 워크로드에 적용됩니다.

  2. 이 ELB가 포드 워크로드용인 경우 이 단계를 건너뜁니다. VM 워크로드에 ELB를 구성하는 경우 ELB의 상태 점검을 정의합니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    다음을 바꿉니다.

    • HEALTH_CHECK_NAME: 상태 점검 리소스에 대해 선택한 이름입니다(예: my-health-check).
    • PORT: 상태 점검이 수행되는 포트. 기본값은 80입니다.
    • TIMEOUT: 실패를 선언하기 전에 대기할 시간(초)입니다. 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • CHECK_INTERVAL: 한 프로브의 시작부터 다음 프로브의 시작까지의 시간(단위: 초). 생략하거나 0으로 설정하면 기본값은 5입니다. 제한 시간을 checkInterval보다 길게 설정하지 않는 것이 좋습니다.
    • HEALTHY_THRESHOLD: 엔드포인트가 정상으로 간주되기 위해 통과해야 하는 순차적 프로브 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.
    • UNHEALTHY_THRESHOLD: 엔드포인트가 비정상으로 간주되도록 하기 위해 실패해야 하는 순차적 프로브의 수입니다. 생략하거나 0으로 설정하면 기본값은 2입니다.

    전역 ELB이므로 전역 API에서 상태 점검을 만듭니다.

  3. 이전에 만든 Backend 리소스를 사용하여 BackendService 객체를 만듭니다. VM 워크로드에 ELB를 구성하는 경우 HealthCheck 리소스를 포함합니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    다음을 바꿉니다.

    • BACKEND_SERVICE_NAME: BackendService 리소스에 대해 선택한 이름입니다.
    • HEALTH_CHECK_NAME: 이전에 만든 HealthCheck 리소스의 이름입니다. 포드 워크로드에 ELB를 구성하는 경우 이 필드를 포함하지 마세요.

    • ZONE: Backend 리소스가 생성되는 영역입니다. backendRefs 필드에 여러 백엔드를 지정할 수 있습니다. 예를 들면 다음과 같습니다.

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • targetPorts 필드는 선택사항입니다. 이 리소스는 이 BackendService 리소스가 변환하는 포트를 나열합니다. 이 객체를 사용하는 경우 다음에 대한 값을 제공합니다.

      • PORT: 서비스에서 노출하는 포트입니다.
      • PROTOCOL: 트래픽이 일치해야 하는 레이어 4 프로토콜입니다. TCP 및 UDP만 지원됩니다.

      • TARGET_PORT: PORT 값이 변환되는 포트입니다(예: 8080). TARGET_PORT 값은 지정된 객체에서 반복될 수 없습니다. targetPorts의 예시는 다음과 같습니다.

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. 선택사항: ELB에 세션 어피니티를 사용하여 동일한 클라이언트의 요청이 동일한 백엔드로 일관되게 라우팅되도록 합니다. 부하 분산기에 세션 어피니티를 사용 설정하려면 BackendServicePolicy 리소스를 만듭니다. 이 리소스는 세션 어피니티 설정을 정의하고 BackendServicePolicy 리소스를 BackendService 리소스에 적용합니다. BackendServicePolicy 리소스를 만들고 적용합니다.

     kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
 apiVersion: networking.global.gdc.goog/v1
 kind: BackendServicePolicy
 metadata:
     namespace: PROJECT_NAME
     name: POLICY_NAME
 spec:
     sessionAffinity: MODE
     selector:
         matchLabels:
           RESOURCE_LABEL

    다음을 바꿉니다.

    • POLICY_NAME: 백엔드 서비스 정책에 대해 선택한 이름입니다.

    • MODE: 세션 어피니티 모드입니다. 두 가지 모드가 지원됩니다.

      • NONE: 세션 어피니티가 사용 중지됩니다. 요청은 사용 가능한 백엔드로 라우팅됩니다. 이는 기본값입니다.
      • CLIENT_IP_DST_PORT_PROTO: 동일한 4튜플 (소스 IP 주소, 대상 IP 주소, 대상 포트, 프로토콜)의 요청이 동일한 백엔드로 라우팅됩니다.

    • RESOURCE_LABEL: 프로젝트 네임스페이스에서 BackendServicePolicy 리소스가 적용되는 백엔드 서비스를 선택하는 라벨 선택기입니다. 여러 BackendServicePolicy 리소스가 동일한 백엔드 서비스와 일치하고 이러한 정책 중 하나 이상에 세션 어피니티가 사용 설정된 경우 이 BackendService 리소스에 세션 어피니티가 사용 설정됩니다.

  5. 서비스를 사용할 수 있는 VIP를 정의하는 외부 ForwardingRule 리소스를 만듭니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT_NAME
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef:
    name: CIDR_NAME
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    다음을 바꿉니다.

    • FORWARDING_RULE_EXTERNAL_NAME: ForwardingRuleExternal 리소스에 대해 선택한 이름입니다.
    • CIDR_NAME: cidrRef 필드는 선택사항입니다. 지정하지 않으면 IPv4/32 CIDR이 전역 IP 풀에서 자동으로 예약됩니다. 이 전달 규칙과 동일한 네임스페이스에 있는 Subnet 리소스의 이름을 지정합니다. Subnet 리소스는 전역 서브넷의 요청 및 할당 정보를 나타냅니다. Subnet 리소스에 대한 자세한 내용은 커스텀 리소스 예시를 참조하세요.
    • PORT: ports 필드를 사용하여 이 전달 규칙으로 구성된 백엔드로 패킷이 전달되는 L4 포트 배열을 지정합니다. 포트를 하나 이상 지정해야 합니다. port 필드를 사용하여 포트 번호를 지정합니다. 노출된 포트는 실제 애플리케이션이 컨테이너 내부에 노출하는 포트와 동일해야 합니다.

    • PROTOCOL: 전달 규칙에 사용할 프로토콜입니다(예: TCP). ports 배열의 항목은 다음과 같이 표시됩니다.

      ports:
- port: 80
  protocol: TCP

  6. 구성된 ELB를 검증하려면 생성된 각 객체에서 Ready 조건을 확인합니다. VIP에 대한 curl 요청으로 트래픽을 확인합니다.

    1. VIP를 가져오려면 kubectl get를 사용합니다.

      kubectl get forwardingruleexternal -n PROJECT_NAME

      출력은 다음과 같이 표시됩니다.

      NAME           BACKENDSERVICE                               CIDR              READY
elb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. 전달 규칙의 PORT 필드에 지정된 포트에서 VIP에 대한 curl 요청으로 트래픽을 확인합니다.

      curl http://FORWARDING_RULE_VIP:PORT

      FORWARDING_RULE_VIP을 전달 규칙의 VIP로 바꿉니다.

표준 클러스터용 외부 부하 분산기 만들기

애플리케이션 소유자 (AO)는 LoadBalancer 유형의 Kubernetes 서비스를 만들어 서비스를 외부에 노출할 수 있습니다. 이 서비스는 서비스가 생성된 표준 클러스터 내의 백엔드만 선택할 수 있습니다. 이는 영역 클러스터 범위 ELB와 동일합니다. 표준 클러스터에는 전역 ELB가 지원되지 않습니다. 자세한 내용은 전역 및 영역 부하 분산기를 참조하세요.

시작하기 전에

ELB 서비스를 구성하려면 다음을 수행해야 합니다.

  • 부하 분산기를 구성하는 프로젝트를 소유합니다. 자세한 내용은 프로젝트 만들기를 참조하세요.
  • 이 ELB 서비스로의 트래픽을 허용하는 맞춤설정된 ProjectNetworkPolicy (PNP) 인그레스 정책이 있습니다. 자세한 내용은 표준 클러스터의 ELB에 대한 트래픽을 허용하도록 PNP 구성을 참고하세요.

  • 필요한 ID 및 액세스 역할이 있어야 합니다.

    • 프로젝트 NetworkPolicy 관리자: 프로젝트 네임스페이스에서 프로젝트 네트워크 정책을 관리할 수 있는 액세스 권한이 있습니다. IAM 조직 관리자에게 프로젝트 NetworkPolicy 관리자 (project-networkpolicy-admin) 역할을 부여해 달라고 요청하세요.
    • 부하 분산기 관리자: IAM 조직 관리자에게 부하 분산기 관리자 (load-balancer-admin) 역할을 부여해 달라고 요청합니다.

Standard 클러스터의 ELB로 트래픽을 허용하도록 PNP 구성

ELB 서비스가 작동하려면 이 ELB 서비스의 워크로드에 대한 트래픽을 허용하도록 자체 맞춤설정된 ProjectNetworkPolicy 인그레스 정책을 구성하고 적용해야 합니다. 네트워크 정책은 부하 분산기 자체가 아닌 워크로드에 대한 액세스를 제어합니다. ELB는 워크로드를 고객 네트워크에 노출하므로 8080과 같은 워크로드 포트에 대한 외부 트래픽을 허용하는 명시적인 네트워크 정책이 필요합니다.

다음 프로젝트 네트워크 정책 YAML 파일 예시에서는 다른 프로젝트의 워크로드에서 ELB를 통해 현재 프로젝트의 워크로드에 액세스하도록 허용합니다.

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ingress-from-client-to-server
  namespace: ${VANILLA_CLUSTER_PROJECT}
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        clusters:
          matchLabels:
            kubernetes.io/metadata.name: my-sc-1
        namespaces:
          matchLabels:
            kubernetes.io/metadata.name: my-app-ns
        workloads:
          matchLabels:
            app: my-internal-app
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - "$PROJECT_2"
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: my-client
    ports:
    - protocol: TCP
      port: 8080

표준 클러스터용 영역 ELB 만들기

표준 Kubernetes 클러스터에서 LoadBalancer 유형의 Kubernetes Service를 만들어 GDC에서 ELB를 만들 수 있습니다.

ELB 서비스를 만들려면 다음을 수행합니다.

  1. LoadBalancer 유형의 Service 정의에 대한 YAML 파일을 만듭니다.

    다음 Service 객체는 ELB 서비스의 예시입니다.

    apiVersion: v1
kind: Service
metadata:
  name: ELB_SERVICE_NAME
  namespace: ELB_SERVICE_NAMESPACE
spec:
  ports:
  - port: PORT
    protocol: TCP
    targetPort: TARGET_PORT
  selector:
    k8s-app: my-app # Example selector, replace with your workload's labels
  type: LoadBalancer

    다음을 바꿉니다.

    • ELB_SERVICE_NAME: ELB 서비스의 이름입니다.
    • ELB_SERVICE_NAMESPACE: 백엔드 워크로드가 포함된 표준 클러스터의 네임스페이스입니다.
    • PORT: Kubernetes 서비스 자체에서 노출하는 포트입니다. 클러스터 내의 다른 서비스 또는 외부 클라이언트는 서비스 IP 주소의 이 포트에 연결됩니다.
    • TARGET_PORT: 애플리케이션이 활성 상태로 실행되고 수신 연결을 리슨하는 포드 컨테이너 내부의 포트입니다. 이는 포드의 컨테이너 사양에 정의된 숫자 포트 또는 이름이 지정된 포트일 수 있습니다.

    port 필드는 VIP 주소에 노출하는 프런트엔드 포트를 구성합니다. targetPort 필드는 백엔드 워크로드에서 트래픽을 전달할 백엔드 포트를 구성합니다. 부하 분산기는 네트워크 주소 변환 (NAT)을 지원합니다. 프런트엔드 및 백엔드 포트는 다를 수 있습니다.

  2. Service 정의의 selector 필드에서 백엔드 워크로드와 일치하는 키-값 쌍을 지정합니다. 표준 클러스터의 경우 포드만 워크로드로 지원됩니다.

    선택기를 사용하여 워크로드에 적용할 수 있습니다. Service는 Service를 정의하는 동일한 프로젝트 및 동일한 클러스터에서만 백엔드 워크로드를 선택할 수 있습니다.

    서비스 선택에 대한 자세한 내용은 https://kubernetes.io/docs/concepts/services-networking/service/를 참조하세요.

  3. Service 사양을 YAML 파일에 저장합니다. 다음 명령어에서 파일 이름을 ELB_FILE로 바꿉니다.

  4. Service 정의 파일을 클러스터에 적용합니다.

    export KUBECONFIG=KUBECONFIG_PATH
kubectl apply -f ELB_FILE

    다음을 바꿉니다.

    • ELB_FILE:ELB 서비스의 Service 정의 파일 이름입니다.
    • KUBECONFIG_PATH: 표준 클러스터의 kubeconfig 파일 경로입니다.

    서비스 상태를 확인하여 ELB 서비스의 IP 주소를 가져올 수 있습니다.

    kubectl -n ELB_SERVICE_NAMESPACE get svc ELB_SERVICE_NAME

    다음을 바꿉니다.

    • ELB_SERVICE_NAMESPACE: 백엔드 워크로드가 포함된 네임스페이스입니다.
    • ELB_SERVICE_NAME: ELB 서비스의 이름입니다.

    다음 예시와 비슷한 출력이 표시됩니다.

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
elb-service             LoadBalancer   10.0.0.1      203.0.1.11      1235:31931/TCP   22h

    EXTERNAL-IP는 조직 외부에서 액세스할 수 있는 서비스의 IP 주소입니다.

부하 분산기의 백엔드로 VM 선택

VM을 부하 분산기에 연결하려면 다음 안내를 따르세요.

  1. VM에 부하 분산기 구성에 사용된 라벨 선택기와 일치하는 라벨이 있는지 확인합니다.

    예를 들어 VM에 적절한 라벨이 없는 경우 해당 영역의 백엔드 객체에서 VM에 지정된 라벨을 추가할 수 있습니다.

    kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL

    다음을 바꿉니다.

    • LABEL: 부하 분산기 구성의 LabelSelector과 일치하는 라벨(예: app=server)입니다.
    • VM_NAME: 연결 중인 가상 머신의 이름입니다.
    • PROJECT_NAME: 프로젝트의 이름

  2. 서버가 HealthCheck 객체에 지정된 것과 동일한 포트에서 리슨하는지 확인합니다.