Knative 분석

Knative 분석

Knative란?

쿠버네티스는 stateless 웹서비스를 구축할 때, deployment, ingress, service 등 쿠버네티스 리소스를 정의해서 배포해야 한다.
이런 서버쪽에 복잡한 설정없이 stateless 서비스를 구축하는 방법으로 서버리스 서비스가 있다.
"서버리스란 사용자가 노드를 관리하지 않는 VM이나 컨테이너 같은 환경을 말한다"

상용 서비스로는 아마존 클라우두 람다(Lambda) 구글 클라우드 평션(Function) 있고 오픈소스로는 구글의 Knative가 있다.

Knative는 서버리스 워크로드를 배포, 관리하기 위한 쿠버네티스 기반 플랫폼으로
특정 클라우드에 종속되지 않고 On-premise도 설치 가능하다.

Knative와 Kubernetes 배포 차이

만약 어떤 서비스를 Knative없이 쿠버네티스로 배포하려면 Loadbalancer, Ingress, Service등의 설정 및 생성을 직접해야 한다.

Knative는 추가 설정없이 간단하게 서비스 컨테이너 이름과 컨테이너만 정의하면 바로 배포 가능하다. 즉 서비스를 하는데 필요한 기타 설정들을 추상화함으로써 최소한의 설정만으로 서비스를 제공할 수 있도록 복잡도를 줄여주는 장점이 있다.

주요 컴포넌트

Knative는 Serving, Eventing 컴포넌트가 있다.

1) Knative Serving

• 주요 기능
  서버리스 컨테이너의 빠른 배포
  자동 스케일업과 다운(Scale to 0)
  Istio를 활용해 라우팅 지원
  특정 시점의 배포 된 코드 및 설정에 대한 스냅 샷

• Serving Resource
  1) Service
  Route와 Configuration 리소스의 추상화된 집합체이다.
  모든 작업(workload)의 lifecycle을 관리하고 트래픽이 항상 최신 Revision으로 라우팅되도록 정의할 수 있다.
  
  2) Route
  서비스로 들어오는 트래픽을 하나 이상의 Revision으로 라우팅하는 역할을 한다.
  최신버전의 Revision으로 자동 라우팅하거나 Canary 테스트와 같이 여러 Revision으로 라우팅할 수도 있다.
  
  3) Configuration
  소스 패키지(git repo, archive)를 컨테이너로 변환하기 위한 메타 데이터(빌드 설정, 환경변수, 오토스케일링)등을 정의한다.
  Knative Serving으로 배포되는 서비스를 정의하고 Revision의 상태를 추적할 수 있다.
  
  4) Revision
  코드와 Configuration에 대한 Snapshot으로 Configuration이 변경될때마다 생성된다.
  Route를 통해 endpoint가 지정되지 않은 Revision은 자동 폐기되고 K8s 리소스에서도 삭제된다.
  이전 Revision으로 롤백하거나 다른 버전의 Revision으로 트래픽을 분할해서 Serving할 수도 있다
  
  

• Serving 컴포넌트
  1) Activator
  서비스 Scaling시 서비스로 들어오는 Requests에 대한 수신 및 버퍼 역할을 한다.
  특정 Revision이 비활성화 되었을때 Revision에게 들어온 Request들을 받아 버퍼링하고 이를 Autoscaler에 보고한다.
  Autoscaler는 전달 받은 Requests를 기반으로 Revision을 확장(Scale)하고, 확장이 완료되면 Revision은 Requests를 다시 받아 처리하도록 한다.
  
  2) Autoscaler
  Requests를 수신 및 트래픽 부하를 처리하는데 필요한 Pod 수를 조정한다.
  
  3) Controller
  모든 Knative 객체들과 Autoscaling CRD를 관리한다.
  사용자가 Knative 서비스를 K8s API로 적용하여 Configuration과 Route를 만들면
  Configuration을 Revision으로, Revision들은 Deployment와 Knative Pod Autoscaler로 전환한다.
  
  4) Networking-istio
  클러스터의 진입이 Istio Virtual Service를 통하도록 지원한다.
  
  5) Webhook
  모든 K8s API 호출과 CRD 입력, 업데이트에 대한 요청을 중간에서 받아 유효성 여부를 검사한다.
  *webhook 개념
  서버에서 어떤 작업이나 이벤트가 수행되었을때 해당 작업이 수행되었음을 알리는 방법
  웹서비스를 제공해주는 서버측에서 어떤 이벤트를 외부에 전달하는 방법 중 하나

apiVersion: v1
kind: ConfigMap
metadata:      
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: "100"  # 동시 요청 처리 개수
 enable-scale-to-zero: "true"                 # scale to zero 사용 여부
 panic-window-percentage: "10"                # stable-window * 0.1, 갑작기 요청수가 많이 들어올 경우 panic 모드로 전환되고 time-window가 panic-window 시간으로 적용
 panic-threshold-percentage: "200"            # ContainerConcurrency * 200일 이상일 경우 panic 모드
 scale-to-zero-grace-period: "30s"            # 스케일 다운을 위한 대기 시간
 stable-window: "60s"                         # 동시 요청 수의 평균을 내기 위한 대기 시간
 tick-interval: "2s"                          # pod들을 스케일할 때의 pod 스케일링 간격
 ................