Merge pull request #28061 from kubernetes/dev-1.21-ko.2

[ko] 2nd Korean localization work for v1.21

Author: k8s-ci-robot

content/ko/case-studies/ibm/ibm_featured_logo.svg

@@ -304,13 +304,6 @@ ConditionFalse 다.).
 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다.
 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다.
 
-
-{{< caution >}}
-`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는
-서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에
-사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다.
-{{< /caution >}}
-
 ### 노드 용량
 
 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의

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

@@ -45,7 +45,7 @@ no_list: true
 
 ## 클러스터 보안
 
-* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
+* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다.
 
 * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다.
 

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

@@ -170,4 +170,5 @@ 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/cluster-administration/system-metrics.md

@@ -50,11 +50,10 @@ terminated 또는 completed 상태인 경우에는 `PreStop` 훅 요청이 실
 ### 훅 핸들러 구현
 
 컨테이너는 훅의 핸들러를 구현하고 등록함으로써 해당 훅에 접근할 수 있다.
-구현될 수 있는 컨테이너의 훅 핸들러에는 세 가지 유형이 있다.
+구현될 수 있는 컨테이너의 훅 핸들러에는 두 가지 유형이 있다.
 
 * Exec - 컨테이너의 cgroups와 네임스페이스 안에서, `pre-stop.sh`와 같은, 특정 커맨드를 실행.
 커맨드에 의해 소비된 리소스는 해당 컨테이너에 대해 계산된다.
-* TCP - 컨테이너의 특정 포트에 대한 TCP 연결을 연다.
 * HTTP - 컨테이너의 특정 엔드포인트에 대해서 HTTP 요청을 실행.
 
 ### 훅 핸들러 실행

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

@@ -11,7 +11,7 @@ weight: 20
 이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
 
 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임
-구성은 파드의 컨테이너를 실행하는데 사용된다.
+구성은 파드의 컨테이너를 실행하는 데 사용된다.
 
 
 
@@ -21,7 +21,7 @@ weight: 20
 ## 동기
 
 서로 다른 파드간에 런타임클래스를 설정하여
-성능대 보안의 균형을 유지할 수 있다.
+성능과 보안의 균형을 유지할 수 있다.
 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
 그러면 몇가지 추가적인 오버헤드는 있지만
@@ -106,7 +106,8 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p
 
 #### dockershim
 
-쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
+dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다.
+dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
 
 #### {{< glossary_tooltip term_id="containerd" >}}
 

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

@@ -2,6 +2,10 @@
 title: 쿠버네티스 확장
 weight: 110
 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
+feature:
+  title: 확장성을 고려하여 설계됨
+  description: >
+    쿠버네티스 업스트림 소스 코드 수정 없이 쿠버네티스 클러스터에 기능을 추가할 수 있다.
 content_type: concept
 no_list: true
 ---
@@ -76,19 +80,18 @@ kubectl에서
 아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
 보여주는 다이어그램이다.
 
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vQBRWyXLVUlQPlp7BvxvV9S1mxyXSM6rAc_cbLANvKlu6kCCf-kGTporTMIeG5GZtUdxXz1xowN7RmL/pub?w=960&h=720">
-
 <!-- image source drawing https://docs.google.com/drawings/d/1muJ7Oxuj_7Gtv7HV9-2zJbOnkQJnjxq-v1ym_kZfB-4/edit?ts=5a01e054 -->
 
+![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png)
 
 ## 익스텐션 포인트
 
 이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
 
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
-
 <!-- image source diagrams: https://docs.google.com/drawings/d/1k2YdJgNTtNfW7_A8moIIkij-DmVgEhNrn3y2OODwqQQ/view -->
 
+![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png)
+
 1.   사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
 2.   apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다.
 3.   apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다.
@@ -99,11 +102,10 @@ kubectl에서
 
 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
 
-
-<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
-
 <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
 
+![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
+
 ## API 익스텐션
 ### 사용자 정의 유형