Devops
Knative
Knative Serving

Knative Serving

1️⃣ Knative Serving이란?

Knative Serving은 컨테이너 기반 서버리스 애플리케이션을 배포하고 관리할 수 있도록 설계된 Kubernetes 확장 기능입니다.
이를 통해 애플리케이션을 배포할 때 자동 확장(Auto-scaling), 트래픽 관리, 버전 관리, Scale-to-zero 등의 기능을 활용할 수 있습니다.

✅ Knative Serving의 주요 특징

  • 자동 확장(Auto-scaling) → 트래픽에 따라 Pod 수 자동 조정
  • Scale-to-zero → 요청이 없으면 Pod을 0으로 줄여 리소스 절약
  • 트래픽 관리(Route, Configuration) → Canary 배포, Blue-Green 배포 지원
  • 빠른 배포 및 롤백 지원(Revision)

💡 Knative Serving 아키텍처 개요
Knative Serving Architecture

2️⃣ 서비스(Service) (서비스 객체의 기본 개념과 설정)

Knative Serving에서 Service는 Knative 애플리케이션의 진입점 역할을 합니다.
Knative Service를 생성하면 자동으로 Revision, Route, Configuration이 함께 생성됩니다.

1. Knative Service의 구조 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
          ports:
            - containerPort: 8080

✅ Service를 생성하면 다음 리소스가 자동 생성됨

  • Configuration → 애플리케이션의 현재 설정
  • Revision → 코드 변경 시 새로운 버전이 자동 생성
  • Route → 트래픽을 특정 Revision으로 라우팅

3️⃣ Revision (버전 관리 및 롤백 전략)

Knative Serving에서 Revision은 애플리케이션의 특정 버전을 나타내는 불변(Immutable) 객체입니다.
애플리케이션이 변경될 때마다 새로운 Revision이 생성되며, 이전 버전으로 롤백이 가능합니다.

1. Revision 생성 예제 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-world
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go:v2
  • 새로운 컨테이너 이미지 helloworld-go:v2가 배포되면 새로운 Revision이 생성됨.

2. 트래픽을 이전 Revision으로 롤백 

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: hello-world-route
spec:
  traffic:
    - revisionName: hello-world-v1
      percent: 100
  • 이전 Revision(hello-world-v1)으로 트래픽을 다시 보낼 수 있음.

4️⃣ Route & Configuration (트래픽 분배 및 설정)

Knative Serving에서 Route는 트래픽을 특정 Revision으로 라우팅하는 역할을 합니다.
Configuration은 현재 Knative Service의 설정을 유지하며, 변경될 때마다 새로운 Revision을 생성합니다.

1. Canary 배포 예제 (트래픽 분배) 

apiVersion: serving.knative.dev/v1
kind: Route
metadata:
  name: canary-route
spec:
  traffic:
    - revisionName: hello-world-v1
      percent: 50
    - revisionName: hello-world-v2
      percent: 50
  • hello-world-v1과 hello-world-v2에 50%씩 트래픽을 분배하여 Canary 배포를 수행.

5️⃣ Autoscaling (수요 기반의 자동 스케일링 설정)

Knative는 트래픽 부하에 따라 자동으로 Pod 수를 조절할 수 있도록 Knative Pod Autoscaler(KPA)를 제공합니다.
또한, Kubernetes의 HPA(Horizontal Pod Autoscaler)와 함께 사용 가능.

1. MinScale 및 MaxScale 설정 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: auto-scale-example
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "10"
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
  • minScale: 1 → 최소 1개의 Pod 유지
  • maxScale: 10 → 최대 10개의 Pod까지 확장 가능

6️⃣ Concurrency & Scaling (동시성 및 스케일링 전략)

Knative Serving에서는 각 Pod에서 처리할 요청 개수(동시성)를 조정할 수 있습니다.

1. Concurrency 설정 예제 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: concurrency-example
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
  • 한 Pod에서 최대 10개의 요청을 동시에 처리하도록 설정.

7️⃣ Cold Start & Warm Start (서버리스 모델의 성능 최적화)

Knative의 Scale-to-zero 기능으로 인해 Pod이 0이 되면 처음 요청 시 Cold Start 문제가 발생할 수 있습니다.
이를 방지하기 위해 minScale을 설정하거나, Keep-alive 요청을 보낼 수 있습니다.

1. Cold Start 방지 (minScale 사용) 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: warm-start-example
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
  • 최소 1개의 Pod을 유지하여 Cold Start 문제를 해결.

8️⃣ Ingress & egress 구성

Knative는 Istio, Contour, Kourier 등의 Ingress 컨트롤러를 지원하며,
트래픽을 내부(Kubernetes 내부)와 외부(외부 클라이언트)로 분리할 수 있습니다.

1. 외부 트래픽 차단 (Internal Only) 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: internal-service
  labels:
    networking.knative.dev/visibility: cluster-local
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
  • cluster-local 레이블을 사용하면 내부 네트워크에서만 접근 가능.

2. 외부 트래픽 허용 (Public Access) 

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: public-service
spec:
  template:
    spec:
      containers:
        - image: gcr.io/knative-samples/helloworld-go
  • cluster-local 레이블을 설정하지 않으면 외부에서도 접근 가능.

9️⃣ 외부 트래픽과 내부 트래픽 분리

Knative에서는 외부 트래픽은 Public 서비스로, 내부 트래픽은 Private 서비스로 구성할 수 있습니다.

1. Istio Gateway를 활용한 내부 및 외부 트래픽 분리 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: knative-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*.public.example.com"
    - port:
        number: 80
        name: internal
        protocol: HTTP
      hosts:
        - "*.internal.example.com"
  • *.public.example.com → 외부 트래픽
  • *.internal.example.com → 내부 트래픽
RSS Feed
마지막 수정일자
Knative 아키텍처Knative Eventing