[Kubernetes] 쿠버네티스 Ingress - Deep Dive (1) Ingress & Ingress Controller 개념
일전에 Ingress 내용으로 글을 작성한 내용이 있었으나, 보완하여 재구성하였습니다.
Ingress 개요
영어에서 Ingress에 대한 사전적인 정의는 다음과 같다.
💡 Ingress 사전적 정의
The act of going in or entering; the right to enter; a means or place of entering; entryway.
들어가는 혹은 입장하는 행위;
쿠버네티스에서의 Ingress는 외부 클라이언트가 클러스터 내 실행중인 어플리케이션 서비스에 접근하는 방법이다. Ingress는 클라이언트의 요청을 Routing Rule에 따라 특정 서비스로 접근할 수 있게 도와주는 역할을 수행한다.
Ingress 기능
쿠버네티스 Ingress는 아래 3가지 기능을 내포한다.
- Ingress API 오브젝트는 클러스터 외부에서 내부 서비스로 접근하는 요청들을 어떻게 처리할지 정의해둔 규칙들의 모음이다.
- L7 Load Balancer 혹은 Reverse Proxy 역할로써, 백엔드 서비스로 트래픽을 라우팅한다.
- Ingress Controller는 Ingress 오브젝트와 연관된 Kubernetes API를 모니터링을 수행하며, Load Balancer 혹은 Reverse Proxy에 이를 반영한다.
💡 Forward Proxy vs Reverse Proxy
Forward Proxy (Client ↔ Proxy Server↔ Internet ↔ Web Server)
클라이언트로 부터 전달받는 요청들을 Forward Proxy 서버가 직접 받아 인터넷에 연결하여 전달받는 결과값을 클라이언트에 전달해준다.
Forward Proxy 서버는 일반적으로 클라이언트와 동일 선상에서 대상 서버를 향해 라우팅하고 Outgoing 트래픽을 필터링하는 역할을 수행한다.
Reverse Proxy (Client ↔ Internet ↔ Proxy Server ↔ Web Server)
클라이언트가 인터넷으로 데이터를 요청하면 Reverse Proxy 서버가 이 요청을 받아 백엔드 서버로부터 데이터를 전달받은 후 클라이언트로 전달한다.
Reverse Proxy 서버는 일반적으로 백엔드 서버와 동일 선상에서 인터넷으로 전달받는 incoming 트래픽을 다루고 이를 하나 이상의 backend 서버로 전달하는 역할을 수행한다.
Ingress 특징
- 각 Deployment에 대하여 일일이 설정을 적용할 필요 없이 하나의 설정 지점에서 처리 규칙을 정의하기만 하면 된다.
- Ingress를 통해 (1) 고유한 주소를 제공하여 사용 목적에 따라 다른 응답을 제공할 수 있고, (2) 트래픽에 대한 L4/L7 로드밸런서와 보안 인증서를 처리하는 기능을 제공한다.
- Ingress는 쿠버네티스에서 ingress라는 이름으로 사용할 수 있으며, kubectl get ingress 명령어로 인그레스의 목록을 확인할 수 있다.
Ingress 를 사용하는 이유
서비스 타입의 단점을 극복하기 위해 쿠버네티스에서는 Ingress를 사용한다.
[NodePort]
① NodePort 서비스는 포트를 중복 사용할 수 없어서 1개의 NodePort에 1개의 Deployment만 적용이 된다. SSL/TLS 연결, 접근 도메인 및 클라이언트 상태에 기반한 라우팅 등을 구현하려면 일일이 설정을 해야 한다.
② 여러개의 Deployment가 있을 때 그 수만큼 NodePort 서비스를 구동하기에는 비효율적이다.
[Load Balancer]
일반적으로 Layer 4 (TCP, UDP)에서의 요청을 처리하며, 네트워크 요청에 대한 세부적인 처리 로직을 구현하기는 한계점이 존재한다.
① SSL/TLS Termination 불가능
② 1개의 Load Balancer로 여러 서비스 연결 불가능 (L7 Layer Routing 불가능(Virtual Host, Path-Base Routing))
Ingress 오브젝트 소개
Ingress를 통해 Service 들을 외부에 노출할 때 Ingress Object를 생성하고 Service Object를 참조하게 된다. 쿠버네티스는 Ingress Object를 사용함으로서 L7 Load Balancer(HTTP Reverse Proxy) 를 구성하게되고 이를 통해 외부 클라이언트가 서비스에 접근을 가능하게 한다.
윗 그림의 구성에서는 HTTP에 대한 요청들을 3개의 서비스들로 라우팅한다. Ingress 오브젝트는 요청받는 유형에 따라 어느 서비스로 라우팅 해야 할 것인지에 대한 규칙들을 내포하고 있다.
- kiada.example.com 로 요청받을 경우 트래픽을 kiada Service로 라우팅한다.
- api.example.com/quote 로 요청받을 경우 트래픽을 quote Service로 라우팅한다.
- api.example.com/questions 로 요청받을 경우 quiz Service로 라우팅한다.
한 클러스터 내에서 여러 Ingress를 이용하기
Ingress 오브젝트는 일반적으로 특정 네임스페이스 내 존재하는 모든 서비스들에 대한 규칙을 내포한다. 그러나, 여러 Ingress 오브젝트를 사용하는 것은 선택사항이다. 일반적으로 Ingress 오브젝트들은 고유의 IP 주소를 보유한다. 그러나 어느 Ingress 구성은 모든 Ingress가 사용하는 공유 entrypoint를 이용하기도 한다.
Ingress Controller 소개
Ingress 리소스 자체로는 어떤 프로그램이 동작하는 코드가 아닌 트래픽 처리에 대한 정보를 담고 있는 정의(규칙)에 가까우며 실제로 외부 요청을 받아들여 Service로 전달하는 주체는 Ingress Controller 이다. Ingress Controller는 Ingress Object와 실제 물리적인 Ingress(Reverse Proxy)와 중개하는 역할을 수행한다. Controller와 로드밸런서는 한 컨테이너 내 서로 다른 프로세스에서 실행되기도 하고 한 파드 내에서 2개의 컨테이너로 실행되는 경우도 있다. 그렇기에 사람들은 Ingress Controller를 로드밸런서로 지칭하여 말하기도 한다.
GCP, AWS와 같은 클라우드 환경에서는 로드밸런서가 쿠버네티스 클러스터 외부 환경에 존재하며 광범위한 Ingress Controller를 이용할 수 있도록 제공한다. 가장 대중적으로 이용되는 Ingress Controller들은 Nginx Ingress Controller, Ambassador, Contour 그리고 Traefik이며 이들은 대부분 Nginx, HAProxy 그리고 Envoy를 리버스 프록시 형태로 사용하기도 한다.
https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
Nginx Ingress Controller는 k8s에서 공식적으로 개발되고 있기에 설치를 위한 YAML 파일을 공식 깃허브 저장소에서 직접 내려받을 수 있다.
https://github.com/kubernetes/ingress-nginx
Ingress Controller 역할
앞서 말한 내용을 다시 언급하자면 Ingress 리소스 자체로는 어떤 프로그램이 동작하는 코드가 아닌 트래픽 처리에 대한 정보를 담고 있는 정의(규칙)에 가까우며 실제로 외부 요청을 받아들여 Service로 전달하는 주체는 Ingress Controller 이다.
Ingress는 단지 요청을 처리하는 규칙을 정의하는 Declaritive한 Object일 뿐 외부 요청을 받아들일 수 있는 실제 서버가 아니며 Ingress는 Ingress Controller에 적용함으로써 규칙을 사용할 수 있다.
Ingress Controller는 쿠버네티스 API 서버와 연결되어 Ingress, Service 그리고 Endpoint들의 오브젝트들에 대하여 모니터링을 실시하며, 이들이 새로 생성/수정/삭제 의 작업이 일어나게 되면 Ingress Controller는 이러한 변화를 감지하여 리버스 프록시로 프로비저닝하고 설정하는 역할을 수행한다.
간단한 구성을 통해 L7 로드밸런서(Reverse Proxy)가 서비스로 어떻게 라우팅하는지 이해해보자.
Reverse Proxy(L7 로드밸런서)는 HTTP의 요청을 핸들링하고 서비스로 라우팅하는 주체이다. 이러한 로드밸런서(proxy)는 일반적으로 virtual host 목록, IP 목록, Endpoint 목록들을 포함한다. 쿠버네티스에서는 Ingress, Service, Endpoint/EndpointSlice 오브젝트에 이러한 정보들을 내포한다. 쿠버네티스는 클라이언트가 로드밸런서(proxy)로 연결 요청을 할 때 이들의 정보들을 참조하여 라우팅하게 된다.
윗 그림에서는 Kiada 서비스에 대하여 클라이언트가 어떻게 서비스에 접근하는지에 대한 과정을 나타낸다.
① 클라이언트는 DNS 과정을 통해 kiada.example.com 와 맵핑되는 공인 IP 주소를 얻는다.
② 클라이언트는 kiada.example.com 헤더를 가지고 있는 로드밸런서(proxy)에 HTTP 요청한다.
③ 로드밸런서(proxy)는 쿠버네티스 클러스터 내 해당 요청을 수행하는 Pod들 중(여기서는 Kiada Pod 그룹) 하나로 요청을 라우팅하며, 클라이언트 측으로 리턴 값을 반환한다.
참조
- Kubernetes in Action - 2nd Edition 정리
'Engineering > Kubernetes (K8S)' 카테고리의 다른 글
[Kubernetes] 쿠버네티스 서비스(Service) Deep Dive - (6) Endpoint (0) | 2022.08.07 |
---|---|
[Kubernetes] 쿠버네티스 서비스(Service) Deep Dive - (5) LoadBalancer (0) | 2022.06.17 |
[Kubernetes] 쿠버네티스 서비스(Service) Deep Dive - (4) Nodeport (0) | 2022.06.08 |
[Kubernetes] 쿠버네티스 서비스(Service) Deep Dive - (3) Cluster DNS (0) | 2022.05.18 |
[Kubernetes] 쿠버네티스 서비스(Service) Deep Dive - (2) ClusterIP (0) | 2022.05.17 |
댓글