Translate content/ko/docs/concepts/architecture/nodes in Korean #11748

content/ko/_index.html

@@ -10,27 +10,27 @@
 {{% blocks/feature image="flower" %}}
 ### [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다.
 
-It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon [15 years of experience of running production workloads at Google](http://queue.acm.org/detail.cfm?id=2898444), combined with best-of-breed ideas and practices from the community.
+애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다.
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="scalable" %}}
 #### 행성 규모 확장성
 
-Designed on the same principles that allows Google to run billions of containers a week, Kubernetes can scale without increasing your ops team.
+Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준 원칙들에 따라 디자인되었기 때문에, 쿠버네티스는 운영팀의 규모를 늘리지 않고도 확장될 수 있습니다.
 
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="blocks" %}}
 #### 무한한 유연성
 
-Whether testing locally or running a global enterprise, Kubernetes flexibility grows with you to deliver your applications consistently and easily no matter how complex your need is.
+지역적인 테스트든지 글로벌 기업 운영이든지 상관없이, 쿠버네티스의 유연성은 사용자의 복잡한 니즈를 모두 수용하기 때문에 사용자의 애플리케이션들을 끊임없고 쉽게 전달할 수 있습니다.
 
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="suitcase" %}}
 #### 어디서나 동작
 
-Kubernetes is open source giving you the freedom to take advantage of on-premises, hybrid, or public cloud infrastructure, letting you effortlessly move workloads to where it matters to you.
+쿠버네티스는 오픈소스로서 온-프레미스, 하이브리드, 또는 퍼블릭 클라우드 인프라스트럭처를 활용하는데 자유를 제공하며, 워크로드를 사용자에게 관건이 되는 곳으로 손쉽게 이동시켜 줄 수 있습니다. 
 
 {{% /blocks/feature %}}
 

content/ko/docs/concepts/architecture/nodes.md

@@ -18,7 +18,7 @@ weight: 10
 노드의 상태는 다음의 정보를 포함한다.
 
 * [주소](#주소)
-* [컨티션](#컨티션)
+* [컨디션](#컨디션)
 * [용량](#용량)
 * [정보](#정보)
 
@@ -33,7 +33,7 @@ weight: 10
 * InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.
 
 
-### 컨티션
+### 컨디션
 
 `conditions` 필드는 모든 `Running` 노드의 상태를 기술한다.
 
@@ -46,7 +46,7 @@ weight: 10
 | `DiskPressure`    | 디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 `True`, 반대의 경우 `False` |
 | `NetworkUnavailable`    | 노드에 대해 네트워크가 올바르게 구성되지 않은 경우 `True`, 반대의 경우 `False` |
 
-노드 컨티션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다.
+노드 컨디션은 JSON 오브젝트로 표현된다. 예를 들어, 다음 응답은 상태 양호한 노드를 나타낸다.
 
 ```json
 "conditions": [
@@ -56,18 +56,18 @@ weight: 10
   }
 ]
 ```
-ready 컨티션의 상태가 [kube-controller-manager](/docs/admin/kube-controller-manager/)에 인수로 넘겨지는 `pod-eviction-timeout` 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
+ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controller-manager/)에 인수로 넘겨지는 `pod-eviction-timeout` 보다 더 길게 `Unknown` 또는 `False`로 유지되는 경우, 노드 상에 모든 파드는 노드 컨트롤러에 의해 삭제되도록 스케줄 된다. 기본 축출 타임아웃 기간은 **5분** 이다. 노드에 접근이 불가할 때와 같은 경우, apiserver는 노드 상의 kubelet과 통신이 불가하다. apiserver와의 통신이 재개될 때까지 파드 삭제에 대한 결정은 kubelet에 전해질 수 없다. 그 사이, 삭제되도록 스케줄 되어진 파드는 분할된 노드 상에서 계속 동작할 수도 있다.
 
 1.5 이전의 쿠버네티스 버전에서는, 노드 컨트롤러가 apiserver로부터 접근 불가한 이러한 파드를 [강제 삭제](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
-시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과가 이루어진다.
+시킬 것이다. 그러나 1.5 이상에서는, 노드 컨트롤러가 클러스터 내 동작 중지된 것을 확신할 때까지는 파드를 강제로 삭제하지 않는다. 파드가 `Terminating` 또는 `Unknown` 상태로 있을 때 접근 불가한 노드 상에서 동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에 대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로 탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다. 쿠버네티스에서 노드 오브젝트를 삭제하면 노드 상에서 동작중인 모든 파드 오브젝트가 apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳는다.
 
-1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨티션을 나타내는
+1.12 버전에서, `TaintNodesByCondition` 기능은 베타가 되어, 노드 수명주기 컨트롤러는 자동으로 컨디션을 나타내는
 [taints](/docs/concepts/configuration/taint-and-toleration/)를 생성한다. 마찬가지로 스케줄러가 노드를 고려할 때, 노드의 컨디션을 무시한다. 대신 노드의 taint와 toleration을 살펴본다.
 
-현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. 아무런 toleration도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 taint를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
+현재 사용자는 이전 스케줄링 모델과 새롭고 더 유연한 스케줄링 모델 사이에 선택할 수 있다. 아무런 toleration 도 가지지 않는 파드는 이전 모델에 따라 스케줄 되지만, 특정한 노드의 taint 를 용인하는 파드는 노드 상에서 스케줄 될 수 있다.
 
 {{< caution >}}
-이 기능을 활성화 하면 컨티션이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
+이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kuelet에 의해 거부되는 파드의 수가 증가할 수 있다.
 {{< /caution >}}
 
 ### 용량
@@ -111,7 +111,7 @@ ready 컨티션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
 
 두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의 사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서 동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는 해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우, 노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
 
-세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) NodeStatus의 NodeReady 컨티션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. (ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
+세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는 노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트 수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.) NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고, 노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다. (ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
 
 쿠버네티스 1.13 이전 버전에서, NodeStatus는 노드로부터의 하트비트가 된다. 쿠버네티스 1.13을 시작으로 node lease 기능이 알파 기능으로 (기능 게이트 `NodeLease`,
 [KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)) 소개되었다. node lease 기능이 활성화 되면, 각 노드는 주기적으로 노드에 의해 갱신되는 `kube-node-lease` 네임스페이스 내 연관된 `Lease` 오브젝트를 가지고 NodeStatus와 node lease는 둘다 노드로부터의 하트비트로 취급된다. NodeStatus가 오직 일부 변경사항이 있거나 충분한 시간이 지난 경우에만 (기본 1분으로, 접근 불가한 노드에 대한 기본 타임아웃 40초 보다 길다.) 노드에서 마스터로 보고 되는 반면에, Node lease는 자주 갱신된다. 노드 리스가 NodeStatus 보다 더 경량이므로, 이 기능은 확장성과 성능 두 가지 측면에서 노드 하트비트를 상당히 경제적이도록 해준다.
@@ -120,7 +120,7 @@ ready 컨티션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
 
 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다.
 
-노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨티션은 ConditionUnknown 또는 ConditionFalse 다.). 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 `--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
+노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨디션은 ConditionUnknown 또는 ConditionFalse 다.). 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` 기본값 0.55) 가 되면 축출 비율은 감소한다. 클러스터가 작으면 (즉 `--large-cluster-size-threshold` 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, 오직 하나의 가용성 영역만 (전체 클러스터) 존재하게 된다.
 
 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 정상 비율 `--node-eviction-rate`로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다.
 

content/ko/docs/reference/glossary/controller.md

@@ -4,16 +4,16 @@ id: controller
 date: 2018-04-12
 full_link: /docs/admin/kube-controller-manager/
 short_description: >
-  A control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
+  API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프.
 
 aka: 
 tags:
 - architecture
 - fundamental
 ---
- A control loop that watches the shared state of the cluster through the {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}} and makes changes attempting to move the current state towards the desired state.
+ {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프.
 
 <!--more--> 
 
-Examples of controllers that ship with Kubernetes today are the replication controller, endpoints controller, namespace controller, and serviceaccounts controller.
+현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스어카운트 컨트롤러가 있다.
 

content/ko/docs/reference/glossary/etcd.md

@@ -4,16 +4,16 @@ id: etcd
 date: 2018-04-12
 full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/
 short_description: >
-  Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
+  모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.
 
 aka: 
 tags:
 - architecture
 - storage
 ---
- Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
+ 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소.
 
 <!--more--> 
 
-Always have a backup plan for etcd's data for your Kubernetes cluster. For in-depth information on etcd, see [etcd documentation](https://github.com/coreos/etcd/blob/master/Documentation/docs.md).
+쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대해 자세히 알아보려면 [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고하라.
 

content/ko/docs/reference/glossary/kube-apiserver.md

@@ -4,16 +4,15 @@ id: kube-apiserver
 date: 2018-04-12
 full_link: /docs/reference/generated/kube-apiserver/
 short_description: >
-  Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. 
+  쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다.
 
 aka: 
 tags:
 - architecture
 - fundamental
 ---
- Component on the master that exposes the Kubernetes API. It is the front-end for the Kubernetes control plane. 
+ 쿠버네티스 API를 노출하는 마스터 상의 컴포넌트. 쿠버네티스 컨트롤 플레인에 대한 프론트엔드이다.
 
 <!--more--> 
 
-It is designed to scale horizontally -- that is, it scales by deploying more instances. See [Building High-Availability Clusters](/docs/admin/high-availability/).
-
+수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다. [고가용성 클러스터 구축하기](/docs/admin/high-availability/)를 참고하라.