Ingress에서 Gateway로 마이그레이션

Ingress에서 Gateway로 마이그레이션 (Migrating from Ingress to Gateway)

Gateway API는 Ingress API의 장기적인 후속일 뿐 아니라 HTTP/HTTPS 기반 애플리케이션을 넘어서는 사용 사례도 지원해요. 이 섹션은 Ingress의 일부 한계를 짚고 Gateway API의 이점과 Ingress API에서 Gateway API로 마이그레이션할 때의 옵션들을 설명해요.

출처: Migrating from Ingress to Gateway

본문

Gateway API는 Ingress API의 장기적인 후속일 뿐 아니라, HTTP/HTTPS 기반 애플리케이션을 넘어서는 사용 사례도 지원해요.

이 섹션은 Ingress의 일부 한계를 짚고, Gateway API의 이점을 설명하며, Ingress API에서 Gateway API로 마이그레이션할 때 사용할 수 있는 옵션들을 설명해요.

Ingress API의 한계 (Ingress API Limitations)

Gateway API의 개발은 Kubernetes Ingress API에 몇 가지 한계가 있다는 깨달음에서 시작됐어요.

  • 고급 라우팅 지원이 제한적
    • Ingress API는 경로와 호스트 규칙에 기반한 기본 라우팅만 지원하며, 트래픽 분할, 헤더 수정, URL 재작성 같은 고급 라우팅 기능을 기본으로 지원하지 않아요.
  • 프로토콜 지원이 제한적
    • Ingress API는 HTTP와 HTTPS 트래픽만 지원하며 TCP나 UDP 같은 다른 프로토콜은 기본으로 지원하지 않아요. Ingress API 스펙은 너무 제한적이고 충분히 확장 가능하지 않았어요. 이런 기술적 한계를 해결하기 위해 소프트웨어 공급업체와 개발자들이 벤더별 어노테이션을 만들었어요. 하지만 어노테이션을 사용하면 Ingress 컨트롤러마다 불일치가 생겼어요. 예를 들어 어노테이션은 종종 벤더별이기 때문에 한 Ingress 컨트롤러에서 다른 컨트롤러로 전환할 때 문제가 자주 발생했어요.
  • 운영상의 제약
    • 마지막으로 Ingress API는 운영상의 제약이 있어요. 공유 로드 밸런싱 인프라를 가진 다중 팀 클러스터에는 적합하지 않아요.

Gateway API의 이점 (Benefits of the Gateway API)

Gateway API는 Ingress API의 한계를 해결하도록 설계됐어요. Kubernetes SIG-Network 팀이 Gateway API를 설계하고 유지 관리해요.

Gateway API에 대한 더 많은 정보는 Gateway API 프로젝트 페이지를 참고해주세요.

Gateway API는 HTTP 라우팅, TLS 종료, 트래픽 분할/가중치, 헤더 수정을 포함한 외부 트래픽 정책을 관리하고 강제하는 중앙 집중식 메커니즘을 제공해요.

외부 트래픽에 대한 정책의 기본 지원은 ingress 트래픽 패턴을 지원하기 위해 더 이상 어노테이션이 필요하지 않다는 뜻이에요. 즉 Gateway API 리소스는 한 Gateway API 구현에서 다른 구현으로 더 이식 가능해요.

커스터마이제이션이 필요할 때 Gateway API는 다양한 트래픽 패턴을 가능하게 하는 특정 확장 지점을 포함한 여러 유연한 모델을 제공해요. Gateway API 팀이 확장을 추가할 때 공통 분모를 찾고 API conformance의 기능을 승격시켜서 Ingress API 리소스를 확장하는 용이성을 극대화해요.

마지막으로 Gateway API는 역할 기반 페르소나를 염두에 두고 설계됐어요. Ingress 모델은 개발자가 ingress와 service 리소스를 스스로 관리하고 만들며 사용하는 페르소나에 기반해요.

더 복잡한 배포에는 더 많은 페르소나가 관여해요:

  • 인프라 프로바이더(Infrastructure Providers): 클라우드 프로바이더의 관리 서비스, 또는 온프레미스에서 Kubernetes를 실행한다면 인프라/네트워크 팀을 관리해요.
  • 클러스터 운영자(Cluster Operators): 클러스터의 관리를 담당해요.
  • 애플리케이션 개발자(Application Developers): 애플리케이션 구성과 서비스 구성(composition)을 정의하는 책임이 있어요.

Ingress API를 여러 Gateway API 객체로 분해함으로써, 페르소나들은 자신의 책임에 필요한 특정 접근과 권한을 얻게 돼요.

예를 들어 특정 팀의 애플리케이션 개발자에게 지정된 네임스페이스에서 Route 객체를 만들 권한을 부여할 수 있고, 동시에 Gateway 구성을 수정하거나 다른 네임스페이스의 Route 객체를 편집할 권한은 부여하지 않을 수 있어요.

더 원활한 마이그레이션을 위해 이 워크플로를 사용해주세요:

  • 마이그레이션 범위와 롤아웃 단계를 구성하세요.
  • NGINX Ingress Annotations to Gateway API Migration으로 현재 NGINX 어노테이션을 인벤토리화하고 분류하세요.
  • 동등한 Gateway API 리소스를 만들고 병렬로 검증하세요.
  • 트래픽을 점진적으로 전환하고 SLO를 모니터링하세요.
  • 안정화된 후 레거시 Ingress 리소스를 제거하세요.

마이그레이션 방법 (Migration Methods)

Ingress API 리소스를 Gateway API로 마이그레이션하는 두 가지 주요 방법이 있어요:

  • manual: 기존 Ingress API 리소스를 기반으로 Gateway API 리소스를 수동으로 만들어요.
  • automated: ingress2gateway 도구를 사용해 규칙을 만들어요. ingress2gateway 프로젝트는 현재 Kube Config를 기반으로 Kubernetes 클러스터에서 Ingress 리소스를 읽어요. 동등한 Gateway API 리소스에 대한 YAML을 stdout으로 출력해요.

참고

ingress2gateway 도구는 여전히 실험적이며 프로덕션에는 권장되지 않아요.

Ingress 어노테이션 마이그레이션 (Ingress Annotations Migration)

대부분의 Ingress 컨트롤러는 HTTP 요청 조작과 라우팅 같은 특정 기능을 제공하기 위해 어노테이션을 사용해요. Gateway API의 이점에서 언급했듯이, Gateway API는 이식 가능한 구성을 제공하기 위해 구현별 어노테이션을 피해요.

결과적으로 구현별 Ingress 어노테이션을 Gateway API 리소스로 이식하는 경우는 드물어요. 대신 Gateway API는 다음을 포함한 일부 기능을 기본 지원해요:

  • 요청/응답 조작
  • 트래픽 분할
  • 헤더, 쿼리 매개변수 또는 메서드 기반 라우팅

NGINX 기반 마이그레이션의 경우 매핑 힌트를 제공하는 NGINX Ingress Annotations to Gateway API Migration을 사용하세요.

마이그레이션 가이드와 예제 (Migration Guides and Examples)

Cilium의 Gateway API 기능으로 마이그레이션하는 예제는 다음을 참고해주세요:

  • HTTP Migration Example
  • TLS Migration
  • NGINX Ingress Annotations to Gateway API Migration

더 알아보기 (Learn more)