Merge pull request #26613 from kubernetes/dev-1.20-ko.4

ko: Fourth Korean l10n work for release-1.20

Author: k8s-ci-robot

content/ko/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -5,7 +5,9 @@ date: 2020-12-02
 slug: dont-panic-kubernetes-and-docker
 ---
 
-**작성자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+**저자:** Jorge Castro, Duffie Cooley, Kat Cosgrove, Justin Garrison, Noah Kantrowitz, Bob Killen, Rey Lejano, Dan “POP” Papandrea, Jeffrey Sica, Davanum “Dims” Srinivas
+
+**번역:** 박재화(삼성SDS), 손석호(한국전자통신연구원)
 
 쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
 [도커를

content/ko/docs/concepts/cluster-administration/system-metrics.md

@@ -1,9 +1,5 @@
 ---
-title: 쿠버네티스 컨트롤 플레인에 대한 메트릭
-
-
-
-
+title: 쿠버네티스 시스템 컴포넌트에 대한 메트릭
 content_type: concept
 weight: 60
 ---
@@ -12,7 +8,7 @@ weight: 60
 
 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다.
 
-쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
+쿠버네티스 컴포넌트의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다.
 이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다.
 
 <!-- body -->
@@ -36,7 +32,7 @@ weight: 60
 
 클러스터가 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}을 사용하는 경우, 메트릭을 읽으려면 `/metrics` 에 접근을 허용하는 클러스터롤(ClusterRole)을 가지는 사용자, 그룹 또는 서비스어카운트(ServiceAccount)를 통한 권한이 필요하다.
 예를 들면, 다음과 같다.
-```
+```yaml
 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRole
 metadata:
@@ -156,5 +152,4 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k
 ## {{% heading "whatsnext" %}}
 
 * 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다
-* [안정적인 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 참고한다
 * [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다

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

@@ -22,6 +22,16 @@ weight: 30
 명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
 일부 시크릿을 만들 수 있다.
 
+{{< caution >}}
+쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
+기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에 
+액세스할 수 있는 모든 사용자가 일반 텍스트로 검색 할 수 있다. 
+시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
+
+1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
+2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+{{< /caution >}}
+
 <!-- body -->
 
 ## 시크릿 개요
@@ -269,6 +279,13 @@ SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다.
 API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지
 검증도 한다.
 
+{{< caution >}}
+SSH 개인 키는 자체적으로 SSH 클라이언트와 호스트 서버간에 신뢰할 수있는 통신을 
+설정하지 않는다. ConfigMap에 추가된 `known_hosts` 파일과 같은 
+"중간자(man in the middle)" 공격을 완화하려면 신뢰를 설정하는 
+2차 수단이 필요하다.
+{{< /caution >}}
+
 ### TLS 시크릿
 
 쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서
@@ -786,7 +803,6 @@ immutable: true
 
 수동으로 생성된 시크릿(예: GitHub 계정에 접근하기 위한 토큰이 포함된 시크릿)은
 시크릿의 서비스 어카운트를 기반한 파드에 자동으로 연결될 수 있다.
-해당 프로세스에 대한 자세한 설명은 [파드프리셋(PodPreset)을 사용하여 파드에 정보 주입하기](/docs/tasks/inject-data-application/podpreset/)를 참고한다.
 
 ## 상세 내용
 
@@ -1233,3 +1249,4 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
 - [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
 - [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
 - [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
+

content/ko/docs/concepts/containers/container-lifecycle-hooks.md

@@ -54,7 +54,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
 
 컨테이너 라이프사이클 관리 훅이 호출되면,
 쿠버네티스 관리 시스템은 훅 동작에 따라 핸들러를 실행하고,
-`exec` 와 `tcpSocket` 은 컨테이너에서 실행되고, `httpGet` 은 kubelet 프로세스에 의해 실행된다.
+`httpGet` 와 `tcpSocket` 은 kubelet 프로세스에 의해 실행되고, `exec` 은 컨테이너에서 실행된다.
 
 훅 핸들러 호출은 해당 컨테이너를 포함하고 있는 파드의 컨텍스트와 동기적으로 동작한다.
 이것은 `PostStart` 훅에 대해서,

content/ko/docs/concepts/containers/runtime-class.md

@@ -1,7 +1,4 @@
 ---
-
-
-
 title: 런타임클래스(RuntimeClass)
 content_type: concept
 weight: 20
@@ -35,10 +32,6 @@ weight: 20
 
 ## 셋업
 
-런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다.
-기능 게이트 활성화에 대한 설명은 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-참고한다. `RuntimeClass` 기능 게이트는 API 서버 _및_ kubelets에서 활성화되어야 한다.
-
 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서).
 2. 상응하는 런타임클래스 리소스 생성.
 
@@ -144,11 +137,9 @@ https://github.com/containerd/cri/blob/master/docs/config.md
 
 {{< feature-state for_k8s_version="v1.16" state="beta" >}}
 
-쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터
-지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는
-노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면,
-[런타임 클래스 어드미션(admission) 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#runtimeclass)를
-활성화(1.16 부터 기본값)해야 한다.
+RuntimeClass에 `scheduling` 필드를 지정하면, 이 RuntimeClass로 실행되는 파드가 
+이를 지원하는 노드로 예약되도록 제약 조건을 설정할 수 있다.
+`scheduling`이 설정되지 않은 경우 이 RuntimeClass는 모든 노드에서 지원되는 것으로 간주된다.
 
 파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면,
 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다.

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

@@ -69,7 +69,7 @@ weight: 10
 웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다.
 *바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다.
 바이너리 플러그인은 kubelet(예:
-[Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
+[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과
 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
 kubectl에서
 사용한다.
@@ -157,7 +157,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 
 ### 스토리지 플러그인
 
-[Flex Volumes](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
+[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면
 Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써
 빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다.
 

content/ko/docs/concepts/services-networking/ingress-controllers.md

@@ -9,11 +9,11 @@ weight: 40
 
 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다.
 
-kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
+`kube-controller-manager` 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는
 클러스터와 함께 자동으로 실행되지 않는다.
 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다.
 
-프로젝트로써 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
+프로젝트로서 쿠버네티스는 [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme)와
   [nginx](https://git.k8s.io/ingress-nginx/README.md#readme) 인그레스 컨트롤러를 지원하고 유지한다.
 
 
@@ -26,6 +26,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 
 * [AKS 애플리케이션 게이트웨이 인그레스 컨트롤러] (https://azure.github.io/application-gateway-kubernetes-ingress/)는 [Azure 애플리케이션 게이트웨이](https://docs.microsoft.com)를 구성하는 인그레스 컨트롤러다.
 * [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Envoy](https://www.envoyproxy.io) 기반 인그레스
   컨트롤러다.
+* [Apache APISIX 인그레스 컨트롤러](https://github.com/apache/apisix-ingress-controller)는 [Apache APISIX](https://github.com/apache/apisix) 기반의 인그레스 컨트롤러이다.
 * [Avi 쿠버네티스 오퍼레이터](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes)는 [VMware NSX Advanced Load Balancer](https://avinetworks.com/)을 사용하는 L4-L7 로드 밸런싱을 제공한다.
 * [Citrix 인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller#readme)는
   Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
@@ -42,7 +43,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 
   기반 인그레스 컨트롤러다.
 * [쿠버네티스 용 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller#readme)는 [Kong 게이트웨이](https://konghq.com/kong/)를
   구동하는 인그레스 컨트롤러다.
-* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)는 [NGINX](https://www.nginx.com/resources/glossary)
+* [쿠버네티스 용 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx-ingress-controller/)는 [NGINX](https://www.nginx.com/resources/glossary/nginx/)
   웹서버(프록시로 사용)와 함께 작동한다.
 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 사용자의 커스텀 프록시를 구축하기 위한 라이브러리로 설계된 쿠버네티스 인그레스와 같은 유스케이스를 포함한 서비스 구성을 위한 HTTP 라우터 및 역방향 프록시다.
 * [Traefik 쿠버네티스 인그레스 제공자](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)는

content/ko/docs/concepts/services-networking/ingress.md

@@ -376,7 +376,7 @@ graph LR;
 트래픽을 일치 시킬 수 있다.
 
 예를 들어, 다음 인그레스는 `first.bar.com`에 요청된 트래픽을
-`service1`로, `second.foo.com`는 `service2`로, 호스트 이름이 정의되지
+`service1`로, `second.bar.com`는 `service2`로, 호스트 이름이 정의되지
 않은(즉, 요청 헤더가 표시 되지 않는) IP 주소로의 모든
 트래픽은 `service3`로 라우팅 한다.
 

content/ko/docs/concepts/services-networking/service.md

@@ -134,7 +134,7 @@ spec:
 * 한 서비스에서 다른
   {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 또는 다른 클러스터의 서비스를 지정하려고 한다.
 * 워크로드를 쿠버네티스로 마이그레이션하고 있다. 해당 방식을 평가하는 동안,
-  쿠버네티스에서는 일정 비율의 백엔드만 실행한다.
+  쿠버네티스에서는 백엔드의 일부만 실행한다.
 
 이러한 시나리오 중에서 파드 셀렉터 _없이_ 서비스를 정의 할 수 있다.
 예를 들면

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

@@ -13,7 +13,7 @@ weight: 50
 
 <!-- overview -->
 
-잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료되도록 한다.
+잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다.
 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다.  지정된 수의
 성공 완료에 도달하면, 작업(즉, 잡)이 완료된다.  잡을 삭제하면 잡이 생성한
 파드가 정리된다.