블로그 | NGINX

NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱

NGINX-F5-수평-검정-유형-RGB의 일부
마이클 플레샤코프 썸네일
마이클 플레샤코프
2015년 11월 17일 게시

쿠버네티스는 Google에서 개발한 오픈 소스 시스템으로, 클러스터에서 컨테이너화된 마이크로서비스 기반 애플리케이션을 실행하고 관리하기 위해 사용됩니다. Kubernetes를 사용하는 사람들은 Kubernetes에서 만든 서비스를 Kubernetes 클러스터 외부에서 액세스할 수 있도록 해야 하는 경우가 많습니다.

Kubernetes는 아래의 내장 솔루션을 사용하여 Kubernetes 서비스 노출 에서 설명한 대로 서비스를 노출하기 위한 내장 솔루션을 제공하지만, 해당 솔루션은 레이어 4 부하 분산 또는 라운드 로빈 HTTP 부하 분산으로 제한됩니다.

이 게시물에서는 클라우드에서 Kubernetes를 실행하든 자체 인프라에서 실행하든 Kubernetes 서비스를 인터넷에 노출하기 위한 고급 Layer 7 로드 밸런싱 솔루션으로 NGINX Plus를 사용하는 방법을 보여줍니다.

Kubernetes(포드, 서비스, 복제 컨트롤러 및 레이블)와 실행 중인 Kubernetes 클러스터에 대한 기본적인 이해가 있다고 가정합니다. Kubernetes에 대해 자세히 알아보려면 공식 Kubernetes 사용자 가이드를 참조하세요.

내장 솔루션을 사용하여 Kubernetes 서비스 노출

쿠버네티스는 서비스를 노출하기 위한 여러 가지 옵션을 제공합니다. 그 중 두 가지(NodePort와 LoadBalancer)는 특정 유형의 서비스에 해당합니다. 세 번째 옵션인 Ingress API는 Kubernetes 릴리스 1.1에서 베타로 제공되기 시작했습니다.

노드포트

서비스 유형을 NodePort 로 지정하면 각 Kubernetes 노드에서 동일한 포트에서 서비스를 사용할 수 있습니다. 서비스를 인터넷에 노출하려면 해당 포트에 하나 이상의 노드를 노출해야 합니다. 고가용성을 위해 여러 노드를 노출하고 DNS 기반 부하 분산을 사용하여 트래픽을 분산하거나 원하는 부하 분산 장치 뒤에 노드를 배치할 수 있습니다.

수신 트래픽이 포트의 노드에 도달하면 서비스의 포드 간에 로드 밸런싱이 이루어집니다. 모든 노드에서 실행되는 Kubernetes 네트워크 프록시( kube-proxy )가 수행하는 로드 밸런싱은 TCP/UDP 로드 밸런싱으로 제한됩니다.

로드 밸런서

서비스 유형을 LoadBalancer 로 지정하면 서비스의 Pod 간에 수신 트래픽을 분산하는 클라우드 로드 밸런서가 할당됩니다.

LoadBalancer 솔루션은 특정 클라우드 공급업체와 Google Container Engine 에서만 지원되며, 자체 인프라에서 Kubernetes를 실행하는 경우에는 사용할 수 없습니다. 또한, Kubernetes에서는 클라우드 로드 밸런서에 세션 지속성이나 요청 매핑과 같은 고급 기능이 있는 경우에도 라운드 로빈 TCP 로드 밸런싱만 구성할 수 있습니다.

인그레스 API

Ingress 리소스를 만들면 사용자 지정 URL(예: URL /foo 에서 서비스 A, URL /bar 에서 서비스 B) 및 여러 가상 호스트 이름(예: 한 서비스 그룹의 경우 foo.example.com , 다른 그룹의 경우 bar.example.com )을 통해 서비스를 인터넷에 노출할 수 있습니다. Ingress 컨트롤러는 Ingress 리소스를 사용하고 외부 로드 밸런서를 설정합니다.

Ingress 컨트롤러는 표준 Kubernetes 배포의 일부가 아닙니다. 요구 사항에 가장 적합한 컨트롤러를 선택하거나 직접 컨트롤러를 구현하여 Kubernetes 클러스터에 추가해야 합니다. 많은 컨트롤러 구현이 곧 등장할 것으로 예상되지만 현재 유일하게 사용 가능한 구현은 Google Compute Engine HTTP 부하 분산 장치용 컨트롤러 입니다. 이는 Google Compute Engine 또는 Google Container Engine 에서 Kubernetes를 실행하는 경우에만 작동합니다. 실제 로드 밸런서가 고급 기능을 지원하더라도 Ingress API는 라운드 로빈 HTTP 로드 밸런싱만 지원합니다.

이 글을 쓰는 시점에서 Ingress API와 Google Compute Engine HTTP 부하 분산 장치용 컨트롤러는 모두 베타 버전입니다.

업데이트 – NGINX 및 NGINX Plus용 NGINX Ingress Controller가 이제 GitHub 저장소 에서 사용 가능합니다. 제품에 대한 자세한 내용은 NGINX Ingress Controller를 참조하세요.

위에서 언급한 솔루션은 설정이 간단하고 바로 사용할 수 있지만 특히 7계층 부하 분산과 관련된 기능을 비롯한 고급 기능을 제공하지 않습니다.

NGINX Plus로 Kubernetes 서비스 노출

[편집자 - 이 섹션은 원래 여기에서 논의된 별도의 동적 구성 모듈을 대체하고 더 이상 사용되지 않는 NGINX Plus API를 참조하도록 업데이트되었습니다.]

NGINX Plus를 Kubernetes와 통합하려면 NGINX Plus 구성이 Kubernetes와 동기화되어 Pod 추가 또는 삭제와 같은 Kubernetes 서비스의 변경 사항을 반영해야 합니다. NGINX 오픈 소스를 사용하면 NGINX 구성 파일을 수동으로 수정하고 구성을 다시 로드할 수 있습니다. NGINX Plus를 사용하면 구성을 동적으로 업데이트하는 두 가지 방법이 있습니다.

  • API 사용 – 이 방법은 NGINX Plus API를 사용하여 NGINX Plus 구성에서 Kubernetes Pod에 대한 항목을 추가하거나 제거하고 Kubernetes API를 사용하여 Pod의 IP 주소를 검색합니다. 이 방법을 사용하려면 약간의 코드를 작성해야 하지만, 여기서는 자세히 다루지 않겠습니다. 자세한 내용은 Kelsey Hightower의 웨비나 'NGINX Plus로 Kubernetes를 Edge로 가져오기'를 시청하세요. 이 웨비나에서 그는 API를 살펴보고 이를 활용하는 애플리케이션을 만듭니다.
  • DNS 이름을 다시 확인 하여 – 이 방법은 다음 섹션에 설명된 대로 NGINX Plus의 적절한 일회성 구성만 필요합니다.

DNS 기반 재구성 활용

이미 실행 중인 Kubernetes 클러스터와 클러스터 관리에 사용할 수 있는 kubectl 유틸리티가 있는 호스트가 있다고 가정합니다. 자세한 내용은 클러스터 유형에 대한 Kubernetes 시작 가이드를 참조하세요. 또한 NGINX Plus Docker 이미지를 빌드해야 하며 이에 대한 지침은 블로그의 Docker를 사용하여 NGINX 및 NGINX Plus 배포 에서 확인할 수 있습니다.

우리가 할 일의 개요는 다음과 같습니다.

  1. 2단계에서 만든 서비스를 노출하고 부하를 분산하기 위해 NGINX Plus Pod를 구성합니다.
  2. 우리의 서비스로 간단한 웹 애플리케이션을 만들어 보겠습니다.
  3. 서비스를 확장하거나 축소하면서 NGINX Plus가 자동으로 재구성되는 모습을 살펴보세요.

참고사항: 이 블로그에 설명된 솔루션을 Google Compute Engine에서 실행되는 Kubernetes 1.0.6 과 로컬 Vagrant 설정(아래에서 사용)을 사용하여 테스트했습니다.

명령에서 Kubernetes 설정에 따라 다를 수 있는 값은 기울임꼴로 표시됩니다.

NGINX Plus Pod 구성

우리는 인터넷에 노출된 노드의 Kubernetes Pod에 NGINX Plus를 배치하고 있습니다. 우리의 포드는 우리가 설정 중인 복제 컨트롤러에 의해 생성됩니다. Kubernetes 전용 NGINX Plus 구성 파일은 NGINX Plus Pod와 노드 간에 공유되는 폴더에 있으므로 유지 관리가 더 간편합니다.

NGINX Plus Pod를 호스팅할 노드 선택

NGINX Plus Pod가 실행되는 노드를 지정하려면 해당 노드에 레이블을 추가합니다. 다음을 실행하여 모든 노드 목록을 가져옵니다.

$ kubectl get nodes 이름 레이블 상태 10.245.1.3 Kubernetes.io/hostname=10.245.1.3 준비 10.245.1.4 Kubernetes.io/hostname=10.245.1.4 준비 10.245.1.5 Kubernetes.io/hostname=10.245.1.5 준비

첫 번째 노드를 선택하고 다음을 실행하여 레이블을 추가합니다.

$ kubectl 레이블 노드10.245.1.3 역할=nginxplus

NGINX Plus Pod에 대한 복제 컨트롤러 구성

NGINX Plus Pod를 직접 만드는 것이 아니라 복제 컨트롤러를 통해 만듭니다. nginxplus-rc.yaml 이라는 Kubernetes 선언 파일에서 NGINX Plus Pod에 대한 복제 컨트롤러를 구성합니다.

  • 복제본 의 개수를 하나로 설정하면 쿠버네티스는 항상 하나의 NGINX Plus 포드가 실행되도록 합니다. 포드에 장애가 발생하면 새로운 포드로 대체됩니다.
  • nodeSelector 필드에서 NGINX Plus Pod가 role: nginxplus라는 라벨이 지정된 노드에 생성됨을 지정합니다.
  • NGINX Plus 컨테이너는 80과 8080이라는 두 개의 포트를 노출하며, 이 두 포트와 노드의 80 및 8080 포트 간의 매핑을 설정합니다.
  • NGINX Plus 컨테이너도 노드에 있는 /etc/nginx/conf.d 폴더를 공유합니다. 아래의 NGINX Plus 구성 에서 자세히 설명한 대로 폴더를 공유하면 컨테이너 이미지를 다시 빌드하지 않고도 NGINX Plus를 재구성할 수 있습니다.
apiVersion: v1
종류: ReplicationController
메타데이터:
이름: nginxplus-rc
스펙:
복제본: 1
선택자:
앱: nginxplus
템플릿:
메타데이터:
레이블:
앱: nginxplus
사양:
노드 선택자:
역할: nginxplus
컨테이너:
- 이름: nginxplus
imagePullPolicy: IfNotPresent
이미지: nginxplus
포트:
- 이름: http
컨테이너 포트: 80
호스트 포트: 80
- 이름: http-alt
컨테이너 포트: 8080
호스트 포트: 8080
볼륨 마운트:
- 마운트 경로: "/etc/nginx/conf.d"
이름: etc-nginx-confd
볼륨:
- 호스트 경로:
경로: "/etc/nginx/conf.d"
이름: etc-nginx-confd

노드에서 NGINX Plus Docker 이미지 사용 가능

위에서 말했듯이, 우리는 이미 NGINX Plus Docker 이미지를 빌드했습니다. 이제 노드에서 사용할 수 있게 됐습니다. 단순화를 위해 개인 Docker 저장소를 사용하지 않고, 노드에 이미지를 수동으로 로드합니다.

Docker 이미지를 빌드한 호스트에서 다음 명령을 실행하여 이미지를 파일에 저장합니다.

$ 도커 저장 -o nginxplus.tar nginxplus

nginxplus.tar를 노드로 전송하고, 노드에서 다음 명령을 실행하여 파일에서 이미지를 로드합니다.

$ docker 로드 -i nginxplus.tar

NGINX Plus 구성

NGINX Plus 컨테이너의 /etc/nginx 폴더에서는 NGINX Plus 패키지와 함께 제공되는 기본 nginx.conf 구성 파일을 그대로 유지합니다. 기본 파일에 있는 include 지시문은 /etc/nginx/conf.d 폴더에서 다른 구성 파일을 읽어옵니다. NGINX Plus 복제 컨트롤러( nginxplus-rc.yaml )에 대한 선언 파일 에서 지정한 대로, NGINX Plus 노드의 /etc/nginx/conf.d 폴더를 컨테이너와 공유합니다. 공유를 통해 컨테이너에 직접 폴더를 만든 경우에는 NGINX Plus Docker 이미지를 다시 빌드해야 하지만, 노드에 있는 폴더에 저장된 구성 파일을 변경할 필요가 없습니다. Kubernetes 관련 구성 파일( backend.conf )을 공유 폴더에 넣었습니다.

먼저, 노드에 /etc/nginx/conf.d 폴더를 만들어 보겠습니다.

$ sudo mkdir -p /etc/nginx/conf.d

그런 다음 해당 위치에 backend.conf 파일을 만들고 다음 지침을 포함합니다.

  • resolver – NGINX Plus가 업스트림 서버를 식별하는 데 사용하는 도메인 이름을 주기적으로 다시 확인하는 데 사용하는 DNS 서버를 정의합니다(다음 항목에서 설명하는 업스트림 블록 내의 서버 지시문). 이 DNS 서버는 도메인 이름인 kube-dns.kube-system.svc.cluster.local 로 식별합니다. 유효한 매개변수는 NGINX Plus에게 5초마다 재확인 요청을 보내라고 지시합니다.

    (이 지시어에 대한 확인 프로세스는 업스트림 서버의 확인 프로세스와 다릅니다. 이 도메인 이름은 NGINX가 시작되거나 다시 로드될 때만 확인되고, NGINX Plus는 /etc/resolv.conf 파일에 정의된 시스템 DNS 서버를 사용하여 이를 확인합니다.)

  • 업스트림 – Kubernetes 서비스를 제공하는 서버를 포함하기 위해 백엔드 라는 업스트림 그룹을 생성합니다. 서버를 개별적으로 나열하는 대신, 단일 서버 지시문에서 완전히 정규화된 호스트 이름으로 서버를 식별합니다. resolve 매개변수는 NGINX Plus에게 resolver 지시문으로 지정된 설정에 따라 런타임에 호스트 이름을 다시 확인하도록 지시합니다.

    Kubernetes DNS와 NGINX Plus(R10 이상)는 모두 DNS 서비스( SRV ) 레코드를 지원하므로 NGINX Plus는 DNS를 통해 업스트림 서버의 포트 번호를 가져올 수 있습니다. NGINX Plus가 SRV 레코드를 요청하도록 서비스 매개변수를 포함하고, 서비스에서 노출되는 포트에 대한 이름( _http )과 프로토콜( _tcp )을 지정합니다. 아래 서비스에 대한 복제 컨트롤러 생성 에서 설명한 webapp-svc.yaml 파일에서 해당 값을 선언합니다.

    DNS를 사용한 서비스 검색에 대한 자세한 내용은 블로그의 NGINX 및 NGINX Plus에서 DNS를 사용하여 서비스 검색을 참조하세요.

  • 서버 (2회) – 두 개의 가상 서버를 정의합니다.

    • 첫 번째 서버는 포트 80에서 수신하고 /webapp (당사 서비스)에 대한 들어오는 요청을 서비스 인스턴스를 실행하는 포드 간에 부하 분산합니다. 또한 적극적인 건강 검진 도 실시합니다.

    • 두 번째 서버는 포트 8080에서 수신합니다. 여기서는 NGINX Plus의 라이브 활동 모니터링을 설정합니다. 나중에 이를 사용하여 NGINX Plus가 올바르게 재구성되었는지 확인하겠습니다.

      [편집자 - 이 두 번째 서버의 구성은 원래 사용되었던 별도의 상태 모듈을 대체하고 더 이상 사용되지 않는 NGINX Plus API를 사용하도록 업데이트되었습니다.]

리졸버 kube-dns.kube-system.svc.cluster.local 유효=5초;

업스트림 백엔드 {
존 업스트림 백엔드 64k;
서버 웹앱-svc.default.svc.cluster.local 서비스=_http._tcp 리졸브;
}

서버 {
수신 80;
상태_존 백엔드-서버;

위치 /웹앱 {
프록시_패스 http://백엔드;
상태_체크;
}
}

서버 {
수신 8080;
루트 /usr/share/nginx/html;

위치 = /dashboard.html { }

위치 = / {
리턴 302 /dashboard.html;
}

위치 /api {
api write=on;
}
}

복제 컨트롤러 생성

이제 다음 명령을 실행하여 복제 컨트롤러를 생성할 준비가 되었습니다.

$ kubectl create -f nginxplus-rc.yaml

NGINX Plus Pod가 생성되었는지 확인하려면 다음을 실행합니다.

$ kubectl get pods 이름 준비 상태 재시작 연령 nginxplus-rc-0ts5t 1/1 실행 중 0 17초

로컬 Vagrant 설정에서 Kubernetes를 실행하고 있으므로 노드의 외부 IP 주소가 10.245.1.3임을 알고 있으며 이 예제의 나머지 부분에서도 해당 주소를 사용할 것입니다. 클라우드 공급자에서 Kubernetes를 실행하는 경우 다음을 실행하여 노드의 외부 IP 주소를 가져올 수 있습니다.

$ kubectl get nodes 노드 이름 -o json | grep -i externalIP -A 1 "유형": "외부IP", "주소": XXX.XXX.XXX.XXX

클라우드에서 실행하는 경우 NGINX Plus 노드가 들어오는 트래픽을 허용할 수 있도록 방화벽 규칙을 설정하는 것을 잊지 마세요. 클라우드 제공자의 설명서를 참조하세요.

NGINX Plus 포드가 제대로 작동 중인지 확인하려면 노드의 외부 IP 주소(우리의 경우 http://10.245.1.3:8080/dashboard.html )에서 포트 8080을 통해 사용할 수 있는 NGINX Plus 라이브 활동 모니터링 대시보드를 살펴보세요. 하지만 이 지점을 살펴보면, 아직 서비스를 만들지 않았기 때문에 서비스에 대한 서버가 보이지 않습니다.

Kubernetes 서비스를 생성하기 전의 NGINX Plus 라이브 활동 모니터링 대시보드

간단한 쿠버네티스 서비스 만들기

이제 Kubernetes 서비스를 만들 시간입니다. 저희 서비스는 두 대의 웹 서버로 구성되어 있으며, 각 서버는 자신이 실행 중인 컨테이너에 대한 정보가 있는 웹 페이지를 제공합니다.

서비스에 대한 복제 컨트롤러 생성

먼저, Kubernetes가 지정된 수의 웹 서버 복제본(포드)이 클러스터에서 항상 실행되도록 하기 위해 복제 컨트롤러를 생성합니다. 선언 파일( webapp-rc.yaml )은 다음과 같습니다.

api버전: v1종류: ReplicationController
메타데이터:
이름: webapp-rc
스펙:
복제본: 2
선택기:
앱: 웹앱
템플릿:
메타데이터:
레이블:
앱: 웹앱
사양:
컨테이너:
- 이름: hello
이미지: nginxdemos/hello 
포트:
- 컨테이너포트: 80

우리의 컨트롤러는 두 개의 웹 서버로 구성되어 있습니다. 단일 컨테이너가 있는 포드로 구성된 컨트롤러를 선언하고 포트 80을 노출합니다. nginxdemos/hello 이미지는 Docker Hub에서 가져옵니다.

복제 컨트롤러를 생성하려면 다음 명령을 실행합니다.

$ kubectl create -f 웹앱-rc.yaml

포드가 생성되었는지 확인하려면 다음 명령을 실행합니다. 이전 단계에서 복제 컨트롤러가 생성한 Pod만 가져오려면 라벨 선택기 app=webapp을 사용합니다.

$ kubectl get pods -l app=webapp 이름 준비 상태 재시작 연령 webapp-rc-544f1 1/1 실행 중 0 2m webapp-rc-uk6pm 1/1 실행 중 0 2m

서비스 생성

다음으로 복제 컨트롤러가 생성한 포드에 대한 서비스를 생성합니다. 다음 파일( webapp-service.yaml )로 서비스를 선언합니다.

api버전: v1종류: 서비스
메타데이터:
이름: webapp-svc
사양:
클러스터IP: 없음
포트:
- 포트: 80
대상 포트: 80
프로토콜: TCP
이름: http
선택자:
앱: 웹앱

여기서는 ClusterIP 필드를 None 으로 설정하여 특별한 헤드리스 서비스를 선언합니다. 이 유형의 서비스에서는 클러스터 IP 주소가 할당되지 않으며 Kube 프록시를 통해 서비스를 사용할 수 없습니다. 쿠버네티스 DNS에 대한 DNS 쿼리는 여러 개의 A 레코드(포드의 IP 주소)를 반환합니다.

또한 NGINX Plus가 Pod를 연결하는 데 사용할 포트를 선언합니다. 포트와 대상 포트 번호를 지정하는 것 외에도 이름( http )과 프로토콜( TCP )을 지정합니다. 우리는 NGINX Plus 구성 파일에서 해당 값을 사용합니다. 이 파일에서 우리는 NGINX Plus에게 SRV 레코드를 사용하여 DNS를 통해 포드의 포트 번호를 가져오도록 지시합니다.

선택기 필드를 app: webapp 으로 설정하면, 서비스에 속하는 Pod, 즉 NGINX 복제 컨트롤러( webapp-rc.yaml 에 정의됨)에서 생성된 Pod를 선언합니다.

다음 명령을 실행하면 서비스가 생성됩니다.

$ kubectl create -f 웹앱 서비스.yaml

이제 대시보드 페이지를 새로 고치고 오른쪽 상단 모서리에 있는 업스트림 탭을 클릭하면 추가한 두 개의 서버를 볼 수 있습니다.

Kubernetes 서비스가 생성된 후 NGINX Plus 라이브 활동 모니터링 대시보드

또한 NGINX Plus가 서비스의 Pod 간 트래픽 로드 밸런싱을 수행하는지 확인할 수도 있습니다. 그렇다면 브라우저에서 http://10.245.1.3/webapp/ 에 접속하면 해당 페이지에 호스트 이름과 IP 주소 등 웹 서버가 실행 중인 컨테이너에 대한 정보가 표시됩니다.

이 페이지를 여러 번 새로 고치고 상태 대시보드를 살펴보면 요청이 두 개의 상위 서버에 어떻게 분산되는지 확인할 수 있습니다.

쿠버네티스 서비스 확장

[편집자 - 이 섹션은 원래 사용되었던 별도의 상태 모듈을 대체하고 더 이상 사용하지 않는 NGINX Plus API를 사용하도록 업데이트되었습니다.]

이제 서비스에 두 개의 Pod를 추가하고 NGINX Plus 구성이 다시 자동으로 업데이트되는지 확인해 보겠습니다. 복제 컨트롤러를 확장하여 포드 수를 4개로 변경하려면 다음 명령을 실행합니다.

$ kubectl scale rc webapp-rc --replicas=4 크기 조정됨

NGINX Plus가 재구성되었는지 확인하기 위해 다시 대시보드를 살펴볼 수 있지만, 이번에는 대신 NGINX Plus API를 사용합니다. 다음 명령을 실행합니다.10.245.1.3 NGINX Plus 노드의 외부 IP 주소이고3 NGINX Plus API 의 버전입니다. JSON 출력을 깔끔하게 포맷하려면 jq 로 파이프합니다.

$ 컬 -s10.245.1.3 :8080/아피/3 /http/upstreams/backend/servers | jq { "피어": [ { "ID": 1, "서버": "10.0.0.1:80", "백업": 거짓, "가중치": 1, "상태": "건강하지 않음", "활성": 0, "요청": 1, "응답": { "1xx": 0, "2xx": 0, "3xx": 0, "4xx": 0, "5xx": 0, "총": 0 }, "보냄": 0, "수신됨": 0, "실패": 0, "사용 불가": 0, "health_checks": { "checks": 1, "실패": 1, "건강에 해롭다": 1, "마지막으로 통과": 거짓 }, "다운타임": 33965, "다운스타트": 1445378182275, "선택됨": 1445378131000 }, { "아이디": 2, "서버": "10.246.1.6:80", ... }, { "아이디": 3, "서버": "10.246.3.2:80", ... { "id": 4, "서버": "10.0.0.2:80", ... } ], "keepalive": 0 }

JSON 출력의 peers 배열에는 웹 서버당 하나씩, 총 4개의 요소가 정확히 있습니다.

이제 포드 수를 4개에서 1개로 줄이고 NGINX Plus 상태를 다시 확인해 보겠습니다.

$ kubectl 스케일 rc 웹앱-rc --레플리카=1 스케일됨 $ curl -s10.245.1.3 :8080/아피/3 /http/업스트림/백엔드/서버 | jq

이제 JSON 출력의 peers 배열에는 요소가 하나만 포함됩니다(출력은 이전 샘플 명령에서 ID가 1인 피어의 경우와 동일합니다).

이제 NGINX Plus를 구동하므로 세션 지속성 , SSL/TLS 종료 , 요청 라우팅 , 고급 모니터링 등 고급 기능을 활용할 수 있습니다.

요약

NGINX Plus에서 제공되는 즉석 재구성 옵션을 사용하면 API를 통한 프로그래밍 방식이나 DNS를 통한 완전한 방식으로 Kubernetes와 손쉽게 통합할 수 있습니다. NGINX Plus를 사용하면 Kubernetes 서비스를 인터넷에 노출할 수 있어 현재 기본 제공 Kubernetes 부하 분산 솔루션에 없는 많은 기능을 제공할 수 있습니다.

NGINX Plus가 Kubernetes와 함께 작동하는 방식을 알아보려면 오늘 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의하세요.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."