GKE에서 포드 버스팅 구성

이 페이지에서는 Google Kubernetes Engine(GKE) 노드에서 사용 가능한 미사용 용량으로 버스팅하도록 포드를 구성하는 방법을 보여줍니다.

버스팅이란 무엇인가요?

버스팅은 포드가 노드에서 원래 요청한 것보다 더 많은 컴퓨팅 용량을 일시적으로 사용하는 작업을 설명합니다.

Kubernetes를 사용하면 포드에 대해 CPU 또는 메모리와 같은 특정 리소스 용량을 요청할 수 있습니다. 이러한 요청은 포드 매니페스트에서 설정합니다. Kubernetes 스케줄러는 이러한 리소스 요청을 수용할 수 있는 충분한 용량이 있는 노드에 포드를 배치합니다.

일부 워크로드는 전체 실행 시간 동안 요청된 리소스의 100%를 사용하지 않습니다. 예를 들어 부팅 기간 동안 추가 CPU를 소비하는 워크로드의 경우 정상 작동에 동일한 양의 리소스가 필요하지 않을 수 있습니다. 이러한 경우 워크로드의 리소스 한도를 리소스 요청보다 높은 값으로 설정하거나 한도를 설정하지 않은 상태로 둘 수 있습니다. GKE를 사용하면 해당 용량이 사용 가능한 경우 워크로드에서 요청에 지정된 것보다 많은 리소스를 일시적으로 사용할 수 있습니다.

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.30.2-gke.1394000 이상을 실행하는 GKE Autopilot 클러스터 또는 GKE Standard 클러스터의 모든 버전이 있는지 확인합니다. 새 클러스터를 만들려면 Autopilot 클러스터 만들기를 참조하세요.

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는 시간 경과에 따라 컨트롤 플레인 버전과 일치하도록 워커 노드를 업그레이드합니다. 버스팅을 사용 설정하려면 컨트롤 플레인을 다시 시작해야 하며 모든 노드가 지원되는 버전을 실행한 후에 진행되어야 합니다. 확장, 업그레이드 또는 유지보수와 같은 작업 중에는 컨트롤 플레인이 일주일에 한 번 정도 자동으로 다시 시작됩니다.

  컨트롤 플레인 재시작을 수동으로 트리거하려면 다음을 수행합니다.

  1. 모든 노드에서 버전 1.30.2-gke.1394000 이상을 실행하는지 확인합니다.

     kubectl get nodes
     

     출력은 다음과 비슷합니다.

     NAME                                          STATUS   ROLES    AGE     VERSION
     gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
     

     출력의 모든 노드는 필수 버전 이상을 표시해야 합니다.

  2. 클러스터에서 이미 사용 중인 버전과 동일한 버전으로 컨트롤 플레인 업그레이드를 수동으로 시작합니다. 자세한 내용은 컨트롤 플레인 수동 업그레이드를 참조하세요.

클러스터에 연결

다음 명령어를 실행합니다.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

다음을 바꿉니다.

• CLUSTER_NAME: 기존 클러스터의 이름입니다.
• LOCATION: 클러스터의 위치

버스팅 가능한 워크로드 배포

1. 다음 매니페스트를 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:
         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: (선택사항) pod-type: "non-critical"과 같은 커스텀 라벨을 사용하여 이러한 필드를 추가하여 GKE에 버스팅 가능한 포드를 실행할 새 노드를 만들도록 지시합니다. GKE는 이러한 새 노드에 taint를 적용하여 중요한 워크로드와 같은 다른 포드가 동일한 노드에서 실행되지 않도록 합니다. Autopilot은 워크로드 분리를 사용하는 포드에 더 높은 최소 리소스 요청을 적용합니다. 자세한 내용은 GKE에서 워크로드 분리 구성 및 Autopilot에서 리소스 요청을 참조하세요.

2. 워크로드를 배포합니다.

   kubectl apply -f burstable-deployment.yaml
   

   워크로드가 시작될 때까지 몇 분 정도 걸릴 수 있습니다.

3. 포드의 QoS 클래스를 확인합니다.

   kubectl describe pod helloweb | grep -m 1 "QoS"
   

   출력은 다음과 같습니다.

   QoS Class: Burstable
   

GKE에서 버스팅 가능한 용량

포드 버스팅을 용이하게 하기 위해 GKE는 클러스터의 각 노드에 대해 버스팅 가능한 용량을 계산합니다. 특정 노드의 계산은 다음과 같습니다.

• Autopilot 클러스터:

  • 가속기를 요청하거나 특정 머신 시리즈를 요청하는 포드: 노드 할당 가능 리소스 용량으로, 워크로드 사용에 사용할 수 있는 용량입니다. 자세한 내용은 노드 할당 가능 리소스를 참조하세요.
  • 기타 모든 포드: 노드의 실제 리소스 용량과 관계없이 해당 노드의 모든 포드의 리소스 요청 합계입니다. 포드가 종료되면 버스팅 가능 용량이 해당 포드의 요청만큼 감소합니다. 포드 중 하나가 버스팅해야 할 경우, 실행 중인 포드에서 사용하지 않는 버스팅 가능한 용량 일부를 할당할 수 있습니다.

  또한 Autopilot은 버스팅 가능 용량에 사전 정의된 버퍼를 추가하므로 요청을 초과하여 버스팅되는 노드의 시스템 포드가 자체 버스팅 가능 포드에 영향을 미치지 않습니다.

• Standard 클러스터: 노드 할당 가능 리소스 용량으로, 워크로드 사용에 사용할 수 있는 용량입니다. 자세한 내용은 노드 할당 가능 리소스를 참조하세요.

버스팅 권장사항

포드 버스팅 시 다음 권장사항을 따르세요.

• 환경에서 중요한 기능을 제공하는 모든 포드에 대해 리소스 요청을 한도와 동일하게 설정합니다. 이렇게 하면 이러한 포드가 Guaranteed Kubernetes 서비스 품질(QoS) 클래스를 받게 됩니다.
• Kubernetes가 노드의 메모리를 회수해야 할 때 제거를 처리할 수 있는 포드에서만 메모리 버스팅을 구성해야 합니다.
• 항상 포드가 부팅되기에 충분한 메모리를 요청합니다. 부팅 요구사항을 충족하기 위해 메모리 버스팅을 사용하지 마세요.
• CPU 요청 배수로 지속적으로 버스팅하는 버스팅 가능한 포드가 중요 워크로드를 방해하지 않도록 하려면 워크로드 분리를 사용하여 이러한 포드가 중요한 포드와 함께 배치되지 않도록 합니다.

Autopilot 노드에서 버스팅 가능한 용량 최적화

Autopilot은 시스템 포드 및 DaemonSet을 포함하여 특정 노드의 모든 포드의 리소스 요청 합계로 버스팅 가능 용량을 계산합니다. 다음과 같은 방법으로 노드에서 버스팅 가능한 용량을 최적화할 수 있습니다. 그러나 버스팅은 기회주의적이며 보장되지 않습니다.

• 특정 워크로드의 노드에서 버스팅 가능한 용량을 늘리려면 포드 어피니티를 사용하여 특정 포드를 동일한 노드에 함께 배치합니다.
• 특정 버스팅 가능한 용량을 모든 노드에서 항상 사용할 수 있도록 하려면 클러스터의 모든 노드에서 실행할 DaemonSets을 만듭니다.

버스팅 작동 방식의 예시

이 섹션에서는 다음과 같이 버스팅 가능한 포드가 있는 배포 예시를 사용하여 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의 CPU 한도는 250m이며 이 한도를 초과하여 버스팅할 수 없습니다.

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 노드 압력 제거에 의해 종료될 가능성이 더 큽니다.

다음 단계

• 신속한 포드 확장을 위해 추가 컴퓨팅 용량 프로비저닝
• 규모에 맞게 GKE Standard 워크로드 크기 조정