Cloud Monitoring을 사용하여 비용 최적화를 위해 GKE 클러스터 모니터링

이 튜토리얼에서는 리소스 사용률 최적화를 위해 Google Kubernetes Engine(GKE) 클러스터를 모니터링하는 방법을 설명합니다. 이러한 종류의 최적화는 앱의 안정성 및 성능을 훼손하지 않으면서 리소스 소비를 줄여서 비용을 줄이고자 하기 때문에 일반적으로 복잡한 태스크입니다. 이 튜토리얼에서는 과다 프로비저닝이 발생하는 가장 일반적인 원인에 대해 대시보드 및 알림 정책을 설정하기 위한 프로세스를 안내합니다. 이 튜토리얼에서는 또한 앱을 안정적으로 실행하고 비용에 최적화할 수 있도록 리소스 권장사항을 제공합니다.

이 튜토리얼은 낮은 비용, 높은 성능, 높은 앱 안정성 목표를 달성하기 위해 GKE 클러스터 및 앱을 최적화하려는 개발자 및 운영자를 대상으로 합니다. 이 튜토리얼에서는 사용자가 Docker, Kubernetes, Kubernetes CronJobs, GKE, Cloud Monitoring, Linux에 익숙하다고 가정합니다.

개요

비용 최적화는 일반적으로 비용 감소에 집중하는 일회용 프로세스로 잘못 해석되는 경우가 많습니다. 하지만 Gartner에서 정의한 대로, 비용 최적화는 비즈니스 가치도 극대화해야 하는 지속적인 과정입니다. 이러한 과정을 Kubernetes 세계에 맞게 인스턴스화할 때는 다른 특성들도 중요합니다.

비용 절감, 성능 목표 달성, 안정성 확보, 비즈니스 성과 달성 등 4가지 목표의 조화로운 균형을 맞춰야 합니다.

이 다이어그램에 나와 있는 것처럼 Kubernetes의 비용 최적화를 위해서는 비용 절감, 성능 목표 달성, 안정성 확보, 비즈니스 성과 극대화라는 4가지 목표의 조화로운 균형을 맞춰야 합니다. 즉, 영향을 제대로 파악하고 고려하지 않는 한 비용 절감은 사용자 환경 또는 비즈니스 성능 저하를 야기해서는 안 됩니다.

Google Cloud는 이러한 목표의 균형 조정에 필요한 도구들을 제공합니다. 하지만 자신의 워크로드 해결을 위해 Kubernetes와 같은 클라우드 기반 솔루션을 수용하는 모든 팀이 성능 및 안정성 목표를 달성하기 위한 전문 기술을 갖고 있지는 않습니다. 이러한 팀은 비즈니스 영향을 완화하기 위해 자신의 환경을 과다 프로비저닝하는 방법을 해결책으로 선택하는 경우도 많습니다.

과다 프로비저닝은 단기적인 구제 조치를 제공할 수 있지만 비용이 상승합니다. 따라서 지속적인 비용 최적화 프로세스의 일부로만 주의해서 사용해야 합니다. 다음 이미지는 이러한 비용 최적화 여정을 시작하는 팀에서 발견되는 4가지 주요 문제를 보여줍니다.

팀에서 발견되는 4가지 주요 문제는 문화, 적재, 앱 크기 조정, 피크타임 축소 등입니다.

  • 첫 번째 문제는 문화입니다. 퍼블릭 클라우드를 도입하는 많은 팀이 사용한 만큼만 지불하는 결제 방식에 익숙하지 않으며, 앱(이 경우 Kubernetes)이 실행되는 환경을 완전히 파악하지 못하는 경우가 많습니다. 최근에 많은 관심을 끌고 있는 FinOps 운동은 이러한 문화를 발전시키는 데 매우 지대한 영향을 미칩니다. FinOps 권장사항 중 하나는 팀에 지출 및 비즈니스 영향력에 대한 실시간 정보를 제공하는 것입니다. 이와 같이 사소한 것들이 회사의 문화에 상당한 영향을 미쳐 보다 균형잡힌 비용 최적화 공식이 도출될 수 있습니다.

  • 두 번째 문제는 적재입니다. 적재는 앱을 GKE 노드에 포함시키는 기능입니다. 앱을 노드에 더 효과적으로 포함할수록 더 많은 것을 절약할 수 있습니다.

  • 세 번째 문제는 적절한 앱 크기 조정입니다. 적절한 크기 조절은 클러스터에 배포되는 객체에 대해 적절한 리소스 요청 및 워크로드 자동 확장 목표를 구성하는 기능입니다. Pod에 적합한 리소스를 더 정밀하게 설정할수록 앱이 실행되는 안정성이 더 향상되고, 대부분의 경우 클러스터에서 더 많은 공간을 확보할 수 있습니다.

  • 마지막으로 사용량이 적을 때 클러스터를 축소하지 않는 것입니다. 수요가 적은 기간(예: 야간)에 비용을 절약하려면 클러스터를 실제 수요에 따라 축소하는 것이 좋습니다. 하지만 클러스터 자동 확장 처리(CA)를 차단하는 워크로드 또는 클러스터 구성으로 인해 경우에 따라 축소가 예상대로 수행되지 않을 수 있습니다.

환경을 효과적으로 최적화하기 위해서는 이러한 문제를 지속적으로 해결해야 합니다. 실용적인 항목에 집중하기 위해 이 튜토리얼의 나머지 부분에서는 문화적인 문제를 생략하고, GKE 클러스터에서 Cloud Monitoring을 사용하여 적재 및 적절한 앱 크기 조정을 모니터링하는 방법을 설명합니다. 수요가 낮은 기간 동안 클러스터 비용 최적화에 대한 자세한 내용은 사용량이 낮은 기간 동안 GKE 클러스터 축소로 비용 감소를 참조하세요.

목표

  • GKE 클러스터를 만듭니다.
  • 예시 앱을 배포합니다.
  • 필요한 측정항목을 Cloud Monitoring으로 내보내서 구성요소를 설정합니다.
  • 리소스 사용률 및 추천을 모니터링하기 위한 대시보드를 동적으로 생성합니다.
  • 프로비저닝이 과도하거나 부족한 경우에 대한 알림 정책을 동적으로 생성합니다.

비용

이 가이드에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

시작하기 전에

  1. Google Cloud Console에서 프로젝트 선택기 페이지로 이동합니다.

    프로젝트 선택기로 이동

  2. Google Cloud 프로젝트를 선택하거나 만듭니다.

  3. Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.

이 가이드를 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않게 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

환경 준비

  1. Cloud Console에서 Cloud Shell을 엽니다. 이 튜토리얼에서는 Cloud Shell에서 명령어를 실행합니다.

    Cloud Console 하단에서 Cloud Shell 세션이 열리고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 gcloud 명령줄 도구가 포함되고 Cloud SDK가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.

  2. Cloud Shell에서 Cloud 프로젝트 ID와 이메일 주소를 구성하고 Compute Engine, GKE, Cloud Monitoring API를 사용 설정합니다.

    PROJECT_ID=YOUR_PROJECT_ID
    ALERT_EMAIL=YOUR_EMAIL_ADDRESS
    CLUSTER=gke-cost-optimization-monitoring
    gcloud config set project $PROJECT_ID
    
    gcloud services enable \
        compute.googleapis.com \
        container.googleapis.com \
        monitoring.googleapis.com
    
    gcloud config set compute/region us-central1
    gcloud config set compute/zone us-central1-f
    

    다음을 바꿉니다.

    • YOUR_PROJECT_ID: 이 튜토리얼에서 사용하는 프로젝트의 Cloud 프로젝트 ID입니다.
    • YOUR_EMAIL_ADDRESS: 클러스터에서 과도하거나 부족한 프로비저닝 기회가 발견되면 알림을 받을 이메일 주소입니다.

    다른 리전 및 영역을 선택할 수 있습니다.

  3. gke-cost-optimization-monitoring GitHub 저장소를 클론합니다.

    git clone https://github.com/GoogleCloudPlatform/gke-cost-optimization-monitoring
    cd gke-cost-optimization-monitoring
    

    이 저장소의 코드는 다음 폴더에 구성됩니다.

    • 루트: CronJob이 커스텀 측정항목을 Cloud Monitoring으로 내보내기 위해 사용하는 main.goDockerfile 파일이 포함됩니다.
    • api/: Kubernetes 및 Monitoring 객체를 조작하기 위한 golang API를 포함합니다.
    • k8s/templates/: 클러스터에서 CronJob, VPA, 수평형 Pod 자동 확장 처리(HPA) 객체를 만드는 데 사용되는 템플릿이 포함됩니다.
    • monitoring/dashboards/templates/: 적재 및 앱 크기 조정 대시보드를 동적으로 만드는 데 사용되는 템플릿이 포함되어 있습니다.
    • monitoring/policies/templates/: 적재 및 앱 크기 조정 알림 정책을 동적으로 만드는 데 사용되는 템플릿이 포함되어 있습니다.

GKE 클러스터 만들기

  1. Cloud Shell에서 GKE 클러스터를 만듭니다.

    gcloud container clusters create $CLUSTER \
        --enable-ip-alias \
        --release-channel=stable \
        --machine-type=e2-standard-2 \
        --enable-autoscaling --min-nodes=1 --max-nodes=5 \
        --enable-vertical-pod-autoscaling
    

    이 설정은 프로덕션 구성이 아니지만, 이 튜토리얼에 적합합니다. 이 설정에서는 VPA를 사용 설정하여 적절한 앱 크기 조정의 기초를 추출합니다.

예시 앱 배포

  1. Online Boutique 앱을 배포합니다.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
    

    Online Boutique 앱은 여러 컴퓨터 언어로 작성된 많은 마이크로서비스로 구성된 데모 소매업 웹 스토어입니다.

  2. 더 사실적인 환경을 시뮬레이션하기 위해 온라인 부티크 배포를 위한 HPA를 만듭니다.

    kubectl get deployments --field-selector='metadata.name!=adservice,metadata.name!=cartservice' -o go-template-file=k8s/templates/cpu-hpa.gtpl | kubectl apply -f -
    
    kubectl get deployments --field-selector='metadata.name==cartservice' -o go-template-file=k8s/templates/memory-hpa.gtpl | kubectl apply -f -
    

    대부분의 온라인 부티크 배포에는 CPU 대상 HPA 객체를 만들고 cartservice 배포용 메모리 대상 HPA를 만들지만 adservice의 HPA 구성은 하지 않습니다. 이 설정은 다음 섹션에 나온 대로 다양한 대시보드 시각화를 보여줍니다.

Cloud Monitoring으로 측정항목을 내보내기 위한 구성요소 설정

  1. 커스텀 측정항목 내보내기 코드를 빌드하고 푸시합니다.

    docker build . -t gcr.io/$PROJECT_ID/metrics-exporter
    docker push gcr.io/$PROJECT_ID/metrics-exporter
    

    이 코드는 클러스터에서 VPA 및 HPA 객체를 쿼리하고 해당 데이터를 기반으로 커스텀 측정항목을 Cloud Monitoring으로 전송합니다. 이 구현은 VPA 목표 권장사항 및 HPA 리소스 목표 사용률(백분율 형태로 정의된 CPU 및 메모리)을 내보냅니다.

  2. CronJob을 배포하여 매분 워크로드 자동 확장 처리 측정항목을 Cloud Monitoring으로 전송합니다.

    sed "s/PROJECT_ID/$PROJECT_ID/g" k8s/templates/metrics-exporter.yaml > k8s/metrics-exporter.yaml
    kubectl create ns custom-metrics
    kubectl apply -f k8s/metrics-exporter.yaml
    

    이 가이드를 이전에 만든 클러스터 대신 자체 클러스터에서 실행하고 워크로드 아이덴티티가 사용 설정된 경우 워크로드 아이덴티티 사용 단계를 수행하면 Cloud Monitoring으로 측정항목을 내보낼 수 있습니다.

  3. 클러스터에서 모든 Deployments, StatefulSets, DaemonSets 객체에 대해 VPA를 만듭니다.

    rm k8s/vpas.yaml 2> /dev/null
    ALL_NAMESPACES=$(kubectl get namespaces -o jsonpath={.items[*].metadata.name})
    for NAMESPACE in $ALL_NAMESPACES
    do
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=k8s/templates/vpa.gtpl >> k8s/vpas.yaml
    done
    kubectl apply -f k8s/vpas.yaml
    

    앞의 스니펫은 시스템 객체를 포함하여 모든 네임스페이스의 모든 객체에 대해 Off 모드로 VPA를 만듭니다. 이 방법은 클러스터 수준 및 노드 풀 수준에서 권장사항에 대해 보다 정확한 뷰를 제공합니다. 하지만 측정항목 서버 서비스의 초과 로드를 방지하기 위해서는 수백 개의 앱이 배포된 큰 클러스터에서와 같이 앞의 스크립트를 실행하지 않는 것이 좋습니다. 큰 클러스터 시나리오의 경우 비용 최적화를 원하는 네임스페이스에 대해서만 앞의 스크립트를 실행하는 것이 좋습니다. 이 시나리오에서는 클러스터 및 노드 풀 수준의 권장사항이 정확하지 않으므로 이를 무시하거나 삭제하세요.

리소스 사용률 및 추천 모니터링을 위한 대시보드 설정

  1. Cloud Console에서 Monitoring 페이지로 이동합니다.

    모니터링으로 이동

  2. 프로젝트를 만듭니다.

    1. 작업공간에 프로젝트 추가 페이지에서 Cloud 프로젝트를 선택합니다.
    2. Add(추가)를 클릭합니다.

    작업공간을 만드는 데 몇 분 정도 걸릴 수 있습니다.

  3. Cloud Shell에서 비용 최적화를 위해 대시보드를 동적으로 생성합니다.

    YOUR_NAMESPACES=$( echo $ALL_NAMESPACES| sed 's/[a-zA-Z0-9_.-]*-system//g; s/gke-[a-zA-Z0-9_.-]*//g; s/kube-public//g; s/kube-node-lease//g; s/custom-metrics//g')
    for NAMESPACE in $YOUR_NAMESPACES
    do
        GTPL_FILE='./monitoring/dashboards/templates/app-rightsizing.gtpl'
        OUTPUT_FILE="./monitoring/dashboards/app-rightsizing-$CLUSTER-$NAMESPACE.yaml"
    
        kubectl get deployments,statefulset,daemonset -n $NAMESPACE -o go-template-file=$GTPL_FILE > $OUTPUT_FILE
    
        sed -i.bkp "s/CLUSTER_TO_REPLACE/$CLUSTER/g" $OUTPUT_FILE
        sed -i.bkp "s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $OUTPUT_FILE
    
        replace=""
        i=0
        while : ; do
            if grep -q "Y_POS_TO_REPLACE_$i" $OUTPUT_FILE
            then
                ((yPos=12 + (4 * $i)))
                replace="s/Y_POS_TO_REPLACE_$i/$yPos/g; ${replace}"
                ((i=i+1))
            else
                break
            fi
        done
        eval "sed -i.bkp '$replace' $OUTPUT_FILE"
        rm "$OUTPUT_FILE.bkp"
    done
    
    sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g" ./monitoring/dashboards/templates/binpacking.yaml > ./monitoring/dashboards/binpacking.yaml
    

    적재 대시보드를 만들기 전 이 스크립트는 또한 시스템 네임스페이스를 제외하고 클러스터에서 각 네임스페이스에 대해 적절한 앱 크기 조정 대시보드를 생성합니다. Online Boutique가 해당 네임스페이스에 완전히 배포되기 때문에 이 튜토리얼에서 스크립트는 default 네임스페이스에 대해 하나의 대시보드만 생성합니다. 하지만 고유 GKE 클러스터에서 동일한 스크립트를 실행하면 각 네임스페이스에 대해 하나의 대시보드가 생성됩니다.

  4. 생성된 대시보드를 Cloud Monitoring으로 가져옵니다.

    for filename in monitoring/dashboards/*.yaml; do
        echo "Creating dashboard policy based on file: $filename"
        gcloud monitoring dashboards create \
            --config-from-file=$filename
    done
    

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

    Creating dashboard policy based on file: monitoring/dashboards/app-rightsizing-gke-cost-optimization-monitoring-default.yaml
    Created [9c1a6cb6-3424-44a8-b824-f2ec959f6588].
    Creating dashboard policy based on file: monitoring/dashboards/binpacking.yaml
    Created [97f6349d-4880-478d-9da8-ca3c8a433093].
    

앱 크기 조정 대시보드 보기

  1. Monitoring 대시보드 페이지로 이동합니다.

    대시보드 페이지로 이동

  2. GKE - 앱 크기 조정(gke-cost-optimization-monitoring:default) 대시보드를 클릭합니다.

이 섹션의 나머지 부분에서는 대시보드에 표시된 차트를 보고 해석하는 방법을 설명합니다.

설치된 데모 환경에는 지속적인 시뮬레이션된 로드가 포함되어 있습니다. 즉, 시간이 지나도 차트에 큰 변화가 표시되지 않습니다. 하지만 고유 클러스터에서 동일한 튜토리얼을 실행할 경우에는 수직 확장 및 축소의 동적 형태를 확인하고 하루 및 한 주 동안 여러 로드 배포가 어떻게 발생하는지 확인하기 위해 몇 시간(이상적으로는 24시간 이상) 정도 기다려야 합니다.

차트의 첫 번째 행에는 네임스페이스 과다 프로비저닝이 표시되고, 두 번째 행에는 과다 프로비저닝된 상위 5개 앱, 세 번째 행에는 과소 프로비저닝된 상위 앱 5개가 표시됩니다.

위의 차트에 표시된 것처럼 대시보드의 처음 세 행은 다음 집계 네임스페이스 정보를 요약합니다.

  • 첫 번째 행: CPU 및 메모리: 네임스페이스 과다 프로비저닝. 지정된 네임스페이스에 있는 앱의 비용 최적화 방식을 간략하게 설명합니다.
  • 두 번째 행: CPU 및 메모리: 상위 5개 과다 프로비저닝된 앱. 네임스페이스 향상을 위한 방법을 찾을 때 먼저 작업해야 하는 앱을 찾는 위치를 보여줍니다.
  • 세 번째 행: CPU 및 메모리: 상위 5개 과소 프로비저닝된 앱. 두 번째 행과 비슷하게, 이 행은 특별한 주의가 필요한 앱을 보여줍니다. 하지만 이 시나리오에서는 비용 절약이 아닌 클러스터에서 앱을 매끄럽게 실행하는 데 집중합니다. '사용 가능한 데이터 없음'이 표시되면 발견된 기회가 없음을 의미합니다.

다음 차트에서는 CPU, 메모리, 복제본과 관련하여 앱별로 대시보드에 제공되는 세부정보를 보여줍니다. 각 행은 지정된 네임스페이스의 앱을 나타냅니다. 이 정보는 개발자가 앱에 필요하다고 말하는 것(requested_<cores|memory> 줄)을 앱에서 실제로 사용되는 것(used_<cores|memory> 줄)과 비교하여 적절한 앱 크기를 조정하는 데 유용합니다.

앱 크기 조정 대시보드에서 CPU, 메모리, 복제본의 세부정보를 표시합니다.

다음 섹션에서는 위 차트에 나온 세 행에 대해 설명합니다 .

첫 번째 행: CPU(p/ Pod)

이러한 차트에서는 워크로드 구성 방식에 따라 앱에 적합한 크기를 결정하는 데 도움이 되는 여러 가지 힌트를 보여줍니다.

  • VPA CPU 권장사항(vpa_recommended_cores): 이 힌트는 앱에 HPA가 구성되지 않았을 때(대시보드의 CPU: adservice (p/Pod) 차트) 또는 HPA가 CPU를 제외한 모든 측정항목으로 구성되었을 때(대시보드의 CPU: cartservice (p/Pod) 차트) 표시됩니다. 이러한 힌트가 표시되면 정적으로 적용하는 것이 좋습니다. 또는 차트 기록을 보는 데 익숙하다면 VPA를 사용 설정(Initial 또는 Auto 모드)하세요.

  • HPA CPU 목표 사용률(hpa_target_utilization): 이 힌트는 앱이 CPU 사용률(다른 모든 CPU 차트)을 기반으로 HPA로 구성될 때 표시됩니다. 이 시나리오에서는 다음을 수행하는 것이 좋습니다.

    • 과다 프로비저닝 사례: 실제 사용률(used_cores)이 일관되게 HPA 목표(hpa_target_utilization)보다 낮으면 지정된 HPA 값(minReplicas 값)에서 배포가 실행됩니다. 이 시나리오에서 권장되는 작업은 minReplicas 값을 줄이는 것입니다.
    • 과소 프로비저닝 사례: 실제 사용률(used_cores )이 일관되게 HPA 대상(hpa_target_utilization)보다 높으면 지정된 HPA 값(maxReplicas 값)에서 배포가 실행됩니다. 이때 제안되는 작업은 Pod 값을 더 크게 만들기 위해 maxReplicas 값을 늘리거나 요청 리소스를 늘리는 것입니다.
    • 수직 확장 및 축소 이해: CPU와 HPA가 Pod 수직 확장 및 축소를 실행하는 시점을 파악하려면 CPUReplicas 차트를 확인하세요.
    • HPA 목표 사용률 세부 조정: 환경에 변경사항을 적용하기 전에 권장사항을 검토하세요.
    • 또한 VPA 및 HPA를 동일한 워크로드에서 CPU 또는 메모리와 혼합하는 것을 방지하는 것이 중요합니다. 이 경우 MPA를 사용합니다.

두 번째 행: 메모리(p/ Pod)

CPU 행과 마찬가지로 워크로드가 구성되는 방법에 따라 다음 차트에는 앱에 적합한 크기를 결정하는 데 도움이 되는 다양한 힌트가 표시됩니다.

  • VPA 메모리 권장사항(vpa_recommended_bytes): 이 힌트는 애플리케이션에 HPA가 구성되지 않은 경우(대시보드의 Mem: adservice (p/Pod) 차트) 또는 HPA가 메모리 이외의 측정항목으로 구성되었을 때(예: Men: emailservice (p/Pod)) 표시됩니다. 리소스 낭비 및 '메모리 부족'(OOMKill) 이벤트를 피할 수 있도록 권장사항을 모두 적용하거나 차트 기록을 보고 적절한 경우 Initial 또는 Auto 모드로 VPA를 사용 설정합니다.

  • HPA 메모리 대상 사용률 (hpa_target_utilization): 이 힌트는 앱이 메모리 사용률에 따라 HPA로 구성되었을 때 표시됩니다(대시보드의 Mem: cartservice (p/Pod) 차트). 이 시나리오에서는 다음을 수행하는 것이 좋습니다.

    • 과다 프로비저닝 사례: 실제 사용률(used_bytes)이 HPA 목표(hpa_target_utilization)보다 일관되게 낮으면 배포가 HPA minReplicas 값에 지정된 값으로 실행됩니다. 이 시나리오에서 권장되는 작업은 minReplicas 값을 줄이는 것입니다.
    • 과소 프로비저닝 사례: 실제 사용률(used_bytes )이 일관되게 HPA 대상(hpa_target_utilization)보다 높으면 지정된 HPA 값(maxReplicas 값)에서 배포가 실행됩니다. 이때 제안되는 작업은 Pod 값을 더 크게 만들기 위해 maxReplicas 값을 늘리거나 요청 리소스를 늘리는 것입니다.
    • 수직 확장 및 축소 이해: MemReplicas 차트를 보면 메모리에서 HPA가 Pod 수직 확장 및 축소를 트리거하는 시점을 파악할 수 있습니다.
    • HPA 목표 사용률 세부 조정: 환경에 변경사항을 적용하기 전에 권장사항을 검토하세요.
    • 또한 VPA 및 HPA를 동일한 워크로드에서 CPU 또는 메모리와 혼합하는 것을 방지하는 것이 중요합니다. 이 경우 MPA를 사용합니다.

세 번째 행: 복제본

이 행의 차트는 지정된 앱에 있는 Pod 수를 보여줍니다. 이 정보는 HPA와 함께 배포된 워크로드에 대해 권장되는 리소스와 사용된 리소스 사이의 변동성을 이해하는 데 유용합니다.

적재 대시보드 보기

  1. Monitoring 대시보드 페이지로 다시 이동합니다.

    대시보드로 이동

  2. GKE - Cluster 적재(gke-cost-optimization-monitoring) 대시보드를 클릭합니다.

다음 차트에 표시된 대로 적재 대시보드에는 클러스터(첫 번째 행)와 노드 풀(두 번째 행)에서 집계된 정보가 표시됩니다. 이 정보는 클러스터 및 노드 풀의 할당 가능한 용량(allocable_<cores|memory> 줄)을 개발자가 앱에 필요로 하는 항목(requested_<cores|memory> 줄)과 비교하여 클러스터를 적재하는 데 유용합니다.

적재 대시보드에는 클러스터(첫 번째 행)와 노드 풀(두 번째 행)로 집계된 정보가 표시됩니다.

이러한 차트에서 실행할 수 있는 한 가지 유용한 분석은 메모리와 같이 한 가지 리소스 유형이 부족한지 그리고 CPU와 같은 다른 리소스 유형을 낭비하는 지 확인하는 것입니다. 이 시나리오에서는 예약된 Pod를 클러스터에 맞추기 위해 사용할 수 있는 메모리가 없기 때문에 클러스터 자동 확장 처리가 수직 확장을 트리거합니다. 또 다른 일반적인 사례는 Pod 밀도 도는 노드별 Pod 수와 관련이 있습니다. 노드 풀: Pod 수 차트에서 각 노드 풀의 Pod 밀도를 확인하고, 이를 구성된 정보(차트에 제공되지 않음)와 비교할 수 있습니다. 노드 풀의 구성된 밀도에 도달했으면 사용 가능한 CPU 및 메모리가 많더라도 예약된 Pod에 맞게 CA가 새 노드를 가동합니다.

이전 대시보드에서 제공되지 않는 또 다른 중요한 분석은 자동 확장 처리의 최소 및 최대 구성과 관련이 있습니다. 예를 들어 HPA 또는 CA에 최소값보다 많은 리소스가 필요하기 때문에 야간에 클러스터가 축소되지 않을 수 있습니다. 또한 해당 풀에 대해 구성된 최대 노드 수에 도달할 수 있기 때문에 CA가 예상된 노드 풀에서 Pod를 가동하지 않을 수 있습니다.

대시보드 제한사항

  • 적절한 앱 크기 조정 대시보드에 지정된 네임스페이스의 모든 앱에 대해 집계된 정보가 제공되더라도, 고유 대시보드에 허용되는 위젯 수 제한으로 인해 이름별로 정렬된 처음 8개 앱의 CPU, 메모리, 복제본만 보여줍니다. 표시된 앱이 가장 중요한 항목이 아닌 것을 확인했으면 요구에 맞게 대시보드를 수정합니다.
  • 적재 대시보드는 클러스터 및 노드 풀에 대해 집계된 데이터를 제공합니다. 다수의 클러스터 또는 노드 풀을 처리할 때는 차트 작성에 사용되는 Monitoring 쿼리 언어(MQL)에 대해 필터를 실행할 수 없으므로 시각화가 제한됩니다.
  • 적재 대시보드는 수백 개의 앱으로 대규모 클러스터를 모니터링할 때 로드하는 데 시간이 오래 걸릴 수 있습니다. 이 경우 로드된 데이터의 양을 줄이려면 대시보드를 장시간 필터링하지 않는 것이 좋습니다.

과다 프로비저닝 및 과소 프로비저닝 알림 정책 설정

회사의 재무팀이 최근 클라우드 청구서를 이중으로 청구하는 이유를 묻는 경우 과다 프로비저닝 문제가 발생한다는 사실을 알리고 싶지 않을 것입니다. 이러한 상황을 방지하려면 환경에서 계획한 대로 시행되지 않을 때 트리거되는 알림 정책을 만드는 것이 좋습니다.

  1. Cloud Shell에서 알림 채널을 만듭니다.

    gcloud beta monitoring channels create \
        --display-name="Cost Optimization team (Primary)" \
        --description="Primary contact method for the Cost Optimization effort"  \
        --type=email \
        --channel-labels=email_address=${ALERT_EMAIL}
    

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

    Created notification channel [projects/your_project/notificationChannels/13166436832066782447].
    

    위 명령어는 가이드 단계를 간소화하기 위해 email 유형의 알림 채널을 만듭니다. 프로덕션 환경에서는 알림 채널을 sms 또는 pagerduty로 설정하여 비동기 전략을 더 적게 사용하는 것이 좋습니다.

  2. NOTIFICATION_CHANNEL_ID 자리표시자에 표시된 값이 있는 변수를 설정합니다.

    NOTIFICATION_CHANNEL_ID=$(gcloud beta monitoring channels list --filter='displayName="Cost Optimization team (Primary)"' | grep 'name:' | sed 's/name: //g')
    
  3. 다음과 같이 알림 정책을 동적으로 만들고 배포합니다.

    for NAMESPACE in $YOUR_NAMESPACES
    do
        for templatefile in monitoring/policies/templates/rightsizing/*.yaml; do
            outputfile=monitoring/policies/$(basename $templatefile)
            sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
            echo "Creating alert policy based on file: $outputfile"
            gcloud alpha monitoring policies create \
                --policy-from-file=$outputfile \
                --notification-channels=$NOTIFICATION_CHANNEL_ID
        done
    done
    
    for templatefile in monitoring/policies/templates/binpacking/*.yaml; do
        outputfile=monitoring/policies/$(basename $templatefile)
        sed "s/CLUSTER_TO_REPLACE/$CLUSTER/g;s/NAMESPACE_TO_REPLACE/$NAMESPACE/g" $templatefile > $outputfile
        echo "Creating alert policy based on file: $outputfile"
        gcloud alpha monitoring policies create \
            --policy-from-file=$outputfile \
            --notification-channels=$NOTIFICATION_CHANNEL_ID
    done
    

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

    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/18091138402474167583].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-cpu-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/8586234469403227589].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/9685822323903723723].
    Creating alert policy based on file: monitoring/policies/app-rightsizing-memory-underprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/15705075159352926212].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-cpu-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/14555072091442814207].
    Creating alert policy based on file: monitoring/policies/nodepools-binpacking-memory-overprovisioning-alert.yaml
    Created alert policy [projects/rubbo-vpa-3-1/alertPolicies/1442392910032052087].
    

    기본적으로 생성된 알림 정책에는 하루보다 긴 기간 동안 앱이 80% 이상 과다 프로비저닝되고, 노드 풀이 40% 이상 과다 프로비저닝된 경우 알림을 트리거하는 사양이 포함됩니다. 리소스 사용률 요구사항을 충족하기 위해 이러한 정책을 미세 조정해야 합니다.

  4. Monitoring 알림 페이지로 이동하여 알림 정책을 확인합니다.

    알림 페이지로 이동

  5. 생성된 정책을 클릭하고 알림 구성의 세부정보를 확인하거나 수정합니다.

삭제

이 가이드에서 사용한 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 다음 안내를 따르세요.

프로젝트 삭제

청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 프로젝트를 삭제하는 것입니다.

  1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

    리소스 관리로 이동

  2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
  3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

다음 단계