본문 바로가기
AI 빅데이터/Open Source Software

[OSS] KNative로 컨테이너 Serverless로 서빙하기

by 마고커 2020. 7. 14.


쿠버네티스가 클라우드 관리의 표준이 되어가고 있지만, 쿠버네티스 관리 자체가 부담되기도 하며, 자동으로 컨테이너 로드 관리를 원할 때가 있다. 이를 테면, 소수의 노드를 여러 명이 번갈아 자신의 컨테이너를 사용해야 하는 환경이라면 매번 컨테이너 이미지를 올리거나 scale up/down하는 것이 번거로울 수 있다. 여러 AI 모델들을 올려 놓고 판매하는 장터가 생긴다면, 관리 없이 요청에 의해 각 컨테이너가 로드될 수 있다면 편리할 것이다. 적합한 예시였는지 확신하긴 어렵지만, Serverless는 이와 같이 서버 관리에 신경 쓰지 않고 컨테이너를 이용하기 위해(?, 자신 없음) 만들어졌다. 

 

GCP의 Cloud Run이나 AWS Fargate가 이러한 기능을 Managed Service로 구현해 놓은 것이며, 이들의 하부 구조에는 구글이 공개하여 오픈 소스화된 KNative와 Istio가 있다. 조병욱님과 김진웅님의 자료에 각각에 대한 좋은 설명이 있다.

 

 

Istio #1 - 마이크로 서비스와 서비스 매쉬

Istio #1 마이크로 서비스 아키텍처와 서비스 매쉬 조대협 (http://bcho.tistory.com) 마이크로 서비스 아키텍쳐는 여러가지 장점을 가지고 있는 아키텍쳐 스타일이기는 하지만, 많은 단점도 가지고 있다

bcho.tistory.com

 

Istio #3- Istio에 대한 소개

ISTIO 조대협 (http://bcho.tistory.com) Envoy를 이용해서 서비스 매쉬를 구현하기 위해서는 Envoy로 구성된 데이타 플레인을 컨트롤할 솔루션이 필요하다. Envoy를 데이타 플레인으로 사용하고 이를 컨트롤

bcho.tistory.com

 

Knative로 서버리스 워크로드 구현

Knative로 서버리스 워크로드 구현 - SK C&C 김진웅 at Google Cloud Next '19 Extended

www.slideshare.net

KNative는 Dockerfie로 컨테이너를 자동 구성하는 Building, 컨테이너를 serverless로 배포해주는 Serving, 주기적인 Event나 Alarm에 대응하게 하는 Eventing과 Monitoring으로 구성되어 있다. 그 중 간단히 Serving에 대해서만 해 본다. 김진웅님의 아래 예제에서 Serving부분만 EKS가 아닌 GCP의 GKE 환경에서 테스트 해 보았다.

 

 

Knative on EKS

EKS에서도 Knative를 구성해보자

ddii.dev

1쿠버네티스 클러스터 생성, Istio 설치, KNative 설치, 서비스 App작성 및 배포, 테스트의 순이다. 

 

1) 쿠버네티스 클러스터 생성

 

쿠버네티스 클러스터는 간단히 GKE로 생성하였다. 

2vCPU 3대의 Worker 노드로 이루어진 Default 형태다.

맥에서도 minikube 등을 이용해 클러스터를 구성하여 테스트할 수 있으나, 외부 IP 받아오는 부분을 어떻게 해결해야 할지 몰라 GCP에서 테스트 하였다.

 

2) Istio 설치

 

Istio와 KNative는 CRD(Customer Resource Definition)을 kubectl로 apply하여 설치한다. 

아래와 같이 생성되는 pod과 service들을 확인한다. container creating 상태에서 잠시 기다리면 running 상태로 바뀐다.

kubectl get pods -n istio-system

kubectl get svc -n istio-system

 

3) KNative 설치

 

kubectl apply -f https://github.com/knative/serving/releases/download/v0.5.0/serving.yaml \ 
-f https://github.com/knative/build/releases/download/v0.5.0/build.yaml \ 
-f https://github.com/knative/eventing/releases/download/v0.5.0/release.yaml \ 
-f https://github.com/knative/eventing-sources/releases/download/v0.5.0/eventing-sources.yaml \ 
-f https://github.com/knative/serving/releases/download/v0.5.0/monitoring.yaml \ 
-f https://raw.githubusercontent.com/knative/serving/v0.5.0/third_party/config/build/clusterrole.yaml 

 

위의 설명대로 KNative는 여러 기능 요소들로 구분되어 있는데, 모두 설치할 필요 없이 용도에 필요한 기능들만 적용하여 설치하면 된다. 여기서는 serving만 적용했다(아래와 같이 build나 eventing도 돌고 있는데 이유는 모르겠다.ㅠ).

 

kubectl get namespaces | grep knative

kubectl get pods -n knative-serving

 

4) 서비스 App 작성 및 배포

 

서비스는 간단히 flask를 사용하여 hello, world를 찍는 것으로 김진웅님이 만든걸 그대로 썼다.

 

<app.py>

위를 컨테이너화하기 위한 Dockerfile은 아래와 같다.

 

<Dockerfile>

그러나 이미 김진웅님이 docker hub에 올린 것을 쓸 것이므로 위의 내용은 따로 작성하지 않아도 된다. 구성된 KNative에 배포하는 yaml은 아래와 같다.

 

<service.yaml>

별다른 구성 없이 컨테이너 이미지 이름만 지정해 두었다.

 

$ kubectl apply -f service.yaml 
service.serving.knative.dev/helloworld-python created

 

위와 같이 적용하고 컨테이너가 배포되면, 모든 준비가 끝난다. 

 

5) 테스트

 

쿠버네티스 클러스터 안에 배포된 것이므로 외부 IP를 얻어와야 한다. 쿠버네티스 클러스터에서는 LoadBalancer를 직접 구성해야 하지만, Serverless로 사용하는 경우에는 Istio가 대신 구성해 준다.

 

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

 

 

위가 외부에서 클러스터 안의 노드에 접근하기 위한 주소이고, 아래는 클러스터 안에 구성된 end-point다. 아래의 명령을 통해 컨테이너가 응답하는 내용을 확인할 수 있다.

 

curl -H "Host:helloworld-python.default.example.com" http://34.64.152.150

 

 

컨테이너가 배포되었지만, 요청이 처음 발생한 경우까지 로드되지 않으므로 최초 실행 시에는 약간의 시간이 걸린다. 이후에는 빠르게 응답하고 요청이 특정 시간 동안 없으면 컨테이너는 다시 내려간다. 



댓글