Merge pull request #25906 from kubernetes/dev-1.20-ko.1

Ko: 1st Korean l10n work for release-1.20

Author: k8s-ci-robot

content/ko/blog/_index.md

@@ -0,0 +1,16 @@
+---
+title: 쿠버네티스 블로그
+linkTitle: 블로그
+menu:
+  main:
+    title: "블로그"
+    weight: 40
+    post: >
+       <p>쿠버네티스와 컨테이너 전반적 영역에 대한 최신 뉴스도 읽고, 방금 나온 따끈따끈한 기술적 노하우도 알아보세요.</p>
+---
+{{< comment >}}
+
+블로그에 기여하는 방법에 대한 자세한 내용은
+https://kubernetes.io/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post 를 참고하세요.
+
+{{< /comment >}}

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

@@ -0,0 +1,104 @@
+---
+layout: blog
+title: "당황하지 마세요. 쿠버네티스와 도커"
+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
+
+쿠버네티스는 v1.20 이후 컨테이너 런타임으로서
+[도커를
+사용 중단(deprecating)](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)합니다.
+
+**당황할 필요는 없습니다. 말처럼 극적이진 않습니다.**
+
+요약하자면, 기본(underlying) 런타임 중 하나인 도커는 쿠버네티스의 [컨테이너 런타임 인터페이스(CRI)](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)를
+사용하는 런타임으로써는 더 이상 사용되지 않습니다(deprecated).
+도커가 생성한 이미지는 늘 그래왔듯이 모든 런타임을 통해 클러스터에서
+계속 작동될 것입니다.
+
+쿠버네티스의 엔드유저에게는 많은 변화가 없을 것입니다.
+이 내용은 도커의 끝을 의미하지 않으며, 도커를 더 이상 개발 도구로 사용할 수 없다거나,
+사용하면 안 된다는 의미도 아닙니다. 도커는 여전히 컨테이너를
+빌드하는 데 유용한 도구이며, `docker
+build` 실행 결과로 만들어진 이미지도 여전히 쿠버네티스 클러스터에서 동작합니다.
+
+GKE, EKS 또는 AKS([containerd가 기본](https://github.com/Azure/AKS/releases/tag/2020-11-16)인)와 같은 관리형 쿠버네티스 서비스를
+사용하는 경우 쿠버네티스의 향후 버전에서 도커에 대한 지원이
+없어지기 전에, 워커 노드가 지원되는 컨테이너 런타임을 사용하고 있는지 확인해야 합니다. 노드에
+사용자 정의가 적용된 경우 사용자 환경 및 런타임 요구 사항에 따라 업데이트가 필요할 수도
+있습니다. 서비스 공급자와 협업하여 적절한 업그레이드
+테스트 및 계획을 확인하세요.
+
+자체 클러스터를 운영하는 경우에도, 클러스터의 고장을 피하기 위해서
+변경을 수행해야 합니다. v1.20에서는 도커에 대한 지원 중단 경고(deprecation warning)가 표시됩니다.
+도커 런타임 지원이 쿠버네티스의 향후 릴리스(현재는 2021년 하반기의
+1.22 릴리스로 계획됨)에서 제거되면 더 이상 지원되지
+않으며, containerd 또는 CRI-O와 같은 다른 호환 컨테이너 런타임 중
+하나로 전환해야 합니다. 선택한 런타임이 현재 사용 중인
+도커 데몬 구성(예: 로깅)을 지원하는지 확인하세요.
+
+## 많은 사람들이 걱정하는 이유는 무엇이며, 왜 이런 혼란이 야기되었나요?
+
+우리는 여기서 두 가지 다른 환경에 대해 이야기하고 있는데, 이것이 혼란을 야기하고
+있습니다. 쿠버네티스 클러스터 내부에는 컨테이너 이미지를 가져오고
+실행하는 역할을 하는 컨테이너 런타임이라는 것이 있습니다. 도커를
+컨테이너 런타임(다른 일반적인 옵션에는 containerd 및 CRI-O가 있음)으로 많이
+선택하지만, 도커는 쿠버네티스 내부에 포함(embedded)되도록 설계되지 않았기에 문제를
+유발합니다.
+
+우리가 "도커"라고 부르는 것은 실제로는 하나가 아닙니다. 도커는
+전체 기술 스택이고, 그 중 한 부분은 그 자체로서 고수준(high-level)의
+컨테이너 런타임인 "containerd" 입니다. 도커는 개발을 하는 동안
+사람이 정말 쉽게 상호 작용할 수 있도록 많은 UX 개선을 포함하므로
+도커는 멋지고 유용합니다. 하지만, 쿠버네티스는 사람이 아니기 때문에
+이런 UX 개선 사항들이 필요하지 않습니다.
+
+이 인간 친화적인 추상화 계층의 결과로, 쿠버네티스 클러스터는
+containerd가 정말 필요로 하는 것들을 확보하기 위해서 도커심(Dockershim)이라는
+다른 도구를 사용해야 합니다. 이것은 좋지 않습니다. 왜냐하면, 이는 추가적인 유지 관리를
+필요로 하고 오류의 가능성도 높이기 때문입니다. 여기서 실제로 일어나는 일은
+도커심이 빠르면 v1.23 릴리스에 Kubelet에서 제거되어, 결과적으로
+도커에 대한 컨테이너 런타임으로서의 지원이 제거된다는 것입니다. 여러분
+스스로도 생각할 수 있을 것입니다. containerd가 도커 스택에 포함되어 있는 것이라면, 도커심이
+쿠버네티스에 왜 필요할까요?
+
+도커는 [컨테이너 런타임 인터페이스](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)인 CRI를 준수하지 않습니다.
+만약 이를 준수했다면, 심(shim)이 필요하지 않았을 것입니다. 그러나
+이건 세상의 종말이 아니며, 당황할 필요도 없습니다. 여러분은 단지
+컨테이너 런타임을 도커에서 지원되는 다른 컨테이너 런타임으로 변경하기만 하면 됩니다.
+
+참고할 사항 한 가지: 현재 클러스터 내 워크플로의 일부가 기본 도커 소켓
+(/var/run/docker.sock)에 의존하고 있는 경우, 다른
+런타임으로 전환하는 것은 해당 워크플로의 사용에 문제를 일으킵니다. 이 패턴은 종종
+도커 내의 도커라고 합니다. 이런 특정 유스케이스에 대해서
+[kaniko](https://github.com/GoogleContainerTools/kaniko),
+[img](https://github.com/genuinetools/img)와
+[buildah](https://github.com/containers/buildah)
+같은 것들을 포함해 많은 옵션들이 있습니다.
+
+## 그렇지만, 이 변경이 개발자에게는 어떤 의미인가요? 여전히 Dockerfile을 작성나요? 여전히 도커로 빌드하나요?
+
+이 변경 사항은 사람들(folks)이 보통 도커와 상호 작용하는 데 사용하는 것과는 다른 환경을
+제시합니다. 개발에 사용하는 도커의 설치는 쿠버네티스 클러스터 내의
+도커 런타임과 관련이 없습니다. 혼란스럽죠, 우리도 알고 있습니다. 개발자에게
+도커는 이 변경 사항이 발표되기 전과 마찬가지로 여전히
+유용합니다. 도커가 생성하는 이미지는 실제로는
+도커에만 특정된 이미지가 아니라 OCI([Open Container Initiative](https://opencontainers.org/)) 이미지입니다.
+모든 OCI 호환 이미지는 해당 이미지를 빌드하는 데 사용하는 도구에 관계없이 
+쿠버네티스에서 동일하게 보입니다. [containerd](https://containerd.io/)와
+[CRI-O](https://cri-o.io/)는 모두 해당 이미지를 가져와 실행하는 방법을 알고 있습니다. 이것이
+컨테이너가 어떤 모습이어야 하는지에 대한 표준이 있는 이유입니다.
+
+변경은 다가오고 있습니다. 이 변경이 일부 문제를 일으킬 수도 있지만, 치명적이지는
+않으며, 일반적으로는 괜찮은 일입니다. 사용자가 쿠버네티스와 상호 작용하는
+방식에 따라 이 변경은 아무런 의미가 없거나 약간의 작업만을 의미할 수 있습니다.
+장기적으로는 일이 더 쉬워질 것입니다. 이것이 여전히
+혼란스럽더라도 괜찮습니다. 이에 대해서 많은 일이 진행되고 있습니다. 쿠버네티스에는 변화되는
+부분이 많이 있고, 이에 대해 100% 전문가는 없습니다. 경험 수준이나
+복잡성에 관계없이 어떤 질문이든 하시기 바랍니다! 우리의 목표는
+모든 사람이 다가오는 변경 사항에 대해 최대한 많은 교육을 받을 수 있도록 하는 것입니다. `<3` 이 글이
+여러분이 가지는 대부분의 질문에 대한 답이 되었고, 불안을 약간은 진정시켰기를 바랍니다!
+
+더 많은 답변을 찾고 계신가요? 함께 제공되는 [도커심 사용 중단 FAQ](/blog/2020/12/02/dockershim-faq/)를 확인하세요.

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

@@ -327,6 +327,26 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 자세한 내용은
 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다.
 
+## 그레이스풀(Graceful) 노드 셧다운
+
+{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
+
+`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다.
+Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다.
+
+`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다.
+
+1. 노드에서 실행 중인 일반 파드를 종료시킨다.
+2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
+
+그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
+* `ShutdownGracePeriod`:
+  * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
+* `ShutdownGracePeriodCriticalPods`:
+  * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다.
+
+예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다.
+
 
 ## {{% heading "whatsnext" %}}
 
@@ -335,3 +355,4 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
 * 아키텍처 디자인 문서의 [노드](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
   섹션을 읽어본다.
 * [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 읽어본다.
+

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

@@ -17,7 +17,7 @@ weight: 70
 
 ## 이미지 수집
 
-쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 
+쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의
 라이프사이클을 관리한다.
 
 이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다:
@@ -36,26 +36,26 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 
 ## 사용자 설정
 
-사용자는 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
+여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다.
 
 1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로
 기본값은 85% 이다.
 2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로
 기본값은 80% 이다.
 
-또한 사용자는 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의 할 수 있다.
+다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다.
 
-1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집 
-되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다. 
+1. `minimum-container-ttl-duration`, 종료된 컨테이너가 가비지 수집
+되기 전의 최소 시간. 기본 값은 0 분이며, 이 경우 모든 종료된 컨테이너는 바로 가비지 수집의 대상이 된다.
 2. `maximum-dead-containers-per-container`, 컨테이너가 보유할 수 있는 오래된
 인스턴스의 최대 수. 기본 값은 1 이다.
 3. `maximum-dead-containers`, 글로벌하게 보유 할 컨테이너의 최대 오래된 인스턴스의 최대 수.
 기본 값은 -1이며, 이 경우 인스턴스 수의 제한은 없다.
 
 컨테이너들은 유용성이 만료되기 이전에도 가비지 수집이 될 수 있다. 이러한 컨테이너들은
-문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도 
-1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container` 
-값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers` 
+문제 해결에 도움이 될 수 있는 로그나 다른 데이터를 포함하고 있을 수 있다. 컨테이너 당 적어도
+1개의 죽은 컨테이너가 허용될 수 있도록 `maximum-dead-containers-per-container`
+값을 충분히 큰 값으로 지정하는 것을 권장한다. 동일한 이유로 `maximum-dead-containers`
 의 값도 상대적으로 더 큰 값을 권장한다.
 자세한 내용은 [해당 이슈](https://github.com/kubernetes/kubernetes/issues/13287)를 참고한다.
 
@@ -82,5 +82,3 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 
 
 자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다.
-
-

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

@@ -55,11 +55,12 @@ weight: 50
 주로 호환된다. 잡이 이전에 VM에서 실행된 경우, VM에 IP가 있고
 프로젝트의 다른 VM과 통신할 수 있다. 이것은 동일한 기본 모델이다.
 
-쿠버네티스의 IP 주소는 그것의 IP 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
+쿠버네티스의 IP 주소는 그것의 IP 주소와 MAC 주소를 포함하여 `Pod` 범위에 존재한다(`Pod` 내
 컨테이너는 네트워크 네임스페이스를 공유함). 이것은 `Pod` 내 컨테이너가 모두
 `localhost` 에서 서로의 포트에 도달할 수 있다는 것을 의미한다. 또한
 `Pod` 내부의 컨테이너 포트의 사용을 조정해야하는 것을 의미하지만, 이것도
-VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 한다.
+VM 내의 프로세스와 동일하다. 이것을 "IP-per-pod(파드별 IP)" 모델이라고 
+한다.
 
 이것이 어떻게 구현되는 지는 사용 중인 특정 컨테이너 런타임의 세부 사항이다.
 

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

@@ -128,6 +128,25 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"}
 cloudprovider_gce_api_request_duration_seconds { request = "list_disk"}
 ```
 
+### kube-scheduler 메트릭
+
+{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
+
+스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다.
+
+kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/ko/docs/concepts/configuration/manage-resources-containers/)을 식별한다. 요청 또는 제한이 0이 아닌 경우 kube-scheduler는 메트릭 시계열을 보고한다. 시계열에는 다음과 같은 레이블이 지정된다.
+- 네임스페이스
+- 파드 이름
+- 파드가 스케줄된 노드 또는 아직 스케줄되지 않은 경우 빈 문자열
+- 우선순위
+- 해당 파드에 할당된 스케줄러
+- 리소스 이름 (예: `cpu`)
+- 알려진 경우 리소스 단위 (예: `cores`)
+
+파드가 완료되면 (`Never` 또는 `OnFailure`의 `restartPolicy`가 있고 `Succeeded` 또는 `Failed` 파드 단계에 있거나, 삭제되고 모든 컨테이너가 종료된 상태에 있음) 스케줄러가 이제 다른 파드를 실행하도록 스케줄할 수 있으므로 시리즈가 더 이상 보고되지 않는다. 두 메트릭을 `kube_pod_resource_request` 및 `kube_pod_resource_limit` 라고 한다.
+
+메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트
+와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다.
 
 
 ## {{% heading "whatsnext" %}}

content/ko/docs/concepts/configuration/manage-resources-containers.md

@@ -600,6 +600,10 @@ spec:
         example.com/foo: 1
 ```
 
+## PID 제한
+
+프로세스 ID(PID) 제한은 kubelet의 구성에 대해 주어진 파드가 사용할 수 있는 PID 수를 제한할 수 있도록 허용한다. 자세한 내용은 [Pid 제한](/docs/concepts/policy/pid-limiting/)을 참고한다.
+
 ## 문제 해결
 
 ### 내 파드가 failedScheduling 이벤트 메시지로 보류 중이다