블로그 | NGINX

커뮤니티 Ingress 컨트롤러에서 F5 NGINX Ingress 컨트롤러로 마이그레이션

NGINX-F5-수평-검정-유형-RGB의 일부
아미르 라우드닷 썸네일
아미르 라우드다트
2022년 5월 19일 게시

편집자 - 이 게시물은 F5 NGINX를 사용하여 Kubernetes 트래픽 관리라는 포괄적인 eBook에서 발췌한 것입니다. 실용 가이드 오늘 무료로 다운로드하세요 .

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

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

이러한 옵션이 어떻게 다른지 모르시겠습니까? Ingress 컨트롤러 선택 가이드 읽기, 4부: NGINX Ingress 컨트롤러 옵션 우리의 블로그에서.

이 게시물의 나머지 부분에서 두 프로젝트를 구별하기 위해 Kubernetes 커뮤니티( kubernetes/ingress-nginx )에서 유지 관리하는 NGINX Ingress Controller를 "커뮤니티 Ingress 컨트롤러"라고 하고 F5 NGINX( nginxinc/kubernetes-ingress )에서 유지 관리하는 NGINX Ingress 컨트롤러를 "NGINX Ingress 컨트롤러"라고 합니다.

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 방법에는 두 가지가 있습니다.

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

이 마이그레이션 옵션을 사용하면 표준 Kubernetes Ingress 리소스를 사용하여 루트 기능을 설정하고 NGINX Ingress 리소스를 사용하여 구성을 개선하여 기능을 향상시키고 사용 편의성을 높일 수 있습니다.

NGINX Ingress 리소스( VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration 및 Policy )에 대한 사용자 정의 리소스 정의(CRD)를 사용하면 구성의 다양한 부분에 대한 제어를 다양한 팀(예: AppDev 및 보안 팀)에 쉽게 위임할 수 있으며, 구성 안전성과 유효성 검사도 더욱 강화할 수 있습니다.

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

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

쿠버네티스 인그레스 리소스 NGINX VirtualServer 리소스 
api 버전: networking.k8s.io/v1kind: Ingress
메타데이터:
이름: nginx-test
사양:
tls:
- 호스트:
- foo.bar.com
secretName: tls-secret
규칙:
- 호스트: foo.bar.com
http:
경로:
- 경로: /login
백엔드: 
서비스 이름: login-svc
서비스 포트: 80
- 경로: /청구
서비스 이름: 청구-서비스
서비스 포트: 80

api 버전: networking.k8s.io/v1kind: VirtualServer
메타데이터:
이름: nginx-test
스펙:
호스트: foo.bar.com 
tls:
비밀: tls-secret
업스트림:
- 이름: 로그인
서비스: login-svc
포트: 80
- 이름: 청구
서비스: 청구-서비스
포트: 80
경로: 
- 경로: /login
작업:
패스: 로그인 
- 경로: /billing 
작업: 
패스: 청구

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

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

NGINX Ingress Controller를 사용하면 TransportServer 리소스가 TCP/UDP 및 TLS Passthrough 부하 분산을 위한 광범위한 옵션을 정의합니다. TransportServer 리소스는 GlobalConfiguration 리소스와 함께 사용되어 인바운드 및 아웃바운드 연결을 제어합니다.

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

커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 리소스로 변환

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

커뮤니티 Ingress 컨트롤러는 Kubernetes 주석을 사용하여 이러한 사용 사례의 대부분을 구현합니다. 그러나 이러한 주석 중 다수는 매우 구체적인 NGINX Ingress 리소스 정의와 관련된 사용자 정의 Lua 확장을 사용하여 작성되었으며, 결과적으로 안정적이고 지원되는 프로덕션 환경에서 고급 기능을 구현하는 데 적합하지 않습니다.

다음 섹션에서는 커뮤니티 Ingress 컨트롤러 주석을 NGINX Ingress 컨트롤러 리소스로 변환하는 방법을 보여줍니다.

카나리아 배포

프로덕션 컨테이너 워크로드에 빈번한 코드 변경을 적용하는 경우에도 기존 사용자에게 계속 서비스를 제공해야 합니다. Canary 및 Blue‑Green 배포를 사용하면 이를 수행할 수 있으며, NGINX Ingress Controller 데이터 플레인에서 이를 수행하여 프로덕션 등급 Kubernetes 환경에서 안정적이고 예측 가능한 업데이트를 달성할 수 있습니다.

이 표에서는 카나리아 배포를 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스의 필드를 보여줍니다.

커뮤니티 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 매니페스트에 해당 순서대로 나타나야 합니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
nginx.ingress.kubernetes.io/canary: "참"nginx.ingress.kubernetes.io/canary-by-header: "http헤더"

일치 :- 조건: - 헤더: httpHeader 값: 절대로 안 됨 작업: 통과: echo - 헤더: httpHeader 값: 항상 작업: 통과: echo-canary 작업: 통과: echo

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "http헤더" nginx.ingress.kubernetes.io/canary-by-header-value: " 내 값 "

일치:- 조건:- 헤더: httpHeader 값: my-value 작업: 통과: echo-canary 작업: 통과: echo

nginx.ingress.kubernetes.io/canary: "참"nginx.ingress.kubernetes.io/canary-by-cookie: "쿠키 이름"

일치:- 조건:
- 쿠키: cookieName
값: never
작업:
통과: echo 
- 쿠키: cookieName
값: always
작업:
통과: echo-canary
작업:
통과: echo

nginx.ingress.kubernetes.io/canary: "참"nginx.ingress.kubernetes.io/canary-weight: "10"

분할 :- 무게: 90 액션: 패스: 에코 - 무게: 10 액션: 패스: 에코 카나리아

교통 통제

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

이 표에서는 속도 제한 , 사용자 정의 HTTP 오류 , 사용자 정의 기본 백엔드 및 URI 재작성을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스의 필드를 보여줍니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
nginx.ingress.kubernetes.io/custom-http-errors: " 코드 " nginx.ingress.kubernetes.io/default-backend: "기본-서비스"

errorPages :- 코드: [ 코드 ] 리디렉션: 코드: 301 url: 기본 서비스

nginx.ingress.kubernetes.io/limit-connections: " 숫자 "

http-snippets : | limit_conn_zone $binary_remote_addr zone = zone_name : 크기 ; 경로: - 경로: / 경로 위치-snippets : | limit_conn zone_name 숫자 ;

nginx.ingress.kubernetes.io/limit-rate: " 숫자 " nginx.ingress.kubernetes.io/limit-rate-after: " 숫자 "

위치 스니펫: | limit_rate 숫자 ; limit_rate_after 숫자 ;

nginx.ingress.kubernetes.io/limit-rpm: " 숫자 " nginx.ingress.kubernetes.io/limit-burst-multiplier: " 배율 "

rateLimit : 속도: 숫자 r/m 버스트: 숫자 * 승수 키:${binary_remote_addr} zoneSize: 크기

nginx.ingress.kubernetes.io/limit-rps: " 숫자 " nginx.ingress.kubernetes.io/limit-burst-multiplier: " 배율 "

rateLimit: 비율: 숫자 r/s 버스트: 숫자 * 승수 키:${binary_remote_addr} zoneSize: 크기

nginx.ingress.kubernetes.io/limit-whitelist: " CIDR "

http-스니펫: | 서버-스니펫 : |

nginx.ingress.kubernetes.io/rewrite-target: " URI "

다시 쓰기 경로 : " URI "

표에 표시된 대로, 이 글을 쓰는 시점에서 NGINX Ingress 리소스에는 다음 네 가지 커뮤니티 Ingress 컨트롤러 주석을 직접 변환하는 필드가 포함되어 있지 않으며, 스니펫을 사용해야 합니다. NGINX Ingress Controller의 향후 릴리스에서는 정책 리소스를 사용하여 4개의 주석에 대한 직접 지원이 계획되어 있습니다.

  • 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 트랜잭션에 관련된 시스템에 중요하고 관련성 있는 추가 정보가 포함되어 있기 때문입니다. 예를 들어, 커뮤니티 Ingress 컨트롤러는 브라우저의 프런트엔드 JavaScript 코드가 백엔드 앱이나 웹 서버에 연결되는 AJAX 애플리케이션에서 사용되는 CORS( 교차 출처 리소스 공유 ) 헤더를 활성화하고 설정하는 것을 지원합니다.

이 표는 헤더 조작을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스의 필드를 보여줍니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
nginx.ingress.kubernetes.io/enable-cors: "참" nginx.ingress.kubernetes.io/cors-allow-credentials: "참" 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: " 초 "

responseHeaders : 추가: - 이름: Access-Control-Allow-Credentials 값: "true" - 이름: Access-Control-Allow-Headers 값: "X-Forwarded-For" - 이름: Access-Control-Allow-Methods 값: "PUT, GET, POST, OPTIONS" - 이름: Access-Control-Allow-Origin 값: "*" - 이름: Access-Control-Max-Age 값: " 초 "

프록싱 및 로드 밸런싱

특정 사용 사례에 따라 NGINX Ingress Controller에서 다른 프록싱 및 부하 분산 기능을 구성할 수도 있습니다. 이러한 기능에는 부하 분산 알고리즘 설정은 물론 프록시 연결에 대한 시간 초과 및 버퍼링 설정이 포함됩니다.

이 표에서는 사용자 정의 NGINX 부하 분산 , 프록시 시간 초과 , 프록시 버퍼링 , 서비스의 클러스터 IP 주소 및 포트에 대한 라우팅 연결 에 대한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX VirtualServer 및 VirtualServerRoute 리소스의 업스트림 필드에 있는 명령문을 보여줍니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
nginx.ingress.kubernetes.io/load-balance

lb-방법

nginx.ingress.kubernetes.io/proxy-buffering

버퍼링

nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size

버퍼

nginx.ingress.kubernetes.io/proxy-connect-timeout

연결-시간 초과

nginx.ingress.kubernetes.io/proxy-next-upstream

다음 상류

nginx.ingress.kubernetes.io/proxy-next-upstream-timeout

다음-상류-타임아웃

nginx.ingress.kubernetes.io/proxy-read-timeout

읽기 시간 초과

nginx.ingress.kubernetes.io/proxy-send-timeout

보내기-시간 초과

nginx.ingress.kubernetes.io/service-upstream

클러스터 IP 사용

mTLS 인증

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

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

이 표는 클라이언트 인증서 인증 과 백엔드 인증서 인증을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당하는 NGINX 정책 리소스의 필드를 보여줍니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 

nginx.ingress.kubernetes.io/auth-tls-secret: 비밀 이름
nginx.ingress.kubernetes.io/auth-tls-verify-client: "켜짐"
nginx.ingress.kubernetes.io/auth-tls-verify-깊이: "1"

ingressMTLS : clientCertSecret: secretName verifyClient: "on" verifyDepth: 1

nginx.ingress.kubernetes.io/프록시-SSL-비밀: "비밀 이름"
nginx.ingress.kubernetes.io/프록시-SSL-검증: "켜기|끄기"
nginx.ingress.kubernetes.io/프록시-SSL-검증-심도: "1"
nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2"
nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "기본"
nginx.ingress.kubernetes.io/proxy-ssl-name: "서버 이름"
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "켜기|끄기"

egressMTLS : tlsSecret: secretName verifyServer: true|false verifyDepth: 1 프로토콜: TLSv1.2 암호: DEFAULT sslName: 서버 이름 serverName: true|false

세션 지속성(NGINX Plus에만 제공)

이 표는 NGINX Plus 기반 NGINX Ingress Controller에서만 사용되는 NGINX 정책 리소스의 필드를 보여주며, 세션 지속성 (친화성)을 위한 커뮤니티 Ingress 컨트롤러 주석에 해당합니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
nginx.ingress.kubernetes.io/affinity: "쿠키" nginx.ingress.kubernetes.io/세션-쿠키-이름: "쿠키 이름" nginx.ingress.kubernetes.io/세션-쿠키-만료: " x " nginx.ingress.kubernetes.io/세션-쿠키-경로: "/경로" nginx.ingress.kubernetes.io/세션-쿠키-보안: "참"

sessionCookie : enable: true 이름: cookieName 만료: x h 경로: /route 보안: true

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

커뮤니티 Ingress 컨트롤러에서 NGINX Ingress 컨트롤러로 마이그레이션하는 두 번째 옵션은 표준 Kubernetes Ingress 리소스에서 주석 과 ConfigMap 만 사용하고 잠재적으로 마스터/미니언 "‑스타일 처리"에 의존하는 것입니다. 이렇게 하면 모든 구성이 Ingress 객체에 유지됩니다.

메모: 이 방법을 사용하면 Ingress 리소스의 spec 필드를 변경하지 않습니다.

주석이 있는 고급 구성

다음 표는 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller NGINX 지침 
nginx.ingress.kubernetes.io/configuration-snippet : |

nginx.org/location-snippets : |
없음 
nginx.ingress.kubernetes.io/load-balance1

nginx.org/lb-메소드
기본:

 

랜덤 두 개의 least_conn

nginx.ingress.kubernetes.io/proxy-buffering : "켜기|끄기"

nginx.org/proxy-buffering : "참|거짓"

프록시 버퍼링

nginx.ingress.kubernetes.io/proxy-buffers-number : " 숫자 " nginx.ingress.kubernetes.io/proxy-buffer-size : " x k"

nginx.org/proxy-buffers : " 숫자 4k|8k" nginx.org/proxy-buffer-size : "4k|8k"

프록시 버퍼 프록시 버퍼 크기

nginx.ingress.kubernetes.io/proxy-connect-timeout : " 초 "

nginx.org/proxy-connect-timeout: : " 초 "

프록시 연결 시간 초과

nginx.ingress.kubernetes.io/proxy-read-timeout : " 초 "

nginx.org/proxy-read-timeout : " 초 "

프록시_읽기_시간 초과

nginx.ingress.kubernetes.io/proxy-send-timeout : " 초 "

nginx.org/proxy-send-timeout : " 초 "

프록시_전송_타임아웃

nginx.ingress.kubernetes.io/rewrite-target : " URI "

nginx.org/rewrites : "serviceName= svc rewrite= URI "

고쳐 쓰기

nginx.ingress.kubernetes.io/server-snippet : |

nginx.org/server-snippets : |
없음 
nginx.ingress.kubernetes.io/ssl-redirect : "참|거짓"

ingress.kubernetes.io/ssl-redirect : "참|거짓"
없음2

1커뮤니티 Ingress 컨트롤러는 Lua를 사용하여 일부 부하 분산 알고리즘을 구현합니다. NGINX Ingress Controller에는 이들 모두에 대응하는 컨트롤러가 없습니다.

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

다음 표는 NGINX Plus 기반 NGINX Ingress Controller에서 지원하는 주석에 직접 해당하는 커뮤니티 Ingress 컨트롤러 주석을 간략하게 설명합니다.

커뮤니티 인그레스 컨트롤러 NGINX Plus 기반 NGINX Ingress 컨트롤러 
nginx.ingress.kubernetes.io/affinity : "쿠키" nginx.ingress.kubernetes.io/session-cookie-name : " 쿠키 이름 " nginx.ingress.kubernetes.io/session-cookie-expires : " 초 " nginx.ingress.kubernetes.io/session-cookie-path : "/ 경로 "

nginx.com/sticky-cookie-services : "serviceName= example-svc 쿠키 이름 만료= 시간 경로=/ 경로 "

메모: NGINX Plus 기반의 NGINX Ingress Controller는 커뮤니티 Ingress 컨트롤러가 전혀 지원하지 않는 기능( 활성 상태 확인 , JSON 웹 토큰(JWT)을 사용한 인증 등)에 대한 추가 주석을 갖고 있습니다.

ConfigMaps를 사용한 글로벌 구성

다음 표는 커뮤니티 Ingress 컨트롤러 ConfigMap 키를 해당 NGINX Ingress 컨트롤러 ConfigMap 키에 직접 매핑합니다. 몇몇 ConfigMap 키 이름이 동일하다는 점에 유의하세요. 또한, 커뮤니티 Ingress 컨트롤러와 NGINX Ingress 컨트롤러는 둘 다 다른 컨트롤러에 없는 ConfigMaps 키를 가지고 있습니다(표에 표시되지 않음).

커뮤니티 인그레스 컨트롤러 NGINX Ingress Controller 
비활성화-액세스-로그

접속-로그-오프

오류-로그-레벨

오류-로그-레벨

하츠

하츠

hsts-include-서브도메인

hsts-include-서브도메인

hsts-최대-나이

hsts-최대-나이

http-스니펫

http-스니펫

살아있음

keepalive-타임아웃

keep-alive-요청

keepalive 요청

부하 분산

lb-방법

위치-스니펫

위치-스니펫

log-format-escape-json : "참"

log-format-escaping : "json"

로그 포맷 스트림

스트림-로그-포맷

로그 포맷 업스트림

로그 형식

메인 스니펫

메인 스니펫

최대 작업자 연결 

근로자 연결

최대-작업자-열린-파일

워커-rlimit-nofile

프록시-바디-사이즈

클라이언트-최대-몸-크기

프록시 버퍼링

프록시 버퍼링

proxy-buffers-number : " 숫자 " proxy-buffer-size : " 크기 "

proxy-buffers : 숫자 크기

프록시 연결 시간 초과

프록시 연결 시간 초과

프록시-읽기-시간 초과

프록시-읽기-시간 초과

프록시-전송-시간 초과

프록시-전송-시간 초과

서버 이름 해시 버킷 크기

서버 이름 해시 버킷 크기

서버 이름 해시 최대 크기

서버 이름 해시 최대 크기

서버 스니펫

서버 스니펫

서버 토큰

서버 토큰

ssl-암호

ssl-암호

ssl-dh-파라미터

ssl-dhparam-파일

ssl 프로토콜

ssl 프로토콜

ssl-리디렉션

ssl-리디렉션

업스트림-keepalive-연결

유지

사용-http2

http2

프록시 프로토콜 사용

프록시 프로토콜

변수-해시-버킷-크기

변수-해시-버킷-크기

워커-CPU-친화성

워커-CPU-친화성

작업자 프로세스

작업자 프로세스

작업자 종료 시간 초과

작업자 종료 시간 초과

요약

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

이 게시물은 F5 NGINX를 사용하여 Kubernetes 트래픽을 관리하는 포괄적인 eBook에서 발췌한 것입니다. 실용 가이드 오늘 무료로 다운로드하세요 .

오늘 무료 30일 평가판을 통해 NGINX Plus 기반 NGINX Ingress Controller를 직접 사용해 보시거나, 사용 사례에 대해 논의하기 위해 저희에게 문의하세요 .

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

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