이 페이지에서는 수직형 포드 자동 확장을 사용하여 리소스 할당을 분석하고 최적화하여 Google Kubernetes Engine (GKE)에서 워크로드 효율성을 개선하는 방법을 설명합니다. 시간 경과에 따른 워크로드의 리소스 사용량을 분석하여 최적화 추천을 받고 CPU 및 메모리 요청과 포드 내 컨테이너에 대한 한도를 자동으로 조정할 수 있습니다.
이 페이지에서는 수직형 포드 자동 확장의 작동 방식, 이점, 제한사항, 사용 권장사항을 알아보고 VerticalPodAutoscaler 커스텀 리소스 및 관련 유형의 API 참조에 액세스합니다.
이 페이지는 클라우드 리소스를 프로비저닝 및 구성하고, 워크로드를 배포하고, 애플리케이션 확장을 관리하는 운영자 및 개발자를 위해 작성되었습니다. 일반적인 역할에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.
이 페이지를 읽기 전에 Kubernetes의 리소스 요청 및 한도를 숙지해야 합니다.
갑작스러운 리소스 사용랑에 대응하여 신속하게 확장해야 하는 경우 수평형 포드 자동 확장 처리를 사용하세요.
자동 확장 권장사항은 GKE의 비용 최적화 Kubernetes 애플리케이션 실행 권장사항을 참조하세요.
수직형 포드 자동 확장을 사용하는 이유
수직형 포드 자동 확장은 다음과 같은 이점을 제공합니다.
- 워크로드에 적합한 리소스 요청 및 한도를 설정하면 안정성과 비용 효율성이 향상됩니다. 포드 리소스 크기가 워크로드에 필요한 것보다 작은 경우 애플리케이션이 제한되거나 메모리 부족 오류로 인해 실패할 수 있습니다. 리소스 크기가 너무 크면 낭비하게 되어 더 많은 비용이 청구됩니다.
- 포드가 필요한 만큼만 사용하기 때문에 클러스터 노드가 효율적으로 사용됩니다.
- 사용할 수 있는 적절한 리소스가 있는 노드에 포드가 예약됩니다.
- CPU 및 메모리 요청의 정확한 값을 알아내기 위해 런타임을 소비하는 벤치마크 테스트를 실행할 필요가 없습니다.
- 시간이 지나면서 자동 확장 처리가 사용자 개입 없이 CPU 및 메모리 요청을 조정할 수 있기 때문에 유지보수 시간이 단축됩니다.
- 수직형 포드 자동 확장은 장기 실행되는 동종 워크로드에서 가장 잘 작동합니다.
GKE 수직형 포드 자동 확장은 오픈소스 Kubernetes 자동 확장 처리에 비해 다음과 같은 이점을 제공합니다.
- 추천 대상을 결정할 때 최대 노드 크기 및 리소스 할당량을 고려합니다.
- 클러스터 용량을 조정하도록 클러스터 자동 확장 처리에 알립니다.
- VerticalPodAutoscaler를 사용 설정하기 전에 수집된 측정항목을 포함하여 이전 데이터를 사용합니다.
- 워커 노드에 배포하는 대신 VerticalPodAutoscaler 포드를 컨트롤 플레인 프로세스로 실행합니다.
수직형 포드 자동 확장의 작동 방식
수직형 포드 자동 확장을 사용하면 포드에 필요한 CPU 및 메모리 리소스를 분석하고 설정할 수 있습니다. 포드의 컨테이너에 대해 최신 CPU 요청 및 제한과 메모리 요청 및 제한을 설정할 필요 없이 수직형 포드 자동 확장을 구성하여 CPU 및 메모리 요청의 권장 값을 제공하고 포드를 수동으로 업데이트하는 데 사용할 수 있는 제한을 제공하거나 값을 자동으로 업데이트하도록 수직형 포드 자동 확장을 구성할 수 있습니다.
수직형 포드 자동 확장은 기본적으로 Autopilot 클러스터에서 사용 설정됩니다.
Kubernetes 오픈소스 VerticalPodAutoscaler와의 관계
GKE 수직형 포드 자동 확장은 오픈소스 Kubernetes VerticalPodAutoscaler API를 기반으로 하지만 GKE에 고유한 별도의 구현입니다. GKE 구현은 자체 추천자를 사용하여 확장하도록 설계되었지만 오픈소스 버전에 정의된 것과 동일한 VerticalPodAutoscaler API 종류 및 필드를 유지합니다.
자세한 내용은 수직형 포드 자동 확장에 대한 Kubernetes 문서를 참조하세요.
수직형 포드 자동 확장 모드
다양한 업데이트 모드를 적용하여 수직형 포드 자동 확장에서 리소스 변경사항을 적용하는 방법을 구성할 수 있습니다.
Auto (Recreate) 모드
Recreate 모드에서 수직형 포드 자동 확장은 포드의 리소스 요청을 변경해야 하는 경우 포드를 삭제합니다. 1.33 이전 버전의 Kubernetes 제한사항으로 인해 실행 중인 포드의 리소스 요청을 수정하는 유일한 방법은 포드를 다시 만드는 것이므로 이븍션이 필요합니다.
포드 재생성 수를 제한하려면 포드 중단 예산을 사용합니다 . 클러스터가 새로운 크기의 워크로드를 처리할 수 있도록 클러스터 자동 확장 처리 및 노드 자동 프로비저닝을 사용합니다.
수직형 포드 자동 확장은 업데이트 전에 클러스터 자동 확장 처리에 업데이트를 알리며 워크로드를 다시 만들기 전에 크기가 조절된 워크로드에 필요한 리소스를 제공하여 중단 시간을 최소화합니다.
Initial 모드
Initial가 사용 설정된 경우 수직형 포드 자동 확장은 포드 생성 시에만 리소스 요청을 할당하고 이후에 항목을 변경하지 않습니다.
InPlaceOrRecreate 모드
InPlaceOrRecreate 모드는 포드를 다시 만들지 않고 포드 리소스를 업데이트하여 서비스 중단을 줄이는 것을 목표로 합니다.
InPlaceOrRecreate 모드를 사용하려면 VerticalPodAutoscaler 객체에서 spec.updatePolicy.updateMode 필드를 "InPlaceOrRecreate"로 설정합니다. 이 모드는 워크로드 매니페스트에 정의된 resizePolicy 필드를 사용하여 리소스 변경에 다시 시작이 필요한지 확인합니다. resizePolicy 필드가 정의되지 않은 경우 CPU 및 메모리의 기본값은 NotRequired입니다. 즉, 인플레이스 업데이트가 시도됩니다.
OOM (메모리 부족) 이벤트로 인해 컨테이너가 종료되면 InPlaceOrRecreate 모드의 수직형 포드 자동 확장은 Auto 모드와 유사하게 작동합니다. 즉, 실패로부터 학습합니다. 비정상 종료로 인해 트리거된 후속 포드 재생성 시 수직형 포드 자동 확장은 OOM 오류의 즉각적인 반복을 방지하기 위해 안전 버퍼 (일반적으로 추가 메모리 20% 또는 100MB 중 더 큰 값)가 포함된 권장사항을 적용합니다.
InPlaceOrRecreate 모드는 Kubernetes 버전 1.34.0-gke.2201000 이상에서 사용할 수 있습니다.
InPlaceOrRecreate 모드의 대체 시나리오
수직형 포드 자동 확장에서 준비된 업데이트가 불가능하다고 판단하면 Recreate 모드 동작으로 대체되어 포드를 제거하고 다시 만들어 변경사항을 적용합니다. 수직형 포드 자동 확장이 다시 생성으로 대체되는 일반적인 시나리오는 다음과 같습니다.
- 노드 용량 부족: 업데이트된 리소스 요청이 현재 노드의 할당 가능한 용량을 초과하고 업데이트를 인플레이스 방식으로 예약할 수 없습니다 ('실행 불가능' 또는 '지연' 상태가 제한 시간보다 길어짐).
- QoS 클래스 변경: 리소스 업데이트로 인해 포드의 서비스 품질(QoS) 클래스가 변경됩니다(예:
Burstable에서Guaranteed로). RestartContainer정책: 수직형 포드 자동 확장이 변경하려는 리소스에 대해 포드의resizePolicy필드가RestartContainer로 설정됩니다.- 시간 초과: 인플레이스 업데이트 요청이 너무 오랫동안 대기 중 상태로 유지됩니다.
Off 모드
Off 모드에서는 수직형 포드 자동 확장이 포드에 변경사항을 자동으로 적용하지 않습니다.
이전 사용량을 기준으로 CPU 및 메모리의 요청 및 한도에 대한 권장 값을 계속 볼 수 있지만 이러한 권장사항은 적용되지 않습니다. 필요한 경우 권장 값을 포드에 수동으로 적용할 수 있습니다.
CPU 시작 부스트
CPU 시작 부스트는 초기화 중에 CPU 요청을 일시적으로 늘리고 기준 수준으로 다시 크기를 조절하여 애플리케이션 시작을 가속화하고 비용 효율성을 개선합니다.
CPU 시작 부스트를 구성하는 방법에 대한 자세한 내용은 CPU 시작 부스트로 애플리케이션 시작 가속화를 참조하세요.
CPU 시작 부스트 작동 방식
CPU 시작 부스트는 컨테이너의 기준 CPU 요청을 기반으로 임시 리소스 증가를 계산합니다. 시작 단계가 끝나면 포드가 이 기준 요청 수준으로 돌아갑니다.
부스트는 이 기준 요청을 배수 또는 고정 수량만큼 늘립니다. 이 상향된 요청은 포드가 준비될 때까지 활성 상태로 유지되며, 이후 GKE는 CPU 요청을 기본 수준으로 복원합니다.
부스트 수명 주기 이해하기
시작 부스트 프로세스는 세 단계로 구성됩니다.
- 승인 단계: 포드 승인 중에 VPA 승인 웹훅이 요청을 가로채고 GKE가 포드를 예약하기 전에 부스트된 CPU 값을 삽입합니다.
- 시작 단계: 애플리케이션이 일시적으로 상향된 CPU 할당을 사용하여 초기화되어 초기화 제한을 방지합니다.
- 부스트 해제 단계: 포드가
Ready상태에 도달하고durationSeconds기간이 경과하면 VPA가 CPU 요청을 기본값으로 인플레이스 축소합니다.
부스트된 워크로드의 업데이트 모드 선택
VPA의 지속적인 리소스 관리 유무에 관계없이 CPU 시작 부스트를 구성할 수 있습니다. VPA의 지속적인 리소스 관리는 시작 단계가 끝난 후 포드 리소스 요청을 자동으로 조정합니다. 원하는 환경설정을 선택하려면 VPA 객체에서 updateMode 필드를 설정합니다. VPA 업데이트 모드에 대한 자세한 내용은 수직형 포드 자동 확장 모드를 참조하세요.
updateMode: "Off": VPA는 포드 승인(포드 생성 단계) 중 초기 부스트와 시작 후 후속 축소만 관리합니다. 컨테이너의 정상 상태 리소스 요청은 수정되지 않습니다.updateMode: "Auto","Recreate"또는"InPlaceOrRecreate": VPA는 시작 부스트를 관리하고 지속적인 사용량을 기준으로 포드의 리소스 요청을 자동으로 계속 조정합니다.
CPU 부스트 리소스 할당 계산 방법
GKE는 다음과 같은 방법으로 일시적으로 상향된 CPU 요청을 계산합니다.
기본 CPU 결정: 기준 CPU 요청은 VPA
updateMode필드에 따라 달라집니다.Auto,Recreate또는InPlaceOrRecreate: 기준 CPU 요청은 VPA 권장사항입니다. 추천이 없으면 GKE는 포드 사양에 정의된 CPU 요청으로 대체됩니다.Off: 기준 CPU 요청은 포드 사양의 요청 값입니다.
부스트된 CPU 계산: 계산은 부스트 구성
type필드에 지정하는 계산 방법에 따라 다릅니다.Factor: 기본 CPU 요청에 배수를 적용합니다.부스티드 CPU = 기본 CPU ×
factorQuantity: 기본 CPU 요청에 절대 CPU 수량을 추가합니다.부스티드 CPU = 기본 CPU +
quantity
최종 CPU 요청은 클러스터 모드에 따라 다릅니다.
- Standard 클러스터: 최종 CPU 요청은 부스트된 CPU 값입니다.
- Autopilot 클러스터: 최종 CPU 요청은 부스트된 CPU 값이며, 할당된 포드 메모리에 허용되는 최대 CPU로 제한됩니다.
부스트 중 CPU 한도 동작 이해하기
GKE가 CPU 한도를 처리하는 방식은 containerResourcePolicy의 controlledValues 설정에 따라 달라집니다.
RequestsAndLimits(기본값): GKE는 CPU 요청과 한도를 모두 상향 조정하여 원래 비율을 유지함으로써 컨테이너의 서비스 품질 (QoS) 클래스를 보존합니다.RequestsOnly: GKE는 CPU 요청만 부스트합니다. GKE는 QoS를 유지하기 위해 정의된 CPU 한도 바로 아래에서 부스트된 요청을 제한합니다.
Autopilot 클러스터 고려사항
GKE Autopilot은 특정 CPU 대 메모리 비율 범위와 최소 포드 크기를 적용하므로 GKE는 포드 허용 중에 부스트를 평가하여 규정 준수를 보장합니다. 다음 시나리오에서는 부스트가 수정되거나 무시될 수 있습니다.
- Autopilot 최솟값: 부스트된 요청이 Autopilot 워크로드의 최소 CPU 요구사항 (예: 범용 포드의 경우 50m)보다 낮으면 GKE는 부스트를 적용하지 않고 표준 최솟값을 적용합니다.
- 비율 제한 (부분 또는 건너뛴 부스트): 부스트된 CPU 요청이 필수 CPU 대 메모리 비율 범위를 초과하는 경우 GKE는 할당된 메모리를 준수하는 가장 높은 값으로 부스트를 제한합니다. 원래 포드 요청이 이미 허용된 최대 CPU 대 메모리 비율을 사용하는 경우 GKE는 메모리 크기 조절을 방지하기 위해 부스트를 건너뜁니다.
- Scale-Out ComputeClass: Scale-Out ComputeClass는 엄격한 1:4 (CPU:메모리) 비율을 적용합니다. 메모리를 늘리지 않고 수평 확장 포드에서 CPU를 부스트하려고 하면 GKE가 부스트를 무시할 수 있습니다.
리소스 정책
ContainerResourcePolicy을 사용하여 수직형 포드 자동 확장에서 특정 컨테이너에 대한 권장사항을 생성하는 방법을 맞춤설정할 수 있습니다. 이 정책을 사용하면 제약 조건을 설정하고 확장되는 리소스를 제어할 수 있습니다.
최소 및 최대 한도
컨테이너의 최소 (minAllowed) 및 최대 (maxAllowed) 리소스 값을 지정할 수 있습니다.
minAllowed: 수직형 포드 자동 확장은 이 한도보다 낮은 값을 추천하지 않습니다. 이 한도는 기준 성능 수준을 보장하거나 애플리케이션별 요구사항을 충족하는 데 도움이 되므로 유용합니다.maxAllowed: 수직형 포드 자동 확장은 이 한도보다 높은 값을 추천하지 않습니다. 이 한도는 비용을 제어하거나 단일 컨테이너가 너무 많은 노드 리소스를 소비하지 않도록 방지하는 데 유용합니다.
제어되는 리소스
기본적으로 수직형 포드 자동 확장은 CPU 및 메모리 모두에 대한 권장사항을 계산합니다. controlledResources 필드를 사용하여 자동 확장할 리소스를 지정할 수 있습니다. 예를 들어 메모리에 대해서만 권장사항을 제공하고 CPU 요청은 변경하지 않도록 자동 확장 처리를 구성할 수 있습니다.
제한사항
- CPU에서 수평형 포드 자동 확장과 함께 수직형 포드 자동 확장을 사용하려면 VPA를 사용한 HPA 적정 크기 조정 (프리뷰) 또는 다차원 포드 자동 확장을 사용합니다. 커스텀 및 외부 측정항목에서 수평형 포드 자동 확장과 함께 수직형 포드 자동 확장을 사용할 수도 있습니다.
- 워크로드의 실제 메모리 사용량에 대한 제한된 공개 상태로 인해 수직형 포드 자동 확장을 아직 JVM 기반 워크로드에서 사용할 수 없습니다.
- GKE 버전 1.35.1 이하에서 수직형 포드 자동 확장의 기본 설정은 배포가 포드를 수정된 리소스 값으로 대체할 때 최소 2개의 복제본을 생성하는 것입니다. 버전 1.35.2 이상에서는 기본값이 최소 복제본 1개입니다. 버전 1.22 이상에서는 PodUpdatePolicy 필드에
minReplicas필드 값을 지정하여 이 설정을 재정의할 수 있습니다. - 수직형 포드 자동 확장의
InPlaceOrRecreate업데이트 모드를 사용하고 인플레이스 업데이트가 불가능한 경우 (예: 노드 용량을 초과하여 포드를 업스케일링하는 경우) 수직형 포드 자동 확장은 포드를 제거하고 다시 만들어 권장사항을 적용합니다. 사양에resizePolicy필드가 설정된 포드에서도 제거 및 재생성이 발생하여 재생성을 방지합니다. 이 동작은 최소 리소스 및 CPU:메모리 비율 제약 조건을 적용하는 경우를 포함하여 Autopilot 크기 조절 요청에 대해 발생합니다. - 수직형 포드 자동 확장을 사용하려면 배포, StatefulSet, ReplicaSet 또는 ReplicationControllers와 같이 포드를 관리하는 워크로드 객체가 필요합니다. 포드 재생성 프로세스를 관리하려면 워크로드 컨트롤러가 필요하므로 독립형 포드에는 수직형 포드 자동 확장을 사용할 수 없습니다.
- 수직형 포드 자동 확장은 컨테이너 수준 리소스 요청 및 한도 (
spec.containers[].resources)에 대해서만 권장사항을 생성하고 업데이트를 적용합니다. 수직형 포드 자동 확장은 포드 수준 리소스 사양(spec.resources)을 지원하지 않습니다.
권장사항
VerticalPodAutoscaler객체 수를 제한합니다. 클러스터 업데이트 중단을 방지하려면 클러스터당VerticalPodAutoscaler객체 수를 1,000 미만으로 유지해야 합니다.- 수직형 포드 자동 확장은 장기 실행되는 동종 워크로드에서 가장 잘 작동합니다.
- 장기 실행: 최소 24시간 동안 실행되는 워크로드입니다. 수직형 포드 자동 확장을 사용하려면 신뢰도가 높은 추천을 생성하기 위해 상당한 양의 이전 데이터가 필요합니다.
Auto또는Recreate모드에서는 일반적으로 포드가 24시간 이상 경과한 후에 업데이트가 수행되므로 포드가 자주 다시 시작되고 변동되는 것을 방지할 수 있습니다. - 동종: 단일
VerticalPodAutoscaler객체(예: 배포의 모든 복제본)가 타겟팅하는 포드는 유사한 리소스 소비 패턴을 보여야 합니다. 수직형 포드 자동 확장 처리는 모든 타겟팅된 포드의 사용량 데이터를 집계하여 추천을 생성합니다. 복제본의 사용량이 이기종인 경우(예: 일부 포드가 유휴 상태이고 다른 포드가 과부하 상태인 경우) 수직형 포드 자동 확장 처리는 유휴 포드를 과도하게 프로비저닝하거나 사용 중인 포드를 과소 프로비저닝하는 권장사항을 제공할 수 있습니다.
- 장기 실행: 최소 24시간 동안 실행되는 워크로드입니다. 수직형 포드 자동 확장을 사용하려면 신뢰도가 높은 추천을 생성하기 위해 상당한 양의 이전 데이터가 필요합니다.
- 수요가 급증하는 워크로드에 수평형 포드 자동 확장을 사용합니다. 수직형 포드 자동 확장은 안정적인 상태의 적정 크기 조정을 위해 설계되었으며 갑작스럽고 단기적인 리소스 급증에 대한 솔루션이 아닙니다. 트래픽 또는 CPU나 메모리 수요가 급격하게 변동하는 워크로드의 경우 수평형 포드 자동 확장 처리를 대신 사용하세요.
- OOM 보호를 활용합니다. 수직형 포드 자동 확장 처리는 사후 대응적이지만 메모리 부족 (OOM) 이벤트에 대한 자동 보호 기능이 포함되어 있습니다. 포드가
OOMKilled인 경우 수직형 포드 자동 확장 처리는 이벤트를 즉시 관찰하고 메모리 권장사항을 약 20% (또는 100MB 중 더 큰 값) 늘려 포드가 다시 생성될 때 안정성을 개선합니다. OOM 이벤트에 대한 자세한 내용은 OOM 이벤트 문제 해결을 참조하세요.
API 참조
v1 API 참조입니다. 이 버전의 API를 사용하는 것이 좋습니다.
VerticalPodAutoscaler v1 autoscaling.k8s.io
| 필드 | |
|---|---|
|
API 그룹, 버전, 종류 |
metadata |
표준 객체 메타데이터 |
spec |
|
status |
가장 최근에 관찰된 |
VerticalPodAutoscalerSpec v1 autoscaling.k8s.io
| 필드 | |
|---|---|
targetRef |
자동 확장 처리가 제어할 pod 집합을 관리하는 컨트롤러를 가리킵니다(예: 배포 또는 StatefulSet).
확장 하위 리소스가 있는 컨트롤러의 |
updatePolicy |
포드가 시작될 때 추천 업데이트가 적용되는지 여부와 포드의 수명 동안 추천 업데이트가 적용되는지 여부를 지정합니다. |
resourcePolicy |
개별 컨테이너의 CPU 및 메모리 요청을 조정하는 방법에 대한 정책을 지정합니다. 리소스 정책을 사용하면 개별 컨테이너의 추천에 제약조건을 설정할 수 있습니다. 지정되지 않은 경우 자동 확장 처리는 추가 제약 없이 포드의 모든 컨테이너에 대한 추천 리소스를 계산합니다. |
recommenders |
이 VPA 객체의 추천을 생성하는 추천자입니다. GKE에서 제공되는 기본 추천자를 사용하려면 비워 둡니다. 그렇지 않으면 사용자가 제공한 대체 추천자에 해당하는 정확히 하나의 항목이 목록에 포함될 수 있습니다. GKE 1.22부터 지원됩니다. |
VerticalPodAutoscalerList v1 autoscaling.k8s.io
| 필드 | |
|---|---|
|
API 그룹, 버전, 종류 |
metadata |
표준 객체 메타데이터 |
items |
|
PodUpdatePolicy v1 autoscaling.k8s.io
| 필드 | |
|---|---|
updateMode |
Pod가 시작될 때 추천 업데이트가 적용되는지 여부와 Pod 수명 동안 추천 업데이트가 적용되는지 여부를 지정합니다. 가능한 값은 다음과 같습니다.
|
minReplicas |
포드 삭제를 시도하기 위해 사용 설정해야 하는 최소 복제본 수입니다(포드 중단 예산 같은 다른 검사 대기 중).
양수 값만 허용됩니다. 기본값은 GKE 버전 1.35.2 이상에서는 |
PodResourcePolicy v1 autoscaling.k8s.io
| 필드 | |
|---|---|
containerPolicies |
개별 컨테이너의 리소스 정책 배열 이름이 지정된 컨테이너마다 최대 한 개의 항목이 포함될 수 있으며, 개별 정책이 없는 모든 컨테이너를 처리하는 `containerName = '*'`가 있는 단일 와일드 카드 항목이 선택적으로 있을 수 있습니다. |
ContainerResourcePolicy v1 autoscaling.k8s.io
| 필드 | |
|---|---|
containerName |
정책이 적용될 컨테이너의 이름입니다. 지정하지 않으면 기본 정책으로 사용됩니다. |
mode |
컨테이너가 시작될 때 추천 업데이트가 적용되는지 여부와 컨테이너의 수명 동안 추천 업데이트가 적용되는지 여부를 지정합니다. 가능한 값은 'Off'와 'Auto'입니다. 값을 지정하지 않으면 기본값은 'Auto'입니다. |
minAllowed |
컨테이너에 허용되는 최소 CPU 요청 및 메모리 요청을 지정합니다. 기본적으로 적용되는 최솟값은 없습니다. |
maxAllowed |
컨테이너에 허용되는 최대 CPU 요청 및 메모리 요청을 지정합니다. 기본적으로 적용되는 최댓값은 없습니다. |
controlledResources |
|
VerticalPodAutoscalerRecommenderSelector v1 autoscaling.k8s.io
| 필드 | |
|---|---|
name |
이 객체의 권장사항을 생성하는 추천자의 이름입니다. |
VerticalPodAutoscalerStatus v1 autoscaling.k8s.io
| 필드 | |
|---|---|
recommendation |
최근에 추천된 CPU 및 메모리 요청입니다. |
conditions |
|
RecommendedPodResources v1 autoscaling.k8s.io
| 필드 | |
|---|---|
containerRecommendations |
개별 컨테이너의 리소스 추천 배열 |
RecommendedContainerResources v1 autoscaling.k8s.io
| 필드 | |
|---|---|
containerName |
추천이 적용되는 컨테이너의 이름 |
target |
컨테이너에 추천되는 CPU 요청 및 메모리 요청 |
lowerBound |
컨테이너에 추천되는 최소 CPU 요청 및 메모리 요청. 이 양은 애플리케이션을 안정적으로 실행하는 데 충분하다는 것을 보장하지 않습니다. 더 적은 CPU 및 메모리 요청으로 실행하면 성능이나 가용성에 상당한 영향을 미칠 가능성이 높습니다. |
upperBound |
컨테이너에 추천되는 최대 CPU 요청 및 메모리 요청. 이 값보다 높은 CPU 및 메모리 요청은 낭비될 가능성이 높습니다. |
uncappedTarget |
자동 확장 처리에서 계산한 최근의 리소스 추천으로, ContainerResourcePolicy를 고려하지 않고 실제 리소스 사용량을 기준으로 계산한 것입니다. 실제 리소스 사용량으로 인해 대상이 ContainerResourcePolicy를 위반하는 경우 이 값은 제한된 권장사항과 다를 수 있습니다. 이 필드는 실제 리소스 할당에는 영향을 미치지 않습니다. 상태 표시 용도로만 사용됩니다. |
VerticalPodAutoscalerCondition v1 autoscaling.k8s.io
| 필드 | |
|---|---|
type |
설명하고 있는 조건의 유형. 가능한 값은 'RecommendationProvided', 'LowConfidence', 'NoPodsMatched', 'FetchingHistory'입니다. |
status |
조건의 상태. 가능한 값은 True, False, Unknown입니다. |
lastTransitionTime |
조건이 한 상태에서 다른 상태로 전환된 마지막 시간 |
reason |
마지막 상태 전환의 이유 |
message |
인간이 읽을 수 있으며 마지막 상태 전환의 세부정보를 제공하는 문자열 |
다음 단계
- 수직형 포드 자동 확장을 구성하는 방법 알아보기
- VPA를 사용하여 HPA 워크로드의 크기를 적정화하는 방법을 알아보세요.
- CPU 시작 부스트를 사용하여 애플리케이션 시작을 가속화하는 방법 알아보기
- 수평형 포드 자동 확장 자세히 알아보기
- 클러스터 자동 확장 처리 자세히 알아보기