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

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

Browse Source 
* 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
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/workloads/controllers/deployment.md
+4 -4
View File
@@ -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
```
content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md
+87
View File
@@ -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 %}}
content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+210
View File
@@ -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 %}}