From f9a9884c0cba16b99f7a09701341976f044ff753 Mon Sep 17 00:00:00 2001 From: June Yi Date: Fri, 28 Feb 2020 11:56:38 +0900 Subject: [PATCH] Fifth Korean l10n work for release 1.17 (#19335) * Update to Outdated files in dev-1.17-ko.5 branch. (#19145) * Translate apiserver-aggregation into Korean (#19168) * Translate storage/volumes.md in Korean. (#18594) * Reflect new docs reference links since dev-1.17-ko.1 (#19159) Co-authored-by: Yuk, Yongsu Co-authored-by: Yoon Co-authored-by: June Yi Co-authored-by: Claudia J.Kang Co-authored-by: Seokho Son Co-authored-by: Yuk, Yongsu Co-authored-by: Yoon Co-authored-by: Claudia J.Kang Co-authored-by: Seokho Son --- content/ko/_index.html | 4 +- content/ko/docs/concepts/_index.md | 4 +- .../docs/concepts/architecture/controller.md | 2 +- .../ko/docs/concepts/architecture/nodes.md | 8 +- .../controller-metrics.md | 48 - .../cluster-administration/proxies.md | 2 +- .../docs/concepts/configuration/overview.md | 10 +- .../docs/concepts/containers/runtime-class.md | 4 +- .../docs/concepts/extend-kubernetes/_index.md | 4 + .../extend-kubernetes/api-extension/_index.md | 4 + .../api-extension/apiserver-aggregation.md | 38 + .../kubernetes-objects.md | 19 +- .../overview/working-with-objects/labels.md | 6 +- .../connect-applications-service.md | 2 +- .../services-networking/dns-pod-service.md | 28 +- .../services-networking/dual-stack.md | 5 +- .../concepts/services-networking/ingress.md | 34 +- .../services-networking/network-policies.md | 97 +- .../services-networking/service-topology.md | 109 +- .../concepts/services-networking/service.md | 4 +- content/ko/docs/concepts/storage/_index.md | 5 + content/ko/docs/concepts/storage/volumes.md | 1444 +++++++++++++++++ .../workloads/controllers/daemonset.md | 10 +- .../workloads/controllers/replicaset.md | 4 +- .../workloads/controllers/statefulset.md | 6 +- .../workloads/controllers/ttlafterfinished.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 8 - content/ko/docs/contribute/_index.md | 82 +- content/ko/docs/contribute/participating.md | 152 +- content/ko/docs/reference/_index.md | 24 +- .../docs/reference/glossary/device-plugin.md | 18 +- .../ko/docs/reference/kubectl/cheatsheet.md | 7 +- .../reference/using-api/client-libraries.md | 1 + content/ko/docs/setup/_index.md | 2 +- .../setup/learning-environment/minikube.md | 6 +- .../container-runtimes.md | 7 +- .../access-cluster.md | 2 +- .../web-ui-dashboard.md | 2 +- .../resource-usage-monitoring.md | 2 +- .../declarative-config.md | 9 +- .../horizontal-pod-autoscale-walkthrough.md | 11 +- .../horizontal-pod-autoscale.md | 170 +- .../ko/docs/tasks/tools/install-minikube.md | 14 +- .../ko/docs/tutorials/clusters/apparmor.md | 4 +- content/ko/docs/tutorials/hello-minikube.md | 16 +- .../ko/docs/tutorials/services/source-ip.md | 12 +- .../basic-stateful-set.md | 4 +- .../stateful-application/cassandra.md | 6 +- .../mysql-wordpress-persistent-volume.md | 2 +- .../stateful-application/zookeeper.md | 14 +- .../expose-external-ip-address.md | 13 +- .../stateless-application/guestbook.md | 4 +- .../ko/examples/application/php-apache.yaml | 39 + .../network-policy-allow-all-egress.yaml | 11 + .../network-policy-allow-all-ingress.yaml | 11 + .../network-policy-default-deny-all.yaml | 10 + .../network-policy-default-deny-egress.yaml | 9 + .../network-policy-default-deny-ingress.yaml | 9 + 58 files changed, 2014 insertions(+), 570 deletions(-) delete mode 100644 content/ko/docs/concepts/cluster-administration/controller-metrics.md create mode 100644 content/ko/docs/concepts/extend-kubernetes/_index.md create mode 100644 content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md create mode 100644 content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md create mode 100644 content/ko/docs/concepts/storage/_index.md create mode 100644 content/ko/docs/concepts/storage/volumes.md create mode 100644 content/ko/examples/application/php-apache.yaml create mode 100644 content/ko/examples/service/networking/network-policy-allow-all-egress.yaml create mode 100644 content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml create mode 100644 content/ko/examples/service/networking/network-policy-default-deny-all.yaml create mode 100644 content/ko/examples/service/networking/network-policy-default-deny-egress.yaml create mode 100644 content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml diff --git a/content/ko/_index.html b/content/ko/_index.html index 59188feb67..b93ac38e8f 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -45,12 +45,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준


- Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020 + Attend KubeCon in Amsterdam on Mar. 30-Apr. 2, 2020



- Attend KubeCon in Shanghai on July 28-30, 2020 + Attend KubeCon in Shanghai on July 28-30, 2020
diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index fb28711866..6d4e30b4ca 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -26,12 +26,12 @@ weight: 40 ## 쿠버네티스 오브젝트 -쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 문서를 참조한다. +쿠버네티스는 시스템의 상태를 나타내는 추상 개념을 다수 포함하고 있다. 컨테이너화되어 배포된 애플리케이션과 워크로드, 이에 연관된 네트워크와 디스크 자원, 그 밖에 클러스터가 무엇을 하고 있는지에 대한 정보가 이에 해당한다. 이런 추상 개념은 쿠버네티스 API 내 오브젝트로 표현된다. 보다 자세한 내용은 [쿠버네티스 오브젝트 이해하기](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 문서를 참조한다. 기초적인 쿠버네티스 오브젝트에는 다음과 같은 것들이 있다. * [파드](/ko/docs/concepts/workloads/pods/pod-overview/) -* [서비스](/docs/concepts/services-networking/service/) +* [서비스](/ko/docs/concepts/services-networking/service/) * [볼륨](/docs/concepts/storage/volumes/) * [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 7af5863f92..e2feb1b4cf 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -26,7 +26,7 @@ weight: 30 ## 컨트롤러 패턴 컨트롤러는 적어도 하나 이상의 쿠버네티스 리소스 유형을 추적한다. -이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) +이 [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) 는 의도한 상태를 표현하는 사양 필드를 가지고 있다. 해당 리소스의 컨트롤러(들)은 현재 상태를 의도한 상태에 가깝게 만드는 역할을 한다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index dffd6bd2db..f9c28cee9c 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -103,7 +103,7 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll ## 관리 -[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/docs/concepts/services-networking/service/)와 달리, +[파드](/ko/docs/concepts/workloads/pods/pod/)와 [서비스](/ko/docs/concepts/services-networking/service/)와 달리, 노드는 본래 쿠버네티스에 의해 생성되지 않는다. 구글 컴퓨트 엔진과 같은 클라우드 제공사업자에 의해 외부로부터 생성 되거나, 물리적 또는 가상 머신의 풀 내에서 존재한다. 그래서 쿠버네티스가 노드를 생성할 때, @@ -272,6 +272,12 @@ DaemonSet 컨트롤러에 의해 생성된 파드는 쿠버네티스 스케줄 애플리케이션을 유출시키는 중이라 할지라도 머신 상에 속한 데몬으로 여긴다. {{< /note >}} +{{< caution >}} +`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 +서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 +사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다. +{{< /caution >}} + ### 노드 용량 노드의 용량 (cpu 수와 메모리 양) 은 노드 오브젝트의 한 부분이다. diff --git a/content/ko/docs/concepts/cluster-administration/controller-metrics.md b/content/ko/docs/concepts/cluster-administration/controller-metrics.md deleted file mode 100644 index 8a7951eb04..0000000000 --- a/content/ko/docs/concepts/cluster-administration/controller-metrics.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 컨트롤러 관리자 메트릭 -content_template: templates/concept -weight: 100 ---- - -{{% capture overview %}} -컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 -중요한 통찰을 제공한다. - -{{% /capture %}} - -{{% capture body %}} -## 컨트롤러 관리자 메트릭은 무엇인가 - -컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다. -메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과 -etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를 -측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다. - -쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다. -이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다. - -예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다: - -``` -cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} -cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} -cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} -cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} -``` - - - -## 구성 - - -클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서 -이용 가능하다. - -메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다. - -운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해, -프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다. - -{{% /capture %}} diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index fedef39322..66e29d2e40 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -33,7 +33,7 @@ weight: 90 - 노드, 파드, 서비스에 도달하는데 사용할 수 있다. - 서비스에 도달할 때에는 로드 밸런싱을 수행한다. -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드에서 실행한다. - UDP, TCP, SCTP를 이용하여 프락시 한다. diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md index 4dd1ffea54..794f46d079 100644 --- a/content/ko/docs/concepts/configuration/overview.md +++ b/content/ko/docs/concepts/configuration/overview.md @@ -37,7 +37,7 @@ weight: 10 ## 서비스 -- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. +- 서비스에 대응하는 백엔드 워크로드(디플로이먼트 또는 레플리카 셋) 또는 서비스 접근이 필요한 어떠한 워크로드를 생성하기 전에 [서비스](/ko/docs/concepts/services-networking/service/)를 미리 생성한다. 쿠버네티스가 컨테이너를 시작할 때, 쿠버네티스는 컨테이너 시작 당시에 생성되어 있는 모든 서비스를 가리키는 환경 변수를 컨테이너에 제공한다. 예를 들어, `foo` 라는 이름의 서비스가 존재한다면, 모든 컨테이너들은 초기 환경에서 다음의 변수들을 얻을 것이다. ```shell FOO_SERVICE_HOST=<서비스가 동작 중인 호스트> @@ -51,14 +51,14 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며 - 반드시 필요한 것이 아니라면 파드에 `hostPort` 를 명시하지 않는다. <`hostIP`, `hostPort`, `protocol`> 조합은 유일해야 하기 때문에, `hostPort`로 바인드하는 것은 파드가 스케줄링될 수 있는 위치의 개수를 제한한다. 만약 `hostIP`와 `protocol`을 뚜렷히 명시하지 않으면, 쿠버네티스는 `hostIP`의 기본 값으로 `0.0.0.0`를, `protocol`의 기본 값으로 `TCP`를 사용한다. - 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. + 만약 오직 디버깅의 목적으로 포트에 접근해야 한다면, [apiserver proxy](/ko/docs/tasks/access-application-cluster/access-cluster/#수작업으로-apiserver-proxy-url을-구축) 또는 [`kubectl port-forward`](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 사용할 수 있다. - 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. + 만약 파드의 포트를 노드에서 명시적으로 노출해야 한다면, `hostPort`에 의존하기 전에 [NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 서비스를 사용하는 것을 고려할 수 있다. - `hostPort`와 같은 이유로, `hostNetwork`를 사용하는 것을 피한다. -- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless- -services)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. +- `kube-proxy` 로드 밸런싱이 필요하지 않을 때, 쉬운 서비스 발견을 위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless- +서비스)(`ClusterIP`의 값을 `None`으로 가지는)를 사용한다. ## 레이블 사용하기 diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 663b5bcd33..2ec1499dc6 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -56,7 +56,7 @@ RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. {{< note >}} 런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. -이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄링](#scheduling)을 참고한다. +이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다. {{< /note >}} 해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. @@ -163,7 +163,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md 노드의 합집합을 취한다. 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 -[노드에 파드 할당](/docs/concepts/configuration/assign-pod-node/)을 참고한다. +[노드에 파드 할당](/ko/docs/concepts/configuration/assign-pod-node/)을 참고한다. [어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/ diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000..ff8525f171 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,4 @@ +--- +title: 쿠버네티스 확장하기 +weight: 110 +--- diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md new file mode 100644 index 0000000000..5701f2d0c5 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/_index.md @@ -0,0 +1,4 @@ +--- +title: 쿠버네티스 API 확장하기 +weight: 20 +--- diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md new file mode 100644 index 0000000000..c7a2054d42 --- /dev/null +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -0,0 +1,38 @@ +--- +title: 애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장하기 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +애그리게이션 레이어는 코어 쿠버네티스 API가 제공하는 기능 이외에 더 많은 기능을 제공할 수 있도록 추가 API를 더해 쿠버네티스를 확장할 수 있게 해준다. + +{{% /capture %}} + +{{% capture body %}} + +## 개요 + +애그리게이션 레이어는 부가적인 쿠버네티스-스타일 API를 클러스터에 설치할 수 있게 해준다. 이는 [서비스-카탈로그](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)와 같이 사전에 구축되어 있는 서드 파티 솔루션일 수 있고, [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)로 시작해볼 수 있는 것과 같은 사용자 정의 API일 수도 있다. + +애그리게이션 레이어는 kube-apiserver 프로세스 안에서 구동된다. 확장 리소스가 등록되기 전까지, 애그리게이션 레이어는 아무 일도 하지 않는다. API를 등록하기 위해서, 사용자는 쿠버네티스 API 내에서 URL 경로를 "요구하는(claim)" APIService 오브젝트를 추가해야 한다. 이때, 애그리게이션 레이어는 해당 API 경로(예: /apis/myextensions.mycompany.io/v1/...)로 전송되는 모든 것을 등록된 APIService로 프록시하게 된다. + +대개, APIService는 클러스터 내에서 구동 중인 파드(pod) 내 *extension-apiserver* 로 구현된다. 이 extension-apiserver는 일반적으로 추가된 리소스에 대한 적극적인 관리가 필요한 경우 하나 이상의 컨트롤러와 짝지어진다. 결과적으로, apiserver-builder는 실제로 그 둘 모두에 대한 스켈레톤을 제공한다. 또 다른 예로, 서비스-카탈로그가 설치된 경우에는, 제공하는 서비스에 대한 extension-apiserver와 컨트롤러를 모두 제공한다. + +Extension-apiserver는 kube-apiserver로 오가는 연결의 레이턴시가 낮아야 한다. +특히, kube-apiserver로 부터의 디스커버리 요청은 왕복 레이턴시가 5초 이내여야 한다. +사용자의 환경에서 달성할 수 없는 경우에는, 이를 어떻게 바꿀 수 있을지 고려해야 한다. 지금은, +`EnableAggregatedDiscoveryTimeout=false` 기능 게이트를 설정해서 타임아웃 제한을 +비활성화 할 수 있다. 이 기능은 미래의 릴리스에서는 삭제될 예정이다. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). +* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. +* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. + +{{% /capture %}} + diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 30b75b82a4..a3f2a02e87 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -12,7 +12,7 @@ card: {{% /capture %}} {{% capture body %}} -## 쿠버네티스 오브젝트 이해하기 +## 쿠버네티스 오브젝트 이해하기 {#kubernetes-objects} *쿠버네티스 오브젝트* 는 쿠버네티스 시스템에서 영속성을 가지는 개체이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 개체를 이용한다. 구체적으로 말하자면, 다음을 기술할 수 있다. @@ -41,8 +41,9 @@ card: {{< codenew file="application/deployment.yaml" >}} -위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다. - +위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 +`kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 커맨드를 이용하는 것이다. 다음 예시와 같다. ```shell kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record @@ -50,8 +51,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record 그 출력 내용은 다음과 유사하다. - -```shell +``` deployment.apps/nginx-deployment created ``` @@ -65,14 +65,15 @@ deployment.apps/nginx-deployment created * `spec` - 오브젝트에 대해 어떤 상태를 의도하는지 오브젝트 `spec`에 대한 정확한 포맷은 모든 쿠버네티스 오브젝트마다 다르고, 그 오브젝트 특유의 중첩된 필드를 포함한다. [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) 는 쿠버네티스를 이용하여 생성할 수 있는 오브젝트에 대한 모든 spec 포맷을 살펴볼 수 있도록 해준다. -예를 들어, `파드`에 대한 `spec` 포맷은 -[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) -에서 확인할 수 있고, `디플로이먼트`에 대한 `spec` 포맷은 -[여기](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. +예를 들어, 파드에 대한 `spec` 포맷은 +[PodSpec v1 Core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +에서 확인할 수 있고, 디플로이먼트에 대한 `spec` 포맷은 +[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)에서 확인할 수 있다. {{% /capture %}} {{% capture whatsnext %}} +* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. * [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index f0f56e600c..ff9a93d5d7 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -70,7 +70,7 @@ spec: image: nginx:1.7.9 ports: - containerPort: 80 - + ``` ## 레이블 셀렉터 @@ -209,7 +209,7 @@ selector: #### 세트-기반 요건을 지원하는 리소스 -[`잡`](/docs/concepts/jobs/run-to-completion-finite-workloads/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카 셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬 셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. +[`잡`](/docs/concepts/workloads/controllers/jobs-run-to-completion/), [`디플로이먼트`](/ko/docs/concepts/workloads/controllers/deployment/), [`레플리카셋`](/ko/docs/concepts/workloads/controllers/replicaset/) 그리고 [`데몬셋`](/ko/docs/concepts/workloads/controllers/daemonset/) 같은 새로운 리소스들은 집합성 기준의 요건도 지원한다. ```yaml selector: @@ -225,6 +225,6 @@ selector: #### 노드 셋 선택 레이블을 통해 선택하는 사용 사례 중 하나는 파드를 스케줄 할 수 있는 노드 셋을 제한하는 것이다. -자세한 내용은 [노드 선택](/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다. +자세한 내용은 [노드 선택](/ko/docs/concepts/configuration/assign-pod-node/) 문서를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 361660a119..2b79d11e88 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -123,7 +123,7 @@ my-nginx 10.244.2.5:80,10.244.3.4:80 1m 이제 클러스터의 모든 노드에서 `:` 로 nginx 서비스를 curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외부에서는 절대로 연결되지 않음에 참고한다. 만약 이것이 어떻게 작동하는지 궁금하다면 -[서비스 프록시](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)에 대해 더 읽어본다. +[서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)에 대해 더 읽어본다. ## 서비스에 접근하기 diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 10da72fb2d..91fbc782d7 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -38,22 +38,24 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ## 서비스 -### A 레코드 +### A/AAAA 레코드 -"노멀"(헤드리스가 아닌) 서비스는 +"노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 `my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 +IP로 해석된다. -"헤드리스"(클러스터 IP가 없는) 서비스 또한 +"헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 `my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 레코드가 할당된다. +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. -클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. +클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 +통해 선택할 수 있다. ### SRV 레코드 SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)에 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. 정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. @@ -128,22 +130,22 @@ spec: ``` 파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, -클러스터의 KubeDNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 레코드를 반환한다. +클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. 예를 들어 호스트네임이 "`busybox-1`"이고, 서브도메인이 "`default-subdomain`"이고, 같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, 파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 레코드를 제공한다. -"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 레코드를 가지고 있다. +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. +"`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. 엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} -A 레코드는 파드의 이름으로 생성되지 않기 때문에 -파드의 A 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. `hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 레코드만 생성할 수 있다. +A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) 또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. 그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 2cdfb31028..9d58bccbd6 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -27,7 +27,6 @@ weight: 70 * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당) * IPv4와 IPv6 지원 서비스(각 서비스는 단일 주소 패밀리이어야 한다.) - * Kubenet 다중 주소 패밀리 지원(IPv4와 IPv6) * IPv4와 IPv6 인터페이스를 통한 파드 오프(off) 클러스터 이그레스 라우팅(예: 인터넷) ## 필수 구성 요소 @@ -36,7 +35,7 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 * 쿠버네티스 1.16 또는 이후 버전 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) - * Kubenet 네트워크 플러그인 + * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 * IPVS 모드에서 구동 중인 Kube-Proxy ## IPv4/IPv6 이중 스택 활성화 @@ -52,7 +51,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--proxy-mode=ipvs` - * `--cluster-cidrs=,` + * `--cluster-cidrs=,` * `--feature-gates="IPv6DualStack=true"` {{< caution >}} diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 2a04159efd..793a1520e3 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -15,24 +15,15 @@ weight: 40 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. -노드(Node) -: 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. - -클러스터(Cluster) -: 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. - -에지 라우터(Edge router) -: 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. - -클러스터 네트워크(Cluster network) -: 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. - -서비스(Service) -: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. +클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. +에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? -인그레스는 클러스터 외부에서 클러스터 내부 +[인그레스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)는 클러스터 외부에서 클러스터 내부 {{< link text="서비스" url="/docs/concepts/services-networking/service/" >}}로 HTTP와 HTTPS 경로를 노출한다. 트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다. @@ -47,8 +38,8 @@ weight: 40 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름 기반의 가상 호스팅을 제공하도록 구성할 수 있다. [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers)는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다. 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다. HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 -[Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 또는 -[Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. +[Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 또는 +[Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 유형의 서비스를 사용한다. ## 전제 조건들 @@ -107,7 +98,7 @@ spec: * 경로 목록 (예, `/testpath`)에는 각각 `serviceName` 과 `servicePort` 가 정의되어있는 관련 백엔드를 가지고 있다. 로드 밸런서가 트래픽을 참조된 서비스로 보내기 전에 호스트와 경로가 모두 수신 요청의 내용과 일치해야 한다. -* 백엔드는 [서비스 문서](/docs/concepts/services-networking/service/)에 설명된 바와 같이 +* 백엔드는 [서비스 문서](/ko/docs/concepts/services-networking/service/)에 설명된 바와 같이 서비스와 포트 이름의 조합이다. 호스트와 규칙 경로가 일치하는 인그레스에 대한 HTTP(와 HTTPS) 요청은 백엔드 목록으로 전송된다. @@ -220,7 +211,7 @@ Events: {{< note >}} 사용중인 [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers) 에 따라 default-http-backend -[서비스](/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. +[서비스](/ko/docs/concepts/services-networking/service/)를 만들어야 할 수도 있다. {{< /note >}} ### 이름 기반의 가상 호스팅 @@ -466,12 +457,13 @@ Events: 사용자는 인그레스 리소스를 직접적으로 포함하지 않는 여러가지 방법으로 서비스를 노출할 수 있다. -* [Service.Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer) 사용. -* [Service.Type=NodePort](/docs/concepts/services-networking/service/#nodeport) 사용. +* [Service.Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer) 사용. +* [Service.Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport) 사용. {{% /capture %}} {{% capture whatsnext %}} +* [인그레스] API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)에 대해 배우기 * [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/)에 대해 배우기 * [NGINX 컨트롤러로 Minikube에서 인그레스 구성하기](/docs/tasks/access-application-cluster/ingress-minikube) {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 2001f96bd5..c3f4ee193b 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -7,16 +7,16 @@ weight: 50 {{< toc >}} {{% capture overview %}} -네트워크 정책은 파드 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. +네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`NetworkPolicy` 리소스는 레이블을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. {{% /capture %}} {{% capture body %}} ## 전제 조건 -네트워크 정책은 네트워크 플러그인으로 구현되므로 `NetworkPolicy` 를 지원하는 네트워킹 솔루션을 사용해야 한다. - 컨트롤러가 없이 단순하게 리소스를 생성하게 되면 아무런 효과가 없기 때문이다. +네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. ## 격리 및 격리되지 않은 파드 @@ -26,11 +26,11 @@ weight: 50 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다. -## `NetworkPolicy` 리소스 +## NetworkPolicy 리소스 {#networkpolicy-resource} -리소스에 대한 전체 정의는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. +리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. -`NetworkPolicy` 의 예시는 다음과 같다. +NetworkPolicy 의 예시는 다음과 같다. ```yaml apiVersion: networking.k8s.io/v1 @@ -69,23 +69,25 @@ spec: port: 5978 ``` -*선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 API 서버에 이를 POST 하더라도 효과가 없다.* +{{< note >}} +선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. +{{< /note >}} -__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 `NetworkPolicy` 에는 +__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일 작업에 대한 일반적인 정보는 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다. -__spec__: `NetworkPolicy` [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. +__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. -__podSelector__: 각 `NetworkPolicy` 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. -__policyTypes__: 각 `NetworkPolicy` 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. +__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 `NetworkPolicy` 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. -__egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. +__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. 따라서 예시의 NetworkPolicy는 다음과 같이 동작한다. @@ -103,7 +105,7 @@ __egress__: 각 `NetworkPolicy` 에는 화이트리스트 `egress` 규칙이 포 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다. -__podSelector__: `NetworkPolicy` 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. +__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다. @@ -164,16 +166,7 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C 모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. @@ -181,33 +174,13 @@ spec: 만약 네임스페이스의 모든 파드에 대한 모든 트래픽을 허용하려는 경우(일부 파드가 "격리 된" 것으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스의 모든 트래픽을 명시적으로 허용하는 정책을 만들 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - ingress: - - {} - policyTypes: - - Ingress -``` +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} ### 기본적으로 모든 이그레스 트래픽 거부 모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 기본 인그레스 격리 정책을 변경하지 않는다. @@ -216,34 +189,13 @@ spec: 만약 네임스페이스의 모든 파드의 모든 트래픽을 허용하려면 (일부 파드가 "격리 된"으로 처리되는 정책이 추가 된 경우에도) 해당 네임스페이스에서 모든 이그레스 트래픽을 명시적으로 허용하는 정책을 생성할 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: allow-all -spec: - podSelector: {} - egress: - - {} - policyTypes: - - Egress -``` +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부 해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. -```yaml -apiVersion: networking.k8s.io/v1 -kind: NetworkPolicy -metadata: - name: default-deny -spec: - podSelector: {} - policyTypes: - - Ingress - - Egress -``` +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} 이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. @@ -251,9 +203,12 @@ spec: {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -쿠버네티스는 `NetworkPolicy` 정의에서 `protocol` 값으로 SCTP를 알파 기능으로 지원한다. 이 기능을 활성화하려면 클러스터 관리자가 apiserver 에서 `SCTPSupport` 기능 게이트를 활성화 할 필요가 있다. 예를 들면, `“--feature-gates=SCTPSupport=true,...”` . 기능 게이트가 활성화 되면 `NetworkPolicy` 의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. +기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. -CNI 플러그인은 SCTP를 `NetworkPolicy` 에서 `protocol` 값으로 지원해야 한다. +{{< note >}} +SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. +{{< /note >}} {{% /capture %}} diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 7e71eee719..16f140e583 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -43,23 +43,6 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수 트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을 유지하는 것이 있다. -## 전제 조건 - -서비스 라우팅을 인식하는 토폴로지를 활성화 하려면 다음과 같은 전제 조건이 -필요하다. - - * 쿠버네티스 1.17 또는 이후 버전 - * Kube-proxy 가 iptables 모드 또는 IPVS 모드에서 실행 중 - * [엔드포인트 슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)의 활성화 - -## 서비스 토폴로지 활성화하기 - -서비스 토폴로지를 활성화하려면 kube-apiserver 와 kube-proxy의 -기능 게이트에서 `ServiceTopology` 를 활성화 한다. - -``` ---feature-gates="ServiceTopology=true" -``` ## 서비스 토폴로지 사용하기 @@ -114,6 +97,98 @@ _서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수 한다. +## 예시들 + +다음은 서비스 토폴로지 기능을 사용하는 일반적인 예시이다. + +### 노드 로컬 엔드포인트만 + +노드 로컬 엔드포인트로만 라우팅하는 서비스이다. 만약 노드에 엔드포인트가 없으면 트레픽이 드롭된다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" +``` + +### 노드 로컬 엔드포인트 선호 + +노드 로컬 엔드포인트를 선호하지만, 노드 로컬 엔드포인트가 없는 경우 클러스터 전체 엔드포인트로 폴백 하는 서비스이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "*" +``` + + +### 영역 또는 지리적 엔드포인트만 + +영역보다는 지리적 엔드포인트를 선호하는 서비스이다. 만약 엔드포인트가 없다면, 트래픽은 드롭된다. + + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" +``` + +### 노드 로컬, 영역 및 지역 엔드포인트 선호 + +노드 로컬, 영역 및 지역 엔드포인트를 선호하지만, 클러스터 전체 엔드포인트로 폴백하는 서비스이다. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: my-app + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + topologyKeys: + - "kubernetes.io/hostname" + - "topology.kubernetes.io/zone" + - "topology.kubernetes.io/region" + - "*" +``` + + {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index b6a8448f06..1c33fb3008 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -850,7 +850,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스 헬스 체크에 실패하고 트래픽을 수신하지 못하게 된다. 트래픽을 균일하게 하려면, DaemonSet을 사용하거나, -[파드 안티어피니티(pod anti-affinity)](/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) +[파드 안티어피니티(pod anti-affinity)](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 를 지정하여 동일한 노드에 위치하지 않도록 한다. [내부 로드 밸런서](/ko/docs/concepts/services-networking/service/#internal-load-balancer) 어노테이션과 함께 NLB 서비스를 @@ -939,7 +939,7 @@ spec: {{< note >}} ExternalName은 IPv4 주소 문자열을 허용하지만, IP 주소가 아닌 숫자로 구성된 DNS 이름을 허용한다. IPv4 주소와 유사한 ExternalName은 CoreDNS 또는 ingress-nginx에 의해 확인되지 않는데, ExternalName은 정식(canonical) DNS 이름을 지정하기 때문이다. IP 주소를 하드 코딩하려면, -[헤드리스(headless) 서비스](#headless-services) 사용을 고려한다. +[헤드리스(headless) 서비스](#헤드리스-headless-서비스) 사용을 고려한다. {{< /note >}} `my-service.prod.svc.cluster.local` 호스트를 검색하면, 클러스터 DNS 서비스는 diff --git a/content/ko/docs/concepts/storage/_index.md b/content/ko/docs/concepts/storage/_index.md new file mode 100644 index 0000000000..1e0fb99a5d --- /dev/null +++ b/content/ko/docs/concepts/storage/_index.md @@ -0,0 +1,5 @@ +--- +title: "스토리지" +weight: 70 +--- + diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..fa84c193c9 --- /dev/null +++ b/content/ko/docs/concepts/storage/volumes.md @@ -0,0 +1,1444 @@ +--- +title: 볼륨 +content_template: templates/concept +weight: 10 +--- + +{{% capture overview %}} + +컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 +애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, +kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 +시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 +컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 +`볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. + +[파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. + +{{% /capture %}} + + +{{% capture body %}} + +## 배경 + +도커는 다소 느슨하고, 덜 관리되지만 +[볼륨](https://docs.docker.com/engine/admin/volumes/)이라는 +개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 +다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 +로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 +제공하지만, 현재 기능은 매우 제한되어 있다(예: 도커 1.7부터 +컨테이너 당 하나의 볼륨 드라이버만 허용되고 매개 변수를 볼륨에 +전달할 방법이 없다). + +반면에, 쿠버네티스 볼륨은 그것을 둘러싼 파드와 +동일한 명시적인 수명을 가진다. 그 결과로, 볼륨은 파드 내에서 실행되는 모든 컨테이너보다 +수명이 길고, 컨테이너를 다시 시작해도 데이터가 보존된다. 물론 파드가 +존재하지 않으면, 볼륨도 존재하지 않는다. 이보다 더 중요한 것은 +쿠버네티스가 많은 유형의 볼륨을 지원하고, 파드는 +여러 볼륨을 동시에 사용할 수 있다. + +기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 +내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 +매체와 내용은 사용된 특정 볼륨의 유형에 따라 +결정된다. + +볼륨을 사용하기 위해 파드는 파드에 제공할 볼륨( +`.spec.volumes` +필드)과 컨테이너에 마운트 할 위치( +`.spec.containers[*].volumeMounts` +필드)를 지정한다. + +컨테이너 내 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 뷰를 +본다. [도커 +이미지](https://docs.docker.com/userguide/dockerimages/)는 파일 +시스템 계층의 루트에 있으며 모든 볼륨은 이미지 내에 지정된 경로에 +마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 +가질 수 없다. 파드 내 각각의 컨테이너는 각각의 볼륨을 마운트 할 위치를 독립적으로 +지정해야 한다. + +## 볼륨 유형들 + +쿠버네티스는 여러 유형의 볼륨을 지원한다. + + * [awsElasticBlockStore](#awselasticblockstore) + * [azureDisk](#azuredisk) + * [azureFile](#azurefile) + * [cephfs](#cephfs) + * [cinder](#cinder) + * [configMap](#configmap) + * [csi](#csi) + * [downwardAPI](#downwardapi) + * [emptyDir](#emptydir) + * [fc (파이버 채널))](#fc) + * [flexVolume](#flexVolume) + * [flocker](#flocker) + * [gcePersistentDisk](#gcepersistentdisk) + * [gitRepo (사용중단(deprecated))](#gitrepo) + * [glusterfs](#glusterfs) + * [hostPath](#hostpath) + * [iscsi](#iscsi) + * [local](#local) + * [nfs](#nfs) + * [persistentVolumeClaim](#persistentvolumeclaim) + * [projected](#projected) + * [portworxVolume](#portworxvolume) + * [quobyte](#quobyte) + * [rbd](#rbd) + * [scaleIO](#scaleio) + * [secret](#secret) + * [storageos](#storageos) + * [vsphereVolume](#vspherevolume) + +우리는 추가 기여를 환영한다. + +### awsElasticBlockStore {#awselasticblockstore} + +`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) [EBS +볼륨](http://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 +데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" +할 수 있다. + +{{< caution >}} +이를 사용하려면 먼저 `aws ec2 create-volume` 또는 AWS API를 사용해서 EBS 볼륨을 생성해야 한다. +{{< /caution >}} + +`awsElasticBlockStore` 볼륨을 사용할 때 몇 가지 제한이 있다. + +* 파드가 실행 중인 노드는 AWS EC2 인스턴스여야 함 +* 이러한 인스턴스는 EBS 볼륨과 동일한 지역과 가용성 영역에 있어야 함 +* EBS는 볼륨을 마운트하는 단일 EC2 인스턴스만 지원함 + +#### EBS 볼륨 생성하기 + +파드와 함께 EBS 볼륨을 사용하려면, 먼저 EBS 볼륨을 생성해야 한다. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. (그리고 크기와 EBS 볼륨 유형이 +사용에 적합한지 확인한다!) + +#### AWS EBS 구성 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # 이 AWS EBS 볼륨은 이미 존재해야 한다. + awsElasticBlockStore: + volumeID: + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +awsElasticBlockStore 의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI +드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAWS` +베타 기능을 활성화 해야 한다. + +#### CSI 마이그레이션 완료 +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +컨트롤러 매니저와 kubelet에 의해 로드되지 않도록 awsElasticBlockStore 스토리지 플러그인을 끄려면, 이 기능의 플래그를 true로 설정해야 한다. 이는 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. + +### azureDisk {#azuredisk} + +`azureDisk` 는 Microsoft Azure [데이터 디스크](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)를 파드에 마운트하는 데 사용한다. + +더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)에서 확인할 수 있다. + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI +드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAzureDisk` +알파 기능을 활성화 해야 한다. + +### azureFile {#azurefile} + +`azureFile` 은 Microsoft Azure 파일 볼륨 (SMB 2.1과 3.0)을 파드에 마운트하는데 +사용한다. + +더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)에서 확인할 수 있다. + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.15" state="alpha" >}} + +azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI +드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` +알파 기능을 활성화 해야 한다. + +### cephfs {#cephfs} + +`cephfs` 볼륨은 기존 CephFS 볼륨을 +파드에 마운트 할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` +와는 다르게 cephfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, +파드 간에 데이터를 "전달(handed off)" 할 수 있다. CephFS는 여러 작성자가 +동시에 마운트할 수 있다. + +{{< caution >}} +CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다. +{{< /caution >}} + +더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다. + +### cinder {#cinder} + +{{< note >}} +전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. 클라우드 공급자 +구성에 대해서는 [오픈스택 클라우드 공급자](/docs/concepts/cluster-administration/cloud-providers/#openstack)를 참조한다. +{{< /note >}} + +`cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. + +#### Cinder 볼륨 예시 구성 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # 이 오픈스택 볼륨은 이미 존재해야 한다. + cinder: + volumeID: + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +Cinder의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI +드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/using-cinder-csi-plugin.md) +를 설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` +알파 기능을 활성화해야 한다. + +### configMap {#configmap} + +[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 리소스는 +구성 데이터를 파드에 주입하는 방법을 제공한다. +`ConfigMap` 오브젝트에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 +그런 다음에 파드에서 실행되는 컨테이너화된 애플리케이션이 소비한다. + +`configMap` 오브젝트를 참조할 때, 간단하게 참조하기 위한 볼륨의 이름을 +제공할 수 있다. ConfigMap의 특정 항목에 사용할 경로를 +사용자 정의할 수 있다. +예를 들어, `log-config` ConfigMap을 `configmap-pod` 라 부르는 파드에 마운트하려면 +아래 YAML을 사용할 수 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +`log-config` ConfigMap은 볼륨으로 마운트되며, `log_level` 항목에 +저장된 모든 컨텐츠는 파드의 "`/etc/config/log_level`" 경로에 마운트 된다. +이 경로는 볼륨의 `mountPath` 와 `log_level` 로 키가 지정된 +`path` 에서 파생된다. + +{{< caution >}} +ConfigMap 볼륨을 사용하려면 먼저 [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 생성해야 한다. +{{< /caution >}} + +{{< note >}} +ConfigMap을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 ConfigMap +업데이트를 수신하지 않는다. +{{< /note >}} + +### downwardAPI {#downwardapi} + +`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 하는데 사용된다. +이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다. + +{{< note >}} +Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 Downward API +업데이트를 수신하지 않는다. +{{< /note >}} + +더 자세한 내용은 [`downwardAPI` 볼륨 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참조한다. + +### emptyDir {#emptydir} + +`emptyDir` 볼륨은 파드가 노드에 할당 될 때 처음 생성되며, +해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 +`emptyDir` 볼륨은 처음에는 비어있다. 파드내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 +파일을 읽고 쓸수 있지만, 볼륨은 각각의 컨테이너에서 동일하거나 +다른 경로에 마운트 될 수 있다. 어떤 이유로든 노드에서 파드를 제거하면 +`emptyDir` 의 데이터가 영구적으로 삭제된다. + +{{< note >}} +컨테이너의 충돌은 노드에서 파드를 제거하지 *않기* 때문에, `emptyDir` 볼륨의 데이터는 컨테이너 충돌에서 안전하다. +{{< /note >}} + +`emptyDir` 의 일부 용도는 다음과 같다. + +* 디스크 기반의 병합 종류와 같은 스크레치 공간 +* 충돌로부터 복구하기위해 긴 계산을 검사점으로 지정 +* 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 + 컨테이너가 가져오는 파일을 보관 + +기본적으로, `emptyDir` 볼륨은 노드를 지원하는 모든 매체에 +저장된다(환경에 따라 디스크, SSD 또는 네트워크 스토리지일 +수 있다). 그러나 `emptyDir.medium` 필드를 `"Memory"` 로 설정해서 +쿠버네티스에 tmpfs(RAM 기반 파일 시스템)를 마운트하도록 할 수 있다. +tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, +작성하는 모든 파일이 컨테이너 메모리 +제한에 포함된다. + +#### 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (파이버 채널) {#fc} + +`fc` 볼륨은 기존 파이버 채널 볼륨을 파드에 마운트할 수 있게 한다. +볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 단일 또는 +다중 대상 월드 와이드 이름을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, +targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다. + +{{< caution >}} +이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. +{{< /caution >}} + +더 자세한 내용은 [FC 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) 를 참조한다. + +### flocker {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스 클러스터 컨테이너 데이터 볼륨 매니저이다. 다양한 +스토리지 백엔드가 지원하는 데이터 볼륨 관리와 오케스트레이션을 제공한다. + +`flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약 +Flocker내에 데이터셋이 없는 경우, 먼저 Flocker +CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면 +Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에 +따라 파드 간에 데이터를 "전달(handed off)" 할 수 있다는 의미이다. + +{{< caution >}} +`flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. +{{< /caution >}} + +더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다. + +### gcePersistentDisk {#gcepersistentdisk} + +`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) [퍼시스턴트 +디스크](http://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고, +볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 +미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다. + +{{< caution >}} +`gcePersistentDisk` 를 사용하려면 먼저 PD를 `gcloud`, GCE API 또는 UI를 사용해서 생성해야 한다. +{{< /caution >}} + +`gcePersistentDisk` 를 사용할 때 몇가지 제한이 있다. + +* 파드가 실행중인 노드는 GCE VM이어야 함 +* 이러한 VM은 PD와 동일한 GCE 프로젝트와 영역에 있어야 함 + +PD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 PD를 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +PD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +ReplicationController가 제어하는 파드에서 PD를 사용하는 것은 +PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 실패할 것이다. + +#### PD 생성하기 + +GCE PD를 파드와 함께 사용하려면 디스크를 먼저 생성해야 한다. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### 예시 파드 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # 이 GCE PD는 이미 존재해야 한다. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### 지역(Regional) 퍼시스턴트 디스크 +{{< feature-state for_k8s_version="v1.10" state="beta" >}} + +[지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. + +#### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 +[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다. +PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. +```shell +gcloud beta compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` +PersistentVolume 사양 예시 + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume + labels: + failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### CSI 마이그레이션 + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내 플러그인에서 +`pd.csi.storage.gke.io` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI +드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) +를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` +베타 기능을 활성화 해야 한다. + +### gitRepo (사용 중단(deprecated)) {#gitrepo} + +{{< warning >}} +gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. +{{< /warning >}} + +`gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 +디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 +복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 +이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. + +여기 gitRepo 볼륨의 예시가 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs {#glusterfs} + +`glusterfs` 볼륨을 사용하면 [Glusterfs](http://www.gluster.org) (오픈 +소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를 +제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` +볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 +glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 +"전달(handed off)" 할 수 있다. GlusterFS는 여러 작성자가 동시에 +마운트할 수 있다. + +{{< caution >}} +사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. +{{< /caution >}} + +더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다. + +### hostPath {#hostpath} + +`hostPath` 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를 +파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부 +애플리케이션에 강력한 탈출구를 제공한다. + +예를 들어, `hostPath` 의 일부 용도는 다음과 같다. + +* 도커 내부에 접근할 필요가 있는 실행중인 컨테이너. `/var/lib/docker` 를 + `hostPath` 로 이용함 +* 컨테이너에서 cAdvisor의 실행. `/sys` 를 `hostPath` 로 이용함 +* 파드는 주어진 `hostPath` 를 파드가 실행되기 이전에 있어야 하거나, + 생성해야 하는지 그리고 존재해야 하는 대상을 지정할 수 있도록 허용함 + +필요한 `path` 속성 외에도, `hostPath` 볼륨에 대한 `type` 을 마음대로 지정할 수 있다. + +필드가 `type` 에 지원되는 값은 다음과 같다. + + +| 값 | 행동 | +|:------|:---------| +| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPash 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | +| `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | +| `Directory` | 주어진 경로에 디렉터리가 있어야 함 | +| `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | +| `File` | 주어진 경로에 파일이 있어야 함 | +| `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | +| `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 | +| `BlockDevice` | 주어진 경로에 블록 디바이스가 있어야 함 | + +다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. + +* 동일한 구성(파드템플릿으로 생성한 것과 같은)을 + 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음 +* 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 + 사용되는 리소스를 설명할 수 없음 +* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 + [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나 + `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함 + +#### 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # 호스트의 디렉터리 위치 + path: /data + # 이 필드는 선택 사항이다 + type: Directory +``` + +### iscsi {#iscsi} + +`iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +다르게 `iscsi` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 iscsi 볼륨에 데이터를 미리 채울 수 있으며, +파드간에 데이터를 "전달(handed off)" 할 수 있다는 것이다. + +{{< caution >}} +사용하려면 먼저 iSCSI 서버를 실행하고 볼륨을 생성해야 한다. +{{< /caution >}} + +iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음, +필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도, +iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다. + +### local {#local} + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +`local` 볼륨은 디스크, 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지 +장치를 나타낸다. + +로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨(PersistentVolume)으로만 사용할 수 있다. 동적으로 +프로비저닝된 것은 아직 지원되지 않는다. + +`hostPath` 볼륨에 비해 로컬 볼륨은 퍼시스턴트볼륨의 노드 어피니티를 살펴봄으로써 +볼륨의 노드 제약 조건을 인식하기 때문에 수동으로 파드를 노드에 예약하지 않고도 +내구성과 휴대성을 갖춘 방식으로 사용할 수 있다. + +그러나 로컬 볼륨은 여전히 기본 노드의 가용성을 따르며 +모든 애플리케이션에 적합하지는 않는다. 만약 노드가 비정상 상태가 +되면 로컬 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 +없게 된다. 로컬 볼륨을 사용하는 애플리케이션은 기본 디스크의 +내구 특성에 따라 이러한 감소되는 가용성과 데이터 +손실 가능성도 허용할 수 있어야 한다. + +다음은 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨 +사양 예시이다. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +로컬 볼륨을 사용할 때는 퍼시스턴트볼륨의 `nodeAffinity` 가 필요하다. 이를 통해 +쿠버네티스 스케줄러는 올바른 노드의 로컬 볼륨을 파드가 사용할 수 있도록 올바르게 +스케줄할 수 있다. + +퍼시스턴트볼륨의 `volumeMode` 을 "Block" (기본값인 "Filesystem"을 +대신해서)으로 설정하면 로컬 볼륨을 원시 블록 장치로 노출할 수 있다. + +로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 +스토리지클래스(StorageClass)를 생성하는 것을 권장한다. +[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 +퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, +파드 어피니티 그리고 파드 안티 어피니티와 +같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. + +로컬 볼륨 라이프사이클의 향상된 관리를 위해 외부 정적 +프로비저너를 별도로 실행할 수 있다. 이 프로비저너는 아직 동적 +프로비저닝을 지원하지 않는 것을 참고한다. 외부 로컬 프로비저너를 실행하는 방법에 대한 +예시는 [로컬 볼륨 프로비저너 사용자 +가이드](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner)를 본다. + +{{< note >}} +로컬 정적 프로비저너를 사용해서 볼륨 라이프사이클을 관리하지 않는 +경우 로컬 퍼시스턴트볼륨을 수동으로 정리하고 삭제하는 것이 +필요하다. +{{< /note >}} + +### nfs {#nfs} + +`nfs` 볼륨을 사용하면 기존 NFS (네트워크 파일 시스템) 볼륨을 파드에 마운트 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +다르게 `nfs` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 +해제만 된다. 이 의미는 NFS 볼륨에 데이터를 미리 채울 수 있으며, +파드간에 데이터를 "전달(handed off)" 할 수 있다는 뜻이다. NFS는 여러 작성자가 +동시에 마운트할 수 있다. + +{{< caution >}} +사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. +{{< /caution >}} + +더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다. + +### persistentVolumeClaim {#persistentvolumeclaim} + +`persistentVolumeClaim` 볼륨은 +[퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)을 파드에 마운트하는데 사용한다. 퍼시스턴트볼륨은 +사용자가 특정 클라우드 환경의 세부 내용을 몰라도 내구성이있는 스토리지 (GCE 퍼시스턴트디스크 또는 +iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. + +더 자세한 내용은 [퍼시스턴트볼륨 예시](/docs/concepts/storage/persistent-volumes/)를 +본다. + +### projected {#projected} + +`Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. + +현재, 다음 유형의 볼륨 소스를 프로젝티드한다. + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + +모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은 +[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다. + +서비스 어카운트 토큰의 프로젝션은 쿠버네티스 1.11에 기능이 +도입되었고 1.12에서 베타로 승격되었다. +1.11에서 이 기능을 활성화 하려면 `TokenRequestProjection` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +True로 명시적인 설정이 필요하다. + +#### 시크릿, downward API 그리고 configmap이 있는 파드 예시. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + +#### 기본값이 아닌 모드 설정과 여러 시크릿을 가진 파드 예시 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + +각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. +파라미터는 두 가지 예외를 제외하고 거의 동일하다. + +* 시크릿의 경우 `secretName` 필드는 ConfigMap 이름과 일치하도록 + `name` 으로 변경되었다. +* `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 + 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` + 를 명시적으로 설정할 수 있다. + +`TokenRequestProjection` 기능이 활성화 되면, 현재 +[서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 +대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 아래는 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + +예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 +있다. 예를 들어 이 토큰은 파드 컨테이너에서 쿠버네티스 API 서버에 접근하는데 +사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 +포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, +그렇지 않으면 토큰을 거부해야 한다. 이 필드는 +선택 사항이며 기본값은 API 서버의 식별자이다. + +`expirationSeconds` 는 서비스 어카운트 토큰의 예상 유효 +기간이다. 기본값은 1시간이며 최소 10분(600초)이어야 한다. 관리자는 +API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정해서 +최대 값을 제한할 수도 있다. `path` 필드는 projected 볼륨의 마운트 위치에 대한 +상대 경로를 지정한다. + +{{< note >}} +projected 볼륨 소스를 [subPath](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. +{{< /note >}} + +### portworxVolume {#portworxvolume} + +`portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 +계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버에 스토리지 지문을 남기고, 역량에 기반하여 계층화 하고, +그리고 여러 서버에 걸쳐 용량을 집계한다. Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다. + +`portworxVolume` 은 쿠버네티스를 통해 동적으로 생성되거나 +사전 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다. +여기에 사전에 프로비전 된 PortworxVolume을 참조하는 파드의 예시가 있다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # 이 Portworx 볼륨은 이미 존재해야 한다. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< caution >}} +파드에서 사용하기 이전에 먼저 이름이 `pxvol` 인 PortworxVolume +이 있는지 확인한다. +{{< /caution >}} + +더 자세한 내용과 예시는 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md)에서 찾을 수 있다. + +### quobyte {#quobyte} + +`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을 +파드에 마운트할 수 있다. + +{{< caution >}} +사용하기 위해선 먼저 Quobyte를 설정하고 생성한 볼륨과 +함께 실행해야 한다. +{{< /caution >}} + +Quobyte는 {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}를 지원한다. +CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의 +깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 [사용 설명서](https://github.com/quobyte/quobyte-csi#quobyte-csi)가 있다. + +### rbd {#rbd} + +`rbd` 볼륨을 사용하면 [Rados Block +Device](http://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 +있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 +의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를 +"전달(handed off)" 할 수 있다는 것이다. + +{{< caution >}} +RBD를 사용하기 위해선 먼저 Ceph를 설치하고 실행해야 한다. +{{< /caution >}} + +RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 +있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +동시 쓰기는 허용되지 않는다. + +더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 본다. + +### scaleIO {#scaleio} + +ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 +생성할 수 있는 소프트웨어 기반 스포티리 플랫폼이다. `scaleIO` 볼륨 +플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 +있다(또는 퍼시스턴트 볼륨 클래임을 위한 새 볼륨을 동적 프로비전할 수 있음, +[ScaleIO 퍼시스턴트 볼륨](/docs/concepts/storage/persistent-volumes/#scaleio)을 본다). + +{{< caution >}} +사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 +생성한 볼륨과 함께 실행해야 한다. +{{< /caution >}} + +다음은 파드 구성을 ScaleIO와 함께 하는 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + +자세한 내용은 [ScaleIO 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)를 본다. + +### secret {#secret} + +`secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 +사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 +파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 +tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토리지에 절대 +기록되지 않는다. + +{{< caution >}} +사용하기 위해선 먼저 쿠버네티스 API에서 시크릿을 생성해야 한다. +{{< /caution >}} + +{{< note >}} +시크릿을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 +업데이트를 수신하지 못한다. +{{< /note >}} + +시크릿에 대해서 [여기](/docs/user-guide/secrets)에 더 자세한 설명이 있다. + +### storageOS {#storageos} + +`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com) +볼륨을 파드에 마운트할 수 있다. + +StorageOS 는 쿠버네티스 환경에서 컨테이너로 실행되므로 +쿠버네티스 클러스터의 모든 노드의 로컬 또는 연결된 스토리지에 접근할 수 있다. +노드 장애로부터 보호하기 위해 데이터를 복제할 수 있다. 씬(Thin) 프로비저닝과 +압축은 활용률을 높이고 비용을 절감할 수 있게 한다. + +StorageOS의 핵심은 컨테이너에 파일시스템을 통해 접근할 수 있는 블록 스토리지를 제공하는 것이다. + +StorageOS 컨테이너는 64 비트 리눅스가 필요하고 추가적인 종속성이 없다. +무료 개발자 라이선스를 사용할 수 있다. + +{{< caution >}} +StorageOS 볼륨에 접근하거나 스토리지 용량을 +풀에 제공할 StorageOS 컨테이너를 실행해야 한다. +설치 설명서는 +[StorageOS 문서](https://docs.storageos.com)를 찾아본다. +{{< /caution >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # `redis-vol01` 볼륨은 StorageOS에 `default` 네임스페이스로 있어야 한다. + volumeName: redis-vol01 + fsType: ext4 +``` + +동적 프로비저닝과 퍼시스턴트 볼륨 클래임을 포함한 더 많은 정보는 +[StorageOS 예시](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 본다. + +### vsphereVolume {#vspherevolume} + +{{< note >}} +전제조건: 쿠버네티스와 함께 vSphere Cloud Provider가 구성됨. 클라우드공급자 +구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다. +{{< /note >}} + +`vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을 +마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다. + +{{< caution >}} +파드와 함께 사용하기 위해선 먼저 다음 방법중 하나를 사용해서 VMDK를 생성해야 한다. +{{< /caution >}} + +#### VMDK 볼륨 생성하기 + +다음 중 하나를 선택해서 VMDK를 생성한다. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="vmkfstools를 사용해서 생성" %}} +먼저 ESX에 ssh로 들어간 다음, 다음 명령을 사용해서 VMDK를 생성한다. + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` +{{% /tab %}} +{{% tab name="vmware-vdiskmanager를 사용해서 생성" %}} +다음 명령을 사용해서 VMDK를 생성한다. + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` +{{% /tab %}} + +{{< /tabs >}} + + +#### vSphere VMDK 예시 구성 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # 이 VMDK 볼륨은 이미 있어야 한다. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다. + + +## subPath 사용하기 + +때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. `volumeMounts.subPath` +속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 지정할 수 있다. + +여기에 단일 공유 볼륨을 사용하는 LAMP 스택(리눅스 아파치 Mysql PHP)이 포함된 파드의 예시가 있다. +HTML 내용은 `html` 폴더에 매핑되고 데이터베이스는 `mysql` 폴더에 저장된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### subPath를 확장된 환경 변수와 함께 사용하기 + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + + +`subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. +이 기능을 사용하려면 `VolumeSubpathEnvExpansion` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. 쿠버네티스 1.15에서는 시작 시 기본적으로 활성화되어 있다. +`subPath` 와 `subPathExpr` 속성은 상호 배타적이다. + +이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## 리소스 + +`emptyDir` 볼륨의 스토리지 매체(디스크, SSD, 등)는 kubelet root +디렉터리(보통 `/var/lib/kubelet`)를 보유한 파일시스템의 +매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 +사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간 +격리는 없다. + +앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/docs/user-guide/compute-resources) +사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이 +있는 클러스터에 사용할 매체 유형을 선택할 수 +있을 것으로 기대한다. + +## 아웃 오브 트리 볼륨 플러그인 +아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고 +FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에 +추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. + +CSI 와 FlexVolume을 도입하기 전에는 모든 볼륨 플러그인(위 +목록의 볼륨 유형과 같은)은 "인 트리(in-tree)" 로 쿠버네티스 핵심 +바이너리와 함께 빌드, 링크, 컴파일 그리고 전달되었고 쿠버네티스 +핵심 API를 확장했다. 이는 새로운 스토리지 시스템을 쿠버네티스( +볼륨 플러그인)에 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. + +CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는 +독립적으로 볼륨 플러그인을 개발하고, 쿠버네티스 클러스터의 확장으로 배포(설치) +할 수 있다. + +아웃 오브 트리(out-of-tree) 볼륨 플러그인을 생성하려는 스토리지 벤더는 +[이 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. + +### CSI + +[컨테이너 스토리지 인터페이스](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) +는 컨테이너 오케스트레이션 시스템(쿠버네티스와 같은)을 위한 표준 인터페이스를 +정의하여 임의의 스토리지 시스템을 컨테이너 워크로드에 노출시킨다. + +더 자세한 정보는 [CSI 디자인 제안](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)을 읽어본다. + +CSI 지원은 쿠버네티스 v1.9에서 알파로 도입이 되었고, 쿠버네티스 v1.10에서 +베타로 이동되고 쿠버네티스 v1.13에서 정식(GA)이 되었다. + +{{< note >}} +CSI 규격 버전 0.2와 0.3에 대한 지원은 쿠버네티스 v1.13에서 사용중단(deprecated) +되었고, 향후 릴리스에서 제거될 예정이다. +{{< /note >}} + +{{< note >}} +CSI 드라이버는 일부 쿠버네티스 릴리스에서 호환되지 않을 수 있다. +각각의 쿠버네티스 릴리스와 호환성 매트릭스에 대해 지원되는 +배포 단계는 특정 CSI 드라이버 문서를 참조한다. +{{< /note >}} + +CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 +`csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트, +등을 할 수 있다. + +`csi` 볼륨 유형은 파드에서의 직접 참조를 지원하지 않으며 +`PersistentVolumeClaim` 오브젝트를 통해 파드에서 참조할 수 있다. + +스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 +구성할 수 있다. + +- `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. + 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)에 + 정의된 CSI 드라이버가 `GetPluginInfoResponse` 에 반환하는 값과 일치해야 한다. + 쿠버네티스에서 호출할 CSI 드라이버를 식별하고, CSI 드라이버 컴포넌트에서 + CSI 드라이버에 속하는 PV 오브젝트를 식별하는데 사용한다. +- `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. + 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 + 정의된 CSI 드라이버가 `CreateVolumeResponse` 의 `volume.id` 필드에 반환하는 값과 일치해야 한다. + 이 값은 볼륨을 참조할 때 CSI 볼륨 드라이버에 대한 모든 호출에 + `volume_id` 값을 전달한다. +- `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 + 여부를 나타내는 선택적인 불리언(boolean) 값. 기본적으로 false 이다. 이 값은 + `ControllerPublishVolumeRequest` 의 `readonly` 필드를 + 통해 CSI 드라이버로 전달된다. +- `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 + 볼륨을 마운트하는 데 사용해야 하는 파일시스템을 지정하는 데 사용될 수 있다. 만약 + 볼륨이 포맷되지 않았고 포맷이 지원되는 경우, 이 값은 + 볼륨을 포맷하는데 사용된다. + 이 값은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest` + 그리고 `NodePublishVolumeRequest` 의 `VolumeCapability` + 필드를 통해 CSI 드라이버로 전달된다. +- `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 + 매핑한다. 이 매핑은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 + 정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes` + 필드에서 반환되는 매핑과 일치해야 한다. + 이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, + 그리고 `NodePublishVolumeRequest` 의 `volume_attributes` 필드를 + 통해 CSI 드라이버로 전달된다. +- `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` + 그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는 + 민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는 + 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 + 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. +- `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 + CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 + 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 + 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 모든 시크릿이 전달된다. +- `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 + CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 + 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 + 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 모든 시크릿이 전달된다. + +#### CSI 원시(raw) 블록 볼륨 지원 + +{{< feature-state for_k8s_version="v1.14" state="beta" >}} + +1.11 버전부터 CSI는 이전 버전의 쿠버네티스에서 도입된 원시 +블록 볼륨 기능에 의존하는 원시 블록 볼륨에 대한 지원을 +도입했다. 이 기능을 사용하면 외부 CSI 드라이버가 있는 벤더들이 쿠버네티스 +워크로드에서 원시 블록 볼륨 지원을 구현할 수 있다. + +CSI 블록 볼륨은 기능 게이트로 지원하지만, 기본적으로 활성화되어있다. 이 +기능을 위해 활성화 되어야하는 두개의 기능 게이트는 `BlockVolume` 과 +`CSIBlockVolume` 이다. + +[원시 블록 볼륨 지원으로 PV/PVC 설정](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) +방법을 알아본다. + +#### CSI 임시(ephemeral) 볼륨 + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +이 기능을 사용하면 CSI 볼륨을 퍼시스턴트볼륨 대신에 파드 사양에 직접적으로 포함할 수 있다. +이러한 방식으로 지정된 볼륨은 임시적이고 파드 재시작시에는 유지되지 않는다. + +예시 + +```yaml +kind: Pod +apiVersion: v1 +metadata: + name: my-csi-app +spec: + containers: + - name: my-frontend + image: busybox + volumeMounts: + - mountPath: "/data" + name: my-csi-inline-vol + command: [ "sleep", "1000000" ] + volumes: + - name: my-csi-inline-vol + csi: + driver: inline.storage.kubernetes.io + volumeAttributes: + foo: bar +``` + +이 기능을 사용하려면 CSIInlineVolume 기능 게이트를 활성화 해야 한다. +쿠버네티스 1.16 시작시 기본적으로 활성화 되어있다. + +CSI 임시 볼륨은 CSI 드라이버의 하위집합에서만 지원된다. CSI 드라이버의 목록은 [여기](https://kubernetes-csi.github.io/docs/drivers.html)를 본다. + +# 개발자 리소스 +CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi +문서](https://kubernetes-csi.github.io/docs/)를 참조한다. + +#### 인 트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 + +{{< feature-state for_k8s_version="v1.14" state="alpha" >}} + +TCSI 마이그레이션 기능이 활성화 되면 기존의 인 트리 플러그인에 +대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다. +이 기능은 필요한 변환 논리와 심(shims)을 구현하여 작업을 완전한 +방식으로 재 라우팅 한다. 결과적으로 운영자는 인 트리 플러그인을 대체하는 +CSI 드라이버로 전환할 때 기존 스토리지 클래스, PV 또는 PVC(인 트리 +플러그인 참조)에 대한 구성을 변경할 필요가 없다. + +알파 상태에서 지원되는 작업과 기능에는 프로비저닝/삭제, +연결/분리, 마운트/마운트 해제 그리고 볼륨 크기 재조정이 포함된다. + +CSI 마이그레이션을 지원하고 해당 CSI 드라이버가 구현된 인 트리 플러그인은 +위의 "볼륨 유형" 섹션에 나열되어 있다. + +### FlexVolume {#flexVolume} + +FlexVolume은 버전 1.2 (CSI 이전) 이후 쿠버네티스에 존재하는 +아웃 오브 트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 +접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드(그리고 일부 경우에 마스터)에 +미리 정의된 볼륨 플러그인 경로에 설치해야 한다. + +파드는 `flexvolume` 인 트리 플러그인을 통해 FlexVolume 드라이버와 상호 작용 한다. +더 자세한 내용은 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)에서 찾아볼 수 있다. + +## 마운트 전파(propagation) + +마운트 전파를 통해 컨테이너가 마운트한 볼륨을 동일한 파드의 +다른 컨테이너 또는 동일한 노드의 다른 파드로 공유할 수 있다. + +볼륨 마운트 전파는 Container.volumeMounts의 `mountPropagation` 필드에 의해 제어된다. +그 값은 다음과 같다. + + * `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 + 마운트된 것을 마운트 이후에 수신하지 않는다. + 비슷한 방식으로, 컨테이너가 생성 한 마운트는 호스트에서 볼 수 없다. + 이것이 기본 모드이다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + + * `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 + 서브디렉터리를 마운트한 정보를 수신한다. + + 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 + 하더라도 컨테이너가 마운트 된 것을 볼 수 있다. + + 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 + 파드에 `HostToContainer` 마운트 전파가 있는 + 컨테이너가 이를 볼 수 있다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + + * `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. + 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 + 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. + + 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 + `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. + + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. + +{{< caution >}} +`Bidirectional` 마운트 전파는 위험할 수 있다. 이것은 +호스트 운영체제를 손상시킬수 있기에 권한이 있는 컨테이너에서만 +허용된다. 리눅스 커널 동작을 숙지하는 것을 권장한다. +또한 파드내 컨테이너에 의해 생성된 볼륨 마운트는 종료시 +컨테이너에의해 파괴(마운트 해제)되어야 한다. +{{< /caution >}} + +### 구성 +일부 배포판(CoreOS, RedHat/Centos, Ubuntu)에서 마운트 전파가 +제대로 작동하려면 아래와 같이 도커에서의 마운트 공유를 +올바르게 구성해야 한다. + +도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. +```shell +MountFlags=shared +``` +또는 `MountFlags=slave` 가 있으면 제거한다. 이후 도커 데몬을 재시작 한다. +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + + + +{{% capture whatsnext %}} +* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index dccde89562..9309a7520f 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -13,8 +13,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 데몬셋의 일부 대표적인 용도는 다음과 같다. - 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. -- 모든 노드에서 `fluentd` 또는 `logstash` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행. +- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행. 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. 더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, @@ -88,9 +88,9 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 오직 일부 노드에서만 파드 실행 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 -[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/#nodeselector)와 +[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/#노드-셀렉터-nodeselector)와 일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 -데몬셋 컨트롤러는 [노트 어피니티](/docs/concepts/configuration/assign-pod-node/#node-affinity)와 일치하는 노드에 파드를 생성한다. +데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/configuration/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 @@ -161,7 +161,7 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. -- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 만들고, +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index aedb0d03ef..f5d199c746 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -22,7 +22,7 @@ weight: 10 레플리카셋이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을 사용한다. -레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +레플리카셋과 파드와의 링크는 파드의 [metadata.ownerReferences](/ko/docs/concepts/workloads/controllers/garbage-collection/#소유자-owner-와-종속-dependent) 필드를 통해서 제공되며, 이는 현재 오브젝트가 소유한 리소스를 명시한다. 레플리카셋이 가지고 있는 모든 파드의 ownerReferences 필드는 해당 파드를 소유한 레플리카셋을 식별하기 위한 소유자 정보를 가진다. 이 링크를 통해 레플리카셋은 자신이 유지하는 파드의 상태를 확인하고 이에 따라 관리 한다. @@ -250,7 +250,7 @@ matchLabels: ### 레플리카셋과 해당 파드 삭제 -레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. +레플리카셋 및 모든 파드를 삭제하려면 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)를 사용한다. [가비지 수집기](/ko/docs/concepts/workloads/controllers/garbage-collection/)는 기본적으로 종속되어있는 모든 파드를 자동으로 삭제한다. REST API또는 `client-go` 라이브러리를 이용할 때는 -d 옵션으로 `propagationPolicy`를 `Background`또는 `Foreground`로 설정해야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 3b95e2b47c..0fd4c8bb1f 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -34,7 +34,7 @@ weight: 40 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. * 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. -* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. +* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. * [롤링 업데이트](#롤링-업데이트)와 기본 [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 @@ -121,7 +121,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 `$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 `web-0,web-1,web-2` 이다. 스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 사용할 수 있다. +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다. 이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. 각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 @@ -130,7 +130,7 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 파드의 네트워크 신원을 책임지는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)를 생성할 책임이 있다. +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. 여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 2f8cbc2a61..ff6cc0284f 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -9,7 +9,7 @@ weight: 65 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 -제한하는 TTL 메커니즘을 제공한다. TTL 컨트롤러는 현재 +제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 [잡(Job)](/docs/concepts/workloads/controllers/jobs-run-to-completion/)만 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 813c111163..6811cd7e0a 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -67,8 +67,6 @@ PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. * `Initialized`: 모든 [초기화 컨테이너](/ko/docs/concepts/workloads/pods/init-containers)가 성공적으로 시작 완료되었음. - * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 - 지금 당장은 파드를 스케줄할 수 없음. * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임. @@ -256,12 +254,6 @@ status: 파드 준비성 평가에 대한 변경을 촉진하기 위해서, 이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. -K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 위해서는 -[특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를 -참으로 설정함으로써 명시적으로 활성화해야 한다. - -K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다. - ## 재시작 정책 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index b954a3478e..12d70b2c79 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -13,68 +13,50 @@ weight: 80 오랜 시간 동안 진행해온 누군가로서, 혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로서 기여할 수 있다. -쿠버네티스 문서 내용과 스타일에 -대해 더 많은 정보를 알고 싶다면, -[문서 스타일 개요](/docs/contribute/style/)를 참고하자. +{{% /capture %}} {{% capture body %}} -## 문서 컨트리뷰터 유형 +## 시작하기 -- 쿠버네티스 조직의 _멤버_ 는 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고, - 프로젝트에 어느 정도 시간과 노력을 바친 사람이다. - 멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 - 참고하라. -- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 - SIG Docs 승인자가 적합한 - GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한 - 쿠버네티스 조직의 멤버이다. -- SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다. - 승인자는 풀 리퀘스트를 머지(merge)할 수 있고, - 쿠버네티스 조직을 대표하여 콘텐츠를 공개한다. - 승인자는 거대한 쿠버네티스 커뮤니티에서 SIG Docs를 대표할 수 있다. - SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은 - 상당한 시간을 필요로 한다. +누구든지 문제에 대한 설명이나, 원하는 문서의 개선사항에 대한 이슈를 오픈 또는 풀 리퀘스트(PR)로 변경하는 기여를 할 수 있다. +일부 작업에는 쿠버네티스 조직에서 더 많은 신뢰와 더 많은 접근이 필요할 수 있다. +역할과 권한에 대한 자세한 내용은 +[SIG Docs 참여](/ko/docs/contribute/participating/)를 본다. -## 문서화에 기여할 수 있는 방법 +쿠버네티스 문서는 GitHub 리포지터리에 있다. 우리는 누구나 +기여를 환경하지만, 쿠버네티스 커뮤니티에서 효과적으로 활동하려면 git과 GitHub의 +기초적인 이해가 필요하다. -이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일, -그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 일로 나누어졌다. -지속적으로 기여를 하는 것은 -이미 만들어진 도구(tooling)와 조직의 결정을 -이해하는 데 도움이 될 것이다. +문서에 참여하려면 -이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만, -시작하는 데에 도움이 될 것이다. +1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명한다. +2. [문서 리포지터리](https://github.com/kubernetes/website) 와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지한다. +3. [콘텐츠 향상](https://kubernetes.io/docs/contribute/start/#improve-existing-content)과 [변경 검토](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)의 기본 프로세스를 이해하도록 한다. -- [누구나](/docs/contribute/start/) - - 조치 가능한 이슈 열기 -- [멤버](/docs/contribute/start/) - - 기존 문서 개선 - - [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시 - - 문서 접근성 개선 - - PR에 대한 구속력 없는 피드백 제공 - - 블로그 포스트 또는 사례 연구 작성 -- [리뷰어](/docs/contribute/intermediate/) - - 새로운 기능 문서화 - - 이슈 선별 및 분류 - - PR 리뷰 - - 다이어그램, 그래픽 자료, 내장 스크린샷 생성 - - 현지화(Localization) - - docs 대표로 다른 저장소에 기여 - - 코드 내 사용자 대면 문자열 편집 - - 코드 주석 및 Godoc 개선 -- [승인자](/docs/contribute/advanced/) - - 승인되어 머지된 PR을 바탕으로 컨트리뷰터 콘텐츠 출시 - - docs 대표로 쿠버네티스 릴리스 팀에 참가 - - 스타일 가이드 개선 제안 - - 문서 테스트 개선 제안 - - 쿠버네티스 website 또는 기타 도구(tooling) 개선 제안 +## 기여 모범 사례 +- 명확하고, 의미있는 GIT 커밋 메시지를 작성한다. +- 이슈를 참조하고, PR이 병합될 때 이슈를 자동으로 닫는 _Github 특수 키워드_ 를 포함한다. +- 오타 수정, 스타일 변경 또는 문법 변경과 같이 변경이 적은 PR을 생성할때, 비교적으로 적은 변화로 많은 커밋 개수를 받지 않도록 반드시 커밋을 스쿼시(squash)한다. +- 변경한 코드를 묘사하고, 코드를 변경한 이유를 포함하는 멋진 PR 설명을 포함하고 있는지와 리뷰어를 위한 충분한 정보가 있는지 꼭 확인한다. +- 추가적인 읽을거리들 + - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) + - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) + - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) -## 추가적인 기여 방법 +## 다른 방법으로 기여하기 - 트위터나 스택오버플로(Stack Overflow) 등의 온라인 포럼의 쿠버네티스 커뮤니티에 기여하거나 지역 모임과 쿠버네티스 이벤트에 관하여 알고 싶다면 [쿠버네티스 커뮤니티 사이트](/community/)를 확인한다. - 기능 개발에 기여하려면 [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 시작한다. {{% /capture %}} + +{{% capture whatsnext %}} + +- 문서에 기여하는 기본적인 사항들에 대한 자세한 내용은 [기여 시작](/docs/contribute/start/)을 본다. +- 변경을 제안할 때는 [쿠버네티스 문서 스타일가이드](/docs/contribute/style/style-guide/)를 따른다. +- SIG Docs에 대한 더 자세한 정보는 [SIG Docs에 참여하기](/ko/docs/contribute/participating/)를 본다. +- 쿠버네티스 문서 현지화에 대한 자세한 내용은 [쿠버네티스 문서 현지화](/docs/contribute/localization/)를 본다. + +{{% /capture %}} diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 887118a157..88db56aa34 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -19,7 +19,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 풀 리퀘스트(PR)를 요청할 수 있고, 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. -SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수도 있다. +[멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수 있다. 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) @@ -34,51 +34,47 @@ SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인 ## 역할과 책임 -풀 리퀘스트가 콘텐츠를 게재하는데 사용되는 브랜치(현재는 `master`)에 머지되면, 해당 콘텐츠가 세상에 -발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록, -SIG Docs 승인자만 풀 리퀘스트를 머지할 수 있도록 제한한다. -다음과 같이 진행된다. +- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. +- 쿠버네티스 조직의 **맴버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 맴버십 기준은 [커뮤니티 맴버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. +- SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 + 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 + 의해 GitHub 리포지터리에 있는 GitHub + 그룹과 `OWNER` 파일에 추가되었다. +- SIG Docs의 **승인자** 는 프로젝트에 대한 지속적인 헌신을 보여준 + 좋은 맴버이다. 승인자는 쿠버네티스 조직을 대신해서 + 풀 리퀘스트를 병합하고 컨텐츠를 게시할 수 있다. + 또한 승인자는 더 큰 쿠버네티스 커뮤니티의 SIG Docs를 대표할 수 있다. + 릴리즈 조정과 같은 SIG Docs 승인자의 일부 의무에는 + 상당한 시간 투입이 필요하다. -- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당 - 풀 리퀘스트가 자동으로 머지된다. -- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나 - `/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가 - 자동으로 머지되는 것을 막을 수 있다. -- 쿠버네티스 멤버 누구나 `/lgtm` 코멘트를 달아서 `lgtm` 레이블을 추가할 수 있다. -- `/approve` 코멘트를 달아서 풀 리퀘스트를 머지할 수 있는 SIG Docs 멤버는 승인자 뿐이다. - 일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는 - [SIG Docs chairperson](#sig-docs-chairperson) 같이 - 특화된 역할을 수행한다. +## 모든 사람 -쿠버네티스 조직 멤버와 SIG Docs 승인자 역할 사이의 기대와 차이에 대한 보다 많은 정보는 -[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다. -다음 섹션에서는 이런 역할과 SIG Docs에서 -이들이 작동하는 방식에 대해 -보다 상세한 내용을 다룬다. +누구나 다음 작업을 할 수 있다. -### 모든 사람 +- 문서를 포함한 쿠버네티스의 모든 부분에 대해 GitHub 이슈 열기. +- 풀 리퀘스트/ 에 대한 구속력 없는 피드백 제공 +- [슬랙](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선할 아이디어를 제시한다. +- `/lgtm` Prow 명령 ("looks good to me" 의 줄임말)을 사용해서 병합을 위한 풀 리퀘스트의 변경을 추천한다. + {{< note >}} + 만약 쿠버네티스 조직의 맴버가 아니라면, `/lgtm` 을 사용하는 것은 자동화된 시스템에 아무런 영향을 주지 않는다. + {{< /note >}} -문서를 포함해서, 쿠버네티스의 모든 부분에 대해서 누구나 이슈를 제기할 수 있다. +[CLS에 서명](/docs/contribute/start#sign-the-cla) 후에 누구나 다음을 할 수 있다. +- 기존 콘텐츠를 개선하거나, 새 콘텐츠를 추가하거나, 블로그 게시물 또는 사례연구 작성을 위해 풀 리퀘스트를 연다. -CLA에 서명한 누구나 풀 리퀘스트를 제출할 수 있다. CLA에 서명할 수 없다면, -쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다. +## 맴버 -### 멤버 +맴버는 [맴버 기준](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 충족하는 쿠버네티스 프로젝트에 기여한 사람들이다. SIG Docs는 쿠버네티스 커뮤니티의 모든 맴버로부터 기여를 환경하며, +기술적 정확성에 대한 다른 SIG 맴버들의 검토를 수시로 요청한다. -[쿠버네티스 조직](https://github.com/kubernetes)의 모든 멤버가 풀 리퀘스트를 리뷰할 수 있고, -기술적 정확도를 기하기 위해 SIG Docs 팀 멤버가 다른 분과회 멤버의 리뷰를 요청하는 일도 자주 -발생한다. -SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다. -풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다. -쿠버네티스 조직의 멤버가 아니라면, -`/lgtm` 코멘트는 자동화 시스템에 유효하지는 않다. +쿠버네티스 조직의 모든 맴버는 다음 작업을 할 수 있다. -쿠버네티스 조직의 모든 멤버는 `/hold` 코멘트를 달아서 풀 리퀘스트가 머지되는 것을 막을 수 있다. -또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다. -해당 PR이 이미 적임자로부터 -`/lgtm`과 `/approve`를 받은 경우라면 말이다. +- [모든 사람](#모든-사람) 하위에 나열된 모든 것 +- 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. +- 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. +- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. -#### 멤버 되기 +### 멤버 되기 최소 5개의 실질적인 풀 리퀘스트를 성공적으로 제출한 경우, 쿠버네티스 조직의 [멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md#member)을 @@ -108,20 +104,29 @@ SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주 해당 GitHub 이슈를 종료한다. 축하한다, 이제 멤버가 되었다! -어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우, +만약 맴버십 요청이 받아들여지지 않으면, 멤버십 위원회에서 재지원 전에 필요한 정보나 단계를 알려준다. -### 리뷰어 +## 리뷰어 리뷰어는 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참고한다. +GitHub 그룹의 멤버이다. 리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 +제공한다. 리뷰어는 다음 작업을 수행할 수 있다. -리뷰어는 문서 풀 리퀘스트를 리뷰하고 -제안받은 변경에 대한 피드백을 제공한다. +- [모든 사람](#모든-사람)과 [맴버](#맴버)에 나열된 모든 것을 수행 +- 새 기능의 문서화 +- 이슈 해결 및 분류 +- 풀 리퀘스트 리뷰와 구속력있는 피드백 제공 +- 다이어그램, 그래픽 자산과 포함가능한 스크린샷과 비디오를 생성 +- 현지화 +- 코드에서 사용자 화면 문자열 편집 +- 코드 코멘트 개선 -자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에 +### 풀 리퀘스트에 대한 리뷰어 할당 + +자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 사용자는 해당 풀 리퀘스트에 `/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다. 풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, 리뷰어는 `/lgtm` 코멘트를 @@ -136,11 +141,7 @@ GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-wit 리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다. -SIG Docs 리뷰어가 되는 방법과 -수반되는 책임과 시간 할애에 대한 보다 많은 정보는 -[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. - -#### 리뷰어 되기 +### 리뷰어 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 충족하면, SIG Docs 리뷰어가 될 수 있다. @@ -161,26 +162,27 @@ SIG Docs 리뷰어가 되는 방법과 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. -### 승인자 +## 승인자 승인자는 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다. -승인자는 PR을 머지할 수 있으므로, 쿠버네티스 웹사이트에 콘텐츠를 게재할 수 있다. -PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다. -승인자가 아닌 누군가가 승인 코멘트를 남기더라도, -자동화 시스템은 이를 무시한다. +승인자는 다음의 작업을 할 수 있다. + +- [모든 사람](#모든-사람), [맴버](#맴버) 그리고 [리뷰어](#리뷰어) 하위의 모든 목록을 할 수 있다. +- 코멘트에 `/approve` 를 사용해서 풀 리퀘스트를 승인하고, 병합해서 기여자의 컨텐츠를 게시한다. + 만약 승인자가 아닌 사람이 코멘트에 승인을 남기면 자동화 시스템에서 이를 무시한다. +- 쿠버네티스 릴리즈팀에 문서 담당자로 참여 +- 스타일 가이드 개선 제안 +- 문서 테스트 개선 제안 +- 쿠버네티스 웹사이트 또는 다른 도구 개선 제안 PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는 해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 `/lgtm`을 남겨야한다. -SIG Docs 승인자가 되는 방법과 -수반되는 책임과 시간 할애에 대한 보다 많은 정보는 -[리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. - -#### 승인자 되기 +### 승인자 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 충족하면, SIG Docs 승인자가 될 수 있다. @@ -201,7 +203,7 @@ SIG Docs 승인자가 되는 방법과 GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. -#### 승인자의 책임 +### 승인자의 책임 승인자는 리뷰와 풀리퀘스트를 웹사이트 리포지터리에 머지하여 문서를 개선한다. 이 역할에는 추가적인 권한이 필요하므로, 승인자에게는 별도의 책임이 부여된다. @@ -209,7 +211,7 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm 부주의한 머지로 인해 사이트를 파괴할 수 있으므로, 머지할 때에 그 의미를 확인해야 한다. -- 제안된 변경이 컨트리뷰션 가이드 라인에 적합한지 확인한다. +- 제안된 변경이 [컨트리뷰션 가이드 라인](/docs/contribute/style/content-guide/#contributing-content)에 적합한지 확인한다. 질문이 생기거나 확실하지 않다면 자유롭게 추가 리뷰를 요청한다. @@ -219,16 +221,11 @@ GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-adm - 승인 전에 PR에 대한 Netlify 프리뷰 페이지를 방문하여, 제대로 보이는지 확인한다. -#### PR Wrangler - -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) +- 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 +것으로 기대한다. [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 문서를 참고한다. -#### SIG Docs chairperson +## SIG Docs chairperson SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 @@ -285,6 +282,24 @@ OWNERS 파일과 마크다운 파일 내 전문의 조합은 자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 PR 소유자에게 조언하는데 활용된다. +## 병합 작업 방식 + +풀 리퀘스트 요청이 콘텐츠(현재 `master`)를 발행하는데 사용하는 +브랜치에 병합되면 그 내용이 전 세계에 공개된다. 게시된 콘텐츠의 +품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. +작동 방식은 다음과 같다. + +- 풀 리퀘스트에 `lgtm` 과 `approve` 레이블이 있고, `hold` 레이블이 없고, + 모든 테스트를 통과하면 풀 리퀘스트는 자동으로 병합된다. +- 쿠버네티스 조직의 맴버와 SIG Docs 승인자들은 지정된 풀 리퀘스트의 + 자동 병합을 방지하기 위해 코멘트를 추가할 수 있다(코멘트에 `/hold` 추가 또는 + `/lgtm` 코멘트 보류). +- 모든 쿠버네티스 맴버는 코멘트에 `/lgtm` 을 추가해서 `lgtm` 레이블을 추가할 수 있다. +- SIG Docs 승인자들만이 코멘트에 `/approve` 를 + 추가해서 풀 리퀘스트를 병합할 수 있다. 일부 승인자들은 + [PR Wrangler](#pr-wrangler) EHsms [SIG Docs 의장](#sig-docs-chairperson)과 + 같은 특정 역할도 수행한다. + {{% /capture %}} {{% capture whatsnext %}} @@ -296,4 +311,3 @@ PR 소유자에게 조언하는데 활용된다. {{% /capture %}} - diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index d12c0a9d28..7bf1eb4579 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -17,12 +17,7 @@ content_template: templates/concept ## API 레퍼런스 * [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 -* 쿠버네티스 API 버전 - * [1.17](/docs/reference/generated/kubernetes-api/v1.17/) - * [1.16](/docs/reference/generated/kubernetes-api/v1.16/) - * [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/) +* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## API 클라이언트 라이브러리 @@ -37,18 +32,17 @@ content_template: templates/concept ## CLI 레퍼런스 -* [kubectl](/docs/user-guide/kubectl-overview) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. - * [JSONPath](/docs/user-guide/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. -* [kubeadm](/docs/admin/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. -* [kubefed](/docs/admin/kubefed/) - 연합된(federated) 클러스터 관리를 도와주는 CLI 도구. +* [kubectl](/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](http://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. +* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 설정 레퍼런스 -* [kubelet](/docs/admin/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. -* [kube-apiserver](/docs/admin/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. -* [kube-controller-manager](/docs/admin/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. -* [kube-proxy](/docs/admin/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. -* [kube-scheduler](/docs/admin/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. ## 설계 문서 diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md index cd850a828b..85fe177e6b 100644 --- a/content/ko/docs/reference/glossary/device-plugin.md +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -4,14 +4,26 @@ id: device-plugin date: 2019-02-02 full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > - 쿠버네티스에서 동작하는 컨테이너로, 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 파드가 공급자별 초기화 또는 설정이 필요한 장치에 접근할 수 있도록 하는 소프트웨어 확장 aka: tags: - fundamental - extension --- - 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + 장치 플러그인은 워커\ + {{< glossary_tooltip term_id="node" text="노드">}}에서 실행되며, + 공급자별 초기화 또는 설정 단계가 필요한 로컬 하드웨어와 + 같은 리소스에 접근할 수 있는 + {{< glossary_tooltip term_id="pod" text="파드">}}. -[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 {{< glossary_tooltip term_id="kubelet" >}}에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로도 디플로이 가능하다. +장치 플러그인은 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}에 +리소스를 알리기에 워크로드 파드는 해당 파드가 실행중인 +노드와 관련된 하드웨어 기능에 접근할 수 있다. +장치 플러그인을 {{< glossary_tooltip term_id="daemonset" >}}으로 배포하거나, +각 대상 노드에 직접 장치 플러그인 소프트웨어를 설치할 수 있다. + +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +의 더 자세한 정보를 +본다 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 071669a6c8..ccac6c32d1 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -140,7 +140,7 @@ EOF # 기본 출력을 위한 Get 커맨드 kubectl get services # 네임스페이스 내 모든 서비스의 목록 조회 kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회 -kubectl get pods -o wide # 네임스페이스 내 모든 파드의 상세 목록 조회 +kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회 kubectl get deployment my-dep # 특정 디플로이먼트의 목록 조회 kubectl get pods # 네임스페이스 내 모든 파드의 목록 조회 kubectl get pod my-pod -o yaml # 파드의 YAML 조회 @@ -156,9 +156,8 @@ kubectl get services --sort-by=.metadata.name # 재시작 횟수로 정렬된 파드의 목록 조회 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' -# test 네임스페이스를 가지는 PersistentVolumes을 용량별로 정렬해서 조회 - -kubectl get pv -n test --sort-by=.spec.capacity.storage +# PersistentVolumes을 용량별로 정렬해서 조회 +kubectl get pv --sort-by=.spec.capacity.storage # app=cassandra 레이블을 가진 모든 파드의 레이블 버전 조회 kubectl get pods --selector=app=cassandra -o \ diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f02188813b..3cc93f7c7f 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -69,6 +69,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | dotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | {{% /capture %}} diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 668684fa03..0ece7e3661 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -37,7 +37,7 @@ card: |커뮤니티 |생태계 | | ------------ | -------- | | [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | -| [kind (Kubernetes IN Docker)](https://github.com/kubernetes-sigs/kind) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [kind (Kubernetes IN Docker)](/docs/setup/learning-environment/kind/) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| | | [Minishift](https://docs.okd.io/latest/minishift/)| | | [MicroK8s](https://microk8s.io/)| | | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index d66ada6ea8..5bea0d3d9b 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -200,7 +200,11 @@ minikube start --vm-driver= * hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) 다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. * vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 개인용 워크스테이션에서 none 드라이버를 사용하는 것을 권장하지 않는다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) +* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) + +{{< caution >}} +`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. +{{< /caution >}} #### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index c83a13327a..e20fe5fd0a 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -73,7 +73,7 @@ kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. ## 리포지터리 설정 ### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 apt-get update && apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common + apt-transport-https ca-certificates curl software-properties-common gnupg2 ### Docker의 공식 GPG 키 추가 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - @@ -160,6 +160,11 @@ systemctl restart docker 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. +{{< note >}} +CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 버전이 일치해야 한다. +더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다. +{{< /note >}} + ### 선행 조건 ```shell diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 0be5cfc5ce..75929ae973 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -352,7 +352,7 @@ redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 - 서비스에 접근하는 데 사용되면 load balacing한다 -1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): +1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드 상에서 실행된다 - UDP와 TCP를 proxy한다 diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index 46ca07d452..f9d87d9095 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -79,7 +79,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. 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 index 9f1be04977..f563fae04b 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md @@ -8,7 +8,7 @@ title: 리소스 모니터링 도구 애플리케이션을 스케일하여 신뢰할 수 있는 서비스를 제공하려면, 애플리케이션이 배포되었을 때 애플리케이션이 어떻게 동작하는지를 이해해야 한다. 컨테이너, [파드](/ko/docs/concepts/workloads/pods/pod), -[서비스](/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 +[서비스](/ko/docs/concepts/services-networking/service), 그리고 전체 클러스터의 특성을 검사하여 쿠버네티스 클러스터 내의 애플리케이션 성능을 검사할 수 있다. 쿠버네티스는 각 레벨에서 애플리케이션의 리소스 사용량에 대한 상세 정보를 제공한다. 이 정보는 애플리케이션의 성능을 평가하고 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 d47b6e7f31..dde6650e20 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -81,7 +81,14 @@ kubectl apply -f <디렉터리>/ kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` {{< note >}} -`diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. +`diff`는 `kube-apiserver`의 활성화가 필요한 +[서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. + +`diff` 는 dry-run 모드에서 서버 측 적용 요청을 수행하므로, +`PATCH`, `CREATE`, 그리고 `UPDATE` 권한을 부여해야 한다. +자세한 것은 +[Dry-Run 인증](/docs/reference/using-api/api-concepts#dry-run-authorization)을 본다. + {{< /note >}} `kubectl apply`를 사용하여 오브젝트를 생성한다. 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 418ebb17dc..5672b7809b 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 @@ -57,14 +57,19 @@ index.php는 CPU 과부하 연산을 수행한다. ?> ``` -첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다. +첫 번째 단계로, 다음 구성을 사용해서 실행 중인 이미지의 디플로이먼트를 +시작하고 서비스로 노출시킨다. +{{< codenew file="application/php-apache.yaml" >}} + + +다음의 명령어를 실행한다. ```shell -kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --limits=cpu=500m --expose --port=80 +kubectl apply -f https://k8s.io/examples/application/php-apache.yaml ``` ``` -service/php-apache created deployment.apps/php-apache created +service/php-apache created ``` ## Horizontal Pod Autoscaler 생성 diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index 3f40a1b22b..4043ef3a13 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -158,15 +158,11 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은 현재 값보다 높은 `desiredReplicas` 을 제공하는 경우 HPA가 여전히 확장할 수 있음을 의미한다. -마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 -기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 -사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 -`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트 -동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한 -스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을 -사용하여 설정할 수 있고, 기본 값은 5분이다. -즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 -영향을 완만하게 한다. +마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. +컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의 +모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다. +즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 +메트릭 값의 영향을 완만하게 한다. ## API 오브젝트 @@ -213,6 +209,9 @@ Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 평가된 메트릭의 동적인 특징 때문에 레플리카 수가 자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다. +v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로 +노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다. + v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 필요성을 제거하였다. @@ -229,11 +228,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 있다. {{< /note >}} -v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds` -를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다. -[구성가능한 스케일링 -동작 지원](#구성가능한-스케일링-동작-지원)을 본다. - ## 멀티 메트릭을 위한 지원 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API @@ -284,154 +278,6 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. 어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과 [외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다. -## 구성가능한 스케일링 동작 지원 - -[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) -부터 `v2beta2` API는 HPA `behavior` 필드를 통해 -스케일링 동작을 구성할 수 있다. -동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown` -섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는 -스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는 -양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면 -스케일링 중 레플리카 변경 속도를 제어할 수 있다. - -### 스케일링 정책 - -스펙의 `behavior` 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다. -폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을 -허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이 -동작을 보여준다. - -```yaml -behavior: - scaleDown: - policies: - - type: Pods - value: 4 - periodSeconds: 60 - - type: Percent - value: 10 - periodSeconds: 60 -``` - -파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다. -예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는 -경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때 -다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의 -각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40 -미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에 -4개의 레플리카가 줄어든다. - -`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다. -첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다. -두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다. - -확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다. -레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다. -값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히 -비활성화 된다. - -### 안정화 윈도우 - -안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을 -다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터 -계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다. -다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다. - -```yaml -scaleDown: - stabilizationWindowSeconds: 300 -``` - -메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은 -이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다. -위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다. - -### 기본 동작 - -사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야 -하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA -알고리즘의 기존 동작과 일치한다. - -```yaml -behavior: - scaleDown: - stabilizationWindowSeconds: 300 - policies: - - type: Percent - value: 100 - periodSeconds: 15 - scaleUp: - stabilizationWindowSeconds: 0 - policies: - - type: Percent - value: 100 - periodSeconds: 15 - - type: Pods - value: 4 - periodSeconds: 15 - selectPolicy: Max -``` -안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된 -경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재 -실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링 -대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다. -스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다. -두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다 -4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다. - -### 예시: 다운스케일 안정화 윈도우 변경 - -사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해 -다음 동작이 HPA에 추가된다. - -```yaml -behavior: - scaleDown: - stabilizationWindowSeconds: 60 -``` - -### 예시: 스케일 다운 비율 제한 - -HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해 -다음 동작이 HPA에 추가된다. - -```yaml -behavior: - scaleDown: - policies: - - type: Percent - value: 10 - periodSeconds: 60 -``` - -마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택 -전략을 추가할 수 있다. - -```yaml -behavior: - scaleDown: - policies: - - type: Percent - value: 10 - periodSeconds: 60 - - type: Pods - value: 5 - periodSeconds: 60 - selectPolicy: Max -``` - -### 예시: 스케일 다운 비활성화 - -`selectPolicy` 의 `Disabled` 값은 주어진 방향으로의 스케일링을 끈다. -따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다. - -```yaml -behavior: - scaleDown: - selectPolicy: Disabled -``` - {{% /capture %}} {{% capture whatsnext %}} diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index e8de40ce96..b50856ff08 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -74,9 +74,17 @@ kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설 • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) -{{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않는다. none 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 에서 도커를 apt로 설치하기를 사용하는 것을 권장한다. 도커의 스냅 설치는 minikube에서 작동하지 않는다. -{{< /note >}} +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. +이 드라이버를 사용하려면 [도커](https://www.docker.com/products/docker-desktop) 와 Linux 환경이 필요하지만, 하이퍼바이저는 필요하지 않다. + +데비안(Debian) 또는 파생된 배포판에서 `none` 드라이버를 사용하는 경우, +Minikube에서는 동작하지 않는 스냅 패키지 대신 도커용 `.deb` 패키지를 사용한다. +[도커](https://www.docker.com/products/docker-desktop)에서 `.deb` 패키지를 다운로드 할 수 있다. + +{{< caution >}} +`none` VM 드라이버는 보안과 데이터 손실 이슈를 일으킬 수 있다. +`--vm-driver=none` 을 사용하기 전에 [이 문서](https://minikube.sigs.k8s.io/docs/reference/drivers/none/)를 참조해서 더 자세한 내용을 본다. +{{< /caution >}} ### 패키지를 이용하여 Minikube 설치 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index 858bb59f58..e3f9246a4f 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -329,7 +329,7 @@ Events: 현재 쿠버네티스는 AppArmor 프로파일을 노드에 적재하기 위한 네이티브 메커니즘을 제공하지 않는다. 프로파일을 설정하는 여러 방법이 있다. 예를 들면 다음과 같다. -* 각 노드에서 파드를 실행하는 [데몬셋](/docs/concepts/workloads/controllers/daemonset/)을 통해서 +* 각 노드에서 파드를 실행하는 [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/)을 통해서 올바른 프로파일이 적재되었는지 확인한다. 예시 구현은 [여기](https://git.k8s.io/kubernetes/test/images/apparmor-loader)에서 찾아볼 수 있다. * 노드 초기화 시간에 노드 초기화 스크립트(예를 들어 Salt, Ansible 등)나 @@ -340,7 +340,7 @@ Events: 스케줄러는 어떤 프로파일이 어떤 노드에 적재되는지 고려하지 않으니, 프로파일 전체 집합이 모든 노드에 적재되어야 한다. 대안적인 방법은 각 프로파일(혹은 프로파일의 클래스)을 위한 노드 레이블을 노드에 추가하고, -[노드 셀렉터](/docs/concepts/configuration/assign-pod-node/)를 이용하여 +[노드 셀렉터](/ko/docs/concepts/configuration/assign-pod-node/)를 이용하여 파드가 필요한 프로파일이 있는 노드에서 실행되도록 한다. ### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy} diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index e24b887509..b4209de162 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -117,7 +117,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl config view ``` - + {{< note >}}`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개관](/docs/user-guide/kubectl-overview/)을 살펴보자.{{< /note >}} ## 서비스 만들기 @@ -125,14 +125,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 기본적으로 파드는 쿠버네티스 클러스터 내부의 IP 주소로만 접근할 수 있다. `hello-node` 컨테이너를 쿠버네티스 가상 네트워크 외부에서 접근하려면 파드를 쿠버네티스 -[*서비스*](/docs/concepts/services-networking/service/)로 노출해야 한다. +[*서비스*](/ko/docs/concepts/services-networking/service/)로 노출해야 한다. 1. `kubectl expose` 명령어로 퍼블릭 인터넷에 파드 노출하기 ```shell kubectl expose deployment hello-node --type=LoadBalancer --port=8080 ``` - + `--type=LoadBalancer`플래그는 클러스터 밖의 서비스로 노출하기 원한다는 뜻이다. @@ -198,13 +198,13 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 storage-provisioner: enabled storage-provisioner-gluster: disabled ``` - + 2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server` ```shell minikube addons enable metrics-server ``` - + 다음과 유사하게 출력된다. ``` @@ -245,7 +245,7 @@ Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네 ```shell minikube addons disable metrics-server ``` - + 다음과 유사하게 출력된다. ``` @@ -278,7 +278,7 @@ minikube delete {{% capture whatsnext %}} * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해서 더 배워 본다. -* [애플리케이션 배포](/docs/user-guide/deploying-applications/)에 대해서 더 배워 본다. -* [서비스 오브젝트](/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. +* [애플리케이션 배포](/docs/tasks/run-application/run-stateless-application-deployment/)에 대해서 더 배워 본다. +* [서비스 오브젝트](/ko/docs/concepts/services-networking/service/)에 대해서 더 배워 본다. {{% /capture %}} diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 719ab6e1b7..23ba647830 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -23,8 +23,8 @@ content_template: templates/tutorial * [NAT](https://en.wikipedia.org/wiki/Network_address_translation): 네트워크 주소 변환 * [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT): 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소 * [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT): 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소 -* [VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 -* [Kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. +* [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 +* [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시): 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. ## 전제 조건 @@ -34,7 +34,7 @@ content_template: templates/tutorial 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다. ```console -kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl create deployment source-ip-app --image=k8s.gcr.io/echoserver:1.4 ``` 출력은 다음과 같다. ``` @@ -57,7 +57,7 @@ deployment.apps/source-ip-app created ## Type=ClusterIP인 서비스에서 소스 IP 쿠버네티스 1.2부터 기본으로 제공하는 -[iptables 모드](/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 +[iptables 모드](/ko/docs/concepts/services-networking/service/#proxy-mode-iptables)로 운영하는 경우 클러스터 내에서 클러스터 IP로 패킷을 보내면 소스 NAT를 통과하지 않는다. Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다. @@ -122,7 +122,7 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또 ## Type=NodePort인 서비스에서 소스 IP -쿠버네티스 1.5부터 [Type=NodePort](/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 +쿠버네티스 1.5부터 [Type=NodePort](/ko/docs/concepts/services-networking/service/#nodeport)인 서비스로 보내진 패킷은 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다. ```console @@ -221,7 +221,7 @@ client_address=104.132.1.79 ## Type=LoadBalancer인 서비스에서 소스 IP -쿠버네티스 1.5 부터 [Type=LoadBalancer](/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 +쿠버네티스 1.5 부터 [Type=LoadBalancer](/ko/docs/concepts/services-networking/service/#loadbalancer)인 서비스로 보낸 패킷은 소스 NAT를 기본으로 하는데, `Ready` 상태로 모든 스케줄된 모든 쿠버네티스 노드는 로드 밸런싱 트래픽에 적합하다. 따라서 엔드포인트가 없는 노드에 패킷이 도착하면 시스템은 엔드포인트를 *포함한* 노드에 프록시를 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 45056e8622..59fdbbc7e3 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -17,7 +17,7 @@ weight: 10 * [파드](/docs/user-guide/pods/single-container/) * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) -* [헤드리스 서비스(Headless Services)](/docs/concepts/services-networking/service/#headless-services) +* [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) * [퍼시스턴트볼륨(PersistentVolumes)](/docs/concepts/storage/persistent-volumes/) * [퍼시턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) @@ -51,7 +51,7 @@ weight: 10 아래 예제를 이용해서 스테이트풀셋을 생성하자. 이는 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) 개념에서 보인 예제와 유사하다. 이것은 `web`과 이 스테이트풀셋 파드의 IP 주소를 게시하는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services)인 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)인 `nginx` 를 생성한다. {{< codenew file="application/web/web.yaml" >}} diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 10c011aa3b..72c090988c 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -29,7 +29,7 @@ weight: 30 {{% /capture %}} {{% capture objectives %}} -* 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다. +* 카산드라 헤드리스 [*서비스*](/ko/docs/concepts/services-networking/service/)를 생성하고 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 검증한다. * [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 수정한다. @@ -37,7 +37,7 @@ weight: 30 {{% /capture %}} {{% capture prerequisites %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 +이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 * *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. @@ -65,7 +65,7 @@ minikube start --memory 5120 --cpus=4 {{% capture lessoncontent %}} ## 카산드라 헤드리스 서비스 생성하기 -쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. +쿠버네티스 [서비스](/ko/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/ko/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. 다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index 1f419fdaf3..603a857a58 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -233,7 +233,7 @@ kubectl apply -k ./ * [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. * [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. -* [포트 포워딩](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. +* [포트 포워딩](/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. * 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 06dc81fed4..7486a7fe71 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -6,9 +6,9 @@ weight: 40 {{% capture overview %}} 이 튜토리얼은 [아파치 ZooKeeper](https://zookeeper.apache.org) -쿠버네티스에서 [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 -[파드디스룹선버짓(PodDisruptionBudget)](/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 -[파드안티어피니티(PodAntiAffinity)](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. +쿠버네티스에서 [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 +[파드디스룹선버짓(PodDisruptionBudget)](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget)과 +[파드안티어피니티(PodAntiAffinity)](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티)를 이용한 [Apache Zookeeper](https://zookeeper.apache.org) 실행을 설명한다. {{% /capture %}} {{% capture prerequisites %}} @@ -18,12 +18,12 @@ weight: 40 - [파드](/docs/user-guide/pods/single-container/) - [클러스터 DNS](/ko/docs/concepts/services-networking/dns-pod-service/) -- [헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services) +- [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) - [퍼시스턴트볼륨](/docs/concepts/storage/volumes/) - [퍼시스턴트볼륨 프로비저닝](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) - [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/) - [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions/#specifying-a-poddisruptionbudget) -- [파드안티어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) +- [파드안티어피니티](/ko/docs/user-guide/node-selection/#파드간-어피니티와-안티-어피니티) - [kubectl CLI](/docs/user-guide/kubectl/) 최소한 4개의 노드가 있는 클러스터가 필요하며, 각 노드는 적어도 2 개의 CPU와 4 GiB 메모리가 필요하다. 이 튜토리얼에서 클러스터 노드를 통제(cordon)하고 비우게(drain) 할 것이다. **이것은 클러스터를 종료하여 노드의 모든 파드를 퇴출(evict)하는 것으로, 모든 파드는 임시로 언스케줄된다는 의미이다.** 이 튜토리얼을 위해 전용 클러스터를 이용하거나, 다른 테넌트에 간섭을 하는 혼란이 발생하지 않도록 해야 합니다. @@ -62,8 +62,8 @@ ZooKeeper는 전체 상태 머신을 메모리에 보존하고 모든 돌연변 ## ZooKeeper 앙상블 생성하기 아래 메니페스트에는 -[헤드리스 서비스](/docs/concepts/services-networking/service/#headless-services), -[서비스](/docs/concepts/services-networking/service/), +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스), +[서비스](/ko/docs/concepts/services-networking/service/), [파드디스룹션버짓](/ko/docs/concepts/workloads/pods/disruptions//#specifying-a-poddisruptionbudget), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)을 포함한다. diff --git a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md index 78b72c9e73..0f7360273e 100644 --- a/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md +++ b/content/ko/docs/tutorials/stateless-application/expose-external-ip-address.md @@ -80,8 +80,17 @@ kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s - 참고: 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, - 동일한 명령어를 다시 입력한다. + {{< note >}} + + `type=LoadBalancer` 서비스는 이 예시에서 다루지 않은 외부 클라우드 공급자가 지원하며, 자세한 내용은 [이 페이지](/ko/docs/concepts/services-networking/service/#loadbalancer를 참조한다. + + {{< /note >}} + + {{< note >}} + + 만약 외부 IP 주소가 \으로 표시되면 잠시 기다린 다음, 동일한 명령어를 다시 입력한다. + + {{< /note >}} 1. 서비스에 대한 자세한 정보를 확인한다. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index a1f24755b8..4753c83b93 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -77,7 +77,7 @@ POD-NAME을 해당 파드 이름으로 수정해야 한다. ### Redis 마스터 서비스 생성하기 -방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. +방명록 애플리케이션에서 데이터를 쓰려면 Redis 마스터와 통신해야 한다. Redis 마스터 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. {{< codenew file="application/guestbook/redis-master-service.yaml" >}} @@ -197,7 +197,7 @@ Redis 마스터는 단일 파드이지만, 복제된 Redis 슬레이브를 추 ### 프론트엔드 서비스 생성하기 -서비스의 기본 유형은 [ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. +서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 redis-slave 및 redis-master 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. 게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 컨테이너 클러스터 외부에서 서비스를 요청할 수 있다. Minikube는 `NodePort`를 통해서만 서비스를 노출할 수 있다. diff --git a/content/ko/examples/application/php-apache.yaml b/content/ko/examples/application/php-apache.yaml new file mode 100644 index 0000000000..5eb04cfb89 --- /dev/null +++ b/content/ko/examples/application/php-apache.yaml @@ -0,0 +1,39 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: php-apache +spec: + selector: + matchLabels: + run: php-apache + replicas: 1 + template: + metadata: + labels: + run: php-apache + spec: + containers: + - name: php-apache + image: k8s.gcr.io/hpa-example + ports: + - containerPort: 80 + resources: + limits: + cpu: 500m + requests: + cpu: 200m + +--- + +apiVersion: v1 +kind: Service +metadata: + name: php-apache + labels: + run: php-apache +spec: + ports: + - port: 80 + selector: + run: php-apache + diff --git a/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-all.yaml b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/ko/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress