서버리스 오픈소스 - knative #1 소개 & Serving

Serveless를 위한 오픈소스 KNative

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

배경

근래에 들어서 컨테이너를 사용한 워크로드 관리는 쿠버네티스 de-facto 표준이 되어가고 있는데, 쿠버네티스 자체가 안정되어가고 있지만, 이를 현업에 적용하기 위해서는 아직까지 여러가지 챌린지가 있다.

컨테이너 기반의 쿠버네티스 서비스가 지향하는 바는, 셀프서비스 기반의 데브옵스 모델로 인프라와 이를 자동화하는 플랫폼을 인프라엔지니어가 개발하여 개발팀에 제공하고, 개발팀은 개발과 배포/운영을 스스로 하는 모델이다.

그런데 예를 들어 간단한 무상태(stateless) 웹서비스를 하나 구축한다 하더라도 Deployment,Ingress,Service 등의 쿠버네티스 리소스를 정의해서 배포해야 하고, 여기에 오토 스케일링이나, 리소스 (CPU,메모리)등의 설정을 따로 해줘야 한다. 그런데 이런 설정을 일일이 다 하기에는 일반 개발자들에게 부담이 된다. 또한 A/B 테스팅이나 카날리 배포등은 쿠버네티스 자체로 지원이 되지 않고 스피니커(spinnaker)등의 다른 솔루션을 부가해서 써야 하는데, 이런 모델은 컨테이너 기반의 셀프 서비스와는 거리가 멀어진다.

서버쪽에 복잡한 설정 없이 무상태 웹서비스나 간단한 이벤트 컨슈밍 서비스등을 구축하는 방법으로는 서버리스 서비스들이 있는다. 아마존 클라우드의 람다(Lambda)나, 구글 클라우드의 펑션(Function)등이 이에 해당한다. 그런데 이러한 서버리스 서비스들은 특정 클라우드 플랫폼에 의존성을 가지고 있는데, 이러한 문제를 해결하기 위해서 나온 오픈소스 서버리스 솔루션이 Knative 이다.

Knative

Knative는 구글의 주도하는 오픈소스 기반의 서버리스 솔루션으로 쿠버네티스 위에서 기동이 된다. 그래서 특정 클라우드 종속성이 없을뿐만 아니라 On-Prem에서도 설치가 가능하다. 지원되는 인프라 목록은 여기에 있는데, 레드헷 오픈 시프트, 피보탈, IBM 과 같은 On-Prem 쿠버네티스뿐만 아니라, 구글, Azure, IBM 클라우드등 다양한 클라우드를 지원한다.

Knative는 스테이트리스 웹서비스뿐만 아니라, 큐에서 이벤트를 받아서 처리하는 이벤트 핸들링을 위한 서버리스 모델을 지원하고, 거기에 더불어 컨테이너를 빌딩할 수 있는 빌드 기능을 제공한다. 그러면 각각을 살펴보자

Serving

서빙은 무상태 웹서비스를 구축하기 위한 프레임웍으로 간단하게 웹서비스 컨테이너만 배포하면, 로드밸런서의 배치, 오토 스케일링, 복잡한 배포 (롤링/카날리)등을 지원하고, 서비스 매쉬 솔루션인 istio와 통합을 통해서 다양한 모니터링을 제공한다.

Hello Serving

일단 간단한 예제를 보자. 아래는 미리 빌드된 간단한 웹서비스 컨테이너를 배포하는 YAML 스크립트이다.

apiVersion: serving.knative.dev/v1alpha1 # Current version of Knative kind: Service metadata:  name: helloworld-go # The name of the app  namespace: default # The namespace the app will use spec:  runLatest:    configuration:      revisionTemplate:        spec:          container:            image: gcr.io/knative-samples/helloworld-go # The URL to the image of the app            env:              - name: TARGET # The environment variable printed out by the sample app                value: "Go Sample v1"

<그림. service.yaml>

kind에 Service로 정의되었고, 서빙을 하는 컨테이너는 container>image에 container image URL이 정의되어 있다. 이 이미지를 이용해서 서빙을 하게 되며, 환경 변수를 컨테이너로 넘길 필요가 있을 경우에는 env에 name/value 식으로 정의하면 된다.

$kubectl apply -f service.yaml

<그림. 서비스 배포>

이렇게 정의된 서비스 yaml 파일은 다른 쿠버네티스의 yaml 파일과 같게 kubectl apply -f {파일명}을 이용하면 배포할 수 있게 된다.

쿠버네티스와 마찬가지로 yaml 파일을 정의해서 컨테이너를 정의하고 서비스를 정의해서 배포하는데, 그렇다면 쿠버네티스로 배포하는 것과 무슨 차이가 있을 것인가? 위의 설정 파일을 보면, 로드밸런서,Ingress 등의 추가 설정없이 간단하게 서비스 컨테이너 이름만 정의하고, 컨테이너만 정의하면 바로 배포가 된다. 서비스를 하는데 필요한 기타 설정을 추상화 시켜서 개발자가 꼭 필요한 최소한의 설정만으로 서비스를 제공할 수 있도록 해서, 복잡도를 줄여주는 장점이 있다.

그러면 배포된 서비스를 호출해보자

서비스를 호출하기 위해서는 먼저 서비스의 IP를 알아야 하는데, Knative serving 은 서비스 매쉬 솔루션인 istio 또는 apigateway인 Gloo 상에서 작동한다. 이 예제는 istio 위에 knative를 설치한것을 가정으로 설명한다.  istio에 대한 설명은 이링크와 이 링크 를 참고하기 바란다.

istio를 사용한 경우에는 istio의 gateway를 통해서 서비스가 되고,하나의 istio gateway가 몇개의 knative 서비스를 라우팅을 통해서 서비스한다. 이때 는 단일 IP이기 때문에 여러 knative 서비스를 서빙하기 위해서는 knative 서비스를 분류할 수 있어야 하는데 URI를 이용해서 구별을 하거나 또는 hostname 으로 구별을 한다. 이 예제에서는 hostname으로 구별하는 방법을 사용하였다.

그러면 실제로 서비스를 호출해보자. 먼저 istio gateway의 ip를 알아야한다.

Istio gateway ip는 다음 명령어를 이용하면 ip를 조회할 수 있다.

$kubectl get svc istio-ingressgateway --namespace istio-system

<그림. Istio gateway IP 조회>

다음으로 해야할일은 서비스의 domain 명을 알아야 하는데, 여기서 배포한 서비스는 helloworld-go 라는 서비스이다. 이 서비스가 배포되면 서비스에 대한 라우팅 정보가 정의되는데, kubectl get route 명령을 이용하면 라우팅 정보를 조회할 수 있고 그 중에서 domain 명을 조회하면 된다.

$kubectl get route helloworld-go  --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain

<그림. Istio gateway IP 조회>

호스트명을 조회하면 아래와 같이 해당 서비스의 호스트명을 알 수 있다.

Domain 명은 {route name}.{kubernetes name space}.도메인명 으로 되어 있고, 도메인명은 디폴트로 example.com을 사용한다. helloworld-go 애플리케이션의 route 명은 helloworld-go이고, 쿠버네티스 네임 스페이스는 default 네임 스페이스를 사용하였기 때문에, helloworld-go.default.example.com 이 전체 서비스 호스트명이 된다.

그러면 조회한 호스트명과 ingress gateway의 IP 주소를 이용해서, curl 명령으로 테스트 호출을 실행해보자.

$curl -H "Host: helloworld-go.default.example.com" http://${IP_ADDRESS}

<그림. Istio gateway IP 조회>

 

IP_ADDRESS는 앞에서 조회한 ingress의  gateway 주소를 이용하면 된다.

실행을하고 나면 다음과 같은 결과를 얻을 수 있다.

Serving detail

간단하게, Serving 을 테스트 해봤다. 그럼 Serving이 어떻게 구성되어 있는지 조금 더 자세하게 살펴보도록 하자. Serving 은 쿠버네티스 CRD (Custom Resource Definition)으로 정의된 4개의 컴포넌트로 구성되어 있다.

• Configuration
  Configuration은 knative serving으로 배포되는 서비스를 정의한다. 컨테이너의 경로, 환경 변수, 오토스케일링 설정, hearbeat 설정등을 정의한다. 재미있는것은 단순히 컨테이너 경로를 정의할 수 도 있지만, 컨테이너 빌드 설정을 정의할 수 있다. 즉 코드가 변경되었을때 Configuration에 있는 빌드 설정을 통해서 새로운 컨테이너를 빌드해서 자동으로 배포하고 새롭게 배포된 컨테이너를 이용해서 서비스를 할 수 있도록 한다.

• Revision
  Configuration의 히스토리라고 보면 되는데, Configuration을 생성할때 마다 새로운 revision이 생성된다.(Revision은 현재 Configuration의 스냅샷이다.) 그래서, 이전 revision으로 롤백을 하거나 저장된 각각의 다른 버전으로 트래픽을 분할해서 서빙할 수 있다.

• Route
  Route는 서비스로 들어오는 트래픽을 Revision으로 라우팅 하는 역할을 한다. 단순하게 최신 버전의 revision으로 라우팅할 수 도 있지만, 카날리 테스트와 같이 여러 revision으로 라우팅 하는 역할은 Route에서 정의된다.

• Service
  Service는 Configuration과 Route를 추상화하여, 하나의 웹서비스를 대표하는 개념이라고 보면 된다. 쿠버네티스에서 Deployment가 ReplicaSet 등을 추상화 하는 개념으로 생각하면 된다.

Serving 컴포넌트의 내용을 추상화하여 그림으로 표현하면 아래 그림과 같다.

<그림. Knative serving의 개념도>