로드 밸런싱 구성에는 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 풀에 태그 {"ncp/owner": cluster:<cluster>}가 있어야 합니다.

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

  1. use_native_loadbalancerTrue로 설정합니다.

  2. pool_algorithmWEIGHTED_ROUND_ROBIN으로 설정합니다.

  3. lb_default_cert_path 및 lb_priv_key_path를 각각 CA 서명된 인증서 파일 및 개인 키 파일의 전체 경로 이름으로 설정합니다. CA 서명된 인증서를 생성하는 샘플 스크립트는 아래를 참조하십시오. 또한 기본 인증서 및 키를 NCP 포드에 마운트합니다. 자세한 내용은 아래를 참조하십시오.

  4. (선택 사항) 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
  5. (선택 사항) service_sizeSMALL, 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_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

라우터 샤딩

NCP는 항상 TLS Edge 종료 및 HTTP 경로를 처리하고 해당 네임스페이스 또는 네임스페이스 레이블에 관계없이 TLS 패스스루 경로 및 TLS 다시 암호화 경로를 건너뜁니다. TLS 다시 암호화 및 패스스루 경로만 처리하도록 OpenShift 라우터를 제한하려면 다음과 같은 단계를 수행해야 합니다.

  • OpenShift 라우터에 네임스페이스 레이블 선택기를 추가합니다.

  • 대상 네임스페이스에 네임스페이스 레이블을 추가합니다.

  • 대상 네임스페이스에서 TLS 다시 암호화/패스스루 경로를 생성합니다.

예를 들어 네임스페이스 레이블 선택기를 사용하여 라우터를 구성하려면 다음 명령을 실행합니다(라우터의 서비스 계정 이름이 router라고 가정함).

oc set env dc/router NAMESPACE_LABELS="router=r1"

이제 라우터는 선택된 네임스페이스에서 경로를 처리합니다. 이 선택기가 네임스페이스와 일치하도록 하려면 다음 명령을 실행합니다(네임스페이스가 ns1이라고 가정함).

oc label namespace ns1 "router=r1"

계층 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

추가 정보

  • HTTPS 트래픽에는 Edge 종료만 지원됩니다.

  • 와일드카드 하위 도메인이 지원됩니다. 예를 들어 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_scalingfalse로 설정하여 이 기능을 사용하지 않도록 설정할 수 있습니다.

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