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

NGINX | 2015년 11월 17일
Michael Pleshakov
Michael Pleshakov

Kubernetes는 컨테이너화된 마이크로서비스 기반 애플리케이션을 클러스터에서 실행하고 관리하기 위해 Google이 개발한 오픈 소스 시스템입니다. Kubernetes 사용자는 Kubernetes에서 생성한 서비스에 Kubernetes 클러스터 외부에서도 액세스할 수 있도록 해야 하는 경우가 많습니다.

Although Kubernetes는 서비스 노출을 위한 기본 제공 솔루션을 제공합니다. 아래의 기본 제공 솔루션을 사용하여 Kubernetes 서비스 노출에서 설명하는 것처럼, 이러한 솔루션은 계층 4 부하 분산 또는 라운드 로빈 HTTP 부하 분산으로 제한됩니다.

이 게시물에서는 클라우드 또는 자체 인프라에서 Kubernetes를 실행하는 경우 모두 Kubernetes 서비스를 인터넷에 노출하기 위한 고급 계층 7 부하 분산 솔루션으로 NGINX Plus를 사용하는 방법을 설명합니다.

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

기본 제공 솔루션으로 Kubernetes 서비스 노출하기

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

NodePort

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

수신 트래픽이 해당 포트의 노드에 도달하면 서비스의 Pod 간에 부하가 분산됩니다. 각 노드에서 실행되는 Kubernetes 네트워크 프록시(kube-proxy)가 수행하는 부하 분산은 TCP/UDP 부하 분산으로 제한됩니다.

로드 밸런서

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

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

Ingress API

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

Ingress 컨트롤러는 표준 Kubernetes 배포에 포함되지 않습니다. 요구 사항에 가장 적합한 컨트롤러를 선택하거나 직접 구현하여 Kubernetes 클러스터에 추가해야 합니다. 조만간 다양한 컨트롤러 구현이 등장할 것으로 예상되지만, 현재 사용할 수 있는 유일한 구현은 Google Compute Engine HTTP 부하 분산기용 컨트롤러이며, 이 컨트롤러는 Kubernetes를 Google Compute Engine 또는 Google Container Engine에서 실행하는 경우에만 작동합니다. 실제 부하 분산기가 고급 기능을 지원하더라도 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와 계속 동기화되어 포드 추가 또는 삭제와 같은 Kubernetes 서비스의 변경 사항을 반영하도록 해야 합니다. NGINX Open Source에서는 NGINX 구성 파일을 수동으로 수정하고 구성을 다시 로드합니다. NGINX Plus에서는 다음 두 가지 방법으로 구성을 동적으로 업데이트할 수 있습니다:

  • API 사용 – 이 방법은 NGINX Plus API를 사용하여 NGINX Plus 구성에서 Kubernetes Pod 항목을 추가 및 제거하고, Kubernetes API를 사용하여 Pod의 IP 주소를 가져옵니다. 이 방법을 사용하려면 코드를 작성해야 하며, 여기서는 자세히 다루지 않습니다. 자세한 내용은 Kelsey Hightower의 웨비나 NGINX Plus로 Kubernetes를 엣지까지 확장하기에서 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를 배치합니다. 이 Pod는 함께 설정하는 복제 컨트롤러에 의해 생성됩니다. Kubernetes 전용 NGINX Plus 구성 파일은 NGINX Plus Pod와 노드가 공유하는 폴더에 저장되므로 더욱 간편하게 유지 관리할 수 있습니다.

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

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

$ kubectl get nodesNAME         LABELS                              STATUS
10.245.1.3   Kubernetes.io/hostname=10.245.1.3   Ready
10.245.1.4   Kubernetes.io/hostname=10.245.1.4   Ready
10.245.1.5   Kubernetes.io/hostname=10.245.1.5   Ready

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

$ kubectl label node 10.245.1.3 role=nginxplus

NGINX Plus Pod용 복제 컨트롤러 구성

NGINX Plus Pod를 직접 생성하는 대신 복제 컨트롤러를 통해 생성합니다. NGINX Plus Pod용 복제 컨트롤러는 nginxplus-rc.yaml이라는 Kubernetes 선언 파일에서 구성합니다.

  • We set the number of replicas 수를 1로 설정합니다. 즉, Kubernetes는 NGINX Plus Pod 하나가 항상 실행되도록 보장하며, 해당 Pod에 장애가 발생하면 새 Pod로 교체합니다.
  • In the nodeSelector 필드에서 NGINX Plus Pod가 role: nginxplus 레이블이 지정된 노드에 생성되도록 지정합니다.
  • NGINX Plus 컨테이너는 80과 8080, 두 개의 포트를 노출하며, 이 포트들을 노드의 80 및 8080 포트에 각각 매핑합니다.
  • NGINX Plus 컨테이너는 노드에 있는 /etc/nginx/conf.d 폴더도 공유합니다. 아래의 NGINX Plus 구성에서 자세히 설명하듯이, 이 폴더를 공유하면 컨테이너 이미지를 다시 빌드하지 않고도 NGINX Plus를 재구성할 수 있습니다.
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginxplus-rc
spec:
  replicas: 1
  selector:
    app: nginxplus
  template:
    metadata:
      labels:
        app: nginxplus
    spec:
      nodeSelector:
        role: nginxplus
      containers:
      - name: nginxplus
        imagePullPolicy: IfNotPresent
        image: nginxplus
        ports:
          - name: http
            containerPort: 80
            hostPort: 80
          - name: http-alt
            containerPort: 8080
            hostPort: 8080
        volumeMounts:
          - mountPath: "/etc/nginx/conf.d"
            name: etc-nginx-confd
      volumes:
        - hostPath:
            path: "/etc/nginx/conf.d"
          name: etc-nginx-confd

노드에서 NGINX Plus Docker 이미지를 사용할 수 있도록 설정하기

앞서 설명한 대로 NGINX Plus Docker 이미지는 이미 빌드했습니다. 이제 이 이미지를 노드에서 사용할 수 있도록 준비합니다. 여기서는 간단하게 진행하기 위해 비공개 Docker 리포지토리를 사용하지 않고 이미지를 노드에 직접 로드합니다.

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

$ docker save -o nginxplus.tar nginxplus

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

$ docker load -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 서버를 정의합니다(다음 항목에서 설명하는 server 지시어는 upstream 블록 안에 있습니다). 이 DNS 서버는 도메인 이름인 kube-dns.kube-system.svc.cluster.local로 식별합니다. valid 매개변수는 NGINX Plus가 5초마다 재확인 요청을 보내도록 지정합니다. (이 지시어의 확인 프로세스는 업스트림 서버의 확인 프로세스와 다릅니다. 이 도메인 이름은 NGINX가 시작되거나 다시 로드될 때만 확인되며, NGINX Plus는 /etc/resolv.conf 파일에 정의된 시스템 DNS 서버를 사용하여 이 이름을 확인합니다.)
  • upstream – 노출하려는 Kubernetes 서비스를 제공하는 서버를 포함하도록 backend라는 업스트림 그룹을 생성합니다. 서버를 개별적으로 나열하는 대신 하나의 server 지시문에서 정규화된 호스트 이름으로 서버를 식별합니다. resolve 매개변수는 resolver 지시문에 지정된 설정에 따라 런타임에 호스트 이름을 다시 확인하도록 NGINX Plus에 지시합니다. Kubernetes DNS와 NGINX Plus(R10 이상)는 모두 DNS 서비스(SRV) 레코드를 지원하므로 NGINX Plus는 DNS를 통해 업스트림 서버의 포트 번호를 가져올 수 있습니다. NGINX Plus가 SRV 레코드를 요청하도록 service 매개변수를 포함하고, 서비스에서 노출하는 포트의 이름(_http)과 프로토콜(_tcp)을 지정합니다. 이러한 값은 아래의 서비스용 복제 컨트롤러 생성에서 설명하는 webapp-svc.yaml 파일에 선언합니다. DNS를 사용한 서비스 검색에 대한 자세한 내용은 블로그의 NGINX 및 NGINX Plus에서 DNS를 사용한 서비스 검색을 참조하세요.
  • server (두 번) – 두 개의 가상 서버를 정의합니다:
    • 첫 번째 서버는 포트 80에서 수신 대기하며 /webapp(이 예시의 서비스)로 들어오는 요청을 서비스 인스턴스가 실행 중인 파드에 분산합니다. 또한 능동 상태 확인도 설정합니다.
    • 두 번째 서버는 포트 8080에서 수신 대기합니다. 여기서는 NGINX Plus의 실시간 활동 모니터링을 설정합니다. 나중에 이를 사용하여 NGINX Plus가 올바르게 재구성되었는지 확인합니다. [편집자 – 이 두 번째 서버의 구성은 기존에 사용되던 별도의 상태 모듈을 대체하고 더 이상 사용되지 않도록 하는 NGINX Plus API를 사용하도록 업데이트되었습니다.]
resolver kube-dns.kube-system.svc.cluster.local valid=5s;

upstream backend {
    zone upstream-backend 64k;
    server webapp-svc.default.svc.cluster.local service=_http._tcp resolve;
}

server {
    listen 80;
    status_zone backend-servers;

    location /webapp {
        proxy_pass http://backend;
        health_check;
    }
}

server {
    listen 8080;
    root /usr/share/nginx/html;

    location = /dashboard.html { }

    location = / {
        return 302 /dashboard.html;
    }

    location /api {
        api write=on;
    }
}

레플리케이션 컨트롤러 생성

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

$ kubectl create -f nginxplus-rc.yaml

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

$ kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
nginxplus-rc-0ts5t   1/1       Running   0          17s

여기서는 로컬 Vagrant 환경에서 Kubernetes를 실행하고 있으므로 노드의 외부 IP 주소가 10.245.1.3임을 알고 있으며, 이 예제의 나머지 부분에서는 이 주소를 사용하겠습니다. 클라우드 제공업체에서 Kubernetes를 실행하고 있다면 다음 명령을 실행하여 노드의 외부 IP 주소를 확인할 수 있습니다:

$ kubectl get nodes node-name -o json | grep -i externalIP -A 1                "type": "ExternalIP",
                "address": XXX.XXX.XXX.XXX

클라우드에서 실행 중인 경우 NGINX Plus 노드가 인바운드 트래픽을 수신할 수 있도록 방화벽 규칙을 설정해야 합니다. 자세한 내용은 클라우드 제공업체의 설명서를 참조하세요.

노드의 외부 IP 주소에서 포트 8080으로 제공되는 NGINX Plus 실시간 활동 모니터링 대시보드를 확인하면 NGINX Plus Pod가 정상적으로 실행 중인지 확인할 수 있습니다(이 예에서는 http://10.245.1.3:8080/dashboard.html입니다). 하지만 아직 서비스를 생성하지 않았으므로 이 시점에 확인하면 서비스에 대한 서버가 표시되지 않습니다.

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

간단한 Kubernetes 서비스 만들기

이제 Kubernetes 서비스를 생성할 차례입니다. 이 서비스는 두 개의 웹 서버로 구성되며, 각 서버는 자신이 실행 중인 컨테이너에 대한 정보가 담긴 웹 페이지를 제공합니다.

서비스용 복제 컨트롤러 만들기

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

apiVersion: v1kind: ReplicationController
metadata:
  name: webapp-rc
spec:
  replicas: 2
  selector:
    app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: hello
        image: nginxdemos/hello 
        ports:
        - containerPort: 80

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

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

$ kubectl create -f webapp-rc.yaml

Pod가 생성되었는지 확인하려면 다음 명령어를 실행하면 됩니다. 레이블 선택자 app=webapp를 사용하여 이전 단계에서 복제 컨트롤러가 생성한 Pod만 가져옵니다:

$ kubectl get pods -l app=webapp
NAME             READY     STATUS    RESTARTS   AGE
webapp-rc-544f1   1/1       Running   0          2m
webapp-rc-uk6pm   1/1       Running   0          2m

서비스 생성

다음으로 복제 컨트롤러가 생성한 파드를 위한 서비스를 만듭니다. 다음 파일을 사용하여 서비스를 선언합니다(webapp-service.yaml):

apiVersion: v1kind: Service
metadata:
  name: webapp-svc
spec:
  clusterIP: None
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: webapp

여기서는 헤드리스 서비스라는 특수한 서비스를 선언하기 위해 ClusterIP 필드를 None으로 설정합니다. 이 유형의 서비스에는 클러스터 IP 주소가 할당되지 않으며 kube-proxy를 통해 서비스에 접근할 수 없습니다. Kubernetes DNS에 DNS 쿼리를 보내면 여러 개의 A 레코드(파드의 IP 주소)가 반환됩니다.

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

By setting the selector 필드를 app: webapp으로 설정하여 서비스에 속하는 Pod, 즉 NGINX 복제 컨트롤러(webapp-rc.yaml에 정의됨)가 생성한 Pod를 지정합니다.

다음 명령을 실행하여 서비스를 생성합니다:

$ kubectl create -f webapp-service.yaml

이제 대시보드 페이지를 새로 고친 후 오른쪽 상단의 Upstreams 탭을 클릭하면 추가한 두 서버가 표시됩니다.

Kubernetes 서비스가 생성된 후의 NGINX Plus 실시간 활동 모니터링 대시보드

NGINX Plus가 서비스의 Pod 간에 트래픽을 부하 분산하고 있는지도 확인할 수 있습니다. 부하 분산이 정상적으로 이루어지고 있다면 브라우저에서 http://10.245.1.3/webapp/에 접속했을 때 페이지에 호스트 이름, IP 주소 등 웹 서버가 실행 중인 컨테이너의 정보가 표시됩니다.

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

Kubernetes 서비스 확장

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

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

$ kubectl scale rc webapp-rc --replicas=4
scaled

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

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq{
  "peers": [
    {
      "id": 1,
      "server": "10.0.0.1:80",
      "backup": false,
      "weight": 1,
      "state": "unhealthy",
      "active": 0,
      "requests": 1,
      "responses": {
        "1xx": 0,
        "2xx": 0,
        "3xx": 0,
        "4xx": 0,
        "5xx": 0,
        "total": 0
      },
      "sent": 0,
      "received": 0,
      "fails": 0,
      "unavail": 0,
      "health_checks": {
        "checks": 1,
        "fails": 1,
        "unhealthy": 1,
        "last_passed": false
      },
      "downtime": 33965,
      "downstart": 1445378182275,
      "selected": 1445378131000
    },
    {
      "id": 2,
      "server": "10.246.1.6:80",
      ...
    },
    {
      "id": 3,
      "server": "10.246.3.2:80",
       ...
    {
      "id": 4,
      "server": "10.0.0.2:80",
      ...
    }
  ],
  "keepalive": 0
}

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

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

$ kubectl scale rc webapp-rc --replicas=1scaled

$ curl -s 10.245.1.3:8080/api/3/http/upstreams/backend/servers | jq

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

이제 NGINX Plus가 정상적으로 실행되고 있으므로 세션 지속성, SSL/TLS 종료, 요청 라우팅, 고급 모니터링, 그리고 기타 기능과 같은 고급 기능을 활용할 수 있습니다.

요약

NGINX Plus에서 제공하는 즉석 재구성 옵션을 사용하면 API를 통해 프로그래밍 방식으로 또는 전적으로 DNS를 통해 Kubernetes와 손쉽게 통합할 수 있습니다. NGINX Plus를 사용하여 Kubernetes 서비스를 인터넷에 노출하면 현재 Kubernetes에 내장된 부하 분산 솔루션에는 없는 다양한 기능을 활용할 수 있습니다.

NGINX Plus가 Kubernetes와 어떻게 연동되는지 알아보려면 지금 30일 무료 평가판을 시작하거나 문의하여 사용 사례에 대해 상담해 보세요.

공유
추천 블로그 게시물
클라우드 네이티브 기술, 플랫폼 엔지니어링 및 AI의 최신 동향F5 NGINX One을 통한 앱 및 API 제공의 전체 수명 주기 관리최신 애플리케이션 제공 간소화: F5 NGINX One과 함께한 9개월
태그: F5 NGINX, Tech, Application Delivery, Kubernetes (k8S)

작성자 소개

Michael Pleshakov
Michael Pleshakov

Michael Pleshakov의 다른 블로그 게시물

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.

실행 위치와 관계없이 모든 애플리케이션과 API를 제공하고 보호하세요
F5는 현대 디지털 비즈니스가 운영되는 복잡한 환경 전반에서 애플리케이션과 API를 빠르고, 가용성이 높으며, 안전하게 유지합니다. F5 Application Delivery and Security Platform에 대해 자세히 알아보세요.
F5와 소통하기