Third Korean L10n Work For Release 1.17 (#18915)

* Changed some words in the IPv4/IPv6 dual-stack korean doc. (#18668) * Update to Outdated files in dev-1.17-ko.3 branch. (#18580) * Translate content/ko/docs/concepts/services-networking/service in Korean (#18195) * Translate docs/tasks/access-application-cluster/port-forward-access-application-cluster.md in Korean (#18721) * Translate controllers/garbage-collection.md in Korean. (#18595) Co-Authored-by: Seokho Son <shsongist@gmail.com> Co-Authored-by: Lawrence Kay <lkay9495@hotmail.com> Co-Authored-by: Jesang Myung <jesang.myung@gmail.com> Co-Authored-by: Claudia J.Kang <claudiajkang@gmail.com> Co-Authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: Seokho Son <shsongist@gmail.com> Co-authored-by: Lawrence Kay <me@lkaybob.pe.kr> Co-authored-by: Jesang Myung <jesang.myung@gmail.com> Co-authored-by: June Yi <june.yi@samsung.com>
2020-01-30 23:34:13 +09:00
parent ce0963fbfc
commit f5e63a268c
11 changed files with 1570 additions and 13 deletions
@@ -334,7 +334,7 @@ NAME                               READY     STATUS    RESTARTS   AGE
 curl-deployment-1515033274-1410r   1/1       Running   0          1m
 ```
 ```shell
-kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/nginx.crt
+kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
 ...
 <title>Welcome to nginx!</title>
 ...
@@ -28,7 +28,7 @@ weight: 70
   * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당)
   * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.)
   * Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6)
-   * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 송신 라우팅(예: 인터넷)
+   * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷)

 ## 필수 구성 요소

@@ -62,7 +62,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요
 ## 서비스

 만약 클러스터 IPv4/IPv6 이중 스택 네트워킹을 활성화한 경우, IPv4 또는 IPv6 주소로 {{< glossary_tooltip text="서비스" term_id="service" >}} 를 만들 수 있다. 해당 서비스에서 `.spec.ipFamily` 필드를 설정하면, 서비스 클러스터 IP의 주소 패밀리를 선택할 수 있다.
-새 서비스를 생성할 때만 이 필드를 설정할 수 있다. `.spec.ipFamily` 필드는 선택 사항이며 클러스터에서 {{< glossary_tooltip text="서비스" term_id="service" >}} 와 {{< glossary_tooltip text="인그레스" term_id="ingress" >}} 를 IPv4와 IPv6로 사용하도록 설정할 경우에만 사용해야 한다. 이 필드의 구성은 [송신](#송신-트래픽)에 대한 요구사항이 아니다.
+새 서비스를 생성할 때만 이 필드를 설정할 수 있다. `.spec.ipFamily` 필드는 선택 사항이며 클러스터에서 {{< glossary_tooltip text="서비스" term_id="service" >}} 와 {{< glossary_tooltip text="인그레스" term_id="ingress" >}} 를 IPv4와 IPv6로 사용하도록 설정할 경우에만 사용해야 한다. 이 필드의 구성은 [이그레스](#이그레스-트래픽)에 대한 요구사항이 아니다.

 {{< note >}}
 클러스터의 기본 주소 패밀리는 `--service-cluster-ip-range` 플래그로 kube-controller-manager에 구성된 첫 번째 서비스 클러스터 IP 범위의 주소 패밀리이다.
@@ -89,9 +89,9 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요

 IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급자들은 `type` 필드를 `LoadBalancer` 로 설정하고, 추가적으로 `ipFamily` 필드를 `IPv6` 로 설정하면 서비스에 대한 클라우드 로드 밸런서가 구축된다.

-## 송신 트래픽
+## 이그레스 트래픽

-근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 송신 트래픽과 모든 응답을 위한 위장 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 위장 IP에 ip-masq-agent 를 사용할 수 있다.
+근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent 를 사용할 수 있다.

 ## 알려진 이슈들

@@ -17,6 +17,11 @@ _크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads
 모든 **크론잡** `일정:` 시간은 잡이 처음 시작된 마스터의 시간대를 기반으로 한다.
 {{< /note >}}

+크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이
+52자 이하인지 확인해야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에
+11자를 자동으로 추가하고, 작업 이름의 최대 길이는
+63자라는 제약 조건이 있기 때문이다.
+
 크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다.

 {{% /capture %}}
@@ -0,0 +1,182 @@
+---
+title: 가비지(Garbage) 수집
+content_template: templates/concept
+weight: 60
+---
+
+{{% capture overview %}}
+
+쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
+소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
+
+{{% /capture %}}
+
+
+{{% capture body %}}
+
+## 소유자(owner)와 종속(dependent)
+
+일부 쿠버네티스 오브젝트는 다른 오브젝트의 소유자이다. 예를 들어 레플리카셋은
+파드 집합의 소유자이다. 소유자 오브젝트에게 소유된 오브젝트를 *종속*
+이라고 한다. 모든 종속 오브젝트는 소유하는 오브젝트를 가르키는 `metadata.ownerReferences`
+필드를 가지고 있다.
+
+때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다.
+예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 
+`ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가
+레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡
+그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을
+자동으로 설정한다.
+
+또한 `ownerReference` 필드를 수동으로 설정해서 소유자와 종속 항목 간의
+관계를 지정할 수도 있다.
+
+여기에 파드 3개가 있는 레플리카셋의 구성 파일이 있다.
+
+{{< codenew file="controllers/replicaset.yaml" >}}
+
+레플리카셋을 생성하고 파드의 메타데이터를 본다면, 
+OwnerReferences 필드를 찾을 수 있다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
+kubectl get pods --output=yaml
+```
+
+출력 결과는 파드의 소유자가 `my-repset` 이라는 이름의 레플리카셋인 것을 보여준다.
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  ...
+  ownerReferences:
+  - apiVersion: apps/v1
+    controller: true
+    blockOwnerDeletion: true
+    kind: ReplicaSet
+    name: my-repset
+    uid: d9607e19-f88f-11e6-a518-42010a800195
+  ...
+```
+
+{{< note >}}
+교차 네임스페이스(cross-namespace)의 소유자 참조는 디자인상 허용되지 않는다. 이는 다음을 의미한다.
+1) 네임스페이스 범위의 종속 항목은 동일한 네임스페이스의 소유자와
+클러스터 범위의 소유자만 지정할 수 있다.
+2) 클러스터 범위의 종속 항목은 클러스터 범위의 소유자만 지정할 수 있으며,
+네임스페이스 범위의 소유자는 불가하다.
+{{< /note >}}
+
+## 가비지 수집기의 종속 항목 삭제 방식 제어
+
+오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의
+여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading)
+삭제* 라고 한다.  *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다.
+
+만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면,
+종속 항목은 *분리됨(orphaned)* 이라고 한다.
+
+### 포어그라운드 캐스케이딩 삭제
+
+*포어그라운드 캐스케이딩 삭제* 에서는 루트 오브젝트가 먼저
+"삭제 중(deletion in progress)" 상태가 된다. "삭제 중" 상태에서는
+다음 사항이 적용된다.
+
+ * 오브젝트는 REST API를 통해 여전히 볼 수 있음
+ * 오브젝트에 `deletionTimestamp` 가 설정됨
+ * 오브젝트의 "foregroundDeletion"에 `metadata.finalizers` 값이 포함됨.
+
+"삭제 중" 상태가 설정되면, 가비지
+수집기는 오브젝트의 종속 항목을 삭제한다. 가비지 수집기는 모든
+"차단" 종속 항목(`ownerReference.blockOwnerDeletion=true` 가 있는 오브젝트)의 삭제가 완료되면,
+소유자 오브젝트를 삭제한다.
+
+"foregroundDeletion" 에서는 ownerReference.blockOwnerDeletion=true 로
+설정된 종속 항목만 소유자 오브젝트의 삭제를 차단한다는 것을 참고한다.
+쿠버네티스 버전 1.7에서는 소유자 오브젝트에 대한 삭제 권한에 따라 `blockOwnerDeletion` 를 true로 설정하기 위해 사용자 접근을 제어하는
+[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement)가
+추가되었기에 권한이 없는 종속 항목은 소유자 오브젝트의 삭제를 지연시킬 수 없다.
+
+만약 오브젝트의 `ownerReferences` 필드가 컨트롤러(디플로이먼트 또는 레플리카셋과 같은)에
+의해 설정된 경우 blockOwnerDeletion이 자동으로 설정되므로 이 필드를 수동으로 수정할 필요가 없다.
+
+### 백그라운드 캐스케이딩 삭제
+
+*백그라운드 캐스케이딩 삭제* 에서 쿠버네티스는 소유자 오브젝트를
+즉시 삭제하고, 가비지 수집기는 백그라운드에서 종속 항목을
+삭제한다.
+
+### 캐스케이딩 삭제 정책 설정하기
+
+캐스케이딩 삭제 정책을 제어하려면, 오브젝트를 삭제할 때 `deleteOptions`
+인수를 `propagationPolicy` 필드에 설정한다. 여기에 가능한 값으로는 "Orphan",
+"Foreground" 또는 "Background" 이다.
+
+쿠버네티스 1.9 이전에는 많은 컨트롤러의 리소스에 대한 기본 가비지 수집 정책이 `orphan` 이었다.
+여기에는 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋 그리고
+디플로이먼트가 포함된다. 그룹 버전 `extensions/v1beta1`, `apps/v1beta1` 그리고 `apps/v1beta2` 의 kinds에서는
+달리 지정하지 않는 한 오브젝트가 분리되는 것이 기본이다. 쿠버네티스 1.9에서는 그룹 버전 `apps/v1` 의 모든 kinds에 해당하는
+종속 오브젝트들이 기본적으로 삭제된다.
+
+여기에 백그라운드에서 종속 항목을 삭제하는 예시가 있다.
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
+  -H "Content-Type: application/json"
+```
+
+여기에 포어그라운드에서 종속 항목을 삭제하는 예시가 있다.
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
+  -H "Content-Type: application/json"
+```
+
+여기에 종속 항목을 분리됨으로 하는 예시가 있다.
+
+```shell
+kubectl proxy --port=8080
+curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
+  -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
+  -H "Content-Type: application/json"
+```
+
+kubectl도 캐스케이딩 삭제를 지원한다.
+kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다.  종속 항목을
+분리하기 위해서는 `--cascase` 를 false로 설정한다. `--cascade` 의 기본값은
+true 이다.
+
+여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다.
+
+```shell
+kubectl delete replicaset my-repset --cascade=false
+```
+
+### 디플로이먼트에 대한 추가 참고
+
+1.7 이전에서는 디플로이먼트와 캐스케이딩 삭제를 사용하면 반드시 `propagationPolicy: Foreground`
+를 사용해서 생성된 레플리카셋 뿐만 아니라 해당 파드도 삭제해야 한다. 만약 이 _propagationPolicy_
+유형을 사용하지 않는다면, 레플리카셋만 삭제되고 파드는 분리된 상태로 남을 것이다.
+더 많은 정보는 [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)를 본다.
+
+## 알려진 이슈들
+
+[#26120](https://github.com/kubernetes/kubernetes/issues/26120)을 추적한다.
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+
+[디자인 문서 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
+
+[디자인 문서 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
+
+{{% /capture %}}
+
+
@@ -26,7 +26,7 @@ card:

 * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다.
 * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.
-[쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다.
+[쿠버네티스 블로그](https://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다.

  * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)
  * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns)
@@ -2,7 +2,7 @@
 title: 커스텀 리소스 데피니션(CustomResourceDefinition)
 id: CustomResourceDefinition
 date: 2018-04-12
-full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
+full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/
 short_description: >
  사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드.

@@ -82,7 +82,7 @@ kubectl config unset users.foo                       # foo 사용자 삭제

 ## 오브젝트 생성

-쿠버네티스 매니페스트는 json이나 yaml로 정의된다. 파일 확장자는 `.yaml`
+쿠버네티스 매니페스트는 JSON이나 YAML로 정의된다. 파일 확장자는 `.yaml`
 , `.yml`, `.json` 이 사용된다.

 ```bash
@@ -203,6 +203,7 @@ kubectl rollout history deployment/frontend                      # 현 리비전
 kubectl rollout undo deployment/frontend                         # 이전 디플로이먼트로 롤백
 kubectl rollout undo deployment/frontend --to-revision=2         # 특정 리비전으로 롤백
 kubectl rollout status -w deployment/frontend                    # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시
+kubectl rollout restart deployment/frontend                      # "frontend" 디플로이먼트의 롤링 재시작


 # 버전 1.11 부터 사용 중단
@@ -330,7 +331,7 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든

 ### 출력 형식 지정

-특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가하면 된다.
+특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 `kubectl` 명령에 `-o` (또는 `--output`) 플래그를 추가한다.

 출력 형식       | 세부 사항
 --------------| -----------
@@ -43,7 +43,6 @@ card:
 |                     | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) |
 |                     | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)|
 |                     | [k3s](https://k3s.io)|
-|                     | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)|


 ## 운영 환경
@@ -77,11 +76,10 @@ card:
 | [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html)            |        |  |      |     |  | &#x2714;
 | [DigitalOcean](https://www.digitalocean.com/products/kubernetes/)        | &#x2714;      |  |      |     |            |
 | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) |       |&#x2714;  | &#x2714;     |  |     | &#x2714;
-| [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)     |      |  |      | |    &#x2714;       | &#x2714;
-| [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)     |      |  |      | |           | &#x2714;
 | [Gardener](https://gardener.cloud/) | &#x2714; | &#x2714; | &#x2714; | &#x2714; | &#x2714; | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
 | [Giant Swarm](https://www.giantswarm.io/)     | &#x2714;       | &#x2714; |   &#x2714;    |     |
 | [Google](https://cloud.google.com/)           |  [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/)       | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/)       |  |  |     |  |      |       |  |
+| [Hidora](https:/hidora.com/)           |  &#x2714;       | &#x2714;| &#x2714;       |  |  |     |  |      |       |  |
 | [IBM](https://www.ibm.com/in-en/cloud)        | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | |
 | [Ionos](https://www.ionos.com/enterprise-cloud)        | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | |
 | [Kontena Pharos](https://www.kontena.io/pharos/)          |    |&#x2714;|    &#x2714;    |        |         |
@@ -92,6 +90,7 @@ card:
 | [Kublr](https://kublr.com/)        |&#x2714; | &#x2714;  |&#x2714;       |&#x2714;  |&#x2714; |&#x2714; |
 | [Microsoft Azure](https://azure.microsoft.com)    |  [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/)     |  |     |        |    |
 | [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/)    |       |  | &#x2714; |  |    |
+| [NetApp Kubernetes Service (NKS)](https://cloud.netapp.com/kubernetes-service) | &#x2714; | &#x2714; | &#x2714; |  |  |
 | [Nirmata](https://www.nirmata.com/)          |              |   &#x2714;     | &#x2714;            |      |          |
 | [Nutanix](https://www.nutanix.com/en)         | [Nutanix Karbon](https://www.nutanix.com/products/karbon)             | [Nutanix Karbon](https://www.nutanix.com/products/karbon)       |             |      | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization)         |
 | [OpenNebula](https://www.opennebula.org)          |[OpenNebula Kubernetes](https://marketplace.opennebula.systems/docs/service/kubernetes.html)              |        |            |      |   |
@@ -101,7 +100,6 @@ card:
 | [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service)           |      |          |
 | [Platform9](https://platform9.com/)         | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)             |       | [Platform9 Managed Kubernetes](https://platform9.com/managed-kubernetes/)            |  &#x2714;    |  &#x2714;    |   &#x2714;
 | [Rancher](https://rancher.com/)         |              |   [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/)     |             |  [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/)    |          | [k3s](https://k3s.io/)
-| [StackPoint](https://stackpoint.io/)          | &#x2714;            |  &#x2714;      |             |      |          |
 | [Supergiant](https://supergiant.io/)         |              |&#x2714;        |             |      |          |
 | [SUSE](https://www.suse.com/)        |              | &#x2714;       |             |      |          |
 | [SysEleven](https://www.syseleven.io/)         | &#x2714;             |        |             |      |          |
@@ -0,0 +1,153 @@
+---
+title: 포트 포워딩을 사용해서 클러스터 내 애플리케이션에 접근하기
+content_template: templates/task
+weight: 40
+---
+
+{{% capture overview %}}
+
+이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서 
+실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스
+디버깅에 유용할 수 있다.
+
+{{% /capture %}}
+
+
+{{% capture prerequisites %}}
+
+* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+* [redis-cli](http://redis.io/topics/rediscli)를 설치한다.
+
+{{% /capture %}}
+
+
+{{% capture steps %}}
+
+## Redis 디플로이먼트와 서비스 생성하기
+
+1. Redis 디플로이먼트를 생성한다.
+
+        kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml
+
+    성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
+
+        deployment.apps/redis-master created
+
+    파드 상태를 조회하여 파드가 준비되었는지 확인한다.
+
+        kubectl get pods
+
+    출력은 파드가 생성되었다는 것을 보여준다.
+
+        NAME                            READY     STATUS    RESTARTS   AGE
+        redis-master-765d459796-258hz   1/1       Running   0          50s
+
+    디플로이먼트 상태를 조회한다.
+
+        kubectl get deployment
+
+    출력은 디플로이먼트가 생성되었다는 것을 보여준다.
+
+        NAME         READY   UP-TO-DATE   AVAILABLE   AGE
+        redis-master 1/1     1            1           55s
+
+    아래의 명령어를 사용하여 레플리카셋 상태를 조회한다.
+
+        kubectl get rs
+
+    출력은 레플리카셋이 생성되었다는 것을 보여준다.
+
+        NAME                      DESIRED   CURRENT   READY     AGE
+        redis-master-765d459796   1         1         1         1m
+
+
+2. Redis 서비스를 생성한다.
+
+        kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml
+
+    성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
+
+        service/redis-master created
+
+    서비스가 생성되었는지 확인한다.
+
+        kubectl get svc | grep redis
+
+    출력은 서비스가 생성되었다는 것을 보여준다.
+
+        NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
+        redis-master   ClusterIP   10.0.0.213   <none>        6379/TCP   27s
+
+3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다.
+
+        kubectl get pods redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
+
+    출력은 포트 번호를 보여준다.
+
+        6379
+
+
+## 파드의 포트를 로컬 포트로 포워딩하기
+
+1.  	쿠버네티스 1.10 버전부터, `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다.
+
+        kubectl port-forward redis-master-765d459796-258hz 7000:6379
+
+    이것은
+
+        kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379
+
+    또는
+
+        kubectl port-forward deployment/redis-master 7000:6379
+
+    또는
+
+        kubectl port-forward rs/redis-master 7000:6379
+
+    또는 다음과 같다.
+
+        kubectl port-forward svc/redis-master 7000:6379
+
+    위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다.
+
+        I0710 14:43:38.274550    3655 portforward.go:225] Forwarding from 127.0.0.1:7000 -> 6379
+        I0710 14:43:38.274797    3655 portforward.go:225] Forwarding from [::1]:7000 -> 6379
+
+2.  Redis 커맨드라인 인터페이스를 실행한다.
+
+        redis-cli -p 7000
+
+3.  Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다.
+
+        127.0.0.1:7000>ping
+
+    성공적인 핑 요청은 PONG을 반환한다.
+
+{{% /capture %}}
+
+
+{{% capture discussion %}}
+
+## 토의
+
+로컬 7000 포트에 대한 연결은 Redis 서버가 실행중인 파드의 6379 포트로 포워딩된다.
+이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데
+사용할 수 있다.
+
+{{< warning >}}
+알려진 제한사항으로 인해, 오늘날 포트 포워딩은 TCP 프로토콜에서만 작동한다. UDP 프로토콜에 대한 지원은 
+[이슈 47862](https://github.com/kubernetes/kubernetes/issues/47862)
+에서 추적되고 있다.
+{{< /warning >}}
+
+{{% /capture %}}
+
+
+{{% capture whatsnext %}}
+[kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward)에 대해 더 알아본다.
+{{% /capture %}}
+
+
+
@@ -0,0 +1,17 @@
+apiVersion: apps/v1
+kind: ReplicaSet
+metadata:
+  name: my-repset
+spec:
+  replicas: 3
+  selector:
+    matchLabels:
+      pod-is-for: garbage-collection-example
+  template:
+    metadata:
+      labels:
+        pod-is-for: garbage-collection-example
+    spec:
+      containers:
+      - name: nginx
+        image: nginx