From bfd90bff5f3ba78e8f545ec860f5c5717e6ae6af Mon Sep 17 00:00:00 2001 From: seokho-son Date: Sat, 2 Jan 2021 23:07:59 +0900 Subject: [PATCH] Ko: Second Korean l10n work for release-1.20 - Update outdated files in the dev-1.20-ko.2(p1) (#25915) - Update outdated files in the dev-1.20-ko.2(p2) (#25916) - Fix issue with links to already translated ko documents (#25991) - Translate reference/glossary/dynamic-volume-provisioning.md in Korean (#26047) Co-authored-by: seokho-son Co-authored-by: Jerry Park Co-authored-by: santachopa --- .../community/static/cncf-code-of-conduct.md | 62 ++++---- .../control-plane-node-communication.md | 2 +- .../concepts/cluster-administration/_index.md | 2 +- .../kubelet-garbage-collection.md | 5 +- .../cluster-administration/system-metrics.md | 32 ++-- .../docs/concepts/configuration/configmap.md | 3 - .../ko/docs/concepts/configuration/secret.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 4 +- .../working-with-objects/common-labels.md | 13 +- .../concepts/policy/pod-security-policy.md | 30 +++- .../docs/concepts/policy/resource-quotas.md | 2 +- .../scheduling-eviction/kube-scheduler.md | 4 +- .../connect-applications-service.md | 2 +- content/ko/docs/concepts/workloads/_index.md | 75 ++++++--- .../workloads/controllers/cron-jobs.md | 34 ++++ .../concepts/workloads/controllers/job.md | 15 +- .../ko/docs/concepts/workloads/pods/_index.md | 30 ++++ .../workloads/pods/init-containers.md | 6 +- .../pods/pod-topology-spread-constraints.md | 6 +- content/ko/docs/reference/_index.md | 6 +- .../feature-gates.md | 10 +- .../glossary/dynamic-volume-provisioning.md | 19 +++ .../ko/docs/reference/glossary/kube-proxy.md | 4 +- .../ko/docs/reference/kubectl/cheatsheet.md | 10 +- content/ko/docs/reference/kubectl/overview.md | 12 +- .../reference/using-api/client-libraries.md | 1 + .../container-runtimes.md | 30 +++- .../tools/kubeadm/self-hosting.md | 8 +- .../production-environment/tools/kubespray.md | 5 +- .../windows/intro-windows-in-kubernetes.md | 4 +- .../configure-access-multiple-clusters.md | 6 +- ...port-forward-access-application-cluster.md | 30 +++- .../administer-cluster/access-cluster-api.md | 2 +- .../kubeadm/kubeadm-upgrade.md | 18 ++- .../debug-pod-replication-controller.md | 4 +- .../tasks/extend-kubectl/kubectl-plugins.md | 2 +- .../manage-hugepages/scheduling-hugepages.md | 21 +-- .../kustomization.md | 11 +- .../ko/docs/tasks/tools/install-kubectl.md | 4 +- .../basic-stateful-set.md | 2 +- .../stateful-application/zookeeper.md | 2 +- .../expose-external-ip-address.md | 149 +++++++++--------- 42 files changed, 437 insertions(+), 252 deletions(-) create mode 100644 content/ko/docs/reference/glossary/dynamic-volume-provisioning.md diff --git a/content/ko/community/static/cncf-code-of-conduct.md b/content/ko/community/static/cncf-code-of-conduct.md index 6e3c838fe8..804c5632fd 100644 --- a/content/ko/community/static/cncf-code-of-conduct.md +++ b/content/ko/community/static/cncf-code-of-conduct.md @@ -2,44 +2,44 @@ https://github.com/cncf/foundation/blob/master/code-of-conduct.md --> ## CNCF 커뮤니티 행동 강령 v1.0 -### 참여자 행동 강령 +### 기여자 행동 강령 -본 프로젝트의 기여자 및 유지 관리자로서, 환영하는 분위기의 공개 커뮤니티를 -육성하기 위하여, 저희는 이슈를 보고하고, 기술 요청을 작성하며, 문서를 업데이트하며, -pull 요청 또는 패치를 제출하고, 다른 활동에 참여하는 -모든 분들을 존중하겠다고 약속드립니다. +본 프로젝트의 기여자 및 메인테이너(maintainer)로서 개방적이고 친근한 분위기의 +커뮤니티 조성을 위하여, 이슈 보고, 기능 요청, 문서 업데이트, +풀 리퀘스트(pull request) 또는 패치 제출, 그리고 기타 다른 활동으로 기여하는 +모든 분들을 존중할 것을 약속합니다. -저희는 경험 수준, 성별, 성 정체성과 표현, 성적 지향, -장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, 또는 -국적에 상관 없이 모두가 괴롭힘 없는 환경에서 -본 프로젝트에 참여하도록 최선을 다하고 있습니다. +우리는 경험의 수준, 성별, 성 정체성 및 표현(gender identity and expression), +성적 지향, 장애, 외양, 신체 크기, 인종, 민족, 나이, 종교, +또는 국적에 상관 없이 모두가 차별 없는 환경에서 본 프로젝트에 +참여할 수 있도록 최선을 다하고 있습니다. -참여자에게 금지하는 행동의 예는 다음과 같습니다.: +참여자에게 금지하는 행위의 예시는 다음과 같습니다. -* 성적 언어 또는 이미지 사용 -* 개인적인 공격 -* 시비 걸기 또는 모욕/경멸적인 코멘트 -* 공적 및 사적 괴롭힘 -* 분명한 허락을 받지 않은 타인의 사적 정보 출판, - 예를 들어 물리적 또는 전자 주소 -* 다른 비윤리적 또는 비전문적인 행동 +- 성적인 언어 또는 이미지 사용 +- 인신 공격 +- 도발적이거나 모욕/경멸적인 코멘트 +- 공개적이거나 사적인 괴롭힘 +- 타인의 주소 및 전자주소와 같은 개인 정보의 + 동의 없는 공개 +- 기타 비윤리적이거나 비전문적인 행동 -프로젝트 유지 관리자는 본 행동 강령을 위반하는 코멘트, 협약, 강령, -위키 수정, 이슈와 다른 참여자를 제거, 수정, 삭제할 권한과 -책임을 가집니다. 본 행동 강령을 적용하여, 프로젝트 유지 관리자는 본 -프로젝트를 유지하는 모든 상황에 공정하고 일관적으로 이러한 원칙들을 -적용하기 위해 헌신해야 합니다. 프로젝트 유지 관리자는 -행동 강령이 프로젝트 팀에서 영구적으로 사라지도록 하거나 강요해서는 안됩니다. +프로젝트 메인테이너에게는 본 행동 강령을 위반하는 코멘트, 커밋(commit), +코드, 위키(wiki) 수정, 이슈, 그리고 그 밖의 기여에 대해서 삭제, 수정, +거부할 수 있는 권한과 책임이 있습니다. 프로젝트 메인테이너는 프로젝트 관리의 +모든 관점에서 이러한 행동 강령 원칙을 공정하고 일관되게 적용할 것을 약속해야 합니다. +행동 강령을 준수하지 않거나 시행하지 않는 프로젝트 메인테이너는 프로젝트 팀에서 +영구적으로 제적될 수 있습니다. -본 행동 강령은 프로젝트 공간과 개인이 프로젝트 또는 -그 커뮤니티를 대표하는 공적 공간에 모두 적용됩니다. +본 행동 강령은 프로젝트 활동 영역 내에서 뿐만 아니라 개인이 프로젝트 +또는 커뮤니티를 대변하는 공공의 활동 영역에서도 적용됩니다. -Kubernetes에서의 폭력, 학대 또는 기타 허용되지 않는 행동 사례는 이메일 주소 를 통해 [Kubernetes 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)로 신고하실 수 있습니다. 다른 프로젝트는 CNCF 프로젝트 관리자 또는 저희 중재자인 Mishi Choudhary에게 이메일 으로 연락하십시오. +쿠버네티스(Kubernetes)에서의 폭력, 학대 또는 기타 허용되지 않는 행위는 [쿠버네티스 행동 강령 위원회](https://git.k8s.io/community/committee-code-of-conduct)에 이메일 를 통해 신고할 수 있습니다. 다른 프로젝트의 경우는 CNCF 프로젝트 메인테이너 또는 중재자인 Mishi Choudhary의 이메일 으로 문의해 주시기 바랍니다. -본 행동강령은 참여자 Contributor Covenant (http://contributor-covenant.org)의 -버전 1.2.0을 적용하였으며, -해당 내용은 여기 http://contributor-covenant.org/version/1/2/0/에서 확인할 수 있습니다. +본 행동 강령은 기여자 서약 (https://contributor-covenant.org) 에서 +제공하는 버전 1.2.0을 적용하였으며, 해당 내용은 +https://contributor-covenant.org/version/1/2/0/ 에서 확인할 수 있습니다. -### CNCF 커뮤니티 행동 강령 +### CNCF 이벤트 행동 강령 -CNCF 이벤트는 리눅스 재단의 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/) 을 따르며, 해당 내용은 이벤트 페이지에서 확인할 수 있습니다. 본 강령은 위 정책과 호환할 수 있도록 설계되었으며, 또한 사건에 따라 더 많은 세부 내용을 포함합니다. \ No newline at end of file +CNCF 이벤트는 리눅스 재단의 이벤트 페이지에서 볼 수 있는 [행동 강령](https://events.linuxfoundation.org/code-of-conduct/)을 준수합니다. 이 행동 강령은 위의 정책과 호환되도록 설계되었으며, 사고 대응에 대한 세부 내용도 포함하고 있습니다. diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 2fdaf7599c..36ece0d6d2 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -46,7 +46,7 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. 이것이 가능하지 않은 경우, 신뢰할 수 없는 네트워크 또는 공용 네트워크를 통한 연결을 피하기 위해 필요한 경우 API 서버와 kubelet 사이에 [SSH 터널링](#ssh-터널)을 사용한다. -마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/docs/admin/kubelet-authentication-authorization/)를 활성화해야 한다. +마지막으로, kubelet API를 보호하려면 [Kubelet 인증 및/또는 권한 부여](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/)를 활성화해야 한다. ### API 서버에서 노드, 파드 및 서비스로의 통신 diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index 5ca2ce5aca..1442a5da01 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -60,7 +60,7 @@ no_list: true ### kubelet 보안 * [컨트롤 플레인-노드 통신](/ko/docs/concepts/architecture/control-plane-node-communication/) * [TLS 부트스트래핑(bootstrapping)](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet 인증/인가](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + * [Kubelet 인증/인가](/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) ## 선택적 클러스터 서비스 diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 228e0af585..95ea899cbb 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,4 +1,5 @@ --- + title: kubelet 가비지(Garbage) 수집 설정하기 content_type: concept weight: 70 @@ -6,7 +7,7 @@ weight: 70 -가비지 수집은 사용되지 않는 이미지들과 컨테이너들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. +가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. 별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다. @@ -20,7 +21,7 @@ weight: 70 쿠버네티스는 cadvisor와 imageManager를 통하여 모든 이미지들의 라이프사이클을 관리한다. -이미지들에 대한 가비지 수집 정책에는 다음 2가지 요소가 고려된다: +이미지들에 대한 가비지 수집 정책은 다음의 2가지 요소를 고려한다. `HighThresholdPercent` 와 `LowThresholdPercent`. 임계값을 초과하는 디스크 사용량은 가비지 수집을 트리거 한다. 가비지 수집은 낮은 입계값에 도달 할 때까지 최근에 가장 적게 사용한 이미지들을 삭제한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index b897a0e79a..03eb904ee3 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -1,18 +1,19 @@ --- title: 쿠버네티스 컨트롤 플레인에 대한 메트릭 + + + + content_type: concept weight: 60 -aliases: -- controller-metrics.md --- 시스템 컴포넌트 메트릭으로 내부에서 발생하는 상황을 더 잘 파악할 수 있다. 메트릭은 대시보드와 경고를 만드는 데 특히 유용하다. -쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력되며 사람이 읽기 쉽다. - - +쿠버네티스 컨트롤 플레인의 메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)으로 출력된다. +이 형식은 구조화된 평문으로 디자인되어 있으므로 사람과 기계 모두가 쉽게 읽을 수 있다. @@ -49,18 +50,20 @@ rules: ## 메트릭 라이프사이클 -알파 메트릭 → 안정적인 메트릭 → 사용 중단된 메트릭 → 히든(hidden) 메트릭 → 삭제 +알파(Alpha) 메트릭 → 안정적인(Stable) 메트릭 → 사용 중단된(Deprecated) 메트릭 → 히든(Hidden) 메트릭 → 삭제된(Deleted) 메트릭 알파 메트릭은 안정성을 보장하지 않는다. 따라서 언제든지 수정되거나 삭제될 수 있다. -안정적인 메트릭은 변경되지 않는다는 보장을 할 수 있다. 특히 안정성은 다음을 의미한다. +안정적인 메트릭은 변경되지 않는다는 것을 보장한다. 이것은 다음을 의미한다. +* 사용 중단 표기가 없는 안정적인 메트릭은, 이름이 변경되거나 삭제되지 않는다. +* 안정적인 메트릭의 유형(type)은 수정되지 않는다. -* 메트릭 자체는 삭제되거나 이름이 변경되지 않는다 -* 메트릭 유형은 수정되지 않는다 +사용 중단된 메트릭은 해당 메트릭이 결국 삭제된다는 것을 나타내지만, 아직은 사용 가능하다는 뜻이다. +이 메트릭은 어느 버전에서부터 사용 중단된 것인지를 표시하는 어노테이션을 포함한다. -사용 중단된 메트릭은 메트릭이 결국 삭제된다는 것을 나타낸다. 어떤 버전을 찾으려면, 해당 메트릭이 어떤 쿠버네티스 버전에서부터 사용 중단될 것인지를 고려하는 내용을 포함하는 어노테이션을 확인해야 한다. +예를 들면, -사용 중단되기 전에는 아래와 같다. +* 사용 중단 이전에는 다음과 같다. ``` # HELP some_counter this counts things @@ -68,7 +71,7 @@ rules: some_counter 0 ``` -사용 중단된 이후에는 아래와 같다. +* 사용 중단 이후에는 다음과 같다. ``` # HELP some_counter (Deprecated since 1.15.0) this counts things @@ -76,9 +79,9 @@ some_counter 0 some_counter 0 ``` -메트릭이 일단 숨겨지면 기본적으로 메트릭은 수집용으로 게시되지 않는다. 히든 메트릭을 사용하려면, 관련 클러스터 컴포넌트의 구성을 오버라이드(override)해야 한다. +히든 메트릭은 깔끔함(scraping)을 위해 더 이상 게시되지는 않지만, 여전히 사용은 가능하다. 히든 메트릭을 사용하려면, [히든 메트릭 표시](#히든-메트릭-표시) 섹션을 참고한다. -메트릭이 삭제되면, 메트릭이 게시되지 않는다. 오버라이드해서 이를 변경할 수 없다. +삭제된 메트릭은 더 이상 게시되거나 사용할 수 없다. ## 히든 메트릭 표시 @@ -128,6 +131,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ``` + ### kube-scheduler 메트릭 {{< feature-state for_k8s_version="v1.20" state="alpha" >}} diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index fc67ab2f82..73fcf62b98 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -225,7 +225,6 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. 캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. - 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 모든 요청을 리디렉션할 수 있다. 따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 @@ -262,12 +261,10 @@ data: immutable: true ``` -{{< note >}} 컨피그맵을 immutable로 표시하면, 이 변경 사항을 되돌리거나 `data` 또는 `binaryData` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. 기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하므로, 이러한 파드를 다시 작성하는 것을 권장한다. -{{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 557fb50397..f120b0002d 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -349,7 +349,7 @@ data: 부트스트랩 타입 시크릿은 `data` 아래 명시된 다음의 키들을 가진다. -- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. +- `token-id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. - `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. - `description`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 문자열. 선택 사항. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 854147597b..026e0e007c 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -17,8 +17,8 @@ card: 최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 수 있도록 HTTP API를 제공한다. -쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: -파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. +쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다. 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index b67a524a7f..09f70af30c 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -58,14 +58,14 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 동일한 쿠버네티스 클러스터에, +애플리케이션은 동일한 쿠버네티스 클러스터에, 심지어는 동일한 네임스페이스에도 한번 또는 그 이상 설치될 수 있다. 예를 들어, 하나의 쿠버네티스 클러스터에 -워드프레스가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. +WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비스할 수 있다. -애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. -예를 들어 워드프레스는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, -애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 -`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 +애플리케이션의 이름과 애플리케이션 인스턴스 이름은 별도로 기록된다. +예를 들어 WordPress는 애플리케이션 이름으로 `app.kubernetes.io/name` 이라는 레이블에 `wordpress` 라는 값을 가지며, +애플리케이션 인스턴스 이름으로는 `app.kubernetes.io/instance` 라는 레이블에 +`wordpress-abcxzy` 라는 값을 가진다. 이를 통해 애플리케이션과 애플리케이션 인스턴스를 식별할 수 있다. 모든 애플리케이션 인스턴스는 고유한 이름을 가져야 한다. ## 예시 @@ -169,4 +169,3 @@ metadata: ``` MySQL `StatefulSet` 과 `Service` 로 MySQL과 WordPress가 더 큰 범위의 애플리케이션에 포함되어 있는 것을 알게 된다. - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 0ea3f087e3..e3c67a4ff9 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -1,4 +1,7 @@ --- + + + title: 파드 시큐리티 폴리시 content_type: concept weight: 30 @@ -213,12 +216,17 @@ kubectl-user create -f- <}} 워크로드가 단일 컴포넌트이거나 함께 작동하는 여러 컴포넌트이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 -[파드](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. -쿠버네티스에서 파드는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} +[_파드_](/ko/docs/concepts/workloads/pods) 집합 내에서 실행한다. +쿠버네티스에서 `Pod` 는 클러스터에서 실행 중인 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 집합을 나타낸다. -파드에는 정의된 라이프사이클이 있다. 예를 들어, 일단 파드가 클러스터에서 실행되고 -해당 파드가 실행 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에서 -심각한 오류가 발생하게 되면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 -최종적으로 처리한다. 나중에 노드가 복구되더라도 새 파드를 만들어야 한다. +쿠버네티스 파드에는 [정의된 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)이 있다. +예를 들어, 일단 파드가 클러스터에서 실행되고 나서 +해당 파드가 동작 중인 {{< glossary_tooltip text="노드" term_id="node" >}}에 +심각한 오류가 발생하면 해당 노드의 모든 파드가 실패한다. 쿠버네티스는 이 수준의 실패를 +최종(final)으로 취급한다. 사용자는 향후 노드가 복구되는 것과 상관 없이 `Pod` 를 새로 생성해야 한다. -그러나, 작업이 훨씬 쉽도록, 각 파드를 직접 관리할 필요는 없도록 만들었다. +그러나, 작업이 훨씬 쉽도록, 각 `Pod` 를 직접 관리할 필요는 없도록 만들었다. 대신, 사용자를 대신하여 파드 집합을 관리하는 _워크로드 리소스_ 를 사용할 수 있다. 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}를 구성한다. -이러한 워크로드 리소스에는 다음이 포함된다. +쿠버네티스는 다음과 같이 여러 가지 빌트인(built-in) 워크로드 리소스를 제공한다. -* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) 및 [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) - (레거시 리소스 {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체); -* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/); -* 스토리지 드라이버 또는 네트워크 플러그인과 같은 노드-로컬 기능을 제공하는 - 파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) -* 완료될 때까지 실행되는 작업에 대한 - [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및 - [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/) +* [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 및 [`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) + (레거시 리소스 + {{< glossary_tooltip text="레플리케이션컨트롤러(ReplicationController)" term_id="replication-controller" >}}를 대체). + `Deployment` 는 `Deployment` 의 모든 `Pod` 가 필요 시 교체 또는 상호 교체 가능한 경우, + 클러스터의 스테이트리스 애플리케이션 워크로드를 관리하기에 적합하다. +* [`StatefulSet`](/ko/docs/concepts/workloads/controllers/statefulset/)는 + 어떻게든 스테이트(state)를 추적하는 하나 이상의 파드를 동작하게 해준다. 예를 들면, 워크로드가 + 데이터를 지속적으로 기록하는 경우, 사용자는 `Pod` 와 + [`PersistentVolume`](/ko/docs/concepts/storage/persistent-volumes/)을 연계하는 `StatefulSet` 을 실행할 수 있다. + 전체적인 회복력 향상을 위해서, `StatefulSet` 의 `Pods` 에서 동작 중인 코드는 동일한 `StatefulSet` 의 + 다른 `Pods` 로 데이터를 복제할 수 있다. +* [`DaemonSet`](/ko/docs/concepts/workloads/controllers/daemonset/)은 노드-로컬 기능(node-local facilities)을 제공하는 `Pods` 를 정의한다. + 이러한 기능들은 클러스터를 운용하는 데 기본적인 것일 것이다. + 예를 들면, 네트워킹 지원 도구 또는 + {{< glossary_tooltip text="add-on" term_id="addons" >}} 등이 있다. + `DaemonSet` 의 명세에 맞는 노드를 클러스터에 추가할 때마다, + 컨트롤 플레인은 해당 신규 노드에 `DaemonSet` 을 위한 `Pod` 를 스케줄한다. +* [`Job`](/ko/docs/concepts/workloads/controllers/job/) 및 + [`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)은 + 실행 완료 후 중단되는 작업을 정의한다. `CronJobs` 이 스케줄에 따라 반복되는 반면, + 잡은 단 한 번의 작업을 나타낸다. -관련성을 찾을 수 있는 두 가지 지원 개념도 있다. -* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 - 제거된 후 클러스터에서 오브젝트를 정리한다. -* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)가 - 완료된 이후 정의된 시간이 경과되면 잡을 제거한다. +더 넓은 쿠버네티스 에코시스템 내에서는 추가적인 동작을 제공하는 제 3자의 워크로드 +리소스도 찾을 수 있다. +[커스텀 리소스 데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)을 사용하면, +쿠버네티스 코어에서 제공하지 않는 특별한 동작을 원하는 경우 제 3자의 워크로드 리소스를 +추가할 수 있다. 예를 들어, 사용자 애플리케이션을 위한 `Pods` 의 그룹을 실행하되 +_모든_ 파드가 가용한 경우가 아닌 경우 멈추고 싶다면(아마도 높은 처리량의 분산 처리를 하는 상황 같은), +사용자는 해당 기능을 제공하는 확장을 구현하거나 설치할 수 있다. ## {{% heading "whatsnext" %}} 각 리소스에 대해 읽을 수 있을 뿐만 아니라, 리소스와 관련된 특정 작업에 대해서도 알아볼 수 있다. -* [디플로이먼트를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) +* [`Deployment` 를 사용하여 스테이트리스(stateless) 애플리케이션 실행](/docs/tasks/run-application/run-stateless-application-deployment/) * 스테이트풀(stateful) 애플리케이션을 [단일 인스턴스](/ko/docs/tasks/run-application/run-single-instance-stateful-application/) 또는 [복제된 세트](/docs/tasks/run-application/run-replicated-stateful-application/)로 실행 -* [크론잡을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [`CronJob` 을 사용하여 자동화된 작업 실행](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/) + +코드를 구성(configuration)에서 분리하는 쿠버네티스의 메커니즘을 배우기 위해서는, +[구성](/ko/docs/concepts/configuration/)을 참고하길 바란다. + +다음은 쿠버네티스가 애플리케이션의 파드를 어떻게 관리하는지를 알 수 있게 해주는 +두 가지 개념이다. +* [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 + 제거된 후 클러스터에서 오브젝트를 정리한다. +* [_time-to-live after finished_ 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/)는 + 잡이 완료된 이후에 정의된 시간이 경과되면 잡을 제거한다. 일단 애플리케이션이 실행되면, 인터넷에서 [서비스](/ko/docs/concepts/services-networking/service/)로 사용하거나, 웹 애플리케이션의 경우에만 [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress)를 이용하여 사용할 수 있다. - -[구성](/ko/docs/concepts/configuration/) 페이지를 방문하여 구성에서 코드를 분리하는 쿠버네티스의 -메커니즘에 대해 알아볼 수도 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 19995d83ce..ed29659a7e 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -1,4 +1,8 @@ --- + + + + title: 크론잡 content_type: concept weight: 80 @@ -45,6 +49,36 @@ kube-controller-manager 컨테이너에 설정된 시간대는 ([크론잡으로 자동화된 작업 실행하기](/ko/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) +### 크론 스케줄 문법 + +``` +# ┌───────────── 분 (0 - 59) +# │ ┌───────────── 시 (0 - 23) +# │ │ ┌───────────── 일 (1 - 31) +# │ │ │ ┌───────────── 월 (1 - 12) +# │ │ │ │ ┌───────────── 요일 (0 - 6) (일요일부터 토요일까지; +# │ │ │ │ │ 특정 시스템에서는 7도 일요일) +# │ │ │ │ │ +# │ │ │ │ │ +# * * * * * +``` + + +| 항목 | 설명 | 상응 표현 | +| ------------- | ------------- |------------- | +| @yearly (or @annually) | 매년 1월 1일 자정에 실행 | 0 0 1 1 * | +| @monthly | 매월 1일 자정에 실행 | 0 0 1 * * | +| @weekly | 매주 일요일 자정에 실행 | 0 0 * * 0 | +| @daily (or @midnight) | 매일 자정에 실행 | 0 0 * * * | +| @hourly | 매시 0분에 시작 | 0 * * * * | + + +예를 들면, 다음은 해당 작업이 매주 금요일 자정에 시작되어야 하고, 매월 13일 자정에도 시작되어야 한다는 뜻이다. + +`0 0 13 * 5` + +크론잡 스케줄 표현을 생성하기 위해서 [crontab.guru](https://crontab.guru/)와 같은 웹 도구를 사용할 수도 있다. + ## 크론잡의 한계 {#cron-job-limitations} 크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 5c505a3286..0f04051ff1 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -1,4 +1,7 @@ --- + + + title: 잡 content_type: concept feature: @@ -35,6 +38,7 @@ weight: 50 ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` +출력 결과는 다음과 같다. ``` job.batch/pi created ``` @@ -44,6 +48,7 @@ job.batch/pi created ```shell kubectl describe jobs/pi ``` +출력 결과는 다음과 같다. ``` Name: pi Namespace: default @@ -88,6 +93,7 @@ Events: pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` +출력 결과는 다음과 같다. ``` pi-5rwd7 ``` @@ -100,7 +106,7 @@ pi-5rwd7 ```shell kubectl logs $pods ``` -다음과 유사하게 출력된다. +출력 결과는 다음과 같다. ```shell 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` @@ -395,10 +401,11 @@ spec: 잡 `old` 를 삭제하지만, _파드를 실행 상태로 둔다_. 삭제하기 전에 어떤 셀렉터를 사용하는지 기록한다. -``` +```shell kubectl get job old -o yaml ``` -``` +출력 결과는 다음과 같다. +```yaml kind: Job metadata: name: old @@ -417,7 +424,7 @@ spec: 시스템이 일반적으로 자동 생성하는 셀렉터를 사용하지 않도록 하기 위해 새 잡에서 `manualSelector: true` 를 지정해야 한다. -``` +```yaml kind: Job metadata: name: new diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 6dce0bfcee..265f971816 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,6 @@ --- + + title: 파드 content_type: concept weight: 10 @@ -189,6 +191,34 @@ spec: 시스템 시맨틱을 단순화하고, 기존 코드를 변경하지 않고도 클러스터의 동작을 확장할 수 있게 한다. +## 파드 갱신 및 교체 + +이전 섹션에서 언급한 바와 같이, 워크로드 리소스의 파드 +템플릿이 바뀌면, 컨트롤러는 기존의 파드를 갱신하거나 패치하는 대신 +갱신된 템플릿을 기반으로 신규 파드를 생성한다. + +쿠버네티스는 사용자가 파드를 직접 관리하는 것을 막지는 않는다. +동작 중인 파드의 필드를 갱신하는 것도 가능하다. +그러나, +[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core) 및 +[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core)와 같은 +파드 갱신 작업에는 다음과 같은 제약이 있다. + +- 파드에 대한 대부분의 메타데이터는 불변(immutable)이다. 예를 들면, 사용자는 + `namespace`, `name`, `uid`, 또는 `creationTimestamp` 필드를 변경할 수 없다. + 그리고 `generation` 필드는 고유하다. 이 필드는 필드의 현재 값을 증가시키는 + 갱신만 허용한다. +- `metadata.deletionTimestamp` 가 설정된 경우, + `metadata.finalizers` 리스트에 새로운 항목이 추가될 수 없다. +- 파드 갱신은 `spec.containers[*].image`, `spec.initContainers[*].image`, + `spec.activeDeadlineSeconds`, 또는 `spec.tolerations` 이외의 필드는 + 변경하지 않을 것이다. `spec.tolerations` 에 대해서만 새로운 항목을 추가할 수 있다. +- `spec.activeDeadlineSeconds` 필드를 추가할 때는, 다음의 두 가지 형태의 갱신만 + 허용한다. + + 1. 지정되지 않은 필드를 양수로 설정; + 1. 필드의 양수를 음수가 아닌 더 작은 숫자로 갱신. + ## 리소스 공유와 통신 파드는 파드에 속한 컨테이너 간의 데이터 공유와 통신을 diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 3267f5b04d..c1e3943178 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -1,4 +1,6 @@ --- + + title: 초기화 컨테이너 content_type: concept weight: 40 @@ -47,9 +49,9 @@ weight: 40 또한, 초기화 컨테이너는 `lifecycle`, `livenessProbe`, `readinessProbe` 또는 `startupProbe` 를 지원하지 않는다. 왜냐하면 초기화 컨테이너는 파드가 준비 상태가 되기 전에 완료를 목표로 실행되어야 하기 때문이다. -만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, Kubelet은 해당 초기화 컨테이너들을 +만약 다수의 초기화 컨테이너가 파드에 지정되어 있다면, kubelet은 해당 초기화 컨테이너들을 한 번에 하나씩 실행한다. 각 초기화 컨테이너는 다음 컨테이너를 실행하기 전에 꼭 성공해야 한다. -모든 초기화 컨테이너들이 실행 완료되었을 때, Kubelet은 파드의 애플리케이션 컨테이너들을 +모든 초기화 컨테이너들이 실행 완료되었을 때, kubelet은 파드의 애플리케이션 컨테이너들을 초기화하고 평소와 같이 실행한다. ## 초기화 컨테이너 사용하기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 2cd28660d0..b927895575 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -66,7 +66,7 @@ graph TB API 필드 `pod.spec.topologySpreadConstraints` 는 다음과 같이 정의된다. -``` +```yaml apiVersion: v1 kind: Pod metadata: @@ -290,7 +290,7 @@ graph BT - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. - 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. -기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)에서 +기본 제약 조건은 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, @@ -315,7 +315,7 @@ profiles: {{< note >}} 기본 스케줄링 제약 조건에 의해 생성된 점수는 -[`SelectorSpread` 플러그인](/docs/reference/scheduling/config/#scheduling-plugins)에 +[`SelectorSpread` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인)에 의해 생성된 점수와 충돌 할 수 있다. `PodTopologySpread` 에 대한 기본 제약 조건을 사용할 때 스케줄링 프로파일에서 이 플러그인을 비활성화 하는 것을 권장한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 8f2f5c48a6..14fee6ee9c 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -1,5 +1,7 @@ --- title: 레퍼런스 + + linkTitle: "레퍼런스" main_menu: true weight: 70 @@ -16,7 +18,7 @@ content_type: concept ## API 레퍼런스 -* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 레퍼런스 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 ## API 클라이언트 라이브러리 @@ -33,7 +35,7 @@ content_type: concept ## CLI 레퍼런스 * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. + * [JSONPath](/ko/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. * [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 78d54badce..ad9c9a45de 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -419,10 +419,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 자세한 내용은 [원시 블록 볼륨 지원](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 참고한다. - `BoundServiceAccountTokenVolume`: ServiceAccountTokenVolumeProjection으로 구성된 프로젝션 볼륨을 사용하도록 서비스어카운트 볼륨을 - 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 - 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 + 마이그레이션한다. 클러스터 관리자는 `serviceaccount_stale_tokens_total` 메트릭을 사용하여 + 확장 토큰에 의존하는 워크로드를 모니터링 할 수 있다. 이러한 워크로드가 없는 경우 `--service-account-extend-token-expiration=false` 플래그로 `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. - 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 + 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. - `ConfigurableFSGroupPolicy`: 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드에 대한 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 참고한다. -`CronJobControllerV2` : {{< glossary_tooltip text="크론잡" term_id="cronjob" >}} 컨트롤러의 대체 구현을 사용한다. 그렇지 않으면 동일한 컨트롤러의 버전 1이 선택된다. 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다. @@ -508,7 +508,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 등에서 제공할 수 있음). [임시 볼륨](/docs/concepts/storage/ephemeral-volumes/)을 참고한다. --`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown)을 참조한다. +-`GracefulNodeShutdown` : kubelet에서 정상 종료를 지원한다. 시스템 종료 중에 kubelet은 종료 이벤트를 감지하고 노드에서 실행중인 파드를 정상적으로 종료하려고 시도한다. 자세한 내용은 [Graceful Node Shutdown](/ko/docs/concepts/architecture/nodes/#그레이스풀-graceful-노드-셧다운)을 참조한다. - `HugePages`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 할당 및 사용을 활성화한다. - `HugePageStorageMediumSize`: 사전 할당된 [huge page](/ko/docs/tasks/manage-hugepages/scheduling-hugepages/)의 여러 크기를 지원한다. - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. @@ -582,7 +582,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. - `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. -- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. +- `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 매개 변수를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. - `TaintBasedEvictions`: 노드의 테인트(taint) 및 파드의 톨러레이션(toleration)을 기반으로 노드에서 파드를 축출할 수 있다. diff --git a/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100644 index 0000000000..ad5f3f2691 --- /dev/null +++ b/content/ko/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,19 @@ +--- +title: 동적 볼륨 프로비저닝(Dynamic Volume Provisioning) +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /ko/docs/concepts/storage/dynamic-provisioning +short_description: > + 사용자가 스토리지 볼륨의 자동 생성을 요청할 수 있게 해준다. + +aka: +tags: +- core-object +- storage +--- + 사용자가 스토리지 {{< glossary_tooltip text="볼륨" term_id="volume" >}}의 자동 생성을 요청할 수 있게 해준다. + + + +동적 프로비저닝은 클러스터 관리자가 스토리지를 사전 프로비저닝할 필요가 없다. 대신 사용자 요청에 따라 자동으로 스토리지를 프로비저닝한다. 동적 볼륨 프로비저닝은 API 오브젝트인 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 기반으로 한다. 이 스토리지클래스는 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 및 {{< glossary_tooltip text="볼륨 플러그인" term_id="volume-plugin" >}}에 전달할 파라미터 세트를 프로비저닝하는 볼륨 플러그인을 참조한다. + diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 7281e6f4c5..c82ef7d968 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -18,10 +18,10 @@ tags: -[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/)는 +[kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)는 노드의 네트워크 규칙을 유지 관리한다. 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 해준다. -kube-proxy는 운영 체제에 가용한 패킷 +kube-proxy는 운영 체제에 가용한 패킷 필터링 계층이 있는 경우, 이를 사용한다. 그렇지 않으면, kube-proxy는 트래픽 자체를 포워드(forward)한다. diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 1613791ddf..7db5ce3bdb 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -356,8 +356,8 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 `-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력 `-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력 `-o=json` | JSON 형식의 API 오브젝트 출력 -`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 -`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath=<템플릿>` | [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/ko/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 `-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음 `-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 `-o=yaml` | YAML 형식의 API 오브젝트 출력 @@ -395,10 +395,10 @@ Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 ## {{% heading "whatsnext" %}} -* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/docs/reference/kubectl/jsonpath)에 대해 배워보자. +* [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 읽고 [JsonPath](/ko/docs/reference/kubectl/jsonpath)에 대해 배워보자. -* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. +* [kubectl](/ko/docs/reference/kubectl/kubectl/) 옵션을 참고한다. -* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. +* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/ko/docs/reference/kubectl/conventions/)을 참고한다. * 더 많은 커뮤니티 [kubectl 치트시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4)를 확인한다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index e86a5579b7..7ddfe5b095 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -119,7 +119,7 @@ kubectl [command] [TYPE] [NAME] [flags] `version` | `kubectl version [--client] [flags]` | 클라이언트와 서버에서 실행 중인 쿠버네티스 버전을 표시한다. `wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 실험(experimental) 기능: 하나 이상의 리소스에서 특정 조건을 기다린다. -명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +명령 동작에 대한 자세한 내용을 배우려면 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ## 리소스 타입 @@ -188,7 +188,7 @@ kubectl [command] [TYPE] [NAME] [flags] ## 출력 옵션 -특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. +특정 명령의 출력을 서식화하거나 정렬하는 방법에 대한 정보는 다음 섹션을 참고한다. 다양한 출력 옵션을 지원하는 명령에 대한 자세한 내용은 [kubectl](/ko/docs/reference/kubectl/kubectl/) 참조 문서를 참고한다. ### 출력 서식화 @@ -207,8 +207,8 @@ kubectl [command] [TYPE] [NAME] -o `-o custom-columns=` | 쉼표로 구분된 [사용자 정의 열](#custom-columns) 목록을 사용하여 테이블을 출력한다. `-o custom-columns-file=` | `` 파일에서 [사용자 정의 열](#custom-columns) 템플릿을 사용하여 테이블을 출력한다. `-o json` | JSON 형식의 API 오브젝트를 출력한다. -`-o jsonpath=