whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seventh Korean l10n work for release 1.18

Browse Source 
- Translate reference/command-line-tools-reference/feature-gates.md int… (#22240)
- Fix issue of broken links to translated docs (#22105)
- Fix issue of document link in some ko documents (#22379)
- Translate tasks/administer-cluster/access-cluster-services.md into Ko… (#21776)
- Fix issue with 'Linux' and 'Windows' notation in Korean docs (#22362)
- Fix issue of broken links to translated docs #2 (#22270)
- Fix issue with k8s.io/ko/docs/concepts/overview/kubernetes-api.md (#22261)
- Fix issue with k8s.io/ko/docs/concepts/overview/working-with-objects/ (#22263)
- Fix incorrect notation of 'directory' into Korean (#22155)
- Fix issue with k8s.io/ko/docs/concepts/overview/components.md (#22232)
- Update outdated files in dev-1.18-ko.7 (#22128)
- Modify spacing term ReplicaSet in Korean (#22148)
- Translate tasks/administer-cluster/extended-resource-node.md into Korean (#21849)
- Translate tasks/administer-cluster/access-cluster-api.md into Korean (#21730)

Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: woopyoung <ywp041@gmail.com>
Co-authored-by: coolguyhong <podolsmith@naver.com>
Co-authored-by: PyungHo Yoon <learder@gmail.com>
Co-authored-by: Seokho Son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Ian Y. Choi <ianyrchoi@gmail.com>
This commit is contained in:
June Yi
2020-07-10 12:38:02 +09:00
parent 2a4923f49a
commit f604a4b60a
148 changed files with 2604 additions and 1350 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/daemonset.md
+2 -2
View File
@@ -54,7 +54,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
`.spec.template` 는 `.spec` 의 필수 필드 중 하나이다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다.
데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야
한다([파드 셀렉터](#파드-셀렉터)를 본다).
@@ -206,7 +206,7 @@ nodeAffinity:
### 스태틱(static) 파드
Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를 생성할 수 있다. 이것을
[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다.
데몬셋과는 다르게 스태틱 파드는 kubectl
또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지
content/ko/docs/concepts/workloads/controllers/deployment.md
+16 -6
View File
@@ -316,7 +316,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이
의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서
`.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다.
결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다.
결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카셋은 0개로 스케일된다.
만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고,
스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다.
@@ -671,7 +671,7 @@ deployment.apps/nginx-deployment scaled
디플로이먼트 컨트롤러는 새로운 5개의 레플리카의 추가를 위한 위치를 결정해야 한다.
만약 비례적 스케일링을 사용하지 않으면 5개 모두 새 레플리카셋에 추가된다.
비례적 스케일링으로 추가 레플리카를 모든 레플리카셋에 걸쳐 분산할 수 있다.
비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카 셋으로 이동한다.
비율이 높을수록 가장 많은 레플리카가 있는 레플리카셋으로 이동하고, 비율이 낮을 수록 적은 레플리카가 있는 레플리카셋으로 이동한다.
남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다.
위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다.
@@ -861,7 +861,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
```
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment.apps/nginx-deployment successfully rolled out
$ echo $?
```
그리고 `kubectl rollout` 의 종료 상태는 0(success)이다.
```shell
echo $?
```
```
0
```
@@ -1003,7 +1008,12 @@ kubectl rollout status deployment.v1.apps/nginx-deployment
```
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
```
그리고 `kubectl rollout` 의 종료 상태는 1(error를 의미함)이다.
```shell
echo $?
```
```
1
```
@@ -1026,7 +1036,7 @@ $ echo $?
## 카나리 디플로이먼트
만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는
[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에
[리소스 관리](/ko/docs/concepts/cluster-administration/manage-deployment/#카나리-canary-디플로이먼트)에
설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다.
## 디플로이먼트 사양 작성
@@ -1035,7 +1045,7 @@ $ echo $?
설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/),
컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다.
디플로이먼트 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
디플로이먼트에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+1 -9
View File
@@ -1,7 +1,7 @@
---
title: 가비지(Garbage) 수집
content_type: concept
weight: 60
weight: 70
---
<!-- overview -->
@@ -10,8 +10,6 @@ weight: 60
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
<!-- body -->
## 소유자(owner)와 종속(dependent)
@@ -170,15 +168,9 @@ kubectl delete replicaset my-repset --cascade=false
## {{% heading "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)
content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md → content/ko/docs/concepts/workloads/controllers/job.md
View File
content/ko/docs/concepts/workloads/controllers/replicaset.md
+5 -7
View File
@@ -223,7 +223,7 @@ pod2 1/1 Running 0 36s
API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다.
레플리카셋 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
레플리카셋도 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)이 필요하다.
@@ -233,7 +233,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한
우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다.
이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다.
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인
템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인
`.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다.
### 파드 셀렉터
@@ -250,7 +250,7 @@ matchLabels:
그렇지 않으면 API에 의해 거부된다.
{{< note >}}
2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카 셋은 다른 레플리카 셋이 생성한 파드를 무시한다.
2개의 레플리카셋이 동일한 `.spec.selector`필드를 지정한 반면, 다른 `.spec.template.metadata.labels`와 `.spec.template.spec` 필드를 명시한 경우, 각 레플리카셋은 다른 레플리카셋이 생성한 파드를 무시한다.
{{< /note >}}
### 레플리카
@@ -307,7 +307,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정
레플리카 셋은
레플리카셋은
[Horizontal Pod Autoscalers (HPA)](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)의 대상이 될 수 있다.
즉, 레플리카셋은 HPA에 의해 오토스케일될 수 있다.
다음은 이전에 만든 예시에서 만든 레플리카셋을 대상으로 하는 HPA 예시이다.
@@ -316,7 +316,7 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
이 매니페스트를 `hpa-rs.yaml`로 저장한 다음 쿠버네티스
클러스터에 적용하면 CPU 사용량에 따라 파드가 복제되는
오토스케일 레플리카 셋 HPA가 생성된다.
오토스케일 레플리카셋 HPA가 생성된다.
```shell
kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml
@@ -361,5 +361,3 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50
이 두 개의 용도는 동일하고, 유사하게 동작하며, 레플리케이션 컨트롤러가 [레이블 사용자 가이드](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)에
설명된 설정-기반의 셀렉터의 요건을 지원하지 않는다는 점을 제외하면 유사하다.
따라서 레플리카셋이 레플리케이션 컨트롤러보다 선호된다.
content/ko/docs/concepts/workloads/controllers/replicationcontroller.md
+3 -3
View File
@@ -114,7 +114,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다.
레플리케이션 컨트롤러 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다.
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
컨피그 파일의 동작에 관련된 일반적인 정보는 다음을 참조하라 [쿠버네티스 오브젝트 관리 ](/ko/docs/concepts/overview/working-with-objects/object-management/).
레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 도 필요하다.
@@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m
`.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다.
`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다.
파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와
중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라.
@@ -255,7 +255,7 @@ API 오브젝트에 대한 더 자세한 것은
[`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/)은 새로운 [집합성 기준 레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#집합성-기준-요건) 이다.
이것은 주로 [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/) 에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카 셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다.
### 디플로이먼트 (권장되는)
content/ko/docs/concepts/workloads/controllers/statefulset.md
+1 -1
View File
@@ -25,7 +25,7 @@ weight: 40
위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다.
만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포,
삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을
삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카셋(ReplicaSet)을
제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다.
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다.
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+3 -3
View File
@@ -1,7 +1,7 @@
---
title: 완료된 리소스를 위한 TTL 컨트롤러
content_type: concept
weight: 65
weight: 70
---
<!-- overview -->
@@ -10,7 +10,7 @@ weight: 65
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재
[잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
{{< glossary_tooltip text="잡(Job)" term_id="job" >}}만
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
@@ -29,7 +29,7 @@ kube-apiserver와 kube-controller-manager와 함께
## TTL 컨트롤러
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
[예시](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리)
[예시](/ko/docs/concepts/workloads/controllers/job/#완료된-잡을-자동으로-정리)
와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),