[K8s deepdive] Ingress, Gateway API 비교

~ MSA에서 인바운드 트래픽을 처리하기 위한 두 가지 옵션 : Ingress 와 Gateway API ~

근데 용어가 너무 헷갈림

• Ingress
• Ingress API
• Ingress Controller
• Gateway API
• Ingress Gateway API

이렇게 다 섞여서 증식되듯(?) 나오는데

얘네의 차이/정의부터 알고가야 할듯.

 

 

Ingress, Ingress API, Ingress Controller, Gateway API, Ingress Gateway API

- 모두 클러스터 외부의 트래픽을 클러스터 내부의 서비스로 라우팅하는 것과 관련된 개념
- 모두 클러스터 외부 트래픽을 내부로 라우팅하는 역할

 

 

1. Ingress

• 정의: Ingress는 쿠버네티스 클러스터 외부의 HTTP 및 HTTPS 트래픽을 클러스터 내의 서비스로 라우팅하는 역할, 단일 IP 주소로 외부에서 접근하여 클러스터 내의 여러 서비스로 트래픽을 분산시키는 기능
• 주요 기능:
  • 외부에서 접근 가능한 URL 경로 설정
  • SSL/TLS를 통한 보안 설정
  • 여러 서비스에 대한 로드 밸런싱
• 차별점: Ingress는 트래픽을 관리하는 고수준의 추상화 기능으로, 서비스들 간의 HTTP(S) 요청을 라우팅하는 데 사용

2. Ingress API

• 정의: Ingress API는 쿠버네티스에서 Ingress 리소스를 정의하기 위한 API, 이 API는 사용자가 클러스터로 들어오는 HTTP(S) 트래픽을 어떻게 처리할지를 명시할 수 있는 YAML 구성 파일을 통해 설정
• Ingress API를 통해 구성되고, Ingress Controller에 의해 실제로 트래픽이 처리
• 주요 기능:
  • 사용자는 Ingress API를 통해 트래픽 규칙, 라우팅 경로, SSL/TLS 설정 등을 지정합니다.
• 차별점: Ingress API는 트래픽 규칙을 정의하는 데 사용되는 API로, 실제 트래픽을 처리하는 것은 Ingress Controller가 담당합니다.

3. Ingress Controller

• 정의: Ingress Controller는 Ingress 리소스에서 정의된 규칙을 실제로 구현하고 실행하는 소프트웨어, 즉, Ingress API에서 정의된 규칙을 기반으로 트래픽을 수신하고 라우팅 == 실제로 역할 하는 녀석
• Ingress API로 정의된 트래픽 규칙을 실제로 처리하는 컨트롤러
• 주요 기능:
  • 클러스터 외부로부터 들어오는 트래픽을 감지하고, 규칙에 따라 내부 서비스로 트래픽을 분배.
  • 로드 밸런싱, SSL 처리, URL 경로 기반 라우팅 등 제공.
• 차별점: Ingress Controller는 NGINX, HAProxy, Contour, Traefik 등 , Ingress API로 설정한 규칙에 따라 트래픽을 실제로 처리하는 컨트롤러

4. Gateway API

• 정의: Gateway API는 Ingress API의 한계*를 보완하기 위해 제안된 멀티 테넌트 네트워크 라우팅 솔루션, 더 유연하고 강력한 기능을 제공하며, 다양한 유형의 Layer 7 리소스를 쉽게 관리할 수 있도록 설계됨
• 주요 기능:
  • 멀티 테넌트 지원: 하나의 클러스터에서 여러 사용자가 서로 독립적으로 네트워크 트래픽을 관리할 수 있습니다.
  • 다양한 라우팅 프로토콜 지원: HTTP, HTTPS 외에도 TCP, UDP 트래픽까지 지원
  • 더 세분화된 트래픽 정책 설정 가능.
• 차별점: Gateway API는 Ingress API보다 더 확장 가능하고 다양한 프로토콜을 지원하며, 멀티 테넌트 환경에 적합하게 설계된 최신 네트워크 라우팅 솔루션입니다.

* 저 한계가 crd를 일일이 적어줘야한다는

 

5. Ingress Gateway API

• 정의: Ingress Gateway API는 Gateway API의 기능 중 하나로, Ingress API와 비슷한 역할을 하지만 Gateway API의 프레임워크 내에서 운영됨...!!>!>? 이는 클러스터 외부에서 클러스터 내부로의 HTTP(S) 트래픽을 라우팅하는 데 사용된다
• 주요 기능:
  • 기존 Ingress API와 유사한 방식으로 HTTP(S) 트래픽을 처리하되, Gateway API의 구조를 통해 더 유연하고 강력한 라우팅 기능 제공.
• 차별점: Ingress Gateway API는 Gateway API의 한 부분으로, Ingress와 유사한 트래픽 관리 기능을 수행하지만, 더 복잡한 라우팅 요구 사항을 충족할 수 있습니다.

 

용어	정의	주요기능	차이점
Ingress	쿠버네티스 클러스터로 외부 트래픽을 HTTP/HTTPS로 라우팅하는 리소스	URL 경로 및 로드 밸런싱, SSL/TLS 처리	HTTP/HTTPS 트래픽을 클러스터 내부 서비스로 분배하는 역할.
Ingress API	Ingress 리소스를 정의하는 쿠버네티스 API	트래픽 규칙, SSL 설정, URL 경로 지정	Ingress 리소스의 규칙을 정의하는 API, 트래픽 처리는 하지 않음.
Ingress Controller	Ingress API에서 정의된 규칙을 실제로 구현하고 실행하는 소프트웨어	트래픽 라우팅, 로드 밸런싱, SSL 처리	Ingress 리소스의 트래픽 규칙을 실제로 처리하는 컨트롤러. NGINX, Traefik, Contour 등 다양한 구현체 존재.
Gateway API	Ingress API의 한계를 보완한 새로운 멀티 테넌트 네트워크 라우팅 API	멀티 테넌트 지원, 다양한 프로토콜 라우팅(TCP, UDP), 더 복잡한 트래픽 정책 설정 가능	확장 가능하고 유연한 라우팅 솔루션으로, Ingress API를 대체할 가능성이 크며 더 세밀한 제어가 가능함.
Ingress Gateway API	Gateway API 내에서 Ingress와 비슷한 역할을 수행하는 기능	HTTP/HTTPS 트래픽 라우팅, 더 유연한 트래픽 관리	기존 Ingress와 유사하지만, Gateway API의 프레임워크를 통해 더 강력하고 유연한 라우팅 기능을 제공.

---

결론

• Ingress는 쿠버네티스 클러스터로 외부 트래픽을 라우팅하는 고수준의 개념
• Ingress API는 이러한 라우팅 규칙을 정의하는 API이며, Ingress Controller가 그 규칙을 실제로 처리
• Gateway API는 Ingress API보다 더 유연하고 확장 가능한 멀티 테넌트 네트워크 솔루션
• Ingress Gateway API는 Gateway API 내에서 Ingress와 유사한 기능을 수행하면서도 더 많은 기능을 제공

 

<Kubernetes In Action의 한 구절에서...🍁🍁>

Kubernetes의 기존 Ingress API는 NGINX에 의해 표준✳️으로 구현되었습니다. 하지만 곧 두 가지 큰 변화🥵가 일어났습니다:

- Contour가 대안적인 CNCF(Cloud Native Computing Foundation) Ingress 컨트롤러로 등장했습니다.
- Gateway API가 Kubernetes 클러스터에서 라우팅을 노출하는 문제에 대한 더 나은 멀티 테넌트 솔루션으로 등장했습니다.

Gateway API는 Ingress API보다 훨씬 더 설명적이고, Layer 7 리소스의 다양한 유형을 더 유연하게 설명할 수 있어 개발자들에게 더 나은 기능을 제공합니다.

Ingress 컨트롤러(또는 Gateway API)를 구현하려면 트래픽을 어떻게 라우팅할지 결정해야 합니다.
Ingress 컨트롤러의 IP 주소는 일반적인 ClusterIP 서비스와 다르기 때문입니다.
Ingress 컨트롤러가 다운되면 클러스터로의 모든 트래픽이 중단되므로, 클러스터 내에서 실행하는 경우 Ingress 컨트롤러를 모든 노드에서 DaemonSet으로 실행하는 것이 좋습니다.

Contour는 Envoy 프록시 기술을 사용하여 서비스 프록싱의 기반으로 작동합니다.

Envoy는 Ingress 컨트롤러, 서비스 메시, 기타 네트워킹 기술을 구축하는 데 사용할 수 있으며,
이를 통해 트래픽을 투명하게 전달하거나 관리할 수 있습니다.
Kubernetes Services API는 Kubernetes 커뮤니티에서 계속 혁신 중인 분야입니다.
클러스터가 점점 커짐에 따라, 앞으로 몇 년 동안 더 복잡한 트래픽 라우팅 모델에 대한 필요성이 증가할 것입니다.

 

 

이전에 있던 궁금증이...

Istio를 연결하면 istio ingress gateway로 통하게 되는데

istio를 붙여도 kubernetes gateway api를 붙일 수 있다는 선택지와 상황에 대한 거였음

어떤 차이가 있는지 명확히 짚고 넘어가지 않았어서 (머리에 남아있지 않은 것을 보아)

정리해 보자~

 

 

• 전에 정리해 뒀던 것

🔹Istio Ingress Gateway

= 메시로 들어오는 요청의 진입점
= 로드 밸런서로 정의된 배포 및 서비스와 함께 배포된 리소스

istio.io와 같은 호스트 이름에 대한 요청을 특정 포트(HTTP)에서 수신하는 Istio Ingress 리소스를 생성할 수 있기 때문에 유리
여러 호스트에 대해 이 작업을 수행할 수 있음
동일한 게이트웨이에 대해 여러 Ingress 리소스를 생성하면 리소스에 사실상 과부하가 발생할 수 있으므로 이는 중요합니다. 
이렇게 하면 서비스당 여러 로드 밸런서를 조달하는 비용이 절약됩니다.

여기서 말하는 "사실상 과부하"라는 표현은 하나의 게이트웨이에 여러 Ingress 리소스를 연결하면, 
이 리소스들이 동시에 처리해야 할 트래픽이 증가한다는 의미입니다. 

하지만 이는 실제로 과부하를 초래하는 것이 아니라, 
여러 서비스나 호스트에 대한 라우팅 규칙을 중앙에서 효율적으로 관리할 수 있게 해줍니다.

즉, 여러 Ingress 리소스를 하나의 게이트웨이에 연결함으로써, 여러 서비스나 호스트에 대한 요청을 하나의 게이트웨이에서 효율적으로 처리할 수 있습니다. 이는 각 서비스마다 별도의 로드 밸런서를 구축하는 비용을 절약하게 해주며, 관리도 간소화됩니다.

간단히 말해, 이 방법은 비용과 관리 효율성을 향상시키면서도 트래픽 라우팅을 중앙에서 효과적으로 관리할 수 있는 방법을 제공합니다.

 

Istio Ingress Gateway로 노출되는 모든 서비스는,

• 해당 서비스 유형이 ClusterIP로 설정된다는 것을 의미
• 서비스에 직접 연결하지 않고 Ingress 게이트웨이를 통해 연결
• -> 이는 TLS를 사용한 보안 계층이기도 함

 

 

• Kubernetes Ingress는 트래픽 라우팅을 담당, Istio Ingress Gateway는 서비스 메시의 일부로서 보안, 트래픽 관리, 모니터링, 라우팅 기능을 제공
• Istio Ingress Gateway는 TLS termination 및 mTLS를 기본적으로 제공하며, 모든 트래픽을 서비스 메시 규칙에 따라 관리할 수 있음

 

근데 istio 쓰면서 k8s gateway api 쓸 수 있긴 한데 그런 경우가 왜 필요한건지가 궁금

 

https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/

Kubernetes Gateway API

how to configure Istio to expose a service outside the service mesh cluster using the Gateway API.

->  Gateway API를 사용하여 서비스 메시 클러스터 외부에 서비스를 노출하도록 Istio를 구성하는 방법 을 위해서!?

 

- Istio의 Gateway API 지원

Istio는 2020년 11월에 Gateway API에 대한 지원을 추가했으며. 또한 조기 채택자에게 메시(서비스 간) 사용을 위해 Gateway API를 실험해 보라고 권장하며, SIG Network에서 필요한 의미 체계를 표준화하면 해당 지원을 베타로 옮길 것입니다.

API v1 릴리스 시점에, 우리는 Gateway API를 Istio의 모든 트래픽 라우팅을 구성하는 기본 방법으로 만들려고 합니다.

즉, 수신(북-남) 및 서비스 간(동-서)을 위한 것입니다. (밑 사진 서비스 방향을 보면 이해가 빠름)

출처 : https://medium.com/diby-uxresearchops/aws-eks-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-istio%EB%A5%BC-%ED%86%B5%ED%95%9C-gateway-api-%EB%8F%84%EC%9E%85-%EC%82%AC%EB%A1%80-048eef9ce0f2

 

 

Gateway API가 안정화된 후에도 Kubernetes가 Ingress API를 수년간 지원할 계획인 것처럼 Istio API(Gateway, VirtualService 및 DestinationRule)도 당분간 지원될 예정입니다.

그뿐만 아니라, 예를 들어 HTTPRoute를 Istio VirtualService 와 함께 사용하는 등 Gateway API와 함께 기존 Istio 트래픽 API를 계속 사용할 수 있습니다 .

API가 유사하다는 것은 Istio API 객체를 Gateway API 객체로 쉽게 변환하는 도구를 제공할 수 있다는 것을 의미하며, 이러한 사용 사례의 표준화를 진행하는 동안 Istio 전용 API를 사용하여 계속 구성됩니다.

 

 

• Istio 환경에서 Gateway API를 사용하면 다른 Kubernetes-native 트래픽 관리 방식과 더 쉽게 통합할 수 있다.
• Istio도 멀티-테넌시 지원이 가능하지만, Gateway API는 멀티-테넌트를 지원하는 데 있어서 더 구체적이고 직관적인 API를 제공하기 때문에,  여러 테넌트가 트래픽을 중앙에서 효율적으로 관리하면서도 각자 독립적인 라우팅 정책을 유지해야 하는 경우, Gateway API가 도움이 된다.
• Istio는 mTLS와 같은 보안 기능과 트래픽 제어 기능을 제공하며, 서비스 메시 내부의 서비스 간 통신을 관리하지만, 클러스터에 존재하는 다른 서비스 메시나 다양한 트래픽 제어 방식이 필요할 수 있는 경우 Gateway API를 사용하여 Istio가 아닌 다른 인그레스 방식과 조화를 이루며 트래픽을 관리할 수 있다.
• Istio는 기본적으로 HTTP와 gRPC 같은 Layer 7 프로토콜에 강하지만, Istio만으로는 다루기 어려운 Layer 4 트래픽 관리에 Gateway API를 추가하여 대응할 수 있다.

 

근데 istio ingress gateway api에서 들어오는 Ingress 경로만 kubernetes gateway api로 또 바꿔주고 설정하는 것보다 istio ingress gateway 그대로 쓰고 layer4 트래픽은 다른 서비스를 붙이는 게 나을 것 같다는 생각이 ~ 든당. (ex . calico?)

 

 

---

<참고>

 

이 글 이해하기 쉽게 적어놓음

https://medium.com/diby-uxresearchops/aws-eks-%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C-istio%EB%A5%BC-%ED%86%B5%ED%95%9C-gateway-api-%EB%8F%84%EC%9E%85-%EC%82%AC%EB%A1%80-048eef9ce0f2

AWS EKS 환경에서 Istio를 통한 Gateway API 도입 사례

 

 

https://www.reddit.com/r/kubernetes/comments/1eeq7td/i_cannot_understand_the_difference_between/

From the kubernetes community on Reddit

 

 

https://dev.to/vivekanandrapaka/istio-ingress-gateway-vs-istio-gateway-vs-kubernetes-ingress-5hgg

Istio Ingress gateway vs Istio Gateway vs Kubernetes Ingress

제목부터 따악 내가 원하던 것였는데 생각보다 비교 내용은 적은...

 

https://thenewstack.io/ingress-controllers-or-the-kubernetes-gateway-api-which-is-right-for-you/

Ingress Controllers or the Kubernetes Gateway API? Which Is Right for You?