Merge pull request #22449 from kubernetes/dev-1.18-ko.7

Seventh Korean l10n work for release 1.18
2020-07-09 21:28:48 -07:00
parent ccc0444c4d f604a4b60a
commit 6bf2feba74
148 changed files with 2604 additions and 1350 deletions
@@ -5,80 +5,15 @@ weight: 50
 content_type: concept
 ---

-{{< toc >}}
-
 <!-- overview -->

-쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을 
-보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은 
+쿠버네티스 문서에서 이 섹션은 개별의 태스크를 수행하는 방법을
+보여준다. 한 태스크 페이지는 일반적으로 여러 단계로 이루어진 짧은
 시퀀스를 제공함으로써, 하나의 일을 수행하는 방법을 보여준다.


-
-<!-- body -->
-
-## 웹 UI (대시보드)
-
-쿠버네티스 클러스터에서 컨테이너화 된 애플리케이션을 관리 및 모니터하는 것을 돕기 위해서 대시보드 웹 유저 인터페이스를 디플로이하고 접속한다.
-
-## kubectl 커맨드라인 사용하기
-
-쿠버네티스 클러스터를 직접 관리하기 위해서 사용되는 `kubectl` 커맨드라인 툴을 설치 및 설정한다.
-
-## 파드 및 컨테이너 구성하기
-
-파드 및 컨테이너에 대한 일반적인 구성 태스크를 수행한다.
-
-## 애플리케이션 동작시키기
-
-롤링 업데이트, 파드에 정보 주입하기, 파드 수평적 오토스케일링 등, 일반적인 애플리케이션 관리 태스크를 수행한다.
-
-## 잡 동작시키기
-
-병렬 프로세싱을 사용하는 잡을 동작시킨다.
-
-## 클러스터의 애플리케이션에 접근하기
-
-클러스터 내에 있는 애플리케이션에 접근할 수 있도록 로드 밸런싱, 포트 포워딩, 방화벽 또는 DNS 구성 등을 구성한다.
-
-## 모니터링, 로깅, 디버깅
-
-클러스터 문제를 해결하거나 컨테이너화 된 애플리케이션을 디버깅하기 위해서 모니터링과 로깅을 설정한다.
-
-## 쿠버네티스 API에 접근하기
-
-쿠버네티스 API에 직접 접근하는 다양한 방법을 배운다.
-
-## TLS 사용하기
-
-클러스터 루트 인증 기관(CA)을 신뢰 및 사용하도록 애플리케이션을 구성한다.
-
-## 클러스터 운영하기(administering)
-
-클러스터를 운영하기 위한 일반적인 태스크를 배운다.
-
-## 스테이트풀 애플리케이션 관리하기
-
-스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다.
-
-## 클러스터 데몬
-
-롤링 업데이트를 수행과 같은, 데몬 셋 관리를 위한 일반적인 태스크를 수행한다.
-
-## GPU 관리하기
-
-클러스터의 노드들에 의해서 리소스로 사용될 NVIDIA GPU들을 구성 및 스케줄한다.
-
-## HugePage 관리하기
-
-클러스터에서 스케줄 가능한 리소스로서 Huge Page들을 구성 및 스케줄한다.
-
-
-
 ## {{% heading "whatsnext" %}}


-만약 태스크 페이지를 작성하고 싶다면, 
-[문서 풀 리퀘스트(Pull Request) 생성하기](/docs/home/contribute/create-pull-request/)를 참조한다.
-
-
+만약 태스크 페이지를 작성하고 싶다면,
+[문서 풀 리퀘스트(Pull Request) 생성하기](/ko/docs/contribute/new-content/new-content/)를 참조한다.
@@ -1,5 +1,6 @@
 ---
 title: "클러스터 내 어플리케이션 액세스"
+description: 클러스터의 애플리케이션에 접근하기 위해 로드 밸런싱, 포트 포워딩, 방화벽 설정 또는 DNS 구성을 설정한다.
 weight: 60
 ---

@@ -145,7 +145,7 @@ curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
 위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 
 두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 
 서버 접속에 사용한다.
-(이들은 `~/.kube` 디렉토리에 설치된다.) 
+(이들은 `~/.kube` 디렉터리에 설치된다.) 
 일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 
 root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다.

@@ -139,7 +139,7 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트
 * [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여
 더 공부한다.

-* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
+* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/ko/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여
 확인한다.

 * [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다.
@@ -147,8 +147,3 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트
 * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다.

 * [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)을 확인한다.
-
-
-
-
-
@@ -46,7 +46,7 @@ card:
 네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
 scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.

-`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
+`config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에
 다음 내용을 가진 `config-demo`라는 파일을 생성한다.

 ```shell
@@ -76,7 +76,7 @@ contexts:
 구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다.

-`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
+`config-exercise` 디렉터리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
 세부사항들을 추가한다.

 ```shell
@@ -245,7 +245,7 @@ kubectl config --kubeconfig=config-demo view --minify

 ## 두 번째 구성 파일 생성

-`config-exercise` 디렉토리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.
+`config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.

 ```shell
 apiVersion: v1
@@ -268,31 +268,31 @@ contexts:
 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다.
 예:

-### Linux
+### 리눅스
 ```shell
 export  KUBECONFIG_SAVED=$KUBECONFIG
 ```
-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
 $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
 ```
 `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
-Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
+리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다.
 `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
 익숙해지길 바란다.

 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.

-### Linux
+### 리눅스
 ```shell
 export  KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
 ```
-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
 $Env:KUBECONFIG=("config-demo;config-demo-2")
 ```

-`config-exercise` 디렉토리에서 다음 커맨드를 입력한다.
+`config-exercise` 디렉터리에서 다음 커맨드를 입력한다.

 ```shell
 kubectl config view
@@ -330,14 +330,14 @@ contexts:
 kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.

-## $HOME/.kube 디렉토리 탐색
+## $HOME/.kube 디렉터리 탐색

 만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
-해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
+해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉터리에 `config`라는
 파일을 가지고 있을 것이다.

 `$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
-보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
+보통 `config`라는 파일이 존재할 것이다. 해당 디렉터리 내에는 다른 구성 파일들도 있을 수 있다.
 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다.

 ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가
@@ -346,17 +346,17 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자.
 예:

-### Linux
+### 리눅스
 ```shell
 export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
 ```
-### Windows Powershell
+### 윈도우 Powershell
 ```shell
 $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
 ```

 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
-config-exercise 디렉토리에서 다음 커맨드를 실행한다.
+config-exercise 디렉터리에서 다음 커맨드를 실행한다.

 ```shell
 kubectl config view
@@ -366,12 +366,12 @@ kubectl config view

 `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>

-### Linux
+### 리눅스
 ```shell
 export KUBECONFIG=$KUBECONFIG_SAVED
 ```

-### Windows PowerShell
+### 윈도우 PowerShell
 ```shell
 $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
 ```
@@ -119,15 +119,15 @@ track=stable

 - **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.

- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
+- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/ko/docs/tasks/inject-data-application/define-command-argument-container/)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.

- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
+- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/ko/docs/concepts/workloads/pods/pod/#파드-컨테이너의-특권-privileged-모드)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.

 - **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.

 ### YAML 또는 JSON 파일 업로드

-쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
+쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/ko/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.

 배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.

@@ -144,9 +144,9 @@ track=stable
 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.

 #### 워크로드
-선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카셋(ReplicaSet), 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.

-워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
+워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카셋으로 관리하는 파드들 또는 새로운 레플리카셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.

 #### 서비스
 외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
@@ -169,5 +169,3 @@ track=stable

 더 많은 정보는
 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
-
-
@@ -1,5 +1,6 @@
 ---
 title: "클러스터 운영"
+description: 클러스터를 운영하기 위한 공통 태스크를 배운다.
 weight: 20
 ---

@@ -0,0 +1,451 @@
+---
+title: 쿠버네티스 API를 사용하여 클러스터에 접근하기
+content_type: task
+---
+
+<!-- overview -->
+이 페이지는 쿠버네티스 API를 사용하여 클러스터에 접근하는 방법을 보여준다.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+<!-- steps -->
+
+## 쿠버네티스 API에 접근
+
+### kubectl을 사용하여 처음으로 접근
+
+쿠버네티스 API에 처음 접근하는 경우, 쿠버네티스
+커맨드 라인 도구인 `kubectl` 을 사용한다.
+
+클러스터에 접근하려면, 클러스터 위치를 알고 접근할 수 있는 자격 증명이
+있어야 한다. 일반적으로, [시작하기 가이드](/ko/docs/setup/)를
+통해 작업하거나,
+다른 사람이 클러스터를 설정하고 자격 증명과 위치를 제공할 때 자동으로 설정된다.
+
+다음의 명령으로 kubectl이 알고 있는 위치와 자격 증명을 확인한다.
+
+```shell
+kubectl config view
+```
+
+많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를
+제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
+
+### REST API에 직접 접근
+
+kubectl은 API 서버 찾기와 인증을 처리한다. `curl` 이나 `wget` 과 같은 http 클라이언트 또는 브라우저를 사용하여 REST API에
+직접 접근하려는 경우, API 서버를 찾고 인증할 수 있는 여러 가지 방법이 있다.
+
+ 1. 프록시 모드에서 kubectl을 실행한다(권장). 이 방법은 저장된 API 서버 위치를 사용하고 자체 서명된 인증서를 사용하여 API 서버의 ID를 확인하므로 권장한다. 이 방법을 사용하면 중간자(man-in-the-middle, MITM) 공격이 불가능하다.
+ 1. 또는, 위치와 자격 증명을 http 클라이언트에 직접 제공할 수 있다. 이 방법은 프록시를 혼란스럽게 하는 클라이언트 코드와 동작한다. 중간자 공격으로부터 보호하려면, 브라우저로 루트 인증서를 가져와야 한다.
+
+ Go 또는 Python 클라이언트 라이브러리를 사용하면 프록시 모드에서 kubectl에 접근할 수 있다.
+
+#### kubectl 프록시 사용
+
+다음 명령은 kubectl을 리버스 프록시로 작동하는 모드에서 실행한다. API
+서버 찾기와 인증을 처리한다.
+
+다음과 같이 실행한다.
+
+```shell
+kubectl proxy --port=8080 &
+```
+
+자세한 내용은 [kubectl 프록시](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참고한다.
+
+그런 다음 curl, wget 또는 브라우저를 사용하여 API를 탐색할 수 있다.
+
+```shell
+curl http://localhost:8080/api/
+```
+
+출력은 다음과 비슷하다.
+
+```json
+{
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+#### kubectl 프록시 없이 접근
+
+다음과 같이 인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시
+사용을 피할 수 있다.
+
+`grep/cut` 방식을 사용한다.
+
+```shell
+# .KUBECONFIG에 여러 콘텍스트가 있을 수 있으므로, 가능한 모든 클러스터를 확인한다.
+kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
+
+# 위의 출력에서 상호 작용하려는 클러스터의 이름을 선택한다.
+export CLUSTER_NAME="some_server_name"
+
+# 클러스터 이름을 참조하는 API 서버를 가리킨다.
+APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
+
+# 토큰 값을 얻는다
+TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
+
+# TOKEN으로 API 탐색
+curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+```
+
+출력은 다음과 비슷하다.
+
+```json
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+`jsonpath` 방식을 사용한다.
+
+```shell
+APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
+TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
+curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
+
+위의 예는 `--insecure` 플래그를 사용한다. 이로 인해 MITM 공격이
+발생할 수 있다. kubectl이 클러스터에 접근하면 저장된 루트 인증서와
+클라이언트 인증서를 사용하여 서버에 접근한다. (`~/.kube` 디렉터리에
+설치된다.) 클러스터 인증서는 일반적으로 자체 서명되므로,
+http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 구성이
+필요할 수 있다.
+
+일부 클러스터에서, API 서버는 인증이 필요하지 않다.
+로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은
+없다. [API에 대한 접근 구성](/docs/reference/access-authn-authz/controlling-access/)은
+클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후
+고 가용성 지원과 충돌할 수 있다.
+
+### API에 프로그래밍 방식으로 접근
+
+쿠버네티스는 공식적으로 [Go](#go-client), [Python](#python-client), [Java](#java-client), [dotnet](#dotnet-client), [Javascript](#javascript-client) 및 [Haskell](#haskell-client) 용 클라이언트 라이브러리를 지원한다. 쿠버네티스 팀이 아닌 작성자가 제공하고 유지 관리하는 다른 클라이언트 라이브러리가 있다. 다른 언어에서 API에 접근하고 인증하는 방법에 대해서는 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 참고한다.
+
+#### Go 클라이언트 {#go-client}
+
+* 라이브러리를 얻으려면, 다음 명령을 실행한다. `go get k8s.io/client-go@kubernetes-<kubernetes-version-number>` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes/client-go/releases](https://github.com/kubernetes/client-go/releases)를 참고한다.
+* client-go 클라이언트 위에 애플리케이션을 작성한다.
+
+{{< note >}}
+
+client-go는 자체 API 오브젝트를 정의하므로, 필요한 경우, 기본 리포지터리가 아닌 client-go에서 API 정의를 가져온다. 예를 들어, `import "k8s.io/client-go/kubernetes"` 가 맞다.
+
+{{< /note >}}
+
+Go 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다.
+
+```golang
+import (
+  "fmt"
+  "k8s.io/apimachinery/pkg/apis/meta/v1"
+  "k8s.io/client-go/kubernetes"
+  "k8s.io/client-go/tools/clientcmd"
+)
+
+func main() {
+  // kubeconfig에서 현재 콘텍스트를 사용한다
+  // path-to-kubeconfig -- 예를 들어, /root/.kube/config
+  config, _ := clientcmd.BuildConfigFromFlags("", "<path-to-kubeconfig>")
+  // clientset을 생성한다
+  clientset, _ := kubernetes.NewForConfig(config)
+  // 파드를 나열하기 위해 API에 접근한다
+  pods, _ := clientset.CoreV1().Pods("").List(v1.ListOptions{})
+  fmt.Printf("There are %d pods in the cluster\n", len(pods.Items))
+}
+```
+
+애플리케이션이 클러스터에서 파드로 배치된 경우, [파드 내에서 API 접근](#accessing-the-api-from-within-a-pod)을 참고한다.
+
+#### Python 클라이언트 {#python-client}
+
+[Python 클라이언트](https://github.com/kubernetes-client/python)를 사용하려면, 다음 명령을 실행한다. `pip install kubernetes` 추가 설치 옵션은 [Python Client Library 페이지](https://github.com/kubernetes-client/python)를 참고한다.
+
+Python 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/python/blob/master/examples/out_of_cluster_config.py)를 참고한다.
+
+```python
+from kubernetes import client, config
+
+config.load_kube_config()
+
+v1=client.CoreV1Api()
+print("Listing pods with their IPs:")
+ret = v1.list_pod_for_all_namespaces(watch=False)
+for i in ret.items:
+    print("%s\t%s\t%s" % (i.status.pod_ip, i.metadata.namespace, i.metadata.name))
+```
+
+#### Java 클라이언트 {#java-client}
+
+* [Java 클라이언트](https://github.com/kubernetes-client/java)를 설치하려면, 다음을 실행한다.
+
+```shell
+# java 라이브러리를 클론한다
+git clone --recursive https://github.com/kubernetes-client/java
+
+# 프로젝트 아티팩트, POM 등을 설치한다
+cd java
+mvn install
+```
+
+어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/java/releases](https://github.com/kubernetes-client/java/releases)를 참고한다.
+
+Java 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/KubeConfigFileClientExample.java)를 참고한다.
+
+```java
+package io.kubernetes.client.examples;
+
+import io.kubernetes.client.ApiClient;
+import io.kubernetes.client.ApiException;
+import io.kubernetes.client.Configuration;
+import io.kubernetes.client.apis.CoreV1Api;
+import io.kubernetes.client.models.V1Pod;
+import io.kubernetes.client.models.V1PodList;
+import io.kubernetes.client.util.ClientBuilder;
+import io.kubernetes.client.util.KubeConfig;
+import java.io.FileReader;
+import java.io.IOException;
+
+/**
+ * 쿠버네티스 클러스터 외부의 애플리케이션에서 Java API를 사용하는 방법에 대한 간단한 예
+ *
+ * <p>이것을 실행하는 가장 쉬운 방법: mvn exec:java
+ * -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"
+ *
+ */
+public class KubeConfigFileClientExample {
+  public static void main(String[] args) throws IOException, ApiException {
+
+    // KubeConfig의 파일 경로
+    String kubeConfigPath = "~/.kube/config";
+
+    // 파일시스템에서 클러스터 외부 구성인 kubeconfig 로드
+    ApiClient client =
+        ClientBuilder.kubeconfig(KubeConfig.loadKubeConfig(new FileReader(kubeConfigPath))).build();
+
+    // 전역 디폴트 api-client를 위에서 정의한 클러스터 내 클라이언트로 설정
+    Configuration.setDefaultApiClient(client);
+
+    // CoreV1Api는 전역 구성에서 디폴트 api-client를 로드
+    CoreV1Api api = new CoreV1Api();
+
+    // CoreV1Api 클라이언트를 호출한다
+    V1PodList list = api.listPodForAllNamespaces(null, null, null, null, null, null, null, null, null);
+    System.out.println("Listing all pods: ");
+    for (V1Pod item : list.getItems()) {
+      System.out.println(item.getMetadata().getName());
+    }
+  }
+}
+```
+
+#### dotnet 클라이언트 {#dotnet-client}
+
+[dotnet 클라이언트](https://github.com/kubernetes-client/csharp)를 사용하려면, 다음 명령을 실행한다. `dotnet add package KubernetesClient --version 1.6.1` 추가 설치 옵션은 [dotnet Client Library 페이지](https://github.com/kubernetes-client/csharp)를 참고한다. 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/csharp/releases](https://github.com/kubernetes-client/csharp/releases)를 참고한다.
+
+dotnet 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/csharp/blob/master/examples/simple/PodList.cs)를 참고한다.
+
+```csharp
+using System;
+using k8s;
+
+namespace simple
+{
+    internal class PodList
+    {
+        private static void Main(string[] args)
+        {
+            var config = KubernetesClientConfiguration.BuildDefaultConfig();
+            IKubernetes client = new Kubernetes(config);
+            Console.WriteLine("Starting Request!");
+
+            var list = client.ListNamespacedPod("default");
+            foreach (var item in list.Items)
+            {
+                Console.WriteLine(item.Metadata.Name);
+            }
+            if (list.Items.Count == 0)
+            {
+                Console.WriteLine("Empty!");
+            }
+        }
+    }
+}
+```
+
+#### JavaScript 클라이언트 {#javascript-client}
+
+[JavaScript 클라이언트](https://github.com/kubernetes-client/javascript)를 설치하려면, 다음 명령을 실행한다. `npm install @kubernetes/client-node` 어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/javascript/releases](https://github.com/kubernetes-client/javascript/releases)를 참고한다.
+
+JavaScript 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/javascript/blob/master/examples/example.js)를 참고한다.
+
+```javascript
+const k8s = require('@kubernetes/client-node');
+
+const kc = new k8s.KubeConfig();
+kc.loadFromDefault();
+
+const k8sApi = kc.makeApiClient(k8s.CoreV1Api);
+
+k8sApi.listNamespacedPod('default').then((res) => {
+    console.log(res.body);
+});
+```
+
+#### Haskell 클라이언트 {#haskell-client}
+
+어떤 버전이 지원되는지를 확인하려면 [https://github.com/kubernetes-client/haskell/releases](https://github.com/kubernetes-client/haskell/releases)를 참고한다.
+
+Haskell 클라이언트는 kubectl CLI가 API 서버를 찾아 인증하기 위해 사용하는 것과 동일한 [kubeconfig 파일](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)을
+사용할 수 있다. 이 [예제](https://github.com/kubernetes-client/haskell/blob/master/kubernetes-client/example/App.hs)를 참고한다.
+
+```haskell
+exampleWithKubeConfig :: IO ()
+exampleWithKubeConfig = do
+    oidcCache <- atomically $ newTVar $ Map.fromList []
+    (mgr, kcfg) <- mkKubeClientConfig oidcCache $ KubeConfigFile "/path/to/kubeconfig"
+    dispatchMime
+            mgr
+            kcfg
+            (CoreV1.listPodForAllNamespaces (Accept MimeJSON))
+        >>= print
+```
+
+
+### 파드 내에서 API에 접근 {#accessing-the-api-from-within-a-pod}
+
+파드 내에서 API에 접근할 때, API 서버를 찾아 인증하는 것은
+위에서 설명한 외부 클라이언트 사례와 약간 다르다.
+
+파드에서 쿠버네티스 API를 사용하는 가장 쉬운 방법은
+공식 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이다. 이러한
+라이브러리는 API 서버를 자동으로 감지하고 인증할 수 있다.
+
+#### 공식 클라이언트 라이브러리 사용
+
+파드 내에서, 쿠버네티스 API에 연결하는 권장 방법은 다음과 같다.
+
+  - Go 클라이언트의 경우, 공식 [Go 클라이언트 라이브러리](https://github.com/kubernetes/client-go/)를 사용한다.
+    `rest.InClusterConfig()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
+    [여기 예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)를 참고한다.
+
+  - Python 클라이언트의 경우, 공식 [Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python/)를 사용한다.
+    `config.load_incluster_config()` 기능은 API 호스트 검색과 인증을 자동으로 처리한다.
+    [여기 예제](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)를 참고한다.
+
+  - 사용할 수 있는 다른 라이브러리가 많이 있다. [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 페이지를 참고한다.
+
+각각의 경우, 파드의 서비스 어카운트 자격 증명은 API 서버와
+안전하게 통신하는 데 사용된다.
+
+#### REST API에 직접 접근
+
+파드에서 실행되는 동안, 쿠버네티스 apiserver는 `default` 네임스페이스에서 `kubernetes`라는
+서비스를 통해 접근할 수 있다. 따라서, 파드는 `kubernetes.default.svc`
+호스트 이름을 사용하여 API 서버를 쿼리할 수 있다. 공식 클라이언트 라이브러리는
+이를 자동으로 수행한다.
+
+API 서버를 인증하는 권장 방법은 [서비스 어카운트](/docs/user-guide/service-accounts)
+자격 증명을 사용하는 것이다. 기본적으로, 파드는
+서비스 어카운트와 연결되어 있으며, 해당 서비스 어카운트에 대한 자격 증명(토큰)은
+해당 파드에 있는 각 컨테이너의 파일시스템 트리의
+`/var/run/secrets/kubernetes.io/serviceaccount/token` 에 있다.
+
+사용 가능한 경우, 인증서 번들은 각 컨테이너의
+파일시스템 트리의 `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt` 에 배치되며,
+API 서버의 제공 인증서를 확인하는 데 사용해야 한다.
+
+마지막으로, 네임스페이스가 지정된 API 작업에 사용되는 기본 네임스페이스는 각 컨테이너의
+`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 에 있는 파일에 배치된다.
+
+#### kubectl 프록시 사용
+
+공식 클라이언트 라이브러리 없이 API를 쿼리하려면, 파드에서
+새 사이드카 컨테이너의 [명령](/ko/docs/tasks/inject-data-application/define-command-argument-container/)으로
+`kubectl proxy` 를 실행할 수 있다. 이런 식으로, `kubectl proxy` 는
+API를 인증하고 이를 파드의 `localhost` 인터페이스에 노출시켜서, 파드의
+다른 컨테이너가 직접 사용할 수 있도록 한다.
+
+#### 프록시를 사용하지 않고 접근
+
+인증 토큰을 API 서버에 직접 전달하여 kubectl 프록시 사용을
+피할 수 있다. 내부 인증서는 연결을 보호한다.
+
+```shell
+# 내부 API 서버 호스트 이름을 가리킨다
+APISERVER=https://kubernetes.default.svc
+
+# ServiceAccount 토큰 경로
+SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
+
+# 이 파드의 네임스페이스를 읽는다
+NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
+
+# ServiceAccount 베어러 토큰을 읽는다
+TOKEN=$(cat ${SERVICEACCOUNT}/token)
+
+# 내부 인증 기관(CA)을 참조한다
+CACERT=${SERVICEACCOUNT}/ca.crt
+
+# TOKEN으로 API를 탐색한다
+curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api
+```
+
+출력은 다음과 비슷하다.
+
+```json
+{
+  "kind": "APIVersions",
+  "versions": [
+    "v1"
+  ],
+  "serverAddressByClientCIDRs": [
+    {
+      "clientCIDR": "0.0.0.0/0",
+      "serverAddress": "10.0.1.149:443"
+    }
+  ]
+}
+```
@@ -0,0 +1,134 @@
+---
+title: 클러스터에서 실행되는 서비스에 접근
+content_type: task
+---
+
+<!-- overview -->
+이 페이지는 쿠버네티스 클러스터에서 실행되는 서비스에 연결하는 방법을 보여준다.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+<!-- steps -->
+
+## 클러스터에서 실행되는 서비스에 접근
+
+쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/pod/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두
+고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수
+없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서
+도달할 수 없다.
+
+### 연결하는 방법
+
+클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다.
+
+  - 퍼블릭 IP를 통해 서비스에 접근한다.
+    - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서
+      접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와
+      [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다.
+    - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며,
+      인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다.
+      자체 인증을 수행하는가?
+    - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면,
+      파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다.
+    - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접
+      접근할 필요는 없다.
+  - 프록시 작업(Proxy Verb)을 사용하여 서비스, 노드 또는 파드에 접근한다.
+    - 원격 서비스에 접근하기 전에 apiserver 인증과 권한 부여를 수행한다.
+      서비스가 인터넷에 노출되거나, 노드 IP의 포트에 접근하거나, 디버깅하기에
+      충분히 안전하지 않은 경우 사용한다.
+    - 프록시는 일부 웹 애플리케이션에 문제를 일으킬 수 있다.
+    - HTTP/HTTPS에서만 작동한다.
+    - [여기](#apiserver-프록시-url-수동-구성)에 설명되어 있다.
+  - 클러스터의 노드 또는 파드에서 접근한다.
+    - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 셸에 연결한다.
+      해당 셸에서 다른 노드, 파드 및 서비스에 연결한다.
+    - 일부 클러스터는 클러스터의 노드로 ssh를 통해 접근하는 것을 허용한다. 거기에서 클러스터 서비스에
+      접근할 수 있다. 이것은 비표준 방법이며, 일부 클러스터에서는 작동하지만 다른 클러스터에서는
+      작동하지 않는다. 브라우저 및 기타 도구가 설치되거나 설치되지 않을 수 있다. 클러스터 DNS가 작동하지 않을 수도 있다.
+
+### 빌트인 서비스 검색
+
+일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을
+사용하여 이들의 목록을 얻는다.
+
+```shell
+kubectl cluster-info
+```
+
+출력은 다음과 비슷하다.
+
+```
+Kubernetes master is running at https://104.197.5.247
+elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
+kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy
+kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy
+grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
+heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
+```
+
+각 서비스에 접근하기 위한 프록시-작업 URL이 표시된다.
+예를 들어, 이 클러스터에는 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` 로
+접근할 수 있는 (Elasticsearch를 사용한) 클러스터 수준 로깅이 활성화되어 있다. 적합한 자격 증명이 전달되는 경우나 kubectl proxy를 통해 도달할 수 있다. 예를 들어 다음의 URL에서 확인할 수 있다.
+`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`.
+
+{{< note >}}
+자격 증명을 전달하거나 kubectl proxy를 사용하는 방법은 [쿠버네티스 API를 사용하여 클러스터에 접근하기](/ko/docs/tasks/administer-cluster/access-cluster-api/)를 참고한다.
+{{< /note >}}
+
+#### apiserver 프록시 URL 수동 구성
+
+위에서 언급한 것처럼, `kubectl cluster-info` 명령을 사용하여 서비스의 프록시 URL을 검색한다. 서비스 엔드포인트, 접미사 및 매개 변수를 포함하는 프록시 URL을 작성하려면, 단순히 서비스의 프록시 URL에 추가하면 된다.
+`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`[https:]service_name[:port_name]`*`/proxy`
+
+포트에 대한 이름을 지정하지 않은 경우, URL에 *port_name* 을 지정할 필요가 없다.
+
+##### 예제
+
+* Elasticsearch 서비스 엔드포인트 `_search?q=user:kimchy` 에 접근하려면, 다음을 사용한다.
+
+    ```
+    http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
+    ```
+
+* Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다.
+
+    ```
+    https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
+    ```
+
+    상태 정보는 다음과 비슷하다.
+
+    ```json
+    {
+      "cluster_name" : "kubernetes_logging",
+      "status" : "yellow",
+      "timed_out" : false,
+      "number_of_nodes" : 1,
+      "number_of_data_nodes" : 1,
+      "active_primary_shards" : 5,
+      "active_shards" : 5,
+      "relocating_shards" : 0,
+      "initializing_shards" : 0,
+      "unassigned_shards" : 5
+    }
+    ```
+
+* *https* Elasticsearch 서비스 상태 정보 `_cluster/health?pretty=true` 에 접근하려면, 다음을 사용한다.
+
+    ```
+    https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true
+    ```
+
+#### 웹 브라우저를 사용하여 클러스터에서 실행되는 서비스에 접근
+
+브라우저의 주소 표시줄에 apiserver 프록시 URL을 넣을 수 있다. 그러나,
+
+  - 웹 브라우저는 일반적으로 토큰을 전달할 수 없으므로, 기본 (비밀번호) 인증을 사용해야 할 수도 있다. Apiserver는 기본 인증을 수락하도록 구성할 수 있지만,
+    클러스터는 기본 인증을 수락하도록 구성되지 않을 수 있다.
+  - 일부 웹 앱, 특히 프록시 경로 접두사를 인식하지 못하는 방식으로 URL을 구성하는 클라이언트 측 자바스크립트가 있는
+    웹 앱이 작동하지 않을 수 있다.
@@ -4,7 +4,7 @@ content_type: task
 ---

 <!-- overview -->
-이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 
+이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝
 하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다.


@@ -20,21 +20,21 @@ content_type: task

 ## 왜 기본 스토리지 클래스를 변경하는가?

-설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 
-스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 
-스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 
+설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존
+스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정
+스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를
 동적으로 프로비저닝 하기 위해 사용된다.
-더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를
+더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임)를
 보자.

-미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 
-않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 
-수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 
+미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지
+않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할
+수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
 하여 스토리지의 동적 프로비저닝을 방지할 수 있다.

-단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 
-애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 
-및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. 
+단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인
+애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자
+및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자.

 ## 기본 스토리지클래스 변경하기

@@ -56,7 +56,7 @@ content_type: task

 1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다.

-      기본 스토리지클래스에는 
+      기본 스토리지클래스에는
      `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다.
      다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다.

@@ -5,9 +5,9 @@ content_type: concept

 <!-- overview -->

-이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성, 
-클러스터의 마스터와 워커 노드들의 업그레이드, 
-노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의 
+이 문서는 클러스터의 라이프사이클에 관련된 몇 가지 주제들을 설명한다. 신규 클러스터 생성,
+클러스터의 마스터와 워커 노드들의 업그레이드,
+노드 유지보수(예. 커널 업그레이드) 수행, 운영 중인 클러스터의
 쿠버네티스 API 버전 업그레이드.


@@ -25,17 +25,17 @@ content_type: concept

 ### Azure Kubernetes Service (AKS) 클러스터 업그레이드

-Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는 
+Azure Kubernetes Service는 클러스터의 컨트롤 플레인과 노드를 손쉽게 셀프 서비스 업그레이드할 수 있게 해준다. 프로세스는
 현재 사용자가 직접 시작하는 방식이며 [Azure AKS 문서](https://docs.microsoft.com/en-us/azure/aks/upgrade-cluster)에 설명되어 있다.

 ### Google Compute Engine 클러스터 업그레이드

-Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고 
-재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해 
+Google Compute Engine Open Source (GCE-OSS)는 마스터를 삭제하고
+재생성하는 방식으로 마스터 업그레이드를 지원한다. 하지만 업그레이드 간에 데이터를 보존하기 위해
 동일한 Persistent Disk(PD)를 유지한다.

-GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는 
-순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은 
+GCE의 노드 업그레이드는 [관리형 인스턴스 그룹](https://cloud.google.com/compute/docs/instance-groups/)을 사용하며, 각 노드는
+순차적으로 제거된 후에 신규 소프트웨어를 가지고 재생성된다. 해당 노드에서 동작하는 파드들은
 레플리케이션 컨트롤러에 의해서 제어되거나, 롤 아웃 후에 수작업으로 재생성되어야 한다.

 open source Google Compute Engine(GCE) 클러스터 업그레이드는 `cluster/gce/upgrade.sh` 스크립트로 제어한다.
@@ -81,7 +81,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레

 ## 클러스터 크기 재조정

-[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다. 
+[노드 자가 등록 모드](/ko/docs/concepts/architecture/nodes/#노드에-대한-자체-등록)로 운영 중인 클러스터가 리소스가 부족하다면 쉽게 머신들을 더 추가할 수 있다. GCE나 Google Kubernetes Engine을 사용하고 있다면 노드들을 관리하는 인스턴스 그룹의 크기를 재조정하여 이를 수행할 수 있다.
 [Google Cloud 콘솔 페이지](https://console.developers.google.com)를 사용한다면 `Compute > Compute Engine > Instance groups > your group > Edit group`에서 인스턴스들의 숫자를 고쳐서 이를 수행할 수 있으며 gcloud CLI를 사용한다면 다음 커맨드를 사용하여 이를 수행할 수 있다.

 ```shell
@@ -99,23 +99,23 @@ Azure Kubernetes Service는 사용자가 CLI나 Azure 포털에서 클러스터

 ### 클러스터 오토스케일링

-GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로 
+GCE나 Google Kubernetes Engine을 사용한다면, 파드가 필요로하는 리소스를 기반으로 클러스터의 크기를 자동으로
 재조정하도록 클러스터를 구성할 수 있다.

-[컴퓨트 리소스](/docs/concepts/configuration/manage-compute-resources-container/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. 
-이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다. 
-여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는 
+[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)에 기술된 것처럼 사용자들은 파드에 얼마만큼의 CPU와 메모리를 할당할 것인지 예약할 수 있다. 
+이 정보는 쿠버네티스 스케줄러가 해당 파드를 어디에서 실행시킬 것인지를 결정할 때 사용된다.
+여유 용량이 넉넉한 노드가 없다면 (또는 다른 파드 요구조건을 충족하지 못한다면) 해당 파드는
 다른 파드들이 종료될 때까지 기다리거나 신규 노드가 추가될 때까지 기다린다.

-Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를 
+Cluster autoscaler는 스케줄링될 수 없는 파드들을 검색하여 클러스터 내의 다른 노드들과 유사한 신규 노드를
 추가하는 것이 도움이 되는지를 체크한다. 만약 도움이 된다면 대기중인 파드들을 수용하기 위해 클러스터의 크기를 재조정한다.

-Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안 
+Cluster autoscaler는 또한 하나 이상의 노드들이 장기간(10분, 하지만 미래에는 변경될 수 있다.)동안
 더 이상 필요하지 않다는 것을 확인했을 때 클러스터를 스케일 다운하기도 한다.

 Cluster autoscaler는 인스턴스 그룹(GCE)이나 노드 풀(Google Kubernetes Engine) 단위로 구성된다.

-GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다. 
+GCE를 사용한다면 kube-up.sh 스크립트로 클러스터를 생성할 때 Cluster autoscaler를 활성화할 수 있다.
 cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설정해야 한다.

 * `KUBE_ENABLE_CLUSTER_AUTOSCALER` - true로 설정되면 cluster autoscaler를 활성화한다.
@@ -128,8 +128,8 @@ cluster autoscaler를 구성하려면 다음 세 가지 환경 변수들을 설
 KUBE_ENABLE_CLUSTER_AUTOSCALER=true KUBE_AUTOSCALER_MIN_NODES=3 KUBE_AUTOSCALER_MAX_NODES=10 NUM_NODES=5 ./cluster/kube-up.sh
 ```

-Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의 
-생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을 
+Google Kubernetes Engine에서는 클러스터 생성이나 업데이트, 또는 (오토스케일하려고 하는) 특정 노드 풀의
+생성 시기에 해당 `gcloud` 커맨드에 `--enable-autoscaling` `--minnodes` `--maxnodes` 플래그들을
 전달하여 cluster autoscaler를 구성할 수 있다.

 예제:
@@ -144,17 +144,17 @@ gcloud container clusters update mytestcluster --enable-autoscaling --min-nodes=

 **Cluster autoscaler는 노드가 수작업으로 변경(예. kubectl을 통해 레이블을 추가)되는 경우를 예상하지 않는데, 동일한 인스턴스 그룹 내의 신규 노드들에 이 속성들이 전파되지 않을 것이기 때문이다.**

-cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은 
-autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) 
+cluster autoscaler가 클러스터 스케일 여부와 언제 어떻게 클러스터 스케일하는지에 대한 상세 사항은
+autoscaler 프로젝트의 [FAQ](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
 문서를 참조하기를 바란다.

 ## 노드 유지보수

-(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면, 
-Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면 
-(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.) 
-노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는 
-레플리카 셋 (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이 
+(커널 업그레이드, libc 업그레이드, 하드웨어 수리 등으로) 한 노드를 리부트해야하는데 다운타임이 짧다면,
+Kubelet이 재시작할 때 해당 노드에 스케줄된 파드들을 재시작하려고 할 것이다. 만약 리부트가 길게 걸린다면
+(컨트롤러 관리자의 `--pod-eviction-timeout`으로 제어되는 기본 시간은 5분이다.)
+노드 컨트롤러는 사용불가한 노드에 묶여져 있는 파드들을 종료 시킬 것이다. 만약 상응하는
+레플리카셋(ReplicaSet) (또는 레플리케이션 컨트롤러)가 존재한다면, 해당 파드의 신규 복제본을 다른 노드에서 기동시킬 것이다. 따라서, 모든 파드들이
 복제된 상황에서 모든 노드들이 동시에 다운되지 않는다고 가정했을 때, 별다른 조작없이 업데이트를 진행할 수 있다.

 만약 업그레이드 과정을 상세하게 통제하기를 원한다면, 다음 워크플로우를 사용할 수 있다.
@@ -167,9 +167,9 @@ kubectl drain $NODENAME

 이렇게하면 파드가 종료되는 동안 신규 파드들이 해당 노드에 스케줄되는 것을 방지한다.

-레플리카 셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.
+레플리카셋의 파드들은 신규 노드에 스케줄되는 신규 파드로 교체될 것이다. 추가적으로 해당 파드가 한 서비스의 일부라면, 클라이언트들은 자동으로 신규 파드로 재전송될 것이다.

-레플리카 셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.
+레플리카셋이 아닌 파드들은 직접 해당 파드의 새로운 복제본을 올려야 하며, 해당 파드가 한 서비스의 일부가 아니라면 클라이언트들을 신규 복제본으로 재전송해야 한다.

 해당 노드에 유지보수 작업을 수행한다.

@@ -179,8 +179,8 @@ kubectl drain $NODENAME
 kubectl uncordon $NODENAME
 ```

-해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가 
-자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면; 
+해당 노드의 VM 인스턴스를 삭제하고 신규로 생성했다면, 신규로 스케줄 가능한 노드 리소스가
+자동으로 생성될 것이다.(당신이 노드 디스커버리를 지원하는 클라우드 제공자를 사용한다면;
 이는 현재 Google Compute Engine만 지원되며 Google Compute Engine 상에서 kube-register를 사용하는 CoreOS를 포함하지는 않는다.) 상세 내용은 [노드](/ko/docs/concepts/architecture/nodes)를 참조하라.

 ## 고급 주제들
@@ -199,15 +199,15 @@ kubectl uncordon $NODENAME

 ### 클러스터에서 API 버전을 ON/OFF 하기

-특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를 
-전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다. 
-예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다. 
+특정 API 버전들은 API 서버가 올라오는 동안 `--runtime-config=api/<version>` 플래그를 전달하여 ON/OFF 시킬 수 있다. 예를 들어, v1 API를 OFF 시키려면, `--runtime-config=api/v1=false`를
+전달한다. runtime-config는 모든 API들과 레거시 API들을 각각 제어하는 api/all과 api/legacy 2가지 특수 키도 지원한다.
+예를 들어, v1을 제외한 모든 API 버전들을 OFF하려면 `--runtime-config=api/all=false,api/v1=true`를 전달한다.
 이 플래그들을 위해 레거시 API들은 명확하게 사용중단된 API들이다.(예. `v1beta3`)

 ### 클러스터에서 스토리지 API 버전을 변경

 클러스터 내에서 활성화된 쿠버네티스 리소스들의 클러스터의 내부 표현을 위해 디스크에 저장된 객체들은 특정 버전의 API를 사용하여 작성된다.
-지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이 
+지원되는 API가 변경될 때, 이 객체들은 새로운 API로 재작성되어야 할 수도 있다. 이것이 실패하면 결과적으로 리소스들이
 쿠버네티스 API 서버에서 더 이상 해독되거나 사용할 수 없게 될 것이다.

 ### 구성 파일을 신규 API 버전으로 변경
@@ -219,5 +219,3 @@ kubectl convert -f pod.yaml --output-version v1
 ```

 옵션에 대한 상세 정보는 [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) 커맨드의 사용법을 참조하기를 바란다.
-
-
@@ -0,0 +1,206 @@
+---
+title: 노드에 대한 확장 리소스 알리기
+content_type: task
+---
+
+
+<!-- overview -->
+
+이 페이지는 노드의 확장 리소스를 지정하는 방법을 보여준다.
+확장 리소스를 통해 클러스터 관리자는 쿠버네티스에게
+알려지지 않은 노드-레벨 리소스를 알릴 수 있다.
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+<!-- steps -->
+
+## 노드의 이름을 확인한다
+
+```shell
+kubectl get nodes
+```
+
+이 연습에 사용할 노드 중 하나를 선택한다.
+
+## 노드 중 하나에 새로운 확장 리소스를 알린다
+
+노드에서 새로운 확장 리소스를 알리려면, 쿠버네티스 API 서버에
+HTTP PATCH 요청을 보낸다. 예를 들어, 노드 중 하나에 4개의 동글(dongle)이 있다고
+가정한다. 다음은 노드에 4개의 동글 리소스를 알리는 PATCH 요청의
+예이다.
+
+```shell
+PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
+Accept: application/json
+Content-Type: application/json-patch+json
+Host: k8s-master:8080
+
+[
+  {
+    "op": "add",
+    "path": "/status/capacity/example.com~1dongle",
+    "value": "4"
+  }
+]
+```
+
+참고로 쿠버네티스는 동글이 무엇인지 또는 동글이 무엇을 위한 것인지 알 필요가 없다.
+위의 PATCH 요청은 노드에 동글이라고 하는 네 가지 항목이 있음을
+쿠버네티스에 알려준다.
+
+쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다.
+
+```shell
+kubectl proxy
+```
+
+다른 명령 창에서 HTTP PATCH 요청을 보낸다.
+`<your-node-name>` 을 노드의 이름으로 바꾼다.
+
+```shell
+curl --header "Content-Type: application/json-patch+json" \
+--request PATCH \
+--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
+http://localhost:8001/api/v1/nodes/<your-node-name>/status
+```
+
+{{< note >}}
+이전 요청에서 `~1` 은 패치 경로의 / 문자에 대한
+인코딩이다. JSON-Patch의 작업 경로값은 JSON-Pointer로
+해석된다. 자세한 내용은 [IETF RFC 6901](https://tools.ietf.org/html/rfc6901)의
+섹션 3을 참고한다.
+{{< /note >}}
+
+출력은 노드가 4개의 동글 용량을 가졌음을 나타낸다.
+
+```
+"capacity": {
+  "cpu": "2",
+  "memory": "2049008Ki",
+  "example.com/dongle": "4",
+```
+
+노드의 정보를 확인한다.
+
+```
+kubectl describe node <your-node-name>
+```
+
+다시 한 번, 출력에 동글 리소스가 표시된다.
+
+```yaml
+Capacity:
+ cpu:  2
+ memory:  2049008Ki
+ example.com/dongle:  4
+```
+
+이제, 애플리케이션 개발자는 특정 개수의 동글을 요청하는 파드를
+만들 수 있다. [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)를
+참고한다.
+
+## 토론
+
+확장 리소스는 메모리 및 CPU 리소스와 비슷하다. 예를 들어,
+노드에서 실행 중인 모든 컴포넌트가 공유할 특정 양의 메모리와 CPU가
+노드에 있는 것처럼, 노드에서 실행 중인 모든 컴포넌트가
+특정 동글을 공유할 수 있다. 또한 애플리케이션 개발자가
+특정 양의 메모리와 CPU를 요청하는 파드를 생성할 수 있는 것처럼, 특정
+동글을 요청하는 파드를 생성할 수 있다.
+
+확장 리소스는 쿠버네티스에게 불투명하다. 쿠버네티스는 그것들이
+무엇인지 전혀 모른다. 쿠버네티스는 노드에 특정 개수의 노드만
+있다는 것을 알고 있다. 확장 리소스는 정수로 알려야
+한다. 예를 들어, 노드는 4.5개의 동글이 아닌, 4개의 동글을 알릴 수 있다.
+
+### 스토리지 예제
+
+노드에 800GiB의 특별한 종류의 디스크 스토리지가 있다고 가정한다.
+example.com/special-storage와 같은 특별한 스토리지의 이름을 생성할 수 있다.
+그런 다음 특정 크기, 100GiB의 청크로 알릴 수 있다. 이 경우,
+노드에는 example.com/special-storage 유형의 8가지 리소스가 있다고
+알린다.
+
+```yaml
+Capacity:
+ ...
+ example.com/special-storage: 8
+```
+
+이 특별한 스토리지에 대한 임의 요청을 허용하려면,
+1바이트 크기의 청크로 특별한 스토리지를 알릴 수 있다. 이 경우, example.com/special-storage 유형의
+800Gi 리소스를 알린다.
+
+```yaml
+Capacity:
+ ...
+ example.com/special-storage:  800Gi
+```
+
+그런 다음 컨테이너는 최대 800Gi의 임의 바이트 수의 특별한 스토리지를 요청할 수 있다.
+
+## 정리
+
+다음은 노드에서 동글 알림을 제거하는 PATCH 요청이다.
+
+```
+PATCH /api/v1/nodes/<your-node-name>/status HTTP/1.1
+Accept: application/json
+Content-Type: application/json-patch+json
+Host: k8s-master:8080
+
+[
+  {
+    "op": "remove",
+    "path": "/status/capacity/example.com~1dongle",
+  }
+]
+```
+
+쿠버네티스 API 서버에 요청을 쉽게 보낼 수 있도록 프록시를 시작한다.
+
+```shell
+kubectl proxy
+```
+
+다른 명령 창에서 HTTP PATCH 요청을 보낸다.
+`<your-node-name>`을 노드의 이름으로 바꾼다.
+
+```shell
+curl --header "Content-Type: application/json-patch+json" \
+--request PATCH \
+--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
+http://localhost:8001/api/v1/nodes/<your-node-name>/status
+```
+
+동글 알림이 제거되었는지 확인한다.
+
+```
+kubectl describe node <your-node-name> | grep dongle
+```
+
+(출력이 보이지 않아야 함)
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+### 애플리케이션 개발자를 위한 문서
+
+* [컨테이너에 확장 리소스 할당하기](/docs/tasks/configure-pod-container/extended-resource/)
+
+### 클러스터 관리자를 위한 문서
+
+* [네임스페이스에 대한 메모리의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)
+* [네임스페이스에 대한 CPU의 최소 및 최대 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)
@@ -1,5 +1,5 @@
 ---
-title: Windows 노드 추가
+title: 윈도우 노드 추가
 min-kubernetes-server-version: 1.17
 content_type: tutorial
 weight: 30
@@ -9,7 +9,7 @@ weight: 30

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

-쿠버네티스를 사용하여 리눅스와 Windows 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 Windows에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 Windows 노드를 클러스터에 등록하는 방법을 보여준다.
+쿠버네티스를 사용하여 리눅스와 윈도우 노드를 혼합하여 실행할 수 있으므로, 리눅스에서 실행되는 파드와 윈도우에서 실행되는 파드를 혼합할 수 있다. 이 페이지는 윈도우 노드를 클러스터에 등록하는 방법을 보여준다.



@@ -17,8 +17,8 @@ weight: 30
 ## {{% heading "prerequisites" %}}
 {{< version-check >}}

-* Windows 컨테이너를 호스팅하는 Windows 노드를 구성하려면
-[Windows Server 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
+* 윈도우 컨테이너를 호스팅하는 윈도우 노드를 구성하려면
+[윈도우 서버 2019 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) 이상이 필요하다.
 VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://support.microsoft.com/help/4489899)도 설치되어 있어야 한다.

 * 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 kubeadm 클러스터([kubeadm을 사용하여 단일 컨트롤 플레인 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 참고)가 필요하다.
@@ -29,15 +29,15 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
 ## {{% heading "objectives" %}}


-* 클러스터에 Windows 노드 등록
-* 리눅스 및 Windows의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성
+* 클러스터에 윈도우 노드 등록
+* 리눅스 및 윈도우의 파드와 서비스가 서로 통신할 수 있도록 네트워킹 구성




 <!-- lessoncontent -->

-## 시작하기: 클러스터에 Windows 노드 추가
+## 시작하기: 클러스터에 윈도우 노드 추가

 ### 네트워킹 구성

@@ -75,7 +75,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
        }
    ```

-    {{< note >}}리눅스의 플란넬이 Windows의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
+    {{< note >}}리눅스의 플란넬이 윈도우의 플란넬과 상호 운용되도록 하려면 VNI를 4096으로, 포트를 4789로 설정해야 한다. 이 필드들에 대한 설명은 [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)를
    참고한다.{{< /note >}}

    {{< note >}}L2Bridge/Host-gateway 모드를 대신 사용하려면 `Type` 의 값을 `"host-gw"` 로 변경하고 `VNI` 와 `Port` 를 생략한다.{{< /note >}}
@@ -102,9 +102,9 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
    kube-system   kube-flannel-ds-54954                     1/1          Running   0          1m
    ```

-1. Windows 플란넬 및 kube-proxy 데몬셋 추가
+1. 윈도우 플란넬 및 kube-proxy 데몬셋 추가

-    이제 Windows 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
+    이제 윈도우 호환 버전의 플란넬과 kube-proxy를 추가할 수 있다. 호환 가능한
    kube-proxy 버전을 얻으려면, 이미지의 태그를
    대체해야 한다. 다음의 예시는 쿠버네티스 {{< param "fullversion" >}}의 사용법을 보여주지만,
    사용자의 배포에 맞게 버전을 조정해야 한다.
@@ -118,7 +118,7 @@ VXLAN/오버레이 네트워킹을 사용하는 경우 [KB4489899](https://suppo
    {{< /note >}}

    {{< note >}}
-Windows 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.
+윈도우 노드에서 이더넷이 아닌 다른 인터페이스(예: "Ethernet0 2")를 사용하는 경우, flannel-host-gw.yml이나 flannel-overlay.yml 파일에서 다음 라인을 수정한다.

 ```powershell
 wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"
@@ -134,14 +134,14 @@ curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/dow



-### Windows 워커 노드 조인(joining)
+### 윈도우 워커 노드 조인(joining)
 {{< note >}}
 `Containers` 기능을 설치하고 도커를 설치해야 한다.
-[Windows Server에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
+[윈도우 서버에 Docker Engine - Enterprise 설치](https://docs.docker.com/ee/docker-ee/windows/docker-ee/#install-docker-engine---enterprise)에서 설치에 대한 내용을 참고할 수 있다.
 {{< /note >}}

 {{< note >}}
-Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의
+윈도우 섹션의 모든 코드 스니펫(snippet)은 윈도우 워커 노드의
 높은 권한(관리자)이 있는 PowerShell 환경에서 실행해야 한다.
 {{< /note >}}

@@ -160,7 +160,7 @@ Windows 섹션의 모든 코드 스니펫(snippet)은 Windows 워커 노드의


 #### 설치 확인
-이제 다음을 실행하여 클러스터에서 Windows 노드를 볼 수 있다.
+이제 다음을 실행하여 클러스터에서 윈도우 노드를 볼 수 있다.

 ```bash
 kubectl get nodes -o wide
@@ -180,6 +180,6 @@ flannel 파드가 실행되면, 노드는 `Ready` 상태가 되고 워크로드
 ## {{% heading "whatsnext" %}}


- [Windows kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)
+- [윈도우 kubeadm 노드 업그레이드](/ko/docs/tasks/administer-cluster/kubeadm/upgrading-windows-nodes)


@@ -242,7 +242,7 @@ min-kubernetes-server-version: 1.18
 -  CNI 제공자 플러그인을 수동으로 업그레이드한다.

    CNI(컨테이너 네트워크 인터페이스) 제공자는 자체 업그레이드 지침을 따를 수 있다.
-    [애드온](/docs/concepts/cluster-administration/addons/) 페이지에서
+    [애드온](/ko/docs/concepts/cluster-administration/addons/) 페이지에서
    사용하는 CNI 제공자를 찾고 추가 업그레이드 단계가 필요한지 여부를 확인한다.

    CNI 제공자가 데몬셋(DaemonSet)으로 실행되는 경우 추가 컨트롤 플레인 노드에는 이 단계가 필요하지 않다.
@@ -1,5 +1,5 @@
 ---
-title: Windows 노드 업그레이드
+title: 윈도우 노드 업그레이드
 min-kubernetes-server-version: 1.17
 content_type: task
 weight: 40
@@ -9,7 +9,7 @@ weight: 40

 {{< feature-state for_k8s_version="v1.18" state="beta" >}}

-이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) Windows 노드를 업그레이드하는 방법을 설명한다.
+이 페이지는 [kubeadm으로 생성된](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) 윈도우 노드를 업그레이드하는 방법을 설명한다.



@@ -18,7 +18,7 @@ weight: 40

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 * [남은 kubeadm 클러스터를 업그레이드하는 프로세스](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade)에
-익숙해져야 한다. Windows 노드를
+익숙해져야 한다. 윈도우 노드를
 업그레이드하기 전에 컨트롤 플레인 노드를 업그레이드해야 한다.


@@ -30,7 +30,7 @@ weight: 40

 ### kubeadm 업그레이드

-1.  Windows 노드에서, kubeadm을 업그레이드한다.
+1.  윈도우 노드에서, kubeadm을 업그레이드한다.

    ```powershell
    # replace {{< param "fullversion" >}} with your desired version
@@ -56,7 +56,7 @@ weight: 40

 ### kubelet 구성 업그레이드

-1.  Windows 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다.
+1.  윈도우 노드에서, 다음의 명령을 호출하여 새 kubelet 구성을 동기화한다.

    ```powershell
    kubeadm upgrade node
@@ -64,7 +64,7 @@ weight: 40

 ### kubelet 업그레이드

-1.  Windows 노드에서, kubelet을 업그레이드하고 다시 시작한다.
+1.  윈도우 노드에서, kubelet을 업그레이드하고 다시 시작한다.

    ```powershell
    stop-service kubelet
@@ -265,7 +265,4 @@ kubectl delete namespace constraints-cpu-example

 * [컨테이너와 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -188,6 +188,4 @@ kubectl delete namespace default-cpu-example

 * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -265,6 +265,4 @@ kubectl delete namespace constraints-mem-example

 * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -196,8 +196,4 @@ kubectl delete namespace default-mem-example

 * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -172,6 +172,4 @@ kubectl delete namespace quota-mem-cpu-example

 * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -133,11 +133,4 @@ kubectl delete namespace quota-pod-example

 * [컨테이너 및 파드 CPU 리소스 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/)
-
-
-
-
-
-
-
+* [파드에 대한 서비스 품질(QoS) 구성](/ko/docs/tasks/configure-pod-container/quality-service-pod/)
@@ -48,7 +48,7 @@ Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함
 간단한 ``올인원`` YAML 파일로 배포할 수 있다.

 ```shell
-kubectl create -f  https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
+kubectl create -f  https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
 ```
 ```
 configmap/cilium-config created
@@ -39,7 +39,3 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman


 로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
-
-
-
-
@@ -1,4 +1,5 @@
 ---
 title: "파드와 컨테이너 설정"
+description: 파드와 컨테이너에 대한 공통 구성 태스크들을 수행한다.
 weight: 20
 ---
@@ -25,7 +25,7 @@ weight: 10
 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면
 다음 단계를 건너뛸 수 있다.

-Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 
+Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를
 활성화할 수 있다.

 ```shell
@@ -53,7 +53,7 @@ v1beta1.metrics.k8s.io

 ## 네임스페이스 생성

-이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 
+이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해
 네임스페이스를 생성한다.

 ```shell
@@ -113,7 +113,7 @@ kubectl top pod memory-demo --namespace=mem-example
 ```

 출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다.
-이는 파드의 100 MiB 요청 보다 많으나 
+이는 파드의 100 MiB 요청 보다 많으나
 파드의 200 MiB 상한보다는 적다.

 ```
@@ -245,7 +245,7 @@ kubectl delete pod memory-demo-2 --namespace=mem-example

 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다.
 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는
-컨테이너를 갖는 
+컨테이너를 갖는
 파드의 구성 파일이다.

 {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}}
@@ -340,25 +340,20 @@ kubectl delete namespace mem-example

 * [CPU 리소스를 컨테이너와 파드에 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)

-* [파드에 서비스 품질 설정](/docs/tasks/configure-pod-container/quality-service-pod/)
+* [파드에 서비스 품질 설정](/ko/docs/tasks/configure-pod-container/quality-service-pod/)

 ### 클러스터 관리자들을 위한

-* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/docs/tasks/administer-cluster/memory-default-namespace/)
+* [네임스페이스에 기본 메모리 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)

-* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/docs/tasks/administer-cluster/cpu-default-namespace/)
-
-* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/docs/tasks/administer-cluster/memory-constraint-namespace/)
-
-* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
-
-* [네임스페이스에 메모리 및 CPU 할당량 구성](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
-
-* [네임스페이스에 파드 할당량 구성](/docs/tasks/administer-cluster/quota-pod-namespace/)
-
-* [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/)
+* [네임스페이스에 기본 CPU 요청량 및 상한을 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)

+* [네임스페이스에 최소 및 최대 메모리 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)

+* [네임스페이스에 최소 및 최대 CPU 제약 조건 구성](/ko/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)

+* [네임스페이스에 메모리 및 CPU 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)

+* [네임스페이스에 파드 할당량 구성](/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/)

+* [API 오브젝트에 할당량 구성](/docs/tasks/administer-cluster/quota-api-object/)
@@ -117,6 +117,5 @@ weight: 120

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

-[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)에
+[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)에
 대해 더 알아보기.
-
@@ -89,7 +89,3 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.
 * [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers/)에 대해 배우기.
 * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기.
 * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기.
-
-
-
-
@@ -9,10 +9,10 @@ content_template: task
 <!-- overview -->


-*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} 
-없이 특정 노드에 있는 kubelet 데몬에 의해 
+*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
+없이 특정 노드에 있는 kubelet 데몬에 의해
 직접 관리된다.
-컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, 
+컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리,
 kubelet 이 각각의 스태틱 파드를 감시한다.
 (만약 충돌이 날 경우 다시 구동한다.)

@@ -20,13 +20,13 @@ kubelet 이 각각의 스태틱 파드를 감시한다.

 Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를
 생성하려고 자동으로 시도한다.
-즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, 
+즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
 API 서버에서 제어될 수는 없다.

 {{< note >}}
-만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 
+만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여
 모든 노드에서 파드를 구동하고 있다면,
-스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} 
+스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}}
 을 사용하는 것이 바람직하다.
 {{< /note >}}

@@ -37,7 +37,7 @@ API 서버에서 제어될 수는 없다.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, 
+이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며,
 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다.
 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다.

@@ -49,12 +49,12 @@ API 서버에서 제어될 수는 없다.

 ## 스태틱 파드 생성하기 {#static-pod-creation}

-[파일 시스템이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다.
+[파일 시스템이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다.

 ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files}

-매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
-Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.
+매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: <the directory>` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다.
+Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자.

 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다.

@@ -64,7 +64,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단
    ssh my-node1
    ```

-2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.  
+2. `/etc/kubelet.d` 와 같은 디렉터리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다.  

    ```shell
 	  # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다.
@@ -87,7 +87,7 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단
    EOF
    ```

-3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.
+3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다.

    ```
    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
@@ -103,10 +103,10 @@ Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단

 ### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http}

-Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으로 다운로드하여 
+Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으로 다운로드하여
 해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다.
-[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 
-유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 
+[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과
+유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에
 변경된 부분이 있을 경우, kubelet 은 이를 적용한다.

 이 방법을 사용하기 위하여 다음을 수행한다.
@@ -130,7 +130,7 @@ Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으
              protocol: TCP
    ```

-2. 선택한 노드에서 `--manifest-url=<manifest-url>` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. 
+2. 선택한 노드에서 `--manifest-url=<manifest-url>` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다.

    ```
    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
@@ -145,7 +145,7 @@ Kubelet은 `--manifest-url=<URL>` 의 인수로 지정된 파일을 주기적으

 ## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods}

-Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. 
+Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다.
 스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱
 파드가 이미 실행 중이어야 한다.

@@ -174,15 +174,15 @@ static-web-my-node1        1/1       Running   0          2m

 {{< note >}}
 Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다.
-[파드시큐리티폴리시(PodSecurityPolicy)](/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
+[파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/) 에 대해 보기.
 {{< /note >}}


-스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 
-미러 파드로 전파된다.  {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 
+스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은
+미러 파드로 전파된다.  {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을
 통하여 이러한 레이블을 사용할 수 있다.

-만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, 
+만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도,
 kubelet 은 스태틱 파드를 지우지 _않는다._

 ```shell
@@ -200,9 +200,9 @@ NAME                       READY     STATUS    RESTARTS   AGE
 static-web-my-node1        1/1       Running   0          12s
 ```

-kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 
+kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로
 중지할 수 있다.
-일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 
+일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는
 것을 볼 수 있다.

 ```shell
@@ -218,7 +218,7 @@ CONTAINER ID        IMAGE         COMMAND                CREATED       ...

 ## 스태틱 파드의 동적 추가 및 제거

-실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.
+실행 중인 kubelet 은 주기적으로, 설정된 디렉터리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉터리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다.

 ```shell
 # 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다.
@@ -227,7 +227,7 @@ CONTAINER ID        IMAGE         COMMAND                CREATED       ...
 mv /etc/kubelet.d/static-web.yaml /tmp
 sleep 20
 docker ps
-# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. 
+# 구동 중인 nginx 컨테이너가 없는 것을 확인한다.
 mv /tmp/static-web.yaml  /etc/kubelet.d/
 sleep 20
 docker ps
@@ -1,5 +1,6 @@
 ---
 title: "모니터링, 로깅, 그리고 디버깅"
+description: 모니터링 및 로깅을 설정하여 클러스터 문제를 해결하거나, 컨테이너화된 애플리케이션을 디버깅한다.
 weight: 80
 ---

@@ -5,15 +5,15 @@ content_type: task

 <!-- overview -->

-이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 
+이 페이지는 컨테이너 종료 메시지를 읽고 쓰는
 방법을 보여준다.

-종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를, 
+종료 메시지는 컨테이너가 치명적인 이벤트에 대한 정보를,
 대시보드나 모니터링 소프트웨어 도구와 같이
-쉽게 조회 및 표시할 수 있는 위치에 
+쉽게 조회 및 표시할 수 있는 위치에
 기록하는 방법을 제공한다.
-대부분의 경우에 종료 메시지에 넣는 정보는 
-일반 
+대부분의 경우에 종료 메시지에 넣는 정보는
+일반
 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다.


@@ -32,7 +32,7 @@ content_type: task
 ## 종료 메시지 읽기 및 쓰기

 이 예제에서는, 하나의 컨테이너를 실행하는 파드를 생성한다.
-하단의 설정 파일은 컨테이너가 시작될 때 수행하는 
+하단의 설정 파일은 컨테이너가 시작될 때 수행하는
 명령어를 지정한다.

 {{< codenew file="debug/termination.yaml" >}}
@@ -41,8 +41,8 @@ content_type: task

        kubectl apply -f https://k8s.io/examples/debug/termination.yaml

-	   YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 
-	   "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 
+	   YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에
+	   "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는
 	   것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를
 	   기록한 후에 종료된다.

@@ -70,25 +70,25 @@ content_type: task
                  Sleep expired
                ...

-1. 종료 메시지만을 포함하는 출력 결과를 보기 
+1. 종료 메시지만을 포함하는 출력 결과를 보기
 위해서는 Go 템플릿을 사용한다.

        kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}"

 ## 종료 메시지 사용자 정의하기

-쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된 
-종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은 
-`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써 
-쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. 
+쿠버네티스는 컨테이너의 `terminationMessagePath` 필드에 지정된
+종료 메시지 파일에서 종료 메시지를 검색하며, 이 필드의 기본값은
+`/dev/termination-log` 이다. 이 필드를 사용자 정의 함으로써
+쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다.
 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다.

 종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다.
-kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 
-12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. 
+kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는
+12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다.
 파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다.

-다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 
+다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록
 `/tmp/my-log` 파일에 종료 메시지를 기록한다.

 ```yaml
@@ -103,12 +103,12 @@ spec:
    terminationMessagePath: "/tmp/my-log"
 ```

-또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy` 
-필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며, 
-이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다. 
-`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로 
-설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우 
-쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 
+또한 사용자는 추가적인 사용자 정의를 위해 컨테이너의 `terminationMessagePolicy`
+필드를 설정할 수 있다. 이 필드의 기본 값은 `File` 이며,
+이는 오직 종료 메시지 파일에서만 종료 메시지가 조회되는 것을 의미한다.
+`terminationMessagePolicy` 필드의 값을 "`FallbackToLogsOnError` 으로
+설정함으로써, 종료 메시지 파일이 비어 있고 컨테이너가 오류와 함께 종료 되었을 경우
+쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다.
 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다.


@@ -118,9 +118,5 @@ spec:

 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
  에 있는 `terminationMessagePath` 에 대해 읽어보기.
-* [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
+* [로그 검색](/ko/docs/concepts/cluster-administration/logging/)에 대해 배워보기.
 * [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기.
-
-
-
-
@@ -5,10 +5,10 @@ content_type: concept

 <!-- overview -->

-컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 
-쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 
-`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, 
-Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. 
+컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
+쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
+`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
+Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.



@@ -17,9 +17,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을

 ## 메트릭 API

-메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인 
-리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 
-않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 
+메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
+리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
+않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
 가져오는 것과 같은 일을 할 수는 없다.

 이 API와 다른 API는 차이가 없다.
@@ -27,7 +27,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
 - 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다
 - 동일한 보안, 확장성 및 신뢰성 보장을 제공한다

-[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) 
+[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go)
 리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.

 {{< note >}}
@@ -38,7 +38,7 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을

 ### CPU

-CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
+CPU는 일정 기간 동안 [CPU 코어](/ko/docs/concepts/configuration/manage-resources-containers/#cpu의-의미)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.

 ### 메모리

@@ -47,15 +47,13 @@ CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/con
 ## 메트릭 서버

 [메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
-`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 
-디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 
+`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
+디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다.

 메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.

-메트릭 서버는 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 
+메트릭 서버는 [쿠버네티스 aggregator](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)를
 통해 메인 API 서버에 등록된다.

 [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
-
-
@@ -1,6 +1,6 @@
 ---
 title: 플러그인으로 kubectl 확장
-description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다.
+description: kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다.
 content_type: task
 ---

@@ -1,5 +1,5 @@
 ---
 title: "애플리케이션에 데이터 주입하기"
+description: 워크로드를 실행하는 파드에 대한 구성과 기타 데이터를 지정한다.
 weight: 30
-
---
+---
@@ -30,9 +30,9 @@ weight: 10
 파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고
 난 이후에는 변경될 수 없다.

-구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가 
-제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을 
-정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와 
+구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가
+제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을
+정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와
 함께 사용된다.

 {{< note >}}
@@ -103,7 +103,7 @@ args: ["$(MESSAGE)"]
 ## 셸 안에서 커맨드 실행하기

 일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가
-서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 
+서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서
 커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다.

 ```shell
@@ -122,18 +122,18 @@ args: ["-c", "while true; do echo hello; sleep 10;done"]

 기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다.

-* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에 
+* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에
 제공되는 기본 값들이 사용된다.

-* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면, 
-제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본 
+* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면,
+제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본
 Cmd 값은 덮어쓰여진다.

-* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint 
+* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint
 값이 정의한 `args` 값들과 함께 실행된다.

-* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본 
-EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께 
+* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본
+EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께
 실행된다.

 여기 몇 가지 예시들이 있다.
@@ -154,7 +154,3 @@ EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값
 * [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
 * [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
 * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.
-
-
-
-
@@ -1,4 +1,5 @@
 ---
 title: "클러스터 데몬 관리"
+description: 롤링 업데이트 수행과 같은 데몬셋 관리를 위한 일반적인 작업을 수행한다.
 weight: 130
 ---
@@ -2,27 +2,20 @@
 title: 데몬셋(DaemonSet)에서 롤백 수행
 content_type: task
 weight: 20
+min-kubernetes-server-version: 1.7
 ---

-
-
 <!-- overview -->

-이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다.
-
-
+이 페이지는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}에서 롤백을 수행하는 방법을 보여준다.


 ## {{% heading "prerequisites" %}}

+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

-* 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은
-  쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다.
-* [데몬셋에서 롤링 업데이트를
-  수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다.
-
-
-
+[데몬셋에서 롤링 업데이트를
+  수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 이미 알고 있어야 한다.

 <!-- steps -->

@@ -40,7 +33,7 @@ kubectl rollout history daemonset <daemonset-name>

 이 명령은 데몬셋 리비전 목록을 반환한다.

-```shell
+```
 daemonsets "<daemonset-name>"
 REVISION        CHANGE-CAUSE
 1               ...
@@ -60,17 +53,17 @@ kubectl rollout history daemonset <daemonset-name> --revision=1

 이 명령은 해당 리비전의 세부 사항을 반환한다.

-```shell
+```
 daemonsets "<daemonset-name>" with revision #1
 Pod Template:
 Labels:       foo=bar
 Containers:
 app:
- Image:       ...
- Port:        ...
- Environment: ...
- Mounts:      ...
-Volumes:       ...
+ Image:        ...
+ Port:         ...
+ Environment:  ...
+ Mounts:       ...
+Volumes:      ...
 ```

 ### 2단계: 특정 리비전으로 롤백
@@ -82,16 +75,19 @@ kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>

 성공하면, 명령은 다음을 반환한다.

-```shell
+```
 daemonset "<daemonset-name>" rolled back
 ```

-`--to-revision` 플래그를 지정하지 않은 경우, 마지막 리비전이 선택된다.
+{{< note >}}
+`--to-revision` 플래그를 지정하지 않은 경우, kubectl은 가장 최신의 리비전을 선택한다.
+{{< /note >}}

 ### 3단계: 데몬셋 롤백 진행 상황 확인

 `kubectl rollout undo daemonset` 은 서버에 데몬셋 롤백을 시작하도록
-지시한다. 실제 롤백은 서버 측에서 비동기적으로 수행된다.
+지시한다. 실제 롤백은 클러스터 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}
+내에서 비동기적으로 수행된다.

 롤백 진행 상황을 보려면 다음의 명령을 수행한다.

@@ -101,21 +97,17 @@ kubectl rollout status ds/<daemonset-name>

 롤백이 완료되면, 출력 결과는 다음과 비슷하다.

-```shell
+```
 daemonset "<daemonset-name>" successfully rolled out
 ```


-
-
 <!-- discussion -->

 ## 데몬셋 리비전의 이해

 이전 `kubectl rollout history` 단계에서, 데몬셋 리비전 목록을
-얻었다. 각 리비전은 `ControllerRevision` 이라는 리소스에 저장된다.
-`ControllerRevision` 은 쿠버네티스 릴리스 1.7 이상에서만 사용할 수 있는
-리소스이다.
+얻었다. 각 리비전은 ControllerRevision이라는 리소스에 저장된다.

 각 리비전에 저장된 내용을 보려면, 데몬셋 리비전 원시 리소스를
 찾는다.
@@ -124,30 +116,29 @@ daemonset "<daemonset-name>" successfully rolled out
 kubectl get controllerrevision -l <daemonset-selector-key>=<daemonset-selector-value>
 ```

-이 명령은 `ControllerRevisions` 의 목록을 반환한다.
+이 명령은 ControllerRevision의 목록을 반환한다.

-```shell
+```
 NAME                               CONTROLLER                     REVISION   AGE
 <daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     1          1h
 <daemonset-name>-<revision-hash>   DaemonSet/<daemonset-name>     2          1h
 ```

-각 `ControllerRevision` 은 데몬셋 리비전의 어노테이션과 템플릿을
-저장한다. ControllerRevision 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+각 ControllerRevision은 데몬셋 리비전의 어노테이션과 템플릿을
+저장한다.

-`kubectl rollout undo` 는 특정 `ControllerRevision` 을 가져와 데몬셋
-템플릿을 `ControllerRevision` 에 저장된 템플릿으로 바꾼다.
+`kubectl rollout undo` 는 특정 ControllerRevision을 가져와 데몬셋
+템플릿을 ControllerRevision에 저장된 템플릿으로 바꾼다.
 `kubectl rollout undo` 는 `kubectl edit` 또는 `kubectl apply` 와 같은 다른 명령을 통해
 데몬셋 템플릿을 이전 리비전으로 업데이트하는 것과
 같다.

 {{< note >}}
 데몬셋 리비전은 롤 포워드만 한다. 즉, 롤백이
-완료된 후, 롤백될 `ControllerRevision` 의
+완료된 후, 롤백될 ControllerRevision의
 리비전 번호(`.revision` 필드)가 증가한다. 예를 들어,
 시스템에 리비전 1과 2가 있고, 리비전 2에서 리비전 1으로 롤백하면,
-`ControllerRevision` 은 `.revision: 1` 에서 `.revision: 3` 이 된다.
+ControllerRevision은 `.revision: 1` 에서 `.revision: 3` 이 된다.
 {{< /note >}}

 ## 문제 해결
@@ -157,4 +148,3 @@ NAME                               CONTROLLER                     REVISION   AGE



-
@@ -1,6 +1,7 @@
 ---
 content_type: concept
 title: GPU 스케줄링
+description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성하고 스케줄링한다.
 ---


@@ -140,7 +141,7 @@ Google은 GKE에서 NVIDIA GPU 사용에 대한 자체 [설명서](https://cloud

 만약 클러스터의 노드들이 서로 다른 타입의 GPU를 가지고 있다면, 사용자는
 파드를 적합한 노드에 스케줄 하기 위해서
-[노드 레이블과 노드 셀렉터](/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다.
+[노드 레이블과 노드 셀렉터](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 사용할 수 있다.

 예를 들면,

@@ -215,5 +216,3 @@ spec:

 이것은 파드가 사용자가 지정한 GPU 타입을 가진 노드에 스케줄 되도록
 만든다.
-
-
@@ -1,16 +1,14 @@
 ---
 title: HugePages 관리
 content_type: task
+description: 클러스터에서 huge page를 스케줄할 수 있는 리소스로 구성하고 관리한다.
 ---

 <!-- overview -->
 {{< feature-state state="stable" >}}

-쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된
-huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가
-huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다.
-
-
+쿠버네티스는 파드의 애플리케이션에 미리 할당된
+huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법에 대해 설명한다.

 ## {{% heading "prerequisites" %}}

@@ -118,11 +116,3 @@ glossary_tooltip text="kube-apiserver"
 term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`)의
 `HugePageStorageMediumSize` [기능
 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 활성화할 수 있다.
-
-## 향후 버전
-
- NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다.
- 리밋레인지(LimitRange)를 지원할 예정이다.
-
-
-
@@ -1,4 +1,5 @@
 ---
 title: "쿠버네티스 오브젝트 관리"
+description: 쿠버네티스 API와 상호 작용하기 위한 선언적이고 명령적인 패러다임
 weight: 25
 ---
@@ -16,7 +16,7 @@ weight: 10
 ## {{% heading "prerequisites" %}}


-[`kubectl`](/docs/tasks/tools/install-kubectl/)를 설치한다.
+[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)를 설치한다.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

@@ -1007,5 +1007,3 @@ template:
 * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/)
 * [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
-
@@ -12,7 +12,7 @@ weight: 30

 ## {{% heading "prerequisites" %}}

-[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
+[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

@@ -169,5 +169,3 @@ kubectl create --edit -f /tmp/srv.yaml
 * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
-
@@ -13,7 +13,7 @@ weight: 40
 ## {{% heading "prerequisites" %}}


-[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
+[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

@@ -152,5 +152,3 @@ template:
 * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/)
 * [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
 * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
-
@@ -6,12 +6,12 @@ weight: 20

 <!-- overview -->

-[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 
-[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 
+[Kustomize](https://github.com/kubernetes-sigs/kustomize)는
+[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을
 통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다.

-1.14 이후로, kubectl도 
-kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. 
+1.14 이후로, kubectl도
+kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다.
 kustomization 파일을 포함하는 디렉터리 내의 리소스를 보려면 다음 명령어를 실행한다.

 ```shell
@@ -29,7 +29,7 @@ kubectl apply -k <kustomization_directory>
 ## {{% heading "prerequisites" %}}


-[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다.
+[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)을 설치한다.

 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

@@ -47,7 +47,7 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다.

 ### 리소스 생성

-컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 
+컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다.
 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다.
 Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다.

@@ -207,7 +207,7 @@ metadata:

 ### 교차 편집 필드 설정

-프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. 
+프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다.
 교차 편집 필드를 설정하는 몇 가지 사용 사례는 다음과 같다.

 * 모든 리소스에 동일한 네임스페이스를 설정
@@ -283,13 +283,13 @@ spec:

 ### 리소스 구성과 사용자 정의

-프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 
-관리하는 것은 일반적이다. 
+프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서
+관리하는 것은 일반적이다.
 Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다.

 #### 구성

-Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. 
+Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다.
 다음 예제는 디플로이먼트와 서비스로 구성된 NGINX 애플리케이션이다.

 ```shell
@@ -344,7 +344,7 @@ EOF

 #### 사용자 정의

-패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는 
+패치는 리소스에 다른 사용자 정의를 적용하는 데 사용할 수 있다. Kustomize는
 `patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다.

 ```shell
@@ -432,10 +432,10 @@ spec:
        - containerPort: 80
 ```

-모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, 
-Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. 
-Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 
-`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 
+모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해,
+Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다.
+Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이
+`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해
 디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다.

 ```shell
@@ -508,7 +508,7 @@ spec:
        - containerPort: 80
 ```

-패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 
+패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는
 기능도 제공한다. 예를 들어 `kustomization.yaml`의 `images` 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다.

 ```shell
@@ -566,9 +566,9 @@ spec:
        - containerPort: 80
 ```

-가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, 
-디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. 
-`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. 
+가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어,
+디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자.
+`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다.
 커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다.

 ```shell
@@ -655,11 +655,11 @@ spec:

 ## Base와 Overlay

-Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 
-사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 
-될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 
-다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. 
-한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, 
+Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는
+사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가
+될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로
+다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다.
+한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며,
 이들의 위에 사용자 정의도 가질 수 있다.

 다음은 base에 대한 예이다.
@@ -711,7 +711,7 @@ resources:
 EOF
 ```

-이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 
+이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을
 서로 다른 overlay에 추가할 수 있다. 다음 예제는 동일한 base를 사용하는 두 overlay들이다.

 ```shell
@@ -732,7 +732,7 @@ EOF

 ## Kustomize를 이용하여 오브젝트를 적용/확인/삭제하는 방법

-`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. 
+`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다.
 `-k`는 다음과 같이 kustomization 디렉터리를 가리키고 있어야 한다는 것을 주의한다.

 ```shell
@@ -835,5 +835,3 @@ deployment.apps "dev-my-nginx" deleted
 * [Kubectl Book](https://kubectl.docs.kubernetes.io)
 * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/)
 * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-
-
@@ -1,4 +1,5 @@
 ---
-title: "네트워크"
+title: "네트워킹"
+description: 클러스터에 대한 네트워킹 설정 방법에 대해 배운다.
 weight: 160
 ---
@@ -12,7 +12,7 @@ content_type: task


 * 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
-* 이중 스택을 지원하는 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예. Kubenet 또는 Calico)
+* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)  (예. Kubenet 또는 Calico)
 * IPVS 모드로 구동되는 Kube-proxy
 * [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터

@@ -155,5 +155,3 @@ my-service   ClusterIP   fe80:20d::d06b   <none>        80/TCP    9s
 NAME         TYPE        CLUSTER-IP       EXTERNAL-IP                     PORT(S)        AGE
 my-service   ClusterIP   fe80:20d::d06b   2001:db8:f100:4002::9d37:c0d7   80:31868/TCP   30s
 ```
-
-
@@ -1,4 +1,5 @@
 ---
 title: "애플리케이션 실행"
+description: 스테이트리스와 스테이트풀 애플리케이션 모두를 실행하고 관리한다.
 weight: 40
 ---
@@ -52,7 +52,7 @@ kubectl delete pods -l app=myapp

 ### 퍼시스턴트볼륨(PersistentVolume)

-스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#termination-of-pods)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.
+스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#파드의-종료)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다.

 {{< note >}}
 PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.
@@ -82,7 +82,3 @@ kubectl delete pvc -l app=myapp


 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기.
-
-
-
-
@@ -8,7 +8,7 @@ weight: 100

 Horizontal Pod Autoscaler는
 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여
-레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.
+레플리케이션 컨트롤러, 디플로이먼트, 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다.

 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다.

@@ -179,9 +179,9 @@ CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
 새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.

 HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다.
+[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
 API 오브젝트에 대한 자세한 내용은
-[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다.
+[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.

 ## kubectl에서 Horizontal Pod Autoscaler 지원

@@ -199,9 +199,9 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`

 ## 롤링 업데이트 중 오토스케일링

-현재 쿠버네티스에서는 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
+현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
 Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
-디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다.
+디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.

 Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
 즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
@@ -229,7 +229,7 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
 이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
 한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
 워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
-너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수
+너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
 있다.
 {{< /note >}}

@@ -439,5 +439,3 @@ behavior:
 * 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
 * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
 * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.
-
-
@@ -1,5 +1,6 @@
 ---
 title: "TLS"
+description: TLS(Transport Layer Security)를 사용하여 클러스터 내 트래픽을 보호하는 방법을 이해한다.
 weight: 100
 ---

@@ -1,5 +1,6 @@
 ---
 title: "도구 설치"
+description: 컴퓨터에서 쿠버네티스 도구를 설정한다.
 weight: 10
 ---

@@ -111,34 +111,34 @@ kubectl version --client

 1. 최신 릴리스를 다운로드한다.

-    ```
-    curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+   ```bash
+   curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl"
+   ```
+
+   특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
+
+   예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
+   ```bash
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
    ```

-    특정 버전을 다운로드하려면, `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다.
+   kubectl 바이너리를 실행 가능하게 만든다.

-    예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다.
-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
-    ```
-
-2. kubectl 바이너리를 실행 가능하게 만든다.
-
-    ```
-    chmod +x ./kubectl
-    ```
+   ```bash
+   chmod +x ./kubectl
+   ```

 3. 바이너리를 PATH가 설정된 디렉터리로 옮긴다.

-    ```
-    sudo mv ./kubectl /usr/local/bin/kubectl
-    ```
+   ```bash
+   sudo mv ./kubectl /usr/local/bin/kubectl
+   ```

 4. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```

 ### macOS에서 Homebrew를 사용하여 설치

@@ -146,21 +146,21 @@ macOS에서 [Homebrew](https://brew.sh/) 패키지 관리자를 사용하는 경

 1. 설치 명령을 실행한다.

-    ```
-    brew install kubectl
-    ```
+   ```bash
+   brew install kubectl
+   ```

-    또는
+   또는

-    ```
-    brew install kubernetes-cli
-    ```
+   ```bash
+   brew install kubernetes-cli
+   ```

 2. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```

 ### macOS에서 Macports를 사용하여 설치

@@ -168,117 +168,123 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하

 1. 설치 명령을 실행한다.

-    ```
-    sudo port selfupdate
-    sudo port install kubectl
-    ```
+   ```bash
+   sudo port selfupdate
+   sudo port install kubectl
+   ```

 2. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```

-## Windows에 kubectl 설치
+## 윈도우에 kubectl 설치

-### Windows에서 curl을 사용하여 kubectl 바이너리 설치
+### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치

 1. [이 링크](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)에서 최신 릴리스 {{< param "fullversion" >}}을 다운로드한다.

-    또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.
+   또는 `curl` 을 설치한 경우, 다음 명령을 사용한다.

-    ```
-    curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
-    ```
+   ```bash
+   curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe
+   ```

-    최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다.
+   최신의 안정 버전(예: 스크립팅을 위한)을 찾으려면, [https://storage.googleapis.com/kubernetes-release/release/stable.txt](https://storage.googleapis.com/kubernetes-release/release/stable.txt)를 참고한다.

 2. 바이너리를 PATH가 설정된 디렉터리에 추가한다.

 3. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```bash
+   kubectl version --client
+   ```

 {{< note >}}
-[Windows용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다.
+[윈도우용 도커 데스크톱](https://docs.docker.com/docker-for-windows/#kubernetes)은 자체 버전의 `kubectl` 을 PATH에 추가한다.
 도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 PATH 항목 앞에 PATH 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다.
 {{< /note >}}

 ### PSGallery에서 Powershell로 설치

-Windows에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.
+윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다.

 1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다).

-    ```
-    Install-Script -Name install-kubectl -Scope CurrentUser -Force
-    install-kubectl.ps1 [-DownloadLocation <path>]
-    ```
+   ```powershell
+   Install-Script -Name install-kubectl -Scope CurrentUser -Force
+   install-kubectl.ps1 [-DownloadLocation <path>]
+   ```

-{{< note >}}`DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.{{< /note >}}
+   {{< note >}}
+   `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 임시 디렉터리에 설치된다.
+   {{< /note >}}

   설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다.

 2. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```powershell
+   kubectl version --client
+   ```

 {{< note >}}
 설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다.
 {{< /note >}}

-### Chocolatey 또는 Scoop을 사용하여 Windows에 설치
+### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치

-1. Windows에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.
-
-{{< tabs name="kubectl_win_install" >}}
-{{% tab name="choco" %}}
+1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다.

+   {{< tabs name="kubectl_win_install" >}}
+   {{% tab name="choco" %}}
+   ```powershell
    choco install kubernetes-cli
-
-{{% /tab %}}
-{{% tab name="scoop" %}}
-
+   ```
+   {{% /tab %}}
+   {{% tab name="scoop" %}}
+   ```powershell
    scoop install kubectl
-
-{{% /tab %}}
-{{< /tabs >}}
+   ```
+   {{% /tab %}}
+   {{< /tabs >}}


 2. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```powershell
+   kubectl version --client
+   ```

-3. 홈 디렉토리로 이동한다.
+3. 홈 디렉터리로 이동한다.
+
+   ```powershell
+   # cmd.exe를 사용한다면, 다음을 실행한다. cd %USERPROFILE%
+   cd ~
+   ```

-    ```
-    cd %USERPROFILE%
-    ```
 4. `.kube` 디렉터리를 생성한다.

-    ```
-    mkdir .kube
-    ```
+   ```powershell
+   mkdir .kube
+   ```

 5. 금방 생성한 `.kube` 디렉터리로 이동한다.

-    ```
-    cd .kube
-    ```
+   ```powershell
+   cd .kube
+   ```

 6. 원격 쿠버네티스 클러스터를 사용하도록 kubectl을 구성한다.

-    ```
-    New-Item config -type file
-    ```
+   ```powershell
+   New-Item config -type file
+   ```

-{{< note >}}메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.{{< /note >}}
+{{< note >}}
+메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다.
+{{< /note >}}

 ## Google Cloud SDK의 일부로 다운로드

@@ -288,15 +294,15 @@ kubectl을 Google Cloud SDK의 일부로 설치할 수 있다.

 2. `kubectl` 설치 명령을 실행한다.

-    ```
-    gcloud components install kubectl
-    ```
+   ```shell
+   gcloud components install kubectl
+   ```

 3. 설치한 버전이 최신 버전인지 확인한다.

-    ```
-    kubectl version --client
-    ```
+   ```shell
+   kubectl version --client
+   ```

 ## kubectl 구성 확인

@@ -312,7 +318,7 @@ URL 응답이 표시되면, kubectl이 클러스터에 접근하도록 올바르

 다음과 비슷한 메시지가 표시되면, kubectl이 올바르게 구성되지 않았거나 쿠버네티스 클러스터에 연결할 수 없다.

-```shell
+```
 The connection to the server <server-name:port> was refused - did you specify the right host or port?
 ```

@@ -350,7 +356,7 @@ bash-completion은 많은 패키지 관리자에 의해 제공된다([여기](ht

 확인하려면, 셸을 다시 로드하고 `type _init_completion` 을 실행한다. 명령이 성공하면, 이미 설정된 상태이고, 그렇지 않으면 `~/.bashrc` 파일에 다음을 추가한다.

-```shell
+```bash
 source /usr/share/bash-completion/bash_completion
 ```

@@ -362,17 +368,17 @@ source /usr/share/bash-completion/bash_completion

 - `~/.bashrc` 파일에서 완성 스크립트를 소싱한다.

-    ```shell
-    echo 'source <(kubectl completion bash)' >>~/.bashrc
-    ```
+   ```bash
+   echo 'source <(kubectl completion bash)' >>~/.bashrc
+   ```
 - 완성 스크립트를 `/etc/bash_completion.d` 디렉터리에 추가한다.

-    ```shell
-    kubectl completion bash >/etc/bash_completion.d/kubectl
-    ```
+   ```bash
+   kubectl completion bash >/etc/bash_completion.d/kubectl
+   ```
 kubectl에 대한 앨리어스(alias)가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.

-```shell
+```bash
 echo 'alias k=kubectl' >>~/.bashrc
 echo 'complete -F __start_kubectl k' >>~/.bashrc
 ```
@@ -403,19 +409,19 @@ bash-completion에는 v1과 v2 두 가지 버전이 있다. v1은 Bash 3.2(macOS

 여기의 지침에서는 Bash 4.1 이상을 사용한다고 가정한다. 다음을 실행하여 Bash 버전을 확인할 수 있다.

-```shell
+```bash
 echo $BASH_VERSION
 ```

 너무 오래된 버전인 경우, Homebrew를 사용하여 설치/업그레이드할 수 있다.

-```shell
+```bash
 brew install bash
 ```

 셸을 다시 로드하고 원하는 버전을 사용 중인지 확인한다.

-```shell
+```bash
 echo $BASH_VERSION $SHELL
 ```

@@ -429,13 +435,13 @@ Homebrew는 보통 `/usr/local/bin/bash` 에 설치한다.

 bash-completion v2가 이미 설치되어 있는지 `type_init_completion` 으로 확인할 수 있다. 그렇지 않은 경우, Homebrew로 설치할 수 있다.

-```shell
+```bash
 brew install bash-completion@2
 ```

 이 명령의 출력에 명시된 바와 같이, `~/.bash_profile` 파일에 다음을 추가한다.

-```shell
+```bash
 export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"
 [[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . "/usr/local/etc/profile.d/bash_completion.sh"
 ```
@@ -448,29 +454,29 @@ export BASH_COMPLETION_COMPAT_DIR="/usr/local/etc/bash_completion.d"

 - 완성 스크립트를 `~/.bash_profile` 파일에서 소싱한다.

-    ```shell
+    ```bash
    echo 'source <(kubectl completion bash)' >>~/.bash_profile

    ```

 - 완성 스크립트를 `/usr/local/etc/bash_completion.d` 디렉터리에 추가한다.

-    ```shell
+    ```bash
    kubectl completion bash >/usr/local/etc/bash_completion.d/kubectl
    ```

 - kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하기 위해 셸 완성을 확장할 수 있다.

-    ```shell
+    ```bash
    echo 'alias k=kubectl' >>~/.bash_profile
    echo 'complete -F __start_kubectl k' >>~/.bash_profile
    ```

 - Homebrew로 kubectl을 설치한 경우([위](#macos에서-homebrew를-사용하여-설치)의 설명을 참고), kubectl 완성 스크립트는 이미 `/usr/local/etc/bash_completion.d/kubectl` 에 있어야 한다. 이 경우, 아무 것도 할 필요가 없다.

-  {{< note >}}
-  bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다.
-  {{< /note >}}
+   {{< note >}}
+   bash-completion v2의 Homebrew 설치는 `BASH_COMPLETION_COMPAT_DIR` 디렉터리의 모든 파일을 소싱하므로, 후자의 두 가지 방법이 적용된다.
+   {{< /note >}}

 어쨌든, 셸을 다시 로드 한 후에, kubectl 완성이 작동해야 한다.
 {{% /tab %}}
@@ -481,13 +487,13 @@ Zsh용 kubectl 완성 스크립트는 `kubectl completion zsh` 명령으로 생

 모든 셸 세션에서 사용하려면, `~/.zshrc` 파일에 다음을 추가한다.

-```shell
+```zsh
 source <(kubectl completion zsh)
 ```

 kubectl에 대한 앨리어스가 있는 경우, 해당 앨리어스로 작업하도록 셸 완성을 확장할 수 있다.

-```shell
+```zsh
 echo 'alias k=kubectl' >>~/.zshrc
 echo 'complete -F __start_kubectl k' >>~/.zshrc
 ```
@@ -496,16 +502,13 @@ echo 'complete -F __start_kubectl k' >>~/.zshrc

 `complete:13: command not found: compdef` 와 같은 오류가 발생하면, `~/.zshrc` 파일의 시작 부분에 다음을 추가한다.

-```shell
+```zsh
 autoload -Uz compinit
 compinit
 ```
 {{% /tab %}}
 {{< /tabs >}}

-
-
-
 ## {{% heading "whatsnext" %}}

 * [Minikube 설치](/ko/docs/tasks/tools/install-minikube/)
@@ -513,4 +516,3 @@ compinit
 * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/docs/tasks/access-application-cluster/service-access-application-cluster/)
 * 직접 생성하지 않은 클러스터에 접근해야하는 경우, [클러스터 접근 공유 문서](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)를 참고한다.
 * [kubectl 레퍼런스 문서](/docs/reference/kubectl/kubectl/) 읽기
-
@@ -65,7 +65,7 @@ Hyper-V Requirements:     A hypervisor has been detected. Features required for

 ### kubectl 설치

-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)의 요령을 따라서 설치할 수 있다.
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#리눅스에-kubectl-설치)의 요령을 따라서 설치할 수 있다.

 ## 하이퍼바이저(hypervisor) 설치

@@ -76,7 +76,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads)

 Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--driver=none` 옵션도 지원한다.
-이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. 
+이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경이 필요하지만, 하이퍼바이저는 필요하지 않다.

 데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우,
 Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다.
@@ -119,7 +119,7 @@ sudo install minikube /usr/local/bin/

 ### Homebrew를 이용해서 Minikube 설치하기

-또 다른 대안으로 Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다.
+또 다른 대안으로 리눅스 [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)를 이용해서 Minikube를 설치할 수 있다.

 ```shell
 brew install minikube
@@ -129,7 +129,7 @@ brew install minikube
 {{% tab name="맥OS" %}}
 ### kubectl 설치

-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)의 요령을 따라서 설치할 수 있다.
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#macos에-kubectl-설치)의 요령을 따라서 설치할 수 있다.

 ### 하이퍼바이저(hypervisor) 설치

@@ -162,10 +162,10 @@ sudo mv minikube /usr/local/bin
 ```

 {{% /tab %}}
-{{% tab name="Windows" %}}
+{{% tab name="윈도우" %}}
 ### kubectl 설치하기

-kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)의 요령을 따라서 설치할 수 있다.
+kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/ko/docs/tasks/tools/install-kubectl/#windows에-kubectl-설치)의 요령을 따라서 설치할 수 있다.

 ### 하이퍼바이저(hypervisor) 설치하기

@@ -206,7 +206,7 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini

 {{< note >}}

-`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다.
+`minikube start` 시 `--driver` 를 설정하려면, 아래에 `<driver_name>` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--driver` 값의 전체 목록은 [VM driver 지정하기 문서](/ko/docs/setup/learning-environment/minikube/#vm-드라이버-지정하기)에서 확인할 수 있다.

 {{< /note >}}
				`@@ -39,7 +39,3 @@ Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/roman`


				`로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.`