whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #31188 from jihoon-seo/220104_Update_outdated_M83

Browse Source 
[ko] Update outdated files in `dev-1.23-ko.1` (M83-M93)
This commit is contained in:
Kubernetes Prow Robot
2022-01-20 01:43:51 -08:00
committed by GitHub
parent 4ce3ae4bdd 6b56f2924b
commit fa2b224ccc
12 changed files with 253 additions and 410 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+198 -134
View File
@@ -3,41 +3,59 @@
title: Horizontal Pod Autoscaler
title: Horizontal Pod Autoscaling
feature:
title: Horizontal 스케일링
description: >
간단한 명령어나 UI를 통해서 또는 CPU 사용량에 따라 자동으로 애플리케이션의 스케일을 업 또는 다운한다.
content_type: concept
weight: 90
---
<!-- overview -->
Horizontal Pod Autoscaler는 CPU 사용량
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다.
쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예:
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며,
워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다.
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
수평 스케일링은 부하 증가에 대해
{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다.
이는 _수직_ 스케일링(쿠버네티스에서는,
해당 워크로드를 위해 이미 실행 중인 파드에
더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.
부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우,
HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋,
또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.
Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예:
{{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다.
HorizontalPodAutoscaler는 쿠버네티스 API 자원 및
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다.
HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다.
쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률,
또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해
목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다.
Horizontal Pod Autoscaling을 활용하는
[연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)가 존재한다.
<!-- body -->
## Horizontal Pod Autoscaler는 어떻게 작동하는가?
## HorizontalPodAutoscaler는 어떻게 작동하는가?
![Horizontal Pod Autoscaler 다이어그램](/images/docs/horizontal-pod-autoscaler.svg)
{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}}
Horizontal Pod Autoscaler는 컨트롤러
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
쿠버네티스는 Horizontal Pod Autoscaling을
간헐적으로(intermittently) 실행되는
컨트롤 루프 형태로 구현했다(지숙적인 프로세스가 아니다).
실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의
`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다).
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
각 주기마다, 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
메트릭 API(파드 단위 리소스 메트릭 용)
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
@@ -45,7 +63,8 @@ Horizontal Pod Autoscaler는 컨트롤러
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을
퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
@@ -54,32 +73,36 @@ Horizontal Pod Autoscaler는 컨트롤러
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
섹션을 참조하기 바란다.
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) 섹션을 참조하기 바란다.
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2` API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다.
HorizontalPodAutoscaler를 사용하는 일반적인 방법은
{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`,
`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다.
`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며,
Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는
[Metrics Server](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참고한다.
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다.
[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를
확인할 수 있다.
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
하위 리소스 스케일에 대한 자세한 내용은
[여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다.
HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는
워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다.
이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며,
이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다.
쿠버네티스 API의 하위 리소스에 대한 일반적인 정보는 [쿠버네티스 API 개념](/docs/reference/using-api/api-concepts/)에서 확인할 수 있다.
### 알고리즘 세부 정보
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는
가장 기본적인 관점에서, HorizontalPodAutoscaler 컨트롤러는
원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로
작동한다.
@@ -90,28 +113,30 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이
`100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가
된다. 만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로
복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는
복제본 수를 반으로 줄일 것이다. 컨트롤 플레인은 비율이 1.0(기본값이 0.1인
`-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여
전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
`targetAverageValue` 또는 `targetAverageUtilization`가 지정되면,
`currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표
안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.
허용치를 확인하고 최종 값을 결정하기 전에, 파드
준비 상태와 누락된 메트릭을 고려한다.
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료
중인 파드) 및 실패한 파드는 모두 폐기된다.
허용치를 확인하고 최종 값을 결정하기 전에,
컨트롤 플레인은 누락된 메트릭이 있는지,
그리고 몇 개의 파드가 [`Ready`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)인지도 고려한다.
삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면
셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는
버려진다.
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와
같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히
초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기
CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히
초기화중이거나, unhealthy하여서) *또는* 파드의 최신 메트릭 포인트가 준비되기
전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
@@ -124,20 +149,21 @@ CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
누락된 메트릭이 있는 경우, 컨트롤 플레인은 파드가 스케일 다운의 경우
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
스케일의 크기를 약화시킨다.
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나
아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우,
컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
비율을 다시 계산한다. 새 비율이 스케일 방향을
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
비율을 사용하여 스케일한다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에,
컨트롤러가 사용률을 다시 계산한다.
새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면,
컨트롤러가 스케일링을 건너뛴다.
그렇지 않으면, 새로 계산한 사용률를 이용하여 파드 수 변경 결정을 내린다.
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
@@ -161,32 +187,25 @@ HPA가 여전히 확장할 수 있음을 의미한다.
## API 오브젝트
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
`autoscaling/v1` API 버전에서 찾을 수 있다.
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
Horizontal Pod Autoscaler는
쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
현재의 안정 버전은 `autoscaling/v2` API 버전이며,
메모리와 커스텀 메트릭에 대한 스케일링을 지원한다.
`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는
어노테이션으로 보존된다.
HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)에서 찾을 수 있다.
## 워크로드 스케일링의 안정성 {#flapping}
## kubectl에서 Horizontal Pod Autoscaler 지원
HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때,
측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다.
이는 종종 *thrashing* 또는 *flapping*이라고 불린다.
이는 사이버네틱스 분야의 *이력 현상(hysteresis)* 개념과 비슷하다.
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
`kubectl autoscale`에 대한 자세한 문서는 [여기](/docs/reference/generated/kubectl/kubectl-commands/#autoscale)에서 찾을 수 있다.
## 롤링 업데이트 중 오토스케일링
@@ -203,31 +222,6 @@ HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
레플리카셋과 같은 중간 리소스가 없다).
## 쿨-다운 / 지연에 대한 지원
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로
노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
안정화되기까지의 시간 간격을 지정한다.
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다.
{{< note >}}
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
있다.
{{< /note >}}
## 리소스 메트릭 지원
모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
@@ -260,7 +254,7 @@ resource:
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
HorizontalPodAutoscaler API는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
@@ -272,6 +266,7 @@ resource:
해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
메트릭 소스를 정의한다.
```yaml
type: ContainerResource
containerResource:
@@ -297,27 +292,31 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는
이전 컨테이너 이름을 제거하여 정리한다.
{{< /note >}}
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod
Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다.
제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
## 사용자 정의 메트릭을 이용하는 스케일링
## 사용자 정의 메트릭을 위한 지원
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
{{< note >}}
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
{{< /note >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
`autoscaling/v2beta2` API 버전을 사용하는 경우,
(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은)
커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다.
이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회한다.
요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
## 복수의 메트릭을 이용하는 스케일링
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
`autoscaling/v2beta2` API 버전을 사용하는 경우,
HorizontalPodAutoscaler가 스케일링에 사용할 복수의 메트릭을 설정할 수 있다.
이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다.
HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를
조정한다(이 값이 이전에 설정한 '총 최대값(overall maximum)'보다는 크지 않을 때에만).
## 메트릭 API를 위한 지원
@@ -332,8 +331,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
클러스터 애드온으로 시작할 수 있다.
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다.
메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다.
직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다.
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
@@ -345,16 +343,21 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과
[외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다.
## 구성가능한 스케일링 동작 지원
## 구성가능한 스케일링 동작
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
스케일링 동작을 구성할 수 있다.
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면,
`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를
사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있다.
각 방향에 대한 동작은 `behavior` 필드 아래의
`scaleUp` / `scaleDown`를 설정하여 지정할 수 있다.
_안정화 윈도우_ 를 명시하여 스케일링 목적물의
레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시
레플리카 수 변화 속도를 조절할 수도 있다.
### 스케일링 정책
@@ -391,23 +394,29 @@ behavior:
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
비활성화 된다.
비활성화된다.
### 안정화 윈도우
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때
레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다.
오토스케일링 알고리즘은 이전의 목표 상태를 추론하고
워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다.
예를 들어, 다음 예제 스니펫에서, `scaleDown`에 대해 안정화 윈도우가 설정되었다.
```yaml
scaleDown:
stabilizationWindowSeconds: 300
behavior:
scaleDown:
stabilizationWindowSeconds: 300
```
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우,
알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다.
위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다.
이를 통해 동적 최대값(rolling maximum)을 근사화하여,
스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다.
### 기본 동작
@@ -453,7 +462,7 @@ behavior:
stabilizationWindowSeconds: 60
```
### 예시: 스케일 다운 비율 제한
### 예시: 스케일 다운 속도 제한
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
다음 동작이 HPA에 추가된다.
@@ -467,9 +476,7 @@ behavior:
periodSeconds: 60
```
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
전략을 추가할 수 있다.
분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소
정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
@@ -497,6 +504,18 @@ behavior:
selectPolicy: Disabled
```
## kubectl의 HorizontalPodAutoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
## 암시적 유지 관리 모드 비활성화
HPA 구성 자체를 변경할 필요없이 대상에 대한
@@ -506,9 +525,54 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
다시 활성화할 때까지 HPA는 대상 조정을
중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).
### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기
HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의
{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서
`spec.replicas`의 값을 삭제하는 것이 바람직하다.
이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로)
오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를
`spec.replicas`에 기재된 값으로 조정할 것이다.
이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다.
`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데,
이는 이 키의 기본값이 1이기 때문이다(레퍼런스:
[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)).
값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다.
이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다.
이러한 1회성 저하를 방지하는 방법이 존재하며,
디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다.
{{< tabs name="fix_replicas_instructions" >}}
{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}}
1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>`
2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이
업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다.
3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다.
소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록
변경 사항을 커밋하고 추가 필요 단계를 수행한다.
4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다.
{{% /tab %}}
{{% tab name="서버 쪽에 적용하기" %}}
[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면,
정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership)
가이드라인을 참조한다.
{{% /tab %}}
{{< /tabs >}}
## {{% heading "whatsnext" %}}
클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은
클러스터 수준의 오토스케일러 사용을 고려해 볼 수 있다.
* 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
* kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
* [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.
HorizontalPodAutoscaler에 대한 더 많은 정보는 아래를 참고한다.
* horizontal pod autoscaling에 대한 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 확인한다.
* [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 문서를 확인한다.
* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면,
[샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
* HorizontalPodAutoscaler [API 레퍼런스](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler/)를 확인한다.