diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md
index ac298f9dc3..e21ff73c49 100644
--- a/content/ko/docs/concepts/architecture/cloud-controller.md
+++ b/content/ko/docs/concepts/architecture/cloud-controller.md
@@ -52,7 +52,7 @@ CCM은 쿠버네티스 컨트롤러 매니저(KCM)의 기능 일부를 독립시
볼륨 컨트롤러는 의도적으로 CCM의 일부가 되지 않도록 선택되었다. 연관된 복잡성 때문에 그리고 벤더 특유의 볼륨 로직 개념을 일반화 하기 위한 기존의 노력때문에, 볼륨 컨트롤러는 CCM으로 이전되지 않도록 결정되었다.
{{< /note >}}
-CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 Flex 볼륨을 사용하기 위한 것이었다. 그러나, CSI라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
+CCM을 이용하는 볼륨을 지원하기 위한 원래 계획은 플러그형 볼륨을 지원하기 위한 [Flex](/docs/concepts/storage/volumes/#flexVolume) 볼륨을 사용하기 위한 것이었다. 그러나, [CSI](/docs/concepts/storage/volumes/#csi)라 알려진 경쟁적인 노력이 Flex를 대체하도록 계획되고 있다.
이러한 역동성을 고려하여, CSI가 준비될 때까지 차이점에 대한 측정은 도중에 중지하기로 결정하였다.
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index e2a3813ec6..dffd6bd2db 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -78,19 +78,10 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면
노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
-1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
-[taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
-마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다.
-대신 노드의 taint와 toleration을 살펴본다.
-
-현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다.
-아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의
-taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
-
-{{< caution >}}
-이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는
-시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
-{{< /caution >}}
+노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
+[테인트(taints)](/docs/concepts/configuration/taint-and-toleration/)를 생성한다.
+스케줄러가 파드를 노드에 할당할 때, 스케줄러는 파드가 극복(tolerate)하는 테인트가
+아닌 한, 노드 계정의 테인트를 고려 한다.
### 용량과 할당가능 {#capacity}
@@ -169,18 +160,28 @@ NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
-쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가
-된다. node lease 기능은 1.14 부터 기본값으로 활성화 되었으며, 베타 기능이다
-(기능 게이트 `NodeLease`, [KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)).
-node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해
-갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고
-NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다.
-NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만
-(기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.)
-노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다.
-노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과
-성능 두 가지 측면에서 노드 하트비트를 상당히
-경제적이도록 해준다.
+#### 하트비트
+
+쿠버네티스 노드에서 보내는 하트비트는 노드의 가용성을 결정하는데 도움이 된다.
+하트비트의 두 가지 형태는 `NodeStatus` 와
+[리스(Lease) 오브젝트](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io) 이다.
+각 노드에는 `kube-node-lease` 라는
+{{< glossary_tooltip term_id="namespace" text="네임스페이스">}} 에 관련된 리스 오브젝트가 있다.
+리스는 경량 리소스로, 클러스터가 확장될 때
+노드의 하트비트 성능을 향상 시킨다.
+
+kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
+의무가 있다.
+
+- kubelet은 상태가 변경되거나 구성된 상태에 대한 업데이트가 없는 경우,
+ `NodeStatus` 를 업데이트 한다. `NodeStatus` 의 기본 업데이트
+ 주기는 5분이다(연결할 수 없는 노드의 시간 제한인 40초
+ 보다 훨씬 길다).
+- kubelet은 10초마다 리스 오브젝트를 생성하고 업데이트 한다(기본 업데이트 주기).
+ 리스 업데이트는 `NodeStatus` 업데이트와는
+ 독립적으로 발생한다.
+
+#### 안정성
쿠버네티스 1.4에서, 대량의 노드들이 마스터 접근에
문제를 지닐 경우 (예를 들어 마스터에 네트워크 문제가 발생했기 때문에)
diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md
index 569a3cef27..3402d68c6c 100644
--- a/content/ko/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md
@@ -64,7 +64,7 @@ card:
* **자동화된 복구(self-healing)**
쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
* **시크릿과 구성 관리**
-쿠버네티스를 사용하면 암호, OAuth 토큰 및 ssh 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
+쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 비밀을 노출하지 않고도 비밀 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.
## 쿠버네티스가 아닌 것
@@ -74,9 +74,9 @@ card:
* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
-* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
+* 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 [Open Service Broker](https://openservicebrokerapi.org/) 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
-* 기본 설정 언어/시스템(예, jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
+* 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
* 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.
diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md
new file mode 100644
index 0000000000..a0728564af
--- /dev/null
+++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md
@@ -0,0 +1,427 @@
+---
+title: 서비스와 애플리케이션 연결하기
+content_template: templates/concept
+weight: 30
+---
+
+
+{{% capture overview %}}
+
+## 컨테이너 연결을 위한 쿠버네티스 모델
+
+지속적으로 실행중이고, 복제된 애플리케이션을 가지고 있다면 네트워크에 노출할 수 있다. 쿠버네티스의 네트워킹 접근 방식을 논의하기 전에, 도커와 함께 동작하는 "일반적인" 네트워킹 방법과 대조해볼 가치가 있다.
+
+기본적으로 도커는 호스트-프라이빗 네트워킹을 사용하기에 컨테이너는 동일한 머신에 있는 경우에만 다른 컨테이너와 통신 할 수 있다. 도커 컨테이너가 노드를 통해 통신하려면 머신 포트에 IP 주소가 할당되어야 컨테이너에 전달되거나 프록시된다. 이것은 컨테이너가 사용하는 포트를 매우 신중하게 조정하거나 포트를 동적으로 할당해야 한다는 의미이다.
+
+여러 개발자에 걸쳐있는 포트를 조정하는 것은 규모면에서 매우 어려우며, 사용자가 제어할 수 없는 클러스터 수준의 문제에 노출된다. 쿠버네티스는 파드가 배치된 호스트와는 무관하게 다른 파드와 통신할 수 있다고 가정한다. 모든 파드에게 자체 클러스터-프라이빗-IP 주소를 제공하기 때문에 파드간에 명시적으로 링크를 만들거나 컨테이너 포트를 호스트 포트에 매핑 할 필요가 없다. 이것은 파드 내의 컨테이너는 모두 로컬호스트에서 서로의 포트에 도달할 수 있으며 클러스터의 모든 파드는 NAT 없이 서로를 볼 수 있다는 의미이다. 이 문서의 나머지 부분에서는 이러한 네트워킹 모델에서 신뢰할 수 있는 서비스를 실행하는 방법에 대해 자세히 설명할 것이다.
+
+이 가이드는 간단한 nginx 서버를 사용해서 개념증명을 보여준다. 동일한 원칙이 보다 완전한 [Jenkins CI 애플리케이션](https://kubernetes.io/blog/2015/07/strong-simple-ssl-for-kubernetes)에서 구현된다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 파드를 클러스터에 노출하기
+
+이 작업은 이전 예시에서 수행해 보았지만, 네트워킹 관점을 중점에 두고 다시 한번 수행해 보자.
+nginx 파드를 생성하고, 해당 파드에 컨테이너 포트 사양이 있는 것을 참고한다.
+
+{{< codenew file="service/networking/run-my-nginx.yaml" >}}
+
+이렇게 하면 클러스터의 모든 노드에서 접근할 수 있다. 파드를 실행 중인 노드를 확인한다.
+
+```shell
+kubectl apply -f ./run-my-nginx.yaml
+kubectl get pods -l run=my-nginx -o wide
+```
+```
+NAME READY STATUS RESTARTS AGE IP NODE
+my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
+my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
+```
+
+파드의 IP를 확인한다.
+
+```shell
+kubectl get pods -l run=my-nginx -o yaml | grep podIP
+ podIP: 10.244.3.4
+ podIP: 10.244.2.5
+```
+
+클러스터의 모든 노드로 ssh 접속하고 두 IP로 curl을 할수 있어야 한다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 containerPort를 사용해서 동일한 노드에서 여러 nginx 파드를 실행하고 IP를 사용해서 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 도커와 마찬가지로 포트는 여전히 호스트 노드의 인터페이스에 게시될 수 있지만, 네트워킹 모델로 인해 포트의 필요성이 크게 줄어든다.
+
+만약 궁금하다면 [우리가 이것을 달성하는 방법](/docs/concepts/cluster-administration/networking/#how-to-achieve-this)을 자세히 읽어본다.
+
+## 서비스 생성하기
+
+평평하고 넓은 클러스터 전체의 주소 공간에서 nginx를 실행하는 파드가 있다고 가정하자. 이론적으로는 이러한 파드와 직접 대화할 수 있지만, 노드가 죽으면 어떻게 되는가? 파드가 함께 죽으면 디플로이먼트에서 다른 IP를 가진 새로운 파드를 생성한다. 이 문제를 서비스가 해결한다.
+
+쿠버네티스 서비스는 클러스터 어딘가에서 실행되는 논리적인 파드 집합을 정의하고 추상화함으로써 모두 동일한 기능을 제공한다. 생성시 각 서비스에는 고유한 IP 주소(clusterIP라고도 한다)가 할당된다. 이 주소는 서비스의 수명과 연관되어 있으며, 서비스가 활성화 되어있는 동안에는 변경되지 않는다. 파드는 서비스와 통신하도록 구성할 수 있으며, 서비스와의 통신은 서비스의 맴버 중 일부 파드에 자동적으로 로드-밸런싱 된다.
+
+`kubectl expose` 를 사용해서 2개의 nginx 레플리카에 대한 서비스를 생성할 수 있다.
+
+```shell
+kubectl expose deployment/my-nginx
+```
+```
+service/my-nginx exposed
+```
+
+이것은 다음 yaml 파일을 `kubectl apply -f` 로 실행한 것과 동일하다.
+
+{{< codenew file="service/networking/nginx-svc.yaml" >}}
+
+이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을
+대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다
+(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는
+추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는
+모든 포트일 수 있다).
+[서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의
+API 오브젝트를 보고 서비스 정의에서 지원되는 필드 목록을 확인한다.
+서비스를 확인한다.
+
+```shell
+kubectl get svc my-nginx
+```
+```
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+my-nginx ClusterIP 10.0.162.149
80/TCP 21s
+```
+
+앞에서 언급한 바와 같이, 서비스는 파드 그룹에 의해 지원된다. 이 파드들은
+`endpoints` 를 통해 노출된다. 서비스 셀렉터는 지속적으로 평가되고
+결과는 `my-nginx` 이름의 엔드포인트 오브젝트에 POST된다.
+파드가 죽으면 자동적으로 엔드포인트에서 제거되며 서비스 셀렉터와
+일치하는 새 파드는 자동적으로 엔드포인트에 추가된다.
+엔드포인트를 확인하고 IP가 첫 번째 단계에서 생성된 파드와 동일하다는
+점을 참고한다.
+
+```shell
+kubectl describe svc my-nginx
+```
+```
+Name: my-nginx
+Namespace: default
+Labels: run=my-nginx
+Annotations:
+Selector: run=my-nginx
+Type: ClusterIP
+IP: 10.0.162.149
+Port: 80/TCP
+Endpoints: 10.244.2.5:80,10.244.3.4:80
+Session Affinity: None
+Events:
+```
+```shell
+kubectl get ep my-nginx
+```
+```
+NAME ENDPOINTS AGE
+my-nginx 10.244.2.5:80,10.244.3.4:80 1m
+```
+
+이제 클러스터의 모든 노드에서 `:` 로 nginx 서비스를
+curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지
+않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면
+[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다.
+
+## 서비스에 접근하기
+
+쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
+지원한다. 전자는 기본적으로 작동하지만 후자는
+[CoreDNS 클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
+{{< note >}}
+만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
+처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
+`enableServiceLinks` 플래그를 `false` 로 설정하면 이 모드를 비활성화할 수 있다.
+{{< /note >}}
+
+
+### 환경 변수들
+
+파드가 노드에서 실행될 때 kubelet은 각기 활성화된 서비스에 대해 일련의 환경
+변수 집합을 추가한다. 이것은 순서 문제를 야기한다. 이유를 확인하려면
+실행 중인 nginx 파드 환경을 점검해야 한다(실제 사용자의 파드 이름은 다를 것이다).
+
+```shell
+kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
+```
+```
+KUBERNETES_SERVICE_HOST=10.0.0.1
+KUBERNETES_SERVICE_PORT=443
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+서비스에 대한 언급이 없다는 것에 참고해야 한다. 이것은 서비스 이전에 레플리카를
+생성했기 때문이다. 이 작업을 수행할 때 또 다른 단점은 스케줄러가 두 파드를
+모두 동일한 머신에 배치할 수도 있다는 것이며, 이로 인해 전체 서비스가 중단될 수
+있다. 두개의 파드를 죽이고 디플로이먼트가 파드를 재생성하기를 기다리는 것으로
+이를 정상화 할 수 있다. 이번에는 서비스가 레플리카들 *전* 에
+존재한다. 이렇게 하면 올바른 환경 변수뿐만 아니라 파드의 스케줄러-수준의
+서비스 분배(모든 노드에 동일한 용량이 제공되는 경우)가
+된다.
+
+```shell
+kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
+
+kubectl get pods -l run=my-nginx -o wide
+```
+```
+NAME READY STATUS RESTARTS AGE IP NODE
+my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
+my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
+```
+
+파드가 죽고 재생성되었기 때문에 다른 이름을 가지는 것을 알 수 있다.
+
+```shell
+kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
+```
+```
+KUBERNETES_SERVICE_PORT=443
+MY_NGINX_SERVICE_HOST=10.0.162.149
+KUBERNETES_SERVICE_HOST=10.0.0.1
+MY_NGINX_SERVICE_PORT=80
+KUBERNETES_SERVICE_PORT_HTTPS=443
+```
+
+### DNS
+
+쿠버네티스는 DNS 클러스터 애드온 서비스를 제공하며 dns 이름을 다른 서비스에 자동으로 할당한다. 다음 명령어로 이것이 클러스터에서 실행 중인지 확인할 수 있다.
+
+```shell
+kubectl get services kube-dns --namespace=kube-system
+```
+```
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m
+```
+
+이 섹션의 나머지 부분에서는 수명이 긴 IP의 서비스(my-nginx)와 이 IP
+에 이름을 할당한 DNS 서버가 있다고 가정한다. 여기서는 CoreDNS 클러스터 애드온(애플리케이션 이름 `kube-dns`)을 사용하므로, 표준 방법(예: `gethostbyname()`)을 사용해서 클러스터의 모든 파드에서 서비스와 통신할 수 있다. 만약 CoreDNS가 실행 중이 아니라면 [CoreDNS README](https://github.com/coredns/deployment/tree/master/kubernetes) 또는 [CoreDNS 설치](/docs/tasks/administer-cluster/coredns/#installing-coredns)를 참조해서 활성화 할 수 있다. 이것을 테스트하기 위해 다른 curl 애플리케이션을 실행한다.
+
+```shell
+kubectl run curl --image=radial/busyboxplus:curl -i --tty
+```
+```
+Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
+Hit enter for command prompt
+```
+
+이제, `nslookup my-nginx` 를 입력하고 실행한다:
+
+```shell
+[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
+Server: 10.0.0.10
+Address 1: 10.0.0.10
+
+Name: my-nginx
+Address 1: 10.0.162.149
+```
+
+## 서비스 보안
+
+지금까지는 클러스터 내부에서만 ngnix 서버에 엑세스 해왔다. 서비스를 인터넷에 공개하기 전에 통신 채널이 안전한지 확인해야 한다. 이를 위해선 다음이 필요하다.
+
+* https에 대한 자체 서명한 인증서 (신원 인증서를 가지고 있지 않은 경우)
+* 인증서를 사용하도록 구성된 nginx 서버
+* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/docs/concepts/configuration/secret/)
+
+[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
+
+```shell
+make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
+kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
+```
+```
+secret/nginxsecret created
+```
+```shell
+kubectl get secrets
+```
+```
+NAME TYPE DATA AGE
+default-token-il9rc kubernetes.io/service-account-token 1 1d
+nginxsecret kubernetes.io/tls 2 1m
+```
+그리고 또한 컨피그맵:
+```shell
+kubectl create configmap nginxconfigmap --from-file=default.conf
+```
+```
+configmap/nginxconfigmap created
+```
+```shell
+kubectl get configmaps
+```
+```
+NAME DATA AGE
+nginxconfigmap 1 114s
+```
+다음은 make를 실행하는데 문제가 있는 경우에 수행해야 하는 수동 단계이다(예시로 windows).
+
+```shell
+# Create a public private key pair
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
+# Convert the keys to base64 encoding
+cat /d/tmp/nginx.crt | base64
+cat /d/tmp/nginx.key | base64
+```
+이전 명령의 출력을 사용해서 다음과 같이 yaml 파일을 생성한다. base64로 인코딩된 값은 모두 한 줄에 있어야 한다.
+
+```yaml
+apiVersion: "v1"
+kind: "Secret"
+metadata:
+ name: "nginxsecret"
+ namespace: "default"
+type: kubernetes.io/tls
+data:
+ tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
+ tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
+```
+이제 파일을 사용해서 시크릿을 생성한다.
+
+```shell
+kubectl apply -f nginxsecrets.yaml
+kubectl get secrets
+```
+```
+NAME TYPE DATA AGE
+default-token-il9rc kubernetes.io/service-account-token 1 1d
+nginxsecret kubernetes.io/tls 2 1m
+```
+
+이제 nginx 레플리카를 수정하여 암호화된 인증서를 사용한 https 서버와 서비스를 실행하고, 두 포트(80과 443)를 노출한다.
+
+{{< codenew file="service/networking/nginx-secure-app.yaml" >}}
+
+nginx-secure-app의 매니페스트에 대한 주목할만한 점:
+
+- 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
+- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
+ 는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
+ 두 포트를 모두 노출한다.
+- 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.
+ 이것은 nginx 서버가 시작되기 *전에* 설정된 것이다.
+
+```shell
+kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
+```
+
+이 시점에서 모든 노드에서 nginx 서버에 연결할 수 있다.
+
+```shell
+kubectl get pods -o yaml | grep -i podip
+ podIP: 10.244.3.5
+node $ curl -k https://10.244.3.5
+...
+Welcome to nginx!
+```
+
+마지막 단계에서 curl에 `-k` 파라미터를 제공한 방법에 참고한다. 이는 인증서 생성시 nginx를 실행하는 파드에 대해 아무것도 모르기 때문에
+curl에 CName 불일치를 무시하도록 지시해야하기 때문이다. 서비스를 생성해서 인증서에 사용된 CName을 서비스 조회시 파드에서 사용된 실제 DNS 이름과 연결했다.
+파드에서 이것을 테스트 해보자(단순히 동일한 시크릿이 재사용되고 있으며, 파드는 서비스에 접근하기위해 nginx.crt만 필요하다).
+
+{{< codenew file="service/networking/curlpod.yaml" >}}
+
+```shell
+kubectl apply -f ./curlpod.yaml
+kubectl get pods -l app=curlpod
+```
+```
+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
+...
+Welcome to nginx!
+...
+```
+
+## 서비스 노출하기
+
+애플리케이션의 일부인 경우 원한다면 외부 IP 주소에 서비스를
+노출할 수 있다. 쿠버네티스는 이를 수행하는 2가지 방법인 NodePorts와
+LoadBalancers를지원한다. 마지막 섹션에서 생성된 서비스는 이미 `NodePort` 를 사용했기에
+노드에 공용 IP가 있는경우 nginx HTTPS 레플리카가 인터넷 트래픽을 처리할
+준비가 되어있다.
+
+```shell
+kubectl get svc my-nginx -o yaml | grep nodePort -C 5
+ uid: 07191fb3-f61a-11e5-8ae5-42010af00002
+spec:
+ clusterIP: 10.0.162.149
+ ports:
+ - name: http
+ nodePort: 31704
+ port: 8080
+ protocol: TCP
+ targetPort: 80
+ - name: https
+ nodePort: 32453
+ port: 443
+ protocol: TCP
+ targetPort: 443
+ selector:
+ run: my-nginx
+```
+```shell
+kubectl get nodes -o yaml | grep ExternalIP -C 1
+ - address: 104.197.41.11
+ type: ExternalIP
+ allocatable:
+--
+ - address: 23.251.152.56
+ type: ExternalIP
+ allocatable:
+...
+
+$ curl https://: -k
+...
+Welcome to nginx!
+```
+
+이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다.
+
+```shell
+kubectl edit svc my-nginx
+kubectl get svc my-nginx
+```
+```
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s
+```
+```
+curl https:// -k
+...
+Welcome to nginx!
+```
+
+`EXTERNAL-IP` 의 IP 주소는 공용 인터넷에서 이용할 수 있는 주소이다. `CLUSTER-IP` 는
+클러스터/프라이빗 클라우드 네트워크 내에서만 사용할 수 있다.
+
+AWS에서는 `LoadBalancer` 유형은 IP가 아닌 (긴)호스트네임을 사용하는 ELB를
+생성한다는 점을 참고한다. 이것은 일반적인 `kubectl get svc` 의 출력에
+맞추기에는 매우 길기 때문에 실제로 이를 보려면 `kubectl describe service my-nginx` 를
+수행해야 한다. 다음과 같은 것을 보게 된다.
+
+```shell
+kubectl describe service my-nginx
+...
+LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
+...
+```
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+게다가 쿠버네티스는 여러 클러스터와 클라우드 공급자들을 포괄하는
+페더레이션 서비스를 지원하여 가용성을 높이고 내결함성을 향상시키며,
+보다 큰 서비스의 확장성을 제공한다. 자세한 내용은
+[페더레이션 서비스 사용자 가이드](/docs/concepts/cluster-administration/federation-service-discovery/)
+를 본다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md
index 4f0354e9e1..481233d4e0 100644
--- a/content/ko/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md
@@ -12,7 +12,7 @@ weight: 10
{{% capture overview %}}
-{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.17" state="beta" >}}
_엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를
추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한
@@ -24,7 +24,7 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
## 엔드포인트 슬라이스 리소스 {#endpointslice-resource}
-쿠버네티스에서 엔드포인트 슬라이스는 일련의 네트워크 엔드 포인트에 대한
+쿠버네티스에서 EndpointSlice는 일련의 네트워크 엔드 포인트에 대한
참조를 포함한다. 쿠버네티스 서비스에 셀렉터가 지정되면 EndpointSlice
컨트롤러는 자동으로 엔드포인트 슬라이스를 생성한다. 이 엔드포인트 슬라이스는
서비스 셀렉터와 매치되는 모든 파드들을 포함하고 참조한다. 엔드포인트
@@ -34,13 +34,13 @@ _엔드포인트 슬라이스_ 는 쿠버네티스 클러스터 내의 네트워
리소스 샘플이 있다.
```yaml
-apiVersion: discovery.k8s.io/v1alpha1
+apiVersion: discovery.k8s.io/v1beta1
kind: EndpointSlice
metadata:
name: example-abc
labels:
kubernetes.io/service-name: example
-addressType: IP
+addressType: IPv4
ports:
- name: http
protocol: TCP
@@ -48,7 +48,6 @@ ports:
endpoints:
- addresses:
- "10.1.2.3"
- - "2001:db8::1234:5678"
conditions:
ready: true
hostname: pod-1
@@ -65,6 +64,14 @@ endpoints:
신뢰할 수 있는 소스로 역할을 할 수 있다. 이를 활성화 하면, 많은 수의 엔드포인트를 가지는
서비스에 대해 성능 향상을 제공해야 한다.
+## 주소 유형
+
+EndpointSlice는 다음 주소 유형을 지원한다.
+
+* IPv4
+* IPv6
+* FQDN (Fully Qualified Domain Name)
+
## 사용동기
엔드포인트 API는 쿠버네티스에서 네트워크 엔드포인트를 추적하는
diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md
index b2a5e4f723..cd8337ef0a 100644
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@@ -55,7 +55,7 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의
{{% capture whatsnext %}}
-* [인그레스](/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
+* [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기.
* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube).
{{% /capture %}}
diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md
index 6ee517af75..2a04159efd 100644
--- a/content/ko/docs/concepts/services-networking/ingress.md
+++ b/content/ko/docs/concepts/services-networking/ingress.md
@@ -44,7 +44,7 @@ weight: 40
[ Services ]
```
-인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
+인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통
[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는
@@ -52,10 +52,10 @@ weight: 40
## 전제 조건들
-[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
+[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
[ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러
-[인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
+[인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 중에서 선택할 수도 있다.
이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스
컨트롤러는 조금 다르게 작동한다.
@@ -89,7 +89,7 @@ spec:
설정 파일의 작성에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), [컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), [리소스 관리하기](/docs/concepts/cluster-administration/manage-deployment/)를 참조한다.
인그레스는 종종 어노테이션을 이용해서 인그레스 컨트롤러에 따라 몇 가지 옵션을 구성하는데,
그 예시는 [재작성-타겟 어노테이션](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)이다.
- 다른 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
+ 다른 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 다른 어노테이션을 지원한다.
지원되는 어노테이션을 확인하려면 선택한 인그레스 컨트롤러의 설명서를 검토한다.
인그레스 [사양](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
@@ -117,7 +117,7 @@ spec:
### 기본 벡엔드
규칙이 없는 인그레스는 모든 트래픽을 단일 기본 백엔드로 전송한다. 기본
-백엔드는 일반적으로 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
+백엔드는 일반적으로 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)의 구성 옵션이며, 인그레스 리소스에 지정되어 있지 않다.
만약 인그레스 오브젝트의 HTTP 요청과 일치하는 호스트 또는 경로가 없으면, 트래픽은
기본 백엔드로 라우팅 된다.
@@ -218,7 +218,7 @@ Events:
볼 수 있다.
{{< note >}}
-사용중인 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers)
+사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)
에 따라 default-http-backend
[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다.
{{< /note >}}
@@ -452,7 +452,7 @@ Events:
## 가용성 영역에 전체에서의 실패
장애 도메인에 트래픽을 분산시키는 기술은 클라우드 공급자마다 다르다.
-자세한 내용은 [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
+자세한 내용은 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 설명서를 확인한다. 페더레이션 클러스터에서 인그레스 배포에 대한 자세한 내용은 [페더레이션 설명서](https://github.com/kubernetes-sigs/federation-v2)
를 참조할 수 있다.
## 앞으로의 할일
@@ -472,6 +472,6 @@ Events:
{{% /capture %}}
{{% capture whatsnext %}}
-* [인그레스 컨트롤러](/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
+* [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기
* [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube)
{{% /capture %}}
diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md
new file mode 100644
index 0000000000..7e71eee719
--- /dev/null
+++ b/content/ko/docs/concepts/services-networking/service-topology.md
@@ -0,0 +1,124 @@
+---
+title: 서비스 토폴로지
+feature:
+ title: 서비스 토폴로지
+ description: >
+ 클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅.
+
+content_template: templates/concept
+weight: 10
+---
+
+
+{{% capture overview %}}
+
+{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
+
+_서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를
+기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을
+클라이언트와 동일한 노드이거나 동일한 가용성 영역에 있는 엔드포인트로
+우선적으로 라우팅되도록 지정할 수 있다.
+
+{{% /capture %}}
+
+{{% capture body %}}
+
+## 소개
+
+기본적으로 `ClusterIP` 또는 `NodePort` 서비스로 전송된 트래픽은 서비스의
+모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)"
+트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만,
+`ClusterIP` 서비스에서는 지원되지 않으며 더 복잡한
+토폴로지 — 영역별 라우팅과 같은 — 에서는 불가능 했다.
+_서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서
+노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록
+함으로써 이 문제를 해결한다.
+
+소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에
+적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)"
+노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을
+동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는
+지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다.
+다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로
+트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에
+연결된 노드로 트래픽을 유지하는 것이 있다.
+
+## 전제 조건
+
+서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이
+필요하다.
+
+ * 쿠버네티스 1.17 또는 이후 버전
+ * Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중
+ * [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화
+
+## 서비스 토폴로지 활성화하기
+
+서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의
+기능 게이트에서 `ServiceTopology` 를 활성화 한다.
+
+```
+--feature-gates="ServiceTopology=true"
+```
+
+## 서비스 토폴로지 사용하기
+
+만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서
+`topologyKeys` 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는
+이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드
+레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의
+발신 노드 값과 일치하는 노드로 보내진다. 만약 노드에 서비스와 일치하는
+백엔드가 없는 경우, 두 번째 레이블을 그리고 더 이상의
+레이블이 남지 않을 때까지 고려한다.
+
+만약 일치하는 것을 못찾는 경우에는, 서비스에 대한 백엔드가 없었던 것처럼
+트래픽이 거부될 것이다. 즉, 엔드포인트는 사용 가능한 백엔드가 있는 첫 번째
+토폴로지 키를 기반으로 선택된다. 만약 이 필드가 지정되고 모든 항목에
+클라이언트의 토폴로지와 일치하는 백엔드가 없는 경우, 서비스에는 해당 클라이언트에
+대한 백엔드가 없기에 연결에 실패해야 한다. 특수한 값인 `"*"` 은 "모든 토폴로지"를
+의미하는데 사용될 수 있다. 이 캐치 올(catch-all) 값을 사용하는 경우
+목록의 마지막 값으로만 타당하다.
+
+만약 `topologyKeys` 가 지정되지 않거나 비어있는 경우 토폴로지 제약 조건이 적용되지 않는다.
+
+호스트 이름, 영역 이름 그리고 지역 이름으로 레이블이 지정된 노드가 있는
+클러스터가 있다고 생각해 보자. 그러고 나면, 서비스의 `topologyKeys` 값을 설정해서 다음과 같이 트래픽을
+전달할 수 있다.
+
+* 동일한 노드의 엔드포인트에만 해당하고, 엔드포인트가 노드에 없으면 실패한다:
+ `["kubernetes.io/hostname"]`.
+* 동일한 노드의 엔드포인트를 선호하지만, 동일한 영역의 엔드포인트로 대체
+ 한 후 동일한 지역으로 대체되고, 그렇지 않으면 실패한다: `["kubernetes.io/hostname",
+ "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]`.
+ 예를 들어 데이터 위치가 중요한 경우에 유용할 수 있다.
+* 동일한 영역이 선호되지만, 이 영역 내에 사용할 수 있는 항목이 없는 경우에는
+ 사용가능한 엔드포인트로 대체된다:
+ `["topology.kubernetes.io/zone", "*"]`.
+
+
+
+## 제약들
+
+* 서비스 토폴로지는 `externalTrafficPolicy=Local` 와 호환되지 않으므로
+ 서비스는 이 두 가지 기능을 함께 사용할 수 없다. 동일한 서비스가 아닌
+ 같은 클러스터의 다른 서비스라면 이 기능을 함께 사용할
+ 수 있다.
+
+* 유효한 토폴로지 키는 현재 `kubernetes.io/hostname`,
+ `topology.kubernetes.io/zone` 그리고 `topology.kubernetes.io/region` 로
+ 제한되어있지만, 앞으로 다른 노드 레이블로 일반화 될 것이다.
+
+* 토폴로지 키는 유효한 레이블 키이어야 하며 최대 16개의 키를 지정할 수 있다.
+
+* 만약 캐치 올(catch-all) 값인 `"*"` 를 사용한다면 토폴로지 키들의 마지막 값이어야
+ 한다.
+
+
+{{% /capture %}}
+
+{{% capture whatsnext %}}
+
+* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다.
+* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다.
+
+{{% /capture %}}
diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
index 023bc74bc8..dccde89562 100644
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -14,7 +14,7 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도
- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행.
- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행.
-- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
+- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행.
단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다.
더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만,
@@ -95,21 +95,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
## 데몬 파드가 스케줄 되는 방법
-### 데몬셋 컨트롤러에 의해서 스케줄(1.12 이후로 기본값으로 사용 안함)
+### 기본 스케줄러로 스케줄
-일반적으로 쿠버네티스 스케줄러에 의해 파드가 실행되는 머신이 선택된다. 그러나 데몬셋
-컨트롤러에 의해 생성된 파드는 이미 머신이 선택되어 있다(`.spec.nodeName` 이
-파드가 생성될 때 명시되므로, 스케줄러에서는 무시된다). 그러므로 다음과 같다.
-
- - 데몬셋 컨트롤러는 노드의 [`unschedulable`](/ko/docs/concepts/architecture/nodes/#수동-노드-관리)
- 필드를 존중하지 않는다.
- - 데몬셋 컨트롤러는 스케줄러가 시작되지 않은 경우에도 파드를 만들 수 있어 클러스터 부트스트랩을
- 도울 수도 있다.
-
-
-### 기본 스케줄러로 스케줄(1.12 이후로 기본값으로 사용)
-
-{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
+{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로
쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index f5b802107e..3b95e2b47c 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -44,10 +44,6 @@ weight: 40
## 구성 요소
아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다.
-* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
-* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
-* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
-
```yaml
apiVersion: v1
kind: Service
@@ -99,6 +95,12 @@ spec:
storage: 1Gi
```
+위의 예시에서:
+
+* 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다.
+* 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다.
+* volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다.
+
## 파드 셀렉터
스테이트풀셋의 `.spec.selector` 필드는 `.spec.template.metadata.labels` 레이블과 일치하도록 설정 해야 한다. 쿠버네티스 1.8 이전에서는 생략시에 `.spec.selector` 필드가 기본 설정 되었다. 1.8 과 이후 버전에서는 파드 셀렉터를 명시하지 않으면 스테이트풀셋 생성시 유효성 검증 오류가 발생하는 결과가 나오게 된다.
@@ -140,7 +142,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
-클러스터 도메인이 달리 [구성된 경우](/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
+클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/#how-it-works)가
아니라면 `cluster.local`로 설정된다.
{{< /note >}}
@@ -260,7 +262,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
* [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다.
* [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다.
-* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)의 예시를 따른다.
+* [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다.
{{% /capture %}}
diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
index 94b34ff0ce..2f8cbc2a61 100644
--- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
@@ -14,9 +14,8 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
-알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고
-[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
-`TTLAfterFinished` 를 통해 활성화 될 수 있다.
+알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께
+[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다.
{{% /capture %}}
diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index a07326c905..8ebdab2345 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -144,7 +144,7 @@ spec:
+---------------+-------+
| zoneA | zoneB |
+-------+-------+-------+
-| node1 | node2 | nod3 |
+| node1 | node2 | node3 |
+-------+-------+-------+
| P P | P | P P |
+-------+-------+-------+
diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md
index 631dc10d13..d12c0a9d28 100644
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@@ -18,11 +18,11 @@ content_template: templates/concept
* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요
* 쿠버네티스 API 버전
+ * [1.17](/docs/reference/generated/kubernetes-api/v1.17/)
* [1.16](/docs/reference/generated/kubernetes-api/v1.16/)
* [1.15](/docs/reference/generated/kubernetes-api/v1.15/)
* [1.14](/docs/reference/generated/kubernetes-api/v1.14/)
* [1.13](/docs/reference/generated/kubernetes-api/v1.13/)
- * [1.12](/docs/reference/generated/kubernetes-api/v1.12/)
## API 클라이언트 라이브러리
diff --git a/content/ko/docs/reference/glossary/cloud-provider.md b/content/ko/docs/reference/glossary/cloud-provider.md
index a0fcc998e9..e649147b32 100644
--- a/content/ko/docs/reference/glossary/cloud-provider.md
+++ b/content/ko/docs/reference/glossary/cloud-provider.md
@@ -4,14 +4,28 @@ id: cloud-provider
date: 2018-04-12
full_link: /docs/concepts/cluster-administration/cloud-providers
short_description: >
- 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+ 클라우드 컴퓨팅 플랫폼을 제공하는 조직.
-aka:
+aka:
+- Cloud Service Provide
tags:
- community
---
- 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사.
+ 클라우드 컴퓨팅 플랫폼을 제공하는 사업자 또는 다른 조직
-
+
-클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다.
+클라우드 공급자, 때로는 클라우드 서비스 공급자(CSP) 부르며,
+클라우드 컴퓨팅 플랫폼 또는 서비스를 제공한다.
+
+많은 클라우드 공급자들은 관리되는 인프라를 제공한다(이를
+Infrastructure as a Service 또는 IaaS 라 부른다).
+관리되는 인프라를 통해 클라우드 공급자는
+서버, 스토리지 그리고 네트워킹을 담당하고 쿠버네티스
+클러스터 실행과 같은 계층을 관리한다.
+
+사용자는 쿠버네티스를 관리되는 서비스로 찾을 수 있다. 때로는 이것을
+Platform as a Service 또는 PaaS라 부른다. 관리되는 쿠버네티스를 사용하면
+클라우드 공급자가 쿠버네티스 컨트롤 플레인만 아니라,
+노드와 연관되는 인프라(네트워킹, 스토리지 그리고 로드밸런서와 같은 기타 요소)
+를 책임진다.
diff --git a/content/ko/docs/reference/glossary/etcd.md b/content/ko/docs/reference/glossary/etcd.md
index ea5a38d015..b9a0625585 100644
--- a/content/ko/docs/reference/glossary/etcd.md
+++ b/content/ko/docs/reference/glossary/etcd.md
@@ -19,4 +19,4 @@ tags:
이 데이터를 [백업](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)하는 계획은
필수이다.
-etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
+etcd에 대한 자세한 정보는, 공식 [문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다.
diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md
index 231373cbec..a964a4a6d6 100644
--- a/content/ko/docs/reference/kubectl/cheatsheet.md
+++ b/content/ko/docs/reference/kubectl/cheatsheet.md
@@ -156,9 +156,9 @@ kubectl get services --sort-by=.metadata.name
# 재시작 횟수로 정렬된 파드의 목록 조회
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'
-# test 네임스페이스 내 파드 목록을 용량으로 정렬해서 조회
+# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회
-kubectl get pods -n test --sort-by=.spec.capacity.storage
+kubectl get pv -n test --sort-by=.spec.capacity.storage
# app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회
kubectl get pods --selector=app=cassandra -o \
diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md
index ddd47ef1e8..e333e40121 100644
--- a/content/ko/docs/reference/using-api/client-libraries.md
+++ b/content/ko/docs/reference/using-api/client-libraries.md
@@ -59,6 +59,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery
| PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) |
| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) |
| Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) |
+| Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) |
| Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) |
| Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) |
| Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) |
diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md
index 50928ca6e1..d10d66cd20 100644
--- a/content/ko/docs/setup/_index.md
+++ b/content/ko/docs/setup/_index.md
@@ -72,7 +72,7 @@ card:
| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ |
| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔|
| [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔
-| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | |
+| [Containership](https://containership.io) | ✔ |✔ | | | |
| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) |
| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔
| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | |
@@ -80,12 +80,12 @@ card:
| [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | | | | | ✔ | ✔
| [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/) | | | | | | ✔
| [Gardener](https://gardener.cloud/) | ✔ | ✔ | ✔ | ✔ | ✔ | [사용자 정의 확장](https://github.com/gardener/gardener/blob/master/docs/extensions/overview.md) |
-| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | |
+| [Giant Swarm](https://www.giantswarm.io/) | ✔ | ✔ | ✔ | |
| [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/) | | | | | | | |
| [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/) | |✔| ✔ | | |
-| [KubeOne](https://github.com/kubermatic/kubeone) | | ✔ | ✔ | ✔ | ✔ | ✔ |
+| [KubeOne](https://kubeone.io/) | | ✔ | ✔ | ✔ | ✔ | ✔ |
| [Kubermatic](https://kubermatic.io/) | ✔ | ✔ | ✔ | ✔ | ✔ | |
| [KubeSail](https://kubesail.com/) | ✔ | | | | |
| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ |
diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md
index 810c02f4ea..4d8d8ed976 100644
--- a/content/ko/docs/setup/best-practices/certificates.md
+++ b/content/ko/docs/setup/best-practices/certificates.md
@@ -102,11 +102,11 @@ kubeadm 사용자만 해당:
| 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 |
|------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------|
| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile |
-| etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
+| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile |
| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file |
| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file |
| kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file |
-| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
+| kube-apiserver-kubelet-client| apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file |
| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file |
| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file |
diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md
index d9fce5275f..4c8df0c805 100644
--- a/content/ko/docs/setup/learning-environment/minikube.md
+++ b/content/ko/docs/setup/learning-environment/minikube.md
@@ -324,6 +324,9 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설
`minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다.
이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다.
+### minikube 업그레이드
+[minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/)를 본다.
+
## 클러스터와 상호 작용하기
### Kubectl
diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md
index 1c83aaf7bc..b5758996af 100644
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@@ -62,17 +62,18 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다.
## Docker
각 머신들에 대해서, Docker를 설치한다.
-버전 18.06.2가 추천된다. 그러나 1.11, 1.12, 1.13, 17.03 그리고 18.09도 동작하는 것으로 알려져 있다.
+버전 19.03.4가 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다.
쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다.
시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다.
{{< tabs name="tab-cri-docker-installation" >}}
-{{< tab name="Ubuntu 16.04" codelang="bash" >}}
+{{< tab name="Ubuntu 16.04+" codelang="bash" >}}
# Docker CE 설치
## 리포지터리 설정
### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치
-apt-get update && apt-get install apt-transport-https ca-certificates curl software-properties-common
+apt-get update && apt-get install \
+ apt-transport-https ca-certificates curl software-properties-common
### Docker의 공식 GPG 키 추가
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
@@ -84,7 +85,10 @@ add-apt-repository \
stable"
## Docker CE 설치.
-apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
+apt-get update && apt-get install \
+ containerd.io=1.2.10-3 \
+ docker-ce=5:19.03.4~3-0~ubuntu-$(lsb_release -cs) \
+ docker-ce-cli=5:19.03.4~3-0~ubuntu-$(lsb_release -cs)
# 데몬 설정.
cat > /etc/docker/daemon.json <}}
+
+`minikube start` 시 `--vm-driver` 를 설정하려면, 아래에 `` 로 소문자로 언급된 곳에 설치된 하이퍼바이저의 이름을 입력한다. `--vm-driver` 값의 전체 목록은 [VM driver 문서에서 지정하기](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver)에서 확인할 수 있다.
+
+{{< /note >}}
+
+```shell
+minikube start --vm-driver=
+```
+
+`minikube start` 가 완료되면, 아래 명령을 실행해서 클러스터의 상태를 확인한다.
+
+```shell
+minikube status
+```
+
+만약 클러스터가 실행 중이면, `minikube status` 의 출력은 다음과 유사해야 한다.
+
+```
+host: Running
+kubelet: Running
+apiserver: Running
+kubeconfig: Configured
+```
+
+Minikube가 선택한 하이퍼바이저와 작동하는지 확인한 후에는, Minikube를 계속 사용하거나 클러스터를 중지할 수 있다. 클러스터를 중지하려면 다음을 실행한다.
+
+```shell
+minikube stop
+```
+
## 새롭게 시작하기 위해 모두 정리하기 {#cleanup-local-state}
이전에 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 27db50cdf1..bcc2543340 100644
--- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
+++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md
@@ -21,7 +21,8 @@ content_template: templates/tutorial
{{% capture prerequisites %}}
-* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
* 예시는 `kubectl` 1.14 이상 버전에서 동작한다.
* [컨피그 맵을 사용해서 컨테이너 설정하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 이해한다.
diff --git a/content/ko/examples/service/networking/curlpod.yaml b/content/ko/examples/service/networking/curlpod.yaml
new file mode 100644
index 0000000000..c15133641f
--- /dev/null
+++ b/content/ko/examples/service/networking/curlpod.yaml
@@ -0,0 +1,28 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: curl-deployment
+spec:
+ selector:
+ matchLabels:
+ app: curlpod
+ replicas: 1
+ template:
+ metadata:
+ labels:
+ app: curlpod
+ spec:
+ volumes:
+ - name: secret-volume
+ secret:
+ secretName: nginxsecret
+ containers:
+ - name: curlpod
+ command:
+ - sh
+ - -c
+ - while true; do sleep 1; done
+ image: radial/busyboxplus:curl
+ volumeMounts:
+ - mountPath: /etc/nginx/ssl
+ name: secret-volume
diff --git a/content/ko/examples/service/networking/nginx-secure-app.yaml b/content/ko/examples/service/networking/nginx-secure-app.yaml
new file mode 100644
index 0000000000..5ef865d52c
--- /dev/null
+++ b/content/ko/examples/service/networking/nginx-secure-app.yaml
@@ -0,0 +1,51 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-nginx
+ labels:
+ run: my-nginx
+spec:
+ type: NodePort
+ ports:
+ - port: 8080
+ targetPort: 80
+ protocol: TCP
+ name: http
+ - port: 443
+ protocol: TCP
+ name: https
+ selector:
+ run: my-nginx
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: my-nginx
+spec:
+ selector:
+ matchLabels:
+ run: my-nginx
+ replicas: 1
+ template:
+ metadata:
+ labels:
+ run: my-nginx
+ spec:
+ volumes:
+ - name: secret-volume
+ secret:
+ secretName: nginxsecret
+ - name: configmap-volume
+ configMap:
+ name: nginxconfigmap
+ containers:
+ - name: nginxhttps
+ image: bprashanth/nginxhttps:1.0
+ ports:
+ - containerPort: 443
+ - containerPort: 80
+ volumeMounts:
+ - mountPath: /etc/nginx/ssl
+ name: secret-volume
+ - mountPath: /etc/nginx/conf.d
+ name: configmap-volume
diff --git a/content/ko/examples/service/networking/nginx-svc.yaml b/content/ko/examples/service/networking/nginx-svc.yaml
new file mode 100644
index 0000000000..12fcd5d0bf
--- /dev/null
+++ b/content/ko/examples/service/networking/nginx-svc.yaml
@@ -0,0 +1,12 @@
+apiVersion: v1
+kind: Service
+metadata:
+ name: my-nginx
+ labels:
+ run: my-nginx
+spec:
+ ports:
+ - port: 80
+ protocol: TCP
+ selector:
+ run: my-nginx
diff --git a/content/ko/examples/service/networking/run-my-nginx.yaml b/content/ko/examples/service/networking/run-my-nginx.yaml
new file mode 100644
index 0000000000..76a879f5c4
--- /dev/null
+++ b/content/ko/examples/service/networking/run-my-nginx.yaml
@@ -0,0 +1,20 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: my-nginx
+spec:
+ selector:
+ matchLabels:
+ run: my-nginx
+ replicas: 2
+ template:
+ metadata:
+ labels:
+ run: my-nginx
+ spec:
+ containers:
+ - name: my-nginx
+ image: nginx
+ ports:
+ - containerPort: 80
+