Merge pull request #30749 from kubernetes/dev-1.22-ko.3

[ko] 3rd Korean localization work for v1.22
2021-12-05 21:16:33 -08:00
parent fdac57e01c e6359e23b1
commit 5014b9377a
95 changed files with 942 additions and 462 deletions
@@ -67,4 +67,4 @@ SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업
 SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다.
 Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다.
-[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
+[Konnectivity 서비스 태스크](/ko/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다.
@@ -72,15 +72,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록
 [이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는
 동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가
 동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한
-상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가
+상태(예: 네트워크 설정, 루트 디스크 내용)와 노드 레이블과 같은 동일한 속성(attribute)을
 갖는다고 암시적으로 가정한다. 인스턴스가
 이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나
 업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고
 업데이트 후 다시 추가해야 한다.
-### 노드에 대한 자체-등록
+### 노드에 대한 자체-등록(self-registration)
-kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에
+kubelet 플래그 `--register-node`가 참(기본값)일 경우, kubelet은 API 서버에
-스스로 등록을 시도할 것이다. 이는 대부분의 배포판에 의해 이용되는, 선호하는 패턴이다.
+스스로 등록을 시도할 것이다. 이는 선호되는 패턴이며, 대부분의 배포판에서 사용된다.
 자체-등록에 대해, kubelet은 다음 옵션과 함께 시작된다.
@@ -96,7 +97,22 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
 [Node authorization mode](/docs/reference/access-authn-authz/node/)와
 [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)이 활성화 되면,
-kubelets 은 자신의 노드 리소스를 생성/수정할 권한을 가진다.
+각 kubelet은 자신이 속한 노드의 리소스에 대해서만 생성/수정할 권한을 가진다.
 {{< note >}}
 [노드 이름 고유성](#노드-이름-고유성) 섹션에서 언급했듯이,
 노드 구성을 업데이트해야 하는 경우 API 서버에 노드를
 다시 등록하는 것이 좋다. 예를 들어 kubelet이 `--node-labels`의 새로운 구성으로
 다시 시작되더라도, 동일한 노드 이름이 사용된 경우
 레이블이 해당 노드의 등록에 설정되기 때문에 변경 사항이 적용되지 않는다.
 노드에 이미 스케줄된 파드는 해당 노드 구성이 kubelet 재시작에 의해 변경된 경우
 오작동하거나 문제를 일으킬 수 있다. 예를 들어 이미 실행 중인 파드가 노드에
 할당된 새 레이블에 대해 테인트(taint)될 수 있는 반면 해당 파드와 호환되지 않는 다른 파드는
 새 레이블을 기반으로 스케줄링된다. 노드 재등록(re-registration)은 모든 파드를
 비우고(drain) 다시 적절하게 스케줄링되도록
 한다.
 {{< /note >}}
 #### 수동 노드 관리
@@ -177,7 +193,8 @@ kubectl describe node <insert-node-name-here>
 대신 코드화된 노드는 사양에 스케줄 불가로 표시된다.
 {{< /note >}}
-쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.
+쿠버네티스 API에서, 노드의 컨디션은 노드 리소스의 `.status` 부분에
 표현된다. 예를 들어, 다음의 JSON 구조는 상태가 양호한 노드를 나타낸다.
 ```json
 "conditions": [
@@ -208,11 +225,13 @@ API 서버와의 통신이 재개될 때까지 파드 삭제에 대한 결정은
 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
-쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가
+쿠버네티스에서 노드 오브젝트를 삭제하면
-API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
+노드 상에서 동작 중인 모든 파드 오브젝트가 API 서버로부터 삭제되며
 파드가 사용하던 이름을 다시 사용할 수 있게 된다.
 노드에서 문제가 발생하면, 쿠버네티스 컨트롤 플레인은 자동으로 노드 상태에 영향을 주는 조건과 일치하는
-[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 생성한다.
+[테인트(taints)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를
 생성한다.
 스케줄러는 파드를 노드에 할당할 때 노드의 테인트를 고려한다.
 또한 파드는 노드에 특정 테인트가 있더라도 해당 노드에서 동작하도록 
 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}을 가질 수 있다.
@@ -235,9 +254,11 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
 ### 정보
-커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너 런타임 상세 정보 및 노드가 사용하는 운영 체계가 무엇인지와 같은 노드에 대한 일반적인 정보가 기술된다.
+커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), 컨테이너
-
+런타임 상세 정보 및 노드가 사용하는 운영 체제가 무엇인지와 같은
-이 정보는 Kubelet이 노드로부터 수집해서 쿠버네티스 API로 이를 보낸다.
+노드에 대한 일반적인 정보가 기술된다.
 이 정보는 Kubelet이 노드에서 수집하여
 쿠버네티스 API로 전송한다.
 ## 하트비트
@@ -248,20 +269,25 @@ API 서버로부터 삭제되어 그 이름을 사용할 수 있는 결과를
 * 노드의 `.status`에 대한 업데이트
 * `kube-node-lease`
-  {{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) 오브젝트.
+  {{< glossary_tooltip term_id="namespace" text="네임스페이스">}}
-  각 노드는 연관된 리스 오브젝트를 갖는다.
+  내의 [리스(Lease)](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
  오브젝트. 각 노드는 연관된 리스 오브젝트를 갖는다.
-노드의 `.status`와 비교해서, 리스는 경량의 리소스이다.
+노드의 `.status`에 비하면, 리스는 경량의 리소스이다.
-큰 규모의 클러스터에서는 리스를 하트비트에 사용해서 업데이트를 위해 필요한 성능 영향도를 줄일 수 있다.
+큰 규모의 클러스터에서는 리스를 하트비트에 사용하여 
 업데이트로 인한 성능 영향을 줄일 수 있다.
 kubelet은 노드의 `.status` 생성과 업데이트 및
 관련된 리스의 업데이트를 담당한다. 
- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우 노드의 `.status`를 업데이트한다.
+- kubelet은 상태가 변경되거나 설정된 인터벌보다 오래 업데이트가 없는 경우
-  노드의 `.status` 업데이트에 대한 기본 인터벌은 접근이 불가능한 노드에 대한 타임아웃인 40초 보다 훨씬 긴 5분이다.
+  노드의 `.status`를 업데이트한다. 노드의 `.status` 업데이트에 대한 기본
- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다 생성하고 업데이트한다.
+  인터벌은 접근이 불가능한 노드에 대한 타임아웃인
-  리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다.
+  40초 보다 훨씬 긴 5분이다.
-  만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고 7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
+- kubelet은 리스 오브젝트를 (기본 업데이트 인터벌인) 매 10초마다
  생성하고 업데이트한다. 리스 업데이트는 노드의 `.status` 업데이트와는 독립적이다.
  만약 리스 업데이트가 실패하면, kubelet은 200밀리초에서 시작하고
  7초의 상한을 갖는 지수적 백오프를 사용해서 재시도한다.
 ### 노드 컨트롤러
@@ -280,11 +306,14 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
 세 번째는 노드의 동작 상태를 모니터링하는 것이다. 노드 컨트롤러는
 다음을 담당한다.
- 노드가 접근이 불가능한 상태가되는 경우, 노드의 `.status` 내에 있는 NodeReady 컨디션을 업데이트한다.
+- 노드가 접근 불가능(unreachable) 상태가 되는 경우, 노드의 `.status`
  내에 있는 NodeReady 컨디션을 업데이트한다.
  이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
- 노드에 계속 접근이 불가능한 상태로 남아있는 경우에는 해당 노드의 모든 파드에 대해서
+- 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
-  [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을 트리거한다.
+  [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
-  기본적으로, 노드 컨트롤러는 노드를 `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가 최초의 축출 요청을 시작한다. 
+  트리거한다. 기본적으로, 노드 컨트롤러는 노드를
  `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
  최초의 축출 요청을 시작한다. 
 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
@@ -315,7 +344,10 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는
 `--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이
 완전히 상태불량(클러스터 내 양호한 노드가 없는 경우)한 경우이다.
-이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한 나머지 노드에서 파드를 축출한다.)
+이러한 경우, 노드 컨트롤러는 컨트롤 플레인과 노드 간 연결에 문제가
 있는 것으로 간주하고 축출을 실행하지 않는다. (중단 이후 일부 노드가
 다시 보이는 경우 노드 컨트롤러는 상태가 양호하지 않거나 접근이 불가능한
 나머지 노드에서 파드를 축출한다.)
 또한, 노드 컨트롤러는 파드가 테인트를 허용하지 않을 때 `NoExecute` 테인트 상태의
 노드에서 동작하는 파드에 대한 축출 책임을 가지고 있다.
@@ -377,19 +409,19 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로
 그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다.
 1. 노드에서 실행 중인 일반 파드를 종료시킨다.
-2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다.
+2. 노드에서 실행 중인 [중요(critical) 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)를 종료시킨다.
 그레이스풀 노드 셧다운 기능은 두 개의 [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) 옵션으로 구성된다.
 * `ShutdownGracePeriod`:
-  * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다.
+  * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 파드 종료에 필요한 총 유예 기간에 해당한다.
 * `ShutdownGracePeriodCriticalPods`:
-  * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다.
+  * 노드 종료 중에 [중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-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)의 종료에 할당된다.
+[중요 파드](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#파드를-중요-critical-로-표시하기)의 종료에 할당된다.
 {{< note >}}
 그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다.
@@ -57,7 +57,7 @@ no_list: true
 * [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)는 인증과 권한 부여 후 쿠버네티스 API 서버에 대한 요청을 가로채는 플러그인에 대해 설명한다.
-* [쿠버네티스 클러스터에서 Sysctls 사용하기](/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
+* [쿠버네티스 클러스터에서 Sysctls 사용하기](/ko/docs/tasks/administer-cluster/sysctl-cluster/)는 관리자가 `sysctl` 커맨드라인 도구를 사용하여 커널 파라미터를 설정하는 방법에 대해 설명한다.
 * [감사(audit)](/docs/tasks/debug-application-cluster/audit/)는 쿠버네티스의 감사 로그를 다루는 방법에 대해 설명한다.
@@ -105,5 +105,5 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대
 ## {{% heading "whatsnext" %}}
-자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 
+자세한 내용은 [리소스 부족 처리 구성](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 
 본다.
@@ -145,7 +145,7 @@ Coil은 베어메탈에 비해 낮은 오버헤드로 작동하며, 외부 네
 ### 콘티브(Contiv)
-[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다. [콘티브](https://contiv.io)는 모두 오픈소스이다.
+[콘티브](https://github.com/contiv/netplugin)는 다양한 적용 사례에서 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 또는 Cisco-SDN/ACI)을 제공한다.
 ### 콘트레일(Contrail) / 텅스텐 패브릭(Tungsten Fabric)
@@ -260,12 +260,6 @@ Multus는 CNI 명세를 구현하는 모든 [레퍼런스 플러그인](https://
 [NSX-T 컨테이너 플러그인(NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf)은 NSX-T와 쿠버네티스와 같은 컨테이너 오케스트레이터 사이의 통합은 물론, NSX-T와 Pivotal 컨테이너 서비스(PKS) 및 OpenShift와 같은 컨테이너 기반 CaaS/PaaS 플랫폼 간의 통합을 제공한다.
 ### Nuage Networks VCS(가상 클라우드 서비스)
 [Nuage](https://www.nuagenetworks.net)는 확장성이 뛰어난 정책 기반의 소프트웨어 정의 네트워킹(SDN) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로 구축된 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인용 오픈소스 Open vSwitch를 사용한다.
 Nuage 플랫폼은 오버레이를 사용하여 쿠버네티스 파드와 쿠버네티스가 아닌 환경(VM 및 베어메탈 서버) 간에 완벽한 정책 기반의 네트워킹을 제공한다. Nuage의 정책 추상화 모델은 애플리케이션을 염두에 두고 설계되었으며 애플리케이션에 대한 세분화된 정책을 쉽게 선언할 수 있도록 한다. 플랫폼의 실시간 분석 엔진을 통해 쿠버네티스 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
 ### OpenVSwitch
 [OpenVSwitch](https://www.openvswitch.org/)는 다소 성숙하지만
@@ -37,7 +37,7 @@ weight: 30
 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
 2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
   활성화 또는 구성.
-3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
+3. 적절한 경우, RBAC과 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
 {{< /caution >}}
@@ -425,9 +425,9 @@ stringData:
 시크릿을 생성하기 위한 몇 가지 옵션이 있다.
- [`kubectl` 명령을 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- [kustomize를 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
 ## 시크릿 편집하기
@@ -1259,7 +1259,7 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
 ## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
+- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
+- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
+- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
 - [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기
@@ -32,7 +32,7 @@ weight: 20
 함수 호출을 통해서 구할 수 있다.
 파드 이름과 네임스페이스는
-[다운워드(Downward) API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
+[다운워드(Downward) API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 통해 환경 변수로 구할 수 있다.
 Docker 이미지에 정적으로 명시된 환경 변수와 마찬가지로,
 파드 정의에서의 사용자 정의 환경 변수도 컨테이너가 사용할 수 있다.
@@ -2,6 +2,11 @@
 title: 쿠버네티스 확장
 weight: 110
 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법
 feature:
  title: 확장성을 고려하여 설계됨
  description: >
@@ -47,9 +52,9 @@ no_list: true
 익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다.
 이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다.
-대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다.
+많은 클러스터 관리자가 호스팅 또는 배포판 쿠버네티스 인스턴스를 사용한다.
-결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고
+이러한 클러스터들은 미리 설치된 익스텐션을 포함한다. 결과적으로 대부분의
-새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다.
+쿠버네티스 사용자는 익스텐션을 설치할 필요가 없고, 새로운 익스텐션을 만들 필요가 있는 사용자는 더 적다.
 ## 익스텐션 패턴
@@ -74,14 +79,12 @@ no_list: true
 바이너리 플러그인은 kubelet(예:
 [Flex Volume 플러그인](/ko/docs/concepts/storage/volumes/#flexVolume)과
 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과
-kubectl에서
+kubectl에서 사용한다.
 사용한다.
 아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을
 보여주는 다이어그램이다.
 <!-- 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)
 ## 익스텐션 포인트
@@ -89,7 +92,6 @@ kubectl에서
 이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다.
 <!-- 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 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다.
@@ -103,10 +105,10 @@ kubectl에서
 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다.
 <!-- image source drawing: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit -->
 ![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png)
 ## API 익스텐션
 ### 사용자 정의 유형
 새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl` 과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자.
@@ -155,7 +157,6 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치
 ## 인프라스트럭처 익스텐션
 ### 스토리지 플러그인
 [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md)을 사용하면
@@ -172,7 +173,8 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
 ### 네트워크 플러그인
-노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
+노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
 을 통해 다양한 네트워킹 패브릭을 지원할 수 있다.
 ### 스케줄러 익스텐션
@@ -200,3 +202,4 @@ Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도
  * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
 * [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기
 * [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기
@@ -1,4 +1,6 @@
 ---
 title: 쿠버네티스 컴포넌트
 content_type: concept
 description: >
@@ -17,11 +19,7 @@ card:
 이 문서는 완전히 작동하는 쿠버네티스 클러스터를 갖기 위해 필요한
 다양한 컴포넌트들에 대해 요약하고 정리한다.
-여기에 모든 컴포넌트가 함께 있는 쿠버네티스 클러스터 다이어그램이 있다.
+{{< figure src="/images/docs/components-of-kubernetes.svg" alt="쿠버네티스 구성 요소" caption="쿠버네티스 클러스터 구성 요소" class="diagram-large" >}}
 ![쿠버네티스의 컴포넌트](/images/docs/components-of-kubernetes.svg)
 <!-- body -->
 ## 컨트롤 플레인 컴포넌트
@@ -1,4 +1,8 @@
 ---
 title: 네임스페이스
 content_type: concept
 weight: 30
@@ -6,8 +10,7 @@ weight: 30
 <!-- overview -->
-쿠버네티스는 동일한 물리 클러스터를 기반으로 하는 여러 가상 클러스터를 지원한다.
+쿠버네티스에서, _네임스페이스_ 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 _(예: 디플로이먼트, 서비스 등)_ 에만 적용 가능하며 클러스터 범위의 오브젝트 _(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)_ 에는 적용 불가능하다.
 이런 가상 클러스터를 네임스페이스라고 한다.
 <!-- body -->
@@ -695,7 +695,7 @@ spec:
 - `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한 기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
 [Sysctl 문서](
-/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)를 참고하길 바란다.
+/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
 ## {{% heading "whatsnext" %}}
@@ -33,5 +33,5 @@ no_list: true
 {{<glossary_definition term_id="pod-disruption" length="all">}}
 * [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)
-* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+* [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)
 * [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)
@@ -14,5 +14,5 @@ API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-ap
 ## {{% heading "whatsnext" %}}
- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
+- [노드-압박 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기
 - [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기
@@ -91,5 +91,5 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
 * 볼륨을 사용하는 파드의 스케줄링에 대해 배우기
  * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)
-  * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/)
+  * [스토리지 용량 추적](/ko/docs/concepts/storage/storage-capacity/)
  * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/)
@@ -48,7 +48,7 @@ weight: 70
 {{< note >}}
 쿠버네티스는 이미 `system-cluster-critical` 과 `system-node-critical`,
 두 개의 프라이어리티클래스를 제공한다.
-이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
+이들은 일반적인 클래스이며 [중요한(critical) 컴포넌트가 항상 먼저 스케줄링이 되도록 하는 데](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 사용된다.
 {{< /note >}}
 ## 프라이어리티클래스
@@ -357,11 +357,11 @@ kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure)
 사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
 예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
-  1. 부족한 리소스 사용량이 요청을 초과하는지 여부
+  1. 기아(starved) 리소스 사용량이 요청을 초과하는지 여부
  1. 파드 우선순위
  1. 요청 대비 리소스 사용량
-더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
+더 자세한 내용은 [kubelet 축출을 위한 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
 참조한다.
 kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
@@ -29,7 +29,7 @@ weight: 1
 널리 알려져 있다.
 {{< /note >}}
-{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" >}}
+{{< figure src="/images/docs/4c.png" title="클라우드 네이티브 보안의 4C" class="diagram-large" >}}
 클라우드 네이티브 보안 모델의 각 계층은 다음의 가장 바깥쪽 계층을 기반으로 한다.
 코드 계층은 강력한 기본(클라우드, 클러스터, 컨테이너) 보안 계층의 이점을 제공한다.
@@ -77,7 +77,7 @@ API 서버에 대한 네트워크 접근(컨트롤 플레인) | 쿠버네티스
 노드에 대한 네트워크 접근(노드) | 지정된 포트의 컨트롤 플레인에서 _만_ (네트워크 접근 제어 목록을 통한) 연결을 허용하고 NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 노드를 구성해야 한다. 가능하면 이러한 노드가 공용 인터넷에 완전히 노출되어서는 안된다.
 클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 컨트롤 플레인 및 노드에 서로 다른 권한 집합을 부여해야 한다. 관리해야하는 리소스에 대해 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. [Kops 설명서](https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles)는 IAM 정책 및 역할에 대한 정보를 제공한다.
 etcd에 대한 접근 | etcd(쿠버네티스의 데이터 저장소)에 대한 접근은 컨트롤 플레인으로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 내용은 [etcd 문서](https://github.com/etcd-io/etcd/tree/master/Documentation)에서 확인할 수 있다.
-etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.
+etcd 암호화 | 가능한 한 모든 스토리지를 암호화하는 것이 좋은 방법이며, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 특히 디스크는 암호화되어 있어야 한다.
 {{< /table >}}
@@ -107,9 +107,9 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
 ------------------------------ | ------------ |
 RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/
 인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/
-애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
+애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/ko/docs/concepts/configuration/secret/ <br> https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
-파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/
+파드가 파드 시큐리티 폴리시를 만족하는지 확인하기 | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation
-서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
+서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/ko/docs/tasks/configure-pod-container/quality-service-pod/
 네트워크 정책 | https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
 쿠버네티스 인그레스를 위한 TLS | https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#tls
@@ -137,7 +137,7 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r
 코드에서 고려할 영역 | 추천 |
 -------------------------| -------------- |
-TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. |
+TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 클라이언트와 TLS 핸드 셰이크를 수행한다. 몇 가지 경우를 제외하고, 전송 중인 모든 것을 암호화한다. 한 걸음 더 나아가, 서비스 간 네트워크 트래픽을 암호화하는 것이 좋다. 이것은 인증서를 가지고 있는 두 서비스의 양방향 검증을 실행하는 [mTLS(상호 TLS 인증)](https://en.wikipedia.org/wiki/Mutual_authentication)를 통해 수행할 수 있다. |
 통신 포트 범위 제한 | 이 권장사항은 당연할 수도 있지만, 가능하면 통신이나 메트릭 수집에 꼭 필요한 서비스의 포트만 노출시켜야 한다. |
 타사 종속성 보안 | 애플리케이션의 타사 라이브러리를 정기적으로 스캔하여 현재 알려진 취약점이 없는지 확인하는 것이 좋다. 각 언어에는 이런 검사를 자동으로 수행하는 도구를 가지고 있다. |
 정적 코드 분석 | 대부분 언어에는 잠재적으로 안전하지 않은 코딩 방법에 대해 코드 스니펫을 분석할 수 있는 방법을 제공한다. 가능한 언제든지 일반적인 보안 오류에 대해 코드베이스를 스캔할 수 있는 자동화된 도구를 사용하여 검사를 한다. 도구는 다음에서 찾을 수 있다. https://owasp.org/www-community/Source_Code_Analysis_Tools |
@@ -76,4 +76,4 @@ weight: 40
 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
-* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
+* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/).
@@ -77,7 +77,7 @@ graph LR;
 다른 모든 쿠버네티스 리소스와 마찬가지로 인그레스에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다.
 인그레스 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
-설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
+설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
 인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
 그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
@@ -567,4 +567,4 @@ Events:
 * [인그레스 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
-* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube/)
+* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/)
@@ -68,6 +68,6 @@ kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되
 ## {{% heading "whatsnext" %}}
-* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기
+* [토폴로지 인식 힌트 활성화](/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints/)에 대해서 읽기
 * [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기
 * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기
@@ -263,9 +263,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
 kube-proxy는 구성에 따라 결정되는 여러 모드에서 기동될 수 있다.
 - kube-proxy의 구성은 컨피그맵(ConfigMap)을 통해 이루어진다. 그리고 해당 kube-proxy를 위한 컨피그맵은 실효성있게 거의 대부분의 kube-proxy의 플래그의 행위를 더 이상 사용하지 않도록 한다.
 - kube-proxy를 위한 해당 컨피그맵은 기동 중 구성의 재적용(live reloading)은 지원하지 않는다.
- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어,
+- kube-proxy를 위한 컨피그맵 파라미터는 기동 시에 검증이나 확인을 하지 않는다. 예를 들어, 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다. 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
 운영 체계가 iptables 명령을 허용하지 않을 경우, 표준 커널 kube-proxy 구현체는 작동하지 않을 것이다.
 마찬가지로, `netsh`을 지원하지 않는 운영 체계에서는, 윈도우 유저스페이스 모드로는 기동하지 않을 것이다.
 ### 유저 스페이스(User space) 프록시 모드 {#proxy-mode-userspace}
@@ -1074,6 +1072,9 @@ spec:
 {{< /note >}}
 엘라스틱 IP에 대한 설명 문서와 기타 일반적 사용 사례를 
 [AWS 로드 밸런서 컨트롤러 문서](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/)에서 볼 수 있다.
 #### Tencent Kubernetes Engine (TKE)의 다른 CLB 어노테이션
 아래 표시된 것처럼 TKE에서 클라우드 로드 밸런서를 관리하기 위한 다른 어노테이션이 있다.
@@ -280,7 +280,7 @@ spec:
 업데이트를 수신하지 않는다.
 {{< /note >}}
-더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
+더 자세한 내용은 [다운워드 API 예시](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다.
 ### emptyDir {#emptydir}
@@ -60,7 +60,7 @@ _모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마
 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다.
-* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/)
+* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/ko/docs/tasks/run-application/run-stateless-application-deployment/)
 * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/)
  또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행
 * [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)
@@ -77,6 +77,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는
 | @hourly 									| 매시 0분에 시작                          								       | 0 * * * * 		|
 예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정(UTC 기준)에도 시작되어야 한다는 뜻이다.
 `CRON_TZ=UTC 0 0 13 * 5`
@@ -47,7 +47,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다.
 일반적인 설정파일 작업에 대한 정보는
-[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와
+[스테이트리스 애플리케이션 실행하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다.
 데몬셋 오브젝트의 이름은 유효한
@@ -1,4 +1,6 @@
 ---
 title: 디플로이먼트
 feature:
  title: 자동화된 롤아웃과 롤백
@@ -74,7 +76,6 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 ```
 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다.
  만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다.
@@ -163,7 +164,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
 1. `nginx:1.14.2` 이미지 대신 `nginx:1.16.1` 이미지를 사용하도록 nginx 파드를 업데이트 한다.
    ```shell
-    kubectl deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
    ```
    또는 다음의 명령어를 사용한다.
@@ -181,7 +182,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
    대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.14.2` 에서 `nginx:1.16.1` 로 변경한다.
    ```shell
-    kubectl edit deployment.v1.apps/nginx-deployment
+    kubectl edit deployment/nginx-deployment
    ```
    다음과 유사하게 출력된다.
@@ -364,7 +365,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
 * 디플로이먼트를 업데이트하는 동안 이미지 이름을 `nginx:1.16.1` 이 아닌 `nginx:1.161` 로 입력해서 오타를 냈다고 가정한다.
    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 
+    kubectl set image deployment/nginx-deployment nginx=nginx:1.161 
    ```
    이와 유사하게 출력된다.
@@ -473,25 +474,25 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
 1. 먼저 이 디플로이먼트의 수정 사항을 확인한다.
    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment
+    kubectl rollout history deployment/nginx-deployment
    ```
    이와 유사하게 출력된다.
    ```
    deployments "nginx-deployment"
    REVISION    CHANGE-CAUSE
    1           kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
-    2           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+    2           kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
-    3           kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161
+    3           kubectl set image deployment/nginx-deployment nginx=nginx:1.161
    ```
    `CHANGE-CAUSE` 는 수정 생성시 디플로이먼트 주석인 `kubernetes.io/change-cause` 에서 복사한다. 다음에 대해 `CHANGE-CAUSE` 메시지를 지정할 수 있다.
-    * 디플로이먼트에 `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
+    * 디플로이먼트에 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` 로 주석을 단다.
    * 수동으로 리소스 매니페스트 편집.
 2. 각 수정 버전의 세부 정보를 보려면 다음을 실행한다.
    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
+    kubectl rollout history deployment/nginx-deployment --revision=2
    ```
    이와 유사하게 출력된다.
@@ -499,7 +500,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
    deployments "nginx-deployment" revision 2
      Labels:       app=nginx
              pod-template-hash=1159050644
-      Annotations:  kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+      Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
      Containers:
       nginx:
        Image:      nginx:1.16.1
@@ -516,7 +517,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
 1. 이제 현재 롤아웃의 실행 취소 및 이전 수정 버전으로 롤백 하기로 결정했다.
    ```shell
-    kubectl rollout undo deployment.v1.apps/nginx-deployment
+    kubectl rollout undo deployment/nginx-deployment
    ```
    이와 유사하게 출력된다.
@@ -526,7 +527,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
    Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
    ```shell
-    kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+    kubectl rollout undo deployment/nginx-deployment --to-revision=2
    ```
    이와 유사하게 출력된다.
@@ -560,7 +561,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
    CreationTimestamp:      Sun, 02 Sep 2018 18:17:55 -0500
    Labels:                 app=nginx
    Annotations:            deployment.kubernetes.io/revision=4
-                            kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+                            kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    Selector:               app=nginx
    Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
    StrategyType:           RollingUpdate
@@ -603,7 +604,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성
 다음 명령어를 사용해서 디플로이먼트의 스케일을 할 수 있다.
 ```shell
-kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
+kubectl scale deployment/nginx-deployment --replicas=10
 ```
 이와 유사하게 출력된다.
 ```
@@ -615,7 +616,7 @@ deployment.apps/nginx-deployment scaled
 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다.
 ```shell
-kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
+kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
 ```
 이와 유사하게 출력된다.
 ```
@@ -644,7 +645,7 @@ deployment.apps/nginx-deployment scaled
 * 클러스터 내부에서 확인할 수 없는 새 이미지로 업데이트 된다.
    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+    kubectl set image deployment/nginx-deployment nginx=nginx:sometag
    ```
    이와 유사하게 출력된다.
@@ -723,7 +724,7 @@ nginx-deployment-618515232    11        11        11        7m
 * 다음 명령을 사용해서 일시 중지한다.
    ```shell
-    kubectl rollout pause deployment.v1.apps/nginx-deployment
+    kubectl rollout pause deployment/nginx-deployment
    ```
    이와 유사하게 출력된다.
@@ -733,7 +734,7 @@ nginx-deployment-618515232    11        11        11        7m
 * 그런 다음 디플로이먼트의 이미지를 업데이트 한다.
    ```shell
-    kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+    kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
    ```
    이와 유사하게 출력된다.
@@ -743,7 +744,7 @@ nginx-deployment-618515232    11        11        11        7m
 * 새로운 롤아웃이 시작되지 않는다.
    ```shell
-    kubectl rollout history deployment.v1.apps/nginx-deployment
+    kubectl rollout history deployment/nginx-deployment
    ```
    이와 유사하게 출력된다.
@@ -765,7 +766,7 @@ nginx-deployment-618515232    11        11        11        7m
 * 예를 들어 사용할 리소스를 업데이트하는 것처럼 원하는 만큼 업데이트할 수 있다.
    ```shell
-    kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+    kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
    ```
    이와 유사하게 출력된다.
@@ -778,7 +779,7 @@ nginx-deployment-618515232    11        11        11        7m
 * 결국, 디플로이먼트를 재개하고 새로운 레플리카셋이 새로운 업데이트를 제공하는 것을 관찰한다.
    ```shell
-    kubectl rollout resume deployment.v1.apps/nginx-deployment
+    kubectl rollout resume deployment/nginx-deployment
    ```
    이와 유사하게 출력된다.
@@ -888,7 +889,7 @@ echo $?
 10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다.
 ```shell
-kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
 ```
 이와 유사하게 출력된다.
 ```
@@ -999,7 +1000,7 @@ Conditions:
 `kubectl rollout status` 는 디플로이먼트의 진행 데드라인을 초과하면 0이 아닌 종료 코드를 반환한다.
 ```shell
-kubectl rollout status deployment.v1.apps/nginx-deployment
+kubectl rollout status deployment/nginx-deployment
 ```
 이와 유사하게 출력된다.
 ```
@@ -1040,7 +1041,7 @@ echo $?
 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다.
 설정 파일 작업에 대한 일반적인 내용은
-[애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/),
+[애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/),
 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
 디플로이먼트 오브젝트의 이름은 유효한
 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
@@ -118,7 +118,6 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
 다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은
 반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다.
 ## 레플리케이션 컨트롤러의 Spec 작성
 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
@@ -189,7 +189,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
 * 파드에 스케일링 작업을 적용하기 전에 모든 선행 파드가 Running 및 Ready 상태여야 한다.
 * 파드가 종료되기 전에 모든 후속 파드가 완전히 종료 되어야 한다.
-스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
+스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
 위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가
 배포된다. web-1은 web-0이
@@ -48,6 +48,21 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)
 ## 파드의 사용
 다음은 `nginx:1.14.2` 이미지를 실행하는 컨테이너로 구성되는 파드의 예시이다.
 {{< codenew file="pods/simple-pod.yaml" >}}
 위에서 설명한 파드를 생성하려면, 다음 명령을 실행한다.
 ```shell
 kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
 ```
 일반적으로 파드는 직접 생성하지는 않으며, 대신 워크로드 리소스를 사용하여 생성한다.
 [파드 작업](#파드-작업) 섹션에서 파드와 워크로드 리소스의 관계에 대한 
 더 많은 정보를 확인한다.
 ### Workload resources for managing pods
 일반적으로 싱글톤(singleton) 파드를 포함하여 파드를 직접 만들 필요가 없다. 대신, {{< glossary_tooltip text="디플로이먼트(Deployment)"
 term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}과 같은 워크로드 리소스를 사용하여 생성한다.
 파드가 상태를 추적해야 한다면,
@@ -97,7 +112,7 @@ term_id="deployment" >}} 또는 {{< glossary_tooltip text="잡(Job)" term_id="jo
 공유 볼륨의 파일에 대한 웹 서버 역할을 하는 컨테이너와, 원격 소스에서 해당 파일을 업데이트하는
 별도의 "사이드카" 컨테이너가 있을 수 있다.
-{{< figure src="/images/docs/pod.svg" alt="예제 파드 다이어그램" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" alt="파드 생성 다이어그램" class="diagram-medium" >}}
 일부 파드에는 {{< glossary_tooltip text="앱 컨테이너" term_id="app-container" >}} 뿐만 아니라 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}를 갖고 있다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 실행되고 완료된다.
@@ -31,7 +31,7 @@ weight: 60
 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애
 - 커널 패닉
 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐
- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
+- 노드의 [리소스 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨
 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다.
 왜냐하면
@@ -71,7 +71,7 @@ weight: 60
 - 파드가 필요로 하는 [리소스를 요청](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는지 확인한다.
 - 고가용성이 필요한 경우 애플리케이션을 복제한다.
-  (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및
+  (복제된 [스테이트리스](/ko/docs/tasks/run-application/run-stateless-application-deployment/) 및
  [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.)
 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체
  ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용)
@@ -76,4 +76,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
 ## {{% heading "whatsnext" %}}
-* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
+* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
@@ -283,7 +283,7 @@ myapp-pod   1/1       Running   0          9m
 초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서
 파드의 `activeDeadlineSeconds`를 사용한다.
 Active deadline은 초기화 컨테이너를 포함한다.
-그러나 사용자가 애플리케이션을 잡(job)으로 배포한 경우 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
+그러나 팀에서 애플리케이션을 잡(job)으로 배포한 경우에만 `activeDeadlineSeconds`를 사용하길 추천한다. 왜냐하면, `activeDeadlineSeconds`는 초기화 컨테이너가 완료된 이후에도 영향을 주기 때문이다.
 이미 정상적으로 동작하고 있는 파드도 `activeDeadlineSeconds`를 설정한 경우 종료(killed)될 수 있다.
 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤
@@ -55,7 +55,7 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되
 생성되더라도, 관련된 그것(이 예에서는 볼륨)도 폐기되고
 새로 생성된다.
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" class="diagram-medium" >}}
 *컨테이너 간의 공유 스토리지에 퍼시스턴트 볼륨을 사용하는 웹 서버와
 파일 풀러(puller)가 포함된 다중 컨테이너 파드이다.*
@@ -433,7 +433,7 @@ API에서 즉시 파드를 제거하므로 동일한 이름으로 새로운 파
 작은 유예 기간이 계속 제공된다.
 스테이트풀셋(StatefulSet)의 일부인 파드를 강제 삭제해야 하는 경우,
-[스테이트풀셋에서 파드를 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
+[스테이트풀셋에서 파드를 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한
 태스크 문서를 참고한다.
 ### 실패한 파드의 가비지 콜렉션 {#pod-garbage-collection}
@@ -29,6 +29,8 @@ card:
 - 문서를 번역합니다.
 - 쿠버네티스 릴리스 주기에 맞추어 문서 부분을 관리하고 발행합니다.
 <!-- body -->
 ## 시작하기
@@ -44,19 +46,99 @@ card:
 문서에 참여하려면
 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다.
-1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
+2. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의
   [정적 사이트 생성기](https://gohugo.io)를 숙지합니다.
-1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
+3. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와
   [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의
   기본 프로세스를 이해하도록 합니다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart TB
 subgraph third[PR 열기]
 direction TB
 U[ ] -.-
 Q[컨텐츠 향상시키기] --- N[컨텐츠 생성하기]
 N --- O[문서 번역하기]
 O --- P[K8s 릴리스 사이클의 문서 파트<br>관리/퍼블리싱하기]
 end
 subgraph second[리뷰]
 direction TB
   T[ ] -.-
   D[K8s/website<br>저장소 살펴보기] --- E[Hugo 정적 사이트<br>생성기 확인하기]
   E --- F[기본 GitHub 명령어<br>이해하기]
   F --- G[열려 있는 PR을 리뷰하기]
 end
 subgraph first[가입]
    direction TB
    S[ ] -.-
    B[CNCF<br>Contributor<br>License Agreement<br>서명하기] --- C[sig-docs 슬랙 채널<br>가입하기] 
    C --- V[kubernetes-sig-docs<br>메일링 리스트 가입하기]
    V --- M[주간<br>sig-docs 회의/<br>슬랙 미팅 참여하기]
 end
 A([fa:fa-user 신규<br>기여자]) --> first
 A --> second
 A --> third
 A --> H[질문하세요!!!]
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
 class S,T,U spacewhite
 class first,second,third white
 {{</ mermaid >}}
 ***그림 - 신규 기여자를 위한 시작 가이드***
 위의 그림은 신규 기여자를 위한 로드맵을 간략하게 보여줍니다. `가입` 및 `리뷰` 단계의 일부 또는 전체를 따를 수 있습니다. 이제 `PR 열기` 아래에 나열된 항목들을 수행하여 당신의 기여 목표를 달성할 수 있습니다. 다시 말하지만 질문은 언제나 환영입니다!
 일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있습니다.
 역할과 권한에 대한 자세한 내용은
 [SIG Docs 참여](/ko/docs/contribute/participate/)를 봅니다.
 ## 첫 번째 기여
- [기여 개요](/ko/docs/contribute/new-content/overview/)를 읽고
+몇 가지 단계를 미리 검토하여 첫 번째 기여를 준비할 수 있습니다. 아래 그림은 각 단계를 설명하며, 그 다음에 세부 사항도 설명되어 있습니다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR
    subgraph second[첫 기여]
    direction TB
    S[ ] -.-
    G[다른 K8s 멤버의 PR 리뷰하기] -->
    A[K8s/website 이슈 리스트에서<br>good first issue 확인하기] --> B[PR을 여세요!!]
    end
    subgraph first[추천 준비 사항]
    direction TB
       T[ ] -.-
       D[기여 개요 읽기] -->E[K8s 컨텐츠 및 <br>스타일 가이드 읽기]
       E --> F[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
    end
    first ----> second
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class A,B,D,E,F,G grey
 class S,T spacewhite
 class first,second white
 {{</ mermaid >}}
 ***그림 - 첫 기여를 위한 준비***
 - [기여 개요](/ko/docs/contribute/new-content/)를 읽고
  기여할 수 있는 다양한 방법에 대해 알아봅니다.
 - [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을
  확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다.
@@ -92,10 +174,13 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다.
  자신을 소개하세요!
 - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는
  [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요.
- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
+- 2주마다 열리는 [SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 공지되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다.
 - 줌 화상 회의가 열리지 않은 경우, SIG Docs 비실시간 슬랙 스탠드업 회의에 참여하세요. 회의는 항상 `#sig-docs` 에 공지됩니다. 회의 공지 후 24시간까지 어느 스레드에나 기여할 수 있습니다.
 ## 다른 기여 방법들
 - [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다.
- [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다.
+- [기여자 치트시트](https://www.kubernetes.dev/docs/contributor-cheatsheet/)를 읽고 쿠버네티스 기능 개발에 참여합니다.
 - 쿠버네티스 기여자 사이트에서 [쿠버네티스 기여자](https://www.kubernetes.dev/)와 [추가적인 기여자 리소스](https://www.kubernetes.dev/resources/)에 대해 더 알아봅니다.
 - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다.
@@ -8,7 +8,7 @@ weight: 98
 <!-- overview -->
 이 페이지에서는 당신이
-[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/overview)하고
+[새로운 콘텐츠에 기여](/ko/docs/contribute/new-content/)하고
 [다른 사람의 작업을 리뷰](/ko/docs/contribute/review/reviewing-prs/)하는 방법을
 이해한다고 가정한다. 또한 기여하기 위한 더 많은 방법에 대해 배울 준비가 되었다고 가정한다. 이러한
 작업 중 일부에는 Git 커맨드 라인 클라이언트와 다른 도구를 사용해야 한다.
@@ -5,10 +5,48 @@ main_menu: true
 weight: 20
 ---
 <!-- overview -->
-이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 있다.
+이 섹션에는 새로운 콘텐츠를 기여하기 전에 알아야 할 정보가 
 있다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR 
    subgraph second[시작하기 전에]
    direction TB
    S[ ] -.-
    A[CNCF CLA 서명하기] --> B[Git 브랜치 선택하기]
    B --> C[한 PR에는 한 언어에 대한 변경사항만]
    C --> F[기여자 도구 확인하기]
    end
    subgraph first[기여 기초]
    direction TB
       T[ ] -.-
       D[문서를 마크다운으로 작성하고<br>Hugo로 사이트 빌드] --- E[GitHub에 있는 소스]
       E --- G['/content/../docs' 폴더에<br>각 언어 컨텐츠가 있음]
       G --- H[Hugo 페이지 컨텐츠 종류와<br>shortcode 숙지하기]
    end
    first ----> second
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class A,B,C,D,E,F,G,H grey
 class S,T spacewhite
 class first,second white
 {{</ mermaid >}}
 ***Figure - Contributing new content preparation***
 The figure above depicts the information you should know
 prior to submitting new content. The information details follow.
@@ -16,28 +54,43 @@ weight: 20
 ## 기여에 대한 기본 사항
- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
+- 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 
- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다.
+  [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다.
- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
+- 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 
  쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 
  일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트를 이용하여 
  자동으로 생성된다.
 - [페이지 템플릿](/docs/contribute/style/page-content-types/)은 
  Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다.
 - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러
-  [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다.
+  [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 
  콘텐츠 표시를 제어한다.
 - 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각
  언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에
  의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어,
  한글 문서의 소스는 `/content/ko/docs/` 에 저장된다.
- 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
+- 여러 언어로 문서화에 기여하거나 
  새로운 번역을 시작하는 방법에 대한 자세한 내용은 
  [현지화](/ko/docs/contribute/localization_ko/)를 참고한다.
 ## 시작하기 전에 {#before-you-begin}
 ### CNCF CLA 서명 {#sign-the-cla}
-모든 쿠버네티스 기여자는 **반드시** [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다.
+모든 쿠버네티스 기여자는 **반드시** 
 [기여자 가이드](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)를 읽고 
 [기여자 라이선스 계약(CLA)에 서명](https://github.com/kubernetes/community/blob/master/CLA.md)해야 한다
 .
-CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, git 이름과 이메일은 CNCF CLA에 사용된 것과 일치해야 한다.
+CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 테스트에 실패한다. 
 제공한 이름과 이메일은 `git config` 에 있는 것과 일치해야 하며, 
 git 이름과 이메일은 CNCF CLA에 사용된 것과 
 일치해야 한다.
 ### 사용할 Git 브랜치를 선택한다
-풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 미리 알아야 한다.
+풀 리퀘스트를 열 때는, 작업의 기반이 되는 브랜치를 
 미리 알아야 한다.
 시나리오   | 브랜치
 :---------|:------------
@@ -45,20 +98,21 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동
 기능 변경 릴리스의 콘텐츠 | `dev-<version>` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다.
 다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다.
 어떤 브랜치를 선택해야 할지 잘 모르는 경우 슬랙의 `#sig-docs` 에 문의한다.
-{{< note >}}
+{{< note >}} 풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
 풀 리퀘스트를 이미 제출했는데 기본 브랜치가 잘못되었다는 것을 알게 되면,
 제출자(제출자인 여러분만)가 이를 변경할 수 있다.
 {{< /note >}}
 ### PR 당 언어
-PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 각 언어마다 별도의 PR을 연다.
+PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 
 여러 언어로 동일한 코드 샘플을 동일하게 변경해야 하는 경우 
 각 언어마다 별도의 PR을 연다.
 ## 기여자를 위한 도구들
-`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.
+`kubernetes/website` 리포지터리의 
-
+[문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 
 디렉터리에는 기여 여정을 좀 더 순조롭게 도와주는 도구들이 포함되어 있다.
@@ -15,7 +15,7 @@ card:
 [새 기능 문서화](/docs/contribute/new-content/new-features/)를 참고한다.
 {{< /note >}}
-새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/overview/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
+새 콘텐츠 페이지를 기여하거나 기존 콘텐츠 페이지를 개선하려면, 풀 리퀘스트(PR)를 연다. [시작하기 전에](/ko/docs/contribute/new-content/#before-you-begin) 섹션의 모든 요구 사항을 준수해야 한다.
 변경 사항이 작거나, git에 익숙하지 않은 경우, [GitHub을 사용하여 변경하기](#github을-사용하여-변경하기)를 읽고 페이지를 편집하는 방법을 알아보자.
@@ -28,7 +28,40 @@ card:
 ## GitHub을 사용하여 변경하기
 git 워크플로에 익숙하지 않은 경우, 풀 리퀘스트를
-여는 쉬운 방법이 있다.
+여는 쉬운 방법이 있다. 아래의 그림은 각 단계를 보여주며, 상세사항은 그 아래에 나온다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR
 A([fa:fa-user 신규<br>기여자]) --- id1[(K8s/Website<br>GitHub)]
 subgraph tasks[GitHub 상에서 변경하기]
 direction TB
    0[ ] -.-
    1[1. '페이지 편집' 누르기] --> 2[2. GitHub 마크다운<br>편집기로 편집하기]
    2 --> 3[3. 'Propose file change'에<br>추가 내용 기재하기]
 end
 subgraph tasks2[ ]
 direction TB
 4[4. 'Propose changes' 누르기] --> 5[5. 'Create pull request' 누르기] --> 6[6. 'Open a pull request'에<br>추가 내용 기재하기]
 6 --> 7[7. 'Create pull request' 누르기] 
 end
 id1 --> tasks --> tasks2
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class A,1,2,3,4,5,6,7 grey
 class 0 spacewhite
 class tasks,tasks2 white
 class id1 k8s
 {{</ mermaid >}}
 ***그림 - GitHub 상에서 PR을 여는 단계***
 1.  이슈가 있는 페이지에서, 오른쪽 상단에 있는 연필 아이콘을 선택한다.
    페이지 하단으로 스크롤 하여 **페이지 편집하기** 를 선택할 수도 있다.
@@ -89,6 +122,37 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우,
 컴퓨터에 [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)이 설치되어 있는지 확인한다. git UI 애플리케이션을 사용할 수도 있다.
 아래 그림은 로컬 포크에서 작업할 때의 단계를 나타낸다. 상세 사항도 소개되어 있다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR
 1[K8s/website<br>저장소 포크하기] --> 2[로컬 클론 생성<br>및 upstream 설정]
 subgraph changes[당신의 변경사항]
 direction TB
 S[ ] -.-
 3[브랜치 생성<br>예: my_new_branch] --> 3a[텍스트 편집기로<br>변경사항 만들기] --> 4["Hugo (localhost:1313)<br>를 이용하거나<br>컨테이너 이미지를 빌드하여<br>변경사항을 로컬에서 미리보기"]
 end
 subgraph changes2[커밋 / 푸시]
 direction TB
 T[ ] -.-
 5[변경사항 커밋하기] --> 6[커밋을<br>origin/my_new_branch<br>로 푸시하기]
 end
 2 --> changes --> changes2
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class 1,2,3,3a,4,5,6 grey
 class S,T spacewhite
 class changes,changes2 white
 {{</ mermaid >}}
 ***그림 - 로컬 포크에서 변경 사항 작업하기***
 ### kubernetes/website 리포지터리 포크하기
 1. [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
@@ -230,7 +294,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 1.  로컬에서 이미지를 빌드한다.
      ```bash
      make docker-image
      # docker 사용(기본값)
      make container-image
@@ -243,7 +306,6 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 2. 로컬에서 `kubernetes-hugo` 이미지를 빌드한 후, 사이트를 빌드하고 서비스한다.
      ```bash
      make docker-serve
      # docker 사용(기본값)
      make container-serve
@@ -291,6 +353,34 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할
 ### 포크에서 kubernetes/website로 풀 리퀘스트 열기 {#open-a-pr}
 아래 그림은 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계를 보여 준다. 상세 사항은 아래에 등장한다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR
 subgraph first[ ]
 direction TB
 1[1. K8s/website 저장소로 이동] --> 2[2. 'New Pull Request' 클릭]
 2 --> 3[3. 'Compare across forks' 클릭]
 3 --> 4[4. 'head repository' 드롭다운 메뉴에서<br>당신의 포크 선택]
 end
 subgraph second [ ]
 direction TB
 5[5. 'compare' 드롭다운 메뉴에서<br>당신의 브랜치 선택] --> 6[6. 'Create Pull Request' 클릭]
 6 --> 7[7. PR 본문에 상세 설명 기재]
 7 --> 8[8. 'Create pull request' 클릭]
 end
 first --> second
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 class 1,2,3,4,5,6,7,8 grey
 class first,second white
 {{</ mermaid >}}
 ***그림 - 당신의 포크에서 K8s/website 저장소로 PR을 여는 단계***
 1. 웹 브라우저에서 [`kubernetes/website`](https://github.com/kubernetes/website/) 리포지터리로 이동한다.
 2. **New Pull Request** 를 선택한다.
 3. **compare across forks** 를 선택한다.
@@ -416,7 +506,6 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www.
    풀 리퀘스트에 더 이상 충돌이 표시되지 않는다.
 ### 커밋 스쿼시하기
 {{< note >}}
@@ -502,8 +591,6 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을
 느낌을 얻으려면 열린 이슈와 PR을 살펴보자. 이슈나 PR을 제출할 때
 가능한 한 상세하게 템플릿의 내용을 작성한다.
 ## {{% heading "whatsnext" %}}
@@ -116,6 +116,6 @@ PR 소유자에게 조언하는데 활용된다.
 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다.
- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/)
+- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/)
 - [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/)
 - [문서 스타일 가이드](/ko/docs/contribute/style/)
@@ -32,7 +32,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D
 - [슬랙](https://slack.k8s.io/) 또는
  [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다.
-[CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
+[CLA에 서명](/ko/docs/contribute/new-content/#sign-the-cla) 후에 누구나 다음을 할 수 있다.
 - 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다.
 - 다이어그램, 그래픽 자산 그리고 포함할 수 있는 스크린캐스트와 비디오를 제작한다.
@@ -18,7 +18,8 @@ weight: 10
 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와
  [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다.
 - 쿠버네티스 문서화 커뮤니티의 다양한
-  [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다.
+  [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 
  이해한다.
 <!-- body -->
@@ -35,7 +36,38 @@ weight: 10
 ## 리뷰 과정
-일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다.
+일반적으로, 영어로 콘텐츠와 스타일에 대한 풀 리퀘스트를 리뷰한다. 아래의 그림은 리뷰 과정의 단계를 보여 준다. 각 단계에 대한 상세 사항은 아래에 나와 있다.
 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
 {{< mermaid >}}
 flowchart LR
    subgraph fourth[리뷰 시작]
    direction TB
    S[ ] -.-
    M[코멘트 작성] --> N[변경사항 리뷰]
    N --> O[새 기여자가 어떤 코멘트를<br>반영할지 선택해야 함]
    end
    subgraph third[PR 선택]
    direction TB
    T[ ] -.-
    J[본문과 코멘트 확인]--> K[Netlify 미리보기 빌드로<br>변경사항 미리보기]
    end
  A[열려 있는 PR 목록 확인]--> B[레이블을 이용하여<br>PR을 필터링]
  B --> third --> fourth
 classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
 classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
 classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
 class A,B,J,K,M,N,O grey
 class S,T spacewhite
 class third,fourth white
 {{</ mermaid >}}
 ***그림 - 리뷰 과정 절차***
 1.  [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls)로
    이동한다.
@@ -43,7 +75,7 @@ weight: 10
    표시된다.
 2.  다음 레이블 중 하나 또는 모두를 사용하여 열린 PR을 필터링한다.
-    - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla)을 참고한다.
+    - `cncf-cla: yes`(권장): CLA에 서명하지 않은 기여자가 제출한 PR은 병합할 수 없다. 자세한 내용은 [CLA 서명](/ko/docs/contribute/new-content/#sign-the-cla)을 참고한다.
    - `language/en`(권장): 영어 문서에 대한 PR 전용 필터이다.
    - `size/<size>`: 특정 크기의 PR을 필터링한다. 새로 시작하는 사람이라면, 더 작은 PR로 시작한다.
@@ -105,7 +105,7 @@ YAML 블록이다. 여기 예시가 있다.
  포함할 수 있다.
 - 이 코드의 목적은 더 큰 파일의 일부를 강조하는 것이기 때문에
  불완전한 예제다. 예를 들어 몇 가지 이유로
-  [PodSecurityPolicy](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)
+  [PodSecurityPolicy](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)
  를 사용자 정의 방법을 설명할 때 문서 파일에서 직접 짧은 요약 정보를 제공할 수 있다.
 - 이 코드는 사용자가 다른 이유로 시도하기 위한 것이 아니다. 예를 들어
  `kubectl edit` 명령을 사용하여 리소스에 새 속성을 추가하는 방법을
@@ -134,6 +134,21 @@ kubectl auth can-i list secrets --namespace dev --as dave
 no
 ```
 유사하게, `dev` 네임스페이스의 `dev-sa` 서비스 어카운트가 
 `target` 네임스페이스의 파드 목록을 볼 수 있는지 확인하려면 다음을 실행한다.
 ```bash
 kubectl auth can-i list pods \
 	--namespace target \
 	--as system:serviceaccount:dev:dev-sa
 ```
 다음과 유사하게 출력된다.
 ```
 yes
 ```
 `SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서
 API 서버 인가를 외부 서비스에 노출시킨다.
 이 그룹의 기타 리소스에는 다음이 포함된다.
@@ -125,7 +125,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `HPAScaleToZero` | `false` | 알파 | 1.16 | |
 | `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
 | `IndexedJob` | `true` | 베타 | 1.22 | |
 | `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
 | `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
 | `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | |
 | `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
@@ -138,13 +137,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `IPv6DualStack` | `true` | 베타 | 1.21 | |
 | `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
 | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
 | `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
 | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
 | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
 | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
 | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
 | `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 |
 | `LogarithmicScaleDown` | `true` | 베타 | 1.22 | |
 | `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
 | `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
 | `MemoryManager` | `false` | 알파 | 1.21 | 1.21 |
 | `MemoryManager` | `true` | 베타 | 1.22 | |
 | `MemoryQoS` | `false` | 알파 | 1.22 | |
@@ -289,9 +288,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 | `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
 | `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
 | `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
 | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
 | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
 | `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
 | `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
 | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
 | `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
@@ -654,7 +650,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  [토큰 요청](https://kubernetes-csi.github.io/docs/token-requests.html)을 참조한다.
 - `CSIStorageCapacity`: CSI 드라이버가 스토리지 용량 정보를 게시하고
  쿠버네티스 스케줄러가 파드를 스케줄할 때 해당 정보를 사용하도록 한다.
-  [스토리지 용량](/docs/concepts/storage/storage-capacity/)을 참고한다.
+  [스토리지 용량](/ko/docs/concepts/storage/storage-capacity/)을 참고한다.
  자세한 내용은 [`csi` 볼륨 유형](/ko/docs/concepts/storage/volumes/#csi) 문서를 확인한다.
 - `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다.
  이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
@@ -698,7 +694,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `DisableCloudProviders`: `kube-apiserver`,  `kube-controller-manager`, 
  `--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의 
  모든 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
+- `DownwardAPIHugePages`: [다운워드 API](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)에서
  hugepages 사용을 활성화한다.
 - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
  요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다.
@@ -738,13 +734,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
 - `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면 
  kubelet과 kube-apiserver를 사용하도록 설정한다.
-  [확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다.
+  [확장된 DNS 구성](/ko/docs/concepts/services-networking/dns-pod-service/#확장된-dns-환경-설정)을 참고한다.
 - `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
  [사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
 - `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
  [퍼시스턴트 볼륨 클레임 확장](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트-볼륨-클레임-확장)을 참고한다.
 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로
-  어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
+  어노테이션을 달아서 [스케줄링이 보장되도록](/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다.
  이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다.
 - `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로
  기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트,
@@ -847,7 +843,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
 - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
 - `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
  반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
-  더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
+  더 자세한 정보는 [스왑 메모리](/ko/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
 - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
 - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
  삭제되지 않도록 한다.
@@ -970,7 +966,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
  참고한다.
 - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널
  파라미터(sysctl)를 지원한다. 자세한 내용은
-  [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
+  [sysctl](/ko/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다.
 - `TTLAfterFinished`: [TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가
  실행이 끝난 후 리소스를 정리하도록
  허용한다.
@@ -15,4 +15,4 @@ tags:
 <!--more-->
-대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다.
+많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다.
@@ -10,9 +10,9 @@ aka:
 tags:
 - fundamental
 ---
- 쿠버네티스에서 동일한 물리 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.
+ 쿠버네티스에서 하나의 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 내에서 리소스 그룹의 격리를 지원하기 위해 사용하는 추상적 개념.
 <!--more--> 
-네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다.
+네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트(예: 디플로이먼트, 서비스 등)에만 적용 가능하며 클러스터 범위의 오브젝트(예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등)에는 적용 불가능하다.
@@ -2,7 +2,7 @@
 title: sysctl
 id: sysctl
 date: 2019-02-12
-full_link: /docs/tasks/administer-cluster/sysctl-cluster/
+full_link: /ko/docs/tasks/administer-cluster/sysctl-cluster/
 short_description: >
  유닉스 커널 파라미터를 가져오거나 설정하는 데 사용하는 인터페이스
@@ -27,7 +27,7 @@ weight: 20
 보고서를 작성하려면, [쿠버네티스 버그 현상금 프로그램](https://hackerone.com/kubernetes)에 취약점을 제출한다. 이를 통해 표준화된 응답시간으로 취약점을 분류하고 처리할 수 있다.
-또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
+또한, 보안 세부 내용과 [모든 쿠버네티스 버그 보고서](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml)로 부터 예상되는 세부사항을 [security@kubernetes.io](mailto:security@kubernetes.io)로 이메일을 보낸다.
 [보안 대응 위원회(Security Response Committee) 구성원](https://git.k8s.io/security/README.md#product-security-committee-psc)의 GPG 키를 사용하여 이 목록으로 이메일을 암호화할 수 있다. GPG를 사용한 암호화는 공개할 필요가 없다.
@@ -187,7 +187,7 @@ kubectl exec -ti nginx-app-5jyvm -- /bin/sh
 # exit
 ```
-자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
+자세한 내용은 [실행 중인 컨테이너의 셸 얻기](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고한다.
 ## docker logs
@@ -0,0 +1,40 @@
 ---
 title: 포트와 프로토콜
 content_type: reference
 weight: 50
 ---
 물리적 네트워크 방화벽이 있는 온프레미스 데이터 센터 또는 
 퍼블릭 클라우드의 가상 네트워크와 같이 네트워크 경계가 엄격한 환경에서 
 쿠버네티스를 실행할 때, 쿠버네티스 구성 요소에서 
 사용하는 포트와 프로토콜을 알고 있는 것이 유용하다.
 ## 컨트롤 플레인
 | 프로토콜   | 방향       | 포트 범위    | 용도                      | 사용 주체                   |
 |----------|-----------|------------|-------------------------|---------------------------|
 | TCP      | 인바운드    | 6443       | 쿠버네티스 API 서버         | 전부                       |
 | TCP      | 인바운드    | 2379-2380  | etcd 서버 클라이언트 API    | kube-apiserver, etcd      |
 | TCP      | 인바운드    | 10250      | Kubelet API             | Self, 컨트롤 플레인          |
 | TCP      | 인바운드    | 10259      | kube-scheduler          | Self                      |
 | TCP      | 인바운드    | 10257      | kube-controller-manager | Self                      |
 etcd 포트가 컨트롤 플레인 섹션에 포함되어 있지만, 외부 또는 사용자 지정 포트에서 자체 
 etcd 클러스터를 호스팅할 수도 있다.
 ## 워커 노드 {#node}
 | 프로토콜   | 방향       | 포트 범위     | 용도                    | 사용 주체                 |
 |----------|-----------|-------------|-----------------------|-------------------------|
 | TCP      | 인바운드    | 10250       | Kubelet API           | Self, 컨트롤 플레인         
 | TCP      | 인바운드    | 30000-32767 | NodePort 서비스†        | 전부                     |
 † [노드포트(NodePort) 서비스](/ko/docs/concepts/services-networking/service/)의 기본 포트 범위.
 모든 기본 포트 번호를 재정의할 수 있다. 사용자 지정 포트를 사용하는 경우 
 여기에 언급된 기본값 대신 해당 포트를 열어야 한다.
 종종 발생하는 한 가지 일반적인 예는 API 서버 포트를 443으로 변경하는 경우이다. 
 또는, API 서버의 기본 포트를 그대로 유지하고, 
 443 포트에서 수신 대기하는 로드 밸런서 뒤에 API 서버를 두고, 
 로드 밸런서에서 API 서버로 가는 요청을 API 서버의 기본 포트로 라우팅할 수도 있다.
@@ -89,7 +89,7 @@ profiles:
  - plugins:
      score:
        disabled:
-        - name: NodeResourcesLeastAllocated
+        - name: PodTopologySpread
        enabled:
        - name: MyCustomPluginA
          weight: 2
@@ -116,10 +116,6 @@ profiles:
  익스텐션 포인트: `filter`.
 - `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다.
  익스텐션 포인트: `preFilter`, `filter`.
 - `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
  `scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라
  노드 점수를 매긴다.
  익스텐션 포인트: `score`.
 - `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
  [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
  구현한다.
@@ -195,8 +191,8 @@ profiles:
 - `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
  선호한다.
  익스텐션 포인트: `score`.
- `NodeLabel`: Filters and / or scores a node according to configured
+- `NodeLabel`: 설정된 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라 
-  {{< glossary_tooltip text="label(s)" term_id="label" >}}.
+  노드를 필터링하거나 스코어링한다.
  익스텐션 포인트: `Filter`, `Score`.
 - `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에
  속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
@@ -255,10 +251,47 @@ profiles:
 단 하나만 가질 수 있기 때문이다.
 {{< /note >}}
 ## 스케줄러 설정 전환
 {{< tabs name="tab_with_md" >}}
 {{% tab name="v1beta1 → v1beta2" %}}
 * 설정 버전 v1beta2 에서는, `NodeResourcesFit` 플러그인을 위한 새로운 스코어링 확장을 
  이용할 수 있다.
  새 확장은 `NodeResourcesLeastAllocated`, `NodeResourcesMostAllocated`, 
  `RequestedToCapacityRatio` 플러그인의 기능을 통합하여 제공한다.
  예를 들어, 이전에 `NodeResourcesMostAllocated` 플러그인을 사용했다면, 
  대신 `NodeResourcesFit`(기본적으로 활성화되어 있음)을 사용하면서 
  다음과 같이 `scoreStrategy`를 포함하는 `pluginConfig`를 추가할 수 있다.
  ```yaml
  apiVersion: kubescheduler.config.k8s.io/v1beta2
  kind: KubeSchedulerConfiguration
  profiles:
  - pluginConfig:
    - args:
        scoringStrategy:
          resources:
          - name: cpu
            weight: 1
          type: MostAllocated
      name: NodeResourcesFit
  ```
 * 스케줄러 플러그인 `NodeLabel`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [`NodeAffinity`](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 플러그인(기본적으로 활성화되어 있음)을 사용한다.
 * 스케줄러 플러그인 `ServiceAffinity`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [`InterPodAffinity`](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 플러그인(기본적으로 활성화되어 있음)을 사용한다.
 * 스케줄러 플러그인 `NodePreferAvoidPods`은 사용 중단되었다. 대신, 비슷한 효과를 얻기 위해 [노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 사용한다.
 * v1beta2 설정 파일에서 활성화된 플러그인은 해당 플러그인의 기본 설정값보다 v1beta2 설정 파일의 값이 우선 적용된다.
 * 스케줄러 healthz와 metrics 바인드 주소에 대해 `host` 또는 `port`가 잘못 설정되면 검증 실패를 유발한다.
 {{% /tab %}}
 {{< /tabs >}}
 ## {{% heading "whatsnext" %}}
 * [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
-* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
+* [kube-scheduler 설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
-* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
+* [kube-scheduler 설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
@@ -69,7 +69,11 @@ sudo sysctl --system
 ## 필수 포트 확인 {#check-required-ports}
 [필수 포트들](/docs/reference/ports-and-protocols/)은
 쿠버네티스 컴포넌트들이 서로 통신하기 위해서 열려 있어야
-한다.
+한다. 다음과 같이 telnet 명령을 이용하여 포트가 열려 있는지 확인해 볼 수 있다.
 ```shell
 telnet 127.0.0.1 6443
 ```
 사용자가 사용하는 파드 네트워크 플러그인(아래 참조)은 특정 포트를 열어야 할 수도
 있다. 이것은 각 파드 네트워크 플러그인마다 다르므로, 필요한 포트에 대한
@@ -147,7 +147,7 @@ LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리
 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능,
 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다.
 GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다.
-윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
+윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/ko/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
 ## 테인트(Taint)와 톨러레이션(Toleration)
@@ -2,6 +2,7 @@
 title: NGINX 인그레스(Ingress) 컨트롤러로 Minikube에서 인그레스 설정하기
 content_type: task
 weight: 100
 min-kubernetes-server-version: 1.19
 ---
 <!-- overview -->
@@ -17,23 +18,21 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 만약 이보다 더 이전 버전의 쿠버네티스를 사용하고 있다면, 
 해당 쿠버네티스 버전의 문서를 참고한다.
 ### Minikube 클러스터 생성하기
 Katacoda 활용하기
 : {{< kat-button >}}
 로컬에서 생성하기
 : 이미 로컬에 [Minikube를 설치](/ko/docs/tasks/tools/#minikube)했다면,
  `minikube start`를 실행하여 클러스터를 생성한다.
 <!-- steps -->
 ## Minikube 클러스터 생성하기
 1. **터미널 실행**을 클릭한다.
    {{< kat-button >}}
 1. (선택 사항) Minikube를 로컬로 설치한 경우 다음 명령을 실행한다.
    ```shell
    minikube start
    ```
 ## 인그레스 컨트롤러 활성화
 1. NGINX 인그레스 컨트롤러를 활성화하기 위해 다음 명령을 실행한다.
@@ -50,9 +49,9 @@ API 객체이다. [인그레스 컨트롤러](/ko/docs/concepts/services-network
 ```shell
 kubectl get pods -n ingress-nginx
 ```
-  {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
+   {{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}}
-Output:
+   결과는 다음과 같다.
 ```
 NAME                                        READY   STATUS      RESTARTS    AGE
@@ -61,14 +60,13 @@ ingress-nginx-admission-patch-rqp78         0/1     Completed   1          11m
 ingress-nginx-controller-59b45fb494-26npt   1/1     Running     0          11m
 ```
   {{% /tab %}}
   {{% tab name="minikube v1.18.1 or earlier" %}}
 ```shell
 kubectl get pods -n kube-system
 ```
-{{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
+   {{< note >}}파드가 정상적으로 실행되기까지 1분 정도 소요될 수 있다.{{< /note >}}
-Output:
+   결과는 다음과 같다.
 ```
 NAME                                        READY     STATUS    RESTARTS   AGE
@@ -79,27 +77,11 @@ kubernetes-dashboard-5498ccf677-b8p5h       1/1       Running   0          2m
 nginx-ingress-controller-5984b97644-rnkrg   1/1       Running   0          1m
 storage-provisioner                         1/1       Running   0          2m
 ```
  `nginx-ingress-controller-`로 시작하는 파드가 있는지 확인한다.
   {{% /tab %}}
   {{< /tabs >}}
    ```shell
    kubectl get pods -n ingress-nginx
    ```
    {{< note >}}이 작업은 1분 정도 소요될 수 있다.{{< /note >}}
    Output:
    ```shell
    NAME                                        READY   STATUS      RESTARTS   AGE
    ingress-nginx-admission-create-2tgrf        0/1     Completed   0          3m28s
    ingress-nginx-admission-patch-68b98         0/1     Completed   0          3m28s
    ingress-nginx-controller-59b45fb494-lzmw2   1/1     Running     0          3m28s
    ```
 ## hello, world 앱 배포하기
 1. 다음 명령을 사용하여 디플로이먼트(Deployment)를 생성한다.
@@ -108,9 +90,9 @@ storage-provisioner                         1/1       Running   0          2m
   kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   deployment.apps/web created
   ```
@@ -120,9 +102,9 @@ storage-provisioner                         1/1       Running   0          2m
   kubectl expose deployment web --type=NodePort --port=8080
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   service/web exposed
   ```
@@ -132,9 +114,9 @@ storage-provisioner                         1/1       Running   0          2m
   kubectl get service web
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
   web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
   ```
@@ -145,17 +127,17 @@ storage-provisioner                         1/1       Running   0          2m
   minikube service web --url
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   http://172.17.0.15:31637
   ```
   {{< note >}}Katacoda 환경만 해당: 터미널 패널 상단에서 더하기 기호를 클릭한 다음 **Select port to view on Host 1**을 클릭한다. 노드포트(이 경우 '31637')를 입력한 다음 **Display Port**를 클릭한다.{{< /note >}}
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
@@ -164,23 +146,23 @@ storage-provisioner                         1/1       Running   0          2m
   이제 Minikube IP 주소와 노드포트를 통해 샘플 앱에 액세스할 수 있다. 다음 단계에서는 
   인그레스 리소스를 사용하여 앱에 액세스할 수 있다.
-## 인그레스 리소스 생성하기
+## 인그레스 생성하기
-다음 파일은 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스 리소스다.
+다음 매니페스트는 hello-world.info를 통해 서비스로 트래픽을 보내는 인그레스를 정의한다.
 1. 다음 파일을 통해 `example-ingress.yaml`을 만든다.
  {{< codenew file="service/networking/example-ingress.yaml" >}}
-1. 다음 명령어를 실행하여 인그레스 리소스를 생성한다.
+1. 다음 명령어를 실행하여 인그레스 오브젝트를 생성한다.
   ```shell
   kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   ingress.networking.k8s.io/example-ingress created
   ```
@@ -192,20 +174,24 @@ storage-provisioner                         1/1       Running   0          2m
   {{< note >}}이 작업은 몇 분 정도 소요될 수 있다.{{< /note >}}
-    ```shell
+다음 예시와 같이, ADDRESS 열에서 IPv4 주소를 확인할 수 있다.
   ```
   NAME              CLASS    HOSTS              ADDRESS        PORTS   AGE
   example-ingress   <none>   hello-world.info   172.17.0.15    80      38s
   ```
-1. `/etc/hosts` 파일의 맨 아래에 다음 행을 추가한다.
+1. 호스트 컴퓨터의 `/etc/hosts` 파일 맨 아래에 
-
+   다음 행을 추가한다 (관리자 권한 필요).
    {{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}}
    ```
    172.17.0.15 hello-world.info
    ```
-    이것은 hello-world.info에서 Minikube로 요청을 보낸다.
+   {{< note >}}Minikube를 로컬에서 실행하는 경우 'minikube ip'를 사용하여 외부 IP를 가져온다. 인그레스 목록에 표시되는 IP 주소는 내부 IP가 된다.{{< /note >}}
    이렇게 하면, 웹 브라우저가 
    hello-world.info URL에 대한 요청을 Minikube로 전송한다.
 1. 인그레스 컨트롤러가 트래픽을 전달하는지 확인한다.
@@ -213,9 +199,9 @@ storage-provisioner                         1/1       Running   0          2m
    curl hello-world.info
    ```
-    Output:
+    결과는 다음과 같다.
-    ```shell
+    ```
    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
@@ -225,32 +211,33 @@ storage-provisioner                         1/1       Running   0          2m
 ## 두 번째 디플로이먼트 생성하기
-1. 다음 명령을 사용하여 v2 디플로이먼트를 생성한다.
+1. 다음 명령을 사용하여 두 번째 디플로이먼트를 생성한다.
   ```shell
   kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   deployment.apps/web2 created
   ```
-1. 디플로이먼트를 노출시킨다.
+1. 두 번째 디플로이먼트를 노출시킨다.
   ```shell
   kubectl expose deployment web2 --port=8080 --type=NodePort
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   service/web2 exposed
   ```
-## 인그레스 수정하기
+## 기존 인그레스 수정하기 {#edit-ingress}
-1. 기존 `example-ingress.yaml`을 편집하여 다음 줄을 추가한다.
+1. 기존 `example-ingress.yaml` 매니페스트를 편집하고, 
 하단에 다음 줄을 추가한다.
    ```yaml
          - path: /v2
@@ -268,9 +255,9 @@ storage-provisioner                         1/1       Running   0          2m
   kubectl apply -f example-ingress.yaml
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   ingress.networking/example-ingress configured
   ```
@@ -282,9 +269,9 @@ storage-provisioner                         1/1       Running   0          2m
   curl hello-world.info
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   Hello, world!
   Version: 1.0.0
   Hostname: web-55b8c6998d-8k564
@@ -296,9 +283,9 @@ storage-provisioner                         1/1       Running   0          2m
   curl hello-world.info/v2
   ```
-    Output:
+   결과는 다음과 같다.
-    ```shell
+   ```
   Hello, world!
   Version: 2.0.0
   Hostname: web2-75cd47646f-t8cjk
@@ -315,5 +302,3 @@ storage-provisioner                         1/1       Running   0          2m
 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 더 보기.
 * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 보기.
@@ -35,7 +35,7 @@ card:
 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 실행한다.
 ```
-kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml
 ```
 ## 대시보드 UI 접근
@@ -182,7 +182,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로바이더
  특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
 - **환경 변수**: 쿠버네티스 서비스를
-  [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
+  [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다.
  환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다.
  애플리케이션들이 서비스를 찾는데 사용된다.
  값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
@@ -88,8 +88,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
 * [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 배워 보기.
 * [퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)에 대해 더 배워 보기.
-### Reference
+### 레퍼런스 {#reference}
-* [퍼시스턴트볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
+* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
-* [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
+  * Pay attention to the 퍼시스턴트볼륨의 `.spec.persistentVolumeReclaimPolicy` [필드](docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)에 주의한다.
-* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)의 `persistentVolumeReclaimPolicy` 필드에 대해 보기.
+* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}
@@ -156,7 +156,7 @@ sysctl 설정이 필요한 노드에만 파드를 예약하는 것이 좋다.
 두 _unsafe_ sysctl을 명시적으로 활성화하지 않은 노드에서 _unsafe_ sysctl을 사용하는 
 파드가 시작되지 않는다. _node-level_ sysctl과 마찬가지로 
 [_테인트와 톨러레이션_ 특징](/docs/reference/generated/kubectl/kubectl-commands/#taint) 또는 
-[노드 테인트](/docs/concepts/scheduling-eviction/taint-and-toleration/)를 
+[노드 테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 
 사용하여 해당 파드를 오른쪽 노드에 
 스케줄하는 것을 추천한다.
@@ -122,5 +122,5 @@ ContainerAdministrator
 * [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/)
 * [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기)
-* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/)
+* [윈도우 파드와 컨테이너의 GMSA 구성](/ko/docs/tasks/configure-pod-container/configure-gmsa/)
@@ -91,7 +91,7 @@ kubectl describe pods ${POD_NAME}
 ### 파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우
-일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/docs/tasks/debug-application-cluster/debug-running-pod/)에
+일단 사용자의 파드가 스케줄 되면, [구동중인 파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/)에
 기술된 메서드를 디버깅에 사용할 수 있다.
@@ -69,7 +69,7 @@ kubectl exec -it cassandra -- sh
 ```
 더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
-/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
+/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
 ## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
@@ -87,7 +87,7 @@ kubectl exec -it cassandra -- sh
 {{< note >}}
 이 섹션에서 소개하는 예시를 사용하기 위해서는
-여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
+여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가
 활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
 {{< /note >}}
@@ -32,7 +32,7 @@ kubectl get pods -l app=myapp
 만약 오랜 시간동안 `Unknown`이나 `Terminating` 상태에 있는
 파드들을 발견하였다면, 이러한 파드들을 어떻게 다루는지 알아보기 위해 
-[스테이트풀셋 파드 삭제하기](/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
+[스테이트풀셋 파드 삭제하기](/ko/docs/tasks/run-application/delete-stateful-set/)를 참고하길 바란다.
 스테이트풀셋에 포함된 개별 파드들을 디버깅하기 위해서는
 [파드 디버그하기](/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/) 가이드를 참고하길 바란다.
@@ -152,5 +152,5 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값
 * [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
-* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
+* [컨테이너 안에서 커맨드를 실행하는 방법](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.
@@ -110,6 +110,6 @@ spec:
 ## {{% heading "whatsnext" %}}
-* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
+* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
 * [시크릿을 환경 변수로 사용하기](/ko/docs/concepts/configuration/secret/#시크릿을-환경-변수로-사용하기)에 대해 알아본다.
 * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
@@ -72,6 +72,6 @@ weight: 20
 ## {{% heading "whatsnext" %}}
-* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
+* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
 * [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
@@ -25,7 +25,7 @@ weight: 40
 실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
-* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
+* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
 * 볼륨 파일
 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
@@ -134,7 +134,7 @@ total 8
 원자적(atomic)으로 갱신한다.
 {{< note >}}
-다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath) 
+다운워드 API를 [subPath](/ko/docs/concepts/storage/volumes/#using-subpath) 
 볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
 {{< /note >}}
@@ -200,8 +200,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
  * 컨테이너의 CPU 요청(request)
  * 컨테이너의 메모리 한도(limit)
  * 컨테이너의 메모리 요청(request)
-  * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
+  * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
-  * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
+  * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
  * 컨테이너의 임시-스토리지 한도(limit)
  * 컨테이너의 임시-스토리지 요청(request)
@@ -27,7 +27,7 @@ weight: 30
 파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
 * 환경 변수
-* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api)
 파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
@@ -145,7 +145,7 @@ kubectl logs dapi-envars-resourcefieldref
 ## {{% heading "whatsnext" %}}
-* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)
 * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
 * [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
@@ -132,7 +132,7 @@ kubectl delete cronjob hello
 ## 크론 잡 명세 작성
 다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
-작업에 대한 일반적인 정보는 [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)와
+작업에 대한 일반적인 정보는 [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
 [kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
 크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
@@ -147,7 +147,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out
 #### 일부 노드에 리소스가 부족하다
 적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이
-중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
+중단되었다. 노드에 [리소스가 부족](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때
 발생할 수 있다.
 이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여
@@ -80,11 +80,11 @@ kubectl delete pvc -l app=myapp
 ### 스테이트풀셋 파드의 강제 삭제
-스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
+스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다.
 ## {{% heading "whatsnext" %}}
-[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
+[스테이트풀셋 파드 강제 삭제하기](/ko/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
@@ -91,6 +91,6 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'
 ## {{% heading "whatsnext" %}}
-[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.
+[스테이트풀셋 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.
@@ -82,8 +82,8 @@ service/php-apache created
 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를
 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다.
 간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다.
-(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
+kubectl run으로 각 파드는 200 밀리코어를 요청하므로,
-따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
+여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.
 이에 대한 자세한 알고리즘은 [여기](/ko/docs/tasks/run-application/horizontal-pod-autoscale/#알고리즘-세부-정보)를 참고하기 바란다.
 ```shell
@@ -196,7 +196,7 @@ kubectl delete pv mysql-pv-volume
 * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기
-* [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
+* [애플리케이션 배포하기](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해 더 배워보기
 * [kubectl run 문서](/docs/reference/generated/kubectl/kubectl-commands/#run)
@@ -0,0 +1,5 @@
 ---
 title: "서비스 카탈로그"
 description: 서비스 카탈로그 익스텐션(extension) API를 설치한다.
 weight: 150
 ---
@@ -0,0 +1,78 @@
 ---
 title: SC로 서비스 카탈로그 설치하기
 content_type: task
 ---
 <!-- overview -->
 {{< glossary_definition term_id="service-catalog" length="all" prepend="서비스 카탈로그는" >}}
 GCP [서비스 카탈로그 설치 프로그램](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation)
 도구로 쿠버네티스 클러스터에 서비스 카탈로그를 쉽게 설치하거나 제거하여 
 Google Cloud 프로젝트에 연결할 수 있다.
 서비스 카탈로그는 Google Cloud뿐 아니라 모든 종류의 관리형 서비스와 함께 작동할 수 있다.
 ## {{% heading "prerequisites" %}}
 * [서비스 카탈로그](/ko/docs/concepts/extend-kubernetes/service-catalog/)의 핵심 개념을 이해한다.
 * [Go 1.6+](https://golang.org/dl/)를 설치하고 `GOPATH`를 설정한다.
 * SSL 아티팩트 생성에 필요한 [cfssl](https://github.com/cloudflare/cfssl) 도구를 설치한다.
 * 서비스 카탈로그에는 Kubernetes 버전 1.7 이상이 필요하다.
 * [kubectl 설치 및 설정](/ko/docs/tasks/tools/)을 사용하여 Kubernetes 버전 1.7 이상의 클러스터에 연결하도록 구성한다.
 * kubectl 사용자는 서비스 카탈로그를 설치하기 위해 *cluster-admin* 역할에 바인딩되어야 한다. 이것이 사실인지 확인하려면 다음 명령을 실행한다.
        kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=<user-name>
 <!-- steps -->
 ## 로컬 환경에 `sc` 설치하기
 설치 프로그램은 로컬 컴퓨터에서 `sc`라는 CLI 도구로 실행된다.
 `go get`을 사용하여 설치한다.
 ```shell
 go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc
 ```
 `sc`는 이제 `GOPATH/bin` 디렉토리에 설치되어야 한다.
 ## 쿠버네티스 클러스터에 서비스 카탈로그 설치하기
 먼저 명령을 실행하여 모든 종속성이 설치되었는지 확인한다.
 ```shell
 sc check
 ```
 확인에 성공하면 다음을 반환해야 한다.
 ```
 Dependency check passed. You are good to go.
 ```
 그런 다음 설치 명령을 실행하고 백업에 사용할 `storageclass`를 지정한다.
 ```shell
 sc install --etcd-backup-storageclass "standard"
 ```
 ## 서비스 카탈로그 제거하기
 `sc` 도구를 사용하여 쿠버네티스 클러스터에서 서비스 카탈로그를 제거하려면 다음을 실행한다.
 ```shell
 sc uninstall
 ```
 ## {{% heading "whatsnext" %}}
 * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기
 * [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색
@@ -12,8 +12,8 @@ card:
 ## {{% heading "prerequisites" %}}
-클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
+클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
-최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
+호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
 ## 리눅스에 kubectl 설치
@@ -12,8 +12,8 @@ card:
 ## {{% heading "prerequisites" %}}
-클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
+클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
-최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
+호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
 ## macOS에 kubectl 설치
@@ -12,8 +12,8 @@ card:
 ## {{% heading "prerequisites" %}}
-클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다.
+클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew currentVersion >}} 클라이언트는 v{{< skew currentVersionAddMinor -1 >}}, v{{< skew currentVersion >}}, v{{< skew currentVersionAddMinor 1 >}}의 컨트롤 플레인과 연동될 수 있다.
-최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
+호환되는 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다.
 ## 윈도우에 kubectl 설치
@@ -346,21 +346,21 @@ Events:
 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)를 이용하여
 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다.
-### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
+### 파드시큐리티폴리시(PodSecurityPolicy)로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
 {{< note >}}
-PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다. 
+파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. 
-더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
+더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
 {{< /note >}}
-만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
+만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
-PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
+파드시큐리티폴리시를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
 ```
 --enable-admission-plugins=PodSecurityPolicy[,others...]
 ```
-AppArmor 옵션은 PodSecurityPolicy의 어노테이션으로 지정할 수 있다.
+AppArmor 옵션은 파드시큐리티폴리시의 어노테이션으로 지정할 수 있다.
 ```yaml
 apparmor.security.beta.kubernetes.io/defaultProfileName: <profile_ref>
@@ -390,7 +390,7 @@ AppArmor가 일반 사용자 버전이 되면 제거된다.
 ### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
 클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
-그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 PodSecurityPolicy 승인)을 거치지 않는다.
+그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
 그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
 파드의 권한을 docker-default 보다 높일 수 있다.
 이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
@@ -439,7 +439,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 ### 프로파일 참조 {#profile-reference}
 - `runtime/default`: 기본 런타임 프로파일을 참조한다.
-  - (기본 PodSecurityPolicy 없이) 프로파일을 지정하지 않고
+  - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
    AppArmor를 사용하는 것과 동등하다.
  - 도커에서는 권한 없는 컨테이너의 경우는
    [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
@@ -451,7 +451,7 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 다른 어떤 프로파일 참조 형식도 유효하지 않다.
-### PodSecurityPolicy 어노테이션 {#podsecuritypolicy-annotations}
+### 파드시큐리티폴리시 어노테이션 {#podsecuritypolicy-annotations}
 아무 프로파일도 제공하지 않을 때에 컨테이너에 적용할 기본 프로파일을 지정하기
@@ -301,5 +301,5 @@ minikube delete
 * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다.
-* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
+* [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다.
 * [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다.
@@ -239,4 +239,4 @@ kubectl apply -k ./
 * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자.
 * [잡](/ko/docs/concepts/workloads/controllers/job/)를 알아보자.
 * [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자.
-* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
+* 어떻게 [컨테이너에서 셸을 사용하는지](/ko/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자.
@@ -40,7 +40,6 @@ weight: 40
 튜토리얼을 시작하기 전에 수동으로 3개의 20 GiB 볼륨을
 프로비저닝해야 한다.
 ## {{% heading "objectives" %}}
 이 튜토리얼을 마치면 다음에 대해 알게 된다.
@@ -50,7 +49,6 @@ weight: 40
 - 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
 - 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
 <!-- lessoncontent -->
 ### ZooKeeper
@@ -262,13 +260,15 @@ server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
 ### 앙상블 무결성 테스트
-가장 기본적인 테스트는 한 ZooKeeper 서버에 데이터를 쓰고 다른 ZooKeeper 서버에서 데이터를 읽는 것이다.
+가장 기본적인 테스트는 한 ZooKeeper 서버에 데이터를 쓰고 
 다른 ZooKeeper 서버에서 데이터를 읽는 것이다.
 아래 명령어는 앙상블 내에 `zk-0` 파드에서 `/hello` 경로로 `world`를 쓰는 스크립트인 `zkCli.sh`를 실행한다.
 ```shell
-kubectl exec zk-0 zkCli.sh create /hello world
+kubectl exec zk-0 -- zkCli.sh create /hello world
 ```
 ```
 WATCHER::
@@ -279,7 +279,7 @@ Created /hello
 `zk-1` 파드에서 데이터를 읽기 위해 다음 명령어를 이용하자.
 ```shell
-kubectl exec zk-1 zkCli.sh get /hello
+kubectl exec zk-1 -- zkCli.sh get /hello
 ```
 `zk-0`에서 생성한 그 데이터는 앙상블 내에 모든 서버에서
@@ -409,7 +409,6 @@ numChildren = 0
 `zk` 스테이트풀셋의 `spec`에 `volumeClaimTemplates` 필드는 각 파드에 프로비전될 퍼시스턴트볼륨을 지정한다.
 ```yaml
 volumeClaimTemplates:
  - metadata:
@@ -443,7 +442,6 @@ datadir-zk-2   Bound     pvc-bee0817e-bcb1-11e6-994f-42010a800002   20Gi       R
 `스테이트풀셋`의 컨테이너 `template`의 `volumeMounts` 부분이 ZooKeeper 서버의 데이터 디렉터리에 퍼시스턴트볼륨 마운트하는 내용이다.
 ```shell
 volumeMounts:
 - name: datadir
@@ -591,6 +589,7 @@ kubectl exec zk-0 -- ps -elf
 `securityContext` 오브젝트의 `runAsUser` 필드 값이 1000 이므로
 루트 사용자로 실행하는 대신 ZooKeeper 프로세스는 ZooKeeper 사용자로 실행된다.
 ```
 F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
 4 S zookeep+     1     0  0  80   0 -  1127 -      20:46 ?        00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
@@ -695,6 +694,7 @@ kubectl exec zk-0 -- ps -ef
 컨테이너의 엔트리 포인트로 PID 1 인 명령이 사용되었으며
 ZooKeeper 프로세스는 엔트리 포인트의 자식 프로세스로 PID 27 이다.
 ```
 UID        PID  PPID  C STIME TTY          TIME CMD
 zookeep+     1     0  0 15:03 ?        00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
@@ -1033,7 +1033,6 @@ kubectl 을 종료하기 위해 `CTRL-C`를 이용하자.
 `zk-0`에서 온전성 테스트 때에 입력한 값을 가져오는 `zkCli.sh`를 이용하자.
 ```shell
 kubectl exec zk-0 zkCli.sh get /hello
 ```
@@ -1132,10 +1131,8 @@ drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인
 서비스는 혼란 예산을 표기한 서비스는 그 예산이 존중은 존중될 것이다.
 파드가 즉각적으로 재스케줄 할 수 있도록 항상 중요 서비스를 위한 추가 용량을 할당해야 한다.
 ## {{% heading "cleanup" %}}
 - `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다.
 - 반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자.
  귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서
@@ -0,0 +1,10 @@
 apiVersion: v1
 kind: Pod
 metadata:
  name: nginx
 spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
@@ -8,6 +8,6 @@ sitemap:
  priority: 0.5
 ---
-릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew latestVersion >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md)에 있다.
+릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew currentVersionAddMinor 0 >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew currentVersionAddMinor 0 >}}.md)에 있다.
-대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew latestVersion >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0)에서 확인한다.
+대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew currentVersionAddMinor 0 >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew currentVersionAddMinor 0 >}}.0)에서 확인한다.
@@ -14,6 +14,9 @@ class: training
        <h2>클라우드 네이티브 커리어를 구축하세요</h2>
        <p>쿠버네티스는 클라우드 네이티브 무브먼트의 핵심입니다. 리눅스 재단이 제공하는 교육과 인증 프로그램을 통해 커리어에 투자하고, 쿠버네티스를 배우며, 클라우드 네이티브 프로젝트를 성공적으로 수행하세요.</p>
      </div>
      <div class="logo-certification cta-image" id="logo-kcnf">
        <img src="/images/training/kubernetes-kcnf-white.svg" />
      </div>
      <div class="logo-certification cta-image" id="logo-cka">
        <img src="/images/training/kubernetes-cka-white.svg"/>
      </div>
@@ -81,6 +84,15 @@ class: training
  <div class="main-section padded">
    <h2>쿠버네티스 공인 자격 획득하기</h2>
    <div class="col-container">
      <div class="col-nav">
        <h5>
          <b>쿠버네티스 및 클라우드 네이티브 전문가(Kubernetes and Cloud Native Associate, KCNA)</b>
        </h5>
        <p>쿠버네티스 및 클라우드 네이티브 전문가 시험은 사용자의 쿠버네티스와 더 넓은 클라우드 네이티브 생태계에 대한 핵심 지식과 기술을 보여줍니다.</p>
        <p>인증된 KCNA는 전체적인 클라우드 네이티브 생태계, 특히 쿠버네티스에 대한 개념적 지식을 확인시켜 줄 것입니다.</p>
        <br>
        <a href="https://training.linuxfoundation.org/certification/kubernetes-cloud-native-associate/" target="_blank" class="button">Go to Certification</a>
      </div>
      <div class="col-nav">
          <h5>
            <b>공인 쿠버네티스 애플리케이션 개발자(Certified Kubernetes Application Developer, CKAD)</b>
`@@ -76,4 +76,4 @@ weight: 40`


	`* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.`	`* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.`
	`* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).`	`* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/ko/docs/tasks/access-application-cluster/ingress-minikube/).`
@@ -76,4 +76,4 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지

	`## {{% heading "whatsnext" %}}`	`## {{% heading "whatsnext" %}}`

	`* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.`	`* [임시 컨테이너 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.`
`@@ -15,4 +15,4 @@ tags:`

	`<!--more-->`	`<!--more-->`

	`대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다.`	`많은 클러스터 관리자가 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용하고 있다. 이러한 클러스터는 익스텐션이 미리 설치되어 제공된다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)을 별도로 설치할 필요가 없으며, 또한 익스텐션을 새로 만들어야 하는 사용자는 거의 없을 것이다.`
`@@ -91,6 +91,6 @@ kubectl patch pod <pod> -p '{"metadata":{"finalizers":null}}'`
	`## {{% heading "whatsnext" %}}`	`## {{% heading "whatsnext" %}}`


	`[스테이트풀셋 디버깅하기](/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.`	`[스테이트풀셋 디버깅하기](/ko/docs/tasks/debug-application-cluster/debug-stateful-set/)에 대해 더 알아보기.`