IP {0} callerCount {1} ' -f $$ip[1].IPAddress,$$callerCounts.Item($$_) } ;$$footer='' ;$$content='{0}{1}{2}' -f $$header,$$callerCountsString,$$footer ;Write-Output $$content ;$$buffer = [System.Text.Encoding]::UTF8.GetBytes($$content) ;$$response.ContentLength64 = $$buffer.Length ;$$response.OutputStream.Write($$buffer, 0, $$buffer.Length) ;$$response.Close() ;$$responseStatus = $$response.StatusCode ;Write-Host('< {0}' -f $$responseStatus) } ; "
+ nodeSelector:
+ beta.kubernetes.io/os: windows
+```
+
+{{< note >}}
+포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다.
+{{< /note >}}
+
+1. 모든 노드가 건강한지 확인한다.
+
+ ```bash
+ kubectl get nodes
+ ```
+
+1. 서비스를 배포하고 파드 갱신을 지켜보자.
+
+ ```bash
+ kubectl apply -f win-webserver.yaml
+ kubectl get pods -o wide -w
+ ```
+
+ 이 서비스가 정확히 배포되면 모든 파드는 Ready로 표기된다. 지켜보기를 중단하려면, Ctrl+C 를 누르자.
+
+1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
+
+ * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다.
+ * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다.
+ * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
+ * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며).
+ * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다.
+ * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/docs/concepts/services-networking/dns-pod-service/#services)와 서비스 이름으로 `curl`을 실행한다.
+ * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
+ * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
+
+{{< note >}}
+윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다.
+{{< /note >}}
+
+## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기
+
+쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자.
+
+## 테인트(Taint)와 톨러레이션(Toleration)
+
+오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다.
+
+### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기
+
+사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다.
+
+* beta.kubernetes.io/os = [windows|linux]
+* beta.kubernetes.io/arch = [amd64|arm64|...]
+
+파드 사양에 노드 셀렉터를 `"beta.kubernetes.io/os": windows`와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다.
+
+그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다.
+
+예를 들면, `--register-with-taints='os=Win1809:NoSchedule'`
+
+모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
+
+```yaml
+nodeSelector:
+ "beta.kubernetes.io/os": windows
+tolerations:
+ - key: "os"
+ operator: "Equal"
+ value: "Win1809"
+ effect: "NoSchedule"
+```
+
+{{% /capture %}}
diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md
new file mode 100644
index 0000000000000..3edff577bd425
--- /dev/null
+++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-nodes.md
@@ -0,0 +1,271 @@
+---
+reviewers:
+title: 쿠버네티스에서 윈도우 노드 추가 가이드
+content_template: templates/concept
+weight: 70
+---
+
+{{% capture overview %}}
+
+쿠버네티스 플랫폼은 이제 리눅스와 윈도우 컨테이너 모두 운영할 수 있다. 윈도우 노드도 클러스터에 등록할 수 있다. 이 가이드는 다음을 어떻게 하는지 보여준다.
+
+* 윈도우 노드를 클러스터에 등록하기
+* 리눅스와 윈도우에서 동작하는 파드가 상호 간에 통신할 수 있게 네트워크를 구성하기
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 시작하기 전에
+
+* 윈도우 컨테이너를 호스트하는 윈도우 노드를 구성하려면 [윈도우 서버 라이선스](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)를 소유해야 한다. 클러스터를 위해서 소속 기관의 라이선스를 사용하거나, Microsoft, 리셀러로 부터 취득할 수 있으며, GCP, AWS, Azure와 같은 주요 클라우드 제공자의 마켓플레이스를 통해 윈도우 서버를 운영하는 가상머신을 프로비저닝하여 취득할 수도 있다. [사용시간이 제한된 시험판](https://www.microsoft.com/en-us/cloud-platform/windows-server-trial)도 활용 가능하다.
+
+* 컨트롤 플레인에 접근할 수 있는 리눅스 기반의 쿠버네티스 클러스터를 구축한다.(몇 가지 예시는 [kubeadm으로 단일 컨트롤플레인 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/), [AKS Engine](/docs/setup/production-environment/turnkey/azure/), [GCE](/docs/setup/production-environment/turnkey/gce/), [AWS](/docs/setup/production-environment/turnkey/aws/)를 포함한다)
+
+## 시작하기: 사용자 클러스터에 윈도우 노드 추가하기
+
+### IP 주소 체계 설계하기
+
+쿠버네티스 클러스터 관리를 위해 실수로 네트워크 충돌을 일으키지 않도록 IP 주소에 대해 신중히 설계해야 한다. 이 가이드는 [쿠버네티스 네트워킹 개념](/docs/concepts/cluster-administration/networking/)에 익숙하다 가정한다.
+
+클러스터를 배포하려면 다음 주소 공간이 필요하다.
+
+| 서브넷 / 주소 범위 | 비고 | 기본값 |
+| --- | --- | --- |
+| 서비스 서브넷 | 라우트 불가한 순수한 가상 서브넷으로 네트워크 토플로지에 관계없이 파드에서 서비스로 단일화된 접근을 제공하기 위해 사용한다. 서비스 서브넷은 노드에서 실행 중인 `kube-proxy`에 의해서 라우팅 가능한 주소 공간으로(또는 반대로) 번역된다. | 10.96.0.0/12 |
+| 클러스터 서브넷 | 클러스터 내에 모든 파드에 사용되는 글로벌 서브넷이다. 각 노드에는 파드가 사용하기 위한 /24 보다 작거나 같은 서브넷을 할당한다. 서브넷은 클러스터 내에 모든 파드를 수용할 수 있을 정도로 충분히 큰 값이어야 한다. *최소 서브넷*의 크기를 계산하려면: `(노드의 개수) + (노드의 개수 * 구성하려는 노드 당 최대 파드 개수)`. 예: 노드 당 100개 파드인 5 노드짜리 클러스터 = `(5) + (5 * 100) = 505.` | 10.244.0.0/16 |
+| 쿠버네티스 DNS 서비스 IP | DNS 확인 및 클러스터 서비스 검색에 사용되는 서비스인 `kube-dns`의 IP 주소이다. | 10.96.0.10 |
+
+클러스터에 IP 주소를 얼마나 할당해야 할지 결정하기 위해 '쿠버네티스에서 윈도우 컨테이너: 지원되는 기능: 네트워킹'에서 소개한 네트워킹 선택 사항을 검토하자.
+
+### 윈도우에서 실행되는 구성 요소
+
+쿠버네티스 컨트롤 플레인이 리눅스 노드에서 운영되는 반면, 다음 요소는 윈도우 노드에서 구성되고 운영된다.
+
+1. kubelet
+2. kube-proxy
+3. kubectl (선택적)
+4. 컨테이너 런타임
+
+v1.14 이후의 최신 바이너리를 [https://github.com/kubernetes/kubernetes/releases](https://github.com/kubernetes/kubernetes/releases)에서 받아온다. kubeadm, kubectl, kubelet, kube-proxy의 Windows-amd64 바이너리는 CHANGELOG 링크에서 찾아볼 수 있다.
+
+### 네트워크 구성
+
+리눅스 기반의 쿠버네티스 마스터 노드를 가지고 있다면 네트워킹 솔루션을 선택할 준비가 된 것이다. 이 가이드는 단순화를 위해 VXLAN 방식의 플라넬(Flannel)을 사용하여 설명한다.
+
+#### 리눅스 컨트롤러에서 VXLAN 방식으로 플라넬 구성하기
+
+1. 플라넬을 위해 쿠버네티스 마스터를 준비한다.
+
+ 클러스터의 쿠버네티스 마스터에서 사소한 준비를 권장한다. 플라넬을 사용할 때에 iptables 체인으로 IPv4 트래픽을 브릿지할 수 있게 하는 것은 추천한다. 이는 다음 커맨드를 이용하여 수행할 수 있다.
+
+ ```bash
+ sudo sysctl net.bridge.bridge-nf-call-iptables=1
+ ```
+
+1. 플라넬 다운로드 받고 구성하기
+
+ 가장 최신의 플라넬 메니페스트를 다운로드한다.
+
+ ```bash
+ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
+ ```
+
+ VXLAN 네트워킹 벡엔드를 가능하게 하기 위해 수정할 곳은 두 곳이다.
+
+ 아래 단계를 적용하면 `kube-flannel.yml`의 `net-conf.json`부분을 다음과 같게 된다.
+
+ ```json
+ net-conf.json: |
+ {
+ "Network": "10.244.0.0/16",
+ "Backend": {
+ "Type": "vxlan",
+ "VNI" : 4096,
+ "Port": 4789
+ }
+ }
+ ```
+
+ {{< note >}}리눅스의 플라넬과 윈도우의 플라넬이 상호운용하기 위해서 `VNI`는 반드시 4096이고, `Port`는 4789여야 한다. 다른 VNI는 곧 지원될 예정이다. [VXLAN 문서](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)에서
+ 이 필드의 설명 부분을 보자.{{< /note >}}
+
+1. `kube-flannel.yml`의 `net-conf.json` 부분을 거듭 확인하자.
+ 1. 클러스터 서브넷(예, "10.244.0.0/16")은 IP 주소 설계에 따라 설정되어야 한다.
+ * VNI 4096 은 벡엔드에 설정한다.
+ * Port 4789 는 벡엔드에 설정한다.
+ 2. `kube-flannel.yml`의 `cni-conf.json` 부분에서 네트워크 이름을 `vxlan0`로 바꾼다.
+
+
+ `cni-conf.json`는 다음과 같다.
+
+ ```json
+ cni-conf.json: |
+ {
+ "name": "vxlan0",
+ "plugins": [
+ {
+ "type": "flannel",
+ "delegate": {
+ "hairpinMode": true,
+ "isDefaultGateway": true
+ }
+ },
+ {
+ "type": "portmap",
+ "capabilities": {
+ "portMappings": true
+ }
+ }
+ ]
+ }
+ ```
+
+1. 플라넬 yaml 을 적용하고 확인하기
+
+ 플라넬 구성을 적용하자.
+
+ ```bash
+ kubectl apply -f kube-flannel.yml
+ ```
+
+ 다음은 플라넬 파드는 리눅스 기반이라 [여기](https://github.com/Microsoft/SDN/blob/1d5c055bb195fecba07ad094d2d7c18c188f9d2d/Kubernetes/flannel/l2bridge/manifests/node-selector-patch.yml) 나온 노드 셀렉터 패치를 플라넬 데몬셋 파드에 적용한다.
+
+ ```bash
+ kubectl patch ds/kube-flannel-ds-amd64 --patch "$(cat node-selector-patch.yml)" -n=kube-system
+ ```
+
+ 몇 분 뒤에 플라넬 파드 네트워크가 배포되었다면, 모든 파드에서 운영 중인 것을 확인할 수 있다.
+
+ ```bash
+ kubectl get pods --all-namespaces
+ ```
+
+ 
+
+ 플라넬 데몬셋에 노드 셀렉터가 적용되었음을 확인한다.
+
+ ```bash
+ kubectl get ds -n kube-system
+ ```
+
+ 
+
+#### 윈도우 워커 조인
+
+이번 단원은 맨 땅에서부터 온프레미스 클러스터에 가입하기까지 윈도우 노드 구성을 다룬다. 클러스터가 클라우드상에 있다면, 다음 단원에 있는 클라우드에 특정한 가이드를 따르도록 된다.
+
+#### 윈도우 노드 준비하기
+{{< note >}}
+윈도우 단원에서 모든 코드 부분은 높은 권한(Admin)으로 파워쉘(PowerShell) 환경에서 구동한다.
+{{< /note >}}
+
+1. 도커(Docker) 설치(시스템 리부팅 필요)
+
+ 쿠버네티스는 [도커](https://www.docker.com/)를 컨테이너 엔진으로 사용하므로, 도커를 설치해야 한다. [공식 문서 설치 요령](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-docker/configure-docker-daemon#install-docker), [도커 명령](https://store.docker.com/editions/enterprise/docker-ee-server-windows)을 따라 해보거나 다음의 *권장하는* 단계를 시도하자.
+
+ ```PowerShell
+ Enable-WindowsOptionalFeature -FeatureName Containers
+ Restart-Computer -Force
+ Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
+ Install-Package -Name Docker -ProviderName DockerMsftProvider
+ ```
+
+ 네트워크 프록시 안쪽에서 작업한다면 다음 파워쉘 환경 변수를 반드시 정의하자.
+
+ ```PowerShell
+ [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+ [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+ ```
+
+ 리부팅 후에 다음 오류를 보게되면, 도커 서비스를 수동으로 재시작해야 한다.
+
+ 
+
+ ```PowerShell
+ Start-Service docker
+ ```
+
+{{< note >}}
+`pause`(인프라스트럭처) 이미지는 Microsoft 컨테이너 레지스트리(MCR)에 등록되어 있다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`로 접근할 수 있다. `DOCKERFILE`은 https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat 에 있다.
+{{< /note >}}
+
+1. 쿠버네티스를 위한 윈도우 디렉터리 준비하기
+
+ 쿠버네티스 바이너리와 배포 스크립트와 구성 파일을 저장할 "윈도우를 위한 쿠버네티스" 디렉터리를 생성한다.
+
+ ```PowerShell
+ mkdir c:\k
+ ```
+
+1. 쿠버네티스 인증서 복사하기
+
+ 쿠버네티스 인증서 파일인 `$HOME/.kube/config`을 [리눅스 컨트롤러](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/creating-a-linux-master#collect-cluster-information)에서 윈도우 노드의 새로운 `C:\k` 디렉터리로 복사한다.
+
+ 팁: 노드 간에 구성 파일 전송을 위해 [xcopy](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/xcopy), [WinSCP](https://winscp.net/eng/download.php)나 [WinSCP 파워쉘 래퍼](https://www.powershellgallery.com/packages/WinSCP/5.13.2.0)같은 도구를 이용할 수 있다.
+
+1. 쿠버네티스 바이너리 다운로드 하기
+
+ 쿠버네티스르 운영을 가능하게 하기 위해 먼저 `kubelet`과 `kube-proxy` 바이너리를 다운로드해야 한다. 이 바이너리를 [최신 릴리스](https://github.com/kubernetes/kubernetes/releases/)의 CHANGELOG.md 파일에 노드 바이너리 링크에서 다운로드 한다. 예를 들어 'kubernetes-node-windows-amd64.tar.gz'. 또한 클라이언트 바이너리 항목에서 찾을 수 있는 윈도우에서 실행되는 `kubectl`을 선택적으로 다운로드 받을 수 있다.
+
+ 압축 파일을 풀고, `C:\k`로 바이너리를 위치하기 위해 [Expand-Archive](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.archive/expand-archive?view=powershell-6) 파워쉘 커맨드를 이용할 수 있다.
+
+#### 윈도우 노드를 플라넬 클러스터에 가입하기
+
+플라넬 오버레이 배포 스크립트와 문서는 [이 리포지터리](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/overlay)에 있다. 다음 단계는 그곳에 있는 자세한 요령을 따라서 단순히 진행하는 것이다.
+
+[Flannel start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1) 스크립트를 다운로드받고, 그 내용을 `C:\k`에 풀어 넣자.
+
+```PowerShell
+cd c:\k
+[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
+wget https://raw.githubusercontent.com/Microsoft/SDN/master/Kubernetes/flannel/start.ps1 -o c:\k\start.ps1
+```
+
+{{< note >}}
+[start.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1)은 [install.ps1](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/install.ps1)을 참고하는데, 이는 사용자를 위해 `flanneld` 실행 **파일 같은** 추가 파일과 [인프라스트럭처 파드를 위한 Dockerfile](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/Dockerfile)을 다운로드하고 설치한다. 오버레이 네트워킹 방식에서 [방화벽](https://github.com/Microsoft/SDN/blob/master/Kubernetes/windows/helper.psm1#L111)은 지역 UDP 4789 포트에 대해 열려있다. 여러 파워쉘 윈도우가 열렸다 닫히며, 포드 네트워크를 위한 새로운 외부 vSwitch가 처음 생성되는 동안 몇 초간은 네트워크가 중단된다. 아래 지정한 인수를 사용하여 스크립트를 실행하자.
+{{< /note >}}
+
+```PowerShell
+.\start.ps1 -ManagementIP
+ 첫 번째 디플로이먼트로, 도커 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자.
+ (Node.js 애플리케이션을 작성하고 Node.js 애플리케이션을 배포하고, 컨테이너를 활용해서 배포해보지 않았다면,
+ Hello Minikube 튜토리얼의 지시를 따른다.)
- 우리의 첫 번째 디플로이먼트로, Docker 컨테이너로 패키지된 Node.js 애플리케이션을 사용해보자.
- Node.js 애플리케이션을 작성하고 Docker 컨테이너를 배포하기 위해서,
- Hello Minikube 튜토리얼의 지시를 따른다. 이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자! 이제 디플로이먼트를 이해했으니, 온라인 튜토리얼을 통해 우리의 첫 번째 애플리케이션을 배포해보자!ipconfig 이용할 수 있다. |
+| -LogDir | C:\k | Kubelet과 Kube-proxy가 각각의 로그 출력 파일을 리다이렉션하는 디렉터리이다. |
+
+이제 다음을 실행하여 사용자 클러스터 내에 윈도우 노드를 볼 수 있다.
+
+```bash
+kubectl get nodes
+```
+
+{{< note >}}
+Kubelet, kueb-proxy 같은 윈도우 노드 구성요소를 윈도우 서비스로 구성할 수 있다. 추가적인 방법은 [문제 해결](#troubleshooting)의 서비스와 백그라운드 프로세스 단원을 보자. 노드의 구성요소를 서비스로 실행하면 로그 수집하는 것이 문제 해결에 있어 중요한 부분이 된다. 추가 지침으로 기여 가이드에서 [로그 수집하기](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) 단원을 보자.
+{{< /note >}}
+
+### 공개 클라우드 제공자
+
+#### Azure
+
+AKS-Engine은 완전하고, 맞춤 설정이 가능한 쿠버네티스 클러스터를 리눅스와 윈도우 노드에 배포할 수 있다. 단계별 안내가 [GitHub에 있는 문서](https://github.com/Azure/aks-engine/blob/master/docs/topics/windows.md)로 제공된다.
+
+#### GCP
+
+사용자가 [GitHub](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/windows/README-GCE-Windows-kube-up.md)에 있는 단계별 안내를 따라서 완전한 쿠버네티스 클러스터를 GCE 상에 쉽게 배포할 수 있다.
+
+#### kubeadm과 클러스터 API로 배포하기
+
+Kubeadm은 쿠버네티스 클러스터를 배포하는 사용자에게 산업 표준이 되었다. Kubeadm에서 윈도우 노드 지원은 미래 릴리스에 나올 것이다. 또한 윈도우 노드가 올바르게 프로비저닝되도록 클러스터 API에 투자하고 있다.
+
+### 다음 단계
+
+이제 클러스터 내에 윈도우 컨테이너를 실행하도록 윈도우 워커를 구성했으니, 리눅스 컨테이너를 실행할 리눅스 노드를 1개 이상 추가할 수 있다. 이제 윈도우 컨테이너를 클러스터에 스케줄링할 준비가 됬다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/setup/production-environment/windows/windows-docker-error.png b/content/ko/docs/setup/production-environment/windows/windows-docker-error.png
new file mode 100644
index 0000000000000..d00528c0d4cc4
Binary files /dev/null and b/content/ko/docs/setup/production-environment/windows/windows-docker-error.png differ
diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
new file mode 100644
index 0000000000000..97eb33b87b2c9
--- /dev/null
+++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -0,0 +1,165 @@
+---
+title: 웹 UI (대시보드)
+content_template: templates/concept
+weight: 10
+card:
+ name: tasks
+ weight: 30
+ title: Use the Web UI Dashboard
+---
+
+{{% capture overview %}}
+대시보드는 웹 기반 쿠버네티스 유저 인터페이스이다. 대시보드를 통해 컨테이너화 된 애플리케이션을 쿠버네티스 클러스터에 배포할 수 있고, 컨테이너화 된 애플리케이션을 트러블슈팅 할 수 있으며, 클러스터 리소스들을 관리할 수 있다. 대시보드를 통해 클러스터에서 동작중인 애플리케이션의 정보를 볼 수 있고, 개별적인 쿠버네티스 리소스들을(예를 들면 디플로이먼트, 잡, 데몬셋 등) 생성하거나 수정할 수 있다. 예를 들면, 디플로이먼트를 스케일하거나, 롤링 업데이트를 초기화하거나, 파드를 재시작하거나 또는 배포 마법사를 이용해 새로운 애플리케이션을 배포할 수 있다.
+
+또한 대시보드는 클러스터 내 쿠버네티스 리소스들의 상태와 발생하는 모든 에러 정보를 제공한다.
+
+
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 대시보드 UI 배포
+
+대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다.
+
+```
+kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-beta1/aio/deploy/recommended.yaml
+```
+
+## 대시보드 UI 접근
+
+클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, [샘플 사용자 만들기](https://github.com/kubernetes/dashboard/wiki/Creating-sample-user) 가이드를 따른다.
+
+{{< warning >}}
+시연 중에 생성한 샘플 사용자는 어드민 권한이 부여되며, 이는 교육 목적으로만 사용한다.
+{{< /warning >}}
+
+### 커맨드 라인 프록시
+kubectl 커맨드라인 도구를 이용해 다음 커맨드를 실행함으로써 대시보드를 사용할 수 있다.
+
+```
+kubectl proxy
+```
+
+kubectl은 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 에 대시보드를 사용하는 것을 가능하게 해줄 것이다.
+
+UI는 커맨드가 실행된 머신에서 _오직_ 접근 가능하다. 상세 내용은 `kubectl proxy --help` 옵션을 확인한다.
+
+{{< note >}}
+Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 인증서를 지원하지 않는다.
+{{< /note >}}
+
+## 웰컴 뷰
+
+초기 클러스터 대시보드에 접근하면, 환영 페이지를 볼 수 있다. 이 페이지는 첫 애플리케이션을 배포하는 버튼이 있을 뿐만 아니라, 이 문서의 링크를 포함하고 있다. 게다가, 대시보드가 있는 클러스터에서 기본적으로 `kube-system` [네임스페이스](/docs/tasks/administer-cluster/namespaces/)이 동작중인 시스템 애플리케이션을 볼 수 있다.
+
+
+
+## 컨테이너화 된 애플리케이션 배포
+
+대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다.
+
+시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다.
+
+### 애플리케이션 세부 정보 지정
+
+배포 마법사는 다음 정보를 제공한다.
+
+- **앱 이름** (필수): 애플리케이션 이름. [레이블](/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다.
+
+ 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다.
+
+- **컨테이너 이미지** (필수): 레지스트리에 올라간 퍼블릭 도커 [컨테이너 이미지](/docs/concepts/containers/images/) 또는 프라이빗 이미지(대체로 Google Container Registry 또는 도커 허브에 올라간)의 URL. 컨테이너 이미지 사양은 콜론으로 끝난다.
+
+- **파드의 수** (필수): 배포하고 싶은 애플리케이션의 원하는 목표 파드 개수. 값은 양의 정수만 허용됩니다.
+
+ 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다.
+
+- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다.
+
+ 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다.
+
+ 서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다.
+
+만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다.
+
+- **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다.
+
+- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다.
+
+ 예를 들면:
+
+ ```conf
+release=1.0
+tier=frontend
+environment=pod
+track=stable
+```
+
+- **네임스페이스**: 쿠버네티스는 동일한 물리 클러스터를 바탕으로 여러 가상의 클러스터를 제공한다. 이러한 가상 클러스터들을 [네임스페이스](/docs/tasks/administer-cluster/namespaces/)라고 부른다. 논리적으로 명명된 그룹으로 리소스들을 분할 할 수 있다.
+
+ 대시보드는 드롭다운 리스트로 가능한 모든 네임스페이스를 제공하고, 새로운 네임스페이스를 생성할 수 있도록 한다. 네임스페이스 이름은 최대 63개의 영숫자 단어와 대시(-)를 포함하고 있지만 대문자를 가지지 못한다.
+ 네임스페이스 이름은 숫자로만 구성할 수 없다. 만약 이름을 10이라는 숫자로 세팅한다면, 파드는 기본 네임스페이스로 배정하게 될 것이다.
+
+ 네임스페이스 생성이 성공하는 경우, 생성된 네임스페이스가 기본으로 선택된다. 만약 생성에 실패하면, 첫번째 네임스페이스가 선택된다.
+
+- **이미지 풀(Pull) 시크릿**: 특정 도커 컨테이너 이미지가 프라이빗한 경우, [풀(Pull) 시크릿](/docs/concepts/configuration/secret/) 증명을 요구한다.
+
+ 대시보드는 가능한 모든 시크릿을 드롭다운 리스트로 제공하며, 새로운 시크릿을 생성 할 수 있도록 한다. 시크릿 이름은 예를 들어 `new.image-pull.secret` 과 같이 DNS 도메인 이름 구문으로 따르기로 한다. 시크릿 내용은 base64 인코딩 방식이며, [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 파일로 정의된다. 시크릿 이름은 최대 253 문자를 포함할 수 있다.
+
+ 이미지 풀(Pull) 시크릿의 생성이 성공한 경우, 기본으로 선택된다. 만약 생성에 실패하면, 시크릿은 허용되지 않는다.
+
+- **CPU 요구 사항 (cores)** 와 **메모리 요구 사항 (MiB)**: 컨테이너를 위한 최소 [리소스 상한](/docs/tasks/configure-pod-container/limit-range/)을 정의할 수 있다. 기본적으로, 파드는 CPU와 메모리 상한을 두지 않고 동작한다.
+
+- **커맨드 실행** 와 **커맨드 인수 실행**: 기본적으로, 컨테이너는 선택된 도커 이미지의 [기본 엔트리포인트 커맨드](/docs/user-guide/containers/#containers-and-commands)를 실행한다. 커맨드 옵션과 인자를 기본 옵션에 우선 적용하여 사용할 수 있다.
+
+- **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다.
+
+- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다.
+
+### YAML 또는 JSON 파일 업로드
+
+쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다.
+
+배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다.
+
+## 대시보드 사용
+다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다.
+
+### 탐색
+
+클러스터에 정의된 쿠버네티스 오프젝트가 있으면, 대시보드는 초기화된 뷰를 제공한다. 기본적으로 _기본_ 네임스페이스의 오프젝트만이 보이는데, 이는 탐색 창에 위치한 네임스페이스 셀렉터를 이용해 변경할 수 있다.
+
+대시보드는 몇가지 메뉴 카테고리 중에서 대부분의 쿠버네티스 오브젝트 종류와 그룹을 보여준다.
+
+#### 어드민 개요
+클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다.
+
+#### 워크로드
+선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다.
+
+워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다.
+
+#### 서비스(Service)
+외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다.
+
+#### 스토리지
+스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다.
+
+#### 컨피그 맵과 시크릿
+클러스터에서 동작 중인 애플리케이션의 라이브 설정을 사용하는 모든 쿠버네티스 리소스들을 보여준다. 컨피그 오브젝트들을 수정하고 관리할 수 있도록 허용하며, 기본적으로는 숨겨져 있는 시크릿들을 보여준다.
+
+#### 로그 뷰어
+파드 목록과 세부사항 페이지들은 대시보드에 구현된 로그 뷰어에 링크된다. 뷰어는 단일 파드에 있는 컨테이너들의 로그들을 내려가면 볼 수 있도록 한다.
+
+
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md
new file mode 100644
index 0000000000000..4f4a2ce184123
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/highly-available-master.md
@@ -0,0 +1,175 @@
+---
+reviewers:
+title: 고가용성 쿠버네티스 클러스터 마스터 설정하기
+content_template: templates/task
+---
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="1.5" state="alpha" >}}
+
+구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다.
+이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다.
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## HA 호환 클러스터 시작
+
+새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다.
+
+* `MULTIZONE=true` - 서버의 기본 존(zone)과 다른 존에서 마스터 복제본의 kubelet이 제거되지 않도록 한다.
+다른 존에서 마스터 복제본을 실행하려는 경우에 권장하고 필요하다.
+
+* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
+true인 경우, Etcd의 리더 복제본에서 읽는다.
+이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
+
+선택적으로 첫 번째 마스터 복제본이 생성될 GCE 존을 지정할 수 있다.
+다음 플래그를 설정한다.
+
+* `KUBE_GCE_ZONE=zone` - 첫 마스터 복제본이 실행될 존.
+
+다음 샘플 커맨드는 europe-west1-b GCE 존에 HA 호환 클러스터를 구성한다.
+
+```shell
+MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
+```
+
+위에 커맨드는 하나의 마스터로 클러스터를 생성한다.
+그러나 후속 커맨드로 새 마스터 복제본을 추가할 수 있다.
+
+## 새 마스터 복제본 추가
+
+HA 호환 클러스터를 생성한 다음 그것의 마스터 복제본을 추가할 수 있다.
+`kube-up` 스크립트에 다음 플래그를 사용하여 마스터 복제본을 추가한다.
+
+* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 마스터의 복제본을
+만든다.
+
+* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 실행될 존.
+반드시 다른 복제본 존과 동일한 존에 있어야 한다.
+
+HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
+설정할 필요는 없다.
+
+다음 샘플 커맨드는 기존 HA 호환 클러스터에서 마스터를 복제한다.
+
+```shell
+KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+```
+
+## 마스터 복제본 제거
+
+다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 마스터 복제본을 제거할 수 있다.
+
+* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다.
+
+* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 제거될 존.
+
+* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 마스터 복제본의 이름.
+비어있는 경우, 해당 존의 모든 복제본이 제거된다.
+
+다음 샘플 커맨드는 기존 HA 클러스터에서 마스터 복제본을 제거한다.
+
+```shell
+KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
+```
+
+## 마스터 복제 실패 처리
+
+HA 클러스터의 마스터 복제본 중 하나가 실패하면,
+클러스터에서 복제본을 제거하고 동일한 존에서 새 복제본을 추가하는 것이 가장 좋다.
+다음 샘플 커맨드로 이 과정을 시연한다.
+
+1. 손상된 복제본을 제거한다.
+
+ ```shell
+ KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
+ ```
+
+1. 기존 복제본 대신 새 복제본을 추가한다.
+
+ ```shell
+ KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
+ ```
+
+## HA 클러스터에서 마스터 복제에 관한 모범 사례
+
+* 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다.
+존 장애를 극복하기 위해 노드를 여러 존에 배치한다
+(더 자세한 내용은 [멀티 존](/docs/setup/best-practices/multiple-zones/)를 참조한다).
+
+* 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다.
+결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다.
+따라서 두 개의 복제본 클러스터는 HA 관점에서 단일 복제 클러스터보다 열등하다.
+
+* 마스터 복제본을 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
+클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
+이 작업은 [여기](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) 기술한 대로
+Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다).
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+
+## 구현 지침
+
+
+
+### 개요
+
+각 마스터 복제본은 다음 모드에서 다음 구성 요소를 실행한다.
+
+* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
+
+* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
+
+* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
+
+* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
+
+또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
+
+### 로드 밸런싱
+
+두 번째 마스터 복제본을 시작할 때, 두 개의 복제본을 포함된 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
+비슷하게 끝에서 두 번째의 마스터 복제본을 제거한 후에는 로드 밸런서가 제거되고
+해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
+로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
+
+### 마스터 서비스와 Kubelet
+
+쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
+시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
+
+* 단일 마스터 클러스터에서 IP 주소는 단일 마스터를 가리킨다.
+
+* 다중 마스터 클러스터에서 IP 주소는 마스터 앞에 로드밸런서를 가리킨다.
+
+마찬가지로 Kubelet은 외부 IP 주소를 사용하여 마스터와 통신한다.
+
+### 마스터 인증서
+
+쿠버네티스는 각 복제본의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 마스터 TLS 인증서를 발급한다.
+복제본의 임시 공개 IP 주소에 대한 인증서는 없다.
+임시 퍼블릭 IP 주소를 통해 복제본에 접근하려면, TLS 검증을 건너뛰어야 한다.
+
+### etcd 클러스터화
+
+etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
+이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
+
+## 추가 자료
+
+[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
+
+{{% /capture %}}
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md
new file mode 100644
index 0000000000000..94d43ce6f08f5
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/_index.md
@@ -0,0 +1,4 @@
+---
+title: 네트워크 폴리시 제공자(Network Policy Provider) 설치
+weight: 30
+---
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
new file mode 100644
index 0000000000000..209d07a3b0396
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md
@@ -0,0 +1,53 @@
+---
+reviewers:
+title: 네트워크 폴리시로 캘리코(Calico) 사용하기
+content_template: templates/task
+weight: 10
+---
+
+{{% capture overview %}}
+이 페이지는 쿠버네티스에서 캘리코(Calico) 클러스터를 생성하는 몇 가지 빠른 방법을 살펴본다.
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+[클라우드](#creating-a-calico-cluster-with-google-kubernetes-engine-gke)나 [지역](#creating-a-local-calico-cluster-with-kubeadm) 클러스터 중에 어디에 배포할지 결정한다.
+{{% /capture %}}
+
+{{% capture steps %}}
+## 구글 쿠버네티스 엔진(GKE)에 캘리코 클러스터 생성하기 {#creating-a-calico-cluster-with-google-kubernetes-engine-gke}
+
+**사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts).
+
+1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다.
+
+ **문법**
+ ```shell
+ gcloud container clusters create [클러스터_이름] --enable-network-policy
+ ```
+
+ **예시**
+ ```shell
+ gcloud container clusters create my-calico-cluster --enable-network-policy
+ ```
+
+1. 배포를 확인하기 위해, 다음 커맨드를 이용하자.
+
+ ```shell
+ kubectl get pods --namespace=kube-system
+ ```
+
+ 캘리코 파드는 `calico`로 시작한다. 각각의 상태가 `Running`임을 확인하자.
+
+## kubeadm으로 지역 캘리코 클러스터 생성하기 {#creating-a-local-calico-cluster-with-kubeadm}
+
+Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러스터를 생성하려면,
+[캘리코 빠른 시작](https://docs.projectcalico.org/latest/getting-started/kubernetes/)을 참고한다.
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해
+[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+{{% /capture %}}
+
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
new file mode 100644
index 0000000000000..b0cba9681ecad
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -0,0 +1,106 @@
+---
+reviewers:
+title: 네트워크 폴리시로 실리움(Cilium) 사용하기
+content_template: templates/task
+weight: 20
+---
+
+{{% capture overview %}}
+이 페이지는 어떻게 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)를 사용하는지 살펴본다.
+
+실리움의 배경에 대해서는 [실리움 소개](https://cilium.readthedocs.io/en/stable/intro)를 읽어보자.
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+{{% capture steps %}}
+## 기본 시험을 위해 실리움을 Minikube에 배포하기
+
+실리움에 쉽게 친숙해지기 위해
+Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
+[실리움 쿠버네티스 시작하기 안내](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
+
+Minikube를 시작하려면 최소 버전으로 >= v0.33.1 이 필요하고,
+다음의 실행 파라미터로 실행한다.
+
+```shell
+minikube version
+```
+```
+minikube version: v0.33.1
+```
+
+```shell
+minikube start --network-plugin=cni --memory=4096
+```
+
+Minikube에서 실리움의 데몬셋 구성과 Minikube에 배포된 etcd 인스턴스로 접속하는데 필요한 구성 뿐만 아니라
+RBAC 설정을 포함하는 필요한 구성을
+이 간단한 ``올인원`` YAML 파일로 배포할 수 있다.
+
+```shell
+kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
+```
+```
+configmap/cilium-config created
+daemonset.apps/cilium created
+clusterrolebinding.rbac.authorization.k8s.io/cilium created
+clusterrole.rbac.authorization.k8s.io/cilium created
+serviceaccount/cilium created
+```
+
+시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
+L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예, HTTP)의 보안 정책을
+적용하는 방법을 설명한다.
+
+## 실리움을 실 서비스 용도로 배포하기
+
+실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
+[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)를 살펴본다.
+이 문서는 자세한 요구사항, 방법과
+실제 데몬셋 예시를 포함한다.
+
+{{% /capture %}}
+
+{{% capture discussion %}}
+## 실리움 구성요소 이해하기
+
+실리움으로 클러스터를 배포하면 파드가 `kube-system` 네임스페이스에 추가된다.
+파드의 목록을 보려면 다음을 실행한다.
+
+```shell
+kubectl get pods --namespace=kube-system
+```
+
+다음과 유사한 파드의 목록을 볼 것이다.
+
+```console
+NAME READY STATUS RESTARTS AGE
+cilium-6rxbd 1/1 Running 0 1m
+...
+```
+
+알고 있어야 할 두 가지 주요 구성요소는 다음과 같다.
+
+- 먼저는 `cilium` 파드가 클러스터의 각 노드에서 운영되고,
+노드의 파드로 보내고/받는 트래픽을 리눅스 BPF를 이용하여 네트워크 폴리시를 적용한다.
+- 실 서비스에 배포하는 경우 실리움은 키-값 저장소(예, etcd)를 활용해야 한다.
+[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)에서
+키-값 저장소를 설치하는 방법과 실리움에서 이를 구성하는 필수 단계를
+제공할 것이다.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+클러스터가 동작하면,
+실리움으로 쿠버네티스 네트워크 폴리시를 시도하기 위해
+[네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+재미있게 즐기고, 질문이 있다면
+[실리움 슬랙 채널](https://cilium.herokuapp.com/)을 이용하여 연락한다.
+{{% /capture %}}
+
+
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
new file mode 100644
index 0000000000000..1ff8d7c4ccd7b
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md
@@ -0,0 +1,25 @@
+---
+reviewers:
+title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기
+content_template: templates/task
+weight: 30
+---
+
+{{% capture overview %}}
+이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다.
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+운영 중인 쿠버네티스 클러스터가 필요하다. 클러스터가 없다면, Kops, Bootkube, Kubeadm 등을 이용해서 클러스터를 생성할 수 있다.
+{{% /capture %}}
+
+{{% capture steps %}}
+## 큐브 라우터 애드온 설치하기
+큐브 라우터 애드온은 갱신된 모든 네트워크 폴리시 및 파드에 대해 쿠버네티스 API 서버를 감시하고, 정책에 따라 트래픽을 허용하거나 차단하도록 iptables 규칙와 ipset을 구성하는 네트워크 폴리시 컨트롤러와 함께 제공된다. 큐브 라우터 애드온을 설치하는 [큐브 라우터를 클러스터 인스톨러와 함께 사용하기](https://www.kube-router.io/docs/user-guide/#try-kube-router-with-cluster-installers) 안내서를 따라해 봅니다.
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+큐브 라우터 애드온을 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+{{% /capture %}}
+
+
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
new file mode 100644
index 0000000000000..5e2c28a7c9164
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md
@@ -0,0 +1,42 @@
+---
+reviewers:
+title: 네트워크 폴리시로 로마나(Romana)
+content_template: templates/task
+weight: 40
+---
+
+{{% capture overview %}}
+
+이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+[kubeadm 시작하기](/docs/getting-started-guides/kubeadm/)의 1, 2, 3 단계를 완료하자.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## kubeadm으로 로마나 설치하기
+
+Kubeadm을 위한 [컨테이너화된 설치 안내서](https://github.com/romana/romana/tree/master/containerize)를 따른다.
+
+## 네트워크 폴리시 적용하기
+
+네트워크 폴리시를 적용하기 위해 다음 중에 하나를 사용하자.
+
+* [Romana 네트워크 폴리시](https://github.com/romana/romana/wiki/Romana-policies).
+ * [Romana 네트워크 폴리시의 예](https://github.com/romana/core/blob/master/doc/policy.md).
+* 네트워크 폴리시 API.
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+로마나를 설치한 후에는, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다.
+
+{{% /capture %}}
+
+
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
new file mode 100644
index 0000000000000..91456a0385928
--- /dev/null
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md
@@ -0,0 +1,58 @@
+---
+reviewers:
+title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기
+content_template: templates/task
+weight: 50
+---
+
+{{% capture overview %}}
+
+이 페이지는 네트워크 폴리시(NetworkPolicy)로 위브넷(Weave Net)를 사용하는 방법을 살펴본다.
+
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 [kubeadm 시작하기 안내서](/docs/getting-started-guides/kubeadm/)를 따른다.
+
+{{% /capture %}}
+
+{{% capture steps %}}
+
+## Weave Net 애드온을 설치한다
+
+[애드온을 통한 쿠버네티스 통합하기](https://www.weave.works/docs/net/latest/kube-addon/) 가이드를 따른다.
+
+쿠버네티스의 위브넷 애드온은 쿠버네티스의 모든 네임스페이스의 네크워크 정책 어노테이션을 자동으로 모니터링하며, 정책에 따라 트래픽을 허용하고 차단하는 `iptables` 규칙을 구성하는 [네트워크 폴리시 컨트롤러](https://www.weave.works/docs/net/latest/kube-addon/#npc)와 함께 제공된다.
+
+## 설치 시험
+
+위브넷이 동작하는지 확인한다.
+
+다음 커맨드를 입력한다.
+
+```shell
+kubectl get pods -n kube-system -o wide
+```
+
+출력은 다음과 유사하다.
+
+```
+NAME READY STATUS RESTARTS AGE IP NODE
+weave-net-1t1qg 2/2 Running 0 9d 192.168.2.10 worknode3
+weave-net-231d7 2/2 Running 1 7d 10.2.0.17 worknodegpu
+weave-net-7nmwt 2/2 Running 3 9d 192.168.2.131 masternode
+weave-net-pmw8w 2/2 Running 0 9d 192.168.2.216 worknode2
+```
+
+위브넷 파드를 가진 각 노드와 모든 파드는 `Running`이고 `2/2 READY`이다(`2/2`는 각 파드가 `weave`와 `weave-npc`를 가지고 있음을 뜻한다).
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+위브넷 애드온을 설치하고 나서, 쿠버네티스 네트워크 폴리시를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. 질문이 있으면 [슬랙 #weave-community 이나 Weave 유저그룹](https://github.com/weaveworks/weave#getting-help)에 연락한다.
+
+{{% /capture %}}
+
+
diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
index ca5003a98da77..b314f9683c0d4 100644
--- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
+++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
@@ -6,7 +6,7 @@ content_template: templates/concept
{{% capture overview %}}
쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은
-쿠버네티스의 Metrics API를 통해 사용할 수 있다. 이 메트릭은
+쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은
`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나,
Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다.
@@ -15,9 +15,9 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
{{% capture body %}}
-## Metrics API
+## 메트릭 API
-Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인
+메트릭 API를 통해 주어진 노드나 파드에서 현재 사용중인
리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지
않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을
가져오는 것과 같은 일을 할 수는 없다.
@@ -31,23 +31,23 @@ Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인
리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다.
{{< note >}}
-이 API를 사용하려면 Metrics server를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
+이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
{{< /note >}}
-## Metrics Server
+## 메트릭 서버
-[Metrics server](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
-쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 Metrics server가
+[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
+쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가
디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된
-[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 Metrics server를 배포할 수 있다.
+[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 메트릭 서버를 배포할 수 있다.
이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조)
-Metric server는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
+메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다.
-Metrics server는 쿠버네티스 1.7에서 도입된
+메트릭 서버는 쿠버네티스 1.7에서 도입된
[쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를
통해 메인 API 서버에 등록된다.
-[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 Metrics server에 대해 자세하게 배울 수 있다.
+[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다.
{{% /capture %}}
diff --git a/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
new file mode 100644
index 0000000000000..639668b3f9fdd
--- /dev/null
+++ b/content/ko/docs/tasks/inject-data-application/define-command-argument-container.md
@@ -0,0 +1,158 @@
+---
+title: 컨테이너를 위한 커맨드와 인자 정의하기
+content_template: templates/task
+weight: 10
+---
+
+{{% capture overview %}}
+
+본 페이지는 {{< glossary_tooltip text="파드" term_id="pod" >}} 안에서 컨테이너를 실행할
+때 커맨드와 인자를 정의하는 방법에 대해 설명한다.
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+{{% /capture %}}
+
+
+{{% capture steps %}}
+
+## 파드를 생성할 때 커맨드와 인자를 정의하기
+
+파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 커맨드와 인자를
+정의할 수 있다. 커맨드를 정의하기 위해서는, 파드 안에서 실행되는 컨테이너에
+`command` 필드를 포함시킨다. 커맨드에 대한 인자를 정의하기 위해서는, 구성
+파일에 `args` 필드를 포함시킨다. 정의한 커맨드와 인자들은 파드가 생성되고
+난 이후에는 변경될 수 없다.
+
+구성 파일 안에서 정의하는 커맨드와 인자들은 컨테이너 이미지가
+제공하는 기본 커맨드와 인자들보다 우선시 된다. 만약 인자들을
+정의하고 커맨드를 정의하지 않는다면, 기본 커맨드가 새로운 인자와
+함께 사용된다.
+
+{{< note >}}
+`command` 필드는 일부 컨테이너 런타임에서 `entrypoint`에 해당된다.
+아래의 [참고사항](#참고사항)을 확인하자.
+{{< /note >}}
+
+이 예제에서는 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성
+파일에서 커맨드와 두 개의 인자를 정의한다.
+
+{{< codenew file="pods/commands.yaml" >}}
+
+1. YAML 구성 파일을 활용해 파드를 생성한다.
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/commands.yaml
+ ```
+
+1. 실행 중인 파드들의 목록을 조회한다.
+
+ ```shell
+ kubectl get pods
+ ```
+
+ 출력은 command-demo라는 파드 안에서 실행된 컨테이너가 완료되었다고 표시할
+ 것이다.
+
+1. 컨테이너 안에서 실행된 커맨드의 출력을 보기 위해, 파드의 로그를
+확인한다.
+
+ ```shell
+ kubectl logs command-demo
+ ```
+
+ 출력은 HOSTNAME과 KUBERNETES_PORT 환경 변수들의 값들을 표시할
+ 것이다.
+
+ ```
+ command-demo
+ tcp://10.3.240.1:443
+ ```
+
+## 인자를 정의하기 위해 환경 변수를 사용하기
+
+이전 예제에서는, 문자열을 제공하면서 직접 인자를 정의해보았다.
+문자열을 직접 제공하는 것에 대한 대안으로, 환경 변수들을 사용하여 인자들을
+정의할 수 있다.
+
+```yaml
+env:
+- name: MESSAGE
+ value: "hello world"
+command: ["/bin/echo"]
+args: ["$(MESSAGE)"]
+```
+
+이것은 [컨피그 맵](/docs/tasks/configure-pod-container/configure
+-pod-configmap/)과 [시크릿](/docs/concepts/configuration/secret/)을
+포함해, 환경 변수를 정의하는데 활용할 수 있는 모든 방법들을 활용해서 파드를 위한 인자를
+정의할
+수 있다는 것을 의미한다.
+
+{{< note >}}
+환경 변수는 `"$(VAR)"`와 같이 괄호 안에 나타난다. 이는 변수가 `command`나 `args`
+필드 안에서 전개되기 위해 필요한 것이다.
+{{< /note >}}
+
+## 셸 안에서 커맨드 실행하기
+
+일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가
+서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서
+커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다.
+
+```shell
+command: ["/bin/sh"]
+args: ["-c", "while true; do echo hello; sleep 10;done"]
+```
+
+## 참고사항
+
+이 테이블은 도커와 쿠버네티스에서 사용되는 필드 이름들을 정리한 것이다.
+
+| 설명 | 도커 필드 이름 | 쿠버네티스 필드 이름 |
+|----------------------------------------|------------------------|-----------------------|
+| 컨테이너에서 실행되는 커맨드 | Entrypoint | command |
+| 커맨드에 전달되는 인자들 | Cmd | arg |
+
+기본 Entrypoint와 Cmd 값을 덮어쓰려고 한다면, 아래의 규칙들이 적용된다.
+
+* 만약 컨테이너를 위한 `command` 값이나 `args` 값을 제공하지 않는다면, 도커 이미지 안에
+제공되는 기본 값들이 사용된다.
+
+* 만약 컨테이너를 위한 `command` 값을 제공하고, `args` 값을 제공하지 않는다면,
+제공된 `command` 값만이 사용된다. 도커 이미지 안에 정의된 기본 EntryPoint 값과 기본
+Cmd 값은 덮어쓰여진다.
+
+* 만약 컨테이너를 위한 `args` 값만 제공한다면, 도커 이미지 안에 정의된 기본 EntryPoint
+값이 정의한 `args` 값들과 함께 실행된다.
+
+* `command` 값과 `args` 값을 동시에 정의한다면, 도커 이미지 안에 정의된 기본
+EntryPoint 값과 기본 Cmd 값이 덮어쓰여진다. `command`가 `args` 값과 함께
+실행된다.
+
+여기 몇 가지 예시들이 있다.
+
+| 이미지 Entrypoint | 이미지 Cmd | 컨테이너 command | 컨테이너 args | 실행되는 커맨드 |
+|--------------------|------------------|---------------------|--------------------|------------------|
+| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | <설정되지 않음> | `[ep-1 foo bar]` |
+| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | <설정되지 않음> | `[ep-2]` |
+| `[/ep-1]` | `[foo bar]` | <설정되지 않음> | `[zoo boo]` | `[ep-1 zoo boo]` |
+| `[/ep-1]` | `[foo bar]` | `[/ep-2]` | `[zoo boo]` | `[ep-2 zoo boo]` |
+
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [파드와 컨테이너를 구성하는 방법](/ko/docs/tasks/)에 대해 더 알아본다.
+* [컨테이너 안에서 커맨드를 실행하는 방법](/docs/tasks/debug-application-cluster/get-shell-running-container/)에 대해 더 알아본다.
+* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)를 확인한다.
+
+{{% /capture %}}
+
+
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index ee7cf0093aaad..f9520b6f6a1de 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -60,7 +60,7 @@ index.php는 CPU 과부하 연산을 수행한다.
첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다.
```shell
-kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
+kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80
```
```
service/php-apache created
diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md
index 80100f534d654..5d80c63981d2b 100644
--- a/content/ko/docs/tasks/tools/install-minikube.md
+++ b/content/ko/docs/tasks/tools/install-minikube.md
@@ -18,17 +18,19 @@ card:
{{< tabs name="minikube_before_you_begin" >}}
{{% tab name="리눅스" %}}
리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다.
-```shell
-egrep --color 'vmx|svm' /proc/cpuinfo
+```
+grep -E --color 'vmx|svm' /proc/cpuinfo
```
{{% /tab %}}
+
{{% tab name="맥OS" %}}
맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다.
```
-sysctl -a | grep machdep.cpu.features
+sysctl -a | grep -E --color 'machdep.cpu.features|VMX'
```
-만약 출력 중에 `VMX`를 볼 수 있다면 VT-x 기능을 운영체제에서 지원한다.
+만약 출력 중에 (색상으로 강조된) `VMX`를 볼 수 있다면, VT-x 기능이 머신에서 활성화된 것이다.
{{% /tab %}}
+
{{% tab name="윈도우" %}}
윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다.
```
@@ -73,7 +75,7 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설
• [VirtualBox](https://www.virtualbox.org/wiki/Downloads)
{{< note >}}
-Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경을 필요로 한다.
+Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다.
{{< /note >}}
### 패키지를 이용하여 Minikube 설치
@@ -158,14 +160,14 @@ Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows
윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행).
```shell
-choco install minikube kubernetes-cli
+choco install minikube
```
Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다.
### 인스톨러 실행파일을 통한 Minikube 설치
-윈도우에서 수동으로 [Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.
+[윈도우 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용하여 윈도우에 Minikube를 수동으로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/download/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다.
### 직접 다운로드하여 Minikube 설치
diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
index be7cb5f61d548..27db50cdf19c2 100644
--- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -96,6 +96,11 @@ kubectl exec -it redis redis-cli
2) "allkeys-lru"
```
+생성된 파드를 삭제한다.
+```shell
+kubectl delete pod redis
+```
+
{{% /capture %}}
{{% capture whatsnext %}}
diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
index a7f8e8bfec54c..c2e4d9f4a3343 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html
@@ -102,13 +102,13 @@ 쿠버네티스에 첫 번째 애플리케이션 배
diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md
index 402cb29a10872..63115403917b0 100644
--- a/content/ko/docs/tutorials/online-training/overview.md
+++ b/content/ko/docs/tutorials/online-training/overview.md
@@ -43,6 +43,8 @@ content_template: templates/concept
* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
+* [Kubernetes Fundamentals (LFS258) (The Linux Foundation)](https://training.linuxfoundation.org/training/kubernetes-fundamentals/)
+
* [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start)
* [Kubernetes the Hard Way with Hands-On Labs (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
index 2014c301a7d4b..991d43262cede 100644
--- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
+++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md
@@ -92,6 +92,13 @@ EOF
{{< codenew file="application/wordpress/mysql-deployment.yaml" >}}
+다음의 매니페스트는 단일-인스턴스 WordPress 디플로이먼트를 기술한다. WordPress 컨테이너는
+웹사이트 데이터 파일을 위해 `/var/www/html`에 퍼시스턴트볼륨을 마운트한다. `WORDPRESS_DB_HOST` 환경 변수에는
+위에서 정의한 MySQL 서비스의 이름이 설정되며, WordPress는 서비스를 통해 데이터베이스에 접근한다.
+`WORDPRESS_DB_PASSWORD` 환경 변수에는 kustomize가 생성한 데이터베이스 패스워드가 설정된다.
+
+{{< codenew file="application/wordpress/wordpress-deployment.yaml" >}}
+
1. MySQL 디플로이먼트 구성 파일을 다운로드한다.
```shell
diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
new file mode 100644
index 0000000000000..01c24a16f9524
--- /dev/null
+++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md
@@ -0,0 +1,401 @@
+---
+title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
+reviewers:
+content_template: templates/tutorial
+weight: 21
+card:
+ name: tutorials
+ weight: 31
+ title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
+---
+
+{{% capture overview %}}
+이 튜토리얼은 [Redis를 이용한 PHP 방명록](../guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다.
+
+* [Redis를 이용한 PHP 방명록](../guestbook)을 실행한 인스턴스
+* Elasticsearch와 Kibana
+* Filebeat
+* Metricbeat
+* Packetbeat
+
+{{% /capture %}}
+
+{{% capture objectives %}}
+* Redis를 이용한 PHP 방명록 시작.
+* kube-state-metrics 설치.
+* 쿠버네티스 시크릿 생성.
+* Beats 배포.
+* 로그와 메트릭의 대시보드 보기.
+{{% /capture %}}
+
+{{% capture prerequisites %}}
+
+{{< include "task-tutorial-prereqs.md" >}}
+{{< version-check >}}
+
+추가로 다음이 필요하다.
+
+* 실행 중인 [Redis를 이용한 PHP 방명록](../guestbook) 튜토리얼의 배포본.
+
+* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다.
+
+{{% /capture %}}
+
+{{% capture lessoncontent %}}
+
+## Redis를 이용한 PHP 방명록 시작
+이 튜토리얼은 [Redis를 이용한 PHP 방명록](../guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자.
+
+## 클러스터 롤 바인딩 추가
+[클러스터 단위 롤 바인딩](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다.
+
+```shell
+kubectl create clusterrolebinding cluster-admin-binding \
+ --clusterrole=cluster-admin --user=