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 리소스에 대해 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 서비스 아키텍처(확대하려면 클릭)
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 클러스터 아키텍처(확대하려면 클릭)
다음 다이어그램은 위 다이어그램을 확장하여 사용자 트래픽의 요청 경로를 자세히 보여줍니다. 자세한 내용은 아래 설명을 참조하세요.
Knative serving 요청 경로(확대하려면 클릭)
Knative serving 요청 경로의 경우:
트래픽 도착 경로:
클러스터 외부의 트래픽용 인그레스 게이트웨이
클러스터 내부의 트래픽용 클러스터 로컬 게이트웨이
트래픽 라우팅 규칙을 지정하는 VirtualService 구성요소는 사용자 트래픽이 올바른 버전으로 라우팅되도록 게이트웨이를 구성합니다.
제어 영역 구성요소인 Kubernetes 서비스는 포드 가용성에 따라 트래픽 처리를 위한 요청 경로의 다음 단계를 결정합니다.
버전에 포드가 없는 경우:
Activator가 수신된 요청을 일시적으로 큐에 넣고 포드를 더 확장하도록 자동 확장 처리에 측정항목을 푸시합니다.
자동 확장 처리가 배포에서 원하는 포드 상태로 확장합니다.
배포가 추가 요청을 수신하기 위해 포드를 더 만듭니다.
Activator가 큐 프록시 사이드카에 요청을 다시 시도합니다.
서비스가 수평 확장되면(포드 사용 가능) Kubernetes 서비스가 큐 프록시 사이드카에 요청을 전송합니다.
큐 프록시 사이드카는 컨테이너가 한 번에 처리할 수 있는 요청 큐 매개변수, 단일 또는 멀티 스레드 요청을 적용합니다.
큐 프록시 사이드카에 처리할 수 있는 것보다 요청이 많으면 자동 확장 처리가 추가 요청 처리를 위해 포드를 더 만듭니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# Architectural overview of Knative serving\n\nThis page provides an architectural overview of Knative serving and covers the changes that occur when you enable Knative serving in your Google Kubernetes Engine cluster.\n\n\u003cbr /\u003e\n\nThis information is useful for the following types of users:\n\n- Users getting started with Knative serving.\n- Operators with experience in running GKE clusters.\n- Application developers who need to know more about how Knative serving integrates with Kubernetes clusters to design better applications or configure their Knative serving application.\n\nComponents in the default installation\n--------------------------------------\n\nInstall [Knative serving](/knative) into\nyour cluster to connect and manage your stateless workloads. Knative\ncomponents are created in the `knative-serving` namespace.\n\nKnative serving uses Cloud Service Mesh to route traffic. By default,\nCloud Service Mesh installs components in the `istio-system` namespace.\n\nHere's a list of the components installed by Knative serving and Cloud Service Mesh:\n\n- Components installed by Knative serving in the `knative-serving` namespace:\n\n - **Activator** : When [pods](https://kubernetes.io/docs/concepts/workloads/pods/pod/) are scaled in to zero or become overloaded with requests sent to the revision, Activator temporarily queues the requests and sends metrics to Autoscaler to spin up more pods. Once Autoscaler scales the revision based on the reported metrics and available pods, Activator forwards queued requests to the revision. Activator is a data plane component; data plane components manage all functions and processes forwarding user traffic.\n - **Autoscaler**: Aggregates and processes metrics from Activator and the queue proxy sidecar container, a component in the data plane that enforces request concurrency limits. Autoscaler then calculates the observed concurrency for the revision and adjusts the size of the deployment based on the desired pod count. When pods are available in the revision, Autoscaler is a control plane component; otherwise, when pods are scaled in to zero, Autoscaler is a data plane component.\n - **Controller** : Creates and updates the child resources of Autoscaler and the [Service objects](#creating_a_service). Controller is a control plane component; control plane components manage all functions and processes establishing the request path of user traffic.\n - **Metrics Collector**: Collects metrics from Knative serving components then forwards them to Cloud Monitoring.\n - **Webhook** : Sets default values, rejects inconsistent and invalid objects, and [validates](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook) and [mutates](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) Kubernetes API calls against Knative serving resources. Webhook is a control plane component.\n- Components installed by Cloud Service Mesh running in the `istio-system` namespace:\n\n - **Cluster Local Gateway**: Load balancer in the data plane responsible for handling internal traffic that arrives from one Knative serving service to another. The Cluster Local Gateway can only be accessed from within your GKE cluster and does not register an external domain to prevent accidental exposure of private information or internal processes.\n - **Istio Ingress Gateway**: Load balancer in the data plane that is responsible for receiving and handling incoming traffic from outside the cluster, including traffic from either external or internal networks.\n - **Istiod** : Configures the Cluster Local Gateway and the Istio Ingress Gateway to handle HTTP requests at the correct endpoints. Istiod is a control plane component. For more information, see [Istiod](https://istio.io/latest/docs/ops/deployment/architecture/#istiod).\n\nKnative serving components are updated automatically with any\nGKE control plane cluster updates. For more information,\nsee [Available GKE versions](/kubernetes-engine/enterprise/knative-serving/docs/cluster-versions).\n\n### Cluster resource usage\n\nThe initial installation for Knative serving approximately requires 1.5\nvirtual CPU and 1 GB of memory for your cluster. The number of nodes in your\ncluster do not affect the space and memory requirements for a\nKnative serving installation.\n\nAn Activator can consume requests at a maximum of 1000 milliCPU and 600 MiB RAM.\nWhen an existing Activator can't support the number of incoming requests, an\nadditional Activator spins up, which requires a reservation of 300 milliCPU and\n60 MiB RAM.\n\nEvery pod created by the Knative serving service creates a\nqueue proxy sidecar that enforces request concurrency limits. The queue proxy\nreserves 25 milliCPU and has no memory reservation. The queue proxy's\nconsumption depends on how many requests are getting queued and the size of the\nrequests; there are no limits on the CPU and memory resources it can consume.\n\nCreating a Service\n------------------\n\n[](/static/kubernetes-engine/enterprise/knative-serving/docs/images/CRfAGCP-service-architecture.svg) Knative serving Service architecture (click to enlarge)\n\nKnative serving extends Kubernetes by defining a set of [Custom\nResource Definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources):\nService, Revision, Configuration, and Route. These CRDs define and control how\nyour applications behave on the cluster:\n\n- *Knative serving Service* is the top level custom resource defined by Knative serving. It is a single application that manages the whole lifecycle of your workload. Your service ensures your app has a *route* , a *configuration* , and a new *revision* for each update of the service.\n- *Revision* is a point-in-time, immutable snapshot of the code and configuration.\n- *Configuration* maintains the current settings for your latest revision and records a history of all past revisions. Modifying a configuration creates a new revision.\n- *Route* defines an HTTP endpoint and associates the endpoint with one or more revisions to which requests are forwarded.\n\nWhen a user creates a Knative serving Service, the following\nhappen:\n\n1. The Knative serving Service object defines:\n\n 1. A configuration for how to serve your revisions.\n 2. An immutable revision for this version of your service.\n 3. A route to manage specified traffic allocation to your revision.\n2. The route object creates VirtualService. The VirtualService object configures\n Ingress Gateway and Cluster Local Gateway to route gateway traffic to the\n correct revision.\n\n3. The revision object creates the following control plane components: a\n Kubernetes Service object and a Deployment object.\n\n4. Network configuration connects Activator, Autoscaler, and load balancers\n for your app.\n\nRequest handling\n----------------\n\nThe following diagram shows a high level overview of a possible request path for\nuser traffic through the Knative serving data plane components on a\nsample Google Kubernetes Engine cluster:\n[](/static/kubernetes-engine/enterprise/knative-serving/docs/images/CRfAGCP-cluster-architecture.svg) Knative serving cluster architecture (click to enlarge)\n\nThe next diagram expands from the diagram above to give an in depth view into\nthe user traffic's request path, also described in detail below:\n[](/static/kubernetes-engine/enterprise/knative-serving/docs/images/CRfAGCP-request-handling.svg) Knative serving request path (click to enlarge)\n\n\u003cbr /\u003e\n\nFor a Knative serving request path:\n\n1. Traffic arrives through:\n\n - The Ingress Gateway for traffic from outside of clusters\n - The Cluster Local Gateway for traffic within clusters\n2. The VirtualService component, which specifies traffic routing rules,\n configures the gateways so that user traffic is routed to the correct\n revision.\n\n3. Kubernetes Service, a control plane component, determines the next step in\n the request path dependent on the availability of pods to handle the\n traffic:\n\n - If there are no pods in the revision:\n\n 1. Activator temporarily queues the request received and pushes a metric to Autoscaler to scale more pods.\n 2. Autoscaler scales to desired state of pods in Deployment.\n 3. Deployment creates more pods to receive additional requests.\n 4. Activator retries requests to the queue proxy sidecar.\n - If the service is scaled out (pods are available), the Kubernetes Service\n sends the request to the queue proxy sidecar.\n\n4. The queue proxy sidecar enforces request queue parameters, single or\n multi-threaded requests, that the container can handle at a time.\n\n5. If the queue proxy sidecar has more requests than it can handle, Autoscaler\n creates more pods to handle additional requests.\n\n6. The queue proxy sidecar sends traffic to the user container."]]
