Merge pull request #27576 from jihoon-seo/210416_Update_outdated_files_in_dev-1.21-ko.1_p4

[ko] Update outdated files in dev-1.21-ko.1 (p4)

Author: k8s-ci-robot

content/ko/docs/concepts/workloads/controllers/replicaset.md

@@ -222,7 +222,7 @@ pod2             1/1     Running   0          36s
 ## 레플리카셋 매니페스트 작성하기
 
 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
-레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다.
+레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
 쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
 API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
 
@@ -237,7 +237,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
 
-템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
+템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
 
 ### 파드 셀렉터
@@ -307,9 +307,51 @@ curl -X DELETE  'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
 
 ### 레플리카셋의 스케일링
 
-레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트 하면 된다.
+레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트하면 된다.
 레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다.
 
+스케일 다운할 때, 레플리카셋 컨트롤러는 스케일 다운할 파드의 
+우선순위를 정하기 위해 다음의 기준으로 가용 파드를 정렬하여 삭제할 파드를 결정한다.
+ 1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다.
+ 2. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는 
+    파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다.
+ 3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다.
+ 4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가 
+    이전에 생성된 파드보다 먼저 스케일 다운된다. 
+    (`LogarithmicScaleDown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다)
+    
+모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
+
+### 파드 삭제 비용
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, 
+레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.
+
+이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
+이 어노테이션은 하나의 레플리카셋에 있는 다른 파드와의 상대적 삭제 비용을 나타낸다.
+삭제 비용이 낮은 파드는 삭제 비용이 높은 파드보다 삭제 우선순위가 높다.
+
+파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
+유효하지 않은 값은 API 서버가 거부한다.
+
+이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. 
+kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
+
+{{< note >}}
+- 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
+- 이 값을 자주 바꾸는 것은 피해야 한다 (예: 메트릭 값에 따라 변경). 
+apiserver에서 많은 양의 파드 업데이트를 동반하기 때문이다.
+{{< /note >}}
+
+#### 사용 예시
+한 애플리케이션 내의 여러 파드는 각각 사용률이 다를 수 있다. 스케일 다운 시, 
+애플리케이션은 사용률이 낮은 파드를 먼저 삭제하고 싶을 수 있다. 파드를 자주 
+업데이트하는 것을 피하기 위해, 애플리케이션은 `controller.kubernetes.io/pod-deletion-cost` 값을 
+스케일 다운하기 전에 1회만 업데이트해야 한다 (파드 사용률에 비례하는 값으로 설정).
+이 방식은 Spark 애플리케이션의 드라이버 파드처럼 애플리케이션이 스스로 다운스케일링을 수행하는 경우에 유효하다.
+
 ### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정
 
 레플리카셋은

content/ko/docs/concepts/workloads/controllers/replicationcontroller.md

@@ -54,7 +54,9 @@ kubectl 명령에서 숏컷으로 사용된다.
 ```shell
 kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 replicationcontroller/nginx created
 ```
@@ -64,7 +66,9 @@ replicationcontroller/nginx created
 ```shell
 kubectl describe replicationcontrollers/nginx
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 Name:        nginx
 Namespace:   default
@@ -103,22 +107,24 @@ Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
 pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
 echo $pods
 ```
+
 출력 결과는 다음과 같다.
+
 ```
 nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 ```
 
 여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고,
-다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은
-반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다.
+다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
+반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
 
 
 ## 레플리케이션 컨트롤러의 Spec 작성
 
 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
 레플리케이션 컨트롤러 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
+환경설정 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
 
 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
 
@@ -198,7 +204,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
 
 ### 레플리케이션 컨트롤러에서 파드 격리
 
-파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅, 데이터 복구 등을 위해 서비스에서 파드를 제거하는데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
+파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정).
 
 ## 일반적인 사용법 패턴
 
@@ -208,8 +214,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
 
 ### 스케일링
 
-레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다.
-레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다.
+레플리케이션컨트롤러는 `replicas` 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다.
 
 ### 롤링 업데이트
 
@@ -246,7 +251,6 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리
 
 레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다.
 
-
 ## API 오브젝트
 
 레플리케이션 컨트롤러는 쿠버네티스 REST API의 최상위 수준의 리소스이다.
@@ -261,8 +265,7 @@ API 오브젝트에 대한 더 자세한 것은
 이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
 
-
-### 디플로이먼트 (권장되는)
+### 디플로이먼트 (권장됨)
 
 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다.
 

content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md

@@ -6,17 +6,17 @@ weight: 70
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
 
 TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}만
 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
 처리하도록 확장될 수 있다.
 
-알파(Alpha) 고지 사항: 이 기능은 현재 알파이고,
-kube-apiserver와 kube-controller-manager와 함께
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다.
+이 기능은 현재 베타이고 기본적으로 활성화되어 있다. 
+kube-apiserver와 kube-controller-manager에서 `TTLAfterFinished` 
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
 
 <!-- body -->
 

content/ko/docs/concepts/workloads/pods/disruptions.md

@@ -89,7 +89,7 @@ weight: 60
 
 ## 파드 disruption budgets
 
-{{< feature-state for_k8s_version="v1.5" state="beta" >}}
+{{< feature-state for_k8s_version="v1.21" state="stable" >}}
 
 쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을
 실행하는 데 도움이 되는 기능을 제공한다.

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -313,17 +313,16 @@ myapp-pod   1/1       Running   0          9m
 파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수
 있다.
 
-* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다.
-  Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너
-  이미지의 변경은 앱 컨테이너만 재시작시킨다.
-* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에
+* 파드 인프라스트럭처 컨테이너가 재시작된 상황. 이는 일반적인 상황이 아니며 노드에
   대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다.
-* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는,
-  동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집
-  때문에 유실되었다.
-
-
-
+* 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실된 상태에서, 
+  `restartPolicy`가 Always로 설정된 파드의 모든 컨테이너가 종료되어 
+  모든 컨테이너를 재시작해야 하는 상황
+
+초기화 컨테이너 이미지가 변경되거나 초기화 컨테이너의 완료 기록이 가비지 수집 
+때문에 유실된 상태이면 파드는 재시작되지 않는다. 이는 쿠버네티스 버전 1.20 이상에 
+적용된다. 이전 버전의 쿠버네티스를 사용하는 경우 해당 쿠버네티스 버전의 문서를 
+참고한다.
 
 ## {{% heading "whatsnext" %}}
 

content/ko/docs/concepts/workloads/pods/pod-lifecycle.md

@@ -312,8 +312,8 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
 
 {{< note >}}
-파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로,
-준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는
+파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
+준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는
 프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다.
 파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로
 남아 있다.

content/ko/docs/reference/_index.md

@@ -21,8 +21,6 @@ no_list: true
 
 * [표준 용어집](/ko/docs/reference/glossary/) -  포괄적이고, 표준화 된 쿠버네티스 용어 목록
 
-
-
 * [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/)
 * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
 * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요
@@ -50,16 +48,35 @@ no_list: true
 
 ## 컴포넌트
 
-* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
-* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API.
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 
+노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며 
+기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
+* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 
+파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 
+수행하는 REST API.
 * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬.
-* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다.
+* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 
+TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 
+할 수 있다.
 * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러.
 
-## 스케줄링
+  * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
+  * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)
+
+## 환경설정 API
+
+이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 
+"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를 
+사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 
+제공하지 않는다.
 
-* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies)
-* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles)
+* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
+* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
+* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
+* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
+* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
+* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
 
 ## 설계 문서
 

content/ko/docs/reference/access-authn-authz/service-accounts-admin.md

@@ -55,9 +55,9 @@ weight: 50
  1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
 
 #### 바인딩된 서비스 어카운트 토큰 볼륨
-{{< feature-state for_k8s_version="v1.13" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
 
-`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
+`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가
 시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다.
 
 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다.