개요

이번에는 이스티오의 기본 리소스 중 하나인 Gateway에 대해서 조금 더 알아보는 시간을 가진다.
클러스터 내부, 외부를 잇는 진입점으로서 게이트웨이의 개념을 먼저 이해하는 것으로 시작한다.

사전 지식

이스티오 게이트웨이는 이스티오의 주요 리소스 중 하나로, 서비스 메시에 내외부들 드나드는 트래픽의 진입문을 설정 관리한다.
리소스로서의 게이트웨이를 알기 전에, north-south 트래픽을 처리하기 위해 실제로 배포하는 워크로드인 인그레스 게이트웨이, 이그레스 게이트웨이부터 봐야 한다.
리소스로서의 게이트웨이는 해당 워크로드를 관리하는 CRD에 불과하기 때문이다.

네트워크 토폴로지에서의 게이트웨이

게이트웨이는 말 그대로 어떤 네트워크의 진입 지점을 이야기한다.
가장 쉽게 이해할 수 있는 표현으로는 API 게이트웨이가 있겠다.
이스티오의 서비스 메시 환경에서 외부의 트래픽을 받거나 외부로 트래픽을 보내는 경로가 되는 지점을 게이트웨이라고 표현한다.
이스티오의 게이트웨이는 클러스터와 외부의 트래픽을 잇는 진입점으로서 기능한다.
외부 트래픽은 게이트웨이를 통해 들어오고, 이 게이트웨이에서는 트래픽의 정보를 확인한다.
그리고 클러스터 내부에 적절한 서비스로 트래픽을 전달해준다.
서비스의 응답 역시 이 게이트웨이를 통해서 나가게 된다.

이 게이트웨이에 대한 트래픽을 조금 세분화시키는 용어가 있는데, 이것이 바로 인그레스(ingress), 이그레스(egress)이다.
잘 정의된 게이트웨이로 들어오는 트래픽을 인그레스가 부르며, 보통 이 트래픽에 대한 응답이 돌아가는 과정까지 총칭한다.
(나가는 트래픽까지 포함하여 부를 때 인바운드라고 표현하기도 한다.)
반대로 이그레스는 게이트웨이를 통해 클러스터 외부로 나가는 트래픽을 말한다.

인그레스란 표현은 쿠버네티스 네트워크를 공부할 때 인그레스 리소스로서 익숙할 것이다.
쿠버 리소스로서 인그레스 역시, HTTP관련 클러스터로 들어온 트래픽을 처리하는 진입점에 대한 설정을 하기에 그런 이름으로 명명된 것이다.

가상 IP, 가상 호스트

그렇다면 게이트웨이로 요청을 보내려면 어떻게 해야하고, 게이트웨이는 어떻게 트래픽을 적절한 서비스로 전달하는가?
여기에서 쓰이는 개념이 가상 IP, 가상 호스트이다.

사실 별 건 아니고, 게이트웨이가 가지는 IP를 가상 IP라고 부르고, 게이트웨이가 처리하는 호스트 이름을 가상 호스트라고 부른다.
왜 가상이라 부르는가?

이건 클러스터 외부의 클라이언트 입장에서 IP와 호스트를 봤을 때 가상이라 그런 것이다.
클라이언트가 통신하고자 하는 대상은 사실 게이트웨이 뒷단의 서비스인데, 요청을 보내기 위해서는 게이트웨이를 거쳐야 한다.
그래서 클라이언트는 게이트웨이의 주소로 요청을 보내게 되는데, 이것은 실제 서비스의 주소는 아니기에 가상 IP라고 부른다.
호스트 역시 마찬가지다.
게이트웨이는 들어온 요청의 호스트 헤더에 따라 트래픽을 어떻게 처리할지 결정한다.
물론 클러스터 내에서 뒷단의 서비스를 매칭하기 위해 각각이 호스트를 가지고 있을 것이고, 이 호스트가 클라가 요청한 호스트와도 일치하긴 할 것이다.
그러나 클라가 결국 호스트랍시고 요청한 대상은 게이트웨이이며, 게이트웨이가 해당 호스트인 마냥 처리한다.

결국 외부 클라의 요청의 정보들은 실제 서비스를 나타내고 있지 않음에도 게이트웨이가 요청을 받고, 처리하기 위해 쓰인다.
이러한 면에서 기본적인 IP와 호스트의 의미가 변질되어 일종의 추상화가 이뤄진다고 볼 수 있다.
그래서 게이트웨이가 처리하는 IP와 호스트를 아울러 가상 IP, 가상 호스트라고 표현하는 것이다.

그냥 개념적인 차원의 내용이긴 한데, 가상 호스트는 보통 뒷단에 어떤 서비스로 트래픽을 보낼지 정하는데 쓰인다.
그래서 이스티오를 설정할 때도 많이 등장하는 개념이라 알아두면 좋다.

인그레스 게이트웨이, 이그레스 게이트웨이

그럼 실제 게이트웨이는 쿠버네티스 클러스터에서 어떤 식으로 구현되는가?
간단하게, NodePort를 가진 서비스로 클러스터 외부에서 트래픽이 접근 가능하게 하고, 이 서비스의 백엔드로 프록시 서버를 두면 된다!
이스티오에서는 설정에 따라 이런 워크로드를 자동으로 배포해주는데, 이 워크로드를 인그레스, 이그레스 게이트웨이라고 부른다.
해당 게이트웨이 역할을 하는 워크로드 역시 하나의 프록시로, 엔보이가 배포된다.

리소스로서의 게이트웨이

이스티오 클러스터에서 게이트웨이의 실제 구현체는 엔보이 프록시를 담은 하나의 워크로드라는 것이 이제야 명확해진다.
그럼 이 게이트웨이에 여러 설정을 집어 넣으려면 어떻게 해야 하는가?
게이트웨이 구현체에 설정을 가하기 위해 이스티오에서는 Gateway라는 리소스를 정의해뒀다.
이를 통해 서비스 메시 클러스터에서 통합적으로 게이트웨이에 대한 관리를 할 수 있게 되는 것이다!
Gateway에 대한 리소스를 만들면 이스티오 컨트롤 플레인은 이를 해석하여 실제 게이트웨이 구현체에 설정을 반영한다.

여기에서 참고해야 하는 것이, Gateway 리소스를 만드는 것 자체는 실제 게이트웨이 구현체를 만드는 것과 별개이다.
이스티오의 Gateway 리소스는 이미 존재하는 게이트웨이 워크로드에 대해 설정을 하는 리소스이며, 워크로드 자체는 직접 배포해야만 한다.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  profile: default
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true

직접 배포해야 한다고 해서 어렵지는 않은 게, 이스티오 설치 및 관리를 하는 양식 파일에 이런 식으로 컴포넌트를 작성해두면 이스티오 컨트롤 플레인에서 알아서 해당 워크로드를 배포해준다.

이 방식은 게이트웨이API의 Gateway 리소스와 큰 차이점을 지닌다.
게웨api에서는 Gateway 리소스를 만들 시 해당 워크로드까지 같이 배포가 진행된다.
반면 이스티오의 Gateway 리소스는 먼저 외부 진입점으로서의 게이트웨이 워크로드가 있는 상태에서 게이트웨이 리소스를 만들어서 이를 추적 관리한다.

실습 진행

사실 이전 실습에서 이스티오를 알아가는 단계 수준으로 게이트웨이는 이미 만진 적이 있다.
이번에는 게이트웨이에 대해 설정을 넣는 방법과 간단한 최적화 기법을 알아본다.

실습 환경 세팅은 이전과 완벽하게 동일하기에 추가적으로 정리하지 않는다.
1W - 서비스 메시와 이스티오 참고.

kubectl stern -n istio-system -l app=istiod

이번 실습 간 간간히 컨트롤 플레인의 로그를 확인할 것이기에 별도의 터미널 창에서 로그를 지속적으로 추적하는 것을 추천한다.

기본 게이트웨이 세팅 후 분석

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 8080
        name: http
        protocol: HTTP
      hosts:
        - "*"

이전에 했던 방식과 다르지 않게 그냥 게이트웨이를 만들어본다.

컨트롤 플레인 로그를 보면 게이트웨이 리소스가 생김에 따라 인그레스 게이트웨이 쪽에 설정 api를 날리는 것이 확인된다.

istioctl pc route -n istio-system istio-ingressgateway-6567675ffd-h5447

라우팅 정보를 보면 서버로 설정한 포트의 name과 number을 이용해 라우팅 필터 이름이 정해졌고, 뒷단에 추가 리소스 설정이 없어 404로 연결된다는 것을 확인할 수 있다.
이번에도 기본 예제는 공식 문서에 있는 bookinfo를 활용한다.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - "*"
  gateways:
    - bookinfo-gateway
  http:
    - match:
        - uri:
            exact: /productpage
        - uri:
            prefix: /static
        - uri:
            exact: /login
        - uri:
            exact: /logout
        - uri:
            prefix: /api/v1/products
      route:
        - destination:
            host: productpage
            port:
              number: 9080

virtual service를 만들자 다시 한번 인그레스 게이트웨이 쪽에 일련의 설정이 들어간다.

라우팅 정보를 보면 이제 virtual service를 향하도록 제대로 반영된 것이 확인된다.


여기에서 재밌는 사실을 하나 알 수 있는데, 엔드포인트로 보이는 정보를 보면, 대상으로 서비스 리소스를 추적하는 것으로 보인다.
그러나 실질적인 ip를 보면 해당 엔드포인트는 파드의 ip란 것을 알 수 있다.
VirtualService에서 지정하는 대상은 기본적으로 서비스이며, 이 서비스의 엔드포인트를 기반으로 실제 대상이 될 파드를 추적한 뒤에 해당 파드의 프록시에 접근해 정보를 업데이트한다고 추론해볼 수 있다.
(이건 아직 확실하진 않고 내 추측이다.)

통신을 해보면 제대로 트래픽이 전달되는 것이 확인된다.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - "bookinfo.com"
  gateways:
    - bookinfo-gateway
  http:
    - match:
        - uri:
            exact: /productpage
        - uri:
            prefix: /static
        - uri:
            exact: /login
        - uri:
            exact: /logout
        - uri:
            prefix: /api/v1/products
      route:
        - destination:
            host: productpage
            port:
              number: 9080

virtualservice에서 호스트 이름을 바꿔본다.

이제는 bookinfo.com을 호스트로 설정하고 들어오는 요청만 제대로 수행되는 것을 확인할 수 있다.

tls 통신

tls에 대해서는 게이트웨이에서 어떤 식으로 tls를 다룰 수 있는지만 간략하게 보고자 한다.
패스스루 모드에 대해서도 실습하기 위해 tls를 처리하는 간단한 어플리케이션이 필요했다.
이건 책의 예제로 빠르게 테스트할 수 있겠다 싶어 책의 예제를 사용했다.

책에는 미리 실습에 활용할 수 있는 다양한 인증서를 준비해뒀기에 유용하게 사용할 수 있겠다 싶었다.

SIMPLE 모드

tls 심플 모드는 게이트웨이에서 tls 통신을 터미네이션한다.
참고로 그렇다고 해서 트래픽이 평문으로 클러스터로 전달되는 것은 아닌 게, 기본 이스티오 설정에서는 서비스 간 mtls 통신을 한다..

kubectl create -n istio-system secret \
generic webapp-credential-mtls --from-file=tls.key=\
../book-source-code-master/ch4/certs/3_application/private/webapp.istioinaction.io.key.pem \
--from-file=tls.crt=\
../book-source-code-master/ch4/certs/3_application/certs/webapp.istioinaction.io.cert.pem \
--from-file=ca.crt=\
../book-source-code-master/ch4/certs/2_intermediate/certs/ca-chain.cert.pem

먼저 이스티오의 네임스페이스에 사용할 시크릿을 등록한다.
구체적으로는 인그레스 게이트웨이가 위치한 네임스페이스에 배치하는 것이다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 8080
        name: http
        protocol: HTTP
      hosts:
        - "webapp.istioinaction.io"
    - port:
        number: 8443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE 
        credentialName: webapp-credential-mtls 
      hosts:
        - "webapp.istioinaction.io"

주어진 인증서는 webapp.istioinaction.io 도메인에 대한 것이므로 호스트도 적절하게 변경해줘야 한다.
virtualSerivce도 똑같이 바꿔줘야 한다!

컨트롤 플레인 로그를 보면 tls 시크릿 값을 넣어줌으로 인해 SDS api가 발동된 것이 확인된다.

또한 인그레스 게이트웨이에 설정이 들어가서 시크릿 정보가 프록시 설정에도 출력된다.

이제 트래픽을 날려보자.

단순하게만 curl을 날리면 아무런 소용이 없다.
에러 때문에 조금 헷갈렸는데, 현재 문제를 구체적으로 확인하려면 이스티오를 이용하면 된다.

리스너 설정을 보면 MATCH의 기준이 SNI가 된 것을 볼 수 있다.
이것은 TLS 통신에 있어 첫번째 과정인 ClientHello 값의 SNI 필드를 기준으로 매칭을 하겠다는 것이다.
그러나 위에서 Host 헤더를 설정하는 방식은 HTTP 헤더를 세팅하는 것이므로 TLS 통신 이후에나 전달된다.

DOMAIN="webapp.istioinaction.io"
curl https://$DOMAIN:30005/productpage \
	-H "Host: $DOMAIN" \
	--resolve $DOMAIN:30005:127.0.0.1 -k 

해결 방법은 간단한데, 그냥 curl 요청을 날릴 때 적절한 호스트 이름을 넣어주고 --resolve 옵션으로 해당 도메인에 대해 직접 리졸브를 해주면 된다.
이렇게 하면 curl이 날아갈 때 해당 주소에 대해 별도의 DNS 질의를 하지 않고 바로 해당 IP 주소로 요청을 날리게 된다.

요청이 성공적으로 수행됐다.

이 실습을 통해 알 수 있는 것은 TLS 통신 시 이스티오에서 호스트 이름을 어떻게 해석하는지에 대한 것이다.
엔보이의 세팅을 공부하면서 리스너 필터 체인과 네트워크 필터 체인 사이 TLS Socket 관련 층이 여기에서도 작용한 것이다.

PASSTHROUGH 모드

패스스루 모드는 게이트웨이에서 별도의 tls 데이터를 복호화하지 않고 그대로 클러스터로 들여오는 방식이다.

cat ../book-source-code-master/ch4/sni/simple-tls-service-1.yaml | sed s/istioinaction/default/ | kaf -

위에서 말한 바와 같이 이건 그냥 빠르게 진행하기 위해 책의 예제를 사용했다.
처음에 default 네임스페이스 쓴 김에 계속 사용 중인데, 위 파일이 오묘하게 한 리소스만 다른 네임스페이스에 설정이 돼있어 부득이하게 해당 값을 바꾸어 적용했다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 8080
        name: http
        protocol: HTTP
      hosts:
        - "webapp.istioinaction.io"
    - port:
        number: 8443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: webapp-credential-mtls
      hosts:
        - "webapp.istioinaction.io"
    - port:
        number: 8443
        name: tcp-sni
        protocol: TLS
      hosts:
        - "simple-sni-1.istioinaction.io"
      tls:
        mode: PASSTHROUGH

게이트웨이에는 패스스루를 진행할 호스트도 같이 설정에 넣어준다.
같은 포트를 쓰기 때문에 문제가 생기지 않을까 싶기도 하지만, 호스트 이름이 다르기에 이스티오(구체적으로는 엔보이)에서는 이를 구분지을 수 있다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: vs-psthr
spec:
  hosts:
    - "simple-sni-1.istioinaction.io"
  gateways:
    - bookinfo-gateway
  tls:
    - match: 
        - port: 8443
          sniHosts:
            - simple-sni-1.istioinaction.io
      route:
        - destination:
            host: simple-tls-service-1
            port:
              number: 80

다음으로 해당 호스트로 들어온 요청이 어디로 라우팅돼야 하는지 지정해주면 끝이다.
설정이 상당히 다른 것을 볼 수 있는데, 여태까지는 TLS 터미네이션이 일어나고 나서 HTTP 트래픽만 클러스터 내부로 들어오게 돼있었다.
그러나 패스스루를 하게 되면 TLS 암호문이 그대로 클러스터로 들어오게 되고, 이를 기반으로 설정을 해줘야만 한다.
이번에는 설정 상에서도 완전히 sniHosts라고 명시하는 것이 보인다.

DOMAIN="simple-sni-1.istioinaction.io"
curl https://$DOMAIN:30005/productpage \
	-H "Host: $DOMAIN" \
	--resolve $DOMAIN:30005:127.0.0.1 -k 

세팅만 제대로 해줬다면, 결국 방법은 다르지 않다.
(출력물이 이쁜 걸 보니 새삼 왜 bookinfo로 실습했나 싶네)

게이트웨이쪽 리스너 설정을 보면 이번에는 목적지가 조금 다르다.
엔보이에서 Route는 HTTP 관련 설정을 거친 후에야 적용되기에 패스스루로 제대로 HTTP 데이터라는 것을 확인할 수도 없는 게이트웨이 입장에서 해당 트래픽은 그저 클러스터로 인식되는 업스트림으로 표시할 수밖에 없다.
(SNI 필드를 확인하니 최소한 TLS 프로토콜을 사용하고 있다는 것은 알 수 있을 것이다.)

번외 - 게이트웨이 워크로드 주입

추가적으로 게이트웨이 워크로드를 직접 만들어보자.

  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
    - name: my-user-gateway
      namespace: istioinaction
      enabled: true
      label:
        istio: my-user-gateway

게이트웨이 워크로드는 이스티오 관리 양식 파일에서 쉽게 세팅해서 적용할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-user-gateway-injected
spec:
  selector:
    matchLabels:
      ingress: my-user-gateway-injected
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        inject.istio.io/templates: gateway
      labels:
        ingress: my-user-gateway-injected
    spec:
      containers:
        - name: istio-proxy
          image: auto

그런데 이런 식으로 어노테이션만 달아주면, 직접 해당 워크로드를 만드는 것도 가능하다.
주의점이 몇 가지 있다.
일단 어노테이션으로 inject.istio.io/templates: gateway라는 식으로 주입될 프록시가 게이트웨이 임을 명시해야한다.
컨테이너 이름과 이미지는 위와 같이 고정해야 한다.
이미지를 아무거나 세팅해도 되는 줄 알고 바꿔봤는데 제대로 동작하지 않았다.
Mutating Admission Webhook에서 이미지 이름까지 체크하며 프록시를 주입하는 것으로 보인다.

해당 워크로드를 사용하는 게이트웨이 리소스를 만들고 난 후 상태를 보면 위에서 봤던 게이트웨이 워크로드와 똑같이 동작하는 것을 확인할 수 있다.

게이트웨이 최적화

마지막으로 해볼 것은 게이트웨이 워크로드 최적화이다.

위에서도 봤지만, 각 프록시에서 추적하는 클러스터가 뭐가 있는지 확인해보면 이렇게 서비스 레지스트리에 등록된 모든 서비스들이 보인다.
지금 간단하게 실습하는데도 이렇게 많은 서비스들이 보이는데, 실제 운용환경에서도 이렇게 모든 서비스가 추적된다면 프록시는 상당한 메모리 리소스를 소모하게 되며 비효율적으로 자원을 날려먹게 된다.
일반 프록시들의 경우 Sidecar라는 리소스를 이용해 서비스 레지스트리에 등록된 모든 클러스터를 가져오지 않고 필요한 서비스만 테이블에 업데이트되도록 세팅할 수 있다고 한다.
(이후 주차에서 보게 될 것 같아서 더 파보진 않았다.)

그러나 게이트웨이 리소스의 경우 Sidecar 리소스를 이용해 관리할 수 없다.

  components:
    pilot:
      k8s:
        env:
          - name: PILOT_FILTER_GATEWAY_CLUSTER_CONFIG
            value: "true"

그렇기 때문에 사용할 수 있는 방법이 바로 이스티오 컨트롤 플레인 설정이다.
이스티오 관리 양식에서 파일럿에 게이트웨이의 클러스터 설정을 적절하게 필터링하도록 환경변수를 세팅하면 게이트웨이에서 추적할 필요 없는 클러스터에 대해 게이트웨이가 추적하는 것을 막을 수 있다.

위 설정을 넣고 업데이트하자 곧바로 게이트웨이의 클러스터가 상당히 줄어든 것을 확인할 수 있다.
위 게이트웨이가 트래픽을 보내야 할 서비스만 명확하게 추적되고 있다!
환경 변수 설정 정보는 여기에서 찾아볼 수 있다.^[1]

참고로 이 pilot agent는 이전에 데이터플레인에 주입된 사이드카 컨테이너의 기본 프로세스이기도 하다.

결론

게이트웨이는 클러스터의 진입점을 지정하는 리소스로 생각보다 세팅 자체는 그다지 어렵지 않다.
이스티오 커뮤니티에서도 게이트웨이는 장차 쿠버네티스의 Gateway API로 대체하는 방향으로 나아간다고 들었는데, 게이트웨이 리소스 자체가 가지는 설정이 크게 많지는 않다보니 충분히 이 리소스의 교체는 큰 무리 없이 일어날 것 같다.
더구나 이스티오의 게이트웨이는 직접 게이트웨이 역할을 수행하는 워크로드를 배포해야 한다는 점에서 세팅에 한 과정이 늘어나는 꼴이라 조금 불편한 감도 없잖아 있다고 생각한다.

이전 글, 다음 글

• 1W - 네이티브 사이드카 컨테이너 이용: 4
• 2W - 인그레스 게이트웨이 실습: 6

다른 글 보기

관련 문서

참고