Merge pull request #29160 from seokho-son/out1-1.21-ko.7

[ko] Update outdated files in dev-1.21-ko.7 (p1)

Author: k8s-ci-robot

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -210,7 +210,7 @@ rules:
 
 자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가?
 
-클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다.
+클라우드 컨트롤러 매니저는 Go 인터페이스를 사용함으로써, 어떠한 클라우드에 대한 구현체(implementation)라도 플러그인 될 수 있도록 한다. 구체적으로는, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)에 정의된 `CloudProvider` 인터페이스를 사용한다.
 
 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다.
 

content/ko/docs/concepts/cluster-administration/logging.md

@@ -83,8 +83,11 @@ kubectl logs counter
 [`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
 자세히 알 수 있다.
 
-**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. kubelet은
-이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. 두 개의 kubelet 플래그 `container-log-max-size` 및 `container-log-max-files` 를 사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
+**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
+kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다.
+[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는
+두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를
+사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다.
 
 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를
 실행하면, 노드의 kubelet이 요청을 처리하고

content/ko/docs/concepts/configuration/secret.md

@@ -1156,8 +1156,8 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음,
 
 ### 시크릿 API를 사용하는 클라이언트
 
-시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, 
-[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 
+시크릿 API와 상호 작용하는 애플리케이션을 배포할 때,
+[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은
 [인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을
 사용하여 접근을 제한해야 한다.
 
@@ -1235,10 +1235,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
  - 시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다.
    API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
    시크릿을 노출하는 파드를 실행할 수 있다.
- - 현재, 모든 노드에 대한 루트 권한이 있는 모든 사용자는 kubelet을 가장하여
-   API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의
-   영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된
-   기능이다.
 
 
 ## {{% heading "whatsnext" %}}

content/ko/docs/concepts/extend-kubernetes/operator.md

@@ -51,8 +51,7 @@ weight: 30
 * 내부 멤버 선출 절차없이 분산 애플리케이션의
   리더를 선택
 
-오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는
-다음과 같다.
+오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 예시는 다음과 같다.
 
 1. 클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스.
 2. 오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을

content/ko/docs/concepts/storage/storage-classes.md

@@ -1,4 +1,9 @@
 ---
+
+
+
+
+
 title: 스토리지 클래스
 content_type: concept
 weight: 30
@@ -184,7 +189,7 @@ CSI | 1.14 (alpha), 1.16 (beta)
 CSI 드라이버에 대한 문서를 본다.
 
 {{< note >}}
-   `waitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다.
+   `WaitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다.
    만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다.
 
    대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다.

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

@@ -304,13 +304,23 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지
 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가
 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만
 트래픽을 받는다는 뜻이다.
-만약 컨테이너가 대량의 데이터, 설정 파일들,
-또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다.
 
-만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
+만약 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면,
 준비성 프로브를 지정하길 바란다.
 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
 
+만약 애플리케이션이 백엔드 서비스에 엄격한 의존성이 있다면,
+활성 프로브와 준비성 프로브 모두 활용할 수도 있다. 활성 프로브는 애플리케이션 스스로가 건강한 상태면
+통과하지만, 준비성 프로브는 추가적으로 요구되는 각 백-엔드 서비스가 가용한지 확인한다. 이를 이용하여,
+오류 메시지만 응답하는 파드로
+트래픽이 가는 것을 막을 수 있다.
+
+만약 컨테이너가 시동 시 대량 데이터의 로딩, 구성 파일, 또는
+마이그레이션에 대한 작업을
+수행해야 한다면, [스타트업 프로브](#언제-스타트업-프로브를-사용해야-하는가)를 사용하면 된다. 그러나, 만약
+failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있는 애플리케이션을 구분하여 탐지하고
+싶다면, 준비성 프로브를 사용하는 것이 더 적합할 것이다.
+
 {{< note >}}
 파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해
 준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는

content/ko/docs/reference/_index.md

@@ -9,6 +9,7 @@ content_type: concept
 no_list: true
 ---
 
+
 <!-- overview -->
 
 쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다.
@@ -48,26 +49,26 @@ no_list: true
 
 ## 컴포넌트
 
-* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 
-노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며 
+* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각
+노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며
 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다.
-* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 
-파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 
+* [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](/ko/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 
-TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 
+* [kube-proxy](/ko/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의 대부분은 아직 API 서버가 
+이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는
+"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를
+사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
 제공하지 않는다.
 
 * [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
@@ -78,6 +79,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
 * [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/)
 * [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/)
 
+## kubeadm을 위한 API 설정
+
+* [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/)
+
 ## 설계 문서
 
 쿠버네티스 기능에 대한 설계 문서의 아카이브.

content/ko/docs/reference/command-line-tools-reference/feature-gates.md

@@ -61,6 +61,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
 | `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
 | `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | |
+| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
 | `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
 | `CPUManager` | `true` | 베타 | 1.10 | |
 | `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
@@ -379,7 +380,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 | `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
 | `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
 | `TokenRequestProjection` | `true` | GA | 1.20 | - |
-| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
 | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
 | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
 | `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@@ -479,6 +479,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
   `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다.
   자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을
   확인한다.
+- `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가
+  kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면,
+  cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록
+  [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의
+  리더 마이그레이션(Leader Migration)을 활성화한다.
 - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
   [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
 - `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
@@ -637,7 +642,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
   어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
   이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
-- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로
+- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
   기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
   권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을
   사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스
@@ -764,6 +769,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다.
   자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다.
 - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다.
+  자세한 사항은
+  [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다.
 - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를
   활성화한다.
 - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)
@@ -794,6 +801,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 
 - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로
   설정하는 기능을 활성화한다.
   [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다.
+- `SizeMemoryBackedVolumes`: memory-backed 볼륨(보통 `emptyDir` 볼륨)의 크기 상한을
+  지정할 수 있도록 kubelets를 활성화한다.
 - `StartupProbe`: kubelet에서
   [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
   프로브를 활성화한다.

content/ko/docs/reference/glossary/kube-controller-manager.md

@@ -4,15 +4,15 @@ id: kube-controller-manager
 date: 2018-04-12
 full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/
 short_description: >
-  {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
+  컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
 
-aka: 
+aka:
 tags:
 - architecture
 - fundamental
 ---
- {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구동하는 마스터 상의 컴포넌트.
+ {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트.
 
-<!--more--> 
+<!--more-->
 
-논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.
+논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다.

content/ko/docs/reference/tools/_index.md

@@ -1,22 +1,17 @@
 ---
+title: 도구
 
 
-title: 도구
 content_type: concept
+weight: 80
+no_list: true
 ---
 
 <!-- overview -->
 쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
 
 
 <!-- body -->
-## Kubectl
-
-[`kubectl`](/ko/docs/tasks/tools/#kubectl)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다.
-
-## Kubeadm
-
-[`kubeadm`](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태).
 
 ## Minikube
 
@@ -31,8 +26,8 @@ content_type: concept
 
 ## Helm
 
-[`쿠버네티스 Helm`](https://github.com/kubernetes/helm)은 사전 구성된 쿠버네티스 리소스를 관리하기위한 도구이며
-또한 Helm의 쿠버네티스 차트라고도 한다.
+[Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다.
+이 패키지는 _Helm charts_ 라고 알려져 있다.
 
 Helm의 용도