NSX-T Data Center 로드 밸런서는 OpenShift와 통합되어 OpenShift 라우터로 작동합니다.

NCP는 OpenShift 라우팅 및 끝점 이벤트를 감시하고 라우팅 규격을 기반으로 로드 밸런서에서 로드 밸런싱 규칙을 구성합니다. 결과적으로 NSX-T Data Center 로드 밸런서는 규칙에 따라 수신 계층 7 트래픽을 적절한 백엔드 포드로 전달합니다.

로드 밸런싱 구성에는 Kubernetes LoadBalancer 서비스 또는 OpenShift 라우팅 구성이 포함됩니다. NCP 복제 컨트롤러도 구성해야 합니다. LoadBalancer 서비스는 계층 4 트래픽용이고 OpenShift 라우팅은 계층 7 트래픽용입니다.

Kubernetes LoadBalancer 서비스를 구성하면 사용자가 구성한 외부 IP 블록의 IP 주소가 할당됩니다. 로드 밸런서는 이 IP 주소와 서비스 포트를 사용합니다. LoadBalancer 정의의 loadBalancerIP 규격을 사용하여 IP 풀의 이름 또는 ID를 지정할 수 있습니다. 이 IP 풀에서 LoadBalancer 서비스의 IP가 할당됩니다. loadBalancerIP 규격이 비어 있으면 IP가 사용자가 구성하는 외부 IP 블록에서 할당됩니다.

loadBalancerIP에서 지정한 IP 풀에는 태그 scope: ncp/owner, tag: cluster:<cluster_name>이 있어야 합니다.

NSX-T Data Center 로드 밸런서를 사용하려면 NCP에서 로드 밸런싱을 구성해야 합니다. ncp_rc.yml 파일에서 다음을 수행합니다.

  1. use_native_loadbalancer를 True로 설정합니다.
  2. pool_algorithm을 WEIGHTED_ROUND_ROBIN으로 설정합니다.
  3. lb_default_cert_path 및 lb_priv_key_path를 각각 CA 서명된 인증서 파일 및 개인 키 파일의 전체 경로 이름으로 설정합니다. CA 서명된 인증서를 생성하는 샘플 스크립트는 아래를 참조하십시오. 또한 기본 인증서 및 키를 NCP 포드에 마운트합니다. 자세한 내용은 아래를 참조하십시오.
  4. (선택 사항) l4_persistence 및 l7_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
  5. (선택 사항) service_size를 SMALL, MEDIUM 또는 LARGE로 설정합니다. 기본값은 SMALL입니다.
  6. OpenShift 3.11을 실행하는 경우 OpenShift에서 LoadBalancer 서비스에 IP를 할당하지 않도록 다음 구성을 수행해야 합니다.
    • /etc/origin/master/master-config.yaml 파일의 networkConfig 아래에서 ingressIPNetworkCIDR을 0.0.0.0/32로 설정합니다.
    • 다음 명령을 사용하여 API 서버와 컨트롤러를 다시 시작합니다. 
         master-restart api
   master-restart controllers

Kubernetes LoadBalancer 서비스의 경우 글로벌 계층 4 지속성이 꺼져 있는 경우(l4_persistence가 <None>으로 설정되어 있음) 서비스 규격에서 sessionAffinity를 지정하여 서비스의 지속성 동작을 구성할 수 있습니다. l4_persistence를 source_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

라우터 샤딩

OpenShift 4에서 각 경로의 메타데이터 필드에는 개수에 제한 없는 레이블이 있을 수 있습니다. 라우터는 선택기를 사용하여 경로의 전체 풀에서 경로의 하위 집합을 선택합니다. 선택 영역에는 경로 네임스페이스의 레이블도 포함될 수 있습니다. 선택한 경로는 경로 샤드를 형성합니다.

다음과 같은 용도로 경로 샤드를 생성할 수 있습니다.
  • 경로 레이블 또는 네임스페이스를 기준으로 수신을 구성합니다.
  • 애플리케이션에 대해 서로 다른 경로를 구성합니다.
  • 성능 향상을 위해 여러 로드 밸런서 서비스에 워크로드를 분산합니다.

이 기능은 계층 7 로드 밸런서 서비스의 샤딩만 지원합니다.

라우터 샤딩을 구성하는 단계:
  1. configmap.yaml의 [k8s] 섹션에서 enable_lb_crd 옵션을 True로 설정하고 YAML 파일을 적용합니다. LoadBalancer CRD(CustomResourceDefinition)를 정의하는 YAML 파일을 생성하고 적용합니다. 예를 들면 다음과 같습니다.
    apiVersion: vmware.com/v1alpha1
kind: LoadBalancer
metadata:
    name: lbs-crd-1
spec:
    httpConfig:
        virtualIP: 192.168.4.4          # VIP for HTTP/HTTPS server. Default to auto_allocate
        port: 81                        # HTTP port number. Default to 80
        tls:
            port: 9998                  # HTTPS port number. default to 443
            secretName: default_secret  # Default certificate for HTTPS server. Default to nil
            secretNamespace: default    # Need to be set with secretName
        xForwardedFor: INSERT           # Available values are INSERT, REPLACE. Default to nil
        affinity:
            type: source_ip             # Available values are sourceIP, cookie
            timeout: 100                # Default to 10800
    size: MEDIUM                        # Default to SMALL
  2. 다음 명령을 실행하여 네임스페이스 레이블 선택기를 사용하여 라우터를 구성합니다(라우터의 dc/svc가 라우터인 경우).
    oc set env dc/router NAMESPACE_LABELS="router=r1"
  3. 이전 단계에서 구성된 라우터는 선택한 네임스페이스의 경로를 처리합니다. 이 선택기가 네임스페이스와 일치하도록 하려면 그에 따라 네임스페이스에 레이블을 지정합니다. 예를 들면 다음과 같습니다.
    apiVersion: v1
kind: Route
metadata:
  name: cafe-route
  annotations:
    nsx/loadbalancer: lbs-crd-1
spec:
  host: cafe.example.com
  to:
    kind: Service
    name: tea-svc
    weight: 1
    다음 명령을 실행합니다. 
    oc label namespace targetns "router=r1"
    대상을 대상 경로가 있는 정확한 네임스페이스로 바꿉니다. 예를 들면 다음과 같습니다. 
    apiVersion: v1
kind: Namespace
metadata:
    name: qe
    annotations:
        nsx/loadbalancer: lbs-crd-1

    참고: 네임스페이스 내의 경로에 다른 주석이 있는 경우 경로 주석이 우선적으로 적용됩니다.

계층 7 로드 밸런서 예

다음 YAML 파일은 계층 7 로드 밸런싱을 제공하는 두 가지 복제 컨트롤러(tea-rc 및 coffee-rc)와 두 가지 서비스(tea-svc 및 coffee-svc) 및 두 가지 라우팅(cafe-route-multi 및 cafe-route)을 구성합니다. 
# RC
apiVersion: v1
kind: ReplicationController
metadata:
  name: tea-rc
spec:
  replicas: 2
  template:
    metadata:
       labels:
         app: tea
    spec:
      containers:
      - name: tea
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: coffee-rc
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: nginxdemos/hello
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
# Services
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
  labels:
    app: tea
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: tea
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
  labels:
    app: coffee
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: coffee
---
# Routes
apiVersion: v1
kind: Route
metadata:
  name: cafe-route-multi
spec:
  host: www.cafe.com
  path: /drinks
  to:
    kind: Service
    name: tea-svc
    weight: 1
  alternateBackends:
  - kind: Service
    name: coffee-svc
    weight: 2
---
apiVersion: v1
kind: Route
metadata:
  name: cafe-route
spec:
  host: www.cafe.com
  path: /tea-svc
  to:
    kind: Service
    name: tea-svc
    weight: 1

추가 정보

  • 모든 종료 모드(edge, passthrough 및 reencrypt)가 지원됩니다.
  • 와일드카드 하위 도메인이 지원됩니다. 예를 들어 wildcardPolicy가 하위 도메인으로 설정되고 호스트 이름이 wildcard.example.com으로 설정되면 *.example.com에 대한 모든 요청이 처리됩니다.
  • 잘못된 구성으로 인해 라우팅 이벤트가 처리되는 동안 NCP에서 오류가 발생하면 라우팅 YAML 파일을 수정하고 라우팅 리소스를 삭제한 다음 다시 생성해야 합니다.
  • NCP는 네임스페이스별로 호스트 이름 소유권을 적용하지 않습니다.
  • Kubernetes 클러스터당 하나의 Loadbalancer 서비스가 지원됩니다.
  • NSX-T Data Center는 각 LoadBalancer 서비스 포트에 대해 계층 4 로드 밸런서 가상 서버와 풀을 생성합니다. TCP와 UDP가 모두 지원됩니다.
  • NSX-T Data Center 로드 밸런서는 다양한 크기로 제공됩니다. NSX-T Data Center 로드 밸런서 구성에 대한 자세한 내용은 "NSX-T Data Center 관리 가이드" 를 참조하십시오.

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

  • 계층 4 로드 밸런서의 자동 크기 조정이 지원됩니다. Kubernetes LoadBalancer 서비스가 생성 또는 수정되어 추가 가상 서버가 필요하고 기존의 계층 4 로드 밸런서에 용량이 충분하지 않으면 새로운 계층 4 로드 밸런서가 생성됩니다. 또한 NCP는 더 이상 가상 서버가 연결되지 않은 계층 4 로드 밸런서를 삭제합니다. 이 기능은 기본적으로 사용하도록 설정되어 있습니다. NCP ConfigMap에서 l4_lb_auto_scaling을 false로 설정하여 이 기능을 사용하지 않도록 설정할 수 있습니다.
  • 경로 규격에서 destinationCACertificate 매개 변수는 지원되지 않으며 NCP에서 무시됩니다.
  • 각 TLS 경로에는 다른 CA 서명 인증서가 있어야 합니다.

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