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:
committed by
Kubernetes Prow Robot
parent
ab5ef4d4ec
commit
3c3831592e
@@ -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 %}}
|
||||
Reference in New Issue
Block a user