Knative(케이네이티브)란?
서버리스(severless) 클라우드 네이티브 애플리케이션을 배포, 실행, 관리하기 위해 쿠버네티스(K8s)에 구성 요소를 추가하는 오픈소스 커뮤니티 프로젝트입니다. 서버리스 클라우드 컴퓨팅 모델은 개발자의 생산성을 높이고 운영 비용을 절감할 수 있습니다.
Knative 장점 및 특징
Knative는 서버 프로비저닝 및 관리 태스크를 제거합니다. 이를 통해 개발자는 복잡한 인프라 설정에 대해 걱정할 필요 없이 코드에 더욱 집중할 수 있습니다. 애플리케이션 구성 요소 전체가 사내에서 작성되는 것이 아니라 서비스로서의 백엔드(Backend-as-a-Service, BaaS)를 통해 타사에서 통합되면 이러한 장점이 더 확대됩니다.
Knative 구성 요소 3가지
Build/Deploy - 소스 코드를 컨테이너에 빌드하는 유연한 접근 방식
Serving - event-driven 모델을 통해 컨테이너를 신속하게 배포하고 자동 확장하여 on-prem 기반 serving workload 처리 가능
Eventing - 애플리케이션을 활성화하기 위해 이벤트를 소비하고 생산하기 위한 인프라 애플리케이션은 자체 애플리케이션의 이벤트, 다양한 제공업체의 클라우드 서비스, 서비스로서의 소프트웨어(Software-as-a-Service, SaaS) 시스템 및 다양한 소스로부터 트리거됩니다.
Serving
서빙은 무상태 웹서비스를 구축하기 위한 프레임웍으로 간단하게 웹서비스 컨테이너만 배포하면, 로드밸런서의 배치, 오토 스케일링, 복잡한 배포 (롤링/카날리)등을 지원하고, 서비스 매쉬 솔루션인 istio와 통합을 통해서 다양한 모니터링을 제공한다.
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 등을 추상화 하는 개념으로 생각하면 된다.
Eventing
knative의 다른 모듈로써는 비동기 메세지 처리를 위한 eventing 이라는 모듈이 있다. 카프카나, 구글 클라우드 Pub/Sub, AWS SQS와 같은 큐에서 메시지를 받거나 또는 Cron과 같은 타이머에서 이벤트가 발생하면 이를 받아서 처리할 수 있는 비동기 메커니즘을 제공하는 모듈이라고 보면 된다.
Event 방식 1
Event 방식 2
Event 방식 3