Kubernetes 용 NGINX Ingress Controller 1.8.0
Kubernetes용 NGINX Ingress Controller 1.8.0 부터 Red Hat, OpenShift, Amazon Elastic Container Service for Kubernetes(EKS), Azure Kubernetes Service(AKS), Google Kubernetes Engine(GKE), IBM Cloud Private, Diamanti 등을 포함한 Kubernetes 플랫폼에서 Ingress 로드 밸런싱을 위한 솔루션의 개발을 기반으로 구축됩니다.
1.8.0 이상에서는 유연하고 강력하며 사용하기 쉬운 Ingress Controller를 제공하기 위해 계속 노력하고 있으며, Kubernetes Ingress resource와 NGINX Ingress resource 모두로 구성할 수 있습니다.
- Kubernetes Ingress resource는 Ingress Controller 구현 전반에 걸쳐 최대한의 호환성을 제공하며, 어노테이션과 사용자 정의 템플릿을 사용하여 확장하고 정교한 구성을 생성할 수 있습니다.
- NGINX Ingress resource는 일반 Kubernetes Ingress resource를 사용자 정의하는 것보다 더 풍부하고 안전한 NGINX 전용 스키마를 제공합니다.
다음과 같은 주요 기능이 향상 및 개선되었습니다.
- NGINX App Protect와 통합 – NGINX App Protect는 웹 애플리케이션에 대한 심층 서명 및 구조적 보호 기능을 제공하는 선도적인 NGINX 기반 애플리케이션 보안 솔루션입니다.
- NGINX Ingress resource에 대한 확장성 – NGINX Ingress resource를 사용하고자 하지만 현재 VirtualServer 및 VirtualServerRoute 리소스가 노출하지 않는 NGINX 기능을 사용자 정의해야 하는 사용자를 위해 이제 구성 스니펫과 사용자 정의 템플릿이라는 두 가지 보완 메커니즘이 지원됩니다.
- URI Rewrite 및 요청 및 응답헤더 수정 – 이러한 기능을 사용하면 업스트림으로 배포되는 헤더를 세밀하게 제어(추가, 제거, 무시)할 수 있습니다.
- 정책 및 IP Address Access Control List – 정책을 사용하면 트래픽 관리의 기능이 별도의 Kubernetes 객체 내에서 추상화되어 여러 팀에서 여러 위치에 정의하고 적용할 수 있습니다. Access Control List(ACL)은 NGINX Ingress Controller를 통해 유입 및 발신되는 네트워크 트래픽을 필터링하는 데 사용됩니다.
- 기타 기능
- 준비 상태 프로브
- VirtualServer 및 VirtualServerRoute resource 및 Helm 차트에서 여러 Ingress Controller 지원
- VirtualServer 및 VirtualServerRoute resource에 대한 상태 정보
- Red Hat OpenShift용 NGINX Ingress Operator 업데이트
목차
1. Kubernetes용 NGINX Ingress Controller 란?
2. NGINX Ingress Controller 1.8.0의 기능은?
2-1. Kubernetes 보안 NGINX App Protect와의 통합
2-2. 스니펫 및 사용자 지정 템플릿으로 NGINX Ingress resource 확장하기
2-3. URI Rewrite 및 요청 및 응답 헤더 수정
2-4. 정책과 IP 주소 액세스 제어 목록
2-5. 기타 새로운 기능
2-5-1. 준비 상태 프로브
2-5-2. NGINX Ingress resource 및 Helm 차트에서 Multiple Ingress Controller 활성화하기
2-5-3. VirtualServer 및 VirtualServerRoute Resource 상태 표시
2-5-4. Red Hat OpenShift용 NGINX Ingress 오퍼레이터 업데이트
3. Kubernetes NGIXN 리소스
1. Kubernetes 용 NGINX Ingress Controller 란?
Kubernetes용 NGINX Ingress Controller는 Kubernetes 환경에서 NGINX 오픈 소스 또는 NGINX Plus 인스턴스와 함께 실행되는 데몬입니다. 이 데몬은 Kubernetes Ingress resource와 NGINX Ingress resource를 모니터링하여 Ingress Load Balancing에 필요한 서비스에 대한 요청을 검색합니다. 그런 다음 데몬은 이러한 서비스로 트래픽을 라우팅하고 로드 밸런싱하도록 NGINX 또는 NGINX Plus를 자동으로 구성합니다.
Multiple NGINX Ingress Controller 구현을 사용할 수 있습니다. 공식 NGINX 구현은 고성능이며 프로덕션에 바로 사용할 수 있고, 장기 배포에 적합합니다. 엔터프라이즈 규모로 배포할 수 있는 기능을 통해 여러 릴리스에 걸쳐 안정성을 제공하는 데 중점을 둡니다. NGINX Plus 구독자에게는 추가 비용 없이 전체 기술 지원을 제공하며, NGINX 오픈 소스 사용자도 안정성과 지원성에 중점을 둔 혜택을 누릴 수 있습니다.
2. NGINX Ingress Controller 1.8.0의 기능은?
2-1. Kubernetes 보안 NGINX App Protect와의 통합
디지털 트랜스포메이션을 가속화하는 기업이 늘어나면서 애플리케이션에 대한 공격도 증가하고 있습니다. 복잡성이 높아진 새로운 취약점 공격이 매일 등장하고 있습니다. 지능형 웹 애플리케이션 방화벽(WAF)인 NGINX App Protect는 네트워크 방화벽 및 안티바이러스 솔루션과 달리 빠른 속도로 악의적인 공격을 효과적으로 방어할 수 있습니다.
릴리스 1.8.0은 NGINX Ingress Controller 내에 NGINX App Protect를 내장하고 있으며, 익숙한 Kubernetes API를 사용하여 App Protect 보안 정책과 구성을 관리할 수 있습니다.
이 통합 솔루션은 세 가지 고유한 이점을 제공합니다:
- 애플리케이션 경계 보안 – 잘 설계된 Kubernetes 배포에서 Ingress Controller는 Kubernetes 내에서 실행되는 서비스에 대한 data plane 트래픽의 유일한 진입 지점이며, 보안 프록시를 배포하기에 이상적인 위치입니다.
- Data Plane 통합 – Ingress Controller 내에 WAF를 내장하면 별도의 WAF 디바이스가 필요하지 않습니다. 따라서 복잡성과 비용이 감소하고 장애 지점 수가 줄어듭니다.
- Control Plane 통합 – Kubernetes API로 WAF 구성을 관리하면 CI/CD 프로세스를 훨씬 더 쉽게 자동화할 수 있습니다. NGINX Ingress Controller 구성은 Kubernetes 역할 기반 액세스 제어(RBAC) 관행을 준수하므로 WAF 구성을 전담 DevSecOps팀에 안전하게 위임할 수 있습니다.
더 자세한 개요는 동반 포스트인 NGINX App Protect를 사용하여 Kubernetes에서 앱 보호하기를 참조하세요. NGINX Ingress Controller에서 NGINX App Protect를 구성하고 문제를 해결하기 위한 전체 지침은 NGINX Ingress Controller 설명서를 참조하세요. 다른 App Protect 사용 사례에 대한 자세한 내용은 NGINX App Protect 설명서를 참조하세요.
NGINX Ingress Controller 이미지에 App Protect를 빌드하려면 NGINX Plus 및 NGINX App Protect에 대한 구독이 있어야 합니다.
2-2. 스니펫 및 사용자 지정 템플릿으로 NGINX Ingress resource 확장하기
이전 릴리스에서는 스니펫과 사용자 정의 템플릿을 사용하여 표준 Kubernetes Ingress resource에 NGINX 구성을 삽입할 수 있었습니다. 스니펫을 사용하면 대부분의 NGINX 구성 컨텍스트에 NGINX 네이티브 구성을 할당할 수 있습니다. 사용자 정의 템플릿을 사용하면 기본 서버와 같은 구성의 다른 블록을 생성하고, 이를 ConfigMap과 함께 적용할 수 있습니다. 릴리스 1.8.0에서는 코드조각과 사용자 정의 템플릿의 사용이 NGINX Ingress resource인 VirtualServer 및 VirtualServerRoute로 확장되었습니다.
관리자는 코드조각과 사용자 정의 템플릿을 모두 사용하여 표준 Kubernetes Ingress resource나 NGINX Ingress resource를 통해 노출되지 않는 사용 사례 및 기능에 대한 구성을 구현할 수 있습니다. 특히 중요한 사용 사례 중 하나는 이미 NGINX에 의해 프록시된 비(非) Kubernetes 애플리케이션을 Kubernetes로 마이그레이션하여 현대화하는 경우입니다. 스니펫과 사용자 정의 템플릿을 사용하면 캐싱 및 속도 제한(Rate Limit)과 같이 NGINX Ingress resource 에서 아직 구현되지 않은 NGINX 기능을 계속 사용할 수 있습니다.
이 샘플 구성은 서로 다른 NGINX 구성 컨텍스트에서 서로 다른 설정을 적용하는 코드 조각을 사용하여 캐싱 및 속도 제한(Rate Limit)을 구성하는 방법을 보여줍니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
namespace: cafe
spec:
http-snippets: |
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
proxy_cache_path /tmp keys_zone=one:10m;
host: cafe.example.com
tls:
secret: cafe-secret
server-snippets: |
limit_req zone=mylimit burst=20;
upstreams:
- name: tea
service: tea-svc
port: 80
- name: coffee
service: coffee-svc
port: 80
routes:
- path: /tea
location-snippets: |
proxy_cache one;
proxy_cache_valid 200 10m;
action:
pass: tea
- path: /coffee
action:
pass: coffee
스니펫과 사용자 정의 템플릿을 신중하게 품질 검사하는 것이 중요합니다. 잘못된 스니펫이나 템플릿은 NGINX 구성을 다시 로드하지 못하도록 합니다. 이 경우 트래픽 처리가 중단되지는 않지만(NGINX는 기존 유효한 구성으로 계속 실행됨) 안정성을 높이기 위해 추가 메커니즘을 사용할 수 있습니다:
- 스니펫에 대한 전역 enable-disable 설정.
- 일반적으로 관리자만 사용자 정의 템플릿을 구성하는 유일한 메커니즘인 ConfigMap을 적용할 수 있습니다.
2-3. URI Rewrite 및 요청 및 응답 헤더 수정
릴리스 1.8.0에서는 업스트림 및 다운스트림 연결 모두에서 요청 및 응답 헤더의 URI Rewrite 및 수정 기능이 도입되었습니다. 이는 기본적으로 필터링 및 수정 계층을 추가하여 최종 사용자와 백엔드를 분리합니다. 이 기능은 이제 VirtualServer 및 VirtualServerRoute resource에서 직접 사용할 수 있으며, 특정 경로에 대해 구성할 수 있습니다.
URI를 rewrite하고 요청 및 응답 헤더를 수정할 수 있으므로 백엔드 개발자가 문제를 해결하거나 코드를 다시 작성할 필요 없이 프로덕션 환경에서 예기치 않은 안정성 문제를 신속하게 해결할 수 있습니다. 결과적으로 Kubernetes에서 애플리케이션 워크로드의 가용성, 보안, 복원력이 향상됩니다.
일반적인 사용 사례는 다음과 같습니다:
- URI rewrite – 관리자가 애플리케이션 코드에 노출된 경로와 다른 경로에 애플리케이션을 게시하고 싶을 수 있습니다. 예를 들어 /coffee URI에 애플리케이션을 외부에 노출하고 Ingress Controller가 애플리케이션 백엔드가 수신 대기 중인 루트(/) URI로 요청을 변환하도록 할 수 있습니다.
- 캐싱 – 애플리케이션 개발자가 항상 캐싱 헤더를 올바르게 또는 전혀 설정하지 않는 경우가 있습니다. 관리자는 헤더 수정을 사용하여 배포된 애플리케이션의 헤더를 패치할 수 있습니다.
요청이 업스트림으로 배포되는 프록시 동작 아래 VirtualServer 또는 VirtualServerRoute에서 헤더 수정 및 URI rewrite를 구성합니다.
이 샘플 구성에서는 Ingress Controller가 클라이언트 요청을 /tea 경로로 프록시할 때 요청을 업스트림으로 전달하기 전에 Content-Type 요청 헤더를 수정합니다. 또한 재작성 경로 필드에 지정된 대로 /tea URI를 /로 rewrite합니다.서버의 응답을 클라이언트에 다시 전달하기 전에 인그레스 컨트롤러는 새 Access-Control-Allow-Origin 헤더를 추가하고 다른 여러 헤더를 숨기거나 무시하고 전달합니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
upstreams:
- name: tea
service: tea-svc
port: 80
- name: coffee
service: coffee-svc
port: 80
routes:
- path: /tea
action:
proxy:
upstream: tea
requestHeaders:
pass: true
set:
- name: Content-Type
value: application/json
responseHeaders:
add:
- name: Access-Control-Allow-Origin
value: "*"
always: true
hide:
- x-internal-version
ignore:
- Expires
- Set-Cookie
pass:
- Server
rewritePath: /
- path: /coffee
action:
pass: coffee
이 샘플 구성은 조건부 일치에 따라 action 블록에 헤더 조작 및 URI rewrite를 포함시켜 더욱 정교한 트래픽을 처리하는 방법을 보여줍니다:
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
upstreams:
- name: tea
service: tea-svc
port: 80
- name: tea-post
service: tea-post-svc
port: 80
routes:
- path: /tea
matches:
- conditions:
- variable: $request_method
value: POST
action:
proxy:
upstream: tea-post
requestHeaders:
pass: true
set:
- name: Content-Type
value: application/json
rewritePath: /
action:
pass: tea2-4. 정책과 IP 주소 액세스 제어 목록
대부분의 조직에서는 여러 팀이 애플리케이션 전송을 위해 협업합니다. 예를 들어, NetOps는 포트 개방과 트래픽 필터링을 담당하고, SecOps는 일관된 보안 태세를 보장하며, 여러 애플리케이션 소유자가 여러 백엔드 애플리케이션 서비스에 대한 Ingress Load Balancing 정책을 프로비저닝합니다.
조직마다 서로 다른 방식으로 역할을 위임하기 때문에 NGINX Ingress Controller는 구성의 특정 부분을 소유하는 팀을 정의한 다음 모든 부분을 함께 조립하고 실행하는 데 최대한의 유연성을 제공합니다. 이를 통해 multi-tenancy를 지원하는 동시에 관리자가 최대한 간단하게 위임할 수 있습니다.
Multi-tenancy를 지원하기 위해 NGINX Ingress Controller 릴리스 1.8.0에서는 정책과 최초로 지원되는 정책 유형을 도입합니다: IP 주소 기반 Access Control List(ACL)입니다.
- 정책을 사용하면 트래픽 관리 기능을 별도의 Kubernetes 객체 내에서 추상화하여 여러 팀에서 여러 위치에 정의하고 적용할 수 있습니다. 이는 NGINX Ingress Controller를 보다 쉽고 자연스럽게 구성하는 방법이며 유형 안정성, 위임, multi-tenancy, 캡슐화 및 간단한 구성, 재사용성, 안정성 등 많은 이점을 제공합니다.
- IP 주소 기반 ACL을 사용하면 네트워크 트래픽을 필터링하고 특정 Ingress resource에 대한 액세스를 허용(Allow)하거나 거부(Deny)할 IP 주소(또는 CIDR 표기법으로 정의된 IP 주소 그룹)를 정밀하게 제어할 수 있습니다.
참고: 릴리스 1.8.0에서는 정책이 서버 컨텍스트에 적용되는 VirtualServer resource에서만 정책을 참조할 수 있습니다. 향후 릴리스에서는 정책이 location 컨텍스트에 적용되는 VirtualServerRoute resource로 정책 지원을 확장할 계획입니다. 또한 속도 제한(Rate Limit)과 같은 다른 기능에 대한 정책도 구현할 계획입니다.
다음 다이어그램은 정책을 사용하는 방법을 보여줍니다. 왼쪽의 VirtualServer resource는 webapp-policy라는 정책을 참조하고, 오른쪽의 구성 스니펫은 각각 10.0.0.0/8 서브넷으로부터의 연결을 필터링(각각 허용 또는 거부)하는 해당 이름의 정책을 정의합니다. 두 정책 모두에 이름을 할당하면 Kubernetes API를 사용하여 가상 서버에 의도한 정책을 적용하여 두 정책 사이를 전환할 수 있습니다.
2-5. 기타 새로운 기능
2-5-1. 준비 상태 프로브
많은 Ingreses resource(표준 Kubernetes, NGINX 또는 둘 다)가 있는 환경에서는 NGINX 구성이 완전히 로드되기 전에 pod가 온라인 상태가 되어 트래픽이 블랙홀 될 수 있다. 프로덕션 등급의 안정성에 대한 약속에 따라, 릴리스 1.8.0에서는 Ingress Controller가 트래픽을 수락할 준비가 될 때까지(즉, NGINX 구성이 로드되고 reload가 보류 중이 아닌 경우) 트래픽이 특정 pod로 배포되지 않도록 하기 위해 Kubernetes 준비 프로브가 도입되었습니다.
2-5-2. NGINX Ingress resource 및 Helm 차트에서 Multiple Ingress Controller 활성화하기
이전 릴리스에서는 표준 Kubernetes Ingress resource에서 표준 Kubernetes Ingress resource의 kuberntes.io/Ingress.class 어노테이션을 사용하여 대상 Kubernetes Ingress Controller deployment를 지정해야만 동일한 클러스터에 여러 개의 NGINX Ingress Controller 인스턴스가 공존하는 것이 가능했습니다. 릴리스 1.8.0에서는 동일한 목적으로 VirtualServer 및 VirtualServerRoute resource에 ingressClassname 필드를 추가했습니다. 또한 Helm 차트를 업데이트하여 multiple NGINX Ingress Controller를 배포를 지원하도록 했습니다.
2-5-3. VirtualServer 및 VirtualServerRoute Resource 상태 표시
kubectl describe 명령의 출력은 Ingress Controller에 대한 구성이 성공적으로 업데이트되었는지 여부(Events 섹션)를 나타내며 외부 엔드포인트의 IP 주소와 포트(Status 섹션)를 나열한다. 릴리스 1.8.0에서는 이 정보를 반환하도록 VirtualServer 및 VirtualServerRoute resource를 확장했습니다. VirtualServerRoute의 경우 Status 섹션에 상위 VirtualServer resource의 이름도 표시됩니다.
앱 소유자는 VirtualServerRoute resource의 상위 VirtualServer가 제거되어 애플리케이션 액세스할 수 없게 된 것을 발견할 수 있습니다. 이제 관련 VirtualServer 및 VirtualServerRoute resource에 대해 kubectl describe 명령을 실행하여 문제를 해결할 수 있습니다.
이 샘플 명령은 Events 섹션에서 유형이 정상이고 이유가 추가 또는 업데이트인 cafe VirtualServer에 대한 구성이 성공적으로 적용되었음을 보여줍니다.
$ kubectl describe vs cafe
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal AddedOrUpdated 16s nginx-ingress-controller Configuration for default/cafe was added or updated
이 샘플은 Events 섹션에서 유형은 경고, 이유는 거부됨으로, cafe VirtualServer에 대한 구성이 유효하지 않은 것으로 거부 되었음을 보여줍니다. 그 이유는 두 개의 업스트림이 모두 tea라는 이름을 가졌기 때문입니다.
$ kubectl describe vs cafe
. . .
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Rejected 12s nginx-ingress-controller VirtualServer default/cafe
is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"
2-5-4. Red Hat OpenShift용 NGINX Ingress 오퍼레이터 업데이트
- 정책 – 이제 NGINX Ingress Controller 운영자를 활용하여 최종 사용자별로 정책을 배포할 수 있습니다.
- App Protect scaling – 오퍼레이터를 사용하면 동일한 배포 내의 모든 인스턴스가 트래픽을 검사할 수 있도록 App Protect를 통해 NGINX Ingress Controller의 확장을 관리할 수 있습니다.
3. Kubernetes NGINX 리소스
릴리스 1.8.0의 전체 변경 로그는 릴리스 노트를 참조하세요.
NGINX Ingress Controller롸 NGINX Plus 및 NGINX app Protect를 사용해 보려면 지금 30일 무료 체험판을 시작하거나 NGINX STORE에 문의하여 사용 사례에 대해 논의하세요.
NGINX 오픈 소스가 포함된 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.
댓글을 달려면 로그인해야 합니다.