Forth Korean l10n work for release-1.16 (#17481)

* Translate workloads/controllers/ttlafterfinished.md in Korean. (#17241)
* Update Korean l10n guide (#17402)
* Translate tasks/manage-kubernetes-objects/kustomization in Korean (#17225)
* Update file outdated korean docs in dev-1.16-ko.4 (#17235)
* Translate concepts/workloads/pods/ephemeral-containers.md in Korean. (#16630)

Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com>
Co-Authored-By: Cheolgu Kim <lapee79@gmail.com>
Co-Authored-By: June Yi <gochist@gmail.com>
Co-Authored-By: Seokho Son <shsongist@gmail.com>
This commit is contained in:
Seokho Son
2019-11-08 16:22:44 +09:00
committed by Kubernetes Prow Robot
parent ab5ef4d4ec
commit 3c3831592e
18 changed files with 1243 additions and 79 deletions
@@ -226,7 +226,7 @@ rules:
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [DigitalOcean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
@@ -88,17 +88,17 @@ weight: 80
있다.
다음의 가이드는 일부 리소스에 대해서 자세히 설명한다.
* [클러스터](/docs/tasks/administer-federation/cluster/)
* [컨피그 맵](/docs/tasks/administer-federation/configmap/)
* [데몬 셋](/docs/tasks/administer-federation/daemonset/)
* [디플로이먼트](/docs/tasks/administer-federation/deployment/)
* [이벤트](/docs/tasks/administer-federation/events/)
* [Hpa](/docs/tasks/administer-federation/hpa/)
* [인그레스](/docs/tasks/administer-federation/ingress/)
* [](/docs/tasks/administer-federation/job/)
* [네임스페이스](/docs/tasks/administer-federation/namespaces/)
* [레플리카 셋](/docs/tasks/administer-federation/replicaset/)
* [시크릿](/docs/tasks/administer-federation/secret/)
* [클러스터](/docs/tasks/federation/administer-federation/cluster/)
* [컨피그 맵](/docs/tasks/federation/administer-federation/configmap/)
* [데몬 셋](/docs/tasks/federation/administer-federation/daemonset/)
* [디플로이먼트](/docs/tasks/federation/administer-federation/deployment/)
* [이벤트](/docs/tasks/federation/administer-federation/events/)
* [Hpa](/docs/tasks/federation/administer-federation/hpa/)
* [인그레스](/docs/tasks/federation/administer-federation/ingress/)
* [](/docs/tasks/federation/administer-federation/job/)
* [네임스페이스](/docs/tasks/federation/administer-federation/namespaces/)
* [레플리카 셋](/docs/tasks/federation/administer-federation/replicaset/)
* [시크릿](/docs/tasks/federation/administer-federation/secret/)
* [서비스](/docs/concepts/cluster-administration/federation-service-discovery/)
@@ -6,12 +6,14 @@ weight: 20
{{% capture overview %}}
쿠버네티스 REST API의 모든 오브젝트는 이름과 UID로 명백히 식별된다.
클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 [_이름_](#names) 을 가지고 있다.
또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 [_UID_](#uids) 를 가지고 있다.
예를 들어, 이름이 “myapp-1234”인 파드는 하나만 가질 수 있지만, 이름이 “myapp-1234”인
파드와 디플로이먼트는 각각 가질 수 있다.
유일하지 않은 사용자 제공 속성에 대해서, 쿠버네티스는 [레이블](/docs/user-guide/labels)과 [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)을 제공한다.
이름과 UID에 대한 정확한 구문 규칙은 [식별자 설계 문서](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)를 참고한다.
{{% /capture %}}
@@ -23,7 +25,7 @@ weight: 20
관례에 따라, 쿠버네티스 리소스의 이름은 최대 253자까지 허용되고 소문자 알파벳과 숫자(alphanumeric), `-`, 그리고 `.`로 구성되며 특정 리소스는 보다 구체적인 제약을 갖는다.
다음은 이름이 `nginx-demo`이고 컨테이너 이름이 `nginx`인 파드의 구성 파일 예시이다.
여기 파드의 이름이 `nginx-demo`라는 매니페스트 예시가 있다.
```yaml
apiVersion: v1
@@ -38,8 +40,19 @@ spec:
- containerPort: 80
```
{{< note >}}
일부 리소스 유형은 이름에 추가적인 제약이 있다.
{{< /note >}}
## UID {#uids}
{{< glossary_definition term_id="uid" length="all" >}}
쿠버네티스 UID는 보편적으로 고유한 식별자이다(또는 UUID라고 한다).
UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
{{% /capture %}}
{{% capture whatsnext %}}
* 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기.
* [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기.
{{% /capture %}}
@@ -156,24 +156,24 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와
```shell
kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
```
또는 간단하게 다음의 명령어를 사용한다.
또는 간단하게 다음의 명령어를 사용한다.
```shell
kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record
```
이와 유사하게 출력된다.
이와 유사하게 출력된다.
```
deployment.apps/nginx-deployment image updated
```
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다.
대안으로 디플로이먼트를 `edit` 해서 `.spec.template.spec.containers[0].image` 를 `nginx:1.7.9` 에서 `nginx:1.9.1` 로 변경한다.
```shell
kubectl edit deployment.v1.apps/nginx-deployment
```
이와 유사하게 출력된다.
이와 유사하게 출력된다.
```
deployment.apps/nginx-deployment edited
```
@@ -0,0 +1,87 @@
---
title: 완료된 리소스를 위한 TTL 컨트롤러
content_template: templates/concept
weight: 65
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을
제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재
[잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만
처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를
처리하도록 확장될 수 있다.
알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고
[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)
`TTLAfterFinished` 를 통해 활성화 될 수 있다.
{{% /capture %}}
{{% capture body %}}
## TTL 컨트롤러
현재의 TTL 컨트롤러는 잡만 지원한다. 클러스터 운영자는
[예시](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
와 같이 `.spec.ttlSecondsAfterFinished` 필드를 명시하여
완료된 잡(`완료` 또는 `실패`)을 자동으로 정리하기 위해 이 기능을 사용할 수 있다.
리소스의 작업이 완료된 TTL 초(sec) 후 (다른 말로는, TTL이 만료되었을 때),
TTL 컨트롤러는 해당 리소스가 정리될 수 있다고 가정한다.
TTL 컨트롤러가 리소스를 정리할때 리소스를 연속적으로 삭제한다. 즉,
의존하는 오브젝트와 함께 삭제한다. 리소스가 삭제되면 완료자(finalizers)와
같은 라이프 사이클 보증이 적용 된다.
TTL 초(sec)는 언제든지 설정이 가능하다. 여기에 잡 필드 중
`.spec.ttlSecondsAfterFinished` 를 설정하는 몇 가지 예시가 있다.
* 작업이 완료된 다음, 일정 시간 후에 자동으로 잡이 정리될 수 있도록
리소스 메니페스트에 이 필드를 지정한다.
* 이미 완료된 기존 리소스에 이 새 기능을 적용하기 위해서 이 필드를
설정한다.
* [어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
을 사용해서
리소스 생성시 이 필드를 동적으로 설정 한다. 클러스터 관리자는 이것을
사용해서 완료된 리소스에 대해 TTL 정책을 적용할 수 있다.
* 리소스가 완료된 이후에
[어드미션 웹후크 변형](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
을 사용해서 이 필드를 동적으로 설정하고, 리소스의 상태,
레이블 등에 따라 다른 TTL 값을 선택한다.
## 경고
### TTL 초(sec) 업데이트
TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는
리소스를 생성하거나 완료한 후에 수정할 수 있다. 그러나, 잡을
삭제할 수 있게 되면(TTL이 만료된 경우) 시스템은 TTL을 연장하기
위한 업데이트가 성공적인 API 응답을 리턴하더라도
작업이 유지되도록 보장하지 않는다.
### 시간 차이(Skew)
TTL 컨트롤러는 쿠버네티스 리소스에
저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의
시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스
오브젝트를 정리하게 될 수 있다.
쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드
([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다)
에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는
아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다.
{{% /capture %}}
{{% capture whatsnext %}}
[자동으로 잡 정리](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
@@ -0,0 +1,210 @@
---
title: 임시(Ephemeral) 컨테이너
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
{{< feature-state state="alpha" >}}
이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서
임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
컨테이너를 사용한다.
{{< warning >}}
임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는
적합하지 않다. 사용자는 컨테이너 네임스페이스를 대상으로 하는 경우와
같은 어떤 상황에서 기능이 작동하지 않을 것으로 예상해야 한다. [쿠버네티스
사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파
기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
{{< /warning >}}
{{% /capture %}}
{{% capture body %}}
## 임시 컨테이너 이해하기
{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의
기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기
때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다.
대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를
사용해서 제어하는 방식으로 파드를 삭제하고 교체한다.
그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해
기존 파드의 상태를 검사해야할 수 있다. 이 경우 사용자는
기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을
실행할 수 있다.
### 임시 컨테이너는 무엇인가?
임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서
다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서
애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는
일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가
호환되지 않으며 임시 컨테이너에는 허용되지 않는다.
- 임시 컨테이너는 포트를 가지지 않을 수 있으므로, `ports`,
`livenessProbe`, `readinessProbe` 와 같은 필드는 허용되지 않는다.
- 파드에 할당된 리소스는 변경할 수 없으므로, `resources` 설정이 허용되지 않는다.
- 허용되는 필드의 전체 목록은 [임시컨테이너 참조
문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core)를 본다.
임시 컨테이너는 `pod.spec` 에 직접 추가하는 대신
API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지기 때문에
`kubectl edit`을 사용해서 임시 컨테이너를 추가할 수 없다.
일반 컨테이너와 마찬가지로, 사용자는 임시 컨테이너를 파드에 추가한
이후에 변경하거나 제거할 수 없다.
## 임시 컨테이너의 사용
임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에
디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때
대화형 문제 해결에 유용하다.
특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless)
를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의
컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를
포함하지 않기 때문에, `kubectl exec` 만으로는 distroless
이미지의 문제 해결이 어렵다.
임시 컨테이너 사용시 [프로세스 네임스페이스
공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
### 예시
{{< note >}}
이 섹션의 예시는 `EphemeralContainers` [기능
게이트](/docs/reference/command-line-tools-reference/feature-gates/)를
활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
{{< /note >}}
이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지
보여준다. 사용자는 일반적으로 자동화하는 단계의 문제 해결을 위해 `kubectl`
플러그인을 사용했을 것이다.
임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
```json
{
"apiVersion": "v1",
"kind": "EphemeralContainers",
"metadata": {
"name": "example-pod"
},
"ephemeralContainers": [{
"command": [
"sh"
],
"image": "busybox",
"imagePullPolicy": "IfNotPresent",
"name": "debugger",
"stdin": true,
"tty": true,
"terminationMessagePolicy": "File"
}]
}
```
이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
```shell
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
```
그러면 새로운 임시 컨테이너 목록이 반환된다.
```json
{
"kind":"EphemeralContainers",
"apiVersion":"v1",
"metadata":{
"name":"example-pod",
"namespace":"default",
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
"resourceVersion":"15886",
"creationTimestamp":"2019-08-29T06:41:42Z"
},
"ephemeralContainers":[
{
"name":"debugger",
"image":"busybox",
"command":[
"sh"
],
"resources":{
},
"terminationMessagePolicy":"File",
"imagePullPolicy":"IfNotPresent",
"stdin":true,
"tty":true
}
]
}
```
사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
```shell
kubectl describe pod example-pod
```
```
...
Ephemeral Containers:
debugger:
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
Image: busybox
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
Port: <none>
Host Port: <none>
Command:
sh
State: Running
Started: Thu, 29 Aug 2019 06:42:21 +0000
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
```
사용자는 `kubectl attach` 를 사용해서 새로운 임시 컨테이너에 붙을 수 있다.
```shell
kubectl attach -it example-pod -c debugger
```
만약 프로세스 네임스페이스를 공유를 활성화하면, 사용자는 해당 파드 안의 모든 컨테이너의 프로세스를 볼 수 있다.
예를 들어, 임시 컨테이너에 붙은 이후에 디버거 컨테이너에서 `ps` 를 실행한다.
```shell
ps auxww
```
다음과 유사하게 출력된다.
```
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 101 0:00 nginx: worker process
13 101 0:00 nginx: worker process
14 101 0:00 nginx: worker process
15 101 0:00 nginx: worker process
16 101 0:00 nginx: worker process
17 101 0:00 nginx: worker process
18 101 0:00 nginx: worker process
19 root 0:00 /pause
24 root 0:00 sh
29 root 0:00 ps auxww
```
{{% /capture %}}