용량 버퍼 정보

용량 버퍼를 사용하면 클러스터에서 활성 또는 대기 용량의 계층을 사전에 선언하여 Google Kubernetes Engine (GKE) 워크로드의 포드 시작 지연 시간을 줄일 수 있습니다. 예비 용량을 미리 선언하면 비용 효율적인 방식으로 워크로드를 더 빠르게 시작할 수 있습니다.

이 문서에서는 용량 버퍼의 작동 방식을 설명합니다. 용량 버퍼를 사용 설정하고 사용하는 방법은 용량 버퍼 구성을 참조하세요.

용량 버퍼를 사용해야 하는 경우

시작 지연 시간에 민감하고 빠르게 확장해야 하는 애플리케이션에는 용량 버퍼를 사용하세요. 트래픽이 갑자기 증가하는 경우 활성 버퍼는 지연 시간이 짧은 확장을 위해 설계된 사전 프로비저닝된 용량을 제공합니다. 트래픽이 지속적으로 증가하는 경우 대기 버퍼는 사전 프로비저닝보다 저렴한 비용으로 포드 예약을 제공합니다.

용량 버퍼는 다음과 같은 이점을 제공합니다.

  • 확장 지연 시간 최소화: 활성 버퍼는 실행 중인 VM을 제공하여 지연 시간을 최소화합니다. 대기 버퍼는 빠르게 재개되어 새 노드보다 더 빠른 용량 가용성을 제공합니다.
  • 비용 효율적인 과도 프로비저닝: 용량 버퍼를 사용하면 고정 크기의 안전망을 유지할 수 있습니다. 대규모 워크로드의 경우 이 접근 방식은 클러스터가 커짐에 따라 유휴 용량을 선형으로 늘릴 수 있는 다른 과도 프로비저닝 방법 (예: HorizontalPodAutoscaler (HPA) 사용률 타겟 낮추기)보다 비용 효율적인 경우가 많습니다.
  • 워크로드 요구사항 충족: 용량 버퍼의 크기를 완전히 제어할 수 있습니다. 옵션에는 커스텀 데몬 세트 또는 데이터 통합, 이미지 사전 로드 및 워크로드 사전 시작 제어가 포함되어 요구사항에 맞게 조정할 수 있습니다.

AI 에이전트, AI 추론, 판매 이벤트 중의 소매 애플리케이션 또는 플레이어 활동이 최고조에 달하는 게임 서버와 같이 빠른 수직 확장이 필요한 지연 시간에 민감한 워크로드에는 용량 버퍼를 사용하는 것이 좋습니다.

시작 지연 시간에 민감하지 않은 워크로드(예: 일괄 처리 작업)에는 용량 버퍼를 사용하지 않는 것이 좋습니다. 이러한 워크로드의 경우 리소스를 과도하게 프로비저닝해도 이점이 없습니다.

용량 버퍼 작동 방식

Kubernetes CapacityBuffer 커스텀 리소스를 사용하여 예비 용량의 버퍼를 정의하여 용량 버퍼를 구현합니다. GKE 클러스터 자동 확장 처리는 CapacityBuffer 리소스를 모니터링하고 이를 대기 중인 수요로 취급하여 예비 용량을 사용할 수 있도록 합니다. 클러스터에 버퍼에 정의된 리소스 요청을 충족할 용량이 충분하지 않으면 클러스터 자동 확장 처리에서 노드를 추가로 프로비저닝합니다.

우선순위가 높은 워크로드가 확장되면 GKE는 버퍼의 사용 가능한 용량에 워크로드를 즉시 예약합니다. 이 즉시 예약은 버퍼에 예약된 복제본 수 또는 리소스 양에 적용되며 노드 프로비저닝과 관련된 일반적인 지연을 방지합니다. 워크로드가 버퍼 단위를 사용하면 클러스터 자동 확장 처리에서 버퍼를 다시 채우기 위해 새 노드를 프로비저닝합니다.

용량 버퍼 전략

지연 시간 및 비용 요구사항에 따라 다양한 프로비저닝 전략을 사용하여 용량 버퍼를 구성할 수 있습니다.

활성 버퍼

활성 버퍼 는 예약된 용량 내에 맞는 워크로드의 지연 시간이 짧은 확장을 위해 실행 중인 VM을 제공합니다. 노드가 이미 준비되어 있으므로 확장 이벤트 중에 초기 버퍼 소비에 최소한의 지연 시간을 제공합니다.

확장 시간이 최우선인 중요한 워크로드에는 이 전략을 사용하는 것이 좋습니다.

대기 버퍼

대기 버퍼 는 일시중지된 VM을 제공합니다. 대기 전략은 활성 전략보다 비용 효율적이지만 워크로드를 수락하기 전에 VM을 재개하는 데 약간의 지연이 발생합니다.

비용을 최적화하기 위해 확장에 약간의 지연을 허용할 수 있는 워크로드에는 이 전략을 사용하는 것이 좋습니다.

CapacityBuffer CRD

용량 버퍼를 구성하려면 CapacityBuffer CustomResourceDefinition (CRD)을 만듭니다. 다양한 기준을 충족하도록 용량 버퍼를 구성할 수 있습니다.

  • 고정 복제본: 고정된 수의 버퍼 포드를 지정합니다. 이 구성은 알려진 크기의 버퍼를 만드는 가장 간단한 방법입니다.
  • 비율 기반: 확장 하위 리소스 (예: 배포, StatefulSet, ReplicaSet 또는 작업)를 정의하는 기존 확장 가능한 객체의 비율로 버퍼 크기를 정의합니다. 버퍼 사이즈는 참조 워크로드가 확장됨에 따라 동적으로 조정됩니다. 포드 템플릿에는 복제본 필드가 없으므로 비율 기반 버퍼를 정의할 수 없습니다.
  • 리소스 한도: 버퍼가 예약해야 하는 총 CPU 및 메모리 양을 정의합니다. 컨트롤러는 참조된 포드 템플릿의 리소스 요청을 기반으로 만들 버퍼 포드 수를 계산합니다.

자세한 내용은 CapacityBuffer CRD 참조 문서를 확인하세요.

요구사항 및 제한사항

용량 버퍼에는 다음과 같은 요구사항 및 제한사항이 있습니다.

  • 용량 버퍼는 활성 버퍼의 경우 버전 1.35.2-gke.1842000 이상, 대기 버퍼의 경우 버전 1.35.2-gke.1842002를 실행하는 GKE 클러스터에서 사용할 수 있습니다.
  • 용량 버퍼는 노드 기반 결제 모델을 사용하는 워크로드만 지원합니다. 용량 버퍼는 포드 기반 결제 모델을 사용하는 워크로드를 지원하지 않습니다.
  • 클러스터에서 노드 자동 프로비저닝을 사용 설정하는 것이 좋습니다. 노드 자동 프로비저닝을 사용하면 클러스터 자동 확장 처리에서 CapacityBuffer의 리소스 요청을 기반으로 새 노드 풀을 만들 수 있습니다. 노드 자동 프로비저닝을 사용 설정하지 않으면 클러스터 자동 확장 처리에서 기존 노드 풀만 확장합니다.

대기 버퍼에는 다음과 같은 추가 제한사항이 있습니다.

다음 단계