💻
DevOps Cookbook
  • Home
    • Meiko DevOps Cookbook
  • Gitlab
    • Tips
      • 사전 정의된 CI/CD 변수의 기본 세트
    • 딥다이브 Gitlab CI/CD
      • GitLab CI/CD 시작하기
        • .gitlab-ci.yml 파일
        • Runner
        • 파이프라인
        • CI/CD 변수
        • CI/CD 컴포넌트
      • CI/CD YAML 구문 참조
    • CI/CD Notifications
      • CI/CD slack notifiaction 구축작업 결과
  • Kubernetes
    • Persistence Volume
      • play-cluster
    • Ingress
      • Ingress란
      • 수동으로 ingress 배포하기
    • Security
    • HPA
      • hpa troubleshooting history
        • 1. HELM_UPGRADE_VALUES_FILE로 hpa가 추가되지 않는 원인
        • 2. targetCPUUtilizationPercentage 계산은 어떻게 되는가
        • 3. helm values에 cpu resource 단위를 1로 했을 때 실제 파드에 1m( 0.001 ) 코어가 부여된 것
        • 4. pod cpu resources가 할당받은 것을 나타내는 것인 지 현재 사용량을 나타내는 것인지 검증
        • 5. 설정한 hpa를 기반으로 pod auto scaling이 동작하는 지 검증
      • HorizontalPodAutoscaler의 behavior 필드 중 stabilizationWindowSeconds 값이 Kubernetes 코드에서 어떻게 사용되는지 분석
  • prometheus
    • prometheus 리소스 alert 세팅
      • 슬랙 채널 구성
      • alert 환경 구성 가이드
  • Loki
    • loki-grafana alert 세팅
      • 1차 검증 결과
      • Alert 환경 구성 가이드
  • load test
    • nGrinder
      • nGrinder Test Configuration 값들
      • 질문리스트
        • groovy는 JUnit 스타일에 포함되지 않는건가 ? + GTest가 뭔지 좀 헷갈린다
      • Script
        • Groovy Script Structure
          • reference
          • Groovy script deep dive
          • Groovy Script 실행 구조 분석
      • Test
        • [nGrinder] single endpoint load test 하기
          • [nGrinder] single endpoint load test script 기반 cpu 사용량 테스트
          • [nGrinder] single endpoint load test script 기반 pod autoscaling 테스트
        • [nGrinder] multi endpoint load test 하기
          • [nGrinder] multi endpoint load test script에 정의한 test들이 실행 순서를 보장 받는가?
  • AWS
    • aws-cli
      • eks cluster vpc 스펙보기
    • aws-vpc
  • EKS
    • youtube links
    • EKS best practice
    • 질문 정리
  • Istio
    • Istio Basic
      • Istio 컴포넌트 별 역할
      • Kubernetes Ingress와 Istio VirtualService의 관계
    • Gateway
      • Gateway 주요 특징
      • Istio Gateway와 Kubernetes Ingress의 주요 차이점
  • IAC
    • Terraform
      • 테라폼 설치
      • 테라폼 문서
      • 테라폼 개념
        • 언어 구조
        • 사용 순서
        • 상태파일 (tfstate)
        • 변수 정의 방법
      • Terraform - AWS VPC
    • Ansible
      • Ansible 초기 학습 내용
      • Ansible Playbook
      • Ansible Study
        • Inventory
        • Playbook
          • Module
        • Variable
  • etc
    • Toss SLASH24
    • Elastic Load Balancing
    • 낙서장
      • IRSA
    • deep dive
      • Istio 공식문서 번역
        • Overview
          • What is Istio?
          • Why choose Istio?
          • Sidecar or ambient?
        • Concepts
          • Traffic Management
        • Page
      • eks 에서 control plane < - > data plane 통신 원리
Powered by GitBook
On this page
Edit on GitHub
  1. Kubernetes
  2. HPA
  3. hpa troubleshooting history

2. targetCPUUtilizationPercentage 계산은 어떻게 되는가

Previous1. HELM_UPGRADE_VALUES_FILE로 hpa가 추가되지 않는 원인Next3. helm values에 cpu resource 단위를 1로 했을 때 실제 파드에 1m( 0.001 ) 코어가 부여된 것

Last updated 1 year ago

targetCPUUtilizationPercentage 계산은 어떻게 되는가

  • targetCPUUtilizationPercentage 계산 방식:

    • targetCPUUtilizationPercentage는 현재 CPU 사용량이 requests.cpu에 대해 차지하는 백분율을 기반으로 계산

공식 문서의 공식 내용

공식 문서 인용:

desiredReplicas 공식 설명

desiredReplicas = ceil(currentReplicas * ( currentMetricValue / desiredMetricValue ))
  1. currentReplicas:

    • 현재 실행 중인 파드의 .

    • 예를 들어, 1개 파드로 시작하면 currentReplicas는 1.

  2. currentMetricValue:

    • 현재 메트릭 값.

    • CPU 사용량을 기준으로 한다면 현재 CPU 사용량이 된다.

    • 예를 들어, 현재 CPU 사용량이 80m일 때 currentMetricValue는 80m.

  3. desiredMetricValue:

    • 목표 메트릭 값.

    • CPU 사용률을 기준으로 한다면 targetCPUUtilizationPercentage에 해당하는 값이 된다.

    • 예를 들어, targetCPUUtilizationPercentage가 75%로 설정되었다면 desiredMetricValue는 75%.

공식 계산 예시

  1. 공식:

    desiredReplicas = ceil(currentReplicas * (currentMetricValue / desiredMetricValue))
  2. 대입 값:

    • currentReplicas = 1

    • currentMetricValue = 80m

    • desiredMetricValue = 75%

  3. 계산 과정:

    • 첫 번째 단계: 80m / 75%

      • 80m을 75%로 나누면 80 / 0.75.

      • 이때 퍼센트(%)는 소수점으로 환산되므로, 75% = 0.75.

      • 따라서 80m / 75% = 80 / 0.75 = 106.67

    • 두 번째 단계: ceil(1 * 106.67)

      • currentReplicas가 1이므로 1 * 106.67은 106.67.

      • ceil 함수를 사용해 이 값을 올림 처리.

      • ceil(106.67) = 2

    • 헷갈리니 그냥 75를 나눠도 된다

  4. 최종 결과:

    • 최종적으로 필요한 파드 수는 2개.

예시 상황

  1. Initial Setup:

    • requests.cpu: 100m

    • targetCPUUtilizationPercentage: 75%

    • Initial Pod Count: 3

    • Initial CPU Usage: 240m (80m * 3)

  2. CPU 사용률 계산:

    • 현재 CPU 사용률: (240m / (100m * 3)) * 100% = 80%

    • 목표 사용률(targetCPUUtilizationPercentage): 75%

  3. 필요한 파드 수 계산:

desiredReplicas = ceil(3 * (80 / 75)) = ceil(3 * 1.0667) = 4
  • 따라서, HPA는 파드 수를 4개로 늘린다.

파드 수 감소 시나리오

Step 1: CPU 사용량이 감소해 현재 CPU 사용률이 40%로 떨어졌다고 가정.

  1. 파드 수 감소 계산 공식 적용:

    • 현재 CPU 사용률: 40%

    • targetCPUUtilizationPercentage: 75%

    desiredReplicas = ceil(4 * (40 / 75)) = ceil(4 * 0.5333) = 3
  2. 결과:

    • HPA는 파드 수를 4개에서 3개로 줄인다.

Step 2: CPU 사용량이 더 감소해 현재 CPU 사용률이 20%로 떨어졌다고 가정.

  1. 파드 수 감소 계산 공식 적용:

    • 현재 CPU 사용률: 20%

    • targetCPUUtilizationPercentage: 75%

    desiredReplicas = ceil(3 * (20 / 75)) = ceil(3 * 0.2667) = 1
  2. 결과:

    • HPA는 파드 수를 3개에서 1개로 줄입니다.

파드 수 감소 시나리오 고려사항

  1. Cool-down 기간:

    • Pod 수를 줄이거나 늘릴 때 Cool-down 기간이 필요할 수 있다.

    • Cool-down 기간을 통해 스케일링 동작이 빈번하게 발생하는 것을 방지할 수 있다.

  2. 최소 파드 수:

    • minReplicas 값은 파드 수가 설정된 최소 값 이하로 줄어들지 않도록 보장한다.

  3. 운영 중지 파드 결정:

    • Pod 수를 줄이는 경우 어느 파드가 중지될지 결정해야 한다.

    • Kubernetes는 파드의 라이프사이클 상태, 사용 리소스 등을 기반으로 파드 종료를 결정한다.

  • ceil 함수를 사용해 결과를 올림 처리하여 최종적으로 2개의 파드를 요구한다.

  • ceil은 수학 함수로, 특정 숫자를 올림하여 정수로 반환하는 함수이다. 이 함수를 사용하여 HPA의 파드 수를 계산할 때 최종적으로 필요한 파드 수를 정수로 결정한다.

  • ceil 함수 설명

  1. ceil 함수는 주어진 소수점 숫자를 올림하여 정수로 반환하는 수학 함수. 이는 특정 수가 소수점 이하 값을 가질 때, 그 수보다 크거나 같은 가장 작은 정수를 반환한다.

    1. 예를 들어, ceil(1.0667)은 2를 반환한다.

    2. 1.0667은 소수점 이하 값이 존재하므로, 올림 처리를 위해 가장 작은 정수를 찾는다.

    3. 1.0667보다 크거나 같은 가장 작은 정수는 2.

  2. ceil 함수의 역할:

    • HPA에서 파드 수를 계산할 때 소수점이 발생할 수 있으므로 이를 올림하여 최종 파드 수를 정수로 결정한다.

예시

ceil(1.0667) = 2
ceil(2.5) = 3
ceil(3.9) = 4
ceil(-1.1) = -1

그래서 resource.request.cpu가 없으면 hpa resource가 ns에 배포되지 않는 것 같다

currentMetricValue와 requests의 관계

  • currentMetricValue는 requests와 직접적인 관계를 갖지는 않지만, 현재 CPU 사용량을 requests 값에 대한 백분율로 비교해 계산된다.

HPA 리소스가 생성되지 않는 이유

  • HPA는 CPU 또는 메모리 requests가 지정되지 않은 경우 작동하지 않을 수 있다.

  • HPA는 resources.requests.cpu나 resources.requests.memory를 기준으로 계산하기 때문이다.

  • 만약 resources 섹션이 비어있거나 설정되어 있지 않다면 HPA는 currentMetricValue를 계산할 수 없어 리소스가 생성되지 않는다.

  • 공식 문서의 관련 내용은 다음과 같다:

The Horizontal Pod Autoscaler automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization (or, with custom metrics support, on some other application-provided metrics).

  • CPU 또는 메모리 requests의 필요성:

    • HPA가 제대로 작동하려면 requests.cpu 또는 requests.memory를 설정해야 한다.

    • requests 값이 없으면 HPA는 리소스 사용률을 계산할 수 없다.

이 문제도 해결되고 나니 hpa가 배포되었다. 근데 k get top pods 로 리소스를 봤는데 NAME CPU(cores) MEMORY(bytes)

staging-7bddbc6d7-bw87t 1m 108Mi

staging-7bddbc6d7-l4tpw 1m 109Mi staging-7bddbc6d7-lnnqf 1m 106Mi 이렇게 cpu가 1m ( 0.001 코어 ) 밀리코어 가 잡혀있었다 내가 예상했던 건 resources.requests.cpu 에 명시한 cpu를 할당하고 시작하는 줄 알았다

Horizontal Pod Autoscaler Walkthrough (Kubernetes 공식 문서)
Kubernetes amount of Pods vs amount of CPU requestsDiscuss Kubernetes
Logo