Merge pull request #29237 from kubernetes/dev-1.21-ko.7

[ko] 7th Korean localization work for v1.21

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/scheduling-eviction/assign-pod-node.md

@@ -72,7 +72,7 @@ spec:
 ## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels}
 
 [붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는
-표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/labels-annotations-taints/)를 참고한다.
+표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다.
 
 {{< note >}}
 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다.