From 64f9f3ebd42894f85e79fbf02344af4f3cc12692 Mon Sep 17 00:00:00 2001 From: "kosehy@gmail.com" Date: Thu, 12 Nov 2020 22:40:40 +0900 Subject: [PATCH] Fifth Korean l10n work for release-1.19 - Update outdated in concept secret.md (#25254) - Update outdated resource quotas for ko5 (#25261) - Mistranslation on kubelet-authentication authorization.md in korean (#25223) - Update outdated files in dev-1.19-ko.5 part-03 (#25159) - Update outdated files in the upstream/dev-1.19-ko.5 branch (#25103) - Update outdated files in dev-1.19-ko.5 part-02 (#25152) - Translate reference/glossary/container-lifecycle-hooks.md in Korean (#25071) - Translate reference/command-line-tools-reference/kube-proxy into korean (#24817) - Translate reference/scheduling/config.md into Korean (#24489) - Translate reference/kubectl/jsonpath into Korean (#24868) Co-authored-by: seokho-son Co-authored-by: Jerry Park Co-authored-by: kosehy@gmail.com Co-authored-by: santachopa --- .../docs/concepts/architecture/controller.md | 12 +- .../concepts/cluster-administration/_index.md | 2 +- .../cluster-administration/logging.md | 2 +- .../cluster-administration/networking.md | 12 +- .../cluster-administration/system-metrics.md | 8 + .../ko/docs/concepts/configuration/secret.md | 383 +++++++- content/ko/docs/concepts/containers/images.md | 4 +- .../docs/concepts/extend-kubernetes/_index.md | 2 +- .../api-extension/custom-resources.md | 2 +- .../extend-kubernetes/extend-cluster.md | 2 +- .../extend-kubernetes/service-catalog.md | 2 +- .../docs/concepts/overview/kubernetes-api.md | 20 +- .../concepts/overview/what-is-kubernetes.md | 2 +- .../kubernetes-objects.md | 3 +- .../overview/working-with-objects/labels.md | 2 +- .../concepts/policy/pod-security-policy.md | 16 +- .../docs/concepts/policy/resource-quotas.md | 194 ++-- .../scheduling-eviction/kube-scheduler.md | 6 +- .../security}/controlling-access.md | 0 content/ko/docs/concepts/security/overview.md | 4 +- .../services-networking/dual-stack.md | 2 +- .../concepts/services-networking/ingress.md | 7 + .../concepts/storage/persistent-volumes.md | 8 +- .../docs/concepts/storage/storage-classes.md | 2 +- .../docs/concepts/storage/volume-snapshots.md | 2 + content/ko/docs/concepts/storage/volumes.md | 837 +++++++++--------- content/ko/docs/concepts/workloads/_index.md | 2 +- .../workloads/controllers/replicaset.md | 2 +- .../concepts/workloads/pods/pod-lifecycle.md | 15 +- .../pods/pod-topology-spread-constraints.md | 12 +- .../contribute/participate/pr-wranglers.md | 2 +- content/ko/docs/reference/_index.md | 6 +- .../reference/access-authn-authz/_index.md | 26 +- .../access-authn-authz/authorization.md | 6 +- .../feature-gates.md | 4 +- .../kube-proxy.md | 343 +++++++ .../kubelet-authentication-authorization.md | 2 +- .../glossary/container-lifecycle-hooks.md | 17 + .../ko/docs/reference/glossary/container.md | 2 +- content/ko/docs/reference/kubectl/jsonpath.md | 113 +++ .../ko/docs/reference/scheduling/config.md | 253 ++++++ content/ko/docs/reference/tools.md | 4 +- content/ko/docs/reference/using-api/_index.md | 119 ++- .../docs/reference/using-api/api-overview.md | 113 --- .../reference/using-api/client-libraries.md | 2 +- .../docs/setup/learning-environment/_index.md | 29 + .../setup/learning-environment/minikube.md | 512 ----------- .../container-runtimes.md | 454 +++++----- .../windows/intro-windows-in-kubernetes.md | 2 +- .../access-cluster.md | 3 +- .../administer-cluster/access-cluster-api.md | 4 +- .../administer-cluster/cluster-management.md | 2 +- .../kubeadm/kubeadm-certs.md | 2 +- .../romana-network-policy.md | 2 +- .../weave-network-policy.md | 2 +- .../assign-memory-resource.md | 4 +- .../configure-persistent-volume-storage.md | 2 +- .../resource-metrics-pipeline.md | 4 +- .../resource-usage-monitoring.md | 2 +- .../define-environment-variable-container.md | 13 +- .../horizontal-pod-autoscale-walkthrough.md | 4 +- .../horizontal-pod-autoscale.md | 4 +- content/ko/docs/tasks/tools/_index.md | 30 +- .../ko/docs/tasks/tools/install-kubectl.md | 2 +- content/ko/docs/tutorials/hello-minikube.md | 18 +- .../stateful-application/cassandra.md | 2 +- .../guestbook-logs-metrics-with-elk.md | 212 +++-- content/ko/includes/task-tutorial-prereqs.md | 2 +- 68 files changed, 2295 insertions(+), 1595 deletions(-) rename content/ko/docs/{reference/access-authn-authz => concepts/security}/controlling-access.md (100%) create mode 100644 content/ko/docs/reference/command-line-tools-reference/kube-proxy.md create mode 100644 content/ko/docs/reference/glossary/container-lifecycle-hooks.md create mode 100644 content/ko/docs/reference/kubectl/jsonpath.md create mode 100644 content/ko/docs/reference/scheduling/config.md delete mode 100644 content/ko/docs/reference/using-api/api-overview.md delete mode 100644 content/ko/docs/setup/learning-environment/minikube.md diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 836b4a5b6b..b65cf13803 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -96,7 +96,17 @@ weight: 30 컨트롤러가 있다. [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 본다.) -## 원하는 상태와 현재 상태 {#desired-vs-current} +여기서 중요한 점은 컨트롤러가 의도한 상태를 가져오기 위해 약간의 변화를 주고, +현재 상태를 클러스터의 API 서버에 다시 보고한다는 것이다. +다른 컨트롤 루프는 보고된 데이터를 관찰하고 자체 조치를 할 수 있다. + +온도 조절기 예에서 방이 매우 추우면 다른 컨트롤러가 +서리 방지 히터를 켤 수도 있다. 쿠버네티스 클러스터에서는 +[쿠버네티스 확장](/ko/docs/concepts/extend-kubernetes/)을 통해 +IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자 APIS 및 +기타 서비스 등과 간접적으로 연동하여 이를 구현한다. + +## 의도한 상태와 현재 상태 {#desired-vs-current} 쿠버네티스는 클라우드-네이티브 관점에서 시스템을 관찰하며, 지속적인 변화에 대응할 수 있다. diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md index daa1dfd702..ffeb3a58fb 100755 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -47,7 +47,7 @@ no_list: true * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다. -* [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)는 사용자와 서비스 어카운트에 대한 권한을 설정하는 방법을 설명한다. +* [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)는 쿠버네티스가 자체 API에 대한 접근 제어를 구현하는 방법을 설명한다. * [인증](/docs/reference/access-authn-authz/authentication/)은 다양한 인증 옵션을 포함한 쿠버네티스에서의 인증에 대해 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 4a0b700e02..48044b0460 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -22,7 +22,7 @@ weight: 60 이 섹션에서는, 쿠버네티스에서 표준 출력 스트림으로 데이터를 출력하는 기본 로깅의 예시를 볼 수 있다. 이 데모에서는 일부 텍스트를 초당 한 번씩 표준 출력에 쓰는 컨테이너와 함께 -[파드 명세](/examples/debug/counter-pod.yaml)를 사용한다. +파드 명세를 사용한다. {{< codenew file="debug/counter-pod.yaml" >}} diff --git a/content/ko/docs/concepts/cluster-administration/networking.md b/content/ko/docs/concepts/cluster-administration/networking.md index 63877bc535..9b378aed79 100644 --- a/content/ko/docs/concepts/cluster-administration/networking.md +++ b/content/ko/docs/concepts/cluster-administration/networking.md @@ -122,6 +122,10 @@ Azure CNI는 [Azure 쿠버네티스 서비스(Azure Kubernetes Service, AKS)](ht 가트너는 최신의 [매직 쿼드런트(Magic Quadrant)](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html)에서 BCF를 비저너리(Visionary)로 인정했다. BCF 쿠버네티스 온-프레미스 디플로이먼트 중 하나(지리적으로 다른 리전에 걸쳐 여러 DC에서 실행되는 쿠버네티스, DC/OS 및 VMware 포함)도 [여기](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/)에서 사례로 참조된다. +### 캘리코 + +[캘리코](https://docs.projectcalico.org/)는 컨테이너, 가상 시스템 및 기본 호스트 기반 워크로드를 위한 오픈소스 네트워킹 및 네트워크 보안 솔루션이다. 캘리코는 순수 리눅스 eBPF 데이터플레인, 표준 리눅스 네트워킹 데이터플레인, 윈도우 HNS 데이터플레인을 포함한 여러 데이터플레인을 지원한다. 캘리코는 완전한 네트워킹 스택을 제공하지만, [클라우드 제공자 CNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)와 함께 사용하여 네트워크 정책 시행을 제공할 수도 있다. + ### 실리움(Cilium) [실리움](https://github.com/cilium/cilium)은 애플리케이션 컨테이너 간에 @@ -289,14 +293,6 @@ OVN은 Open vSwitch 커뮤니티에서 개발한 오픈소스 네트워크 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)에 특정 쿠버네티스 플러그인 및 문서가 있다. -### 프로젝트 캘리코 - -[프로젝트 캘리코](https://docs.projectcalico.org/)는 오픈소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다. - -캘리코는 리눅스(오픈소스)와 윈도우(독점 - [Tigera](https://www.tigera.io/essentials/)에서 사용 가능) 모두에서 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 쿠버네티스 파드를 연결하기 위한 확장성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. 캘리코는 캡슐화나 오버레이 없이 구축되어 고성능의 대규모 데이터센터 네트워킹을 제공할 수 있다. 또한 캘리코는 분산 방화벽을 통해 쿠버네티스 파드에 대해 세분화된 의도기반의 네트워크 보안 정책을 제공한다. - -캘리코는 플라넬, 일명 [canal](https://github.com/tigera/canal) 또는 네이티브 GCE, AWS나 Azure 네트워킹과 같은 다른 네트워킹 솔루션과 함께 정책 적용 모드로 실행될 수도 있다. - ### 로마나 [로마나](https://romana.io)는 오버레이 네트워크 없이 쿠버네티스를 배포할 수 있는 오픈소스 네트워크 및 보안 자동화 솔루션이다. 로마나는 쿠버네티스 [네트워크 폴리시](/ko/docs/concepts/services-networking/network-policies/)를 지원하여 네트워크 네임스페이스에서 격리를 제공한다. diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index 440da51dd8..e4dedb068a 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -97,6 +97,14 @@ some_counter 0 릴리스 `1.12` 에서 `1.13` 으로 업그레이드 중이지만, `1.12` 에서 사용 중단된 메트릭 `A` 를 사용하고 있다면, 커맨드 라인에서 `--show-hidden-metrics=1.12` 플래그로 히든 메트릭을 설정해야 하고, `1.14` 로 업그레이드하기 전에 이 메트릭을 사용하지 않도록 의존성을 제거하는 것을 기억해야 한다. +## 액셀러레이터 메트릭 비활성화 + +kubelet은 cAdvisor를 통해 액셀러레이터 메트릭을 수집한다. NVIDIA GPU와 같은 액셀러레이터의 경우, 이러한 메트릭을 수집하기 위해 kubelet은 드라이버에 열린 핸들을 가진다. 이는 인프라 변경(예: 드라이버 업데이트)을 수행하기 위해 클러스터 관리자가 kubelet 에이전트를 중지해야 함을 의미한다. + +액셀러레이터 메트릭을 수집하는 책임은 이제 kubelet이 아닌 공급 업체에 있다. 공급 업체는 메트릭을 수집하여 메트릭 서비스(예: 프로메테우스)에 노출할 컨테이너를 제공해야 한다. + +[`DisableAcceleratorUsageMetrics` 기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/#알파-또는-베타-기능을-위한-기능-게이트:~:text= DisableAcceleratorUsageMetrics,-false)는 [이 기능을 기본적으로 사용하도록 설정하는 타임라인](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)를 사용하여 kubelet에서 수집한 메트릭을 비활성화한다. + ## 컴포넌트 메트릭 ### kube-controller-manager 메트릭 diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index a934d173d1..e75beb8666 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -12,51 +12,380 @@ weight: 30 쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은 민감한 정보를 저장하고 관리할 수 ​​있다. 기밀 정보를 시크릿에 저장하는 것이 -{{< glossary_tooltip term_id="pod" text="파드" >}} 정의나 -{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} 내에 그대로 두는 것보다 안전하고 유연하다. 자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. - +{{< glossary_tooltip term_id="pod" >}} 정의나 +{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}} +내에 그대로 두는 것보다 안전하고 유연하다. +자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다. +시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 +포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드 +명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도 +일부 시크릿을 만들 수 있다. ## 시크릿 개요 -시크릿은 비밀번호, 토큰 또는 키와 같은 소량의 -민감한 데이터를 포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 -파드 명세 또는 이미지에 포함될 수 있다. 사용자는 시크릿을 생성할 수 있으며 시스템도 -일부 시크릿을 생성한다. - 시크릿을 사용하려면, 파드가 시크릿을 참조해야 한다. 시크릿은 세 가지 방법으로 파드와 함께 사용할 수 있다. - 하나 이상의 컨테이너에 마운트된 -{{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의 -[파일](#시크릿을-파드의-파일로-사용하기)로써 사용. + {{< glossary_tooltip text="볼륨" term_id="volume" >}} 내의 + [파일](#시크릿을-파드의-파일로-사용하기)로써 사용. - [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용. - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용. 시크릿 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. +사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를 +명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다. +`data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다. +만약 사용자에게 base64로의 문자열 변환이 적합하지 않다면, +임의의 문자열을 값으로 받는 `stringData` 필드를 대신 사용할 수 있다. -`data` 와 `stringData` 의 키는 영숫자 및 `-`, `_` 또는 `.` 으로 -구성되어야 한다. +`data` 및 `stringData`의 키는 영숫자 문자, +`-`, `_`, 또는 `.` 으로 구성되어야 한다. `stringData` 필드의 모든 키-값 쌍은 의도적으로 +`data` 필드로 합쳐진다. 만약 키가 `data` 와 `stringData` 필드 모두에 정의되어 +있으면, `stringData` 필드에 지정된 값이 +우선적으로 사용된다. -### 빌트인 시크릿 +## 시크릿 타입 {#secret-types} -#### 서비스 어카운트는 API 자격 증명으로 시크릿을 자동으로 생성하고 연결함 +시크릿을 생성할 때, [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +리소스의 `type` 필드를 사용하거나, (활용 가능하다면) `kubectl` 의 +유사한 특정 커맨드라인 플래그를 사용하여 시크릿의 타입을 명시할 수 있다. +시크릿 타입은 시크릿 데이터의 프로그래믹 처리를 촉진시키기 위해 사용된다. -쿠버네티스는 API 접근을 위한 자격 증명이 포함된 -시크릿을 자동으로 생성하고 이러한 유형의 시크릿을 사용하도록 파드를 자동으로 -수정한다. +쿠버네티스는 일반적인 사용 시나리오를 위해 몇 가지 빌트인 타입을 제공한다. +이 타입은 쿠버네티스가 부과하여 수행되는 검증 및 제약에 +따라 달라진다. -원하는 경우 API 자격 증명의 자동 생성 및 사용을 비활성화하거나 -오버라이드할 수 있다. 그러나, API 서버에 안전하게 접근하기만 하면 되는 경우, -자동 생성 및 사용이 권장되는 워크플로이다. +| 빌트인 타입 | 사용처 | +|--------------|-------| +| `Opaque` | 임의의 사용자 정의 데이터 | +| `kubernetes.io/service-account-token` | 서비스 어카운트 토큰 | +| `kubernetes.io/dockercfg` | 직렬화 된(serialized) `~/.dockercfg` 파일 | +| `kubernetes.io/dockerconfigjson` | 직렬화 된 `~/.docker/config.json` 파일 | +| `kubernetes.io/basic-auth` | 기본 인증을 위한 자격 증명(credential) | +| `kubernetes.io/ssh-auth` | SSH를 위한 자격 증명 | +| `kubernetes.io/tls` | TLS 클라이언트나 서버를 위한 데이터 | +| `bootstrap.kubernetes.io/token` | 부트스트랩 토큰 데이터 | -서비스 어카운트 작동 방식에 대한 자세한 내용은 -[서비스어카운트(ServiceAccount)](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 참고한다. +사용자는 시크릿 오브젝트의 `type` 값에 비어 있지 않은 문자열을 할당하여 자신만의 시크릿 +타입을 정의하고 사용할 수 있다. 비어 있는 문자열은 `Opaque` 타입으로 인식된다. +쿠버네티스는 타입 명칭에 제약을 부과하지는 않는다. 그러나 만약 +빌트인 타입 중 하나를 사용한다면, 해당 타입에 정의된 모든 요구 사항을 +만족시켜야 한다. -### 시크릿 생성하기 +### 불투명(Opaque) 시크릿 + +`Opaque` 은 시크릿 구성 파일에서 누락된 경우의 기본 시크릿 타입이다. +`kubectl` 을 사용하여 시크릿을 생성할 때 `Opaque` 시크릿 타입을 나타내기 +위해서는 `generic` 하위 커맨드를 사용할 것이다. 예를 들어, 다음 커맨드는 +타입 `Opaque` 의 비어 있는 시크릿을 생성한다. + +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +출력은 다음과 같다. + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + +해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다. +이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다. + +### 서비스 어카운트 토큰 시크릿 + +`kubernetes.io/service-account-token` 시크릿 타입은 서비스 어카운트를 확인하는 토큰을 저장하기 위해서 사용한다. 이 시크릿 타입을 사용할 때는, +`kubernetes.io/service-account.name` 어노테이션이 존재하는 서비스 +어카운트 이름으로 설정되도록 해야 한다. 쿠버네티스 컨트롤러는 +`kubernetes.io/service-account.uid` 및 실제 토큰 +콘텐츠로 설정된 `data` 필드의 `token` 키와 같은, +몇 가지 다른 필드들을 채운다. + +다음은 서비스 어카운트 토큰 시크릿의 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-sa-sample + annotations: + kubernetes.io/service-account.name: "sa-name" +type: kubernetes.io/service-account-token +data: + # 사용자는 불투명 시크릿을 사용하므로 추가적인 키 값 쌍을 포함할 수 있다. + extra: YmFyCg== +``` + +`Pod` 를 생성할 때, 쿠버네티스는 자동으로 서비스 어카운트 시크릿을 +생성하고 자동으로 파드가 해당 시크릿을 사용하도록 수정한다. 해당 서비스 +어카운트 토큰 시크릿은 API 접속을 위한 자격 증명을 포함한다. + +이러한 API 자격 증명의 자동 생성과 사용은 원하는 경우 해제하거나 +기각할 수 있다. 그러나 만약 사용자가 API 서버에 안전하게 접근하는 것만 +필요하다면, 이것이 권장되는 워크플로우이다. + +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) 문서를 보면 +서비스 어카운트가 동작하는 방법에 대한 더 자세한 정보를 얻을 수 있다. +또한 파드에서 서비스 어카운트를 참조하는 방법을 +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)의 +`automountServiceAccountToken` 필드와 `serviceAccountName` +필드를 통해 확인할 수 있다. + +### 도커 컨피그 시크릿 + +이미지에 대한 도커 레지스트리 접속 자격 증명을 저장하기 위한 +시크릿을 생성하기 위해서 다음의 `type` 값 중 하나를 사용할 수 있다. + +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` + +`kubernetes.io/dockercfg` 는 직렬화 된 도커 커맨드라인 구성을 +위한 기존(legacy) 포맷 `~/.dockercfg` 를 저장하기 위해 할당된 타입이다. +시크릿 타입을 사용할 때는, `data` 필드가 base64 포맷으로 +인코딩된 `~/.dockercfg` 파일의 콘텐츠를 값으로 가지는 `.dockercfg` 키를 포함하고 있는지 +확실히 확인해야 한다. + +`kubernetes/dockerconfigjson` 타입은 `~/.dockercfg` 의 +새로운 포맷인 `~/.docker/config.json` 파일과 동일한 포맷 법칙을 +따르는 직렬화 된 JSON의 저장을 위해 디자인되었다. +이 시크릿 타입을 사용할 때는, 시크릿 오브젝트의 `data` 필드가 `.dockerconfigjson` 키를 +꼭 포함해야 한다. `~/.docker/config.json` 파일을 위한 콘텐츠는 +base64로 인코딩된 문자열으로 제공되어야 한다. + +아래는 시크릿의 `kubernetes.io/dockercfg` 타입 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-dockercfg +type: kubernetes.io/dockercfg +data: + .dockercfg: | + "" +``` + +{{< note >}} +만약 base64 인코딩 수행을 원하지 않는다면, 그 대신 `stringData` 필드의 +사용을 선택할 수 있다. +{{< /note >}} + +이러한 타입들을 매니페스트를 사용하여 생성하는 경우, API +서버는 해당 `data` 필드에 기대하는 키가 존재하는지 확인하고, +제공된 값이 유효한 JSON으로 파싱될 수 있는지 검증한다. API +서버가 해당 JSON이 실제 도커 컨피그 파일인지를 검증하지는 않는다. + +도커 컨피그 파일을 가지고 있지 않거나 도커 레지스트리 시크릿을 생성하기 +위해 `kubectl` 을 사용하고 싶은 경우, 다음과 같이 처리할 수 있다. + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com +``` + +이 커맨드는 `kubernetes.io/dockerconfigjson` 타입의 시크릿을 생성한다. +만약 `data` 필드로부터 `.dockerconfigjson` 콘텐츠를 복사(dump)해오면, +다음과 같이 유효한 도커 JSON 콘텐츠를 +즉석에서 얻게 될 것이다. + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "username": "tiger", + "password": "pass113", + "email": "tiger@acme.com", + "auth": "dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### 기본 인증 시크릿 + +`kubernetes.io/basic-auth` 타입은 기본 인증을 위한 자격 증명을 저장하기 +위해 제공된다. 이 시크릿 타입을 사용할 때는 시크릿의 `data` 필드가 +다음의 두 키를 포함해야 한다. + +- `username`: 인증을 위한 사용자 이름 +- `password`: 인증을 위한 암호나 토큰 + +위의 두 키에 대한 두 값은 모두 base64로 인코딩된 문자열이다. 물론, +시크릿 생성 시 `stringData` 를 사용하여 평문 텍스트 콘텐츠(clear text content)를 제공할 +수도 있다. + +다음의 YAML은 기본 인증 시크릿을 위한 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: admin + password: t0p-Secret +``` + +이 기본 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다. +사용자는 기본 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. +그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 +검증도 한다. + +### SSH 인증 시크릿 + +이 빌트인 타입 `kubernetes.io/ssh-auth` 는 SSH 인증에 사용되는 데이터를 +저장하기 위해서 제공된다. 이 시크릿 타입을 사용할 때는 `ssh-privatekey` +키-값 쌍을 사용할 SSH 자격 증명으로 `data` (또는 `stringData`) +필드에 명시해야 할 것이다. + +다음 YAML은 SSH 인증 시크릿의 구성 예시이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # 본 예시를 위해 축약된 데이터임 + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + +SSH 인증 시크릿 타입은 사용자 편의만을 위해서 제공된다. +사용자는 SSH 인증에서 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. +그러나, 빌트인 시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 +검증도 한다. + +### TLS 시크릿 + +쿠버네티스는 보통 TLS를 위해 사용되는 인증서와 관련된 키를 저장하기 위해서 +빌트인 시크릿 타입 `kubernetes.io/tls` 를 제공한다. +이 데이터는 인그레스 리소스의 TLS 종료에 주로 사용되지만, 다른 +리소스나 워크로드에 의해 직접적으로 사용될 수도 있다. +이 타입의 시크릿을 사용할 때는 `tls.key` 와 `tls.crt` 키가 시크릿 구성의 +`data` (또는 `stringData`) 필드에서 제공되어야 한다. 그러나, API +서버가 각 키에 대한 값이 유효한지 실제로 검증하지는 않는다. + +다음 YAML은 TLS 시크릿을 위한 구성 예시를 포함한다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # 본 예시를 위해 축약된 데이터임 + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + +TLS 시크릿 타입은 사용자 편의만을 위해서 제공된다. 사용자는 TLS 서버 및/또는 +클라이언트를 위해 사용되는 자격 증명을 위한 `Opaque` 를 생성할 수도 있다. 그러나, 빌트인 +시크릿 타입을 사용하는 것은 사용자의 자격 증명들의 포맷을 통합하는 데 도움이 되고, +API 서버는 요구되는 키가 시크릿 구성에서 제공되고 있는지 검증도 한다. + +`kubectl` 를 사용하여 TLS 시크릿을 생성할 때, `tls` 하위 커맨드를 +다음 예시와 같이 사용할 수 있다. + +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + +공개/개인 키 쌍은 사전에 존재해야 한다. `--cert` 를 위한 공개 키 인증서는 +.PEM 으로 인코딩(Base64로 인코딩된 DER 포맷)되어야 하며, `--key` 를 위해 주어진 +개인 키에 맞아야 한다. +개인 키는 일반적으로 PEM 개인 키 포맷이라고 하는, +암호화되지 않은 형태(unencrypted)이어야 한다. 두 가지 방식 모두에 대해서, PEM의 +시작과 끝 라인(예를 들면, 인증서의 `--------BEGIN CERTIFICATE-----` 및 `-------END CERTIFICATE----`) +은 포함되면 *안* 된다. + +### 부트스트랩 토큰 시크릿 + +부트스트랩 토큰 시크릿은 시크릿 `type` 을 `bootstrap.kubernetes.io/token` 으로 +명확하게 지정하면 생성할 수 있다. 이 타입의 시크릿은 노드 부트스트랩 과정 중에 사용되는 +토큰을 위해 디자인되었다. 이것은 잘 알려진 컨피그맵에 서명하는 데 사용되는 +토큰을 저장한다. + +부트스트랩 토큰 시크릿은 보통 `kube-system` 네임스페이스에 생성되며 +`` 가 해당 토큰 ID의 6개 문자의 문자열으로 구성된 `bootstrap-token-` 형태로 +이름이 지정된다. + +쿠버네티스 매니페스트로서, 부트스트렙 토큰 시크릿은 다음과 유사할 +것이다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token +data: + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== +``` + +부트스트랩 타입은 `data` 아래 명시된 다음의 키들을 가진다. + +- `token_id`: 토큰 식별자로 임의의 6개 문자의 문자열. 필수 사항. +- `token-secret`: 실제 토큰 시크릿으로 임의의 16개 문자의 문자열. 필수 사항. +- `description1`: 토큰의 사용처를 설명하는 사람이 읽을 수 있는 + 문자열. 선택 사항. +- `expiration`: 토큰이 만료되어야 하는 시기를 명시한 RFC3339를 + 사용하는 절대 UTC 시간. 선택 사항. +- `usage-bootstrap-`: 부트스트랩 토큰의 추가적인 사용처를 나타내는 + 불리언(boolean) 플래그. +- `auth-extra-groups`: system:bootstrappers 그룹에 추가로 인증될 + 쉼표로 구분된 그룹 이름 목록. + +위의 YAML은 모두 base64로 인코딩된 문자열 값이므로 혼란스러워 보일 +수 있다. 사실은 다음 YAML을 사용하여 동일한 시크릿 오브젝트 결과를 만드는 +동일한 시크릿을 생성할 수 있다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + # 시크릿 이름이 어떻게 지정되었는지 확인 + name: bootstrap-token-5emitj + # 부트스트랩 토큰 시크릿은 일반적으로 kube-system 네임스페이스에 포함 + namespace: kube-system +type: bootstrap.kubernetes.io/token +stringData: + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # 이 토큰 ID는 이름에 사용됨 + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # 이 토큰은 인증을 위해서 사용될 수 있음 + usage-bootstrap-authentication: "true" + # 또한 서명(signing)에도 사용될 수 있음 + usage-bootstrap-signing: "true" +``` + +## 시크릿 생성하기 시크릿을 생성하기 위한 몇 가지 옵션이 있다. @@ -64,7 +393,7 @@ weight: 30 - [구성 파일로 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - [kustomize를 사용하여 시크릿 생성하기](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -### 시크릿 편집하기 +## 시크릿 편집하기 기존 시크릿은 다음 명령을 사용하여 편집할 수 있다. @@ -791,11 +1120,11 @@ spec: HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, HMAC이 있는 일부 메시지에 서명해야 하는 프로그램을 고려한다. 애플리케이션 로직이 복잡하기 때문에, 서버에서 눈에 띄지 않는 원격 파일 읽기 공격이 -있을 수 있으며, 이로 인해 프라이빗 키가 공격자에게 노출될 수 있다. +있을 수 있으며, 이로 인해 개인 키가 공격자에게 노출될 수 있다. 이는 두 개의 컨테이너의 두 개 프로세스로 나눌 수 있다. 사용자 상호 작용과 -비즈니스 로직을 처리하지만, 프라이빗 키를 볼 수 없는 프론트엔드 컨테이너와 -프라이빗 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에 +비즈니스 로직을 처리하지만, 개인 키를 볼 수 없는 프론트엔드 컨테이너와 +개인 키를 볼 수 있고, 프론트엔드의 간단한 서명 요청(예를 들어, localhost 네트워킹을 통해)에 응답하는 서명자 컨테이너로 나눌 수 있다. 이 분할된 접근 방식을 사용하면, 공격자는 이제 애플리케이션 서버를 속여서 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 497f4cbfda..2f1ae4a27c 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -61,9 +61,9 @@ weight: 10 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. -## 매니페스트가 있는 다중 아키텍처 이미지 +## 이미지 인덱스가 있는 다중 아키텍처 이미지 -바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 컨테이너 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 제공할 수도 있다. 매니페스트는 아키텍처별 버전의 컨테이너에 대한 이미지 매니페스트를 참조할 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. +바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. 쿠버네티스 자체는 일반적으로 `-$(ARCH)` 접미사로 컨테이너 이미지의 이름을 지정한다. 이전 버전과의 호환성을 위해, 접미사가 있는 오래된 이미지를 생성한다. 아이디어는 모든 아키텍처에 대한 매니페스트가 있는 `pause` 이미지와 이전 구성 또는 이전에 접미사로 이미지를 하드 코딩한 YAML 파일과 호환되는 `pause-amd64` 라고 하는 이미지를 생성한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index ec09e00446..81cc38337f 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -126,7 +126,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. 이러한 각 단계는 익스텐션 포인트를 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f4301e2933..68e529549b 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -13,7 +13,7 @@ weight: 10 ## 커스텀 리소스 -*리소스* 는 [쿠버네티스 API](/ko/docs/reference/using-api/api-overview/)에서 특정 종류의 +*리소스* 는 [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에서 특정 종류의 [API 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/) 모음을 저장하는 엔드포인트이다. 예를 들어 빌트인 *파드* 리소스에는 파드 오브젝트 모음이 포함되어 있다. *커스텀 리소스* 는 쿠버네티스 API의 익스텐션으로, 기본 쿠버네티스 설치에서 반드시 diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md index 3fe6451755..9775299a3c 100644 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md @@ -127,7 +127,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### API 접근 익스텐션 -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/reference/access-authn-authz/controlling-access/)를 참고하길 바란다. +요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. 이러한 각 단계는 익스텐션 포인트를 제공한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md index 6e27220d68..3ac6a2df7d 100644 --- a/content/ko/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/ko/docs/concepts/extend-kubernetes/service-catalog.md @@ -227,7 +227,7 @@ spec: * 만약 당신이 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}에 익숙하다면, 당신의 쿠버네티스 클러스터에 [Helm을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-helm/)할 수 있다. 다른 방법으로 [SC tool을 이용하여 서비스 카탈로그를 설치](/docs/tasks/service-catalog/install-service-catalog-using-sc/)할 수 있다. * [샘플 서비스 브로커](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) 살펴보기 -* [kubernetes-incubator/service-catalog](https://github.com/kubernetes-incubator/service-catalog) 프로젝트 탐색 +* [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 프로젝트 탐색 * [svc-cat.io](https://svc-cat.io/docs/) 살펴보기 diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 65662da9d0..89871bd83a 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -22,7 +22,7 @@ card: 대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 -[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)과 +[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다. @@ -101,8 +101,20 @@ API가 시스템 리소스 및 동작에 대한 명확하고 일관된 보기를 제어할 수 있도록 한다. 보다 쉽게 발전하고 API를 확장하기 위해, 쿠버네티스는 -[활성화 또는 비활성화](/ko/docs/reference/using-api/api-overview/#api-그룹-활성화-또는-비활성화-하기)가 -가능한 [API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 구현한다. +[활성화 또는 비활성화](/ko/docs/reference/using-api/#api-그룹-활성화-또는-비활성화)가 +가능한 [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 구현한다. + +API 리소스는 API 그룹, 리소스 유형, 네임스페이스 +(네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 +여러 API 버전을 통해 동일한 기본 데이터를 제공하고 API 버전 간의 +변환을 투명하게 처리할 수 있다. 이 모든 다른 버전은 실제로 +같은 리소스의 표현이다. 예를 들어 동일한 리소스에 대해 +두 가지 버전 `v1`과 `v1beta1`이 있다고 가정해 보자. +`v1beta1` 버전에서 생성된 오브젝트를 `v1beta1` 또는 `v1` 버전에서 +읽기, 업데이트 및 삭제할 수 있다. + +API 버전 수준 정의에 대한 자세한 내용은 +[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다. API 리소스는 해당 API 그룹, 리소스 유형, 네임스페이스 (네임스페이스 리소스용) 및 이름으로 구분된다. API 서버는 여러 API 버전을 통해 동일한 @@ -129,7 +141,7 @@ API 버전 수준 정의에 대한 자세한 내용은 - 자체 [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)을 추가하여 쿠버네티스 API를 확장하는 방법에 대해 배우기. -- [API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)는 +- [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)는 클러스터가 API 접근을 위한 인증 및 권한을 관리하는 방법을 설명한다. - [API 레퍼런스](/docs/reference/kubernetes-api/)를 읽고 API 엔드포인트, 리소스 유형 및 샘플에 대해 배우기. diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 7d6c8c1f0e..449cae4393 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -35,7 +35,7 @@ sitemap: 각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다. -**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. +**컨테이너 개발 시대:** 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다. 컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다. 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 c43acf468c..6bfdda943f 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 @@ -91,6 +91,7 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} -* API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. + * [파드](/ko/docs/concepts/workloads/pods/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. +* API 개념의 더 많은 설명은 [쿠버네티스 API 사용](/ko/docs/reference/using-api/)을 본다. 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 a6f03a907f..631f0347d4 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -185,7 +185,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' [`services`](/ko/docs/concepts/services-networking/service/) 와 [`replicationcontrollers`](/ko/docs/concepts/workloads/controllers/replicationcontroller/)와 같은 일부 쿠버네티스 오브젝트는 레이블 셀렉터를 사용해서 -[파드](/ko/docs/concepts/workloads/pods/pod/)와 같은 다른 리소스 집합을 선택한다. +[파드](/ko/docs/concepts/workloads/pods/)와 같은 다른 리소스 집합을 선택한다. #### 서비스와 레플리케이션 컨트롤러 diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index c1e7bc56a9..93f2093952 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -138,12 +138,16 @@ RBAC 바인딩에 대한 자세한 예는, ### 문제 해결 - [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는 -[보안 API 포트](/ko/docs/reference/access-authn-authz/controlling-access/)에 대해 실행해야 하며, -슈퍼유저 권한이 없어야 한다. 그렇지 않으면 요청이 인증 및 권한 부여 모듈을 우회하고, -모든 파드시큐리티폴리시 오브젝트가 허용되며 -사용자는 특권있는 컨테이너를 만들 수 있다. 컨트롤러 관리자 권한 구성에 대한 자세한 -내용은 [컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 -참고하길 바란다. +보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다. +API 서버 접근 제어에 대한 자세한 내용은 +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다. +컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를 +통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고, +모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를 +만들 수 있는 권한을 부여할 수 있다. + +컨트롤러 관리자 권한 구성에 대한 자세한 내용은 +[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고하기 바란다. ## 정책 순서 diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 028209a07e..ffda9f5eda 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -15,7 +15,7 @@ weight: 10 `ResourceQuota` 오브젝트로 정의된 리소스 쿼터는 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공한다. 유형별로 네임스페이스에서 만들 수 있는 오브젝트 수와 -해당 프로젝트의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 +해당 네임스페이스의 리소스가 사용할 수 있는 총 컴퓨트 리소스의 양을 제한할 수 있다. 리소스 쿼터는 다음과 같이 작동한다. @@ -23,10 +23,10 @@ weight: 10 - 다른 팀은 다른 네임스페이스에서 작동한다. 현재 이것은 자발적이지만 ACL을 통해 이 필수 사항을 적용하기 위한 지원이 계획되어 있다. -- 관리자는 각 네임스페이스에 대해 하나의 `ResourceQuota`를 생성한다. +- 관리자는 각 네임스페이스에 대해 하나의 리소스쿼터를 생성한다. - 사용자는 네임스페이스에서 리소스(파드, 서비스 등)를 생성하고 쿼터 시스템은 - 사용량을 추적하여 `ResourceQuota`에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. + 사용량을 추적하여 리소스쿼터에 정의된 하드(hard) 리소스 제한을 초과하지 않도록 한다. - 리소스를 생성하거나 업데이트할 때 쿼터 제약 조건을 위반하면 위반된 제약 조건을 설명하는 메시지와 함께 HTTP 상태 코드 `403 FORBIDDEN`으로 요청이 실패한다. @@ -38,7 +38,7 @@ weight: 10 이 문제를 회피하는 방법에 대한 예제는 [연습](/ko/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)을 참고하길 바란다. -`ResourceQuota` 오브젝트의 이름은 유효한 +리소스쿼터 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다. 네임스페이스와 쿼터를 사용하여 만들 수 있는 정책의 예는 다음과 같다. @@ -59,7 +59,7 @@ weight: 10 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. -해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 +해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. ## 컴퓨트 리소스 쿼터 @@ -70,10 +70,14 @@ API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 | 리소스 이름 | 설명 | | --------------------- | ----------------------------------------------------------- | -| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음 | -| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음 | -| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음 | -| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음 | +| `limits.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 제한의 합은 이 값을 초과할 수 없음. | +| `limits.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 제한의 합은 이 값을 초과할 수 없음. | +| `requests.cpu` | 터미널이 아닌 상태의 모든 파드에서 CPU 요청의 합은 이 값을 초과할 수 없음. | +| `requests.memory` | 터미널이 아닌 상태의 모든 파드에서 메모리 요청의 합은 이 값을 초과할 수 없음. | +| `hugepages-` | 터미널 상태가 아닌 모든 파드에 걸쳐서, 지정된 사이즈의 +휴즈 페이지 요청은 이 값을 초과하지 못함. | +| `cpu` | `requests.cpu` 와 같음. | +| `memory` | `requests.memory` 와 같음. | ### 확장된 리소스에 대한 리소스 쿼터 @@ -103,7 +107,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `requests.storage` | 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | | `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | | `.storageclass.storage.k8s.io/requests.storage` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 스토리지 요청의 합은 이 값을 초과할 수 없음 | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | storage-class-name과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | `` 과 관련된 모든 퍼시스턴트 볼륨 클레임에서 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | 예를 들어, 운영자가 `bronze` 스토리지 클래스와 별도로 `gold` 스토리지 클래스를 사용하여 스토리지에 쿼터를 지정하려는 경우 운영자는 다음과 같이 쿼터를 정의할 수 있다. @@ -115,14 +119,17 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | 리소스 이름 | 설명 | | ------------------------------- |----------------------------------------------------------- | -| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음 | -| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음 | +| `requests.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 요청의 합은 이 값을 초과할 수 없음. | +| `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. | +| `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. | ## 오브젝트 수 쿼터 -1.9 릴리스는 다음 구문을 사용하여 모든 표준 네임스페이스 리소스 유형에 쿼터를 지정하는 지원을 추가했다. +다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한 +특정 리소스 전체 수에 대하여 쿼터를 지정할 수 있다. -* `count/.` +* 코어 그룹이 아닌(non-core) 리소스를 위한 `count/.` +* 코어 그룹의 리소스를 위한 `count/` 다음은 사용자가 오브젝트 수 쿼터 아래에 배치하려는 리소스 셋의 예이다. @@ -136,32 +143,29 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. * `count/statefulsets.apps` * `count/jobs.batch` * `count/cronjobs.batch` -* `count/deployments.extensions` -1.15 릴리스는 동일한 구문을 사용하여 사용자 정의 리소스에 대한 지원을 추가했다. +사용자 정의 리소스를 위해 동일한 구문을 사용할 수 있다. 예를 들어 `example.com` API 그룹에서 `widgets` 사용자 정의 리소스에 대한 쿼터를 생성하려면 `count/widgets.example.com`을 사용한다. `count/*` 리소스 쿼터를 사용할 때 서버 스토리지 영역에 있다면 오브젝트는 쿼터에 대해 과금된다. 이러한 유형의 쿼터는 스토리지 리소스 고갈을 방지하는 데 유용하다. 예를 들어, 크기가 큰 서버에서 시크릿 수에 쿼터를 지정할 수 있다. 클러스터에 시크릿이 너무 많으면 실제로 서버와 -컨트롤러가 시작되지 않을 수 있다! 네임스페이스에 너무 많은 작업을 생성하는 -잘못 구성된 크론 잡으로 인해 서비스 거부를 유발하는 것으로부터 보호하기 위해 작업의 쿼터를 지정하도록 선택할 수 있다. - -1.9 릴리스 이전에는 제한된 리소스 셋에서 일반 오브젝트 수 쿼터를 적용할 수 있었다. -또한, 특정 리소스에 대한 쿼터를 유형별로 추가로 제한할 수 있다. +컨트롤러가 시작되지 않을 수 있다. 잘못 구성된 크론 잡으로부터의 보호를 위해 +잡의 쿼터를 설정할 수 있다. 네임스페이스 내에서 너무 많은 잡을 생성하는 크론 잡은 서비스 거부를 유발할 수 있다. +또한 제한된 리소스 셋에 대해서 일반 오브젝트 수(generic object count) 쿼터를 적용하는 것도 가능하다. 다음 유형이 지원된다. | 리소스 이름 | 설명 | | ------------------------------- | ------------------------------------------------- | -| `configmaps` | 네임스페이스에 존재할 수 있는 총 구성 맵 수 | +| `configmaps` | 네임스페이스에 존재할 수 있는 총 컨피그맵 수 | | `persistentvolumeclaims` | 네임스페이스에 존재할 수 있는 총 [퍼시스턴트 볼륨 클레임](/ko/docs/concepts/storage/persistent-volumes/#퍼시스턴트볼륨클레임) 수 | | `pods` | 네임스페이스에 존재할 수 있는 터미널이 아닌 상태의 파드의 총 수. `.status.phase in (Failed, Succeeded)`가 true인 경우 파드는 터미널 상태임 | -| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션 컨트롤러 수 | -| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 [리소스 쿼터](/docs/reference/access-authn-authz/admission-controllers/#resourcequota) 수 | +| `replicationcontrollers` | 네임스페이스에 존재할 수 있는 총 레플리케이션컨트롤러 수 | +| `resourcequotas` | 네임스페이스에 존재할 수 있는 총 리소스쿼터 수 | | `services` | 네임스페이스에 존재할 수 있는 총 서비스 수 | -| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 로드 밸런서 유형의 총 서비스 수 | -| `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | +| `services.loadbalancers` | 네임스페이스에 존재할 수 있는 `LoadBalancer` 유형의 총 서비스 수 | +| `services.nodeports` | 네임스페이스에 존재할 수 있는 `NodePort` 유형의 총 서비스 수 | | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | 예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 @@ -171,7 +175,7 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. ## 쿼터 범위 -각 쿼터에는 연결된 범위 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 +각 쿼터에는 연결된 `scopes` 셋이 있을 수 있다. 쿼터는 열거된 범위의 교차 부분과 일치하는 경우에만 리소스 사용량을 측정한다. 범위가 쿼터에 추가되면 해당 범위와 관련된 리소스를 지원하는 리소스 수가 제한된다. @@ -183,22 +187,60 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 | | `BestEffort` | 최상의 서비스 품질을 제공하는 파드 | | `NotBestEffort` | 서비스 품질이 나쁜 파드 | +| `PriorityClass` | 지정된 [프라이올리티 클래스](/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. | -`BestEffort` 범위는 다음의 리소스(파드)를 추적하도록 쿼터를 제한한다. +`BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다. -`Terminating`, `NotTerminating` 및 `NotBestEffort` 범위는 쿼터를 제한하여 다음의 리소스를 추적한다. - -* `cpu` -* `limits.cpu` -* `limits.memory` -* `memory` * `pods` + +`Terminating`, `NotTerminating`, `NotBestEffort` 및 `PriorityClass` +범위는 쿼터를 제한하여 다음의 리소스를 추적한다. + +* `pods` +* `cpu` +* `memory` * `requests.cpu` * `requests.memory` +* `limits.cpu` +* `limits.memory` + +`Terminating` 과 `NotTerminating` 범위를 동일한 쿼터 내에 모두 +명시하지는 못하며, 마찬가지로 `BestEffort` 와 +`NotBestEffort` 범위도 동일한 쿼터 내에서 모두 명시하지는 못한다. + +`scopeSelector` 는 `operator` 필드에 다음의 값을 지원한다. + +* `In` +* `NotIn` +* `Exists` +* `DoesNotExist` + +`scopeSelector` 를 정의할 때, `scopeName` 으로 다음의 값 중 하나를 사용하는 +경우, `operator` 는 `Exists` 이어야 한다. + +* `Terminating` +* `NotTerminating` +* `BestEffort` +* `NotBestEffort` + +만약 `operator` 가 `In` 또는 `NotIn` 인 경우, `values` 필드는 적어도 하나의 값은 +가져야 한다. 예를 들면 다음과 같다. + +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: + - middle +``` + +만약 `operator` 가 `Exists` 또는 `DoesNotExist` 이라면, `values` 필드는 명시되면 +*안된다*. ### PriorityClass별 리소스 쿼터 -{{< feature-state for_k8s_version="v1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} 특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 @@ -281,7 +323,7 @@ items: kubectl create -f ./quota.yml ``` -```shell +``` resourcequota/pods-high created resourcequota/pods-medium created resourcequota/pods-low created @@ -293,7 +335,7 @@ resourcequota/pods-low created kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -358,7 +400,7 @@ kubectl create -f ./high-priority-pod.yml kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -386,13 +428,6 @@ memory 0 20Gi pods 0 10 ``` -`scopeSelector`는 `operator` 필드에서 다음 값을 지원한다. - -* `In` -* `NotIn` -* `Exist` -* `DoesNotExist` - ## 요청과 제한의 비교 {#requests-vs-limits} 컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다. @@ -456,7 +491,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -```shell +``` NAME AGE compute-resources 30s object-counts 32s @@ -466,7 +501,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -```shell +``` Name: compute-resources Namespace: myspace Resource Used Hard @@ -482,7 +517,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -```shell +``` Name: object-counts Namespace: myspace Resource Used Hard @@ -504,7 +539,7 @@ kubectl create namespace myspace ``` ```shell -kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace ``` ```shell @@ -515,29 +550,29 @@ kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2 kubectl describe quota --namespace=myspace ``` -```shell +``` Name: test Namespace: myspace Resource Used Hard -------- ---- ---- -count/deployments.extensions 1 2 +count/deployments.apps 1 2 count/pods 2 3 -count/replicasets.extensions 1 4 +count/replicasets.apps 1 4 count/secrets 1 4 ``` ## 쿼터 및 클러스터 용량 -`ResourceQuotas`는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. +리소스쿼터는 클러스터 용량과 무관하다. 그것들은 절대 단위로 표현된다. 따라서 클러스터에 노드를 추가해도 각 네임스페이스에 더 많은 리소스를 사용할 수 있는 기능이 자동으로 부여되지는 *않는다*. 가끔 다음과 같은 보다 복잡한 정책이 필요할 수 있다. - - 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다. - - 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 - 막기 위한 충분한 제한이 있다. - - 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다. +- 여러 팀으로 전체 클러스터 리소스를 비례적으로 나눈다. +- 각 테넌트가 필요에 따라 리소스 사용량을 늘릴 수 있지만, 실수로 리소스가 고갈되는 것을 + 막기 위한 충분한 제한이 있다. +- 하나의 네임스페이스에서 요구를 감지하고 노드를 추가하며 쿼터를 늘린다. 이러한 정책은 쿼터 사용을 감시하고 다른 신호에 따라 각 네임스페이스의 쿼터 하드 제한을 조정하는 "컨트롤러"를 작성하여 `ResourceQuotas`를 구성 요소로 @@ -548,14 +583,16 @@ count/secrets 1 4 ## 기본적으로 우선 순위 클래스 소비 제한 -파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 경우에만 "cluster-services"가 네임스페이스에 허용되어야 힌다. +파드가 특정 우선 순위, 예를 들어 일치하는 쿼터 오브젝트가 존재하는 +경우에만 "cluster-services"가 네임스페이스에 허용되어야 한다. -이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다. +이 메커니즘을 통해 운영자는 특정 우선 순위가 높은 클래스의 사용을 +제한된 수의 네임스페이스로 제한할 수 있으며 모든 네임스페이스가 +기본적으로 이러한 우선 순위 클래스를 사용할 수 있는 것은 아니다. -이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file`을 사용하여 다음 구성 파일의 경로를 전달해야 한다. +이를 적용하려면 kube-apiserver 플래그 `--admission-control-config-file` 을 +사용하여 다음 구성 파일의 경로를 전달해야 한다. -{{< tabs name="example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -571,30 +608,10 @@ plugins: operator: In values: ["cluster-services"] ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: "ResourceQuota" - configuration: - # Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1, ResourceQuotaConfiguration - apiVersion: resourcequota.admission.k8s.io/v1beta1 - kind: Configuration - limitedResources: - - resource: pods - matchScopes: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] -``` -{{% /tab %}} -{{< /tabs >}} 이제 "cluster-services" 파드는 `scopeSelector`와 일치하는 쿼터 오브젝트가 있는 네임스페이스에서만 허용된다. 예를 들면 다음과 같다. + ```yaml scopeSelector: matchExpressions: @@ -603,12 +620,9 @@ plugins: values: ["cluster-services"] ``` -자세한 내용은 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)와 [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 참고하길 바란다. - -## 예제 - -[리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고하길 바란다. - ## {{% heading "whatsnext" %}} -- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. +- 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고한다. +- [리소스 쿼터를 사용하는 방법에 대한 자세한 예](/docs/tasks/administer-cluster/quota-api-object/)를 참고한다. +- [우선 순위 클래스에 대한 쿼터 지원 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)를 읽는다. +- [제한된 자원](https://github.com/kubernetes/kubernetes/pull/36765)을 참고한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index a3bf6a5a25..6bbe7a6767 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -78,7 +78,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 방법이 있다. 1. [스케줄링 정책](/docs/reference/scheduling/config/#profiles)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. -1. [스케줄링 프로파일](/docs/reference/scheduling/profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. +1. [스케줄링 프로파일](/docs/reference/scheduling/config/#profiles)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. ## {{% heading "whatsnext" %}} @@ -88,8 +88,8 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 -* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 -* 볼륨을 사용하느 파드의 스케줄링에 대해 배우기 +* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 +* 볼륨을 사용하는 파드의 스케줄링에 대해 배우기 * [볼륨 토폴리지 지원](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드) * [스토리지 용량 추적](/docs/concepts/storage/storage-capacity/) * [노드별 볼륨 한도](/ko/docs/concepts/storage/storage-limits/) diff --git a/content/ko/docs/reference/access-authn-authz/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md similarity index 100% rename from content/ko/docs/reference/access-authn-authz/controlling-access.md rename to content/ko/docs/concepts/security/controlling-access.md diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index af5c9ba574..86240a4116 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -102,7 +102,7 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋 워크로드 보안에서 고려할 영역 | 추천 | ------------------------------ | ------------ | RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ -인증 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ +인증 | https://kubernetes.io/ko/docs/concepts/security/controlling-access/ 애플리케이션 시크릿 관리(및 유휴 상태에서의 etcd 암호화 등) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ 파드 보안 정책 | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ 서비스 품질(및 클러스터 리소스 관리) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ @@ -146,8 +146,8 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 * [파드 보안 표준](/docs/concepts/security/pod-security-standards/) * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) +* [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access) * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) -* [API 접근 통제](/ko/docs/reference/access-authn-authz/controlling-access/) * 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/) diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 844ff7bd2b..4206a2d9d4 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -94,7 +94,7 @@ IPv6가 활성화된 외부 로드 밸런서를 지원하는 클라우드 공급 ## 이그레스 트래픽 -근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent) 는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent 를 사용할 수 있다. +근본적으로 {{< glossary_tooltip text="CNI" term_id="cni" >}} 공급자가 전송을 구현할 수 있는 경우 공개적으로 라우팅 하거나 비공개 라우팅만 가능한 IPv6 주소 블록의 사용은 허용된다. 만약 비공개 라우팅만 가능한 IPv6를 사용하는 파드가 있고, 해당 파드가 오프 클러스터 목적지(예: 공용 인터넷)에 도달하기를 원하는 경우에는 이그레스 트래픽과 모든 응답을 위한 마스커레이딩 IP를 설정해야 한다. [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)는 이중 스택을 인식하기에, 이중 스택 클러스터에서 마스커레이딩 IP에 ip-masq-agent를 사용할 수 있다. ## 알려진 이슈들 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index c4d18ada98..5b91356437 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -411,6 +411,13 @@ type: kubernetes.io/tls TLS 시크릿이 `https-example.foo.com` 의 정규화 된 도메인 이름(FQDN)이라고 하는 일반 이름(CN)을 포함하는 인증서에서 온 것인지 확인해야 한다. +{{< note >}} +가능한 모든 하위 도메인에 대해 인증서가 발급되어야 하기 때문에 +TLS는 기본 규칙에서 작동하지 않는다. 따라서 +`tls` 섹션의 `hosts`는 `rules`섹션의 `host`와 명시적으로 일치해야 +한다. +{{< /note >}} + {{< codenew file="service/networking/tls-example-ingress.yaml" >}} {{< note >}} diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 4cf129a3e6..a74dd45de6 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -177,27 +177,29 @@ spec: 퍼시스턴트볼륨이 존재하고 `claimRef` 필드를 통해 퍼시스턴트볼륨클레임을 예약하지 않은 경우, 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이 바인딩된다. 바인딩은 노드 선호도(affinity)를 포함하여 일부 볼륨 일치(matching) 기준과 관계없이 발생한다. -컨트롤 플레인은 여전히 [스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다. +컨트롤 플레인은 여전히 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/), 접근 모드 및 요청된 스토리지 크기가 유효한지 확인한다. -``` +```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: + storageClassName: "" # 빈 문자열은 명시적으로 설정해야 하며 그렇지 않으면 기본 스토리지클래스가 설정됨 volumeName: foo-pv ... ``` 이 메서드는 퍼시스턴트볼륨에 대한 바인딩 권한을 보장하지 않는다. 다른 퍼시스턴트볼륨클레임에서 지정한 PV를 사용할 수 있는 경우, 먼저 해당 스토리지 볼륨을 예약해야 한다. PV의 `claimRef` 필드에 관련 퍼시스턴트볼륨클레임을 지정하여 다른 PVC가 바인딩할 수 없도록 한다. -``` +```yaml apiVersion: v1 kind: PersistentVolume metadata: name: foo-pv spec: + storageClassName: "" claimRef: name: foo-pvc namespace: foo diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 38d59b6fb0..7526aff98d 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -89,7 +89,7 @@ volumeBindingMode: Immediate 등에 대한 완전한 재량권을 가진다. [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner) 리포지터리에는 대량의 사양을 구현하는 외부 프로비저너를 작성하기 위한 라이브러리가 있다. 일부 외부 프로비저너의 목록은 -[kubernetes-incubator/external-storage](https://github.com/kubernetes-incubator/external-storage) 리포지터리에 있다. +[kubernetes-sigs/external-storage](https://github.com/kubernetes-sigs/external-dns) 리포지터리에 있다. 예를 들어, NFS는 내부 프로비저너를 제공하지 않지만, 외부 프로비저너를 사용할 수 있다. 타사 스토리지 업체가 자체 외부 diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index 5ad5a938eb..5903905d59 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -24,6 +24,8 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 `VolumeSnapshotClass` 을 사용하면 `VolumeSnapshot` 에 속한 다른 속성을 지정할 수 있다. 이러한 속성은 스토리지 시스템에의 동일한 볼륨에서 가져온 스냅샷마다 다를 수 있으므로 `PersistentVolumeClaim` 의 `StorageClass` 를 사용하여 표현할 수는 없다. +볼륨 스냅샷은 쿠버네티스 사용자에게 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 콘텐츠를 복사하는 표준화된 방법을 제공한다. 예를 들어, 데이터베이스 관리자는 이 기능을 사용하여 수정 사항을 편집 또는 삭제하기 전에 데이터베이스를 백업할 수 있다. + 사용자는 이 기능을 사용할 때 다음 사항을 알고 있어야 한다. * API 객체인 `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` 는 핵심 API가 아닌, {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}이다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 9077eec5d2..d89c0b7241 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -7,13 +7,14 @@ weight: 10 컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 -애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 첫째, 컨테이너가 충돌되면, -kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상태로 -시작되기 때문에 기존 파일이 유실된다. 둘째, `파드` 에서 컨테이너를 함께 실행할 때 -컨테이너 사이에 파일을 공유해야 하는 경우가 자주 발생한다. 쿠버네티스의 -`볼륨` 추상화는 이 두 가지 문제를 모두 해결한다. +애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 한 가지 문제는 +컨테이너가 크래시될 때 파일이 손실된다는 것이다. kubelet은 컨테이너를 다시 시작하지만 +초기화된 상태이다. 두 번째 문제는 `Pod`에서 같이 실행되는 컨테이너간에 +파일을 공유할 때 발생한다. +쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 추상화는 +이러한 문제를 모두 해결한다. -[파드](/ko/docs/concepts/workloads/pods/pod/)에 대해 익숙해지는 것을 추천한다. +[파드](/ko/docs/concepts/workloads/pods/)에 대해 익숙해지는 것을 추천한다. @@ -21,86 +22,47 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 도커는 다소 느슨하고, 덜 관리되지만 [볼륨](https://docs.docker.com/storage/)이라는 -개념을 가지고 있다. 도커에서 볼륨은 단순한 디스크 내 디렉터리 또는 -다른 컨테이너에 있는 디렉터리다. 수명은 관리되지 않으며 최근까지는 -로컬 디스크 백업 볼륨만 있었다. 도커는 이제 볼륨 드라이버를 -제공하지만, 현재 기능은 매우 제한되어 있다(예: 도커 1.7부터 -컨테이너 당 하나의 볼륨 드라이버만 허용되고 매개 변수를 볼륨에 -전달할 방법이 없다). +개념을 가지고 있다. 도커 볼륨은 디스크에 있는 디렉터리이거나 +다른 컨테이너에 있다. 도커는 볼륨 +드라이버를 제공하지만, 기능이 다소 제한된다. -반면에, 쿠버네티스 볼륨은 그것을 둘러싼 파드와 -동일한 명시적인 수명을 가진다. 그 결과로, 볼륨은 파드 내에서 실행되는 모든 컨테이너보다 -수명이 길고, 컨테이너를 다시 시작해도 데이터가 보존된다. 물론 파드가 -존재하지 않으면, 볼륨도 존재하지 않는다. 이보다 더 중요한 것은 -쿠버네티스가 많은 유형의 볼륨을 지원하고, 파드는 -여러 볼륨을 동시에 사용할 수 있다. +쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는 +여러 볼륨 유형을 동시에 사용할 수 있다. +임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은 +파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서 +실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가 +더 이상 존재하지 않으면, 볼륨은 삭제된다. 기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 -내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 +내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 매체와 내용은 사용된 특정 볼륨의 유형에 따라 결정된다. -볼륨을 사용하기 위해 파드는 파드에 제공할 볼륨( -`.spec.volumes` -필드)과 컨테이너에 마운트 할 위치( -`.spec.containers[*].volumeMounts` -필드)를 지정한다. +볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 +`.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. -컨테이너 내 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 뷰를 -본다. [도커 -이미지](https://docs.docker.com/userguide/dockerimages/)는 파일 -시스템 계층의 루트에 있으며 모든 볼륨은 이미지 내에 지정된 경로에 -마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 -가질 수 없다. 파드 내 각각의 컨테이너는 각각의 볼륨을 마운트 할 위치를 독립적으로 +컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 +뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 +파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 +마운트된다. 볼륨은 다른 볼륨에 마운트할 수 없거나 다른 볼륨에 대한 하드 링크를 +가질 수 없다. 파드 구성의 각 컨테이너는 각 볼륨을 마운트할 위치를 독립적으로 지정해야 한다. -## 볼륨 유형들 +## 볼륨 유형들 {#volume-types} 쿠버네티스는 여러 유형의 볼륨을 지원한다. - * [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 -볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 +`awsElasticBlockStore` 볼륨은 아마존 웹 서비스 (AWS) +[EBS 볼륨](https://aws.amazon.com/ebs/)을 파드에 마운트 한다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 EBS 볼륨의 -내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 -데이터를 미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" -할 수 있다. +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 EBS 볼륨에 +데이터를 미리 채울 수 있으며, 파드 간에 데이터를 "전달(handed off)"할 수 있다. -{{< caution >}} +{{< note >}} 이를 사용하려면 먼저 `aws ec2 create-volume` 또는 AWS API를 사용해서 EBS 볼륨을 생성해야 한다. -{{< /caution >}} +{{< /note >}} `awsElasticBlockStore` 볼륨을 사용할 때 몇 가지 제한이 있다. @@ -108,7 +70,7 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 * 이러한 인스턴스는 EBS 볼륨과 동일한 지역과 가용성 영역에 있어야 함 * EBS는 볼륨을 마운트하는 단일 EC2 인스턴스만 지원함 -#### EBS 볼륨 생성하기 +#### AWS EBS 볼륨 생성하기 파드와 함께 EBS 볼륨을 사용하려면, 먼저 EBS 볼륨을 생성해야 한다. @@ -116,8 +78,8 @@ kubelet은 컨테이너를 재시작시키지만, 컨테이너는 깨끗한 상 aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 ``` -클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. (그리고 크기와 EBS 볼륨 유형이 -사용에 적합한지 확인한다!) +클러스터를 띄운 영역과 생성하는 영역이 일치하는지 확인한다. 크기와 EBS 볼륨 유형이 +사용에 적합한지 확인한다. #### AWS EBS 구성 예시 @@ -137,37 +99,38 @@ spec: - name: test-volume # 이 AWS EBS 볼륨은 이미 존재해야 한다. awsElasticBlockStore: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI 마이그레이션 +#### AWS EBS 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` +`awsElasticBlockStore` 의 `CSIMigration` 기능이 활성화된 경우, 기존 인-트리 플러그인의 +모든 플러그인 작업을 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [AWS EBS CSI +드라이버](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)를 +설치하고 `CSIMigration` 과 `CSIMigrationAWS` 베타 기능을 활성화해야 한다. -#### CSI 마이그레이션 완료 +#### AWS EBS CSI 마이그레이션 완료 {{< feature-state for_k8s_version="v1.17" state="alpha" >}} -컨트롤러 매니저와 kubelet에 의해 로드되지 않도록 awsElasticBlockStore 스토리지 플러그인을 끄려면, 이 기능의 플래그를 true로 설정해야 한다. 이는 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다. +컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지 +플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `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/)를 파드에 마운트하는 데 사용한다. +`azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)에서 확인할 수 있다. +더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다. -#### CSI 마이그레이션 +#### azureDisk CSI 마이그레이션 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`azureDisk` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `disk.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 디스크 CSI 드라이버](https://github.com/kubernetes-sigs/azuredisk-csi-driver) @@ -176,46 +139,46 @@ azureDisk의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 ### azureFile {#azurefile} -`azureFile` 은 Microsoft Azure 파일 볼륨 (SMB 2.1과 3.0)을 파드에 마운트하는데 -사용한다. +`azureFile` 볼륨 유형은 Microsoft Azure 파일 볼륨(SMB 2.1과 3.0)을 파드에 +마운트한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)에서 확인할 수 있다. +더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md)을 참고한다. -#### CSI 마이그레이션 +#### azureFile CSI 마이그레이션 {{< feature-state for_k8s_version="v1.15" state="alpha" >}} -azureFile의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +`azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` 알파 기능을 활성화해야 한다. -### cephfs {#cephfs} +### cephfs `cephfs` 볼륨은 기존 CephFS 볼륨을 파드에 마운트 할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 cephfs 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 -해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, -파드 간에 데이터를 "전달(handed off)" 할 수 있다. CephFS는 여러 작성자가 +해제만 된다. 이 의미는 `cephfs` 볼륨에 데이터를 미리 채울 수 있으며, +해당 데이터는 파드 간에 공유될 수 있다. `cephfs` 볼륨은 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다. -### cinder {#cinder} +### cinder {{< note >}} -전제 조건: 오픈스택 클라우드 공급자로 구성된 쿠버네티스. +쿠버네티스는 오픈스택 클라우드 공급자로 구성되어야 한다. {{< /note >}} -`cinder` 는 오픈스택 Cinder 볼륨을 파드에 마운트하는 데 사용한다. +`cinder` 볼륨 유형은 오픈스택 Cinder 볼륨을 파드에 마운트하는데 사용된다. -#### Cinder 볼륨 예시 구성 +#### Cinder 볼륨 구성 예시 ```yaml apiVersion: v1 @@ -233,33 +196,32 @@ spec: - name: test-volume # 이 오픈스택 볼륨은 이미 존재해야 한다. cinder: - volumeID: + volumeID: "" fsType: ext4 ``` -#### CSI 마이그레이션 +#### 오픈스택 CSI 마이그레이션 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -Cinder의 CSI 마이그레이션 기능이 활성화된 경우, 기존 트리 내 플러그인에서 +Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `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) {#configmap} -[`configMap`](/docs/tasks/configure-pod-container/configure-pod-configmap/) 리소스는 +[컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)은 구성 데이터를 파드에 주입하는 방법을 제공한다. -`ConfigMap` 오브젝트에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 +컨피그맵에 저장된 데이터는 `configMap` 유형의 볼륨에서 참조되고 그런 다음에 파드에서 실행되는 컨테이너화된 애플리케이션이 소비한다. -`configMap` 오브젝트를 참조할 때, 간단하게 참조하기 위한 볼륨의 이름을 -제공할 수 있다. ConfigMap의 특정 항목에 사용할 경로를 -사용자 정의할 수 있다. -예를 들어, `log-config` ConfigMap을 `configmap-pod` 라 부르는 파드에 마운트하려면 -아래 YAML을 사용할 수 있다. +컨피그맵을 참조할 때, 볼륨에 컨피그맵의 이름을 +제공한다. 컨피그맵의 특정 항목에 사용할 경로를 +사용자 정의할 수 있다. 다음 구성은 `log-config` 컨피그맵을 +`configmap-pod` 라 부르는 파드에 마운트하는 방법을 보여준다. ```yaml apiVersion: v1 @@ -282,48 +244,42 @@ spec: path: log_level ``` -`log-config` ConfigMap은 볼륨으로 마운트되며, `log_level` 항목에 -저장된 모든 컨텐츠는 파드의 "`/etc/config/log_level`" 경로에 마운트 된다. +`log-config` 컨피그맵은 볼륨으로 마운트되며, `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 +* 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 수신하지 않는다. -{{< /note >}} -{{< note >}} -텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩을 사용하려면, binaryData를 사용한다. +* 텍스트 데이터는 UTF-8 문자 인코딩을 사용하는 파일로 노출된다. 다른 문자 인코딩의 경우, `binaryData` 를 사용한다. {{< /note >}} - ### downwardAPI {#downwardapi} -`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 하는데 사용된다. +`downwardAPI` 볼륨은 애플리케이션에서 다운워드(downward) API 데이터를 사용할 수 있도록 한다. 이것은 디렉터리를 마운트하고 요청된 데이터를 일반 텍스트 파일로 작성한다. {{< note >}} -Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 Downward API +다운워드 API를 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다. {{< /note >}} -더 자세한 내용은 [`downwardAPI` 볼륨 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참조한다. +더 자세한 내용은 [다운워드 API 예시](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)를 참고한다. ### emptyDir {#emptydir} -`emptyDir` 볼륨은 파드가 노드에 할당 될 때 처음 생성되며, -해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 -`emptyDir` 볼륨은 처음에는 비어있다. 파드내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 -파일을 읽고 쓸수 있지만, 볼륨은 각각의 컨테이너에서 동일하거나 -다른 경로에 마운트 될 수 있다. 어떤 이유로든 노드에서 파드를 제거하면 +`emptyDir` 볼륨은 파드가 노드에 할당될 때 처음 생성되며, +해당 노드에서 파드가 실행되는 동안에만 존재한다. 이름에서 알 수 있듯이 +`emptyDir` 볼륨은 처음에는 비어있다. 파드 내 모든 컨테이너는 `emptyDir` 볼륨에서 동일한 +파일을 읽고 쓸 수 있지만, 해당 볼륨은 각각의 컨테이너에서 동일하거나 +다른 경로에 마운트될 수 있다. 어떤 이유로든 노드에서 파드가 제거되면 `emptyDir` 의 데이터가 영구적으로 삭제된다. {{< note >}} -컨테이너의 충돌은 노드에서 파드를 제거하지 *않기* 때문에, `emptyDir` 볼륨의 데이터는 컨테이너 충돌에서 안전하다. +컨테이너가 크래시되는 것은 노드에서 파드를 제거하지 *않는다*. `emptyDir` 볼륨의 데이터는 +컨테이너 크래시로부터 안전하다. {{< /note >}} `emptyDir` 의 일부 용도는 다음과 같다. @@ -333,15 +289,14 @@ Downward API를 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하 * 웹 서버 컨테이너가 데이터를 처리하는 동안 컨텐츠 매니저 컨테이너가 가져오는 파일을 보관 -기본적으로, `emptyDir` 볼륨은 노드를 지원하는 모든 매체에 -저장된다(환경에 따라 디스크, SSD 또는 네트워크 스토리지일 -수 있다). 그러나 `emptyDir.medium` 필드를 `"Memory"` 로 설정해서 -쿠버네티스에 tmpfs(RAM 기반 파일 시스템)를 마운트하도록 할 수 있다. +환경에 따라, `emptyDir` 볼륨은 디스크, SSD 또는 네트워크 스토리지와 +같이 노드를 지원하는 모든 매체에 저장된다. 그러나, `emptyDir.medium` 필드를 +`"Memory"`로 설정하면, 쿠버네티스에 tmpfs(RAM 기반 파일시스템)를 마운트하도록 할 수 있다. tmpfs는 매우 빠르지만, 디스크와 다르게 노드 재부팅시 tmpfs가 지워지고, 작성하는 모든 파일이 컨테이너 메모리 제한에 포함된다. -#### 파드 예시 +#### emptyDir 구성 예시 ```yaml apiVersion: v1 @@ -362,69 +317,72 @@ spec: ### fc (파이버 채널) {#fc} -`fc` 볼륨은 기존 파이버 채널 볼륨을 파드에 마운트할 수 있게 한다. -볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 단일 또는 -다중 대상 월드 와이드 이름을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, +`fc` 볼륨 유형은 기존 파이버 채널 블록 스토리지 볼륨을 +파드에 마운트할 수 있게 한다. 볼륨 구성에서 `targetWWNs` 파라미터를 사용하여 +단일 또는 다중 대상 월드 와이드 이름(WWN)을 지정할 수 있다. 만약 여러 WWN이 지정된 경우, targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다. -{{< caution >}} -이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. -{{< /caution >}} +{{< note >}} +이러한 LUN (볼륨)을 할당하고 대상 WWN에 마스킹하도록 FC SAN Zoning을 구성해야만 +쿠버네티스 호스트가 해당 LUN에 접근할 수 있다. +{{< /note >}} -더 자세한 내용은 [FC 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) 를 참조한다. +더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다. -### flocker {#flocker} +### flocker (사용 중단됨(deprecated)){#flocker} -[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스 클러스터 컨테이너 데이터 볼륨 매니저이다. 다양한 +[Flocker](https://github.com/ClusterHQ/flocker)는 오픈소스이고, 클러스터 +컨테이너 데이터 볼륨 매니저이다. Flocker는 다양한 스토리지 백엔드가 지원하는 데이터 볼륨 관리와 오케스트레이션을 제공한다. `flocker` 볼륨은 Flocker 데이터셋을 파드에 마운트할 수 있게 한다. 만약 Flocker내에 데이터셋이 없는 경우, 먼저 Flocker CLI 또는 Flocker API를 사용해서 생성해야 한다. 만약 데이터셋이 이미 있다면 Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이는 필요에 -따라 파드 간에 데이터를 "전달(handed off)" 할 수 있다는 의미이다. +따라 파드 간에 데이터를 공유할 수 있다는 의미이다. -{{< caution >}} +{{< note >}} `flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다. -### gcePersistentDisk {#gcepersistentdisk} +### gcePersistentDisk -`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진 (GCE) -[퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks)를 파드에 마운트 한다. 파드를 -제거할 때 지워지는 `emptyDir` 와는 다르게 PD의 내용은 유지되고, -볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 -미리 채울 수 있으며, 파드간에 데이터를 "전달(handed off)" 할 수 있다는 것을 의미한다. +`gcePersistentDisk` 볼륨은 구글 컴퓨트 엔진(GCE) +[영구 디스크](https://cloud.google.com/compute/docs/disks)(PD)를 파드에 마운트한다. +파드를 제거할 때 지워지는 `emptyDir` 와는 다르게, PD의 내용은 유지되고, +볼륨은 마운트 해제만 된다. 이는 PD에 데이터를 +미리 채울 수 있으며, 파드 간에 데이터를 공유할 수 있다는 것을 의미한다. -{{< caution >}} +{{< note >}} `gcePersistentDisk` 를 사용하려면 먼저 PD를 `gcloud`, GCE API 또는 UI를 사용해서 생성해야 한다. -{{< /caution >}} +{{< /note >}} -`gcePersistentDisk` 를 사용할 때 몇가지 제한이 있다. +`gcePersistentDisk` 를 사용할 때 몇 가지 제한이 있다. -* 파드가 실행중인 노드는 GCE VM이어야 함 -* 이러한 VM은 PD와 동일한 GCE 프로젝트와 영역에 있어야 함 +* 파드가 실행 중인 노드는 GCE VM이어야 함 +* 이러한 VM은 영구 디스크와 동일한 GCE 프로젝트와 영역에 있어야 함 -PD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 PD를 미리 채운 다음, 필요한 -만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, -PD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 -동시 쓰기는 허용되지 않는다. +GCE 영구 디스크의 한 가지 기능은 영구 디스크에 대한 동시 읽기 전용 접근이다. +`gcePersistentDisk` 볼륨을 사용하면 여러 사용자가 영구 디스크를 읽기 전용으로 +동시에 마운트할 수 있다. 즉, PD를 데이터 세트로 미리 채운 다음 +필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행히도, +PD는 읽기-쓰기 모드에서 단일 사용자만 마운트할 수 있다. 동시 +쓰기는 허용되지 않는다. -ReplicationController가 제어하는 파드에서 PD를 사용하는 것은 -PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 실패할 것이다. +PD가 읽기 전용이거나 레플리카의 수가 0 또는 1이 아니라면 레플리카셋(ReplicaSet)으로 제어되는 +파드가 있는 GCE 영구 디스크를 사용할 수 없다. -#### PD 생성하기 +#### GCE 영구 디스크 생성하기 {#gce-create-persistent-disk} -GCE PD를 파드와 함께 사용하려면 디스크를 먼저 생성해야 한다. +GCE 영구 디스크를 파드와 함께 사용하려면, 디스크를 먼저 생성해야 한다. ```shell gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk ``` -#### 예시 파드 +#### GCE 영구 디스크 구성 예시 ```yaml apiVersion: v1 @@ -446,18 +404,26 @@ spec: fsType: ext4 ``` -#### 지역(Regional) 퍼시스턴트 디스크 -[지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. +#### 리전 영구 디스크 + +[리전 영구 디스크](https://cloud.google.com/compute/docs/disks/#repds) +기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 영구 디스크를 +생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨(PersistentVolume)으로 +프로비저닝해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. + +#### 리전 PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 + +[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 +사용해서 동적 프로비저닝이 가능하다. +퍼시스턴트볼륨을 생성하기 전에 영구 디스크를 생성해야만 한다. -#### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 -[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다. -PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. ```shell gcloud compute disks create --size=500GB my-data-disk - --region us-central1 - --replica-zones us-central1-a,us-central1-b + --region us-central1 + --replica-zones us-central1-a,us-central1-b ``` -PersistentVolume 사양 예시 + +#### 리전 영구 디스크 구성 예시 ```yaml apiVersion: v1 @@ -483,29 +449,28 @@ spec: - us-central1-b ``` -#### CSI 마이그레이션 +#### GCE CSI 마이그레이션 {{< feature-state for_k8s_version="v1.17" state="beta" >}} -GCE PD의 CSI 마이그레이션 기능이 활성화된 경우 기존 트리 내 플러그인에서 +GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러그인에서 `pd.csi.storage.gke.io` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI +드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, 클러스터에 [GCE PD CSI 드라이버](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationGCE` 베타 기능을 활성화해야 한다. -### gitRepo (사용 중단(deprecated)) {#gitrepo} +### gitRepo (사용 중단됨) {#gitrepo} {{< warning >}} -gitRepo 볼륨 유형은 사용 중단(deprecated)되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. +`gitRepo` 볼륨 유형은 사용 중단되었다. git repo가 있는 컨테이너를 프로비전 하려면 초기화 컨테이너(InitContainer)에 [EmptyDir](#emptydir)을 마운트하고, 여기에 git을 사용해서 repo를 복제하고, [EmptyDir](#emptydir)을 파드 컨테이너에 마운트 한다. {{< /warning >}} -`gitRepo` 볼륨은 볼륨 플러그인으로 할 수 있는 예시이다. 빈 -디렉터리를 마운트하고 파드가 사용할 수 있도록 해당 디렉터리에 git 리포지트리를 -복제한다. 미래에는 모든 이용 사례에 대해 쿠버네티스 API를 확장하는 대신에 -이런 볼륨은 훨씬 더 분리된 모델로 이동될 수 있다. +`gitRepo` 볼륨은 볼륨 플러그인의 예시이다. 이 플러그인은 +빈 디렉터리를 마운트하고 파드가 사용할 수 있도록 이 디렉터리에 git 리포지터리를 +복제한다. -여기 gitRepo 볼륨의 예시가 있다. +여기 `gitRepo` 볼륨의 예시가 있다. ```yaml apiVersion: v1 @@ -526,19 +491,19 @@ spec: revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` -### glusterfs {#glusterfs} +### glusterfs `glusterfs` 볼륨을 사용하면 [Glusterfs](https://www.gluster.org) (오픈 -소스 네트워크 파일시스템) 볼륨을 파드에 마운트 할수 있다. 파드를 +소스 네트워크 파일시스템) 볼륨을 파드에 마운트할 수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `glusterfs` 볼륨의 내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 -glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데이터를 -"전달(handed off)" 할 수 있다. GlusterFS는 여러 작성자가 동시에 +glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데이터를 +공유할 수 있다. GlusterFS는 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다. @@ -576,14 +541,12 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. -* 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 - 사용되는 리소스를 설명할 수 없다. * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/tasks/configure-pod-container/security-context/)에서 루트로 실행하거나 `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. -#### 파드 예시 +#### hostPath 구성 예시 ```yaml apiVersion: v1 @@ -607,10 +570,13 @@ spec: ``` {{< caution >}} -`FileOrCreate` 모드에서는 파일의 상위 디렉터리가 생성되지 않는다. 마운트된 파일의 상위 디렉터리가 없으면 파드가 시작되지 않는다. 이 모드가 작동하도록 하기 위해 다음과 같이 디렉터리와 파일을 별도로 마운트할 수 있다. +`FileOrCreate` 모드는 파일의 상위 디렉터리를 생성하지 않는다. 마운트된 파일의 상위 디렉터리가 +없으면 파드가 시작되지 않는다. 이 모드가 작동하는지 확인하려면, +[`FileOrCreate` 구성](#hostpath-fileorcreate-example)에 표시된대로 +디렉터리와 파일을 별도로 마운트할 수 있다. {{< /caution >}} -#### FileOrCreate 파드 예시 +#### hostPath FileOrCreate 구성 예시 {#hostpath-fileorcreate-example} ```yaml apiVersion: v1 @@ -638,49 +604,47 @@ spec: type: FileOrCreate ``` -### iscsi {#iscsi} +### iscsi `iscsi` 볼륨을 사용하면 기존 iSCSI (SCSI over IP) 볼륨을 파드에 마운트 -할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `iscsi` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 해제만 된다. 이 의미는 iscsi 볼륨에 데이터를 미리 채울 수 있으며, -파드간에 데이터를 "전달(handed off)" 할 수 있다는 것이다. +파드간에 데이터를 공유할 수 있다는 것이다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 iSCSI 서버를 실행하고 볼륨을 생성해야 한다. -{{< /caution >}} +{{< /note >}} iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 사전에 볼륨을 채운다음, -필요한 만큼 많은 파드에서 병렬로 제공할 수 있다. 불행하게도, -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 `local` 볼륨은 디스크, 파티션 또는 디렉터리 같은 마운트된 로컬 스토리지 장치를 나타낸다. -로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨(PersistentVolume)으로만 사용할 수 있다. 동적으로 -프로비저닝된 것은 아직 지원되지 않는다. +로컬 볼륨은 정적으로 생성된 퍼시스턴트볼륨으로만 사용할 수 있다. 동적으로 +프로비저닝된 것은 지원되지 않는다. -`hostPath` 볼륨에 비해 로컬 볼륨은 퍼시스턴트볼륨의 노드 어피니티를 살펴봄으로써 -볼륨의 노드 제약 조건을 인식하기 때문에 수동으로 파드를 노드에 예약하지 않고도 -내구성과 휴대성을 갖춘 방식으로 사용할 수 있다. +`hostPath` 볼륨에 비해 `local` 볼륨은 수동으로 파드를 노드에 예약하지 않고도 +내구성과 휴대성을 갖춘 방식으로 사용된다. 시스템은 +퍼시스턴트볼륨의 노드 어피니티를 확인하여 볼륨의 노드 제약 조건을 인식한다. -그러나 로컬 볼륨은 여전히 기본 노드의 가용성을 따르며 +그러나 `local` 볼륨은 여전히 기본 노드의 가용성을 따르며 모든 애플리케이션에 적합하지는 않는다. 만약 노드가 비정상 상태가 -되면 로컬 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 -없게 된다. 로컬 볼륨을 사용하는 애플리케이션은 기본 디스크의 +되면 `local` 볼륨도 접근할 수 없게 되고, 파드를 실행할 수 +없게 된다. `local` 볼륨을 사용하는 애플리케이션은 기본 디스크의 내구 특성에 따라 이러한 감소되는 가용성과 데이터 손실 가능성도 허용할 수 있어야 한다. -다음은 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨 -사양 예시이다. +다음의 예시는 `local` 볼륨과 `nodeAffinity` 를 사용하는 퍼시스턴트볼륨을 +보여준다. ```yaml apiVersion: v1 @@ -707,18 +671,18 @@ spec: - example-node ``` -로컬 볼륨을 사용할 때는 퍼시스턴트볼륨의 `nodeAffinity` 가 필요하다. 이를 통해 -쿠버네티스 스케줄러는 올바른 노드의 로컬 볼륨을 파드가 사용할 수 있도록 올바르게 -스케줄할 수 있다. +`local` 볼륨을 사용하는 경우 퍼시스턴트볼륨 `nodeAffinity` 를 설정해야 합니다. +쿠버네티스 스케줄러는 퍼시스턴트볼륨 `nodeAffinity` 를 사용하여 +파드를 올바른 노드로 스케줄한다. 퍼시스턴트볼륨의 `volumeMode` 을 "Block" (기본값인 "Filesystem"을 대신해서)으로 설정하면 로컬 볼륨을 원시 블록 장치로 노출할 수 있다. 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 -스토리지클래스(StorageClass)를 생성하는 것을 권장한다. -[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 -퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, -파드 어피니티 그리고 파드 안티 어피니티와 +스토리지클래스(StorageClass)를 생성하는 것을 권장한다. 자세한 내용은 +local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-classes/#local) 예제를 참고한다. +볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도 +노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. 로컬 볼륨 라이프사이클의 향상된 관리를 위해 외부 정적 @@ -733,18 +697,18 @@ spec: 필요하다. {{< /note >}} -### nfs {#nfs} +### nfs `nfs` 볼륨을 사용하면 기존 NFS (네트워크 파일 시스템) 볼륨을 파드에 마운트 -할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 +할수 있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `nfs` 볼륨의 내용은 유지되고, 볼륨은 그저 마운트 해제만 된다. 이 의미는 NFS 볼륨에 데이터를 미리 채울 수 있으며, -파드간에 데이터를 "전달(handed off)" 할 수 있다는 뜻이다. NFS는 여러 작성자가 +파드 간에 데이터를 공유할 수 있다는 뜻이다. NFS는 여러 작성자가 동시에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다. -{{< /caution >}} +{{< /note >}} 더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다. @@ -758,27 +722,59 @@ iSCSI 볼륨와 같은)를 "클레임" 할 수 있는 방법이다. 더 자세한 내용은 [퍼시스턴트볼륨 예시](/ko/docs/concepts/storage/persistent-volumes)를 본다. -### projected {#projected} +### portworxVolume {#portworxvolume} + +`portworxVolume` 은 쿠버네티스와 하이퍼컨버지드(hyperconverged)를 실행하는 탄력적인 블록 스토리지 +계층이다. [Portworx](https://portworx.com/use-case/kubernetes-storage/)는 서버의 +스토리지를 핑거프린팅하고(fingerprints), 기능에 기반하여 계층화하고, 그리고 여러 서버에 걸쳐 용량을 집계한다. +Portworx는 가상 머신 내 게스트 또는 베어 메탈 리눅스 노드 위에서 실행된다. + +`portworxVolume` 은 쿠버네티스를 통해 동적으로 생성되거나 +사전에 프로비전할 수 있으며 쿠버네티스 파드 내에서 참조할 수 있다. +다음은 사전에 프로비저닝된 Portworx 볼륨을 참조하는 파드의 예시이다. + +```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: "" +``` + +{{< note >}} +파드에서 사용하기 이전에 먼저 이름이 `pxvol` 인 PortworxVolume이 +있는지 확인한다. +{{< /note >}} + +자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다. + +### projected `Projected` 볼륨은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑한다. 현재, 다음 유형의 볼륨 소스를 프로젝티드한다. -- [`secret`](#secret) -- [`downwardAPI`](#downwardapi) -- [`configMap`](#configmap) -- `serviceAccountToken` +* [`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` -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 -True로 명시적인 설정이 필요하다. - -#### 시크릿, downward API 그리고 configmap이 있는 파드 예시. +#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap} ```yaml apiVersion: v1 @@ -818,7 +814,7 @@ spec: path: my-group/my-config ``` -#### 기본값이 아닌 모드 설정과 여러 시크릿을 가진 파드 예시 +#### 구성 예시: 기본값이 아닌 소유권 모드 설정의 시크릿 {#example-configuration-secrets-nondefault-permission-mode} ```yaml apiVersion: v1 @@ -853,7 +849,7 @@ spec: 각각의 projected 볼륨 소스는 `source` 아래 사양 목록에 있다. 파라미터는 두 가지 예외를 제외하고 거의 동일하다. -* 시크릿의 경우 `secretName` 필드는 ConfigMap 이름과 일치하도록 +* 시크릿의 경우 `secretName` 필드는 컨피그맵 이름과 일치하도록 `name` 으로 변경되었다. * `defaultMode` 는 각각의 볼륨 소스에 대해 projected 수준에서만 지정할 수 있다. 그러나 위에서 설명한 것처럼 각각의 개별 projection 에 대해 `mode` @@ -861,7 +857,7 @@ spec: `TokenRequestProjection` 기능이 활성화 되면, 현재 [서비스 어카운트](/docs/reference/access-authn-authz/authentication/#service-account-tokens)에 -대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 아래는 예시이다. +대한 토큰을 파드의 지정된 경로에 주입할 수 있다. 예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -887,7 +883,7 @@ spec: ``` 예시 파드에 주입된 서비스 어카운트 토큰이 포함된 projected 볼륨이 -있다. 예를 들어 이 토큰은 파드 컨테이너에서 쿠버네티스 API 서버에 접근하는데 +있다. 이 토큰은 파드의 컨테이너에서 쿠버네티스 API 서버에 접근하는데 사용할 수 있다. `audience` 필드는 토큰에 의도하는 대상을 포함한다. 토큰 수령은 토큰 대상에 지정된 식별자로 자신을 식별해야 하며, 그렇지 않으면 토큰을 거부해야 한다. 이 필드는 @@ -900,95 +896,60 @@ API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정 상대 경로를 지정한다. {{< note >}} -projected 볼륨 소스를 [subPath](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. +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` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을 파드에 마운트할 수 있다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 Quobyte를 설정하고 생성한 볼륨과 함께 실행해야 한다. -{{< /caution >}} +{{< /note >}} Quobyte는 {{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}를 지원한다. CSI 는 쿠버네티스 내에서 Quobyte 볼륨을 사용하기 위해 권장하는 플러그인이다. Quobyte의 깃헙 프로젝트에는 예시와 함께 CSI를 사용해서 Quobyte를 배포하기 위한 [사용 설명서](https://github.com/quobyte/quobyte-csi#quobyte-csi)가 있다. -### rbd {#rbd} +### rbd `rbd` 볼륨을 사용하면 -[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)를 파드에 마운트할 수 -있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 -내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 +[Rados Block Device](https://ceph.com/docs/master/rbd/rbd/)(RBD) 볼륨을 파드에 마운트할 수 +있다. 파드를 제거할 때 지워지는 `emptyDir` 와는 다르게 `rbd` 볼륨의 +내용은 유지되고, 볼륨은 마운트 해제만 된다. 이 의미는 RBD 볼륨에 데이터를 미리 채울 수 있으며, 데이터를 -"전달(handed off)" 할 수 있다는 것이다. +공유할 수 있다는 것이다. -{{< caution >}} +{{< note >}} RBD를 사용하기 위해선 먼저 Ceph를 설치하고 실행해야 한다. -{{< /caution >}} +{{< /note >}} RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수 -있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 -만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, -RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있으며 +있다는 것이다. 즉, 데이터셋으로 볼륨을 미리 채운 다음, 필요한 +만큼 많은 파드에서 병렬로 제공할수 있다. 불행하게도, +RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다. 동시 쓰기는 허용되지 않는다. -더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 본다. +더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를 +참고한다. -### scaleIO {#scaleio} +### scaleIO (사용 중단됨) {#scaleio} ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를 -생성할 수 있는 소프트웨어 기반 스포티리 플랫폼이다. `scaleIO` 볼륨 +생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨 플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수 -있다(또는 퍼시스턴트 볼륨 클래임을 위한 새 볼륨을 동적 프로비전할 수 있음, -[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 본다). +있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는 +방법에 대한 자세한 내용은 +[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고 생성한 볼륨과 함께 실행해야 한다. -{{< /caution >}} +{{< /note >}} -다음은 파드 구성을 ScaleIO와 함께 하는 예시이다. +다음의 예시는 ScaleIO를 사용하는 파드 구성이다. ```yaml apiVersion: v1 @@ -1015,26 +976,26 @@ spec: fsType: xfs ``` -자세한 내용은 [ScaleIO 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio)를 본다. +더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다. -### secret {#secret} +### secret `secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데 -사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 -파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 +사용된다. 쿠버네티스 API에 시크릿을 저장하고 쿠버네티스에 직접적으로 연결하지 않고도 +파드에서 사용할 수 있도록 파일로 마운트 할 수 있다. `secret` 볼륨은 tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토리지에 절대 기록되지 않는다. -{{< caution >}} +{{< note >}} 사용하기 위해선 먼저 쿠버네티스 API에서 시크릿을 생성해야 한다. -{{< /caution >}} +{{< /note >}} {{< note >}} -시크릿을 [subPath](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 +시크릿을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 시크릿 업데이트를 수신하지 못한다. {{< /note >}} -시크릿에 대해서 [여기](/ko/docs/concepts/configuration/secret/)에 더 자세한 설명이 있다. +더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다. ### storageOS {#storageos} @@ -1058,6 +1019,8 @@ StorageOS 볼륨에 접근하거나 스토리지 용량을 [StorageOS 문서](https://docs.storageos.com)를 찾아본다. {{< /caution >}} +다음의 예시는 StorageOS를 사용한 파드 구성이다. + ```yaml apiVersion: v1 kind: Pod @@ -1086,24 +1049,24 @@ spec: fsType: ext4 ``` -동적 프로비저닝과 퍼시스턴트 볼륨 클래임을 포함한 더 많은 정보는 -[StorageOS 예시](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 본다. +StorageOS, 동적 프로비저닝과 퍼시스턴트 볼륨 클래임에 대한 더 자세한 정보는 +[StorageOS 예제](https://github.com/kubernetes/examples/blob/master/volumes/storageos)를 참고한다. ### vsphereVolume {#vspherevolume} {{< note >}} -전제조건: 쿠버네티스와 함께 vSphere Cloud Provider가 구성됨. 클라우드공급자 +쿠버네티스 vSphere 클라우드 공급자를 구성해야 한다. 클라우드공급자 구성에 대해선 [vSphere 시작 가이드](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)를 참조한다. {{< /note >}} `vsphereVolume` 은 vSphere VMDK 볼륨을 파드에 마운트하는데 사용된다. 볼륨을 마운트 해제해도 볼륨의 내용이 유지된다. VMFS와 VSAM 데이터스토어를 모두 지원한다. -{{< caution >}} -파드와 함께 사용하기 위해선 먼저 다음 방법중 하나를 사용해서 VMDK를 생성해야 한다. -{{< /caution >}} +{{< note >}} +파드와 함께 사용하기 위해선 먼저 다음 방법 중 하나를 사용하여 vSphere VMDK 볼륨을 생성해야 한다. +{{< /note >}} -#### VMDK 볼륨 생성하기 +#### VMDK 볼륨 생성하기 {#creating-vmdk-volume} 다음 중 하나를 선택해서 VMDK를 생성한다. @@ -1114,6 +1077,7 @@ spec: ```shell vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk ``` + {{% /tab %}} {{% tab name="vmware-vdiskmanager를 사용해서 생성" %}} 다음 명령을 사용해서 VMDK를 생성한다. @@ -1121,12 +1085,13 @@ vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk ```shell vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk ``` + {{% /tab %}} {{< /tabs >}} -#### vSphere VMDK 예시 구성 +#### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration} ```yaml apiVersion: v1 @@ -1148,23 +1113,23 @@ spec: fsType: ext4 ``` -더 많은 예시는 [여기](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere)에서 확인할 수 있다. +더 자세한 내용은 [vSphere 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) 예제를 참고한다. -#### CSI 마이그레이션 +#### vSphere CSI 마이그레이션 {#vsphere-csi-migration} {{< feature-state for_k8s_version="v1.19" state="beta" >}} -vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인-트리 플러그인에서 -`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 shim한다. -이 기능을 사용하려면, [vSphere CSI -드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 +`vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서 +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. +이 기능을 사용하려면, +[vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. 또한 최소 vSphere vCenter/ESXi 버전은 7.0u1이고 최소 HW 버전은 VM 버전 15여야 한다. {{< note >}} -빌트인 vsphereVolume 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. +빌트인 `vsphereVolume` 플러그인의 다음 스토리지클래스 파라미터는 vSphere CSI 드라이버에서 지원되지 않는다. * `diskformat` * `hostfailurestotolerate` @@ -1174,22 +1139,28 @@ vsphereVolume용 CSI 마이그레이션 기능이 활성화되면, 기존 인- * `objectspacereservation` * `iopslimit` -이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다. +이러한 파라미터를 사용하여 생성된 기존 볼륨은 vSphere CSI 드라이버로 마이그레이션되지만, +vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를 따르지 않는다. {{< /note >}} -#### CSI 마이그레이션 완료 +#### vSphere CSI 마이그레이션 완료 {#vsphere-csi-migration-complete} + {{< feature-state for_k8s_version="v1.19" state="beta" >}} -vsphereVolume 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 true로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치되어 있어야 한다. +`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다. +## subPath 사용하기 {#using-subpath} -## subPath 사용하기 +때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. +`volumeMounts.subPath` 속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 +지정할 수 있다. -때로는 단일 파드에서 여러 용도의 한 볼륨을 공유하는 것이 유용하다. `volumeMounts.subPath` -속성을 사용해서 root 대신 참조하는 볼륨 내의 하위 경로를 지정할 수 있다. +다음의 예시는 단일 공유 볼륨을 사용하여 LAMP 스택(리눅스 Apache MySQL PHP)이 +있는 파드를 구성하는 방법을 보여준다. 이 샘플 `subPath` 구성은 프로덕션 용도로 +권장되지 않는다. -여기에 단일 공유 볼륨을 사용하는 LAMP 스택(리눅스 아파치 Mysql PHP)이 포함된 파드의 예시가 있다. -HTML 내용은 `html` 폴더에 매핑되고 데이터베이스는 `mysql` 폴더에 저장된다. +PHP 애플리케이션의 코드와 자산은 볼륨의 `html` 폴더에 매핑되고 +MySQL 데이터베이스는 볼륨의 `mysql` 폴더에 저장된다. 예를 들면 다음과 같다. ```yaml apiVersion: v1 @@ -1219,15 +1190,18 @@ spec: claimName: my-lamp-site-data ``` -### subPath를 확장된 환경 변수와 함께 사용하기 +### subPath를 확장된 환경 변수와 함께 사용하기 {#using-subpath-expanded-environment} {{< feature-state for_k8s_version="v1.17" state="stable" >}} - -`subPathExpr` 필드를 사용해서 Downward API 환경 변수로부터 `subPath` 디렉터리 이름을 구성한다. +`subPathExpr` 필드를 사용해서 다운워드 API 환경 변수로부터 +`subPath` 디렉터리 이름을 구성한다. `subPath` 와 `subPathExpr` 속성은 상호 배타적이다. -이 예제는 파드가 `subPathExpr` 을 사용해서 Downward API로부터 파드 이름을 사용해서 hostPath 볼륨 `/var/log/pods` 내에 `pod1` 디렉터리를 생성한다. 호스트 디렉터리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트 된다. +이 예제는 `Pod` 가 `subPathExpr` 을 사용해서 `hostPath` 볼륨 +`/var/log/pods` 내에 `pod1` 디렉터리를 만든다. +`hostPath` 볼륨은 `downwardAPI` 에서 `Pod` 이름을 사용한다. +호스트 디렉토리 `/var/log/pods/pod1` 은 컨테이너의 `/logs` 에 마운트된다. ```yaml apiVersion: v1 @@ -1258,47 +1232,41 @@ spec: ## 리소스 -`emptyDir` 볼륨의 스토리지 매체(디스크, SSD, 등)는 kubelet root +`emptyDir` 볼륨의 스토리지 매체(디스크나 SSD와 같은)는 kubelet root 디렉터리(보통 `/var/lib/kubelet`)를 보유한 파일시스템의 -매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 -사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너간 또는 파드간 -격리는 없다. +매체에 의해 결정 된다. `emptyDir` 또는 `hostPath` 볼륨이 +사용할 수 있는 공간의 크기는 제한이 없으며, 컨테이너 간 또는 파드 간 격리는 +없다. -앞으로 `emptyDir` 과 `hostPath` 볼륨이 [리소스](/ko/docs/concepts/configuration/manage-resources-containers/) -사양을 사용해서 일정량의 공간을 요청하고, 여러 매체 유형이 -있는 클러스터에 사용할 매체 유형을 선택할 수 -있을 것으로 기대한다. +리소스 사양을 사용한 공간 요청에 대한 자세한 내용은 +[리소스 관리 방법](/ko/docs/concepts/configuration/manage-resources-containers/)을 참고한다. -## 아웃 오브 트리 볼륨 플러그인 +## 아웃-오브-트리(out-of-tree) 볼륨 플러그인 -아웃 오브 트리 볼륨 플러그인에는 컨테이너 스토리지 인터페이스 (CSI) 그리고 -FlexVolume이 포함된다. 스토리지 벤더들은 이 플러그인을 쿠버네티스 리포지터리에 +아웃-오브-트리 볼륨 플러그인에는 +{{< glossary_tooltip text="컨테이너 스토리지 인터페이스" term_id="csi" >}}(CSI) 그리고 +FlexVolume이 포함된다. 이러한 플러그인을 사용하면 스토리지 벤더들은 플러그인 소스 코드를 쿠버네티스 리포지터리에 추가하지 않고도 사용자 정의 스토리지 플러그인을 만들 수 있다. -CSI 와 FlexVolume을 도입하기 전에는 모든 볼륨 플러그인(위 -목록의 볼륨 유형과 같은)은 "인 트리(in-tree)" 로 쿠버네티스 핵심 -바이너리와 함께 빌드, 링크, 컴파일 그리고 전달되었고 쿠버네티스 -핵심 API를 확장했다. 이는 새로운 스토리지 시스템을 쿠버네티스( -볼륨 플러그인)에 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. +이전에는 모든 볼륨 플러그인이 "인-트리(in-tree)"에 있었다. "인-트리" 플러그인은 쿠버네티스 핵심 바이너리와 +함께 빌드, 링크, 컴파일 및 배포되었다. 즉, 쿠버네티스(볼륨 플러그인)에 +새로운 스토리지 시스템을 추가하려면 쿠버네티스 핵심 코드 리포지토리의 코드 확인이 필요했음을 의미한다. CSI와 FlexVolume을 통해 쿠버네티스 코드 베이스와는 독립적으로 볼륨 플러그인을 개발하고, 쿠버네티스 클러스터의 확장으로 배포(설치) 할 수 있다. 아웃 오브 트리(out-of-tree) 볼륨 플러그인을 생성하려는 스토리지 벤더는 -[이 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. +[볼륨 플러그인 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md)를 참조한다. -### CSI +### csi -[컨테이너 스토리지 인터페이스](https://github.com/container-storage-interface/spec/blob/master/spec.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) 되었고, 향후 릴리스에서 제거될 예정이다. @@ -1311,57 +1279,59 @@ CSI 드라이버는 일부 쿠버네티스 릴리스에서 호환되지 않을 {{< /note >}} CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 -`csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결, 마운트, -등을 할 수 있다. +사용자는 `csi` 볼륨 유형을 사용해서 CSI 드라이버에 의해 노출된 볼륨에 연결하거나 +마운트할 수 있다. `csi` 볼륨은 세 가지 방법으로 파드에서 사용할 수 있다. -- [`persistentVolumeClaim`](#persistentvolumeclaim)에 대한 참조를 통해서 -- [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 (알파 기능) -- 드라이버가 지원하는 경우 - [CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) (베타 기능) + +* [퍼시스턴트볼륨클레임](#persistentvolumeclaim)에 대한 참조를 통해서 +* [일반 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)과 함께 +(알파 기능) +* 드라이버가 지원하는 경우 +[CSI 임시 볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)과 함께 (베타 기능) 스토리지 관리자가 다음 필드를 사용해서 CSI 퍼시스턴트 볼륨을 구성할 수 있다. -- `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. +* `driver`: 사용할 볼륨 드라이버의 이름을 지정하는 문자열 값. 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo)에 정의된 CSI 드라이버가 `GetPluginInfoResponse` 에 반환하는 값과 일치해야 한다. 쿠버네티스에서 호출할 CSI 드라이버를 식별하고, CSI 드라이버 컴포넌트에서 CSI 드라이버에 속하는 PV 오브젝트를 식별하는데 사용한다. -- `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. +* `volumeHandle`: 볼륨을 식별하게 하는 고유한 문자열 값. 이 값은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 정의된 CSI 드라이버가 `CreateVolumeResponse` 의 `volume.id` 필드에 반환하는 값과 일치해야 한다. 이 값은 볼륨을 참조할 때 CSI 볼륨 드라이버에 대한 모든 호출에 `volume_id` 값을 전달한다. -- `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 +* `readOnly`: 볼륨을 읽기 전용으로 "ControllerPublished" (연결)할지 여부를 나타내는 선택적인 불리언(boolean) 값. 기본적으로 false 이다. 이 값은 `ControllerPublishVolumeRequest` 의 `readonly` 필드를 통해 CSI 드라이버로 전달된다. -- `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 +* `fsType`: 만약 PV의 `VolumeMode` 가 `Filesystem` 인 경우에 이 필드는 볼륨을 마운트하는 데 사용해야 하는 파일시스템을 지정하는 데 사용될 수 있다. 만약 볼륨이 포맷되지 않았고 포맷이 지원되는 경우, 이 값은 볼륨을 포맷하는데 사용된다. 이 값은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest` 그리고 `NodePublishVolumeRequest` 의 `VolumeCapability` 필드를 통해 CSI 드라이버로 전달된다. -- `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 +* `volumeAttributes`: 볼륨의 정적 속성을 지정하는 문자열과 문자열을 매핑한다. 이 매핑은 [CSI 사양](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume)에 정의된 대로 CSI 드라이버의 `CreateVolumeResponse` 와 `volume.attributes` 필드에서 반환되는 매핑과 일치해야 한다. 이 매핑은 `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, 그리고 `NodePublishVolumeRequest` 의 `volume_context` 필드를 통해 CSI 드라이버로 전달된다. -- `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` +* `controllerPublishSecretRef`: CSI의 `ControllerPublishVolume` 그리고 `ControllerUnpublishVolume` 호출을 완료하기 위해 CSI 드라이버에 전달하려는 민감한 정보가 포함된 시크릿 오브젝트에 대한 참조이다. 이 필드는 - 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 + 선택사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. -- `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 +* `nodeStageSecretRef`: CSI의 `NodeStageVolume` 호출을 완료하기위해 CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 - 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 + 경우 비어있을 수 있다. 만약 시크릿에 둘 이상의 시크릿이 포함된 경우에도 모든 시크릿이 전달된다. -- `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 +* `nodePublishSecretRef`: CSI의 `NodePublishVolume` 호출을 완료하기위해 CSI 드라이버에 전달하려는 민감한 정보가 포함 된 시크릿 오브젝트에 대한 참조이다. 이 필드는 선택 사항이며, 시크릿이 필요하지 않은 경우 비어있을 수 있다. 만약 시크릿 오브젝트에 둘 이상의 시크릿이 포함된 경우에도 @@ -1375,7 +1345,7 @@ CSI 호환 볼륨 드라이버가 쿠버네티스 클러스터에 배포되면 지원을 구현할 수 있다. CSI 설정 변경 없이 평소와 같이 -[원시 블록 볼륨 지원으로 PV/PVC 설정](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원)을 할 수 있다. +[원시 블록 볼륨 지원으로 퍼시스턴트볼륨/퍼시스턴트볼륨클레임](/ko/docs/concepts/storage/persistent-volumes/#원시-블록-볼륨-지원) 설정을 할 수 있다. #### CSI 임시(ephemeral) 볼륨 @@ -1384,105 +1354,104 @@ CSI 설정 변경 없이 평소와 같이 파드 명세 내에서 CSI 볼륨을 직접 구성할 수 있다. 이 방식으로 지정된 볼륨은 임시 볼륨이며 파드가 다시 시작할 때 지속되지 않는다. 자세한 내용은 [임시 -볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)을 +볼륨](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)을 참고한다. -#### {{% heading "whatsnext" %}} +CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 +[쿠버네티스-csi 문서](https://kubernetes-csi.github.io/docs/)를 참조한다. -CSI 드라이버의 개발 방법에 대한 더 자세한 정보는 [쿠버네티스-csi -문서](https://kubernetes-csi.github.io/docs/)를 참조한다. +#### 인-트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 -#### 인 트리 플러그인으로부터 CSI 드라이버로 마이그레이션하기 +{{< feature-state for_k8s_version="v1.17" state="beta" >}} -{{< feature-state for_k8s_version="v1.14" state="alpha" >}} - -TCSI 마이그레이션 기능이 활성화 되면 기존의 인 트리 플러그인에 +`CSIMigration` 기능이 활성화 되면 기존의 인-트리 플러그인에 대한 작업을 해당 CSI 플러그인(설치와 구성이 될 것으로 예상한)으로 유도한다. -이 기능은 필요한 변환 논리와 심(shims)을 구현하여 작업을 완전한 -방식으로 재 라우팅 한다. 결과적으로 운영자는 인 트리 플러그인을 대체하는 -CSI 드라이버로 전환할 때 기존 스토리지 클래스, PV 또는 PVC(인 트리 -플러그인 참조)에 대한 구성을 변경할 필요가 없다. +결과적으로, 운영자는 인-트리 플러그인을 대체하는 +CSI 드라이버로 전환할 때 기존 스토리지 클래스, 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임(인-트리 플러그인 참조)에 +대한 구성 변경을 수행할 필요가 없다. -알파 상태에서 지원되는 작업과 기능에는 프로비저닝/삭제, +지원되는 작업 및 기능은 프로비저닝/삭제, 연결/분리, 마운트/마운트 해제 그리고 볼륨 크기 재조정이 포함된다. -CSI 마이그레이션을 지원하고 해당 CSI 드라이버가 구현된 인 트리 플러그인은 -위의 "볼륨 유형" 섹션에 나열되어 있다. +`CSIMigration` 을 지원하고 해당 CSI 드라이버가 구현된 인-트리 플러그인은 +[볼륨 유형들](#volume-types)에 나열되어 있다. -### FlexVolume {#flexVolume} +### flexVolume -FlexVolume은 버전 1.2 (CSI 이전) 이후 쿠버네티스에 존재하는 -아웃 오브 트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 -접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드(그리고 일부 경우에 마스터)에 +FlexVolume은 버전 1.2(CSI 이전) 이후 쿠버네티스에 존재하는 +아웃-오브-트리 플러그인 인터페이스이다. 이것은 exec 기반 모델을 사용해서 드라이버에 +접속한다. FlexVolume 드라이버 바이너리 파일은 각각의 노드와 일부 경우에 컨트롤 플레인 노드의 미리 정의된 볼륨 플러그인 경로에 설치해야 한다. -파드는 `flexvolume` 인 트리 플러그인을 통해 FlexVolume 드라이버와 상호 작용 한다. -더 자세한 내용은 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)에서 찾아볼 수 있다. +파드는 `flexvolume` 인-트리 볼륨 플러그인을 통해 FlexVolume 드라이버와 상호 작용한다. +더 자세한 내용은 [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) 예제를 참고한다. ## 마운트 전파(propagation) 마운트 전파를 통해 컨테이너가 마운트한 볼륨을 동일한 파드의 다른 컨테이너 또는 동일한 노드의 다른 파드로 공유할 수 있다. -볼륨 마운트 전파는 Container.volumeMounts의 `mountPropagation` 필드에 의해 제어된다. -그 값은 다음과 같다. +볼륨 마운트 전파는 `Container.volumeMounts` 의 `mountPropagation` 필드에 +의해 제어된다. 그 값은 다음과 같다. - * `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 - 마운트된 것을 마운트 이후에 수신하지 않는다. - 비슷한 방식으로, 컨테이너가 생성 한 마운트는 호스트에서 볼 수 없다. - 이것이 기본 모드이다. +* `None` - 이 볼륨 마운트는 호스트의 볼륨 또는 해당 서브디렉터리에 + 마운트된 것을 마운트 이후에 수신하지 않는다. + 비슷한 방식으로, 컨테이너가 생성한 마운트는 호스트에서 볼 수 없다. + 이것이 기본 모드이다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. - * `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 - 서브디렉터리를 마운트한 정보를 수신한다. +* `HostToContainer` - 이 볼륨 마운트는 볼륨 또는 해당 + 서브디렉터리를 마운트한 정보를 수신한다. - 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 - 하더라도 컨테이너가 마운트 된 것을 볼 수 있다. + 다시 말하면, 만약 호스트가 볼륨 마운트 내부에 다른 것을 마운트 + 하더라도 컨테이너가 마운트된 것을 볼 수 있다. - 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 - 파드에 `HostToContainer` 마운트 전파가 있는 - 컨테이너가 이를 볼 수 있다. + 마찬가지로 `Bidirectional` 마운트 전파가 있는 파드가 동일한 마운트가 된 경우에 + 파드에 `HostToContainer` 마운트 전파가 있는 + 컨테이너가 이를 볼 수 있다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. - * `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. - 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 - 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. +* `Bidirectional` - 이 볼륨 마운트는 `HostToContainer` 마운트와 동일하게 작동한다. + 추가로 컨테이너에서 생성된 모든 볼륨 마운트는 동일한 볼륨을 + 사용하는 모든 파드의 모든 컨테이너와 호스트로 다시 전파된다. - 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 - `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. + 이 모드의 일반적인 유스 케이스로는 FlexVolume 또는 CSI 드라이버를 사용하는 파드 또는 + `hostPath` 볼륨을 사용하는 호스트에 무언가를 마운트해야 하는 파드이다. - 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 - 설명된 `rshared` 마운트 전파와 같다. + 이 모드는 [리눅스 커널 문서](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)에 + 설명된 `rshared` 마운트 전파와 같다. -{{< caution >}} +{{< warning >}} `Bidirectional` 마운트 전파는 위험할 수 있다. 이것은 -호스트 운영체제를 손상시킬수 있기에 권한이 있는 컨테이너에서만 +호스트 운영체제를 손상시킬 수 있기에 권한이 있는 컨테이너에서만 허용된다. 리눅스 커널 동작을 숙지하는 것을 권장한다. -또한 파드내 컨테이너에 의해 생성된 볼륨 마운트는 종료시 -컨테이너에의해 파괴(마운트 해제)되어야 한다. -{{< /caution >}} +또한 파드 내 컨테이너에 의해 생성된 볼륨 마운트는 종료 시 +컨테이너에 의해 파괴(마운트 해제)되어야 한다. +{{< /warning >}} ### 구성 + 일부 배포판(CoreOS, RedHat/Centos, Ubuntu)에서 마운트 전파가 제대로 작동하려면 아래와 같이 도커에서의 마운트 공유를 올바르게 구성해야 한다. -도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. +도커의 `systemd` 서비스 파일을 편집한다. `MountFlags` 를 다음과 같이 설정한다. + ```shell MountFlags=shared ``` + 또는 `MountFlags=slave` 가 있으면 제거한다. 이후 도커 데몬을 재시작 한다. + ```shell sudo systemctl daemon-reload sudo systemctl restart docker ``` - - ## {{% heading "whatsnext" %}} -* [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. +[퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. diff --git a/content/ko/docs/concepts/workloads/_index.md b/content/ko/docs/concepts/workloads/_index.md index a020124b6d..efd6fa1ff7 100644 --- a/content/ko/docs/concepts/workloads/_index.md +++ b/content/ko/docs/concepts/workloads/_index.md @@ -32,7 +32,7 @@ no_list: true 파드를 실행하기 위한 [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) * 완료될 때까지 실행되는 작업에 대한 [잡(Job)](/ko/docs/concepts/workloads/controllers/job/) 및 - [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cronjob/) + [크론잡(CronJob)](/ko/docs/concepts/workloads/controllers/cron-jobs/) 관련성을 찾을 수 있는 두 가지 지원 개념도 있다. * [가비지(Garbage) 수집](/ko/docs/concepts/workloads/controllers/garbage-collection/)은 _소유하는 리소스_ 가 diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 5c0852dc12..c5a6832fd9 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -229,7 +229,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 ### 파드 템플릿 -`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#파드-템플릿)이다. +`.spec.template`은 레이블을 붙이도록 되어있는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 00aed3c13d..e80c36aee4 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -77,13 +77,13 @@ UID로 정의된 특정 파드는 다른 노드로 절대 "다시 스케줄"되 `phase`에 가능한 값은 다음과 같다. -값 | 의미 -:-----|:----------- -`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다. -`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다. +값 | 의미 +:-----------|:----------- +`Pending` | 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함된다. +`Running` | 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었다. 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있다. `Succeeded` | 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않을 것이다. -`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. -`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. +`Failed` | 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. +`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생한다. 노드가 죽거나 클러스터의 나머지와의 연결이 끊어지면, 쿠버네티스는 손실된 노드의 모든 파드의 `phase` 를 Failed로 설정하는 정책을 적용한다. @@ -229,7 +229,8 @@ kubelet은 파드의 [조건](#파드의-조건)을 `ContainerReady` 로 설정 ## 컨테이너 프로브(probe) [프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 -컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. +컨테이너에서 [kubelet](/docs/reference/command-line-tools-reference/kubelet/)에 의해 +주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너에 의해서 구현된 [핸들러](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)를 호출한다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index e45d00eef7..c8224ea76c 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -4,11 +4,21 @@ content_type: concept weight: 40 --- +{{< feature-state for_k8s_version="v1.19" state="stable" >}} + + 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. - +{{< note >}} +v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 +[API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 +[스케줄러](/docs/reference/generated/kube-scheduler/)에서 +`EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다 +{{< /note >}} diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index a70374295f..30c0979969 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -6,7 +6,7 @@ weight: 20 -SIG Docs [승인자](/ko/docs/contribute/participating/roles-and-responsibilites/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. +SIG Docs [승인자](/ko/docs/contribute/participate/roles-and-responsibilities/#승인자)는 리포지터리에 대해 일주일 동안 교대로 [풀 리퀘스트 관리](https://github.com/kubernetes/website/wiki/PR-Wranglers)를 수행한다. 이 섹션은 PR 랭글러의 의무에 대해 다룬다. 좋은 리뷰 제공에 대한 자세한 내용은 [Reviewing changes](/ko/docs/contribute/review/)를 참고한다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index 86c67f4b06..8f2f5c48a6 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -16,8 +16,8 @@ content_type: concept ## API 레퍼런스 -* [쿠버네티스 API 개요](/ko/docs/reference/using-api/api-overview/) - 쿠버네티스 API에 대한 개요 -* [Kubernetes API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 레퍼런스 {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) +* [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 ## API 클라이언트 라이브러리 @@ -34,7 +34,7 @@ content_type: concept * [kubectl](/ko/docs/reference/kubectl/overview/) - 명령어를 실행하거나 쿠버네티스 클러스터를 관리하기 위해 사용하는 주된 CLI 도구. * [JSONPath](/docs/reference/kubectl/jsonpath/) - kubectl에서 [JSONPath 표현](https://goessner.net/articles/JsonPath/)을 사용하기 위한 문법 가이드. -* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. +* [kubeadm](/ko/docs/reference/setup-tools/kubeadm/) - 안정적인 쿠버네티스 클러스터를 쉽게 프로비전하기 위한 CLI 도구. ## 컴포넌트 레퍼런스 diff --git a/content/ko/docs/reference/access-authn-authz/_index.md b/content/ko/docs/reference/access-authn-authz/_index.md index c075922ad1..9e23c5d767 100644 --- a/content/ko/docs/reference/access-authn-authz/_index.md +++ b/content/ko/docs/reference/access-authn-authz/_index.md @@ -1,4 +1,26 @@ --- -title: API 접근하기 +title: API 접근 제어 weight: 20 ---- \ No newline at end of file +no_list: true +--- + +쿠버네티스가 API 접근을 구현 및 제어하는 방법에 대한 자세한 내용은 +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고한다. + +참조 문헌 + +- [인증](/docs/reference/access-authn-authz/authentication/) + - [부트스트랩 토큰 인증](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [승인 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/) + - [동적 승인 제어](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [인가](/ko/docs/reference/access-authn-authz/authorization/) + - [역할 기반 접근 제어](/docs/reference/access-authn-authz/rbac/) + - [속성 기반 접근 제어](/docs/reference/access-authn-authz/abac/) + - [노드 인가](/docs/reference/access-authn-authz/node/) + - [웹훅 인가](/docs/reference/access-authn-authz/webhook/) +- [인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) + - [CSR 승인](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)과 + [인증서 서명](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)을 포함함 +- 서비스 어카운트 + - [개발자 가이드](/docs/tasks/configure-pod-container/configure-service-account/) + - [관리](/ko/docs/reference/access-authn-authz/service-accounts-admin/) diff --git a/content/ko/docs/reference/access-authn-authz/authorization.md b/content/ko/docs/reference/access-authn-authz/authorization.md index 3fe13d7ced..40d0a37c92 100644 --- a/content/ko/docs/reference/access-authn-authz/authorization.md +++ b/content/ko/docs/reference/access-authn-authz/authorization.md @@ -11,7 +11,7 @@ weight: 60 쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다. -인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)를 +인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)를 참고한다. 쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다. @@ -47,7 +47,7 @@ weight: 60 * **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다. * **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당). * **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당) - * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/reference/using-api/api-overview/#api-그룹)을 지정한다. + * **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 _핵심(core)_ [API 그룹](/ko/docs/reference/using-api/#api-그룹)을 지정한다. ## 요청 동사 결정 @@ -197,5 +197,5 @@ status: ## {{% heading "whatsnext" %}} -* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다. +* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access/)에서 **인증** 을 참조한다. * 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 11dc7f26b6..f5b7fa8dad 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -485,7 +485,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. -- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/configuration/pod-overhead/) 기능을 활성화한다. +- `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. - `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 @@ -511,7 +511,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) 기능을 활성화한다. - `ScheduleDaemonSetPods`: 데몬셋(DaemonSet) 컨트롤러 대신 기본 스케줄러로 데몬셋 파드를 스케줄링할 수 있다. - `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서 _SCTP_ `protocol` 값을 활성화한다. -- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/api-concepts/#server-side-apply) 경로를 활성화한다. +- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/) 경로를 활성화한다. - `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. - `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md new file mode 100644 index 0000000000..565c3b4faf --- /dev/null +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -0,0 +1,343 @@ +--- +title: kube-proxy +content_type: tool-reference +weight: 30 +--- + +## {{% heading "synopsis" %}} + + +쿠버네티스 네트워크 프록시는 각 노드에서 실행된다. +이는 각 노드의 쿠버네티스 API에 정의된 서비스를 반영하며 단순한 +TCP, UDP 및 SCTP 스트림 포워딩 또는 라운드 로빈 TCP, UDP 및 SCTP 포워딩을 백엔드 셋에서 수행 할 수 있다. +서비스 클러스트 IP 및 포트는 현재 서비스 프록시에 의해 열린 포트를 지정하는 +Docker-links-compatible 환경 변수를 통해 찾을 수 있다. +이러한 클러스터 IP에 클러스터 DNS를 제공하는 선택적 애드온이 있다. 유저는 apiserver API로 +서비스를 생성하여 프록시를 구성해야 한다. + +``` +kube-proxy [flags] +``` + +## {{% heading "options" %}} + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--azure-container-registry-config string
Azure 컨테이너 레지스트리 구성 정보가 들어 있는 파일의 경로.
--bind-address ip     기본값: 0.0.0.0
프록시 서버가 서비스할 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0'으로 설정, 모든 IPv6 인터페이스의 경우 '::'로 설정)
--bind-address-hard-fail
true인 경우 kube-proxy는 포트 바인딩 실패를 치명적인 것으로 간주하고 종료한다.
--cleanup
true인 경우 iptables 및 ipvs 규칙을 제거하고 종료한다.
--cluster-cidr string
클러스터에 있는 파드의 CIDR 범위. 구성 후에는 이 범위 밖에서 서비스 클러스터 IP로 전송되는 트래픽은 마스커레이드되고 파드에서 외부 LoadBalancer IP로 전송된 트래픽은 대신 해당 클러스터 IP로 전송된다
--config string
설정 파일의 경로.
--config-sync-period duration     기본값: 15m0s
apiserver의 설정이 갱신되는 빈도. 0보다 커야 한다.
--conntrack-max-per-core int32     기본값: 32768
CPU 코어당 추적할 최대 NAT 연결 수(한도(limit)를 그대로 두고 contrack-min을 무시하려면 0으로 설정한다)(
--conntrack-min int32     기본값: 131072
conntrack-max-per-core와 관계없이 할당할 최소 conntrack 항목 수(한도를 그대로 두려면 conntrack-max-per-core값을 0으로 설정).
--conntrack-tcp-timeout-close-wait duration     기본값: 1h0m0s
CLOSE_WAIT 상태의 TCP 연결에 대한 NAT 시간 초과
--conntrack-tcp-timeout-established duration     기본값: 24h0m0s
설정된 TCP 연결에 대한 유휴시간 초과(값이 0이면 그대로 유지)
--detect-local-mode LocalMode
로컬 트래픽을 탐지하는 데 사용할 모드
--feature-gates mapStringBool
알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍 집합. 옵션은 다음과 같다.
APIListChunking=true|false (BETA - 기본값=true)
APIPriorityAndFairness=true|false (ALPHA - 기본값=false)
APIResponseCompression=true|false (BETA - 기본값=true)
AllAlpha=true|false (ALPHA - 기본값=false)
AllBeta=true|false (BETA - 기본값=false)
AllowInsecureBackendProxy=true|false (BETA - 기본값=true)
AnyVolumeDataSource=true|false (ALPHA - 기본값=false)
AppArmor=true|false (BETA - 기본값=true)
BalanceAttachedNodeVolumes=true|false (ALPHA - 기본값=false)
BoundServiceAccountTokenVolume=true|false (ALPHA - 기본값=false)
CPUManager=true|false (BETA - 기본값=true)
CRIContainerLogRotation=true|false (BETA - 기본값=true)
CSIInlineVolume=true|false (BETA - 기본값=true)
CSIMigration=true|false (BETA - 기본값=true)
CSIMigrationAWS=true|false (BETA - 기본값=false)
CSIMigrationAWSComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureDisk=true|false (BETA - 기본값=false)
CSIMigrationAzureDiskComplete=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFile=true|false (ALPHA - 기본값=false)
CSIMigrationAzureFileComplete=true|false (ALPHA - 기본값=false)
CSIMigrationGCE=true|false (BETA - 기본값=false)
CSIMigrationGCEComplete=true|false (ALPHA - 기본값=false)
CSIMigrationOpenStack=true|false (BETA - 기본값=false)
CSIMigrationOpenStackComplete=true|false (ALPHA - 기본값=false)
CSIMigrationvSphere=true|false (BETA - 기본값=false)
CSIMigrationvSphereComplete=true|false (BETA - 기본값=false)
CSIStorageCapacity=true|false (ALPHA - 기본값=false)
CSIVolumeFSGroupPolicy=true|false (ALPHA - 기본값=false)
ConfigurableFSGroupPolicy=true|false (ALPHA - 기본값=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - 기본값=false)
DefaultPodTopologySpread=true|false (ALPHA - 기본값=false)
DevicePlugins=true|false (BETA - 기본값=true)
DisableAcceleratorUsageMetrics=true|false (ALPHA - 기본값=false)
DynamicKubeletConfig=true|false (BETA - 기본값=true)
EndpointSlice=true|false (BETA - 기본값=true)
EndpointSliceProxying=true|false (BETA - 기본값=true)
EphemeralContainers=true|false (ALPHA - 기본값=false)
ExpandCSIVolumes=true|false (BETA - 기본값=true)
ExpandInUsePersistentVolumes=true|false (BETA - 기본값=true)
ExpandPersistentVolumes=true|false (BETA - 기본값=true)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 기본값=false)
GenericEphemeralVolume=true|false (ALPHA - 기본값=false)
HPAScaleToZero=true|false (ALPHA - 기본값=false)
HugePageStorageMediumSize=true|false (BETA - 기본값=true)
HyperVContainer=true|false (ALPHA - 기본값=false)
IPv6DualStack=true|false (ALPHA - 기본값=false)
ImmutableEphemeralVolumes=true|false (BETA - 기본값=true)
KubeletPodResources=true|false (BETA - 기본값=true)
LegacyNodeRoleBehavior=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolation=true|false (BETA - 기본값=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 기본값=false)
NodeDisruptionExclusion=true|false (BETA - 기본값=true)
NonPreemptingPriority=true|false (BETA - 기본값=true)
PodDisruptionBudget=true|false (BETA - 기본값=true)
PodOverhead=true|false (BETA - 기본값=true)
ProcMountType=true|false (ALPHA - 기본값=false)
QOSReserved=true|false (ALPHA - 기본값=false)
RemainingItemCount=true|false (BETA - 기본값=true)
RemoveSelfLink=true|false (ALPHA - 기본값=false)
RotateKubeletServerCertificate=true|false (BETA - 기본값=true)
RunAsGroup=true|false (BETA - 기본값=true)
RuntimeClass=true|false (BETA - 기본값=true)
SCTPSupport=true|false (BETA - 기본값=true)
SelectorIndex=true|false (BETA - 기본값=true)
ServerSideApply=true|false (BETA - 기본값=true)
ServiceAccountIssuerDiscovery=true|false (ALPHA - 기본값=false)
ServiceAppProtocol=true|false (BETA - 기본값=true)
ServiceNodeExclusion=true|false (BETA - 기본값=true)
ServiceTopology=true|false (ALPHA - 기본값=false)
SetHostnameAsFQDN=true|false (ALPHA - 기본값=false)
StartupProbe=true|false (BETA - 기본값=true)
StorageVersionHash=true|false (BETA - 기본값=true)
SupportNodePidsLimit=true|false (BETA - 기본값=true)
SupportPodPidsLimit=true|false (BETA - 기본값=true)
Sysctls=true|false (BETA - 기본값=true)
TTLAfterFinished=true|false (ALPHA - 기본값=false)
TokenRequest=true|false (BETA - 기본값=true)
TokenRequestProjection=true|false (BETA - 기본값=true)
TopologyManager=true|false (BETA - 기본값=true)
ValidateProxyRedirects=true|false (BETA - 기본값=true)
VolumeSnapshotDataSource=true|false (BETA - 기본값=true)
WarningHeaders=true|false (BETA - 기본값=true)
WinDSR=true|false (ALPHA - 기본값=false)
WinOverlay=true|false (ALPHA - 기본값=false)
WindowsEndpointSliceProxying=true|false (ALPHA - 기본값=false)
--healthz-bind-address ipport     기본값: 0.0.0.0:10256
헬스 체크 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4의 인터페이스의 경우 '0.0.0.0:10256', 모든 IPv6의 인터페이스인 경우 '[::]:10256'로 설정). 사용 안 할 경우 빈칸으로 둠.
-h, --help
kube-proxy에 대한 도움말.
--hostname-override string
문자열 값이 있으면, 이 값을 실제 호스트네임 대신에 ID로 사용한다.
--iptables-masquerade-bit int32     기본값: 14
순수 iptable 프록시를 사용하는 경우 SNAT가 필요한 패킷을 표시하는 fwmark 스페이스 비트. [0, 31] 범위 안에 있어야 한다.
--iptables-min-sync-period duration     기본값: 1s
엔드포인트 및 서비스가 변경될 때 iptable 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').
--iptables-sync-period duration     기본값: 30s
iptable 규칙을 새로 고치는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.
--ipvs-exclude-cidrs stringSlice
IPVS 규칙을 정리할 때 ipvs 프록시가 건드리지 않아야 하는 쉼표로 구분된 CIDR 목록.
--ipvs-min-sync-period duration
엔드포인트 및 서비스가 변경될 때 ipvs 규칙을 새로 고칠 수 있는 빈도의 최소 간격(예: '5s', '1m', '2h22m').
--ipvs-scheduler string
프록시 모드가 ipvs인 경우 ipvs 스케줄러 유형.
--ipvs-strict-arp
arp_ignore를 1로 설정하고 arp_annotes를 2로 설정하여 엄격한 ARP를 사용.
--ipvs-sync-period duration     기본값: 30s
ipvs 규칙이 새로 갱신되는 빈도의 최대 간격(예: '5s', '1m', '2h22m'). 0 보다 커야 한다.
--ipvs-tcp-timeout duration
유휴 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--ipvs-tcpfin-timeout duration
FIN 패킷을 수신한 후 IPVS TCP 연결에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--ipvs-udp-timeout duration
IPVS UDP 패킷에 대한 시간 초과. 0이면 그대로 유지(예: '5s', '1m', '2h22m').
--kube-api-burst int32     기본값: 10
쿠버네티스 api 서버와 통신하는 동안 사용할 burst.
--kube-api-content-type string     기본값: "application/vnd.kubernetes.protobuf"
api 서버에 보낸 요청의 내용 유형.
--kube-api-qps float32     기본값: 5
쿠버네티스 api 서버와 통신할 때 사용할 QPS.
--kubeconfig string
인증 정보가 있는 kubeconfig 파일의 경로(마스터 위치는 마스터 플래그로 설정됨).
--log-flush-frequency duration     기본값: 5s
로그 플러시 사이의 최대 시간
--masquerade-all
순수 iptables 프록시를 사용하는 경우 서비스 클러스터 IP를 통해 전송된 모든 트래픽을 SNAT함(일반적으로 필요하지 않음).
--master string
쿠버네티스 API 서버의 주소(kubeconfig의 모든 값 덮어쓰기).
--metrics-bind-address ipport     기본값: 127.0.0.1:10249
메트릭 서버가 서비스할 포트가 있는 IP 주소(모든 IPv4 인터페이스의 경우 '0.0.0.0:10249', 모든 IPv6 인터페이스의 경우 '[::]:10249'로 설정됨). 사용하지 않으려면 비워둘 것.
--nodeport-addresses stringSlice
NodePort에 사용할 주소를 지정하는 값의 문자열 조각. 값은 유효한 IP 블록(예: 1.2.3.0/24, 1.2.3.4/32). 기본값인 빈 문자열 조각값은([]) 모든 로컬 주소를 사용하는 것을 의미한다.
--oom-score-adj int32     기본값: -999
kube-proxy 프로세스에 대한 oom-score-adj 값. 값은 [-1000, 1000] 범위 내에 있어야 한다.
--profiling
값이 true이면 /debug/pprof 핸들러에서 웹 인터페이스를 통한 프로파일링을 활성화한다.
--proxy-mode ProxyMode
사용할 프록시 모드: 'userspace' (이전) or 'iptables' (빠름) or 'ipvs' or 'kernelspace' (윈도우). 공백인 경우 가장 잘 사용할 수 있는 프록시(현재는 iptables)를 사용한다. iptables 프록시를 선택했지만, 시스템의 커널 또는 iptables 버전이 맞지 않으면, 항상 userspace 프록시로 변경된다.
--proxy-port-range port-range
서비스 트래픽을 프록시하기 위해 사용할 수 있는 호스트 포트 범위(beginPort-endPort, single port 또는 beginPort+offset 포함). 만약 범위가 0, 0-0, 혹은 지정되지 않으면, 포트는 무작위로 선택된다.
--show-hidden-metrics-for-version string
숨겨진 메트릭을 표시할 이전 버전.
--udp-timeout duration     기본값: 250ms
유휴 UDP 연결이 열린 상태로 유지되는 시간(예: '250ms', '2s'). 값은 0보다 커야 한다. 프록시 모드 userspace에만 적용 가능함.
--version version[=true]
버전 정보를 인쇄하고 종료.
--write-config-to string
기본 구성 값을 이 파일에 옮겨쓰고 종료한다.
+ + + diff --git a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md index 61f0b35d1f..6f9060dba4 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md +++ b/content/ko/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md @@ -5,7 +5,7 @@ title: Kubelet 인증/인가 ## 개요 -kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 노출시키며, +kubelet의 HTTPS 엔드포인트는 다양한 민감도의 데이터에 대한 접근을 제공하는 API를 노출하며, 노드와 컨테이너 내에서 다양한 수준의 권한으로 작업을 수행할 수 있도록 허용한다. 이 문서는 kubelet의 HTTPS 엔드포인트에 대한 접근을 인증하고 인가하는 방법을 설명한다. diff --git a/content/ko/docs/reference/glossary/container-lifecycle-hooks.md b/content/ko/docs/reference/glossary/container-lifecycle-hooks.md new file mode 100644 index 0000000000..7b1ebd27a4 --- /dev/null +++ b/content/ko/docs/reference/glossary/container-lifecycle-hooks.md @@ -0,0 +1,17 @@ +--- +title: 컨테이너 라이프사이클 훅(Container Lifecycle Hooks) +id: container-lifecycle-hooks +date: 2018-10-08 +full_link: /ko/docs/concepts/containers/container-lifecycle-hooks/ +short_description: > + 라이프사이클 훅은 컨테이너 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다. + +aka: +tags: +- extension +--- + 라이프사이클 훅은 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 관리 라이프사이클에 이벤트를 노출하고 이벤트가 발생할 때 사용자가 코드를 실행할 수 있도록 한다. + + + +컨테이너에는 두 개의 훅(컨테이너가 생성된 직후에 실행되는 PostStart와 컨테이너가 종료되기 직전에 차단되고 호출되는 PreStop)이 노출된다. diff --git a/content/ko/docs/reference/glossary/container.md b/content/ko/docs/reference/glossary/container.md index 2420a42112..9d01041f9e 100755 --- a/content/ko/docs/reference/glossary/container.md +++ b/content/ko/docs/reference/glossary/container.md @@ -2,7 +2,7 @@ title: 컨테이너(Container) id: container date: 2018-04-12 -full_link: /ko/docs/concepts/overview/what-is-kubernetes/#왜-컨테이너인가 +full_link: /ko/docs/concepts/containers/ short_description: > 소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지. diff --git a/content/ko/docs/reference/kubectl/jsonpath.md b/content/ko/docs/reference/kubectl/jsonpath.md new file mode 100644 index 0000000000..4a910829f8 --- /dev/null +++ b/content/ko/docs/reference/kubectl/jsonpath.md @@ -0,0 +1,113 @@ +--- +title: JSONPath 지원 +content_type: concept +weight: 25 +--- + + +Kubectl은 JSONPath 템플릿을 지원한다. + + + + +JSONPath 템플릿은 중괄호 {}로 둘러싸인 JSONPath 표현식으로 구성된다. +Kubectl은 JSONPath 표현식을 사용하여 JSON 오브젝트의 특정 필드를 필터링하고 출력 형식을 지정한다. +원본 JSONPath 템플릿 구문 외에도 다음과 같은 기능과 구문이 유효하다. + +1. 큰따옴표를 사용하여 JSONPath 표현식 내부의 텍스트를 인용한다. +2. 목록을 반복하려면 `range`, `end` 오퍼레이터를 사용한다. +3. 목록에서 뒤로 이동하려면 negative slice 인덱스를 사용한다. negative 인덱스는 목록을 "순환(wrap around)" 하지 않으며, `-index + listLength >= 0` 인 한 유효하다. + +{{< note >}} + +- 표현식은 항상 루트 오브젝트에서 시작하므로 `$` 오퍼레이터는 선택 사항이다. + +- 결과 오브젝트는 String() 함수로 출력된다. + +{{< /note >}} + +JSON 입력 시 다음과 같다. + +```json +{ + "kind": "List", + "items":[ + { + "kind":"None", + "metadata":{"name":"127.0.0.1"}, + "status":{ + "capacity":{"cpu":"4"}, + "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}] + } + }, + { + "kind":"None", + "metadata":{"name":"127.0.0.2"}, + "status":{ + "capacity":{"cpu":"8"}, + "addresses":[ + {"type": "LegacyHostIP", "address":"127.0.0.2"}, + {"type": "another", "address":"127.0.0.3"} + ] + } + } + ], + "users":[ + { + "name": "myself", + "user": {} + }, + { + "name": "e2e", + "user": {"username": "admin", "password": "secret"} + } + ] +} +``` + +Function | Description | Example | Result +--------------------|---------------------------|-----------------------------------------------------------------|------------------ +`text` | 일반 텍스트 | `kind is {.kind}` | `kind is List` +`@` | 현재 오브젝트 | `{@}` | 입력과 동일 +`.` or `[]` | 자식 오퍼레이터 | `{.kind}`, `{['kind']}` or `{['name\.type']}` | `List` +`..` | 재귀 하향(recursive descent)| `{..name}` | `127.0.0.1 127.0.0.2 myself e2e` +`*` | 와일드 카드. 모든 오브젝트 가져오기 | `{.items[*].metadata.name}` | `[127.0.0.1 127.0.0.2]` +`[start:end:step]` | 아래 첨자 오퍼레이터 | `{.users[0].name}` | `myself` +`[,]` | 조합 오퍼레이터 | `{.items[*]['metadata.name', 'status.capacity']}` | `127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]` +`?()` | 필터 | `{.users[?(@.name=="e2e")].user.password}` | `secret` +`range`, `end` | 반복 목록 | `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}` | `[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]` +`''` | 해석된 문자열 인용 | `{range .items[*]}{.metadata.name}{'\t'}{end}` | `127.0.0.1 127.0.0.2` + +`kubectl` 및 JSONPath 표현식을 사용하는 예는 다음과 같다. + +```shell +kubectl get pods -o json +kubectl get pods -o=jsonpath='{@}' +kubectl get pods -o=jsonpath='{.items[0]}' +kubectl get pods -o=jsonpath='{.items[0].metadata.name}' +kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}" +kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}' +``` + +{{< note >}} +윈도우에서 공백이 포함된 JSONPath 템플릿을 큰따옴표(위의 bash에 표시된 작은따옴표가 아님)로 묶어야 한다. 즉, 템플릿의 모든 문자 주변에 작은따옴표 또는 이스케이프된 큰따옴표를 사용해야 한다. 예를 들면, 다음과 같다. + +```cmd +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}" +kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}" +``` +{{< /note >}} + +{{< note >}} + +JSONPath 정규식은 지원되지 않는다. 정규 표현식을 이용해 매치하려면 `jq`와 같은 도구를 사용하면 된다. + +```shell +# kubectl은 JSONPath 출력에 대한 정규 표현식을 지원하지 않는다. +# 다음 커맨드는 작동하지 않는다. +kubectl get pods -o jsonpath='{.items[?(@.metadata.name=~/^test$/)].metadata.name}' + +# 다음 커맨드는 원하는 결과를 얻는다. +kubectl get pods -o json | jq -r '.items[] | select(.metadata.name | test("test-")).spec.containers[].image' +``` +{{< /note >}} diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md new file mode 100644 index 0000000000..0f3f120d77 --- /dev/null +++ b/content/ko/docs/reference/scheduling/config.md @@ -0,0 +1,253 @@ +--- +title: 스케줄러 구성 +content_type: concept +weight: 20 +--- + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +구성 파일을 작성하고 해당 경로를 커맨드 라인 인수로 전달하여 +`kube-scheduler` 의 동작을 사용자 정의할 수 있다. + + + + + +스케줄링 프로파일(Profile)을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서 +여러 단계의 스케줄링을 구성할 수 있다. +각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 +익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. + +컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) +또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를 +사용하고, `kube-scheduler --config `을 실행하여 +스케줄링 프로파일을 지정할 수 있다. +`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을 +실행하도록 kube-scheduler를 구성할 수 있다. + +최소 구성은 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +clientConnection: + kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig +``` + +## 프로파일 + +스케줄링 프로파일을 사용하면 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}에서 +여러 단계의 스케줄링을 구성할 수 있다. +각 단계는 [익스텐션 포인트](#익스텐션-포인트)에 노출된다. +[플러그인](#스케줄링-플러그인)은 이러한 익스텐션 포인트 중 +하나 이상을 구현하여 스케줄링 동작을 제공한다. + +`kube-scheduler` 의 단일 인스턴스를 구성하여 +[여러 프로파일](#여러-프로파일)을 실행할 수 있다. + +### 익스텐션 포인트 + +스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서 +발생한다. + +1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를 + 정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다. + 사용할 수 있다. +1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를 + 사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로 + 표시할 수 있다. +1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며 + 파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는 + 구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로 + 표시된다. +1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는 + 정보성 익스텐션 포인트이다. +1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를 + 제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은 + 노드를 선택한다. +1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에 + 알리는 정보성 익스텐션 포인트이다. 플러그인은 또한 + `Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을 + 구현한다. +1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다. +1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다. +1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며 + 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind + 플러그인은 적어도 하나 이상 필요하다. +1. `PostBind`: 파드가 바인드된 후 호출되는 + 정보성 익스텐션 포인트이다. + +각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나 +자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: + - plugins: + score: + disabled: + - name: NodeResourcesLeastAllocated + enabled: + - name: MyCustomPluginA + weight: 2 + - name: MyCustomPluginB + weight: 1 +``` + +비활성화된 배열의 이름으로 `*` 를 사용하여 해당 익스텐션 포인트에 대한 +모든 기본 플러그인을 비활성화할 수 있다. 원하는 경우, 플러그인 순서를 재정렬하는 데 +사용할 수도 있다. + +### 스케줄링 플러그인 + +1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우 + 호출되는 정보성 익스텐션 포인트이다. + +## 스케줄링 플러그인 + +기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중 +하나 이상을 구현한다. + +- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}}, + {{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및 + {{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에 + 속하는 파드에 대해 노드 간 분산을 선호한다. + 익스텐션 포인트: `PreScore`, `Score`. +- `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 + 구현한다. + 익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`. +- `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다. + 익스텐션 포인트: `Filter`. +- `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`. +- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}} + `scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라 + 노드 점수를 매긴다. + 익스텐션 포인트: `Score`. +- `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 + [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를 + 구현한다. + 익스텐션 포인트: `Filter`, `Score`. +- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를 + 구현한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. +- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를 + 필터링한다. + 익스텐션 포인트: `Filter`. +- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지 + 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`. +- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을 + 얻을 수 있는 노드를 선호한다. + 익스텐션 포인트: `Score`. +- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지 + 또는 바인딩할 수 있는지 확인한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`. +- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 + 제한 사항을 충족하는지 확인한다. + 익스텐션 포인트: `Filter`. +- `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다. + 익스텐션 포인트: `Filter`. +- `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다. + 익스텐션 포인트: `Filter`. +- `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를 + 구현한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`. +- `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다. + 익스텐션 포인트: `QueueSort`. +- `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다. + 익스텐션 포인트: `Bind`. +- `DefaultPreemption`: 기본 선점 메커니즘을 제공한다. + 익스텐션 포인트: `PostFilter`. + +기본으로 활성화되지 않는 다음의 플러그인을 +컴포넌트 구성 API를 통해 활성화할 수도 있다. + +- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를 + 선호한다. + 익스텐션 포인트: `Score`. +- `NodeResourceLimits`: 파드 리소스 제한을 충족하는 노드를 선호한다. + 익스텐션 포인트: `PreScore`, `Score`. +- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지 + 확인한다. + 익스텐션 포인트: `Filter`. +- `NodeLabel`: Filters and / or scores a node according to configured + {{< glossary_tooltip text="label(s)" term_id="label" >}}. + 익스텐션 포인트: `Filter`, `Score`. +- `ServiceAffinity`: {{< glossary_tooltip text="서비스" term_id="service" >}}에 + 속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지 + 확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에 + 분산하는 것을 선호한다. + 익스텐션 포인트: `PreFilter`, `Filter`, `Score`. + +### 여러 프로파일 + +둘 이상의 프로파일을 실행하도록 `kube-scheduler` 를 구성할 수 있다. +각 프로파일에는 연관된 스케줄러 이름이 있으며 [익스텐션 포인트](#익스텐션-포인트)에 구성된 +다른 플러그인 세트를 가질 수 있다. + +다음의 샘플 구성을 사용하면, 스케줄러는 기본 플러그인이 있는 +프로파일과 모든 스코어링 플러그인이 비활성화된 프로파일의 두 가지 프로파일로 +실행된다. + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: + - schedulerName: default-scheduler + - schedulerName: no-scoring-scheduler + plugins: + preScore: + disabled: + - name: '*' + score: + disabled: + - name: '*' +``` + +특정 프로파일에 따라 스케줄하려는 파드는 +`.spec.schedulerName` 에 해당 스케줄러 이름을 포함할 수 있다. + +기본적으로, 스케줄러 이름 `default-scheduler` 를 가진 하나의 프로파일이 생성된다. +이 프로파일에는 위에서 설명한 기본 플러그인이 포함되어 있다. 둘 이상의 +프로파일을 선언할 때, 각각에 대한 고유한 스케줄러 이름이 필요하다. + +파드가 스케줄러 이름을 지정하지 않으면, kube-apiserver는 이를 `default-scheduler` 로 +설정한다. 따라서, 해당 파드를 스케줄하려면 이 스케줄러 이름을 가진 프로파일이 +있어야 한다. + +{{< note >}} +파드의 스케줄링 이벤트에는 ReportingController로 `.spec.schedulerName` 이 있다. +리더 선출을 위한 이벤트는 목록에서 첫 번째 프로파일의 스케줄러 이름을 +사용한다. +{{< /note >}} + +{{< note >}} +모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며 +동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을 +단 하나만 가질 수 있기 때문이다. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 +* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 diff --git a/content/ko/docs/reference/tools.md b/content/ko/docs/reference/tools.md index ceac0a5101..ac0a5fb6c5 100644 --- a/content/ko/docs/reference/tools.md +++ b/content/ko/docs/reference/tools.md @@ -20,7 +20,7 @@ content_type: concept ## Minikube -[`minikube`](/ko/docs/tasks/tools/install-minikube/)는 개발과 테스팅 목적으로 하는 +[`minikube`](https://minikube.sigs.k8s.io/docs/)는 개발과 테스팅 목적으로 하는 단일 노드 쿠버네티스 클러스터를 로컬 워크스테이션에서 쉽게 구동시키는 도구이다. @@ -44,7 +44,7 @@ Helm의 용도 ## Kompose -[`Kompose`](https://github.com/kubernetes-incubator/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다. +[`Kompose`](https://github.com/kubernetes/kompose)는 도커 컴포즈 유저들이 쿠버네티스로 이동하는데 도움이 되는 도구이다. Kompose의 용도 diff --git a/content/ko/docs/reference/using-api/_index.md b/content/ko/docs/reference/using-api/_index.md index 7751aef2f4..427cebf529 100644 --- a/content/ko/docs/reference/using-api/_index.md +++ b/content/ko/docs/reference/using-api/_index.md @@ -1,4 +1,121 @@ --- -title: 쿠버네티스 API 사용하기 +title: 쿠버네티스 API 개요 +content_type: concept weight: 10 +card: + name: 레퍼런스 + weight: 50 + title: API 개요 --- + + + +이 섹션은 쿠버네티스 API에 대한 참조 정보를 제공한다. + +REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, +컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 +REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 +API 오브젝트로 취급되고, +[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다. + +[쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)는 +쿠버네티스 버전 {{< param "version" >}}에 대한 API가 나열되어 있다. + +일반적인 배경 정보를 보려면, +[쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)를 참고한다. +[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)는 +클라이언트가 쿠버네티스 API 서버에 인증하는 방법과 +요청이 승인되는 방법을 설명한다. + + +## API 버전 규칙 + +JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 +동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. + +API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. +[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 +API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. + +API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. +[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 +각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. + +아래는 각 수준의 기준에 대한 요약이다. + +- 알파(Alpha): + - 버전 이름에 `alpha`가 포함된다(예: `v1alpha1`). + - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그에 노출될 수 있다. + 기본적으로 비활성화되어 있다. + - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. + - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. + - 버그에 대한 위험이 높고 장기간 지원되지 않으므로 + 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. + +- 베타(Beta): + - 버전 이름에 `beta`가 포함된다(예: `v2beta3`). + - 코드가 잘 테스트 되었다. 이 기능을 활성화해도 안전하다. + 기본적으로 활성화되어 있다. + - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. + + - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 + 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 + 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 + 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. + 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. + - 이 소프트웨어는 프로덕션 용도로 권장하지 않는다. 이후 여러 버전에서 + 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 + 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. + + {{< note >}} + 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 + 실질적으로 더 많은 변경이 어렵다. + {{< /note >}} + +- 안정화(Stable): + - 버전 이름이 `vX`이고 `X` 는 정수다. + - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. + +## API 그룹 + +[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 +쿠버네티스 API를 더 쉽게 확장하게 해준다. +API 그룹은 REST 경로와 직렬화된 오브젝트의 `apiVersion` 필드에 +명시된다. + +쿠버네티스에는 다음과 같은 다양한 API 그룹이 있다. + +* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다. + 핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를 + 들어, `apiVersion: v1` 과 같다. +* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 + `apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`). + 지원되는 API 그룹 전체의 목록은 + [쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#-strong-api-groups-strong-)에서 확인할 수 있다. + +## API 그룹 활성화 또는 비활성화 + +특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 +`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다. +`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는 +쉼표로 구분된 `=` 쌍을 허용한다. 만약 `=` +부분을 생략하면, `=true` 가 명시된 것처럼 취급한다. 예를 들면, 다음과 같다. + + - `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정 + - `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정 + +{{< note >}} +그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 +`--runtime-config` 변경을 반영해야 한다. +{{< /note >}} + +## 지속성 + +쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서 +직렬화된 상태를 저장한다. + +## {{% heading "whatsnext" %}} + +- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기 +- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에 + 대한 디자인 문서 읽기 diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md deleted file mode 100644 index 4bf982fc1b..0000000000 --- a/content/ko/docs/reference/using-api/api-overview.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: 쿠버네티스 API 개요 -content_type: concept -weight: 10 -card: - name: 레퍼런스 - weight: 50 - title: API 개요 ---- - - - -이 페이지는 쿠버네티스 API에 대한 개요를 제공한다. - - - - -REST API는 쿠버네티스의 근본적인 구조이다. 모든 조작, -컴포넌트 간의 통신과 외부 사용자의 명령은 API 서버에서 처리할 수 있는 -REST API 호출이다. 따라서, 쿠버네티스 플랫폼 안의 모든 것은 -API 오브젝트로 취급되고, -[API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에 상응하는 항목이 있다. - -## API 버전 규칙 - -JSON과 Protobuf 직렬화 스키마 모두 스키마 변경에 대해서 -동일한 가이드라인을 따른다. 이후 설명에서는 이 형식 모두를 다룬다. - -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관된다. -[API와 릴리스 버전 부여에 관한 제안](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 -API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. - -API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. -[API 변경 문서](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 -각 수준의 기준에 대한 더 많은 정보를 찾을 수 있다. - -아래는 각 수준의 기준에 대한 요약이다. - -- 알파(Alpha) 수준: - - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) - - 버그가 있을 수도 있다. 이 기능을 활성화하면 버그가 노출될 수 있다. - 기본적으로 비활성화되어 있다. - - 기능에 대한 기술 지원이 언제든 공지 없이 중단될 수 있다. - - 다음 소프트웨어를 릴리스할 때 공지 없이 API의 호환성이 깨지는 방식으로 변경될 수 있다. - - 버그의 위험이 높고 장기간 지원되지 않으므로 - 단기간 테스트 용도의 클러스터에서만 사용하기를 권장한다. - -- 베타(Beta) 수준: - - 버전 이름에 `beta`가 포함된다. (예: `v2beta3`). - - 코드가 잘 테스트되었다. 이 기능을 활성화 시켜도 안전하다. - 기본적으로 활성화되어 있다. - - 구체적인 내용이 바뀔 수는 있지만, 전반적인 기능에 대한 기술 지원이 중단되지 않는다. - - - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 - 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 - 이관할 수 있는 가이드가 제공된다. 스키마 변경은 API 오브젝트의 삭제, 편집 또는 재생성이 - 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. - 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. - - 이 소프트웨어는 프로덕션 용도로 권장되지 않는다. 이후 여러 버전에서 - 호환되지 않는 변경 사항이 적용될 수 있다. 복수의 클러스터를 가지고 있어서 - 독립적으로 업그레이드할 수 있다면, 이런 제약에서 벗어날 수도 있다. - - {{< note >}} - 베타 기능을 사용해보고 피드백을 제공하자. 기능이 베타 수준을 벗어난 이후에는 - 실질적으로 더 많은 변경이 어렵다. - {{< /note >}} - -- 안정화(stable) 수준: - - 버전 이름이 `vX`이고 `X` 는 정수다. - - 안정화 버전의 기능은 이후 여러 버전에 걸쳐서 소프트웨어 릴리스에 포함된다. - -## API 그룹 - -[API 그룹](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)은 -쿠버네티스 API를 더 쉽게 확장하게 해준다. -API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 -명시된다. - -현재 다음과 같은 다양한 API 그룹이 사용되고 있다. - -* *핵심* (또는 *레거시* 라고 불리는) 그룹은 REST 경로 `/api/v1`에 있다. - 핵심 그룹은 `apiVersion` 필드의 일부로 명시되지 않는다. 예를 - 들어, `apiVersion: v1` 와 같다. -* 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 - `apiVersion: $GROUP_NAME/$VERSION`을 사용한다(예를 들어, `apiVersion: batch/v1`). - 지원되는 API 그룹 전체의 목록은 - [쿠버네티스 API 참조 문서](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)에서 확인할 수 있다. - -## API 그룹 활성화 또는 비활성화 {#enabling-or-disabling} - -특정 리소스 및 API 그룹은 기본적으로 활성화된다. API 서버에서 -`--runtime-config` 를 설정하여 활성화 또는 비활성화할 수 있다. -`--runtime-config` 플래그는 API 서버의 런타임 구성을 설명하는 -쉼표로 구분된 `=` 쌍을 허용한다. 예를 들면, 다음과 같다. - - - `batch/v1` 을 비활성화하려면, `--runtime-config=batch/v1=false` 로 설정 - - `batch/v2alpha1` 을 활성화하려면, `--runtime-config=batch/v2alpha1` 으로 설정 - -{{< note >}} -그룹이나 리소스를 활성화 또는 비활성화하려면, apiserver와 controller-manager를 재시작하여 -`--runtime-config` 변경을 반영해야 한다. -{{< /note >}} - -## 지속성 - -쿠버네티스는 {{< glossary_tooltip term_id="etcd" >}}에 기록하여 API 리소스 측면에서 -직렬화된 상태를 저장한다. - -## {{% heading "whatsnext" %}} - -- [API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)에 대해 자세히 알아보기 -- [애그리게이터(aggregator)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md)에 - 대한 디자인 문서 읽기 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index 9a6e07293f..9391072163 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -10,7 +10,7 @@ weight: 30 -[쿠버네티스 REST API](/ko/docs/reference/using-api/api-overview/)를 사용해 애플리케이션을 작성하기 위해 +[쿠버네티스 REST API](/ko/docs/reference/using-api/)를 사용해 애플리케이션을 작성하기 위해 API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. 사용하고 있는 프로그래밍 언어를 위한 클라이언트 라이브러리를 사용하면 된다. diff --git a/content/ko/docs/setup/learning-environment/_index.md b/content/ko/docs/setup/learning-environment/_index.md index cd7005bf79..1c035d5bae 100644 --- a/content/ko/docs/setup/learning-environment/_index.md +++ b/content/ko/docs/setup/learning-environment/_index.md @@ -2,3 +2,32 @@ title: 학습 환경 weight: 20 --- + + + +## kind + +[`kind`](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 +쿠버네티스를 사용할 수 있다. 이 툴을 사용하려면 +[도커](https://docs.docker.com/get-docker/)를 설치 및 구성해야 한다. + +kind [빠른 시작](https://kind.sigs.k8s.io/docs/user/quick-start/) 페이지에는 +kind를 시작하고 실행하기 위해 해야 할 일이 나와 있다. + +## minikube + +`kind`와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 로컬에서 쿠버네티스를 실행할 수 있는 툴이다. +`minikube`는 개인용 컴퓨터(윈도우, 맥OS, 리눅스 포함)에서 +단일 노드 쿠버네티스 클러스터를 실행하므로 +쿠버네티스를 시험해 보거나 일상적인 개발 작업에 사용할 수 있다. + +툴을 설치하고 싶으면 +[시작하기!](https://minikube.sigs.k8s.io/docs/start/) 공식 가이드를 +참조하기 바란다. diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md deleted file mode 100644 index 191da08404..0000000000 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ /dev/null @@ -1,512 +0,0 @@ ---- -title: Minikube로 쿠버네티스 설치 -weight: 30 -content_type: concept ---- - - - -Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 가상 머신(VM) 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. - - - - - -## Minikube 특징 - -Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. - -* DNS -* 노드 포트 -* 컨피그 맵과 시크릿 -* 대시보드 -* 컨테이너 런타임: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/) 와 [containerd](https://github.com/containerd/containerd) -* CNI(Container Network Interface) 사용 -* 인그레스 - -## 설치 - -[Minikube 설치](/ko/docs/tasks/tools/install-minikube/) 항목을 보자. - -## 빠른 시작 - -여기서 기술하는 간단한 데모는 어떻게 로컬에서 Minikube를 시작하고, 사용하고 삭제하는지를 안내한다. 다음의 주어진 단계를 따라서 Minikube를 시작하고 탐구한다. - -1. Minikube를 시작하고 클러스터를 생성 - - ```shell - minikube start - ``` - - 결과는 다음과 비슷하다. - - ``` - Starting local Kubernetes cluster... - Running pre-create checks... - Creating machine... - Starting local Kubernetes cluster... - ``` - - 특정 쿠버네티스 버전, VM, 컨테이너 런타임 상에서 클러스터를 시작하기 위한 보다 상세한 정보는 [클러스터 시작하기](#클러스터-시작하기)를 참조한다. - -2. 이제, kubectl을 통해서 클러스터와 상호작용할 수 있다. 보다 상세한 정보는 [클러스터와 상호 작용하기](#클러스터와-상호-작용하기)를 참조한다. - - 간단한 HTTP 서버인 `echoserver` 이미지를 사용해서 쿠버네티스 디플로이먼트를 만들고 `--port`를 이용해서 8080 포트로 노출해보자. - - ```shell - kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 - ``` - - 결과는 다음과 비슷하다. - - ``` - deployment.apps/hello-minikube created - ``` -3. `hello-minikube` 디플로이먼트에 액세스하기 위해, 서비스로 노출시킨다. - - ```shell - kubectl expose deployment hello-minikube --type=NodePort --port=8080 - ``` - - `--type=NodePort` 옵션은 서비스 타입을 지정한다. - - 결과는 다음과 비슷하다. - - ``` - service/hello-minikube exposed - ``` - -4. `hello-minikube` 파드가 이제 시작되었지만 노출된 서비스를 통해서 접근하기 전에 파드가 뜨기를 기다려야한다. - - 파드가 시작되고 실행 중인지 확인한다. - - ```shell - kubectl get pod - ``` - - 출력에서 `STATUS`가 `ContainerCreating`으로 나타나는 경우, 파드는 아직 생성 중이다. - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` - - 출력에서 `STATUS`가 `Running`으로 나타나는 경우, 파드는 이제 시작돼서 실행 중이다. - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` - -5. 서비스 상세를 보기 위해서 노출된 서비스의 URL을 얻는다. - - ```shell - minikube service hello-minikube --url - ``` - -6. 로컬 클러스터의 상세를 보기위해서, 출력에서 얻은 URL을 브라우저에 복사해서 붙여넣는다. - - 출력은 다음과 비슷하다. - - ``` - Hostname: hello-minikube-7c77b68cff-8wdzq - - Pod Information: - -no pod information available- - - Server values: - server_version=nginx: 1.13.3 - lua: 10008 - - Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ - - Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - - Request Body: - -no body in request- - ``` - - 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. - -7. `hello-minikube` 서비스 삭제 - - ```shell - kubectl delete services hello-minikube - ``` - - The output is similar to this: - - ``` - service "hello-minikube" deleted - ``` - -8. `hello-minikube` 디플로이먼트 삭제 - - ```shell - kubectl delete deployment hello-minikube - ``` - - The output is similar to this: - - ``` - deployment.extensions "hello-minikube" deleted - ``` - -9. 로컬 Minikube 클러스터 중지 - - ```shell - minikube stop - ``` - - The output is similar to this: - - ``` - Stopping "minikube"... - "minikube" stopped. - ``` - - 보다 상세한 정보는 [클러스터 중지하기](#클러스터-중지하기)를 참조한다. - -10. 로컬 Minikube 클러스터 삭제 - - ```shell - minikube delete - ``` - 출력은 다음과 비슷하다. - ``` - Deleting "minikube" ... - The "minikube" cluster has been deleted. - ``` - 보다 상세한 정보는 [Deleting a cluster](#클러스터-삭제하기)를 참조한다. - -## 클러스터 관리하기 - -### 클러스터 시작하기 - -클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다. -이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다. -이 커멘드는 또한 [kubectl](/ko/docs/reference/kubectl/overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. - -{{< note >}} -웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. - -```shell -https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 -``` -불행하게도, 환경 변수 설정만으로는 되지 않는다. - -Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. -이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. -{{< /note >}} - -#### 쿠버네티스 버전 지정하기 - -`minikube start` 코멘드에 `--kubernetes-version` 문자열을 -추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. -예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. - -``` -minikube start --kubernetes-version {{< param "fullversion" >}} -``` -#### VM 드라이버 지정하기 -`minikube start` 코멘드에 `--driver=` 플래그를 추가해서 VM 드라이버를 변경할 수 있다. -코멘드를 예를 들면 다음과 같다. -```shell -minikube start --driver= -``` -Minikube는 다음의 드라이버를 지원한다. -{{< note >}} -지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://minikube.sigs.k8s.io/docs/reference/drivers/)를 참조한다. -{{< /note >}} - -* docker ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/docker/)) -* virtualbox ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) -* podman ([드라이버 설치](https://minikube.sigs.k8s.io/docs/drivers/podman/)) (EXPERIMENTAL) -* vmwarefusion -* kvm2 ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) -* hyperkit ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) -* hyperv ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) -다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. -* vmware ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) (VMware unified driver) -* parallels ([드라이버 설치](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) -* none (쿠버네티스 컴포넌트를 가상 머신이 아닌 호스트 상에서 구동한다. 리눅스를 실행중이어야 하고, {{< glossary_tooltip term_id="docker" >}}가 설치되어야 한다.) - -{{< caution >}} -`none` 드라이버를 사용한다면 일부 쿠버네티스 컴포넌트는 Minikube 환경 외부에 있는 부작용이 있는 권한을 가진 컨테이너로 실행된다. 이런 부작용은 개인용 워크스테이션에는 `none` 드라이버가 권장하지 않는 것을 의미 한다. -{{< /caution >}} - -#### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 -Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. -{{< tabs name="container_runtimes" >}} -{{% tab name="containerd" %}} -[containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=containerd \ - --bootstrapper=kubeadm -``` - -혹은 확장 버전을 사용할 수 있다. - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ - --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{% tab name="CRI-O" %}} -[CRI-O](https://cri-o.io/)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=cri-o \ - --bootstrapper=kubeadm -``` -혹은 확장 버전을 사용할 수 있다. - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ - --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{< /tabs >}} - -#### Docker 데몬 재사용을 통한 로컬 이미지 사용하기 - -쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 도커 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 도커 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 도커 데몬 안에서 이미지를 빌드하기 때문이다. - -{{< note >}} -Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. -{{< /note >}} - -맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `minikube docker-env` 에서 마지막 줄을 실행한다. - -이제 개인의 맥/리눅스 머신 내 커멘드 라인에서 도커를 사용해서 Minikube VM 안의 도커 데몬과 통신할 수 있다. - -```shell -docker ps -``` - -{{< note >}} -Centos 7 에서 Docker는 아래와 같은 오류를 발생한다. - -``` -Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory -``` - -/etc/sysconfig/docker를 업데이트하고 Minikube의 환경에 변경이 반영되었는지 확인해서 고칠 수 있다. - -```shell -< DOCKER_CERT_PATH=/etc/docker ---- -> if [ -z "${DOCKER_CERT_PATH}" ]; then -> DOCKER_CERT_PATH=/etc/docker -> fi -``` -{{< /note >}} - -### 쿠버네티스 구성하기 - -Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설정할 수 있도록 하는 '설정기' 기능이 있다. -이 기능을 사용하려면, `--extra-config` 플래그를 `minikube start` 명령어에 추가하여야 한다. - -이 플래그는 여러번 쓸 수 있어 여러 옵션 설정을 전달 할 수 있다. - -이 플래그는 `component.key=value`형식의 문자열로, -앞에 `component`는 아래 목록에 하나의 문자열이며 `key`는 configuration struct의 값이고 `value`는 설정할 값이다(역주: key는 struct의 맴버명). - -올바른 키들은 각 컴포넌트의 쿠버네티스 `componentconfigs` 문서에서 찾아 볼 수 있다. -다음은 각각의 지원하는 설정에 대한 문서이다. - -* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig#KubeletConfiguration) -* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) -* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) -* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) -* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) -* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) - -#### 예제 - -쿠블렛에서 `MaxPods` 설정을 5로 바꾸려면 `--extra-config=kubelet.MaxPods=5` 플래그를 전달하자. - -이 기능은 또한 중첩 구조를 지원한다. 스케쥴러에서 `LeaderElection.LeaderElect` 설정을 `true`로 하려면, `--extra-config=scheduler.LeaderElection.LeaderElect=true` 플래그를 전달하자. - -`apiserver`에서 `AuthorizationMode`를 `RBAC`으로 바꾸려면, `--extra-config=apiserver.authorization-mode=RBAC`를 사용할 수 있다. - -### 클러스터 중지 -`minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. -이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. -클러스터를 다시 시작하면 이전의 상태로 돌려준다. - -### 클러스터 삭제 -`minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. -이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. - -### Minikube 업그레이드 -macOS를 사용하고 있고 [Brew 패키지 관리자](https://brew.sh/)가 설치되어 있다면 다음과 같이 실행한다. - -```shell -brew update -brew upgrade minikube -``` - -## 클러스터와 상호 작용하기 - -### Kubectl - -`minikube start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. -이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. - -Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자. - -`kubectl config use-context minikube` - -혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다. - -`kubectl get pods --context=minikube` - -### 대시보드 - -[쿠버네티스 대시보드](/ko/docs/tasks/access-application-cluster/web-ui-dashboard/)를 이용하려면, Minikube를 실행한 후 쉘에서 아래 명령어를 실행하여 주소를 확인한다. - -```shell -minikube dashboard -``` - -### 서비스 - -노드 포트로 노출된 서비스를 접근하기 위해, Minikube를 시작한 이후 쉘에서 아래 명령어를 실행하여 주소를 확인하자. - -```shell -minikube service [-n NAMESPACE] [--url] NAME -``` - -## 네트워킹 - -Minikube VM은 host-only IP 주소를 통해 호스트 시스템에 노출되고, 이 IP 주소는 `minikube ip` 명령어로 확인할 수 있다. -`NodePort` 서비스 타입은 IP 주소에 해당 노드 포트로 접근할 수 있다. - -서비스의 NodePort를 확인하려면 `kubectl` 명령어로 아래와 같이 하면 된다. - -`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` - -## 퍼시스턴트 볼륨 -Minikube는 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 `hostPath` 타입으로 지원한다. -이런 퍼시스턴트 볼륨은 Minikube VM 내에 디렉터리로 매핑됩니다. - -Minikube VM은 tmpfs에서 부트하는데, 매우 많은 디렉터리가 재부트(`minikube stop`)까지는 유지되지 않다. -그러나, Minikube는 다음의 호스트 디렉터리 아래 파일은 유지하도록 설정되어 있다. - -* `/data` -* `/var/lib/minikube` -* `/var/lib/docker` - -이것은 `/data` 디렉터리에 데이터를 보존하도록 한 퍼시스턴트 볼륨 환경설정의 예이다. - -```yaml -apiVersion: v1 -kind: PersistentVolume -metadata: - name: pv0001 -spec: - accessModes: - - ReadWriteOnce - capacity: - storage: 5Gi - hostPath: - path: /data/pv0001/ -``` - -## 호스트 폴더 마운트 -어떤 드라이버는 VM 안에 호스트 폴더를 마운트하여 VM과 호스트 사이에 쉽게 파일을 공유할 수 있게 한다. 이들은 지금 설정할 수 없고 사용하는 드라이버나 운영체제에 따라 다르다. - -{{< note >}} -호스트 폴더 공유는 KVM 드라이버에서 아직 구현되어 있지 않다. -{{< /note >}} - -| Driver | OS | HostFolder | VM | -| --- | --- | --- | --- | -| VirtualBox | 리눅스 | `/home` | `/hosthome` | -| VirtualBox | macOS | `/Users` | `/Users` | -| VirtualBox | 윈도우 | `C://Users` | `/c/Users` | -| VMware Fusion | macOS | `/Users` | `/mnt/hgfs/Users` | -| Xhyve | macOS | `/Users` | `/Users` | - -## 프라이빗 컨테이너 레지스트리 - -프라이빗 컨테이너 레지스트리를 이용하려면, [이 페이지](/ko/docs/concepts/containers/images/)의 단계를 따르자. - -`ImagePullSecrets`를 이용하기를 권하지만, Minikube VM 상에서 설정하려 한다면 `/home/docker` 디렉터리에 `.dockercfg`를 두거나 `/home/docker/.docker` 디렉터리에 `config.json`을 둘 수 있다. - -## 애드온 - -Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, -Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. -폴더 내부의 애드온은 Minikube VM으로 이동되어 -Minikube가 시작하거나 재시작될 때에 함께 실행된다. - -## HTTP 프록시 환경에서 Minikube 사용하기 - -Minikube는 쿠버네티스와 Docker 데몬을 포함한 가상 머신을 생성한다. -쿠버네티스가 Docker를 이용하여 컨테이너를 스케쥴링 시도할 때에, Docker 데몬은 컨테이너 이미지를 풀링하기 위해 외부 네트워크를 이용해야 한다. - -HTTP 프록시 내부라면, Docker에서 프록시 설정을 해야 한다. -이를 하기 위해서 요구되는 환경 변수를 `minikube start` 중에 플래그로 전달한다. - -예를 들어: - -```shell -minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ - --docker-env https_proxy=https://$YOURPROXY:PORT -``` - -만약 가상 머신 주소가 192.168.99.100 이라면 프록시 설정이 `kubectl`에 직접적으로 도달하지 못할 수도 있다. -이 IP 주소에 대해 프록시 설정을 지나치게 하려면 no_proxy 설정을 수정해야 한다. 다음과 같이 할 수 있다. - -```shell -export no_proxy=$no_proxy,$(minikube ip) -``` - -## 알려진 이슈 - -다중 노드가 필요한 기능은 Minukube에서 동작하지 않는다. - -## 설계 - -Minikube는 VM 프로비저닝을 위해서 [libmachine](https://github.com/docker/machine/tree/master/libmachine)를 사용하고, 쿠버네티스 클러스터를 프로비저닝하기 위해 [kubeadm](https://github.com/kubernetes/kubeadm)을 사용한다. - -Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md) 부분을 읽어보자. - -## 추가적인 링크: - -* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://minikube.sigs.k8s.io/docs/contrib/roadmap/)을 살펴보자. -* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](https://minikube.sigs.k8s.io/docs/contrib/)를 살펴보자. -* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://minikube.sigs.k8s.io/docs/contrib/building/)를 살펴보자. -* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/drivers/)를 보자. -* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. -* **MicroK8s**: 가상 머신을 사용하지 않으려는 리눅스 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. - -## 커뮤니티 - -컨트리뷰션, 질문과 의견은 모두 환영하며 격려한다! Minikube 개발자는 [슬랙](https://kubernetes.slack.com)에 `#minikube` 채널(초청받으려면 [여기](https://slack.kubernetes.io/))에 상주하고 있다. 또한 [kubernetes-dev 구글 그룹 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-dev)도 있다. 메일링 리스트에 포스팅한다면 제목에 "minikube: "라는 접두어를 사용하자. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 0bc616419b..5f6051d59c 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -4,126 +4,133 @@ content_type: concept weight: 10 --- -{{< feature-state for_k8s_version="v1.6" state="stable" >}} -파드에서 컨테이너를 실행하기 위해 쿠버네티스는 컨테이너 런타임을 사용한다. -이 페이지는 다양한 런타임들에 대한 설치 지침을 담고 있다. - +파드가 노드에서 실행될 수 있도록 클러스터의 각 노드에 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 +설치해야 한다. 이 페이지에서는 관련된 항목을 설명하고 +노드 설정 관련 작업을 설명한다. +이 페이지에는 리눅스 환경의 쿠버네티스에서 여러 공통 컨테이너 런타임을 사용하는 방법에 대한 +세부 정보가 있다. -{{< caution >}} -컨테이너를 실행할 때 runc가 시스템 파일 디스크립터를 처리하는 방식에서 결함이 발견되었다. -악성 컨테이너는 이 결함을 사용하여 runc 바이너리의 내용을 덮어쓸 수 있으며 -따라서 컨테이너 호스트 시스템에서 임의의 명령을 실행할 수 있다. - -문제에 대한 자세한 내용은 [CVE-2019-5736](https://access.redhat.com/security/cve/cve-2019-5736) -를 참고한다. -{{< /caution >}} - -### 적용 가능성 +- [containerd](#containerd) +- [CRI-O](#cri-o) +- [도커](#도커) {{< note >}} -이 문서는 리눅스에 CRI를 설치하는 사용자를 위해 작성되었다. 다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자. {{< /note >}} -### Cgroup 드라이버 - -리눅스 배포판의 init 시스템이 systemd인 경우, init 프로세스는 -root control group(`cgroup`)을 생성 및 사용하는 cgroup 관리자로 작동한다. -Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. -컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. -systemd와 함께`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. +## Cgroup 드라이버 Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다. -단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고, -기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다. -관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는 -`cgroupfs`를 사용하고 나머지 프로세스는 -`systemd`를 사용하도록 노드가 설정된 경우, -리소스가 부족할 때 불안정해지는 사례를 본 적이 있다. + +리눅스 배포판의 init 시스템이 [systemd](https://www.freedesktop.org/wiki/Software/systemd/)인 +경우, init 프로세스는 root control group(`cgroup`)을 +생성 및 사용하는 cgroup 관리자로 작동한다. +Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할당한다. +컨테이너 런타임과 kubelet이 `cgroupfs`를 사용하도록 설정할 수 있다. systemd와 함께 +`cgroupfs`를 사용하면 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다. + +단일 cgroup 관리자는 할당되는 리소스가 무엇인지를 단순화하고, +기본적으로 사용할 수 있는 리소스와 사용 중인 리소스를 일관성있게 볼 수 있다. +시스템에 두 개의 cgroup 관리자가 있으면, 이런 리소스도 두 개의 관점에서 보게 된다. +현장에서 사람들은 kubelet과 도커에 `cgroupfs`를 사용하고, +나머지 프로세스는 `systemd`를 사용하도록 노드가 설정된 경우, 리소스가 부족할 때 +불안정해지는 사례를 보고했다. 컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면 -시스템이 안정화된다. 아래의 도커 설정에서 `native.cgroupdriver=systemd` 옵션을 확인하라. +시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다. {{< caution >}} -클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 권장하지 않는다. +클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 *않는다*. 하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, -컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 PodSandBox를 재생성을 시도할 때, 에러가 발생할 수 있다. -kubelet을 재시작 하는 것은 에러를 해결할 수 없을 것이다. -추천하는 방법은 워크로드에서 노드를 제거하고, 클러스터에서 제거한 다음 다시 결합시키는 것이다. +컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다. +kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. + +자동화가 가능하다면, 업데이트된 구성을 사용하여 노드를 다른 노드로 +교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} -## 도커 +## 컨테이너 런타임 -각 머신들에 대해서, 도커를 설치한다. -버전 19.03.11이 추천된다. 그러나 1.13.1, 17.03, 17.06, 17.09, 18.06 그리고 18.09도 동작하는 것으로 알려져 있다. -쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 도커 버전의 지속적인 파악이 필요하다. +{{% thirdparty-content %}} -시스템에 도커를 설치하기 위해서 아래의 커맨드들을 사용한다. +### containerd -{{< tabs name="tab-cri-docker-installation" >}} -{{% tab name="Ubuntu 16.04+" %}} +이 섹션에는 `containerd` 를 CRI 런타임으로 사용하는 데 필요한 단계가 포함되어 있다. + +필수 구성 요소를 설치 및 구성한다. ```shell -# (도커 CE 설치) -## 리포지터리 설정 -### apt가 HTTPS 리포지터리를 사용할 수 있도록 해주는 패키지 설치 -sudo apt-get update && sudo apt-get install -y \ - apt-transport-https ca-certificates curl software-properties-common gnupg2 -``` - -```shell -# 도커 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - -``` - -```shell -# 도커 apt 리포지터리 추가. -sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" -``` - -```shell -# 도커 CE 설치. -sudo apt-get update && sudo apt-get install -y \ - containerd.io=1.2.13-2 \ - docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ - docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) -``` - -```shell -# 도커 데몬 설정 -cat <}} +{{% tab name="Ubuntu 16.04" %}} + +```shell +# 도커의 공식 GPG 키 추가 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - +# (containerd 설치) +## 리포지터리 설정 +### HTTPS를 통해 리포지터리를 사용할 수 있도록 패키지 설치 +sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common ``` ```shell -sudo mkdir -p /etc/systemd/system/docker.service.d +## 도커의 공식 GPG 키 추가 +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - ``` ```shell -# 도커 재시작. -sudo systemctl daemon-reload -sudo systemctl restart docker +## 도커 apt 리포지터리 추가 +sudo add-apt-repository \ + "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" +``` + +```shell +## containerd 설치 +sudo apt-get update && sudo apt-get install -y containerd.io +``` + +```shell +# containerd 구성 +sudo mkdir -p /etc/containerd +sudo containerd config default > /etc/containerd/config.toml +``` + +```shell +# containerd 재시작 +sudo systemctl restart containerd ``` {{% /tab %}} {{% tab name="CentOS/RHEL 7.4+" %}} ```shell -# (도커 CE 설치) +# (containerd 설치) ## 리포지터리 설정 ### 필요한 패키지 설치 sudo yum install -y yum-utils device-mapper-persistent-data lvm2 @@ -131,64 +138,73 @@ sudo yum install -y yum-utils device-mapper-persistent-data lvm2 ```shell ## 도커 리포지터리 추가 -sudo yum-config-manager --add-repo \ - https://download.docker.com/linux/centos/docker-ce.repo +sudo yum-config-manager \ + --add-repo \ + https://download.docker.com/linux/centos/docker-ce.repo ``` ```shell -# 도커 CE 설치. -sudo yum update -y && sudo yum install -y \ - containerd.io-1.2.13 \ - docker-ce-19.03.11 \ - docker-ce-cli-19.03.11 +# containerd 설치 +sudo yum update -y && sudo yum install -y containerd.io ``` ```shell -## /etc/docker 생성. -sudo mkdir /etc/docker +## containerd 구성 +sudo mkdir -p /etc/containerd +sudo containerd config default > /etc/containerd/config.toml ``` ```shell -# 도커 데몬 설정. -cat <}} -부팅 시 도커 서비스를 시작하려면, 다음 명령을 실행한다. +#### systemd {#containerd-systemd} -```shell -sudo systemctl enable docker +`/etc/containerd/config.toml` 의 `systemd` cgroup 드라이버를 `runc` 에서 사용하려면, 다음과 같이 설정한다. + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] + ... + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] + SystemdCgroup = true ``` -자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/) -를 참고한다. +kubeadm을 사용하는 경우, +[kubelet용 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 수동으로 구성한다. -## CRI-O +### CRI-O -이 섹션은 `CRI-O`를 CRI 런타임으로 설치하는 필수적인 단계를 담고 있다. +이 섹션은 CRI-O를 컨테이너 런타임으로 설치하는 필수적인 단계를 담고 있다. 시스템에 CRI-O를 설치하기 위해서 다음의 커맨드를 사용한다. @@ -197,7 +213,7 @@ CRI-O 메이저와 마이너 버전은 쿠버네티스 메이저와 마이너 더 자세한 정보는 [CRI-O 호환 매트릭스](https://github.com/cri-o/cri-o)를 본다. {{< /note >}} -### 선행 조건 +필수 구성 요소를 설치하고 구성한다. ```shell sudo modprobe overlay @@ -216,9 +232,10 @@ sudo sysctl --system {{< tabs name="tab-cri-cri-o-installation" >}} {{% tab name="Debian" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 $OS를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. -| 운영 체제 | $OS | +| 운영 체제 | `$OS` | | ---------------- | ----------------- | | Debian Unstable | `Debian_Unstable` | | Debian Testing | `Debian_Testing` | @@ -233,14 +250,14 @@ sudo sysctl --system 그런 다음, 아래를 실행한다. ```shell cat < /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list -echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ /" > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$VERSION.list +cat <}} -### CRI-O 시작 +CRI-O를 시작한다. ```shell sudo systemctl daemon-reload @@ -340,78 +361,75 @@ sudo systemctl start crio 자세한 사항은 [CRI-O 설치 가이드](https://github.com/kubernetes-sigs/cri-o#getting-started)를 참고한다. -## Containerd +### 도커 -이 섹션은 `containerd`를 CRI 런타임으로써 사용하는데 필요한 단계를 담고 있다. +각 노드에 도커 CE를 설치한다. -Containerd를 시스템에 설치하기 위해서 다음의 커맨드들을 사용한다. +쿠버네티스 릴리스 정보에서 해당 버전의 쿠버네티스와 호환되는 도커 버전을 찾을 수 있다. -### 선행 조건 +사용자의 시스템에서 다음의 명령을 이용해 도커를 설치한다. + +{{< tabs name="tab-cri-docker-installation" >}} +{{% tab name="Ubuntu 16.04+" %}} ```shell -cat <}} -{{% tab name="Ubuntu 16.04" %}} - -```shell -# (containerd 설치) +# (도커 CE 설치) ## 리포지터리 설정 ### apt가 HTTPS로 리포지터리를 사용하는 것을 허용하기 위한 패키지 설치 -sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common +sudo apt-get update && sudo apt-get install -y \ + apt-transport-https ca-certificates curl software-properties-common gnupg2 ``` ```shell -## 도커 공식 GPG 키 추가 -curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - +# 도커 공식 GPG 키 추가: +curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - ``` ```shell -## 도커 apt 리포지터리 추가. +# 도커 apt 리포지터리 추가: sudo add-apt-repository \ - "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ - $(lsb_release -cs) \ - stable" + deb [arch=amd64] https://download.docker.com/linux/ubuntu \ + $(lsb_release -cs) \ + stable" ``` ```shell -## containerd 설치 -sudo apt-get update && sudo apt-get install -y containerd.io +# 도커 CE 설치 +sudo apt-get update && sudo apt-get install -y \ + containerd.io=1.2.13-2 \ + docker-ce=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) \ + docker-ce-cli=5:19.03.11~3-0~ubuntu-$(lsb_release -cs) ``` ```shell -# containerd 설정 -sudo mkdir -p /etc/containerd -sudo containerd config default > /etc/containerd/config.toml +# 도커 데몬 설정 +cat < /etc/containerd/config.toml +## /etc/docker 생성 +sudo mkdir /etc/docker ``` ```shell -# containerd 재시작 -sudo systemctl restart containerd -``` -{{% /tab %}} -{{% tab name="윈도우 (PowerShell)" %}} -```powershell -# (containerd 설치) -# containerd 다운로드 -cmd /c curl -OL https://github.com/containerd/containerd/releases/download/v1.4.0-beta.2/containerd-1.4.0-beta.2-windows-amd64.tar.gz -cmd /c tar xvf .\containerd-1.4.0-beta.2-windows-amd64.tar.gz +# 도커 데몬 설정 +cat <}} -### systemd - -`systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`에 다음을 설정한다. +부팅 시 `docker` 서비스를 시작하려면, 다음 명령을 실행한다. +```shell +sudo systemctl enable docker ``` -[plugins.cri] -systemd_cgroup = true -``` -kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 -[kubelet을 위한 cgroup 드라이버](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node)를 설정한다. -## 다른 CRI 런타임: frakti - -자세한 정보는 [Frakti 빠른 시작 가이드](https://github.com/kubernetes/frakti#quickstart)를 참고한다. +자세한 내용은 [공식 도커 설치 가이드](https://docs.docker.com/engine/installation/)를 +참조한다. diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index b41120f7be..7eb0f8f706 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -600,7 +600,7 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다. - "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 참고한다. + "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `docker pull mcr.microsoft.com/k8s/core/pause:1.2.0`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. ### 추가 조사 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 39226c89be..e78046f0ee 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -149,9 +149,8 @@ root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 요구하지 않지만 이는 표준이 아니다. -[API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은 +[API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)은 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. -이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. ## API에 프로그래밍 방식으로 접근 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md index ba4a794d23..efb489b18d 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md @@ -148,8 +148,8 @@ http 클라이언트가 루트 인증서를 사용하도록 하려면 특별한 일부 클러스터에서, API 서버는 인증이 필요하지 않다. 로컬 호스트에서 제공되거나, 방화벽으로 보호될 수 있다. 이에 대한 표준은 -없다. [API에 대한 접근 구성](/ko/docs/reference/access-authn-authz/controlling-access/)은 -클러스터 관리자가 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 +없다. [쿠버네티스 API에 대한 접근 제어](/docs/concepts/security/controlling-access)은 +클러스터 관리자로서 이를 구성하는 방법에 대해 설명한다. 이러한 접근 방식은 향후 고 가용성 지원과 충돌할 수 있다. ### API에 프로그래밍 방식으로 접근 diff --git a/content/ko/docs/tasks/administer-cluster/cluster-management.md b/content/ko/docs/tasks/administer-cluster/cluster-management.md index b57e07db65..0f241c87f4 100644 --- a/content/ko/docs/tasks/administer-cluster/cluster-management.md +++ b/content/ko/docs/tasks/administer-cluster/cluster-management.md @@ -69,7 +69,7 @@ Oracle은 당신이 고가용성의 관리형 쿠버네티스 컨트롤 플레 다른 제공자들과 도구들은 업그레이드를 다른 방식으로 관리한다. 이들의 업그레이드를 위해서는 이들의 주요 문서를 참조하기를 권장한다. * [kops](https://github.com/kubernetes/kops) -* [kubespray](https://github.com/kubernetes-incubator/kubespray) +* [kubespray](https://github.com/kubernetes-sigs/kubespray) * [CoreOS Tectonic](https://coreos.com/tectonic/docs/latest/admin/upgrade.html) * [Digital Rebar](https://provision.readthedocs.io/en/tip/doc/content-packages/krib.html) * ... diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index ac3ac3f695..aea9411eda 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -8,7 +8,7 @@ weight: 10 {{< feature-state for_k8s_version="v1.15" state="stable" >}} -[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. +[kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 생성된 클라이언트 인증서는 1년 후에 만료된다. 이 페이지는 kubeadm으로 인증서 갱신을 관리하는 방법을 설명한다. ## {{% heading "prerequisites" %}} diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md index 1b0873f74a..8623aadbc8 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/romana-network-policy.md @@ -12,7 +12,7 @@ weight: 40 ## {{% heading "prerequisites" %}} -[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)의 1, 2, 3 단계를 완료하자. +[kubeadm 시작하기](/ko/docs/reference/setup-tools/kubeadm/)의 1, 2, 3 단계를 완료하자. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md index 736572c808..5b32655017 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/weave-network-policy.md @@ -11,7 +11,7 @@ weight: 50 ## {{% heading "prerequisites" %}} 쿠버네티스 클러스터가 필요하다. 맨 땅에서부터 시작하기를 위해서 -[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/kubeadm/)를 따른다. +[kubeadm 시작하기 안내서](/ko/docs/reference/setup-tools/kubeadm/)를 따른다. diff --git a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md index 980d71d9b5..a798018b91 100644 --- a/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/ko/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -21,8 +21,8 @@ weight: 10 클러스터의 각 노드에 최소 300 MiB 메모리가 있어야 한다. 이 페이지의 몇 가지 단계를 수행하기 위해서는 클러스터 내 -[metrics-server](https://github.com/kubernetes-incubator/metrics-server) -서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) +서비스 실행이 필요하다. 이미 실행 중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 4c1679b8a3..dc4acf8411 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -31,7 +31,7 @@ weight: 60 아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를 사용하여 클러스터 하나를 생성할 수 있다. -* [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)의 +* [퍼시스턴트 볼륨](https://minikube.sigs.k8s.io/docs/)의 관련 자료에 익숙해지도록 한다. diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index a9c9bf182d..e4bf6a1715 100644 --- a/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -51,8 +51,8 @@ kubelet은 비율 계산에 사용할 윈도우를 선택한다. ## 메트릭 서버 -[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. -기본적으로, `kube-up.sh` 스크립트에 의해 생성된 클러스터에는 메트릭 서버가 +[메트릭 서버](https://github.com/kubernetes-sigs/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다. +`kube-up.sh` 스크립트에 의해 생성된 클러스터에는 기본적으로 메트릭 서버가 디플로이먼트 오브젝트로 배포된다. 만약 다른 쿠버네티스 설치 메커니즘을 사용한다면, 제공된 [디플로이먼트 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) 파일을 사용하여 메트릭 서버를 배포할 수 있다. 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 87856b9cfe..21c5c3decf 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 @@ -28,7 +28,7 @@ title: 리소스 모니터링 도구 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 -[metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 +[metrics-server](https://github.com/kubernetes-sigs/metrics-server)에 의해서 수집되며 `metrics.k8s.io` API를 통해 노출된다. metrics-server는 클러스터 상의 모든 노드를 발견하고 각 노드의 diff --git a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md index 191e82021c..22372813e9 100644 --- a/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md +++ b/content/ko/docs/tasks/inject-data-application/define-environment-variable-container.md @@ -47,17 +47,10 @@ weight: 20 envar-demo 1/1 Running 0 9s ``` -1. 파드 안에 실행되고 있는 컨테이너의 셸에 접근한다. +1. 파드의 컨테이너 환경 변수를 나열한다. ```shell - kubectl exec -it envar-demo -- /bin/bash - ``` - -1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. - - ```shell - # 컨테이너 내 셸에서 다음을 실행한다. - printenv + kubectl exec envar-demo -- printenv ``` 출력은 아래와 비슷할 것이다. @@ -71,8 +64,6 @@ weight: 20 DEMO_FAREWELL=Such a sweet sorrow ``` -1. 셸에서 빠져나오기 위해, `exit`을 입력한다. - {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 안에서 명시된 모든 환경 변수들을 오버라이딩한다. 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 c9c694e237..b81329c24a 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 @@ -18,9 +18,9 @@ Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. +[메트릭-서버](https://github.com/kubernetes-sigs/metrics-server) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. -메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. +메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, 버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 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 7a7d129525..5afca02371 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -264,12 +264,12 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. * 해당 API 등록: - * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server)가 제공하는 `metrics.k8s.io` API이다. + * 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-sigs/metrics-server)가 제공하는 `metrics.k8s.io` API이다. 클러스터 애드온으로 시작할 수 있다. * 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. 메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다. - 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-incubator/custom-metrics-apiserver)을 확인하라. + 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다. * 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다. diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md index 9753772c5f..74abf8d981 100755 --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -17,11 +17,23 @@ no_list: true kubectl 설치 및 설정 가이드 보기 -[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 읽어볼 수도 있다. +[`kubectl` 레퍼런스 문서](/ko/docs/reference/kubectl/)를 +읽어볼 수도 있다. + +## kind + +[kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 +쿠버네티스를 실행할 수 있다. 이 도구를 사용하려면 +[도커](https://docs.docker.com/get-docker/)를 설치하고 구성해야 한다. + +kind [퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/) 페이지는 +kind를 시작하고 실행하기 위해 수행해야 하는 작업을 보여준다. + +kind 시작하기 가이드 보기 ## minikube -[`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 +`kind` 와 마찬가지로, [`minikube`](https://minikube.sigs.k8s.io/)는 쿠버네티스를 로컬에서 실행할 수 있는 도구이다. `minikube` 는 개인용 컴퓨터(윈도우, macOS 및 리눅스 PC 포함)에서 단일 노드 쿠버네티스 클러스터를 실행하여 쿠버네티스를 사용해보거나 일상적인 개발 작업을 수행할 수 있다. @@ -35,14 +47,12 @@ no_list: true `minikube` 가 작동하면, 이를 사용하여 [샘플 애플리케이션을 실행](/ko/docs/tutorials/hello-minikube/)해볼 수 있다. -## kind +## kubeadm -`minikube` 와 마찬가지로, [kind](https://kind.sigs.k8s.io/docs/)를 사용하면 로컬 컴퓨터에서 -쿠버네티스를 실행할 수 있다. `minikube` 와 달리, `kind` 는 단일 컨테이너 런타임에서만 작동한다. -`kind` 는 [도커](https://docs.docker.com/get-docker/)를 설치하고 -구성해야 한다. +{{< glossary_tooltip term_id="kubeadm" text="kubeadm" >}} 도구를 사용하여 쿠버네티스 클러스터를 만들고 관리할 수 있다. +사용자 친화적인 방식으로 최소한의 실행 가능하고 안전한 클러스터를 설정하고 실행하는 데 필요한 작업을 수행한다. -[퀵 스타트](https://kind.sigs.k8s.io/docs/user/quick-start/)는 `kind` 를 시작하고 실행하기 위해 -수행해야 하는 작업을 보여준다. +[kubeadm 설치](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 페이지는 kubeadm 설치하는 방법을 보여준다. +설치가 끝나면, [클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)이 가능하다. -kind 시작하기 가이드 보기 +kubeadm 설치 가이드 보기 diff --git a/content/ko/docs/tasks/tools/install-kubectl.md b/content/ko/docs/tasks/tools/install-kubectl.md index 2f2e6c4fe0..04801d4ff8 100644 --- a/content/ko/docs/tasks/tools/install-kubectl.md +++ b/content/ko/docs/tasks/tools/install-kubectl.md @@ -521,7 +521,7 @@ compinit ## {{% heading "whatsnext" %}} -* [Minikube 설치](/ko/docs/tasks/tools/install-minikube/) +* [Minikube 설치](https://minikube.sigs.k8s.io/docs/start/) * 클러스터 생성에 대한 자세한 내용은 [시작하기](/ko/docs/setup/)를 참고한다. * [애플리케이션을 시작하고 노출하는 방법에 대해 배운다.](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/) * 직접 생성하지 않은 클러스터에 접근해야하는 경우, diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 699902295e..8f3f515f31 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -15,25 +15,23 @@ card: -이 튜토리얼에서는 [Minikube](/ko/docs/setup/learning-environment/minikube)와 Katacoda를 이용하여 +이 튜토리얼에서는 Minikube와 Katacoda를 이용하여 쿠버네티스에서 샘플 애플리케이션을 어떻게 실행하는지 살펴본다. Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. {{< note >}} -[로컬에서 Minikube](/ko/docs/tasks/tools/install-minikube/)를 설치했다면 이 튜토리얼도 따라 할 수 있다. +로컬에서 Minikube를 설치했다면 이 튜토리얼도 따라 할 수 있다. +설치 안내는 [minikube 시작](https://minikube.sigs.k8s.io/docs/start/)을 참고한다. {{< /note >}} ## {{% heading "objectives" %}} - -* 샘플 애플리케이션을 Minikube에 배포한다. +* 샘플 애플리케이션을 minikube에 배포한다. * 배포한 애플리케이션을 실행한다. * 애플리케이션의 로그를 확인한다. - - ## {{% heading "prerequisites" %}} @@ -43,14 +41,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. -## Minikubue 클러스터 만들기 +## minikubue 클러스터 만들기 1. **Launch Terminal** 을 클릭 {{< kat-button >}} {{< note >}} - Minikube를 로컬에 설치했다면 `minikube start`를 실행한다. + minikube를 로컬에 설치했다면 `minikube start`를 실행한다. {{< /note >}} 2. 브라우저에서 쿠버네티스 대시보드를 열어보자. @@ -156,7 +154,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. 로드 밸런서를 지원하는 클라우드 공급자의 경우에는 서비스에 접근할 수 있도록 외부 IP 주소가 프로비저닝 한다. - Minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 + minikube에서 `LoadBalancer`타입은 `minikube service` 명령어를 통해서 해당 서비스를 접근할 수 있게 한다. 3. 다음 명령어를 실행한다 @@ -173,7 +171,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ## 애드온 사용하기 -Minikube에는 활성화하거나 비활성화 할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 {{< glossary_tooltip text="애드온" term_id="addons" >}} 셋이 있다. +minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네티스 환경에서 접속해 볼 수 있는 내장 {{< glossary_tooltip text="애드온" term_id="addons" >}} 셋이 포함되어 있다. 1. 현재 지원하는 애드온 목록을 확인한다. diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 33fdcb4dbe..8273f3bcd9 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -50,7 +50,7 @@ weight: 30 ### 추가적인 Minikube 설정 요령 {{< caution >}} -[Minikube](/docs/getting-started-guides/minikube/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. +[Minikube](https://minikube.sigs.k8s.io/docs/)는 1024MiB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. diff --git a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md index cc02b6651d..faf5fd5303 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk.md @@ -17,8 +17,6 @@ card: * Metricbeat * Packetbeat - - ## {{% heading "objectives" %}} * Redis를 이용한 PHP 방명록 시작. @@ -27,7 +25,6 @@ card: * Beats 배포. * 로그와 메트릭의 대시보드 보기. - ## {{% heading "prerequisites" %}} @@ -38,16 +35,20 @@ card: * 실행 중인 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook) 튜토리얼의 배포본. -* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. +* 실행 중인 Elasticsearch와 Kibana 디플로이먼트. [Elastic Cloud의 Elasticsearch 서비스](https://cloud.elastic.co)를 사용하거나, + [파일을 내려받아](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-elastic-stack.html) + 워크스테이션이나 서버에서 운영하거나, [Elastic의 Helm 차트](https://github.com/elastic/helm-charts)를 이용한다. ## Redis를 이용한 PHP 방명록 시작 + 이 튜토리얼은 [Redis를 이용한 PHP 방명록](/ko/docs/tutorials/stateless-application/guestbook)을 기반으로 한다. 방명록 애플리케이션을 실행 중이라면, 이를 모니터링할 수 있다. 실행되지 않은 경우라면 지침을 따라 방명록을 배포하고 **정리하기** 단계는 수행하지 말자. 방명록을 실행할 때 이 페이지로 돌아오자. ## 클러스터 롤 바인딩 추가 + [클러스터 단위 롤 바인딩](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding)을 생성하여, 클러스터 수준(kube-system 안에)으로 kube-state-metrics와 Beats를 배포할 수 있게 한다. ```shell @@ -58,31 +59,39 @@ kubectl create clusterrolebinding cluster-admin-binding \ ## kube-state-metrics 설치 [*kube-state-metrics*](https://github.com/kubernetes/kube-state-metrics)는 쿠버네티스 API 서버를 모니터링하며 오브젝트 상태에 대한 메트릭을 생성하는 간단한 서비스이다. 이런 메트릭을 Metricbeat이 보고한다. 방명록이 실행된 쿠버네티스 클러스터에서 kube-state-metrics을 추가한다. + ```shell git clone https://github.com/kubernetes/kube-state-metrics.git kube-state-metrics kubectl apply -f kube-state-metrics/examples/standard ``` ### kube-state-metrics 실행 여부 확인 + ```shell kubectl get pods --namespace=kube-system -l app.kubernetes.io/name=kube-state-metrics ``` + 출력 -```shell + +``` NAME READY STATUS RESTARTS AGE kube-state-metrics-89d656bf8-vdthm 1/1 Running 0 21s ``` + ## Elastic의 예제를 GitHub 리포지터리에 클론한다. + ```shell git clone https://github.com/elastic/examples.git ``` 나머지 커맨드는 `examples/beats-k8s-send-anywhere` 디렉터리의 파일을 참조할 것이라서, 그쪽으로 현재 디렉터리를 변경한다. + ```shell cd examples/beats-k8s-send-anywhere ``` ## 쿠버네티스 시크릿 만들기 + 쿠버네티스 {{< glossary_tooltip text="시크릿" term_id="secret" >}}은 암호나 토큰, 키 같이 소량의 민감한 데이터를 포함하는 오브젝트이다. 이러한 정보는 다른 방식으로도 파드 스펙이나 이미지에 넣을 수 있을 것이다. 시크릿 오브젝트에 넣으면 이것이 어떻게 사용되는지 다양하게 제어할 수 있고, 우발적인 노출 사고의 위험이 줄일 수 있다. {{< note >}} @@ -93,55 +102,68 @@ cd examples/beats-k8s-send-anywhere {{% tab name="자체 관리(Self Managed)" %}} ### 자체 관리 + Elastic Cloud의 Elasticsearch 서비스로 연결한다면 **관리 서비스** 탭으로 전환한다. ### 자격증명(credentials) 설정 + 자체 관리 Elasticsearch와 Kibana(자체 관리는 사실상 Elastic Cloud의 관리 서비스 Elasticsearch와 다르다) 서비스에 접속할 때에 4개 파일을 수정하여 쿠버네티스 시크릿을 생성한다. 파일은 다음과 같다. -1. ELASTICSEARCH_HOSTS -1. ELASTICSEARCH_PASSWORD -1. ELASTICSEARCH_USERNAME -1. KIBANA_HOST +1. `ELASTICSEARCH_HOSTS` +1. `ELASTICSEARCH_PASSWORD` +1. `ELASTICSEARCH_USERNAME` +1. `KIBANA_HOST` 이 정보를 Elasticsearch 클러스터와 Kibana 호스트에 지정한다. 여기 예시(또는 [*이 구성*](https://stackoverflow.com/questions/59892896/how-to-connect-from-minikube-to-elasticsearch-installed-on-host-local-developme/59892897#59892897)을 본다)가 있다. #### `ELASTICSEARCH_HOSTS` + 1. Elastic의 Elasticsearch Helm 차트에서 노드 그룹(nodeGroup). - ```shell - ["http://elasticsearch-master.default.svc.cluster.local:9200"] - ``` + ``` + ["http://elasticsearch-master.default.svc.cluster.local:9200"] + ``` + 1. Mac을 위한 Docker에서 Beats를 운영 중인 Mac에서 운영하는 단일 Elasticsearch 노드. - ```shell - ["http://host.docker.internal:9200"] - ``` + ``` + ["http://host.docker.internal:9200"] + ``` + 1. VM이나 물리 장비에서 운영 중인 두 개의 ELASTICSEARCH 노드. - ```shell - ["http://host1.example.com:9200", "http://host2.example.com:9200"] - ``` -`ELASTICSEARCH_HOSTS` 수정한다. + ``` + ["http://host1.example.com:9200", "http://host2.example.com:9200"] + ``` + +`ELASTICSEARCH_HOSTS` 를 수정한다. + ```shell vi ELASTICSEARCH_HOSTS ``` #### `ELASTICSEARCH_PASSWORD` -화이트 스페이스나 인용 부호나 <> 도 없는 암호이다. +화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 암호이다. - <사용자의 시크릿 암호> +``` +<사용자시크릿암호> +``` + +`ELASTICSEARCH_PASSWORD` 를 수정한다. -`ELASTICSEARCH_PASSWORD` 수정한다. ```shell vi ELASTICSEARCH_PASSWORD ``` #### `ELASTICSEARCH_USERNAME` -화이트 스페이스나 인용 부호나 <> 도 없는 이름이다. +화이트 스페이스나 인용 부호나 `<` 또는 `>` 도 없는 이름이다. - +``` + +``` + +`ELASTICSEARCH_USERNAME` 을 수정한다. -`ELASTICSEARCH_USERNAME` 수정한다. ```shell vi ELASTICSEARCH_USERNAME ``` @@ -150,78 +172,97 @@ vi ELASTICSEARCH_USERNAME 1.Elastic의 Kibana Helm 차트의 인스턴스이다. 하위 도메인 `default`는 기본 네임스페이스를 참조한다. 다른 네임스페이스를 사용하여 Helm 차트를 배포한 경우 하위 도메인이 다릅니다. - ```shell - "kibana-kibana.default.svc.cluster.local:5601" - ``` + ``` + "kibana-kibana.default.svc.cluster.local:5601" + ``` + 1. Mac 용 Docker에서 실행하는 Beats가 있는 Mac에서 실행하는 Kibana 인스턴스 - ```shell - "host.docker.internal:5601" - ``` + ``` + "host.docker.internal:5601" + ``` 1. 가상머신이나 물리적 하드웨어에서 실행 중인 두 개의 Elasticsearch 노드 - ```shell - "host1.example.com:5601" - ``` -`KIBANA_HOST`를 편집한다. + ``` + "host1.example.com:5601" + ``` + +`KIBANA_HOST` 를 편집한다. + ```shell vi KIBANA_HOST ``` ### 쿠버네티스 시크릿 만들기 -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 만든다. - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTICSEARCH_HOSTS \ - --from-file=./ELASTICSEARCH_PASSWORD \ - --from-file=./ELASTICSEARCH_USERNAME \ - --from-file=./KIBANA_HOST \ - --namespace=kube-system +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 만든다. + +```shell +kubectl create secret generic dynamic-logging \ + --from-file=./ELASTICSEARCH_HOSTS \ + --from-file=./ELASTICSEARCH_PASSWORD \ + --from-file=./ELASTICSEARCH_USERNAME \ + --from-file=./KIBANA_HOST \ + --namespace=kube-system +``` {{% /tab %}} {{% tab name="관리 서비스(Managed service)" %}} ## 관리 서비스 + 이 탭은 Elastic Cloud에서 Elasticsearch 서비스 만에 대한 것으로, 이미 자체 관리 Elasticsearch와 Kibana 배포로 시크릿을 생성했다면, [Beats 배포](#deploy-the-beats)를 계속한다. + ### 자격증명(credentials) 설정 + Elastic Cloud에서 관리되는 Elastic 서비스에 연결할 때, 쿠버네티스 시크릿을 생성하기 위해 편집할 두 파일이 있다. 파일은 다음과 같다. -1. ELASTIC_CLOUD_AUTH -1. ELASTIC_CLOUD_ID +1. `ELASTIC_CLOUD_AUTH` +1. `ELASTIC_CLOUD_ID` 디플로이먼트를 생성할 때에 Elasticsearch 콘솔에서 제공한 정보로 이를 설정한다. 여기 예시들이 있다. -#### ELASTIC_CLOUD_ID -```shell +#### `ELASTIC_CLOUD_ID` + +``` devk8s:ABC123def456ghi789jkl123mno456pqr789stu123vwx456yza789bcd012efg345hijj678klm901nop345zEwOTJjMTc5YWQ0YzQ5OThlN2U5MjAwYTg4NTIzZQ== ``` -#### ELASTIC_CLOUD_AUTH +#### `ELASTIC_CLOUD_AUTH` + 사용자 이름, 콜론(`:`) 및 비밀번호인데, 공백 또는 따옴표는 없다. -```shell + +``` elastic:VFxJJf9Tjwer90wnfTghsn8w ``` ### 필요 파일 편집하기 + ```shell vi ELASTIC_CLOUD_ID vi ELASTIC_CLOUD_AUTH ``` + ### 쿠버네티스 시크릿 생성하기 -이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(kube-system)에 시크릿을 생성한다. - kubectl create secret generic dynamic-logging \ - --from-file=./ELASTIC_CLOUD_ID \ - --from-file=./ELASTIC_CLOUD_AUTH \ - --namespace=kube-system +이 커맨드는 방금 편집한 파일을 기반으로 쿠버네티스의 시스템 수준의 네임스페이스(`kube-system`)에 시크릿을 생성한다. - {{% /tab %}} +```shell +kubectl create secret generic dynamic-logging \ + --from-file=./ELASTIC_CLOUD_ID \ + --from-file=./ELASTIC_CLOUD_AUTH \ + --namespace=kube-system +``` + +{{% /tab %}} {{< /tabs >}} ## Beats 배포하기 {#deploy-the-beats} + 각 Beat마다 메니페스트 파일을 제공한다. 이 메니페스트 파일은 앞서 생성한 시크릿을 사용하여, Elasticsearch 및 Kibana 서버에 연결하도록 Beats를 구성한다. ### Filebeat에 대해 + Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파드에서 실행되는 컨테이너의 로그를 수집한다. Filebeat는 {{< glossary_tooltip text="데몬 셋" term_id="daemonset" >}}으로 배포한다. Filebeat는 쿠버네티스 클러스터에서 실행 중인 애플리케이션을 자동 검색할 수 있다. 시작시에 Filebeat는 기존 컨테이너를 검색하고 이에 적절한 구성을 시작하고 새 시작/종료 이벤트를 감시한다. 아래 내용은 Filebeat가 방명록 애플리케이션과 함께 배포된 Redis 컨테이너에서 Redis 로그를 찾아 구문분석할 수 있게 하는 자동 검색 구성이다. 이 구성은 `filebeat-kubernetes.yaml`파일에 있다. @@ -240,20 +281,25 @@ Filebeat는 쿠버네티스 노드와 해당 노두에서 실행되는 각 파 enabled: true var.hosts: ["${data.host}:${data.port}"] ``` + 이것은 `redis` 컨테이너가 `app` 문자열을 포함하는 레이블로 감지될 때에 Filebeat 모듈 `redis`를 적용하도록 Filebeat를 구성한다. Redis 모듈은 Docker 입력 유형을 사용하여 컨테이너에서 `로그` 스트림을 수집할 수 있다(이 Redis 컨테이너의 STDOUT 스트림과 연관된 쿠버네티스 노드에서 파일 읽기). 또한 이 모듈은 컨테이너 메타 데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 Redis의 `slowlog` 항목을 수집할 수 있다. ### Filebeat 배포 + ```shell kubectl create -f filebeat-kubernetes.yaml ``` #### 확인 + ```shell kubectl get pods -n kube-system -l k8s-app=filebeat-dynamic ``` ### Metricbeat에 대해 + Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음은 Redis 컨테이너에 대한 Metricbeat의 자동 검색 구성이다. 이 구성은 `metricbeat-kubernetes.yaml`에 있다. + ```yaml - condition.equals: kubernetes.labels.tier: backend @@ -265,18 +311,23 @@ Metricbeat 자동 검색은 Filebeat와 같은 방식으로 구성된다. 다음 # Redis hosts hosts: ["${data.host}:${data.port}"] ``` + 이것은 컨테이너가 `tier` 레이블이 `backend` 문자열과 같은 레이블로 감지될 때에 Metricbeat 모듈 `redis`를 적용하도록 Metricbeat를 구성한다. `redis` 모듈은 컨테이너 메타데이터에 제공되는 적절한 파드 호스트와 포트에 연결하여 컨테이너에서 `info` 및 `keyspace` 메트릭을 수집할 수 있다. ### Metricbeat 배포 + ```shell kubectl create -f metricbeat-kubernetes.yaml ``` + #### 확인 + ```shell kubectl get pods -n kube-system -l k8s-app=metricbeat ``` ### Packetbeat에 대해 + Packetbeat 구성은 Filebeat와 Metricbeat와는 다르다. 컨테이너 레이블과 일치시킬 패턴을 지정하지 않고, 구성은 관련 프로토콜 및 포트 번호를 기반으로 한다. 아래는 포트 번호의 하위 집합이다. {{< note >}} @@ -307,11 +358,13 @@ packetbeat.flows: ``` #### Packetbeat 배포하기 + ```shell kubectl create -f packetbeat-kubernetes.yaml ``` #### 확인하기 + ```shell kubectl get pods -n kube-system -l k8s-app=packetbeat-dynamic ``` @@ -328,13 +381,16 @@ Metricbeat에서 Apache 메트릭을 가져올 수 있게 하려면, mod-status ## 디플로이먼트를 확장하고 모니터링중인 새 파드를 확인하기 + 기존 디플로이먼트를 확인한다. + ```shell kubectl get deployments ``` 출력 -```shell + +``` NAME READY UP-TO-DATE AVAILABLE AGE frontend 3/3 3 3 3h27m redis-master 1/1 1 1 3h27m @@ -342,54 +398,56 @@ redis-slave 2/2 2 2 3h27m ``` front의 디플로이먼트를 두 개의 파드로 축소한다. + ```shell kubectl scale --replicas=2 deployment/frontend ``` + 출력 -```shell + +``` deployment.extensions/frontend scaled ``` + frontend의 파드를 최대 3개의 파드로 확장한다. + ```shell kubectl scale --replicas=3 deployment/frontend ``` ## Kibana에서 변화 확인하기 + 스크린 캡처를 확인하여, 표시된 필터를 추가하고 해당 열을 뷰에 추가한다. ScalingReplicaSet 항목이 표시되고, 여기에서 이벤트 목록의 맨 위에 풀링되는 이미지, 마운트된 볼륨, 파드 시작 등을 보여준다. ![Kibana 디스커버리](https://raw.githubusercontent.com/elastic/examples/master/beats-k8s-send-anywhere/scaling-up.png) - - ## {{% heading "cleanup" %}} 디플로이먼트와 서비스를 삭제하면 실행중인 파드도 삭제된다. 한 커맨드로 여러 개의 리소스를 삭제하기 위해 레이블을 이용한다. 1. 다음 커맨드를 실행하여 모든 파드, 디플로이먼트, 서비스를 삭제한다. - ```shell - kubectl delete deployment -l app=redis - kubectl delete service -l app=redis - kubectl delete deployment -l app=guestbook - kubectl delete service -l app=guestbook - kubectl delete -f filebeat-kubernetes.yaml - kubectl delete -f metricbeat-kubernetes.yaml - kubectl delete -f packetbeat-kubernetes.yaml - kubectl delete secret dynamic-logging -n kube-system - ``` + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment -l app=guestbook + kubectl delete service -l app=guestbook + kubectl delete -f filebeat-kubernetes.yaml + kubectl delete -f metricbeat-kubernetes.yaml + kubectl delete -f packetbeat-kubernetes.yaml + kubectl delete secret dynamic-logging -n kube-system + ``` 1. 실행 중인 파드가 없음을 확인하기 위해 파드 목록을 조회한다. - ```shell - kubectl get pods - ``` - - 커맨드의 출력은 다음과 같아야 한다. - - ``` - No resources found. - ``` + ```shell + kubectl get pods + ``` + 출력은 다음과 같아야 한다. + ``` + No resources found. + ``` ## {{% heading "whatsnext" %}} diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md index b05dc3ac8c..90aa725d6c 100644 --- a/content/ko/includes/task-tutorial-prereqs.md +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -1,7 +1,7 @@ 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약, 아직 클러스터를 가지고 있지 않다면, -[Minikube](/ko/docs/setup/learning-environment/minikube/)를 사용해서 생성하거나, +[minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground)