Merge pull request #52347 from hyorimlee/horizontal-pod-autoscale-walkthrough

[ko] Sync /tasks/run-application/horizontal-pod-autoscale-walkthrough with upstream en

Author: k8s-ci-robot

content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md

@@ -21,11 +21,11 @@ min-kubernetes-server-version: 1.23
 
 수평 스케일링은 부하 증가에 대해 
 {{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다. 
-이는 _수직_ 스케일링(쿠버네티스에서는, 
-해당 워크로드를 위해 이미 실행 중인 파드에 
-더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.
+이는 _수직_ 스케일링과는 다른데, 쿠버네티스에서 수직 스케일링은
+이미 실행 중인 파드에 더 많은 리소스(예: 메모리 또는 CPU)를 
+할당하는 것을 뜻한다.
 
-부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우, 
+부하량이 줄어들고, 파드의 수가 설정된 최소값보다 많다면, 
 HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋, 
 또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.
 
@@ -45,11 +45,17 @@ HorizontalPodAutoscaler를 설정하는 예시를 다룬다.
 리소스 메트릭을 수집하고, 수집한 메트릭을 
 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 통해 노출시키며, 
 메트릭 수치를 나타내는 새로운 종류의 리소스를 추가하기 위해 
-[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용할 수 있다.
+[APIService](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를 사용한다.
 
 Metrics Server를 실행하는 방법을 보려면 
 [metrics-server 문서](https://github.com/kubernetes-sigs/metrics-server#deployment)를 참고한다.
 
+만약 {{< glossary_tooltip term_id="minikube" >}}를 사용 중이라면, 다음 명령으로 metrics-server를 활성화한다.
+
+```shell
+minikube addons enable metrics-server
+```
+
 <!-- steps -->
 
 ## php-apache 서버 구동 및 노출
@@ -58,7 +64,7 @@ HorizontalPodAutoscaler 시연을 위해, `hpa-example` 이미지를 사용하
 다음의 매니페스트를 사용하여 디플로이먼트를
 {{< glossary_tooltip term_id="service" text="서비스">}}로 노출한다.
 
-{{< codenew file="application/php-apache.yaml" >}}
+{{% code_sample file="application/php-apache.yaml" %}}
 
 이를 위해, 다음의 명령어를 실행한다.
 
@@ -73,13 +79,13 @@ service/php-apache created
 
 ## HorizontalPodAutoscaler 생성 {#create-horizontal-pod-autoscaler}
 
-이제 서비스가 동작중이므로, 
+이제 서버가 동작 중이므로, 
 `kubectl`을 사용하여 오토스케일러를 생성한다. 이를 위해 
-[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다.
+[`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands#autoscale) 서브커맨드를 사용할 수 있다.
 
 아래에서는 첫 번째 단계에서 만든 php-apache 
 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 
-Horizontal Pod Autoscaler를 생성하는 명령어를 실행할 것이다.
+HorizontalPodAutoscaler를 생성하는 명령어를 실행할 것이다.
 
 간단히 이야기하면, HPA {{<glossary_tooltip text="컨트롤러" term_id="controller">}}는 
 평균 CPU 사용량을 50%로 유지하기 위해 (디플로이먼트를 업데이트하여) 레플리카의 개수를 늘리고 줄인다.
@@ -114,7 +120,7 @@ NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICA
 php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s
 ```
 
-(HorizontalPodAutoscalers 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며, 
+(HorizontalPodAutoscaler의 이름이 다르다면, 이미 기존에 존재하고 있었다는 뜻이며, 
 보통은 문제가 되지 않는다.)
 
 아직 서버로 요청을 보내는 클라이언트가 없기 때문에, 현재 CPU 사용량이 0%임을 확인할 수 있다. 
@@ -135,24 +141,24 @@ kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never --
 이제 아래 명령을 실행한다.
 ```shell
 # 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다.
-kubectl get hpa
+kubectl get hpa php-apache --watch
 ```
 
-1분 쯤 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다.
+1분 정도 지나면, 다음과 같이 CPU 부하가 올라간 것을 볼 수 있다.
 
 ```
 NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   305% / 50%  1         10        1          3m
 ```
 
-그리고 다음과 같이 레플리카의 수가 증가한 것도 볼 수 있다.
+그리고 다음과 같이 레플리카 수가 증가한 것도 볼 수 있다.
 ```
 NAME         REFERENCE                     TARGET      MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   305% / 50%  1         10        7          3m
 ```
 
 CPU 사용률이 305%까지 증가하였다.
-결과적으로, 디플로이먼트의 레플리카 개수가 7개까지 증가하였다.
+결과적으로, 디플로이먼트의 레플리카 수가 7개로 재조정이 이루어졌다.
 
 ```shell
 kubectl get deployment php-apache
@@ -177,20 +183,22 @@ php-apache   7/7      7           7           19m
 `busybox` 파드를 띄운 터미널에서,
 `<Ctrl> + C`로 부하 발생을 중단시킨다.
 
-그런 다음 (몇 분 후에) 결과를 확인한다.
+이후 (몇 분 정도 지나면) 결과를 확인한다.
 
 ```shell
 # 준비가 되면, 관찰을 마치기 위해 Ctrl+C를 누른다.
 kubectl get hpa php-apache --watch
 ```
 
 출력은 다음과 같다.
+
 ```
 NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
 php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
 ```
 
-디플로이먼트도 스케일 다운 했음을 볼 수 있다.
+디플로이먼트도 스케일 다운했음을 볼 수 있다.
+
 ```shell
 kubectl get deployment php-apache
 ```
@@ -200,15 +208,13 @@ NAME         READY   UP-TO-DATE   AVAILABLE   AGE
 php-apache   1/1     1            1           27m
 ```
 
-CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카의 개수를 1로 줄였다.
+CPU 사용량이 0으로 떨어져서, HPA가 자동으로 레플리카 수를 1로 줄였다.
 
-{{< note >}}
 레플리카 오토스케일링은 몇 분 정도 소요된다.
-{{< /note >}}
 
 <!-- discussion -->
 
-## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링
+## 다양한 메트릭 및 사용자 정의 메트릭에 기반한 오토스케일링
 
 `php-apache` 디플로이먼트를 오토스케일링할 때,
 `autoscaling/v2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다.
@@ -255,22 +261,32 @@ status:
 ```
 
 `targetCPUUtilizationPercentage` 필드가 `metrics` 배열로 대체되었다.
-CPU 사용량 메트릭은 *resource metric* 으로 파드 컨테이너 자원의 백분율로 표현된다.
-CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다.
-이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며,
-`metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다.
+CPU 사용량 메트릭은 *리소스 메트릭(resource metric)* 으로 파드 컨테이너 리소스의 
+백분율로 표현된다. CPU 외에 다른 메트릭도 지정할 수 있다. 기본적으로 
+지원되는 리소스 메트릭은 `memory`뿐이다. 이 리소스들은 한 클러스터에서 
+다른 클러스터로 이름을 변경할 수 없으며, `metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다.
+
+요청 값에 대한 백분율이 아니라 직접 값으로 리소스 메트릭을 지정할 수도 있는데, 
+`target.type`을 `Utilization` 대신 `AverageValue`로 설정하고, 
+`target.averageUtilization` 대신 `target.averageValue` 필드를 설정하면 된다.
 
-또한, `Utilization` 대신 `AverageValue`의 `target` 타입을,
-그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여
-자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다.
+```
+  metrics:
+  - type: Resource
+    resource:
+      name: memory
+      target:
+        type: AverageValue
+        averageValue: 500Mi
+```
 
-파드 메트릭과 오브젝트 메트릭 두 가지의 *사용자 정의 메트릭* 이 있다.
-파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며,
+*사용자 정의 메트릭*에는 파드 메트릭과 오브젝트 메트릭 두 가지가 있다.
+이 메트릭은 클러스터에 특화된 이름을 가지고 있으며,
 더 고급화된 클러스터 모니터링 설정이 필요하다.
 
-이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다.
-이 메트릭은 파드들을 설명하고, 파드들 간의 평균을 내며, 대상 값과 비교하여 레플리카 개수를 결정한다.
-이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, 자원 메트릭과 매우 유사하게 동작한다.
+이러한 대체 메트릭 타입 중 첫 번째는 *파드 메트릭* 이다.
+이 메트릭은 파드들을 설명하고, 파드들 간의 평균을 내며, 대상 값과 비교하여 레플리카 수를 결정한다.
+이것들은 `AverageValue` 타입의 `target`만을 지원한다는 것을 제외하면, 리소스 메트릭과 매우 유사하게 동작한다.
 
 파드 메트릭은 이처럼 메트릭 블록을 사용하여 정의된다.
 
@@ -286,10 +302,10 @@ pods:
 
 두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다.
 이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다.
-이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다.
-오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다.
-`Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다.
-`AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다.
+이 메트릭은 단지 오브젝트를 기술할 뿐이기에, 오브젝트로부터 반드시 가져와야 할 필요는 없다.
+오브젝트 메트릭은 `Value`와 `AverageValue` 두 가지 `target` 타입을 지원한다.
+`Value`를 사용할 경우 API로부터 반환되는 메트릭과 목표 값을 직접 비교된다.
+`AverageValue`를 사용할 경우, 사용자 정의 메트릭 API에서 반환된 값이 파드 수로 나누어진 후 목표 값과 비교된다.
 다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다.
 
 ```yaml
@@ -307,11 +323,11 @@ object:
 ```
 
 이러한 메트릭 블록을 여러 개 제공하면, HorizontalPodAutoscaler는 각 메트릭을 차례로 고려한다.
-HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수를 계산하고,
-그중 가장 높은 레플리카 개수를 선정한다.
+HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 수를 계산하고,
+그중 가장 높은 레플리카 수를 선정한다.
 
 예를 들어, 네트워크 트래픽 메트릭을 수집하는 모니터링 시스템이 있는 경우,
-`kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다.
+`kubectl edit` 명령어를 이용하여 위의 정의를 다음과 같이 업데이트할 수 있다.
 
 ```yaml
 apiVersion: autoscaling/v2
@@ -374,13 +390,13 @@ status:
         value: 10k
 ```
 
-이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지,
+이후, HorizontalPodAutoscaler는 각 파드가 요청된 약 50%의 CPU 사용률을 소모하는지,
 초당 1000 패킷을 처리하는지,
 메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다.
 
-### 보다 구체적인 메트릭을 기초로한 오토스케일링
+### 보다 구체적인 메트릭을 기반한 오토스케일링
 
-많은 메트릭 파이프라인들을 사용하면 이름 또는 _labels_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다.
+많은 메트릭 파이프라인들을 사용하면 이름 또는 _레이블(labels)_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다.
 그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해,
 메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다.
 예를 들면, `verb` 레이블로 `http_requests` 메트릭을 수집하는 경우,
@@ -398,26 +414,26 @@ object:
 모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우,
 해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다.
 셀렉터는 부가적인 속성이며,
-대상 오브젝트(`Pods` 타입의 대상 파드, `Object` 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다.
+대상 오브젝트(`Pods` 타입인 경우 대상 파드, `Object` 타입인 경우 기술된 오브젝트)가 **아닌** 메트릭을 선택할 수 없다.
 
-### 쿠버네티스 오브젝트와 관련이 없는 메트릭을 기초로한 오토스케일링
+### 쿠버네티스 오브젝트와 관련이 없는 메트릭을 기반한 오토스케일링
 
 쿠버네티스 위에서 동작하는 애플리케이션은, 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여
 오토스케일링을 할 수도 있다.
-예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다.
+예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기반으로 한 메트릭을 들 수 있다.
 쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다.
 
 외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다.
-이 설치는 사용자 정의 메트릭과 유사하다.
+설정 방식은 사용자 정의 메트릭을 사용할 때와 유사하다.
 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다.
 위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 명시하고,
 `Object` 대신에 `External` 메트릭 타입을 사용한다.
-만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다.
+만일 여러 시계열과 `metricSelector`이 일치하면, HorizontalPodAutoscaler는 해당 값의 합을 사용한다.
 외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고,
 `Object` 타입을 사용할 때와 똑같이 동작한다.
 
-예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우,
-다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다.
+예를 들면 애플리케이션이 호스팅된 대기열 서비스에서 작업을 처리하는 경우,
+다음과 같이 HorizontalPodAutoscaler 매니페스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다.
 
 ```yaml
 - type: External
@@ -443,7 +459,7 @@ HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 
 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지,
 어떤 방식으로든 제한되어 있는지 여부를 나타낸다.
 
-이 조건은 `status.conditions`에 나타난다.
+이 조건은 `status.conditions` 필드에 나타난다.
 HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다.
 
 ```shell
@@ -471,25 +487,25 @@ Conditions:
 Events:
 ```
 
-이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다.
-첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지,
-백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다.
-두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 개수가 0이 아닌지),
-원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우,
+이 HorizontalPodAutoscaler 경우, 여러 조건이 정상임을 확인할 수 있다.
+첫 번째 `AbleToScale`은 HPA가 스케일을 가져오고 업데이트할 수 있는지, 그리고 
+백오프(backoff)와 관련된 조건이 스케일링을 방해하고 있는지 여부를 나타낸다.
+두 번째 `ScalingActive`는 HPA가 활성화되어 있는지(즉 대상 레플리카 수가 0이 아닌지),
+원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False`인 경우,
 일반적으로 메트릭을 가져오는 데 문제가 있다.
 마지막으로, 마지막 조건인 `ScalingLimited`는
-원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다.
-이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다.
+원하는 스케일이 HorizontalPodAutoscaler의 최대값이나 최소값에 의해 제한되었음을 나타낸다.
+이는 HorizontalPodAutoscaler의 최소 또는 최대 레플리카 수 제약을 늘리거나 줄이는 것을 고려해야 함을 의미한다.
 
-## 수량
+## 수량(Quantities)
 
 HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
 쿠버네티스에서 사용하는
-{{< glossary_tooltip term_id="quantity" text="수량">}} 숫자 표기법을 사용한다.
-예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다.
+{{< glossary_tooltip term_id="quantity" text="수량(quantity)">}} 숫자 표기법을 사용한다.
+예를 들면, `10500m` 수량은 10진법 `10.5`로 쓰인다.
 메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며,
 일반적으로 수량을 밀리단위로 반환한다.
-10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다.
+이것은 메트릭 값이 `1`과 `1500m` 사이에서 변동하는 것을 볼 수 있으며, 10진수 표기법으로는 `1`과 `1.5` 사이에서 변동하는 것으로 나타난다는 뜻이다.
 
 ## 다른 가능한 시나리오
 
@@ -498,7 +514,7 @@ HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은
 HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고,
 명시적으로 다음 매니페스트를 사용하여 만들 수 있다.
 
-{{< codenew file="application/hpa/php-apache.yaml" >}}
+{{% code_sample file="application/hpa/php-apache.yaml" %}}
 
 다음으로, 아래의 명령어를 실행하여 오토스케일러를 생성한다.