First Korean I10n work for release-1.14 (#13730)

* First Korean I10n work for release-1.14

- ko: Fix nav-menu sync in tutorials/statefulset #13374 (#13474)
- ko: add outdated files in dev-1.14-ko.1 branch (#13473)
- Translate title of concepts/../image.md Ko (#13507)
- ko: add translation tutorial/stateful-application/cassandra #12450 (#13515)
- Translate reference/kubectl/cheatsheet in Korean (#13549)
- Translate tasks/access-application-cluster/access-cluster in Korean (#13565)
- ko: add tutorials/stateful-application/mysql-wordpress-persistent-vol… (#13516)
- Issue 12838 object management kubectl imperative config (#13657)
- Translate standardized glossary Tag Fandamental in Korean (#13552)

Co-authored-by:    Kim Young Dae <[email protected]>

Co-authored-by:    Yoon <[email protected]>

Co-authored-by:    lapee79 <[email protected]>

Co-authored-by:    Jesang Myung <[email protected]>

Co-authored-by:    Seokho <[email protected]>

Co-authored-by:    Claudia J.Kang <[email protected]>

Co-authored-by:    June Yi <[email protected]>

* Fix conflict : pick-right-solution

Author: claudiajkang

content/ko/_index.html

@@ -8,7 +8,7 @@
 
 {{< blocks/section id="oceanNodes" >}}
 {{% blocks/feature image="flower" %}}
-### [쿠버네티스 (k8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
+### [쿠버네티스 (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
 
 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}

content/ko/case-studies/pinterest/index.html

@@ -26,28 +26,27 @@ <h1> CASE STUDY:<img src="/images/pinterest_logo.png" style="margin-bottom:-1%"
 <section class="section1">
 <div class="cols">
   <div class="col1">
+<br><br>
     <h2>Challenge</h2>
     After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.
 
-<br>
+<br><br>
 
  <h2>Solution</h2>
     The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
 
-</div>
-
-<div class="col2">
+<br><br>
 
 <h2>Impact</h2>
   "By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."
 
-
 </div>
-
 </div>
+
 </section>
-<div class="banner2">
-  <div class="banner2text">
+<div class="banner2" style="text-align:center">
+    <iframe width="500" height="260" src="https://www.youtube.com/embed/I36NNJH1xQY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
+    <div class="banner2text"><br><br>
 "So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we&nbsp;were&nbsp;pushing&nbsp;for." <span style="font-size:14px;letter-spacing:0.12em;padding-top:20px;text-transform:uppercase;line-height:14px"><br><br>— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest</span>
 
   </div>

content/ko/docs/concepts/architecture/cloud-controller.md

@@ -255,6 +255,7 @@ rules:
 * [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
 * [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
 * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
+* [Linode](https://github.com/linode/linode-cloud-controller-manager)
 
 ## 클러스터 관리
 

content/ko/docs/concepts/cluster-administration/federation.md

@@ -6,7 +6,9 @@ weight: 80
 
 {{% capture overview %}}
 
-{{< include "federation-current-state.md" >}}
+{{< deprecationfilewarning >}}
+{{< include "federation-deprecation-warning-note.md" >}}
+{{< /deprecationfilewarning >}}
 
 이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을 
 설명한다.

content/ko/docs/concepts/containers/images.md

@@ -1,5 +1,5 @@
 ---
-title: Images
+title: 이미지
 content_template: templates/concept
 weight: 10
 ---

content/ko/docs/concepts/overview/components.md

@@ -77,7 +77,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 ### 컨테이너 런타임
 
 컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. 
-쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)를 구현한 모든 런타임이다.
+쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다.
 
 ## 애드온
 

content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md

@@ -0,0 +1,143 @@
+---
+title: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리
+content_template: templates/concept
+weight: 30
+---
+
+{{% capture overview %}}
+쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성파일과 함께 `kubectl`
+커맨드 라인 툴을 이용하여 생성, 업데이트 및 삭제할 수 있다.
+이 문서는 구성파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다.
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 트레이드 오프
+
+`kubectl` 툴은 3가지 종류의 오브젝트 관리를 지원한다.
+
+* 명령형 커맨드
+* 명령형 오브젝트 구성
+* 선언형 오브젝트 구성
+
+각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는
+[쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/)를 참고한다.
+
+## 오브젝트 생성 방법
+
+구성파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다.
+보다 상세한 정보는 [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
+참조한다.
+
+- `kubectl create -f <파일명|url>`
+
+## 오브젝트 업데이트 방법
+
+{{< warning >}}
+`replace` 커맨드로 오브젝트를 업데이트 하게되면,
+구성파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는
+`externalIPs`필드가 구성파일로부터 독립적으로 관리되는
+`LoadBalancer`타입의 서비스와 같이, 클러스터 의해 부분적으로
+관리되는 스펙의 오브젝트와 함께 사용되어서는 안된다.
+독립적으로 관리되는 필드는 `replace`로 삭제되는 것을 방지하기 위해
+구성파일에 복사되어져야만 한다.
+{{< /warning >}}
+
+구성파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f`
+를 사용할 수 있다.
+
+- `kubectl replace -f <파일명|url>`
+
+## 오브젝트 삭제 방법
+
+구성파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를
+사용할 수 있다.
+
+- `kubectl delete -f <파일명|url>`
+
+## 오브젝트 삭제 방법
+
+구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f`
+명령을 사용할 수 있다.
+
+- `kubectl get -f <파일명|url> -o yaml`
+
+`-o yaml` 플래그는 전체 오브젝트 구성이 출력되도록 정의한다. 옵션의 리스트를 확인하기
+위해서는 `kubectl get -h`를 사용한다.
+
+## 제약사항
+
+`create`, `replace`, 그리고 `delete` 명령은 각 오브젝트의 구성이
+그 구성파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다.
+그러나 활성 오브젝트가 업데이트 되고, 구성파일 안에 병합되지 않으면,
+업데이트 내용은 다음번 `replace`가 실행될 때 삭제될 것이다.
+이는 HorizontalPodAutoscaler와 같은 컨트롤러가
+활성 오브젝트를 직접적으로 업데이트하도록 할 경우 발생한다.
+여기 예시가 있다.
+
+1. 구성파일로부터 오브젝트를 생성할 경우
+1. 또 다른 소스가 일부 필드를 변경함으로써 오브젝트가 업데이트 되는 경우
+1. 구성파일로부터 오브젝트를 대체할 경우. 스텝 2에서의
+다른 소스에 의해 이루어진 변경은 유실된다.
+
+동일 오브젝트에 대해 여러 명의 작성자들로부터의 지원이 필요한 경우, 오브젝트를 관리하기 위해
+`kubectl apply`를 사용할 수 있다.
+
+## 구성 저장 없이 URL로부터 오브젝트 생성과 편집하기
+
+구성파일에 대한 URL을 가진다고 가정해보자.
+`kubectl create --edit`을 사용하여 오브젝트가 생성되기 전에
+구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을
+가르키는 튜토리얼과 작업에 특히 유용하다.
+
+```sh
+kubectl create -f <url> --edit
+```
+
+## 명령형 커맨드에서 명령형 오브젝트 구성으로 전환하기
+
+령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 위해
+몇 가지 수동 단계를 포함한다.
+
+1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다.
+```sh
+kubectl get <종류>/<이름> -o yaml --export > <종류>_<이름>.yaml
+```
+
+1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다.
+
+1. 이후 오브젝트 관리를 위해, `replace`만 사용한다.
+```sh
+kubectl replace -f <종류>_<이름>.yaml
+```
+
+
+## 컨트롤러 셀렉터와 PodTemplate 레이블 삭제하기
+
+{{< warning >}}
+컨트롤러에서 셀렉터를 업데이트하지 않도록 강력하게 권고한다.
+{{< /warning >}}
+
+권고되는 접근방법은 다른 의미론적 의미가 없는 컨트롤러 셀렉터의 의해서만
+사용되는 단일, 불변의 PodTemplate 레이블로 정의하는 것이다.
+
+레이블 예시:
+
+```yaml
+selector:
+  matchLabels:
+      controller-selector: "extensions/v1beta1/deployment/nginx"
+template:
+  metadata:
+    labels:
+      controller-selector: "extensions/v1beta1/deployment/nginx"
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/)
+- [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
+- [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/)
+- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
+{{% /capture %}}

content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -41,11 +41,11 @@ card:
 
 {{< codenew file="application/deployment.yaml" >}}
 
-위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create) 명령을 이용하는 것이다. 다음 예시와 같다.
+위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 명령을 이용하는 것이다. 다음 예시와 같다.
 
 
 ```shell
-$ kubectl create -f https://k8s.io/examples/application/deployment.yaml --record
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record
 ```
 
 그 출력 내용은 다음과 유사하다.

content/ko/docs/concepts/overview/working-with-objects/namespaces.md

@@ -41,7 +41,9 @@ weight: 30
 사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다.
 
 ```shell
-$ kubectl get namespaces
+kubectl get namespaces
+```
+```
 NAME          STATUS    AGE
 default       Active    1d
 kube-system   Active    1d

content/ko/docs/concepts/workloads/pods/init-containers.md

@@ -106,19 +106,19 @@ metadata:
     pod.beta.kubernetes.io/init-containers: '[
         {
             "name": "init-myservice",
-            "image": "busybox",
+            "image": "busybox:1.28",
             "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"]
         },
         {
             "name": "init-mydb",
-            "image": "busybox",
+            "image": "busybox:1.28",
             "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"]
         }
     ]'
 spec:
   containers:
   - name: myapp-container
-    image: busybox
+    image: busybox:1.28
     command: ['sh', '-c', 'echo The app is running! && sleep 3600']
 ```
 
@@ -135,14 +135,14 @@ metadata:
 spec:
   containers:
   - name: myapp-container
-    image: busybox
+    image: busybox:1.28
     command: ['sh', '-c', 'echo The app is running! && sleep 3600']
   initContainers:
   - name: init-myservice
-    image: busybox
+    image: busybox:1.28
     command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
   - name: init-mydb
-    image: busybox
+    image: busybox:1.28
     command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
 ```
 
@@ -176,12 +176,24 @@ spec:
 다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다.
 
 ```shell
-$ kubectl create -f myapp.yaml
+kubectl apply -f myapp.yaml
+```
+```
 pod/myapp-pod created
-$ kubectl get -f myapp.yaml
+```
+
+```shell
+kubectl get -f myapp.yaml
+```
+```
 NAME        READY     STATUS     RESTARTS   AGE
 myapp-pod   0/1       Init:0/2   0          6m
-$ kubectl describe -f myapp.yaml
+```
+
+```shell
+kubectl describe -f myapp.yaml
+```
+```
 Name:          myapp-pod
 Namespace:     default
 [...]
@@ -214,18 +226,25 @@ Events:
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
   13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634
-$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container
-$ kubectl logs myapp-pod -c init-mydb      # Inspect the second init container
+```
+```shell
+kubectl logs myapp-pod -c init-myservice # Inspect the first init container
+kubectl logs myapp-pod -c init-mydb      # Inspect the second init container
 ```
 
 `mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 
 `myapp-pod`가 생성된 것을 볼 수 있다.
 
 ```shell
-$ kubectl create -f services.yaml
+kubectl apply -f services.yaml
+```
+```
 service/myservice created
 service/mydb created
-$ kubectl get -f myapp.yaml
+```
+
+```shell
+kubectl get -f myapp.yaml
 NAME        READY     STATUS    RESTARTS   AGE
 myapp-pod   1/1       Running   0          9m
 ```