커뮤니티 Ingress Controller에서 F5 NGINX Ingress Controller로 마이그레이션하기

NGINX | 2022년 5월 19일
Amir Rawdat
Amir Rawdat솔루션 엔지니어

편집자 – 이 게시물은 종합 전자책인 F5 NGINX를 활용한 Kubernetes 트래픽 관리: 실용 가이드에서 발췌한 내용입니다. 지금 무료로 다운로드하세요.

Kubernetes를 처음 구축하는 많은 조직은 Kubernetes 커뮤니티에서 개발하고 유지 관리하는 NGINX Ingress 컨트롤러(kubernetes/ingress-nginx)로 시작합니다. 하지만 Kubernetes 배포 환경이 성숙해짐에 따라 일부 조직은 NGINX를 데이터 플레인으로 유지하면서 고급 기능이나 상용 지원이 필요하다는 사실을 깨닫게 됩니다.

한 가지 방법은 F5 NGINX에서 개발하고 유지 관리하는 NGINX Ingress Controller(nginxinc/kubernetes-ingress)로 마이그레이션하는 것입니다. 여기서는 두 프로젝트 간의 차이로 인해 발생할 수 있는 몇 가지 문제를 방지할 수 있도록 전체 지침을 제공합니다.

이러한 옵션의 차이점을 잘 모르시겠나요? 인그레스 컨트롤러 선택 가이드, 4부: NGINX 인그레스 컨트롤러 옵션 블로그 게시물을 읽어보세요.

이 글의 나머지 부분에서는 두 프로젝트를 구분하기 위해 Kubernetes 커뮤니티에서 유지 관리하는 NGINX Ingress Controller(kubernetes/ingress-nginx)를 ‘커뮤니티 Ingress 컨트롤러’로, F5 NGINX에서 유지 관리하는 컨트롤러(nginxinc/kubernetes-ingress)를 ‘NGINX Ingress Controller’로 지칭합니다.

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress Controller로 마이그레이션하는 방법은 두 가지입니다:

옵션 1: NGINX Ingress 리소스를 사용하여 마이그레이션

이 마이그레이션 옵션에서는 표준 Kubernetes Ingress 리소스를 사용하여 기본 기능을 설정하고, NGINX Ingress 리소스를 사용하여 기능과 사용 편의성을 높이도록 구성을 개선합니다.

NGINX Ingress 리소스의 사용자 정의 리소스 정의(CRD)인 VirtualServer, VirtualServerRoute, TransportServer, GlobalConfiguration, Policy를 사용하면 구성의 여러 부분에 대한 제어 권한을 다양한 팀(예: AppDev 및 보안 팀)에 손쉽게 위임할 수 있을 뿐만 아니라, 구성의 안전성과 유효성 검사를 강화할 수 있습니다.

SSL 종료 및 HTTP 경로 기반 라우팅 구성

이 표는 표준 Kubernetes Ingress 리소스의 spec 필드에 있는 SSL 종료 및 계층 7 경로 기반 라우팅 구성을 NGINX spec 리소스의 VirtualServer 필드와 대응시킵니다. 두 리소스의 구문과 들여쓰기는 약간 다르지만, 기본적으로 동일한 Ingress 기능을 수행합니다.

Kubernetes Ingress 리소스 NGINX VirtualServer 리소스 
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: nginx-testspec:  tls:    - hosts:      - foo.bar.com      secretName: tls-secret  rules:    - host: foo.bar.com      http:        paths:        - path: /login          backend:             serviceName: login-svc            servicePort: 80        - path: /billing            serviceName: billing-svc            servicePort: 80

apiVersion: networking.k8s.io/v1kind: VirtualServermetadata:  name: nginx-testspec:  host: foo.bar.com   tls:    secret: tls-secret  upstreams:    - name: login      service: login-svc      port: 80    - name: billing       service: billing-svc      port: 80  routes:   - path: /login    action:      pass: login   - path: /billing     action:       pass: billing

TCP/UDP 부하 분산 및 TLS 패스스루 구성

커뮤니티 Ingress 컨트롤러를 사용하는 경우 Kubernetes ConfigMap API 객체가 TCP 및 UDP 서비스를 노출하는 유일한 방법입니다.

NGINX Ingress Controller에서는 TransportServer 리소스를 통해 TCP/UDP 및 TLS 패스스루 부하 분산을 위한 다양한 옵션을 정의합니다. TransportServer 리소스는 GlobalConfiguration 리소스와 함께 사용하여 인바운드 및 아웃바운드 연결을 제어합니다.

자세한 내용은 블로그의 NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루 서비스 지원 문서를 참조하세요.

커뮤니티 Ingress Controller 주석을 NGINX Ingress 리소스로 변환

프로덕션급 Kubernetes 배포에서는 카나리 및 블루-그린 배포, 트래픽 제한, 인그레스-이그레스 트래픽 조작 등의 고급 사용 사례를 구현하기 위해 기본 Ingress 규칙을 확장해야 하는 경우가 많습니다.

커뮤니티 Ingress 컨트롤러는 이러한 사용 사례 중 다수를 Kubernetes 어노테이션을 사용하여 구현합니다. 그러나 이러한 어노테이션 중 상당수는 매우 구체적인 NGINX Ingress 리소스 정의에만 적용되는 사용자 지정 Lua 확장 기능으로 구축되었으므로, 안정적이고 지원되는 프로덕션 환경에서 고급 기능을 구현하는 데 적합하지 않습니다.

다음 섹션에서는 커뮤니티 Ingress 컨트롤러의 어노테이션을 NGINX Ingress Controller 리소스로 변환하는 방법을 설명합니다.

카나리 배포

프로덕션 컨테이너 워크로드에 코드 변경 사항을 자주 배포하는 중에도 기존 사용자에게 서비스를 계속 제공해야 합니다. 카나리 배포와 블루-그린 배포를 사용하면 이를 실현할 수 있으며, NGINX Ingress Controller 데이터 플레인에서 이러한 배포를 수행하여 프로덕션급 Kubernetes 환경에서 안정적이고 예측 가능한 업데이트를 구현할 수 있습니다.

이 표는 NGINX VirtualServer 및 VirtualServerRoute 리소스에서 커뮤니티 Ingress 컨트롤러의 카나리 배포용 어노테이션에 해당하는 필드를 보여줍니다.

커뮤니티 Ingress 컨트롤러는 다음 우선순위에 따라 카나리 어노테이션을 평가합니다:

  1. nginx.ingress.kubernetes.io/canary-by-header
  2. nginx.ingress.kubernetes.io/canary-by-cookie
  3. nginx.ingress.kubernetes.io/canary-by-weight

NGINX Ingress Controller가 동일한 방식으로 평가하려면 NGINX VirtualServer 또는 VirtualServerRoute 매니페스트에 해당 순서대로 표시되어야 합니다.

커뮤니티 Ingress Controller NGINX Ingress Controller 
				nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"
				
				matches:- conditions:  - header: httpHeader      value: never  action:    pass: echo   - header: httpHeader      value: always  action:    pass: echo-canaryaction:  pass: echo
				
				nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"nginx.ingress.kubernetes.io/canary-by-header-value: "my-value"
				
				matches:- conditions:  - header: httpHeader      value: my-value  action:    pass: echo-canary action:  pass: echo
				
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"
				
				matches:- conditions:  - cookie: cookieName      value: never  action:    pass: echo   - cookie: cookieName      value: always  action:    pass: echo-canaryaction:  pass: echo
				
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"
				
splits:- weight: 90   action:    pass: echo- weight: 10    action:     pass: echo-canary

트래픽 제어

애플리케이션이 본질적으로 일시적이어서 오류 응답을 반환할 가능성이 더 높은 마이크로서비스 환경에서 DevOps 팀은 애플리케이션이 비정상 상태이거나 예상대로 작동하지 않을 때 오류가 발생하지 않도록 회로 차단, 요청 속도 제한, 연결 제한 등의 트래픽 제어 정책을 광범위하게 활용합니다.

이 표에는 NGINX VirtualServer 및 VirtualServerRoute 리소스에서 커뮤니티 Ingress 컨트롤러의 다음 주석에 해당하는 필드가 나와 있습니다: 속도 제한, 사용자 지정 HTTP 오류, 사용자 지정 기본 백엔드, URI 재작성.

Community Ingress Controller NGINX Ingress Controller 
nginx.ingress.kubernetes.io/custom-http-errors: "code"nginx.ingress.kubernetes.io/default-backend: "default-svc"
				
				errorPages:- codes: [code]    redirect:      code: 301      url: default-svc
				
				nginx.ingress.kubernetes.io/limit-connections: "number"
				
				http-snippets: |    limit_conn_zone $binary_remote_addr zone=zone_name:size;routes:- path: /path    location-snippets: |      limit_conn zone_name number;
				
				nginx.ingress.kubernetes.io/limit-rate: "number"nginx.ingress.kubernetes.io/limit-rate-after: "number"
				
location-snippets: |    limit_rate number;    limit_rate_after number;
				
nginx.ingress.kubernetes.io/limit-rpm: "number"nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
				
				rateLimit:    rate: numberr/m    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				
nginx.ingress.kubernetes.io/limit-rps: "number"nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
				
rateLimit:    rate: numberr/s    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				
				nginx.ingress.kubernetes.io/limit-whitelist: "CIDR"
				
				http-snippets: |server-snippets: |
				
nginx.ingress.kubernetes.io/rewrite-target: "URI"
				
rewritePath: "URI"

표에 나와 있듯이, 이 글을 작성하는 현재 NGINX Ingress 리소스에는 다음 네 가지 커뮤니티 Ingress 컨트롤러 어노테이션을 직접 변환하는 필드가 없으므로 스니펫을 사용해야 합니다. Policy 리소스를 사용하여 이 네 가지 어노테이션을 직접 지원하는 기능은 NGINX Ingress Controller의 향후 릴리스에 추가될 예정입니다.

  • nginx.ingress.kubernetes.io/limit-connections
  • nginx.ingress.kubernetes.io/limit-rate
  • nginx.ingress.kubernetes.io/limit-rate-after
  • nginx.ingress.kubernetes.io/limit-whitelist

헤더 조작

HTTP 헤더에는 HTTP 트랜잭션에 관여하는 시스템에 중요하고 관련성 높은 추가 정보가 포함되어 있으므로, 다양한 사용 사례에서 HTTP 헤더를 조작하는 것이 유용합니다. 예를 들어, 커뮤니티 Ingress 컨트롤러는 교차 출처 리소스 공유(CORS) 헤더를 활성화하고 설정하는 기능을 지원합니다. 이 헤더는 브라우저의 프런트엔드 JavaScript 코드가 백엔드 앱이나 웹 서버에 연결되는 AJAX 애플리케이션에서 사용됩니다.

이 표에는 NGINX VirtualServer 및 VirtualServerRoute 리소스에서 커뮤니티 Ingress 컨트롤러의 헤더 조작 어노테이션에 해당하는 필드가 나와 있습니다.

커뮤니티 Ingress 컨트롤러 NGINX Ingress 컨트롤러 
				nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-credentials: "true"nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"nginx.ingress.kubernetes.io/cors-allow-origin: "*"nginx.ingress.kubernetes.io/cors-max-age: "seconds"
				
				responseHeaders:  add:     - name: Access-Control-Allow-Credentials      value: "true"     - name: Access-Control-Allow-Headers      value: "X-Forwarded-For"    - name: Access-Control-Allow-Methods      value: "PUT, GET, POST, OPTIONS"    - name: Access-Control-Allow-Origin      value: "*"    - name: Access-Control-Max-Age      value: "seconds"

프록시 및 부하 분산

특정 사용 사례에 따라 NGINX Ingress Controller에서 다른 프록시 및 부하 분산 기능을 구성해야 할 수도 있습니다. 이러한 기능에는 부하 분산 알고리즘 설정뿐만 아니라 프록시 연결의 시간 제한 및 버퍼링 설정도 포함됩니다.

이 표는 커뮤니티 Ingress 컨트롤러의 다음 어노테이션에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스의 upstream 필드 구문을 보여줍니다: 사용자 지정 NGINX 부하 분산, 프록시 시간 제한, 프록시 버퍼링, 서비스의 Cluster IP 주소 및 포트로 연결 라우팅.

커뮤니티 Ingress 컨트롤러 NGINX Ingress 컨트롤러 
nginx.ingress.kubernetes.io/load-balance
				
				lb-method
				
				nginx.ingress.kubernetes.io/proxy-buffering
				
buffering
				
				nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size
				
				buffers
				
				nginx.ingress.kubernetes.io/proxy-connect-timeout
				
				connect-timeout
				
				nginx.ingress.kubernetes.io/proxy-next-upstream
				
				next-upstream
				
				nginx.ingress.kubernetes.io/proxy-next-upstream-timeout
				
				next-upstream-timeout
				
				nginx.ingress.kubernetes.io/proxy-read-timeout
				
read-timeout
				
				nginx.ingress.kubernetes.io/proxy-send-timeout
				
				send-timeout
				
				nginx.ingress.kubernetes.io/service-upstream
				
				use-cluster-ip

mTLS 인증

A 서비스 메시는 엄격한 제로 트러스트 환경에서 특히 유용합니다. 이러한 환경에서는 클러스터 내부의 분산 애플리케이션이 상호 인증을 통해 안전하게 통신합니다. 그렇다면 클러스터로 들어오고 나가는 트래픽(남북 트래픽)에도 동일한 수준의 보안을 적용해야 한다면 어떻게 해야 할까요?

Ingress Controller 계층에서 mTLS 인증을 구성하면 외부 연결의 양쪽 엔드 시스템이 유효한 인증서를 제시하여 서로를 인증하도록 할 수 있습니다.

이 표에는 NGINX Policy 리소스에서 커뮤니티 Ingress 컨트롤러의 클라이언트 인증서 인증 및 백엔드 인증서 인증 어노테이션에 해당하는 필드가 나와 있습니다.

커뮤니티 Ingress 컨트롤러 NGINX Ingress 컨트롤러 
				nginx.ingress.kubernetes.io/auth-tls-secret: secretNamenginx.ingress.kubernetes.io/auth-tls-verify-client: "on"nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
				
				ingressMTLS:   clientCertSecret: secretName   verifyClient: "on"   verifyDepth: 1
				
nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName"nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off"nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1"nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2"nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "DEFAULT"nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name"nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off"
				
egressMTLS:   tlsSecret: secretName   verifyServer: true|false   verifyDepth: 1   protocols: TLSv1.2   ciphers: DEFAULT   sslName: server-name   serverName: true|false

세션 지속성(NGINX Plus 전용)

다음 표에서는 NGINX Policy 리소스의 필드 중 NGINX Plus 기반 NGINX Ingress Controller에서만 사용할 수 있으며 커뮤니티 Ingress Controller의 세션 지속성(어피니티) 어노테이션에 해당하는 필드를 보여줍니다.

커뮤니티 Ingress 컨트롤러 NGINX Ingress 컨트롤러 
nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookieName"nginx.ingress.kubernetes.io/session-cookie-expires: "x"nginx.ingress.kubernetes.io/session-cookie-path: "/route"nginx.ingress.kubernetes.io/session-cookie-secure: "true"
				
sessionCookie:  enable: true  name: cookieName  expires: xh  path: /route  secure: true

옵션 2: Kubernetes Ingress 리소스를 사용하여 마이그레이션

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress Controller로 마이그레이션하는 두 번째 방법은 표준 Kubernetes Ingress 리소스에서 어노테이션과 ConfigMap만 사용하고, 필요에 따라 마스터/미니언 방식의 처리를 활용하는 것입니다. 이렇게 하면 모든 구성이 Ingress 객체에 유지됩니다.

참고: 이 방법을 사용할 때는 Ingress 리소스의 spec 필드를 변경하지 마세요.

어노테이션을 사용한 고급 구성

다음 표에서는 NGINX Ingress Controller에서 지원하는 어노테이션에 직접 대응하는 커뮤니티 Ingress 컨트롤러 어노테이션을 설명합니다.

Community Ingress Controller NGINX Ingress Controller NGINX Directive
N/A
Default:

 

				random two least_conn
				
nginx.org/rewrites: "serviceName=svc rewrite=URI"
N/A
N/A2

1커뮤니티 Ingress 컨트롤러는 일부 부하 분산 알고리즘을 구현하는 데 Lua를 사용합니다. NGINX Ingress Controller에는 이 모든 알고리즘에 대응하는 기능이 있는 것은 아닙니다.

2HTTP 트래픽을 HTTPS로 리디렉션합니다. 커뮤니티 Ingress 컨트롤러는 Lua 코드로 이를 구현하는 반면, NGINX Ingress Controller는 NGINX의 기본 if 조건을 사용합니다.

다음 표에서는 NGINX Plus 기반 NGINX Ingress Controller에서 지원하는 어노테이션과 직접 대응하는 커뮤니티 Ingress 컨트롤러 어노테이션을 설명합니다.

커뮤니티 Ingress 컨트롤러 NGINX Plus 기반 NGINX Ingress 컨트롤러 
				nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"

참고: NGINX Plus 기반 NGINX Ingress Controller에는 커뮤니티 Ingress Controller에서 전혀 지원하지 않는 기능을 위한 추가 어노테이션이 있습니다. 여기에는 능동 상태 확인 및 JSON Web Token을 사용한 인증(JWT)이 포함됩니다.

ConfigMap을 사용한 전역 구성

다음 표는 커뮤니티 Ingress 컨트롤러의 ConfigMap 키와 이에 직접 대응하는 NGINX Ingress Controller의 ConfigMap 키를 보여줍니다. 일부 ConfigMap 키 이름은 동일합니다. 또한 커뮤니티 Ingress 컨트롤러와 NGINX Ingress Controller에는 각각 상대방에는 없는 ConfigMap 키도 있습니다(표에는 표시되지 않음).

Community Ingress ControllerNGINX Ingress Controller
disable-access-log
access-log-off
error-log-level
error-log-level
hsts
hsts
hsts-include-subdomains
hsts-include-subdomains
hsts-max-age
hsts-max-age
http-snippet
http-snippets
keep-alive
keepalive-timeout
keep-alive-requests
keepalive-requests
load-balance
lb-method
location-snippet
location-snippets
log-format-escape-json: "true"
log-format-escaping: "json"
log-format-stream
stream-log-format
log-format-upstream
log-format
main-snippet
main-snippets
max-worker-connections 
worker-connections
max-worker-open-files
worker-rlimit-nofile
proxy-body-size
client-max-body-size
proxy-buffering
proxy-buffering
proxy-buffers-number: "number"proxy-buffer-size: "size"
proxy-buffers: number size
proxy-connect-timeout
proxy-connect-timeout
proxy-read-timeout
proxy-read-timeout
proxy-send-timeout
proxy-send-timeout
server-name-hash-bucket-size
server-names-hash-bucket-size
server-name-hash-max-size
server-names-hash-max-size
server-snippet
server-snippets
server-tokens
server-tokens
ssl-ciphers
ssl-ciphers
ssl-dh-param
ssl-dhparam-file
ssl-protocols
ssl-protocols
ssl-redirect
ssl-redirect
upstream-keepalive-connections
keepalive
use-http2
http2
use-proxy-protocol
proxy-protocol
variables-hash-bucket-size
variables-hash-bucket-size
worker-cpu-affinity
worker-cpu-affinity
worker-processes
worker-processes
worker-shutdown-timeout
worker-shutdown-timeout

요약

커스텀 NGINX Ingress 리소스 또는 어노테이션 및 ConfigMap이 포함된 표준 Kubernetes Ingress 리소스를 사용하여 커뮤니티 Ingress 컨트롤러에서 NGINX Ingress Controller로 마이그레이션할 수 있습니다. 전자는 더 광범위한 네트워킹 기능을 지원하므로 프로덕션급 Kubernetes 환경에 더 적합합니다.

이 게시물은 당사의 종합 전자책 F5 NGINX를 활용한 Kubernetes 트래픽 관리: 실용 가이드에서 발췌한 내용입니다. 지금 무료로 다운로드하세요.

NGINX Plus 기반 NGINX Ingress Controller를 30일 무료 평가판으로 지금 직접 사용해 보거나, 문의하여 사용 사례에 대해 상담해 보세요.

공유
추천 블로그 게시물
클라우드 네이티브 기술, 플랫폼 엔지니어링 및 AI의 최신 동향F5 NGINX One을 통한 앱 및 API 제공의 전체 수명 주기 관리최신 애플리케이션 제공 간소화: F5 NGINX One과 함께한 9개월
태그: F5 NGINX, Tech, Kubernetes (k8S), F5 NGINX Ingress Controller, Learn, BIG-IP Container Ingress Services, Networking for Kubernetes, BIG-IP Next for Kubernetes, F5 Distributed Cloud Load Balancer & K8s Gateway

작성자 소개

Amir Rawdat
Amir Rawdat솔루션 엔지니어

Amir Rawdat의 다른 블로그 게시물

관련 블로그 게시물

시청하기: 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와 소통하기