이 페이지에서는 Google Kubernetes Engine(GKE) 노드에서 사용 가능한 미사용 용량으로 버스팅하도록 포드를 구성하는 방법을 보여줍니다.
버스팅이란 무엇인가요?
버스팅은 노드에서 원래 요청된 것보다 더 많은 컴퓨팅 용량을 일시적으로 사용하는 포드 작업을 설명합니다.
Kubernetes를 사용하면 포드에 대해 CPU 또는 메모리와 같은 특정 리소스 용량을 요청할 수 있습니다. 이러한 요청은 포드 매니페스트에서 설정합니다. Kubernetes 스케줄러는 이러한 리소스 요청을 수용하기에 충분한 용량이 있는 노드에 포드를 배치합니다.
일부 워크로드는 전체 런타임 동안 요청된 리소스를 100% 사용하지 않습니다. 예를 들어 부팅 기간 동안 추가 CPU를 사용하는 워크로드는 일반 작업에 동일한 양의 리소스를 필요로 하지 않을 수 있습니다. 이러한 경우 워크로드의 리소스 한도를 리소스 요청보다 높은 값으로 설정하거나 한도를 설정하지 않은 상태로 둘 수 있습니다. GKE를 사용하면 해당 용량이 사용 가능한 경우 워크로드에서 요청에 지정된 것보다 많은 리소스를 일시적으로 사용할 수 있습니다.
GKE에서 이 프로세스가 작동하는 방식에 대한 자세한 내용은 이 문서의 버스팅 작동 방식을 참조하세요.
포드 버스팅의 이점
버스팅은 포드에 리소스 사용량 급증을 수용하기 위해 짧은 기간 동안만 추가 리소스가 필요한 경우에 유용합니다. 예시 시나리오는 다음과 같습니다.
- 종종 유휴 상태이고 초당 적은 수의 요청을 전송하지만 경우에 따라 트래픽이 급증하는 워크로드 그룹이 있으며, 이러한 요청을 처리하는 데 추가 리소스를 활용할 수 있습니다.
- 워크로드에 정상 작동 중보다 시작 중에 더 많은 리소스가 필요한 경우입니다.
- 프로비저닝하는 컴퓨팅 용량의 사용량을 극대화하려고 합니다.
버스팅을 사용하면 대부분의 런타임 동안 포드에 필요한 리소스만 요청할 수 있으며 필요한 경우 포드가 더 많은 리소스를 소비할 수 있습니다. 버스팅의 이점은 다음과 같습니다.
- 실행 비용 절감: 워크로드의 예상되는 최대 리소스 소비를 요청할 필요가 없습니다. 안정적인 상태 값이 더 낮을 때 요청할 수 있습니다. Autopilot에서는 포드 리소스 요청의 합계에 대한 비용을 지불하므로 실행 비용이 낮아집니다.
- 더 효율적인 리소스 사용: 포드가 사용되지 않은 용량으로 버스팅하므로 유휴 컴퓨팅 용량을 방지합니다. 워크로드는 유료 리소스를 모두 사용할 가능성이 높습니다.
- 향상된 성능: 포드는 필요에 따라 추가 리소스를 사용하여 수신 요청을 처리하는 시간을 줄이거나 확장 이벤트 중에 더 빠르게 부팅할 수 있습니다.
버스팅을 사용하지 말아야 하는 경우
Kubernetes는 요청보다 높은 리소스 한도를 지정하는 포드에 Burstable 서비스 품질(QoS) 클래스를 할당합니다. Burstable QoS 포드는 Kubernetes가 노드에서 리소스를 회수해야 할 때 제거될 가능성이 높습니다. 자세한 내용은 Kubernetes 문서의 버스팅 가능한 QoS 클래스를 참조하세요.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치한 경우
gcloud components update를 실행하여 최신 버전을 가져옵니다.
- 버전 1.29.2-gke.1060000 이상을 실행하는 GKE Autopilot 클러스터 또는 GKE Standard 클러스터 버전이 있는지 확인합니다. 새 클러스터를 만들려면 Autopilot 클러스터 만들기를 참조하세요.
GKE의 버스팅 가용성
다음과 같은 경우 워크로드가 버스팅될 수 있습니다.
| 버스팅 가용성 | |
|---|---|
| GKE Autopilot 모드 | 성능 컴퓨팅 클래스 또는 가속기 컴퓨팅 클래스를 사용하는 포드는 해당 컴퓨팅 클래스를 지원하는 모든 GKE 버전에서 버스팅할 수 있습니다. 다른 컴퓨팅 클래스와 컴퓨팅 클래스를 지정하지 않는 포드의 경우 클러스터가 다음 조건을 모두 충족하는 경우에만 버스팅을 사용할 수 있습니다.
이러한 제한은 Autopilot 클러스터에서 버스팅에 cgroup v2가 필요하기 때문에 발생합니다. cgroup v2는 처음에 버전 1.26 이상으로 생성된 클러스터에서만 사용할 수 있습니다. |
| GKE Standard 모드 | 모든 GKE 버전에서 포드를 버스팅할 수 있습니다. |
처음에 1.26 이전 버전으로 생성되었고 나중에 1.29.2-gke.1060000 이상으로 업그레이드된 Autopilot 클러스터는 버스팅을 지원하지 않습니다. 원래 클러스터 버전을 확인하려면 다음 명령어를 실행합니다.
gcloud container clusters describe CLUSTER_NAME \
--location=LOCATION \
--format="value(initialClusterVersion)"
출력은 GKE 버전 1.26 이상이어야 합니다.
제한사항
- Autopilot 워크로드는 CPU 및 메모리 요청에만 버스팅을 사용할 수 있습니다.
- Autopilot 제어 영역과 노드는 지원되는 GKE 버전을 사용해야 합니다. 최근에 클러스터를 지원되는 버전으로 업그레이드한 경우 버스팅을 사용하기 전에 노드가 해당 버전을 실행하는지 확인합니다.
클러스터에 연결
다음 명령어를 실행합니다.
gcloud container clusters get-credentials CLUSTER_NAME \
--location=LOCATION
다음을 바꿉니다.
CLUSTER_NAME: 기존 클러스터의 이름입니다.LOCATION: 클러스터의 위치
버스팅 가능한 워크로드 배포
다음 매니페스트를
burstable-deployment.yaml로 저장합니다.apiVersion: apps/v1 kind: Deployment metadata: name: helloweb labels: app: hello spec: selector: matchLabels: app: hello tier: web template: metadata: labels: app: hello tier: web spec: nodeSelector: pod-type: "non-critical" tolerations: - key: pod-type operator: Equal value: "non-critical" effect: NoSchedule containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 ports: - containerPort: 8080 resources: requests: cpu: 250m limits: cpu: 350m이 매니페스트에는 버스팅을 사용 설정하기 위한 다음 필드가 있습니다.
resources.requests: 컨테이너가 작동하는 데 필요한 리소스입니다. 이 값을 컨테이너가 안정적인 상태에서 필요한 용량으로 설정합니다.resources.limits: 컨테이너가 사용할 수 있는 최대 리소스 용량입니다. 한도를 요청 수보다 높게 설정하면 노드에서 해당 용량을 사용할 수 있는 경우 포드가 지정된 한도까지 버스팅할 수 있습니다. 이 필드를 생략하면 포드가 노드에서 사용 가능한 버스팅 가능한 용량으로 버스팅할 수 있습니다. 이 용량은 다음과 같이 계산됩니다.- Autopilot 모드: 노드에서 포드의 리소스 요청 합계에 포함된 사용되지 않은 용량입니다.
- Standard 모드: 노드 리소스의 사용되지 않은 용량입니다.
spec.nodeSelector및spec.tolerations: (선택사항) 버스팅 가능한 포드를 실행할 새 노드를 만들도록 GKE에 지시합니다. GKE는 이러한 새 노드에 taint를 적용하여 중요한 워크로드와 같은 다른 포드가 동일한 노드에서 실행되지 않도록 합니다. 자세한 내용은 GKE에서 워크로드 분리 구성을 참조하세요.
워크로드를 배포합니다.
kubectl apply -f burstable-deployment.yaml워크로드를 시작하는 데 몇 분 정도 걸릴 수 있습니다.
포드의 QoS 클래스를 확인합니다.
kubectl describe pod helloweb | grep -m 1 "QoS"출력은 다음과 같습니다.
QoS Class: Burstable
GKE에서 버스팅 가능한 용량
포드 버스팅을 촉진하기 위해 GKE는 클러스터의 각 노드에 대해 버스팅 가능한 용량을 계산합니다. 특정 노드에 대한 계산은 다음과 같습니다.
Autopilot 클러스터: 노드의 실제 리소스 용량에 관계없이 해당 노드에 있는 모든 포드의 리소스 요청 합계입니다. 포드가 종료되면 버스팅 가능한 용량이 해당 포드의 요청에 따라 줄어듭니다. 포드 중 하나가 버스팅해야 할 경우, 실행 중인 포드에서 사용하지 않는 버스팅 가능한 용량 일부를 할당할 수 있습니다.
또한 Autopilot은 버스팅 가능한 용량에 사전 정의된 버퍼를 추가하여 요청 범위를 넘어 버스팅하는 노드의 시스템 포드가 자체 버스팅 가능한 포드에 영향을 주지 않도록 합니다.
Standard 클러스터: 노드 VM에서 사용할 수 있는 총 리소스 용량입니다.
버스팅 권장사항
포드 버스팅에 다음 권장사항을 따릅니다.
- 환경에서 중요한 기능을 제공하는 모든 포드에 대해 리소스 요청을 한도와 동일하게 설정합니다. 이렇게 하면 이러한 포드가
GuaranteedKubernetes 서비스 품질(QoS) 클래스를 받게 됩니다. - Kubernetes가 노드에서 메모리를 회수해야 할 때 제거를 처리할 수 있는 포드에만 메모리 버스팅을 구성해야 합니다.
- 항상 포드가 부팅되기에 충분한 메모리를 요청합니다. 부팅 요구사항을 충족하기 위해 메모리 버스팅에 의존하지 마세요.
- CPU 요청 배수로 지속적으로 버스팅하는 버스팅 가능한 포드가 중요 워크로드를 방해하지 않도록 하려면 워크로드 분리를 사용하여 이러한 포드가 중요한 포드와 함께 배치되지 않도록 합니다.
Autopilot 노드에서 버스팅 가능한 용량 최적화
Autopilot은 시스템 포드 및 DaemonSet를 포함하여 특정 노드의 모든 포드 리소스 요청의 합계로 버스팅 가능한 용량을 계산합니다. 다음과 같은 방법으로 노드에서 버스팅 가능한 용량을 최적화할 수 있습니다. 하지만 버스팅은 상황별이며 보장되지 않습니다.
- 특정 워크로드의 노드에서 버스팅 가능한 용량을 늘리려면 포드 어피니티를 사용하여 특정 포드를 동일한 노드에 함께 배치합니다.
- 특정 버스팅 가능한 용량을 모든 노드에서 항상 사용할 수 있도록 하려면 클러스터의 모든 노드에서 실행할 DaemonSet을 만듭니다.
버스팅의 작동 방식 예시
이 섹션에서는 다음과 같은 버스팅 가능한 포드가 있는 배포 예시를 사용하여 GKE Autopilot 클러스터에서 포드 버스팅이 작동하는 방식을 보여줍니다.
- 포드 1은 250m CPU를 요청하고 CPU 한도는 없습니다. 포드 1은 100m CPU를 사용하여 실행합니다.
- 포드 2는 200m CPU를 요청하고 CPU 한도는 250m입니다. 포드 2는 100m CPU를 사용하여 실행합니다.
두 포드 모두 동일한 노드에서 실행됩니다. 노드의 총 버스팅 가능 용량은 450m CPU(리소스 요청의 합계)입니다. 각 포드는 100m CPU만 사용하여 실행됩니다. 즉, 노드의 남은 사용 가능한 버스팅 가능 용량은 250m입니다.
트래픽 급증이 발생하는 다음 상황을 가정해 보겠습니다.
- 포드 1에는 추가 300m CPU가 필요합니다. 사용 가능한 버스팅 가능 용량인 250m CPU까지 버스팅하여 사용할 수 있습니다. 노드에는 사용 가능한 버스팅 가능 용량이 더 이상 없습니다.
- 포드 2에는 150m CPU가 추가로 필요하며, 버스팅하여 150m CPU를 추가로 사용할 수 있습니다. 그러면 노드에 사용 가능한 버스팅 가능 용량 중 100m CPU가 남아 있습니다.
- 포드 2에는 200m CPU가 추가로 필요합니다. 150m CPU를 버스팅하여 사용할 수 있으므로 포드 2의 총 사용량은 250m CPU가 됩니다. 포드 2는 250m CPU 한도를 가지며 이 한도를 초과하여 버스팅할 수 없습니다.
GKE에서 버스팅 가능한 용량을 초과하는 포드를 처리하는 방법
버스팅 가능한 포드가 노드의 버스팅 가능한 용량보다 많은 리소스를 사용하려고 하면 GKE는 다음 작업을 수행합니다.
- CPU: CPU 사용량이 버스팅 가능한 용량을 초과하면 GKE는 일부 컨테이너의 CPU 사용량을 제한하여 노드의 모든 컨테이너가 요청한 CPU를 가져옵니다.
- 메모리: 메모리 사용량이 버스팅 가능한 용량을 초과하면 GKE가 컨테이너를 종료하여 노드에서 메모리를 회수합니다. GKE는 QoS가 낮은 포드에서 리소스 집약적인 컨테이너를 종료하는 것부터 시작합니다.
항상 일반 포드 작업에 충분한 메모리를 요청하는 것이 좋습니다. 컨테이너가 정상적으로 작동하기 위해 메모리 버스팅에 대한 종속 항목이 있는 경우 해당 메모리를 사용할 수 없으면 반복적으로 비정상 종료될 수 있습니다.
예비 용량 프로비저닝으로 포드 버스팅 사용
GKE를 사용하면 유휴 포드를 배포하여 온라인 스토어 플래시 세일과 같이 트래픽이 높은 향후 이벤트 중에 빠르게 포드를 확장할 수 있도록 추가 컴퓨팅 용량을 예약할 수 있습니다. 동일한 노드의 다른 포드는 사용되지 않은 예약된 용량으로 버스팅할 수 있으므로, 트래픽이 높은 이벤트가 발생하는 동안 유휴 상태가 되지 않습니다. 다양한 Kubernetes 메커니즘을 사용하여 이 용량을 예약할 수 있습니다. 예를 들어 PriorityClass가 낮은 포드를 배포할 수 있습니다. 자세한 내용은 신속한 포드 확장을 위해 추가 컴퓨팅 용량 프로비저닝을 참조하세요.
GKE Standard 클러스터의 포드 버스팅
GKE Standard 클러스터는 또한 한도를 요청보다 높게 설정하거나 한도를 생략하여 포드 버스팅을 지원합니다. 하지만 Standard 클러스터에서는 버스팅을 지원하기 위해 적절한 리소스 용량으로 노드 풀을 만들고 구성해야 합니다. 기본 Compute Engine VM에 대한 비용을 지불하기 때문에 Standard 클러스터에서 버스팅 가능한 포드의 잠재적인 비용 절감 효과를 얻기 위해서는 더 신중한 노드 계획과 포드 빈 패킹이 필요합니다.
Standard 클러스터에서는 다음을 고려하세요.
Kubernetes 제거 또는 CPU 제한을 트리거하는 최대 리소스 소비 한도는 노드에서 할당 가능한 리소스 용량입니다. 이 값을 결정하려면 GKE Standard 노드 크기 계획을 참조하세요.
한도를 지정하지 않으면 GKE가 리소스 소비를 자동으로 제한하지 않으므로 Standard 클러스터의 노드 리소스 사용량이 Kubernetes 제거 기준점에 도달할 가능성이 높습니다. 따라서 메모리로 버스팅하는 포드는 Kubernetes 노드 압력 제거에 의해 종료될 가능성이 높습니다.