kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

modify: M97, M95, M96

pull/35484/head
onestone9900 2022-07-27 20:48:32 +09:00
parent 22194189ed
commit b436f64e02
3 changed files with 77 additions and 134 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

134
content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
View File

@ -7,38 +7,38 @@ weight: 40
<!-- overview -->
본 페이지는 파드가
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)을 사용하여
[`downwardAPI` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)을 사용하여
파드에서 실행되는 컨테이너에 자신에 대한 정보를 노출하는 방법에 대해 설명한다.
`DownwardAPIVolumeFile`은 파드 필드와 컨테이너 필드를 노출할 수 있다.
`downwardAPI` 볼륨은 파드 필드와 컨테이너 필드를 노출할 수 있다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## 다운워드(Downward) API
실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
쿠버네티스에는 실행 중인 컨테이너에 파드 필드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다.
* [환경 변수](/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#다운워드-downward-api)
* 볼륨 파일
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을
"다운워드 API"라고 한다.
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을
_downward API_ 라고 한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 파드 필드 저장
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다.
다음은 파드에 대한 구성 파일이다.
이 연습에서는 컨테이너가 한 개 있는 파드를 생성하고, 해당 파드의
파드 수준(Pod-level) 필드를 실행 중인 컨테이너에 파일 형태로 생성한다.
다음은 파드를 위한 매니페스트를 보여준다.
{{< codenew file="pods/inject/dapi-volume.yaml" >}}
구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는
것을 확인할 수 있다.
매니페스트에서, 파드에 `downwardAPI` 볼륨이 있고,
컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는 것을 확인할 수 있다.
`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는
[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는
`downwardAPI` 볼륨을 의미한다.
첫 번째 요소는 파드의 `metadata.labels` 필드 값이
`labels`라는 파일에 저장되어야 함을 지정한다.
두 번째 요소는 파드의 `annotations` 필드 값이
@ -69,7 +69,7 @@ kubectl logs kubernetes-downwardapi-volume-example
출력은 `labels` 파일과 `annotations` 파일의 내용을 보여준다.
```shell
```
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"
@ -147,24 +147,25 @@ total 8
## 컨테이너 필드 저장
이전 연습에서는 파드 필드를
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)에 저장하였다.
이 다음 연습에서는 컨테이너 필드를 저장한다.
다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
이전 연습에서는 downward API를 사용하여 파드 수준 필드에 액세스할 수
있도록 했다.
이번 연습에서는 파드 전체가 아닌 특정
[컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)의
일부 필드만 전달한다. 다음은 기존과 마찬가지로 하나의
컨테이너만 가진 파드의 매니페스트를
보여준다.
{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
구성 파일에서 파드에 [`downwardAPI` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)이 있고
컨테이너는 `/etc/podinfo`에
매니페스트에서 파드에 [`downwardAPI` 볼륨](/ko/docs/concepts/storage/volumes/#downwardapi)이 있고
단일 컨테이너는 `/etc/podinfo`에
볼륨을 마운트하는 것을 확인할 수 있다.
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는
[`DownwardAPIVolumeFile`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 downward API 볼륨의 파일을 의미한다.
첫 번째 요소는 `client-container`라는 컨테이너에서
`1m`으로 지정된 형식의 `limits.cpu` 필드 값이
`cpu_limit`이라는 파일에 저장되어야 함을 지정한다. `divisor` 필드는 선택 사항이며
기본값인 `1`은 CPU에 대한 코어 및 메모리에 대한 바이트를 의미한다.
`cpu_limit`이라는 파일에 배포되어야 함을 지정한다. `divisor` 필드는 선택 사항이다. divisor 1은 `cpu` 리소스를 위한 코어 수를 의미하거나 `memory` 리소스에 대한 바이트 수를 의미한다.
파드를 생성한다.
@ -181,7 +182,8 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
셸에서 `cpu_limit` 파일을 확인한다.
```shell
/# cat /etc/podinfo/cpu_limit
# 컨테이너 내부의 쉘에서 실행하자.
cat /etc/podinfo/cpu_limit
```
비슷한 명령을 통해 `cpu_request`, `mem_limit` 및
@ -189,79 +191,19 @@ kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
<!-- discussion -->
<!-- TODO: This section should be extracted out of the task page. -->
## 다운워드 API의 기능
다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해
컨테이너에서 사용할 수 있다.
* `fieldRef`를 통해 다음 정보를 사용할 수 있다.
* `metadata.name` - 파드의 이름
* `metadata.namespace` - 파드의 네임스페이스(Namespace)
* `metadata.uid` - 파드의 UID
* `metadata.labels['<KEY>']` - 파드의 레이블 `<KEY>` 값
(예를 들어, `metadata.labels['mylabel']`)
* `metadata.annotations['<KEY>']` - 파드의 어노테이션 `<KEY>` 값
(예를 들어, `metadata.annotations['myannotation']`)
* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다.
* 컨테이너의 CPU 한도(limit)
* 컨테이너의 CPU 요청(request)
* 컨테이너의 메모리 한도(limit)
* 컨테이너의 메모리 요청(request)
* 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages`
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages`
[기능 게이트(feature gate)](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
* 컨테이너의 임시-스토리지 한도(limit)
* 컨테이너의 임시-스토리지 요청(request)
`downwardAPI` 볼륨 `fieldRef`를 통해
다음 정보를 사용할 수 있다.
* `metadata.labels` - 한 줄에 하나의 레이블이 있는
`label-key="escaped-label-value"` 형식의 모든 파드 레이블
* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는
`annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
환경 변수를 통해 다음 정보를 사용할 수 있다.
* `status.podIP` - 파드의 IP 주소
* `spec.serviceAccountName` - 파드의 서비스 계정 이름
* `spec.nodeName` - 스케줄러가 항상 파드를 스케줄링하려고 시도할
노드의 이름
* `status.hostIP` - 파드가 할당될 노드의 IP 주소
{{< note >}}
컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로
CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
{{< /note >}}
## 특정 경로 및 파일 권한에 대한 프로젝트 키
키(key)를 파드 안의 특정 경로에, 특정 권한으로, 파일 단위로 투영(project)할 수 있다.
자세한 내용은
[시크릿(Secrets)](/ko/docs/concepts/configuration/secret/)을 참조한다.
## 다운워드 API에 대한 동기
컨테이너가 쿠버네티스에 과도하게 결합되지 않고
자체에 대한 정보를 갖는 것이 때때로 유용하다.
다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고
자체 또는 클러스터에 대한 정보를 사용할 수 있다.
예를 들어 잘 알려진 특정 환경 변수에 고유 식별자가 있다고 가정하는
기존 애플리케이션이 있다. 한 가지 가능성은 애플리케이션을 래핑하는 것이지만
이는 지루하고 오류가 발생하기 쉬우며 낮은 결합 목표를 위반한다.
더 나은 옵션은 파드의 이름을 식별자로 사용하고
파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다.
## {{% heading "whatsnext" %}}
* 파드의 목표 상태(desired state)를 정의하는
[`PodSpec`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) API 정의를 확인한다.
* [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)을 읽어보자.
파드에 대한 API 정의다. 여기에는 컨테이너 (파드의 일부)의 정의가 포함되어 있다.
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/docs/concepts/workloads/pods/downward-api/#available-fields) 목록을 읽어보자.
레거시 API 레퍼런스에서 볼륨에 대해 읽어본다.
* 컨테이너가 접근할 파드 내의 일반 볼륨을 정의하는
[`Volume`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core) API 정의를 확인한다.
* 다운워드 API 정보를 포함하는 볼륨을 정의하는

56
content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
View File

@ -6,40 +6,31 @@ weight: 30
<!-- overview -->
본 페이지는 파드에서 실행 중인 컨테이너에게 파드가 환경 변수를 사용해서 자신의 정보를 노출하는 방법에
대해 설명한다. 환경 변수는 파드 필드와 컨테이너 필드를 노출할 수 있다.
본 페이지는 파드가 환경 변수를 사용하여 _downward API_ 로 파드 내부의 컨테이너 정보를 노출하는 방법에
대해 설명한다.
환경 변수를 사용하여 파드 필드, 컨테이너 필드 또는 둘 다 노출할 수 있다.
쿠버네티스에는 실행 중인 컨테이너에 파드 필드 및 컨테이너 필드를 노출하는 두 가지 방법이 있다.
* _환경 변수_ (본 태스크에 설명이 있음)
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api)
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 downward API라고 한다.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
{{< include "task-tutorial-prereqs.md" >}}
<!-- steps -->
## 다운워드(Downward) API
파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
* 환경 변수
* [볼륨 파일](/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#다운워드-downward-api)
파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
## 파드 필드를 환경 변수의 값으로 사용하자
이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. 다음은 파드에 대한 구성 파일이다.
이 연습에서 하나의 컨테이너가 있는 파드와 파드 수준의 필드를 실행 중인 컨테이너의 환경변수로 생성한다.
{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
구성 파일에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다.
매니페스트에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는
환경 변수 정의의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다.
{{< note >}}
이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
@ -54,6 +45,7 @@ kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
파드의 컨테이너가 실행중인지 확인한다.
```shell
# 새 파드가 아직 정상 상태가 아니면, 이 명령을 몇 번 다시 실행한다.
kubectl get pods
```
@ -85,7 +77,8 @@ kubectl exec -it dapi-envars-fieldref -- sh
셸에서 환경 변수를 보자.
```shell
/# printenv
# 컨테이너 내부의 쉘에서 실행하자.
printenv
```
출력은 특정 환경 변수에 파드 필드 값이 할당되었음을 보여준다.
@ -103,14 +96,15 @@ MY_POD_NAME=dapi-envars-fieldref
## 컨테이너 필드를 환경 변수의 값으로 사용하기
이전 연습에서는 파드 필드를 환경 변수의 값으로 사용했다. 이 다음 연습에서는 컨테이너 필드를
환경 변수의 값으로 사용한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다.
이전 연습에서 파드 수준 필드의 정보를 환경 변수의 값으로 사용했다. 이번 연습에서는 파드 전체가 아닌 특정 [컨테이너](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)의 일부 필드만 전달한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다.
여기, 다시 하나의 컨테이너만 가진 파드를 위한 매니페스트가 있다.
{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
구성 파일에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는
[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의
`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 컨테이너 필드에서
매니페스트에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는
환경 변수 정의의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의
`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 특정 컨테이너 필드에서
값을 가져온다.
파드를 생성한다.
@ -122,6 +116,7 @@ kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
파드의 컨테이너가 실행중인지 확인한다.
```shell
# 새 파드가 아직 정상 상태가 아니면, 이 명령을 몇 번 다시 실행한다.
kubectl get pods
```
@ -140,12 +135,15 @@ kubectl logs dapi-envars-resourcefieldref
67108864
```
## {{% heading "whatsnext" %}}
* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)를 읽어보자.
* [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)을 읽어보자.
파드에 대한 API 정의다. 여기에는 컨테이너 (파드의 일부)의 정의가 포함되어 있다.
* downward API를 사용하여 노출할 수 있는 [이용 가능한 필드](/docs/concepts/workloads/pods/downward-api/#available-fields) 목록을 읽어보자.
레거시 API 레퍼런스에서 파드, 컨테이너 및 환경 변수에 대해 읽어본다.
* [컨테이너를 위한 환경 변수 정의하기](/ko/docs/tasks/inject-data-application/define-environment-variable-container/)
* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)

21
content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md
View File

@ -36,10 +36,10 @@ weight: 10
<!-- steps -->
## 크론 잡 생성
## 크론잡(CronJob) 생성 {#creating-a-cron-job}
크론 잡은 구성 파일이 필요하다.
아래의 크론 잡 구성 `.spec` 파일의 예제는 매 분마다 현재 시간과 hello 메시지를 출력한다.
다음은 1분마다 간단한 데모 작업을 실행하는 크론잡 매니페스트다.
{{< codenew file="application/job/cronjob.yaml" >}}
@ -59,6 +59,7 @@ cronjob.batch/hello created
```shell
kubectl get cronjob hello
```
출력 결과는 다음과 비슷하다.
```
@ -87,6 +88,7 @@ hello-4111706356 1/1 5s 5s
```shell
kubectl get cronjob hello
```
출력 결과는 다음과 비슷하다.
```
@ -94,7 +96,9 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 50s 75s
```
크론 잡 `hello` 가 `LAST SCHEDULE` 에 지정된 시간에 성공적으로 잡을 스케줄했는지 확인해야 한다. 현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
크론 잡 `hello` 가 지정된 시간에 성공적으로 잡을 스케줄했는지
`LAST SCHEDULE`에서 확인해야 한다.
현재는 0개의 활성 잡이 있고, 이는 작업이 완료되었거나 실패했음을 의미한다.
이제, 마지막으로 스케줄된 잡이 생성한 파드를 찾고 생성된 파드 중 하나의 표준 출력을 확인한다.
@ -118,7 +122,7 @@ Fri Feb 22 11:02:09 UTC 2019
Hello from the Kubernetes cluster
```
## 크론 잡 삭제
## 크론잡(CronJob) 삭제 {#deleting-a-cron-job}
더 이상 크론 잡이 필요하지 않으면, `kubectl delete cronjob <cronjob name>` 명령을 사용해서 삭제한다.
@ -129,16 +133,15 @@ kubectl delete cronjob hello
크론 잡을 삭제하면 생성된 모든 잡과 파드가 제거되고 추가 잡 생성이 중지된다.
[가비지(garbage) 수집](/ko/docs/concepts/architecture/garbage-collection/)에서 잡 제거에 대해 상세한 내용을 읽을 수 있다.
## 크론 잡 명세 작성
## 크론잡(CronJob) 명세 작성 {#writing-a-cron-job-spec}
다른 모든 쿠버네티스 구성과 마찬가지로, 크론 잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 구성 파일
작업에 대한 일반적인 정보는 [애플리케이션 배포](/ko/docs/tasks/run-application/run-stateless-application-deployment/)와
다른 모든 쿠버네티스 오브젝트들과 마찬가지로, 크론잡은 `apiVersion`, `kind` 그리고 `metadata` 필드가 반드시 필요하다. Kubernetes 개체 작업과 {{< glossary_tooltip text="매니페스트" term_id="manifest" >}} 대한 자세한 내용은 [리소스 관리하기](/ko/docs/concepts/cluster-administration/manage-deployment/)와
[kubectl을 사용하여 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다.
크론 잡 구성에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다.
크론잡(CronJob)의 각 매니페스트에는 [`.spec`](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#오브젝트-명세-spec-와-상태-status) 섹션도 필요하다.
{{< note >}}
크론 잡, 특히 해당 잡의 `.spec` 에 대한 모든 수정 사항은 다음 번 실행에만 적용된다.
크론잡(CrontJob)을 수정한 경우, 수정 후 새로 실행하는 작업부터 적용된다. 이미 시작된 작업(및 해당 파드)은 변경 없이 계속 실행된다. 즉, 크론잡(CrontJob)은 기존 작업이 계속 실행 중이라면, 작업을 변경하지 _않는다._
{{< /note >}}
### 스케줄