Knative serving에서 각 버전은 모든 수신 요청을 처리하는 데 필요한 컨테이너 인스턴스 수에 맞게 자동으로 확장됩니다. 버전에 트래픽이 수신되지 않으면 기본적으로 버전이 컨테이너 인스턴스 0개로 축소됩니다. 하지만 원하는 경우 이 기본값을 변경하여 최소 인스턴스 설정을 사용해 이 인스턴스를 유휴 또는 '준비' 상태로 유지하도록 지정할 수 있습니다.
비용 관리 목적으로 또는 서비스에서 사용하는 다른 리소스와의 호환성을 높이기 위해 시작 가능한 총 컨테이너 인스턴스 수를 제한해야 할 수 있습니다. 예를 들면 Knative serving 서비스가 동시에 열려 있는 연결을 일정한 개수만 처리할 수 있는 데이터베이스와 상호작용하는 경우가 있습니다.
최대 컨테이너 인스턴스 정보
최대 컨테이너 인스턴스 설정을 사용하여 최대 컨테이너 인스턴스 수 설정에 설명된 대로 동시에 시작할 수 있는 총 인스턴스 수를 제한할 수 있습니다.
최대 인스턴스 수 초과
일반적인 상황에서는 수신 트래픽 로드를 처리하기 위해 새 인스턴스를 만들어 버전을 수평 확장합니다. 하지만 최대 인스턴스 한도를 설정하면 경우에 따라 수신 트래픽 로드를 처리하기에 인스턴스가 부족할 수 있습니다. 이 경우 수신 요청은 최대 60초 동안 큐에서 대기합니다. 이 60초 동안 인스턴스가 요청의 처리를 완료하면 큐에 추가된 요청을 처리하는 데 인스턴스를 사용할 수 있게 됩니다. 이 60초 동안 사용 가능하게 되는 인스턴스가 없으면 Cloud Run에서 429 오류 코드와 함께 요청이 실패합니다.
확장 보증
최대 인스턴스 한도는 상한입니다. 한도를 높게 설정한다고 해서 버전이 지정한 컨테이너 인스턴스 수로 수평 확장되는 것은 아니며,
다만 특정 시점의 컨테이너 인스턴스의 수가 한도를 초과하지 않아야 함을 의미합니다.
트래픽 급증
빠르게 트래픽이 증가하는 등 경우에 따라 Knative serving이 지정된 최대 인스턴스 값보다 약간 더 많은 컨테이너 인스턴스를 단시간에 만들 수 있습니다. 서비스가 이 일시적인 동작을 감당할 수 없으면 안전성이 보장되는 여유를 고려하여 최대 인스턴스 값을 더 낮게 설정해야 할 수 있습니다.
배포
새 버전을 배포하면 Knative serving이 이전 버전에서 새 버전으로 트래픽을 점진적으로 마이그레이션합니다. 각 버전에 최대 인스턴스 한도가 설정되기 때문에 배포 후 일정 기간 동안 지정된 한도를 일시적으로 초과할 수도 있습니다.
유휴 인스턴스 및 콜드 스타트 최소화
Kubernetes 리소스는 인스턴스가 요청을 처리할 때만 사용됩니다. 하지만 그렇다고 해서 모든 요청을 처리한 후 Knative serving에서 즉시 인스턴스를 종료하지는 않습니다. 콜드 스타트의 영향을 최소화하기 위해 Knative serving에서 일부 인스턴스를 유휴 상태로 유지할 수 있습니다. 이러한 인스턴스는 갑작스러운 트래픽 급증이 발생할 경우 요청을 처리할 준비가 되어 있습니다.
예를 들어 컨테이너 인스턴스는 요청 처리를 완료한 후에 다른 요청을 처리해야 할 경우에 대비하여 일정 기간 동안 유휴 상태로 유지될 수 있습니다. 유휴 컨테이너 인스턴스는 열린 데이터베이스 연결과 같은 리소스를 유지할 수 있습니다. 하지만 Cloud Run의 경우 CPU를 사용할 수 없습니다.
[[["이해하기 쉬움","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-09-01(UTC)"],[],[],null,["# Container instance autoscaling\n\nIn Knative serving, each [revision](/kubernetes-engine/enterprise/knative-serving/docs/resource-model#revisions)\nis automatically scaled to the number of container instances needed to handle\nall incoming requests. When a revision does not receive any traffic, by default\nit is scaled to zero container instances. However, if desired, you can\nchange this default to specify an instance to be kept idle or \"warm\" using\nthe [minimum instances](/kubernetes-engine/enterprise/knative-serving/docs/configuring/min-instances) setting.\n\nThe number of instances scheduled is impacted by:\n\n- The amount of CPU needed to process a request\n- The [concurrency setting](/kubernetes-engine/enterprise/knative-serving/docs/concurrency)\n- The [maximum number of container instances setting](/kubernetes-engine/enterprise/knative-serving/docs/configuring/max-instances)\n- The [minimum number of container instances setting](/kubernetes-engine/enterprise/knative-serving/docs/configuring/min-instances)\n\nIn some cases you may want to limit the total number of container instances\nthat can be started, for cost control reasons, or for better compatibility with\nother resources used by your service. For example, your Knative serving\nservice might interact with a database that can only handle a certain number of\nconcurrent open connections.\n\nAbout maximum container instances\n---------------------------------\n\nYou can use the maximum container instances setting to limit the total number of\ninstances that can be started in parallel, as documented in\n[Setting a maximum number of container instances](/kubernetes-engine/enterprise/knative-serving/docs/configuring/max-instances).\n\n### Exceeding maximum instances\n\nUnder normal circumstances, your revision scales out by creating new instances\nto handle incoming traffic load. But when you set a maximum instances limit, in some\nscenarios there will be insufficient instances to meet that traffic load. In\nthat case, incoming requests queue for up to 60 seconds. During this 60 second\nwindow, if an instance finishes processing requests, it becomes available to\nprocess queued requests. If no instances become available during the 60 second\nwindow, the request fails with a `429` error code on Cloud Run.\n\n### Scaling guarantees\n\nThe maximum instances limit is an upper limit. Setting a high limit does not mean\nthat your revision will scale out to the specified number of container instances.\nIt only means that the number of container instances at any point in time should\nnot exceed the limit.\n\n### Traffic spikes\n\nIn some cases, such as rapid traffic surges, Knative serving may, for a short\nperiod of time, create slightly *more* container instances than the specified\nmax instances value. If your service cannot tolerate this temporary behavior,\nyou may want to factor in a safety margin and set a lower max instances value.\n\nDeployments\n-----------\n\nWhen you deploy a new revision, Knative serving gradually migrates traffic\nfrom the old revision to the new one. Because maximum instances limits are set for\neach revision, you may temporarily exceed the specified limit during the period\nafter deployment.\n\nIdle instances and minimizing cold starts\n-----------------------------------------\n\nKubernetes resources are only consumed when an instance is handling a request,\nbut this does not mean that Knative serving immediately shuts down\ninstances once they have handled all requests. To minimize the impact of cold\nstarts, Knative serving may keep some instances idle. These\ninstances are ready to handle requests in case of a sudden traffic spike.\n\nFor example, when a container instance has finished handling requests, it may\nremain idle for a period of time in case another request needs to\nbe handled. An idle container instance may persist resources, such as open\ndatabase connections. However, for Cloud Run, the\n[CPU will not be available](/kubernetes-engine/enterprise/knative-serving/docs/reference/container-contract#cpu)\n\nTo keep idle instances *permanently* available, use the\n[`min-instance`](/kubernetes-engine/enterprise/knative-serving/docs/configuring/min-instances) setting.\n\nWhat's next\n-----------\n\n- To manage the maximum number of instances of your Knative serving services, see [Setting a maximum number of container instances](/kubernetes-engine/enterprise/knative-serving/docs/configuring/max-instances).\n- To manage the maximum number of simultaneous requests handled by each container instance, see [Setting concurrency](/kubernetes-engine/enterprise/knative-serving/docs/configuring/concurrency).\n- To optimize your concurrency setting, see [development tips for tuning concurrency](/kubernetes-engine/enterprise/knative-serving/docs/tips/general#tuning-concurrency).\n- To specify an idle instance to keep running to minimize latency or cold starts on first requests, see [Using `min-instance` to enable idle instances](/kubernetes-engine/enterprise/knative-serving/docs/configuring/min-instances)."]]