First Korean l10n work for release-1.15 (#15356)

* Translate concepts/workloads/controllers/replicationcontroller in Korean (#15044) * ko: Update outdated 1.14-ko.4 branch (#15099) * Translate tasks/access-application-cluster/configure-access-multiple-clusters in Korean (#15121) * Translate standardized glossary items in Tag Network into Korean (#15278) * ko: Keep up with upstream - renamed files (#15030) Co-Authored-By: Seokho <shsongist@gmail.com> Co-Authored-By: lapee79 <lapee79@gmail.com> Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com>
kubernetes · Jul 10, 2019 · 113008f · 113008f
1 parent bdf4e5f
commit 113008f
Show file tree

Hide file tree

Showing 53 changed files with 1,776 additions and 824 deletions.
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
@@ -17,14 +17,14 @@ weight: 10
 
 노드의 상태는 다음의 정보를 포함한다.
 
-* [주소](#주소)
-* [컨디션](#컨디션)
-* [용량](#용량)
-* [정보](#정보)
+* [주소](#addresses)
+* [컨디션](#condition)
+* [용량과 할당가능](#capacity)
+* [정보](#info)
 
 각 섹션은 아래 상세하게 기술되었다.
 
-### 주소
+### 주소 {#addresses}
 
 이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다.
 
@@ -33,9 +33,9 @@ weight: 10
 * InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다.
 
 
-### 컨디션
+### 컨디션 {#condition}
 
-`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다.
+`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다.
 
 | Node Condition | Description |
 |----------------|-------------|
@@ -52,7 +52,11 @@ weight: 10
 "conditions": [
   {
     "type": "Ready",
-    "status": "True"
+    "status": "True",
+    "reason": "KubeletReady",
+    "message": "kubelet is posting ready status",
+    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
+    "lastTransitionTime": "2019-06-05T11:41:27Z"
   }
 ]
 ```
@@ -70,11 +74,19 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll
 이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다.
 {{< /caution >}}
 
-### 용량
+### 용량과 할당가능 {#capacity}
 
 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.
 
-### 정보
+용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
+할당가능 블록은 일반 파드에서 사용할 수 있는
+노드의 리소스 양을 나타낸다.
+
+노드에서
+[컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을
+배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자.
+
+### 정보 {#info}
 
 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다.
 

diff --git a/content/ko/docs/concepts/cluster-administration/federation.md b/content/ko/docs/concepts/cluster-administration/federation.md
@@ -170,7 +170,7 @@ zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availabi
 
 마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면, 
 더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은 
-클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다.
+클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/best-practices/cluster-large/)에서 확인 가능하다.
 
 {{% /capture %}}
 

diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
@@ -60,6 +60,8 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전
   - AWS EC2 컨테이너 레지스트리(ECR) 사용
     - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함
     - ECR 로그인 자격 증명은 자동으로 갱신됨
+  - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용
+    - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함
   - Azure 컨테이너 레지스트리(ACR) 사용
   - IBM 클라우드 컨테이너 레지스트리 사용
   - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
@@ -275,19 +277,7 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
 
 ```shell
-cat <<EOF > ./kustomization.yaml
-secretGenerator:
-- name: myregistrykey
-  type: docker-registry
-  literals:
-  - docker-server=DOCKER_REGISTRY_SERVER
-  - docker-username=DOCKER_USER
-  - docker-password=DOCKER_PASSWORD
-  - docker-email=DOCKER_EMAIL
-EOF
-
-kubectl apply -k .
-secret/myregistrykey-66h7d4d986 created
+kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
 ```
 
 만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, 

diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md
@@ -8,7 +8,13 @@ weight: 20
 
 {{< feature-state for_k8s_version="v1.12" state="alpha" >}}
 
-이 페이지는 런타임 클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다.
+
+{{< warning >}}
+런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다.
+런타임클래스를 v1.14 이전부터 사용하고 있었다면,
+[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다.
+{{< /warning >}}
 
 {{% /capture %}}
 
@@ -17,82 +23,72 @@ weight: 20
 
 ## 런타임 클래스
 
-런타임 클래스는 파드의 컨테이너를 실행하는데 사용할 컨테이너 런타임 설정을 선택하기 위한 
-알파 특징이다.
+런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다.
+이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다.
 
-### 셋업
+## 동기
 
-초기 알파 특징이므로, 런타임 클래스 특징을 사용하기 위해서는 몇 가지 추가 셋업 
-단계가 필요하다.
+서로 다른 파드간에 런타임 클래스를 설정하여
+성능대 보안의 균형을 유지할 수 있다.
+예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우,
+하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다.
+그러면 몇가지 추가적인 오버헤드는 있지만
+대체 런타임을 추가 분리하는 유익이 있다.
 
-1. 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요)
-2. 런타임 클래스 CRD 설치
-3. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
-4. 상응하는 런타임 클래스 리소스 생성
+또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른
+여러 파드를 실행할 수 있다.
 
-#### 1. 런타임 클래스 특징 게이트 활성화
+### 셋업
 
+RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다.
 특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
-참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 
-한다.
-
-#### 2. 런타임 클래스 CRD 설치
+참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다.
 
-런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수 
-있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd]
+1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서)
+2. 상응하는 런타임 클래스 리소스 생성
 
-`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다.
+#### 1. CRI 구현을 노드에 설정
 
-[CustomResourceDefinition]: /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
-[runtimeclass_crd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml
-
-
-#### 3. CRI 구현을 노드에 설정
-
-런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI 
-구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파 
-특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다.
+런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다.
+사용자의 CRI 구현에 따른 설정 방법은
+연관된 문서를 통해서 확인한다([아래](#cri-configuration)).
 
 {{< note >}}
 런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정
-(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 
-설정)이라도 
-스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([파드를 노드에 
-할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
+(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한
+설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다
+([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고).
 {{< /note >}}
 
-해당 설정은 상응하는 `RuntimeHandler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
+해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다.
 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다.
 
-#### 4. 상응하는 런타임 클래스 리소스 생성
+#### 2. 상응하는 런타임 클래스 리소스 생성
 
-3단계에서 셋업 한 설정은 연관된 `RuntimeHandler` 이름을 가져야 하며, 이를 통해서 
-설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 
-상응하는 런타임 클래스 오브젝트를 생성한다.
+1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다.
+각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다.
 
 현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러
-(`spec.runtimeHandler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
+(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다.
 
 ```yaml
-apiVersion: node.k8s.io/v1alpha1  # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
+apiVersion: node.k8s.io/v1beta1  # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음
 kind: RuntimeClass
 metadata:
   name: myclass  # 런타임 클래스는 해당 이름을 통해서 참조됨
   # 런타임 클래스는 네임스페이스가 없는 리소스임
-spec:
-  runtimeHandler: myconfiguration  # 상응하는 CRI 설정의 이름임
+handler: myconfiguration  # 상응하는 CRI 설정의 이름임
 ```
 
-
 {{< note >}}
 런타임 클래스 쓰기 작업(create/update/patch/delete)은
-클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 
-개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
+클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다.
+더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다.
 {{< /note >}}
 
 ### 사용
 
-클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 
+클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에
 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다.
 
 ```yaml
@@ -105,12 +101,75 @@ spec:
   # ...
 ```
 
-이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 
-런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 
-`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 
-메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 
+이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
+만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
+`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
+에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
 확인한다.
 
-만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용될 것이다. 기본 런타임 핸들러는 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며,
+런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다.
+
+### CRI 구성 {#cri-configuration}
+
+CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다.
+
+#### dockershim
+
+쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다.
+
+#### [containerd](https://containerd.io/)
+
+런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다.
+유효한 핸들러는 runtimes 단락 아래에서 설정한다.
+
+```
+[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+```
+
+더 자세한 containerd의 구성 문서를 살펴본다.
+https://github.com/containerd/cri/blob/master/docs/config.md
+
+#### [cri-o](https://cri-o.io/)
+
+런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다.
+[crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에
+유효한 핸들러를 설정한다.
+
+```
+[crio.runtime.runtimes.${HANDLER_NAME}]
+  runtime_path = "${PATH_TO_BINARY}"
+```
+
+더 자세한 cri-o의 구성 문서를 살펴본다.
+https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go
+
+
+### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta}
+
+런타임 클래스 베타 기능은 다음의 변화를 포함한다.
+
+- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서
+  내장 API로 이전되었다.
+- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다.
+  (즉, 더 이상 RuntimeClassSpec는 없다).
+- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다.
+- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가
+  필요하다는 의미이다.
+- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로,
+  이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는
+  다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`.
+
+**작업 필요** 다음 작업은 알파 버전의 런타임 기능을
+베타 버전으로 업그레이드하기 위해 진행되어야 한다.
+
+- 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고,
+  `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다.
+  ```
+  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
+  ```
+- 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는
+  더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다
+  (위를 참조).
 
 {{% /capture %}}
diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md
@@ -16,7 +16,7 @@ card:
 ## 마스터 컴포넌트
 
 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정
-(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
+(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다.
 
 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나,
 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고,
@@ -72,13 +72,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드
 
 ### kube-proxy
 
-[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서
- 쿠버네티스 서비스 추상화가 가능하도록 해준다.
+{{< glossary_definition term_id="kube-proxy" length="all" >}}
 
 ### 컨테이너 런타임
 
-컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
-쿠버네티스는 몇몇의 런타임을 지원하는데 [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)를 구현한 모든 런타임이다.
+{{< glossary_definition term_id="container-runtime" length="all" >}}
 
 ## 애드온