Merge branch 'dev-1.22-ko.3' into out-ko.3-m1

2021-11-23 02:45:15 +09:00
parent d75f6f2a46 0fcaddc0c9
commit c8deb047c2
67 changed files with 126 additions and 129 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 서비스를 설정한다.
@@ -51,7 +51,7 @@ weight: 10
 ```

 쿠버네티스는 내부적으로 노드 오브젝트를 생성한다(표시한다). 쿠버네티스는
-kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어있는지 확인한다.
+kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록이 되어 있는지 확인한다.
 노드가 정상이면(예를 들어 필요한 모든 서비스가 실행중인 경우) 파드를 실행할 수 있게 된다.
 그렇지 않으면, 해당 노드는 정상이 될 때까지 모든 클러스터 활동에
 대해 무시된다.
@@ -162,7 +162,7 @@ kubectl cordon $NODENAME
 kubectl describe node <insert-node-name-here>
 ```

-출력되는 각 섹션은 아래에 설명되어있다.
+출력되는 각 섹션은 아래에 설명되어 있다.

 ### 주소 {#addresses}

@@ -310,7 +310,7 @@ kubelet은 노드의 `.status` 생성과 업데이트 및
  내에 있는 NodeReady 컨디션을 업데이트한다.
  이 경우에는 노드 컨트롤러가 NodeReady 컨디션을 `ConditionUnknown`으로 설정한다.
 - 노드가 계속 접근 불가능 상태로 남아있는 경우, 해당 노드의 모든 파드에 대해서
-  [API를 이용한 축출](/docs/concepts/scheduling-eviction/api-eviction/)을
+  [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)을
  트리거한다. 기본적으로, 노드 컨트롤러는 노드를
  `ConditionUnknown`으로 마킹한 뒤 5분을 기다렸다가
  최초의 축출 요청을 시작한다. 
@@ -409,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/)
- [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- [`kubectl` 명령을 사용하여 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
+- [구성 파일로 시크릿 생성하기](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)
+- [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/)하는 방법 배우기
- [구성 파일을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
- [kustomize를 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
+- [`kubectl` 을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
+- [구성 파일을 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 배우기
+- [kustomize를 사용한 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 배우기
 - [API 레퍼런스](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)에서 `Secret`에 대해 읽기
@@ -22,7 +22,7 @@ no_list: true

 ## 컨테이너 이미지
 [컨테이너 이미지](/ko/docs/concepts/containers/images/)는 애플리케이션을
-실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어있는(ready-to-run) 소프트웨어 패키지이다.
+실행하는 데 필요한 모든 것이 포함된 실행할 준비가 되어 있는(ready-to-run) 소프트웨어 패키지이다.
 여기에는 실행하는 데 필요한 코드와 모든 런타임, 애플리케이션 및 시스템 라이브러리,
 그리고 모든 필수 설정에 대한 기본값이 포함된다.

@@ -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/)에 대해 알아보기
+
@@ -85,7 +85,7 @@ CNI 네트워킹 플러그인은 파드 수신 및 송신 트래픽 셰이핑도
 플러그인을 사용하거나 대역폭 제어 기능이 있는 자체 플러그인을 사용할 수 있다.

 트래픽 셰이핑 지원을 활성화하려면, CNI 구성 파일 (기본값 `/etc/cni/net.d`)에 `bandwidth` 플러그인을
-추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어있는지 확인한다.
+추가하고, 바이너리가 CNI 실행 파일 디렉터리(기본값: `/opt/cni/bin`)에 포함되어 있는지 확인한다.

 ```json
 {
@@ -50,7 +50,7 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시

 접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어 있다.

 유효한 레이블 값은 다음과 같다.
 * 63 자 이하여야 하고 (공백일 수도 있음),
@@ -95,7 +95,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
 {{< /note >}}

 {{< caution >}}
-일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어있는지 확인해야 한다.
+일치성 기준과 집합성 기준 조건 모두에 대해 논리적인 _OR_ (`||`) 연산자가 없다. 필터 구문이 적절히 구성되어 있는지 확인해야 한다.
 {{< /caution >}}

 ### _일치성 기준_ 요건
@@ -231,7 +231,7 @@ selector:
    - {key: environment, operator: NotIn, values: [dev]}
 ```

-`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어있어 일치하기 위해서는 모든 요건을 만족해야 한다.
+`matchLabels`는 `{key,value}`의 쌍과 매칭된다. `matchLabels`에 매칭된 단일 `{key,value}`는 `matchExpressions`의 요소와 같으며 `key` 필드는 "key"로, `operator`는 "In" 그리고 `values`에는 "value"만 나열되어 있다. `matchExpressions`는 파드 셀렉터의 요건 목록이다. 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다. In 및 NotIn은 설정된 값이 있어야 한다. `matchLabels`와 `matchExpressions` 모두 AND로 되어 있어 일치하기 위해서는 모든 요건을 만족해야 한다.

 #### 노드 셋 선택

@@ -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/)에 대해 더 배우기
@@ -265,7 +265,7 @@ PodSpec에 지정된 NodeAffinity도 적용된다.

 `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를
 선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다).
-생략되어있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.
+생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다.

 파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와
 연관된 `matchExpressions` 가 모두 충족되어야 한다.
@@ -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 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
@@ -56,7 +56,7 @@ kubectl get pods -l run=my-nginx -o yaml | grep podIP

 평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.

-쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
+쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어 있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.

 `kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.

@@ -346,7 +346,7 @@ kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert
 노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
 LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
 노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
-준비가 되어있다.
+준비가 되어 있다.

 ```shell
 kubectl get svc my-nginx -o yaml | grep nodePort -C 5
@@ -233,7 +233,7 @@ DNS 정책은 파드별로 설정할 수 있다.
  자세한 내용을 확인할 수 있다.

 {{< note >}}
-"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면
+"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어 있지 않다면
 "ClusterFirst"가 기본값으로 사용된다.
 {{< /note >}}

@@ -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/)
@@ -96,7 +96,7 @@ __podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드

 __policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다.

-__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.
+__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어 있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다.

 __egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다.

@@ -96,7 +96,7 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노

 * 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
  `topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
-  제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
+  제한되어 있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.

 * 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.

@@ -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/) 읽기
@@ -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}

@@ -358,7 +358,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
 `flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약
 Flocker내에 데이터셋이 없는 경우, 먼저 Flocker
 CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면
-Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에
+Flocker는 파드가 스케줄 되어 있는 노드에 다시 연결한다. 이는 필요에
 따라 파드 간에 데이터를 공유할 수 있다는 의미이다.

 {{< note >}}
@@ -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/)
@@ -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/)를 참고한다.

 데몬셋 오브젝트의 이름은 유효한
@@ -166,7 +166,7 @@ nodeAffinity:
 데몬셋의 파드와 통신할 수 있는 몇 가지 패턴은 다음과 같다.

 - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록
-  구성되어있다. 그들은 클라이언트들을 가지지 않는다.
+  구성되어 있다. 그들은 클라이언트들을 가지지 않는다.
 - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 
  노드IP를 통해 파드에 접근할 수 있다. 
  클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다.
@@ -50,13 +50,13 @@ _디플로이먼트(Deployment)_ 는 {{< glossary_tooltip text="파드" term_id=
  보다 정교한 선택 규칙의 적용이 가능하다.

  {{< note >}}
-  `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된
+  `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어 있다. `matchLabels` 에 매핑된
  단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, `key` 필드는 "key"에 그리고 `operator`는 "In"에 대응되며
  `value` 배열은 "value"만 포함한다.
  매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다.
  {{< /note >}}

-* `template` 필드에는 다음 하위 필드가 포함되어있다.
+* `template` 필드에는 다음 하위 필드가 포함되어 있다.
  * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다.
  * 파드 템플릿의 사양 또는 `.template.spec` 필드는
  파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는
@@ -1023,7 +1023,7 @@ echo $?

 디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서
 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다.
-기본적으로 10으로 되어있다.
+기본적으로 10으로 되어 있다.

 {{< note >}}
 명시적으로 이 필드를 0으로 설정하면 그 결과로 디플로이먼트의 기록을 전부 초기화를 하고,
@@ -1040,7 +1040,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-서브도메인-이름)이어야 한다.
@@ -369,7 +369,7 @@ spec:
  다른 접근 방식들은 기존에 컨테이너화된 애플리케이션에 보다 쉽게 적용할 수 있다.


-여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
+여기에 트레이드오프가 요약되어 있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다.
 패턴 이름은 예시와 더 자세한 설명을 위한 링크이다.

 |                  패턴                      | 단일 잡 오브젝트      | 작업 항목보다 파드가 적은가?       | 수정되지 않은 앱을 사용하는가? |
@@ -50,7 +50,7 @@ OwnerReference가 {{< glossary_tooltip term_id="controller" >}} 가 아니고

 {{< codenew file="controllers/frontend.yaml" >}}

-이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어있는 레플리카셋이
+이 매니페스트를 `frontend.yaml`에 저장하고 쿠버네티스 클러스터에 적용하면 정의되어 있는 레플리카셋이
 생성되고 레플리카셋이 관리하는 파드가 생성된다.

 ```shell
@@ -128,7 +128,7 @@ frontend-wtsmm   1/1     Running   0          6m36s
 kubectl get pods frontend-b2zdv -o yaml
 ```

-메타데이터의 ownerReferences 필드에 설정되어있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.
+메타데이터의 ownerReferences 필드에 설정되어 있는 프런트엔드 레플리카셋의 정보가 다음과 유사하게 나오는 것을 볼 수 있다.

 ```shell
 apiVersion: v1
@@ -223,7 +223,7 @@ pod2             1/1     Running   0          36s

 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다.
 레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다.
-쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
+쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어 있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다.
 API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.

 레플리카셋 오브젝트의 이름은 유효한
@@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한

 ### 파드 템플릿

-`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
+`.spec.template`은 레이블을 붙이도록 되어 있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다.
 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.

@@ -269,7 +269,7 @@ matchLabels:

 ### 레플리카셋과 해당 파드 삭제

-레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다.
+레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어 있는 모든 파드를 자동으로 삭제한다.

 REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로
 설정해야 한다.
@@ -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이
@@ -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)에 대해 알아보기.
@@ -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}