NGINX Ingress Controller 버전 2.0: 알아야 할 사항

Brian Ehlert제품 관리 이사

10월에는 F5 NGINX Ingress Controller 버전 2.0(nginxinc/kubernetes-ingress)을 출시하면서 Kubernetes 1.22 및 Ingress API 버전 1(networking.k8s.io/v1)에 대한 지원을 추가했습니다. 그래서 무엇이 달라졌는지 궁금하실 수 있습니다. 그래서 뭐가 달라졌을까요?

그 “그래서 그게 왜 중요한가?”에 대한 답은 다소 복합적이며, 서로 연관된 세 가지 질문에 답하면서 설명하겠습니다:

• Kubernetes 릴리스가 중요한 이유는 무엇인가요?
• Ingress API란 무엇이며 networking.k8s.io/v1로의 업그레이드가 중요한 이유는 무엇인가요?
• NGINX Ingress Controller 2.0은 기존 고객에게 어떤 영향을 미치나요?

계속 읽으며 답을 확인하고, 2022년 1월 11일에 진행되는 Kubernetes 버전의 공격에 대비하는 전투 계획을 시청해 보세요.

Kubernetes 릴리스가 중요한 이유는 무엇일까요?

이 질문에 대한 답은 간단하면서도 복잡합니다. Kubernetes의 호환성 관리가 어려운 이유는 Kubernetes 운영자가 세 가지 버전 범주를 관리해야 하기 때문입니다:

1. Kubernetes 플랫폼 자체 – 새 릴리스가 나올 때마다 Kubernetes 팀은 이전 버전의 유지 관리를 중단합니다. 이러한 버전을 계속 사용하면 위험 관리 전략에 문제가 생기며, 더 이상 Kubernetes 팀의 도움을 받을 수 없어 문제 해결도 어려워집니다. 현재 Kubernetes 프로젝트는 최신 마이너 릴리스 3개(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의 주요 변경 사항은 Ingress 컨트롤러와 같은 도구 및 관련 리소스가 계속 정상적으로 작동하는지에 영향을 줄 수 있습니다.

따라서 Kubernetes, Ingress API, NGINX Ingress Controller의 세 가지 일정을 추적해야 합니다. Kubernetes에 문제가 발생하지 않도록 하려면 Kubernetes 버전이 API 및 NGINX Ingress Controller와 호환되는 최적의 지점을 찾아야 합니다. 호환성을 확인하지 않고 이 세 구성 요소 중 하나라도 업그레이드하면 심각한 결과를 초래할 수 있습니다. 세 구성 요소가 모두 서로 호환되지 않는다면… 축하합니다. 애플리케이션이 망가졌습니다!

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

Ingress API를 사용하면 Ingress 컨트롤러가 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 리소스가 작동하지 않게 되었습니다!

NGINX Ingress Controller 2.0은 기존 고객에게 어떤 영향을 미치나요?

NGINX Ingress Controller는 Ingress API와 긴밀하게 결합되어 있으므로 v1 릴리스는 제품인 NGINX Ingress Controller뿐만 아니라 고객 여러분에게도 상당한 영향을 미쳤습니다. 이에 따라 NGINX Ingress Controller의 버전 번호를 1.x에서 2.x로 올렸습니다. NGINX Ingress Controller 2.0은 Ingress API v1을 활용하도록 아키텍처를 재설계하여 Kubernetes 1.22와 완벽하게 호환됩니다.

NGINX Ingress Controller를 사용하는 경우 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 버전(v1beta1 계열 및 v1)을 지원하므로 기존 환경에서 바로 변환할 수 있습니다.
  • 아직 이전하지 않았다면 Ingress 및 IngressClass 리소스를 즉시 networking.k8s.io/v1로 이전하세요.
    • 지원 중단된 kubernetes.io/ingress.class 어노테이션을 Ingress 리소스에서 사용하고 있다면 ingressClassName 필드로 전환하는 것이 좋습니다.
    • 업데이트를 계획하려면 문서 및 예시(networking.k8s.io/v1 및 Ingress 리소스의 ingressClassName 필드와 함께 제공됨)를 참조하세요.
• Kubernetes 1.22:
  • 이전 버전의 NGINX Ingress Controller는 Kubernetes 1.22와 호환되지 않고 Ingress API v1을 지원하지 않으므로, NGINX Ingress Controller 2.0을 이미 실행 중인지 확인하세요.

NGINX Ingress Controller의 (그리 짧지만은 않은) 역사

2016년 처음 출시된 이후 NGINX Ingress Controller는 초기 단계의 도구에서 Kubernetes 네트워킹을 위한 강력한 솔루션으로 성장했습니다. 출시부터 현재까지 어떻게 발전해 왔는지 살펴보겠습니다.

2016년 (v0.5.0)

NGINX 엔지니어 Michael Pleshakov가 GitHub 리포지토리에 첫 번째 항목을 게시하여(nginxinc/kubernetes-ingress), NGINX와 F5 NGINX Plus를 Kubernetes Ingress 컨트롤러(KIC)로 사용할 수 있게 되었습니다.

NGINX Ingress Controller가 KubeCon EU 2016에서 처음으로 대중에게 공개됩니다. 다음 녹화 영상을 확인해 보세요: 1일 차, NGINX를 활용한 Kubernetes용 고급 부하 분산 솔루션 구축; KubeCon EU 2016.

2017년 (v1.0.0)

이 프로젝트는 NGINX Plus 기반 버전에서 JSON 웹 토큰(JWT)을 핵심적으로 지원하는 등 프로덕션 환경에서 사용할 수 있는 수준에 도달했습니다.

NGINX Conf 2017에서 Michael Pleshakov는 Kubernetes에서 애플리케이션의 부하 분산을 위한 Ingress 컨트롤러로 NGINX Plus 사용을 통해 고급 부하 분산을 비롯한 프로덕션 환경의 기능을 시연합니다.

2018

NGINX Ingress Controller는 가시성, 사용 편의성 및 유연성 측면에서 크게 향상되었습니다:

• 5월 (v1.2.0) – 프로젝트에서 새로운 NGINX Plus API를 도입하고 nginx-ingress 이미지를 공식 NGINX Docker Hub로 이전했습니다. 이 버전에서는 gRPC, 수동 상태 확인, Helm 차트 및 Prometheus 지원이 처음 도입되었습니다.
• 8월 (v1.3.0) – 이제 NGINX Plus 고객은 메트릭을 Prometheus로 내보내고 능동 상태 확인을 활용할 수 있으며, 모든 사용자가 개선된 Helm 차트, 병합 가능한 Ingress 리소스, 더욱 간편해진 사용자 지정 템플릿 관리 기능을 이용할 수 있습니다(참조: NGINX Ingress Controller for Kubernetes 릴리스 1.3.0 발표).
• 11월 (v1.4.0) – TCP/UDP 지원이 추가되어 레이어 4 트래픽을 관리할 수 있습니다. 그 밖에도 사용자 지정 어노테이션을 더 쉽게 개발할 수 있으며, 두 가지 무작위 선택(Random with Two Choices) 부하 분산 알고리즘을 지원합니다(참조: NGINX Ingress Controller for Kubernetes 릴리스 1.4.0 발표).

NGINX Conf 2018에서 Michael Pleshakov는 NGINX를 Kubernetes Ingress Controller로 사용하기 세션을 통해 Helm으로 NGINX Ingress Controller를 배포하고, HTTP 및 TCP/UDP 부하 분산을 구성하며, Prometheus로 모니터링하고, 문제를 해결하는 방법을 공유합니다.

2019

표준 Kubernetes Ingress 리소스를 대체하는 솔루션을 선보여, 고급 기능을 더욱 쉽고 안정적으로 구현할 수 있도록 했습니다.

• 5월(v1.5.0) – 새로운 구성 방식으로 VirtualServer 및 VirtualServerRoute(VS/VSR) 리소스가 도입되었습니다. VS/VSR은 최초의 NGINX Ingress 리소스로, 네이티브 방식의 형식 안전성과 들여쓰기를 지원하는 구성 스타일을 제공하여 Ingress 부하 분산을 더 간편하게 구현할 수 있습니다(참조: Kubernetes용 NGINX Ingress Controller 릴리스 1.5.0 발표<.htmla>).
• 12월(v1.6.0) – docs.nginx.com에 문서가 마련되었습니다. VS/VSR 리소스에 더욱 풍부한 부하 분산 지원이 추가되어 프로덕션 환경에서 사용할 수 있는 수준에 도달했습니다. 모니터링 및 디버깅 활용 사례를 개선하기 위해 OpenTracing 지원이 추가되었으며, 보안을 강화하기 위해 root가 아닌 사용자로 실행할 수 있는 기능도 추가되었습니다(참조: Kubernetes용 NGINX Ingress Controller 릴리스 1.6.0 발표).

In 차세대 NGINX Ingress Controller에서 Michael Pleshakov는 NGINX Conf 2019 무대에 다시 올라 블루-그린 배포와 A/B 테스트 등의 사용 사례를 위한 VS/VSR을 시연합니다.

2020

NGINX Ingress 리소스에 대한 다양한 개선 사항과 더불어, 올해의 주요 주제는 에코시스템 도구 및 NGINX 제품과의 통합입니다.

• 4월 (v1.7.0) – OpenShift 4.x 환경에서 NGINX Ingress Controller를 빠르고 간편하게, 인증된 방식으로 배포할 수 있도록 NGINX Ingress Operator를 출시했습니다. 추가 프로토콜과 회로 차단기를 지원하고 검증 및 보고 기능을 개선하는 등 NGINX Ingress 리소스도 계속 확장되고 있습니다(참조: 「Kubernetes용 NGINX Ingress Controller 1.7.0 릴리스 발표」).
• 7월 (v1.8.0) – F5 NGINX App Protect WAF과의 통합을 통해 고객은 Ingress 컨트롤러와 동일한 컨테이너에 가볍고 유연한 WAF를 배포할 수 있습니다. 스니펫 또는 사용자 지정 템플릿을 통한 NGINX Ingress 리소스 사용자 지정 기능이 추가되었으며, URI 재작성 및 액세스 제어 목록 등의 기능을 통해 더욱 세밀하게 제어할 수 있습니다(참조: Kubernetes용 NGINX Ingress Controller 릴리스 1.8.0 발표).
• 10월(v1.9.0) – F5 NGINX Service Mesh와의 통합을 통해 동일한 구성에서 남북 및 동서 트래픽을 관리할 수 있습니다. 과거 데이터를 쉽게 시각화할 수 있도록 Grafana 대시보드가 추가되었습니다(참조: NGINX Ingress Controller 릴리스 1.9.0 발표).

In NGINX 및 OpenShift로 프로덕션 앱 보호에서 기술 마케팅 엔지니어 Amir Rawdat은 NGINX Ingress Operator를 사용하는 방법, 부서 간 프로비저닝을 위해 역할 기반 액세스 제어(RBAC)를 활용하는 방법, NGINX App Protect로 컨테이너화된 앱을 보호하는 방법, 그리고 JWT로 클라이언트를 검증하는 방법을 시연합니다.

2021

보안이 주요 테마이며, 더 많은 생태계 통합도 이루어졌습니다.

• 2월(v1.10.0) – 주요 추가 기능은 OpenID Connect(OIDC) 인증으로, JWT 인증을 사용해 강력한 SSO(Single Sign-On) 옵션을 손쉽게 제공할 수 있습니다(참조: OpenID Connect와 NGINX Ingress Controller를 활용한 간편하고 강력한 SSO).
• 3월 (v1.11.0) – WAF 및 부하 분산 정책이 대폭 개선되어 상태 검사와 상태 보고를 비롯한 기능과 유연성이 한층 강화되었습니다(참조: 「NGINX Ingress Controller를 통한 향상된 TCP/UDP 부하 분산 및 WAF 구성」).
• 7월 (v1.12.0) – 이번 릴리스의 주요 특징은 배포 편의성에 초점을 맞추고 있습니다. AWS Container Marketplace를 통한 구매 외에도 F5 Container Registry에서 사전 빌드된 이미지를 가져올 수 있도록 지원합니다(컨테이너용 AWS Marketplace에서 NGINX 이용 가능 참조).
• 10월(v2.0.3) – 기능 측면에서 중요한 이정표가 되는 릴리스는 아니지만, Kubernetes API와의 상호 운용 및 Ingress 객체의 발전이라는 측면에서는 중요한 의미를 갖습니다. 이번 변경으로 NGINX Ingress Controller 2.0 이상은 Kubernetes 1.19 이상과 호환됩니다. 또한 Kubernetes 1.22 이상에 배포할 수 있는 버전은 NGINX Ingress Controller 2.0 이상뿐입니다.

NGINX Sprint 2.0 세션인 엔드 투 엔드 암호화로 마이크로서비스 완벽하게 다루기에서 소프트웨어 엔지니어 Aidan Carson은 NGINX Ingress Controller로 엣지를 보호하고, NGINX Service Mesh로 서비스 간 보안 액세스 제어를 설정하며, 두 제품을 모두 사용해 mTLS로 이그레스 트래픽을 보호하는 방법을 시연합니다.

다음 단계: NGINX Ingress Controller 사용해 보기

오픈 소스 Ingress 컨트롤러가 애플리케이션에 적합한 선택이라고 판단하셨다면, NGINX Open Source 기반 NGINX Ingress Controller를 다음 GitHub 리포지토리에서 빠르게 시작할 수 있습니다.

대규모 프로덕션 배포에는 NGINX Plus 기반의 상용 NGINX Ingress Controller를 사용해 보시기 바랍니다. 30일 무료 평가판을 이용할 수 있으며, NGINX App Protect가 포함되어 있습니다.

작성자 소개

Brian Ehlert제품 관리 이사

Brian Ehlert의 다른 블로그 게시물