Merge pull request #26643 from ysyukr/dev-1.20-ko.5-outdated-part-03

Update to Outdated files in dev-1.20-ko.5 branch (3)
2021-02-22 21:24:03 -08:00 · 2021-02-22 21:24:03 -08:00 · 2daeee3424
parent 767bee3cd7 2d78104965
commit 2daeee3424
26 changed files with 204 additions and 895 deletions
--- a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
+++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md
@ -32,7 +32,7 @@ content_type: task
 수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화
 하여 스토리지의 동적 프로비저닝을 방지할 수 있다.

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

--- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
+++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md
@ -9,18 +9,13 @@ weight: 100
 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 
 사용하는 파드를 생성하는 방법을 보여준다.

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

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

 * 이 실습을 수행하기 위해, 
 [도커 ID](https://docs.docker.com/docker-id/)와 비밀번호가 필요하다.

-
-
 <!-- steps -->

 ## 도커 로그인
@ -106,7 +101,8 @@ kubectl create secret docker-registry regcred --docker-server=<your-registry-ser

 아래의 각 항목에 대한 설명을 참고한다.

-* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다. (도커허브(DockerHub)의 경우, https://index.docker.io/v1/)
+* `<your-registry-server>` 은 프라이빗 도커 저장소의 FQDN 주소이다.
+  도커허브(DockerHub)는 `https://index.docker.io/v2/` 를 사용한다.
 * `<your-name>` 은 도커 사용자의 계정이다.
 * `<your-pword>` 은 도커 사용자의 비밀번호이다.
 * `<your-email>` 은 도커 사용자의 이메일 주소이다.
@ -192,7 +188,8 @@ your.private.registry.example.com/janedoe/jdoe-private:v1
 ```

 프라이빗 저장소에서 이미지를 받아오기 위하여, 쿠버네티스에서 자격 증명이 필요하다.
-구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가 `regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.
+구성 파일의 `imagePullSecrets` 필드를 통해 쿠버네티스가
+`regcred` 라는 시크릿으로부터 자격 증명을 가져올 수 있다.

 시크릿을 사용해서 파드를 생성하고, 파드가 실행되는지 확인하자.

@ -201,16 +198,11 @@ kubectl apply -f my-private-reg-pod.yaml
 kubectl get pod private-reg
 ```

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

-
 * [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
 * [프라이빗 레지스트리 사용](/ko/docs/concepts/containers/images/#프라이빗-레지스트리-사용)에 대해 더 배워 보기.
 * [서비스 어카운트에 풀 시크릿(pull secret) 추가하기](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)에 대해 더 배워 보기.
 * [kubectl create secret docker-registry](/docs/reference/generated/kubectl/kubectl-commands/#-em-secret-docker-registry-em-)에 대해 읽어보기.
 * [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)에 대해 읽어보기.
 * [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 `imagePullSecrets` 필드에 대해 읽어보기.
-
-
--- a/content/ko/docs/tasks/configure-pod-container/static-pod.md
+++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md
@ -22,6 +22,7 @@ Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버
 생성하려고 자동으로 시도한다.
 즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만,
 API 서버에서 제어될 수는 없다.
+파드 이름에는 노드 호스트 이름 앞에 하이픈을 붙여 접미사로 추가된다.

 {{< note >}}
 만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여
--- a/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
+++ b/content/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana.md
@ -1,121 +0,0 @@
---
-content_type: concept
-title: 엘라스틱서치(Elasticsearch) 및 키바나(Kibana)를 사용한 로깅
---
-
-<!-- overview -->
-
-Google 컴퓨트 엔진(Compute Engine, GCE) 플랫폼에서, 기본 로깅 지원은
-[스택드라이버(Stackdriver) 로깅](https://cloud.google.com/logging/)을 대상으로 한다. 이는
-[스택드라이버 로깅으로 로깅하기](/docs/tasks/debug-application-cluster/logging-stackdriver)에 자세히 설명되어 있다.
-
-이 문서에서는 GCE에서 운영할 때 스택드라이버 로깅의 대안으로,
-[엘라스틱서치](https://www.elastic.co/products/elasticsearch)에 로그를 수집하고
-[키바나](https://www.elastic.co/products/kibana)를 사용하여 볼 수 있도록
-클러스터를 설정하는 방법에 대해 설명한다.
-
-{{< note >}}
-Google 쿠버네티스 엔진(Kubernetes Engine)에서 호스팅되는 쿠버네티스 클러스터에는 엘라스틱서치 및 키바나를 자동으로 배포할 수 없다. 수동으로 배포해야 한다.
-{{< /note >}}
-
-
-
-<!-- body -->
-
-클러스터 로깅에 엘라스틱서치, 키바나를 사용하려면 kube-up.sh를 사용하여
-클러스터를 생성할 때 아래와 같이 다음의 환경 변수를
-설정해야 한다.
-
-```shell
-KUBE_LOGGING_DESTINATION=elasticsearch
-```
-
-또한 `KUBE_ENABLE_NODE_LOGGING=true`(GCE 플랫폼의 기본값)인지 확인해야 한다.
-
-이제, 클러스터를 만들 때, 각 노드에서 실행되는 Fluentd 로그 수집 데몬이
-엘라스틱서치를 대상으로 한다는 메시지가 나타난다.
-
-```shell
-cluster/kube-up.sh
-```
-```
-...
-Project: kubernetes-satnam
-Zone: us-central1-b
-... calling kube-up
-Project: kubernetes-satnam
-Zone: us-central1-b
-+++ Staging server tars to Google Storage: gs://kubernetes-staging-e6d0e81793/devel
-+++ kubernetes-server-linux-amd64.tar.gz uploaded (sha1 = 6987c098277871b6d69623141276924ab687f89d)
-+++ kubernetes-salt.tar.gz uploaded (sha1 = bdfc83ed6b60fa9e3bff9004b542cfc643464cd0)
-Looking for already existing resources
-Starting master and configuring firewalls
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/zones/us-central1-b/disks/kubernetes-master-pd].
-NAME                 ZONE          SIZE_GB TYPE   STATUS
-kubernetes-master-pd us-central1-b 20      pd-ssd READY
-Created [https://www.googleapis.com/compute/v1/projects/kubernetes-satnam/regions/us-central1/addresses/kubernetes-master-ip].
-+++ Logging using Fluentd to elasticsearch
-```
-
-노드별 Fluentd 파드, 엘라스틱서치 파드 및 키바나 파드는
-클러스터가 활성화된 직후 kube-system 네임스페이스에서 모두 실행되어야
-한다.
-
-```shell
-kubectl get pods --namespace=kube-system
-```
-```
-NAME                                           READY     STATUS    RESTARTS   AGE
-elasticsearch-logging-v1-78nog                 1/1       Running   0          2h
-elasticsearch-logging-v1-nj2nb                 1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-5oq0     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-6896     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-l1ds     1/1       Running   0          2h
-fluentd-elasticsearch-kubernetes-node-lz9j     1/1       Running   0          2h
-kibana-logging-v1-bhpo8                        1/1       Running   0          2h
-kube-dns-v3-7r1l9                              3/3       Running   0          2h
-monitoring-heapster-v4-yl332                   1/1       Running   1          2h
-monitoring-influx-grafana-v1-o79xf             2/2       Running   0          2h
-```
-
-`fluentd-elasticsearch` 파드는 각 노드에서 로그를 수집하여
-`elasticsearch-logging` 파드로 전송한다. 이 로그는 `elasticsearch-logging` 이라는
-[서비스](/ko/docs/concepts/services-networking/service/)의 일부이다. 이
-엘라스틱서치 파드는 로그를 저장하고 REST API를 통해 노출한다.
-`kibana-logging` 파드는 엘라스틱서치에 저장된 로그를 읽기 위한 웹 UI를
-제공하며, `kibana-logging` 이라는 서비스의 일부이다.
-
-엘라스틱서치 및 키바나 서비스는 모두 `kube-system` 네임스페이스에
-있으며 공개적으로 접근 가능한 IP 주소를 통해 직접 노출되지 않는다. 이를 위해,
-[클러스터에서 실행 중인 서비스 접근](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)에
-대한 지침을 참고한다.
-
-브라우저에서 `elasticsearch-logging` 서비스에 접근하려고 하면,
-다음과 같은 상태 페이지가 표시된다.
-
-![엘라스틱서치 상태](/images/docs/es-browser.png)
-
-원할 경우, 이제 엘라스틱서치 쿼리를 브라우저에 직접 입력할 수
-있다. 수행 방법에 대한 자세한 내용은 [엘라스틱서치의 문서](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-uri-request.html)를
-참조한다.
-
-또는, 키바나를 사용하여 클러스터의 로그를 볼 수도 있다(다시
-[클러스터에서 실행되는 서비스에 접근하기 위한 지침](/ko/docs/tasks/access-application-cluster/access-cluster/#클러스터에서-실행되는-서비스로-액세스)을 참고).
-키바나 URL을 처음 방문하면 수집된 로그 보기를
-구성하도록 요청하는 페이지가 표시된다. 시계열 값에
-대한 옵션을 선택하고 `@timestamp` 를 선택한다. 다음 페이지에서
-`Discover` 탭을 선택하면 수집된 로그를 볼 수 있다.
-로그를 정기적으로 새로 고치려면 새로 고침 간격을 5초로
-설정할 수 있다.
-
-키바나 뷰어에서 수집된 로그의 일반적인 보기는 다음과 같다.
-
-![키바나 로그](/images/docs/kibana-logs.png)
-
-
-
-## {{% heading "whatsnext" %}}
-
-
-키바나는 로그를 탐색하기 위한 모든 종류의 강력한 옵션을 제공한다! 이를 파헤치는 방법에 대한
-아이디어는 [키바나의 문서](https://www.elastic.co/guide/en/kibana/current/discover.html)를 확인한다.
--- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
+++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md
@ -22,7 +22,7 @@ content_type: task

 ## kubectl 플러그인 설치

-플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 간단히 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.
+플러그인은 이름이 `kubectl-` 로 시작되는 독립형 실행 파일이다. 플러그인을 설치하려면, 실행 파일을 `PATH` 에 지정된 디렉터리로 옮기면 된다.

 [Krew](https://krew.dev/)를 사용하여 오픈소스에서 사용 가능한
 kubectl 플러그인을 검색하고 설치할 수도 있다. Krew는 쿠버네티스 SIG CLI 커뮤니티에서 관리하는
@ -57,9 +57,9 @@ Krew [플러그인 인덱스](https://krew.sigs.k8s.io/plugins/)를 통해 사

 플러그인 설치 또는 사전 로딩이 필요하지 않다. 플러그인 실행 파일은
 `kubectl` 바이너리에서 상속된 환경을 받는다.
-플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다. 예를
-들어, 새로운 명령인 `kubectl foo` 를 제공하려는 플러그인은 단순히 이름이
-`kubectl-foo` 이고, `PATH` 의 어딘가에 있다.
+플러그인은 이름을 기반으로 구현할 명령 경로를 결정한다.
+예를 들어, `kubectl-foo` 라는 플러그인은 `kubectl foo` 명령을 제공한다.
+`PATH` 어딘가에 플러그인 실행 파일을 설치해야 한다.

 ### 플러그인 예제

@ -85,30 +85,31 @@ echo "I am a plugin named kubectl-foo"

 ### 플러그인 사용

-위의 플러그인을 사용하려면, 간단히 실행 가능하게 만든다.
+플러그인을 사용하려면, 실행 가능하게 만든다.

-```
+```shell
 sudo chmod +x ./kubectl-foo
 ```

 그리고 `PATH` 의 어느 곳에나 옮겨 놓는다.

-```
+```shell
 sudo mv ./kubectl-foo /usr/local/bin
 ```

 이제 플러그인을 `kubectl` 명령으로 호출할 수 있다.

-```
+```shell
 kubectl foo
 ```
+
 ```
 I am a plugin named kubectl-foo
 ```

 모든 인수와 플래그는 그대로 실행 파일로 전달된다.

-```
+```shell
 kubectl foo version
 ```
 ```
@ -120,6 +121,7 @@ kubectl foo version
 ```bash
 export KUBECONFIG=~/.kube/config
 kubectl foo config
+
 ```
 ```
 /home/<user>/.kube/config
@ -128,6 +130,7 @@ kubectl foo config
 ```shell
 KUBECONFIG=/etc/kube/config kubectl foo config
 ```
+
 ```
 /etc/kube/config
 ```
@ -373,11 +376,8 @@ kubectl 플러그인의 배포 패키지를
 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가
 더 쉬워진다.

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

-
 * Go로 작성된 플러그인의
  [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는
  샘플 CLI 플러그인 리포지터리를 확인한다.
--- a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
+++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md
@ -35,7 +35,7 @@ weight: 30

 ## 메시지 대기열 서비스 시작

-이 문서의 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 타입의 메시지 서비스에 적용하는데 문제가 없을 것이다.
+이 예시에서는 RabbitMQ를 사용하지만, 다른 AMQP 유형의 메시지 서비스를 사용하도록 예시를 조정할 수 있다.

 실제로 사용할 때는, 클러스터에 메시지 대기열 서비스를 한 번
 구축하고서, 여러 많은 잡이나 오래 동작하는 서비스에 재사용할 수 있다.
--- a/content/ko/docs/tasks/job/parallel-processing-expansion.md
+++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md
@ -12,7 +12,7 @@ weight: 20
 있다.

 이 예에는 _apple_, _banana_ 그리고 _cherry_ 세 항목만 있다.
-샘플 잡들은 단순히 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.
+샘플 잡들은 문자열을 출력한 다음 일시 정지하는 각 항목을 처리한다.

 이 패턴이 보다 실질적인 유스케이스에 어떻게 부합하는지 알아 보려면
 [실제 워크로드에서 잡 사용하기](#실제-워크로드에서-잡-사용하기)를 참고한다.
--- a/content/ko/docs/tasks/run-application/delete-stateful-set.md
+++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md
@ -60,7 +60,7 @@ PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자.

 ### 스테이트풀셋의 완벽한 삭제

-연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다.
+연결된 파드를 포함해서 스테이트풀셋의 모든 것을 삭제하기 위해 다음과 같이 일련의 명령을 실행한다.

 ```shell
 grace=$(kubectl get pods <stateful-set-pod> --template '{{.spec.terminationGracePeriodSeconds}}')
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@ -190,7 +190,7 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
 `kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
 마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.

-또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
+또한 Horizontal Pod Autoscaler를 생성할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
 예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
 실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
 그리고 2와 5 사이의 레플리카 개수로 설정된다.
@ -220,9 +220,10 @@ v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의
 v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
 필요성을 제거하였다.

- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은
-  오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을
-  수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다.
+- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
+  안정화되기까지의 시간 간격을 지정한다.
+  Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
+  이 시간 간격에서의 가장 큰 크기에서만 작동한다.
  기본값은 5분(`5m0s`)이다.

 {{< note >}}
@ -382,7 +383,12 @@ behavior:
      periodSeconds: 60
 ```

-파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
+`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
+첫 번째 정책은 _(파드들)_ 이 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
+두 번째 정책은 _비율_ 로 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
+
+기본적으로 가장 많은 변경을 허용하는 정책이 선택되기에 두 번째 정책은
+파드의 레플리카 수가 40개를 초과하는 경우에만 사용된다. 레플리카가 40개 이하인 경우 첫 번째 정책이 적용된다.
 예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
 경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
 다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
@ -390,10 +396,6 @@ behavior:
 미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
 4개의 레플리카가 줄어든다.

-`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
-첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
-두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
-
 확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
 레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
 값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
@ -440,7 +442,7 @@ behavior:
      periodSeconds: 15
    selectPolicy: Max
 ```
-안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
+안정화 윈도우의 스케일링 다운의 경우 _300_ 초 (또는 제공된
 경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
 실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
 대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
--- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
+++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md
@ -65,6 +65,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로

        kubectl describe deployment mysql

+    출력은 다음과 유사하다.
+
        Name:                 mysql
        Namespace:            default
        CreationTimestamp:    Tue, 01 Nov 2016 11:18:45 -0700
@ -105,6 +107,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로

        kubectl get pods -l app=mysql

+    출력은 다음과 유사하다.
+
        NAME                   READY     STATUS    RESTARTS   AGE
        mysql-63082529-2z3ki   1/1       Running   0          3m

@ -112,6 +116,8 @@ MySQL을 실행하고 퍼시스턴트볼륨클레임을 참조하는 디플로

        kubectl describe pvc mysql-pv-claim

+    출력은 다음과 유사하다.
+
        Name:         mysql-pv-claim
        Namespace:    default
        StorageClass:
--- a/content/ko/docs/tutorials/_index.md
+++ b/content/ko/docs/tutorials/_index.md
@ -33,7 +33,7 @@ content_type: concept

 * [외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기](/ko/docs/tutorials/stateless-application/expose-external-ip-address/)

-* [예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/)
+* [예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/)

 ## 상태 유지가 필요한(stateful) 애플리케이션

--- a/content/ko/docs/tutorials/clusters/apparmor.md
+++ b/content/ko/docs/tutorials/clusters/apparmor.md
@ -168,8 +168,7 @@ k8s-apparmor-example-deny-write (enforce)

 *이 예시는 AppArmor를 지원하는 클러스터를 이미 구성하였다고 가정한다.*

-먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 단순히
-파일 쓰기를 거부할 것이다.
+먼저 노드에서 사용하려는 프로파일을 적재해야 한다. 사용할 프로파일은 파일 쓰기를 거부한다.

 ```shell
 #include <tunables/global>
--- a/content/ko/docs/tutorials/kubernetes-basics/_index.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html
@ -41,7 +41,7 @@ card:
    <div class="row">
      <div class="col-md-9">
        <h2>쿠버네티스가 어떤 도움이 될까?</h2>
-        <p>오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.</p>
+        <p>오늘날의 웹서비스에 대해서, 사용자는 애플리케이션이 24/7 가용하기를 바라고, 개발자는 하루에도 몇 번이고 새로운 버전의 애플리케이션을 배포하기를 바란다. 컨테이너화를 통해 소프트웨어를 패키지하면 애플리케이션을 다운타임 없이 릴리스 및 업데이트할 수 있게 되어서 이런 목표를 달성하는데 도움이 된다. 쿠버네티스는 이렇게 컨테이너화된 애플리케이션을 원하는 곳 어디에든 또 언제든 구동시킬 수 있다는 확신을 갖는데 도움을 주며, 그 애플리케이션이 작동하는데 필요한 자원과 도구를 찾는 것을 도와준다. 쿠버네티스는 구글의 컨테이너 오케스트레이션 부문의 축적된 경험으로 설계되고 커뮤니티로부터 도출된 최고의 아이디어가 결합된 운영 수준의 오픈 소스 플랫폼이다.</p>
      </div>
    </div>

--- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@ -64,12 +64,6 @@ weight: 10
 			</div>
 		</div>

-		<div class="row">
-			<div class="col-md-8">
-				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
-			</div>
-		</div>
-
 		<div class="row">
 			<div class="col-md-8">
 				<p>서비스는 파드 셋에 걸쳐서 트래픽을 라우트한다. 여러분의 애플리케이션에 영향을 주지 않으면서 쿠버네티스에서 파드들이 죽게도 하고, 복제가 되게도 해주는 추상적 개념이다. 종속적인 파드들 사이에서의 디스커버리와 라우팅은 (하나의 애플리케이션에서 프로트엔드와 백엔드 컴포넌트와 같은) 쿠버네티스 서비스들에 의해 처리된다.</p>
--- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
+++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md
@ -921,7 +921,7 @@ web-2     0/1       Terminating   0         3m

 `web` 스테이트풀셋이 다시 생성될 때 먼저 `web-0` 시작한다.
 `web-1`은 이미  Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로
-전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
+전환될 때는 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고
 `web-0`을 재생성했다면 `web-1`이
 이미 Running과 Ready 상태이고,
 `web-2`은 종료되었을 것이다.
@ -932,6 +932,7 @@ web-2     0/1       Terminating   0         3m
 ```shell
 for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
 ```
+
 ```
 web-0
 web-1
@ -957,6 +958,7 @@ kubectl get pods -w -l app=nginx
 ```shell
 kubectl delete statefulset web
 ```
+
 ```
 statefulset.apps "web" deleted
 ```
@ -966,6 +968,7 @@ statefulset.apps "web" deleted
 ```shell
 kubectl get pods -w -l app=nginx
 ```
+
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 web-0     1/1       Running   0          11m
@ -997,6 +1000,7 @@ web-1     0/1       Terminating   0         29m
 ```shell
 kubectl delete service nginx
 ```
+
 ```
 service "nginx" deleted
 ```
@ -1006,6 +1010,7 @@ service "nginx" deleted
 ```shell
 kubectl apply -f web.yaml
 ```
+
 ```
 service/nginx created
 statefulset.apps/web created
@ -1017,6 +1022,7 @@ statefulset.apps/web created
 ```shell
 for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
 ```
+
 ```
 web-0
 web-1
@ -1031,13 +1037,16 @@ web-1
 ```shell
 kubectl delete service nginx
 ```
+
 ```
 service "nginx" deleted
 ```
+
 그리고 `web` 스테이트풀셋을 삭제한다.
 ```shell
 kubectl delete statefulset web
 ```
+
 ```
 statefulset "web" deleted
 ```
--- a/content/ko/docs/tutorials/stateful-application/zookeeper.md
+++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md
@ -15,17 +15,17 @@ weight: 40
 이 튜토리얼을 시작하기 전에
 다음 쿠버네티스 개념에 친숙해야 한다.

-   [파드](/ko/docs/concepts/workloads/pods/)
-   [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
-   [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
-   [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
-   [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
-   [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
-   [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
-   [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
-   [kubectl CLI](/ko/docs/reference/kubectl/kubectl/)
+- [파드](/ko/docs/concepts/workloads/pods/)
+- [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)
+- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)
+- [퍼시스턴트볼륨](/ko/docs/concepts/storage/persistent-volumes/)
+- [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/)
+- [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)
+- [PodDisruptionBudget](/ko/docs/concepts/workloads/pods/disruptions/#파드-disruption-budgets)
+- [파드안티어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
+- [kubectl CLI](/ko/docs/reference/kubectl/kubectl/)

-최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.
+반드시 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 축출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다.

 이 튜토리얼은 클러스터가 동적으로 퍼시스턴트볼륨을 프로비저닝하도록 구성한다고 가정한다.
 그렇게 설정되어 있지 않다면
@ -37,15 +37,15 @@ weight: 40

 이 튜토리얼을 마치면 다음에 대해 알게 된다.

-   어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
-   어떻게 앙상블을 일관되게 설정하는가.
-   어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
-   어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.
+- 어떻게 스테이트풀셋을 이용하여 ZooKeeper 앙상블을 배포하는가.
+- 어떻게 앙상블을 일관되게 설정하는가.
+- 어떻게 ZooKeeper 서버 디플로이먼트를 앙상블 안에서 퍼뜨리는가.
+- 어떻게 PodDisruptionBudget을 이용하여 계획된 점검 기간 동안 서비스 가용성을 보장하는가.


 <!-- lessoncontent -->

-### ZooKeeper 기본 {#zookeeper-basics}
+### ZooKeeper

 [아파치 ZooKeeper](https://zookeeper.apache.org/doc/current/)는
 분산 애플리케이션을 위한 분산 오픈 소스 코디네이션 서비스이다.
@ -438,8 +438,8 @@ datadir-zk-2   Bound     pvc-bee0817e-bcb1-11e6-994f-42010a800002   20Gi       R

 ```shell
 volumeMounts:
-        - name: datadir
-          mountPath: /var/lib/zookeeper
+- name: datadir
+  mountPath: /var/lib/zookeeper
 ```

 `zk` 스테이트풀셋이 (재)스케줄링될 때 항상 동일한 `퍼시스턴트볼륨`을
@ -462,6 +462,7 @@ ZooKeeper 앙상블에 서버는 리더 선출과 쿼럼을 구성하기 위한
 ```shell
 kubectl get sts zk -o yaml
 ```
+
 ```
 …
 command:
@ -551,11 +552,9 @@ kubectl logs zk-0 --tail 20
 2016-12-06 19:34:46,230 [myid:1] - INFO  [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
 ```

-쿠버네티스는 더 강력하지만 조금 복잡한 로그 통합을
-[스택드라이버](/docs/tasks/debug-application-cluster/logging-stackdriver/)와
-[Elasticsearch와 Kibana](/ko/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/)를 지원한다.
-클러스터 수준의 로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해
-[사이드카](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) 컨테이너를 배포하는 것을 고려한다.
+쿠버네티스는 많은 로그 솔루션과 통합된다. 클러스터와 애플리케이션에
+가장 적합한 로그 솔루션을 선택할 수 있다. 클러스터 수준의
+로그 적재(ship)와 통합을 위해서는 로그 순환과 적재를 위해 [사이드카 컨테이너](/ko/docs/concepts/cluster-administration/logging/#로깅-에이전트와-함께-사이드카-컨테이너-사용)를 배포하는 것을 고려한다.

 ### 권한 없는 사용자를 위해 구성하기

@ -623,6 +622,7 @@ drwxr-sr-x 3 zookeeper zookeeper 4096 Dec  5 20:45 /var/lib/zookeeper/data
 ```shell
 kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
 ```
+
 ```
 statefulset.apps/zk patched
 ```
@ -632,6 +632,7 @@ statefulset.apps/zk patched
 ```shell
 kubectl rollout status sts/zk
 ```
+
 ```
 waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
 Waiting for 1 pods to be ready...
@ -872,8 +873,8 @@ kubernetes-node-2g2d

 ## 생존 유지

-**이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면,
-다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.**
+이 섹션에서는 노드를 통제(cordon)하고 비운다(drain). 공유된 클러스터에서 이 튜토리얼을 진행한다면,
+다른 테넌트에 부정적인 영향을 비치지 않음을 보증해야 한다.

 이전 섹션은 계획되지 않은 노드 실패에서 살아남도록
 어떻게 파드를 확산할 것인가에 대해 알아보았다.
@ -1008,6 +1009,7 @@ zk-1      0/1       Pending   0         0s
 ```shell
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
 ```
+
 ```
 node "kubernetes-node-i4c4" cordoned

@ -1051,6 +1053,7 @@ numChildren = 0
 ```shell
 kubectl uncordon kubernetes-node-pb41
 ```
+
 ```
 node "kubernetes-node-pb41" uncordoned
 ```
@ -1060,6 +1063,7 @@ node "kubernetes-node-pb41" uncordoned
 ```shell
 kubectl get pods -w -l app=zk
 ```
+
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
@ -1125,7 +1129,6 @@ drain으로 노드를 통제하고 유지보수를 위해 노드를 오프라인


 - `kubectl uncordon`은 클러스터 내에 모든 노드를 통제 해제한다.
- 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한
-  퍼시스턴트 스토리지 미디어를 삭제하자.
+- 반드시 이 튜토리얼에서 사용한 퍼시스턴트 볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제하자.
  귀하의 환경과 스토리지 구성과 프로비저닝 방법에서 필요한 절차를 따라서
  모든 스토리지가 재확보되도록 하자.
--- 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
@ -1,457 +0,0 @@
---
-title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
-content_type: tutorial
-weight: 21
-card:
-  name: tutorials
-  weight: 31
-  title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가"
---
-
-<!-- overview -->
-이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼을 기반으로 한다. Elastic의 경량 로그, 메트릭, 네트워크 데이터 오픈소스 배송기인 *Beats* 를 방명록과 동일한 쿠버네티스 클러스터에 배포한다. Beats는 데이터를 수집하고 구문분석하여 Elasticsearch에 색인화하므로, Kibana에서 동작 정보를 결과로 보며 분석할 수 있다. 이 예시는 다음과 같이 구성되어 있다.
-
-* [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 실행한 인스턴스
-* Elasticsearch와 Kibana
-* Filebeat
-* Metricbeat
-* Packetbeat
-
-## {{% heading "objectives" %}}
-
-* Redis를 이용한 PHP 방명록 시작.
-* kube-state-metrics 설치.
-* 쿠버네티스 시크릿 생성.
-* Beats 배포.
-* 로그와 메트릭의 대시보드 보기.
-
-## {{% heading "prerequisites" %}}
-
-
-{{< include "task-tutorial-prereqs.md" >}}
-{{< version-check >}}
-
-추가로 다음이 필요하다.
-
-* 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/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)를 이용한다.
-
-
-
-<!-- lessoncontent -->
-
-## Redis를 이용한 PHP 방명록 시작
-
-이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자.
-
-## 클러스터 롤 바인딩 추가
-
-[클러스터 단위 롤 바인딩](/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=<your email associated with the k8s provider account>
-```
-
-## kube-state-metrics 설치
-
-[*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다.
-
-```shell
-git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics
-kubectl apply -f kube-state-metrics/examples/standard
-```
-
-### kube-state-metrics 실행 여부 확인
-
-```shell
-kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics
-```
-
-출력
-
-```
-NAME                                 READY   STATUS    RESTARTS   AGE
-kube-state-metrics-89d656bf8-vdthm   1/1     Running     0          21s
-```
-
-## Elastic의 예제를 GitHub 리포지터리에 클론한다.
-
-```shell
-git clone https://github.com/elastic/examples.git
-```
-
-나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다.
-
-```shell
-cd examples/beats-k8s-send-anywhere
-```
-
-## 쿠버네티스 시크릿 만들기
-
-쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다.
-
-{{< note >}}
-여기에는 방식이 나뉘는데, 하나는 *자체 관리(Self managed)* 로 Elasticsearch와 Kibana(Elastic의 Helm 차트를 이용하여 사용자 서버를 구동하는)를 사용하는 경우이고 다른 경우는 Elastic Cloud의 Elasticsearch 서비스의 *관리 서비스(Managed service)* 를 사용하는 방식이다. 이 튜토리얼에서는 사용할 Elasticsearch와 Kibana 시스템의 종류에 따라 시크릿을 만들어야 한다.
-{{< /note >}}
-
-{{< tabs name="tab_with_md" >}}
-{{% tab name="자체 관리(Self Managed)" %}}
-
-### 자체 관리
-
-Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다.
-
-### 자격증명(credentials) 설정
-
-자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다.
-
-1. `ELASTICSEARCH_HOSTS`
-1. `ELASTICSEARCH_PASSWORD`
-1. `ELASTICSEARCH_USERNAME`
-1. `KIBANA_HOST`
-
-이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다.
-
-#### `ELASTICSEARCH_HOSTS`
-
-1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup).
-
-   ```
-   ["http://elasticsearch-master.default.svc.cluster.local:9200"]
-   ```
-
-1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드.
-
-   ```
-   ["http://host.docker.internal:9200"]
-   ```
-
-1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드.
-
-   ```
-   ["http://host1.example.com:9200", "http://host2.example.com:9200"]
-   ```
-
-`ELASTICSEARCH_HOSTS` 를 수정한다.
-
-```shell
-vi ELASTICSEARCH_HOSTS
-```
-
-#### `ELASTICSEARCH_PASSWORD`
-화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다.
-
-```
-<사용자시크릿암호>
-```
-
-`ELASTICSEARCH_PASSWORD` 를 수정한다.
-
-```shell
-vi ELASTICSEARCH_PASSWORD
-```
-
-#### `ELASTICSEARCH_USERNAME`
-화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다.
-
-```
-<Elasticsearch를 위한 수집 사용자 이름>
-```
-
-`ELASTICSEARCH_USERNAME` 을 수정한다.
-
-```shell
-vi ELASTICSEARCH_USERNAME
-```
-
-#### `KIBANA_HOST`
-
-1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다.
-
-   ```
-   "kibana-kibana.default.svc.cluster.local:5601"
-   ```
-
-1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스
-
-   ```
-   "host.docker.internal:5601"
-   ```
-1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드
-
-   ```
-   "host1.example.com:5601"
-   ```
-
-`KIBANA_HOST` 를 편집한다.
-
-```shell
-vi KIBANA_HOST
-```
-
-### 쿠버네티스 시크릿 만들기
-
-이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다.
-
-```shell
-kubectl create secret generic dynamic-logging \
-  --from-file=./ELASTICSEARCH_HOSTS \
-  --from-file=./ELASTICSEARCH_PASSWORD \
-  --from-file=./ELASTICSEARCH_USERNAME \
-  --from-file=./KIBANA_HOST \
-  --namespace=kube-system
-```
-
-{{% /tab %}}
-{{% tab name="관리 서비스(Managed service)" %}}
-
-## 관리 서비스
-
-이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다.
-
-### 자격증명(credentials) 설정
-
-Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다.
-
-1. `ELASTIC_CLOUD_AUTH`
-1. `ELASTIC_CLOUD_ID`
-
-디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다.
-
-#### `ELASTIC_CLOUD_ID`
-
-```
-devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ==
-```
-
-#### `ELASTIC_CLOUD_AUTH`
-
-사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다.
-
-```
-elastic:VFxJJf9Tjwer90wnfTghsn8w
-```
-
-### 필요 파일 편집하기
-
-```shell
-vi ELASTIC_CLOUD_ID
-vi ELASTIC_CLOUD_AUTH
-```
-
-### 쿠버네티스 시크릿 생성하기
-
-이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다.
-
-```shell
-kubectl create secret generic dynamic-logging \
-  --from-file=./ELASTIC_CLOUD_ID \
-  --from-file=./ELASTIC_CLOUD_AUTH \
-  --namespace=kube-system
-```
-
-{{% /tab %}}
-{{< /tabs >}}
-
-## Beats 배포하기 {#deploy-the-beats}
-
-각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다.
-
-### Filebeat에 대해
-
-Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다.
-
-아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다.
-
-```yaml
- condition.contains:
-    kubernetes.labels.app: redis
-  config:
-    - module: redis
-      log:
-        input:
-          type: docker
-          containers.ids:
-            - ${data.kubernetes.container.id}
-      slowlog:
-        enabled: true
-        var.hosts: ["${data.host}:${data.port}"]
-```
-
-이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다.
-
-### Filebeat 배포
-
-```shell
-kubectl create -f filebeat-kubernetes.yaml
-```
-
-#### 확인
-
-```shell
-kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic
-```
-
-### Metricbeat에 대해
-
-Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다.
-
-```yaml
- condition.equals:
-    kubernetes.labels.tier: backend
-  config:
-    - module: redis
-      metricsets: ["info", "keyspace"]
-      period: 10s
-
-      # Redis hosts
-      hosts: ["${data.host}:${data.port}"]
-```
-
-이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다.
-
-### Metricbeat 배포
-
-```shell
-kubectl create -f metricbeat-kubernetes.yaml
-```
-
-#### 확인
-
-```shell
-kubectl get pods -n kube-system -l k8s-app=metricbeat
-```
-
-### Packetbeat에 대해
-
-Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다.
-
-{{< note >}}
-비표준 포트로 서비스를 실행했다면 해당 포트를 `filebeat.yaml`에 적절한 유형에 추가하고, Packetbeat 데몬 셋을 삭제하고 생성한다.
-{{< /note >}}
-
-```yaml
-packetbeat.interfaces.device: any
-
-packetbeat.protocols:
- type: dns
-  ports: [53]
-  include_authorities: true
-  include_additionals: true
-
- type: http
-  ports: [80, 8000, 8080, 9200]
-
- type: mysql
-  ports: [3306]
-
- type: redis
-  ports: [6379]
-
-packetbeat.flows:
-  timeout: 30s
-  period: 10s
-```
-
-#### Packetbeat 배포하기
-
-```shell
-kubectl create -f packetbeat-kubernetes.yaml
-```
-
-#### 확인하기
-
-```shell
-kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic
-```
-
-## Kibana에서 보기
-
-브라우저에서 Kibana를 열고, **대시보드** 애플리케이션을 열어보자. 검색창에 kubernetes를 입력하고 쿠버네티스를 위한 Metricbeat 대시보드를 클릭한다. 이 대시보드에는 노드 상태, 배포 등의 보고 내용이 있다.
-
-대시보드 페이지에 Packetbeat를 검색하고 Packetbeat의 개요 페이지를 살펴보자.
-
-마찬가지로 Apache와 Redis를 위한 대시보드를 확인한다. 각 로그와 메트릭에 대한 대시보드가 표시된다. 이 Apache Metricbeat 대시보드는 비어 있다. Apache Filebeat 대시보드를 보고, 맨 아래로 스크롤하여 Apache 오류 로그를 확인한다. Apache에서 보여줄 메트릭이 없는 이유를 알려줄 것이다.
-
-Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status 구성 파일을 포함한 컨피그맵을 추가하고 방명록을 재배포하여 서버 상태를 활성화해야 한다.
-
-
-## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기
-
-기존 디플로이먼트를 확인한다.
-
-```shell
-kubectl get deployments
-```
-
-출력
-
-```
-NAME            READY   UP-TO-DATE   AVAILABLE   AGE
-frontend        3/3     3            3           3h27m
-redis-master    1/1     1            1           3h27m
-redis-slave     2/2     2            2           3h27m
-```
-
-front의 디플로이먼트를 두 개의 파드로 축소한다.
-
-```shell
-kubectl scale --replicas=2 deployment/frontend
-```
-
-출력
-
-```
-deployment.extensions/frontend scaled
-```
-
-frontend의 파드를 최대 3개의 파드로 확장한다.
-
-```shell
-kubectl scale --replicas=3 deployment/frontend
-```
-
-## Kibana에서 변화 확인하기
-
-스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다.
-![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png)
-
-## {{% heading "cleanup" %}}
-
-디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다.
-
-1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다.
-
-   ```shell
-   kubectl delete deployment -l app=redis
-   kubectl delete service -l app=redis
-   kubectl delete deployment -l app=guestbook
-   kubectl delete service -l app=guestbook
-   kubectl delete -f filebeat-kubernetes.yaml
-   kubectl delete -f metricbeat-kubernetes.yaml
-   kubectl delete -f packetbeat-kubernetes.yaml
-   kubectl delete secret dynamic-logging -n kube-system
-   ```
-
-1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다.
-
-   ```shell
-   kubectl get pods
-   ```
-
-   출력은 다음과 같아야 한다.
-
-   ```
-   No resources found.
-   ```
-
-## {{% heading "whatsnext" %}}
-
-* [리소스 모니터링 도구](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)를 공부한다.
-* [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 더 읽어본다.
-* [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다.
-* [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다.
--- a/content/ko/docs/tutorials/stateless-application/guestbook.md
+++ b/content/ko/docs/tutorials/stateless-application/guestbook.md
@ -1,26 +1,25 @@
 ---
-title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기"
+title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기"
 content_type: tutorial
 weight: 20
 card:
  name: tutorials
  weight: 30
-  title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록"
+  title: "상태를 유지하지 않는 예제: MongoDB를 사용한 PHP 방명록"
+min-kubernetes-server-version: v1.14
 ---

 <!-- overview -->
-이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다.
+이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 _(운영 준비가 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다.

-* 방명록을 저장하는 단일 인스턴스 [Redis](https://redis.io/) 마스터
-* 읽기를 제공하는 여러 개의 [복제된 Redis](https://redis.io/topics/replication) 인스턴스
+* 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/)
 * 여러 개의 웹 프론트엔드 인스턴스



 ## {{% heading "objectives" %}}

-* Redis 마스터를 시작
-* Redis 슬레이브를 시작
+* Mongo 데이터베이스를 시작
 * 방명록 프론트엔드를 시작
 * 프론트엔드 서비스를 노출하고 확인
 * 정리 하기
@ -37,24 +36,28 @@ card:

 <!-- lessoncontent -->

-## Redis 마스터를 실행하기
+## Mongo 데이터베이스를 실행

-방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. Redis 마스터 인스턴스에 데이터를 기록하고 여러 Redis 슬레이브 인스턴스에서 데이터를 읽는다.
+방명록 애플리케이션은 MongoDB를 사용해서 데이터를 저장한다.

-### Redis 마스터의 디플로이먼트를 생성하기
+### Mongo 디플로이먼트를 생성하기

-아래의 매니페스트 파일은 단일 복제본 Redis 마스터 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다.
+아래의 매니페스트 파일은 단일 복제본 Mongo 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다.

-{{< codenew file="application/guestbook/redis-master-deployment.yaml" >}}
+{{< codenew file="application/guestbook/mongo-deployment.yaml" >}}

 1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다.
-1. `redis-master-deployment.yaml` 파일을 통해 Redis 마스터의 디플로이먼트에 적용한다.
+1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다.

      ```shell
-      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+      kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
      ```
+<!--
+컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
+kubectl apply -f ./content/en/examples/application/guestbook/mongo-deployment.yaml
+-->

-1. 파드의 목록을 질의하여 Redis 마스터 파드가 실행 중인지 확인한다.
+1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다.

      ```shell
      kubectl get pods
@ -64,32 +67,32 @@ card:

      ```shell
      NAME                            READY     STATUS    RESTARTS   AGE
-      redis-master-1068406935-3lswp   1/1       Running   0          28s
+      mongo-5cfd459dd4-lrcjb          1/1       Running   0          28s
      ```

-1. Redis 마스터 파드에서 로그를 보려면 다음 명령어를 실행한다.
+2. MongoDB 파드에서 로그를 보려면 다음 명령어를 실행한다.

     ```shell
-     kubectl logs -f POD-NAME
+     kubectl logs -f deployment/mongo
     ```

-{{< note >}}
-POD-NAME을 해당 파드 이름으로 수정해야 한다.
-{{< /note >}}
+### MongoDB 서비스 생성하기

-### Redis 마스터 서비스 생성하기
+방명록 애플리케이션에서 데이터를 쓰려면 MongoDB와 통신해야 한다. MongoDB 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.

-방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다.
+{{< codenew file="application/guestbook/mongo-service.yaml" >}}

-{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
-
-1. `redis-master-service.yaml` 파일을 통해 Redis 마스터 서비스에 적용한다.
+1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다.

      ```shell
-      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+      kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
      ```
+<!--
+컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
+kubectl apply -f ./content/en/examples/application/guestbook/mongo-service.yaml
+-->

-1. 서비스의 목록을 질의하여 Redis 마스터 서비스가 실행 중인지 확인한다.
+1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다.

      ```shell
      kubectl get service
@ -100,77 +103,17 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다.
      ```shell
      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    1m
-      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP   8s
+      mongo          ClusterIP   10.0.0.151   <none>        6379/TCP   8s
      ```

 {{< note >}}
-이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `redis-master`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 Redis 마스터 파드로 라우팅한다.
+이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `mongo`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 MongoDB 파드로 라우팅한다.
 {{< /note >}}


-## Redis 슬레이브 실행하기
-
-Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추가하여 트래픽 요구 사항을 충족시킬 수 있다.
-
-### Redis 슬레이브의 디플로이먼트 생성하기
-
-디플로이먼트는 매니페스트 파일에 설정된 구성에 따라 확장된다. 이 경우, 디플로이먼트 오브젝트는 두 개의 복제본을 지정한다.
-
-실행 중인 복제본이 없으면, 이 디플로이먼트는 컨테이너 클러스터에 있는 두 개의 복제본을 시작한다. 반대로 두 개 이상의 복제본이 실행 중이면, 두 개의 복제본이 실행될 때까지 축소된다.
-
-{{< codenew file="application/guestbook/redis-slave-deployment.yaml" >}}
-
-1. `redis-slave-deployment.yaml` 파일을 통해 Redis 슬레이브의 디플로이먼트에 적용한다.
-
-      ```shell
-      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
-      ```
-
-1. 파드의 목록을 질의하여 Redis 슬레이브 파드가 실행 중인지 확인한다.
-
-      ```shell
-      kubectl get pods
-      ```
-
-      결과는 아래와 같은 형태로 나타난다.
-
-      ```shell
-      NAME                            READY     STATUS              RESTARTS   AGE
-      redis-master-1068406935-3lswp   1/1       Running             0          1m
-      redis-slave-2005841000-fpvqc    0/1       ContainerCreating   0          6s
-      redis-slave-2005841000-phfv9    0/1       ContainerCreating   0          6s
-      ```
-
-### Redis 슬레이브 서비스 생성하기
-
-방명록 애플리케이션은 Redis 슬레이브와 통신하여 데이터를 읽는다. Redis 슬레이브를 확인할 수 있도록 하기 위해 서비스를 설정해야 한다. 서비스는 파드 집합에 투명한 로드 밸런싱을 제공한다.
-
-{{< codenew file="application/guestbook/redis-slave-service.yaml" >}}
-
-1. `redis-slave-service.yaml` 파일을 통해 Redis 슬레이브 서비스에 적용한다.
-
-      ```shell
-      kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
-      ```
-
-1. 서비스의 목록을 질의하여 Redis 슬레이브 서비스가 실행 중인지 확인한다.
-
-      ```shell
-      kubectl get services
-      ```
-
-      결과는 아래와 같은 형태로 나타난다.
-
-      ```
-      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
-      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP    2m
-      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP   1m
-      redis-slave    ClusterIP   10.0.0.223   <none>        6379/TCP   6s
-      ```
-
 ## 방명록 프론트엔드를 설정하고 노출하기

-방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 쓰기 요청을 위한 `redis-master` 서비스와 읽기 요청을 위한 `redis-slave` 서비스에 연결하도록 설정된다.
+방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 방명록 항목들을 저장하기 위해 `mongo` 서비스에 연결하도록 구성 한다.

 ### 방명록 프론트엔드의 디플로이먼트 생성하기

@ -182,6 +125,11 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추
      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
      ```

+<!--
+컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
+kubectl apply -f ./content/en/examples/application/guestbook/frontend-deployment.yaml
+-->
+
 1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다.

      ```shell
@ -199,12 +147,12 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추

 ### 프론트엔드 서비스 생성하기

-서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.
+서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 `mongo` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다.

-게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다.
+게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 사용하더라도 `kubectl port-forward`를 사용해서 서비스에 접근할 수 있다.

 {{< note >}}
-Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : NodePort`를 삭제하거나 주석 처리하고 `type : LoadBalancer`의 주석을 제거해야 한다.
+Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다.
 {{< /note >}}

 {{< codenew file="application/guestbook/frontend-service.yaml" >}}
@ -215,6 +163,11 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
      kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
      ```

+<!--
+컨텐츠에 대한 로컬 테스트는 파일의 상대경로로 한다.
+kubectl apply -f ./content/en/examples/application/guestbook/frontend-service.yaml
+-->
+
 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다.

      ```shell
@ -225,29 +178,27 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우

      ```
      NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
-      frontend       NodePort    10.0.0.112   <none>       80:31323/TCP   6s
+      frontend       ClusterIP   10.0.0.112   <none>       80/TCP   6s
      kubernetes     ClusterIP   10.0.0.1     <none>        443/TCP        4m
-      redis-master   ClusterIP   10.0.0.151   <none>        6379/TCP       2m
-      redis-slave    ClusterIP   10.0.0.223   <none>        6379/TCP       1m
+      mongo          ClusterIP   10.0.0.151   <none>        6379/TCP       2m
      ```

-### `NodePort`를 통해 프론트엔드 서비스 확인하기
+### `kubectl port-forward`를 통해 프론트엔드 서비스 확인하기

-애플리케이션을 Minikube 또는 로컬 클러스터에 배포한 경우, 방명록을 보려면 IP 주소를 찾아야 한다.
-
-1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다.
+1. 다음 명령어를 실행해서 로컬 머신의 `8080` 포트를 서비스의 `80` 포트로 전달한다.

      ```shell
-      minikube service frontend --url
+      kubectl port-forward svc/frontend 8080:80
      ```

      결과는 아래와 같은 형태로 나타난다.

      ```
-      http://192.168.99.100:31323
+      Forwarding from 127.0.0.1:8080 -> 80
+      Forwarding from [::1]:8080 -> 80
      ```

-1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다.
+1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다.

 ### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기

@ -270,7 +221,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우

 ## 웹 프론트엔드 확장하기

-서버가 디플로이먼트 컨트롤러를 사용하는 서비스로 정의되어 있기 때문에 확장 또는 축소가 쉽다.
+서버가 디플로이먼트 컨르롤러를 사용하는 서비스로 정의되어 있기에 필요에 따라 확장 또는 축소할 수 있다.

 1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다.

@ -293,9 +244,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
      frontend-3823415956-k22zn       1/1       Running   0          54m
      frontend-3823415956-w9gbt       1/1       Running   0          54m
      frontend-3823415956-x2pld       1/1       Running   0          5s
-      redis-master-1068406935-3lswp   1/1       Running   0          56m
-      redis-slave-2005841000-fpvqc    1/1       Running   0          55m
-      redis-slave-2005841000-phfv9    1/1       Running   0          55m
+      mongo-1068406935-3lswp   1/1       Running   0          56m
      ```

 1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다.
@ -316,9 +265,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
      NAME                            READY     STATUS    RESTARTS   AGE
      frontend-3823415956-k22zn       1/1       Running   0          1h
      frontend-3823415956-w9gbt       1/1       Running   0          1h
-      redis-master-1068406935-3lswp   1/1       Running   0          1h
-      redis-slave-2005841000-fpvqc    1/1       Running   0          1h
-      redis-slave-2005841000-phfv9    1/1       Running   0          1h
+      mongo-1068406935-3lswp   1/1       Running   0          1h
      ```


@ -330,19 +277,18 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우
 1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다.

      ```shell
-      kubectl delete deployment -l app=redis
-      kubectl delete service -l app=redis
-      kubectl delete deployment -l app=guestbook
-      kubectl delete service -l app=guestbook
+      kubectl delete deployment -l app.kubernetes.io/name=mongo
+      kubectl delete service -l app.kubernetes.io/name=mongo
+      kubectl delete deployment -l app.kubernetes.io/name=guestbook
+      kubectl delete service -l app.kubernetes.io/name=guestbook
      ```

      결과는 아래와 같은 형태로 나타난다.

      ```
-      deployment.apps "redis-master" deleted
-      deployment.apps "redis-slave" deleted
-      service "redis-master" deleted
-      service "redis-slave" deleted
+      deployment.apps "mongo" deleted
+      service "mongo" deleted
+      deployment.apps "frontend" deleted
      deployment.apps "frontend" deleted    
      service "frontend" deleted
      ```
@ -363,7 +309,6 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우

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

-* [ELK 로깅과 모니터링](/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기
 * [쿠버네티스 기초](/ko/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료
 * [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기
 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기
--- a/content/ko/examples/application/guestbook/frontend-deployment.yaml
+++ b/content/ko/examples/application/guestbook/frontend-deployment.yaml
@ -3,22 +3,24 @@ kind: Deployment
 metadata:
  name: frontend
  labels:
-    app: guestbook
+    app.kubernetes.io/name: guestbook
+    app.kubernetes.io/component: frontend
 spec:
  selector:
    matchLabels:
-      app: guestbook
-      tier: frontend
+      app.kubernetes.io/name: guestbook
+      app.kubernetes.io/component: frontend
  replicas: 3
  template:
    metadata:
      labels:
-        app: guestbook
-        tier: frontend
+        app.kubernetes.io/name: guestbook
+        app.kubernetes.io/component: frontend
    spec:
      containers:
-      - name: php-redis
-        image: gcr.io/google-samples/gb-frontend:v4
+      - name: guestbook
+        image: paulczar/gb-frontend:v5
+        # image: gcr.io/google-samples/gb-frontend:v4
        resources:
          requests:
            cpu: 100m
@ -26,13 +28,5 @@ spec:
        env:
        - name: GET_HOSTS_FROM
          value: dns
-          # Using `GET_HOSTS_FROM=dns` requires your cluster to
-          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
-          # service launched automatically. However, if the cluster you are using
-          # does not have a built-in DNS service, you can instead
-          # access an environment variable to find the master
-          # service's host. To do so, comment out the 'value: dns' line above, and
-          # uncomment the line below:
-          # value: env
        ports:
        - containerPort: 80
--- a/content/ko/examples/application/guestbook/frontend-service.yaml
+++ b/content/ko/examples/application/guestbook/frontend-service.yaml
@ -3,16 +3,14 @@ kind: Service
 metadata:
  name: frontend
  labels:
-    app: guestbook
-    tier: frontend
+    app.kubernetes.io/name: guestbook
+    app.kubernetes.io/component: frontend
 spec:
-  # comment or delete the following line if you want to use a LoadBalancer
-  type: NodePort 
  # if your cluster supports it, uncomment the following to automatically create
  # an external load-balanced IP for the frontend service.
  # type: LoadBalancer
  ports:
  - port: 80
  selector:
-    app: guestbook
-    tier: frontend
+    app.kubernetes.io/name: guestbook
+    app.kubernetes.io/component: frontend
--- a/content/ko/examples/application/guestbook/mongo-deployment.yaml
+++ b/content/ko/examples/application/guestbook/mongo-deployment.yaml
@ -0,0 +1,31 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: mongo
+  labels:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
+spec:
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: mongo
+      app.kubernetes.io/component: backend
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app.kubernetes.io/name: mongo
+        app.kubernetes.io/component: backend
+    spec:
+      containers:
+      - name: mongo
+        image: mongo:4.2
+        args:
+          - --bind_ip
+          - 0.0.0.0
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        ports:
+        - containerPort: 27017
--- a/content/ko/examples/application/guestbook/mongo-service.yaml
+++ b/content/ko/examples/application/guestbook/mongo-service.yaml
@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: mongo
+  labels:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
+spec:
+  ports:
+  - port: 27017
+    targetPort: 27017
+  selector:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
--- a/content/ko/examples/application/guestbook/redis-master-deployment.yaml
+++ b/content/ko/examples/application/guestbook/redis-master-deployment.yaml
@ -1,29 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: redis-master
-  labels:
-    app: redis
-spec:
-  selector:
-    matchLabels:
-      app: redis
-      role: master
-      tier: backend
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        app: redis
-        role: master
-        tier: backend
-    spec:
-      containers:
-      - name: master
-        image: k8s.gcr.io/redis:e2e  # or just image: redis
-        resources:
-          requests:
-            cpu: 100m
-            memory: 100Mi
-        ports:
-        - containerPort: 6379
--- a/content/ko/examples/application/guestbook/redis-master-service.yaml
+++ b/content/ko/examples/application/guestbook/redis-master-service.yaml
@ -1,17 +0,0 @@
-apiVersion: v1
-kind: Service
-metadata:
-  name: redis-master
-  labels:
-    app: redis
-    role: master
-    tier: backend
-spec:
-  ports:
-  - name: redis
-    port: 6379
-    targetPort: 6379
-  selector:
-    app: redis
-    role: master
-    tier: backend
--- a/content/ko/examples/application/guestbook/redis-slave-deployment.yaml
+++ b/content/ko/examples/application/guestbook/redis-slave-deployment.yaml
@ -1,40 +0,0 @@
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: redis-slave
-  labels:
-    app: redis
-spec:
-  selector:
-    matchLabels:
-      app: redis
-      role: slave
-      tier: backend
-  replicas: 2
-  template:
-    metadata:
-      labels:
-        app: redis
-        role: slave
-        tier: backend
-    spec:
-      containers:
-      - name: slave
-        image: gcr.io/google_samples/gb-redisslave:v3
-        resources:
-          requests:
-            cpu: 100m
-            memory: 100Mi
-        env:
-        - name: GET_HOSTS_FROM
-          value: dns
-          # Using `GET_HOSTS_FROM=dns` requires your cluster to
-          # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
-          # service launched automatically. However, if the cluster you are using
-          # does not have a built-in DNS service, you can instead
-          # access an environment variable to find the master
-          # service's host. To do so, comment out the 'value: dns' line above, and
-          # uncomment the line below:
-          # value: env
-        ports:
-        - containerPort: 6379
--- a/content/ko/examples/application/guestbook/redis-slave-service.yaml
+++ b/content/ko/examples/application/guestbook/redis-slave-service.yaml
@ -1,15 +0,0 @@
-apiVersion: v1
-kind: Service
-metadata:
-  name: redis-slave
-  labels:
-    app: redis
-    role: slave
-    tier: backend
-spec:
-  ports:
-  - port: 6379
-  selector:
-    app: redis
-    role: slave
-    tier: backend