로드 밸런싱을 구성하려면 Kubernetes LoadBalancer 서비스 또는 수신 리소스와 NCP 복제 컨트롤러를 구성해야 합니다.

LoadBalancer 유형의 Kubernetes 서비스를 구성하여 계층 4 로드 밸런서를 생성하고, Kubernetes 수신 리소스를 구성하여 계층 7 로드 밸런서를 생성할 수 있습니다.

NCP에서 로드 밸런싱을 구성하려면 ncp-rc.yml 파일에서 다음을 수행합니다.

  1. use_native_loadbalancer = True로 설정합니다.
  2. (선택 사항) pool_algorithmROUND_ROBIN 또는 LEAST_CONNECTION/IP_HASH로 설정합니다. 기본값은 ROUND_ROBIN입니다.
  3. (선택 사항) service_size = SMALL, MEDIUM 또는 LARGE로 설정합니다. 기본값은 SMALL입니다.

LEAST_CONNECTION/IP_HASH 알고리즘은 동일한 소스 IP 주소의 트래픽을 동일한 백엔드 포드로 전송합니다.

다른 크기의 NSX-T 로드 밸런서가 지원하는 항목에 대한 자세한 내용은 "NSX-T Data Center 관리 가이드" 를 참조하십시오.

로드 밸런서가 생성된 후 로드 밸런서 크기는 구성 파일을 업데이트하여 변경할 수 없습니다. 대신 NSX Manager UI 또는 API를 통해 변경할 수 있습니다.

계층 4 및 계층 7 로드 밸런싱의 지속성 설정

NCP ConfigMap에서 l4_persistencel7_persistence 매개 변수를 사용하여 지속성 설정을 지정할 수 있습니다. 계층 4 지속성에 대해서는 소스 IP를 옵션으로 사용할 수 있습니다. 계층 7 지속성에 대해서는 쿠키 및 소스 IP를 옵션으로 사용할 수 있습니다. 기본값은 <None>입니다. 예를 들면 다음과 같습니다.
   # Choice of persistence type for ingress traffic through L7 Loadbalancer.
   # Accepted values:
   # 'cookie'
   # 'source_ip'
   l7_persistence = cookie

   # Choice of persistence type for ingress traffic through L4 Loadbalancer.
   # Accepted values:
   # 'source_ip'
   l4_persistence = source_ip

Kubernetes LoadBalancer 서비스의 경우 글로벌 계층 4 지속성이 꺼져 있는 경우(l4_persistence<None>으로 설정되어 있음) 서비스 규격에서 sessionAffinity를 지정하여 서비스의 지속성 동작을 구성할 수 있습니다. l4_persistencesource_ip로 설정한 경우 서비스 규격의 sessionAffinity를 사용하여 서비스에 대한 지속성 시간 초과를 사용자 지정할 수 있습니다. 기본 계층 4 지속성 시간 초과는 10800초입니다(서비스에 대한 Kubernetes 설명서 https://kubernetes.io/docs/concepts/services-networking/service에 지정된 것과 동일). 기본 지속성 시간 초과가 지정된 모든 서비스는 동일한 NSX-T 로드 밸런서 지속성 프로파일을 공유합니다. 기본값이 아닌 지속성 시간 초과가 지정된 각 서비스에 대해 전용 프로파일이 생성됩니다.

참고: 수신의 백엔드 서비스가 LoadBalancer 유형의 서비스인 경우 해당 서비스에 대한 계층 4 가상 서버와 수신에 대한 계층 7 가상 서버에 서로 다른 지속성 설정(예: 계층 4에 대해 source_ip, 계층 7에 대해 cookie)을 지정할 수 없습니다. 이러한 시나리오에서는 두 가상 서버에 대한 지속성 설정이 동일하거나( source_ip, cookie 또는 None) 그 중 하나가 None여야 합니다(이 경우 기타 설정은 source_ip 또는 cookie일 수 있음). 이러한 시나리오의 예는 다음과 같습니다.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80
-----
apiVersion: v1
kind: Service
metadata:
  name: tea-svc <==== same as the Ingress backend above
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: tcp
  selector:
    app: tea
  type: LoadBalancer

수신

  • NSX-T Data Center는 TLS 규격을 사용하는 수신에 대해 하나의 계층 7 로드 밸런서를 생성하고 TLS 규격을 사용하지 않는 수신에 대해 하나의 계층 7 로드 밸런서를 생성합니다.
  • 모든 수신에는 단일 IP 주소가 할당됩니다.
  • 수신 리소스에는 ncp.ini[nsx_v3] 섹션에 있는 external_ip_pools 옵션에서 지정한 외부 IP 풀의 IP 주소가 할당됩니다. 로드 밸런서는 이 IP 주소와 HTTP 및 HTTPS 포트(80 및 443)를 사용합니다.
  • 수신 리소스에는 ncp.ini[nsx_v3] 섹션에 있는 external_ip_pools_lb 옵션에서 지정한 외부 IP 풀의 IP 주소가 할당됩니다. external_ip_pools_lb 옵션이 없는 경우 external_ip_pools에서 지정한 풀이 사용됩니다. 로드 밸런서는 이 IP 주소와 HTTP 및 HTTPS 포트(80 및 443)를 사용합니다.
  • 구성을 변경하고 NCP를 다시 시작하여 다른 IP 풀로 변경할 수 있습니다.
  • TLS에 대해 기본 인증서를 지정할 수 있습니다. 인증서를 생성하고 NCP 포드에 마운트하는 데 대한 내용은 아래를 참조하십시오.
  • TLS 규격을 사용하지 않는 수신은 HTTP 가상 서버(포트 80)에서 호스팅됩니다.
  • TLS 규격을 사용하는 수신은 HTTPS 가상 서버(포트 443)에서 호스팅됩니다. 로드 밸런서는 SSL 서버 역할을 하며 클라이언트 SSL 연결을 종료합니다.
  • 암호 및 수신의 생성 순서는 중요하지 않습니다. 암호 개체가 존재하고 이를 참조하는 수신이 있으면 NSX-T Data Center가 인증서를 가져옵니다. 암호가 삭제되거나 암호를 참조하는 마지막 수신이 삭제되면 암호에 해당하는 인증서가 삭제됩니다.
  • TLS 섹션을 추가하거나 제거하여 수신을 수정하는 작업이 지원됩니다. 수신 규격에서 tls 키가 제거되면 HTTPS 가상 서버(포트 443)에서 HTTP 가상 서버(포트 80)로 수신 규칙이 전송됩니다. 마찬가지로 수신 규격에 tls 키가 추가되면 HTTP 가상 서버(포트 80)에서 HTTPS 가상 서버(포트 443)로 수신 규칙이 전송됩니다.
  • 단일 클러스터에 대한 수신 정의에 중복된 규칙이 있는 경우 첫 번째 규칙만 적용됩니다.
  • 각 클러스터당 기본 백엔드가 있는 하나의 수신만 지원됩니다. 수신 규칙과 일치하지 않는 트래픽은 기본 백엔드로 전달됩니다.
  • 기본 백엔드가 있는 수신이 여러 개인 경우 첫 번째 수신만 구성됩니다. 다른 수신에는 오류 주석이 추가됩니다.
  • 와일드카드 URI 일치가 정규식 문자 “.”를 사용하여 지원됩니다. 및 “*”을 사용하여 지원됩니다. 예를 들어, 경로 “/coffee/.*”는 "/coffee/" 뒤에 0 또는 하나 이상의 문자가 나오는 경우와 일치합니다. 예를 들어 “/coffee/”, “/coffee/a”, “/coffee/b”와는 일치하지만 “/coffee”, “/coffeecup” 또는”/coffeecup/a”와는 일치하지 않습니다.
    수신 규격 예:
    kind: Ingress
    metadata:
      name: cafe-ingress
    spec:
      rules:
      - http:
          paths:
          - path: /coffee/.*    #Matches /coffee/, /coffee/a but NOT /coffee, /coffeecup, etc.
            backend:
              serviceName: coffee-svc
              servicePort: 80
  • 수신 리소스에 주석을 추가하여 URL 요청 재작성을 구성할 수 있습니다. 예를 들면 다음과 같습니다.
    kind: Ingress
    metadata:
      name: cafe-ingress
      annotations:
        ingress.kubernetes.io/rewrite-target: /
    spec:
      rules:
      - host: cafe.example.com
        http:
          paths:
          - path: /tea
            backend:
              serviceName: tea-svc
              servicePort: 80
          - path: /coffee
            backend:
              serviceName: coffee-svc
              servicePort: 80

    URL이 백엔드 서비스로 전송되기 전에 경로 /tea/coffee/로 재작성됩니다.

  • 수신 주석 kubernetes.io/ingress.allow-http가 지원됩니다.
    • 주석이 false로 설정되어 있으면 HTTPS 규칙만 생성됩니다.
    • 주석이 true로 설정되어 있거나 누락된 경우에는 HTTP 규칙이 생성됩니다. 또한 수신 규격에 TLS 섹션이 있는 경우 HTTPS 규칙이 생성됩니다.
  • 오류는 수신 리소스에 주석으로 추가됩니다. 오류 키는 ncp/error.loadbalancer이고 주의 키는 ncp/warning.loadbalancer입니다. 다음과 같은 오류 및 주의가 발생할 수 있습니다.
    • ncp/error.loadbalancer: DEFAULT_BACKEND_IN_USE

      이 오류는 기본 백엔드가 있는 수신이 이미 있음을 나타냅니다. 이 경우 수신은 비활성 상태입니다. TLS 사용 여부와 관계없이 수신 그룹에는 기본 백엔드가 하나만 있어야 합니다. 이 오류를 해결하려면 수신을 삭제한 후 올바른 규격을 사용하여 다시 생성하십시오.

    • ncp/warning.loadbalancer: SECRET_NOT_FOUND

      이 오류는 수신 규격에 지정된 암호가 없음을 나타냅니다. 이 경우 수신은 부분적으로 활성 상태입니다. 이 오류를 해결하려면 누락된 암호를 생성하십시오. 참고로 주석에 주의가 있으면 해당 주의는 수신 리소스의 수명주기 동안 지워지지 않습니다.

    • ncp/warning.loadbalancer: INVALID_INGRESS
      이 오류는 다음 조건 중 하나가 true임을 나타냅니다. 이 경우 수신은 비활성 상태입니다. 이 오류를 해결하려면 수신을 삭제한 후 올바른 규격을 사용하여 다시 생성하십시오.
      • 수신 규칙이 동일한 Kubernetes 클러스터의 다른 수신 규칙과 충돌합니다.
      • allow-http 주석이 False로 설정되고 수신에 TLS 섹션이 포함되지 않습니다.
      • 수신 규칙에 hostpath가 지정되어 있지 않습니다. 이러한 수신 규칙에 수신 기본 백엔드와 동일한 기능이 있습니다. 대신 수신 기본 백엔드를 사용합니다.

유형 LoadBalancer의 서비스

  • NSX-T Data Center는 각 서비스 포트에 대해 계층 4 로드 밸런서 가상 서버와 풀을 생성합니다.
  • TCP와 UDP가 모두 지원됩니다.
  • 각 서비스에는 고유한 IP 주소가 할당됩니다.
  • 이 서비스에는 LoadBalancer 정의의 loadBalancerIP 필드를 기준으로 외부 IP 풀의 IP 주소가 할당됩니다. loadBalancerIP 필드는 비워 둘 수 있고 IP 풀의 IP 주소, 이름 또는 ID를 포함할 수 있습니다. loadBalancerIP 필드가 비어 있으면 ncp.ini[nsx_v3] 섹션에 있는 external_ip_pools_lb 옵션에서 지정한 외부 IP 풀에서 IP가 할당됩니다. external_ip_pools_lb 옵션이 없는 경우 external_ip_pools에서 지정한 풀이 사용됩니다. LoadBalancer 서비스는 이 IP 주소와 서비스 포트를 사용합니다.
  • 구성을 변경하고 NCP를 다시 시작하여 다른 IP 풀로 변경할 수 있습니다.
  • loadBalancerIP에서 지정한 IP 풀에는 태그 scope: ncp/owner, tag: cluster:<cluster_name>이 있어야 합니다.

  • 오류는 서비스에 주석으로 추가됩니다. 오류 키는 ncp/error.loadbalancer입니다. 다음과 같은 오류가 발생할 수 있습니다.
    • ncp/error.loadbalancer: IP_POOL_NOT_FOUND

      이 오류는 사용자가 loadBalancerIP: <nsx-ip-pool>을 지정했지만 <nsx-ip-pool>이 없음을 나타냅니다. 이 경우 서비스는 비활성 상태입니다. 이 오류를 해결하려면 올바른 IP 풀을 지정하고, 서비스를 삭제한 후 다시 생성하십시오.

    • ncp/error.loadbalancer: IP_POOL_EXHAUSTED

      이 오류는 사용자가 loadBalancerIP: <nsx-ip-pool>을 지정했지만 해당 IP 풀이 IP 주소를 모두 사용했음을 나타냅니다. 이 경우 서비스는 비활성 상태입니다. 이 오류를 해결하려면 사용 가능한 IP 주소가 있는 IP 풀을 지정하고, 서비스를 삭제한 후 다시 생성하십시오.

    • ncp/error.loadbalancer: IP_POOL_NOT_UNIQUE

      이 오류는 여러 IP 풀에 loadBalancerIP: <nsx-ip-pool>에서 지정한 이름이 있음을 나타냅니다. 이 경우 서비스는 비활성 상태입니다.

    • ncp/error.loadbalancer: POOL_ACCESS_DENIED

      이 오류는 loadBalancerIP에서 지정한 IP 풀에 태그 scope: ncp/owner, tag: cluster:<cluster_name>가 없거나 태그에 지정된 클러스터가 Kubernetes 클러스터의 이름과 일치하지 않음을 나타냅니다.

    • ncp/error.loadbalancer: LB_VIP_CONFLICT

      이 오류는 loadBalancerIP 필드의 IP가 활성 서비스의 IP와 동일함을 나타냅니다. 이 경우 서비스는 비활성 상태입니다.

  • 계층 4 로드 밸런서의 자동 크기 조정이 지원됩니다. Kubernetes LoadBalancer 서비스가 생성 또는 수정되어 추가 가상 서버가 필요하고 기존의 계층 4 로드 밸런서에 용량이 충분하지 않으면 새로운 계층 4 로드 밸런서가 생성됩니다. 또한 NCP는 더 이상 가상 서버가 연결되지 않은 계층 4 로드 밸런서를 삭제합니다. 이 기능은 기본적으로 사용하도록 설정되어 있습니다. NCP ConfigMap에서 l4_lb_auto_scalingfalse로 설정하여 이 기능을 사용하지 않도록 설정할 수 있습니다.

로드 밸런서 및 네트워크 정책

NSX 로드 밸런서 가상 서버에서 포드로 트래픽을 전달하는 경우 소스 IP는 Tier-1 라우터의 업링크 포트 IP 주소입니다. 이 주소는 개인 Tier-1 전송 네트워크에 있으며, 이 때문에 CIDR 기반 네트워크 정책이 허용해야 할 트래픽을 허용하지 않을 수 있습니다. 이 문제를 방지하려면 Tier-1 라우터의 업링크 포트 IP 주소가 허용되는 CIDR 블록에 포함되도록 네트워크 정책을 구성해야 합니다. 이 내부 IP 주소는 status.loadbalancer.ingress.ip 필드와 수신 리소스의 주석(ncp/internal_ip_for_policy)으로 표시됩니다.

예를 들어, 가상 서버의 외부 IP 주소가 4.4.0.5이고 내부 Tier-1 라우터의 업링크 포트 IP 주소가 100.64.224.11인 경우 상태는 다음과 같습니다.
    status:
      loadBalancer:
      ingress:
      - ip: 4.4.0.5
      - ip: 100.64.224.11
유형 LoadBalancer 리소스의 수신 및 서비스에 대한 주석은 다음과 같습니다.
    ncp/internal_ip_for_policy: 100.64.224.11
IP 주소 100.64.224.11은 네트워크 정책에서 ipBlock 선택기의 허용된 CIDR에 속해 있어야 합니다. 예를 들면 다음과 같습니다.
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    ...
    ingress:
    - from:
      - ipBlock:
         cidr: 100.64.224.11/32

CA 서명된 인증서를 생성하는 샘플 스크립트

아래 스크립트는 <filename>.crt 및 <finename>.key 파일에 각각 저장된 CA 서명된 인증서와 개인 키를 생성합니다. genrsa 명령은 CA 키를 생성합니다. CA 키는 암호화해야 합니다. aes256과 같은 명령을 사용하여 암호화 방법을 지정할 수 있습니다.
#!/bin/bash
host="www.example.com"
filename=server

openssl genrsa -out ca.key 4096
openssl req -key ca.key -new -x509 -days 365 -sha256 -extensions v3_ca -out ca.crt -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl req -out ${filename}.csr -new -newkey rsa:2048 -nodes -keyout ${filename}.key -subj "/C=US/ST=CA/L=Palo Alto/O=OS3/OU=Eng/CN=${host}"
openssl x509 -req -days 360 -in ${filename}.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ${filename}.crt -sha256

NCP 포드에 기본 인증서 및 키 마운트

인증서와 개인 키가 생성된 후 호스트 VM의 /etc/nsx-ujo 디렉토리에 저장합니다. 인증서와 키 파일의 이름이 lb-default.crtlb-default.key로 각각 지정되었다고 가정하고 호스트의 해당 파일이 포드에 마운트되도록 ncp-rc.yaml을 편집합니다. 예를 들면 다음과 같습니다.
spec:
  ...
  containers:
  - name: nsx-ncp
    ...
    volumeMounts:
    ...
    - name: lb-default-cert
      # Mount path must match nsx_v3 option "lb_default_cert_path"
      mountPath: /etc/nsx-ujo/lb-default.crt
    - name: lb-priv-key
      # Mount path must match nsx_v3 option "lb_priv_key_path"
      mountPath: /etc/nsx-ujo/lb-default.key
  volumes:
  ...
  - name: lb-default-cert
    hostPath:
      path: /etc/nsx-ujo/lb-default.crt
  - name: lb-priv-key
    hostPath:
      path: /etc/nsx-ujo/lb-default.key