Merge pull request #26643 from ysyukr/dev-1.20-ko.5-outdated-part-03

Update to Outdated files in dev-1.20-ko.5 branch (3)

Author: k8s-ci-robot

content/ko/docs/tasks/administer-cluster/change-default-storage-class.md

@@ -32,7 +32,7 @@ content_type: task
 수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
 하여 스토리지의 동적 프로비저닝을 방지할 수 있다.
 
-단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
+기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동 중인
 애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
 및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.
 

content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md

@@ -9,18 +9,13 @@ weight: 100
 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 
 사용하는 파드를 생성하는 방법을 보여준다.
 
-
-
 ## {{% heading "prerequisites" %}}
 
-
 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
 * 이 실습을 수행하기 위해, 
 [도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.
 
-
-
 <!-- steps -->
 
 ## 도커 로그인
@@ -106,7 +101,8 @@ kubectl create secret docker-registry regcred --docker-server=<your-registry-ser
 
 아래의 각 항목에 대한 설명을 참고한다.
 
-* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다. (도커허브(DockerHub)의 경우, https://index.docker.io/v1/)
+* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다.
+  도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다.
 * `<your-name>` 은 도커 사용자의 계정이다.
 * `<your-pword>` 은 도커 사용자의 비밀번호이다.
 * `<your-email>` 은 도커 사용자의 이메일 주소이다.
@@ -192,7 +188,8 @@ your.private.registry.example.com/janedoe/jdoe-private:v1
 ```
 
 프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다.
-구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 `regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
+구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가
+`regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
 
 시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자.
 
@@ -201,16 +198,11 @@ kubectl apply -f my-private-reg-pod.yaml
 kubectl get pod private-reg
 ```
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
 * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
 * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
 * [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
 * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.
-
-

content/ko/docs/tasks/configure-pod-container/static-pod.md

@@ -22,6 +22,7 @@ Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버
 생성하려고 자동으로 시도한다.
 즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
 API 서버에서 제어될 수는 없다.
+파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.
 
 {{< note >}}
 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여

content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md

@@ -22,7 +22,7 @@ content_type: task
 
 ## kubectl 플러그인 설치
 
-플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
+플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
 
 [Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한
 kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
@@ -57,9 +57,9 @@ Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사
 
 플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
 `kubectl` 바이너리에서 상속된 환경을 받는다.
-플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를
-들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이
-`kubectl-foo` 이고, `PATH` 의 어딘가에 있다.
+플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다.
+예를 들어, `kubectl-foo` 라는 플러그인은 `kubectl foo` 명령을 제공한다.
+`PATH` 어딘가에 플러그인 실행 파일을 설치해야 한다.
 
 ### 플러그인 예제
 
@@ -85,30 +85,31 @@ echo "I am a plugin named kubectl-foo"
 
 ### 플러그인 사용
 
-위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다.
+플러그인을 사용하려면, 실행 가능하게 만든다.
 
-```
+```shell
 sudo chmod +x ./kubectl-foo
 ```
 
 그리고 `PATH` 의 어느 곳에나 옮겨 놓는다.
 
-```
+```shell
 sudo mv ./kubectl-foo /usr/local/bin
 ```
 
 이제 플러그인을 `kubectl` 명령으로 호출할 수 있다.
 
-```
+```shell
 kubectl foo
 ```
+
 ```
 I am a plugin named kubectl-foo
 ```
 
 모든 인수와 플래그는 그대로 실행 파일로 전달된다.
 
-```
+```shell
 kubectl foo version
 ```
 ```
@@ -120,6 +121,7 @@ kubectl foo version
 ```bash
 export KUBECONFIG=~/.kube/config
 kubectl foo config
+
 ```
 ```
 /home/<user>/.kube/config
@@ -128,6 +130,7 @@ kubectl foo config
 ```shell
 KUBECONFIG=/etc/kube/config kubectl foo config
 ```
+
 ```
 /etc/kube/config
 ```
@@ -373,11 +376,8 @@ kubectl 플러그인의 배포 패키지를
 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
 더 쉬워진다.
 
-
-
 ## {{% heading "whatsnext" %}}
 
-
 * Go로 작성된 플러그인의
   [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
   샘플 CLI 플러그인 리포지터리를 확인한다.

content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md

@@ -35,7 +35,7 @@ weight: 30
 
 ## 메시지 대기열 서비스 시작
 
-이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
+이 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 유형의 메시지 서비스를 사용하도록 예시를 조정할 수 있다.
 
 실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
 구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.

content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md

@@ -12,7 +12,7 @@ weight: 20
 있다.
 
 이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
-샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
+샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
 
 이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
 [실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.

content/ko/docs/tasks/job/parallel-processing-expansion.md

@@ -60,7 +60,7 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
 
 ### 스테이트풀셋의 완벽한 삭제
 
-연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다.
+연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다.
 
 ```shell
 grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')

content/ko/docs/tasks/run-application/delete-stateful-set.md

@@ -190,7 +190,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
 `kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
 마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
 
-또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
+또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
 예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
 실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
 그리고 2와 5 사이의 레플리카 개수로 설정된다.
@@ -220,9 +220,10 @@ v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의
 v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
 필요성을 제거하였다.
 
-- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은
-  오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을
-  수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다.
+- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
+  안정화되기까지의 시간 간격을 지정한다.
+  Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
+  이 시간 간격에서의 가장 큰 크기에서만 작동한다.
   기본값은 5분(`5m0s`)이다.
 
 {{< note >}}
@@ -382,18 +383,19 @@ behavior:
       periodSeconds: 60
 ```
 
-파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
+`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
+첫 번째 정책은 _(파드들)_ 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
+두 번째 정책은 _비율_ 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
+
+기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은
+파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다.
 예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
 경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
 다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
 각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40
 미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
 4개의 레플리카가 줄어든다.
 
-`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
-첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
-두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
-
 확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
 레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
 값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
@@ -440,7 +442,7 @@ behavior:
       periodSeconds: 15
     selectPolicy: Max
 ```
-안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
+안정화 윈도우의 스케일링 다운의 경우 _300_ 초 (또는 제공된
 경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
 실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
 대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.

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

@@ -65,6 +65,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
 
         kubectl describe deployment mysql
 
+    출력은 다음과 유사하다.
+
         Name:                 mysql
         Namespace:            default
         CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
@@ -105,13 +107,17 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로
 
         kubectl get pods -l app=mysql
 
+    출력은 다음과 유사하다.
+
         NAME                   READY     STATUS    RESTARTS   AGE
         mysql-63082529-2z3ki   1/1       Running   0          3m
 
 1. 퍼시스턴트볼륨클레임을 살펴본다.
 
         kubectl describe pvc mysql-pv-claim
 
+    출력은 다음과 유사하다.
+
         Name:         mysql-pv-claim
         Namespace:    default
         StorageClass: