KNative 그게 뭘까?!

KNatives 란 ?

서버리스한 클라우드 네이티브 어플리케이션을 배포, 실행, 관리하기 위해 쿠버네티스(k8s) 환경에 구성요소를 추가하는 오픈소스 프로젝트이며, 구글이 2018년 7월에 발표하였습니다.

서버리스는 무엇인가?

개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 해주는 클라우드 네이티브 개발 모델입니다.

 

이게 무슨 말인가?

우리가 많이 아는 Serverless Computing Service로 AWS의 Lambda, GCP의 Cloud Functions 등이 있는데, 각각 AWS 인프라, GCP 인프라 위에서 동작하는건데, Serverless는 아니지 않을까? 라는 생각이 들었는데요.

Serverless 모델에서도 서버가 존재하는 것이 맞으나, 어플리케이션 개발와는 분리되어 추상화되어 제공되어짐을 의미합니다. 개발자는 어플리케이션 코드만 작성하여 패키징하여 제공하면, 그 뒷단에서 필요에 따라 자동으로 스케일 업/다운 등 필요한 기능등을 수행하여줍니다.

 

어떤 점이 좋아서 사용하는 가?

1. 인프라(서버) 관리를 하지 않아도 된다.

개발자는 서버 관리 및 배포와 관련된 작업을 해주지 않아도 됩니다.

2. 자동으로 스케일 업/다운 관리

트래픽 등 여러 상황에 맞게 스케일 업/다운 등 관리하여줍니다.

3. 사용한 만큼 지불

우리가 작성한 어플리케이션(또는 기능, 함수단위)가 수행함에 있어서 사용한 컴퓨팅 자원의 비용만 발생합니다. 아무런 동작을 하지 않는 유휴 상태에서 비용이 발생하지 않습니다.

 

서버리스 서비스에는 무엇이 있을까 ?

대표적으로 GCP의 Cloud Functions 와 AWS의 Lambda 서비스가 있습니다. 그러면 이러한 서비스를 이용하면 좋은데, 왜 Knative 오픈 소스 프로젝트가 시작되었을까? 많은 이유가 있지만 대표적인 이유는 다음과 같습니다.

클라우드 종속성

Cloud Functions는 GCP, Lambda는 AWS Cloud에 종속적이게 됩니다.

 

개발 언어와 프레임워크의 제한

각 서비스에서 지원해주는 언어와 프레임워크만을 사용하여 개발 할 수 있습니다.

 

왜 KNative 를 사용하는가 ?

앞서 살펴본 서버리스 서비스에는 다양한 서비스가 있습니다. 하지만 그러한 서비스들의 대표적인 문제점은 클라우드에 종속적이라는 점과, 사용할 수 있는 언어와 프레임워크가 제한적이라는 것입니다.

하지만 KNative는 K8S 환경이라면 어디에도 설치하여 사용할 수 있으며, 따라 온프로미스 환경에서도 K8S가 있다면 설치하여 사용할 수 있습니다.

 

KNative 주요 구성요소

1. Build

핵심 구성요소였으나, KNative의 핵심과 맞지 않는다고 판단되어 Deprecated 되었고, Tekton의 Pipelines의 사용을 권장하고 있습니다.

• https://github.com/knative/build/issues/614
• https://tekton.dev/

 

2. Serving

KNative Serving은 어플리케이션 또는 Function(작읍 기능단위의 스크립트)을 서버리스한 컨테이너 형태로 쿠버네티스 상에 배포하는 것을 도와주는 주요 구성요소입니다.

 

대표적인 기능

 

1. 서버리스한 컨테이너를 신속하게 배치하여 배포하여줍니다.

2. 컨테이너로 트래픽 요청이 없을 경우 Pod의 수를 0개로 축소하는 등의 오토 스케일링 작업을 수행하여줍니다.

3. 배포된 컨테이너의 Revision을 관리하여줍니다.

4. Istio(Contour, Kourier) 등과 통합하여 모니터링 및 트래픽을 효율적으로 관리할 수 있도록 도와줍니다.

5. HTTP/HTTPS 요청 모두 지원합니다.

 

Serving 구성요소는 Service, Configuration, Revision, Route 와 같은 4개의 CRD로 구성되어있습니다.

 

Configuration

Knative Serving으로 배포되는 어플리케이션에 대한 상태를 정의하는 리소스이며, 수정될 경우 새로운 Revision이 생성됩니다.

 

어플리케이션에 대한 상태 정보

1. 컨테이너 이미지의 경로

2. 환경 변수

3. 오토 스케일링 설정

4. Health-Check

5. etc…

 

Revision

Configuration의 히스토리 리소스이며, 특정 어플리케이션의 배포된 시점에 대한 스냅샷입니다.

Configuration을 생성 및 수정될 때마다 새로운 Revision이 생성되고, 이 리소스를 기반으로 하여 이전 Revision으로 롤백하거나, Revision 별로 트래픽을 분배하여 서비스할 수 있습니다.

 

Route

서비스로 들어오는 트래픽을 Revision으로의 라우팅을 정의하는 리소스입니다. 최신 버전으로 트래픽을 전부 보내거나, Revision 별로 트래픽을 분배하는 카나리 등의 여러 라우팅을 지원합니다.

 

Service

Configuration과 Route를 추상화한 리소스이며, 하나가 어플리케이션 서비스라고 보면 됩니다. K8S에서의 Deployment가 ReplicaSet 등을 추상화하는 것과 같은 개념이다.

 

3. Eventing

비동기 메시지 처리를 위한 컴포넌트(모듈)이며, 메시지 큐와 같은 이벤트 발생 자원들은 Event Source에 등록되고, 해당 이벤트가 발생하면 지정된 KNative Service로 이벤트 메시지를 전송하여줍니다.

 

표준 HTTP POST 요청을 사용하여, Event Source와 Sink 간에 이벤트를 주고 받습니다.

 

Component	Description
Source(Event Source) Producer	Broker에게로 Event를 발행하는 역할을 수행합니다. Knative Service는 Source, Sink의 역할 모두 수행할 수 있습니다. 지원하는 다양한 이벤트 소스 : https://knative.dev/docs/eventing/sources/index.html Event Source는 CRD이기때문에, 커스텀하게 만들어서 사용할수도 있습니다.
Broker	Event Source로 부터 발행된 메시지를 전달받아 저장하는 중앙 저장소 역할을 수행합니다. 다양한 브로커들을 지원합니다 : https://knative.dev/docs/eventing/broker/
Trigger	Broker에 적재된 메시지 중 특정 조건에 맞는 메시지(EventType이 일치한다거나, 등등)가 있을 경우, 해당 메시지를 서비스로 전달하여주는 역할을 수행합니다. 이를 통해 효율적으로 메시지를 전달할 수 있습니다.
Sink (Subscriber, Consumer)	메시지의 목적지(Service)입니다. Event Source는 CRD이기때문에, 커스텀하게 만들어서 사용할수도 있습니다.

 

Event Type

Broker에서 사용할 수 있는 이벤트 유형을 정의하는 리소스입니다.

• Github

apiVersion: eventing.knative.dev/v1alpha1
kind: EventType
metadata:
  generateName: dev.knative.source.github.push-**
  namespace: default
  owner: # Owned by github-source-sample
**spec:
  type: dev.knative.source.github.push
  source: <https://github.com/my-other-user/my-other-repo>
  broker: default**

 

Trigger

apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
  name: my-service-trigger
  namespace: default
spec:
  filter:
    sourceAndType:
      type: dev.knative.source.github.push
      source: <https://github.com/my-other-user/my-other-repo>
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1alpha1
      kind: Service
      name: my-service

 

Event Registry

Eventing Component에서는 Consumer가 원하는 Event를 보다 쉽게 찾아서 소비할 수 있도록 Event Type을 정의할 수 있는 Registry를 제공합니다.

Registry는 Event Type 들의 모음으로 구성되고, 트리거를 구성하는데 필요한 정보들을 가지게 됩니다.

 

다음 번에는 직접 사용해본 이야기로 돌아오겠습니다.

Reference

https://knative.dev/docs/eventing

https://github.com/knative/build

https://knative.dev/docs/eventing/event-registry/