Google Kubernetes Engine (GKE)은 워크로드가 확장될 때 포드 시작 지연 시간을 줄이는 데 도움이 되는 여러 전략을 제공합니다. 노드 프로비저닝, 컨테이너 이미지 가져오기, 애플리케이션 초기화의 지연 시간을 줄이면 트래픽 급증 시 서비스 응답성을 개선하고 인프라 비용의 균형을 맞출 수 있습니다.
이 문서를 사용하여 포드 시작 수명 주기 전반에서 GKE 시작 지연 시간 감소 전략을 비교하고 워크로드 요구사항에 맞는 단일 전략 또는 계층화된 조합을 선택하세요.
포드 시작 수명 주기 이해
GKE에서 워크로드가 확장되고 기존 노드에 새 포드를 위한 할당 가능한 용량이 충분하지 않으면 엔드 투 엔드 시작 지연 시간이 세 가지 순차적 단계에 걸쳐 발생합니다.
- 노드 프로비저닝 및 포드 예약 단계에서 클러스터 자동 확장 처리는 새 Compute Engine VM을 프로비저닝하고 노드를 초기화하며 Kubernetes 스케줄러가 대기 중인 포드를 배치할 수 있도록 컨트롤 플레인에 등록합니다.
- 컨테이너 이미지 가져오기 단계에서 노드의
kubelet구성요소는 포드에 필요한 컨테이너 이미지를 Container Registry에서 다운로드하고 압축을 풉니다. - 애플리케이션 초기화 단계에서 컨테이너 런타임은 애플리케이션 프로세스를 시작하고 종속 항목 또는 모델 가중치를 메모리에 로드하며 Kubernetes 시작 및 준비 프로브를 전달합니다.
다양한 GKE 기능은 이 수명 주기의 특정 단계를 타겟팅합니다. 워크로드의 시작 시간에 가장 큰 영향을 미치는 단계를 알아보려면, 시작 지연 시간 측정항목 모니터링을 참조하세요.
시작 지연 시간 감소 전략 비교
다음 표에서는 포드 시작 수명 주기 전반에서 GKE 시작 지연 시간 감소 전략을 비교합니다.
| 전략 | 수명 주기 단계 | 지연 시간 프로필 | 비용 및 할당량 프로필 | 클러스터 모드 및 하드웨어 지원 | 용도 |
|---|---|---|---|---|---|
| 활성 용량 버퍼 (미리보기) | 노드 프로비저닝 및 포드 예약 | 노드가 이미 실행 중이므로 즉시 포드 예약 |
VM 실행을 위한 표준 노드 기반 컴퓨팅 요금 Compute Engine vCPU, 메모리, 디스크, IP 주소 할당량과 네임스페이스의 Kubernetes 리소스 할당량을 사용합니다. |
Standard 클러스터 및 커스텀 ComputeClass가 있는 Autopilot 클러스터 (노드 기반 결제) CPU, GPU, TPU를 지원합니다. |
갑작스러운 트래픽 급증을 흡수하고 지연 시간에 민감한 GPU, TPU 또는 CPU 워크로드를 확장합니다. |
| 대기 용량 버퍼 (미리보기) | 노드 프로비저닝 및 포드 예약 | 일시중지된 노드를 약 30~35초 내에 재개합니다. 이는 새 노드를 프로비저닝하는 것보다 빠릅니다. |
일시중지된 동안에는 VM 컴퓨팅 요금이 청구되지 않습니다. 부팅 디스크 및 저장된 메모리 상태에 대해 영구 디스크 스토리지 요금이 발생합니다. 일시중지된 동안에는 디스크 및 IP 주소 할당량과 네임스페이스의 Kubernetes 리소스 할당량을 사용합니다. |
Standard 클러스터(노드 자동 프로비저닝 포함) 및 Autopilot 클러스터(커스텀 ComputeClass 포함) CPU만 지원합니다 (GPU, TPU 또는 로컬 SSD 없음). |
지속적인 트래픽 증가에 대한 비용 효율적인 버스트 용량 유지 |
| 빠른 시작 노드 | 노드 프로비저닝 및 포드 예약 | 사전 초기화된 하드웨어를 사용하여 콜드 노드 시작 시간을 최선을 다해 줄입니다. | 추가 비용 없이 제공됩니다. |
Standard 클러스터의 Autopilot 클러스터 및 Autopilot 워크로드 로컬 SSD 또는 스팟 VM이 없는 적합한 범용 및 GPU 머신 시리즈를 지원합니다. |
구성 또는 유휴 용량 비용 없이 기준 노드 프로비저닝 가속화 |
| 우선순위가 낮은 플레이스홀더 포드 | 노드 프로비저닝 및 포드 예약 | 우선순위가 낮은 자리표시자 포드를 삭제한 후 즉시 포드 예약 |
실행 중인 노드의 표준 컴퓨팅 요금 수동 배포 및 PriorityClass 관리가 필요합니다. |
Standard 및 Autopilot 클러스터 | 포드 기반 결제 또는 1.35 이전 버전을 사용하는 클러스터에서 예비 용량 예약 |
| 이미지 스트리밍 | 컨테이너 이미지 가져오기 | 전체 이미지가 다운로드될 때까지 기다리지 않고 컨테이너를 시작할 수 있습니다. |
추가 비용 없이 제공됩니다. Artifact Registry 또는 적합한 Docker Hub 저장소가 필요합니다. |
Autopilot (기본적으로 사용 설정됨) 및 Standard 클러스터 | 대용량 컨테이너 이미지의 이미지 가져오기 시간 단축 |
| 보조 부팅 디스크 | 컨테이너 이미지 가져오기 | 노드 프로비저닝과 동시에 사전 채워진 영구 디스크를 새 노드에 연결합니다. | 각 노드의 연결된 영구 디스크 및 디스크 이미지 스토리지에 대해 요금이 청구됩니다. | Standard 및 Autopilot 클러스터 | 대용량 컨테이너 이미지 또는 머신러닝 모델 가중치와 같은 정적 데이터세트 미리 로드 |
| 포드 스냅샷 | 애플리케이션 초기화 | 프로세스 메모리 및 파일 시스템 상태의 저장된 체크포인트에서 새 포드 복제본을 직접 복원합니다. | Cloud Storage의 스냅샷 스토리지에 대해 요금이 청구됩니다. |
GKE Sandbox에서 포드를 실행하는 Standard 및 Autopilot 클러스터 적합한 CPU 및 GPU 머신 유형을 지원합니다 (TPU 없음). |
시작 루틴이 많은 AI 추론 모델 및 애플리케이션의 긴 초기화 건너뛰기 |
| CPU 시작 부스트 (미리보기) | 애플리케이션 초기화 | 포드 시작 중에 CPU 요청 및 한도를 일시적으로 늘린 다음 제자리에서 크기를 조절합니다. | 시작 기간 동안 추가 노드 CPU 용량을 일시적으로 사용합니다. | 수직형 포드 자동 확장이 사용 설정된 Standard 및 Autopilot 클러스터 | Java, Python 또는 Node.js와 같은 런타임의 CPU 바운드 초기화 가속화 |
포드 시작 단계별로 전략 선택
다음 섹션에서는 포드 시작 수명 주기의 각 단계에서 사용할 수 있는 옵션을 설명합니다.
노드 프로비저닝 및 포드 예약 가속화
대기 중인 포드가 기존 노드에 맞지 않으면 새 노드가 부팅될 때까지 기다리는 것이 확장 지연 시간에 가장 큰 영향을 미치는 경우가 많습니다. 다음 전략을 사용하여 이 지연 시간을 줄이거나 없앨 수 있습니다.
- 용량 버퍼를 사용하여 예비 노드 용량을 선언적으로 예약합니다.
- 사전 프로비저닝된 노드를 실행하고 포드를 즉시 예약할 수 있도록 준비 상태를 유지하도록 활성 버퍼 (
buffer.x-k8s.io/active-capacity전략)를 구성합니다. 활성 버퍼는 CPU, GPU, TPU 워크로드를 지원합니다. - 사전 프로비저닝된 CPU 노드를 일시중지된 상태로 유지하도록 대기 버퍼 (
buffer.gke.io/standby-capacity전략)를 구성합니다. 워크로드가 확장되면 GKE는 대기 노드를 약 30~35초 내에 재개하여 유휴 VM 실행의 전체 컴퓨팅 비용을 방지합니다.
- 사전 프로비저닝된 노드를 실행하고 포드를 즉시 예약할 수 있도록 준비 상태를 유지하도록 활성 버퍼 (
- 적합한 Autopilot 워크로드 및 GPU 머신 시리즈에서 자동 최선을 다한 하드웨어 사전 초기화를 위해 빠른 시작 노드를 사용합니다. GKE가 적합한 워크로드에 새 노드를 프로비저닝하면 빠른 시작 노드를 자동으로 사용합니다. 여기에는 호환되는 Autopilot 커스텀 ComputeClass에서 용량 버퍼를 다시 채우기 위해 생성된 노드가 포함됩니다.
- 워크로드에서 Autopilot 포드 기반 결제 모델을 사용하거나 GKE 버전 1.35 이전에서 실행되는 경우 Kubernetes PriorityClass를 사용하여 우선순위가 낮은 자리표시자 포드를 배포합니다. 지원되는 GKE 버전에서 노드 기반 결제를 사용하는 클러스터의 경우 자리표시자 배포 또는 포드 삭제 루프를 관리할 필요가 없으므로 선언적 용량 버퍼를 사용하는 것이 좋습니다.
컨테이너 이미지 가져오기 가속화
스케줄러가 노드에 포드를 배치한 후에는 컨테이너를 시작하기 전에 노드가 컨테이너 이미지를 가져와야 합니다. 다음 전략을 사용하여 이미지 가져오기 지연 시간을 줄일 수 있습니다.
- 이미지 스트리밍을 사용 설정하면 필요한 파일이 네트워크를 통해 스트리밍되는 즉시 컨테이너를 시작할 수 있으며 나머지 이미지는 백그라운드에서 다운로드됩니다. Autopilot 클러스터는 기본적으로 Artifact Registry의 적합한 이미지에 이미지 스트리밍을 사용 설정합니다.
- 보조 부팅 디스크를 구성하여 대용량 컨테이너 기본 레이어 또는 정적 데이터세트를 커스텀 디스크 이미지에 미리 로드합니다. GKE가 노드를 만들면 노드 프로비저닝과 동시에 디스크 이미지에서 인스턴스화된 영구 디스크를 연결합니다.
- 노드 초기화 기간 (
buffer.gke.io/standby-capacity-init-time주석) 동안 대기 버퍼에 컨테이너 이미지를 미리 로드하도록 DaemonSet를 실행합니다. GKE가 대기 노드를 일시중지하기 전에 DaemonSet는 워크로드 이미지를 노드의 부팅 디스크로 가져오므로 노드가 재개될 때 이미지가 이미 캐시됩니다.
애플리케이션 초기화 가속화
노드가 실행되고 컨테이너 이미지가 있더라도 애플리케이션이 프레임워크를 로드하거나, JIT (Just-In-Time) 코드를 컴파일하거나, 모델 가중치를 메모리에 로드하는 데 상당한 시간이 걸릴 수 있습니다. 다음 전략을 사용하여 초기화 시간을 줄일 수 있습니다.
- 포드 스냅샷을 구성하여 GKE Sandbox에서 실행 중인 포드의 메모리 및 파일 시스템 상태의 체크포인트를 캡처합니다. 워크로드가 수평 확장되면 GKE는 Cloud Storage의 스냅샷에서 새 복제본을 복원하므로 포드는 새 상태에서 초기화하는 대신 스냅샷이 생성된 지점부터 실행을 재개합니다.
- VerticalPodAutoscaler에서 CPU 시작 부스트를 구성하여 승인 및 초기화 중에 포드에
추가 CPU를 할당합니다. 포드가
Ready상태에 도달하고 구성된 부스트 기간이 종료되면 GKE는 컨테이너를 다시 시작하지 않고 포드의 CPU 요청을 기준 수준으로 제자리에서 다시 축소합니다.
엔드 투 엔드 최적화를 위한 전략 결합
이러한 전략은 포드 시작 수명 주기의 여러 단계에서 작동하므로 계층화하여 엔드 투 엔드 확장 시간을 최적화할 수 있습니다.
- 작은 활성 용량 버퍼와 더 큰 대기 용량 버퍼를 결합합니다. 갑작스러운 트래픽 급증 시 활성 버퍼는 포드의 초기 버스트를 즉시 흡수합니다. 한편 GKE는 대기 버퍼에서 노드를 약 30~35초 내에 재개하여 활성 버퍼를 보충하고 지속적인 증가를 처리합니다. 백그라운드에서 클러스터 자동 확장 처리는 대기 버퍼를 다시 채우기 위해 새 노드를 프로비저닝하고 일시중지합니다.
- 대기 용량 버퍼의 경우 노드가 재개될 때 대용량 컨테이너 이미지를 다운로드하는 데 시간이 걸리지 않도록 노드가 일시중지되기 전에 이미지 스트리밍을 사용 설정하거나 DaemonSet를 사용하여 컨테이너 이미지를 미리 로드합니다.
- GKE가 사전 프로비저닝된 노드 또는 사전 초기화된 노드에 포드를 예약한 후 포드가 시작 중에 CPU 스로틀링을 방지하거나 저장된 스냅샷에서 직접 복원하도록 용량 버퍼 또는 빠른 시작 노드 위에 CPU 시작 부스트 또는 포드 스냅샷을 계층화합니다.
단일 전략 또는 결합된 전략이 워크로드에 미치는 영향을 측정하려면 Cloud Monitoring에서 포드 시작 지연 시간 분포 및 포드 첫 번째 준비 지연 시간 차트를 보고 Cloud Logging에서 예약 지연 시간 로그를 검사합니다. 자세한 내용은 시작 지연 시간 측정항목 모니터링을 참조하세요.