Merge pull request #22082 from kubernetes/dev-1.18-ko.6

Sixth Korean l10n work for release 1.18

content/ko/docs/concepts/_index.md

@@ -33,15 +33,15 @@ weight: 40
 * [파드](/ko/docs/concepts/workloads/pods/pod-overview/)
 * [서비스](/ko/docs/concepts/services-networking/service/)
 * [볼륨](/ko/docs/concepts/storage/volumes/)
-* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/)
+* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/)
 
 또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다.
 
-* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)
-* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/)
-* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/)
-* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/)
-* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
+* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)
+* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
+* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
+* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
+* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 
 ## 쿠버네티스 컨트롤 플레인
 
@@ -66,7 +66,6 @@ weight: 40
 
 
 개념 페이지를 작성하기를 원하면,
-개념 페이지 유형과 개념 템플릿에 대한 정보가 있는
-[페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다.
-
+개념 페이지 유형에 대한 정보가 있는
+[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다.
 

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

@@ -19,7 +19,6 @@ weight: 40
 
 
 
-
 <!-- body -->
 
 ## 디자인
@@ -31,6 +30,7 @@ weight: 40
 프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를
 구현한다.
 
+
 {{< note >}}
 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스
 {{< glossary_tooltip text="애드온" term_id="addons" >}}으로

content/ko/docs/concepts/architecture/control-plane-node-communication.md

@@ -15,7 +15,7 @@ aliases:
 <!-- body -->
 
 ## 노드에서 컨트롤 플레인으로의 통신
-노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다.
+쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다.
 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다.
 
 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다.
@@ -28,9 +28,11 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증
 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다.
 
 ## 컨트롤 플레인에서 노드로의 통신
+
 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다.
 
 ### API 서버에서 kubelet으로의 통신
+
 API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다.
 
 * 파드에 대한 로그를 가져온다.
@@ -58,9 +60,10 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로
 SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다.
 
 ### Konnectivity 서비스
+
 {{< feature-state for_k8s_version="v1.18" state="beta" >}}
 
-SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다.
-그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다.
+SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
+Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
 
-클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다.
+[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.

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

@@ -48,7 +48,7 @@ weight: 30
 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 
 상호 작용하며 상태를 관리한다.
 
-잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고, 
+잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 
 작업을 수행한 다음 중지하는 
 쿠버네티스 리소스 이다.
 

content/ko/docs/concepts/architecture/nodes.md

@@ -31,7 +31,8 @@ weight: 10
 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록
 2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가
 
-노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
+노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후
+컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다.
 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다.
 
 ```json
@@ -61,7 +62,8 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 노드 오브젝트를 명시적으로 삭제해야한다.
 {{< /note >}}
 
-노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
+노드 오브젝트의 이름은 유효한
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
 
 ### 노드에 대한 자체-등록
 
@@ -73,7 +75,9 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
   - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
   - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
   - `--register-node` - 자동으로 API 서버에 등록.
-  - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함.
+  - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록. 
+
+    `register-node`가 거짓이면 동작 안 함.
   - `--node-ip` - 노드의 IP 주소.
   - `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고).
   - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의.
@@ -188,6 +192,9 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다.
 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다.
 
+자세한 내용은
+[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다.
+
 ### 용량과 할당가능 {#capacity}
 
 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 
@@ -201,7 +208,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
 [컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을
 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.
 
-### 정보 {#info}
+### 정보
 
 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다.
 이 정보는 Kubelet에 의해 노드로부터 수집된다.
@@ -285,6 +292,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
 
+
 {{< caution >}}
 `kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
 서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
@@ -318,7 +326,6 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 `TopologyManager` 
 [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
-
 자세한 내용은
 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
 
@@ -331,4 +338,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
   섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다.
 * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다.
-

content/ko/docs/concepts/cluster-administration/cloud-providers.md

@@ -134,13 +134,13 @@ CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이
 GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다.
 참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함).
 
-## HUAWEI 클라우드
+## HUAWEI CLOUD
 
 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다.
 
 ### 노드 이름
 
-HUAWEI 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
+HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다.
 노드에서 kubelet을 시작할 때 반드시 `--hostname-override=<node private IP>` 를 사용한다.
 
 ## OpenStack
@@ -415,6 +415,7 @@ Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으
 참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다.
 
 ## Tencent 쿠버네티스 엔진
+
 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다.
 
 ### 노드 이름

content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md

@@ -78,7 +78,6 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 
 
 
-
 ## {{% heading "whatsnext" %}}
 
 

content/ko/docs/concepts/cluster-administration/manage-deployment.md

@@ -400,7 +400,7 @@ rm /tmp/nginx.yaml
 
 `kubectl patch` 를 사용하여 API 오브젝트를 인플레이스 업데이트할 수 있다. 이 명령은 JSON 패치,
 JSON 병합 패치 그리고 전략적 병합 패치를 지원한다.
-[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/run-application/update-api-object-kubectl-patch/)와
+[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)와
 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)를
 참조한다.
 

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

@@ -43,7 +43,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob
 컨피그맵의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
 
-## 컨피그맵과 파드(Pod)
+## 컨피그맵과 파드
 
 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를
 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은
@@ -157,7 +157,91 @@ spec:
 사용할 수도 있다.
 {{< /note >}}
 
+## 컨피그맵 사용하기
 
+컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로
+노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어,
+컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다.
+
+### 파드에서 컨피그맵을 파일로 사용하기
+
+파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
+
+1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
+1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다.
+1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
+1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
+
+다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: mypod
+spec:
+  containers:
+  - name: mypod
+    image: redis
+    volumeMounts:
+    - name: foo
+      mountPath: "/etc/foo"
+      readOnly: true
+  volumes:
+  - name: foo
+    configmap:
+      name: myconfigmap
+```
+
+사용하려는 각 컨피그맵은 `.spec.volumes` 에서 참조해야 한다.
+
+파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 `volumeMounts` 블록이 필요하지만,
+컨피그맵은 각 컨피그맵 당 하나의 `.spec.volumes` 만 필요하다.
+
+#### 마운트된 컨피그맵이 자동으로 업데이트
+
+현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다.
+kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다.
+그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다.
+캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의
+`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다.
+
+컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접
+모든 요청을 리디렉션할 수 있다.
+따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의
+총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시
+전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파
+지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함).
+
+{{< feature-state for_k8s_version="v1.18" state="alpha" >}}
+
+쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과
+컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게
+사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우
+데이터 변경을 방지하면 다음과 같은 이점이 있다.
+
+- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호
+- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴
+
+이 기능을 사용하려면 `ImmutableEmphemeralVolumes`
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고
+시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다.
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  ...
+data:
+  ...
+immutable: true
+```
+
+{{< note >}}
+컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나
+`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다.
+기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는
+것을 권장한다.
+{{< /note >}}
 
 ## {{% heading "whatsnext" %}}
 
@@ -167,4 +251,3 @@ spec:
 * 코드를 구성에서 분리하려는 동기를 이해하려면
   [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
 
-