이 정보는 다음 유형의 사용자에게 유용합니다.
- Knative serving을 시작하는 사용자
- GKE 클러스터 실행 경험이 있는 운영자
- Knative serving을 Kubernetes 클러스터와 통합하여 효율적인 애플리케이션을 설계하거나 Knative serving 애플리케이션을 구성하는 방법에 대해 자세히 알아야 하는 애플리케이션 개발자
기본 설치에 포함된 구성요소
Knative serving을 클러스터에 설치하여 스테이트리스(Stateless) 워크로드를 연결하고 관리합니다. Knative 구성요소는 knative-serving 네임스페이스에 생성됩니다.
Knative serving은 Cloud Service Mesh를 사용하여 트래픽을 라우팅합니다. 기본적으로 Cloud Service Mesh는 istio-system 네임스페이스에 구성요소를 설치합니다.
다음은 Knative Serving 및 Cloud Service Mesh에 의해 설치된 구성요소 목록입니다.
knative-serving네임스페이스에서 Knative serving에 의해 설치된 구성요소:- Activator: 포드가 0으로 수평 축소되거나 버전에 요청이 과도하게 전송되면 Activator가 요청을 일시적으로 큐에 추가하고 더 많은 포드를 가동하도록 자동 확장 처리에 측정항목을 전송합니다. 자동 확장 처리가 보고된 측정항목 및 사용 가능한 포드를 기준으로 버전을 확장하면 Activator가 큐에 넣은 요청을 버전으로 전달합니다. Activator는 데이터 영역 구성요소입니다. 데이터 영역 구성요소는 사용자 트래픽을 전달하는 모든 기능 및 프로세스를 관리합니다.
- 자동 확장 처리: Activator 및 큐 프록시 사이드카 컨테이너의 측정항목을 집계 및 처리합니다. 요청 동시 실행 제한을 적용하는 데이터 영역의 구성요소입니다. 그런 다음 자동 확장 처리는 버전의 관찰된 동시 실행을 계산하고 원하는 포드 수를 기준으로 배포 크기를 조정합니다. 버전에 사용 가능한 포드가 있으면 자동 확장 처리가 제어 영역 구성요소이고, 그렇지 않고 포드가 0으로 수평 축소되면 자동 확장 처리가 데이터 영역 구성요소입니다.
- 컨트롤러: 자동 확장 처리 및 서비스 객체의 하위 리소스를 만들고 업데이트합니다. 컨트롤러는 제어 영역 구성요소입니다. 제어 영역 구성요소는 사용자 트래픽의 요청 경로를 설정하는 모든 기능 및 프로세스를 관리합니다.
- 측정항목 수집기: Knative serving 구성요소에서 측정항목을 수집한 후 Cloud Monitoring으로 전달합니다.
- 웹훅: 기본값을 설정하고, 일관성이 없고 잘못된 객체를 거절하고, Knative serving 리소스에 대해 Kubernetes API 호출을 검사 및 mutates합니다. 웹훅은 제어 영역 구성요소입니다.
istio-system네임스페이스에서 실행되는 Cloud Service Mesh에 의해 설치된 구성요소:- 클러스터 로컬 게이트웨이: 한 Knative serving 서비스에서 다른 항목으로 전달되는 내부 트래픽을 처리하는 데이터 영역의 부하 분산기입니다. 클러스터 로컬 게이트웨이는 GKE 클러스터 내에서만 액세스할 수 있으며, 비공개 정보 또는 내부 프로세스가 실수로 노출되지 않도록 방지하기 위해 외부 도메인을 등록하지 않습니다.
- Istio 인그레스 게이트웨이: 외부 또는 내부 네트워크의 트래픽을 포함하여 클러스터 외부에서 들어오는 트래픽을 수신하고 처리하는 데이터 영역의 부하 분산기입니다.
- Istiod: HTTP 요청을 올바른 엔드포인트에서 처리하도록 클러스터 로컬 게이트웨이 및 Istio 인그레스 게이트웨이를 구성합니다. Istiod는 제어 영역 구성요소입니다. 자세한 내용은 Istiod를 참조하세요.
Knative serving 구성요소는 GKE 제어 영역 클러스터가 업데이트될 때 자동으로 업데이트됩니다. 자세한 내용은 사용 가능한 GKE 버전을 참조하세요.
클러스터 리소스 사용량
Knative serving을 처음 설치할 때는 클러스터에 대략 1.5개의 가상 CPU와 1GB의 메모리가 필요합니다. 클러스터의 노드 수는 Knative serving 설치의 공간 및 메모리 요구사항에 영향을 주지 않습니다.
Activator는 최대 1,000milliCPU 및 600MiB RAM으로 요청을 소비할 수 있습니다. 기존 Activator가 새로 추가되는 요청 개수를 지원할 수 없으면 추가 Activator가 가동되고 이를 위해서는 300milliCPU 및 60MiB RAM 예약이 필요합니다.
Knative serving 서비스로 생성되는 모든 포드는 요청 동시 실행 제한을 적용하는 큐 프록시 사이드카를 만듭니다. 큐 프록시는 25milliCPU를 예약하며 메모리 예약은 없습니다. 큐 프록시의 소비는 큐에 입력되는 요청 수 그리고 요청 크기에 따라 달라집니다. 소비할 수 있는 CPU 및 메모리 리소스에는 제한이 없습니다.
서비스 만들기
Knative serving은 커스텀 리소스 정의(CRD) 집합인 서비스, 버전, 구성, 경로를 정의하여 Kubernetes를 확장합니다. 이러한 CRD는 클러스터에서 애플리케이션의 작동 방식을 정의하고 제어합니다.
- Knative serving 서비스는 Knative serving에서 정의되는 최상위 커스텀 리소스입니다. 워크로드의 전체 수명 주기를 관리하는 단일 애플리케이션입니다. 서비스는 서비스를 업데이트할 때마다 앱에 경로, 구성 및 새 버전이 포함되는지 확인합니다.
- 버전은 변경될 수 없도록 코드 및 구성이 포함된 특정 시점의 스냅샷입니다.
- 구성은 최신 버전에 대한 현재 설정을 유지 관리하고 모든 이전 버전의 내역을 기록합니다. 구성을 수정하면 새 버전이 생성됩니다.
- 경로는 HTTP 엔드포인트를 정의하고 요청이 전달되는 하나 이상의 대상 버전에 연결합니다.
사용자가 Knative serving 서비스를 만들면 다음 결과가 발생합니다.
Knative serving 서비스 객체는 다음을 정의합니다.
- 버전 제공 방법에 대한 구성
- 이 서비스 버전에 대한 변경될 수 없는 버전
- 버전에 대한 지정된 트래픽 할당을 관리하는 경로
경로 객체는 VirtualService를 만듭니다. VirtualService 객체는 게이트웨이 트래픽을 올바른 버전으로 라우팅하도록 인그레스 게이트웨이 및 클러스터 로컬 게이트웨이를 구성합니다.
버전 객체는 제어 영역 구성요소인 Kubernetes 서비스 객체와 배포 객체를 만듭니다.
네트워크 구성은 앱의 Activator, 자동 확장 처리, 부하 분산기를 연결합니다.
요청 처리
다음 다이어그램은 샘플 Google Kubernetes Engine 클러스터의 Knative serving 데이터 영역 구성요소를 통해 사용자 트래픽에 사용 가능한 요청 경로를 개략적으로 보여줍니다.
다음 다이어그램은 위 다이어그램을 확장하여 사용자 트래픽의 요청 경로를 자세히 보여줍니다. 자세한 내용은 아래 설명을 참조하세요.
Knative serving 요청 경로의 경우:
트래픽 도착 경로:
- 클러스터 외부의 트래픽용 인그레스 게이트웨이
- 클러스터 내부의 트래픽용 클러스터 로컬 게이트웨이
트래픽 라우팅 규칙을 지정하는 VirtualService 구성요소는 사용자 트래픽이 올바른 버전으로 라우팅되도록 게이트웨이를 구성합니다.
제어 영역 구성요소인 Kubernetes 서비스는 포드 가용성에 따라 트래픽 처리를 위한 요청 경로의 다음 단계를 결정합니다.
버전에 포드가 없는 경우:
- Activator가 수신된 요청을 일시적으로 큐에 넣고 포드를 더 확장하도록 자동 확장 처리에 측정항목을 푸시합니다.
- 자동 확장 처리가 배포에서 원하는 포드 상태로 확장합니다.
- 배포가 추가 요청을 수신하기 위해 포드를 더 만듭니다.
- Activator가 큐 프록시 사이드카에 요청을 다시 시도합니다.
서비스가 수평 확장되면(포드 사용 가능) Kubernetes 서비스가 큐 프록시 사이드카에 요청을 전송합니다.
큐 프록시 사이드카는 컨테이너가 한 번에 처리할 수 있는 요청 큐 매개변수, 단일 또는 멀티 스레드 요청을 적용합니다.
큐 프록시 사이드카에 처리할 수 있는 것보다 요청이 많으면 자동 확장 처리가 추가 요청 처리를 위해 포드를 더 만듭니다.
큐 프록시 사이드카가 트래픽을 사용자 컨테이너로 전송합니다.