NGINX Ingress Controller 2.0: 알아야 할 사항

2021년에는 NGINX Ingress Controller 2.0(nginxinc/kubernetes-ingress)을 출시하여 Kubernetes 1.22와 Ingress API의 버전 1(networking.k8s.io/v1)을 지원하게 되었습니다.
여러분은 “그래서 어떻게 되는 건가요?”라고 궁금해할 수 있습니다.

목차

1. NGINX Ingress Controller 2.0 과 Kubernetes 릴리스가 왜 중요한가요?
2. Ingress API란 무엇이며, networking.k8s.io/v1가 왜 중요한가요?
3. NGINX Ingress Controller 2.0 은 현재 고객에게 어떤 영향을 미치나요?
4. NGINX Ingress Controller 2.0 – 간략한 역사
 4-1. 2016
 4-2. 2017
 4-3. 2018
 4-4. 2019
 4-5. 2020
 4-6. 2021
5. NGINX Ingress Controller 2.0 사용해보기

1. NGINX Ingress Controller 2.0 과 Kubernetes 릴리스가 왜 중요한가요?

이 질문에 대한 답변은 단순하지만 복잡합니다. Kubernetes의 호환성 관리는 까다로운 작업인데, 그 이유는 Kubernetes 운영자가 세 가지 카테고리의 버전 관리를 해야 하기 때문입니다.

1. Kubernetes 플랫폼 자체 – 새로운 릴리즈가 나올 때마다, Kubernetes 팀은 이전 버전의 유지 관리를 중단합니다. 이런 버전을 계속 사용하는 것은 위험 관리 전략에 문제가 될 수 있으며, Kubernetes 팀의 도움을 더 이상 받을 수 없기 때문에 문제 해결이 어려워집니다. 현재 Kubernetes 프로젝트는 가장 최근의 세 가지 마이너 릴리즈(1.20, 1.21, 1.22)에 대한 릴리즈 브랜치를 유지 관리하고 있습니다. Kubernetes 1.19 이후 버전은 대략 1년 동안 패치 지원을 받으며, 1.18 이전 버전은 대략 9개월 동안 패치 지원을 받았습니다. (1.18 이전 버전의 지원 기간이 더 짧은 이유는 Kubernetes가 연간 3회 출시하는 현재와 달리 연간 4회 출시하던 시절이었기 때문입니다.)
2. Kubernetes API – Kubernetes 릴리즈마다 새로운 API가 등장하고 사용되지 않는 API는 폐기되며, API의 변경은 해당 리소스와 도구에 영향을 미칩니다. Kubernetes 플랫폼을 업그레이드하면 API도 업그레이드해야 할 수 있습니다.
3. Kubernetes에 배포한 도구 – Kubernetes나 그 API의 주요 변경 사항은 NGINX Ingress Controller 2.0 과 같은 도구와 해당 리소스가 제대로 작동하는지 여부에 영향을 줄 수 있습니다.

따라서 Kubernetes, Ingress API, NGINX Ingress Controller 2.0 각각에 대한 타임라인을 추적해야 합니다. Kubernetes를 중단하지 않으려면 Kubernetes 버전이 API와 NGINX Ingress Controller 2.0과 호환되는 달콤한 점을 찾아야 합니다.
세 가지 구성 요소 중 하나를 호환성을 확인하지 않고 업그레이드하면 심각한 결과를 초래할 수 있습니다. 세 가지 구성 요소가 서로 호환되지 않으면… 축하합니다, 앱이 망가졌습니다!

2. Ingress API란 무엇이며, networking.k8s.io/v1가 왜 중요한가요?

Ingress API는 NGINX Ingress Controller 2.0 이 Kubernetes 앱을 안전하게 노출할 수 있게 합니다. networking.k8s.io/v1 API(즉, Ingress API v1)는 Kubernetes 1.19와 함께 도입되었습니다.
당시에는 Kubernetes가 v1beta1과 v1을 모두 지원했으며, 자동으로 한 버전을 다른 버전으로 표시했습니다. 이러한 API 버전의 “숨겨진” 호환성은 운영적으로 이점을 제공하지만, 계획 작업을 방해할 수 있습니다.

Kubernetes 1.22가 출시되면서 v1이 Ingress API의 유일한 버전이 되었습니다. 이것은 중요한데, 그 이유는 Ingress API v1이 “유일한” 것이 되면서 모든 베타 버전(extensions/v1beta1 및 networking.k8s.io/v1beta1)이 폐기되기 때문입니다.

이것은 Ingress API v1을 아직 채택하지 않은 조직에게는 혼란을 줄 수 있지만, NGINX에서는 이 변화를 좋은 신호로 보고 있습니다. Ingress API의 베타에서의 승격은 성숙하고 완전히 실현된 API로의 졸업을 의미합니다. 그런데 이 변화가 왜 중요한 걸까요? 그 이유는 버전 관리와 관련이 있습니다. 기존 클러스터를 Kubernetes 1.22로 업그레이드 하지만 v1beta1 Ingress 관련 리소스를 계속 사용한다고 가정해 봅시다… 축하합니다, Ingress 리소스가 망가졌습니다!

3. NGINX Ingress Controller 2.0 은 현재 고객에게 어떤 영향을 미치나요

NGINX Ingress Controller 2.0 는 Ingress API와 긴밀하게 연결되어 있기 때문에, v1의 출시는 NGINX 제품에 큰 영향을 미쳤고, 고객인 여러분에게도 영향을 미쳤습니다.
이로 인해 NGINX는 NGINX Ingress Controller 버전 번호를 1.x에서 2.x로 바꾸었습니다. NGINX는 NGINX Ingress Controller 2.0을 재구성하여 Ingress API v1을 활용하도록 만들었고, 이로 인해 Kubernetes 1.22와 완벽하게 호환될 수 있게 되었습니다.

NGINX Ingress Controller 2.0 를 사용한다면, Kubernetes, Ingress 리소스, 또는 NGINX Ingress Controller를 망가뜨리지 않기 위해 즉시 버전에 따른 다음의 작업을 수행해야 합니다:

Kubernetes 1.18 이하:

• 가장 많은 기능 세트를 활용할 수 있도록 NGINX Ingress Controller 1.12를 사용하고 있는지 확인합니다. (NGINX Ingress Controller 2.0으로 업그레이드하면, Kubernetes 1.19 이상으로도 업그레이드해야 합니다.)
• 다음 Kubernetes 릴리즈 이후에는 Kubernetes 1.18이 지원되지 않으므로, 다음 몇 개월 내에 새 버전의 Kubernetes (및 NGINX Ingress Controller)로 이전할 계획을 세웁니다.

Kubernetes 1.19–1.21:

• NGINX Ingress Controller 2.0 으로 업그레이드합니다.
• 아직 Ingress 관련 리소스를 networking.k8s.io/v1으로 이전하지 않았다면, (NGINX Ingress Controller 2.0 릴리즈 노트를 참조하여) 계획을 세웁니다. Kubernetes 1.19–1.21은 모든 현재 버전의 Ingress API(v1beta1s 및 v1)를 지원하므로, 그대로 변환할 수 있는 기회를 제공합니다.
• 이미 그렇게 하지 않았다면, 즉시 Ingress 및 IngressClass 리소스를 networking.k8s.io/v1으로 이동시킵니다.
• Ingress 리소스에서 사용 중지된 kubernetes.io/ingress.class 주석을 사용하고 있다면, ingressClassName 필드로 전환하는 것을 권장합니다.
• NGINX의 문서와 예제(networking.k8s.io/v1 및 Ingress 리소스의 ingressClassName 필드가 포함되어 있음)를 사용하여 업데이트 계획을 세웁니다.

Kubernetes 1.22:

• 이미 NGINX Ingress Controller 2.0 을 실행하고 있는지 확인합니다.
  이전 버전의 NGINX Ingress Controller는 Kubernetes 1.22와 호환되지 않으며 Ingress API v1을 지원하지 않습니다.

4. NGINX Ingress Controller 2.0 – 간략한 역사

2016년 첫 출시 이후, NGINX Ingress Controller 는 초기 도구에서 Kubernetes 네트워킹의 강력한 도구로 성장해 왔습니다. 이제 출시부터 현재까지의 진화를 살펴보겠습니다.

4-1. 2016

NGINX 엔지니어인 Michael Pleshakov이 GitHub 리포지토리(nginxinc/kubernetes-ingress)에 첫 번째 항목을 게시함으로써, NGINX와 F5 NGINX Plus를 Kubernetes Ingress Controller(KIC)로 사용할 수 있게 되었습니다.

NGINX Ingress Controller는 2016년 KubeCon EU에서 처음으로 공개되었습니다.

4-2. 2017

프로젝트는 생산 준비를 완료하였고, 이에는 NGINX Plus 기반 버전에서 JSON Web Tokens (JWTs)의 핵심 지원이 포함되었습니다.

2017년 NGINX Conf에서 Michael Pleshakov은 에서 고급 로드 밸런싱을 포함한 생산 기능을 시연하였습니다. 이를 통해 NGINX Ingress Controller의 발전된 기능과 생산성을 입증하였습니다.

4-3. 2018

NGINX Ingress Controller는 가시성, 사용 편의성, 유연성 등의 영역에서 큰 개선을 보았습니다:

• 5월 (v1.2.0) – 프로젝트는 새로운 NGINX Plus API를 채택하고 nginx-ingress 이미지가 공식 NGINX Docker Hub로 이동했습니다. 이 버전에서는 gRPC, 수동 health check, Helm 차트, Prometheus를 지원하는 기능이 처음으로 도입되었습니다.
• 8월 (v1.3.0) – NGINX Plus 고객은 이제 Prometheus로 메트릭을 내보낼 수 있고, active health check를 활용할 수 있게 되었습니다. 또한 모든 사용자는 Helm 차트, 병합 가능한 Ingress 리소스, 커스텀 템플릿 관리의 향상된 기능을 활용할 수 있게 되었습니다(NGINX Ingress Controller for Kubernetes 릴리스 1.3.0 발표 참조).
• 11월 (v1.4.0) – TCP/UDP 지원이 추가되어 Layer 4 트래픽 관리가 가능해졌습니다. 다른 기능으로는 커스텀 애노테이션의 개발이 쉬워졌고, 두 가지 선택의 무작위(Load-balancing algorithm) 알고리즘을 지원합니다.

2018년, Michael Pleshakov은 NGINX Ingress Controller를 Helm과 함께 배포하는 방법, HTTP 및 TCP/UDP 로드 밸런싱을 구성하는 방법, Prometheus를 사용한 모니터링 방법, 그리고 문제 해결 방법에 대해 공유했습니다.

4-4. 2019

표준 Kubernetes Ingress 리소스에 대한 대안을 처음으로 선보였습니다. 이를 통해 고급 기능을 더 쉽고 안정적으로 실행할 수 있게 되었습니다.

• 5월 (v1.5.0) – VirtualServer와 VirtualServerRoute (VS/VSR) 리소스가 새로운 구성 접근 방식으로 도입되었습니다. VS/VSR은 첫 번째 NGINX Ingress 리소스로, 네이티브하고, 타입-안전하며, 들여쓰기된 구성 스타일을 제공하여 Ingress 로드 밸런싱의 구현을 단순화합니다.
• 12월 (v1.6.0) – 문서가 구축되었습니다. VS/VSR 리소스는 더 풍부한 로드 밸런싱 지원을 추가하고 생산 준비를 완료합니다. 더 나은 모니터링과 디버깅 사례를 위해 OpenTracing 지원이 추가되었고, 보안을 향상시키기 위해 non-root 사용자로 실행할 수 있는 기능이 추가되었습니다.

2019, Michael Pleshakov은 VS/VSR을 사용한 사례, 예를 들어 Blue-Green 배포와 A/B 테스팅을 시연하였습니다.

4-5. 2020

NGINX Ingress 리소스에 대한 수많은 개선 외에도, 올해의 주요 주제는 생태계 도구와 NGINX 제품과의 통합입니다.

• 4월 (v1.7.0) – NGINX는 NGINX Ingress Operator를 출시하여 OpenShift 4.x 환경에서 NGINX Ingress Controller를 빠르고, 쉽게, 그리고 인증된 방식으로 배포할 수 있도록 제공하였습니다. NGINX Ingress 리소스는 추가 프로토콜, 서킷 브레이커, 개선된 검증 및 보고를 지원하면서 계속 성장하고 있습니다.
• 7월 (v1.8.0) – NGINX App Protect WAF와의 통합을 통해 고객들은 NGINX Ingress Controller 2.0 과 같은 컨테이너에서 경량, 유연한 WAF를 배포할 수 있게 되었습니다. 스니펫 또는 커스텀 템플릿을 통한 NGINX Ingress 리소스의 커스텀화가 추가되었고, URI Rewrite와 Access Control List 등의 기능은 더 세밀한 제어를 제공합니다.
• 10월 (v1.9.0) – NGINX Service Mesh와의 통합을 통해 North-South 및 East-West 트래픽을 같은 구성에서 관리할 수 있게 되었습니다. Grafana 대시보드가 추가되어 과거 데이터를 쉽게 시각화할 수 있습니다.

Amir Rawdat은 NGINX Ingress Operator를 사용하는 방법, 역할 기반 액세스 제어(RBAC)를 활용한 교차 기능 프로비저닝, NGINX App Protect를 사용한 컨테이너화된 앱 보안, JWT를 사용한 클라이언트 유효성 검사 등을 시연하였습니다.

4-6. 2021

보안이 주요 주제로, 더 많은 생태계 통합이 이루어졌습니다.

• 2월 (v1.10.0) – OpenID Connect (OIDC) 인증이 주요 추가 사항으로, JWT 인증을 쉽게 사용하여 강력한 단일 로그인(SSO) 옵션을 제공합니다(OpenID Connect와 NGINX Ingress Controller를 사용한 쉽고 강력한 단일 로그인 참조).
• 3월 (v1.11.0) – WAF와 로드 밸런싱 정책에 대한 주요 개선 사항이 추가되어 더 많은 힘과 유연성을 제공합니다. 이에는 Health Check와 상태 보고가 포함됩니다.
• 7월 (v1.12.0) – 이번 릴리스의 하이라이트는 배포의 용이성에 관한 것입니다. AWS Container Marketplace를 통한 구매 외에도 F5 Container Registry에서 사전 빌드된 이미지를 불러올 수 있게 되었습니다.
• 10월 (v2.0.3) – 기능 측면에서 주요 마일스톤은 아니지만, 이 릴리스는 Kubernetes API와 Ingress 객체의 발전과의 상호 운용성에 대한 마일스톤을 나타냅니다. 이 변경으로 인해 NGINX Ingress Controller 2.0 (및 이후 버전)은 Kubernetes 1.19 및 이후 버전과 호환됩니다. 또한 NGINX Ingress Controller 2.0은 Kubernetes 1.22 및 이후 버전에서 배포할 수 있는 유일한 버전입니다.

소프트웨어 엔지니어인 Aidan Carson은 NGINX Ingress Controller로 엣지를 보호하는 방법, NGINX Service Mesh로 서비스 간에 안전한 액세스 제어를 설정하는 방법, 그리고 mTLS로 Egress 트래픽을 보호하는 두 제품을 모두 사용하는 방법을 시연하였습니다.

5. NGINX Ingress Controller 2.0 사용해보기

만약 여러분이 오픈 소스 NGINX Ingress Controller 2.0 이 여러분의 앱에 적합한 선택이라고 결정했다면, GitHub 리포지토리에서 NGINX 오픈소스 기반의 NGINX Ingress Controller를 빠르게 시작할 수 있습니다.

대규모 프로덕션 배포를 위해 NGINX는 여러분이 NGINX Plus 기반의 상업용 NGINX Ingress Controller 2.0 을 시도해 볼 것을 바랍니다.
이는 NGINX App Protect를 포함한 무료 30일 시험판으로 사용할 수 있습니다.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.