From 3c3831592e2ff1a6ce09750e855154b13896c4d7 Mon Sep 17 00:00:00 2001 From: Seokho Son Date: Fri, 8 Nov 2019 16:22:44 +0900 Subject: [PATCH] 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 Co-Authored-By: Cheolgu Kim Co-Authored-By: June Yi Co-Authored-By: Seokho Son --- .../concepts/architecture/cloud-controller.md | 2 +- .../cluster-administration/federation.md | 22 +- .../overview/working-with-objects/names.md | 21 +- .../workloads/controllers/deployment.md | 8 +- .../workloads/controllers/ttlafterfinished.md | 87 ++ .../workloads/pods/ephemeral-containers.md | 210 +++++ content/ko/docs/contribute/localization_ko.md | 72 +- .../docs/reference/glossary/applications.md | 2 +- .../ko/docs/reference/glossary/replica-set.md | 11 +- .../ko/docs/reference/kubectl/cheatsheet.md | 3 +- content/ko/docs/setup/_index.md | 1 + .../docs/setup/best-practices/certificates.md | 34 +- .../setup/best-practices/node-conformance.md | 2 +- .../resource-metrics-pipeline.md | 8 +- .../declarative-config.md | 2 +- .../imperative-config.md | 2 +- .../kustomization.md | 831 ++++++++++++++++++ .../horizontal-pod-autoscale-walkthrough.md | 4 +- 18 files changed, 1243 insertions(+), 79 deletions(-) create mode 100644 content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md create mode 100644 content/ko/docs/concepts/workloads/pods/ephemeral-containers.md create mode 100644 content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index d31d11aaf9..4bdef8c662 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -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) diff --git a/content/ko/docs/concepts/cluster-administration/federation.md b/content/ko/docs/concepts/cluster-administration/federation.md index 81584a28e1..7d7fb35a0a 100644 --- a/content/ko/docs/concepts/cluster-administration/federation.md +++ b/content/ko/docs/concepts/cluster-administration/federation.md @@ -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/) diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 8896f2e931..37a1a22642 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -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 %}} diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index f721d81fff..13995f8c04 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -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 ``` diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md new file mode 100644 index 0000000000..94b34ff0ce --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -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 %}} diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md new file mode 100644 index 0000000000..6e831326c6 --- /dev/null +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -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: + Host Port: + Command: + sh + State: Running + Started: Thu, 29 Aug 2019 06:42:21 +0000 + Ready: False + Restart Count: 0 + Environment: + Mounts: +... +``` + +사용자는 `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 %}} diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index 0d975db927..775fcccd21 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -42,6 +42,40 @@ content_template: templates/concept 접시를 씻고 | 설거지를 하고 가게에 배들, 사과들, 복숭아들이 있다 (과다한 복수형) | 가게에 배, 사과, 복숭아들이 있다 +### 한글과 영어 혼용에 관련한 원칙 + +한글과 영어 단어 중 선택은 다음의 우선 순위를 따르나, 자연스럽지 않은 용어를 무리하게 선택하지는 않는다. + +* 한글 단어 + * 순 우리말 단어 + * 한자어 (예: 운영 체제), 외래어 (예: 쿠버네티스, 파드) +* 한영 병기 (예: 훅(hook)) +* 영어 단어 (예: Kubelet) + +단, 자연스러움을 판단하는 기준은 주관적이므로 다음의 [용어집](#용어집)과 기존에 번역된 문서를 참고한다. + +{{% note %}} +한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 적용하고 이후 부터는 한글만 표기한다. +{{% /note %}} + +#### API 오브젝트는 외래어 표기법에 따라 한글 표기 + +쿠버네티스 API 오브젝트는 원 단어를 +[국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에 +따라 한글화 한다. 예를 들면 다음과 같다. + +원 단어 | 외래어 표기 +--- | --- +Deployment | 디플로이먼트 +Pod | 파드 +Service | 서비스 + +{{% note %}} +API 오브젝트의 필드 이름, 파일 이름, 경로와 같은 내용은 독자가 구성 파일이나 +커맨드라인에서 그대로 사용할 가능성이 높으므로 한글로 옮기지 않고 원문을 유지한다. +단, 주석에 포함된 내용은 한글로 옮길 수 있다. +{{% /note %}} + ## 문서 코딩 가이드 ### 가로폭은 원문을 따름 @@ -57,7 +91,6 @@ content_template: templates/concept 삭제한다. ```diff ---- - reviews: - - reviewer1 - - reviewer2 @@ -65,44 +98,9 @@ content_template: templates/concept + title: 쿠버네티스 컴포넌트 content_template: templates/concept weight: 10 ---- ``` -## 용어 - -용어 선택은 다음의 우선 순위를 따르나, 자연스럽지 않은 용어를 무리하게 선택하지는 않는다. - - -* 한글 단어 - * 순 우리말 단어 - * 한자어 (예: 운영 체제), 외래어 (예: 쿠버네티스, 파드) -* 한영 병기 (예: 훅(hook)) -* 영어 단어 (예: Kubelet) - -단, 자연스러움을 판단하는 기준은 주관적이므로 다음의 [용어집](#용어집)과 기존에 번역된 문서를 참고한다. - -{{% note %}} -API 오브젝트는 원 단어를 -[국립국어원 외래어 표기법](http://www.korean.go.kr/front/page/pageView.do?page_id=P000104&mn_id=97)에 -따라 한글화 한다. 예를 들면 다음과 같다. - -원 단어 | 외래어 ---- | --- -Deployment | 디플로이먼트 -Pod | 파드 -Service | 서비스 -{{% /note %}} - -{{% note %}} -API 오브젝트의 필드 이름, 파일 이름, 경로 이름과 같은 내용은 주로 코드 스타일로 기술된다. 이는 독자가 구성 파일이나 -커맨드라인에서 그대로 사용할 가능성이 높으므로 한글로 옮기지 않고 원문을 유지한다. 단, 주석은 한글로 옮길 수 있다. -{{% /note %}} - -{{% note %}} -한영 병기는 페이지 내에서 해당 용어가 처음 사용되는 경우에만 적용하고 이후 부터는 한글만 표기한다. -{{% /note %}} - -### 용어집 +## 용어집 English | 한글 | 비고 --- | --- | --- diff --git a/content/ko/docs/reference/glossary/applications.md b/content/ko/docs/reference/glossary/applications.md index c8c7c0d029..d3b5547469 100644 --- a/content/ko/docs/reference/glossary/applications.md +++ b/content/ko/docs/reference/glossary/applications.md @@ -1,6 +1,6 @@ --- title: 애플리케이션(Applications) -id: appplications +id: applications date: 2019-05-12 full_link: short_description: > diff --git a/content/ko/docs/reference/glossary/replica-set.md b/content/ko/docs/reference/glossary/replica-set.md index d9ac9ae4d4..3b92ae31bd 100755 --- a/content/ko/docs/reference/glossary/replica-set.md +++ b/content/ko/docs/reference/glossary/replica-set.md @@ -1,10 +1,10 @@ --- -title: 레플리카 셋(ReplicaSet) +title: 레플리카셋(ReplicaSet) id: replica-set date: 2018-04-12 full_link: /docs/concepts/workloads/controllers/replicaset/ short_description: > - 레플리카 셋은 차세대 레플리케이션 컨트롤러이다. + 레플리카셋은 지정된 수의 파드 레플리카가 동시에 실행이 되도록 보장한다 aka: tags: @@ -12,9 +12,10 @@ tags: - core-object - workload --- - 레플리카 셋은 차세대 레플리케이션 컨트롤러이다. + 레플리카셋은 (목표로) 주어진 시간에 실행되는 레플리카 파드 셋을 유지 관리 한다. -레플리케이션 컨트롤러와 같은 레플리카 셋은, 지정된 수의 파드 레플리카가 동시에 동작하게 관리한다. 레플리카 셋은 레이블 사용자 가이드에 기술된 대로 셋(set) 기반의 셀렉터 요구 사항을 지원한다. 반면, 레플리케이션 컨트롤러는 동일성 기반의 셀렉터 요구 사항만 제공한다. - +{{< glossary_tooltip term_id="deployment" >}} 와 같은 워크로드 오브젝트는 레플리카셋을 +사용해서 해당 레플리카셋의 스펙에 따라 구성된 {{< glossary_tooltip term_id="pod" text="파드" >}} 의 +수를 클러스터에서 실행한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 930af362cb..231373cbec 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -58,6 +58,7 @@ kubectl config view # e2e 사용자의 암호를 확인한다 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' +kubectl config view -o jsonpath='{.users[].name}' # 첫 번째 사용자 출력 kubectl config view -o jsonpath='{.users[*].name}' # 사용자 리스트 조회 kubectl config get-contexts # 컨텍스트 리스트 출력 kubectl config current-context # 현재 컨텍스트 출력 @@ -268,7 +269,7 @@ kubectl delete -f ./pod.json # pod. kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제 kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제 kubectl delete pods,services -l name=myLabel --include-uninitialized # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제 -kubectl -n my-ns delete po,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제 +kubectl -n my-ns delete pod,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제 # awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제 kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 20791313ab..c50b7d3314 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -73,6 +73,7 @@ card: | [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| | [Canonical](https://ubuntu.com/kubernetes) | ✔ | ✔ | ✔ | ✔ |✔ | ✔ | [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | | +| [D2iQ](https://d2iq.com/) | | [Kommander](https://d2iq.com/solutions/ksphere) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | [Konvoy](https://d2iq.com/solutions/ksphere/konvoy) | | [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ | [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | | [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 0d833c95d8..810c02f4ea 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -54,6 +54,8 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | etcd/ca.crt,key | etcd-ca | 모든 etcd 관련 기능을 위해서 | | front-proxy-ca.crt,key | kubernetes-front-proxy-ca | [front-end proxy][proxy] 위해서 | +위의 CA외에도, 서비스 계정 관리를 위한 공개/개인 키 쌍인 `sa.key` 와 `sa.pub` 을 얻는 것이 필요하다. + ### 모든 인증서 이런 개인키를 API 서버에 복사하기 원치 않는다면, 모든 인증서를 스스로 생성할 수 있다. @@ -70,7 +72,8 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | | front-proxy-client | kubernetes-front-proxy-ca | | client | | -[1]: `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, `kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local` +[1]: 클러스터에 접속한 다른 IP 또는 DNS 이름([kubeadm][kubeadm] 이 사용하는 로드 밸런서 안정 IP 또는 DNS 이름, `kubernetes`, `kubernetes.default`, `kubernetes.default.svc`, +`kubernetes.default.svc.cluster`, `kubernetes.default.svc.cluster.local`) `kind`는 하나 이상의 [x509 키 사용][usage] 종류를 가진다. @@ -79,6 +82,19 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | server | digital signature, key encipherment, server auth | | client | digital signature, key encipherment, client auth | +{{< note >}} +위에 나열된 호스트/SAN은 작업 중인 클러스터를 획득하는데 권장된다. 특정 설정이 필요한 경우, 모든 서버 인증서에 SAN을 추가할 수 있다. +{{< /note >}} + +{{< note >}} +kubeadm 사용자만 해당: + +* 개인 키 없이 클러스터 CA 인증서에 복사하는 시나리오는 kubeadm 문서에서 외부 CA라고 한다. +* 위 목록을 kubeadm이 생성한 PKI와 비교하는 경우, `kube-etcd`, `kube-etcd-peer` 와 `kube-etcd-healthcheck-client` 인증서는 + 외부 etcd 케이스에서는 생성하지 않는 것을 알고 있어야 한다. + +{{< /note >}} + ### 인증서 파일 경로 인증서는 권고하는 파일 경로에 존재해야 한다([kubeadm][kubeadm]에서 사용되는 것처럼). 경로는 위치에 관계없이 주어진 파라미터를 사용하여 지정되야 한다. @@ -88,18 +104,24 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | | etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | | kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file, --root-ca-file, --cluster-signing-cert-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | -| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate | +| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | | front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | -| | | | | | | | etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | -| etcd-ca | | etcd/ca.crt | etcdctl[2] | | --cacert | -| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl[2] | --key | --cert | +| etcd-ca | | etcd/ca.crt | etcdctl | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert | -[2]: 셀프 호스팅시, 생존신호(liveness probe)를 위해 +서비스 계정 키 쌍에도 동일한 고려 사항이 적용된다. + +| 개인키 경로 | 공개 키 경로 | 명령어 | 파라미터 | +|------------------------------|-----------------------------|-------------------------|--------------------------------------| +| sa.key | | kube-controller-manager | service-account-private | +| | sa.pub | kube-apiserver | service-account-key | ## 각 사용자 계정을 위한 인증서 설정하기 diff --git a/content/ko/docs/setup/best-practices/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md index 7e3e62dfa1..399e7f13a5 100644 --- a/content/ko/docs/setup/best-practices/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -73,7 +73,7 @@ sudo docker run -it --rm --privileged --net=host \ k8s.gcr.io/node-test:0.2 ``` -노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/e2e-node-tests.md)를 컨테이너화한 버전이다. +노드 적합성 테스트는 [노드 e2e 테스트](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/sig-node/e2e-node-tests.md)를 컨테이너화한 버전이다. 기본적으로, 모든 적합성 테스트를 실행한다. 이론적으로, 컨테이너와 필요한 볼륨을 적절히 설정했다면 어떤 노드 e2e 테스트도 수행할 수 있다. 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 index b314f9683c..05b08113e7 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -5,7 +5,7 @@ content_template: templates/concept {{% capture overview %}} -쿠버네티스 1.8 부터 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 +컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량 메트릭은 쿠버네티스의 메트릭 API를 통해 사용할 수 있다. 이 메트릭은 `kubectl top` 커맨드 사용과 같이 사용자가 직접적으로 액세스하거나, Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 내릴 때 사용될 수 있다. @@ -37,15 +37,13 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을 ## 메트릭 서버 [메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -쿠버네티스 1.8 부터 `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 +`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [배포 yaml들](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy)을 사용하여 메트릭 서버를 배포할 수 있다. -이 방식은 쿠버네티스 1.7 이상에서 지원된다. (상세 사항은 아래를 참조) 메트릭 서버는 각 노드에서 [Kubelet](/docs/admin/kubelet/)에 의해 노출된 Summary API에서 메트릭을 수집한다. -메트릭 서버는 쿠버네티스 1.7에서 도입된 -[쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 +메트릭 서버는 [쿠버네티스 aggregator](/docs/concepts/api-extension/apiserver-aggregation/)를 통해 메인 API 서버에 등록된다. [설계 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md)에서 메트릭 서버에 대해 자세하게 배울 수 있다. diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 8d0795441f..83f787b152 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -762,7 +762,7 @@ spec: rollingUpdate: # defaulted by apiserver - derived from strategy.type maxSurge: 1 maxUnavailable: 1 - type: RollingUpdate # defaulted apiserver + type: RollingUpdate # defaulted by apiserver template: metadata: creationTimestamp: null diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index a2b43e7133..1080064ff1 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -29,7 +29,7 @@ weight: 40 * 선언형 오브젝트 구성 각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 -[쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/)를 참고한다. +[쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. ## 오브젝트 생성 방법 diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md new file mode 100644 index 0000000000..1d395362fd --- /dev/null +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -0,0 +1,831 @@ +--- +title: Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리 +content_template: templates/task +weight: 20 +--- + +{{% capture overview %}} + +[Kustomize](https://github.com/kubernetes-sigs/kustomize)는 +[kustomization 파일](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md#kustomization)을 +통해 쿠버네티스 오브젝트를 사용자가 원하는 대로 변경하는(customize) 독립형 도구이다. + +1.14 이후로, kubectl도 +kustomization 파일을 사용한 쿠버네티스 오브젝트의 관리를 지원한다. +kustomization 파일을 포함하는 디렉터리 내의 리소스를 보려면 다음 명령어를 실행한다. + +```shell +kubectl kustomize +``` + +이 리소스를 적용하려면 `kubectl apply`를 `--kustomize` 또는 `-k` 플래그와 함께 실행한다. + +```shell +kubectl apply -k +``` + +{{% /capture %}} + +{{% capture prerequisites %}} + +[`kubectl`](/docs/tasks/tools/install-kubectl/)을 설치한다. + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +{{% /capture %}} + +{{% capture steps %}} + +## Kustomize 개요 + +Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다. 이는 애플리케이션 구성 파일을 관리하기 위해 다음 기능들을 가진다. + +* 다른 소스에서 리소스 생성 +* 리소스에 대한 교차 편집 필드 설정 +* 리소스 집합을 구성하고 사용자 정의 + +### 리소스 생성 + +컨피그 맵과 시크릿은 파드같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. +컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일같이 다른 곳에서 가져온다. +Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다. + +#### configMapGenerator + +파일에서 컨피그 맵을 생성하려면 `configMapGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 하나의 파일 콘텐츠에서 데이터 항목으로 컨피그 맵을 생성하는 예제이다. + +```shell +# application.properties 파일을 생성 +cat <application.properties +FOO=Bar +EOF + +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-1 + files: + - application.properties +EOF +``` + +생성된 컨피그 맵은 다음 명령어를 통해 확인할 수 있다. + +```shell +kubectl kustomize ./ +``` + +생성된 컨피그 맵은 다음과 같다. + +```yaml +apiVersion: v1 +data: + application.properties: | + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-8mbdf7882g +``` + +컨피그 맵은 문자로된 키-값 쌍들로도 생성할 수 있다. 문자로된 키-값 쌍에서 컨피그 맵을 생성하려면, configMapGenerator 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 컨피그 맵을 생성하는 예제이다. + +```shell +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-2 + literals: + - FOO=Bar +EOF +``` + +생성된 컨피그 맵은 다음 명령어로 확인할 수 있다. + +```shell +kubectl kustomize ./ +``` + +생성된 컨피그 맵은 다음과 같다. + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + name: example-configmap-2-g2hdhfc6tk +``` + +#### secretGenerator + +파일 또는 문자로된 키-값 쌍들로 시크릿을 생성할 수 있다. 파일에서 시크릿을 생성하려면 `secretGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 파일을 데이터 항목으로 받는 시크릿을 생성하는 예제이다. + +```shell +# password.txt 파일을 생성 +cat <./password.txt +username=admin +password=secret +EOF + +cat <./kustomization.yaml +secretGenerator: +- name: example-secret-1 + files: + - password.txt +EOF +``` + +생성된 시크릿은 다음과 같다. + +```yaml +apiVersion: v1 +data: + password.txt: dXNlcm5hbWU9YWRtaW4KcGFzc3dvcmQ9c2VjcmV0Cg== +kind: Secret +metadata: + name: example-secret-1-t2kt65hgtb +type: Opaque +``` + +문자로된 키-값 쌍으로 시크릿을 생성하려면, `secretGenerator` 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 시크릿을 생성하는 예제이다. + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: example-secret-2 + literals: + - username=admin + - password=secret +EOF +``` + +생성된 시크릿은 다음과 같다. + +```yaml +apiVersion: v1 +data: + password: c2VjcmV0 + username: YWRtaW4= +kind: Secret +metadata: + name: example-secret-2-t52t6g96d8 +type: Opaque +``` + +#### generatorOptions + +생성된 컨피그 맵과 시크릿은 콘텐츠를 해쉬화하여 덧붙이는 접미사를 가진다. 이는 콘텐츠가 변경될 때 새로운 컨피그 맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 `generatorOptions`를 사용할 수 있다. 그밖에, 생성된 컨피그 맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다. + +```shell +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-3 + literals: + - FOO=Bar +generatorOptions: + disableNameSuffixHash: true + labels: + type: generated + annotations: + note: generated +EOF +``` + +생성된 컨피그 맵을 보려면 `kubectl kustomize ./`를 실행한다. + +```yaml +apiVersion: v1 +data: + FOO: Bar +kind: ConfigMap +metadata: + annotations: + note: generated + labels: + type: generated + name: example-configmap-3 +``` + +### 교차 편집 필드 설정 + +프로젝트 내 모든 쿠버네티스 리소스에 교차 편집 필드를 설정하는 것은 꽤나 일반적이다. +교차 편집 필드를 설정하는 몇 가지 사용 사례는 다음과 같다. + +* 모든 리소스에 동일한 네임스페이스를 설정 +* 동일한 네임 접두사 또는 접미사를 추가 +* 동일한 레이블들을 추가 +* 동일한 어노테이션들을 추가 + +다음은 예제이다. + +```shell +# deployment.yaml을 생성 +cat <./deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx +EOF + +cat <./kustomization.yaml +namespace: my-namespace +namePrefix: dev- +nameSuffix: "-001" +commonLabels: + app: bingo +commonAnnotations: + oncallPager: 800-555-1212 +resources: +- deployment.yaml +EOF +``` + +이 필드들이 디플로이먼트 리소스에 모두 설정되었는지 보려면 `kubectl kustomize ./`를 실행한다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + name: dev-nginx-deployment-001 + namespace: my-namespace +spec: + selector: + matchLabels: + app: bingo + template: + metadata: + annotations: + oncallPager: 800-555-1212 + labels: + app: bingo + spec: + containers: + - image: nginx + name: nginx +``` + +### 리소스 구성과 사용자 정의 + +프로젝트 내 리소스의 집합을 구성하여 이들을 동일한 파일이나 디렉터리 내에서 +관리하는 것은 일반적이다. +Kustomize는 서로 다른 파일들로 리소스를 구성하고 패치나 다른 사용자 정의를 이들에 적용하는 것을 제공한다. + +#### 구성 + +Kustomize는 서로 다른 리소스들의 구성을 지원한다. `kustomization.yaml` 파일 내 `resources` 필드는 구성 내에 포함하려는 리소스들의 리스트를 정의한다. `resources` 리스트 내에 리소스의 구성 파일의 경로를 설정한다. +다음 예제는 디플로이먼트와 서비스를 가지는 nginx 애플리케이션이다. + +```shell +# deployment.yaml 파일 생성 +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# service.yaml 파일 생성 +cat < service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +# 이들을 구성하는 kustomization.yaml 생성 +cat <./kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +`kubectl kustomize ./`의 리소스는 디플로이먼트와 서비스 오브젝트 모두를 포함한다. + +#### 사용자 정의 + +리소스 위에 패치를 적용하는 것으로 서로 다른 사용자 정의들을 적용할 수 있다. Kustomize는 +`patchesStrategicMerge`와 `patchesJson6902`를 통해 서로 다른 패치 메커니즘을 지원한다. `patchesStrategicMerge`는 파일 경로들의 리스트이다. 각각의 파일은 [전략적 병합 패치](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/strategic-merge-patch.md)로 분석될 수 있어야 한다. 패치 내부의 네임은 반드시 이미 읽혀진 리소스 네임과 일치해야 한다. 한 가지 일을 하는 작은 패치가 권장된다. 예를 들기 위해 디플로이먼트 레플리카 숫자를 증가시키는 하나의 패치와 메모리 상한을 설정하는 다른 패치를 생성한다. + +```shell +# deployment.yaml 파일 생성 +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# increase_replicas.yaml 패치 생성 +cat < increase_replicas.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 +EOF + +# 다른 패치로 set_memory.yaml 생성 +cat < set_memory.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + template: + spec: + containers: + - name: my-nginx + resources: + limits: + memory: 512Mi +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +patchesStrategicMerge: +- increase_replicas.yaml +- set_memory.yaml +EOF +``` + +디플로이먼트를 보려면 `kubectl kustomize ./`를 실행한다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + limits: + memory: 512Mi + name: my-nginx + ports: + - containerPort: 80 +``` + +모든 리소스 또는 필드가 전략적 병합 패치를 지원하는 것은 아니다. 임의의 리소스 내 임의의 필드의 수정을 지원하기 위해, +Kustomize는 `patchesJson6902`를 통한 [JSON 패치](https://tools.ietf.org/html/rfc6902) 적용을 제공한다. +Json 패치의 정확한 리소스를 찾기 위해, 해당 리소스의 group, version, kind, name이 +`kustomization.yaml` 내에 명시될 필요가 있다. 예를 들면, `patchesJson6902`를 통해 +디플로이먼트 오브젝트의 레플리카 개수를 증가시킬 수 있다. + +```shell +# deployment.yaml 파일 생성 +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# json 패치 생성 +cat < patch.yaml +- op: replace + path: /spec/replicas + value: 3 +EOF + +# kustomization.yaml 생성 +cat <./kustomization.yaml +resources: +- deployment.yaml + +patchesJson6902: +- target: + group: apps + version: v1 + kind: Deployment + name: my-nginx + path: patch.yaml +EOF +``` + +`kubectl kustomize ./`를 실행하여 `replicas` 필드가 갱신되었는지 확인한다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 3 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: nginx + name: my-nginx + ports: + - containerPort: 80 +``` + +패치 기능에 추가로 Kustomize는 패치를 생성하지 않고 컨테이너 이미지를 사용자 정의하거나 다른 오브젝트의 필드 값을 컨테이너에 주입하는 +기능도 제공한다. 예를 들어 `kustomization.yaml`의 `images` 필드에 신규 이미지를 지정하여 컨테이너에서 사용되는 이미지를 변경할 수 있다. + +```shell +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +images: +- name: nginx + newName: my.image.registry/nginx + newTag: 1.4.0 +EOF +``` +사용된 이미지가 갱신되었는지 확인하려면 `kubectl kustomize ./`를 실행한다. +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - image: my.image.registry/nginx:1.4.0 + name: my-nginx + ports: + - containerPort: 80 +``` + +가끔, 파드 내에서 실행되는 애플리케이션이 다른 오브젝트의 설정 값을 사용해야 할 수도 있다. 예를 들어, +디플로이먼트 오브젝트의 파드는 Env 또는 커맨드 인수로 해당 서비스 네임을 읽어야 한다고 하자. +`kustomization.yaml` 파일에 `namePrefix` 또는 `nameSuffix`가 추가되면 서비스 네임이 변경될 수 있다. +커맨드 인수 내에 서비스 네임을 하드 코딩하는 것을 권장하지 않는다. 이 용도에서 Kustomize는 `vars`를 통해 containers에 서비스 네임을 삽입할 수 있다. + +```shell +# deployment.yaml 파일 생성 +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + command: ["start", "--host", "\$(MY_SERVICE_NAME)"] +EOF + +# service.yaml 파일 생성 +cat < service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF + +cat <./kustomization.yaml +namePrefix: dev- +nameSuffix: "-001" + +resources: +- deployment.yaml +- service.yaml + +vars: +- name: MY_SERVICE_NAME + objref: + kind: Service + name: my-nginx + apiVersion: v1 +EOF +``` + +`kubectl kustomize ./`를 실행하면 `dev-my-nginx-001`로 컨테이너에 삽입된 서비스 네임을 볼 수 있다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: dev-my-nginx-001 +spec: + replicas: 2 + selector: + matchLabels: + run: my-nginx + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - command: + - start + - --host + - dev-my-nginx-001 + image: nginx + name: my-nginx +``` + +## Base와 Overlay + +Kustomize는 **base**와 **overlay**의 개념을 가지고 있다. **base**는 `kustomization.yaml`과 함께 사용되는 디렉터리다. 이는 +사용자 정의와 관련된 리소스들의 집합을 포함한다. `kustomization.yaml`의 내부에 표시되는 base는 로컬 디렉터리이거나 원격 리포지터리의 디렉터리가 +될 수 있다. **overlay**는 `kustomization.yaml`이 있는 디렉터리로 +다른 kustomization 디렉터리들을 `bases`로 참조한다. **base**는 overlay에 대해서 알지 못하며 여러 overlay들에서 사용될 수 있다. +한 overlay는 다수의 base들을 가질 수 있고, base들에서 모든 리소스를 구성할 수 있으며, +이들의 위에 사용자 정의도 가질 수 있다. + +다음은 base에 대한 예이다. + +```shell +# base를 가지는 디렉터리 생성 +mkdir base +# base/deployment.yaml 생성 +cat < base/deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx +EOF + +# base/service.yaml 파일 생성 +cat < base/service.yaml +apiVersion: v1 +kind: Service +metadata: + name: my-nginx + labels: + run: my-nginx +spec: + ports: + - port: 80 + protocol: TCP + selector: + run: my-nginx +EOF +# base/kustomization.yaml 생성 +cat < base/kustomization.yaml +resources: +- deployment.yaml +- service.yaml +EOF +``` + +이 base는 다수의 overlay에서 사용될 수 있다. 다른 `namePrefix` 또는 다른 교차 편집 필드들을 +서로 다른 overlay에 추가할 수 있다. 다음 예제는 동일한 base를 사용하는 두 overlay들이다. + +```shell +mkdir dev +cat < dev/kustomization.yaml +bases: +- ../base +namePrefix: dev- +EOF + +mkdir prod +cat < prod/kustomization.yaml +bases: +- ../base +namePrefix: prod- +EOF +``` + +## Kustomize를 이용하여 오브젝트를 적용/확인/삭제하는 방법 + +`kustomization.yaml`에서 관리되는 리소스를 인식하려면 `kubectl` 명령어에 `--kustomize` 나 `-k`를 사용한다. +`-k`는 다음과 같이 kustomization 디렉터리를 가리키고 있어야 한다는 것을 주의한다. + +```shell +kubectl apply -k / +``` + +다음 `kustomization.yaml`이 주어지고, + +```shell +# deployment.yaml 파일 생성 +cat < deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-nginx +spec: + selector: + matchLabels: + run: my-nginx + replicas: 2 + template: + metadata: + labels: + run: my-nginx + spec: + containers: + - name: my-nginx + image: nginx + ports: + - containerPort: 80 +EOF + +# kustomization.yaml 생성 +cat <./kustomization.yaml +namePrefix: dev- +commonLabels: + app: my-nginx +resources: +- deployment.yaml +EOF +``` + +디플로이먼트 오브젝트 `dev-my-nginx`를 적용하려면 다음 명령어를 실행한다. + +```shell +> kubectl apply -k ./ +deployment.apps/dev-my-nginx created +``` + +디플로이먼트 오브젝트 `dev-my-nginx`를 보려면 다음 명령어들 중에 하나를 실행한다. + +```shell +kubectl get -k ./ +``` + +```shell +kubectl describe -k ./ +``` + +디플로이먼트 오브젝트 `dev-my-nginx`를 삭제하려면 다음 명령어를 실행한다. + +```shell +> kubectl delete -k ./ +deployment.apps "dev-my-nginx" deleted +``` + +## Kustomize 기능 리스트 + +| 필드 | 유형 | 설명 | +|-----------------------|--------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------| +| namespace | string | 모든 리소스에 네임스페이스 추가 | +| namePrefix | string | 모든 리소스 네임에 이 필드의 값이 접두사로 추가된다 | +| nameSuffix | string | 모든 리소스 네임에 이 필드의 값이 접미사로 추가된다 | +| commonLabels | map[string]string | 모든 리소스와 셀렉터에 추가될 레이블 | +| commonAnnotations | map[string]string | 모든 리소스에 추가될 어노테이션 | +| resources | []string | 이 리스트 내 각각의 항목은 반드시 존재하는 리소스 구성 파일로 해석되어져야 한다 | +| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L195) | 이 리스트 내 각각의 항목은 컨피그 맵을 생성한다 | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L201) | 이 리스트 내 각각의 항목은 시크릿을 생성한다 | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/kustomization.go#L239) | 모든 configMapGenerator와 secretGenerator의 동작을 변경 | +| bases | []string | 이 리스트 내 각각의 항목은 kustomization.yaml 파일을 가지는 디렉터리로 해석되어져야 한다 | +| patchesStrategicMerge | []string | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트의 전략적 병합 패치로 해석되어져야 한다 | +| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/patch/json6902.go#L23) | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트와 Json 패치로 해석되어져야 한다 | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/types/var.go#L31) | 각각의 항목은 한 리소스의 필드에서 텍스트를 캡쳐한다 | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/pkg/image/image.go#L23) | 각각의 항목은 패치를 생성하지 않고 한 이미지의 name, tags 그리고/또는 digest를 수정한다 | +| configurations | []string | 이 리스트 내 각각의 항목은 [Kustomize 변환 설정](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs)을 포함하는 파일로 해석되어져야 한다 | +| crds | []string | 이 리스트 내 각각의 항목은 쿠버네티스 타입에 대한 OpenAPI 정의 파일로 해석되어져야 한다 | + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [Kustomize](https://github.com/kubernetes-sigs/kustomize) +* [Kubectl Book](https://kubectl.docs.kubernetes.io) +* [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl/) +* [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + +{{% /capture %}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 05809be861..24a54c1143 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -308,7 +308,9 @@ spec: pods: metric: name: packets-per-second - targetAverageValue: 1k + target: + type: AverageValue + averageValue: 1k - type: Object object: metric: