From 4518c983d224f9e63f86c6d347ca9abd52080af1 Mon Sep 17 00:00:00 2001 From: June Yi Date: Thu, 8 Aug 2019 23:33:19 +0900 Subject: [PATCH] Third Korean l10n work for release-1.15 (#15744) * Add Link /docs/reference/ in Korean (#15610) * Translate tasks/debug-application-cluster/resource-usage-monitoring in Korean (#15593) * Translate tasks/inject-data-application/define-environment-variable-container in Korean (#15606) * ko: Update outdated files in dev-1.15-ko.3 (#15605) * Translate home/supported-doc-version in Korean (#15621) * ko: Update some files in reference/glossary (#15631) * Translate reference/glossary/cloud-provider.md in Korean (#15685) * Translate docs/reference/using-api/api-overview in Korean (#15644) * Translate tasks/debug-application-cluster/resource-metrics-pipeline in Korean (#15665) Co-Authored-By: June Yi Co-Authored-By: Seokho Co-Authored-By: Tim Bannister Co-authored-by: Yoon Co-authored-by: JiMyung Lee Co-authored-by: lapee79 Co-authored-by: Sunghoon Kang Co-authored-by: Yuk, Yongsu Co-authored-by: Lawrence Kay --- content/ko/docs/concepts/_index.md | 2 +- .../ko/docs/concepts/overview/components.md | 10 +- .../controllers/replicationcontroller.md | 4 +- .../workloads/pods/init-containers.md | 252 ++++++++------- .../docs/concepts/workloads/pods/podpreset.md | 3 +- content/ko/docs/contribute/participating.md | 28 +- .../ko/docs/home/supported-doc-versions.md | 28 ++ content/ko/docs/reference/_index.md | 4 +- .../docs/reference/glossary/cloud-provider.md | 17 + content/ko/docs/reference/glossary/cluster.md | 12 +- .../reference/glossary/container-runtime.md | 2 +- .../ko/docs/reference/glossary/daemonset.md | 12 +- .../ko/docs/reference/glossary/deployment.md | 10 +- .../docs/reference/glossary/init-container.md | 10 +- .../ko/docs/reference/glossary/limitrange.md | 8 +- .../ko/docs/reference/glossary/static-pod.md | 4 +- .../ko/docs/reference/kubectl/cheatsheet.md | 2 +- content/ko/docs/reference/using-api/_index.md | 5 + .../docs/reference/using-api/api-overview.md | 111 +++++++ content/ko/docs/setup/_index.md | 3 + .../tasks/debug-application-cluster/_index.md | 5 + .../resource-metrics-pipeline.md | 53 +++ .../resource-usage-monitoring.md | 116 +++++++ .../tasks/inject-data-application/_index.md | 5 + .../define-environment-variable-container.md | 120 +++++++ .../tutorials/kubernetes-basics/_index.html | 2 + .../basic-stateful-set.md | 306 +++++++++--------- content/ko/examples/pods/inject/envars.yaml | 15 + 28 files changed, 819 insertions(+), 330 deletions(-) create mode 100644 content/ko/docs/home/supported-doc-versions.md create mode 100644 content/ko/docs/reference/glossary/cloud-provider.md create mode 100644 content/ko/docs/reference/using-api/_index.md create mode 100644 content/ko/docs/reference/using-api/api-overview.md create mode 100755 content/ko/docs/tasks/debug-application-cluster/_index.md create mode 100644 content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md create mode 100644 content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md create mode 100644 content/ko/docs/tasks/inject-data-application/_index.md create mode 100644 content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md create mode 100644 content/ko/examples/pods/inject/envars.yaml diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index c2720da086..d78e60b5b8 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -7,7 +7,7 @@ weight: 40 {{% capture overview %}} -개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 클러스터를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다. +개념 섹션을 통해 쿠버네티스 시스템을 구성하는 요소와 {{< glossary_tooltip text="클러스터" term_id="cluster" length="all" >}}를 표현하는데 사용되는 추상 개념에 대해 배우고 쿠버네티스가 작동하는 방식에 대해 보다 깊이 이해할 수 있다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 40b6fe95b9..575d5e2e5c 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -80,11 +80,13 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 ## 애드온 -애드온은 클러스터 기능을 이행하는 파드와 서비스다. -이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다. -네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다. +애드온은 쿠버네티스 리소스({{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}, +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 등)를 +이용하여 클러스터 기능을 구현한다. 이들은 클러스터 단위의 기능을 제공하기 때문에 +애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다. -선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. +선택된 일부 애드온은 아래에 설명하였고, 사용가능한 전체 확장 애드온 리스트는 +[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. ### DNS diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 38d1c99937..6dcfd6908b 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -108,8 +108,8 @@ echo $pods nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` -여기서 셀렉터는 레플리케이션 컨트롤러의 셀렉터와 같다 ( -`kubectl describe` 의 출력에서 볼 수 있는 것과, 다른 형식의 파일인 `replication.yaml` 의 것). `--output=jsonpath` 옵션은 +여기서 셀렉터는 레플리케이션 컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, +다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다. diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index c05c27de61..19fe8e18b5 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -5,126 +5,104 @@ weight: 40 --- {{% capture overview %}} -이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는 -앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는 +이 페이지는 초기화 컨테이너에 대한 개요를 제공한다. 초기화 컨테이너는 +{{< glossary_tooltip text="파드" term_id="pod" >}}의 앱 컨테이너들이 실행되기 전에 실행되는 특수한 컨테이너이며, 앱 이미지에는 없는 유틸리티 또는 설정 스크립트 등을 포함할 수 있다. + +초기화 컨테이너는 `containers` 배열(앱 컨테이너를 기술하는)과 나란히 +파드 스펙에 명시할 수 있다. {{% /capture %}} -이 특징은 1.6에서 베타를 빠져나왔다. 초기화 컨테이너는 앱 `containers` 배열과 나란히 -파드 스펙에 명시될 수 있다. 베타 어노테이션의 값은 여전히 존중되며 파드 스펙 필드 값을 덮어쓴다. -하지만, 베타 어노테이션은 1.6과 1.7에서 사용 중단(deprecated)되었다. -1.8에서 어노테이션은 더는 지원되지 않으므로 파드 스펙 필드로 변환되어야 한다. - {{% capture body %}} + ## 초기화 컨테이너 이해하기 -[파드](/ko/docs/concepts/workloads/pods/pod-overview/)는 앱들을 실행하는 다수의 컨테이너를 -포함할 수 있다. 또한, 파드는 앱 컨테이너 실행 전에 동작되는 하나 이상의 -초기화 컨테이너도 포함할 수 있다. +{{< glossary_tooltip text="파드" term_id="pod" >}}는 앱들을 실행하는 다수의 컨테이너를 +포함할 수 있고, 또한 앱 컨테이너 실행 전에 동작되는 하나 이상의 +초기화 컨테이너도 포함할 수 있다. -다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다. +다음의 경우를 제외하면, 초기화 컨테이너는 일반적인 컨테이너와 매우 유사하다. * 초기화 컨테이너는 항상 완료를 목표로 실행된다. -* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. +* 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. -만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 -반복적으로 재시작한다. 그러나, 만약 파드가 `restartPolicy`을 절대 하지 않음(Never)으로 설정한다면, 파드는 재시작되지 않는다. +만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 +반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. -컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히 -`initContainers` 필드를 +컨테이너를 초기화 컨테이너로 지정하기 위해서는, +파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를 [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 타입 오브젝트들의 JSON 배열로서 추가한다. -초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를 -통해서 컨테이너 상태 배열로 반환된다 (`.status.containerStatuses`와 -유사하게). +초기화 컨테이너의 상태는 `.status.initContainerStatuses` 필드를 +통해서 컨테이너 상태 배열로 반환된다 +(`.status.containerStatuses` 필드와 유사하게). ### 일반적인 컨테이너와의 차이점 -초기화 컨테이너는 앱 컨테이너의 리소스 상한, 볼륨, 보안 세팅을 포함한 -모든 필드와 특징을 지원한다. 그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은 -약간 다르게 처리된다. 이것에 대해서는 아래 [리소스](#리소스)에 문서화되어 있다. 또한, 초기화 컨테이너는 -준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 -파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 -때문이다. +초기화 컨테이너는 앱 컨테이너의 리소스 상한(limit), 볼륨, 보안 세팅을 포함한 +모든 필드와 기능을 지원한다. +그러나, 초기화 컨테이너를 위한 리소스 요청량과 상한은 +[리소스](#리소스)에 문서화된 것처럼 다르게 처리된다. -만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, 해당 초기화 컨테이너들은 순차적으로 -한 번에 하나씩 실행된다. 각 초기화 컨테이너들은 다음 초기화 컨테이너가 실행되기 전에 성공되어야 한다. -모든 초기화 컨테이너들이 실행 완료되었을 때, 쿠버네티스는 파드를 초기화하고 -애플리케이션 컨테이너를 평소와 같이 실행한다. +또한, 초기화 컨테이너는 준비성 프로브(readiness probe)를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 +파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다. -## 초기화 컨테이너는 무엇을 위해서 사용될 수 있는가? +만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을 +한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다. +모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을 +초기화하고 평소와 같이 실행한다. -초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에 -관련된 코드에 몇 가지 이점을 가진다. +## 초기화 컨테이너 사용하기 -* 보안 상 앱 컨테이너 이미지에서는 바람직하지 않은 유틸리티를 포함하고 - 실행시킬 수 있다. -* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함한다. +초기화 컨테이너는 앱 컨테이너와는 별도의 이미지를 가지고 있기 때문에, 시동(start-up)에 +관련된 코드로서 몇 가지 이점을 가진다. + +* 앱 이미지에는 없는 셋업을 위한 유틸리티 또는 맞춤 코드를 포함할 수 있다. 예를 들어, 셋업 중에 단지 `sed`, `awk`, `python`, 또는 `dig`와 같은 도구를 사용하기 위해서 다른 이미지로부터(`FROM`) 새로운 이미지를 만들 필요가 없다. +* 앱 컨테이너 이미지의 보안성을 떨어뜨릴 수도 있는 유틸리티를 안전하게 실행할 수 있다. * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. * 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. - 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 시크릿에 접근 권한이 주어질 수 있다. -* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 - 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 + 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 + {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다. +* 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 + 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 충족될 때까지 앱 컨테이너가 시동되는 것을 막거나 지연시키는 간편한 방법을 제공한다. + ### 예제 초기화 컨테이너를 사용하는 방법에 대한 몇 가지 아이디어는 다음과 같다. -* 다음과 같은 셀 커맨드로, 서비스가 생성될 때까지 기다리기. - - for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 +* 다음과 같은 셸 커맨드로, + {{< glossary_tooltip text="서비스" term_id="service">}}가 생성될 때까지 기다리기. + ```shell + for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 + ``` * 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기. + ```shell + curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' + ``` - `curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()'` +* 다음과 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기. + ```shell + sleep 60 + ``` -* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기. -* git 저장소를 볼륨 안에 클론하기. -* 설정 파일에 값을 지정하고 메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기. - 예를 들어, 설정에 POD_IP 값을 지정하고 메인 앱 설정 파일을 Jinja를 통해서 생성. +* Git 저장소를 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 안에 클론하기. -더 자세한 사용 예제는 [스테이트풀 셋 문서](/docs/concepts/workloads/controllers/statefulset/) -과 [프로덕션 파드 가이드](/docs/tasks/configure-pod-container/configure-pod-initialization/)에서 확인한다. +* 설정 파일에 값을 지정하고 + 메인 앱 컨테이너를 위한 설정 파일을 동적으로 생성하기 위한 템플릿 도구를 실행하기. + 예를 들어, 설정에 `POD_IP` 값을 지정하고 + 메인 앱 설정 파일을 Jinja를 통해서 생성. -### 사용되고 있는 초기화 컨테이너 +### 사용 중인 초기화 컨테이너 -쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. -첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 +쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. +첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 완료되면, 파드가 시작될 것이다. -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: myapp-pod - labels: - app: myapp - annotations: - pod.beta.kubernetes.io/init-containers: '[ - { - "name": "init-myservice", - "image": "busybox:1.28", - "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] - }, - { - "name": "init-mydb", - "image": "busybox:1.28", - "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] - } - ]' -spec: - containers: - - name: myapp-container - image: busybox:1.28 - command: ['sh', '-c', 'echo The app is running! && sleep 3600'] -``` - -쿠버네티스 1.6에는 새로운 구문이 있다. 다만, 예전 어노테이션 구문도 1.6과 1.7에서는 여전히 동작한다. 새로운 구문은 -1.8 또는 더 높은 버전에서 사용되어야 한다. 초기화에 대한 선언은 `spec`으로 옮겨졌다. - ```yaml apiVersion: v1 kind: Pod @@ -146,8 +124,6 @@ spec: command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] ``` -1.5 구문도 1.6에서 여전히 동작하지만, 1.6 구문 사용을 추천한다. 쿠버네티스 1.6에서는, 초기화 컨테이너가 API에서 필드로 -만들어졌었다. 베타 어노테이션은 1.6과 1.7에서 여전히 지원되지만, 1.8이나 더 높은 버전에서는 지원되지 않는다. 아래의 yaml file은 `mydb`와 `myservice` 서비스의 개요를 보여준다. @@ -182,6 +158,7 @@ kubectl apply -f myapp.yaml pod/myapp-pod created ``` +그리고 파드의 상태를 확인한다. ```shell kubectl get -f myapp.yaml ``` @@ -190,6 +167,7 @@ NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m ``` +혹은 좀 더 자세히 살펴본다. ```shell kubectl describe -f myapp.yaml ``` @@ -227,14 +205,43 @@ Events: 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 ``` + +파드의 초기화 컨테이너의 상태를 보기 위해, 다음을 실행한다. ```shell kubectl logs myapp-pod -c init-myservice # Inspect the first init container kubectl logs myapp-pod -c init-mydb # Inspect the second init container ``` -`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 +`mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 `myapp-pod`가 생성된 것을 볼 수 있다. +여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다. + +```yaml +--- +apiVersion: v1 +kind: Service +metadata: + name: myservice +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9376 +--- +apiVersion: v1 +kind: Service +metadata: + name: mydb +spec: + ports: + - protocol: TCP + port: 80 + targetPort: 9377 +``` + +`mydb`와 `myservice` 서비스 생성하기. + ```shell kubectl apply -f services.yaml ``` @@ -243,26 +250,31 @@ service/myservice created service/mydb created ``` +초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로 +변경되는 것을 볼 것이다. + ```shell kubectl get -f myapp.yaml +``` +``` NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m ``` -이 예제는 매우 단순하지만 사용자만의 초기화 컨테이너를 생성하는데 -영감을 줄 것이다. +이 간단한 예제는 사용자만의 초기화 컨테이너를 생성하는데 +영감을 줄 것이다. [다음 순서](#what-s-next)에는 더 자세한 예제의 링크가 있다. ## 자세한 동작 -파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가 -순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 -종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 -실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, -파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 +파드 시동 시, 네트워크와 볼륨이 초기화되고 나면, 초기화 컨테이너가 +순서대로 시작된다. 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 +종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 +실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, +파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 `restartPolicy`을 실패 시(OnFailure)로 사용한다. 파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는 -서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 +서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 `Initializing`이 참이 되는 조건을 가져야 한다. 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 @@ -275,69 +287,59 @@ myapp-pod 1/1 Running 0 9m 코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는 출력 파일이 이미 존재할 가능성에 대비해야 한다. -초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 -`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 +초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 +`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다. -초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 -파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 -사용한다. +초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 +파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다. -파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 +파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다. ### 리소스 -초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한 +초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한 다음의 규칙이 적용된다. -* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장 +* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장 높은 것은 *유효한 초기화 요청량/상한* 이다. * 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다. * 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계 * 리소스에 대한 유효한 초기화 요청량/상한 -* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉, - 초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를 - 예약할 수 있다. -* 파드의 *유효한 QoS 계층* 에서 QoS 계층은 초기화 컨테이너들과 +* 스케줄링은 유효한 요청/상한에 따라 이루어진다. 즉, + 초기화 컨테이너는 파드의 삶에서는 사용되지 않는 초기화를 위한 리소스를 + 예약할 수 있다. +* 파드의 *유효한 QoS 계층* 에서 QoS(서비스의 품질) 계층은 초기화 컨테이너들과 앱 컨테이너들의 QoS 계층과 같다. -쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라 +쿼터 및 상한은 유효한 파드의 요청량 및 상한에 따라 적용된다. -파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다. 이는 스케줄러와 같다. +파드 레벨 cgroup은 유효한 파드 요청량 및 상한을 기반으로 한다. +이는 스케줄러와 같다. + ### 파드 재시작 이유 -파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수 +파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수 있다. -* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다. - Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너 - 이미지의 변경은 앱 컨테이너만 재시작시킨다. -* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 +* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다. + Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너 + 이미지의 변경은 앱 컨테이너만 재시작시킨다. +* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. -* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, - 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 +* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, + 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실되었다. -## 지원 및 호환성 - -Api서버 버전 1.6.0 또는 더 높은 버전으로 구성된 클러스터는 `.spec.initContainers` -필드를 사용하여 초기화 컨테이너를 지원한다. 이전 버전들은 초기화 컨테이너를 알파 또는 -베타 어노테이션을 사용하여 지원한다. `.spec.initContainers` 필드는 알파 또는 베타 -어노테이션에도 반영되어 있어서 버전 1.3.0 이상의 Kubelet이 초기화 컨테이너를 실행할 수 -있도록 한다. 따라서, 버전 1.6 api서버가 기존에 생성된 파드들의 초기화 컨테이너 기능 손실 없이 -안전하게 버전 1.5.x로 롤백할 수 있게 한다. - -Api서버 및 Kubelet 버전 1.8.0 이상에서는, 사용 중단된 어노테이션을 -`.spec.initContainers` 필드로 변환하는 것이 필요한, 알파 및 베타 어노테이션의 지원이 중단되었다. - {{% /capture %}} {{% capture whatsnext %}} * [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) +* [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 1a4f036794..204f7d9ec1 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -69,8 +69,7 @@ weight: 50 minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` 플래그를 추가한다. -1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. - 이것을 이루는 방법 중 하나는 +1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다. minikube에서는 클러스터가 시작할 때 diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 5162b44177..93e5335c22 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -201,22 +201,30 @@ SIG Docs 승인자가 되는 방법과 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. -#### 웹사이트 관리자 되기 +#### 승인자의 책임 -`kubernetes-website-admins` GitHub 그룹의 멤버는 GitHub 그룹의 멤버십을 관리할 수 있고 -리포지터리를 세팅하거나 웹훅(webhook)을 추가, 삭제하고 트러블슈팅하는 것을 포함한 -모든 관리 권한을 가질 수 있다. -모든 SIG Docs 승인자가 이 수준의 액세스를 할 필요는 없다. +승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다. -만약 이 수준의 접근 권한이 필요하다면, 현재 웹사이트 관리자나 -[쿠버네티스 Slack](https://kubernetes.slack.com) #sig-docs 채널에서 말한다. +- 승인자는 PR들을 리포에 머지하는 `/approve` 명령을 사용할 수 있다. + + 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. + +- 제안된 변경이 컨트리뷰션 가이드 라인에 적합한지 확인한다. + + 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. + +- PR을 `/approve` 하기 전에 Netlify 테스트 결과를 검토한다. + + 승인 전에 반드시 Netlify 테스트를 통과해야 한다 + +- 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. #### PR Wrangler SIG Docs 승인자는 -[PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 -올라서 주 단위로 돌아가며 역할을 수행한다. -모든 SIG Docs 승인자는 이 로테이션에 참여하게 된다. 보다 자세한 내용은 +[PR Wrangler 회람 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 +참여하여 주 단위로 돌아가며 역할을 수행한다. +SIG Docs는 모든 승인자들이 이 회람에 참여하기를 기대한다. 보다 자세한 내용은 [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 문서를 참고한다. diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000..69245a2f41 --- /dev/null +++ b/content/ko/docs/home/supported-doc-versions.md @@ -0,0 +1,28 @@ +--- +title: 쿠버네티스 문서의 버전 지원 +content_template: templates/concept +card: + name: about + weight: 10 + title: 문서의 버전 지원 +--- + +{{% capture overview %}} + +이 웹 사이트에는 현재 버전의 쿠버네티스와 이전 4개 버전의 +쿠버네티스에 대한 문서가 포함되어 있습니다. + +{{% /capture %}} + +{{% capture body %}} + +## 현재 버전 + +현재 버전은 +[{{< param "version" >}}](/). + +## 이전 버전 + +{{< versions-other >}} + +{{% /capture %}} diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 4ad5e4a590..8ca5921f15 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -16,13 +16,13 @@ content_template: templates/concept ## API 레퍼런스 -* [쿠버네티스 API 개요](/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 +* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 * 쿠버네티스 API 버전 + * [1.15](/docs/reference/generated/kubernetes-api/v1.15/) * [1.14](/docs/reference/generated/kubernetes-api/v1.14/) * [1.13](/docs/reference/generated/kubernetes-api/v1.13/) * [1.12](/docs/reference/generated/kubernetes-api/v1.12/) * [1.11](/docs/reference/generated/kubernetes-api/v1.11/) - * [1.10](/docs/reference/generated/kubernetes-api/v1.10/) ## API 클라이언트 라이브러리 diff --git a/content/ko/docs/reference/glossary/cloud-provider.md b/content/ko/docs/reference/glossary/cloud-provider.md new file mode 100644 index 0000000000..a0fcc998e9 --- /dev/null +++ b/content/ko/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,17 @@ +--- +title: 클라우드 공급자 +id: cloud-provider +date: 2018-04-12 +full_link: /docs/concepts/cluster-administration/cloud-providers +short_description: > + 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사. + +aka: +tags: +- community +--- + 클라우드 공급자는 쿠버네티스 클러스터를 실행할 수 있는 클라우드 컴퓨팅 플랫폼을 제공하는 회사. + + + +클라우드 컴퓨팅 플랫폼을 제공하는 클라우드 공급자 또는 클라우드 서비스 공급자(CSP)라고 한다. 이들은 인프라 서비스(IaaS) 또는 플랫폼 서비스(PaaS)를 제공할 수 있다. 클라우드 공급자는 쿠버네티스 클러스터를 호스트 하며 클러스터와 상호작용하는 로드밸런서, 스토리지 클래스 등의 서비스도 제공한다. diff --git a/content/ko/docs/reference/glossary/cluster.md b/content/ko/docs/reference/glossary/cluster.md index 50277df48e..92f8eabd37 100755 --- a/content/ko/docs/reference/glossary/cluster.md +++ b/content/ko/docs/reference/glossary/cluster.md @@ -1,19 +1,17 @@ --- title: 클러스터(Cluster) id: cluster -date: 2018-04-12 +date: 2019-06-15 full_link: short_description: > - 쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합. + 쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다. -aka: +aka: tags: - fundamental - operation --- - 쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합. +쿠버네티스에서 관리하는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 기계의 집합. 클러스터는 최소 1개의 워커 노드와 최소 1개의 마스터 노드를 가진다. - -클러스터는 여러 개의 워커 노드와 적어도 하나의 마스터를 가진다. - +워커 노드는 애플리케이션의 구성요소인 파드를 호스트한다. 마스터 노드는 워커 노드와 클러스터 내 파드를 관리한다. 다수의 마스터 노드는 장애극복(failover)과 고가용성의 클러스터에서 사용한다. diff --git a/content/ko/docs/reference/glossary/container-runtime.md b/content/ko/docs/reference/glossary/container-runtime.md index 8a26ee8147..112282e178 100644 --- a/content/ko/docs/reference/glossary/container-runtime.md +++ b/content/ko/docs/reference/glossary/container-runtime.md @@ -15,7 +15,7 @@ tags: -쿠버네티스느 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com), +쿠버네티스는 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet)과 [Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어. diff --git a/content/ko/docs/reference/glossary/daemonset.md b/content/ko/docs/reference/glossary/daemonset.md index 580f6bf0be..81405e5437 100755 --- a/content/ko/docs/reference/glossary/daemonset.md +++ b/content/ko/docs/reference/glossary/daemonset.md @@ -1,20 +1,20 @@ --- -title: 데몬 셋(DaemonSet) +title: 데몬셋(DaemonSet) id: daemonset date: 2018-04-12 full_link: /docs/concepts/workloads/controllers/daemonset short_description: > - 파드의 복제품이 클러스터의 노드 집합에 걸쳐 동작하는 것을 확실히 한다. + 파드의 복제본을 클러스터 노드 집합에서 동작하게 한다. -aka: +aka: tags: - fundamental - core-object - workload --- - {{< glossary_tooltip text="파드" term_id="pod" >}}의 복제품이 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}의 노드 집합에 걸쳐 동작하는 것을 확실히 한다. + {{< glossary_tooltip text="파드" term_id="pod" >}} 복제본을 {{< glossary_tooltip text="클러스터" term_id="cluster" >}} 노드 집합에서 동작하게 한다. - + -일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 디플로이하기 위해서 사용된다. +일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 배포하기 위해서 사용된다. diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md index c6ef06e304..39c5e4d7f6 100755 --- a/content/ko/docs/reference/glossary/deployment.md +++ b/content/ko/docs/reference/glossary/deployment.md @@ -4,17 +4,17 @@ id: deployment date: 2018-04-12 full_link: /docs/concepts/workloads/controllers/deployment/ short_description: > - 레플리케이션 된 애플리케이션을 관리하는 API 오브젝트. + 복제된(replicated) 애플리케이션을 관리하는 API 오브젝트. -aka: +aka: tags: - fundamental - core-object - workload --- - 레플리케이션 된 애플리케이션을 관리하는 API 오브젝트. + 복제된 애플리케이션을 관리하는 API 오브젝트. - + -각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 각 파드는 클러스터의 노드에 분산된다. +각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 파드는 클러스터의 노드에 분산된다. diff --git a/content/ko/docs/reference/glossary/init-container.md b/content/ko/docs/reference/glossary/init-container.md index 890b34505e..fdb4d2c82c 100755 --- a/content/ko/docs/reference/glossary/init-container.md +++ b/content/ko/docs/reference/glossary/init-container.md @@ -2,17 +2,17 @@ title: 초기화 컨테이너(Init Container) id: init-container date: 2018-04-12 -full_link: +full_link: short_description: > - 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. + 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. -aka: +aka: tags: - fundamental --- - 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. + 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. - + 한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다. diff --git a/content/ko/docs/reference/glossary/limitrange.md b/content/ko/docs/reference/glossary/limitrange.md index 5588e45449..26802da637 100755 --- a/content/ko/docs/reference/glossary/limitrange.md +++ b/content/ko/docs/reference/glossary/limitrange.md @@ -4,7 +4,7 @@ id: limitrange date: 2019-04-15 full_link: /docs/concepts/policy/limit-range/ short_description: > - 네임스페이스 안의 컨테이너나 파드의 리소스 사용량을 제한하는 제약을 제공한다. + 네임스페이스 내에 컨테이너나 파드당 리소스 소비를 한정하는 제약 조건을 제공한다. aka: tags: @@ -16,8 +16,8 @@ related: - container --- - 네임스페이스 안의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}의 리소스 사용량을 제한하는 제약을 제공한다. + 네임스페이스 내에 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}당 리소스 소비를 한정하는 제약 조건을 제공한다. -범위 제한은 타입별로 만들 수 있는 객체의 수와 -네임스페이스 안의 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비한 컴퓨팅 리소스의 양을 제한한다. +범위 제한은 타입별로 만들 수 있는 오브젝트의 개수와 +네임스페이스 안에 개별 {{< glossary_tooltip text="컨테이너" term_id="container" >}}나 {{< glossary_tooltip text="파드" term_id="pod" >}}가 요청하거나 소비할 컴퓨팅 리소스의 양을 제한한다. diff --git a/content/ko/docs/reference/glossary/static-pod.md b/content/ko/docs/reference/glossary/static-pod.md index 91d5d2794c..ec5ea8c8e8 100755 --- a/content/ko/docs/reference/glossary/static-pod.md +++ b/content/ko/docs/reference/glossary/static-pod.md @@ -4,11 +4,11 @@ id: static-pod date: 2091-02-12 full_link: /docs/tasks/administer-cluster/static-pod/ short_description: > - 특정 노드의 kubelet 데몬이 직접 관리하는 파드 + 특정 노드의 Kubelet 데몬이 직접 관리하는 파드 aka: tags: - fundamental --- - API 서버가 관찰하지 않고, 특정 노드의 kubelet 데몬이 + API 서버가 관찰하지 않고, 특정 노드의 Kubelet 데몬이 직접 관리하는 {{< glossary_tooltip text="파드" term_id="pod" >}}. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 3dd586cbde..76e05c79e6 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -344,7 +344,7 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 로그 레벨 | 세부 사항 --------------| ----------- -`--v=0` | 일반적으로 운영자에게 유용함. +`--v=0` | 일반적으로 클러스터 운영자(operator)에게 *항상* 보여지게 하기에는 유용함. `--v=1` | 자세한 정보를 원하지 않는 경우, 적절한 기본 로그 수준. `--v=2` | 서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다. `--v=3` | 변경 사항에 대한 확장 정보. diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md new file mode 100644 index 0000000000..a224824aa1 --- /dev/null +++ b/content/ko/docs/reference/using-api/_index.md @@ -0,0 +1,5 @@ +--- +title: 쿠버네티스 API 사용하기 +weight: 10 +toc-hide: true +--- diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md new file mode 100644 index 0000000000..3c77ed24b8 --- /dev/null +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -0,0 +1,111 @@ +--- +title: 쿠버네티스 API 개요 +content_template: templates/concept +weight: 10 +card: + name: 레퍼런스 + weight: 50 + title: API 개요 +--- + +{{% capture overview %}} +이 페이지는 쿠버네티스 API에 대한 개요를 제공한다. +{{% /capture %}} + +{{% capture body %}} +REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, 컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 +API 오브젝트로 취급되고, +[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다. + +대부분의 작업은 API에 의존하고 있는 +[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 인터페이스 또는 +[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 같은 다른 커맨드라인 툴을 통해 수행할 수 있다. +그러나, REST 호출 사용을 통해서 API에 직접 접근할 수도 있다. + +쿠버네티스 API를 사용하는 애플리케이션을 작성하는 경우 +[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)중 하나의 사용을 고려한다. + +## API 버전 규칙 + +필드를 없애거나 리소스 표현을 재구성하기 쉽도록, +쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 +각각 다른 API 경로에서 복수의 API 버전을 지원한다. + +아래를 위해 버전은 리소스나 필드 수준보다는 API 수준에서 설정된다. + +- API가 시스템 리소스와 동작에 대해 명확하고 일관성 있게 표현하는 것을 보장 +- 수명 종료(end-of-life) 또는 실험적인 API 접근 제어 활성화 + +JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. + +{{< note >}} +API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. +[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. +{{< /note >}} + +API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [API 변경 문서](https://git.k8s.io/community/contributors/devel/api_changes.md#alpha-beta-and-stable-versions)에서 각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. + +아래는 각 수준의 기준에 대한 요약이다. + +- 알파(Alpha) 수준: + - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) + - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. 기본적으로 비활성화되어 있다. + - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. + - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. + - 버그의 위험이 높고 장기간 지원되지 않으므로 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. + +- 베타(Beta) 수준: + - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`). + - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. 기본적으로 활성화되어 있다. + - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. + - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드가 제공된다. 이때 API 오브젝트의 삭제, 편집 또는 재생성이 + 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. + - 이후 여러 버전에서 잠재적으로 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면, 이런 제약에서 안심이 될 수도 있겠다. + + {{< note >}} +베타 기능을 사용해보고 피드백을 제공하자. 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다. + {{< /note >}} + +- 안정화(stable) 수준: + - 버전 이름이 `vX`이고 `X` 는 정수다. + - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. + +## API 그룹 + +[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 쿠버네티스 API를 더 쉽게 확장하게 해준다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다. + +현재 다음과 같은 다양한 API 그룹이 사용되고 있다: + +* *핵심* (또는 *레거시*라고 불리는) 그룹은 `apiVersion: v1`와 같이 `apiVersion` 필드에 명시되지 않고 REST 경로 `/api/v1`에 있다. +* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 + (예를 들어 `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [쿠버네티스 API 참조 문서](/docs/reference/)에서 확인할 수 있다. + +[사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. + + - 기본적인 CRUD 요구에는 + [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) + + +## API 그룹 활성화 시키기 + +특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나 +비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어: + - batch/v1을 비활성화하려면 `--runtime-config=batch/v1=false`로 설정 + - batch/v2alpha1을 활성화하려면 `--runtime-config=batch/v2alpha1`로 설정 +이 플래그는 apiserver의 런타임 구성을 설명하는 쉼표로 분리된 키=값 쌍의 집합을 허용한다. + +{{< note >}} +그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 +`--runtime-config` 변경을 반영해야 한다. +{{< /note >}} + +## 그룹 내 리소스 활성화 시키기 + +데몬셋, 디플로이먼트, HorizontalPodAutoscaler, 인그레스, 잡 및 레플리카셋이 기본적으로 활성화되어 있다. +다른 확장 리소스는 apiserver의 `--runtime-config`를 설정해서 +활성화할 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어 디플로이먼트와 잡을 비활성화하려면, +`--runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false`와 같이 설정한다. +{{% /capture %}} + + diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index a8693e3b58..29789d5dbd 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -66,6 +66,7 @@ card: | [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | | [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | | [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | +| [Banzai Cloud Pipeline Kubernetes Engine (PKE)](https://banzaicloud.com/products/pke/) | | ✔ | | ✔ | ✔ | ✔ | | [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | | [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | | [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | @@ -81,6 +82,7 @@ card: | [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | | [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | | [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | +| [Ionos](https://www.ionos.com/enterprise-cloud) | [Ionos Managed Kubernetes](https://www.ionos.com/enterprise-cloud/managed-kubernetes) | [Ionos Enterprise Cloud](https://www.ionos.com/enterprise-cloud) | | | [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | | [Kubermatic](https://www.loodse.com/) | ✔ | ✔ | ✔ | | | | [KubeSail](https://kubesail.com/) | ✔ | | | | | @@ -100,6 +102,7 @@ card: | [Supergiant](https://supergiant.io/) | |✔ | | | | | [SUSE](https://www.suse.com/) | | ✔ | | | | | [SysEleven](https://www.syseleven.io/) | ✔ | | | | | +| [Tencent Cloud](https://intl.cloud.tencent.com/) | [Tencent Kubernetes Engine](https://intl.cloud.tencent.com/product/tke) | ✔ | ✔ | | | ✔ | | [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | | [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) diff --git a/content/ko/docs/tasks/debug-application-cluster/_index.md b/content/ko/docs/tasks/debug-application-cluster/_index.md new file mode 100755 index 0000000000..0613fed1ef --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/_index.md @@ -0,0 +1,5 @@ +--- +title: "모니터링, 로깅, 그리고 디버깅" +weight: 80 +--- + diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md new file mode 100644 index 0000000000..ca5003a98d --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -0,0 +1,53 @@ +--- +title: 리소스 메트릭 파이프라인 +content_template: templates/concept +--- + +{{% capture overview %}} + +쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 +쿠버네티스의 Metrics API를 통해 사용할 수 있다. 이 메트릭은 +`kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, +Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. + +{{% /capture %}} + + +{{% capture body %}} + +## Metrics API + +Metrics API를 통해 주어진 노드나 파드에서 현재 사용중인 +리소스의 양을 알 수 있다. 이 API는 메트릭 값을 저장하지 +않으므로 지정된 노드에서 10분 전에 사용된 리소스의 양을 +가져오는 것과 같은 일을 할 수는 없다. + +이 API와 다른 API는 차이가 없다. + +- 다른 쿠버네티스 API의 엔드포인트와 같이 `/apis/metrics.k8s.io/` 하위 경로에서 발견될 수 있다 +- 동일한 보안, 확장성 및 신뢰성 보장을 제공한다 + +[k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) +리포지터리에서 이 API를 정의하고 있다. 여기에서 이 API에 대한 더 상세한 정보를 찾을 수 있다. + +{{< note >}} +이 API를 사용하려면 Metrics server를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다. +{{< /note >}} + +## Metrics Server + +[Metrics server](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. +쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 Metrics server가 +디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 +[배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 Metrics server를 배포할 수 있다. +이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조) + +Metric server는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. + +Metrics server는 쿠버네티스 1.7에서 도입된 +[쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 +통해 메인 API 서버에 등록된다. + +[설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 Metrics server에 대해 자세하게 배울 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md new file mode 100644 index 0000000000..41e33f80d2 --- /dev/null +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -0,0 +1,116 @@ +--- +content_template: templates/concept +title: 리소스 모니터링 도구 +--- + +{{% capture overview %}} + +애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, +애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. +컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), +[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 +검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 +애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다. +이 정보는 애플리케이션의 성능을 평가하고 +병목 현상을 제거하여 전체 성능을 향상할 수 있게 해준다. + +{{% /capture %}} + +{{% capture body %}} + +쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. +신규 클러스터에서는 기본적으로 두 개의 개별 파이프라인을 사용하여 모니터링 통계를 +수집할 수 있다. + +- [**리소스 메트릭 파이프라인**](#리소스-메트릭-파이프라인)은 HorizontalPodAutoscaler + 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 + 제한된 집합을 제공한다. 이 메트릭은 + [metrics-server](https://github.com/kubernetes-incubator/metrics-server) + 에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. `metrics-server`는 클러스터 + 상의 모든 노드를 발견하고 각 노드의 + [Kubelet](/docs/reference/command-line-tools-reference/kubelet)에 CPU와 메모리 + 사용량을 질의한다. Kubelet은 [cAdvisor](https://github.com/google/cadvisor)에서 + 데이터를 가져온다. `metrics-server`는 경량의 단기 인메모리 저장소이다. + +- 프로메테우스 같이 [**완전한 메트릭 파이프라인**](#완전한-메트릭-파이프라인)은 보다 풍부한 + 메트릭에 액세스할 수 있게 해준다. 추가적으로 쿠버네티스는 Horizontal Pod Autoscaler와 + 같은 메커니즘을 사용하여 현재 상태를 기반으로 클러스터를 자동으로 확장 또는 + 조정함으로써 이런 메트릭에 응답할 수 있다. 모니터링 파이프라인은 Kubelet에서 + 메트릭을 가져온 다음 `custom.metrics.k8s.io` 이나 + `external.metrics.k8s.io` API로 구현된 어댑터를 통해 + 이들을 쿠버네티스에 노출한다. + +## 리소스 메트릭 파이프라인 + +### Kubelet + +Kubelet은 쿠버네티스 마스터와 노드들 사이의 다리 역할을 한다. 이는 머신 상에서 실행되는 파드들과 컨테이너들을 관리한다. Kubelet은 각 파드를 이를 구성하는 컨테이너들로 변환하며 컨테이너 런타임 인터페이스를 통해 컨테이너 런타임에서 개별 컨테이너의 사용량 통계를 가져온다. 레거시 도커 통합에서는 cAdvisor에서 이 정보를 가져온다. 그런 다음 Kubelet 리소스 메트릭 API를 통해 집계된 파드 리소스 사용량 통계를 노출한다. 이 API는 Kubelet의 인증되고 읽기 전용의 포트들 상에서 `/metrics/resource/v1alpha1`으로 제공된다. + +### cAdvisor + +cAdvisor는 오픈 소스 컨테이너 자원 사용률/성능 분석 에이전트이다. 이는 컨테이너 전용으로 설계되었으며 도커 컨테이너를 기본적으로 지원한다. 쿠버네티스에서 cAdvisor는 Kubelet 바이너리와 통합된다. cAdvisor는 머신 내 모든 컨테이너를 자동으로 발견하며 CPU, 메모리, 파일시스템, 네트워크 사용량 통계를 수집한다. cAdvisor는 또한 machine 상의 'root' 컨테이너 분석에 의한 전체 머신 사용량도 제공한다. + +Kubelet은 기본 포트 4194를 통해 머신의 컨테이너에 대한 단순한 cAdvisor UI를 노출한다. +아래 그림은 전체 머신의 사용량을 예제로 보여준다. 하지만, 이 기능은 v1.10에서는 사용 중단(deprecated)으로 +표시되었으며, v1.12에서는 완전히 제거되었다. + +![cAdvisor](/images/docs/cadvisor.png) + +v1.13부터, [cAdvisor를 데몬셋으로 배포](https://github.com/google/cadvisor/tree/master/deploy/kubernetes)하여 cAdvisor UI에 액세스할 수 있다. + +## 완전한 메트릭 파이프라인 + +쿠버네티스를 위한 많은 완전한 메트릭 솔루션들이 존재한다. + +### 프로메테우스 + +[프로메테우스](https://prometheus.io)는 기본적으로 쿠버네티스, 노드, 프로메테우스 자체를 모니터링할 수 있다. +[Prometheus Operator](https://coreos.com/operators/prometheus/docs/latest/)는 +쿠버네티스에서 프로메테우스 설정을 단순화하고, +[Prometheus adapter](https://github.com/directxman12/k8s-prometheus-adapter)를 +사용하여 커스텀 메트릭 API를 제공할 수 있게 해준다. +프로메테우스는 강력한 쿼리 언어와 데이터 쿼리와 시각화를 위한 내장 대시보드를 제공한다. +또한 [Grafana](https://prometheus.io/docs/visualization/grafana/)에서는 +데이터 소스로 프로메테우스가 지원된다. + +### Sysdig +[Sysdig](http://sysdig.com)는 완전한 스펙트럼 컨테이너와 플랫폼 인텔리전스를 제공하며, +진정한 컨테이너 네이티브 솔루션이다. Sysdig는 시스템 호출, 쿠버네티스 이벤트, 프로메테우스 메트릭, +statsD, JMX 등의 데이터를 하나의 창으로 통합하여 환경에 대한 포괄적인 그림을 제공한다. +또한 Sysdig는 강력하고 사용자 정의가 가능한 솔루션을 제공하기 위해 쿼리를 실행할 수 있는 API를 제공한다. +Sysdig는 오픈 소스로 만들어졌다. [Sysdig와 Sysdig Inspect](https://sysdig.com/opensource/inspect/)는 +자유롭게 트러블슈팅, 분석, 포렌식을 수행할 수 있는 기능을 제공한다. + +### 구글 클라우드 모니터링 + +구글 클라우드 모니터링은 호스팅 모니터링 서비스로 애플리케이션의 +중요한 메트릭을 시각화하고 경고하는데 사용할 수 있으며, +쿠버네티스에서 메트릭을 수집하고 +[Cloud Monitoring Console](https://app.google.stackdriver.com/)을 +통해 이 메트릭들에 접근할 수 있다. 대시보드를 만들고 사용자 정의하여 쿠버네티스 클러스터에서 +수집한 데이터를 시각화할 수 있다. + +이 동영상은 힙스터(Heapster)를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법을 보여준다. + +[![힙스터를 기반으로 구글 클라우드 모니터링을 구성하고 실행하는 방법](https://img.youtube.com/vi/xSMNR2fcoLs/0.jpg)](https://www.youtube.com/watch?v=xSMNR2fcoLs) + + +{{< figure src="/images/docs/gcm.png" alt="구글 클라우드 모니터링 대시보드 예제" title="구글 클라우드 모니터링 대시보드 예제" caption="대시보드는 클러스터 전역의 리소스 사용량을 보여준다." >}} + +## 크론잡 모니터링 + +### Kubernetes Job Monitor + +[Kubernetes Job Monitor](https://github.com/pietervogelaar/kubernetes-job-monitor) 대시보드를 사용하여 클러스터 관리자는 실행되고 있는 잡들과 완료된 잡의 상태를 볼 수 있다. + +### New Relic 쿠버네티스 모니터링 통합 + +[New Relic 쿠버네티스](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration) 통합은 쿠버네티스 환경의 성능에 대한 가시성을 향상시킨다. New Relic의 쿠버네티스 통합은 쿠버네티스 오브젝트의 메트릭을 리포팅하는 것으로 컨테이너 오케스트레이션 계층을 측정한다. 통합을 통해 쿠버네티스 노드, 네임스페이스, 디플로이먼트, 레플리카 셋, 파드, 컨테이너에 대한 인사이트를 얻을 수 있다. + +중요 기능: +사전 구축된 대시보드에서 데이터를 확인하여 쿠버네티스 환경에 대한 즉각적인 인사이트를 확인한다. +자동으로 보고되는 데이터의 인사이트로 커스텀 쿼리와 차트를 생성한다. +쿠버네티스 데이터에 대해 경고 조건을 생성한다. +이 [페이지](https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/kubernetes-monitoring-integration)에서 더 알아볼 수 있다. + +{{% /capture %}} diff --git a/content/ko/docs/tasks/inject-data-application/_index.md b/content/ko/docs/tasks/inject-data-application/_index.md new file mode 100644 index 0000000000..e7ae5375f4 --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "애플리케이션에 데이터 주입하기" +weight: 30 + +--- \ No newline at end of file diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md new file mode 100644 index 0000000000..5cdf78075c --- /dev/null +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -0,0 +1,120 @@ +--- +title: 컨테이너를 위한 환경 변수 정의하기 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} + +본 페이지는 쿠버네티스 파드의 컨테이너를 위한 환경 변수를 +정의하는 방법에 대해 설명한다. + +{{% /capture %}} + + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + + +{{% capture steps %}} + +## 컨테이너를 위한 환경 변수 정의하기 + +파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 환경 변수를 설정할 +수 있다. 환경 변수를 설정하려면, 구성 파일에 `env`나 `envFrom` 필드를 +포함시켜야 한다. + +이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 +파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는 +값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일 +예시이다. + +{{< codenew file="pods/inject/envars.yaml" >}} + +1. YAML 구성 파일을 활용해 파드를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/pods/inject/envars.yaml + ``` + +1. 실행 중인 파드들의 목록을 조회한다. + + ```shell + kubectl get pods -l purpose=demonstrate-envars + ``` + + 출력은 아래와 비슷할 것이다. + + ``` + NAME READY STATUS RESTARTS AGE + envar-demo 1/1 Running 0 9s + ``` + +1. 파드 안에 실행되고 있는 컨테이너의 셸에 접근한다. + + ```shell + kubectl exec -it envar-demo -- /bin/bash + ``` + +1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. + + ```shell + root@envar-demo:/# printenv + ``` + + 출력은 아래와 비슷할 것이다. + + ``` + NODE_VERSION=4.4.2 + EXAMPLE_SERVICE_PORT_8080_TCP_ADDR=10.3.245.237 + HOSTNAME=envar-demo + ... + DEMO_GREETING=Hello from the environment + DEMO_FAREWELL=Such a sweet sorrow + ``` + +1. 셸에서 빠져나오기 위해, `exit`을 입력한다. + +{{< note >}} +`env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 +안에서 명시된 어떠한 환경 변수들보다 더 우선시된다. +{{< /note >}} + +## 설정 안에서 환경 변수 사용하기 + +파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: print-greeting +spec: + containers: + - name: env-print-demo + image: bash + env: + - name: GREETING + value: "Warm greetings to" + - name: HONORIFIC + value: "The Most Honorable" + - name: NAME + value: "Kubernetes" + command: ["echo"] + args: ["$(GREETING) $(HONORIFIC) $(NAME)"] +``` + +컨테이너가 생성되면, `echo Warm greetings to The Most Honorable Kubernetes` 커맨드가 컨테이너에서 실행된다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다. +* [시크릿을 환경 변수로 사용하기](/docs/user-guide/secrets/#using-secrets-as-environment-variables)에 대해 알아본다. +* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다. + +{{% /capture %}} \ No newline at end of file diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index 405572ef30..9fea785eee 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -42,6 +42,8 @@ card: +
+

쿠버네티스 기초 모듈

diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index bfe22aa5d6..8adc83eafb 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -6,13 +6,13 @@ weight: 10 --- {{% capture overview %}} -이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 +이 튜토리얼은 스테이트풀셋([StatefulSets](/docs/concepts/workloads/controllers/statefulset/))을 이용하여 +애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 스케일링하고 업데이트하는지 시연한다. {{% /capture %}} {{% capture prerequisites %}} -튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해 +튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해 익숙해야 한다. * [파드](/docs/user-guide/pods/single-container/) @@ -23,17 +23,17 @@ weight: 10 * [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) * [kubectl CLI](/docs/user-guide/kubectl/) -이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 -설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, -튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 +이 튜토리얼은 클러스터가 퍼시스턴스볼륨을 동적으로 프로비저닝 하도록 +설정되었다고 가정한다. 만약 클러스터가 이렇게 설정되어 있지 않다면, +튜토리얼 시작 전에 수동으로 2개의 1 GiB 볼륨을 프로비저닝해야 한다. {{% /capture %}} {{% capture objectives %}} -스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서 -이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과 -분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해 -이 둘을 결합하지 않고, 스테이트풀셋을 사용한 +스테이트풀셋은 상태 유지가 필요한(stateful) 애플리케이션과 분산시스템에서 +이용하도록 의도했다. 그러나 쿠버네티스 상에 스테이트풀 애플리케이션과 +분산시스템을 관리하는 것은 광범위하고 복잡한 주제이다. 스테이트풀셋의 기본 기능을 보여주기 위해 +이 둘을 결합하지 않고, 스테이트풀셋을 사용한 단순 웹 애플리케이션을 배포할 것이다. 이 튜토리얼을 마치면 다음 항목에 대해 익숙해질 것이다. @@ -48,26 +48,26 @@ weight: 10 {{% capture lessoncontent %}} ## 스테이트풀셋 생성하기 -아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 -[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 -예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 +아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 +[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 +예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 +[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 `nginx` 를 생성한다. {{< codenew file="application/web/web.yaml" >}} 위에 예제를 다운로드 받아서 파일이름을 `web.yaml`으로 저장하자. -2개의 터미널창을 사용한다. 첫째 터미널에서 -[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)을 이용해서 +2개의 터미널창을 사용한다. 첫째 터미널에서 +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)을 이용해서 스테이트풀셋의 파드가 생성되는지 감시하자. ```shell kubectl get pods -w -l app=nginx ``` -두번째 터미널에서 -[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로 +두번째 터미널에서 +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로 `web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다. ```shell @@ -76,8 +76,8 @@ service/nginx created statefulset.apps/web created ``` -상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 -실행하는 2개의 파드를 생성한다. `nginx` 서비스와 +상기 명령어는 [NGINX](https://www.nginx.com) 웹 서버를 +실행하는 2개의 파드를 생성한다. `nginx` 서비스와 `web` 스테이트풀셋이 성공적으로 생성되었는지 알아보자. ```shell @@ -92,9 +92,9 @@ web 2 1 20s ### 차례대로 파드 생성하기 -N개의 레플리카를 가진 스테이트풀셋은 배포시에 -순차적으로 {0..N-1} 순으로 생성된다. -첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자. +N개의 레플리카를 가진 스테이트풀셋은 배포시에 +순차적으로 {0..N-1} 순으로 생성된다. +첫째 터미널에서 `kubectl get` 명령의 출력 내용을 살펴보자. 결국 그 내용은 아래 예와 비슷할 것이다. ```shell @@ -110,7 +110,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 18s ``` -`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에 +`web-1` 파드는 `web-0` 파드가 [Running과 Ready](/docs/user-guide/pod-states) 상태가 되기 전에 시작하지 않음을 주의하자. ## 스테이트풀셋 안에 파드 @@ -129,17 +129,17 @@ web-1 1/1 Running 0 1m ``` -[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 -언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. -이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 -고유한 순번에 기인한다. 파드의 이름의 형식은 -`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 +[스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/) 개념에서 +언급했듯 스테이트풀셋의 파드는 끈끈하고 고유한 정체성을 가진다. +이 정체성은 스테이트풀 컨트롤러에서 각 파드에 주어지는 +고유한 순번에 기인한다. 파드의 이름의 형식은 +`<스테이트풀셋 이름>-<순번>` 이다. 앞서 `web` 스테이트풀셋은 2개의 레플리카를 가졌으므로 `web-0` 과 `web-1` 2개 파드를 생성한다. ### 안정적인 네트워크 신원 사용하기 -각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서 -`hostname` 명령어를 실행하도록 +각 파드는 각 순번에 따른 안정적인 호스트네임을 갖는다. 각 파드에서 +`hostname` 명령어를 실행하도록 [`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 이용하자. ```shell @@ -148,13 +148,13 @@ web-0 web-1 ``` -`dnsutils` 패키지에서 `nslookup` 명령을 제공하는 컨테이너를 -실행하도록 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하자. -파드의 호스트네임에 `nslookup`을 이용하면 클러스터 내부 DNS 주소를 +`dnsutils` 패키지에서 `nslookup` 명령을 제공하는 컨테이너를 +실행하도록 [`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)을 이용하자. +파드의 호스트네임에 `nslookup`을 이용하면 클러스터 내부 DNS 주소를 확인할 수 있다. ```shell -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -171,7 +171,7 @@ Address 1: 10.244.2.6 ``` 헤드리스 서비스의 CNAME은 SRV 레코드를 지칭한다 -(Running과 Ready 상태의 각 파드마다 1개). +(Running과 Ready 상태의 각 파드마다 1개). SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지칭한다. 첫째 터미널에서 스테이트풀셋의 파드를 가져오자. @@ -179,8 +179,8 @@ SRV 레코드는 파드의 IP 주소를 포함한 A 레코드 엔트리를 지 ```shell kubectl get pod -w -l app=nginx ``` -두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해 -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를 +두번째 터미널에서 스테이트풀셋 내에 파드를 모두 삭제하기위해 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)를 이용하자. ```shell @@ -189,7 +189,7 @@ pod "web-0" deleted pod "web-1" deleted ``` -스테이트풀셋이 재시작되고 두 파드가 Running과 Ready 상태로 +스테이트풀셋이 재시작되고 두 파드가 Running과 Ready 상태로 전환되도록 기다리자. ```shell @@ -204,7 +204,7 @@ web-1 0/1 ContainerCreating 0 0s web-1 1/1 Running 0 34s ``` -파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 +파드의 호스트네임과 클러스터 내부 DNS 엔트리를 보기 위해 `kubectl exec`과 `kubectl run`을 이용하자. ```shell @@ -212,7 +212,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -228,23 +228,23 @@ Name: web-1.nginx Address 1: 10.244.2.8 ``` -파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 -파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 -다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 +파드의 순번, 호스트네임, SRV 레코드와 A 레코드이름은 변경되지 않지만 +파드의 IP 주소는 변경될 수 있다. 이는 튜토리얼에서 사용하는 클러스터나 +다른 클러스터에도 동일하다. 따라서 다른 애플리케이션이 IP 주소로 스테이트풀셋의 파드에 접속하지 않도록 하는 것이 중요하다. -스테이트풀셋의 활성 맴버를 찾아 연결할 경우 -헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다. -CNAME과 연관된 SRV 레코드는 스테이트풀셋의 -Running과 Ready 상태의 모든 파드들을 +스테이트풀셋의 활성 맴버를 찾아 연결할 경우 +헤드리스 서비스(`nginx.default.svc.cluster.local`)의 CNAME을 쿼리해야 한다. +CNAME과 연관된 SRV 레코드는 스테이트풀셋의 +Running과 Ready 상태의 모든 파드들을 담고 있다. -애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는 -연결 로직을 구현되어 있다면 +애플리케이션에서 이미 활성상태(liveness)와 준비성(readiness) 테스트하는 +연결 로직을 구현되어 있다면 파드`web-0.nginx.default.svc.cluster.local`, -`web-1.nginx.default.svc.cluster.local`)의 SRV레코드를 안정적으로 사용할 수 있어 -애플리케이션은 파드가 Running과 Ready 상태로 전환할 때 +`web-1.nginx.default.svc.cluster.local`)의 SRV레코드를 안정적으로 사용할 수 있어 +애플리케이션은 파드가 Running과 Ready 상태로 전환할 때 파드의 주소를 검색할 수 있다. ### 안정적인 스토리지에 쓰기 {#writing-to-stable-storage} @@ -257,16 +257,16 @@ NAME STATUS VOLUME CAPACITY ACCE www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s ``` -스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)에 -묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 +스테이트풀셋 컨트롤러는 2개의 [퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)에 +묶인 2개의 퍼시스턴트볼륨클레임을 생성했다. 본 튜토리얼에서 사용되는 클러스터는 퍼시스턴트볼륨을 동적으로 프로비저닝하도록 설정되었으므로 생성된 퍼시스턴트볼륨도 자동으로 묶인다. -NGINX 웹서버는 기본 색인 파일로 -`/usr/share/nginx/html/index.html`을 이용합니다. -스테이트풀셋 `spec`내의 `volumeMounts` 필드는 `/usr/share/nginx/html` 디렉터리가 +NGINX 웹서버는 기본 색인 파일로 +`/usr/share/nginx/html/index.html`을 이용합니다. +스테이트풀셋 `spec`내의 `volumeMounts` 필드는 `/usr/share/nginx/html` 디렉터리가 퍼시스턴트볼륨으로 제공되는지 보증합니다. -파드의 호스트네임을 `index.html` 파일에 작성하고 +파드의 호스트네임을 `index.html` 파일에 작성하고 NGINX 웹서버가 해당 호스트네임을 제공하는지 확인해보자. ```shell @@ -278,7 +278,7 @@ web-1 ``` {{< note >}} -위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 +위에 curl 명령어로 403 Forbidden 아닌 응답을 보려면 `volumeMounts`로 마운트된 디렉터리의 퍼미션을 수정해야 한다 ([hostPath 볼륨을 사용할 때에 버그](https://github.com/kubernetes/kubernetes/issues/2630)로 인함). @@ -302,7 +302,7 @@ kubectl delete pod -l app=nginx pod "web-0" deleted pod "web-1" deleted ``` -첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, 모든 파드가 Running과 Ready 상태로 전환될때까지 기다리자. ```shell @@ -325,16 +325,16 @@ web-0 web-1 ``` -비록 `web-0`과 `web-1`이 재스케줄링되어도 계속해서 -자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에 -연관된 퍼시스턴트볼륨이 해당 `volumeMounts`로 재마운트되기 때문이다. -`web-0`과 `web-1`의 스케줄링에 관계없이 +비록 `web-0`과 `web-1`이 재스케줄링되어도 계속해서 +자신의 호스트네임을 제공하는데 이는 각 퍼시스턴트볼륨클레임에 +연관된 퍼시스턴트볼륨이 해당 `volumeMounts`로 재마운트되기 때문이다. +`web-0`과 `web-1`의 스케줄링에 관계없이 각각의 퍼시스턴트볼륨은 적절하게 마운트된다. ## 스테이트풀셋 스케일링 -스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. -[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 -[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 +스테이트풀셋을 스케일링하는 것은 레플리카 개수를 늘리거나 줄이는 것을 의미한다. 이것은 `replicas` 필드를 갱신하여 이뤄진다. +[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)이나 +[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)을 이용해서 스테이트풀셋을 스케일링할 수 있다. ### 스케일 업 @@ -345,7 +345,7 @@ web-1 kubectl get pods -w -l app=nginx ``` -다른 터미널창에서 `kubectl scale`을 이용하여 레플리카 개수를 +다른 터미널창에서 `kubectl scale`을 이용하여 레플리카 개수를 5로 스케일링하자. ```shell @@ -353,7 +353,7 @@ kubectl scale sts web --replicas=5 statefulset.apps/web scaled ``` -첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, +첫번째 터미널에서 실행 중인 `kubectl get`명령어의 출력을 확인하고, 3개의 추가 파드가 Running과 Ready 상태로 전환될때까지 기다리자. ```shell @@ -376,10 +376,10 @@ web-4 0/1 ContainerCreating 0 0s web-4 1/1 Running 0 19s ``` -스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. -[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는 -각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 -이전 파드가 Running과 Ready 상태가 될때까지 +스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. +[스테이트풀셋 생성](#ordered-pod-creation)으로 스테이트풀셋 컨트롤러는 +각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 +이전 파드가 Running과 Ready 상태가 될때까지 기다린다. ### 스케일 다운 {#scaling-down} @@ -418,8 +418,8 @@ web-3 1/1 Terminating 0 42s ### 순차 파드 종료 -컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고 -다음 파드를 삭제하기 전에 +컨트롤러는 순번의 역순으로 한번에 1개 파드를 삭제하고 +다음 파드를 삭제하기 전에 각각이 완전하게 종료되기까지 기다린다. 스테이트풀셋의 퍼시스턴트볼륨클레임을 가져오자. @@ -435,23 +435,23 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO ``` -여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다. +여전히 5개의 퍼시스턴트볼륨클레임과 5개의 퍼시스턴트볼륨이 있다. 파드의 [안전한 스토리지](#writing-to-stable-storage)를 탐색하면서 스테이트풀셋의 파드가 삭제될 때에 파드에 마운트된 스테이트풀셋의 퍼시스턴트볼륨이 삭제되지 않은 것을 보았다. 스테이트풀셋 스케일 다운으로 파드 삭제할 때에도 여전히 사실이다. ## 스테이트풀셋 업데이트하기 -쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다. -전략은 스테이트풀셋 API 오브젝트의 `spec.updateStrategy` 필드로 결정된다. -이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나 -혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다. -`RollingUpdate`과 `OnDelete`의 2개의 +쿠버네티스 1.7 이상에서 스테이트풀셋 컨트롤러는 자동 업데이트를 지원한다. +전략은 스테이트풀셋 API 오브젝트의 `spec.updateStrategy` 필드로 결정된다. +이 기능은 컨테이너 이미지, 스테이트풀셋의 리소스 요청이나 +혹은 한계와 레이블과 파드의 어노테이션을 업그레이드하기 위해 사용될 수 있다. +`RollingUpdate`과 `OnDelete`의 2개의 유효한 업데이트 전략이 있다. `RollingUpdate` 업데이트 전략은 스테이트풀셋에서 기본 값이다. ### 롤링 업데이트 -`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다. +`RollingUpdate` 업데이트 전략은 스테이트풀셋을 보장하면서 스테이트풀셋 내에 파드를 역순으로 업데이트합니다. 스테이트풀셋 `web`의 업데이트 전략을 `RollingUpdate`으로 패치하자. @@ -460,7 +460,7 @@ kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpda statefulset.apps/web patched ``` -터미널 창에서 스테이트풀셋 `web`의 컨테이너 이미지를 바꾸도록 +터미널 창에서 스테이트풀셋 `web`의 컨테이너 이미지를 바꾸도록 또 패치하자. ```shell @@ -506,15 +506,15 @@ web-0 0/1 ContainerCreating 0 0s web-0 1/1 Running 0 10s ``` -스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다. -이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 -그것이 Running과 Ready 상태로 전환될때까지 기다린다. -알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 -다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. -업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 -이전 버전으로 복원한다. -이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 -애플리케이션을 계속 건강하게 유지하고 +스테이트풀셋 내에 파드는 순번의 역순으로 업데이트된다. +이 스테이트풀셋 컨트롤러는 각 파드를 종료시키고 다음 파드를 업데이트하기 전에 +그것이 Running과 Ready 상태로 전환될때까지 기다린다. +알아둘 것은 비록 스테이트풀셋 컨트롤러에서 이전 파드가 Running과 Ready 상태가 되기까지 +다음 파드를 업데이트하지 않아도 현재 버전으로 파드를 업데이트하다 실패하면 복원한다는 것이다. +업데이트를 이미 받은 파드는 업데이트된 버전으로 복원되고 아직 업데이트를 받지 못한 파드는 +이전 버전으로 복원한다. +이런 식으로 컨트롤러는 간헐적인 오류가 발생해도 +애플리케이션을 계속 건강하게 유지하고 업데이트도 일관되게 유지하려 한다. 컨테이너 이미지를 살펴보기 위해 파드를 가져오자. @@ -529,13 +529,13 @@ k8s.gcr.io/nginx-slim:0.8 스테이트풀셋의 모든 파드가 지금은 이전 컨테이너 이미지를 실행 중이이다. -**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` +**팁** 롤링 업데이트 상황을 살펴보기 위해 `kubectl rollout status sts/` 명령어도 사용할 수 있다. #### 단계적으로 업데이트 하기 {#staging-an-update} `RollingUpdate` 업데이트 전략의 파라미터인 `partition`를 이용하여 스테이트풀셋의 단계적으로 업데이트할 수 있다. -단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 +단계적 업데이트는 스테이트풀셋의 모든 파드를 현재 버전으로 유지하면서 스테이트풀셋의 `.spec.template`에 변경을 허용한다. 스테이트풀셋 `web`의 `updateStrategy` 필드에 partition을 추가하자. @@ -579,12 +579,12 @@ k8s.gcr.io/nginx-slim:0.8 ``` 비록 업데이트 전략이 `RollingUpdate`이지만 스테이트풀셋은 -파드를 그것의 원래 컨테이너로 복원한다. -파드의 순번이 `updateStrategy`에서 지정된 +파드를 그것의 원래 컨테이너로 복원한다. +파드의 순번이 `updateStrategy`에서 지정된 `파티션`보다 작기 때문이다. #### 카나리(Canary) 롤링 아웃 -[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 +[위에서](#staging-an-update) 지정한 `partition`값을 차감시키면 변경사항을 테스트하기 위해 카나리 롤아웃을 할 수 있다. 스테이트풀셋에 partition을 차감하도록 패치하자. @@ -614,7 +614,7 @@ k8s.gcr.io/nginx-slim:0.7 ``` `partition`을 바꾸면 스테이트풀셋 컨트롤러는 자동으로 -`web-2` 파드를 업데이트하는데 +`web-2` 파드를 업데이트하는데 이는 해당 파드의 순번이 `partition` 이상이기 때문이다. `web-1` 파드를 삭제하자. @@ -649,17 +649,17 @@ k8s.gcr.io/nginx-slim:0.8 ``` -`web-1` 는 원래 환경설정으로 복원되었는데 -이는 파드의 순번이 partition보다 작기 때문이다. -스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을 -가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나 +`web-1` 는 원래 환경설정으로 복원되었는데 +이는 파드의 순번이 partition보다 작기 때문이다. +스테이트풀셋의 `.spec.template`이 갱신되면, 지정된 partition 이상의 순번을 +가진 모든 파드는 업데이트된다. 미만의 순번을 가진 파드라면 삭제되거나 종료되어 원래 환경설정으로 복원된다. #### 단계적 롤아웃 -[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게 -분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 -수행할 수 있다. 단계적 롤아웃을 수행하려면 -컨트롤러가 업데이트를 일시 중지할 순번으로 +[카나리 롤아웃](#rolling-out-a-canary)에서 했던 방법과 비슷하게 +분할된 롤링 업데이트를 이용하여 단계적 롤아웃(e.g. 선형, 기하 또는 지수적 롤아웃)을 +수행할 수 있다. 단계적 롤아웃을 수행하려면 +컨트롤러가 업데이트를 일시 중지할 순번으로 `partition`를 정하자. partition은 현재 `2`이다. partition을 `0`으로 바꾸자. @@ -700,20 +700,20 @@ k8s.gcr.io/nginx-slim:0.7 ``` -`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 +`partition`을 `0`으로 이동하여 스테이트풀셋 컨트롤러에서 계속해서 업데이트 처리를 하도록 허용하였다. ### 삭제시 동작 `OnDelete` 업데이트 전략은 예전 동작(1.6 이하)으로, 이 업데이트 전략을 선택하면 스테이트풀셋 컨트롤러는 스테이트풀셋의 -`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다. +`.spec.template` 필드에 수정 사항이 발생해도 자동으로 파드를 업데이트하지 않는다. 이 전략은 `.spec.template.updateStrategy.type`을 `OnDelete`로 설정하여 선택할 수 있다. ## 스테이트풀셋 삭제하기 -스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다. -비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다. +스테이트풀셋은 비종속적(non-cascading), 종속적(cascading) 삭제를 둘 다 지원한다. +비종속적 삭제에서는 스테이트풀셋이 지워질 때에 스테이트풀셋의 파드는 지워지지 않는다. 종속적 삭제에서는 스테이트풀셋과 그에 속한 파드가 모두 지워진다. ### 비종속적 삭제 @@ -724,9 +724,9 @@ k8s.gcr.io/nginx-slim:0.7 kubectl get pods -w -l app=nginx ``` -다른 터미널에서는 스테이트풀셋을 지우기 위해 -[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자. -이 명령어에 `--cascade=false` 파라미터가 추가되었다. +다른 터미널에서는 스테이트풀셋을 지우기 위해 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자. +이 명령어에 `--cascade=false` 파라미터가 추가되었다. 이 파라미터는 쿠버네티스에 스테이트풀셋만 삭제하고 그에 속한 파드는 지우지 않도록 요청한다. ```shell @@ -744,7 +744,7 @@ web-1 1/1 Running 0 7m web-2 1/1 Running 0 5m ``` -비록 `web`이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다. +비록 `web`이 삭제되고 있어도, 모든 파드는 여전히 Running과 Ready 상태이다. `web-0`을 삭제하자. ```shell @@ -769,17 +769,17 @@ web-2 1/1 Running 0 7m kubectl get pods -w -l app=nginx ``` -두번째 터미널에서 스테이트풀셋을 다시 생성하자. -`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를 +두번째 터미널에서 스테이트풀셋을 다시 생성하자. +`nginx` 서비스(가지지 말았어야 하는)를 삭제하기 전까지는 그 서비스가 이미 존재한다는 에러를 볼 것이라는 것을 명심하자. ```shell kubectl apply -f web.yaml statefulset.apps/web created -Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists +service/nginx unchanged ``` -이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 +이 에러는 무시하자. 이것은 다만 해당 서비스가 있더라도 nginx 헤드리스 서비스를 생성하려고 했음을 뜻한다. 첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보자. @@ -800,14 +800,14 @@ web-2 0/1 Terminating 0 3m web-2 0/1 Terminating 0 3m ``` -`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다. -`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 -전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 -`web-0`을 재생성했다면 `web-1`이 -이미 Running과 Ready 상태이고, +`web` 스테이트풀셋이 다시 생성될때 먼저 `web-0` 시작한다. +`web-1`은 이미 Running과 Ready 상태이므로 `web-0`이 Running과 Ready 상태로 +전환될 때는 단순히 이 파드에 적용됬다. 스테이트풀셋에`replicas`를 2로 하고 +`web-0`을 재생성했다면 `web-1`이 +이미 Running과 Ready 상태이고, `web-2`은 종료되었을 것이다. -파드의 웹서버에서 제공한 `index.html` 파일 내용을 +파드의 웹서버에서 제공한 `index.html` 파일 내용을 다른 관점으로 살펴보자. ```shell @@ -816,10 +816,10 @@ web-0 web-1 ``` -스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던 -원래 호스트네임을 제공한다. 스테이트풀셋은 -파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다. -다시 스테이트풀셋을 생성하면 `web-0`을 시작하며 +스테이트풀셋과 `web-0` 파드를 둘다 삭제했으나 여전히 `index.html` 파일에 입력했던 +원래 호스트네임을 제공한다. 스테이트풀셋은 +파드에 할당된 퍼시스턴트볼륨을 결코 삭제하지 않기때문이다. +다시 스테이트풀셋을 생성하면 `web-0`을 시작하며 원래 퍼시스턴트볼륨을 다시 마운트한다. ### 단계식 삭제 @@ -830,14 +830,14 @@ web-1 kubectl get pods -w -l app=nginx ``` -다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는 +다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는 `--cascade=false` 파라미터를 생략하자. ```shell kubectl delete statefulset web statefulset.apps "web" deleted ``` -첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 +첫째 터미널에서 실행 중인 `kubectl get` 명령어의 출력을 살펴보고 모든 파드가 Terminating 상태로 전환될때까지 기다리자. ```shell @@ -857,13 +857,13 @@ web-1 0/1 Terminating 0 29m ``` -[스케일 다운](#scaling-down) 섹션에서 보았듯 파드는 -각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때 -스테이트풀 컨트롤러는 이전 파드가 +[스케일 다운](#scaling-down) 섹션에서 보았듯 파드는 +각 순번의 역순으로 하나씩 종료된다. 파드가 종료될 때 +스테이트풀 컨트롤러는 이전 파드가 완전히 종료되기까지 기다린다. -스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 -삭제하지 않음을 주의하자. +스테이트풀셋과 그 파드를 종속적으로 삭제하는 중에 연관된 헤드리스 서비스를 +삭제하지 않음을 주의하자. 꼭 `nginx` 서비스를 수동으로 삭제해라. ```shell @@ -879,7 +879,7 @@ service/nginx created statefulset.apps/web created ``` -스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때 +스테이트풀셋의 모든 파드가 Running과 Ready 상태로 전환될 때 `index.html` 파일 내용을 검색하자. ```shell @@ -888,8 +888,8 @@ web-0 web-1 ``` -스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 -다시 생성되고 `web-0`과 `web-1`은 여전히 +스테이트풀셋과 그 내부의 모든 파드를 삭제했지만 퍼시스턴트볼륨이 마운트된 채로 +다시 생성되고 `web-0`과 `web-1`은 여전히 각 호스트네임을 제공한다. 최종적으로 `web` 스테이트풀셋과`nginx` 서비스를 삭제한다. @@ -904,29 +904,29 @@ statefulset "web" deleted ## 파드 관리 정책 -일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은 -불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다. -이를 해결하기 위해 쿠버네티스 1.7에서 `.spec.podManagementPolicy`를 +일부 분산 시스템의 경우 스테이트풀셋의 순서 보증은 +불필요하거나 바람직하지 않다. 이러한 시스템은 고유성과 신원만 필요하다. +이를 해결하기 위해 쿠버네티스 1.7에서 `.spec.podManagementPolicy`를 스테이트풀셋 API 오브젝트에 도입했다. ### OrderedReady 파드 관리 -`OrderedReady` 파드 관리는 스테이트풀셋에서는 기본이다. -이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를 +`OrderedReady` 파드 관리는 스테이트풀셋에서는 기본이다. +이는 스테이트풀셋 컨트롤러가 지금까지 위에서 설명했던 순서를 보증함을 뜻한다. ### Parallel 파드 관리 -`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를 -병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에 -파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지 +`Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를 +병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에 +파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지 기다리지 않음을 뜻한다. {{< codenew file="application/web/web-parallel.yaml" >}} 상기 예제를 다운로드받아 파일 이름을 `web-parallel.yaml`로 저장하자. -이 매니페스트는 `web` 스테이트풀셋의 `.spec.podManagementPolicy`이 +이 매니페스트는 `web` 스테이트풀셋의 `.spec.podManagementPolicy`이 `Parallel`인 것 말고는 이전에 다운로드 받았던 것과 동일하다. 터미널에서 스테이트풀셋의 파드를 감시하자. @@ -960,7 +960,7 @@ web-1 1/1 Running 0 10s 스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘다 동시에 시작했다. -두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 +두번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 스케일링 하자. ```shell @@ -980,7 +980,7 @@ web-3 1/1 Running 0 26s ``` -스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다. +스테이트풀 컨트롤러는 두개의 새 파드를 시작하였다. 두번째 것을 런칭하기 위해 먼저 런칭한 것이 Running과 Ready 상태가 될 떄까지 기다리지 않는다. 이 터미널을 열어 놓고 다른 터미널에서 `web` 스테이트풀셋을 삭제하자. @@ -1017,10 +1017,10 @@ web-3 0/1 Terminating 0 9m web-3 0/1 Terminating 0 9m ``` -스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 +스테이트풀 컨트롤러는 모든 파드를 동시에 삭제한다. 파드를 삭제하기 전에 그 파드의 순서상 후계자를 기다리지 않는다. -`kubectl get` 명령어가 실행된 터미널을 닫고 +`kubectl get` 명령어가 실행된 터미널을 닫고 `nginx` 서비스를 삭제하자. ```shell @@ -1029,9 +1029,9 @@ kubectl delete svc nginx {{% /capture %}} {{% capture cleanup %}} -이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 +이 튜토리얼에서 사용된 퍼시턴트볼륨을 위한 퍼시스턴트 스토리지 미디어를 삭제해야 한다. -모든 스토리지를 반환하도록 환경, 스토리지 설정과 +모든 스토리지를 반환하도록 환경, 스토리지 설정과 프로비저닝 방법에 따른 단계를 따르자. {{% /capture %}} diff --git a/content/ko/examples/pods/inject/envars.yaml b/content/ko/examples/pods/inject/envars.yaml new file mode 100644 index 0000000000..ebf5214376 --- /dev/null +++ b/content/ko/examples/pods/inject/envars.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: envar-demo + labels: + purpose: demonstrate-envars +spec: + containers: + - name: envar-demo-container + image: gcr.io/google-samples/node-hello:1.0 + env: + - name: DEMO_GREETING + value: "Hello from the environment" + - name: DEMO_FAREWELL + value: "Such a sweet sorrow"