용량 버퍼를 사용하면 클러스터에서 활성 또는 대기 용량 버퍼의 등급을 사전에 선언하여 Google Kubernetes Engine (GKE) 워크로드의 포드 시작 지연 시간을 줄일 수 있습니다. 예비 용량을 미리 선언하면 비용 효율적인 방식으로 워크로드를 더 빠르게 시작할 수 있습니다.
이 문서에서는 용량 버퍼의 작동 방식을 설명합니다. 용량 버퍼를 사용 설정하고 사용하는 방법은 용량 버퍼 구성을 참조하세요.
용량 버퍼를 사용해야 하는 경우
시작 지연 시간에 민감하고 빠르게 확장해야 하는 애플리케이션에는 용량 버퍼를 사용하세요. 트래픽이 갑자기 증가하는 경우 활성 버퍼는 지연 시간이 짧은 확장을 위해 설계된 사전 프로비저닝된 용량을 제공합니다. 트래픽이 지속적으로 증가하는 경우 대기 버퍼는 사전 프로비저닝보다 저렴한 비용으로 포드 예약을 제공합니다.
용량 버퍼는 다음과 같은 이점을 제공합니다.
- 확장 지연 시간 최소화: 활성 버퍼는 실행 중인 노드를 제공하여 지연 시간을 최소화합니다. 대기 버퍼는 빠르게 재개되어 활성 버퍼에 비해 더 낮은 비용으로 새 노드보다 더 빠른 용량 가용성을 제공합니다.
- 비용 효율적인 과도 프로비저닝: 용량 버퍼를 사용하면 안전망을 유지할 수 있습니다. 대규모 워크로드의 경우 이 접근 방식은 클러스터가 커짐에 따라 유휴 용량을 선형적으로 늘릴 수 있는 다른 과도 프로비저닝 방법 (예: HorizontalPodAutoscaler (HPA) 사용률 타겟 낮추기)보다 비용 효율적인 경우가 많습니다.
- 워크로드 요구사항 충족: 용량 버퍼 구성을 완전히 제어할 수 있습니다. 옵션에는 커스텀 데몬세트를 통합하여 이미지를 미리 로드하고, 시작 시간을 조정하고, 필요에 맞게 버퍼 크기를 제어하는 것이 포함됩니다.
AI 에이전트, AI 추론, 판매 이벤트 중의 소매 애플리케이션 또는 플레이어 활동이 최고조에 달하는 게임 서버와 같이 빠른 수직 확장이 필요한 지연 시간에 민감한 워크로드에는 용량 버퍼를 사용하는 것이 좋습니다.
용량 버퍼의 작동 방식
Kubernetes CapacityBuffer 커스텀 리소스를 사용하여 예비 용량 버퍼를 정의하여 용량 버퍼를 구현합니다. GKE 클러스터 자동 확장 처리는 CapacityBuffer 리소스를 모니터링하고 이를 대기 중인 수요로 처리하여 예비 용량을 사용할 수 있도록 합니다. 클러스터에 버퍼에 정의된 리소스 요청을 충족할 수 있는 용량이 충분하지 않으면 클러스터 자동 확장 처리가 노드를 추가로 프로비저닝합니다.
우선순위가 높은 워크로드가 수직 확장되면 GKE는 버퍼의 사용 가능한 용량에 워크로드를 즉시 예약합니다. 이 즉시 예약은 버퍼에 예약된 복제본 수 또는 리소스 양에 적용되며 노드 프로비저닝과 관련된 일반적인 지연을 방지합니다. 워크로드가 버퍼 단위를 사용하면 클러스터 자동 확장 처리가 새 노드를 프로비저닝하여 버퍼를 다시 채웁니다.
용량 버퍼 전략
지연 시간 및 비용 요구사항에 따라 다양한 프로비저닝 전략을 사용하여 용량 버퍼를 구성할 수 있습니다.
활성 버퍼
활성 버퍼 는 예약된 용량 내에 맞는 워크로드의 지연 시간이 짧은 확장을 위해 실행 중인 노드를 제공합니다. 노드가 이미 실행 중이므로 수직 확장 이벤트 중에 포드를 클레임하는 데 최소한의 지연 시간이 발생합니다.
대기 버퍼
대기 버퍼 는 일시중지된 노드를 제공합니다. 대기 전략은 활성 전략보다 비용 효율적이지만 워크로드를 수락하기 전에 노드를 재개하는 데 약간의 지연이 발생합니다.
비용 및 가격 책정
용량 버퍼의 결제는 버퍼 유형에 따라 다릅니다.
- 활성 버퍼: GKE가 활성 버퍼 용량으로 사용하기 위해 유지관리하는 실행 중인 VM에 대해 표준 GKE 컴퓨팅 요금이 청구됩니다. Autopilot에서는 실행 중인 포드에 표준 포드 기반 결제 요금이 적용됩니다.
- 대기 버퍼: VM 인스턴스가 일시중지된 동안에는 컴퓨팅 비용 (CPU 또는 메모리)을 지불하지 않습니다. 사소한 스토리지 요금 (예: VM 부팅 디스크)과 고정 외부 IP 주소와 같은 연결된 리소스 비용이 발생합니다. GKE가 워크로드를 호스팅하기 위해 대기 VM을 재개하면 표준 컴퓨팅 또는 포드 기반 결제 요금이 적용됩니다.
CapacityBuffer CRD
용량 버퍼를 구성하려면 CapacityBuffer CustomResourceDefinition (CRD)을 만듭니다. 다양한 기준을 충족하도록 용량 버퍼를 구성할 수 있습니다.
- 고정 복제본: 참조된 포드 템플릿의 리소스 요청을 기반으로 만들 고정된 버퍼 포드 수를 지정합니다. 이 구성은 알려진 크기의 버퍼를 만드는 가장 간단한 방법입니다.
- 리소스 한도: 버퍼가 예약해야 하는 총 CPU 및 메모리 양을 지정합니다. 컨트롤러는 참조된 포드 템플릿의 리소스 요청을 기반으로 만들 버퍼 포드 수를 계산합니다.
- 비율 기반: 확장 하위 리소스 (예: 배포, StatefulSet, ReplicaSet 또는 작업)를 정의하는 기존 확장 가능한 객체의 비율로 버퍼 크기를 정의합니다. 참조 워크로드가 확장됨에 따라 버퍼 크기가 동적으로 조정됩니다. 비율 기반 용량 버퍼는 Kubernetes 확장 하위 리소스를 구현하는 객체에만 지원됩니다.
자세한 내용은 CapacityBuffer CRD 참조 문서를 확인하세요.
권장사항
용량 버퍼를 구성할 때 비용 효율성과 응답성을 최적화하려면 다음 권장사항을 따르세요.
- 비용 최적화된 대기 우선 전략 사용: 워크로드가 약 30 초의 짧은 수직 확장 지연을 허용할 수 있는 경우 대기 버퍼의 우선순위를 지정합니다. 이 전략은 활성 VM의 전체 비용을 발생시키지 않고 새 VM의 콜드 노드 부팅을 방지합니다.
- 지연 시간에 민감한 워크로드에 활성 버퍼 사용: 포드 일정 계획 시간이 가능한 한 짧아야 할 때 노드 재개 시간을 허용할 수 없는 워크로드에 활성 버퍼를 사용합니다.
- 성능과 비용의 균형을 맞추기 위해 하이브리드 전략 사용: 비용 효율적인 설정을 위해 작은 활성 버퍼와 더 큰 대기 버퍼를 결합합니다. GKE는 대기 버퍼에서 노드를 재개하여 활성 버퍼를 다시 채우는 것을 우선시하며 (약 30초 소요), 대기 버퍼를 백필하기 위해 백그라운드에서 새 노드가 프로비저닝됩니다. 이 설정은 활성 용량으로 초기 급증을 흡수하고 더 낮은 비용의 대기 용량을 사용하여 지속적인 성장을 수용합니다.
- 초기 급증을 위한 활성 버퍼 크기 조정: 대기 버퍼 노드가 재개되기 전에 발생할 것으로 예상되는 초기 복제본 급증을 처리하도록 활성 버퍼의 크기를 정의합니다.
- 지속적인 부하를 위한 대기 버퍼 크기 조정: 버퍼가 콜드 스타트에서 백그라운드로 다시 채워질 수 있도록 발생할 것으로 예상되는 확장된 부하를 처리할 수 있는 충분한 대기 버퍼를 정의합니다. 충분한 크기의 대기 버퍼는 최대 포드 예약 지연 시간을 노드를 재개하는 데 걸리는 시간(약 30초)으로 줄일 수 있습니다. 용량 버퍼가 사용되기 시작하고 다시 채워지면 새 버퍼 노드는 일시중지되기 전에 활성 상태로 전환됩니다. 이 전략은 장기 부하 중에 활성 용량을 늘리는 데 도움이 됩니다.
- 버퍼 시뮬레이터 사용: 특정 워크로드에 가장 적합한 결과를 얻기 위해 다양한 활성 및 대기 버퍼 크기를 실험해 봅니다. https://github.com/gke-labs/buffers-simulator의 오픈소스 GKE 버퍼 시뮬레이터를 사용하여 워크로드 확장 동작 시뮬레이션을 실행하여 버퍼 크기 조정 규칙을 미세 조정하고 성능 목표를 달성합니다.
요구사항 및 제한사항
용량 버퍼에는 다음과 같은 요구사항 및 제한사항이 있습니다.
- 용량 버퍼는 활성 버퍼의 경우 버전 1.35.2-gke.1842000 이상을 실행하는 GKE 클러스터에서, 대기 버퍼의 경우 버전 1.36.0-gke.2253000을 실행하는 GKE 클러스터에서 사용할 수 있습니다.
- 용량 버퍼는 특정 하드웨어를 선택하는 Standard 노드 풀 및 Autopilot 노드 풀에 노드 기반 결제 모델을 사용하는 워크로드만 지원합니다. 용량 버퍼는 포드 기반 결제 모델을 사용하는 워크로드를 지원하지 않습니다.
- Standard 클러스터에서는 노드 자동 프로비저닝을 사용 설정하는 것이 좋습니다. 노드 자동 프로비저닝을 사용하면 클러스터 자동 확장 처리가 CapacityBuffer의 리소스 요청을 기반으로 새 노드 풀을 만들 수 있습니다. 노드 자동 프로비저닝을 사용 설정하지 않으면 클러스터 자동 확장 처리는 기존 노드 풀만 확장합니다.
- 활성 및 대기 용량 버퍼는 모두 Compute Engine 할당량에 포함됩니다.
- CapacityBuffer 구성 종속 항목(예: PodTemplate)이 커스텀 ComputeClass를 선택하는 경우 종속 항목은 프로비저닝된 노드에서 스케줄링하는 데 필요한 모든 톨러레이션(toleration), 노드 선택기 또는 런타임 클래스(예: GKE Sandbox 요구사항)를 정의해야 합니다. 자세한 내용은 커스텀 ComputeClass 문서를 참조하세요.
대기 버퍼에는 다음과 같은 추가 제한사항이 있습니다.
- 노드 자동 프로비저닝이 사용 설정된 Standard 클러스터에서 지원됩니다.
- 버전 1.36.0-gke.2853000 이상을 실행하는 Autopilot 클러스터에서 지원됩니다.
- GPU 또는 TPU가 연결된 노드는 지원되지 않습니다.
- 로컬 SSD는 지원되지 않습니다.
- 컨피덴셜 Google Kubernetes Engine 노드는 지원되지 않습니다.
- Compute Engine 일시중지 및 재개 작업과 관련된 제한사항을 잘 알고 있어야 합니다.
몇 가지 주요 제한사항은 다음과 같습니다.
- 고객 제공 암호화 키 (CSEK)로 보호되는 디스크가 있는 노드는 지원되지 않습니다.
- 메모리가 208GB를 초과하는 노드는 지원되지 않습니다.
- 베어메탈 인스턴스는 지원되지 않습니다.
- 노드 OS는 ACPI S3 절전 모드 신호를 지원해야 합니다.
- 일시중지 프로세스 길이는 메모리 크기에 비례합니다.
- 재개는 재개에 필요한 기본 리소스의 확보 가능성에 따라 다릅니다.
다음 단계
- 용량 버퍼를 구현하는 방법을 알아보려면 용량 버퍼 구성을 참조하세요.