Knative

미친놈들 모여서 미친것을 만들었군.. ㅎㅎ 예상했던 내용들을 현실로 만드는 클라스

Kubernetes 관련 비지니스를 하고 있는 입장에서 봐도 놀랄일이지만 인프라 영역부터 개발자 영역까지 모두를 추상화시키는 클라우드 네이티브의 힘이란 참 대단하다.

오늘은 knative에서 주요기능들을 둘러보고자 한다.

개인적인 생각은 Kubernetes 진영이라고 해야하나 CNCF 진영이라고 해야하나.. 그동안 노래를 부르고 주목했던 CRDs, Operators, Serverless Workload, CloudEvents, Mesh Layer 개념과 영역을 흡수해서 그 기반으로 확장시키고 있다.

kubectl apply -f https://storage.googleapis.com/knative-releases/serving/latest/release.yaml

위 코드 내용을 상세하게 보고있지만 담은것들이 정말 많다. 그래도 다 이해하려면 하나하나 챙겨봐야 한다.

오늘은 일단 코어 기능만 살펴본다.

Build

build는 Knative의 주요 custom resource이고 이를 이용하여 fetch, build, package를 수행한다. repo의 소스를 빌드하고 컨테이너로 이미지로 만들고 그다음에 Knative Serving으로 보낸다고 한다.

Build 용어

• Build는 여러 steps을 포함하고 Builder로 구체화된다
• Builder는 컨테이너 이미지 유형
• Build내 steps은 repository에 push를 할 수 있음
• BuildTemplate 는 재활용가능한 템플릿
• Build내 source는 kubernetes Volume으로 mount되는 데이터를 정의할수 있고 git, Google Cloud Storage, 컨테이너 이미지를 지원함.
• kubernetes Secret을 사용하여 ServiceAccount로 인증함

Serving

Knative Serving은 Kubernetes와 Istio를 기반으로 Serverless Workload가 클러스터에서 작동하는 방식을 정의하고 제어하는데 사용된다고 하지만 엄연히 Public FaaS(AWS Lambda등)와는 구별되어야 한다고 생각한다.

Serverless 라고 하는 용어를 쉽게 생각하는 사람들이 많은데 결국 나중에는 간단한 애플리케이션들은 다 Serverless 스타일로 전환될것이라는 사상을 서비스나 플랫폼에 넣고 있는 추세다.

CNCF 진형의 Cloud Event라고 하는 이벤트 그리드방식의 표준화를 따라 가는것인지 아니면 새로운 스타일을 정의하려고 하는것인지는 그들의 향후 Cloud Native 로드맵에 달려있다 해도 무방할것 같다.

• Serverless Container의 신속한 배치가 가능
• Automatic scaling up and down to zero
• Istio Component
• 배포 된 코드 및 config의 특정 시점 스냅 샷

Serving Resources

CRDs로 정의한 Objects 집합체, 이러한 Object들은 Serverless 워크로드 형태로 정의되고 사용된다. 가장 인상깊고 중요한 문구는 Request-driven compute that can scale to zero 인 것 같다.

한동안 유행했던 OpenPaaS, CF기반의 PaaS 플랫폼을 뛰어넘는 구축형 그것도 스프링부트 영역까지도 kubernetes 기반 이벤트 드리븐 서버리스로 간다는 이야기...

이미 퍼블릭으로는 GA도 되었다.

우리 팀원들과 함께 열심히 vmware dispatch framework으로 개발하고 있지만 결국 pivotal과 vmware는 거의 한몸이기에 더욱 더 변화가 필요한 순간이다.

• Route는 사용자 서비스에 대한 HTTP endpoint를 제공.
• Revisions은 code(function)와 config로 구성된 불변의 스냅샷. Route를 통해 endpoint를 할당받지 못한 Revision은 자동으로 kubernetes resource에서 삭제됨
• Configuration은 요구되는 Revision 최신 상태를 기록하고 생성하고 추적할수 있음. 소스 패키지(git repo나 archive)를 컨테이너로 변환하기 위한 내용이나 메타데이터등을 포함시킬수 있음.
• Service는 Routes와 Configurations 리소스의 추상화된 집합체. 모든 워크로드의 lifecycle을 관리함. 트래픽을 항상 최신의 revision으로 route되도록 정의할수 있음

Events

CNCF의 CloudEvent Spec. 기반으로 하는 이벤트를 produce/comsume 하는 방법을 제공한다. 플러그인 형태로 이벤트를 수신할수 있고 다양한 pub/sub 스타일의 broker service를 통해 제공될수 있다.

Azure는 이미 EventGrid서비스를 GA를 한 상황이고 Pivotal 진영도 Serverless Workload는 Knative기반으로 넘어간다고 했으니 Dispatch 도 결국 따라가지 않을까 생각해본다.

Bus

Kafka나 Nats와 같은 메시지 Bus를 통해 K8s기반의 pub/sub을 제공하는 개념. 이벤트는 Channel에 의해 게시되고 관심있는 사람에게 라우팅됨.

• Channel : 여기서 이야기 하는 채널은 특정 bus에 사용되는 이벤트를 받기 위한 네트워크 기반 엔드포인트
• Subscription : Channel에서 수신한 이벤트를 관심있는 target, DNS이름으로 표현되는 이벤트에 연결함
• Bus : (kafka topic에 이벤트가 전달되는것 처럼) 특정 지속성 전략을 사용하여 Channel과 Subscription을 구현하는데 필요한 적용 계층을 정의함

현재 3가지의 Bus가 제공됨 (Kafka, Stub, GCP PubSub)

Sources

Source는 K8s 외부의 데이터 소스를 프로비저닝하고 이를 클러스터로 라우팅하기 위한 추상화 레이어를 제공함. 아래와 같은 소스들을 제공하고 있음

• Feed : EventType과 Action (CloudEvents 호환 HTTP endpoint)간의 연결을 정의하는 기본 객체
• EventType and ClusterEventType : EventSource에서 분리되는 공통스키마로 특정 이벤트의 집합, EventType은 Namespace 범위내에서 사용되고 ClusterEventType은 모든 Namespace에서 사용될수 있도록 관리자에 의해 설치됨
• EventSource and ClusterEventSource : 하나 이상의 EventTypes를 생성 할 수있는 외부 시스템을 기술함

현재 3가지 Sources를 제공함

• K8sevents : Kubernetes Events를 수집하고 CloudEvents 타입으로 표시함
• Github : PR(pull request) notification을 수집하고 CloudEvents 타입으로 표시함
• GCP PubSub : GCP PubSub topic으로 publish된 이벤트를 수집하고 CloudEvents 타입으로 표시함

Flows

마지막으로 Source에서 Endpoint까지 묶어주는 Flow라고 부르는 높은 수준의 추상화가 있다. Spec으로 이벤트가 라우팅된 Channel과 Bus를 기재하여 사용할 수 있다. Flow는 Eventing에서 최상위 개념으로 사용자가 선택할수 있고, 외부 Source 이벤트에서 목적지까지 원하는 경로를 기술할수 있다.

정리

워낙 방대한 양을 가지고 있고 이해하려고 노력하면서 적다보니 번역위주로 되어버렸다. 원래 다음번에 Nats Streaming을 다룰 예정이였으나, 당분간은 knative 구성요소를 이해하고 적용하는 위주로 포스팅을 할 예정이다. 아마도 모듈별(Serving, Building, Eventing) 시리즈가 될 듯 하다.