[Kubernetes] 인바운드 트래픽을 처리하는 방법 : 인그레스(Ingress)

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

이번 포스팅에서는 쿠버네티스 클러스터의 외부에서 내부로 요청(인바운드 트래픽)이 들어왔을 때, 어떻게 처리할지를 결정하는 인그레스(Ingress) 라는 리소스 오브젝트에 대해서 배워보도록 하자.

1. 서비스 vs 인그레스

먼저 인그레스라는 용어의 정의에 대해서 짚고 넘어가보자. 인그레스란, 외부에서 내부로 향하는 것을 일컫는다. 그래서 인그레스 트래픽이라 함은 외부에서 내부로 향하는 트래픽을 말하고, 인그레스 네트워크라고 한다면 외부에서 내부로 향하는 트래픽(인그레스 트래픽)을 처리하기 위한 네트워크를 의미한다.

 

인그레스라는 리소스 오브젝트를 이해하기 위해서 비교군이 될만한 다른 리소스 오브젝트는 서비스이다. 서비스는 예전 포스팅에서 개념을 다루었으니 여기서는 간단한 정의만 하고 짚고 넘어가겠다. 서비스는 쿠버네티스 클러스터에 배포한 파드들을 쿠버네티스 클러스터의 밖 즉, 외부에서 접근할 수 있도록 파드들을 외부로 노출하는 데 사용되는 오브젝트이다. 

 

그렇다면 이러한 서비스라는 오브젝트의 개념을 빗대어 볼 때, 인그레스 오브젝트란 클러스터 외부에서 내부로 전달한 요청을 어떻게 또는 어떠한 방식으로 파드로 전달할지에 대한 처리를 수행하는 오브젝트이다. 쉽게 그림으로 간단하게 도식화해보면 다음과 같다.

 

인그레스와 서비스의 차이

 

위 그림처럼 서비스는 파드를 외부로 노출시키는 역할을 하고, 외부로 노출시킴에 따라 외부에서 내부로 들어오는 요청을 어떻게 처리해서 파드로 전달할지는 인그레스가 담당하게 된다. 참고로 위 그림 상에서는 내부로 들어오는 요청이 마치 [서비스 → 인그레스] 순서로 통과한다고 오해할 수 있는데, 그것은 아니다. 단순히 서비스는 외부로 노출시키는 역할이고, 인그레스는 외부로부터 온 요청을 처리하는 역할임을 구분하기 위해 이해를 위해 위처럼 표시했다.

 

여기서 인그레스가 하는 역할로서, 외부에서 내부로 들어오는 요청을 처리하는 방법에는 다양하지만 대표적으로 나열해보자면 다음과 같다.

 

• 외부 요청의 라우팅 : 예를 들어, /predict, /zedd 처럼 특정 경로로 들어온 요청을 어떠한 서비스로 전달할지 정의하는 라우팅 규칙을 정의
• 가상 호스트 기반의 요청 처리 : 같은 IP 주소에 대해서 서로 다른 도메인 이름으로 요청이 도착했을 때, 어떻게 처리할 것인지 정의
• SSL/TLS 보안 연결 처리 : 여러 개의 서비스로 요청을 라우팅할 때, 보안 연결을 위한 인증서를 쉽게 적용

물론 위에서 명시한 3가지 기능이 인그레스 기능의 전부는 아니다. 또한 위 기능은 인그레스가 하는 자체적인 기능이고, 해당 기능을 또 서로 다르게 사용하기도 하는데 이는 인그레스의 요청을 처리하는 서버를 어떤 것으로 선택하느냐에 따라 또 달라지기도 한다. 여기서 "인그레스의 요청을 처리하는 서버"를 이해하기 위해서는 인그레스 컨트롤러와 로드 밸런서에 대해 알아야 하는데 이에 대해서는 밑에서 알아볼 예정이니 일단은 넘어가자.

2. 인그레스는 왜 필요한가?

1번 목차의 내용 말미에서 소개한 인그레스의 대표적인 3가지 기능만 보았을 때는 굳이 인그레스를 사용하지 않고 서비스 오브젝트로만 사용해서도 해당 기능들을 구현할 수 있지 않은가? 에 대해서도 의문을 품을 수 있다. 물론 불가능한 것은 아니다. 즉, 서비스 오브젝트 그 중에서도 NodePort 나 LoadBalancer 유형의 서비스 오브젝트를 정의함으로써 인그레스 트래픽을 부하 분산(로드 밸런서)하거나 하는 등 트래픽 처리가 가능하긴 하다. 하지만 인그레스를 함께 사용하게 되면 서비스만 이용하는 것보다는 더 큰 장점을 누릴 수 있다. 이 장점을 체감하기 위해서 서비스만을 사용할 때와 서비스와 인그레스를 함께 사용할 때의 차이점을 비교해보도록 하자. 먼저 아래 그림을 보자.

 

인그레스를 사용하지 않고 서비스로만 운영할 경우

 

A, B, C 라는 서로 다른 기능을 하는 애플리케이션이 있다고 가정해보자. 실질적인 웹서버 역할을 하는 파드는 Deployment로 배포했고, Deployment도 각 서비스에 따라 A, B, C로 각각 배포했다고 해보자. 그리고 이 Deployment들을 외부(Client)에서 접근하는 것을 가능하게 하기 위해 각 Deployment에 대해서 서비스도 함께 배포했다고 해보자. 

 

그런데 서로 다른 기능을 하는 A, B, C 애플리케이션 간에 라우팅 규칙이나 SSL/TLS 설정값 등이 모두 동일할 수도 있지만 보통은 다를 확률이 높다. 그렇게 되면 k8s를 사용하는 개발자 입장에서는 각 설정값을 서비스 또는 Deployment의 매니페스트 파일마다 별도로 설정을 해주어야 할 수 밖에 없다.

 

서비스로만 운영한다면 서로 다른 애플리케이션의 매니페스트 마다 설정값을 반영해주어야 함

 

그러면 결국 개발자 입장에서는 애플리케이션 3개만 하더라도 관리해야 할 매니페스트 파일이 3개나 된다. 즉, 계속적으로 추가되는 애플리케이션 개수에 비례해서 관리해야 할 매니페스트 파일 개수가 증가하는 것이다.

 

하지만 인그레스 오브젝트를 사용하면 URL 엔드포인트를 단 하나만 생성함으로써 이렇게 관리포인트가 늘어나는 번거로움을 쉽게 해결할 수 있게 된다. 인그레스가 추가된 구조는 다음과 같다.

 

인그레스가 추가된 구조

 

위와 같이 인그레스가 서비스 앞단에 추가가 되면 외부(클라이언트) 입장에서는 3개의 서비스에 대해서 각각 URL 엔드포인트가 존재하는 것이 아니라 단순히 인그레스에 접근하기 위한 하나의 URL 엔드포인트만 존재하게 되는 것이다. 따라서 외부에 있는 클라이언트는 1개의 인그레스 URL로 접근 하게 되면 인그레스에 정의된 규칙에 따라 요청을 구체적으로 어떤 Deployment에 전달될지 결정되는 것이다.

 

이렇게 되면 인그레스가 추가됨으로써 아까 서비스만 있던 구조에서 발견되었던 한계점인 "관리해야 할 매니페스트 개수가 늘어난다" 라는 문제가 해결된다. 즉, 인그레스라는 매니페스트 1개만으로 각 서비스 또는 디플로이먼트에 적용될 설정값을 마치 중앙에서 관리하게 되는 셈이다. 이것이 바로 인그레스의 핵심적인 기능이다.

 

서비스에 인그레스를 같이 사용해야 하는 또 다른 이유는 라우팅 규칙 명시이다. 이에 대해서 잠시 살펴보자. 먼저 인그레스와 서비스 간의 차이점을 네트워크 OSI 7 계층 관점에서 살펴볼 필요가 있다. 먼저 인그레스는 OSI Layer 중 L7 계층인 Application 계층이며 해당 계층의 구현체는 HTTP로 식별자가 IP 주소, PORT 번호, URL PATH 까지이다. 반면에 서비스는 L4 계층인 Transport 계층이며 해당 계층의 구현체는 TCP/UDP로 식별자가 IP 주소와 PORT 번호이다. 

 

중요한 차이점은 식별자가 URL PATH 까지 여부이냐인데, 인그레스는 그렇기 때문에 밑에서 알아보겠지만 라우팅 규칙까지 정의할 수 있게 되는 것이다. 반면에, 서비스는 URL PATH가 식별자에 포함되지 않기 때문에 라우팅 규칙까지는 정의할 수가 없다. 

3. 인그레스의 구조

직전 목차까지는 인그레스가 어떤 개념이고, 인그레스가 왜 필요한지에 대해서 살펴보았다. 이번 목차에서는 좀 더 세부적으로 k8s 클러스터에 인그레스를 적용하게 되면 어떤 구조로 동작하는지에 대해서 살펴보도록 하자.

 

지금까지 이야기했던 '인그레스'는 엄밀히 말하면 규칙을 정의한 내용이 들어있는 파일 형태에 불과하다. 이게 무슨 소리인가? 직전 목차에서 인그레스를 도식화한 것을 보면 인그레스 자체가 일종의 서버 역할을 하면서 로드 밸런서 역할도 하는 것처럼 보였다. 하지만 인그레스의 실체(?)는 단순한 YAML 파일이다. 그리고 그 파일의 내용에는 직전에서 인그레스의 기능이라고 소개했던 라우팅 규칙, SSL/TLS 설정값 등과 같은 것들을 명시하는 내용이 들어있다. 공식 문서에서 소개되는 인그레스 예제 파일은 아래와 같다.

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

 

위 파일의 내용에서 항목들이 구체적으로 어떤 것을 의미하는지 알아보기 전에 인그레스의 구조를 좀 더 깊숙히 파헤쳐보도록 하자.

 

인그레스 말고도 알아야 할 개념이 인그레스 컨트롤러와 로드 밸런서이다. 인그레스 컨트롤러는 인그레스라는 것에 명시된 규칙을 실행시키도록 하는 주체이다. 이름에 '컨트롤러' 라는 단어가 들어가 있는 것에서 눈치챌 수 있듯이 무엇인가를 제어한다는 의미인데, 바로 인그레스에 명시된 규칙을 제어한다는 것이다. 그렇다면 로드 밸런서는 무엇일까? 직전 목차에서 인그레스가 로드 밸런서 기능을 한다고 했지만 엄밀히 말하면 로드 밸런서 역할을 하는 서버가 별도로 있는데, 이 서버가 인그레스 컨트롤러가 명령한 규칙을 실행시키는 실질적인 주체가 된다. 이 로드 밸런서라는 서버는 인그레스 컨트롤러의 종류가 무엇인지에 따라 달라지는데, 만약 NGINX 인그레스 컨트롤러라면 로드 밸런서 서버는 NGINX 웹서버가 된다. 이외에 대표적인 인그레스 컨트롤러 종류로는 NGINX, Istio, Kong, GCE 등이 있다. 참고로 GCE는 구글 클라우드 환경에서 매니지드 k8s를 제공하는 GKE 환경에서 사용하는 인그레스 컨트롤러이다.

 

결국 위 내용을 정리해서 인그레스, 인그레스 컨트롤러, 로드 밸런서 간의 관계를 요약하면 다음과 같다.

 

1. NGINX 인그레스 컨트롤러는 인그레스에 명시된 규칙을 본다
2. 그 규칙을 본 NGINX 인그레스 컨트롤러는 로드 밸런서(실질적인 서버이며 이 경우 NGINX 서버로 구성됨)에게 명령을 내린다
3. 그 명령(인그레스에 명시된 규칙) 대로 로드 밸런서 서버가 동작한다

그래서 이 관계를 반영해서 k8s 클러스터의 그림을 다시 도식화해보면 아래와 같다. 

 

인그레스 구조

 

인그레스 컨트롤러는 주로 마스터 노드에 존재하며 인그레스 컨트롤러 자체도 사실상은 컨피그맵이다. 그리고 인그레스와 로드 밸런서는 주로 워커 노드에 존재한다. 

 

그리고 인그레스 컨트롤러와 로드 밸런서 간의 관계에 대해서도 살펴볼 필요가 있다. 인그레스 컨트롤러를 반드시 1개만 사용해야 할까? 아니다 여러 개를 사용할 수도 있다. 만약 5개의 서로 다른 기능을 하는 서비스가 존재하고, 인그레스 컨트롤러를 3개의 서비스는 NGINX 인그레스 컨트롤러를, 나머지 2개의 서비스는 Kong 인그레스 컨트롤러를 사용한다고 해보자. 이럴 경우, 인그레스 컨트롤러와 로드 밸런서는 각각 몇 개를 사용하는 걸까? 인그레스 컨트롤러는 2개, 로드 밸런서는 5개이다. 로드 밸런서 개수가 2개가 아니라 5개인 이유는 로드 밸런서 1개 당 하나의 서비스에 붙어있는 여러 개의 디플로이먼트들에 부하 분산을 하기 때문에 서비스 개수 별로 존재해야만 한다.

 

정리하자면, 인그레스를 적용하는 순서는 다음과 같다.

 

1. 인그레스 컨트롤러를 하나 선정해 생성한다
2. 인그레스 컨트롤러를 외부로 노출하는 서비스를 생성한다
3. 규칙을 정의하는 인그레스를 생성한다
4. 인그레스를 생성하는 순간, 인그레스 컨트롤러는 이를 인지하고, 인그레스를 로드해 로드 밸런서로 전달한다
5. 로드 밸런서는 인바운드 트래픽을 처리한다

참고로 인그레스를 생성하는 순간에 인그레스 컨트롤러가 알아차릴 수 있는 이유는 Watch API를 사용하기 때문이다. 이 Watch API는 인그레스 말고도 쿠버네티스 API에서 특정 오브젝트의 상태가 변화하는 것을 포착할 수 있는데, 예를 들어 리소스 오브젝트가 생성, 삭제, 수정 등의 이벤트가 발생하면 이를 알려주는 기능을 한다. kubectl CLI 에서도 사용할 수 있는데, 대표적인 예시로 파드를 Watch API로 살펴보려면 아래와 같이 사용해볼 수 있다.

 

kubectl get pods -w

4. 인그레스 규칙 이해하기 : 기초

그러면 이제 인그레스 예제 파일을 보면서 규칙을 이해해보도록 하자. 아래와 같은 예제 인그레스가 있다고 해보자.

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: zedd-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: zedd.example.com
    http:
      paths:
      - path: /echo-hello
        pathType: Prefix
        backend:
          service:
            name: hello-service
            port:
              number: 80

 

• spec.host : 해당 도메인 이름으로 접근하는 요청에 대해서 처리 규칙을 적용한다. 이 host 도 여러 개 정의해 사용할 수 있음
• spec.http.paths.path : 해당 경로에 들어온 요청을 어느 서비스로 전달할 것인지 정의한다. 여러 개의 path를 정의할 수 있음
• spec.http.paths.backend.service.port : 해당 path로 들어온 요청이 전달될 서비스와 포트 번호를 정의한다. 위 예시에서는 hello-service 라는 서비스 명을 갖는 파드의 80 포트번호로 요청을 전달한다

그런데 방금 spec.http.paths.backend.service.port 항목을 설명하면서 정의된 서비스 즉, hello-service 라는 이름으로 요청이 전달한다고 했다. 정확히 말하면 인그레스는 해당 서비스로 요청을 전달하는 것이 아닌 해당 서비스에 붙어있는 디플로이먼트 즉, 실질적인 처리를 담당하는 엔드포인트로 직접 전달되게 된다. 이러한 동작을 쿠버네티스에서는 바이패스(bypass)라고 부른다. 참고해보도록 하자.

5. 인그레스 규칙 이해하기 : annotations(주석)

이번에는 인그레스 규칙 중 좀 더 심화된 내용인 annotations 항목을 알아보도록 하자. 아까 위에서 살펴본 인그레스 예제와 비슷하되 한 줄만 추가되었다. annotations 항목만 보자.

 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: zedd-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: zedd.example.com
    http:
      paths:
      - path: /echo-hello
        pathType: Prefix
        backend:
          service:
            name: hello-service
            port:
              number: 80

 

• kubernetes.io/ingress.class : 인그레스 규칙을 어떤 인그레스 컨트롤러에 적용할 것인지 명시하는 것이다. 환경에 따라 쿠버네티스 클러스터가 해당 주석이 없으면 기본적으로 사용하는 인그레스 컨트롤러가 다르다. 예를 들어, GKE 환경에서의 쿠버네티스 클러스터를 구성했고 NGINX 인그레스 컨트롤러를 사용하려고 한다면 반드시 해당 주석에 "nginx" 라고 적어주어야 한다. 그렇지 않으면 기본적으로 GKE 환경이기 때문에 GCE 인그레스 컨트롤러를 사용하게 된다.

다음은 NGINX 인그레스 컨트롤러에 한정된 것이지만, nginx.ingress.kubernetes.io/rewrite-target 이라는 주석에 대해 배워보자. 해당 주석은 인그레스에 정의된 경로로 들어오는 요청을 rewrite-target에 정의한 경로(이 예시에서는 루트(/) 경로)로 전달하라는 의미이다. 위 예시로 들자면, 해당 인그레스의 /echo-hello 로 시작하는 모든 경로로 들어온 요청은 hello-service 이름인 서비스명의 루트(/) 경로로 모두 전달하라는 뜻이다. 예를 들어서, /echo-hello 경로던 /echo-hello/zedd 던 /echo-hello/zedd/123 이던 모두 hello-service 라는 서비스의 루트(/) 경로로 전달한다. 

 

이러한 rewrite-target은 NGINX의 캡쳐 그룹과 함께 사용하면 요청 경로를 변수로 사용해 동적으로 사용할 수 있게 된다. 자세한 예시는 책에도 있긴 하지만, 문서에도 존재하니 살펴보도록 하자. 정규표현식과 매우 유사하다.