Merge pull request #28577 from jihoon-seo/210623_Update_outdated_files_in_dev-1.21-ko.5

[ko] Update outdated files in dev-1.21-ko.5 (p3)

Author: k8s-ci-robot

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

@@ -1,4 +1,10 @@
 ---
+
+
+
+
+
+
 title: 데몬셋
 content_type: concept
 weight: 40
@@ -26,7 +32,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
 
 ### 데몬셋 생성
 
-YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
+YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 
+fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다.
 
 {{< codenew file="controllers/daemonset.yaml" >}}
 
@@ -40,19 +47,23 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
 일반적인 설정파일 작업에 대한 정보는
-[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/),
-[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
+[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
+ [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
 
 데몬셋 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다.
+데몬셋에는 
+[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 
+섹션도 필요하다.
 
 ### 파드 템플릿
 
 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
 
-`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
+`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 
+이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 
+{{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다.
 
 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
 한다([파드 셀렉터](#파드-셀렉터)를 본다).
@@ -73,19 +84,22 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 
 `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다.
 
-* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다.
+* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 
+`.spec.selector` 와 동일하게 작동한다.
 * `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를
   명시해서 보다 정교한 셀렉터를 만들 수 있다.
 
 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다.
 
-만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다.
+만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 
+일치하지 않는 구성은 API에 의해 거부된다.
 
 ### 오직 일부 노드에서만 파드 실행
 
 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
-일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면
+일치하는 노드에 파드를 생성한다. 
+마찬가지로 `.spec.template.spec.affinity` 를 명시하면
 데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다.
 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다.
 
@@ -100,18 +114,19 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다.
 이에 대한 이슈를 소개한다.
 
- * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
-   그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
-   이것은 사용자에게 혼란을 준다.
- * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은
-   기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
-   파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
+* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다.
+  그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다.
+  이것은 사용자에게 혼란을 준다.
+* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은
+  기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는
+  파드 우선순위와 선점을 고려하지 않고 스케줄 한다.
 
 `ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신
 `NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본
 스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본
 스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에
-이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
+이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 
+원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는
 데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며,
 데몬셋의 `spec.template` 은 변경되지 않는다.
 
@@ -152,10 +167,12 @@ nodeAffinity:
 
 - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
   구성되어있다. 그들은 클라이언트들을 가지지 않는다.
-- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
+- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 
+  노드IP를 통해 파드에 접근할 수 있다. 
+  클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
 - **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고,
-  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를
-  검색한다.
+  그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 
+  DNS에서 여러 A레코드를 검색한다.
 - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서
   임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다).
 

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

@@ -304,7 +304,7 @@ spec:
 
 ### 완료된 잡을 위한 TTL 메커니즘
 
-{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
 
 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은
 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해
@@ -342,11 +342,6 @@ spec:
 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된
 후에 TTL 컨트롤러에 의해 정리되지 않는다.
 
-이 TTL 메커니즘은 기능 게이트 `TTLAfterFinished`와 함께 알파 단계이다. 더
-자세한 정보는 완료된 리소스를 위한
-[TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)
-문서를 본다.
-
 ## 잡 패턴
 
 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다.  잡 오브젝트는 과학

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

@@ -86,7 +86,7 @@ weight: 60
 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다.
 클러스터 관리자 또는 호스팅 공급자는
 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다.
-파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/configuration/pod-priority-preemption/)와 같은 특정 환경설정 옵션
+파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)와 같은 특정 환경설정 옵션
 또한 자발적(+ 비자발적) 중단을 유발할 수 있다.
 
 

content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md

@@ -15,7 +15,7 @@ obsolete -->
 {{< note >}}
 v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면
 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와
-[스케줄러](/docs/reference/generated/kube-scheduler/)에서
+[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서
 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화해야 한다
 {{< /note >}}

content/ko/docs/contribute/suggesting-improvements.md

@@ -10,7 +10,7 @@ card:
 
 <!-- overview -->
 
-쿠버네티스 문서에 문제가 있거나, 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다.
+쿠버네티스 문서의 문제를 발견하거나 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다.
 
 대부분의 경우, 쿠버네티스 문서에 대한 새로운 작업은 GitHub의 이슈로 시작된다. 그런 다음
 쿠버네티스 기여자는 필요에 따라 이슈를 리뷰, 분류하고 태그를 지정한다. 다음으로, 여러분이나
@@ -22,7 +22,7 @@ card:
 
 ## 이슈 열기
 
-기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다.
+기존 콘텐츠에 대한 개선을 제안하고 싶거나 오류를 발견하면, 이슈를 연다.
 
 1. 오른쪽 사이드바에서 **문서에 이슈 생성** 링크를 클릭한다. 그러면 헤더가
  미리 채워진 GitHub 이슈 페이지로 리디렉션된다.

content/ko/docs/reference/_index.md

@@ -37,7 +37,7 @@ no_list: true
 - [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python)
 - [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java)
 - [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript)
-- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
+- [쿠버네티스 C# 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp)
 - [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell)
 
 ## CLI

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

@@ -53,7 +53,7 @@ weight: 50
 1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다.
 1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다.
 1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다.
-1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다.
+1. 파드에 `imagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다.
 
 #### 바인딩된 서비스 어카운트 토큰 볼륨
 
@@ -86,14 +86,14 @@ weight: 50
 프로젝티드 볼륨은 세 가지로 구성된다.
 
 1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.
-1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`이 활성화되어 있어야 동작한다. `RootCAConfigMap`은 1.20에서 기본적으로 활성화되어 있으며, 1.21 이상에서는 항상 활성화된 상태이다.
+1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`에 의해 동작한다. `RootCAConfigMap` 기능 게이트는 1.21에서 GA로 전환되었으며 기본적으로 활성화되어 있다. (이 플래그는 1.22에서 `--feature-gate` 인자에서 제외될 예정이다.)
 1. 파드의 네임스페이스를 참조하는 DownwardAPI.
 
 상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.
 
 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, 
-위의 프로젝티드 볼륨을 파드 스펙에 추가하여 시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
-그러나, `RootCAConfigMap`은 활성화되어 있어야 한다.
+위의 프로젝티드 볼륨을 파드 스펙에 추가하여 
+시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
 
 ### 토큰 컨트롤러