[10] 쿠버네티스 Ingress

쿠버네티스에서 파드를 외부로 노출시키기 위해서 서비스를 사용하였다. 만약에 쿠버네티스 클러스터 내의 여러 애플리케이션을 외부로 노출시켜야 한다고 가정하자. 그러면 우리는 배운대로 애플리케이션을 디플로이먼트로 띄우고, 서비스를 통해 외부로 노출시킬 것이다. 운영 환경에서는 아래 그림과 같이 서비스를 LoadBalancer 타입으로 노출시킬 것이다.

 

하지만 이런 방식을 사용할 경우 애플리케이션 종류별로 로드밸런서를 구축해야 한다는 단점이 있다. 간단한 서비스의 경우, 비용적인 측면에서 효율적이지 못할 수도 있다.

 

Ingress

다행히도 쿠버네티스에서는 이러한 측면을 보완해주는 쿠버네티스 오브젝트를 제공해주는데 그것이 바로 Ingress이다. Ingress는 간단히 말하면 Host, Path기반으로 애플리케이션을 적절히 라우팅시켜주는 L7 로드밸런서이다. Ingress를 사용하면 여러 서비스를 외부로 노출시키지 않고 Ingress만 외부로 노출시켜서 여러 애플리케이션을 Host 또는 Path 기반으로 라우팅 시킨다. 즉, Ingress 하나만 외부로 노출시키고 별도의 추가 서비스를 노출시키지 않고도 여러 애플리케이션을 외부로 노출시킬 수 있게 된다.

 

 

구성 요소

Ingress의 구성 요소로는 Ingress Controller와 Ingress Resource가 있다. 간단히 말하면 Ingress Resource는 Host나 Path 기반의 라우팅 룰을 정의하는 쿠버네티스 리소스이며, Ingress Controller는 Ingress Resource에서 정의된 라우팅 룰을 사용하여 요청을 적절한 파드로 라우팅시키는 주체이다.

 

일단은 Ingress를 사용하기 위해서는 Ingress Controller를 설치해야 한다. 대표적인 Ingress Controller는 Nginx Ingress Controller이며, 이 컨트롤러를 사용하여 Ingress를 구성해볼 예정이다.

 

 

설치

Nginx Ingress Controller는 설치는 환경마다 다른 방법을 사용하는 것 같다. 일단 클라우드 환경이 아닌 베어메탈 환경에서 쿠버네티스를 구축한 경우 아래 명령어를 실행하면 설치할 수 있다.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.0/deploy/static/provider/baremetal/deploy.yaml

다른 환경이라면 공식 문서를 참고하여 설치해보자.

 

 

Ingress Controller

Nginx Ingress Controller를 설치하면 Deployment, Service, ConfigMap, ServiceAccount 등의 리소스가 생성되는데 Nginx Ingress Controller도 사실은 여느 애플리케이션과 다르지 않다.

 

Deployment를 사용하여 Nginx 파드를 띄우고, Service를 사용하여 Ingress Controller 파드를 외부로 노출시킨다. Nginx에 keep-alive threshold, SSL 설정, 세션 타임아웃 등의 구성옵션이 필요하다면 ConfigMap을 통해 구성할 수 있다. 

 

마지막으로 Nginx Ingress Controller는 기존 Nginx 서버와 크게 다른 기능은 없지만 쿠버네티스 클러스터의 Ingress Resource를 모니터링하고 해당 리소스를 사용하여 Nginx 서버를 구성하는 추가 기능이 내장되어 있다. Ingress Controller가 해당 네임스페이스의 Ingress Resource를 모니터링하려면 권한이 필요하다. 그래서 ServiceAccount와 RBAC를 설정해줘야 한다.

 

위와 같이 설치하였을 경우 ingress-nginx 네임스페이스에 Deployment, Service, ConfigMap, ServiceAccount 등의 리소스가 생성 될 것이다.

 

 

Ingress Resource

Ingress Resource는 Ingress Controller에 적용되는 일련의 룰과 구성이다. Ingress Resource를 사용하여 모든 incoming traffic을 하나의 애플리케이션으로 포워드하거나 URL이나 Domain name을 기반으로 다른 애플리케이션으로 트래픽을 라우팅하는 규칙을 정할 수 있다.

Ingress Resource는 매니페스트 파일을 사용하여 생성할 수 있다.

 

 

Path 기반 라우팅

Path 기반 라우팅은 하나의 Host를 사용하여 Path의 prefix 기반으로 여러 서비스로 라우팅 하는 것을 의미한다.

 

예를 들어, 맥주를 판매하는 서비스가 있다고 하자. 이 서비스의 Host는 https://store.beer1.com 이라고 하자. 맥주를 파는 서비스에서 상품정보에 관한 기능은 Product Service, 결제에 관한 기능은 Payment Service가 담당한다고 하자. 그러면 Path가 /product 로 시작하는 요청은 Product Service, /payment로 시작하는 요청은 Payment Service가 처리한다고 하자. 그림으로 나타내면 아래와 같을 것이다.

 

 

이를 Ingress로 나타내면 아래와 같다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: beer1-path-based
  namespace: beer1
spec:
  rules:
    - host: store.beer1.com
      http:
        paths:
          - path: /product
            backend:
              service:
                name: product
                port: 
                  number: 80
          - path: /payment
            backend:
              service:
                name: payment
                port:
                  number: 80
  

 

Host 기반 라우팅

Host 기반 라우팅은 서로 다른 Host를 기준으로 여러 애플리케이션을 라우팅 하는 것을 의미한다.

 

예를 들어, 맥주 관련 서비스가 있는데 이를 쇼핑몰(store.beer1.com), 서비스 관리자(admin.beer1.com), 쇼핑몰 관리자(shop-manage.beer1.com) 페이지를 서브도메인으로 세분화했다고 하자.  그리고 각각의 서비스는 store, admin, shop-manage 로 분산시켰다고 하자. 그림으로 나타내면 아래와 같다.

 

이를 Ingress로 나타내면 아래와 같다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: beer1-host-based
spec:
  rules:
    - host: store.beer1.com
      http:
        paths:
          - backend:
              service:
                name: store
                port: 
                  number: 80
    - host: admin.beer1.com
      http:
        paths: 
          - backend:
              service:
                name: admin
                port: 
                  number: 80
    - host: shop-manage.beer1.com
      http:
        paths: 
          - backend:
              service:
                name: shop-manage
                port: 
                  number: 80
  

 

Host + Path 기반

물론 두 개 모두 동시에 rule을 정의할 수 있다. Host 기반에서 store.beer1.com은 Path 기반의 예시와 같이 /product, /payment Path 기반으로 각각 Product, Payment 서비스로 라우팅 한다고 가정하자. 그림으로 나타내면 다음과 같다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: beer1-ingress
spec:
  rules:
    - host: store.beer1.com
      http:
        paths:
          - path: /product
            backend:
              service:
                name: product
                port: 
                  number: 80
          - path: /payment
            backend:
              service:
                name: payment
                port:
                  number: 80
    - host: admin.beer1.com
      http:
        paths: 
          - backend:
              service:
                name: admin
                port: 
                  number: 80
    - host: shop-manage.beer1.com
      http:
        paths: 
          - backend:
              service:
                name: shop-manage
                port: 
                  number: 80
  

 

Ingress vs Service

Service나 Ingress 모두 파드를 쿠버네티스 외부로 노출시키는 역할은 같다. (Ingress Controller도 내부적으로 따지자면 Pod + Service 이기 때문) 하지만 Service에 비해 Ingress가 얻는 장점이 많다.

 

1. 하나의 로드밸런서만으로도 서빙 가능

2. Access Log를 하나의 Ingress에서 수집 가능: 클러스터 외부에서 들어오는 모든 트래픽을 Ingress가 최상단에서 받기 때문에 Access log를 수집하기 수월하여 트래픽 분석에 많은 이점을 가질 수 있을 것 같다.

 

마무리

Nginx Ingress Controller 이외에도 여러 Ingress Controller도 있다. 대표적으로는 Istio와 Kong, HAProxy 등이 있다. 필자는 Ingress의 역할을 포함하여 서비스메쉬를 제공하는 오픈소스인 Istio를 사용하는데 기회가 된다면 Istio에 대한 글도 정리해 볼 생각이다.