NSX 로드 밸런서는 OpenShift와 통합되어 OpenShift 라우터로 작동합니다.
NCP는 OpenShift 라우팅 및 끝점 이벤트를 감시하고 라우팅 규격을 기반으로 로드 밸런서에서 로드 밸런싱 규칙을 구성합니다. 결과적으로 NSX 로드 밸런서는 규칙에 따라 수신 계층 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 로드 밸런서를 사용하려면 NCP에서 로드 밸런싱을 구성해야 합니다. ncp_rc.yml 파일에서 다음을 수행합니다.
- use_native_loadbalancer를 True로 설정합니다.
- pool_algorithm을 WEIGHTED_ROUND_ROBIN으로 설정합니다.
- lb_default_cert_path 및 lb_priv_key_path를 각각 CA 서명된 인증서 파일 및 개인 키 파일의 전체 경로 이름으로 설정합니다. CA 서명된 인증서를 생성하는 샘플 스크립트는 아래를 참조하십시오. 또한 기본 인증서 및 키를 NCP 포드에 마운트합니다. 자세한 내용은 아래를 참조하십시오.
- (선택 사항) 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
- (선택 사항) service_size를 SMALL, MEDIUM 또는 LARGE로 설정합니다. 기본값은 SMALL입니다.
-
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 로드 밸런서 지속성 프로파일을 공유합니다. 기본값이 아닌 지속성 시간 초과가 지정된 각 서비스에 대해 전용 프로파일이 생성됩니다.
참고: 수신의 백엔드 서비스가 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 로드 밸런서 서비스의 샤딩만 지원합니다.
라우터 샤딩을 구성하는 단계:
- 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 - 다음 명령을 실행하여 네임스페이스 레이블 선택기를 사용하여 라우터를 구성합니다(라우터의 dc/svc가 라우터인 경우).
oc set env dc/router NAMESPACE_LABELS="router=r1"
- 이전 단계에서 구성된 라우터는 선택한 네임스페이스의 경로를 처리합니다. 이 선택기가 네임스페이스와 일치하도록 하려면 그에 따라 네임스페이스에 레이블을 지정합니다. 예를 들면 다음과 같습니다.
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는 각 LoadBalancer 서비스 포트에 대해 계층 4 로드 밸런서 가상 서버와 풀을 생성합니다. TCP와 UDP가 모두 지원됩니다.
- NSX 로드 밸런서는 다양한 크기로 제공됩니다. NSX 로드 밸런서 구성에 대한 자세한 내용은 "NSX 관리 가이드" 를 참조하십시오.
로드 밸런서가 생성된 후 로드 밸런서 크기는 구성 파일을 업데이트하여 변경할 수 없습니다. 대신 UI 또는 API를 통해 변경할 수 있습니다.
- 계층 4 로드 밸런서의 자동 크기 조정이 지원됩니다. Kubernetes LoadBalancer 서비스가 생성 또는 수정되어 추가 가상 서버가 필요하고 기존의 계층 4 로드 밸런서에 용량이 충분하지 않으면 새로운 계층 4 로드 밸런서가 생성됩니다. 또한 NCP는 더 이상 가상 서버가 연결되지 않은 계층 4 로드 밸런서를 삭제합니다. 이 기능은 기본적으로 사용하도록 설정되어 있습니다. NCP ConfigMap에서 l4_lb_auto_scaling을 false로 설정하여 이 기능을 사용하지 않도록 설정할 수 있습니다.
- 경로 규격에서 destinationCACertificate 매개 변수는 지원되지 않으며 NCP에서 무시됩니다.
- 각 TLS 경로에는 다른 CA 서명 인증서가 있어야 합니다.
- NSX 로드 밸런서가 경로를 관리하지 않도록 하려면 주석 use_nsx_controller:False를 경로 규격에 추가합니다.
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
