블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

오픈소스 API 게이트웨이 Kong

#3 쿠버네티스 Kong

조대협 (http://bcho.tistory.com)


Kong Kubernetes

API 게이트웨이가 마이크로서비스의 중요 컴포넌트이다 보니, Kong이 마이크로 서비스에 적합한 K8S (aka. 쿠버네티스)에 어떻게 적용될 수 있는지가 궁금해서 아키텍쳐 관련 설명 내용을 찾아보았다. https://konghq.com/blog/kong-kubernetes-ingress-controller/ (아래 그림은, 이 동영상에서 캡춰하여 사용하였다.) 에 보면 Kong summit에서 발표된 영상이 있는데, 정리가 매우 잘되어 있다. 


기본 컨셉을 먼저 요약해보자면, Kong의 리소스들은 K8S의 리소스로 등록되어 사용되게 된다. API 게이트 웨이는 Ingress로 등록되고, Plugin들은 CRD (Kubernetes Custom Resource Definition)으로 등록되어 적용된다. 즉 별도의 Kong 설정을 하는 것이 아니라 쿠버네티스 리소스로 쿠버네티스 아키텍쳐에 따라서 등록이 된다는 이야기이다. 별도의 서비스나 서버를 기동하는 것이 아니라 K8S의 일부로 사용할 수 있도록 하고 있다. (동영상에서도 나오지만 Kong이 K8S 1’st citizen임을 계속 강조하고 있다.)


Kong의 쿠버네티스내의 배포 아키텍쳐는 다음과 같다. 

먼저 관리 서버 부분인 Control plane과, API 게이트 웨이 부분인 Data plane으로 나뉘어 진다. 


Control plane에는 Ingress controller가 있고, 이는 K8S의 API 서버와 통신을 통해서 명령을 받는다. 그리고 이 설정 정보를 psql 데이타 베이스에 저장한다. 

저장된 설정 정보는 Data plane 즉, API 게이트웨이 인스턴스에 반영이 된다. 

(만약에 psql이 죽어도 dataplane에 있는 프록시는 설정을 저장하고 있기 때문에 문제 없다.)


Kong의 리소스 맵핑

그러면 Kong API 게이트웨이에서 사용하는 리소스들은 어떻게 쿠버네티스 리소스로 맵핑이 될가?

쿠버네티스의 리소스를 Kong의 리소스로 맵핑(Translate) 해서 서비스 한다. 

아래는 Kong에서 사용하는 리소스들이다. 


이를 쿠버네티스 리소스로 맵핑한것은 다음과 같다. 




  • Route는 Ingress rule로 맵핑이 되고

  • Service 는 쿠버네티스의 Service로 맵핑 된다.

  • Target은 쿠버네티스의 pod가 되고

  • Upstream은 healthcheck와 LB로 정의 된다. 


게이트웨이에서 사용되는 플러그인 (라우팅이나 RateLimiting, Logging, 인증등)은 K8S의 CRD로 정의되어 있다.  CRD를 사용하게 되면 Ingress 에 반영되어서 사용된다.  

아래는 Rate limiting 플러그인을 K8S에서 CRD로 정의해서 사용한 예제이다

플러그인 CRD들은 ingress에 붙어서 사용된다. 




Ingress는 CRD와 함께 Limit rating, Logging, Routing등을 제공한다. 이러한 기능들은 대부분 Istio와 같은 Service mesh에도 있는데, Istio와 같은 서비스 메쉬와 비교할 경우, JWT 등  인증이 안되는 부분이 있는데, 이 부분을 보면 다소 차이가 있다. 


결론적으로 정리를 해보자면, Kong API 게이트웨이는 K8S에서는 Ingress로 정의되고, 플러그인은 CRD로 제공된다. Control Plane을 통해서 설정 정보가 저장되는 형태이다. 


쿠버네티스에 Kong을 설치하는 가이드는  https://docs.konghq.com/install/kubernetes/ 있는데, 설치는 Helm이나 Kustomize로 도 가능한데, 데이타 베이스에 대한 내용을 보면, 다음과 같다. 


"We recommend running Kong in the in-memory (also known as DB-less) mode inside Kubernetes as all the configuration is stored in Kubernetes control-plane. This setup drastically simplifies Kong’s operations as one doesn’t need to worry about Database provisioning, backup, availability, security, etc."


별도의 데이타 베이스 설치는 권장하지 않고, DB-less 모드로 설정하기를 권장하고 있다. 

YAML 파일로 설정을 정의해서 변경할 경우, 설정이 어떻게 전체 게이트웨이로 전파가되는지 등은 실제 테스트를 해봐야 알 수 있을듯



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

오픈소스 API 게이트웨이 Kong

#2 아키텍쳐와 간단한 테스트

조대협 (http://bcho.tistory.com)

Kong 아키텍쳐

Kong API 서버의 배포 아키텍쳐는 다음과 같다. 


출처 : stackoverflow.com

Kong API 게이트웨이 각각 nginx 로 되어 있고, DB 모드의 경우에는 별도의 데이타 베이스 인스턴스를 사용한다. 지원되는 데이타 베이스로는 카산드라나 postgres를 사용할 수 있다. 

데이타 베이스를 사용하더라도 변경된 설정은 인스턴스에 바로 반영되지 않는다. 각 인스턴스가 설정 내용을 캐슁하기 때문인데, 캐쉬가 리프레쉬되어야 설정 내용이 반영된다. 

클러스터에서 Kong API 게이트웨이 인스턴스간의 로드 밸런싱을 하기 위해서는 각 인스턴스 앞에 로드밸런서를 배치 시킨다. 만약에 Session Affinity가 필요하다면 L4에서 IP나 Session based affinity를 설정해야 한다. 


Kong API 게이트웨이에서 각종 기능들은 nginX의 Lua 스크립트 모듈은 OpenResty를 이용한다. 

간단한 API 테스트

개념 이해가 끝났으면 간단한 테스트를 해보자

파이썬으로 간단한 API 서버를 구현하였다. app.py로 simpleapi:9001/api URL로 HTTP GET으로 간단하게 서빙하는 API가 있다고 할때


kong.yml을 다음과 같이 구현한다. 

_format_version: "1.1"


services:

- name: simpleapi

  url: http://simpleapi:9001

  routes:

  - name: simpleapi-route

    paths:

    - /simpleapiservice



simpleapi라는 이름으로 서비스를 등록하고 API 서버의 호스트 경로는 http://simpleapi:9001로 등록한다.

위의 설정은 {Kong IP}/simpleapiservice URL을 —> http://simpleapi:9001로 라우팅하도록 한 설정이다.

%curl localhost:8000/simpleapiservice/api


실행하면 http://simpleapi:9001/api 를 호출한 결과가 리턴된다. 


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Kong API gateway #1 - 설치와 둘러보기

카테고리 없음 | 2019.11.10 23:58 | Posted by 조대협

오픈소스 API 게이트웨이 Kong

조대협 (http://bcho.tistory.com)


Kong API 게이트 웨이를 설치 하는 방법은 여러가지가 있지만, 여기서는 테스트 환경용으로 로컬 환경에 도커 이미지로 간단하게 설치 하는 방법에 대해서 알아본다. 

(도커 기반 Kong API 게이트 웨이 설치 방법 참고 :  https://docs.konghq.com/install/docker/)

전체 설치 방법은 https://docs.konghq.com/install 를 참고하기 바란다. 

설치 하기

Kong 설치하기

Kong API 게이트웨이는 데이타베이스가 필요하지만, 간편하게 데이타 베이스가 없는 dbless 모드로 설치를 한다. 웹 인터페이스를 이용하기 위해서 Konga (https://pantsel.github.io/konga/) 를 추가로 설치할 것인다. Konga도 도커 컨테이너로 설치한다. 이때 Konga도 가 Kong API 게이트웨이로 통신을 해야 하기 때문에,둘을 같은 네트워크로 묶어서 서로 통신하도록 하겠다.

(참고 : 도커 컨테이너는 네트워크 공간이 각각 분리되기 때문에, 다른 컨테이너간에 통신을 하기 위해서는 네트워크 공간을 묶어줄 필요가 있다. )

네트워크 생성하기

Kong API 게이트 웨이 Admin API를  Konga에서 호출할 수 있도록 같은 네트워크로 묶기 위해서 “kong-net”이라는 네트워크를 생성한다

$ docker network create kong-net

디스크 볼륨 생성하기

여기서는 데이타베이스 없이 Kong API 게이트웨이를 설치하기 때문에, 디스크 볼륨을 정의하여 디스크에 설정 정보를 저장하도록 한다. 아래와 같이 디스크 볼륨을 생성한다.  

$ docker volume create kong-vol

설정 파일 작성하기 

디폴트 설정 파일이 있어야 게이트웨이가 기동이 되기 때문에 디폴트 설정 파일을 만든다.

설정 파일은 앞서 만든 kong-vol 볼륨에 kong.yml 로 저장이 된다. 파일을 생성하기 위해서 볼륨의 호스트 파일상의 경로를 알아보기 위해서 docker volume inspect 명령을 사용한다. 


$ docker volume inspect kong-vol


[

     {

         "CreatedAt": "2019-05-28T12:40:09Z",

         "Driver": "local",

         "Labels": {},

         "Mountpoint": "/var/lib/docker/volumes/kong-vol/_data",

         "Name": "kong-vol",

         "Options": {},

         "Scope": "local"

     }

 ]


디렉토리가 /var/lib/docker/volumes/kong-vol/_data임을 확인할 수 있다. 호스트(로컬 PC)의 이 디렉토리에서 아래와 같이 kong.yml 파일을 생성한다. 

kong.yml 파일 (주의 kong.yaml이 아님)

_format_version: "1.1"


services:

- name: my-service

  url: https://example.com

  plugins:

  - name: key-auth

  routes:

  - name: my-route

    paths:

    - /


consumers:

- username: my-user

  keyauth_credentials:

  - key: my-key


생성이 끝났으면 아래 도커 명령어를 이용해서 Kong API 게이트웨이를 기동 시킨다.

% docker run -d --name kong \

     --network=kong-net \

     -v "kong-vol:/usr/local/kong/declarative" \

     -e "KONG_DATABASE=off" \

     -e "KONG_DECLARATIVE_CONFIG=/usr/local/kong/declarative/kong.yml" \

     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \

     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \

     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \

     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \

     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \

     -p 8000:8000 \

     -p 8443:8443 \

     -p 8001:8001 \

     -p 8444:8444 \

     kong:latest


설치가 제대로 되었는지

%curl http://localhost:8001 

명령을 이용하여 확인한다. 

Konga설치 하기

다음은 웹 UI를 위해서 Konga를 설치한다. https://pantsel.github.io/konga/

여러가지 설치 방법이 있지만 간단하게 하기 위해서 역시 도커로 설치한다. 

% docker run -d -p 1337:1337 --network=kong-net --name konga -v /var/data/kongadata:/app/kongadata -e "NODE_ENV=production"              pantsel/konga


이때, Kong API 서버 8001 포트로 통신을 해서 관리 API를 호출해야 하기 때문에, network를 "kong-net”으로 설정해서 실행한다. 설치가 끝나면 http://localhost:1337을 접속하면 Konga UI가 나오고, 관리자 계정과 비밀 번호를 입력할 수 있다.


로그인을 하면 Kong API 게이트웨이와 연결을 해야 하는데, 이름(임의로 적어도 된다.) Kong API 게이트웨이 Admin URL을 적어야 한다. 이때 http://kong:8001 을 적는다. (kong은 Kong API 게이트 웨이를 도커 컨테이너로 기동할때 사용한 컨테이너 이름이다. localhost로 하면 Konga 컨테이너의 로컬 호스트를 찾기 때문에 정상적으로 작동하지 않는다. )


이제 설정할 준비가 되었다. 


참고 : kong-dashboard 도 테스트 해봤지만, UI가 Konga가 훨씬 나은듯 해서, 글 내용을 변경함

% docker run --network=kong-net -itd --rm -p 8080:8080 pgbi/kong-dashboard start --kong-url http://kong:8001 --basic-auth {사용자이름}={비밀번호}


쿠버네티스와 Kong 통합 둘러보기

Kong API 게이트웨이를 사용하는 방법은 VM 기반의 일반 서버 앞에 설치해서 사용해도 되지만 쿠버네티스에 같이 사용할 경우 쿠버네티스 기반의 마이크로 서비스 아키텍쳐 패턴 구현에 더 용이 한다. 생각보다 잘 되어 있어서 놀랐다. 

설치 방법은 https://docs.konghq.com/install/kubernetes/ 에 설명되어 있는데, Helm이나 Kustomize로 설치가 가능하고, Kong은 CRD 형태로 지정된 Ingress로 프로비저닝이 된다. 

그리고 설정은 별도의 데이타 베이스 설치가 필요 없고 쿠버네티스의 컨트롤 플레인(마스터)에 저장되기 때문에 운영이 비교적 간단하다.


데이타베이스가 없을 경우, API 메트릭 저장하는 부분에 대해서 우려를 했는데, 아래와 같이 외장 플러그인을 지원한다. 




데이타 독 통합이 지원되고, 프로메테우스를 통하여 메트릭 저장이 가능하다. 그리고 Kong 용 프로메테우스/그라파나 대쉬보드도 훌륭하게 지원되고 있고, 분산 트렌젝션 추적을 위한 ZipKin도 이미 지원하고 있다. 


반면 로깅이 약간 애매한데, ELK(EFK)지원은 직접적으로는 보이지는 않는다. 



대신 파일 로그가 있기 때문에, 이 파일을 읽을 수 있는 Fluentd를 설치하면 될것으로 보이지만, 아무래도 컨테이너를 새로 말아야 하는 부담이 있기도 하고, 이를 통해서 메트릭이나 API 전용 로깅을 하는데는 별도의 설정이 필요할듯 하다. 


일단 GKE (구글 클라우드)의 경우에는 마켓 플레이스를 통해서 쉽게 설치가 가능하니 한번 테스트해볼만한 가치는 있을듯


11월 10일 업데이트

DBless 모드를 사용하게 되면, 동적으로 설정 변경이 불가능하다. Konga를 설치하더라도 설정 내용을 볼수만 있고 설정 변경은 불가능하다. 그외에도 지원되는 플러그인등에 대한 제약 사항이 있기 때문에 이 부분을 주의해야 한다.

제약 사항


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Kong API gateway

아키텍쳐 | 2019.02.07 23:11 | Posted by 조대협

Kong API gateway 간단 리뷰 노트 


요즘 MSA가 다시 올라오기 시작하고 있고, Kubernetes Istio 조합으로 좋은 아키텍쳐를 많이 그려낼 수 있게 되기 시작해서, API 게이트웨이를 다시 살펴보고 있는데, 시장에 API 게이트 웨이들은 대부분 인수가 된 상황이고, Kubernetes에서는 Ambassador가 올라오고 있는데, Istio 통합이나 Kubernetes 통합 기능은 강력하지만, 아직 신생 제품이라 기능이 그리 많이 않고, 보통 오픈 소스 대세는 Kong을 많이 이야기 하길래 쭈욱 살펴봤는데, 일단 CLI 명령이 거의 없고 제대로 이해한것이 맞다면, REST CALL로 설정을 잡아야 하고, Kubenetes 에 Ingress로 올라갈 수 도 있고, Istio 통합도 로드맵에는 있지만 아직은 완성전 단계..  설치 스크립트를 따라가 보니 Cassandra나 Postgres를 뒷단에 놓는것이 아마도 로그 수집 용도인것 같은데, 가볍게 사용하기에는 설정이 너무 무겁다. 

GUI 도구로는 지원 도구인 Konga가 있기는 하지만 UI를 봤을때 너무 단순하기도 하다. 

지켜보기는 하지만, 아직은 살짝 기다려야 하는 상태가 아닌가 싶다. 


참고 https://medium.com/@tselentispanagis/managing-microservices-and-apis-with-kong-and-konga-7d14568bb59d


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. Skull Island 2019.07.17 18:17  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다