Kubernetes 용 NGINX Ingress Controller 1.7.0
Kubernetes 용 NGINX Ingress Controller의 1.7.0 릴리스는 Amazon Elastic Container Service for Kubernetes (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift, IBM Cloud Private, Diamanti 등을 포함한 Kubernetes 플랫폼에서의 Ingress 로드 밸런싱을 위한 지원 솔루션 개발을 기반으로 구축되었습니다.

릴리스 1.7.0을 통해, NGINX는 유연하고 강력하며 사용하기 쉬운 Ingress Controller를 제공하는 것에 대한 약속을 이어가고 있습니다. 이 컨트롤러는 Kubernetes Ingress 리소스와 NGINX Ingress 리소스를 모두 구성할 수 있습니다.
- Kubernetes Ingress 리소스는 Ingress Controller 구현 간의 최대 호환성을 제공하며, 주석과 사용자 정의 템플릿을 사용하여 고급 구성을 생성할 수 있습니다.
- NGINX Ingress 리소스는 NGINX에 특화된 구성 스키마를 제공하며, 일반적인 Kubernetes Ingress 리소스를 사용자 정의하는 것보다 풍부하고 안전한 구성을 제공합니다.
릴리스 1.7.0에서는 다음과 같은 주요 개선 사항이 소개되었습니다.
- Red Hat OpenShift Operator – 이 Operator는 OpenShift에서 NGINX Ingress Controller의 라이프사이클을 간단하고 익숙한 방식으로 관리합니다. Red Hat에서 인증을 받았으며, NGINX Ingress Controller가 OpenShift에 대해 완전히 지원되는 솔루션임을 의미합니다.
- NGINX Ingress 리소스가 추가 프로토콜(TCP, UDP, TLS Passthrough)을 지원합니다. 이제 사용자 정의 리소스를 사용하여 Kubernetes에서 복잡한 non-HTTP 기반 서비스를 간편하고 직관적인 방식으로 제공할 수 있습니다.
이 접근 방식은 우리의 미래 방향을 미리 보여주는 미리보기입니다. - NGINX Ingress 리소스가 마이크로서비스를 위한 Circuit breaker 패턴을 지원합니다.
이제 NGINX Ingress Controller가 이름이 지정된 서비스가 올바르게 작동하지 않을 때 반환하는 기본 오류 페이지를 지정할 수 있습니다. - NGINX Ingress 리소스가 개선된 유효성 검사 및 보고를 제공합니다. OpenAPI 유효성 검사를 사용하여 더 엄격한 유효성 검사를 수행하고, NGINX Ingress 리소스에서 발생하는 오류 가능성을 줄이며, 훨씬 개선된 오류 메시지를 제공합니다.
목차
1. Kubernetes 용 NGINX Ingress Controller란 무엇입니까?
2. Kubernetes 용 NGINX Ingress Controller 1.7.0의 새로운 기능은 무엇입니까?
2-1. Red Hat OpenShift 지원
2-2. Kubernetes NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루(Passthrough) 서비스 지원
2-3. TCP, UDP 및 TLS 패스스루 서비스 예제
2-4. 회로 차단기 패턴(Circuit Breaker Pattern) 지원
2-5. 향상된 검증 및 보고
3. 자원
1. Kubernetes 용 NGINX Ingress Controller란 무엇입니까?
Kubernetes용 NGINX Ingress Controller는 Kubernetes 환경에서 NGINX 오픈소스 또는 NGINX Plus 인스턴스와 함께 실행되는 데몬입니다.
이 데몬은 Kubernetes Ingress 리소스와 NGINX Ingress 리소스를 모니터링하여 Ingress 로드 밸런싱이 필요한 서비스에 대한 요청을 감지합니다.
그런 다음 데몬은 자동으로 NGINX 또는 NGINX Plus를 구성하여 이러한 서비스로의 트래픽을 라우팅하고 로드 밸런싱합니다.
여러 가지 NGINX Ingress Controller 구현이 있습니다. 공식 NGINX 구현은 고성능이며, 실전에 사용할 수 있으며, 장기적인 배포에 적합합니다.
NGINX는 릴리스 간의 안정성을 제공하고, 기업 규모에서 배포할 수 있는 기능을 갖추고 있습니다. NGINX Plus 구독자에게는 추가 비용 없이 전체 기술 지원을 제공하며, NGINX 오픈소스 사용자는 안정성과 지원 가능성에 중점을 둔 지원을 받을 수 있습니다.
2. Kubernetes 용 NGINX Ingress Controller 1.7.0의 새로운 기능은 무엇입니까?
2-1. Red Hat OpenShift 지원
Red Hat OpenShift용 NGINX Ingress Operator를 소개하게 되어 기쁩니다.
이는 OpenShift 플랫폼에서 NGINX Ingress Controller(NGINX 오픈소스 및 NGINX Plus 모두)의 완전히 지원되는 라이프사이클 관리 솔루션입니다.
이를 통해 NGINX Ingress Controller의 설치가 포인트 앤 클릭으로 가능해집니다. 기본 배포를 위해 몇 가지 매개변수만 지정하면 됩니다.
이 Operator는 Kubernetes의 기본 개체(배포, 복제본, Pod 등) 주변의 복잡성을 추상화하여 애플리케이션 소유자 및 다른 팀이 Kubernetes 컨테이너 인프라를 자세히 이해하지 않아도 되도록 합니다.
또한, Operator는 Ingress Controller 배포를 사용자 정의하기 위한 매개변수를 제공합니다.
Operator의 목표는 NGINX Ingress Controller의 고급 기능을 OpenShift로 한 단계 배포 프로세스로 제공하는 것입니다. 예를 들어, blue-green 배포, 트래픽 분할, A/B Testing와 같은 다양한 사용 사례를 지원하기 위해 NGINX Ingress 리소스(VirtualServer, VirtualServerRoute, TransportServer)를 활용할 수 있습니다.
또한, NGINX Ingress 리소스의 역할 기반 액세스 제어(RBAC) 및 네임스페이스 간 기능을 활용하여 사용자의 셀프 서비스 및 멀티 테넌시를 지원할 수 있으며, 다른 팀 간에 애플리케이션 전달 구성 요소 관리의 명확한 구분과 위임을 제공합니다.
OpenShift 클러스터 관리자가 Operator를 설치한 후, 최종 사용자는 다음과 같은 간단한 매니페스트로 NGINX Ingress Controller를 배포할 수 있습니다.
apiVersion: k8s.nginx.org/v1alpha1
kind: NginxIngressController
metadata:
name: nginx-ingress-controller-foo
namespace: nginx-ingress-controller-foo-ns
spec:
type: deployment
image:
repository: registry.hub.docker.com/nginx/nginx-ingress
tag: edge
pullPolicy: Always
serviceType: NodePort
고급 사용자를 위해 Operator는 배포를 사용자 정의하는 다양한 옵션을 노출시킵니다. 모든 가능한 매개변수를 포함한 샘플 매니페스트는 GitHub 저장소를 참조하세요.
2-2. Kubernetes NGINX Ingress 리소스에서 TCP, UDP 및 TLS 패스스루(Passthrough) 서비스 지원
1.7.0 버전에서는 NGINX Ingress 리소스를 확장하여 TCP, UDP 및 TLS Passthrough 로드 밸런싱을 지원했습니다:
- TCP 및 UDP 지원은 Ingress Controller가 DNS 및 Syslog(UDP)부터 데이터베이스 및 기타 TCP 기반 애플리케이션까지 훨씬 더 다양한 프로토콜을 관리할 수 있게 합니다.
- TLS Passthrough는 NGINX Ingress Controller가 TLS 암호화된 연결을 TLS 인증서 또는 키에 액세스하지 않고도 Service Name Indication (SNI) 헤더를 기반으로 라우팅할 수 있게 합니다.
1.7.0 버전에서는 TCP, UDP 및 TLS Passthrough를 구성하기 위한 두 가지 새로운 NGINX Ingress 리소스인 GlobalConfiguration과 TransportServer를 미리보기로 제공합니다. 다음 릴리스(1.8.0)를 개발하는 동안 이 접근 방식에 대한 피드백, 비판 및 개선 제안을 환영합니다.
견고한 구성 아키텍처를 확보한 후에는 안정적이고 완전히 프로덕션에 사용할 준비가 된 것으로 간주합니다.
이러한 비-HTTP 프로토콜에 대한 직접적인 지원은 이전에 NGINX 스트림 구성을 Kubernetes Ingress 리소스에 직접 포함시키는 것이 권장되었던 것보다 더 간단하고 신뢰할 수 있는 옵션을 제공합니다.
2-3. TCP, UDP 및 TLS 패스스루 서비스 예제
NGINX Ingress Controller에서 TCP 및 UDP 서비스를 지원하는 새로운 간소화된 신뢰할 수 있는 방법을 살펴보겠습니다.
클러스터 관리자로서, GlobalConfiguration 리소스를 사용하여 사용자가 할당한 특정 포트를 통해 애플리케이션의 TCP 및 UDP 로드 밸런싱을 구성할 수 있도록 설정합니다. Ingress Controller의 전역 구성을 정의하기 위해 설치 중에 -global-configuration=namespace/name 명령행 인수를 추가하기만 하면 됩니다.
다음은 두 개의 리스너를 가진 nginx-ingress 네임스페이스의 샘플 GlobalConfiguration 정의를 고려해보세요:
- 포트 5353에서 수신하는 TCP 프로토콜
- 포트 5353에서 수신하는 UDP 프로토콜
apiVersion: k8s.nginx.org/v1alpha1
kind: GlobalConfiguration
metadata:
name: nginx-configuration
namespace: nginx-ingress
spec:
listeners:
- name: dns-udp
port: 5353
protocol: UDP
- name: dns-tcp
port: 5353
protocol: TCP
사용자는 TCP 및 UDP 로드 밸런싱을 위해 NGINX Ingress Controller를 구성할 때 TransportServer 리소스에서 이름(dns-udp 또는 dns-tcp)을 참조해야 합니다.
다음은 TCP 로드 밸런싱을 위한 TransportServer 리소스의 샘플 구현입니다.
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: dns-tcp
spec:
listener:
name: dns-tcp
protocol: TCP
upstreams:
- name: dns-app
service: coredns
port: 5353
action:
pass: dns-app
spec 섹션에서 사용자는 GlobalConfiguration 리소스 정의에서 정의된 dns-tcp 리스너를 참조하고, TCP 연결을 dns-app upstream으로 전달합니다. dns-tcp 리스너에는 포트 5353만 할당되었음에 유의하세요. UDP 프로토콜에 대한 TransportServer도 유사하게 구성할 수 있습니다. GitHub에서 전체 TCP/UDP 예제를 확인하세요.
사용자는 또한 TransportServer 리소스를 사용하여 TLS Passthrough를 위해 TLS 암호화된 연결을 upstream 서비스로 라우팅할 수 있습니다. TLS Passthrough를 활성화하려면 설치 중에 –enable-tls-passthrough 명령행 인수를 추가하면 됩니다. 다음은 TLS Passthrough를 사용한 TransportServer 리소스의 샘플 구현입니다.
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: secure-app
spec:
listener:
name: tls-passthrough
protocol: TLS_PASSTHROUGH
host: app.example.com
upstreams:
- name: secure-app
service: secure-app
port: 8443
action:
pass: secure-app
TLS Passthrough를 활성화할 때는, 내장된 이름이 tls-passthrough이고 프로토콜이 TLS_PASSTHROUGH인 리스너를 참조합니다. GitHub에서 전체 TLS Passthrough 예제를 확인하세요.
2-4. 회로 차단기 패턴(Circuit Breaker Pattern) 지원
NGINX Ingress Controller의 회로 차단기 패턴 구현은 두 가지 작업을 수행합니다:
- 실패한 서비스를 감지하고 격리하여 애플리케이션에서 제거합니다 (릴리스 1.6.0 이상에서 지원됨).
- 실패한 서비스로의 요청을 라우팅하는 대신 클라이언트에게 canned response를 전달합니다 (릴리스 1.7.0에서 새롭게 추가됨).
회로 차단기의 사용은 타임아웃이나 지연을 발생시킬 수 있는 실패한 구성 요소로의 호출을 제거함으로써 애플리케이션의 성능을 향상시킬 수 있으며, 종종 비필수 구성 요소의 실패로 인한 영향을 완화할 수 있습니다.
예를 들어, 애플리케이션은 기사의 댓글, 추천, 광고 등을 포함한 부수적인 항목 목록을 제공할 수 있습니다. 이 목록을 생성하는 Kubernetes 서비스가 실패하는 경우, 회로 차단기는 내부적으로 생성된 오류 메시지(502 Service Unavailable)를 더 적절한 응답(빈 JSON 목록 등)으로 대체할 수 있습니다.
이렇게 함으로써, 애플리케이션에서 제공되는 서비스가 저하되더라도(부수적인 항목을 사용할 수 없음), 내부 오류가 호출 클라이언트에게 감춰지는 방식으로 우아하게 처리됩니다.
다음 예제에서는 NGINX Ingress 리소스가 app-svc 서비스로의 트래픽을 관리합니다.
/status에 대한 요청에 대해 엔드포인트가 적절한 상태 코드(기본적으로 2xx 또는 3xx)로 응답하는지 확인하기 위해 Active Health Check(NGINX Plus 전용)를 사용하며, 502 Error Response을 유발하는 요청을 리다이렉션합니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: app
spec:
host: app.example.com
tls:
secret: app-secret
upstreams:
- name: app
service: app-svc
port: 80
healthCheck:
enable: true
path: /status
routes:
- path: /
errorPages:
- codes: [502]
redirect:
code: 301
url: https://nginx.org
action:
pass: app
주기적으로 app upstream의 상태를 확인하기 위해 VirtualServer 정의를 적용할 수 있습니다.
app-svc 서비스의 모든 엔드포인트에 대한 주기적인 헬스 체크가 실패하면 app upstream이 사용 불가능해지고(회로 차단기가 열림), app upstream으로의 요청을 하는 클라이언트는 백업 웹사이트(이 예제에서는 https://nginx.org)로 리다이렉션됩니다.
이 회로 차단기 사용 사례를 테스트할 때, 다음 시나리오와 NGINX의 응답을 고려해보세요:
- 엔드포인트에 대한 요청이 일시적인 오류로 인해 실패합니다. NGINX는 요청을 다시 시도하거나 요청을 포기하고 리다이렉션하는 방식으로 재시도 요청 로직을 구성에 따라 처리합니다.
- 서비스의 모든 엔드포인트에 대한 헬스 체크가 실패합니다. NGINX는 모든 엔드포인트가 실패했음을 인식하고 요청을 지정된 URL로 리다이렉션합니다.
- 서비스에 엔드포인트가 없습니다(준비 상태가 아닐 수도 있음). NGINX는 요청을 신속하게 리다이렉션합니다.
2-5. 향상된 검증 및 보고
NGINX Ingress Controller의 1.7.0 버전은 NGINX Ingress 리소스의 유효성을 검증하는 메커니즘을 개선했습니다. NGINX Ingress 리소스 객체(VirtualServer, VirtualServerRoute, TransportServer)에 대한 OpenAPI 스펙을 기반으로 kubectl과 Kubernetes API 서버는 리소스의 구조 위반(예: 정수 값을 문자열 필드에 할당하는 경우)을 감지할 수 있습니다.
이를 통해 애플리케이션의 로드 밸런싱을 구성하는 사용자가 이러한 오류를 감지하는 데 필요한 피드백 루프를 단축시킬 수 있습니다.
이전 릴리스와 비교하여, 유효성 검사기는 NGINX Ingress Controller 구성 프로세스에서 오류를 더 일찍 감지하고 더 자세한 오류 메시지를 제공합니다.
다음은 NGINX Ingress Controller에서 Layer 7 경로 기반 라우팅을 위한 간단한 VirtualServer 구현의 YAML 파일입니다. 노란색으로 강조된 필드는 구성 오류입니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
- name: tea
service: tea-svc
port: DD
healthCheck:
enable: 3654
- name: coffee
service: coffee-svc
port: 80
routes:
- path: /tea
action:
pass: tea
- path: /coffee
actionn:
pass: coffee
다음 명령을 실행하여 YAML 파일을 적용합니다.
# kubectl apply -f cafe-virtual-server.yaml
유효성 검사 메커니즘은 위에서 강조된 오류를 감지하고 다음과 같은 메시지를 생성합니다. 메시지는 YAML 파일에서 오류가 발생한 순서와 반대로 생성됩니다(첫 번째 메시지는 마지막 오류에 해당하며, actionn의 철자가 틀린 오류입니다).
error: error validating "cafe-virtual-server.yaml": error validating data: [ValidationError(VirtualServer.spec.routes[1]): unknown field "actionn" in org.nginx.k8s.v1.VirtualServer.spec.routes,
ValidationError(VirtualServer.spec.upstreams[0].healthCheck.enable): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.healthCheck.enable: got "number", expected "boolean",
ValidationError(VirtualServer.spec.upstreams[0].port): invalid type for org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: got "string", expected "integer"]; if you choose to ignore these errors, turn validation off with --validate=false
3. 자원
1.7.0 버전의 전체 변경 내역은 릴리스 노트를 참조하세요.
NGINX Ingress Controller와 NGINX Plus 및 NGINX App Protect를 함께 사용해보려면 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하기 위해 NGINX STORE에게 문의하세요.
NGINX Ingress Controller를 NGINX 오픈소스와 함께 사용해보려면 릴리스 소스 코드를 얻거나 DockerHub에서 미리 빌드된 컨테이너를 다운로드할 수 있습니다.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
댓글을 달려면 로그인해야 합니다.