From 34be3c1d39b7976efd5acaad1c734c5cd1f1264b Mon Sep 17 00:00:00 2001 From: June Yi Date: Sun, 14 Jun 2020 01:11:06 +0900 Subject: [PATCH] Sixth Korean l10n work for release 1.18 - Update outdated files in dev-1.18-ko.6 partly (#21714) - Translate StorageClass to Korean word (#21805) - Translate StatefulSet to Korean word in pods.md (#21794) - Translate tasks/run-application/delete-stateful-set/ in Korean (#21686) - Translate tasks/administer-cluster/change-default-storage-class in Korean (#21801) - update outdated docs (#21940) - Modify spacing term StatefulSet in Korean (#21871) - Translate /tasks/administer-cluster/coredns in Korean (#21876) - Fix typo in k8s.io/ko/docs/contribute/new-content/new-content/ (#21975) - Translation error correction in /concepts/containers/runtime-class.md (#21868) - Translate tasks/tls/certificate-rotation/ in Korean (#21838) - Translate /tasks/configure-pod-container/static-pod in Korean (#21798) - Update to Outdated files in the dev-1.18-ko.6 branch - (1/4) (#21911) - Fix English bugs in Korean documentation (#21994) - Update outdated dev-1.18-ko.6 partly (#22067) Co-authored-by: Jerry Park Co-authored-by: PyungHo Yoon Co-authored-by: Yuk, Yongsu Co-authored-by: Jerry Park Co-authored-by: Seokho Son Co-authored-by: Jordy Ruiter Co-authored-by: bluefriday Co-authored-by: Dajin Gwon Co-authored-by: Hyungseok Lee Co-authored-by: Jihoon Seo Co-authored-by: coolguyhong Co-authored-by: jmyung Co-authored-by: June Yi --- content/ko/docs/concepts/_index.md | 17 +- .../concepts/architecture/cloud-controller.md | 2 +- .../control-plane-node-communication.md | 11 +- .../docs/concepts/architecture/controller.md | 2 +- .../ko/docs/concepts/architecture/nodes.md | 18 +- .../cluster-administration/cloud-providers.md | 5 +- .../kubelet-garbage-collection.md | 1 - .../manage-deployment.md | 2 +- .../docs/concepts/configuration/configmap.md | 87 ++++++- .../organize-cluster-access-kubeconfig.md | 2 +- .../concepts/configuration/pod-overhead.md | 1 + .../containers/container-environment.md | 3 +- content/ko/docs/concepts/containers/images.md | 14 +- .../ko/docs/concepts/containers/overview.md | 1 - .../docs/concepts/containers/runtime-class.md | 69 ++--- .../api-extension/apiserver-aggregation.md | 7 +- .../api-extension/custom-resources.md | 15 +- .../compute-storage-net/device-plugins.md | 2 +- .../ko/docs/concepts/overview/components.md | 2 + .../docs/concepts/overview/kubernetes-api.md | 149 +++++++---- .../working-with-objects/common-labels.md | 18 +- .../working-with-objects/field-selectors.md | 9 +- .../kubernetes-objects.md | 6 +- .../overview/working-with-objects/labels.md | 3 +- .../overview/working-with-objects/names.md | 1 - .../working-with-objects/object-management.md | 4 +- .../ko/docs/concepts/policy/limit-range.md | 12 +- .../concepts/policy/pod-security-policy.md | 15 +- .../docs/concepts/policy/resource-quotas.md | 11 +- .../scheduling-eviction/assign-pod-node.md | 27 +- .../scheduling-eviction/kube-scheduler.md | 4 +- .../scheduler-perf-tuning.md | 45 ++-- .../taint-and-toleration.md | 55 ++-- content/ko/docs/concepts/security/overview.md | 78 +++--- ...ries-to-pod-etc-hosts-with-host-aliases.md | 25 +- .../connect-applications-service.md | 6 +- .../services-networking/dns-pod-service.md | 172 ++++++------- .../services-networking/dual-stack.md | 2 +- .../services-networking/endpoint-slices.md | 7 +- .../ingress-controllers.md | 46 ++-- .../concepts/services-networking/ingress.md | 17 +- .../services-networking/network-policies.md | 56 ++--- .../services-networking/service-topology.md | 4 +- .../concepts/services-networking/service.md | 15 +- .../concepts/storage/dynamic-provisioning.md | 17 +- .../concepts/storage/persistent-volumes.md | 16 +- .../docs/concepts/storage/storage-classes.md | 5 +- .../concepts/storage/volume-pvc-datasource.md | 3 +- .../storage/volume-snapshot-classes.md | 12 +- .../docs/concepts/storage/volume-snapshots.md | 3 +- content/ko/docs/concepts/storage/volumes.md | 31 ++- .../workloads/controllers/cron-jobs.md | 41 ++- .../workloads/controllers/daemonset.md | 131 +++++----- .../workloads/controllers/deployment.md | 161 ++++++------ .../controllers/garbage-collection.md | 11 +- .../controllers/jobs-run-to-completion.md | 14 +- .../controllers/replicationcontroller.md | 22 +- .../workloads/controllers/statefulset.md | 132 +++++----- .../workloads/controllers/ttlafterfinished.md | 11 +- .../concepts/workloads/pods/disruptions.md | 108 ++++---- .../workloads/pods/ephemeral-containers.md | 53 ++-- .../workloads/pods/init-containers.md | 37 ++- .../concepts/workloads/pods/pod-lifecycle.md | 12 +- .../concepts/workloads/pods/pod-overview.md | 10 +- .../pods/pod-topology-spread-constraints.md | 22 +- .../ko/docs/concepts/workloads/pods/pod.md | 86 +++---- .../docs/concepts/workloads/pods/podpreset.md | 3 + content/ko/docs/contribute/_index.md | 8 +- content/ko/docs/contribute/localization_ko.md | 112 ++++++--- .../docs/contribute/new-content/open-a-pr.md | 2 +- .../docs/contribute/new-content/overview.md | 2 +- content/ko/docs/contribute/participating.md | 13 +- .../docs/contribute/review/reviewing-prs.md | 2 +- .../docs/contribute/style/write-new-topic.md | 11 +- content/ko/docs/home/_index.md | 6 +- .../reference/glossary/aggregation-layer.md | 2 +- .../glossary/container-env-variables.md | 2 +- .../glossary/customresourcedefinition.md | 2 +- content/ko/docs/reference/glossary/image.md | 2 +- .../ko/docs/reference/glossary/statefulset.md | 6 +- content/ko/docs/reference/glossary/volume.md | 2 +- content/ko/docs/reference/kubectl/overview.md | 12 +- .../docs/reference/using-api/api-overview.md | 2 +- .../reference/using-api/client-libraries.md | 1 + .../docs/setup/best-practices/certificates.md | 4 +- .../setup/learning-environment/minikube.md | 39 +-- content/ko/docs/setup/release/notes.md | 30 +-- content/ko/docs/tasks/_index.md | 2 +- ...icate-containers-same-pod-shared-volume.md | 2 +- .../configure-access-multiple-clusters.md | 87 ++++--- .../web-ui-dashboard.md | 28 ++- .../change-default-storage-class.md | 101 ++++++++ .../docs/tasks/administer-cluster/coredns.md | 98 ++++++++ .../kubeadm/kubeadm-certs.md | 4 + .../kubeadm/kubeadm-upgrade.md | 2 + .../memory-default-namespace.md | 2 + .../manage-resources/quota-pod-namespace.md | 5 + .../calico-network-policy.md | 2 - .../kube-router-network-policy.md | 3 +- .../romana-network-policy.md | 3 +- .../weave-network-policy.md | 1 - .../assign-memory-resource.md | 22 +- .../configure-pod-initialization.md | 22 +- .../pull-image-private-registry.md | 2 +- .../configure-pod-container/static-pod.md | 238 ++++++++++++++++++ .../determine-reason-pod-failure.md | 25 +- .../resource-usage-monitoring.md | 8 +- .../tasks/extend-kubectl/kubectl-plugins.md | 20 +- .../define-environment-variable-container.md | 21 +- .../manage-daemon/rollback-daemon-set.md | 23 +- .../tasks/manage-daemon/update-daemon-set.md | 22 +- .../docs/tasks/manage-gpus/scheduling-gpus.md | 6 +- .../manage-hugepages/scheduling-hugepages.md | 16 +- .../declarative-config.md | 6 +- .../imperative-command.md | 2 + .../imperative-config.md | 2 + .../run-application/delete-stateful-set.md | 88 +++++++ .../horizontal-pod-autoscale-walkthrough.md | 2 +- .../horizontal-pod-autoscale.md | 22 +- ...un-single-instance-stateful-application.md | 27 +- content/ko/docs/tasks/tls/_index.md | 5 + .../ko/docs/tasks/tls/certificate-rotation.md | 83 ++++++ .../ko/docs/tasks/tools/install-minikube.md | 7 +- content/ko/docs/tutorials/_index.md | 5 +- .../ko/docs/tutorials/clusters/apparmor.md | 7 +- content/ko/docs/tutorials/hello-minikube.md | 1 + .../kubernetes-basics/scale/scale-intro.html | 2 +- .../basic-stateful-set.md | 2 +- .../stateful-application/cassandra.md | 19 +- .../mysql-wordpress-persistent-volume.md | 3 +- .../stateful-application/zookeeper.md | 2 + .../guestbook-logs-metrics-with-elk.md | 2 - .../stateless-application/guestbook.md | 1 - 133 files changed, 2075 insertions(+), 1227 deletions(-) create mode 100644 content/ko/docs/tasks/administer-cluster/change-default-storage-class.md create mode 100644 content/ko/docs/tasks/administer-cluster/coredns.md create mode 100644 content/ko/docs/tasks/configure-pod-container/static-pod.md create mode 100644 content/ko/docs/tasks/run-application/delete-stateful-set.md create mode 100644 content/ko/docs/tasks/tls/_index.md create mode 100644 content/ko/docs/tasks/tls/certificate-rotation.md diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 30424ead72088..34bc413e7496d 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -33,15 +33,15 @@ weight: 40 * [파드](/ko/docs/concepts/workloads/pods/pod-overview/) * [서비스](/ko/docs/concepts/services-networking/service/) * [볼륨](/ko/docs/concepts/storage/volumes/) -* [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces/) +* [네임스페이스(Namespace)](/ko/docs/concepts/overview/working-with-objects/namespaces/) 또한, 쿠버네티스에는 기초 오브젝트를 기반으로, 부가 기능 및 편의 기능을 제공하는 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 의존하는 보다 높은 수준의 추상 개념도 포함되어 있다. 다음이 포함된다. -* [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) -* [데몬 셋](/ko/docs/concepts/workloads/controllers/daemonset/) -* [스테이트풀 셋](/ko/docs/concepts/workloads/controllers/statefulset/) -* [레플리카 셋](/ko/docs/concepts/workloads/controllers/replicaset/) -* [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/) +* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/) +* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/) +* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/) +* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## 쿠버네티스 컨트롤 플레인 @@ -66,7 +66,6 @@ weight: 40 개념 페이지를 작성하기를 원하면, -개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 -[페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다. - +개념 페이지 유형에 대한 정보가 있는 +[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다. diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index 12b1d714e811f..b3806591c29a4 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -19,7 +19,6 @@ weight: 40 - ## 디자인 @@ -31,6 +30,7 @@ weight: 40 프로세스에 여러 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구현한다. + {{< note >}} 또한 사용자는 클라우드 컨트롤러 매니저를 컨트롤 플레인의 일부가 아닌 쿠버네티스 {{< glossary_tooltip text="애드온" term_id="addons" >}}으로 diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 819ee0c384812..62fd283b2fe48 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -15,7 +15,7 @@ aliases: ## 노드에서 컨트롤 플레인으로의 통신 -노드에서 컨트롤 플레인까지의 모든 통신 경로는 API 서버에서 종료된다(다른 마스터 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). 일반적인 배포에서 API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(443)에서 원격 연결을 수신하도록 구성된다. +쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. @@ -28,9 +28,11 @@ API 서버에 연결하려는 파드는 쿠버네티스가 공개 루트 인증 결과적으로, 노드 및 노드에서 실행되는 파드에서 컨트롤 플레인으로 연결하기 위한 기본 작동 모드는 기본적으로 보호되며 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행될 수 있다. ## 컨트롤 플레인에서 노드로의 통신 + 컨트롤 플레인(API 서버)에서 노드로는 두 가지 기본 통신 경로가 있다. 첫 번째는 API 서버에서 클러스터의 각 노드에서 실행되는 kubelet 프로세스이다. 두 번째는 API 서버의 프록시 기능을 통해 API 서버에서 모든 노드, 파드 또는 서비스에 이르는 것이다. ### API 서버에서 kubelet으로의 통신 + API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. * 파드에 대한 로그를 가져온다. @@ -58,9 +60,10 @@ API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. ### Konnectivity 서비스 + {{< feature-state for_k8s_version="v1.18" state="beta" >}} -SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 연결을 유지한다. -그런 다음 컨트롤 플레인에서 노드로의 모든 트래픽은 이 연결을 통과한다. +SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. +Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. -클러스터에서 설정하는 방법에 대해서는 [Konnectivity 서비스 설정](/docs/tasks/setup-konnectivity/)을 참조한다. +[Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index 6688a969d7d8d..7782d278556e2 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -48,7 +48,7 @@ weight: 30 내장 컨트롤러의 예시이다. 내장 컨트롤러는 클러스터 API 서버와 상호 작용하며 상태를 관리한다. -잡은 단일 {{< glossary_tooltip term_id="pod" >}} 또는 여러 파드를 실행하고, +잡은 단일 {{< glossary_tooltip text="파드" term_id="pod" >}} 또는 여러 파드를 실행하고, 작업을 수행한 다음 중지하는 쿠버네티스 리소스 이다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 197ae71422d1f..e4f5c9564e2c9 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -31,7 +31,8 @@ weight: 10 1. 노드의 kubelet으로 컨트롤 플레인에 자체 등록 2. 사용자 또는 다른 사용자가 노드 오브젝트를 수동으로 추가 -노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. +노드 오브젝트 또는 노드의 kubelet으로 자체 등록한 후 +컨트롤 플레인은 새 노드 오브젝트가 유효한지 확인한다. 예를 들어 다음 JSON 매니페스트에서 노드를 만들려는 경우이다. ```json @@ -61,7 +62,8 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 노드 오브젝트를 명시적으로 삭제해야한다. {{< /note >}} -노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +노드 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. ### 노드에 대한 자체-등록 @@ -73,7 +75,9 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API - `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로. - `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법. - `--register-node` - 자동으로 API 서버에 등록. - - `--register-with-taints` - 주어진 taint 리스트 (콤마로 분리된 `=:`)를 가진 노드 등록. `register-node`가 거짓이면 동작 안함. + - `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `=:`)를 가진 노드 등록. + + `register-node`가 거짓이면 동작 안 함. - `--node-ip` - 노드의 IP 주소. - `--node-labels` - 클러스터에 노드를 등록할 때 추가 할 {{< glossary_tooltip text="레이블" term_id="label" >}}([NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)에 의해 적용되는 레이블 제한 사항 참고). - `--node-status-update-frequency` - 얼마나 자주 kubelet이 마스터에 노드 상태를 게시할 지 정의. @@ -188,6 +192,9 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 스케줄러는 파드를 노드에 할당 할 때 노드의 테인트를 고려한다. 또한 파드는 노드의 테인트를 극복(tolerate)할 수 있는 톨러레이션(toleration)을 가질 수 있다. +자세한 내용은 +[컨디션별 노드 테인트하기](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/#컨디션별-노드-테인트하기)를 참조한다. + ### 용량과 할당가능 {#capacity} 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 @@ -201,7 +208,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 [컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을 배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자. -### 정보 {#info} +### 정보 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은노드에 대한 일반적인 정보를 보여준다. 이 정보는 Kubelet에 의해 노드로부터 수집된다. @@ -285,6 +292,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. + {{< caution >}} `kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 @@ -318,7 +326,6 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 `TopologyManager` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다. - 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. @@ -331,4 +338,3 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 섹션을 읽어본다. * [테인트와 톨러레이션](/ko/docs/concepts/configuration/taint-and-toleration/)을 읽어본다. * [클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)을 읽어본다. - diff --git a/content/ko/docs/concepts/cluster-administration/cloud-providers.md b/content/ko/docs/concepts/cluster-administration/cloud-providers.md index 30dc7b230efd4..91e1a4e7ac3f4 100644 --- a/content/ko/docs/concepts/cluster-administration/cloud-providers.md +++ b/content/ko/docs/concepts/cluster-administration/cloud-providers.md @@ -134,13 +134,13 @@ CloudStack 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이 GCE 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 (kubelet에 의해 결정되거나 `--hostname-override` 로 재정의된) 호스트 이름을 사용한다. 참고로 쿠버네티스 노드 이름의 첫 번째 세그먼트는 GCE 인스턴스 이름과 일치해야 한다(예: `kubernetes-node-2.c.my-proj.internal` 이름이 지정된 노드는 `kubernetes-node-2` 이름이 지정된 인스턴스에 해당해야 함). -## HUAWEI 클라우드 +## HUAWEI CLOUD 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)이다. ### 노드 이름 -HUAWEI 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. +HUAWEI CLOUD 제공자는 쿠버네티스 노드 오브젝트의 이름으로 노드의 프라이빗 IP 주소가 필요하다. 노드에서 kubelet을 시작할 때 반드시 `--hostname-override=` 를 사용한다. ## OpenStack @@ -415,6 +415,7 @@ Baidu 클라우드 제공자는 쿠버네티스 노드 오브젝트의 이름으 참고로 쿠버네티스 노드 이름은 Baidu VM 프라이빗 IP와 일치해야 한다. ## Tencent 쿠버네티스 엔진 + 이 외부 클라우드 제공자를 사용하려는 경우, 해당 리포지터리는 [TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)이다. ### 노드 이름 diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index a6907ad44c94c..d749710484c13 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -78,7 +78,6 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index 6bed969e90d69..c2835e78cbca4 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -400,7 +400,7 @@ rm /tmp/nginx.yaml `kubectl patch` 를 사용하여 API 오브젝트를 인플레이스 업데이트할 수 있다. 이 명령은 JSON 패치, JSON 병합 패치 그리고 전략적 병합 패치를 지원한다. -[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/run-application/update-api-object-kubectl-patch/)와 +[kubectl patch를 사용한 인플레이스 API 오브젝트 업데이트](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)와 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch)를 참조한다. diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 8e5eb3bed1f8c..f61add3919107 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -43,7 +43,7 @@ API [오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-ob 컨피그맵의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -## 컨피그맵과 파드(Pod) +## 컨피그맵과 파드 컨피그맵을 참조하는 파드 `spec` 을 작성하고 컨피그맵의 데이터를 기반으로 해당 파드의 컨테이너를 구성할 수 있다. 파드와 컨피그맵은 @@ -157,7 +157,91 @@ spec: 사용할 수도 있다. {{< /note >}} +## 컨피그맵 사용하기 +컨피그맵은 데이터 볼륨으로 마운트할 수 있다. 컨피그맵은 파드에 직접적으로 +노출되지 않고, 시스템의 다른 부분에서도 사용할 수 있다. 예를 들어, +컨피그맵은 시스템의 다른 부분이 구성을 위해 사용해야 하는 데이터를 보유할 수 있다. + +### 파드에서 컨피그맵을 파일로 사용하기 + +파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다. + +1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다. +1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다. +1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다. +1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다. + +다음은 볼륨에 컨피그맵을 마운트하는 파드의 예시이다. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: mypod + image: redis + volumeMounts: + - name: foo + mountPath: "/etc/foo" + readOnly: true + volumes: + - name: foo + configmap: + name: myconfigmap +``` + +사용하려는 각 컨피그맵은 `.spec.volumes` 에서 참조해야 한다. + +파드에 여러 컨테이너가 있는 경우 각 컨테이너에는 자체 `volumeMounts` 블록이 필요하지만, +컨피그맵은 각 컨피그맵 당 하나의 `.spec.volumes` 만 필요하다. + +#### 마운트된 컨피그맵이 자동으로 업데이트 + +현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다. +kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다. +그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. +캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +`ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. + +컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 +모든 요청을 리디렉션할 수 있다. +따라서 컨피그맵이 업데이트되는 순간부터 새 키가 파드에 업데이트되는 순간까지의 +총 지연시간은 kubelet 동기화 기간 + 캐시 전파 지연만큼 길 수 있다. 여기서 캐시 +전파 지연은 선택한 캐시 유형에 따라 달라질 수 있다(전파 +지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함). + +{{< feature-state for_k8s_version="v1.18" state="alpha" >}} + +쿠버네티스 알파 기능인 _변경할 수 없는(immutable) 시크릿과 컨피그맵_ 은 개별 시크릿과 +컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게 +사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우 +데이터 변경을 방지하면 다음과 같은 이점이 있다. + +- 애플리케이션 중단을 일으킬 수 있는 우발적(또는 원하지 않는) 업데이트로부터 보호 +- immutable로 표시된 컨피그맵에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 + +이 기능을 사용하려면 `ImmutableEmphemeralVolumes` +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하고 +시크릿 또는 컨피그맵의 `immutable` 필드를 `true` 로 한다. 다음은 예시이다. +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + ... +data: + ... +immutable: true +``` + +{{< note >}} +컨피그맵 또는 시크릿을 immutable로 표시하면, 이 변경 사항을 되돌리거나 +`data` 필드 내용을 변경할 수 _없다_. 컨피그맵만 삭제하고 다시 작성할 수 있다. +기존 파드는 삭제된 컨피그맵에 대한 마운트 지점을 유지하며, 이러한 파드를 다시 작성하는 +것을 권장한다. +{{< /note >}} ## {{% heading "whatsnext" %}} @@ -167,4 +251,3 @@ spec: * 코드를 구성에서 분리하려는 동기를 이해하려면 [Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다. - diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index 0e50a842bba4b..483e664e2405d 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -99,7 +99,7 @@ kubectl config view `KUBECONFIG` 환경 변수 설정의 예로, [KUBECONFIG 환경 변수 설정](/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#kubeconfig-환경-변수-설정)를 참조한다. - 그렇지 않다면, 병합하지 않고 기본 kubecofig 파일인 `$HOME/.kube/config`를 사용한다. + 그렇지 않다면, 병합하지 않고 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다. 1. 이 체인에서 첫 번째를 기반으로 사용할 컨텍스트를 결정한다. diff --git a/content/ko/docs/concepts/configuration/pod-overhead.md b/content/ko/docs/concepts/configuration/pod-overhead.md index cafd3a921da5a..3dd850067c35b 100644 --- a/content/ko/docs/concepts/configuration/pod-overhead.md +++ b/content/ko/docs/concepts/configuration/pod-overhead.md @@ -8,6 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.18" state="beta" >}} + 노드 위에서 파드를 구동할 때, 파드는 그 자체적으로 많은 시스템 리소스를 사용한다. 이러한 리소스는 파드 내의 컨테이너들을 구동하기 위한 리소스 이외에 추가적으로 필요한 것이다. _파드 오버헤드_ 는 컨테이너 리소스 요청과 상한 위에서 파드의 인프라에 의해 diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md index 95671af60d40e..799306a9ff886 100644 --- a/content/ko/docs/concepts/containers/container-environment.md +++ b/content/ko/docs/concepts/containers/container-environment.md @@ -56,6 +56,7 @@ FOO_SERVICE_PORT=<서비스가 동작 중인 포트> * [컨테이너 라이프사이클 훅(hooks)](/ko/docs/concepts/containers/container-lifecycle-hooks/)에 대해 더 배워 보기. -* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) 실제 경험 얻기. +* [컨테이너 라이프사이클 이벤트에 핸들러 부착](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) + 실제 경험 얻기. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index afc9a3076af9a..f03847c38c08e 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -63,6 +63,7 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - Azure 컨테이너 레지스트리(ACR) 사용 + - IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함 - IBM 클라우드 컨테이너 레지스트리 사용 - IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 @@ -127,13 +128,19 @@ kubelet은 ECR 자격 증명을 가져오고 주기적으로 갱신할 것이다 - `aws_credentials.go:116] Got ECR credentials from ECR API for .dkr.ecr..amazonaws.com` ### Azure 컨테이너 레지스트리(ACR) 사용 -[Azure 컨테이너 레지스트리](https://azure.microsoft.com/en-us/services/container-registry/)를 사용하는 경우 -관리자 역할의 사용자나 서비스 주체(principal) 중 하나를 사용하여 인증할 수 있다. +쿠버네티스는 Azure 쿠버네티스 서비스(AKS)를 사용할 때 +[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를 +기본적으로 지원한다. + +AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한 +지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다. + +ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다. 어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은 [azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다. 우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는 -[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. +[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/azure/container-registry/container-registry-get-started-azure-cli)에서 찾을 수 있다. 컨테이너 레지스트리를 생성하고 나면, 다음의 자격 증명을 사용하여 로그인한다. @@ -367,4 +374,3 @@ imagePullSecrets을 셋팅하여 자동화할 수 있다. 다중 레지스트리에 접근해야 하는 경우, 각 레지스트리에 대해 하나의 시크릿을 생성할 수 있다. Kubelet은 모든`imagePullSecrets` 파일을 하나의 가상`.docker / config.json` 파일로 병합한다. - diff --git a/content/ko/docs/concepts/containers/overview.md b/content/ko/docs/concepts/containers/overview.md index 7ad30f57493db..9fc833a4ca429 100644 --- a/content/ko/docs/concepts/containers/overview.md +++ b/content/ko/docs/concepts/containers/overview.md @@ -31,7 +31,6 @@ weight: 10 애플리케이션을 변경하려는 경우, 변경사항을 포함하여 만든 새로운 이미지를 통해 컨테이너를 다시 생성해야 한다. - ## 컨테이너 런타임 {{< glossary_definition term_id="container-runtime" length="all" >}} diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 8af3bda7a8685..54500e7ad863e 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -1,5 +1,5 @@ --- -title: 런타임 클래스 +title: 런타임클래스(RuntimeClass) content_type: concept weight: 20 --- @@ -8,7 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다. +이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다. 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 구성은 파드의 컨테이너를 실행하는데 사용된다. @@ -20,69 +20,69 @@ weight: 20 ## 동기 -서로 다른 파드간에 런타임 클래스를 설정하여 +서로 다른 파드간에 런타임클래스를 설정하여 성능대 보안의 균형을 유지할 수 있다. 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. 그러면 몇가지 추가적인 오버헤드는 있지만 대체 런타임을 추가 분리하는 유익이 있다. -또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 +또한 런타임클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 여러 파드를 실행할 수 있다. ## 셋업 -RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. -특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 -참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. +런타임클래스 기능 게이트가 활성화(기본값)된 것을 확인한다. +기능 게이트 활성화에 대한 설명은 [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +참고한다. `RuntimeClass` 기능 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. 1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) -2. 상응하는 런타임 클래스 리소스 생성 +2. 상응하는 런타임클래스 리소스 생성 ### 1. CRI 구현을 노드에 설정 -런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. +런타임클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. 사용자의 CRI 구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다([아래](#cri-configuration)). {{< note >}} -런타임 클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 +런타임클래스는 기본적으로 클러스터 전체에 걸쳐 동질의 노드 설정 (모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 이종의(heterogenous) 노드 설정을 지원하기 위해서는, 아래 [스케줄](#스케줄)을 참고한다. {{< /note >}} -해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. +해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다. -### 2. 상응하는 런타임 클래스 리소스 생성 +### 2. 상응하는 런타임클래스 리소스 생성 1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. -각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다. +각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임클래스 오브젝트를 생성한다. -현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러 +현재 런타임클래스 리소스는 런타임클래스 이름(`metadata.name`)과 런타임 핸들러 (`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다. ```yaml -apiVersion: node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음 +apiVersion: node.k8s.io/v1beta1 # 런타임클래스는 node.k8s.io API 그룹에 정의되어 있음 kind: RuntimeClass metadata: - name: myclass # 런타임 클래스는 해당 이름을 통해서 참조됨 - # 런타임 클래스는 네임스페이스가 없는 리소스임 + name: myclass # 런타임클래스는 해당 이름을 통해서 참조됨 + # 런타임클래스는 네임스페이스가 없는 리소스임 handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` -런타임 클래스 오브젝트의 이름은 유효한 +런타임클래스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)어이야 한다. {{< note >}} -런타임 클래스 쓰기 작업(create/update/patch/delete)은 +런타임클래스 쓰기 작업(create/update/patch/delete)은 클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} ## 사용 -클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 +클러스터를 위해서 런타임클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다. ```yaml @@ -95,14 +95,14 @@ spec: # ... ``` -이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. -만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 +이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. +만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 `Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다. 에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 확인한다. 만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며, -런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다. +런타임클래스 기능이 비활성화되었을 때와 동일하게 동작한다. ### CRI 구성 {#cri-configuration} @@ -143,24 +143,26 @@ https://github.com/containerd/cri/blob/master/docs/config.md {{< feature-state for_k8s_version="v1.16" state="beta" >}} -쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 지원을 포함한다. -이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 노드로 스케줄된다는 것을 보장할 수 있다. -이 스케줄링 기능을 사용하려면, [런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본 값)해야 한다. +쿠버네티스 v1.16 부터, 런타임 클래스는 `scheduling` 필드를 통해 이종의 클러스터 +지원을 포함한다. 이 필드를 사용하면, 이 런타임 클래스를 갖는 파드가 이를 지원하는 +노드로 스케줄된다는 것을 보장할 수 있다. 이 스케줄링 기능을 사용하려면, +[런타임 클래스 어드미션(admission) 컨트롤러][]를 활성화(1.16 부터 기본값)해야 한다. -파드가 지정된 런타임 클래스를 지원하는 노드에 안착한다는 것을 보장하려면, +파드가 지정된 런타임클래스를 지원하는 노드에 안착한다는 것을 보장하려면, 해당 노드들은 `runtimeClass.scheduling.nodeSelector` 필드에서 선택되는 공통 레이블을 가져야한다. 런타임 클래스의 nodeSelector는 파드의 nodeSelector와 어드미션 시 병합되어서, 실질적으로 -각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, 파드는 거부된다. +각각에 의해 선택된 노드의 교집합을 취한다. 충돌이 있는 경우, +파드는 거부된다. -지원되는 노드가 테인트(taint)되어서 다른 런타임 클래스 파드가 노드에서 구동되는 것을 막고 있다면, -`tolerations`를 런타임 클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 +지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면, +`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시 해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된 노드의 합집합을 취한다. 노드 셀렉터와 톨러레이션 설정에 대해 더 배우려면 [노드에 파드 할당](/ko/docs/concepts/scheduling-eviction/assign-pod-node/)을 참고한다. -[런타임 클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass +[런타임클래스 어드미션 컨트롤러]: /docs/reference/access-authn-authz/admission-controllers/#runtimeclass ### 파드 오버헤드 @@ -171,7 +173,6 @@ https://github.com/containerd/cri/blob/master/docs/config.md PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 시켜야 한다. (기본으로 활성화 되어 있다.) - 파드 오버헤드는 런타임 클래스에서 `overhead` 필드를 통해 정의된다. 이 필드를 사용하면, 해당 런타임 클래스를 사용해서 구동 중인 파드의 오버헤드를 특정할 수 있고 이 오버헤드가 쿠버네티스 내에서 처리된다는 것을 보장할 수 있다. @@ -180,8 +181,8 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c ## {{% heading "whatsnext" %}} -- [런타임 클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) -- [런타임 클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) +- [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) +- [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) - [파드 오버헤드](/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 - [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index 3b0b42dfccab9..53d925f891d8f 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -35,9 +35,8 @@ extention API server가 레이턴시 요구 사항을 달성할 수 없는 경 ## {{% heading "whatsnext" %}} -* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/). -* 다음에, [extension api-server를 구성해서](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. -* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)를 배워본다. +* 사용자의 환경에서 Aggregator를 동작시키려면, [애그리게이션 레이어를 설정한다](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). +* 다음에, [확장 API 서버를 구성해서](/docs/tasks/extend-kubernetes/setup-extension-api-server/) 애그리게이션 레이어와 연계한다. +* 또한, 어떻게 [쿠버네티스 API를 커스텀 리소스 데피니션으로 확장하는지](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)를 배워본다. * [API 서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)의 사양을 읽어본다. - 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 9e9f3e9e2938c..0d7c08a9a4624 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 @@ -175,15 +175,15 @@ CRD는 애그리게이트 API보다 생성하기가 쉽다. | 기능 | 설명 | CRD | 애그리게이트 API | | ------- | ----------- | ---- | -------------- | -| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | -| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | -| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning) | 예 | +| 유효성 검사 | 사용자가 오류를 방지하고 클라이언트와 독립적으로 API를 발전시킬 수 있도록 도와준다. 이러한 기능은 동시에 많은 클라이언트를 모두 업데이트할 수 없는 경우에 아주 유용하다. | 예. [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation)를 사용하여 CRD에서 대부분의 유효성 검사를 지정할 수 있다. [웹훅 유효성 검사](/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)를 추가해서 다른 모든 유효성 검사를 지원한다. | 예, 임의의 유효성 검사를 지원한다. | +| 기본 설정 | 위를 참고하자. | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)의 `default` 키워드(1.17에서 GA) 또는 [웹훅 변형(mutating)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)(이전 오브젝트의 etcd에서 읽을 때는 실행되지 않음)을 통해 지원한다. | 예 | +| 다중 버전 관리 | 두 가지 API 버전을 통해 동일한 오브젝트를 제공할 수 있다. 필드 이름 바꾸기와 같은 API 변경을 쉽게 할 수 있다. 클라이언트 버전을 제어하는 ​​경우는 덜 중요하다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning) | 예 | | 사용자 정의 스토리지 | 다른 성능 모드(예를 들어, 키-값 저장소 대신 시계열 데이터베이스)나 보안에 대한 격리(예를 들어, 암호화된 시크릿이나 다른 암호화) 기능을 가진 스토리지가 필요한 경우 | 아니오 | 예 | | 사용자 정의 비즈니스 로직 | 오브젝트를 생성, 읽기, 업데이트 또는 삭제를 할 때 임의의 점검 또는 조치를 수행한다. | 예, [웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용한다. | 예 | -| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#scale-subresource) | 예 | -| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#status-subresource) | 예 | +| 서브리소스 크기 조정 | HorizontalPodAutoscaler 및 PodDisruptionBudget과 같은 시스템이 새로운 리소스와 상호 작용할 수 있다. | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) | 예 | +| 서브리소스 상태 | 사용자가 스펙 섹션을 작성하고 컨트롤러가 상태 섹션을 작성하는 세분화된 접근 제어를 허용한다. 커스텀 리소스 데이터 변형 시 오브젝트 생성을 증가시킨다(리소스에서 별도의 스펙과 상태 섹션 필요). | [예](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource) | 예 | | 기타 서브리소스 | "logs" 또는 "exec"과 같은 CRUD 이외의 작업을 추가한다. | 아니오 | 예 | -| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/run-application/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | +| strategic-merge-patch | 새로운 엔드포인트는 `Content-Type: application/strategic-merge-patch+json` 형식의 PATCH를 지원한다. 로컬 및 서버 양쪽에서 수정할 수도 있는 오브젝트를 업데이트하는 데 유용하다. 자세한 내용은 ["kubectl 패치를 사용한 API 오브젝트 업데이트"](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)를 참고한다. | 아니오 | 예 | | 프로토콜 버퍼 | 새로운 리소스는 프로토콜 버퍼를 사용하려는 클라이언트를 지원한다. | 아니오 | 예 | | OpenAPI 스키마 | 서버에서 동적으로 가져올 수 있는 타입에 대한 OpenAPI(스웨거(swagger)) 스키마가 있는가? 허용된 필드만 설정하여 맞춤법이 틀린 필드 이름으로부터 사용자를 보호하는가? 타입이 적용되는가(즉, `string` 필드에 `int`를 넣지 않는가?) | 예, [OpenAPI v3.0 유효성 검사](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/#validation)를 기반으로 하는 스키마(1.16에서 GA) | 예 | @@ -250,6 +250,5 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부 * [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기. -* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. - +* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index d75601de9f4eb..a22ad8112cd1e 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -158,7 +158,7 @@ kubelet 인스턴스에 자신을 다시 등록할 것으로 기대된다. 현 장치 플러그인에서 제공하는 리소스를 모니터링하려면, 모니터링 에이전트가 노드에서 사용 중인 장치 셋을 검색하고 메트릭과 연관될 컨테이너를 설명하는 메타데이터를 얻을 수 있어야 한다. 장치 모니터링 에이전트에 의해 노출된 -[프로메테우스(Prometheus)](https://prometheus.io/) 지표는 +[프로메테우스](https://prometheus.io/) 지표는 [쿠버네티스 Instrumentation 가이드라인](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)을 따라 `pod`, `namespace` 및 `container` 프로메테우스 레이블을 사용하여 컨테이너를 식별해야 한다. diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 3d4a8b8370f48..8d0efc2212914 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -56,6 +56,8 @@ card: ### cloud-controller-manager +{{< glossary_definition term_id="cloud-controller-manager" length="short" >}} + cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행한다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다. diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index aa5d4a043d38c..d1d1e3d49948f 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -9,17 +9,15 @@ card: -전체 API 관례는 [API conventions doc](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)에 기술되어 있다. +쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 핵심은 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}이다. API 서버는 +최종 사용자, 클러스터의 다른 부분 그리고 외부 컴포넌트가 서로 통신할 +수 있도록 HTTP API를 제공한다. -API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/reference)에 기술되어 있다. +쿠버네티스 API를 사용하면 쿠버네티스 API 오브젝트(예: +파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의하고 조작할 수 있다. -API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다. - -쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. - -쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. - -쿠버네티스 자체는 여러 컴포넌트로 나뉘어져서 각각의 API를 통해 상호작용한다. +API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/ko/docs/reference)에 기술되어 있다. @@ -28,54 +26,77 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc ## API 변경 -경험에 따르면, 성공적인 시스템은 새로운 유스케이스의 등장과 기존 유스케이스의 변경에 맞춰 성장하고 변경될 필요가 있다. 그래서, 쿠버네티스 API가 지속적으로 변경되고 성장하기를 바란다. 그러나, 일정 기간 동안은 현재의 클라이언트와의 호환성을 깨지 않으려고 한다. 일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. 리소스나 필드를 없애는 일은 다음의 [API deprecation policy](/docs/reference/using-api/deprecation-policy/)를 따른다. - -호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 [API change document](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md)에 있다. +새로운 유스케이스가 등장하거나 기존 시스템이 변경됨에 따라 성공적인 시스템은 성장하고 변경될 필요가 있다. +따라서, 쿠버네티스는 쿠버네티스 API를 지속적으로 변경하고 성장시킬 수 있는 디자인 기능을 가지고 있다. +쿠버네티스 프로젝트는 기존 클라이언트와의 호환성을 중단하지 _않고_, +다른 프로젝트가 적응할 수 있도록 오랫동안 호환성을 유지하는 것을 목표로 한다. -## OpenAPI 및 Swagger 정의 +일반적으로, 새로운 API 리소스와 새로운 리소스 필드가 주기적으로 추가될 것이다. +리소스나 필드를 없애는 일은 다음의 +[API 사용 중단 정책](/docs/reference/using-api/deprecation-policy/)을 따른다. -완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. - -쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. -요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다. +호환되는 변경에 어떤 내용이 포함되는지, 어떻게 API를 변경하는지에 대한 자세한 내용은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)을 참고한다. -헤더 | 가능한 값 ------- | --------- -Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음) -Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨) +## OpenAPI 명세 {#api-specification} -1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - -**OpenAPI 규격을 조회하는 예제** +완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -1.10 이전 | 쿠버네티스 1.10 이상 ------------ | ----------------------------- -GET /swagger.json | GET /openapi/v2 **Accept**: application/json -GET /swagger-2.0.0.pb-v1 | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf -GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github.proto-openapi.spec.v2@v1.0+protobuf **Accept-Encoding**: gzip +OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. +다음과 같은 요청 헤더를 사용해서 응답 형식을 요청할 수 있다. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HeaderPossible valuesNotes
Accept-Encodinggzipnot supplying this header is also acceptable
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use
application/jsondefault
*serves application/json
Valid request header values for OpenAPI v2 queries
쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다. -1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) -쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. -이러한 엔드포인트는 사용이 중단되었으며, 쿠버네티스 1.14에서 제거되었다. - ## API 버전 규칙 필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. -리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다. +버전 관리는 API가 시스템 리소스와 동작에 대해 명확하고 일관된 보기를 +제공하고 수명 종료(end-of-life)와 실험적인 API에 대한 접근을 제어할 수 있도록 +리소스 또는 필드 수준이 아닌 API 수준에서 수행된다. -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. -[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 -API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. +JSON과 Protobuf 직렬화 스키마는 스키마 변경에 대한 동일한 지침을 따르며 아래의 모든 설명은 두 형식을 모두 포함한다. +참고로 API 버전 관리와 소프트웨어 버전 관리는 간접적으로만 연관이 있다. +[쿠버네티스 릴리스 버전 관리](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +제안은 API 버전 관리와 소프트웨어 버전 관리 사이의 관계를 설명한다. -API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. -각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다. +API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 +[API 변경](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 +상세히 다룬다. 요약하자면 다음과 같다. - 알파(Alpha) 수준: - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) @@ -102,32 +123,35 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르 쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다. -현재 다양한 API 그룹이 사용되고 있다. +클러스터에 다양한 API 그룹이 있다. -1. *핵심* 그룹 또는 *레거시 그룹* 이라고 하는 그룹은 REST 경로 `/api/v1`에서 `apiVersion: v1`을 사용한다. +1. *레거시* 그룹이라고도 하는 *핵심* 그룹은 REST 경로인 `/api/v1/` 에 있고, `apiVersion: v1`을 사용한다. 1. 이름이 있는 그룹은 REST 경로 `/apis/$GROUP_NAME/$VERSION`에 있으며 `apiVersion: $GROUP_NAME/$VERSION`을 사용한다 - (예: `apiVersion: batch/v1`). 지원되는 API 그룹 전체의 목록은 [Kubernetes API reference](/docs/reference/)에서 확인할 수 있다. + (예: `apiVersion: batch/v1`). 사용 가능한 API 그룹의 전체의 목록은 + [쿠버네티스 API 참조](/ko/docs/reference/)에 있다. -[Custom resources](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 두 종류의 경로가 지원된다. +[사용자 지정 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)로 API를 확장하는 두 가지 방법이 있다. -1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인 - CRUD 요구를 갖는 사용자에게 적합하다. -1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는 - [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록 - 만들 수 있다. +1. [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)은 + API 서버가 선택한 리소스 API를 제공하는 방법을 선언적으로 정의할 수 있다. +1. 또한, [자신의 확장 API 서버 구현](/docs/tasks/extend-kubernetes/setup-extension-api-server/)과 + [aggregator](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)를 + 사용해서 클라이언트를 원활하게 만들 수 있다. ## API 그룹 활성화 또는 비활성화하기 -특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. 이들은 apiserver에서 `--runtime-config`를 설정해서 활성화하거나 -비활성화 시킬 수 있다. `--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화 시키려면 -`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을 -설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. +특정 리소스와 API 그룹은 기본적으로 활성화되어 있다. kube-apiserver에서 커맨드 라인 옵션으로 `--runtime-config` 를 +설정해서 활성화하거나 비활성화할 수 있다. + +`--runtime-config`는 쉼표로 분리된 값을 허용한다. 예를 들어서 batch/v1을 비활성화시키려면, +`--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화시키려면, `--runtime-config=batch/v2alpha1`을 +설정한다. 이 플래그는 API 서버의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. -{{< note >}}그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 -`--runtime-config` 변경을 반영시켜야 한다. {{< /note >}} +{{< note >}}그룹이나 리소스를 활성화 또는 비활성화하려면 kube-apiserver와 +controller-manager를 재시작해서 `--runtime-config` 변경 사항을 반영해야 한다. {{< /note >}} ## extensions/v1beta1 그룹 내 특정 리소스 활성화하기 @@ -137,4 +161,19 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 {{< note >}}개별 리소스의 활성화/비활성화는 레거시 문제로 `extensions/v1beta1` API 그룹에서만 지원된다. {{< /note >}} +## 지속성 + +쿠버네티스는 API 리소스에 대한 직렬화된 상태를 {{< glossary_tooltip term_id="etcd" >}}에 +기록하고 저장한다. + + +## {{% heading "whatsnext" %}} + +[API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)는 클러스터가 +API 접근에 대한 인증과 권한을 관리하는 방법을 설명한다. + +전체 API 규약은 +[API 규약](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) +문서에 설명되어 있다. +API 엔드포인트, 리소스 타입과 샘플은 [API 참조](/docs/reference/kubernetes-api/)에 설명되어 있다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index be7db19bb5b81..c9125cbe3dbe4 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -8,7 +8,8 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 공통 레이블 셋은 모든 도구들이 이해할 수 있는 공통의 방식으로 오브젝트를 식별하고 도구들이 상호 운용적으로 작동할 수 있도록 한다. -권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 애플리케이션을 식별하게 한다. +권장 레이블은 지원 도구 외에도 쿼리하는 방식으로 +애플리케이션을 식별하게 한다. @@ -18,17 +19,18 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 애플리케이션에 포함된 정의는 유연하다. {{< note >}} -메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 코어 도구에는 필요하지 않다. +메타데이터들은 권장하는 레이블이다. 애플리케이션을 보다 쉽게 관리할 수 있지만 +코어 도구에는 필요하지 않다. {{< /note >}} 공유 레이블과 주석에는 공통 접두사인 `app.kubernetes.io` 가 있다. 접두사가 없는 레이블은 사용자가 개인적으로 사용할 수 있다. 공유 접두사는 공유 레이블이 사용자 정의 레이블을 방해하지 않도록 한다. - ## 레이블 -레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. +레이블을 최대한 활용하려면 모든 리소스 오브젝트에 +적용해야 한다. | Key | Description | Example | Type | | ----------------------------------- | --------------------- | -------- | ---- | @@ -56,8 +58,9 @@ metadata: ## 애플리케이션과 애플리케이션 인스턴스 -애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 한번 또는 그 이상 설치할 수 있다. -예를 들어 워드프레스는 다른 워드프레스가 설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. +애플리케이션은 때에 따라 쿠버네티스 클러스터의 동일한 네임스페이스에 +한번 또는 그 이상 설치할 수 있다. 예를 들어 워드프레스는 다른 워드프레스가 +설치되어있는 웹사이트에 한번 한번 또는 그 이상 설치할 수 있다. 애플리케이션의 이름과 인스턴스 이름은 별도로 기록된다. 예를 들어 워드프레스는 `app.kubernetes.io/name` 에 `wordpress` 를 가지며 인스턴스 이름으로는 @@ -97,7 +100,8 @@ metadata: ### 데이터베이스가 있는 웹 애플리케이션 -Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. +Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 +설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. 다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md index 06326befa8ef5..9a343ca5c52e2 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/ko/docs/concepts/overview/working-with-objects/field-selectors.md @@ -16,12 +16,7 @@ kubectl get pods --field-selector status.phase=Running ``` {{< note >}} -필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 따라서 다음의 `kubectl` 쿼리들은 동일하다. - -```shell -kubectl get pods -kubectl get pods --field-selector "" -``` +필드 셀렉터는 본질적으로 리소스 *필터* 이다. 기본적으로 적용되는 셀렉터나 필드는 없으며, 이는 명시된 종류의 모든 리소스가 선택된다는 것을 의미한다. 여기에 따라오는 `kubectl` 쿼리인 `kubectl get pods` 와 `kubectl get pods --field-selector ""` 는 동일하다. {{< /note >}} ## 사용 가능한 필드 @@ -53,7 +48,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway ## 여러 개의 리소스 종류 -필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀 셋과 서비스를 선택한다. +필드 셀렉터를 여러 개의 리소스 종류에 걸쳐 사용할 수 있다. 다음의 `kubectl` 커맨드는 `default` 네임스페이스에 속해있지 않은 모든 스테이트풀셋(StatefulSet)과 서비스를 선택한다. ```shell kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default 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 1fe7183c2990e..73fa4ff4d0e6f 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 @@ -44,7 +44,8 @@ spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 -어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 +어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 +경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다. 오브젝트 명세, 상태, 그리고 메타데이터에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다. @@ -91,6 +92,5 @@ deployment.apps/nginx-deployment created ## {{% heading "whatsnext" %}} * API 개념의 더 많은 설명은 [Kubernetes API 개요](/ko/docs/reference/using-api/api-overview/)를 본다. -* [파드(Pod)](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. +* [파드](/ko/docs/concepts/workloads/pods/pod-overview/)와 같이, 가장 중요하고 기본적인 쿠버네티스 오브젝트에 대해 배운다. * 쿠버네티스의 [컨트롤러](/ko/docs/concepts/architecture/controller/)에 대해 배운다. - 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 fe8b0ce8fb522..e06daff9295e3 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -83,7 +83,8 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의 레이블 셀렉터는 쉼표로 구분된 다양한 _요구사항_ 에 따라 만들 수 있다. 다양한 요구사항이 있는 경우 쉼표 기호가 AND(`&&`) 연산자로 구분되는 역할을 하도록 해야 한다. 비어있거나 지정되지 않은 셀렉터는 상황에 따라 달라진다. -셀렉터를 사용하는 API 유형은 유효성과 의미를 문서화해야 한다. +셀렉터를 사용하는 API 유형은 유효성과 의미를 +문서화해야 한다. {{< note >}} 레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 0cb3e7656a7b5..891ad4d07a21b 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -15,7 +15,6 @@ weight: 20 - ## 이름 {#names} diff --git a/content/ko/docs/concepts/overview/working-with-objects/object-management.md b/content/ko/docs/concepts/overview/working-with-objects/object-management.md index 550cbe951c6cf..9b59aae529bfe 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ko/docs/concepts/overview/working-with-objects/object-management.md @@ -127,7 +127,6 @@ kubectl replace -f nginx.yaml - 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다. - 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다. - ## 선언형 오브젝트 구성 선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트 @@ -178,6 +177,7 @@ kubectl apply -R -f configs/ ## {{% heading "whatsnext" %}} + - [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) - [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) @@ -186,6 +186,4 @@ kubectl apply -R -f configs/ - [Kubectl 서적](https://kubectl.docs.kubernetes.io) - [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) -{{< comment >}} -{{< /comment >}} diff --git a/content/ko/docs/concepts/policy/limit-range.md b/content/ko/docs/concepts/policy/limit-range.md index e2bd0a10d3d6b..ee30ec64374df 100644 --- a/content/ko/docs/concepts/policy/limit-range.md +++ b/content/ko/docs/concepts/policy/limit-range.md @@ -24,11 +24,13 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. ## 리밋레인지 활성화 -많은 쿠버네티스 배포판에 리밋레인지 지원이 기본적으로 활성화되어 있다. apiserver `--enable-admission-plugins=` 플래그의 인수 중 하나로 `LimitRanger` 어드미션 컨트롤러가 있는 경우 활성화된다. +쿠버네티스 1.10 버전부터 리밋레인지 지원이 기본적으로 활성화되었다. -해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 특정 네임스페이스에 리밋레인지가 지정된다. +해당 네임스페이스에 리밋레인지 오브젝트가 있는 경우 +특정 네임스페이스에 리밋레인지가 지정된다. -리밋레인지 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야한다. +리밋레인지 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ### 리밋 레인지 개요 @@ -36,7 +38,8 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - 사용자는 네임스페이스에서 파드, 컨테이너 및 퍼시스턴트볼륨클레임과 같은 리소스를 생성한다. - `LimitRanger` 어드미션 컨트롤러는 컴퓨팅 리소스 요청 사항을 설정하지 않은 모든 파드와 컨테이너에 대한 기본값과 제한을 지정하고 네임스페이스의 리밋레인지에 정의된 리소스의 최소, 최대 및 비율을 초과하지 않도록 사용량을 추적한다. - 리밋레인지 제약 조건을 위반하는 리소스(파드, 컨테이너, 퍼시스턴트볼륨클레임)를 생성하거나 업데이트하는 경우 HTTP 상태 코드 `403 FORBIDDEN` 및 위반된 제약 조건을 설명하는 메시지와 함께 API 서버에 대한 요청이 실패한다. -- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. +- `cpu`, `memory`와 같은 컴퓨팅 리소스의 네임스페이스에서 리밋레인지가 활성화된 경우 사용자는 해당 값에 + 대한 요청 또는 제한을 지정해야 한다. 그렇지 않으면 시스템에서 파드 생성이 거부될 수 있다. - 리밋레인지 유효성 검사는 파드 실행 단계가 아닌 파드 어드미션 단계에서만 발생한다. 리밋 레인지를 사용하여 생성할 수 있는 정책의 예는 다음과 같다. @@ -66,4 +69,3 @@ _리밋레인지_ 는 다음과 같은 제약 조건을 제공한다. - [네임스페이스당 할당량을 설정하는 자세한 예시](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/). - diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index 57a115fc69fa3..de6ab7a25deb9 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -31,7 +31,7 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 | 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) | | 볼륨 유형의 사용 | [`volumes`](#볼륨-및-파일시스템) | | 호스트 파일시스템의 사용 | [`allowedHostPaths`](#볼륨-및-파일시스템) | -| FlexVolume 드라이버의 화이트리스트 | [`allowedFlexVolumes`](#flexvolume-드라이버) | +| 특정 FlexVolume 드라이버의 허용 | [`allowedFlexVolumes`](#flexvolume-드라이버) | | 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#볼륨-및-파일시스템) | | 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) | | 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) | @@ -398,13 +398,13 @@ podsecuritypolicy "example" deleted 동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데 사용할 수 있다. -**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 화이트리스트(whitelist)를 +**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을 제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다. 기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다. ### 볼륨 및 파일시스템 -**Volumes** - 허용되는 볼륨 유형의 화이트리스트를 제공한다. 허용 가능한 값은 +**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은 볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은 [볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다. 또한 `*`를 사용하여 모든 볼륨 유형을 @@ -435,7 +435,7 @@ podsecuritypolicy "example" deleted 유효성을 검사한다. - *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다. -**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 화이트리스트를 +**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을 지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다. 이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은 허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는 @@ -466,7 +466,7 @@ allowedHostPaths: ### FlexVolume 드라이버 -flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 화이트리스트를 지정한다. +flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다. 빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다. [`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어 있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다. @@ -552,7 +552,7 @@ spec: 다음 필드는 대문자로 표기된 기능 이름 목록을 `CAP_` 접두사 없이 가져온다. -**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 화이트리스트를 +**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을 제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은 기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을 의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다. @@ -576,7 +576,7 @@ spec: ### AllowedProcMountTypes -`allowedProcMountTypes`는 허용된 ProcMountTypes의 화이트리스트이다. +`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다. 비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다. `DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임 @@ -637,4 +637,3 @@ spec: API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. - diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index 4aec897572b7d..7c7a6f64a87a9 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -56,7 +56,8 @@ weight: 10 API 서버 `--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. -해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 리소스 쿼터가 적용된다. +해당 네임스페이스에 `ResourceQuota`가 있는 경우 특정 네임스페이스에 +리소스 쿼터가 적용된다. ## 컴퓨트 리소스 쿼터 @@ -160,9 +161,10 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `services.nodeports` | 네임스페이스에 존재할 수 있는 노드 포트 유형의 총 서비스 수 | | `secrets` | 네임스페이스에 존재할 수 있는 총 시크릿 수 | -예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 계산하고 최대값을 적용한다. -사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP 공급이 고갈되는 경우를 피하기 위해 -네임스페이스에 `pods` 쿼터를 설정할 수 있다. +예를 들어, `pods` 쿼터는 터미널이 아닌 단일 네임스페이스에서 생성된 `pods` 수를 +계산하고 최댓값을 적용한다. 사용자가 작은 파드를 많이 생성하여 클러스터의 파드 IP +공급이 고갈되는 경우를 피하기 위해 네임스페이스에 +`pods` 쿼터를 설정할 수 있다. ## 쿼터 범위 @@ -599,4 +601,3 @@ plugins: 자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)를 참고하길 바란다. - diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index a56dece692d0a..4694533315d58 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -151,7 +151,7 @@ spec: 예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. `NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나, -특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/docs/concepts/configuration/taint-and-toleration/)를 설정할 수 있다. +특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. `nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄 되기 위해서는 *둘 다* 반드시 만족해야 한다. @@ -206,13 +206,11 @@ spec: `preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값 "S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다. (보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키 -`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, 노드 N이 키 -`failure-domain.beta.kubernetes.io/zone` 와 일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) -파드 안티-어피니티 규칙에 의하면 노드가 이미 키 "security"와 값 "S2"인 레이블을 가진 파드를 -실행하고 있는 파드는 노드에 스케줄되는 것을 선호하지 않는다. -(만약 `topologyKey` 가 `failure-domain.beta.kubernetes.io/zone` 라면 노드가 키 -"security"와 값 "S2"를 레이블로 가진 파드와 -동일한 영역에 있는 경우, 노드에 파드를 예약할 수 없음을 의미한다.) +`failure-domain.beta.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, +노드 N이 키 `failure-domain.beta.kubernetes.io/zone` 와 +일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) +파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와 +동일한 영역의 노드에 스케줄되지 않는다. [디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의 파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다. @@ -222,10 +220,11 @@ spec: 원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다. 하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다. -1. 어피니티와 `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 대해 -`topologyKey` 가 비어있는 것을 허용하지 않는다. -2. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를에 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 간단히 이를 비활성화 할 수 있다. -3. `preferredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티는 `topologyKey` 가 비어있는 것을 허용하지 않는다. +1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 +`topologyKey` 의 빈 값을 허용하지 않는다. +3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 간단히 이를 비활성화해야 한다. 4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. `labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 @@ -388,7 +387,7 @@ spec: ## {{% heading "whatsnext" %}} -[테인트](/docs/concepts/configuration/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아내게* 할 수 있다. +[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다. [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 @@ -397,5 +396,3 @@ spec: 파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 노드 수준의 리소스 할당 결정에 참여할 수 있다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 54373e2e2cecb..576d966a9b5c6 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -89,10 +89,10 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 ## {{% heading "whatsnext" %}} -* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling/scheduler-perf-tuning/)에 대해 읽기 +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/administer-cluster/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 -* [파드 오버헤드](/docs/concepts/configuration/pod-overhead/)에 대해 배우기 +* [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 52db3136352b5..b564eda5fb971 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -8,8 +8,8 @@ weight: 70 {{< feature-state for_k8s_version="1.14" state="beta" >}} -[kube-scheduler](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) -는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 +[kube-scheduler](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler)는 +쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의 노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는 @@ -19,7 +19,7 @@ weight: 70 높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 _바인딩_ 이라는 프로세스로 API 서버에 해당 결정을 통지한다. -본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 +본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다. @@ -45,7 +45,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 일 수 있다)을 편집한 다음 스케줄러를 재시작 한다. -이를 변경한 후에 다음을 실행해서 +이를 변경한 후에 다음을 실행해서 ```bash kubectl get componentstatuses ``` @@ -68,7 +68,7 @@ scheduler Healthy ok 정수 값(숫자)로 변환 한다. 스케줄링 중에 kube-scheduler가 구성된 비율을 초과 할만큼 충분히 실행 가능한 노드를 식별한 경우, kube-scheduler는 더 실행 가능한 노드를 찾는 검색을 중지하고 -[스코어링 단계](/ko/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation)를 진행한다. +[스코어링 단계](/ko/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)를 진행한다. [스케줄러가 노드 탐색을 반복(iterate)하는 방법](#스케줄러가-노드-탐색을-반복-iterate-하는-방법) 은 이 프로세스를 자세히 설명한다. @@ -101,14 +101,15 @@ algorithmSource: percentageOfNodesToScore: 50 ``` + ### percentageOfNodesToScore 튜닝 -`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며 -기본 값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 -최소 값도 있다. +`percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며 +기본값은 클러스터 크기에 따라 계산된다. 또한 50 노드로 하드 코딩된 +최솟값도 있다. -{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 -모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 +{{< note >}} 클러스터에서 적합한 노드가 50 미만인 경우, 스케줄러는 여전히 +모든 노드를 확인한다. 그 이유는 스케줄러가 탐색을 조기 중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다. 규모가 작은 클러스터에서는 `percentageOfNodesToScore` 에 낮은 값을 설정하면, @@ -119,10 +120,10 @@ percentageOfNodesToScore: 50 성능이 크게 향상되지 않는다. {{< /note >}} -이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 +이 값을 세팅할 때 중요하고 자세한 사항은, 클러스터에서 적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서 -일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 -가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 +일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데 +가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지 않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다. `percentageOfNodesToScore` 를 매우 낮게 설정해서 kube-scheduler가 @@ -133,19 +134,19 @@ percentageOfNodesToScore: 50 ## 스케줄러가 노드 탐색을 반복(iterate)하는 방법 -이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 +이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을 위해 작성되었다. -클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 +클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를 가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을 -반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 -시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 -찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 -이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 +반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의 +시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를 +찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가 +이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막 포인트부터 확인을 재개한다. -만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 -확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 +만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성 +확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서 탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자. ``` @@ -160,5 +161,3 @@ percentageOfNodesToScore: 50 ``` 모든 노드를 검토한 후, 노드 1로 돌아간다. - - diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index 0d0a192dddab1..2100a6de105c1 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -6,16 +6,17 @@ weight: 40 -[여기](/ko/docs/concepts/configuration/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)에 설명된 노드 어피니티는 -노드 셋을 *끌어들이는* (기본 설정 또는 어려운 요구 사항) -*파드* 속성이다. 테인트는 그 반대로, *노드* 가 파드 셋을 -*제외* 할 수 있다. +[_노드 어피니티_](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)는 +{{< glossary_tooltip text="노드" term_id="node" >}} 셋을 +(기본 설정 또는 어려운 요구 사항으로) *끌어들이는* {{< glossary_tooltip text="파드" term_id="pod" >}}의 속성이다. +_테인트_ 는 그 반대로, 노드가 파드 셋을 제외할 수 있다. + +_톨러레이션_ 은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 +스케줄되게 하지만 필수는 아니다. 테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다. 하나 이상의 테인트가 노드에 적용된다. 이것은 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 되는 것을 나타낸다. -톨러레이션은 파드에 적용되며, 파드를 일치하는 테인트가 있는 노드에 스케줄되게 -하지만 필수는 아니다. @@ -61,13 +62,13 @@ tolerations: {{< codenew file="pods/pod-with-toleration.yaml" >}} +지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. + 톨러레이션은 키가 동일하고 이펙트가 동일한 경우, 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다. * `operator` 가 `Exists` 인 경우(이 경우 `value` 를 지정하지 않아야 함), 또는 * `operator` 는 `Equal` 이고 `value` 는 `value` 로 같다. -지정하지 않으면 `operator` 의 기본값은 `Equal` 이다. - {{< note >}} 두 가지 특별한 경우가 있다. @@ -198,8 +199,7 @@ tolerations: * `tolerationSeconds` 가 지정된 테인트를 용인하는 파드는 지정된 시간 동안 바인딩된 상태로 유지된다. -덧붙여, 쿠버네티스 1.6 버전에서는 노드 문제를 나타내는 알파 지원이 -도입되었다. 다시 말해, 특정 조건이 참일 때 노드 컨트롤러는 자동으로 +노드 컨트롤러는 특정 조건이 참일 때 자동으로 노드를 테인트시킨다. 다음은 빌트인 테인트이다. * `node.kubernetes.io/not-ready`: 노드가 준비되지 않았다. 이는 NodeCondition @@ -221,10 +221,9 @@ tolerations: 관련 테인트를 제거할 수 있다. {{< note >}} -노드 문제로 인해 파드 축출의 기존 [비율 제한](/ko/docs/concepts/architecture/nodes/) -동작을 유지하기 위해, 시스템은 실제로 테인트를 비율-제한 방식으로 -추가한다. 이는 마스터가 노드에서 분할되는 등의 시나리오에서 -대규모 파드 축출을 방지한다. +콘트롤 플레인은 노드에 새 테인트를 추가하는 비율을 제한한다. +이 비율-제한은 많은 노드가 동시에 도달할 수 없을 때(예를 들어, 네트워크 중단으로) +트리거될 축출 개수를 관리한다. {{< /note >}} 이 기능을 `tolerationSeconds` 와 함께 사용하면, 파드에서 @@ -243,20 +242,15 @@ tolerations: tolerationSeconds: 6000 ``` -쿠버네티스는 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/not-ready` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/not-ready` 에 대한 -톨러레이션을 자동으로 추가한다. -마찬가지로 사용자가 제공한 파드 구성에 이미 추가된 -`node.kubernetes.io/unreachable` 에 대한 톨러레이션이 없는 경우 -`tolerationSeconds=300` 으로 `node.kubernetes.io/unreachable` 에 대한 +{{< note >}} +쿠버네티스는 사용자나 컨트롤러에서 명시적으로 설정하지 않았다면, 자동으로 +`node.kubernetes.io/not-ready` 와 `node.kubernetes.io/unreachable` 에 대해 +`tolerationSeconds=300` 으로 톨러레이션을 추가한다. -자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 -감지된 후 5분 동안 바인딩 상태로 남아있는 기본 파드 -동작이 유지되도록 한다. -[DefaultTolerationSecondsadmission controller](https://git.k8s.io/kubernetes/plugin/pkg/admission/defaulttolerationseconds) -어드미션 컨트롤러에 의해 두 개의 기본 톨러레이션이 추가된다. +자동으로 추가된 이 톨러레이션은 이러한 문제 중 하나가 감지된 후 5분 동안 +파드가 노드에 바인딩된 상태를 유지함을 의미한다. +{{< /note >}} [데몬셋](/ko/docs/concepts/workloads/controllers/daemonset/) 파드는 `tolerationSeconds` 가 없는 다음 테인트에 대해 `NoExecute` 톨러레이션를 가지고 생성된다. @@ -273,8 +267,7 @@ tolerations: 마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다. 쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을 -모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 -방지한다. +모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다. * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` @@ -284,3 +277,9 @@ tolerations: 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에 임의의 톨러레이션을 추가할 수도 있다. + + +## {{% heading "whatsnext" %}} + +* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기 +* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index f988d1d5d9571..b64f946acc871 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -7,13 +7,13 @@ weight: 1 {{< toc >}} -쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 -방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 -수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, -전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 -몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 -몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 -소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 +쿠버네티스 보안(일반적인 보안)은 관련된 많은 부분이 상호작용하는 +방대한 주제다. 오늘날에는 웹 애플리케이션의 실행을 돕는 +수많은 시스템에 오픈소스 소프트웨어가 통합되어 있으며, +전체적인 보안에 대하여 생각할 수 있는 방법에 대한 통찰력을 도울 수 있는 +몇 가지 중요한 개념이 있다. 이 가이드는 클라우드 네이티브 보안과 관련된 +몇 가지 일반적인 개념에 대한 멘탈 모델(mental model)을 정의한다. 멘탈 모델은 완전히 임의적이며 +소프트웨어 스택을 보호할 위치를 생각하는데 도움이되는 경우에만 사용해야 한다. @@ -22,8 +22,8 @@ weight: 1 ## 클라우드 네이티브 보안의 4C 계층적인 보안에 대해서 어떻게 생각할 수 있는지 이해하는 데 도움이 될 수 있는 다이어그램부터 살펴보자. {{< note >}} -이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) -접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 +이 계층화된 접근 방식은 보안에 대한 [심층 방어](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) +접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로 널리 알려져 있다. 4C는 클라우드(Cloud), 클러스터(Clusters), 컨테이너(Containers) 및 코드(Code)이다. {{< /note >}} @@ -31,23 +31,23 @@ weight: 1 위 그림에서 볼 수 있듯이, -4C는 각각의 사각형의 보안에 따라 다르다. 코드 -수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 -보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 -처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 +4C는 각각의 사각형의 보안에 따라 다르다. 코드 +수준의 보안만 처리하여 클라우드, 컨테이너 및 코드의 열악한 보안 표준으로부터 +보호하는 것은 거의 불가능하다. 그러나 이런 영역들의 보안이 적절하게 +처리되고, 코드에 보안을 추가한다면 이미 강력한 기반이 더욱 강화될 것이다. 이러한 관심 분야는 아래에서 더 자세히 설명한다. ## 클라우드 여러 면에서 클라우드(또는 공동 위치 서버, 또는 기업의 데이터 센터)는 쿠버네티스 클러스터 구성을 위한 [신뢰 컴퓨팅 기반(trusted computing base)](https://en.wikipedia.org/wiki/Trusted_computing_base) -이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) -경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 -실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 -안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 -제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 -클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 -알려진 클라우드 공급자의 보안 문서의 일부와 +이다. 이러한 구성 요소 자체가 취약하거나(또는 취약한 방법으로 구성된) +경우 이 기반 위에서 구축된 모든 구성 요소의 보안을 +실제로 보장할 방법이 없다. 각 클라우드 공급자는 그들의 환경에서 워크로드를 +안전하게 실행하는 방법에 대해 고객에게 광범위한 보안 권장 사항을 +제공한다. 모든 클라우드 공급자와 워크로드는 다르기 때문에 +클라우드 보안에 대한 권장 사항을 제공하는 것은 이 가이드의 범위를 벗어난다. 다음은 +알려진 클라우드 공급자의 보안 문서의 일부와 쿠버네티스 클러스터를 구성하기 위한 인프라 보안에 대한 일반적인 지침을 제공한다. @@ -65,7 +65,7 @@ Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | -자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 +자체 하드웨어나 다른 클라우드 공급자를 사용하는 경우 보안에 대한 모범 사례는 해당 문서를 참조한다. ### 일반적인 인프라 지침 표 @@ -73,32 +73,33 @@ VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | 쿠버네티스 인프라에서 고려할 영역 | 추천 | --------------------------------------------- | ------------ | API 서버에 대한 네트워크 접근(마스터) | 이상적으로는 인터넷에서 쿠버네티스 마스터에 대한 모든 접근을 공개적으로 허용하지 않으며 클러스터를 관리하는데 필요한 IP 주소 집합으로 제한된 네트워크 접근 제어 목록(ACL)에 의해 제어되어야 한다. | -노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. +노드에 대한 네트워크 접근(워커 서버) | 노드는 마스터의 지정된 포트 연결_만_ 허용하고(네트워크 접근 제어 목록의 사용), NodePort와 LoadBalancer 유형의 쿠버네티스 서비스에 대한 연결을 허용하도록 구성해야 한다. 가능한 노드가 공용 인터넷에 완전히 노출되어서는 안된다. 클라우드 공급자 API에 대한 쿠버네티스 접근 | 각 클라우드 공급자는 쿠버네티스 마스터 및 노드에 서로 다른 권한을 부여해야 함으로써, 이런 권장 사항이 더 일반적이다. 관리해야 하는 리소스에 대한 [최소 권한의 원칙](https://en.wikipedia.org/wiki/Principle_of_least_privilege)을 따르는 클라우드 공급자의 접근 권한을 클러스터에 구성하는 것이 가장 좋다. AWS의 Kops에 대한 예제: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles etcd에 대한 접근 | etcd (쿠버네티스의 데이터저장소)에 대한 접근은 마스터로만 제한되어야 한다. 구성에 따라 TLS를 통해 etcd를 사용해야 한다. 자세한 정보: https://github.com/etcd-io/etcd/tree/master/Documentation#security etcd 암호화 | 가능한 모든 드라이브를 유휴 상태에서 암호화 하는 것이 좋은 방법이지만, etcd는 전체 클러스터(시크릿 포함)의 상태를 유지하고 있기에 디스크의 암호화는 유휴 상태에서 암호화 되어야 한다. ## 클러스터 -이 섹션에서는 쿠버네티스의 워크로드 +이 섹션에서는 쿠버네티스의 워크로드 보안을 위한 링크를 제공한다. 쿠버네티스 보안에 영향을 미치는 다음 두 가지 영역이 있다. * 클러스터를 구성하는 설정 가능한 컴포넌트의 보안 * 클러스터에서 실행되는 컴포넌트의 보안 + ### 클러스터_의_ 컴포넌트 -우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, -모범 사례에 대한 정보를 채택하기 위해서는 +우발적이거나 악의적인 접근으로부터 클러스터를 보호하고, +모범 사례에 대한 정보를 채택하기 위해서는 [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/)에 대한 조언을 읽고 따른다. ### 클러스터 _내_ 컴포넌트(애플리케이션) -애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 -중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 -리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, -리소스 제한을 설정하지 않은 서비스 B에 의해 -서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 +애플리케이션의 공격 영역에 따라, 보안의 특정 측면에 +중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와 +리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우, +리소스 제한을 설정하지 않은 서비스 B에 의해 +서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서 실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다. 워크로드 보안에서 고려할 영역 | 추천 | @@ -115,9 +116,9 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r ## 컨테이너 -쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, -쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 -반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 +쿠버네티스에서 소프트웨어를 실행하려면, 소프트웨어는 컨테이너에 있어야 한다. 이로 인해, +쿠버네티스의 원시적인 워크로드 보안으로부터 이점을 얻기 위해서 +반드시 고려해야 할 보안 사항이 있다. 컨테이너 보안 또한 이 가이드의 범위를 벗어나지만, 해당 주제에 대한 추가적인 설명을 위하여 일반 권장사항 및 링크 표를 아래에 제공한다. @@ -129,9 +130,9 @@ RBAC 인증(쿠버네티스 API에 대한 접근) | https://kubernetes.io/docs/r ## 코드 -마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 -주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 -밖이지만 몇가지 권장사항이 있다. +마지막으로 애플리케이션의 코드 수준으로 내려가면, 가장 많은 제어를 할 수 있는 +주요 공격 영역 중 하나이다. 이런 코드 수준은 쿠버네티스의 범위 +밖이지만 몇 가지 권장사항이 있다. ### 일반적인 코드 보안 지침표 @@ -146,8 +147,8 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이 ## 강력한(robust) 자동화 -위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 -전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 +위에서 언급한 대부분의 제안사항은 실제로 일련의 보안 검사의 일부로 코드를 +전달하는 파이프라인에 의해 자동화 될 수 있다. 소프트웨어 전달을 위한 "지속적인 해킹(Continuous Hacking)"에 대한 접근 방식에 대해 알아 보려면, 자세한 설명을 제공하는 [이 기사](https://thenewstack.io/beyond-ci-cd-how-continuous-hacking-of-docker-containers-and-pipeline-driven-security-keeps-ygrene-secure/)를 참고한다. @@ -159,4 +160,3 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 클라이 * 컨트롤 플레인에 대한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) 알아보기 * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) 알아보기 * [쿠버네티스 시크릿](/docs/concepts/configuration/secret/)에 대해 알아보기 - diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md index bc5560b5ba666..ad5b1f9bbbf8f 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md @@ -54,16 +54,15 @@ fe00::2 ip6-allrouters 10.200.0.4 nginx ``` -기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 +기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6 상용구들만 포함하고 있다. ## HostAliases를 사용하여 추가 항목들 추가하기 -기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, `foo.remote`, -`bar.remote`가 `10.1.2.3`로 해석될 수 있도록 추가 항목들을 `hosts` 파일에 추가할 수 있으며, -이는 `.spec.hostAliases` 항목에서 정의하여 -파드에 HostAliases를 추가하면 가능하다. - +기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로, +`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록 +추가 항목들을 `hosts` 파일에 추가할 수 있으며, +이는 `.spec.hostAliases` 항목에서 정의하여 파드에 HostAliases를 추가하면 가능하다. {{< codenew file="service/networking/hostaliases-pod.yaml" >}} @@ -113,14 +112,12 @@ fe00::2 ip6-allrouters ## 왜 Kubelet이 호스트 파일을 관리하는가? -컨테이너가 이미 시작되고 난 후 Docker가 파일을 [수정](https://github.com/moby/moby/issues/17190) -하는 것을 방지하기 위해 Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 -[관리](https://github.com/kubernetes/kubernetes/issues/14633) -한다. +컨테이너가 이미 시작되고 난 후 도커가 파일을 +[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해 +Kubelet은 파드의 각 컨테이너의 `hosts` 파일을 +[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다. -호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 +호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로 `hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이 -덮어쓰여진다. 따라서, 호스트 파일의 내용을 +덮어 쓰인다. 따라서, 호스트 파일의 내용을 직접 바꾸는 것은 권장하지 않는다. - - diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 46495773993e9..eda8ab3d6823a 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -73,7 +73,7 @@ service/my-nginx exposed 이 사양은 `run: my-nginx` 레이블이 부착된 모든 파드에 TCP 포트 80을 대상으로 하는 서비스를 만들고 추상화된 서비스 포트에 노출시킨다 -(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 +(`targetPort` 는 컨테이너가 트래픽을 수신하는 포트, `port` 는 추상화된 서비스 포트로 다른 파드들이 서비스에 접속하기위해 사용하는 모든 포트일 수 있다). [서비스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)의 @@ -390,8 +390,8 @@ kubectl edit svc my-nginx kubectl get svc my-nginx ``` ``` -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -my-nginx ClusterIP 10.0.162.149 162.222.184.144 80/TCP,81/TCP,82/TCP 21s +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s ``` ``` curl https:// -k diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 7550473fc2d0e..46ac05bf8ed3a 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -3,9 +3,6 @@ title: 서비스 및 파드용 DNS content_type: concept weight: 20 --- - - - 이 페이지는 쿠버네티스의 DNS 지원에 대한 개요를 설명한다. @@ -14,26 +11,26 @@ weight: 20 ## 소개 -쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, -개별 컨테이너들이 DNS 네임을 해석할 때 +쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, +개별 컨테이너들이 DNS 네임을 해석할 때 DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### DNS 네임이 할당되는 것들 -클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. -기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 -클러스터의 기본 도메인을 포함한다. +클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. +기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와 +클러스터의 기본 도메인을 포함한다. 이 예시는 다음과 같다. -쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 -단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. -네임스페이스 `quux`에서 실행 중인 파드는 +쿠버네티스 네임스페이스 `bar`에 `foo`라는 서비스가 있다. 네임스페이스 `bar`에서 running 상태인 파드는 +단순하게 `foo`를 조회하는 DNS 쿼리를 통해서 서비스 `foo`를 찾을 수 있다. +네임스페이스 `quux`에서 실행 중인 파드는 `foo.bar`를 조회하는 DNS 쿼리를 통해서 이 서비스를 찾을 수 있다. -다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. -이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 경고 없이 변경될 수 있다. +다음 절에서는 쿠버네티스 DNS에서 지원하는 레코드 유형과 레이아웃을 자세히 설명한다. +이 외에 동작하는 레이아웃, 네임 또는 쿼리는 구현 세부 정보로 간주하며 +경고 없이 변경될 수 있다. 최신 업데이트에 대한 자세한 설명은 다음 링크를 통해 참조할 수 있다. - [쿠버네티스 DNS 기반 서비스 디스커버리](https://github.com/kubernetes/dns/blob/master/docs/specification.md). ## 서비스 @@ -41,43 +38,50 @@ DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. ### A/AAAA 레코드 "노멀"(헤드리스가 아닌) 서비스는 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` +`my-svc.my-namespace.svc.cluster-domain.example` 형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. 이는 서비스의 클러스터 IP로 해석된다. "헤드리스"(클러스터 IP가 없는) 서비스 또한 서비스 IP 계열에 따라 -`my-svc.my-namespace.svc.cluster-domain.example` -형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. -노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. +`my-svc.my-namespace.svc.cluster-domain.example` +형식의 이름을 가진 DNS A 또는 AAAA 레코드가 할당된다. +노멀 서비스와는 다르게 이는 서비스에 의해 선택된 파드들의 IP 집합으로 해석된다. 클라이언트는 해석된 IP 집합에서 IP를 직접 선택하거나 표준 라운드로빈을 통해 선택할 수 있다. ### SRV 레코드 -SRV 레코드는 노멀 서비스 또는 -[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 -속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. +SRV 레코드는 노멀 서비스 또는 +[헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)에 +속하는 네임드 포트를 위해 만들어졌다. 각각의 네임드 포트에 대해서 SRV 레코드는 다음과 같은 형식을 가질 수 있다. `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. -정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. +정규 서비스의 경우, 이는 포트 번호와 도메인 네임으로 해석된다. `my-svc.my-namespace.svc.cluster-domain.example`. -헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 -포트 번호와 도메인 이름을 포함한다. +헤드리스 서비스의 경우, 서비스를 지원하는 각 파드에 대해 하나씩 복수 응답으로 해석되며 이 응답은 파드의 +포트 번호와 도메인 이름을 포함한다. `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. ## 파드 +### A/AAAA 레코드 + +디플로이먼트나 데몬셋으로 생성되는 파드는 다음과 같은 +DNS 주소를 갖게 된다. + +`pod-ip-address.deployment-name.my-namespace.svc.cluster-domain.example.` + ### 파드의 hostname 및 subdomain 필드 파드가 생성되면 hostname은 해당 파드의 `metadata.name` 값이 된다. -파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. -이 필드는 파드의 호스트네임을 지정할 수 있다. -`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. +파드 스펙(Pod spec)에는 선택적 필드인 `hostname`이 있다. +이 필드는 파드의 호스트네임을 지정할 수 있다. +`hostname` 필드가 지정되면, 파드의 이름보다 파드의 호스트네임이 우선시된다. 예를 들어 `hostname` 필드가 "`my-host`"로 설정된 파드는 호스트네임이 "`my-host`"로 설정된다. -또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. -예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, -`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. +또한, 파드 스펙에는 선택적 필드인 `subdomain`이 있다. 이 필드는 서브도메인을 지정할 수 있다. +예를 들어 "`my-namespace`" 네임스페이스에서, `hostname` 필드가 "`foo`"로 설정되고, +`subdomain` 필드가 "`bar`"로 설정된 파드는 전체 주소 도메인 네임(FQDN)을 가지게 된다. "`foo.bar.my-namespace.svc.cluster-domain.example`". 예시: @@ -129,59 +133,58 @@ spec: name: busybox ``` -파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, +파드와 동일한 네임스페이스 내에 같은 서브도메인 이름을 가진 헤드리스 서비스가 있다면, 클러스터의 DNS 서버는 파드의 전체 주소 호스트네임(fully qualified hostname)인 A 또는 AAAA 레코드를 반환한다. -예를 들어 호스트네임이 "`busybox-1`"이고, -서브도메인이 "`default-subdomain`"이고, -같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, -파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. +예를 들어 호스트네임이 "`busybox-1`"이고, +서브도메인이 "`default-subdomain`"이고, +같은 네임스페이스 내 헤드리스 서비스의 이름이 "`default-subdomain`"이면, +파드는 다음과 같이 자기 자신의 FQDN을 얻게 된다. "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". -DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. +DNS는 위 FQDN에 대해 파드의 IP를 가리키는 A 또는 AAAA 레코드를 제공한다. "`busybox1`"와 "`busybox2`" 파드 모두 각 파드를 구분 가능한 A 또는 AAAA 레코드를 가지고 있다. -엔드포인트 객체는 `hostname` 필드를 임의의 엔드포인트 IP 주소로 지정할 수 있다. +엔드포인트 객체는 `hostname` 필드를 +임의의 엔드포인트 IP 주소로 지정할 수 있다. {{< note >}} -A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 -파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. -`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 -A 또는 AAAA 레코드만 생성할 수 있다. -(`default-subdomain.my-namespace.svc.cluster-domain.example`) -또한 레코드를 가지기 위해서는 파드가 준비되어야 한다. -그렇지 않은 경우, 서비스에서 `publishNotReadyAddresses=True`가 활성화된다. +A 또는 AAAA 레코드는 파드의 이름으로 생성되지 않기 때문에 +파드의 A 또는 AAAA 레코드를 생성하기 위해서는 `hostname` 필드를 작성해야 한다. +`hostname` 필드는 없고 `subdomain` 필드만 있는 파드는 파드의 IP 주소를 가리키는 헤드리스 서비스의 +A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespace.svc.cluster-domain.example`) +또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} ### 파드의 DNS 정책 -DNS 정책은 파드별로 설정할 수 있다. 현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. +DNS 정책은 파드별로 설정할 수 있다. +현재 쿠버네티스는 다음과 같은 파드별 DNS 정책을 지원한다. 이 정책들은 파드 스펙의 `dnsPolicy` 필드에서 지정할 수 있다. -- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. - 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) - 에서 확인할 수 있다. -- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 - 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. - 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. - 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 - [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods) - 에서 확인할 수 있다. -- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 +- "`Default`": 파드는 파드가 실행되고 있는 노드로부터 네임 해석 설정(the name resolution configuration)을 상속받는다. + 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)에서 + 확인할 수 있다. +- "`ClusterFirst`": "`www.kubernetes.io`"와 같이 클러스터 도메인 suffix 구성과 + 일치하지 않는 DNS 쿼리는 노드에서 상속된 업스트림 네임서버로 전달된다. + 클러스터 관리자는 추가 스텁-도메인(stub-domain)과 업스트림 DNS 서버를 구축할 수 있다. + 그러한 경우 DNS 쿼리를 어떻게 처리하는지에 대한 자세한 내용은 + [관련 논의](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)에서 + 확인할 수 있다. +- "`ClusterFirstWithHostNet`": hostNetwork에서 running 상태인 파드의 경우 DNS 정책인 "`ClusterFirstWithHostNet`"을 명시적으로 설정해야 한다. -- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. +- "`None`": 이 정책은 파드가 쿠버네티스 환경의 DNS 설정을 무시하도록 한다. 모든 DNS 설정은 파드 스펙 내에 `dnsConfig`필드를 사용하여 제공해야 한다. - 아래 절인 - [파드의 DNS 설정](#pod-dns-config) - 에서 자세한 내용을 확인할 수 있다. + 아래 절인 [파드의 DNS 설정](#pod-dns-config)에서 + 자세한 내용을 확인할 수 있다. {{< note >}} -"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 +"Default"는 기본 DNS 정책이 아니다. `dnsPolicy`가 명시적으로 지정되어있지 않다면 “ClusterFirst”가 기본값으로 사용된다. {{< /note >}} -아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 -DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. +아래 예시는 `hostNetwork`필드가 `true`로 설정되어 있어서 +DNS 정책이 "`ClusterFirstWithHostNet`"으로 설정된 파드를 보여준다. ```yaml apiVersion: v1 @@ -206,30 +209,33 @@ spec: 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다. -`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. -이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 `dnsConfig` 필드를 지정할 수 있다. +`dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. +이때, 파드의 `dnsPolicy`의 값이 "`None`"으로 설정되어 있어야 +`dnsConfig` 필드를 지정할 수 있다. 사용자는 `dnsConfig` 필드에서 다음과 같은 속성들을 지정할 수 있다. -- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. - 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 - 적어도 하나의 IP 주소가 포함되어야 하며, +- `nameservers`: 파드의 DNS 서버가 사용할 IP 주소들의 목록이다. + 파드의 `dnsPolicy`가 "`None`" 으로 설정된 경우에는 + 적어도 하나의 IP 주소가 포함되어야 하며, 그렇지 않으면 이 속성은 생략할 수 있다. - `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 중복되는 주소는 제거된다. -- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. - 이 속성은 생략이 가능하며, - 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. - 병합 시 중복되는 도메인은 제거되며, 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. -- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. - 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. - 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, + `nameservers`에 나열된 서버는 지정된 DNS 정책을 통해 생성된 기본 네임 서버와 합쳐지며 + 중복되는 주소는 제거된다. +- `searches`: 파드의 호스트네임을 찾기 위한 DNS 검색 도메인의 목록이다. + 이 속성은 생략이 가능하며, + 값을 지정한 경우 나열된 검색 도메인은 지정된 DNS 정책을 통해 생성된 기본 검색 도메인에 합쳐진다. + 병합 시 중복되는 도메인은 제거되며, + 쿠버네티스는 최대 6개의 검색 도메인을 허용하고 있다. +- `options`: `name` 속성(필수)과 `value` 속성(선택)을 가질 수 있는 객체들의 선택적 목록이다. + 이 속성의 내용은 지정된 DNS 정책에서 생성된 옵션으로 병합된다. + 이 속성의 내용은 지정된 DNS 정책을 통해 생성된 옵션으로 합쳐지며, 병합 시 중복되는 항목은 제거된다. - + 다음은 커스텀 DNS 세팅을 한 파드의 예시이다. {{< codenew file="service/networking/custom-dns.yaml" >}} -위에서 파드가 생성되면, +위에서 파드가 생성되면, 컨테이너 `test`의 `/etc/resolv.conf` 파일에는 다음과 같은 내용이 추가된다. ``` @@ -243,9 +249,7 @@ IPv6 셋업을 위해서 검색 경로와 네임 서버 셋업은 다음과 같 ```shell kubectl exec -it dns-example -- cat /etc/resolv.conf ``` - 출력은 다음과 같은 형식일 것이다. - ```shell nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -267,9 +271,5 @@ options ndots:5 ## {{% heading "whatsnext" %}} -DNS 구성 관리에 대한 지침은 -[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/) -에서 확인 할 수 있다. - - - +DNS 구성 관리에 대한 지침은 +[DNS 서비스 구성](/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index 11390c04d5447..a94aaad2d158b 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -47,7 +47,7 @@ IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요 * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64이다. + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. * kubelet: * `--feature-gates="IPv6DualStack=true"` * kube-proxy: diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 2a2ffc45bf003..d07b03ea5d22e 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -152,7 +152,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 필요한 새 엔드포인트로 채운다. 3. 추가할 새 엔드포인트가 여전히 남아있으면, 이전에 변경되지 않은 슬라이스에 엔드포인트를 맞추거나 새로운 것을 생성한다. - + 중요한 것은, 세 번째 단계는 엔드포인트슬라이스를 완벽하게 전부 배포하는 것보다 엔드포인트슬라이스 업데이트 제한을 우선시한다. 예를 들어, 추가할 새 엔드포인트가 10개이고 각각 5개의 공간을 사용할 수 있는 엔드포인트 공간이 있는 2개의 @@ -161,7 +161,7 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 엔드포인트슬라이스를 생성하는 것이 여러 엔드포인트슬라이스를 업데이트하는 것 보다 더 선호된다. 각 노드에서 kube-proxy를 실행하고 엔드포인트슬라이스를 관찰하면, -엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 +엔드포인트슬라이스에 대한 모든 변경 사항이 클러스터의 모든 노드로 전송되기 때문에 상대적으로 비용이 많이 소요된다. 이 방법은 여러 엔드포인트슬라이스가 가득 차지 않은 결과가 발생할지라도, 모든 노드에 전송해야 하는 변경 횟수를 의도적으로 제한하기 위한 것이다. @@ -179,6 +179,5 @@ text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그 * [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices) -* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 를 읽는다. - +* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md index 4600c32bcfb32..85aebe74afdfe 100644 --- a/content/ko/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md @@ -9,12 +9,13 @@ weight: 40 인그레스 리소스가 작동하려면, 클러스터는 실행 중인 인그레스 컨트롤러가 반드시 필요하다. -kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 클러스터와 함께 자동으로 실행되지 않는다. +kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 다른 타입과 달리 인그레스 컨트롤러는 +클러스터와 함께 자동으로 실행되지 않는다. 클러스터에 가장 적합한 인그레스 컨트롤러 구현을 선택하는데 이 페이지를 사용한다. 프로젝트로써 쿠버네티스는 현재 [GCE](https://git.k8s.io/ingress-gce/README.md) 와 [nginx](https://git.k8s.io/ingress-nginx/README.md) 컨트롤러를 지원하고 유지한다. - + @@ -22,31 +23,42 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 ## 추가 컨트롤러 * [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress) is an ingress controller that enables ingress to [AKS clusters](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal) using the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). -* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 - [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 +* [Ambassador](https://www.getambassador.io/) API 게이트웨이는 [Datawire](https://www.datawire.io/)의 + [커뮤니티](https://www.getambassador.io/docs) 혹은 [상업적](https://www.getambassador.io/pro/) 지원을 제공하는 [Envoy](https://www.envoyproxy.io) 기반 인그레스 컨트롤러다. -* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. +* [AppsCode Inc.](https://appscode.com) 는 가장 널리 사용되는 [HAProxy](http://www.haproxy.org/) 기반 인그레스 컨트롤러인 [Voyager](https://appscode.com/products/voyager)에 대한 지원 및 유지 보수를 제공한다. * [AWS ALB 인그레스 컨트롤러](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)는 [AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)를 사용하여 인그레스를 활성화한다. -* [Contour](https://projectcontour.io/)는 VMware에서 제공하고 지원하는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다. +* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러로 + VMware에서 제공하고 지원한다. * Citrix는 [베어메탈](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)과 [클라우드](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment) 배포를 위해 하드웨어 (MPX), 가상화 (VPX) 및 [무료 컨테이너화 (CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)를 위한 [인그레스 컨트롤러](https://github.com/citrix/citrix-k8s-ingress-controller)를 제공한다. -* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. +* F5 Networks는 [쿠버네티스를 위한 F5 BIG-IP 컨트롤러](http://clouddocs.f5.com/products/connectors/k8s-bigip-ctlr/latest)에 대한 + [지원과 유지 보수](https://support.f5.com/csp/article/K86859508)를 제공한다. * [Gloo](https://gloo.solo.io)는 [solo.io](https://www.solo.io)의 엔터프라이즈 지원과 함께 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의 오픈 소스 인그레스 컨트롤러다. * [HAProxy 인그레스](https://haproxy-ingress.github.io)는 HAProxy를 위한 고도로 커스터마이징 가능한 커뮤니티 주도형 인그레스 컨트롤러다. * [HAProxy Technologies](https://www.haproxy.com/)는 [쿠버네티스를 위한 HAProxy 인그레스 컨트롤러](https://github.com/haproxytech/kubernetes-ingress)를 지원하고 유지 보수한다. [공식 문서](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)를 통해 확인할 수 있다. -* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 - [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). -* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. -* [NGINX, Inc.](https://www.nginx.com/) 는 [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. -* 쿠버네티스 인그레스와 같이 사용 사례를 포함하는 서비스 구성을 위한 [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. -* [Traefik](https://github.com/containous/traefik)은 완벽한 기능([암호화](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. +* [Istio](https://istio.io/)는 인그레스 컨트롤러 기반으로 + [인그레스 트래픽을 제어](https://istio.io/docs/tasks/traffic-management/ingress/). +* [Kong](https://konghq.com/)은 [쿠버네티스를 위한 Kong 인그레스 컨트롤러](https://github.com/Kong/kubernetes-ingress-controller)에 대한 + [커뮤니티](https://discuss.konghq.com/c/kubernetes) 또는 + [상업적](https://konghq.com/kong-enterprise/) 지원과 유지 보수를 제공한다. +* [NGINX, Inc.](https://www.nginx.com/)는 + [쿠버네티스를 위한 NGINX 인그레스 컨트롤러](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)에 대한 지원과 유지 보수를 제공한다. +* [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)는 쿠버네티스 인그레스와 같은 유스케이스를 포함하는 서비스 구성을 위한 HTTP 라우터와 리버스 프록시는 사용자 정의 프록시를 빌드하기 위한 라이브러리로 설계되었다. +* [Traefik](https://github.com/containous/traefik)은 + 모든 기능([Let's Encrypt](https://letsencrypt.org), secrets, http2, 웹 소켓)을 갖춘 인그레스 컨트롤러로, + [Containous](https://containo.us/services)에서 상업적인 지원을 제공한다. ## 여러 인그레스 컨트롤러 사용 -하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. 인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 어떤 인그레스 컨트롤러를 사용해야하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) 어노테이션을 각각의 인그레스에 달아야 한다. +하나의 클러스터 내에 [여러 개의 인그레스 컨트롤러](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)를 배포할 수 있다. +인그레스를 생성할 때, 클러스터 내에 둘 이상의 인그레스 컨트롤러가 존재하는 경우 +어떤 인그레스 컨트롤러를 사용해야 하는지 표시해주는 적절한 [`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster) +어노테이션을 각각의 인그레스에 달아야 한다. 만약 클래스를 정의하지 않으면, 클라우드 제공자는 기본 인그레스 컨트롤러를 사용할 수 있다. -이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야하지만, 다양한 인그레스 컨트롤러는 약간 다르게 작동한다. +이상적으로는 모든 인그레스 컨트롤러가 이 사양을 충족해야 하지만, +다양한 인그레스 컨트롤러는 약간 다르게 작동한다. {{< note >}} 인그레스 컨트롤러의 설명서를 검토하여 선택 시 주의 사항을 이해해야한다. @@ -58,6 +70,4 @@ kube-controller-manager 바이너리의 일부로 실행되는 컨트롤러의 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 자세히 알아보기. -* [NGINX 컨트롤러로 Minikube에서 Ingress를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). - - +* [NGINX 컨트롤러로 Minikube에서 인그레스를 설정하기](/docs/tasks/access-application-cluster/ingress-minikube). diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index 968274bc1c0ea..19982fd447dea 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -1,5 +1,5 @@ --- -title: 인그레스 +title: 인그레스(Ingress) content_type: concept weight: 40 --- @@ -15,11 +15,11 @@ weight: 40 이 가이드는 용어의 명확성을 위해 다음과 같이 정의한다. -노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. -클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. -에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. -클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. -서비스(Service): {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. +* 노드(Node): 클러스터의 일부이며, 쿠버네티스에 속한 워커 머신. +* 클러스터(Cluster): 쿠버네티스에서 관리되는 컨테이너화 된 애플리케이션을 실행하는 노드 집합. 이 예시와 대부분의 일반적인 쿠버네티스 배포에서 클러스터에 속한 노드는 퍼블릭 인터넷의 일부가 아니다. +* 에지 라우터(Edge router): 클러스터에 방화벽 정책을 적용하는 라우터. 이것은 클라우드 공급자 또는 물리적 하드웨어의 일부에서 관리하는 게이트웨이일 수 있다. +* 클러스터 네트워크(Cluster network): 쿠버네티스 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)에 따라 클러스터 내부에서 통신을 용이하게 하는 논리적 또는 물리적 링크 집합. +* 서비스: {{< glossary_tooltip text="레이블" term_id="label" >}} 셀렉터를 사용해서 파드 집합을 식별하는 쿠버네티스 {{< glossary_tooltip text="서비스" term_id="service" >}}. 달리 언급하지 않으면 서비스는 클러스터 네트워크 내에서만 라우팅 가능한 가상 IP를 가지고 있다고 가정한다. ## 인그레스란? @@ -134,8 +134,7 @@ spec: 요청은 _p_ 경로에 일치한다. {{< note >}} - 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: - `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). + 경로의 마지막 요소가 요청 경로에 있는 마지막 요소의 하위 문자열인 경우에는 일치하지 않는다(예시: `/foo/bar` 와 `/foo/bar/baz` 와 일치하지만, `/foo/barbaz` 는 일치하지 않는다). {{< /note >}} #### 다중 일치 @@ -216,7 +215,7 @@ NAME HOSTS ADDRESS PORTS AGE test-ingress * 203.0.113.123 80 59s ``` -여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 +여기서 `203.0.113.123` 는 인그레스 컨트롤러가 인그레스를 충족시키기 위해 할당한 IP 이다. {{< note >}} diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 55fde3a3bec38..f10552c703cc4 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -9,28 +9,28 @@ weight: 50 네트워크 정책은 {{< glossary_tooltip text="파드" term_id="pod">}} 그룹이 서로 간에 또는 다른 네트워크 엔드포인트와 통신할 수 있도록 허용하는 방법에 대한 명세이다. -`NetworkPolicy` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. +`네트워크폴리시(NetworkPolicy)` 리소스는 {{< glossary_tooltip text="레이블" term_id="label">}}을 사용해서 파드를 선택하고 선택한 파드에 허용되는 트래픽을 지정하는 규칙을 정의한다. ## 전제 조건 -네트워크 정책은 [네트워크 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 NetworkPolicy를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 NetworkPolicy 리소스를 생성해도 아무런 효과가 없기 때문이다. +네트워크 정책은 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)으로 구현된다. 네트워크 정책을 사용하려면 네트워크폴리시를 지원하는 네트워킹 솔루션을 사용해야만 한다. 이를 구현하는 컨트롤러 없이 네트워크폴리시 리소스를 생성해도 아무런 효과가 없기 때문이다. ## 격리 및 격리되지 않은 파드 기본적으로, 파드는 격리되지 않는다. 이들은 모든 소스에서 오는 트래픽을 받아들인다. -파드는 파드를 선택한 NetworkPolicy에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 NetworkPolicy가 있으면 해당 파드는 NetworkPolicy에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 NetworkPolicy에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) +파드는 파드를 선택한 네트워크폴리시에 의해서 격리된다. 네임스페이스에 특정 파드를 선택하는 네트워크폴리시가 있으면 해당 파드는 네트워크폴리시에서 허용하지 않는 모든 연결을 거부한다. (네임스페이스 내에서 어떠한 네트워크폴리시에도 선택 받지 않은 다른 파드들은 계속해서 모든 트래픽을 받아들인다.) 네트워크 정책은 충돌하지 않으며, 추가된다. 만약 어떤 정책 또는 정책들이 파드를 선택하면, 해당 정책의 인그레스(수신)/이그레스(송신) 규칙을 통합하여 허용되는 범위로 파드가 제한된다. 따라서 평가 순서는 정책 결과에 영향을 미치지 않는다. -## NetworkPolicy 리소스 {#networkpolicy-resource} +## 네트워크폴리시 리소스 {#networkpolicy-resource} -리소스에 대한 전체 정의에 대한 참조는 [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. +리소스에 대한 전체 정의에 대한 참조는 [네트워크폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) 를 본다. -NetworkPolicy 의 예시는 다음과 같다. +네트워크폴리시 의 예시는 다음과 같다. ```yaml apiVersion: networking.k8s.io/v1 @@ -73,23 +73,23 @@ spec: 선택한 네트워킹 솔루션이 네트워킹 정책을 지원하지 않으면 클러스터의 API 서버에 이를 POST 하더라도 효과가 없다. {{< /note >}} -__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 NetworkPolicy 에는 +__필수 필드들__: 다른 모든 쿠버네티스 설정과 마찬가지로 네트워크폴리시 에는 `apiVersion`, `kind`, 그리고 `metadata` 필드가 필요하다. 구성 파일 작업에 대한 일반적인 정보는 [컨피그 맵을 사용해서 컨테이너 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/), 그리고 [오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management) 를 본다. -__spec__: NetworkPolicy [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. +__spec__: 네트워크폴리시 [사양](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)에는 지정된 네임스페이스에서 특정 네트워크 정책을 정의하는데 필요한 모든 정보가 있다. -__podSelector__: 각 NetworkPolicy 에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. +__podSelector__: 각 네트워크폴리시에는 정책이 적용되는 파드 그룹을 선택하는 `podSelector` 가 포함된다. 예시 정책은 "role=db" 레이블이 있는 파드를 선택한다. 비어있는 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. -__policyTypes__: 각 NetworkPolicy 에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 NetworkPolicy에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, NetworkPolicy에 `Egress` 가 있으면 이그레스 규칙이 설정된다. +__policyTypes__: 각 네트워크폴리시에는 `Ingress`, `Egress` 또는 두 가지 모두를 포함할 수 있는 `policyTypes` 목록이 포함된다. `policyTypes` 필드는 선택한 파드에 대한 인그레스 트래픽 정책, 선택한 파드에 대한 이그레스 트래픽 정책 또는 두 가지 모두에 지정된 정책의 적용 여부를 나타낸다. 만약 네트워크폴리시에 `policyTypes` 가 지정되어 있지 않으면 기본적으로 `Ingress` 가 항상 설정되고, 네트워크폴리시에 `Egress` 가 있으면 이그레스 규칙이 설정된다. -__ingress__: 각 NetworkPolicy 에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. +__ingress__: 각 네트워크폴리시에는 화이트리스트 `ingress` 규칙 목록이 포함될 수 있다. 각 규칙은 `from` 과 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 규칙이 포함되어있는데 첫 번째 포트는 `ipBlock` 을 통해 지정되고, 두 번째는 `namespaceSelector` 를 통해 그리고 세 번째는 `podSelector` 를 통해 세 가지 소스 중 하나의 단일 포트에서 발생하는 트래픽과 일치 시킨다. -__egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. +__egress__: 각 네트워크폴리시에는 화이트리스트 `egress` 규칙이 포함될 수 있다. 각 규칙은 `to` 와 `ports` 부분과 모두 일치하는 트래픽을 허용한다. 예시 정책에는 단일 포트의 트래픽을 `10.0.0.0/24` 의 모든 대상과 일치시키는 단일 규칙을 포함하고 있다. -따라서 예시의 NetworkPolicy는 다음과 같이 동작한다. +따라서 예시의 네트워크폴리시는 다음과 같이 동작한다. 1. 인그레스 및 이그레스 트래픽에 대해 "default" 네임스페이스에서 "role=db"인 파드를 격리한다(아직 격리되지 않은 경우). 2. (인그레스 규칙)은 "role=db" 레이블을 사용하는 "default" 네임스페이스의 모든 파드에 대해서 TCP 포트 6397로의 연결을 허용한다. 인그레스을 허용 할 대상은 다음과 같다. @@ -105,7 +105,7 @@ __egress__: 각 NetworkPolicy 에는 화이트리스트 `egress` 규칙이 포 `ingress` `from` 부분 또는 `egress` `to` 부분에 지정할 수 있는 네 종류의 셀렉터가 있다. -__podSelector__: NetworkPolicy 을 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. +__podSelector__: 네트워크폴리시를 통해서, 인그레스 소스 또는 이그레스 목적지로 허용되야 하는 동일한 네임스페이스에 있는 특정 파드들을 선택한다. __namespaceSelector__: 모든 파드가 인그레스 소스 또는 이그레스를 대상으로 허용되어야 하는 특정 네임스페이스를 선택한다. @@ -146,15 +146,15 @@ __namespaceSelector__ *와* __podSelector__: `namespaceSelector` 와 `podSelecto __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP CIDR 범위를 선택한다. 파드 IP는 임시적이고 예측할 수 없기에 클러스터 외부 IP이어야 한다. 클러스터 인그레스 및 이그레스 매커니즘은 종종 패킷의 소스 또는 대상 IP의 재작성을 -필요로 한다. 이러한 상황이 발생하는 경우, NetworkPolicy의 처리 전 또는 후에 +필요로 한다. 이러한 상황이 발생하는 경우, 네트워크폴리시의 처리 전 또는 후에 발생한 것인지 정의되지 않으며, 네트워크 플러그인, 클라우드 공급자, `서비스` 구현 등의 조합에 따라 동작이 다를 수 있다. -인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 -필터링할 수 있는 반면에 다른 경우에는 NetworkPolicy가 작동하는 +인그레스 사례에서의 의미는 실제 원본 소스 IP를 기준으로 들어오는 패킷을 +필터링할 수 있는 반면에 다른 경우에는 네트워크폴리시가 작동하는 "소스 IP"는 `LoadBalancer` 또는 파드가 속한 노드 등의 IP일 수 있다. -이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 +이그레스의 경우 파드에서 클러스터 외부 IP로 다시 작성된 `서비스` IP로의 연결은 `ipBlock` 기반의 정책의 적용을 받거나 받지 않을 수 있다는 것을 의미한다. ## 기본 정책 @@ -164,11 +164,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스 트래픽 거부 -모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만 해당 파드에 대한 인그레스 트래픽은 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 여전히 격리된다. 이 정책은 기본 이그레스 격리 동작을 변경하지 않는다. ### 기본적으로 모든 인그레스 트래픽 허용 @@ -178,11 +178,11 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 이그레스 트래픽 거부 -모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 NetworkPolicy를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. +모든 파드를 선택하지만, 해당 파드의 이그레스 트래픽을 허용하지 않는 네트워크폴리시를 생성해서 네임스페이스에 대한 "기본" 이그레스 격리 정책을 생성할 수 있다. {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드조차도 이그레스 트래픽을 허용하지 않는다. 이 정책은 기본 인그레스 격리 정책을 변경하지 않는다. ### 기본적으로 모든 이그레스 트래픽 허용 @@ -193,21 +193,21 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ### 기본적으로 모든 인그레스와 모든 이그레스 트래픽 거부 -해당 네임스페이스에 아래의 NetworkPolicy를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. +해당 네임스페이스에 아래의 네트워크폴리시를 만들어 모든 인그레스와 이그레스 트래픽을 방지하는 네임스페이스에 대한 "기본" 정책을 만들 수 있다. {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} -이렇게 하면 다른 NetworkPolicy에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. +이렇게 하면 다른 네트워크폴리시에서 선택하지 않은 파드도 인그레스 또는 이그레스 트래픽을 허용하지 않는다. ## SCTP 지원 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} 이 기능을 사용하려면 사용자(또는 클러스터 관리자가) API 서버에 `--feature-gates=SCTPSupport=true,…` 를 사용해서 `SCTPSupport` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 활성화 해야 한다. -기능 게이트가 활셩화 되면, NetworkPolicy의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. +기능 게이트가 활셩화 되면, 네트워크폴리시의 `protocol` 필드를 `SCTP` 로 설정할 수 있다. {{< note >}} -SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. +SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} @@ -218,6 +218,4 @@ SCTP 프로토콜 NetworkPolicy을 지원하는 {{< glossary_tooltip text="CNI" - 자세한 설명과 추가 예시는 [네트워크 정책 선언](/docs/tasks/administer-cluster/declare-network-policy/)을 본다. -- NetworkPolicy 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. - - +- 네트워크폴리시 리소스에서 사용되는 일반적인 시나리오는 [레시피](https://github.com/ahmetb/kubernetes-network-policy-recipes)를 본다. diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index da419f76e4e1f..567b9987911dd 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -194,7 +194,7 @@ spec: ## {{% heading "whatsnext" %}} -* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽는다. -* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽는다. +* [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기. +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index e1e0d28c7c108..51845e9496524 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -10,8 +10,6 @@ weight: 10 --- - - {{< glossary_definition term_id="service" length="short" >}} @@ -242,7 +240,8 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을 추가와 제거를 감시한다. 각 서비스는 로컬 노드에서 포트(임의로 선택됨)를 연다. 이 "프록시 포트"에 대한 모든 연결은 (엔드포인트를 통해 보고된대로) 서비스의 백엔드 파드 중 하나로 -프록시된다. kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 +프록시된다. +kube-proxy는 사용할 백엔드 파드를 결정할 때 서비스의 `SessionAffinity` 설정을 고려한다. 마지막으로, 유저-스페이스 프록시는 서비스의 @@ -497,15 +496,15 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는 `NodePort`와 `ClusterIP` 서비스가 자동으로 생성된다. * [`ExternalName`](#externalname): 값과 함께 CNAME 레코드를 리턴하여, 서비스를 - `externalName` 필드의 컨텐츠 (예:`foo.bar.example.com`)에 - 맵핑한다. 어떤 종류의 프록시도 설정되어 있지 않다. + `externalName` 필드의 콘텐츠 (예:`foo.bar.example.com`)에 + 매핑한다. + 어떤 종류의 프록시도 설정되어 있지 않다. {{< note >}} `ExternalName` 유형을 사용하려면 kube-dns 버전 1.7 또는 CoreDNS 버전 1.7 이상이 필요하다. {{< /note >}} [인그레스](/ko/docs/concepts/services-networking/ingress/)를 사용하여 서비스를 노출시킬 수도 있다. 인그레스는 서비스 유형이 아니지만, 클러스터의 진입점 역할을 한다. 동일한 IP 주소로 여러 서비스를 노출시킬 수 있기 때문에 라우팅 규칙을 단일 리소스로 통합할 수 있다. - ### NodePort 유형 {#nodeport} `type` 필드를 `NodePort`로 설정하면, 쿠버네티스 컨트롤 플레인은 @@ -686,7 +685,7 @@ metadata: ```yaml [...] metadata: - annotations: + annotations: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` @@ -1234,5 +1233,3 @@ kube-proxy는 유저스페이스 모드에 있을 때 SCTP 연결 관리를 지 * [서비스와 애플리케이션 연결](/ko/docs/concepts/services-networking/connect-applications-service/) 알아보기 * [인그레스](/ko/docs/concepts/services-networking/ingress/)에 대해 알아보기 * [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/)에 대해 알아보기 - - diff --git a/content/ko/docs/concepts/storage/dynamic-provisioning.md b/content/ko/docs/concepts/storage/dynamic-provisioning.md index bf0b257dbf3a1..87ce9c9d279cc 100644 --- a/content/ko/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ko/docs/concepts/storage/dynamic-provisioning.md @@ -29,19 +29,19 @@ API 오브젝트를 기반으로 한다. 클러스터 관리자는 볼륨을 프 클러스터 관리자는 클러스터 내에서 사용자 정의 파라미터 집합을 사용해서 여러 가지 유형의 스토리지 (같거나 다른 스토리지 시스템들)를 정의하고 노출시킬 수 있다. 또한 이 디자인을 통해 최종 사용자는 -스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, +스토리지 프로비전 방식의 복잡성과 뉘앙스에 대해 걱정할 필요가 없다. 하지만, 여전히 여러 스토리지 옵션들을 선택할 수 있다. -스토리지 클래스에 대한 자세한 정보는 -[여기](/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. +스토리지 클래스에 대한 자세한 정보는 +[여기](/ko/docs/concepts/storage/storage-classes/)에서 찾을 수 있다. ## 동적 프로비저닝 활성화하기 -동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 StorageClass +동적 프로비저닝을 활성화하려면 클러스터 관리자가 사용자를 위해 하나 이상의 스토리지클래스(StorageClass) 오브젝트를 사전 생성해야 한다. -StorageClass 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 +스토리지클래스 오브젝트는 동적 프로비저닝이 호출될 때 사용할 프로비저너와 해당 프로비저너에게 전달할 파라미터를 정의한다. -StorageClass 오브젝트의 이름은 유효한 +스토리지클래스 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 다음 매니페스트는 표준 디스크와 같은 퍼시스턴트 디스크를 프로비전하는 @@ -117,7 +117,7 @@ spec: 작성하면, `DefaultStorageClass` 어드미션 컨트롤러가 디폴트 스토리지 클래스를 가리키는 `storageClassName` 필드를 자동으로 추가한다. -클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 +클러스터에는 최대 하나의 *default* 스토리지 클래스가 있을 수 있다. 그렇지 않은 경우 `storageClassName` 을 명시적으로 지정하지 않은 `PersistentVolumeClaim` 을 생성할 수 없다. @@ -125,7 +125,6 @@ spec: [다중 영역](/ko/docs/setup/best-practices/multiple-zones/) 클러스터에서 파드는 한 지역 내 여러 영역에 걸쳐 분산될 수 있다. 파드가 예약된 영역에서 단일 영역 스토리지 백엔드를 -프로비전 해야 한다. [볼륨 바인딩 모드](/docs/concepts/storage/storage-classes/#volume-binding-mode)를 +프로비전해야 한다. [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 설정해서 수행할 수 있다. - diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 397041842b297..c345a472fe068 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -22,7 +22,7 @@ weight: 20 스토리지 관리는 컴퓨트 인스턴스 관리와는 별개의 문제다. 퍼시스턴트볼륨 서브시스템은 사용자 및 관리자에게 스토리지 사용 방법에서부터 스토리지가 제공되는 방법에 대한 세부 사항을 추상화하는 API를 제공한다. 이를 위해 퍼시스턴트볼륨 및 퍼시스턴트볼륨클레임이라는 두 가지 새로운 API 리소스를 소개한다. -_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. +_퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다. 노드가 클러스터 리소스인 것처럼 PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와는 별개의 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다. _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: 한 번 읽기/쓰기 또는 여러 번 읽기 전용으로 마운트 할 수 있음). @@ -47,7 +47,7 @@ PV를 프로비저닝 할 수 있는 두 가지 방법이 있다: 정적(static) 관리자가 생성한 정적 PV가 사용자의 퍼시스턴트볼륨클레임과 일치하지 않으면 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝 하려고 시도할 수 있다. 이 프로비저닝은 스토리지클래스를 기반으로 한다. PVC는 -[스토리지 클래스](/docs/concepts/storage/storage-classes/)를 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes/)를 요청해야 하며 관리자는 동적 프로비저닝이 발생하도록 해당 클래스를 생성하고 구성해야 한다. `""` 클래스를 요청하는 클레임은 동적 프로비저닝을 효과적으로 비활성화한다. @@ -244,7 +244,7 @@ FlexVolume의 크기 조정은 기본 드라이버가 크기 조정을 지원하 {{< /note >}} {{< note >}} -EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터(quota)가 있다. +EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마다 한 번의 수정을 할 수 있는 볼륨별 쿼터가 있다. {{< /note >}} @@ -376,7 +376,7 @@ CLI에서 접근 모드는 다음과 같이 약어로 표시된다. ### 클래스 PV는 `storageClassName` 속성을 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름으로 설정하여 지정하는 클래스를 가질 수 있다. 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩될 수 있다. `storageClassName`이 없는 PV에는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만 @@ -449,8 +449,7 @@ CLI는 PV에 바인딩된 PVC의 이름을 표시한다. 각 PVC에는 스펙과 상태(클레임의 명세와 상태)가 포함된다. 퍼시스턴트볼륨클레임 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 -한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ```yaml apiVersion: v1 @@ -496,7 +495,7 @@ spec: ### 클래스 클레임은 `storageClassName` 속성을 사용하여 -[스토리지클래스](/docs/concepts/storage/storage-classes/)의 이름을 지정하여 +[스토리지클래스](/ko/docs/concepts/storage/storage-classes/)의 이름을 지정하여 특정 클래스를 요청할 수 있다. 요청된 클래스의 PV(PVC와 동일한 `storageClassName`을 갖는 PV)만 PVC에 바인딩될 수 있다. @@ -747,7 +746,7 @@ spec: * [퍼시스턴트볼륨 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)에 대해 자세히 알아보기 * [퍼시스턴트볼륨클레임 생성](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim)에 대해 자세히 알아보기 -* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽기 +* [퍼시스턴트 스토리지 설계 문서](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) 읽어보기 ### 참고 @@ -755,4 +754,3 @@ spec: * [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) * [퍼시스턴트볼륨클레임](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) * [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) - diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index e73d886ef7b73..13b4f4917517b 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -162,8 +162,8 @@ CSI | 1.14 (alpha), 1.16 (beta) 클러스터 관리자는 `WaitForFirstConsumer` 모드를 지정해서 이 문제를 해결할 수 있는데 이 모드는 퍼시스턴트볼륨클레임을 사용하는 파드가 생성될 때까지 퍼시스턴트볼륨의 바인딩과 프로비저닝을 지연시킨다. 퍼시스턴트볼륨은 파드의 스케줄링 제약 조건에 의해 지정된 토폴로지에 -따라 선택되거나 프로비전된다. 여기에는 [리소스 -요구 사항](/docs/concepts/configuration/manage-compute-resources-container/), +따라 선택되거나 프로비전된다. 여기에는 +[리소스 요구 사항](/ko/docs/concepts/configuration/manage-resources-containers/), [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector), [파드 어피니티(affinity)와 안티-어피니티(anti-affinity)](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) @@ -816,4 +816,3 @@ volumeBindingMode: WaitForFirstConsumer 적절한 퍼시스턴트볼륨을 선택할 때 파드의 모든 스케줄링 제약 조건을 고려할 수 있다. - diff --git a/content/ko/docs/concepts/storage/volume-pvc-datasource.md b/content/ko/docs/concepts/storage/volume-pvc-datasource.md index 8b8e1b484fed7..e6ff2caa38f79 100644 --- a/content/ko/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/ko/docs/concepts/storage/volume-pvc-datasource.md @@ -6,8 +6,7 @@ weight: 30 -이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨] -(/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. +이 문서에서는 쿠버네티스의 기존 CSI 볼륨 복제의 개념을 설명한다. [볼륨](/ko/docs/concepts/storage/volumes)을 숙지하는 것을 추천한다. diff --git a/content/ko/docs/concepts/storage/volume-snapshot-classes.md b/content/ko/docs/concepts/storage/volume-snapshot-classes.md index 801ff624bb52f..cc31fae666ba3 100644 --- a/content/ko/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/ko/docs/concepts/storage/volume-snapshot-classes.md @@ -7,8 +7,8 @@ weight: 30 이 문서는 쿠버네티스의 `VolumeSnapshotClass` 개요를 설명한다. -[볼륨 스냅샷](/docs/concepts/storage/volume-snapshots/)과 -[스토리지 클래스](/docs/concepts/storage/storage-classes)의 숙지를 추천한다. +[볼륨 스냅샷](/ko/docs/concepts/storage/volume-snapshots/)과 +[스토리지 클래스](/ko/docs/concepts/storage/storage-classes)의 숙지를 추천한다. @@ -32,7 +32,7 @@ weight: 30 처음 생성할 때 클래스의 이름과 기타 파라미터를 설정하고, 오브젝트가 생성된 이후에는 업데이트할 수 없다. -관리자는 특정 클래스의 바인딩을 요청하지 않는 VolumeSnapshots에만 +관리자는 특정 클래스의 바인딩을 요청하지 않는 볼륨스냅샷에만 기본 `VolumeSnapshotClass` 를 지정할 수 있다. ```yaml @@ -40,14 +40,14 @@ apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshotClass metadata: name: csi-hostpath-snapclass -driver: hostpath.csi.k8s.io +driver: hostpath.csi.k8s.io deletionPolicy: Delete parameters: ``` ### 드라이버 -볼륨 스냅샷 클래스에는 VolumeSnapshots의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 +볼륨 스냅샷 클래스에는 볼륨스냅샷의 프로비저닝에 사용되는 CSI 볼륨 플러그인을 결정하는 드라이버를 가지고 있다. 이 필드는 반드시 지정해야한다. ### 삭제정책(DeletionPolicy) @@ -61,5 +61,3 @@ parameters: 볼륨 스냅샷 클래스에는 볼륨 스냅샷 클래스에 속하는 볼륨 스냅샷을 설명하는 파라미터를 가지고 있다. `driver` 에 따라 다른 파라미터를 사용할 수 있다. - - diff --git a/content/ko/docs/concepts/storage/volume-snapshots.md b/content/ko/docs/concepts/storage/volume-snapshots.md index d2d85909e1092..997f3d6fee48c 100644 --- a/content/ko/docs/concepts/storage/volume-snapshots.md +++ b/content/ko/docs/concepts/storage/volume-snapshots.md @@ -41,8 +41,7 @@ API 리소스 `PersistentVolume` 및 `PersistentVolumeClaim` 가 사용자 및 스냅샷을 프로비저닝할 수 있는 방법에는 사전 프로비저닝 혹은 동적 프로비저닝의 두 가지가 있다: . #### 사전 프로비전 {#static} -클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. -이것은 쿠버네티스 API에 있고 사용 가능하다. +클러스터 관리자는 많은 `VolumeSnapshotContents` 을 생성한다. 그들은 클러스터 사용자들이 사용 가능한 스토리지 시스템의 실제 볼륨 스냅샷 세부 정보를 제공한다. 이것은 쿠버네티스 API에 있고 사용 가능하다. #### 동적 사전 프로비저닝을 사용하는 대신 퍼시스턴트볼륨클레임에서 스냅샷을 동적으로 가져오도록 요청할 수 있다. [볼륨스냅샷클래스](/docs/concepts/storage/volume-snapshot-classes/)는 스냅샷 사용 시 스토리지 제공자의 특정 파라미터를 명세한다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index a5a3e8aa2301e..b8ff826d673b3 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -451,15 +451,13 @@ spec: ``` #### 지역(Regional) 퍼시스턴트 디스크 -{{< feature-state for_k8s_version="v1.10" state="beta" >}} - [지역(Regional) 퍼시스턴트 디스크](https://cloud.google.com/compute/docs/disks/#repds) 기능을 사용하면 동일한 영역 내의 두 영역에서 사용할 수 있는 퍼시스턴트 디스크를 생성할 수 있다. 이 기능을 사용하려면 볼륨을 퍼시스턴트볼륨으로 프로비저닝 해야 한다. 파드에서 직접 볼륨을 참조하는 것은 지원되지 않는다. #### 지역(Regional) PD 퍼시스턴트볼륨을 수동으로 프로비저닝하기 -[GCE PD 용 StorageClass](/docs/concepts/storage/storage-classes/#gce) 를 사용해서 동적 프로비저닝이 가능하다. +[GCE PD용 스토리지클래스](/ko/docs/concepts/storage/storage-classes/#gce-pd)를 사용해서 동적 프로비저닝이 가능하다. PersistentVolume을 생성하기 전에 PD를 생성해야만 한다. ```shell -gcloud beta compute disks create --size=500GB my-data-disk +gcloud compute disks create --size=500GB my-data-disk --region us-central1 --replica-zones us-central1-a,us-central1-b ``` @@ -470,8 +468,6 @@ apiVersion: v1 kind: PersistentVolume metadata: name: test-volume - labels: - failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b spec: capacity: storage: 400Gi @@ -480,6 +476,15 @@ spec: gcePersistentDisk: pdName: my-data-disk fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b ``` #### CSI 마이그레이션 @@ -574,12 +579,13 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드간에 데 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 - 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있음 + 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. * 쿠버네티스가 계획한 대로 리소스 인식 스케줄링을 추가하면 `hostPath` 에서 - 사용되는 리소스를 설명할 수 없음 -* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. 프로세스를 - [특권 컨테이너](/docs/user-guide/security-context) 에서 루트로 실행하거나 - `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 함 + 사용되는 리소스를 설명할 수 없다. +* 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. + 프로세스를 [특권을 가진(privileged) 컨테이너](/docs/user-guide/security-context)에서 + 루트로 실행하거나 + `hostPath` 볼륨에 쓸 수 있도록 호스트의 파일 권한을 수정해야 한다. #### 파드 예시 @@ -714,7 +720,7 @@ spec: 로컬 볼륨을 사용할 때는 `volumeBindingMode` 가 `WaitForFirstConsumer` 로 설정된 스토리지클래스(StorageClass)를 생성하는 것을 권장한다. -[예시](/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 +[예시](/ko/docs/concepts/storage/storage-classes/#local)를 본다. 볼륨 바인딩을 지연시키는 것은 퍼시스턴트볼륨클래임 바인딩 결정도 노드 리소스 요구사항, 노드 셀렉터, 파드 어피니티 그리고 파드 안티 어피니티와 같이 파드가 가질 수 있는 다른 노드 제약 조건으로 평가되도록 만든다. @@ -1473,4 +1479,3 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} * [퍼시스턴트 볼륨과 함께 워드프레스와 MySQL 배포하기](/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/)의 예시를 따른다. - diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 54d15ba05027e..1eecdc5d567ed 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -10,19 +10,20 @@ weight: 80 _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. -하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. - +하나의 크론잡 오브젝트는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. +크론잡은 잡을 [크론](https://ko.wikipedia.org/wiki/Cron) 형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. {{< caution >}} 모든 **크론잡** `일정:` 시간은 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}의 시간대를 기준으로 한다. 컨트롤 플레인이 파드 또는 베어 컨테이너에서 kube-controller-manager를 실행하는 경우, -kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트롤러가 사용하는 시간대로 결정한다. +kube-controller-manager 컨테이너에 설정된 시간대는 +크론잡 컨트롤러가 사용하는 시간대로 결정한다. {{< /caution >}} -크론잡 리소스에 대한 매니페스트를 생성할때에는 제공하는 이름이 -유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +크론잡 리소스에 대한 매니페스트를 생성할 때에는 제공하는 이름이 +유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 이름은 52자 이하여야 한다. 이는 크론잡 컨트롤러는 제공된 잡 이름에 11자를 자동으로 추가하고, 작업 이름의 최대 길이는 63자라는 제약 조건이 있기 때문이다. @@ -37,7 +38,7 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을 스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다. -### 예제 +### 예시 이 크론잡 매니페스트 예제는 현재 시간과 hello 메시지를 1분마다 출력한다. @@ -46,17 +47,17 @@ kube-controller-manager 컨테이너에 설정된 시간대는 크론잡 컨트 ([크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)는 이 예시를 더 자세히 설명한다.) -## 크론 잡의 한계 {#cron-job-limitations} +## 크론잡의 한계 {#cron-job-limitations} -크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 +크론잡은 일정의 실행시간 마다 _약_ 한 번의 잡 오브젝트를 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 -않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 _멱등원_ 이 된다. +않도록 해야겠지만, 완벽히 그럴 수는 없다. 따라서 잡은 _멱등원_ 이 된다. 만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), -`concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은 +`concurrencyPolicy` 가 `Allow` 로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다. -모든 크론 잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. +모든 크론잡에 대해 크론잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. ```` Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. @@ -64,17 +65,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다. -크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론 잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. +크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. 즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, -`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가 +`startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론잡 컨트롤러가 `08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다. -이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, -`startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가 -전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) +이 개념을 더 자세히 설명하자면, 크론잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, +`startingDeadlineSeconds` 이 200이라고 가정한다. 크론잡 컨트롤러가 +전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) -크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, +크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. @@ -83,7 +84,5 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). [크론 표현 포맷](https://pkg.go.dev/github.com/robfig/cron?tab=doc#hdr-CRON_Expression_Format)은 크론잡 `schedule` 필드의 포맷을 문서화 한다. -크론 잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 -예는 [크론 잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. - - +크론잡 생성과 작업에 대한 지침과 크론잡 매니페스트의 +예는 [크론잡으로 자동화된 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs/)를 참조한다. diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index 83f3c428a382a..5917eb288d681 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -6,18 +6,18 @@ weight: 50 -_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 -파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 +_데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도록 한다. 노드가 클러스터에 추가되면 +파드도 추가된다. 노드가 클러스터에서 제거되면 해당 파드는 가비지(garbage)로 수집된다. 데몬셋을 삭제하면 데몬셋이 생성한 파드들이 정리된다. 데몬셋의 일부 대표적인 용도는 다음과 같다. -- 각 노드에서 `glusterd`, `ceph` 와 같은 클러스터 스토리지 데몬의 실행. -- 모든 노드에서 `fluentd` 또는 `filebeat` 와 같은 로그 수집 데몬의 실행. -- 모든 노드에서 [Prometheus Node Exporter](https://github.com/prometheus/node_exporter), [Flowmill](https://github.com/Flowmill/flowmill-k8s/), [Sysdig Agent](https://docs.sysdig.com), `collectd`, [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), Ganglia `gmond` 또는 [Instana Agent](https://www.instana.com/supported-integrations/kubernetes-monitoring/) 또는 [Elastic Metricbeat](https://www.elastic.co/guide/en/beats/metricbeat/current/running-on-kubernetes.html)와 같은 노드 모니터링 데몬의 실행. +- 모든 노드에서 클러스터 스토리지 데몬 실행 +- 모든 노드에서 로그 수집 데몬 실행 +- 모든 노드에서 노드 모니터링 데몬 실행 단순한 케이스에서는, 각 데몬 유형의 처리를 위해서 모든 노드를 커버하는 하나의 데몬셋이 사용된다. -더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, +더 복잡한 구성에서는 단일 유형의 데몬에 여러 데몬셋을 사용할 수 있지만, 각기 다른 하드웨어 유형에 따라 서로 다른 플래그, 메모리, CPU 요구가 달라진다. @@ -42,11 +42,12 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 필수 필드 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/tasks/run-application/run-stateless-application-deployment/), +일반적인 설정파일 작업에 대한 정보는 [애플리케이션 배포하기](/docs/user-guide/deploying-applications/), [컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. 데몬셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + 데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. ### 파드 템플릿 @@ -55,7 +56,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 [파드](/ko/docs/concepts/workloads/pods/pod/)와 정확히 같은 스키마를 가진다. -데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 +데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). 데몬셋의 파드 템플릿의 [`RestartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책)는 `Always` 를 가져야 하며, @@ -63,7 +64,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### 파드 셀렉터 -`.spec.selector` 필드는 파드 셀렉터이다. 이것은 +`.spec.selector` 필드는 파드 셀렉터이다. 이것은 [잡](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)의 `.spec.selector` 와 같은 동작을 한다. 쿠버네티스 1.8 부터는 레이블이 `.spec.template` 와 일치하는 파드 셀렉터를 명시해야 한다. @@ -82,18 +83,18 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. -또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 -레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 -{{< glossary_tooltip term_id="controller" >}} 는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 -막지 못한다. 사용자가 이와 같은 일을 하게되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 +또한 일반적으로 다른 데몬셋이나 레플리카셋과 같은 다른 컨트롤러를 통해 직접적으로 +레이블이 셀렉터와 일치하는 다른 파드를 생성하지 않아야 한다. 그렇지 않으면 데몬셋 +{{< glossary_tooltip term_id="controller" text="컨트롤러" >}}는 해당 파드가 생성된 것으로 생각한다. 쿠버네티스는 이런 일을 하는 것을 +막지 못한다. 사용자가 이와 같은 일을 하게 되는 한 가지 경우는 테스트를 목적으로 한 노드에서 다른 값을 가지는 파드들을 수동으로 생성하는 것이다. ### 오직 일부 노드에서만 파드 실행 -만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 -[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 -일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 -데몬셋 컨트롤러는 [노트 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. +만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 +[노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 +일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 +데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. ## 데몬 파드가 스케줄 되는 방법 @@ -102,24 +103,24 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml {{< feature-state state="stable" for-kubernetes-version="1.17" >}} -데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 -쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 +데몬셋은 자격이 되는 모든 노드에서 파드 사본이 실행하도록 보장한다. 일반적으로 +쿠버네티스 스케줄러에 의해 파드가 실행되는 노드가 선택된다. 그러나 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다. 이에 대한 이슈를 소개한다. * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. 이것은 사용자에게 혼란을 준다. - * [파드 선점](/docs/concepts/configuration/pod-priority-preemption/) - 은 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 + * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은 + 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. -`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 -`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 -스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 -스케줄러를 사용해서 대상 호스트에 파드를 바인딩 한다. 만약 데몬셋 파드에 -이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 -데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, +`ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 +`NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 +스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 +스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에 +이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 +데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, 데몬셋의 `spec.template` 은 변경되지 않는다. ```yaml @@ -133,29 +134,25 @@ nodeAffinity: - target-host-name ``` -또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 -자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 +또한, 데몬셋 파드에 `node.kubernetes.io/unschedulable:NoSchedule` 이 톨러레이션(toleration)으로 +자동으로 추가된다. 기본 스케줄러는 데몬셋 파드를 스케줄링시 `unschedulable` 노드를 무시한다. - ### 테인트(taints)와 톨러레이션(tolerations) -데몬 파드는 -[테인트와 톨러레이션](/docs/concepts/configuration/taint-and-toleration)을 존중하지만, -다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 +데몬 파드는 +[테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 존중하지만, +다음과 같이 관련 기능에 따라 자동적으로 데몬셋 파드에 톨러레이션을 추가한다. -| 톨러레이션 키 | 영향 | 버전 | 설명 | +| 톨러레이션 키 | 영향 | 버전 | 설명 | | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | - - - +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | 네트워크 파티션과 같은 노드 문제가 발생해도 데몬셋 파드는 축출되지 않는다. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | 데몬셋 파드는 기본 스케줄러의 스케줄할 수 없는(unschedulable) 속성을 극복한다. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | 호스트 네트워크를 사용하는 데몬셋 파드는 기본 스케줄러에 의해 이용할 수 없는 네트워크(network-unavailable) 속성을 극복한다. | ## 데몬 파드와 통신 @@ -164,7 +161,7 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. - **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. -- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, +- **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 @@ -172,58 +169,56 @@ nodeAffinity: ## 데몬셋 업데이트 -만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 +만약 노드 레이블이 변경되면, 데몬셋은 새로 일치하는 노드에 즉시 파드를 추가하고, 새로 일치하지 않는 노드에서 파드를 삭제한다. -사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 -필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 +사용자는 데몬셋이 생성하는 파드를 수정할 수 있다. 그러나 파드는 모든 +필드가 업데이트 되는 것을 허용하지 않는다. 또한 데몬셋 컨트롤러는 다음에 노드(동일한 이름으로)가 생성될 때 원본 템플릿을 사용한다. -사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 -파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, -새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 +사용자는 데몬셋을 삭제할 수 있다. 만약 `kubectl` 에서 `--cascade=false` 를 명시하면 +파드는 노드에 남게 된다. 이후에 동일한 셀렉터로 새 데몬셋을 생성하면, +새 데몬셋은 기존 파드를 채택한다. 만약 파드를 교체해야 하는 경우 데몬셋은 `updateStrategy` 에 따라 파드를 교체한다. -사용자는 데몬셋에서 [롤링 업데이트를 수행](/docs/tasks/manage-daemon/update-daemon-set/) 할 수 있다. +사용자는 데몬셋에서 [롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)할 수 있다. ## 데몬셋의 대안 ### 초기화 스크립트 데몬 프로세스를 직접 노드에서 시작해서 실행하는 것도 당연히 가능하다. -(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 +(예: `init`, `upstartd` 또는 `systemd` 를 사용). 이 방법도 문제는 전혀 없다. 그러나 데몬셋을 통해 데몬 프로세스를 실행하면 몇 가지 이점 있다. - 애플리케이션과 동일한 방법으로 데몬을 모니터링하고 로그 관리를 할 수 있다. - 데몬 및 애플리케이션과 동일한 구성 언어와 도구(예: 파드 템플릿, `kubectl`). -- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 +- 리소스 제한이 있는 컨테이너에서 데몬을 실행하면 앱 컨테이너에서 데몬간의 격리를 증가시킨다. 그러나 이것은 파드가 아닌 컨테이너에서 데몬을 실행해서 이루어진다 (예: 도커에서 직접적으로 시작). ### 베어(Bare) 파드 -직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 +직접적으로 파드를 실행할 특정한 노드를 명시해서 파드를 생성할 수 있다. 그러나 데몬셋은 노드 장애 또는 커널 업그레이드와 같이 변경사항이 많은 노드 유지보수의 경우를 비롯하여 -어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 +어떠한 이유로든 삭제되거나 종료된 파드를 교체한다. 따라서 개별 파드를 생성하는 것보다는 데몬 셋을 사용해야 한다. ### 스태틱(static) 파드 -Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 -[스태틱 파드](/docs/tasks/configure-pod-container/static-pod/)라고 부른다. -데몬셋과는 다르게 스태틱 파드는 kubectl -또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 -않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단(deprecated)될 수 있다. +Kubelet이 감시하는 특정 디렉토리에 파일을 작성하는 파드를 생성할 수 있다. 이것을 +[스태틱 파드](/ko/docs/tasks/configure-pod-container/static-pod/)라고 부른다. +데몬셋과는 다르게 스태틱 파드는 kubectl +또는 다른 쿠버네티스 API 클라이언트로 관리할 수 없다. 스태틱 파드는 API 서버에 의존하지 +않기 때문에 클러스터 부트스트랩(bootstraping)하는 경우에 유용하다. 또한 스태틱 파드는 향후에 사용 중단될 수 있다. ### 디플로이먼트 -데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, -해당 파드에서는 프로세스가 종료되지 않을 것으로 +데몬셋은 파드를 생성한다는 점에서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 유사하고, +해당 파드에서는 프로세스가 종료되지 않을 것으로 예상한다(예: 웹 서버). -파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, -업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 -디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, +파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고, +업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의 +디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고, 다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index 96f41dc186aa4..269d72f51061e 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -1,4 +1,6 @@ --- + + title: 디플로이먼트 feature: title: 자동화된 롤아웃과 롤백 @@ -11,7 +13,7 @@ weight: 30 -_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 +_디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 _의도하는 상태_ 를 설명하고, 디플로이먼트 {{< glossary_tooltip term_id="controller" >}} 는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. @@ -53,16 +55,16 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 보다 정교한 선택 규칙의 적용이 가능하다. {{< note >}} - `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 - 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 + `.spec.selector.matchLabels` 필드는 {key,value}의 쌍으로 매핑되어있다. `matchLabels` 에 매핑된 + 단일 {key,value}은 `matchExpressions` 의 요소에 해당하며, 키 필드는 "key"에 그리고 연산자는 "In"에 대응되며 값 배열은 "value"만 포함한다. 매칭을 위해서는 `matchLabels` 와 `matchExpressions` 의 모든 요건이 충족되어야 한다. {{< /note >}} * `template` 필드에는 다음 하위 필드가 포함되어있다. * 파드는 `.metadata.labels` 필드를 사용해서 `app: nginx` 라는 레이블을 붙인다. - * 파드 템플릿의 사양 또는 `.template.spec` 필드는 - 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 + * 파드 템플릿의 사양 또는 `.template.spec` 필드는 + 파드가 [도커 허브](https://hub.docker.com/)의 `nginx` 1.14.2 버전 이미지를 실행하는 `nginx` 컨테이너 1개를 실행하는 것을 나타낸다. * 컨테이너 1개를 생성하고, `.spec.template.spec.containers[0].name` 필드를 사용해서 `nginx` 이름을 붙인다. @@ -72,7 +74,6 @@ _디플로이먼트_ 는 [파드](/ko/docs/concepts/workloads/pods/pod/)와 1. 다음 명령어를 실행해서 디플로이먼트를 생성한다. - ```shell kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ``` @@ -84,7 +85,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 2. `kubectl get deployments` 을 실행해서 디플로이먼트가 생성되었는지 확인한다. - + 만약 디플로이먼트가 여전히 생성 중이면, 다음과 유사하게 출력된다. ```shell NAME READY UP-TO-DATE AVAILABLE AGE @@ -145,7 +146,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 디플로이먼트에는 파드 템플릿 레이블과 적절한 셀렉터를 반드시 명시해야 한다 (이 예시에서는 `app: nginx`). -레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀 셋 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. +레이블 또는 셀렉터는 다른 컨트롤러(다른 디플로이먼트와 스테이트풀셋(StatefulSet) 포함)와 겹치지 않아야 한다. 쿠버네티스는 겹치는 것을 막지 않으며, 만약 다중 컨트롤러가 겹치는 셀렉터를 가지는 경우 해당 컨트롤러의 충돌 또는 예기치 않은 동작을 야기할 수 있다. {{< /note >}} ### Pod-template-hash 레이블 @@ -156,13 +157,13 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml `pod-template-hash` 레이블은 디플로이먼트 컨트롤러에 의해서 디플로이먼트가 생성 또는 채택한 모든 레플리카셋에 추가된다. -이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, +이 레이블은 디플로이먼트의 자식 레플리카셋이 겹치지 않도록 보장한다. 레플리카셋의 `PodTemplate` 을 해싱하고, 해시 결과를 레플리카셋 셀렉터, 파드 템플릿 레이블 및 레플리카셋 이 가질 수 있는 기존의 모든 파드에 레이블 값으로 추가해서 사용하도록 생성한다. ## 디플로이먼트 업데이트 {{< note >}} -디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. +디플로이먼트의 파드 템플릿(즉, `.spec.template`)이 변경된 경우에만 디플로이먼트의 롤아웃이 트리거(trigger) 된다. 예를 들면 템플릿의 레이블이나 컨테이너 이미지가 업데이트된 경우이다. 디플로이먼트의 스케일링과 같은 다른 업데이트는 롤아웃을 트리거하지 말아야 한다. {{< /note >}} @@ -219,7 +220,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml nginx-deployment 3/3 3 3 36s ``` -* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, +* `kubectl get rs` 를 실행해서 디플로이먼트가 새 레플리카셋을 생성해서 파드를 업데이트 했는지 볼 수 있고, 새 레플리카셋을 최대 3개의 레플리카로 스케일 업, 이전 레플리카셋을 0개의 레플리카로 스케일 다운한다. ```shell @@ -255,8 +256,8 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml 또한 디플로이먼트는 의도한 파드 수 보다 더 많이 생성되는 파드의 수를 제한한다. 기본적으로, 의도한 파드의 수 기준 최대 125%까지만 추가 파드가 동작할 수 있도록 제한한다(최대 25% 까지). - 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 - 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, + 예를 들어, 위 디플로이먼트를 자세히 살펴보면 먼저 새로운 파드를 생성한 다음 + 이전 파드를 삭제하고, 새로운 파드를 만든 것을 볼 수 있다. 충분한 수의 새로운 파드가 나올 때까지 이전 파드를 죽이지 않으며, 충분한 수의 이전 파드들이 죽기 전까지 새로운 파드를 만들지 않는다. 이것은 최소 2개의 파드를 사용할 수 있게 하고, 최대 4개의 파드를 사용할 수 있게 한다. @@ -264,7 +265,7 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml ```shell kubectl describe deployments ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -303,48 +304,48 @@ kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 ``` - 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 + 처음 디플로이먼트를 생성했을 때, 디플로이먼트가 레플리카셋(nginx-deployment-2035384211)을 생성해서 3개의 레플리카로 직접 스케일 업한 것을 볼 수 있다. - 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 + 디플로이먼트를 업데이트할 때 새 레플리카셋(nginx-deployment-1564180365)을 생성하고, 1개로 스케일 업한 다음 이전 레플리카셋을 2개로 스케일 다운해서, 최소 2개의 파드를 사용할 수 있고 최대 4개의 파드가 항상 생성되어 있도록 하였다. 이후 지속해서 같은 롤링 업데이트 정책으로 새 레플리카셋은 스케일 업하고 이전 레플리카셋은 스케일 다운한다. 마지막으로 새로운 레플리카셋에 3개의 사용 가능한 레플리카가 구성되며, 이전 레플리카셋은 0개로 스케일 다운된다. ### 롤오버(일명 인-플라이트 다중 업데이트) -디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 -의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 +디플로이먼트 컨트롤러는 각 시간마다 새로운 디플로이먼트에서 레플리카셋이 +의도한 파드를 생성하고 띄우는 것을 주시한다. 만약 디플로이먼트가 업데이트되면, 기존 레플리카셋에서 `.spec.selector` 레이블과 일치하는 파드를 컨트롤 하지만, 템플릿과 `.spec.template` 이 불일치하면 스케일 다운이 된다. 결국 새로운 레플리카셋은 `.spec.replicas` 로 스케일되고, 모든 기존 레플리카 셋은 0개로 스케일된다. -만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, +만약 기존 롤아웃이 진행되는 중에 디플로이먼트를 업데이트하는 경우 디플로이먼트가 업데이트에 따라 새 레플리카셋을 생성하고, 스케일 업하기 시작한다. 그리고 이전에 스케일 업 하던 레플리카셋에 롤오버 한다. --이것은 기존 레플리카셋 목록에 추가하고 스케일 다운을 할 것이다. 예를 들어 디플로이먼트로 `nginx:1.14.2` 레플리카를 5개 생성을 한다. -하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` -레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 -`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. -이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 +하지만 `nginx:1.14.2` 레플리카 3개가 생성되었을 때 디플로이먼트를 업데이트해서 `nginx:1.16.1` +레플리카 5개를 생성성하도록 업데이트를 한다고 가정한다. 이 경우 디플로이먼트는 즉시 생성된 3개의 +`nginx:1.14.2` 파드 3개를 죽이기 시작하고 `nginx:1.16.1` 파드를 생성하기 시작한다. +이것은 과정이 변경되기 전 `nginx:1.14.2` 레플리카 5개가 생성되는 것을 기다리지 않는다. ### 레이블 셀렉터 업데이트 일반적으로 레이블 셀렉터를 업데이트 하는 것을 권장하지 않으며 셀렉터를 미리 계획하는 것을 권장한다. -어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, +어떤 경우든 레이블 셀렉터의 업데이트를 해야하는 경우 매우 주의하고, 모든 영향을 파악했는지 확인해야 한다. {{< note >}} API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 이후에는 변경할 수 없다. {{< /note >}} -* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. -그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 -이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, +* 셀렉터 추가 시 디플로이먼트의 사양에 있는 파드 템플릿 레이블도 새 레이블로 업데이트 해야한다. +그렇지 않으면 유효성 검사 오류가 반환된다. 이 변경은 겹치지 않는 변경으로 새 셀렉터가 +이전 셀렉터로 만든 레플리카셋과 파드를 선택하지 않게 되고, 그 결과로 모든 기존 레플리카셋은 고아가 되며, 새로운 레플리카셋을 생성하게 된다. * 셀렉터 업데이트는 기존 셀렉터 키 값을 변경하며, 결과적으로 추가와 동일한 동작을 한다. * 셀렉터 삭제는 디플로이먼트 셀렉터의 기존 키를 삭제하며 파드 템플릿 레이블의 변경을 필요로 하지 않는다. -기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. +기존 레플리카셋은 고아가 아니고, 새 레플리카셋은 생성되지 않는다. 그러나 제거된 레이블은 기존 파드와 레플리카셋에 여전히 존재한다는 점을 참고해야 한다. ## 디플로이먼트 롤백 @@ -354,11 +355,11 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 (이 사항은 수정 기록에 대한 상한 수정을 통해서 변경할 수 있다). {{< note >}} -디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 -(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. +디플로이먼트의 수정 버전은 디플로이먼트 롤아웃시 생성된다. 이는 디플로이먼트 파드 템플릿 +(`.spec.template`)이 변경되는 경우에만 새로운 수정 버전이 생성된다는 것을 의미한다. 예를 들어 템플릿의 레이블 또는 컨테이너 이미지를 업데이트 하는 경우. 디플로이먼트의 스케일링과 같은 다른 업데이트시 디플로이먼트 수정 버전은 생성되지 않으며 수동-스케일링 또는 자동-스케일링을 동시에 수행할 수 있다. -이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 +이는 이전 수정 버전으로 롤백을 하는 경우에 디플로이먼트 파드 템플릿 부분만 롤백된다는 것을 의미한다. {{< /note >}} @@ -385,7 +386,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 Waiting for rollout to finish: 1 out of 3 new replicas have been updated... ``` -* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). +* Ctrl-C 를 눌러 위의 롤아웃 상태 보기를 중지한다. 고착된 롤아웃 상태에 대한 자세한 정보는 [이 것을 더 읽어본다](#디플로이먼트-상태). * 이전 레플리카는 2개(`nginx-deployment-1564180365` 과 `nginx-deployment-2035384211`), 새 레플리카는 1개(nginx-deployment-3066724191)임을 알 수 있다. @@ -425,7 +426,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl describe deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -476,7 +477,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl rollout history deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" REVISION CHANGE-CAUSE @@ -496,7 +497,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployments "nginx-deployment" revision 2 Labels: app=nginx @@ -521,7 +522,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` @@ -531,14 +532,14 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2 ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` deployment.apps/nginx-deployment rolled back ``` 롤아웃 관련 명령에 대한 자세한 내용은 [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout)을 참조한다. - 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 + 이제 디플로이먼트가 이전 안정 수정 버전으로 롤백 된다. 버전 2로 롤백하기 위해 `DeploymentRollback` 이벤트가 디플로이먼트 컨트롤러에서 생성되는 것을 볼 수 있다. 2. 만약 롤백에 성공하고, 디플로이먼트가 예상대로 실행되는지 확인하려면 다음을 실행한다. @@ -546,7 +547,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 kubectl get deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 30m @@ -555,7 +556,7 @@ API 버전 `apps/v1` 에서 디플로이먼트의 레이블 셀렉터는 생성 ```shell kubectl describe deployment nginx-deployment ``` - 이와 유사하게 출력된다. + 이와 유사하게 출력된다. ``` Name: nginx-deployment Namespace: default @@ -613,7 +614,7 @@ deployment.apps/nginx-deployment scaled ``` 가령 클러스터에서 [horizontal Pod autoscaling](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 설정 -한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 +한 경우 디플로이먼트에 대한 오토스케일러를 설정할 수 있다. 그리고 기존 파드의 CPU 사용률을 기준으로 실행할 최소 파드 및 최대 파드의 수를 선택할 수 있다. ```shell @@ -627,7 +628,7 @@ deployment.apps/nginx-deployment scaled ### 비례적 스케일링(Proportional Scaling) 디플로이먼트 롤링업데이트는 여러 버전의 애플리케이션을 동시에 실행할 수 있도록 지원한다. -사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), +사용자 또는 오토스케일러가 롤아웃 중에 있는 디플로이먼트 롤링 업데이트를 스케일링 하는 경우(진행중 또는 일시 중지 중), 디플로이먼트 컨트롤러는 위험을 줄이기 위해 기존 활성화된 레플리카셋(파드와 레플리카셋)의 추가 레플리카의 균형을 조절 한다. 이것을 *proportional scaling* 라 부른다. @@ -654,7 +655,7 @@ deployment.apps/nginx-deployment scaled deployment.apps/nginx-deployment image updated ``` -* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, +* 이미지 업데이트는 레플리카셋 nginx-deployment-1989198191 으로 새로운 롤 아웃이 시작하지만, 위에서 언급한 `maxUnavailable` 의 요구 사항으로 인해 차단된다. 롤아웃 상태를 확인한다. ```shell kubectl get rs @@ -674,14 +675,14 @@ deployment.apps/nginx-deployment scaled 남은 것들은 대부분의 레플리카가 있는 레플리카셋에 추가된다. 0개의 레플리카가 있는 레플리카셋은 스케일 업 되지 않는다. 위의 예시에서 기존 레플리카셋에 3개의 레플리카가 추가되고, 2개의 레플리카는 새 레플리카에 추가된다. -결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. +결국 롤아웃 프로세스는 새 레플리카가 정상이라고 가정하면 모든 레플리카를 새 레플리카셋으로 이동시킨다. 이를 확인하려면 다음을 실행한다. ```shell kubectl get deploy ``` -이와 유사하게 출력된다. +이와 유사하게 출력된다. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m @@ -845,7 +846,7 @@ nginx-deployment-618515232 11 11 11 7m 쿠버네티스는 다음과 같은 특성을 가지게 되면 디플로이먼트를 _완료_ 로 표시한다. -* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. +* 디플로이먼트과 관련된 모든 레플리카가 지정된 최신 버전으로 업데이트 되었을 때. 즉, 요청한 모든 업데이트가 완료되었을 때. * 디플로이먼트와 관련한 모든 레플리카를 사용할 수 있을 때. * 디플로이먼트에 대해 이전 복제본이 실행되고 있지 않을 때. @@ -877,11 +878,11 @@ $ echo $? * 애플리케이션 런타임의 잘못된 구성 이 조건을 찾을 수 있는 한 가지 방법은 디플로이먼트 스펙에서 데드라인 파라미터를 지정하는 것이다 -([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 -(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 +([`.spec.progressDeadlineSeconds`](#진행-기한-시간-초)). `.spec.progressDeadlineSeconds` 는 +(디플로이먼트 상태에서) 디플로이먼트의 진행이 정지되었음을 나타내는 디플로이먼트 컨트롤러가 대기하는 시간(초)를 나타낸다. -다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 +다음 `kubectl` 명령어로 `progressDeadlineSeconds` 를 설정해서 컨트롤러가 10분 후 디플로이먼트에 대한 진행 상태의 부족에 대한 리포트를 수행하게 한다. ```shell @@ -891,7 +892,7 @@ kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadline ``` deployment.apps/nginx-deployment patched ``` -만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 +만약 데드라인을 넘어서면 디플로이먼트 컨트롤러는 디플로이먼트의 `.status.conditions` 속성에 다음의 디플로이먼트 컨디션(DeploymentCondition)을 추가한다. * Type=Progressing @@ -901,14 +902,14 @@ deployment.apps/nginx-deployment patched 컨디션 상태에 대한 자세한 내용은 [쿠버네티스 API 규칙](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties)을 참고한다. {{< note >}} -쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 -보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, +쿠버네티스는 `Reason=ProgressDeadlineExceeded` 과 같은 상태 조건을 +보고하는 것 이외에 정지된 디플로이먼트에 대해 조치를 취하지 않는다. 더 높은 수준의 오케스트레이터는 이를 활용할 수 있으며, 예를 들어 디플로이먼트를 이전 버전으로 롤백할 수 있다. {{< /note >}} {{< note >}} 만약 디플로이먼트를 일시 중지하면 쿠버네티스는 지정된 데드라인과 비교하여 진행 상황을 확인하지 않는다. -롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 +롤아웃 중에 디플로이먼트를 안전하게 일시 중지하고, 데드라인을 넘기도록 하는 조건을 트리거하지 않고 재개할 수 있다. {{< /note >}} @@ -961,7 +962,7 @@ status: unavailableReplicas: 2 ``` -결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 +결국, 디플로이먼트 진행 데드라인을 넘어서면, 쿠버네티스는 진행 컨디션의 상태와 이유를 업데이트한다. ``` @@ -973,9 +974,9 @@ Conditions: ReplicaFailure True FailedCreate ``` -디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, +디플로이먼트를 스케일 다운하거나, 실행 중인 다른 컨트롤러를 스케일 다운하거나, 네임스페이스에서 할당량을 늘려서 할당량이 부족한 문제를 해결할 수 있다. -만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 +만약 할당량 컨디션과 디플로이먼트 롤아웃이 완료되어 디플로이먼트 컨트롤러를 만족한다면 성공한 컨디션의 디플로이먼트 상태가 업데이트를 볼 수 있다(`Status=True` 와 `Reason=NewReplicaSetAvailable`). ``` @@ -987,9 +988,9 @@ Conditions: ``` `Type=Available` 과 `Status=True` 는 디플로이먼트가 최소한의 가용성을 가지고 있는 것을 의미한다. -최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 +최소한의 가용성은 디플로이먼트 계획에 명시된 파라미터에 의해 결정된다. `Type=Progressing` 과 `Status=True` 는 디플로이먼트가 롤아웃 도중에 진행 중 이거나, 성공적으로 완료되었으며, 진행 중 최소한으로 필요한 새로운 레플리카를 이용 가능하다는 것이다. -(자세한 내용은 특정 조건의 이유를 참조한다. +(자세한 내용은 특정 조건의 이유를 참조한다. 이 경우 `Reason=NewReplicaSetAvailable` 는 배포가 완료되었음을 의미한다.) `kubectl rollout status` 를 사용해서 디플로이먼트의 진행이 실패되었는지 확인할 수 있다. @@ -1013,7 +1014,7 @@ $ echo $? ## 정책 초기화 -디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 +디플로이먼트의 `.spec.revisionHistoryLimit` 필드를 설정해서 디플로이먼트에서 유지해야 하는 이전 레플리카셋의 수를 명시할 수 있다. 나머지는 백그라운드에서 가비지-수집이 진행된다. 기본적으로 10으로 되어있다. @@ -1024,14 +1025,14 @@ $ echo $? ## 카나리 디플로이먼트 -만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 -[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 +만약 디플로이먼트를 이용해서 일부 사용자 또는 서버에 릴리즈를 롤아웃 하기 위해서는 +[리소스 관리](/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)에 설명된 카나리 패던에 따라 각 릴리스 마다 하나씩 여러 디플로이먼트를 생성할 수 있다. ## 디플로이먼트 사양 작성 다른 모든 쿠버네티스 설정과 마찬가지로 디플로이먼트에는 `.apiVersion`, `.kind` 그리고 `.metadata` 필드가 필요하다. -설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), +설정 파일 작업에 대한 일반적인 내용은 [애플리케이션 배포하기](/docs/tutorials/stateless-application/run-stateless-application-deployment/), 컨테이너 구성하기 그리고 [kubectl을 사용해서 리소스 관리하기](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참조한다. 디플로이먼트 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. @@ -1048,7 +1049,7 @@ $ echo $? 파드에 필요한 필드 외에 디플로이먼트 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 명시해야 한다. 레이블의 경우 다른 컨트롤러와 겹치지 않도록 해야한다. 자세한 것은 [셀렉터](#셀렉터)를 참조한다. -[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, +[`.spec.template.spec.restartPolicy`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 에는 오직 `Always` 만 허용되고, 명시되지 않으면 기본값이 된다. ### 레플리카 @@ -1057,15 +1058,14 @@ $ echo $? ### 셀렉터 -`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 +`.spec.selector` 는 디플로이먼트의 대상이 되는 파드에 대해 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 지정하는 필수 필드이다. `.spec.selector` 는 `.spec.template.metadata.labels` 과 일치해야 하며, 그렇지 않으면 API에 의해 거부된다. API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설정되지 않으면 `.spec.template.metadata.labels` 은 기본 설정되지 않는다. 그래서 이것들은 명시적으로 설정되어야 한다. 또한 `apps/v1` 에서는 디플로이먼트를 생성한 후에는 `.spec.selector` 이 변경되지 않는 점을 참고한다. - -디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 +디플로이먼트는 템플릿의 `.spec.template` 와 다르거나 파드의 수가 `.spec.replicas` 를 초과할 경우 셀렉터와 일치하는 레이블을 가진 파드를 종료할 수 있다. 파드의 수가 의도한 수량보다 적을 경우 `.spec.template` 에 맞는 새 파드를 띄운다. @@ -1075,7 +1075,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 쿠버네티스는 이 일을 막지 않는다. {{< /note >}} -만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 +만약 셀렉터가 겹치는 컨트롤러가 어러 개 있는 경우, 컨트롤러는 서로 싸우고 올바르게 작동하지 않는다. ### 전략 @@ -1099,8 +1099,8 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 #### 디플로이먼트 롤링 업데이트 -디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 -방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 +디플로이먼트는 `.spec.strategy.type==RollingUpdate` 이면 파드를 롤링 업데이트 +방식으로 업데이트 한다. `maxUnavailable` 와 `maxSurge` 를 명시해서 롤링 업데이트 프로세스를 제어할 수 있다. ##### 최대 불가(Max Unavailable) @@ -1110,9 +1110,10 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 절대 값은 반올림해서 백분율로 계산한다. 만약 `.spec.strategy.rollingUpdate.maxSurge` 가 0이면 값이 0이 될 수 없다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 -의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, -업데이트 중에 항상 사용가능한 전체 파드의 수는 의도한 파드의 수의 70%이상이 되도록 새 레플리카셋을 스케일을 업 할수 있다. +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 즉각 이전 레플리카셋의 크기를 +의도한 파드 중 70%를 스케일 다운할 수 있다. 새 파드가 준비되면 기존 레플리카셋을 스케일 다운할 수 있으며, +업데이트 중에 항상 사용 가능한 전체 파드의 수는 +의도한 파드의 수의 70% 이상이 되도록 새 레플리카셋을 스케일 업할 수 있다. ##### 최대 서지(Max Surge) @@ -1121,18 +1122,18 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 `MaxUnavailable` 값이 0이면 이 값은 0이 될 수 없다. 절대 값은 반올림해서 백분율로 계산한다. 기본 값은 25% 이다. -예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 +예를 들어 이 값을 30%로 설정하면 롤링업데이트 시작시 새 레플리카셋의 크기를 즉시 조정해서 기존 및 새 파드의 전체 갯수를 의도한 파드의 130%를 넘지 않도록 한다. -기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, +기존 파드가 죽으면 새로운 래플리카셋은 스케일 업할 수 있으며, 업데이트하는 동안 항상 실행하는 총 파드의 수는 최대 의도한 파드의 수의 130%가 되도록 보장한다. ### 진행 기한 시간(초) -`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 -상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 +`.spec.progressDeadlineSeconds` 는 디플로어먼트가 표면적으로 `Type=Progressing`, `Status=False`의 +상태 그리고 리소스가 `Reason=ProgressDeadlineExceeded` 상태로 [진행 실패](#디플로이먼트-실패)를 보고하기 전에 디플로이먼트가 진행되는 것을 대기시키는 시간(초)를 명시하는 선택적 필드이다. 디플로이먼트 컨트롤러는 디플로이먼트를 계속 재시도 한다. 기본값은 600(초)이다. -미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, +미래에 자동화된 롤백이 구현된다면 디플로이먼트 컨트롤러는 상태를 관찰하고, 그 즉시 디플로이먼트를 롤백할 것이다. 만약 명시된다면 이 필드는 `.spec.minReadySeconds` 보다 커야 한다. @@ -1153,7 +1154,7 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 디플로이먼트의 수정 버전 기록은 자신이 컨트롤하는 레플리카셋에 저장된다. `.spec.revisionHistoryLimit` 은 롤백을 허용하기 위해 보존할 이전 레플리카셋의 수를 지정하는 선택적 필드이다. -이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. +이 이전 레플리카셋은 `etcd` 의 리소스를 소비하고, `kubectl get rs` 의 결과를 가득차게 만든다. 각 디플로이먼트의 구성은 디플로이먼트의 레플리카셋에 저장된다. 이전 레플리카셋이 삭제되면 해당 디플로이먼트 수정 버전으로 롤백할 수 있는 기능이 사라진다. 기본적으로 10개의 기존 레플리카셋이 유지되지만 이상적인 값은 새로운 디플로이먼트의 빈도와 안정성에 따라 달라진다. 더욱 구체적으로 이 필드를 0으로 설정하면 레플리카가 0이 되며 이전 레플리카셋이 정리된다. 이 경우, 새로운 디플로이먼트 롤아웃을 취소할 수 없다. 새로운 디플로이먼트 롤아웃은 수정 버전 이력이 정리되기 때문이다. @@ -1161,8 +1162,6 @@ API 버전 `apps/v1` 에서는 `.spec.selector` 와 `.metadata.labels` 이 설 ### 일시 정지 `.spec.paused` 는 디플로이먼트를 일시 중지나 재개하기 위한 선택적 부울 필드이다. -일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 +일시 중지 된 디플로이먼트와 일시 중지 되지 않은 디플로이먼트 사이의 유일한 차이점은 일시 중지된 디플로이먼트는 PodTemplateSpec에 대한 변경 사항이 일시중지 된 경우 새 롤아웃을 트리거 하지 않는다. 디플로이먼트는 생성시 기본적으로 일시 중지되지 않는다. - - diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md index f819614a6c032..4f4762fe9d0ed 100644 --- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md @@ -22,7 +22,7 @@ weight: 60 필드를 가지고 있다. 때때로, 쿠버네티스는 `ownerReference` 값을 자동적으로 설정한다. -예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 +예를 들어 레플리카셋을 만들 때 쿠버네티스는 레플리카셋에 있는 각 파드의 `ownerReference` 필드를 자동으로 설정한다. 1.8 에서는 쿠버네티스가 레플리케이션컨트롤러, 레플리카셋, 스테이트풀셋, 데몬셋, 디플로이먼트, 잡 그리고 크론잡에 의해서 생성되거나 차용된 오브젝트의 `ownerReference` 값을 @@ -35,7 +35,7 @@ weight: 60 {{< codenew file="controllers/replicaset.yaml" >}} -레플리카셋을 생성하고 파드의 메타데이터를 본다면, +레플리카셋을 생성하고 파드의 메타데이터를 본다면, OwnerReferences 필드를 찾을 수 있다. ```shell @@ -72,7 +72,7 @@ metadata: 오브젝트를 삭제할 때, 오브젝트의 종속 항목을 자동으로 삭제하는지의 여부를 지정할 수 있다. 종속 항목을 자동으로 삭제하는 것을 *캐스케이딩(cascading) -삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. +삭제* 라고 한다. *캐스케이딩 삭제* 에는 *백그라운드* 와 *포어그라운드* 2가지 모드가 있다. 만약 종속 항목을 자동으로 삭제하지 않고 오브젝트를 삭제한다면, 종속 항목은 *분리됨(orphaned)* 이라고 한다. @@ -147,8 +147,8 @@ curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-rep ``` kubectl도 캐스케이딩 삭제를 지원한다. -kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 -분리하기 위해서는 `--cascase` 를 false로 설정한다. `--cascade` 의 기본값은 +kubectl을 사용해서 종속 항목을 자동으로 삭제하려면 `--cascade` 를 true로 설정한다. 종속 항목을 +분리하기 위해서는 `--cascade` 를 false로 설정한다. `--cascade` 의 기본값은 true 이다. 여기에 레플리카셋의 종속 항목을 분리로 만드는 예시가 있다. @@ -181,3 +181,4 @@ kubectl delete replicaset my-repset --cascade=false + diff --git a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md index 4d6e93ded5ff6..f203befbade35 100644 --- a/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/ko/docs/concepts/workloads/controllers/jobs-run-to-completion.md @@ -111,7 +111,7 @@ kubectl logs $pods ## 잡 사양 작성하기 다른 쿠버네티스의 설정과 마찬가지로 잡에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. -잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +잡의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 잡에는 [`.spec` 섹션](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. @@ -175,8 +175,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 - _고정적인 완료 횟수(fixed completion count)_ 잡의 경우, 병렬로 실행 중인 파드의 수는 남은 완료 수를 초과하지 않는다. `.spec.parallelism` 의 더 큰 값은 사실상 무시된다. - _작업 큐_ 잡은 파드가 성공한 이후에 새로운 파드가 시작되지 않는다. 그러나 나머지 파드는 완료될 수 있다. -- 만약 잡 {{< glossary_tooltip term_id="controller" >}} 가 반응할 시간이 없는 경우 -- 만약 잡 컨트롤러가 어떤 이유(`리소스 쿼터` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, +- 만약 잡 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}} 가 반응할 시간이 없는 경우 +- 만약 잡 컨트롤러가 어떤 이유(`ResourceQuota` 의 부족, 권한 부족 등)로든 파드 생성에 실패한 경우, 요청한 것보다 적은 수의 파드가 있을 수 있다. - 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다. - 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다. @@ -327,7 +327,7 @@ spec: 여기에는 전송할 이메일들, 렌더링할 프레임, 코드 변환이 필요한 파일, NoSQL 데이터베이스에서의 키 범위 스캔 등이 있다. -복잡한 시스템에는 여러개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 +복잡한 시스템에는 여러 개의 다른 작업 항목 집합이 있을 수 있다. 여기서는 사용자와 함께 관리하려는 하나의 작업 항목 집합 — *배치 잡* 을 고려하고 있다. 병렬 계산에는 몇몇 다른 패턴이 있으며 각각의 장단점이 있다. @@ -471,8 +471,6 @@ spec: 이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도, 파드 생성과 작업 할당 방법을 완전히 제어하고 유지한다는 것이다. -## 크론 잡 {#cron-jobs} - -[`크론잡`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. - +## 크론잡 {#cron-jobs} +[`CronJob`](/ko/docs/concepts/workloads/controllers/cron-jobs/)을 사용해서 Unix 도구인 `cron`과 유사하게 지정된 시간/일자에 실행되는 잡을 생성할 수 있다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 16146a45b63f9..7f78c8d6f0aec 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -13,10 +13,10 @@ weight: 20 {{< note >}} -[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/) 을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/) 가 현재 권장되는 레플리케이션 설정 방법이다. +[`ReplicaSet`](/ko/docs/concepts/workloads/controllers/replicaset/)을 구성하는 [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)가 현재 권장하는 레플리케이션 설정 방법이다. {{< /note >}} -_레플리케이션 컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 +_레플리케이션컨트롤러_ 는 언제든지 지정된 수의 파드 레플리카가 실행 중임을 보장한다. 다시 말하면, 레플리케이션 컨트롤러는 파드 또는 동일 종류의 파드의 셋이 항상 기동되고 사용 가능한지 확인한다. @@ -105,8 +105,8 @@ echo $pods nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` -여기서 셀렉터는 레플리케이션 컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, -다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 +여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, +다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다. @@ -123,7 +123,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m `.spec.template` 는 오직 `.spec` 필드에서 요구되는 것이다. -`.spec.template` 는 [파드(Pod) 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. +`.spec.template` 는 [파드 개요](/ko/docs/concepts/workloads/pods/pod-overview/#pod-templates) 이다. 정확하게 [파드](/ko/docs/concepts/workloads/pods/pod/) 스키마와 동일하나, 중첩되어 있고 `apiVersion` 혹은 `kind`를 갖지 않는다. 파드에 필요한 필드 외에도 레플리케이션 컨트롤러의 파드 템플릿은 적절한 레이블과 적절한 재시작 정책을 지정해야 한다. 레이블의 경우 다른 컨트롤러와 중첩되지 않도록 하라. [파드 셀렉터](#파드-셀렉터)를 참조하라. @@ -223,12 +223,12 @@ REST API나 go 클라이언트 라이브러리를 사용하는 경우 간단히 예를 들어, 서비스는 `tier in (frontend), environment in (prod)` 이 있는 모든 파드를 대상으로 할 수 있다. 이제 이 계층을 구성하는 10 개의 복제된 파드가 있다고 가정해 보자. 하지만 이 구성 요소의 새로운 버전을 '카나리' 하기를 원한다. 대량의 레플리카에 대해 `replicas` 를 9로 설정하고 `tier=frontend, environment=prod, track=stable` 레이블을 설정한 레플리케이션 컨트롤러와, 카나리에 `replicas` 가 1로 설정된 다른 레플리케이션 컨트롤러에 `tier=frontend, environment=prod, track=canary` 라는 레이블을 설정할 수 있다. 이제 이 서비스는 카나리와 카나리 이외의 파드 모두를 포함한다. 그러나 레플리케이션 컨트롤러를 별도로 조작하여 테스트하고 결과를 모니터링하는 등의 작업이 혼란스러울 수 있다. -### 서비스와 레플리케이션 컨트롤러 사용 +### 서비스와 레플리케이션컨트롤러 사용 -하나의 서비스 뒤에 여러 개의 레플리케이션 컨트롤러가 있을 수 있다. 예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. +하나의 서비스 뒤에 여러 개의 레플리케이션컨트롤러가 있을 수 있다. +예를 들어 일부 트래픽은 이전 버전으로 이동하고 일부는 새 버전으로 이동한다. -레플리케이션 컨트롤러는 자체적으로 종료되지 않지만 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션 컨트롤러에 의해 제어되는 파드로 구성될 수 있으며 서비스 라이프사이클 동안 (예를 들어 서비스를 실행하는 파드 업데이트 수행을 위해) -많은 레플리케이션 컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션 컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. +레플리케이션컨트롤러는 자체적으로 종료되지 않지만, 서비스만큼 오래 지속될 것으로 기대되지는 않는다. 서비스는 여러 레플리케이션컨트롤러에 의해 제어되는 파드로 구성될 수 있으며, 서비스 라이프사이클 동안(예를 들어, 서비스를 실행하는 파드 업데이트 수행을 위해) 많은 레플리케이션컨트롤러가 생성 및 제거될 것으로 예상된다. 서비스 자체와 클라이언트 모두 파드를 유지하는 레플리케이션컨트롤러를 의식하지 않는 상태로 남아 있어야 한다. ## 레플리케이션을 위한 프로그램 작성 @@ -280,6 +280,4 @@ API 오브젝트에 대한 더 자세한 것은 ## 더 자세한 정보는 -[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/) 를 참조하라. - - +[스테이트리스 애플리케이션 레플리케이션 컨트롤러 실행하기](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)를 참고한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 1779ea4f92909..39836fd7a152b 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -24,24 +24,25 @@ weight: 40 * 순차적인, 자동 롤링 업데이트. 위의 안정은 파드의 (재)스케줄링 전반에 걸친 지속성과 같은 의미이다. -만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, -삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 +만약 애플리케이션이 안정적인 식별자 또는 순차적인 배포, +삭제 또는 스케일링이 필요하지 않으면, 스테이트리스 레플리카 셋을 제공하는 워크로드 오브젝트를 사용해서 애플리케이션을 배포해야 한다. -[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 +[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/) 또는 [레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/)과 같은 컨트롤러가 스테이트리스 요구에 더 적합할 수 있다. ## 제한사항 * 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다. -* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. +* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다. * 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다. * 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다. -* [롤링 업데이트](#롤링-업데이트)와 기본 +* [롤링 업데이트](#롤링-업데이트)와 기본 [파드 매니지먼트 폴리시](#파드-매니지먼트-폴리시) (`OrderedReady`)를 함께 사용시 [복구를 위한 수동 개입](#강제-롤백)이 필요한 파손 상태로 빠질 수 있다. ## 구성 요소 + 아래의 예시에서는 스테이트풀셋의 구성요소를 보여 준다. ```yaml @@ -100,9 +101,9 @@ spec: * 이름이 nginx라는 헤드리스 서비스는 네트워크 도메인을 컨트롤하는데 사용 한다. * 이름이 web인 스테이트풀셋은 3개의 nginx 컨테이너의 레플리카가 고유의 파드에서 구동될 것이라 지시하는 Spec을 갖는다. * volumeClaimTemplates은 퍼시스턴트 볼륨 프로비저너에서 프로비전한 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 사용해서 안정적인 스토리지를 제공한다. -스테이트풀셋 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)이어야 한다. +스테이트풀셋 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. ## 파드 셀렉터 @@ -110,9 +111,9 @@ spec: ## 파드 신원 -스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 그리고 -안정적인 스토리지로 구성되는 고유한 신원을 가진다. 신원은 -파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. +스테이트풀셋 파드는 순서, 안정적인 네트워크 신원 +그리고 안정적인 스토리지로 구성되는 고유한 신원을 가진다. +신원은 파드가 어떤 노드에 있고, (재)스케줄과도 상관없이 파드에 붙어있다. ### 순서 색인 @@ -121,23 +122,23 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 ### 안정적인 네트워크 신원 -스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 -호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 -`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 +스테이트풀셋의 각 파드는 스테이트풀셋의 이름과 파드의 순번에서 +호스트 이름을 얻는다. 호스트 이름을 구성하는 패턴은 +`$(statefulset name)-$(ordinal)` 이다. 위의 예시에서 생성된 3개 파드의 이름은 `web-0,web-1,web-2` 이다. -스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 +스테이트풀셋은 스테이트풀셋에 있는 파드의 도메인을 제어하기위해 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 사용할 수 있다. -이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, +이 서비스가 관리하는 도메인은 `$(service name).$(namespace).svc.cluster.local` 의 형식을 가지며, 여기서 "cluster.local"은 클러스터 도메인이다. -각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 -일치되는 DNS 서브도메인을 가지며, 여기서 governing service는 +각 파드는 생성되면 `$(podname).$(governing service domain)` 형식을 가지고 +일치되는 DNS 서브도메인을 가지며, 여기서 거버닝 서비스(governing service)는 스테이트풀셋의 `serviceName` 필드에 의해 정의된다. [제한사항](#제한사항) 섹션에서 언급한 것처럼 사용자는 -파드의 네트워크 신원을 책임지는 +파드의 네트워크 신원을 책임지는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 생성할 책임이 있다. -여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, +여기 클러스터 도메인, 서비스 이름, 스테이트풀셋 이름을 선택을 하고, 그 선택이 스테이트풀셋 파드의 DNS이름에 어떻게 영향을 주는지에 대한 약간의 예시가 있다. 클러스터 도메인 | 서비스 (ns/이름) | 스테이트풀셋 (ns/이름) | 스테이트풀셋 도메인 | 파드 DNS | 파드 호스트 이름 | @@ -147,26 +148,26 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | {{< note >}} -클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 +클러스터 도메인이 달리 [구성된 경우](/ko/docs/concepts/services-networking/dns-pod-service/)가 아니라면 `cluster.local`로 설정된다. {{< /note >}} ### 안정된 스토리지 -쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 -생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 -1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게된다. 만약 스토리지 클래스가 -명시되지 않은 경우 기본 스토리지 클래스를 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이되면 +쿠버네티스는 각 VolumeClaimTemplate마다 하나의 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/)을 +생성한다. 위의 nginx 예시에서 각 파드는 `my-storage-class` 라는 스토리지 클래스와 +1 Gib의 프로비전된 스토리지를 가지는 단일 퍼시스턴트 볼륨을 받게 된다. 만약 스토리지 클래스가 +명시되지 않은 경우, 기본 스토리지 클래스가 사용된다. 파드가 노드에서 스케줄 혹은 재스케줄이 되면 파드의 `volumeMounts` 는 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨이 마운트 된다. -참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 +참고로, 파드 퍼시스턴트 볼륨 클레임과 관련된 퍼시스턴트 볼륨은 파드 또는 스테이트풀셋이 삭제되더라도 삭제되지 않는다. 이것은 반드시 수동으로 해야한다. ### 파드 이름 레이블 스테이트풀셋 {{< glossary_tooltip term_id="controller" >}} -가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` -레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 +가 파드를 생성할 때 파드 이름으로 `statefulset.kubernetes.io/pod-name` +레이블이 추가된다. 이 레이블로 스테이트풀셋의 특정 파드에 서비스를 연결할 수 있다. ## 디플로이먼트와 스케일링 보증 @@ -178,87 +179,87 @@ N개의 레플리카가 있는 스테이트풀셋은 스테이트풀셋에 있 스테이트풀셋은 `pod.Spec.TerminationGracePeriodSeconds` 을 0으로 명시해서는 안된다. 이 방법은 안전하지 않으며, 사용하지 않기를 강권한다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. -위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 -배포된다. web-1은 web-0이 -[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, -web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, -web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, +위의 nginx 예시가 생성될 때 web-0, web-1, web-2 순서로 3개 파드가 +배포된다. web-1은 web-0이 +[Running 및 Ready](/ko/docs/concepts/workloads/pods/pod-lifecycle/) 상태가 되기 전에는 배포되지 않으며, +web-2 도 web-1이 Running 및 Ready 상태가 되기 전에는 배포되지 않는다. 만약 web-1이 Running 및 Ready 상태가 된 이후, +web-2가 시작되기 전에 web-0이 실패하게 된다면, web-2는 web-0이 성공적으로 재시작이되고, Running 및 Ready 상태가 되기 전까지 시작되지 않는다. -만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 -스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 -전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 -web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 +만약 사용자가 배포된 예제의 스테이트풀셋을 `replicas=1` 으로 패치해서 +스케일한 경우 web-2가 먼저 종료된다. web-1은 web-2가 완전히 종료 및 삭제되기 +전까지 정지되지 않는다. 만약 web-2의 종료 및 완전히 중지되고, web-1이 종료되기 전에 +web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 되기 전까지 종료되지 않는다. ### 파드 관리 정책 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.podManagementPolicy` 필드를 통해 고유성 및 신원 보증을 유지하면서 순차 보증을 완화한다. #### OrderedReady 파드 관리 -`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. +`OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. 이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다. #### 병렬 파드 관리 -`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 -병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 +`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 +병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다. -이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 +이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 받지 않는다. ## 업데이트 전략 -쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 -파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 +쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의 +파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를 구성하거나 비활성화 할 수 있다. ### 삭제 시(On Delete) -`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 -`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 -스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 +`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의 +`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는 +스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의 `.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다. ### 롤링 업데이트 -`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 -구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 -스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 -순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), -각 파드의 업데이트는 한번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 +`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를 +구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면 +스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이 +순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지), +각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될 때까지 기다린다. #### 파티션(Partition) -`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` -를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 +`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition` +를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가 업데이트 될 때 부여된 수가 파티션보다 크거나 같은 모든 파드가 업데이트 된다. -파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, +파티션보다 작은 수를 가진 모든 파드는 업데이트 되지 않으며, 삭제 된 경우라도 이전 버전에서 재생성된다. -만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 +만약 스테이트풀셋의 `.spec.updateStrategy.rollingUpdate.partition` 이 `.spec.replicas` 보다 큰 경우 `.spec.template` 의 업데이트는 해당 파드에 전달하지 않는다. -대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, +대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나, 카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다. #### 강제 롤백 -기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 -함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 +기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과 +함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우 직접 수동으로 복구를 해야하는 고장난 상태가 될 수 있다. -만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 -경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) +만약 파드 템플릿을 Running 및 Ready 상태가 되지 않는 구성으로 업데이트하는 +경우(예시: 잘못된 바이너리 또는 애플리케이션-레벨 구성 오류로 인한) 스테이트풀셋은 롤아웃을 중지하고 기다린다. 이 상태에서는 파드 템플릿을 올바른 구성으로 되돌리는 것으로 충분하지 않다. -[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 -인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 -작동하는 구성으로 되돌아가는 시도를 하기 +[알려진 이슈](https://github.com/kubernetes/kubernetes/issues/67250)로 +인해 스테이트풀셋은 손상된 파드가 준비(절대 되지 않음)될 때까지 기다리며 +작동하는 구성으로 되돌아가는 시도를 하기 전까지 기다린다. -템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 +템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로 실행하려고 시도한 모든 파드를 삭제해야 한다. 그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다. @@ -269,6 +270,3 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 * [스테이트풀 애플리케이션의 배포](/ko/docs/tutorials/stateful-application/basic-stateful-set/)의 예시를 따른다. * [카산드라와 스테이트풀셋 배포](/ko/docs/tutorials/stateful-application/cassandra/)의 예시를 따른다. * [레플리케이티드(replicated) 스테이트풀 애플리케이션 실행하기](/docs/tasks/run-application/run-replicated-stateful-application/)의 예시를 따른다. - - - diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index c095dd31c5de4..de92b4f3ea26b 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -14,8 +14,9 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. -알파(Alpha) 고지 사항: 이 기능은 현재 알파이다, 그리고 kube-apiserver 와 kube-controller-manager 와 함께 -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/) 로 `TTLAfterFinished` 를 활성화 할 수 있다. +알파(Alpha) 고지 사항: 이 기능은 현재 알파이고, +kube-apiserver와 kube-controller-manager와 함께 +[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. @@ -66,13 +67,13 @@ TTL 기간은, 예를 들어 잡의 `.spec.ttlSecondsAfterFinished` 필드는 ### 시간 차이(Skew) TTL 컨트롤러는 쿠버네티스 리소스에 -저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 +저장된 타임스탬프를 사용해서 TTL의 만료 여부를 결정하기 때문에, 이 기능은 클러스터 간의 시간 차이에 민감하며, 시간 차이에 의해서 TTL 컨트롤러가 잘못된 시간에 리소스 오브젝트를 정리하게 될 수 있다. 쿠버네티스에서는 시간 차이를 피하기 위해 모든 노드 ([#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058)를 본다) -에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 +에서 NTP를 실행해야 한다. 시계가 항상 정확한 것은 아니지만, 그 차이는 아주 작아야 한다. 0이 아닌 TTL을 설정할때는 이 위험에 대해 유의해야 한다. @@ -83,5 +84,3 @@ TTL 컨트롤러는 쿠버네티스 리소스에 [자동으로 잡 정리](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/#완료된-잡을-자동으로-정리) [디자인 문서](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0026-ttl-after-finish.md) - - diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index bd2f2023af501..0e46b4bf5e1bb 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -9,7 +9,7 @@ weight: 60 파드에서 발생하는 장애 유형을 이해하기 원하는 애플리케이션 소유자를 위한 것이다. -또한 클러스터의 업그레이드와 오토스케일링과 같은 +또한 클러스터의 업그레이드와 오토스케일링과 같은 클러스터의 자동화 작업을 하려는 관리자를 위한 것이다. @@ -19,7 +19,7 @@ weight: 60 ## 자발적 중단과 비자발적 중단 -파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 +파드는 누군가(사람 또는 컨트롤러)가 파괴하거나 불가피한 하드웨어 오류 또는 시스템 소프트웨어 오류가 아니면 사라지지 않는다. 우리는 이런 불가피한 상황을 애플리케이션의 *비자발적 중단* 으로 부른다. @@ -33,7 +33,8 @@ weight: 60 - 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. -왜냐하면 그 조건은 쿠버네티스에 국한되지 않기 때문이다. +왜냐하면 +그 조건은 쿠버네티스에 국한되지 않기 때문이다. 우리는 다른 상황을 *자발적인 중단* 으로 부른다. 여기에는 애플리케이션 소유자의 작업과 클러스터 관리자의 작업이 모두 포함된다. @@ -46,19 +47,21 @@ weight: 60 클러스터 관리자의 작업: - 복구 또는 업그레이드를 위한 [노드 드레이닝](/docs/tasks/administer-cluster/safely-drain-node/). -- 클러스터의 스케일 축소를 위한 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaler)에 대해 알아보기). +- 클러스터의 스케일 축소를 위한 + 노드 드레이닝([클러스터 오토스케일링](/ko/docs/tasks/administer-cluster/cluster-management/#클러스터-오토스케일링)에 대해 알아보기 + ). - 노드에 다른 무언가를 추가하기 위해 파드를 제거. 위 작업은 클러스터 관리자가 직접 수행하거나 자동화를 통해 수행하며, 클러스터 호스팅 공급자에 의해서도 수행된다. -클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 +클러스터에 자발적인 중단을 일으킬 수 있는 어떤 원인이 있는지 클러스터 관리자에게 문의하거나 클라우드 공급자에게 문의하고, 배포 문서를 참조해서 확인해야 한다. 만약 자발적인 중단을 일으킬 수 있는 원인이 없다면 Pod Disruption Budget의 생성을 넘길 수 있다. {{< caution >}} 모든 자발적인 중단이 Pod Disruption Budget에 연관되는 것은 아니다. -예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget를 무시한다. +예를 들어 디플로이먼트 또는 파드의 삭제는 Pod Disruption Budget을 무시한다. {{< /caution >}} ## 중단 다루기 @@ -66,48 +69,58 @@ weight: 60 비자발적인 중단으로 인한 영향을 경감하기 위한 몇 가지 방법은 다음과 같다. - 파드가 필요로 하는 [리소스를 요청](/docs/tasks/configure-pod-container/assign-cpu-ram-container)하는지 확인한다. -- 고가용성이 필요한 경우 애플리케이션을 복제한다. (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/)애플리케이션에 대해 알아보기.) -- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체([안티-어피니티](/docs/user-guide/node-selection/#inter-pod-affinity-and-anti-affinity-beta-feature) 이용) 또는 -영역 간(또는 [다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다.)에 -애플리케이션을 분산해야 한다. +- 고가용성이 필요한 경우 애플리케이션을 복제한다. + (복제된 [스테이트리스](/docs/tasks/run-application/run-stateless-application-deployment/) 및 + [스테이트풀](/docs/tasks/run-application/run-replicated-stateful-application/) 애플리케이션에 대해 알아보기.) +- 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 + ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) + 또는 영역 간 + ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 + 애플리케이션을 분산해야 한다. 자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. -또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. -클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +또한 클러스터(노드) 오토스케일링의 일부 구현에서는 +단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. +클러스터 관리자 또는 호스팅 공급자는 +예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. 쿠버네티스는 자주 발생하는 자발적 중단에도 고가용성 애플리케이션을 -실행 할 수 있는 기능을 제공한다. +실행 할 수 있는 기능을 제공한다. 우리는 이 기능을 *Disruption Budgets* 이라 부른다. + ## Disruption Budgets의 작동 방식 {{< feature-state for_k8s_version="v1.5" state="beta" >}} 애플리케이션 소유자는 각 애플리케이션에 대해 `PodDisruptionBudget` 오브젝트(PDB)를 만들 수 있다. -PDB는 자발적 중단으로 일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. -예를 들어 정족수 기반의 애플리케이션이 +PDB는 자발적 중단으로 +일시에 중지되는 복제된 애플리케이션 파드의 수를 제한한다. +예를 들어 정족수 기반의 애플리케이션이 실행 중인 레플리카의 수가 정족수 이하로 떨어지지 않도록 한다. -웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 +웹 프런트 엔드는 부하를 처리하는 레플리카의 수가 일정 비율 이하로 떨어지지 않도록 보장할 수 있다. -클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 -[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 -불리는 Pod Disruption Budgets를 준수하는 도구를 이용해야 한다. +클러스터 관리자와 호스팅 공급자는 직접적으로 파드나 디플로이먼트를 제거하는 대신 +[Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)로 +불리는 Pod Disruption Budget을 준수하는 도구를 이용해야 한다. 예를 들어 `kubectl drain` 명령어나 Kubernetes-on-GCE 클러스터 업그레이드 스크립트(`cluster/gce/upgrade.sh`)이다. 클러스터 관리자가 노드를 비우고자 할 경우에는 `kubectl drain` 명령어를 사용한다. 해당 도구는 머신에 존재하는 모든 파드를 축출하려는 시도를 한다. -축출 요청은 일시적으로 거부될 수 있으며, 도구는 모든 파드가 종료되거나 +축출 요청은 일시적으로 거부될 수 있으며, +도구는 모든 파드가 종료되거나 설정 가능한 타임아웃이 도래할 때까지 주기적으로 모든 실패된 요청을 다시 시도한다. PDB는 애플리케이션이 필요로 하는 레플리카의 수에 상대적으로, 용인할 수 있는 레플리카의 수를 지정한다. 예를 들어 `.spec.replicas: 5` 의 값을 갖는 디플로이먼트는 어느 시점에든 5개의 파드를 가져야 한다. -만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. +만약 해당 디플로이먼트의 PDB가 특정 시점에 파드를 4개 허용한다면, +Eviction API는 한 번에 2개의 파드가 아닌, 1개의 파드의 자발적인 중단을 허용한다. -파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 -애플리케이션 컨트롤러(디플로이먼트, 스테이트풀 셋 등)를 사용한 것과 같다. +파드 그룹은 레이블 셀렉터를 사용해서 지정한 애플리케이션으로 구성되며 +애플리케이션 컨트롤러(디플로이먼트, 스테이트풀셋 등)를 사용한 것과 같다. 파드의 "의도"하는 수량은 파드 컨트롤러의 `.spec.replicas` 를 기반으로 계산한다. 컨트롤러는 오브젝트의 `.metadata.ownerReferences` 를 사용해서 파드를 발견한다. @@ -116,7 +129,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 버짓이 차감된다. 애플리케이션의 롤링 업그레이드로 파드가 삭제되거나 사용할 수 없는 경우 중단 버짓에 영향을 준다. -그러나 컨트롤러(디플로이먼트, 스테이트풀 셋과 같은)는 롤링 업데이트시 PDB의 제한을 받지 않는다. +그러나 컨트롤러(디플로이먼트, 스테이트풀셋과 같은)는 +롤링 업데이트시 PDB의 제한을 받지 않는다. 애플리케이션 업데이트 진행 중 발생하는 중단 처리는 컨트롤러 사양에 구성되어있다. ([디플로이먼트 업데이트](/ko/docs/concepts/workloads/controllers/deployment/#디플로이먼트-업데이트)에 대해 알아보기.) @@ -126,7 +140,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 ## PDB 예시 `node-1` 부터 `node-3` 까지 3개의 노드가 있는 클러스터가 있다고 하자. -클러스터에는 여러 애플리케이션을 실행하고 있다. +클러스터에는 여러 애플리케이션을 실행하고 있다. 여러 애플리케이션 중 하나는 `pod-a`, `pod-b`, `pod-c` 로 부르는 3개의 레플리카가 있다. 여기에 `pod-x` 라고 부르는 PDB와 무관한 파드가 보인다. 초기에 파드는 다음과 같이 배치된다. @@ -135,7 +149,8 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-a *available* | pod-b *available* | pod-c *available* | | pod-x *available* | | | -전체 3개 파드는 디플로이먼트의 일부분으로 전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. +전체 3개 파드는 디플로이먼트의 일부분으로 +전체적으로 항상 3개의 파드 중 최소 2개의 파드를 사용할 수 있도록 하는 PDB를 가지고 있다. 예를 들어, 클러스터 관리자가 커널 버그를 수정하기위해 새 커널 버전으로 재부팅하려는 경우를 가정해보자. 클러스터 관리자는 첫째로 `node-1` 을 `kubectl drain` 명령어를 사용해서 비우려 한다. @@ -149,12 +164,12 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | pod-x *terminating* | | | 디플로이먼트는 한 개의 파드가 중지되는 것을 알게되고, `pod-d` 라는 대체 파드를 생성한다. -`node-1` 은 차단되어 있어 다른 노드에 위치한다. +`node-1` 은 차단되어 있어 다른 노드에 위치한다. 무언가가 `pod-x` 의 대체 파드로 `pod-y` 도 생성했다. -(참고: 스테이트풀 셋은 `pod-0`처럼 불릴, `pod-a`를 +(참고: 스테이트풀셋은 `pod-0` 처럼 불릴, `pod-a` 를 교체하기 전에 완전히 중지해야 하며, `pod-0` 로 불리지만, 다른 UID로 생성된다. -그렇지 않으면 이 예시는 스테이트풀 셋에도 적용된다.) +그렇지 않으면 이 예시는 스테이트풀셋에도 적용된다.) 이제 클러스터는 다음과 같은 상태이다. @@ -170,9 +185,9 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 | | pod-b *available* | pod-c *available* | | | pod-d *starting* | pod-y | -이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 -비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, -PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d`가 available 상태가 된다. +이 시점에서 만약 성급한 클러스터 관리자가 `node-2` 또는 `node-3` 을 +비우려고 하는 경우 디플로이먼트에 available 상태의 파드가 2개 뿐이고, +PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된다. 약간의 시간이 지나면 `pod-d` 가 available 상태가 된다. 이제 클러스터는 다음과 같은 상태이다. @@ -182,13 +197,13 @@ PDB에 필요한 최소 파드는 2개이기 때문에 drain 명령이 차단된 | | pod-d *available* | pod-y | 이제 클러스터 관리자는 `node-2` 를 비우려고 한다. -drain 커멘드는 `pod-b`에서 `pod-d`와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. -drain 커멘드는 `pod-b`를 축출하는데 성공했다. -그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 +drain 커멘드는 `pod-b` 에서 `pod-d` 와 같이 어떤 순서대로 두 파드를 축출하려 할 것이다. +drain 커멘드는 `pod-b` 를 축출하는데 성공했다. +그러나 drain 커멘드가 `pod-d` 를 축출하려 하는 경우 디플로이먼트에 available 상태의 파드는 1개로 축출이 거부된다. -디플로이먼트는`pod-b` 를 대체할 `pod-e`라는 파드를 생성한다. -클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 +디플로이먼트는`pod-b` 를 대체할 `pod-e` 라는 파드를 생성한다. +클러스터에 `pod-e` 를 스케줄하기 위한 충분한 리소스가 없기 때문에 드레이닝 명령어는 차단된다. 클러스터는 다음 상태로 끝나게 된다. @@ -200,7 +215,7 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. 이 시점에서 클러스터 관리자는 클러스터에 노드를 추가해서 업그레이드를 진행해야 한다. -쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 +쿠버네티스에 중단이 발생할 수 있는 비율을 어떻게 변화시키는지 다음의 사례를 통해 알 수 있다. - 애플리케이션에 필요한 레플리카의 수 @@ -211,28 +226,29 @@ drain 커멘드는 `pod-b`를 축출하는데 성공했다. ## 클러스터 소유자와 애플리케이션 소유자의 역할 분리 -보통 클러스터 매니저와 애플리케이션 소유자는 +보통 클러스터 매니저와 애플리케이션 소유자는 서로에 대한 지식이 부족한 별도의 역할로 생각하는 것이 유용하다. -이와 같은 책임의 분리는 +이와 같은 책임의 분리는 다음의 시나리오에서 타당할 수 있다. - 쿠버네티스 클러스터를 공유하는 애플리케이션 팀이 많고, 자연스럽게 역할이 나누어진 경우 -- 타사 도구 또는 타사 서비스를 이용해서 클러스터 관리를 자동화 하는 경우 +- 타사 도구 또는 타사 서비스를 이용해서 + 클러스터 관리를 자동화 하는 경우 -Pod Disruption Budgets는 역할 분리에 따라 +Pod Disruption Budget은 역할 분리에 따라 역할에 맞는 인터페이스를 제공한다. 만약 조직에 역할 분리에 따른 책임의 분리가 없다면 -Pod Disruption Budgets를 사용할 필요가 없다. +Pod Disruption Budget을 사용할 필요가 없다. ## 클러스터에서 중단이 발생할 수 있는 작업을 하는 방법 -만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 +만약 클러스터 관리자라면, 그리고 클러스터 전체 노드에 노드 또는 시스템 소프트웨어 업그레이드와 같은 중단이 발생할 수 있는 작업을 수행하는 경우 다음과 같은 옵션을 선택한다. - 업그레이드 하는 동안 다운타임을 허용한다. - 다른 레플리카 클러스터로 장애조치를 한다. - - 다운타임은 없지만, 노드 사본과 + - 다운타임은 없지만, 노드 사본과 전환 작업을 조정하기 위한 인력 비용이 많이 발생할 수 있다. - PDB를 이용해서 애플리케이션의 중단에 견디도록 작성한다. - 다운타임 없음 @@ -251,5 +267,3 @@ Pod Disruption Budgets를 사용할 필요가 없다. * [Pod Disruption Budget 설정하기](/docs/tasks/run-application/configure-pdb/)의 단계를 따라서 애플리케이션을 보호한다. * [노드 비우기](/docs/tasks/administer-cluster/safely-drain-node/)에 대해 자세히 알아보기 - - diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md index 721405614c1e8..1e8a54fff9448 100644 --- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md @@ -9,13 +9,14 @@ weight: 80 {{< feature-state state="alpha" for_k8s_version="v1.16" >}} 이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는 -트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip term_id="pod" >}} 에서 +트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서 임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시 컨테이너를 사용한다. {{< warning >}} -임시 컨테이너는 초기 알파 상태이며, 프로덕션 클러스터에는 -적합하지 않다. [쿠버네티스 사용중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 +임시 컨테이너는 초기 알파 상태이며, +프로덕션 클러스터에는 적합하지 않다. +[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라 이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다. {{< /warning >}} @@ -25,23 +26,23 @@ weight: 80 ## 임시 컨테이너 이해하기 -{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 -기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 +{{< glossary_tooltip text="파드" term_id="pod" >}} 는 쿠버네티스 애플리케이션의 +기본 구성 요소이다. 파드는 일회용이고, 교체 가능한 것으로 의도되었기 때문에, 사용자는 파드가 한번 생성되면, 컨테이너를 추가할 수 없다. -대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 +대신, 사용자는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 를 사용해서 제어하는 방식으로 파드를 삭제하고 교체한다. -그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 -기존 파드의 상태를 검사해야할 수 있다. 이 경우 사용자는 -기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 +그러나 때때로 재현하기 어려운 버그의 문제 해결을 위해 +기존 파드의 상태를 검사해야 할 수 있다. 이 경우 사용자는 +기존 파드에서 임시 컨테이너를 실행해서 상태를 검사하고, 임의의 명령을 실행할 수 있다. ### 임시 컨테이너는 무엇인가? -임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 -다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 -애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 -일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 +임시 컨테이너는 리소스 또는 실행에 대한 보증이 없다는 점에서 +다른 컨테이너와 다르며, 결코 자동으로 재시작되지 않는다. 그래서 +애플리케이션을 만드는데 적합하지 않다. 임시 컨테이너는 +일반 컨테이너와 동일한 `ContainerSpec` 을 사용해서 명시하지만, 많은 필드가 호환되지 않으며 임시 컨테이너에는 허용되지 않는다. - 임시 컨테이너는 포트를 가지지 않을 수 있으므로, `ports`, @@ -60,20 +61,20 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 ## 임시 컨테이너의 사용 임시 컨테이너는 컨테이너가 충돌 되거나 또는 컨테이너 이미지에 -디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 +디버깅 도구가 포함되지 않은 이유로 `kubectl exec` 이 불충분할 때 대화형 문제 해결에 유용하다. 특히, [distroless 이미지](https://github.com/GoogleContainerTools/distroless) -를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 -컨테이너 이미지를 배포할 수 있다. distroless 이미지는 쉘 또는 어떤 디버깅 도구를 -포함하지 않기 때문에, `kubectl exec` 만으로는 distroless +를 사용하면 공격 표면(attack surface)과 버그 및 취약점의 노출을 줄이는 최소한의 +컨테이너 이미지를 배포할 수 있다. distroless 이미지는 셸 또는 어떤 디버깅 도구를 +포함하지 않기 때문에, `kubectl exec` 만으로는 distroless 이미지의 문제 해결이 어렵다. -임시 컨테이너 사용시 [프로세스 네임스페이스 -공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 +임시 컨테이너 사용 시 [프로세스 네임스페이스 +공유](/docs/tasks/configure-pod-container/share-process-namespace/)를 활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다. -임시 컨테이너를 사용해서 문제를 해결하는 예시는 +임시 컨테이너를 사용해서 문제를 해결하는 예시는 [임시 디버깅 컨테이너로 디버깅하기] (/docs/tasks/debug-application-cluster/debug-running-pod/#debugging-with-ephemeral-debug-container)를 참조한다. @@ -81,17 +82,17 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지 {{< note >}} 이 섹션의 예시는 `EphemeralContainers` [기능 -게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 +게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다. {{< /note >}} -이 섹션의 에시는 임시 컨테이너가 어떻게 API에 나타나는지 +이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지 보여준다. 일반적으로 `kubectl alpha debug` 또는 -다른 `kubectl` [플러그인](/docs/tasks/extend-kubectl/kubectl-plugins/)을 +다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을 사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다. -임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 -사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 +임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를 +사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저 `EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다. ```json @@ -187,5 +188,3 @@ Ephemeral Containers: ```shell kubectl attach -it example-pod -c debugger ``` - - diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 0e1f614de342f..d29cc514e35c9 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -27,7 +27,7 @@ weight: 40 * 각 초기화 컨테이너는 다음 초기화 컨테이너가 시작되기 전에 성공적으로 완료되어야 한다. 만약 파드를 위한 초기화 컨테이너가 실패한다면, 쿠버네티스는 초기화 컨테이너가 성공할 때까지 파드를 -반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy`을 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. +반복적으로 재시작한다. 그러나, 만약 파드의 `restartPolicy` 를 절대 하지 않음(Never)으로 설정했다면, 파드는 재시작되지 않는다. 컨테이너를 초기화 컨테이너로 지정하기 위해서는, 파드 스펙에 앱 `containers` 배열과 나란히 `initContainers` 필드를 @@ -63,7 +63,7 @@ weight: 40 * 애플리케이션 이미지 빌더와 디플로이어 역할은 독립적으로 동작될 수 있어서 공동의 단일 앱 이미지 형태로 빌드될 필요가 없다. * 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용한다. - 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 + 결과적으로, 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 {{< glossary_tooltip text="시크릿" term_id="secret" >}}에 접근 권한이 주어질 수 있다. * 앱 컨테이너들은 병렬로 실행되는 반면, 초기화 컨테이너들은 어떠한 앱 컨테이너라도 시작되기 전에 실행 완료되어야 하므로, 초기화 컨테이너는 사전 조건들이 @@ -102,7 +102,7 @@ weight: 40 ### 사용 중인 초기화 컨테이너 쿠버네티스 1.5에 대한 다음의 yaml 파일은 두 개의 초기화 컨테이너를 포함한 간단한 파드에 대한 개요를 보여준다. -첫 번째는 `myservice`를 기다리고 두 번째는 `mydb`를 기다린다. 두 컨테이너들이 +첫 번째는 `myservice` 를 기다리고 두 번째는 `mydb` 를 기다린다. 두 컨테이너들이 완료되면, 파드가 시작될 것이다. ```yaml @@ -190,7 +190,7 @@ kubectl logs myapp-pod -c init-mydb # Inspect the second init container ``` `mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 -`myapp-pod`가 생성된 것을 볼 수 있다. +`myapp-pod` 가 생성된 것을 볼 수 있다. 여기에 이 서비스를 보이기 위해 사용할 수 있는 구성이 있다. @@ -217,7 +217,7 @@ spec: targetPort: 9377 ``` -`mydb`와 `myservice` 서비스 생성하기. +`mydb` 와 `myservice` 서비스 생성하기. ```shell kubectl apply -f services.yaml @@ -227,7 +227,7 @@ service/myservice created service/mydb created ``` -초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Runnning 상태로 +초기화 컨테이너들이 완료되는 것과 `myapp-pod` 파드가 Running 상태로 변경되는 것을 볼 것이다. ```shell @@ -249,13 +249,13 @@ myapp-pod 1/1 Running 0 9m 각 초기화 컨테이너는 다음 컨테이너가 시작되기 전에 성공적으로 종료되어야 한다. 만약 런타임 문제나 실패 상태로 종료되는 문제로인하여 초기화 컨테이너의 시작이 -실패된다면, 초기화 컨테이너는 파드의 `restartPolicy`에 따라서 재시도 된다. 다만, -파드의 `restartPolicy`이 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 -`restartPolicy`을 실패 시(OnFailure)로 사용한다. +실패된다면, 초기화 컨테이너는 파드의 `restartPolicy` 에 따라서 재시도 된다. 다만, +파드의 `restartPolicy` 가 항상(Always)으로 설정된 경우, 해당 초기화 컨테이너는 +`restartPolicy` 를 실패 시(OnFailure)로 사용한다. -파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready`될 수 없다. 초기화 컨테이너의 포트는 +파드는 모든 초기화 컨테이너가 성공되기 전까지 `Ready` 될 수 없다. 초기화 컨테이너의 포트는 서비스 하에 합쳐지지 않는다. 초기화 중인 파드는 `Pending` 상태이지만 -`Initialized`이 참이 되는 조건을 가져야 한다. +`Initialized` 가 참이 되는 조건을 가져야 한다. 만약 파드가 [재시작](#파드-재시작-이유)되었다면, 모든 초기화 컨테이너는 반드시 다시 실행된다. @@ -264,15 +264,16 @@ myapp-pod 1/1 Running 0 9m 초기화 컨테이너 이미지 필드를 변경하는 것은 파드를 재시작하는 것과 같다. 초기화 컨테이너는 재시작되거나, 재시도, 또는 재실행 될 수 있기 때문에, 초기화 컨테이너 -코드는 멱등성(indempotent)을 유지해야 한다. 특히, `EmptyDirs`에 있는 파일에 쓰기를 수행하는 코드는 +코드는 멱등성(idempotent)을 유지해야 한다. 특히, `EmptyDirs` 에 있는 파일에 쓰기를 수행하는 코드는 출력 파일이 이미 존재할 가능성에 대비해야 한다. 초기화 컨테이너는 앱 컨테이너의 필드를 모두 가지고 있다. 그러나, 쿠버네티스는 -`readinessProbe`가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 +`readinessProbe` 가 사용되는 것을 금지한다. 초기화 컨테이너가 완료 상태와 준비성을 구분해서 정의할 수 없기 때문이다. 이것은 유효성 검사 중에 시행된다. -초기화 컨테이너들이 실패를 영원히 지속하는 상황을 방지하기 위해서 -파드의 `activeDeadlineSeconds`와 컨테이너의 `livenessProbe`를 사용한다. +초기화 컨테이너들이 실패를 +영원히 지속하는 상황을 방지하기 위해서 +파드의 `activeDeadlineSeconds` 와 컨테이너의 `livenessProbe` 를 사용한다. 파드 내의 각 앱과 초기화 컨테이너의 이름은 유일해야 한다. 어떤 컨테이너가 다른 컨테이너와 같은 이름을 공유하는 경우 유효성 오류가 발생한다. @@ -310,7 +311,7 @@ myapp-pod 1/1 Running 0 9m 이미지의 변경은 앱 컨테이너만 재시작시킨다. * 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. -* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy`이 항상으로 설정되어 있는, +* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는, 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실되었다. @@ -320,7 +321,5 @@ myapp-pod 1/1 Running 0 9m ## {{% heading "whatsnext" %}} -* [초기화 컨테이너를 가진 파드 생성하기](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) +* [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 - - diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index e8e384a4ababd..18f4b3e813fab 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -114,9 +114,9 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 지원하지 않는다면, 기본 상태는 `Success`이다. * `startupProbe`: 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. - 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 + 스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, - 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 + 컨테이너는 [재시작 정책](#재시작-정책)에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 `Success`이다. ### 언제 활성 프로브를 사용해야 하는가? @@ -193,8 +193,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 ... ``` -* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. - 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. +* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. ```yaml ... @@ -212,7 +211,7 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 애플리케이션은 추가 피드백 또는 신호를 PodStatus: _Pod readiness_ 와 같이 주입할 수 있다. 이를 사용하기 위해, 파드의 준비성을 평가하기 -위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. +위한 추가적인 조건들을 `PodSpec` 내의 `ReadinessGate` 필드를 통해서 지정할 수 있다. 준비성 게이트는 파드에 대한 `status.condition` 필드의 현재 상태에 따라 결정된다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 @@ -261,6 +260,9 @@ status: * 파드 내의 모든 컨테이너들이 준비 상태이다. * `ReadinessGates`에 지정된 모든 조건들이 `True` 이다. +파드의 컨테이너가 Ready 이나 적어도 한 개의 사용자 지정 조건이 빠졌거나 `False` 이면, +Kubelet은 파드의 상태를 `ContainerReady`로 설정한다. + ## 재시작 정책 PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 5b2af22d7323d..bf52e77c2a3e1 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -26,6 +26,7 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. + 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(더 많은 인스턴스를 실행해서 더 많은 전체 리소스를 제공하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 일반적으로 워크로드 리소스와 해당 {{< glossary_tooltip text="_컨트롤러_" term_id="controller" >}}에 의해 그룹으로 생성과 관리된다. 쿠버네티스가 컨트롤러를 사용해서 워크로드의 확장과 복구를 구현하는 방법에 대한 자세한 내용은 [파드와 컨트롤러](#파드와-컨트롤러)를 참고한다. @@ -48,7 +49,7 @@ card: #### 저장소 -파드는 공유 저장소 집합인 {{< glossary_tooltip text="Volumes" term_id="volume" >}} 을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)를 참고하길 바란다. +파드는 공유 저장소 집합인 {{< glossary_tooltip text="볼륨" term_id="volume" >}}을 명시할 수 있다. 파드 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 파드 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 파드 안의 공유 저장소를 사용하는지 보려면 [볼륨](/ko/docs/concepts/storage/volumes/)을 참고하길 바란다. ## 파드 작업 @@ -64,13 +65,16 @@ card: 워크로드 리소스를 사용해서 여러 파드를 생성하고 관리할 수 있다. 리소스 컨트롤러는 파드 장애 발생 시 복제, 롤아웃, 자동 복구를 처리한다. 예를 들어, 노드에 장애가 발생하면, 컨트롤러는 해당 노드의 파드는 작동을 멈추고 교체용 파드를 생성한다는 것을 알게 된다. 스케줄러는 교체용 파드를 정상적인 노드에 배치하게 된다. +다음은 하나 이상의 파드를 관리하는 워크로드 리소스의 예이다. + * {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} * {{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}} * {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}} + ## 파드 템플릿 -워크로드 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 +{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스에 대한 컨트롤러는 파드 템플릿으로 파드를 생성하고 사용자를 대신해서 이러한 파드를 관리한다. 파드템플릿은 파드를 생성하기 위한 명세이며 @@ -87,6 +91,7 @@ apiVersion: batch/v1 kind: Job metadata: name: hello +spec: template: # 이것이 파드 템플릿이다. spec: @@ -113,4 +118,3 @@ metadata: * 파드의 동작에 대해 더 알아보자. * [파드 종료](/ko/docs/concepts/workloads/pods/pod/#파드의-종료) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) - 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 d7cc7d545ba52..f1f586f5d8405 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 @@ -18,10 +18,10 @@ weight: 50 ### 기능 게이트 활성화 -를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** -{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 -대해 `EvenPodsSpread` -[기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어야 한다. +를 참조한다. {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} **와** +{{< glossary_tooltip text="스케줄러" term_id="kube-scheduler" >}}에 대해 +`EvenPodsSpread` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어야 한다. ### 노드 레이블 @@ -160,6 +160,7 @@ spec: - 신규 파드와 같은 네임스페이스를 갖는 파드만이 매칭의 후보가 된다. - `topologySpreadConstraints[*].topologyKey` 가 없는 노드는 무시된다. 이것은 다음을 의미한다. + 1. 이러한 노드에 위치한 파드는 "maxSkew" 계산에 영향을 미치지 않는다. - 위의 예시에서, "node1"은 "zone" 레이블을 가지고 있지 않다고 가정하면, 파드 2개는 무시될 것이고, 이런 이유로 신규 파드는 "zoneA"로 스케줄된다. 2. 신규 파드는 이런 종류의 노드에 스케줄 될 기회가 없다. - 위의 예시에서, 레이블로 `{zone-typo: zoneC}` 를 가지는 "node5"가 클러스터에 편입한다고 가정하면, 레이블 키에 "zone"이 없기 때문에 무시하게 된다. @@ -191,13 +192,13 @@ spec: 토폴로지 분배 제약 조건은 다음과 같은 경우에만 파드에 적용된다. - `.spec.topologySpreadConstraints` 에는 어떠한 제약도 정의되어 있지 않는 경우. -- 서비스, 레플리케이션 컨트롤러, 레플리카 셋 또는 스테이트풀 셋에 속해있는 경우. +- 서비스, 레플리케이션컨트롤러(ReplicationController), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)에 속해있는 경우. 기본 제약 조건은 [스케줄링 프로파일](/docs/reference/scheduling/profiles)에서 `PodTopologySpread` 플러그인의 일부로 설정할 수 있다. 제약 조건은 `labelSelector` 가 비어 있어야 한다는 점을 제외하고, [위와 동일한 API](#api)로 제약 조건을 지정한다. 셀렉터는 파드가 속한 서비스, 레플리케이션 컨트롤러, -레플리카 셋 또는 스테이트풀 셋에서 계산한다. +레플리카 셋 또는 스테이트풀셋에서 계산한다. 예시 구성은 다음과 같다. @@ -226,17 +227,16 @@ profiles: ## 파드어피니티(PodAffinity)/파드안티어피니티(PodAntiAffinity)와의 비교 쿠버네티스에서 "어피니티(Affinity)"와 관련된 지침은 파드가 -더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. +더 많이 채워지거나 더 많이 분산되는 방식으로 스케줄 되는 방법을 제어한다. - `PodAffinity` 는, 사용자가 자격이 충족되는 토폴로지 도메인에 원하는 수의 파드를 얼마든지 채울 수 있다. - `PodAntiAffinity` 로는, 단일 토폴로지 도메인에 단 하나의 파드만 스케줄 될 수 있다. -"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 -고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 -레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. -더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/blob/master/keps/sig-scheduling/20190221-pod-topology-spread.md#motivation)를 참조한다. +"EvenPodsSpread" 기능은 다양한 토폴로지 도메인에 파드를 균등하게 분배해서 +고 가용성 또는 비용 절감을 달성할 수 있는 유연한 옵션을 제공한다. 또한 워크로드의 롤링 업데이트와 레플리카의 원활한 스케일링 아웃에 도움이 될 수 있다. +더 자세한 내용은 [모티베이션(Motivation)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/895-pod-topology-spread#motivation)를 참조한다. ## 알려진 제한사항 diff --git a/content/ko/docs/concepts/workloads/pods/pod.md b/content/ko/docs/concepts/workloads/pods/pod.md index 9f7d06d09139e..05de1ccb61c34 100644 --- a/content/ko/docs/concepts/workloads/pods/pod.md +++ b/content/ko/docs/concepts/workloads/pods/pod.md @@ -5,15 +5,21 @@ weight: 20 --- -_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 배포 가능한 최소 컴퓨팅 단위이다. + +_파드_ 는 쿠버네티스에서 생성되고 관리될 수 있는 +배포 가능한 최소 컴퓨팅 단위이다. + ## 파드는 무엇인가? -_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) 컨테이너 그룹이다. -이 그룹은 스토리지/네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. + +_파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) 하나 이상의(도커 컨테이너 같은) +{{< glossary_tooltip text="컨테이너" term_id="container" >}} 그룹이다. +이 그룹은 스토리지/네트워크를 공유하고, +해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠들은 항상 함께 배치되고 같이 스케줄되며, 공유 컨텍스트 내에서 구동된다. 파드는 애플리케이션에 특화된 "논리 호스트"를 모델로 하고 있다. 이것은 하나 또는 강하게 서로 결합되어 있는 여러 애플리케이션 컨테이너를 포함한다. @@ -47,9 +53,10 @@ _파드_ 는 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지 개별 애플리케이션 컨테이너와 같이, 파드는 상대적으로 수명이 짧은 엔터티로 간주된다. [파드의 생애](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에서 논의된 것과 같이, 파드가 만들어지고 고유한 ID(UID)가 할당되고, -재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. +재시작 정책에 따라서 종료 또는 삭제될 때 까지 노드에 스케줄된다. 노드가 종료되면 해당 노드로 스케줄 된 파드는 제한시간이 지나면 삭제되도록 스케줄된다. -해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. 대신, 동일한 파드로, +해당 파드(UID로 정의된)는 새로운 노드에 "리스케줄(reschedule)" 되지 않는다. +대신, 동일한 파드로, 원한다면 이름도 동일하게, 교체될 수 있지만, 새로운 UID가 부여된다. 더 자세한 내용은 [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 참조한다. @@ -59,6 +66,7 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 동일한 대체품이 만들어 지더라도 관련된 것(예 : 볼륨) 또한 삭제되고 새로 만들어진다. {{< figure src="/images/docs/pod.svg" title="파드 다이어그램" width="50%" >}} + *파일 풀러(Puller)와 컨테이너 간 공유 스토리지로 퍼시스턴트 볼륨을 사용하는 웹 서버를 포함하는 멀티 컨테이너 파드.* @@ -70,7 +78,8 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드는 그 구성 요소 집합보다 높은 수준의 추상화를 제공함으로써 애플리케이션 배포 및 관리를 단순화한다. 파드는 전개 단위, 수평 확장 및 복제를 한다. -공동 스케줄링, 공유 된 생애주기 (예 : 종료), 조정 된 복제, 자원 공유 및 종속성 관리는 +공동 스케줄링, +공유된 생애주기(예: 종료), 조정된 복제, 자원 공유 및 종속성 관리는 파드의 컨테이너에 대해 자동으로 처리된다. ### 리소스 공유 및 통신 @@ -80,10 +89,12 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 파드의 모든 애플리케이션은 동일한 네트워크 네임스페이스(동일한 IP 및 포트 공간)를 사용하므로 서로를 찾고 통신하는데 `localhost`를 사용할 수 있다. 이 때문에 파드의 애플리케이션은 포트 사용을 조정 해야한다. -각 파드에는 다른 물리적 컴퓨터 및 파드들과 네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. +각 파드에는 다른 물리적 컴퓨터 및 파드들과 +네트워크를 통해 통신할 수 있는 공유 네트워크 공간의 IP 주소가 있다. 호스트 이름은 파드 안에있는 애플리케이션 컨테이너의 파드 이름으로 설정된다. -더 자세한 내용은 [네트워킹의 더 자세한 내용](/docs/concepts/cluster-administration/networking/)을 참조한다. +더 자세한 내용은 +[네트워킹](/ko/docs/concepts/cluster-administration/networking/) 섹션을 참조한다. 파드는 파드 안의 애플리케이션 컨테이너를 정의하는 것 이외에도 공유 저장 볼륨의 집합을 지정한다. 볼륨은 컨테이너가 재시작되어도 데이터가 생존할 수 있도록 하고, @@ -104,14 +115,17 @@ UID를 포함한 해당 파드가 존재하는 한 그것도 존재한다는 것 일반적으로 하나의 파드는 동일한 애플리케이션의 여러 인스턴스를 실행하도록 사용하지 않는다. -더 자세한 설명을 보려면 [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴] (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 참조한다. +더 자세한 설명을 보려면 +[분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)을 +참조한다. ## 고려된 대안 _싱글 (도커)컨테이너에서 다중 프로그램을 실행하지 않는 이유는 무엇인가?_ 1. 투명도. 인프라에 파드 내의 컨테이너를 표시하면, - 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 제공할 수 있다. + 인프라에서 프로세스 관리와 리소스 모니터링과 같은 기능을 + 제공할 수 있다. 이 기능들은 사용자에게 편의를 제공한다. 1. 소프트웨어 의존성 분리. 각각의 컨테이너는 독립적으로 버전 관리, 재빌드, 재배포될 수 있다. @@ -129,19 +143,18 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 ## 파드의 내구성 (또는 결핍) -파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, -노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. +파드는 내구성이 강한 엔터티로 취급하지는 않는다. 파드는 스케줄링 실패, 노드 장애 또는 그 밖에 리소스가 부족해서, 또는 노드 정비를 위한 경우와 같이 축출(eviction)되는 상황에서는 살아남을 수 없을 것이다. 일반적으로 사용자는 파드를 직접 만들 필요가 없다. -싱글톤이라도 대부분 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. +싱글톤이라도 대부분 [디플로이먼트(Deployment)](/ko/docs/concepts/workloads/controllers/deployment/)와 같은 컨트롤러를 사용한다. 컨트롤러는 클러스터 범위에서 복제와 롤아웃 관리 뿐 만 아니라 자가치료 기능도 제공한다. -[StatefulSet](/ko/docs/concepts/workloads/controllers/statefulset.md)과 같은 컨트롤러는 상태를 저장하는 파드에도 +[스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)과 같은 +컨트롤러는 상태를 저장하는 파드에도 위와 같은 기능 제공을 할 수 있다. 사용자 지향적으로 선정된 API를 사용하는 것은 [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema)와 [Tupperware](https://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997)를 비롯한 클러스터 스케줄링 시스템에서 비교적 일반적이다. - 파드는 아래와 같은 사항들을 용이하게 하기 위해 노출이 된다: * 스케줄러 및 컨트롤러 연결 가능 @@ -149,58 +162,45 @@ _컨테이너의 어피니티(affinity) 기반 공동 스케줄링을 지원하 * 부트스트랩과 같이 컨트롤러의 생애와 파드의 생애 분리 * 컨트롤러와 서비스의 분리 — 파드를 감시하는 엔드 포인트 컨트롤러 * 클러스터 레벨과 kubelet 레벨 기능의 깔끔한 구성 — Kubelet은 효과적인 "파드 컨트롤러" 이다. -* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, -삭제 전에는 확실히 교체되는 고가용성 애플리케이션. +* 계획된 삭제 또는 이미지 프리페칭과 같이 파드가 종료되기 전에 교체가 될 것이고, 삭제 전에는 확실히 교체되는 고가용성 애플리케이션. ## 파드의 종료 -파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로 이러한 프로세스가 더 이상 필요하지 않을 때 (KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. -사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐 만 아니라, 삭제가 결국 완료되는 것을 확인 할 수 있어야 한다. -사용자가 파드를 삭제하도록 요청하면 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고 TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. -유예 기간이 만료되면 KILL 신호가 해당 프로세스로 전송되고 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면 종료가 전체 유예 기간과 함께 재시도된다. +파드는 클러스터의 노드에서 실행 중인 프로세스를 나타내므로, 이러한 프로세스가 더 이상 필요하지 않을 때(KILL 시그널로 강제로 죽여서 정리할 기회를 주지 않는 것과 대조적으로) 정상적으로 종료 되도록 허용하는 것이 중요하다. 사용자는 삭제를 요청할 수 있어야 하며, 프로세스가 종료 될 때 알 수 있어야 할 뿐만 아니라, 삭제가 결국 완료되는 것을 확인할 수 있어야 한다. 사용자가 파드를 삭제하도록 요청하면, 시스템은 파드가 강제로 종료되기 전에 예정된 유예 기간을 기록하고, TERM 시그널이 각 컨테이너의 주 프로세스로 전송된다. 유예 기간이 만료되면, KILL 신호가 해당 프로세스로 전송되고, 파드가 API 서버에서 삭제된다. 프로세스가 종료되기를 기다리는 동안 Kubelet 또는 컨테이너 관리자가 다시 시작되면, 종료가 전체 유예 기간과 함께 재시도된다. 흐름 예시: 1. 사용자가 파드 삭제 명령을 내린다. (기본 유예 기간 30초) -1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은 것(죽은)것으로 간주되는 파드가 업데이트 된다. +1. API 서버 안의 파드는 유예 기간에 따라, 시간을 넘은(죽은) 것으로 간주되는 파드가 업데이트된다. 1. 클라이언트 명령에서 파드는 "Terminating" 이라는 문구를 나타낸다. 1. (3번 단계와 동시에) Kubelet은 파드가 2번 단계에서 설정된 시간으로 인해 Terminating으로 표시되는 것을 확인하면 파드 종료 단계를 시작한다. 1. 파드의 컨테이너 중 하나에 [preStop hook](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)이 정의된 경우, 해당 컨테이너 내부에서 실행된다. 유예 기간이 만료된 후에도 `preStop` 훅이 계속 실행 중이면, 유예 기간을 짧게(2초)를 1회 연장해서 2번 단계를 실행한다. 1. 파드의 프로세스에 TERM 시그널이 전달된다. 파드의 모든 컨테이너가 TERM 시그널을 동시에 받기 때문에 컨테이너의 종료 순서가 중요한 경우에는 `preStop` 훅이 각각 필요할 수 있음을 알아두자. 만약 `preStop` 훅을 완료하는 데 더 오랜 시간이 필요한 경우 `terminationGracePeriodSeconds` 를 수정해야 한다. -1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행중인 파드로 고려하지 않는다. -느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. +1. (3번 단계와 동시에) 파드는 서비스를 위해 엔드포인트 목록에서 제거되며, 더 이상 레플리케이션 컨트롤러가 실행 중인 파드로 고려하지 않는다. 느리게 종료되는 파드는 로드밸런서(서비스 프록시와 같은)의 로테이션에서 지워지기 때문에 트래픽을 계속 처리할 수 없다. 1. 유예 기간이 만료되면, 파드에서 실행중이던 모든 프로세스가 SIGKILL로 종료된다. 1. Kubelet은 유예기간 0(즉시 삭제)을 세팅하여 API 서버에서 파드 삭제를 끝낼 것이다. API 서버에서 사라진 파드는 클라이언트에게서 더 이상 보이지 않는다. -기본적으로 모든 삭제는 30초 이내에 끝이난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드 하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0`값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). kubectl 버전 >= 1.5 에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0`와 함께 추가 플래그인 `--force`를 지정해야 한다. +기본적으로 모든 삭제는 30초 이내에 끝이 난다. `kubectl delete` 명령은 사용자가 기본 설정을 오버라이드하고 자신이 원하는 값을 설정할 수 있게 해주는 `--grace-period=` 옵션을 지원한다. `0` 값은 파드를 [강제로 삭제한다](/ko/docs/concepts/workloads/pods/pod/#파드-강제-삭제). +kubectl 1.5 버전 이상에서는, 강제 삭제 수행을 위해서 반드시 `--grace-period=0` 와 함께 추가 플래그인 `--force` 를 지정해야 한다. ### 파드 강제 삭제 -파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. -API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. -노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. - -강제 삭제는 일부 파드의 경우 잠재적으로 위험 할 수 있으므로 주의해서 수행해야 한다. -스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업문서를 참조한다. +파드 강제 삭제는 클러스터 및 etcd에서 즉시 삭제하는 것으로 정의된다. 강제 삭제가 수행되면, API 서버는 kubelet에서 실행 중이던 노드에서 파드가 종료되었다는 확인을 기다리지 않는다. API에서 파드를 즉시 제거하므로 동일한 이름으로 새 파드를 만들 수 있다. 노드에서 즉시 종결되도록 설정된 파드에는 강제 삭제되기 전에 짧은 유예 기간이 주어진다. +강제 삭제는 일부 파드의 경우 잠재적으로 위험할 수 있으므로 주의해서 수행해야 한다. 스테이트풀셋 파드의 경우 [스테이트풀셋 파드 삭제](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대한 작업 문서를 참조한다. ## 파드 컨테이너의 특권(Privileged) 모드 -Kubernetes v1.1부터, 파드의 모든 컨테이너는 컨테이너 스펙의 `SecurityContext`의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 Linux 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일 할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. - -마스터가 Kubernetes v1.1 이상에서 실행 중이고, 노드가 v1.1 보다 낮은 버전을 실행중인 경우 새 권한이 부여 된 파드는 api-server에 의해 승인되지만 시작되지는 않는다. 이것들은 pending 상태가 될 것이다. -사용자가 `kubectl describe pod FooPodName` 을 호출하면 사용자는 파드가 pending 상태에 있는 이유를 볼 수 있다. describe 명령 출력의 이벤트 테이블은 다음과 같다. -`Error validating pod "FooPodName"."FooPodNamespace" from api, ignoring: spec.containers[0].securityContext.privileged: forbidden '<*>(0xc2089d3248)true'` +파드의 모든 컨테이너는 컨테이너 스펙의 [시큐리티 콘텍스트(security context)](/docs/tasks/configure-pod-container/security-context/)의 `privileged` 플래그를 사용하여 특권 모드를 사용할 수 있다. 이것은 네트워크 스택을 조작하고 장치에 액세스하는 것과 같은 리눅스 기능을 사용하려는 컨테이너에 유용하다. 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스에서 사용할 수 있는 거의 동일한 권한을 갖는다. 특권 모드를 사용하면 네트워크 및 볼륨 플러그인을 kubelet에 컴파일할 필요가 없는 별도의 파드로 쉽게 만들 수 있다. -마스터가 v1.1보다 낮은 버전에서 실행중인 경우 특권을 갖는 파드를 만들 수 없다. 유저가 특권을 갖는 컨테이너가 있는 파드를 만들려고 하면 다음과 같은 오류가 발생한다. -`The Pod "FooPodName" is invalid. -spec.containers[0].securityContext.privileged: forbidden '<*>(0xc20b222db0)true'` +{{< note >}} +이와 같은 설정을 위해서는 컨테이너 런타임에서 반드시 특권 컨테이너 개념을 지원해야 한다. +{{< /note >}} ## API 오브젝트 -파드는 쿠버네티스 REST API에서 최상위 리소스이다. API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: +파드는 쿠버네티스 REST API에서 최상위 리소스이다. +API 오브젝트에 더 자세한 정보는 아래 내용을 참조한다: [파드 API 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core). 파드 오브젝트에 대한 매니페스트를 생성할때는 지정된 이름이 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름들)인지 확인해야 한다. - - +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다. diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 4b37e0c2327ef..9793dbc52ea55 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -1,4 +1,6 @@ --- + + title: 파드 프리셋 content_type: concept weight: 50 @@ -25,6 +27,7 @@ weight: 50 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다. + ## 클러스터에서 파드프리셋 활성화하기 {#enable-pod-preset} 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 9dd0b23cd38d5..8f9ef72ba6c89 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -47,8 +47,8 @@ card: - [kubernetes/website에 기여하기](https://github.com/kubernetes/website/contribute)를 참조하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. - 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/docs/contribute/new-content/new-content/#changes-using-github) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/docs/contribute/review/reviewing-prs/)를 합니다. -- 쿠버네티스 [컨텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. -- [페이지 템플릿 사용](/docs/contribute/style/page-templates/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. +- 쿠버네티스 [콘텐츠](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽고 정보에 대한 코멘트를 남길 수 있습니다. +- [페이지 템플릿 사용](/docs/contribute/style/page-content-types/)과 [휴고(Hugo) 단축코드(shortcodes)](/docs/contribute/style/hugo-shortcodes/)를 사용해서 큰 변경을 하는 방법에 대해 배워봅니다. ## 다음 단계 @@ -67,12 +67,10 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. 자신을 소개하세요! - 더 광범위한 토론이 이루어지고 공식적인 결정이 기록이 되는 [`kubernetes-sig-docs` 메일링 리스트에 가입](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 하세요. -- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoon) 클라이언트](https://zoom.us/download)를 다운로드 하거나 전화를 이용하여 전화 접속해야 합니다. +- [주간 SIG Docs 화상 회의](https://github.com/kubernetes/community/tree/master/sig-docs)에 참여하세요. 회의는 항상 `#sig-docs` 에 발표되며 [쿠버네티스 커뮤니티 회의 일정](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)에 추가됩니다. [줌(Zoom) 클라이언트](https://zoom.us/download)를 다운로드하거나 전화를 이용하여 전화 접속해야 합니다. ## 다른 기여 방법들 - [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. - - diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index dc5c8ec28d26c..f6e0ae13b7b44 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -132,21 +132,29 @@ weight: 10 ### API 오브젝트 용어 한글화 방침 -API 오브젝트 중 `kubectl api-resources` 결과의 `kind`에 해당하는 오브젝트는 +일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는 [국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에 -따라 한글 표기한다. 예를 들면 다음과 같다. +따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다. + +API 오브젝트(kind) | 한글화(외래어 표기 및 영문 병기) +--- | --- +ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) +ConfigMap | 컨피그맵(ConfigMap) +Deployment | 디플로이먼트(Deployment) +PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) +... | ... + +`kind` 에 속하는 API 오브젝트 중에서도 일부는 표현의 간결함을 위해 한영병기를 하지 않는 등의 예외가 있으며, +예외에 대해서는 [한글화 용어집](#한글화-용어집)에 등록된 방식을 준용한다. 예를 들면 다음과 같다. API 오브젝트(kind) | 한글화(외래어 표기) --- | --- -ClusterRoleBinding | 클러스터롤바인딩 -ConfigMap | 컨피그맵 -Deployment | 디플로이먼트 Pod | 파드 -PersistentVolumeClaim | 퍼시스턴트볼륨클레임 Service | 서비스 ... | ... -그 이외의 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고, + +`kind` 에 속하지 않는 API 오브젝트는, [한글화 용어집](#한글화-용어집)에 등록된 용어인 경우를 제외하고, 모두 원문 그대로 표기한다. 예를 들면 다음과 같다. API 오브젝트(kind가 아닌 경우) | 한글화(원문 유지) @@ -162,7 +170,7 @@ PersistentVolumeClaimSpec | PersistentVolumeClaimSpec {{% note %}} 단, API 오브젝트 한글화 원칙에 예외가 있을 수 있으며, 이 경우에는 가능한 [한글화 용어집](#한글화-용어집)을 준용한다. (예를 들면, Horizontal Pod Autoscaler -는 API 오브젝트에 대해 외래어 표기법 적용하지 않고 원문 그대로 표기한다.) +는 API 오브젝트에 대해 외래어 표기법을 적용하지 않고 원문 그대로 표기한다.) {{% /note %}} {{% note %}} @@ -239,6 +247,7 @@ Age | 기간 | Allocation | 할당량 | alphanumeric | 영숫자 | Annotation | 어노테이션 | +APIService | API서비스(APIService) | API 오브젝트인 경우 App | 앱 | Appendix | 부록 | Application | 애플리케이션 | @@ -248,6 +257,7 @@ autoscaler | 오토스케일러 | availability zone | 가용성 영역(availability zone) | bare pod | 베어(bare) 파드 | beta | 베타 | +Binding | 바인딩(Binding) | API 오브젝트인 경우 boilerplate | 상용구 | Boot | 부트 | Build | 빌드 | @@ -255,31 +265,37 @@ Cache | 캐시 | Calico | 캘리코(Calico) | canary | 카나리(canary) | 릴리스 방식에 관련한 용어인 경우에 한함 cascading | 캐스케이딩(cascading) | +CertificateSigningRequest | CertificateSigningRequest | API 오브젝트인 경우 character set | 캐릭터 셋 | Charts | 차트 | checkpoint | 체크포인트 | Cilium | 실리움(Cilium) | CLI | CLI | Cluster | 클러스터 | +ClusterRole | 클러스터롤(ClusterRole) | API 오브젝트인 경우 +ClusterRoleBinding | 클러스터롤바인딩(ClusterRoleBinding) | API 오브젝트인 경우 Command Line Tool | 커맨드라인 툴 | -Config Map | 컨피그 맵 | +ComponentStatus | 컴포넌트스테이터스(ComponentStatus) | API 오브젝트인 경우 +ConfigMap | 컨피그맵(ConfigMap) | API 오브젝트인 경우 configuration | 구성, 설정 | Connection | 연결 | containerized | 컨테이너화 된 | Context | 컨텍스트 | Control Plane | 컨트롤 플레인 | controller | 컨트롤러 | -Cron Job | 크론 잡 | +ControllerRevision | 컨트롤러리비전(ControllerRevision) | API 오브젝트인 경우 +cron job | 크론 잡 | +CronJob | 크론잡(CronJob) | API 오브젝트인 경우 +CSIDriver | CSI드라이버(CSIDriver) | API 오브젝트인 경우 +CSINode | CSI노드(CSINode) | API 오브젝트인 경우 custom metrics | 사용자 정의 메트릭 | -Custom resource | 사용자 정의 리소스 | -CustomResourceDefinition | 커스텀 리소스 데피니션 | +custom resource | 사용자 정의 리소스 | +CustomResourceDefinition | 커스텀리소스데피니션(CustomResourceDefinition) | API 오브젝트인 경우 Daemon | 데몬 | -Daemon Set | 데몬 셋 | +DaemonSet | 데몬셋(DaemonSet) | API 오브젝트인 경우 Dashboard | 대시보드 | Data Plane | 데이터 플레인 | -Default Limit | 기본 상한 | -Default Request | 기본 요청량 | -Deployment | 디플로이먼트 | +Deployment | 디플로이먼트(Deployment) | API 오브젝트인 경우 deprecated | 사용 중단(deprecated) | descriptor | 디스크립터, 식별자 | Desired number of pods | 의도한 파드의 수 | @@ -292,9 +308,11 @@ Docker Swarm | Docker Swarm | Downward API | 다운워드(Downward) API | draining | 드레이닝(draining) | egress | 이그레스, 송신(egress) | -Endpoint | 엔드포인트 | +endpoint | 엔드포인트 | +EndpointSlice | 엔드포인트슬라이스(EndpointSlice) | API 오브젝트인 경우 +Endpoints | 엔드포인트(Endpoints) | API 오브젝트인 경우 entry point | 진입점 | -Event | 이벤트 | +Event | 이벤트(Event) | API 오브젝트인 경우 evict | 축출하다 | eviction | 축출 | Exec | Exec | @@ -321,27 +339,31 @@ Hypervisor | 하이퍼바이저 | idempotent | 멱등성 | Image | 이미지 | Image Pull Secrets | 이미지 풀(Pull) 시크릿 | -Ingress | 인그레스 | +Ingress | 인그레스(Ingress) | API 오브젝트인 경우 +IngressClass | 인그레스클래스(IngressClass) | API 오브젝트인 경우 Init Container | 초기화 컨테이너 | Instance group | 인스턴스 그룹 | introspection | 인트로스펙션(introspection) | Istio | 이스티오(Istio) | -Job | 잡 | +Job | 잡(Job) | API 오브젝트인 경우 kube-proxy | kube-proxy | Kubelet | Kubelet | Kubernetes | 쿠버네티스 | Kube-router | Kube-router | label | 레이블 | +Lease | 리스(Lease) | API 오브젝트인 경우 lifecycle | 라이프사이클 | +LimitRange | 리밋레인지(LimitRange) | API 오브젝트인 경우 +limit | 한도(limit) | 리소스의 개수나 용량을 한정하기 위한 수치로 사용된 경우 선택적으로 사용 (API 오브젝트의 속성으로 limit을 사용한 경우는 가능한 영문 유지) Linux | 리눅스 | load | 부하 | +LocalSubjectAccessReview | 로컬서브젝트액세스리뷰(LocalSubjectAccessReview) | API 오브젝트인 경우 Log | 로그 | loopback | 루프백(loopback) | Lost | Lost | 클레임의 상태에 한함 Machine | 머신 | manifest | 매니페스트 | Master | 마스터 | -max limit/request ratio | 최대 상한/요청량 비율 | metadata | 메타데이터 | metric | 메트릭 | masquerading | 마스커레이딩 | @@ -349,11 +371,12 @@ Minikube | Minikube | Mirror pod | 미러 파드(mirror pod) | monitoring | 모니터링 | multihomed | 멀티홈드(multihomed) | +MutatingWebhookConfiguration | MutatingWebhookConfiguration | API 오브젝트인 경우 naked pod | 네이키드(naked) 파드 | -Namespace | 네임스페이스 | +Namespace | 네임스페이스(Namespace) | API 오브젝트인 경우 netfilter | 넷필터(netfilter) | -Network Policy | 네트워크 폴리시 | -Node | 노드 | +NetworkPolicy | 네트워크폴리시(NetworkPolicy) | API 오브젝트인 경우 +Node | 노드(Node) | API 오브젝트인 경우 node lease | 노드 리스(lease) Object | 오브젝트 | Orchestrate | 오케스트레이션하다 | @@ -361,16 +384,19 @@ Output | 출력 | parameter | 파라미터 | patch | 패치 | Pending | Pending | 파드, 클레임의 상태에 한함 -Persistent Volume | 퍼시스턴트 볼륨 | -Persistent Volume Claim | 퍼시스턴트 볼륨 클레임 | +PersistentVolume | 퍼시스턴트볼륨(PersistentVolume) | API 오브젝트인 경우 +PersistentVolumeClaim | 퍼시스턴트볼륨클레임(PersistentVolumeClaim) | API 오브젝트인 경우 pipeline | 파이프라인 | placeholder pod | 플레이스홀더(placeholder) 파드 | -Pod | 파드 | +Pod | 파드 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 Pod Preset | 파드 프리셋 | PodAntiAffinity | 파드안티어피니티(PodAntiAffinity) | -PodDisruptionBudget | PodDisruptionBudget | +PodDisruptionBudget | PodDisruptionBudget | API 오브젝트인 경우 +PodSecurityPolicy | 파드시큐리티폴리시(PodSecurityPolicy) | API 오브젝트인 경우 +PodTemplate | 파드템플릿(PodTemplate) | API 오브젝트인 경우 postfix | 접미사 | prefix | 접두사 | +PriorityClass | 프라이어리티클래스(PriorityClass) | API 오브젝트인 경우 Privileged | 특권을 가진(privileged) | Prometheus | 프로메테우스 | proof of concept | 개념 증명 | @@ -386,29 +412,33 @@ redirect | 리다이렉트(redirect) | redirection | 리다이렉션 | Registry | 레지스트리 | Release | 릴리스 | -Replica Set | 레플리카 셋 | +ReplicaSet | 레플리카셋(ReplicaSet) | API 오브젝트인 경우 replicas | 레플리카 | -Replication Controller | 레플리케이션 컨트롤러 | +ReplicationController | 레플리케이션컨트롤러(ReplicationController) | API 오브젝트인 경우 repository | 리포지터리 | +request | 요청(request) | 리소스의 개수나 용량에 대한 요청 수치를 표현하기 위해 사용된 경우 선택적으로 사용 (API 오브젝트 속성으로 request를 사용한 경우는 가능한 영문을 유지) resource | 리소스 | -Resource Limit | 리소스 상한 | -Resource Quota | 리소스 쿼터 | +ResourceQuota | 리소스쿼터(ResourceQuota) | API 오브젝트인 경우 return | 반환하다 | revision | 리비전 | -Role | 롤 | +Role | 롤(Role) | API 오브젝트인 경우 +RoleBinding | 롤바인딩(RoleBinding) | API 오브젝트인 경우 rollback | 롤백 | rolling update | 롤링 업데이트 | rollout | 롤아웃 | Romana | 로마나(Romana) | Running | Running | 파드의 상태에 한함 runtime | 런타임 | +RuntimeClass | 런타임클래스(RuntimeClass) | API 오브젝트인 경우 Scale | 스케일 | -Secret | 시크릿 | +Secret | 시크릿(Secret) | API 오브젝트인 경우 segment | 세그먼트 | Selector | 셀렉터 | Self-healing | 자가 치유 | -Service | 서비스 | -Service Account | 서비스 어카운트 | +SelfSubjectAccessReview | 셀프서브젝트액세스리뷰(SelfSubjectAccessReview) | API 오브젝트인 경우 +SelfSubjectRulesReview | SelfSubjectRulesReview | API 오브젝트이지만 용어를 구성하는 단어 중 복수형 Rules를 '룰스'로 외래어 표기하는 경우 한국어 독자에게 다소 생경할 수 있어 예외적으로 영문 용어를 사용함 +Service | 서비스 | API 오브젝트인 경우에도 표현의 간결함을 위해 한영병기를 하지 않음 +ServiceAccount | 서비스어카운트(ServiceAccount) | API 오브젝트인 경우 service discovery | 서비스 디스커버리 | service mesh | 서비스 메시 | Session | 세션 | @@ -421,10 +451,11 @@ skew | 차이(skew) | snippet | 스니펫(snippet) | spec | 명세, 스펙, 사양 | specification | 명세 | -Stateful Set | 스테이트풀 셋 | +StatefulSet | 스테이트풀셋(StatefulSet) | API 오브젝트인 경우 stateless | 스테이트리스 | Static pod | 스태틱(static) 파드 | -Storage Class | 스토리지 클래스 | +StorageClass | 스토리지클래스(StorageClass) | API 오브젝트인 경우 +SubjectAccessReview | 서브젝트액세스리뷰(SubjectAccessReview) | API 오브젝트인 경우 Sub-Object | 서브-오브젝트 | support | 지원 | Surge | 증가율 | 롤링업데이트 전략에 한함 @@ -432,6 +463,7 @@ System | 시스템 | taint | 테인트(taint) | Task | 태스크 | Terminated | Terminated | 파드의 상태에 한함 +TokenReview | 토큰리뷰(TokenReview) | API 오브젝트인 경우 tolerations | 톨러레이션(toleration) | Topology spread constraints | 토폴로지 분배 제약 조건 | Tools | 도구 | @@ -441,9 +473,11 @@ ubuntu | 우분투 | use case | 유스케이스 | userspace | 유저스페이스(userspace) | Utilization | 사용량, 사용률 | +ValidatingWebhookConfiguration | ValidatingWebhookConfiguration | API 오브젝트인 경우 verbosity | 로그 상세 레벨(verbosity) | virtualization | 가상화 | Volume | 볼륨 | +VolumeAttachment | 볼륨어태치먼트(VolumeAttachment) | API 오브젝트인 경우 Waiting | Waiting | 파드의 상태에 한함 Walkthrough | 연습 | Weave-net | 위브넷(Weave Net) | Weaveworks 사의 솔루션 공식 명칭은 'Weave Net'이므로 한영병기 시 공식 명칭 사용 @@ -451,5 +485,3 @@ Windows | 윈도우 | Worker | 워커 | 노드의 형태에 한함 Workload | 워크로드 | YAML | YAML | - - diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 6f01e041354f3..46439d3565ecc 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -408,7 +408,7 @@ PR에 여러 커밋이 있는 경우, PR을 병합하기 전에 해당 커밋을 git rebase -i HEAD~ ``` - 커밋을 스쿼시하는 것은 일종의 리베이스이다. git의 `-i` 스위치는 리베이스를 대화형으로 할 수 있게 한다. `HEAD~` 는 리베이스를 위해 살펴볼 커밋 수를 나타낸다. 출력은 다음과 비슷하다. diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index c17a557c6d4f5..f86bbb841f108 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -19,7 +19,7 @@ weight: 5 - 마크다운(Markdown)으로 쿠버네티스 문서를 작성하고 [Hugo](https://gohugo.io/)를 사용하여 쿠버네티스 사이트를 구축한다. - 소스는 [GitHub](https://github.com/kubernetes/website)에 있다. 쿠버네티스 문서는 `/content/ko/docs/` 에서 찾을 수 있다. 일부 참조 문서는 `update-imported-docs/` 디렉터리의 스크립트에서 자동으로 생성된다. -- [페이지 템플릿](/docs/contribute/style/page-templates/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. +- [페이지 템플릿](/docs/contribute/style/page-content-types/)은 Hugo에서 문서 콘텐츠의 프리젠테이션을 제어한다. - 표준 Hugo 단축코드(shortcode) 이외에도 설명서에서 여러 [사용자 정의 Hugo 단축코드](/docs/contribute/style/hugo-shortcodes/)를 사용하여 콘텐츠 표시를 제어한다. - 문서 소스는 `/content/` 에서 여러 언어로 제공된다. 각 언어는 [ISO 639-1 표준](https://www.loc.gov/standards/iso639-2/php/code_list.php)에 의해 결정된 2문자 코드가 있는 자체 폴더가 있다. 예를 들어, 한글 문서의 소스는 `/content/ko/docs/` 에 저장된다. - 여러 언어로 문서화에 기여하거나 새로운 번역을 시작하는 방법에 대한 자세한 내용은 [현지화](/ko/docs/contribute/localization_ko/)를 참고한다. diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index 8f9cb0b5f6a3f..a1897f350c1a5 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -36,7 +36,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. ## 역할과 책임 -- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla))하고 GitHub 계정을 가지고 있어야 한다. +- **모든 사람** 은 쿠버네티스 문서에 기여할 수 있다. 기여 시 [CLA에 서명](/docs/contribute/new-content/overview/#sign-the-cla)하고 GitHub 계정을 가지고 있어야 한다. - 쿠버네티스 조직의 **멤버** 는 쿠버네티스 프로젝트에 시간과 노력을 투자한 기여자이다. 일반적으로 승인되는 변경이 되는 풀 리퀘스트를 연다. 멤버십 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참조한다. - SIG Docs의 **리뷰어** 는 쿠버네티스 조직의 일원으로 문서 풀 리퀘스트에 관심을 표명했고, SIG Docs 승인자에 @@ -75,7 +75,7 @@ SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. - [모든 사람](#모든-사람) 하위에 나열된 모든 것 - 풀 리퀘스트 코멘트에 `/lgtm` 을 사용해서 LGTM(looks good to me) 레이블을 붙일 수 있다. - 풀 리퀘스트에 이미 LGTM 과 승인 레이블이 있는 경우에 풀 리퀘스트가 병합되지 않도록 코멘트에 `/hold` 를 사용할 수 있다. -- 코멘트에 `/assgin` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. +- 코멘트에 `/assign` 을 사용해서 풀 리퀘스트에 리뷰어를 배정한다. ### 멤버 되기 @@ -309,9 +309,6 @@ PR 소유자에게 조언하는데 활용된다. 쿠버네티스 문서화에 기여하는 일에 대한 보다 많은 정보는 다음 문서를 참고한다. -- [신규 컨텐츠 기여하기](/docs/contribute/overview/) -- [컨텐츠 검토하기](/docs/contribute/review/reviewing-prs) -- [문서 스타일 가이드](/docs/contribute/style/) - - - +- [신규 콘텐츠 기여하기](/ko/docs/contribute/new-content/overview/) +- [콘텐츠 검토하기](/ko/docs/contribute/review/reviewing-prs/) +- [문서 스타일 가이드](/ko/docs/contribute/style/) diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index b7416f505a796..06c2b81f21223 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -86,7 +86,7 @@ weight: 10 - 이 PR이 페이지 제목, slug/alias 또는 앵커(anchor) 링크를 변경 또는 제거하는가? 그렇다면, 이 PR의 결과로 끊어진 링크가 있는가? slug를 변경 없이 페이지 제목을 변경하는 등의 다른 옵션이 있는가? - PR이 새로운 페이지를 소개하는가? 그렇다면, - - 페이지가 올바른 [페이지 템플릿](/docs/contribute/style/page-templates/)과 연관된 Hugo 단축 코드를 사용하는가? + - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가? - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 0c8ab86fbf574..ac7252a50f393 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -28,9 +28,8 @@ weight: 20 튜토리얼 | 튜토리얼 페이지는 여러 쿠버네티스의 특징들을 하나로 묶어서 목적을 달성하는 방법을 보여준다. 튜토리얼은 독자들이 페이지를 읽을 때 실제로 할 수 있는 몇 가지 단계의 순서를 제공한다. 또는 관련 코드 일부에 대한 설명을 제공할 수도 있다. 예를 들어 튜토리얼은 코드 샘플의 연습을 제공할 수 있다. 튜토리얼에는 쿠버네티스의 특징에 대한 간략한 설명이 포함될 수 있지만 개별 기능에 대한 자세한 설명은 관련 개념 문서과 연결지어야 한다. {{< /table >}} -새 페이지에 대한 템플릿을 사용하자. 각 페이지 타입에 있는 -[템플릿](/docs/contribute/style/page-templates/) -은 문서를 작성할 때 사용할 수 있다. 템플릿을 사용하면 +작성하는 각각의 새 페이지에 대해 [콘텐츠 타입](/docs/contribute/style/page-content-types/)을 +사용하자. 페이지 타입을 사용하면 지정된 타입의 문서 간에 일관성을 보장할 수 있다. ## 제목과 파일 이름 선택 @@ -38,12 +37,12 @@ weight: 20 검색 엔진에서 찾을 키워드가 있는 제목을 선택하자. 제목에 있는 단어를 하이픈으로 구분하여 사용하는 파일 이름을 만들자. 예를 들어 -[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/access-kubernetes-api/http-proxy-access-api/) +[HTTP 프록시를 사용하여 쿠버네티스 API에 접근](/docs/tasks/extend-kubernetes/http-proxy-access-api/) 이라는 제목의 문서는 `http-proxy-access-api.md`라는 이름의 파일을 가진다. "쿠버네티스"가 이미 해당 주제의 URL에 있기 때문에 파일 이름에 "쿠버네티스" 를 넣을 필요가 없다. 예를 들면 다음과 같다. - /docs/tasks/access-kubernetes-api/http-proxy-access-api/ + /docs/tasks/extend-kubernetes/http-proxy-access-api/ ## 전문에 항목 제목 추가 @@ -164,6 +163,6 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ## {{% heading "whatsnext" %}} -* [페이지 템플릿 사용](/docs/contribute/page-templates/))에 대해 알아보기. +* [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기. * [풀 리퀘스트 작성](/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. diff --git a/content/ko/docs/home/_index.md b/content/ko/docs/home/_index.md index 2432f8781c6e4..b47bbf5c14846 100644 --- a/content/ko/docs/home/_index.md +++ b/content/ko/docs/home/_index.md @@ -43,7 +43,7 @@ cards: title: "교육" description: "공인 쿠버네티스 인증을 획득하고 클라우드 네이티브 프로젝트를 성공적으로 수행하세요!" button: "교육 보기" - button_path: "/training" + button_path: "/training" - name: reference title: 레퍼런스 정보 찾기 description: 용어, 커맨드 라인 구문, API 자원 종류, 그리고 설치 툴 문서를 살펴본다. @@ -54,8 +54,8 @@ cards: description: 이 프로젝트가 처음인 사람이든, 오래 활동한 사람이든 상관없이 누구나 기여할 수 있다. button: 문서에 기여하기 button_path: "/ko/docs/contribute" -- name: download - title: 쿠버네티스 내려받기 +- name: release-notes + title: 릴리스 노트 description: 쿠버네티스를 설치하거나 최신의 버전으로 업그레이드하는 경우, 현재 릴리스 노트를 참고한다. - name: about title: 문서에 대하여 diff --git a/content/ko/docs/reference/glossary/aggregation-layer.md b/content/ko/docs/reference/glossary/aggregation-layer.md index 404257f20b383..b09902c287c03 100644 --- a/content/ko/docs/reference/glossary/aggregation-layer.md +++ b/content/ko/docs/reference/glossary/aggregation-layer.md @@ -16,4 +16,4 @@ tags: -{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. +{{< glossary_tooltip text="쿠버네티스 API 서버" term_id="kube-apiserver" >}}에서 [추가 API 지원](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)을 구성하였으면, 쿠버네티스 API의 URL 경로를 "요구하는" `APIService` 오브젝트 추가할 수 있다. diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md index 7df679f358bc4..ab538071a515e 100755 --- a/content/ko/docs/reference/glossary/container-env-variables.md +++ b/content/ko/docs/reference/glossary/container-env-variables.md @@ -2,7 +2,7 @@ title: 컨테이너 환경 변수(Container Environment Variables) id: container-env-variables date: 2018-04-12 -full_link: /ko/docs/concepts/containers/container-environment-variables/ +full_link: /ko/docs/concepts/containers/container-environment/ short_description: > 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md index 3e680ca2bd822..97ef81c1c8cfd 100755 --- a/content/ko/docs/reference/glossary/customresourcedefinition.md +++ b/content/ko/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: 커스텀 리소스 데피니션(CustomResourceDefinition) id: CustomResourceDefinition date: 2018-04-12 -full_link: /docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API 서버에 추가할 리소스를 정의하는 사용자 정의 코드. diff --git a/content/ko/docs/reference/glossary/image.md b/content/ko/docs/reference/glossary/image.md index d7583343b82f4..adfe414d57e85 100755 --- a/content/ko/docs/reference/glossary/image.md +++ b/content/ko/docs/reference/glossary/image.md @@ -10,7 +10,7 @@ aka: tags: - fundamental --- - {{< glossary_tooltip term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. + {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md index afb2dd3ba9bb3..54fc5d0526ffb 100755 --- a/content/ko/docs/reference/glossary/statefulset.md +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -1,12 +1,12 @@ --- -title: 스테이트풀 셋(StatefulSet) +title: 스테이트풀셋(StatefulSet) id: statefulset date: 2018-04-12 full_link: /ko/docs/concepts/workloads/controllers/statefulset/ short_description: > 내구성이 있는 스토리지와 파드별로 지속성 식별자를 사용해서 파드 집합의 디플로이먼트와 스케일링을 관리한다. -aka: +aka: tags: - fundamental - core-object @@ -15,7 +15,7 @@ tags: --- {{< glossary_tooltip text="파드" term_id="pod" >}} 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . - + {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md index 24e37a3165617..bbe78369a21d8 100755 --- a/content/ko/docs/reference/glossary/volume.md +++ b/content/ko/docs/reference/glossary/volume.md @@ -11,7 +11,7 @@ tags: - core-object - fundamental --- - 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. + 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에서 접근 가능하다. diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md index d70eb8939a336..0a4a3fefbeb8d 100644 --- a/content/ko/docs/reference/kubectl/overview.md +++ b/content/ko/docs/reference/kubectl/overview.md @@ -7,14 +7,13 @@ card: weight: 20 --- -{{% capture overview %}} + Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구이다. `kubectl` 은 config 파일을 $HOME/.kube 에서 찾는다. KUBECONFIG 환경 변수를 설정하거나 [`--kubeconfig`](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 플래그를 설정하여 다른 [kubeconfig](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 파일을 지정할 수 있다. 이 개요는 `kubectl` 구문을 다루고, 커맨드 동작을 설명하며, 일반적인 예제를 제공한다. 지원되는 모든 플래그 및 하위 명령을 포함한 각 명령에 대한 자세한 내용은 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 참조 문서를 참고한다. 설치 방법에 대해서는 [kubectl 설치](/ko/docs/tasks/tools/install-kubectl/)를 참고한다. -{{% /capture %}} -{{% capture body %}} + ## 구문 @@ -441,7 +440,7 @@ The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-bar ``` ```shell -# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, +# 또한, 이 명령은 예를 들어 실행 불가능한 파일이거나, # 다른 플러그인에 의해 가려진 플러그인에 대해 # 경고할 수 있다 sudo chmod -x /usr/local/bin/kubectl-foo @@ -486,10 +485,9 @@ Current user: plugins-user 플러그인에 대한 자세한 내용은 [cli plugin 예제](https://github.com/kubernetes/sample-cli-plugin)를 참고한다. -{{% /capture %}} -{{% capture whatsnext %}} +## {{% heading "whatsnext" %}} [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 명령을 사용하여 시작한다. -{{% /capture %}} + diff --git a/content/ko/docs/reference/using-api/api-overview.md b/content/ko/docs/reference/using-api/api-overview.md index e7a0b8ce8ddeb..098e9ad9bff6b 100644 --- a/content/ko/docs/reference/using-api/api-overview.md +++ b/content/ko/docs/reference/using-api/api-overview.md @@ -83,7 +83,7 @@ API 버전의 차이는 수준의 안정성과 지원의 차이를 나타낸다. [사용자 정의 리소스](/docs/concepts/api-extension/custom-resources/)로 API를 확장하는 경우에는 다음 두 종류의 경로가 지원된다. - 기본적인 CRUD 요구에는 - [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/) + [커스텀리소스데피니션(CustomResourceDefinition)](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) - 쿠버네티스 API의 의미론적 전체 집합으로 사용자만의 Apiserver를 구현하려는 경우에는 [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 4757354dcac14..321cf5ed2f9f6 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -47,6 +47,7 @@ Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | +| Java | [github.com/manusa/yakc](https://github.com/manusa/yakc) | | Lisp | [github.com/brendandburns/cl-k8s](https://github.com/brendandburns/cl-k8s) | | Lisp | [github.com/xh4/cube](https://github.com/xh4/cube) | | Node.js (TypeScript) | [github.com/Goyoo/node-k8s-client](https://github.com/Goyoo/node-k8s-client) | diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 0ce3fe2270e5a..f5d1486f39146 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -29,7 +29,7 @@ weight: 40 * [front-proxy][proxy]를 위한 클라이언트와 서버 인증서 {{< note >}} -`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/access-kubernetes-api/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. +`front-proxy` 인증서는 kube-proxy에서 [API 서버 확장](/docs/tasks/extend-kubernetes/setup-extension-api-server/)을 지원할 때만 kube-proxy에서 필요하다. {{< /note >}} etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. @@ -160,6 +160,6 @@ KUBECONFIG= kubectl config use-context default-system [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ -[proxy]: /docs/tasks/access-kubernetes-api/configure-aggregation-layer/ +[proxy]: /docs/tasks/extend-kubernetes/configure-aggregation-layer/ diff --git a/content/ko/docs/setup/learning-environment/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md index e8d169af96348..7cc0eb9874d72 100644 --- a/content/ko/docs/setup/learning-environment/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -135,7 +135,7 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. -no body in request- ``` - 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. + 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. 7. `hello-minikube` 서비스 삭제 @@ -197,21 +197,21 @@ Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. 이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. {{< note >}} -웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. +웹 프록시 뒤에 있다면, `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`. +Minikube는 또한 "minikube" 콘텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. +이 콘텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. {{< /note >}} #### 쿠버네티스 버전 지정하기 -`minikube start` 코멘드에 `--kubernetes-version` 문자열을 -추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. +`minikube start` 코멘드에 `--kubernetes-version` 문자열을 +추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. 예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. ``` @@ -239,7 +239,7 @@ Minikube는 다음의 드라이버를 지원한다. * 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 >}} @@ -357,27 +357,34 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 ### 클러스터 중지 `minikube stop` 명령어는 클러스터를 중지하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하지만, 모든 클러스터 상태와 데이터를 보존한다. -클러스터를 다시 시작하면 이전의 상태로 돌려줍니다. +클러스터를 다시 시작하면 이전의 상태로 돌려준다. ### 클러스터 삭제 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. ### Minikube 업그레이드 -macOS를 사용하는 경우 기존에 설치된 Minikube를 업그레이드하려면 [Minikube 업그레이드](https://minikube.sigs.k8s.io/docs/start/macos/#upgrading-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 start` 명령어는 Minikube로 부르는 [kubectl 콘텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. +이 콘텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. + +Minikube는 이 콘텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 다음을 실행하자. -Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 +`kubectl config use-context minikube` -`kubectl config use-context minikube`을 실행하자. +혹은 다음과 같이 커맨드를 실행할 때마다 매번 콘텍스트를 전달한다. -혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다. +`kubectl get pods --context=minikube` ### 대시보드 @@ -454,7 +461,7 @@ spec: ## 애드온 -Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, +Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. 폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. @@ -497,7 +504,7 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit * **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [기여하기](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/)를 보자. +* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://minikube.sigs.k8s.io/docs/contrib/addons/)를 보자. * **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다. ## 커뮤니티 diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md index 270287b1b363f..3bc3dad135c9d 100644 --- a/content/ko/docs/setup/release/notes.md +++ b/content/ko/docs/setup/release/notes.md @@ -2,7 +2,7 @@ title: v1.18 릴리스 노트 weight: 10 card: - name: 다운로드 + name: release-notes weight: 20 anchors: - anchor: "#" @@ -306,7 +306,7 @@ NodeLocal DNSCache는 dnsCache 파드를 데몬셋으로 실행하여 clusterDNS - Kube-proxy: iptables 프록시에 이중 스택 IPv4/IPv6 지원이 추가되었다. ([#82462](https://github.com/kubernetes/kubernetes/pull/82462), [@vllry](https://github.com/vllry)) [SIG 네트워크] - Kubeadm은 이제 kube-controller-manager에 대한 이중 스택 노드 cidr 마스크의 자동 계산을 지원한다. ([#85609](https://github.com/kubernetes/kubernetes/pull/85609), [@Arvinderpal](https://github.com/Arvinderpal)) [SIG 클러스터 라이프사이클] - Kubeadm: 잡(Job)을 배포하는 업그레이드된 헬스 체크를 추가한다. ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] -- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 +- Kubeadm: 실험 기능 게이트 PublicKeysECDSA를 추가하여 "kubeadm init"에서 ECDSA 인증서가 있는 클러스터를 생성할 수 있게 한다. "kubeadm alpha certs renew"을 사용하여 기존 ECDSA 인증서의 갱신도 지원되지만, 즉시 또는 업그레이드 중에 RSA와 ECDSA 알고리즘간에 전환하지는 않는다. ([#86953](https://github.com/kubernetes/kubernetes/pull/86953), [@rojkov](https://github.com/rojkov)) [SIG API Machinery, Auth 및 클러스터 라이프사이클] - Kubeadm: JSON, YAML, Go 템플릿 및 JsonPath 형식으로 'kubeadm config images list' 커맨드의 구조화된 출력을 구현했다. ([#86810](https://github.com/kubernetes/kubernetes/pull/86810), [@bart0sh](https://github.com/bart0sh)) [SIG 클러스터 라이프사이클] - Kubeadm: kubeconfig 인증서 갱신 시, 내장된 CA를 디스크의 CA와 동기화된 상태로 유지한다. ([#88052](https://github.com/kubernetes/kubernetes/pull/88052), [@neolit123](https://github.com/neolit123)) [SIG 클러스터 라이프사이클] @@ -689,8 +689,8 @@ filename | sha512 hash - Add `rest_client_rate_limiter_duration_seconds` metric to component-base to track client side rate limiter latency in seconds. Broken down by verb and URL. ([#88134](https://github.com/kubernetes/kubernetes/pull/88134), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] - Allow user to specify resource using --filename flag when invoking kubectl exec ([#88460](https://github.com/kubernetes/kubernetes/pull/88460), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. - After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. +- Apiserver add a new flag --goaway-chance which is the fraction of requests that will be closed gracefully(GOAWAY) to prevent HTTP/2 clients from getting stuck on a single apiserver. + After the connection closed(received GOAWAY), the client's other in-flight requests won't be affected, and the client will reconnect. The flag min value is 0 (off), max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. ([#88567](https://github.com/kubernetes/kubernetes/pull/88567), [@answer1991](https://github.com/answer1991)) [SIG API Machinery] - Azure: add support for single stack IPv6 ([#88448](https://github.com/kubernetes/kubernetes/pull/88448), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] @@ -739,7 +739,7 @@ filename | sha512 hash - Kubelets perform fewer unnecessary pod status update operations on the API server. ([#88591](https://github.com/kubernetes/kubernetes/pull/88591), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Scalability] - Plugin/PluginConfig and Policy APIs are mutually exclusive when running the scheduler ([#88864](https://github.com/kubernetes/kubernetes/pull/88864), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Specifying PluginConfig for the same plugin more than once fails scheduler startup. - + Specifying extenders and configuring .ignoredResources for the NodeResourcesFit plugin fails ([#88870](https://github.com/kubernetes/kubernetes/pull/88870), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - Support TLS Server Name overrides in kubeconfig file and via --tls-server-name in kubectl ([#88769](https://github.com/kubernetes/kubernetes/pull/88769), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Auth and CLI] - Terminating a restartPolicy=Never pod no longer has a chance to report the pod succeeded when it actually failed. ([#88440](https://github.com/kubernetes/kubernetes/pull/88440), [@smarterclayton](https://github.com/smarterclayton)) [SIG Node and Testing] @@ -806,18 +806,18 @@ filename | sha512 hash If you are setting `--redirect-container-streaming=true`, then you must migrate off this configuration. The flag will no longer be able to be enabled starting in v1.20. If you are not setting the flag, no action is necessary. ([#88290](https://github.com/kubernetes/kubernetes/pull/88290), [@tallclair](https://github.com/tallclair)) [SIG API Machinery and Node] - Yes. - + Feature Name: Support using network resources (VNet, LB, IP, etc.) in different AAD Tenant and Subscription than those for the cluster. - + Changes in Pull Request: - + 1. Add properties `networkResourceTenantID` and `networkResourceSubscriptionID` in cloud provider auth config section, which indicates the location of network resources. 2. Add function `GetMultiTenantServicePrincipalToken` to fetch multi-tenant service principal token, which will be used by Azure VM/VMSS Clients in this feature. 3. Add function `GetNetworkResourceServicePrincipalToken` to fetch network resource service principal token, which will be used by Azure Network Resource (Load Balancer, Public IP, Route Table, Network Security Group and their sub level resources) Clients in this feature. 4. Related unit tests. - + None. - + User Documentation: In PR https://github.com/kubernetes-sigs/cloud-provider-azure/pull/301 ([#88384](https://github.com/kubernetes/kubernetes/pull/88384), [@bowen5](https://github.com/bowen5)) [SIG Cloud Provider] ## Changes by Kind @@ -833,8 +833,8 @@ filename | sha512 hash - Added support for multiple sizes huge pages on a container level ([#84051](https://github.com/kubernetes/kubernetes/pull/84051), [@bart0sh](https://github.com/bart0sh)) [SIG Apps, Node and Storage] - AppProtocol is a new field on Service and Endpoints resources, enabled with the ServiceAppProtocol feature gate. ([#88503](https://github.com/kubernetes/kubernetes/pull/88503), [@robscott](https://github.com/robscott)) [SIG Apps and Network] - Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources. ([#84920](https://github.com/kubernetes/kubernetes/pull/84920), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Introduces optional --detect-local flag to kube-proxy. - Currently the only supported value is "cluster-cidr", +- Introduces optional --detect-local flag to kube-proxy. + Currently the only supported value is "cluster-cidr", which is the default if not specified. ([#87748](https://github.com/kubernetes/kubernetes/pull/87748), [@satyasm](https://github.com/satyasm)) [SIG Cluster Lifecycle, Network and Scheduling] - Kube-scheduler can run more than one scheduling profile. Given a pod, the profile is selected by using its `.spec.SchedulerName`. ([#88285](https://github.com/kubernetes/kubernetes/pull/88285), [@alculquicondor](https://github.com/alculquicondor)) [SIG Apps, Scheduling and Testing] - Moving Windows RunAsUserName feature to GA ([#87790](https://github.com/kubernetes/kubernetes/pull/87790), [@marosset](https://github.com/marosset)) [SIG Apps and Windows] @@ -1048,9 +1048,9 @@ filename | sha512 hash - aggragation api will have alpha support for network proxy ([#87515](https://github.com/kubernetes/kubernetes/pull/87515), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] - API request throttling (due to a high rate of requests) is now reported in client-go logs at log level 2. The messages are of the form - + Throttling request took 1.50705208s, request: GET: - + The presence of these messages, may indicate to the administrator the need to tune the cluster accordingly. ([#87740](https://github.com/kubernetes/kubernetes/pull/87740), [@jennybuckley](https://github.com/jennybuckley)) [SIG API Machinery] - kubeadm: reject a node joining the cluster if a node with the same name already exists ([#81056](https://github.com/kubernetes/kubernetes/pull/81056), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - disableAvailabilitySetNodes is added to avoid VM list for VMSS clusters. It should only be used when vmType is "vmss" and all the nodes (including masters) are VMSS virtual machines. ([#87685](https://github.com/kubernetes/kubernetes/pull/87685), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] @@ -1360,7 +1360,7 @@ filename | sha512 hash * Update Cluster Autoscaler to 1.17.0; changelog: https://github.com/kubernetes/autoscaler/releases/tag/cluster-autoscaler-1.17.0 ([#85610](https://github.com/kubernetes/kubernetes/pull/85610), [@losipiuk](https://github.com/losipiuk)) * Filter published OpenAPI schema by making nullable, required fields non-required in order to avoid kubectl to wrongly reject null values. ([#85722](https://github.com/kubernetes/kubernetes/pull/85722), [@sttts](https://github.com/sttts)) * kubectl set resources will no longer return an error if passed an empty change for a resource. ([#85490](https://github.com/kubernetes/kubernetes/pull/85490), [@sallyom](https://github.com/sallyom)) - * kubectl set subject will no longer return an error if passed an empty change for a resource. + * kubectl set subject will no longer return an error if passed an empty change for a resource. * kube-apiserver: fixed a conflict error encountered attempting to delete a pod with gracePeriodSeconds=0 and a resourceVersion precondition ([#85516](https://github.com/kubernetes/kubernetes/pull/85516), [@michaelgugino](https://github.com/michaelgugino)) * kubeadm: add a upgrade health check that deploys a Job ([#81319](https://github.com/kubernetes/kubernetes/pull/81319), [@neolit123](https://github.com/neolit123)) * kubeadm: make sure images are pre-pulled even if a tag did not change but their contents changed ([#85603](https://github.com/kubernetes/kubernetes/pull/85603), [@bart0sh](https://github.com/bart0sh)) diff --git a/content/ko/docs/tasks/_index.md b/content/ko/docs/tasks/_index.md index b9e161f26bf52..359ec82a9cd15 100644 --- a/content/ko/docs/tasks/_index.md +++ b/content/ko/docs/tasks/_index.md @@ -59,7 +59,7 @@ content_type: concept ## 스테이트풀 애플리케이션 관리하기 -스테이트풀 셋의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. +스테이트풀셋(StatefulSet)의 스케일링, 삭제하기, 디버깅을 포함하는 스테이트풀 애플리케이션 관리를 위한 일반적인 태스크를 수행한다. ## 클러스터 데몬 diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 9c70cbe8b1360..0218324ff2ef5 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,7 +6,7 @@ weight: 110 -이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지 +이 페이지에서는 동일한 파드에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨을 이용하는지 살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자. diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 4fa9a9492accc..e279148e33db8 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -10,14 +10,14 @@ card: -이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 -설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 -구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 +이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 +설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의 +구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를 사용하여 클러스터를 빠르게 변경할 수 있다. {{< note >}} -클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 -불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 +클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고 +불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이 반드시 존재해야 한다는 것을 의미하는 것은 아니다. {{< /note >}} @@ -26,7 +26,12 @@ card: ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} + +{{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면, +`kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과 +[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야 +한다. @@ -34,14 +39,14 @@ card: ## 클러스터, 사용자, 컨텍스트 정의 -당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. -`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 -작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. -`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 -네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, +당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자. +`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서 +작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다. +`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조 +네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고, scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다. -`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 +`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. ```shell @@ -68,10 +73,10 @@ contexts: name: exp-scratch ``` -구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 +구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과 두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다. -`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 +`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의 세부사항들을 추가한다. ```shell @@ -100,7 +105,7 @@ kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=develo kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter ``` -`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 +`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는 것 대신에 `config view` 커맨드를 사용할 수도 있다. ```shell @@ -150,16 +155,16 @@ users: username: exp ``` -위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 -플레이스홀더(placeholder)이다. +위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로 이름을 위한 +플레이스홀더(placeholder)이다. 당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다. -만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 -이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, +만약 당신이 인증서 파일들의 경로 대신에 여기에 포함된 base64로 인코딩된 데이터를 사용하려고 한다면 +이 경우 키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`, `client-certificate-data`, `client-key-data` 같이 사용할 수 있다. -컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 -`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 +컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어 +`dev-frontend` 컨텍스트는 "`development` 클러스터의 `frontend` 네임스페이스에 접근하는데 `developer` 사용자 자격증명을 사용하라고 알려준다." 현재 컨텍스트를 설정한다. @@ -168,11 +173,11 @@ users: kubectl config --kubeconfig=config-demo use-context dev-frontend ``` -이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 -네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 +이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와 +네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된 사용자 자격증명을 사용할 것이다. -현재 컨텍스트에 관련된 구성 정보만을 보려면 +현재 컨텍스트에 관련된 구성 정보만을 보려면 `--minify` 플래그를 사용한다. ```shell @@ -212,8 +217,8 @@ users: kubectl config --kubeconfig=config-demo use-context exp-scratch ``` -이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 -default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 +이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의 +default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된 사용자의 자격증명을 사용할 것이다. 현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자. @@ -222,7 +227,7 @@ default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열 kubectl config --kubeconfig=config-demo view --minify ``` -마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 +마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서 잠시 작업을 하려고 한다고 가정해보자. 현재 컨텍스트를 `dev-storage`로 변경한다. @@ -259,7 +264,7 @@ contexts: ## KUBECONFIG 환경 변수 설정 -`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, +`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면, 이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다. 예: @@ -271,9 +276,9 @@ export KUBECONFIG_SAVED=$KUBECONFIG ```shell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` -`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 -Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. -`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 +`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 +Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다. +`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 익숙해지길 바란다. 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자. @@ -293,9 +298,9 @@ $Env:KUBECONFIG=("config-demo;config-demo-2") kubectl config view ``` -당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 -표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` -컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 +당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로 +표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up` +컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 가지고 있다는 것에 주목하길 바란다. ```shell @@ -322,22 +327,22 @@ contexts: name: exp-scratch ``` -kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 +kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다. ## $HOME/.kube 디렉토리 탐색 -만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 -해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 +만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여 +해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는 파일을 가지고 있을 것이다. -`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. -보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. +`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자. +보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다. 간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다. ## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가 -당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` +당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG` 환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자. 예: @@ -350,7 +355,7 @@ export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` -이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. +이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. config-exercise 디렉토리에서 다음 커맨드를 실행한다. ```shell diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index bef17a789d95d..75bfb61a76c5d 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -61,7 +61,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 ## 컨테이너화 된 애플리케이션 배포 -대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스(Service) 로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. +대시보드를 이용하여 컨테이너화 된 애플리케이션을 디플로이먼트와 간단한 마법사를 통한 선택적인 서비스로 생성하고 배포할 수 있다. 애플리케이션 세부 정보를 수동으로 지정할 수 있고, 또는 애플리케이션 구성을 포함한 YAML, JSON 파일을 업로드 할 수 있다. 시작하는 페이지의 상위 오른쪽 코너에 있는 **CREATE** 버튼을 클릭한다. @@ -69,7 +69,7 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 배포 마법사는 다음 정보를 제공한다. -- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스(Service)에 추가되어야 한다. +- **앱 이름** (필수): 애플리케이션 이름. [레이블](/ko/docs/concepts/overview/working-with-objects/labels/) 이름은 배포할 모든 디플로이먼트와 서비스에 추가되어야 한다. 애플리케이션 이름은 선택된 쿠버네티스 [네임스페이스](/docs/tasks/administer-cluster/namespaces/) 안에서 유일해야 한다. 소문자로 시작해야하며, 소문자 또는 숫자로 끝나고, 소문자, 숫자 및 대쉬(-)만을 포함해야한다. 24 문자만을 제한한다. 처음과 끝의 스페이스는 무시된다. @@ -79,17 +79,21 @@ Kubeconfig 인증 방법은 외부 아이덴티티 프로파이더 또는 x509 클러스터에 의도한 파드의 수를 유지하기 위해서 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)가 생성될 것이다. -- **서비스(Service)** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스(Service)](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. 외부 서비스들을 위해, 한개 또는 여러 개의 포트들을 열어 둘 필요가 있다. [이 곳](/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/) 내용을 참고한다. +- **서비스** (선택): 일부 애플리케이션의 경우, (예를 들어, 프론트엔드) 아마도 클러스터 바깥의 퍼블릭 IP 주소를 가진 (외부 서비스) 외부에 [서비스](/ko/docs/concepts/services-networking/service/)를 노출 시키고 싶을 수 있다. - 클러스터 내부에서만 보고 싶은 어떤 서비스(Serivce)들이 있을 것인다. 이를 내부 서비스라고 한다. + {{< note >}} + 외부 서비스들을 위해, 한 개 또는 여러 개의 포트를 열어 둘 필요가 있다. + {{< /note >}} - 서비스(Service) 타입과는 무관하게, 서비스(Service) 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스(Service)는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스(Service)는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스(Service)가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. + 클러스터 내부에서만 보고 싶은 어떤 서비스들이 있을 것이다. 이를 내부 서비스라고 한다. + + 서비스 타입과는 무관하게, 서비스 생성을 선택해서 컨테이너의 (들어오는 패킷의) 포트를 리슨한다면, 두 개의 포트를 정의해야 한다. 서비스는 컨테이너가 바라보는 타겟 포트와 (들어오는 패킷의) 맵핑하는 포트가 만들어져야 할 것이다. 서비스는 배포된 파드에 라우팅 될 것이다. 지원하는 프로토콜은 TCP와 UDP이다. 서비스가 이용하는 내부 DNS 이름은 애플리케이션 이름으로 지정한 값이 될 것이다. 만약 필요하다면, 더 많은 세팅을 지정할 수 있는 **자세한 옵션 보기** 섹션에서 확장할 수 있다. - **설명**: 입력하는 텍스트값은 디플로이먼트에 [어노테이션](/ko/docs/concepts/overview/working-with-objects/annotations/) 으로 추가될 것이고, 애플리케이션의 세부사항에 표시될 것이다. -- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스(Service), 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. +- **레이블**: 애플리케이션에 사용되는 기본적인 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)은 애플리케이션 이름과 버전이다. 릴리스, 환경, 티어, 파티션, 그리고 릴리스 트랙과 같은 레이블을 디플로이먼트, 서비스, 그리고 파드를 생성할 때 추가적으로 정의할 수 있다. 예를 들면: @@ -119,13 +123,13 @@ track=stable - **특권을 가진(privileged) 상태로 실행**: 다음 세팅은 호스트에서 루트 권한을 가진 프로세스들이 [특권을 가진 컨테이너](/docs/user-guide/pods/#privileged-mode-for-pod-containers)의 프로세스들과 동등한 지 아닌지 정의한다. 특권을 가진(privileged) 컨테이너는 네트워크 스택과 디바이스에 접근하는 것을 조작하도록 활용할 수 있다. -- **환경 변수**: 쿠버네티스 서비스(Service)를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스(Service)를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. +- **환경 변수**: 쿠버네티스 서비스를 [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)를 통해 노출한다. 환경 변수 또는 인자를 환경 변수들의 값으로 커맨드를 통해 구성할 수 있다. 애플리케이션들이 서비스를 찾는데 사용된다. 값들은 `$(VAR_NAME)` 구문을 사용하는 다른 변수들로 참조할 수 있다. ### YAML 또는 JSON 파일 업로드 쿠버네티스는 선언적인 설정을 제공한다. 이 방식으로 모든 설정은 쿠버네티스 [API](/docs/concepts/overview/kubernetes-api/) 리소스 스키마를 이용하여 YAML 또는 JSON 설정 파일에 저장한다. -배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. +배포 마법사를 통해 애플리케이션 세부사항들을 지정하는 대신, 애플리케이션을 YAML 또는 JSON 파일로 정의할 수 있고 대시보드를 이용해서 파일을 업로드할 수 있다. ## 대시보드 사용 다음 섹션들은 어떻게 제공하고 어떻게 사용할 수 있는지에 대한 쿠버네티스 대시보드 UI의 모습을 보여준다. @@ -140,12 +144,12 @@ track=stable 클러스터와 네임스페이스 관리자에게 대시보드는 노드, 네임스페이스 그리고 퍼시스턴트 볼륨과 세부사항들이 보여진다. 노드는 모든 노드를 통틀어 CPU와 메모리 사용량을 보여준다. 세부사항은 각 노드들에 대한 사용량, 사양, 상태, 할당된 리소스, 이벤트 그리고 노드에서 돌아가는 파드를 보여준다. #### 워크로드 -선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀 셋 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. +선택된 네임스페이스에서 구동되는 모든 애플리케이션을 보여준다. 애플리케이션의 워크로드 종류(예를 들어, 디플로이먼트, 레플리카 셋, 스테이트풀셋(StatefulSet) 등)를 보여주고 각각의 워크로드 종류는 따로 보여진다. 리스트는 예를 들어 레플리카 셋에서 준비된 파드의 숫자 또는 파드의 현재 메모리 사용량과 같은 워크로드에 대한 실용적인 정보를 요약한다. 워크로드에 대한 세부적인 것들은 상태와 사양 정보, 오프젝트들 간의 관계를 보여준다. 예를 들어, 레플리카 셋으로 관리하는 파드들 또는 새로운 레플리카 셋과 디플로이먼트를 위한 Horizontal Pod Autoscalers 이다. -#### 서비스(Service) -외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스(Service)와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. +#### 서비스 +외부로 노출되는 서비스들과 클러스터 내에 발견되는 서비스들을 허용하는 쿠버네티스 리소스들을 보여준다. 이러한 이유로 서비스와 인그레스는 클러스터간의 연결을 위한 내부 엔드포인트들과 외부 사용자를 위한 외부 엔드포인트들에 의해 타게팅된 파드들을 보여준다. #### 스토리지 스토리지는 애플리케이션이 데이터를 저장하기 위해 사용하는 퍼시턴트 볼륨 클레임 리소스들을 보여준다. @@ -163,7 +167,7 @@ track=stable ## {{% heading "whatsnext" %}} -더 많은 정보는 +더 많은 정보는 [쿠버네티스 대시보드 프로젝트 페이지](https://github.com/kubernetes/dashboard)를 참고한다. diff --git a/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md new file mode 100644 index 0000000000000..9c9341919ad2b --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/change-default-storage-class.md @@ -0,0 +1,101 @@ +--- +title: 기본 스토리지클래스(StorageClass) 변경하기 +content_type: task +--- + + +이 페이지는 특별한 요구사항이 없는 퍼시스턴트볼륨클레임(PersistentVolumeClaim)의 볼륨을 프로비저닝 +하는데 사용되는 기본 스토리지 클래스를 변경하는 방법을 보여준다. + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## 왜 기본 스토리지 클래스를 변경하는가? + +설치 방법에 따라, 사용자의 쿠버네티스 클러스터는 기본으로 표시된 기존 +스토리지클래스와 함께 배포될 수 있다. 이 기본 스토리지클래스는 특정 +스토리지 클래스가 필요하지 않은 퍼시스턴트볼륨클레임에 대해 스토리지를 +동적으로 프로비저닝 하기 위해 사용된다. +더 자세한 내용은 [퍼시스턴트볼륨클레임 문서](/ko/docs/concepts/storage/persistent-volumes/#class-1)를 +보자. + +미리 설치된 기본 스토리지클래스가 사용자의 예상되는 워크로드에 적합하지 +않을수도 있다. 예를 들어, 너무 가격이 높은 스토리지를 프로비저닝 해야할 +수도 있다. 이런 경우에, 기본 스토리지 클래스를 변경하거나 완전히 비활성화 +하여 스토리지의 동적 프로비저닝을 방지할 수 있다. + +단순하게 기본 스토리지클래스를 삭제하는 경우, 사용자의 클러스터에서 구동중인 +애드온 매니저에 의해 자동으로 다시 생성될 수 있으므로 정상적으로 삭제가 되지 않을 수도 있다. 애드온 관리자 +및 개별 애드온을 비활성화 하는 방법에 대한 자세한 내용은 설치 문서를 참조하자. + +## 기본 스토리지클래스 변경하기 + +1. 사용자의 클러스터에 있는 스토리지클래스 목록을 조회한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard (default) kubernetes.io/gce-pd 1d + gold kubernetes.io/gce-pd 1d + ``` + + 기본 스토리지클래스는 `(default)` 로 표시되어 있다. + +1. 기본 스토리지클래스를 기본값이 아닌 것으로 표시한다. + + 기본 스토리지클래스에는 + `storageclass.kubernetes.io/is-default-class` 의 값이 `true` 로 설정되어 있다. + 다른 값이거나 어노테이션이 없을 경우 `false` 로 처리된다. + + 스토리지클래스를 기본값이 아닌 것으로 표시하려면, 그 값을 `false` 로 변경해야 한다. + + ```bash + kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' + ``` + + 여기서 `standard` 는 사용자가 선택한 스토리지클래스의 이름이다. + +1. 스토리지클래스를 기본값으로 표시한다. + + 이전 과정과 유사하게, 어노테이션을 추가/설정 해야 한다. + `storageclass.kubernetes.io/is-default-class=true`. + + ```bash + kubectl patch storageclass gold -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' + ``` + + 최대 1개의 스토리지클래스를 기본값으로 표시할 수 있다는 것을 알아두자. 만약 + 2개 이상이 기본값으로 표시되면, 명시적으로 `storageClassName` 가 지정되지 않은 `PersistentVolumeClaim` 은 생성될 수 없다. + +1. 사용자가 선택한 스토리지클래스가 기본값으로 되어있는지 확인한다. + + ```bash + kubectl get storageclass + ``` + + 결과는 아래와 유사하다. + + ```bash + NAME PROVISIONER AGE + standard kubernetes.io/gce-pd 1d + gold (default) kubernetes.io/gce-pd 1d + ``` + + + +## {{% heading "whatsnext" %}} + +* [퍼시스턴트볼륨(PersistentVolume)](/ko/docs/concepts/storage/persistent-volumes/)에 대해 더 보기. diff --git a/content/ko/docs/tasks/administer-cluster/coredns.md b/content/ko/docs/tasks/administer-cluster/coredns.md new file mode 100644 index 0000000000000..6f0caad9e40bb --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/coredns.md @@ -0,0 +1,98 @@ +--- +title: 서비스 디스커버리를 위해 CoreDNS 사용하기 +min-kubernetes-server-version: v1.9 +content_type: task +--- + + +이 페이지는 CoreDNS 업그레이드 프로세스와 kube-dns 대신 CoreDNS를 설치하는 방법을 보여준다. + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + +## CoreDNS 소개 + +[CoreDNS](https://coredns.io)는 쿠버네티스 클러스터의 DNS 역할을 수행할 수 있는, 유연하고 확장 가능한 DNS 서버이다. +쿠버네티스와 동일하게, CoreDNS 프로젝트도 {{< glossary_tooltip text="CNCF" term_id="cncf" >}}가 관리한다. + +사용자는 기존 디플로이먼트인 kube-dns를 교체하거나, 클러스터를 배포하고 업그레이드하는 +kubeadm과 같은 툴을 사용하여 클러스터 안의 kube-dns 대신 CoreDNS를 사용할 수 있다. + +## CoreDNS 설치 + +Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트](https://github.com/coredns/deployment/tree/master/kubernetes)에 +있는 문서를 확인하자. + +## CoreDNS로 이관하기 + +### Kubeadm을 사용해 기존 클러스터 업그레이드하기 + +쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여 +`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은 +`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의 +설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다. + +만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다. +예를 들어, `v1.11.0` 로 업그레이드 하는 경우는 다음과 같다. +``` +kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true +``` + +쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다. +업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 +설명된 지침 가이드를 참고하자. + +1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**. +**만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이 +시작된 후에 변경 사항을 다시 적용해야 할 수도 있다. + +만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서, +기존의 Corefile이 유지된다. + + +### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기 + +{{< note >}} +쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며, +기본적으로 설치된다. +{{< /note >}} + +{{< warning >}} +쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. +{{< /warning >}} + +1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` +값을 `false` 로 변경해야 한다. + +``` +kubeadm init --feature-gates=CoreDNS=false +``` + +1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자. + +## CoreDNS 업그레이드하기 + +CoreDNS는 쿠버네티스 1.9 버전부터 사용할 수 있다. +쿠버네티스와 함께 제공되는 CoreDNS의 버전과 CoreDNS의 변경 사항은 [여기](https://github.com/coredns/deployment/blob/master/kubernetes/CoreDNS-k8s_version.md)에서 확인할 수 있다. + +CoreDNS는 사용자 정의 이미지를 사용하거나 CoreDNS만 업그레이드 하려는 경우에 수동으로 업그레이드할 수 있다. +업그레이드를 원활하게 수행하는 데 유용한 [가이드라인 및 연습](https://github.com/coredns/deployment/blob/master/kubernetes/Upgrading_CoreDNS.md)을 참고하자. + +## CoreDNS 튜닝하기 + +리소스 활용이 중요한 경우, CoreDNS 구성을 조정하는 것이 유용할 수 있다. +더 자세한 내용은 [CoreDNS 스케일링에 대한 설명서](https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md)를 확인하자. + + + +## {{% heading "whatsnext" %}} + + +`Corefile` 을 수정하여 kube-dns 보다 더 많은 유스케이스를 지원하도록 +[CoreDNS](https://coredns.io)를 구성할 수 있다. +더 자세한 내용은 [CoreDNS 웹사이트](https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/)을 확인하자. 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 dc17eb9cdc06f..5e9c61d3e6894 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -241,4 +241,8 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지 [cert-cas]: /ko/docs/setup/best-practices/certificates/#단일-루트-ca [cert-table]: /ko/docs/setup/best-practices/certificates/#모든-인증서 +## 인증 기관(CA) 순환(rotation) {#certificate-authority-rotation} +Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다. + +CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 452cfb18651e7..b6b1c878c6bc6 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -294,6 +294,7 @@ sudo kubeadm upgrade apply kubelet을 다시 시작한다. ```shell +sudo systemctl daemon-reload sudo systemctl restart kubelet ``` @@ -372,6 +373,7 @@ sudo systemctl restart kubelet - kubelet을 다시 시작한다. ```shell + sudo systemctl daemon-reload sudo systemctl restart kubelet ``` diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index c735bc1a72eff..7127a7f235f57 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -199,3 +199,5 @@ kubectl delete namespace default-mem-example * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) + + diff --git a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md index a90d2263d3e71..880444cefd35a 100644 --- a/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md +++ b/content/ko/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace.md @@ -136,3 +136,8 @@ kubectl delete namespace quota-pod-example * [파드에 대한 서비스 품질(QoS) 구성](/docs/tasks/configure-pod-container/quality-service-pod/) + + + + + diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index 2d7f856e46433..44f57b3b58dd9 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 캘리코(Calico) 사용하기 content_type: task weight: 10 @@ -52,4 +51,3 @@ Kubeadm을 이용해서 15분 이내에 지역 단일 호스트 캘리코 클러 클러스터가 동작하면, 쿠버네티스 네트워크 폴리시(NetworkPolicy)를 시도하기 위해 [네트워크 폴리시 선언하기](/docs/tasks/administer-cluster/declare-network-policy/)를 따라 할 수 있다. - diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md index 71a96ed8ee972..1fbc5e4455997 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy.md @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 큐브 라우터(Kube-router) 사용하기 content_type: task weight: 30 --- + + 이 페이지는 네트워크 폴리시(NetworkPolicy)로 [큐브 라우터(Kube-router)](https://github.com/cloudnativelabs/kube-router)를 사용하는 방법을 살펴본다. 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 dceaf495fca30..462e482bff60a 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 @@ -1,10 +1,11 @@ --- -reviewers: title: 네트워크 폴리시로 로마나(Romana) content_type: task weight: 40 --- + + 이 페이지는 네트워크 폴리시(NetworkPolicy)로 로마나(Romana)를 사용하는 방법을 살펴본다. 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 d5fef95e75aa2..484a8d58cdb5b 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 @@ -1,5 +1,4 @@ --- -reviewers: title: 네트워크 폴리시로 위브넷(Weave Net) 사용하기 content_type: task weight: 50 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 06e8f645b2d27..7083bdea675b1 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 @@ -25,7 +25,8 @@ weight: 10 서비스 실행이 필요하다. 이미 실행중인 metrics-server가 있다면 다음 단계를 건너뛸 수 있다. -Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 활성화 할 수 있다. +Minikube를 사용 중이라면, 다음 명령어를 실행해 metric-server를 +활성화할 수 있다. ```shell minikube addons enable metrics-server @@ -52,7 +53,8 @@ v1beta1.metrics.k8s.io ## 네임스페이스 생성 -이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 네임스페이스를 생성한다. +이 예제에서 생성할 자원과 클러스터 내 나머지를 분리하기 위해 +네임스페이스를 생성한다. ```shell kubectl create namespace mem-example @@ -110,8 +112,9 @@ resources: kubectl top pod memory-demo --namespace=mem-example ``` -출력은 파드가 약 150MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. -이는 파드의 100 MiB 요청 보다 많으나 파드의 200 MiB 상한보다는 적다. +출력은 파드가 약 150 MiB 해당하는 약 162,900,000 바이트 메모리를 사용하는 것을 보여준다. +이는 파드의 100 MiB 요청 보다 많으나 +파드의 200 MiB 상한보다는 적다. ``` NAME CPU(cores) MEMORY(bytes) @@ -138,7 +141,7 @@ kubectl delete pod memory-demo --namespace=mem-example {{< codenew file="pods/resource/memory-request-limit-2.yaml" >}} -구성 파일의 'args' 섹션에서 컨테이너가 +구성 파일의 `args` 섹션에서 컨테이너가 100 MiB 상한을 훨씬 초과하는 250 MiB의 메모리를 할당하려는 것을 볼 수 있다. 파드 생성: @@ -242,7 +245,8 @@ kubectl delete pod memory-demo-2 --namespace=mem-example 이 예제에서는 메모리 요청량이 너무 커 클러스터 내 모든 노드의 용량을 초과하는 파드를 생성한다. 다음은 클러스터 내 모든 노드의 용량을 초과할 수 있는 1000 GiB 메모리 요청을 포함하는 -컨테이너를 갖는 파드의 구성 파일이다. +컨테이너를 갖는 +파드의 구성 파일이다. {{< codenew file="pods/resource/memory-request-limit-3.yaml" >}} @@ -302,8 +306,7 @@ kubectl delete pod memory-demo-3 --namespace=mem-example 컨테이너에 메모리 상한을 지정하지 않으면 다음 중 하나가 적용된다. * 컨테이너가 사용할 수 있는 메모리 상한은 없다. 컨테이너가 -실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행 될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 -없는 컨테이너가 종료될 가능성이 크다. +실행 중인 노드에서 사용 가능한 모든 메모리를 사용하여 OOM Killer가 실행될 수 있다. 또한 메모리 부족으로 인한 종료 시 메모리 상한이 없는 컨테이너가 종료될 가능성이 크다. * 기본 메모리 상한을 갖는 네임스페이스 내에서 실행중인 컨테이너는 자동으로 기본 메모리 상한이 할당된다. 클러스터 관리자들은 @@ -356,3 +359,6 @@ kubectl delete namespace mem-example * [API 오브젝트에 할당량 구성 ](/docs/tasks/administer-cluster/quota-api-object/) + + + diff --git a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md index 2e6356b89620b..cff2ae900dc72 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -1,22 +1,23 @@ --- title: 초기화 컨테이너에 대한 구성 -content_template: templates/task +content_type: task weight: 130 --- -{{% capture overview %}} + 이 페이지는 애플리케이션 실행 전에 파드를 초기화하기 위해 어떻게 초기화 컨테이너를 구성해야 하는지 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## 초기화 컨테이너를 갖는 파드 생성 @@ -78,9 +79,10 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다.

Kubernetes is open source giving you the freedom to take advantage ...

... -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [같은 파드 내 실행 중인 컨테이너들간 통신](/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)에 대해 배우기. @@ -88,4 +90,6 @@ init-demo 파드 내 실행 중인 nginx 컨테이너의 셸을 실행한다. * [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 배우기. * [초기화 컨테이너 디버깅](/docs/tasks/debug-application-cluster/debug-init-containers/)에 대해 배우기. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 662b7528bcd39..939919b2e6594 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -7,7 +7,7 @@ weight: 100 이 페이지는 프라이빗 도커 레지스트리나 리포지터리로부터 이미지를 받아오기 위해 시크릿(Secret)을 -사용하는 파드(Pod)를 생성하는 방법을 보여준다. +사용하는 파드를 생성하는 방법을 보여준다. diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md new file mode 100644 index 0000000000000..a6ddeae8fb3f6 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -0,0 +1,238 @@ +--- + + +title: 스태틱(static) 파드 생성하기 +weight: 170 +content_template: task +--- + + + + +*스태틱 파드* 는 {{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +없이 특정 노드에 있는 kubelet 데몬에 의해 +직접 관리된다. +컨트롤 플레인에 의해 관리되는 파드(예를 들어 {{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})와는 달리, +kubelet 이 각각의 스태틱 파드를 감시한다. +(만약 충돌이 날 경우 다시 구동한다.) + +스태틱 파드는 항상 특정 노드에 있는 하나의 {{< glossary_tooltip term_id="kubelet" >}}에 매여 있다. + +Kubelet 은 각각의 스태틱 파드에 대하여 쿠버네티스 API 서버에서 {{< glossary_tooltip text="미러 파드(mirror pod)" term_id="mirror-pod" >}}를 +생성하려고 자동으로 시도한다. +즉, 노드에서 구동되는 파드는 API 서버에 의해서 볼 수 있지만, +API 서버에서 제어될 수는 없다. + +{{< note >}} +만약 클러스터로 구성된 쿠버네티스를 구동하고 있고, 스태틱 파드를 사용하여 +모든 노드에서 파드를 구동하고 있다면, +스태틱 파드를 사용하는 대신 {{< glossary_tooltip text="데몬셋(DaemonSet)" term_id="daemonset" >}} +을 사용하는 것이 바람직하다. +{{< /note >}} + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, +노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. +다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. + + + + + + + +## 스태틱 파드 생성하기 {#static-pod-creation} + +[파일 시스템이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#configuration-files)이나 [웹이 호스팅 하는 구성 파일](/ko/docs/tasks/configure-pod-container/static-pod/#pods-created-via-http)을 사용하여 스태틱 파드를 구성할 수 있다. + +### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} + +매니페스트는 특정 디렉토리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉토리를 정기적으로 스캔하여, 디렉토리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +Kubelet 이 특정 디렉토리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. + +예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. + +1. 스태틱 파드를 실행할 노드를 선택한다. 이 예제에서는 `my-model` 이다. + + ```shell + ssh my-node1 + ``` + +2. `/etc/kubelet.d` 와 같은 디렉토리를 선택하고 웹 서버 파드의 정의를 해당 위치에, 예를 들어 `/etc/kubelet.d/static-web.yaml` 에 배치한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + mkdir /etc/kubelet.d/ + cat </etc/kubelet.d/static-web.yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + EOF + ``` + +3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉토리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: ` 필드를 추가한다. + +4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} + +Kubelet은 `--manifest-url=` 의 인수로 지정된 파일을 주기적으로 다운로드하여 +해당 파일을 파드의 정의가 포함된 JSON/YAML 파일로 해석한다. +[파일시스템이 호스팅 하는 매니페스트](#configuration-files) 의 작동 방식과 +유사하게 kubelet은 스케줄에 맞춰 매니페스트 파일을 다시 가져온다. 스태틱 파드의 목록에 +변경된 부분이 있을 경우, kubelet 은 이를 적용한다. + +이 방법을 사용하기 위하여 다음을 수행한다. + +1. kubelet 에게 파일의 URL을 전달하기 위하여 YAML 파일을 생성하고 이를 웹 서버에 저장한다. + + ```yaml + apiVersion: v1 + kind: Pod + metadata: + name: static-web + labels: + role: myrole + spec: + containers: + - name: web + image: nginx + ports: + - name: web + containerPort: 80 + protocol: TCP + ``` + +2. 선택한 노드에서 `--manifest-url=` 을 실행하여 웹 메니페스트를 사용하도록 kubelet을 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 수정한다. + + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=" + ``` + +3. Kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. + + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` + +## 스태틱 파드 행동 관찰하기 {#behavior-of-static-pods} + +Kubelet 을 시작하면, 정의된 모든 스태틱 파드가 자동으로 시작된다. +스태틱 파드를 정의하고, kubelet을 재시작했으므로, 새로운 스태틱 +파드가 이미 실행 중이어야 한다. + +(노드에서) 구동되고 있는 (스태틱 파드를 포함한) 컨테이너들을 볼 수 있다. +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker ps +``` + +결과는 다음과 유사하다. + +``` +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c +``` + +API 서버에서 미러 파드를 볼 수 있다. + +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 2m +``` + +{{< note >}} +Kubelet에 API 서버에서 미러 파드를 생성할 수 있는 권한이 있는지 미리 확인해야 한다. 그렇지 않을 경우 API 서버에 의해서 생성 요청이 거부된다. +[파드시큐리티폴리시(PodSecurityPolicy)](/docs/concepts/policy/pod-security-policy/) 에 대해 보기. +{{< /note >}} + + +스태틱 파드에 있는 {{< glossary_tooltip term_id="label" text="레이블" >}} 은 +미러 파드로 전파된다. {{< glossary_tooltip term_id="selector" text="셀렉터" >}} 등을 +통하여 이러한 레이블을 사용할 수 있다. + +만약 API 서버로부터 미러 파드를 지우기 위하여 `kubectl` 을 사용하려 해도, +kubelet 은 스태틱 파드를 지우지 _않는다._ + +```shell +kubectl delete pod static-web-my-node1 +``` +``` +pod "static-web-my-node1" deleted +``` +파드가 여전히 구동 중인 것을 볼 수 있다. +```shell +kubectl get pods +``` +``` +NAME READY STATUS RESTARTS AGE +static-web-my-node1 1/1 Running 0 12s +``` + +kubelet 이 구동 중인 노드로 돌아가서 도커 컨테이너를 수동으로 +중지할 수 있다. +일정 시간이 지나면, kubelet이 파드를 자동으로 인식하고 다시 시작하는 +것을 볼 수 있다. + +```shell +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +docker stop f6d05272b57e # 예제를 수행하는 사용자의 컨테이너 ID로 변경한다. +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +``` + +## 스태틱 파드의 동적 추가 및 제거 + +실행 중인 kubelet 은 주기적으로, 설정된 디렉토리(예제에서는 `/etc/kubelet.d`)에서 변경 사항을 스캔하고, 이 디렉토리에 새로운 파일이 생성되거나 삭제될 경우, 파드를 생성/삭제 한다. + +```shell +# 예제를 수행하는 사용자가 파일시스템이 호스팅하는 스태틱 파드 설정을 사용한다고 가정한다. +# kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. +# +mv /etc/kubelet.d/static-web.yaml /tmp +sleep 20 +docker ps +# 구동 중인 nginx 컨테이너가 없는 것을 확인한다. +mv /tmp/static-web.yaml /etc/kubelet.d/ +sleep 20 +docker ps +``` +``` +CONTAINER ID IMAGE COMMAND CREATED ... +e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +``` diff --git a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index b59e62f067bc2..246e6af3bba8d 100644 --- a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -3,7 +3,7 @@ title: 파드 실패의 원인 검증하기 content_template: templates/task --- -{{% capture overview %}} + 이 페이지는 컨테이너 종료 메시지를 읽고 쓰는 방법을 보여준다. @@ -16,17 +16,18 @@ content_template: templates/task 일반 [쿠버네티스 로그](/ko/docs/concepts/cluster-administration/logging/)에도 쓰여져야 한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -{{% /capture %}} -{{% capture steps %}} + + ## 종료 메시지 읽기 및 쓰기 @@ -82,6 +83,11 @@ content_template: templates/task 쿠버네티스가 종료 메시지를 검색할 때 다른 파일을 사용하도록 조정할 수 있다. 쿠버네티스는 지정된 파일의 내용을 사용하여 컨테이너의 성공 및 실패에 대한 상태 메시지를 채운다. +종료 메시지는 assertion failure 메세지처럼 간결한 최종 상태로 생성된다. +kubelet은 4096 바이트보다 긴 메시지를 자른다. 모든 컨테이너의 총 메시지 길이는 +12KiB로 제한된다. 기본 종료 메시지 경로는 `/dev/termination-log`이다. +파드가 시작된 후에는 종료 메시지 경로를 설정할 수 없다. + 다음의 예제에서 컨테이너는, 쿠버네티스가 조회할 수 있도록 `/tmp/my-log` 파일에 종료 메시지를 기록한다. @@ -105,13 +111,16 @@ spec: 쿠버네티스가 컨테이너 로그 출력의 마지막 청크를 사용하도록 지시할 수 있다. 로그 출력은 2048 바이트나 80 행 중 더 작은 값으로 제한된다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) 에 있는 `terminationMessagePath` 에 대해 읽어보기. * [로그 검색](/docs/concepts/cluster-administration/logging/)에 대해 배워보기. * [Go 템플릿](https://golang.org/pkg/text/template/)에 대해 배워보기. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md b/content/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring.md index 9677ccd1b996e..34c51ad860fa7 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 @@ -18,15 +18,11 @@ title: 리소스 모니터링 도구 -쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. -신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 -메트릭 파이프라인](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 -수집할 수 있다. +쿠버네티스에서 애플리케이션 모니터링은 단일 모니터링 솔루션에 의존하지 않는다. 신규 클러스터에서는, [리소스 메트릭](#리소스-메트릭-파이프라인) 또는 [완전한 메트릭](#완전한-메트릭-파이프라인) 파이프라인으로 모니터링 통계를 수집할 수 있다. ## 리소스 메트릭 파이프라인 -리소스 메트릭 파이프라인은 -[Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) +리소스 메트릭 파이프라인은 [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale) 컨트롤러와 같은 클러스터 구성요소나 `kubectl top` 유틸리티에 관련되어 있는 메트릭들로 제한된 집합을 제공한다. 이 메트릭은 경량의 단기 인메모리 저장소인 [metrics-server](https://github.com/kubernetes-incubator/metrics-server)에 diff --git a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md index e299d4db512d5..1a72dbf241811 100644 --- a/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md +++ b/content/ko/docs/tasks/extend-kubectl/kubectl-plugins.md @@ -1,23 +1,24 @@ --- title: 플러그인으로 kubectl 확장 description: kubectl 플러그인을 사용하면, 새로운 하위 명령을 추가하여 kubectl 명령의 기능을 확장할 수 있다. -content_template: templates/task +content_type: task --- -{{% capture overview %}} + 이 가이드는 [kubectl](/docs/reference/kubectl/kubectl/) 확장을 설치하고 작성하는 방법을 보여준다. 핵심 `kubectl` 명령을 쿠버네티스 클러스터와 상호 작용하기 위한 필수 구성 요소로 생각함으로써, 클러스터 관리자는 플러그인을 이러한 구성 요소를 활용하여 보다 복잡한 동작을 만드는 수단으로 생각할 수 있다. 플러그인은 새로운 하위 명령으로 `kubectl` 을 확장하고, 주요 배포판에 포함되지 않은 `kubectl` 의 새로운 사용자 정의 기능을 허용한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + 동작하는 `kubectl` 바이너리가 설치되어 있어야 한다. -{{% /capture %}} -{{% capture steps %}} + + ## kubectl 플러그인 설치 @@ -372,9 +373,10 @@ kubectl 플러그인의 배포 패키지를 컴파일된 패키지를 사용 가능하게 하거나, Krew를 사용하면 설치가 더 쉬워진다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * Go로 작성된 플러그인의 [자세한 예제](https://github.com/kubernetes/sample-cli-plugin)에 대해서는 @@ -383,4 +385,4 @@ kubectl 플러그인의 배포 패키지를 [SIG CLI 팀](https://github.com/kubernetes/community/tree/master/sig-cli)에 문의한다. * kubectl 플러그인 패키지 관리자인 [Krew](https://krew.dev/)에 대해 읽어본다. -{{% /capture %}} + 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 21fcf9e9c294e..c7057c1887f4b 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 @@ -30,7 +30,7 @@ weight: 20 이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 `DEMO_GREETING` 이라는 이름과 `"Hello from the environment"`이라는 -값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 파일 +값을 가지는 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다. {{< codenew file="pods/inject/envars.yaml" >}} @@ -63,7 +63,8 @@ weight: 20 1. 셸 안에서, 환경 변수를 나열하기 위해 `printenv` 커맨드를 실행한다. ```shell - root@envar-demo:/# printenv + # 컨테이너 내 셸에서 다음을 실행한다. + printenv ``` 출력은 아래와 비슷할 것이다. @@ -81,12 +82,24 @@ weight: 20 {{< note >}} `env` 나 `envFrom` 필드를 이용해 설정된 환경 변수들은 컨테이너 이미지 -안에서 명시된 어떠한 환경 변수들보다 더 우선시된다. +안에서 명시된 모든 환경 변수들을 오버라이딩한다. +{{< /note >}} + +{{< note >}} +환경 변수는 서로를 참조할 수 있으며 사이클이 가능하다. +사용하기 전에 순서에 주의한다. {{< /note >}} ## 설정 안에서 환경 변수 사용하기 -파드의 구성 파일 안에서 정의한 환경 변수는 파드의 컨테이너를 위해 설정하는 커맨드들과 인자들과 같이, 구성 파일 안의 다른 곳에서 사용할 수 있다. 아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 `NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, 그리고 `Kubernetes`로 설정되어 있다. 이들 환경 변수들은 이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 사용된다. +파드의 구성 파일 안에서 정의한 환경 변수는 +파드의 컨테이너를 위해 설정하는 커맨드와 인자들과 같이, +구성 파일 안의 다른 곳에서 사용할 수 있다. +아래의 구성 파일 예시에서, `GREETING`, `HONORIFIC`, 그리고 +`NAME` 환경 변수들이 각각 `Warm greetings to`, `The Most honorable`, +그리고 `Kubernetes`로 설정되어 있다. 이 환경 변수들은 +이후 `env-print-demo` 컨테이너에 전달되어 CLI 인자에서 +사용된다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md index a1c3ba02dc8a7..60aa4f4d1a069 100644 --- a/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/rollback-daemon-set.md @@ -1,27 +1,30 @@ --- title: 데몬셋(DaemonSet)에서 롤백 수행 -content_template: templates/task +content_type: task weight: 20 --- -{{% capture overview %}} + + + 이 페이지는 데몬셋에서 롤백을 수행하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + * 데몬셋 롤아웃 기록과 데몬셋 롤백 기능은 쿠버네티스 버전 1.7 이상의 `kubectl` 에서만 지원된다. * [데몬셋에서 롤링 업데이트를 수행](/ko/docs/tasks/manage-daemon/update-daemon-set/)하는 방법을 알고 있어야 한다. -{{% /capture %}} -{{% capture steps %}} + + ## 데몬셋에서 롤백 수행 @@ -102,10 +105,10 @@ kubectl rollout status ds/ daemonset "" successfully rolled out ``` -{{% /capture %}} -{{% capture discussion %}} + + ## 데몬셋 리비전의 이해 @@ -152,4 +155,6 @@ NAME CONTROLLER REVISION AGE * [데몬셋 롤링 업데이트 문제 해결](/ko/docs/tasks/manage-daemon/update-daemon-set/#문제-해결)을 참고한다. -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 78ff27204264d..925f174206245 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -1,24 +1,27 @@ --- title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행 -content_template: templates/task +content_type: task weight: 10 --- -{{% capture overview %}} + + + 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다. -{{% /capture %}} -{{% capture steps %}} + + + ## 데몬셋 업데이트 전략 @@ -188,13 +191,14 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system kubectl delete ds fluentd-elasticsearch -n kube-system ``` -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [태스크: 데몬셋에서 롤백 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. * [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. -{{% /capture %}} + diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 01d6d8331eecf..7ea6b51d93eee 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -1,10 +1,10 @@ --- - - content_type: concept title: GPU 스케줄링 --- + + {{< feature-state state="beta" for_k8s_version="v1.10" >}} @@ -98,7 +98,7 @@ kubectl create -f https://raw.githubusercontent.com/RadeonOpenCompute/k8s-device - Kubelet은 자신의 컨테이너 런타임으로 도커를 사용해야 한다. - 도커는 runc 대신 `nvidia-container-runtime` 이 [기본 런타임](https://github.com/NVIDIA/k8s-device-plugin#preparing-your-gpu-nodes)으로 설정되어야 한다. -- NVIDIA 드라이버의 버전은 조건 ~= 361.93 을 만족해야 한다. +- NVIDIA 드라이버의 버전은 조건 ~= 384.81을 만족해야 한다. 클러스터가 실행 중이고 위의 요구 사항이 만족된 후, NVIDIA 디바이스 플러그인을 배치하기 위해서는 아래 명령어를 실행한다. diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md index c48a11ab56eeb..9d4e4ca2b38bb 100644 --- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -1,18 +1,19 @@ --- title: HugePages 관리 -content_template: templates/task +content_type: task --- -{{% capture overview %}} + {{< feature-state state="stable" >}} 쿠버네티스는 **GA** 기능으로 파드의 애플리케이션에 미리 할당된 huge page의 할당과 사용을 지원한다. 이 페이지에서는 사용자가 huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한다. -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} + 1. 쿠버네티스 노드는 노드에 대한 huge page 용량을 보고하기 위해 huge page를 미리 할당해야 한다. 노드는 여러 크기의 huge page를 미리 할당할 수 @@ -21,9 +22,9 @@ huge page를 사용하는 방법과 현재의 제약 사항에 대해 설명한 노드는 모든 huge page 리소스를 스케줄 가능한 리소스로 자동 검색하고 보고한다. -{{% /capture %}} -{{% capture steps %}} + + ## API @@ -123,4 +124,5 @@ term_id="kube-apiserver" >}} (`--feature-gates=HugePageStorageMediumSize=true`) - NUMA 지역성(locality)은 서비스 품질(QoS)의 기능으로 보장할 예정이다. - 리밋레인지(LimitRange)를 지원할 예정이다. -{{% /capture %}} + + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md index 7c81129176339..87469281c99d2 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/declarative-config.md @@ -65,7 +65,7 @@ weight: 10 kubectl apply -f <디렉터리>/ ``` -이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` +이것은 각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` 어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던 오브젝트 구성 파일의 내용을 포함한다.  @@ -78,9 +78,11 @@ kubectl apply -f <디렉터리>/ {{< codenew file="application/simple_deployment.yaml" >}} 생성될 오브젝트를 출력하려면 `kubectl diff`를 실행한다.  + ```shell kubectl diff -f https://k8s.io/examples/application/simple_deployment.yaml ``` + {{< note >}} `diff`는 `kube-apiserver`의 활성화가 필요한 [서버사이드 dry-run](/docs/reference/using-api/api-concepts/#dry-run)을 사용한다. @@ -1000,8 +1002,10 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md index 47089a10dc480..ddf2c2f1b9274 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-command.md @@ -164,8 +164,10 @@ kubectl create --edit -f /tmp/srv.yaml ## {{% heading "whatsnext" %}} + * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(명령형)](/ko/docs/tasks/manage-kubernetes-objects/imperative-config/) * [오브젝트 구성을 이용하여 쿠버네티스 관리하기(선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md index ca6d1de04d920..927c6df079394 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/imperative-config.md @@ -147,8 +147,10 @@ template: ## {{% heading "whatsnext" %}} + * [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/tasks/manage-kubernetes-objects/imperative-command/) * [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/ko/docs/tasks/manage-kubernetes-objects/declarative-config/) * [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md new file mode 100644 index 0000000000000..ce5f030622afa --- /dev/null +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -0,0 +1,88 @@ +--- +title: 스테이트풀셋(StatefulSet) 삭제하기 +content_type: task +weight: 60 +--- + + + +이 작업은 {{< glossary_tooltip term_id="StatefulSet"text="스테이트풀셋">}}을 삭제하는 방법을 설명한다. + + + +## {{% heading "prerequisites" %}} + + +* 이 작업은 클러스터에 스테이트풀셋으로 표시되는 애플리케이션이 있다고 가정한다. + + + + + +## 스테이트풀셋 삭제 + +쿠버네티스에서 다른 리소스를 삭제하는 것과 같은 방식으로 스테이트풀셋을 삭제할 수 있다. `kubectl delete` 명령어를 사용하고 파일 또는 이름으로 스테이트풀셋을 지정하자. + +```shell +kubectl delete -f +``` + +```shell +kubectl delete statefulsets +``` + +스테이트풀셋 자체를 삭제한 후 연결된 헤드리스 서비스는 별도로 삭제해야 할 수도 있다. + +```shell +kubectl delete service +``` + +kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다. +파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다. + +```shell +kubectl delete -f --cascade=false +``` + +`kubectl delete` 에 `--cascade=false` 를 사용함으로써, 스테이트풀셋 객체가 삭제 된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. + +```shell +kubectl delete pods -l app=myapp +``` + +### 퍼시스턴트볼륨(PersistentVolume) + +스테이트풀셋의 파드들을 삭제하는 것이 연결된 볼륨을 삭제하는 것은 아니다. 이것은 볼륨을 삭제하기 전에 볼륨에서 데이터를 복사할 수 있는 기회를 준다. 파드들이 [terminating 상태](/ko/docs/concepts/workloads/pods/pod/#termination-of-pods)가 된 후 PVC를 삭제하는 것은 스토리지클래스(StorageClass) 와 반환 정책에 따라 백업 퍼시스턴트볼륨이 삭제될 수도 있다. 클레임 삭제 후 볼륨에 접근할 수 있다고 가정하면 안된다. + +{{< note >}} +PVC를 삭제할 때 데이터 손실될 수 있음에 주의하자. +{{< /note >}} + +### 스테이트풀셋의 완벽한 삭제 + +연결된 파드를 포함해서 스테이트풀셋의 모든 것을 간단히 삭제하기 위해 다음과 같이 일련의 명령을 실행 한다. + +```shell +grace=$(kubectl get pods --template '{{.spec.terminationGracePeriodSeconds}}') +kubectl delete statefulset -l app=myapp +sleep $grace +kubectl delete pvc -l app=myapp + +``` + +위의 예에서 파드에는 `app=myapp` 라는 레이블이 있다. 사용자에게 적절한 레이블로 대체하자. + +### 스테이트풀셋 파드의 강제 삭제 + +스테이트풀셋의 일부 파드가 오랫동안 'Terminating' 또는 'Unknown' 상태에 있는 경우, apiserver에 수동적으로 개입하여 파드를 강제 삭제할 수도 있다. 이것은 잠재적으로 위험한 작업이다. 자세한 설명은 [스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)를 참고한다. + + + +## {{% heading "whatsnext" %}} + + +[스테이트풀셋 파드 강제 삭제하기](/docs/tasks/run-application/force-delete-stateful-set-pod/)에 대해 더 알아보기. + + + + 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 fdf1f75411f2b..6b294b78509e2 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 @@ -8,7 +8,7 @@ weight: 100 Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 -레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. +레플리케이션 컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/ko/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. 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 c2426951654d1..2362c7f47519f 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -9,13 +9,17 @@ content_type: concept weight: 90 --- + + + + Horizontal Pod Autoscaler는 CPU 사용량 (또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), 아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 -컨트롤러, 디플로이먼트, 레플리카 셋 또는 스테이트풀 셋의 파드 개수를 자동으로 스케일한다. Horizontal -Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다. +컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal +Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다. Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다. 리소스는 컨트롤러의 동작을 결정한다. @@ -160,11 +164,7 @@ HPA가 여전히 확장할 수 있음을 의미한다. 마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 -사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 -`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트 -동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한 -스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을 -사용하여 설정할 수 있고, 기본 값은 5분이다. +사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본값은 5분이다. 즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 영향을 완만하게 한다. @@ -233,11 +233,6 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대 있다. {{< /note >}} -v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds` -를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다. -[구성가능한 스케일링 -동작 지원](#구성가능한-스케일링-동작-지원)을 본다. - ## 멀티 메트릭을 위한 지원 Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API @@ -265,7 +260,7 @@ Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용 기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한 API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. -* [API 집합 레이어](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 활성화 +* [API 애그리게이션 레이어](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 활성화 * 해당 API 등록: @@ -445,3 +440,4 @@ behavior: * kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). * [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제. + diff --git a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md index 37ed18a70acd3..8642c374af7ed 100644 --- a/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md +++ b/content/ko/docs/tasks/run-application/run-single-instance-stateful-application.md @@ -1,37 +1,39 @@ --- title: 단일 인스턴스 스테이트풀 애플리케이션 실행하기 -content_template: templates/tutorial +content_type: tutorial weight: 20 --- -{{% capture overview %}} + 이 페이지에서는 쿠버네티스 클러스터에서 퍼시스턴트볼륨(PersistentVolume)과 디플로이먼트(Deployment)를 사용하여, 단일 인스턴스 스테이트풀 애플리케이션을 실행하는 방법을 보인다. 해당 애플리케이션은 MySQL이다. -{{% /capture %}} -{{% capture objectives %}} + +## {{% heading "objectives" %}} + * 사용자 환경의 디스크를 참조하는 퍼시스턴트볼륨 생성하기 * MySQL 디플로이먼트 생성하기 * 알려진 DNS 이름으로 클러스터의 다른 파드에 MySQL 서비스 노출하기 -{{% /capture %}} -{{% capture prerequisites %}} + +## {{% heading "prerequisites" %}} * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * {{< include "default-storage-class-prereqs.md" >}} -{{% /capture %}} -{{% capture lessoncontent %}} + + + ## MySQL 배포하기 @@ -180,10 +182,11 @@ kubectl delete pv mysql-pv-volume 일부 동적 프로비저너(EBS 와 PD와 같은)는 퍼시스턴트볼륨을 삭제할 때에 기본 리소스도 해제한다. -{{% /capture %}} -{{% capture whatsnext %}} + +## {{% heading "whatsnext" %}} + * [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워 보기 @@ -193,4 +196,6 @@ kubectl delete pv mysql-pv-volume * [볼륨](/ko/docs/concepts/storage/volumes/)과 [퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/) -{{% /capture %}} + + + diff --git a/content/ko/docs/tasks/tls/_index.md b/content/ko/docs/tasks/tls/_index.md new file mode 100644 index 0000000000000..8607aa28d29b6 --- /dev/null +++ b/content/ko/docs/tasks/tls/_index.md @@ -0,0 +1,5 @@ +--- +title: "TLS" +weight: 100 +--- + diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md new file mode 100644 index 0000000000000..7f7422411cebb --- /dev/null +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -0,0 +1,83 @@ +--- + + + +title: Kubelet의 인증서 갱신 구성 +content_type: task +--- + + +이 페이지는 kubelet에 대한 인증서 갱신을 활성화하고 구성하는 방법을 보여준다. + + +{{< feature-state for_k8s_version="v1.8" state="beta" >}} + +## {{% heading "prerequisites" %}} + + +* 쿠버네티스 1.8.0 버전 혹은 그 이상의 버전이 요구됨 + + + + + +## 개요 + +kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. +기본적으로 이러한 인증서는 1년 만기로 발급되므로 +너무 자주 갱신할 필요는 없다. + +쿠버네티스 1.8은 [kubelet 인증서 +갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며, +이 기능은 현재 인증서의 만료 시한이 임박한 경우, +새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다. +새로운 인증서를 사용할 수 있게 되면 +쿠버네티스 API에 대한 연결을 인증하는데 사용된다. + +## 클라이언트 인증서 갱신 활성화하기 + +`kubelet` 프로세스는 현재 사용 중인 인증서의 만료 시한이 다가옴에 따라 +kubelet이 자동으로 새 인증서를 요청할지 여부를 제어하는 +`--rotate-certificates` 인자를 허용한다. +인증서 갱신은 베타 기능이므로 기능 플래그는 +`--feature-gates = RotateKubeletClientCertificate=true` 를 사용하여 활성화해야 한다. + + +`kube-controller-manager` 프로세스는 얼마나 오랜 기간 인증서가 유효한지를 제어하는 +`--experimental-cluster-signing-duration` 인자를 +허용한다. + +## 인증서 갱신 구성에 대한 이해 + +kubelet이 시작할 때 부트 스트랩 (`--bootstrap-kubeconfig` 플래그를 사용) +을 구성하면 초기 인증서를 사용하여 쿠버네티스 API에 연결하고 +인증서 서명 요청을 발행한다. +다음을 사용하여 인증서 서명 요청 상태를 볼 수 있다. + +```sh +kubectl get csr +``` + +초기에 노드의 kubelet에서 인증서 서명 요청은 `Pending` 상태이다. +인증서 서명 요청이 특정 기준을 충족하면 컨트롤러 관리자가 +자동으로 승인한 후 상태가 `Approved` 가 된다. +다음으로, 컨트롤러 관리자는 +`--experimental-cluster-signing-duration` 파라미터에 의해 지정된 기간 동안 +발행된 인증서에 서명하고 +서명된 인증서는 인증서 서명 요청에 첨부된다. + +kubelet은 쿠버네티스 API로 서명된 인증서를 가져와서 +`--cert-dir`에 지정된 위치에 디스크에 기록한다. +그런 다음 kubelet은 쿠버네티스 API에 연결해서 새로운 인증서를 사용한다. + +서명된 인증서의 만료가 다가오면 kubelet은 쿠버네티스 API를 사용하여 +새로운 인증서 서명 요청을 자동으로 발행한다. +또한, 컨트롤러 관리자는 인증서 요청을 자동으로 승인하고 +서명된 인증서를 인증서 서명 요청에 첨부한다. +kubelet은 쿠버네티스 API로 서명된 새로운 인증서를 가져와서 디스크에 쓴다. +그런 다음 새로운 인증서를 사용한 재연결을 위해서 +가지고 있는 쿠버네티스 API로의 연결을 업데이트 한다. + + + + diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 386d606769e60..dc43810c143f9 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -200,7 +200,6 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{% /tab %}} {{< /tabs >}} - ## 설치 확인 하이퍼바이저와 Minikube의 성공적인 설치를 확인하려면, 다음 명령어를 실행해서 로컬 쿠버네티스 클러스터를 시작할 수 있다. @@ -211,6 +210,10 @@ Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Mini {{< /note >}} +{{< caution >}} +KVM을 사용할 때 Debian과 다른 시스템에서 libvirt의 기본 QEMU URI는 `qemu:///session`이고, Minikube의 기본 QEMU URI는 `qemu:///system`이다. 시스템이 이런 환경이라면, `--kvm-qemu-uri qemu:///session`을 `minikube start`에 전달해야 한다. +{{< /caution >}} + ```shell minikube start --driver= ``` @@ -256,4 +259,4 @@ minikube delete ## {{% heading "whatsnext" %}} -* [Minikube로 로컬에서 쿠버네티스 실행하기](/docs/setup/minikube/) +* [Minikube로 로컬에서 쿠버네티스 실행하기](/ko/docs/setup/learning-environment/minikube/) diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 7a3ca934e085b..4a18224f02275 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -69,9 +69,8 @@ content_type: concept ## {{% heading "whatsnext" %}} -튜토리얼을 작성하고 싶다면, -튜토리얼 페이지 유형과 튜토리얼 템플릿에 대한 정보가 있는 -[Using Page Templates](/docs/home/contribute/page-templates/) +튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는 +[내용 페이지 유형](/docs/contribute/style/page-content-types/) 페이지를 참조한다. diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index a168b521e1021..803b58594cd55 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -1,9 +1,10 @@ --- -reviewers: title: AppArmor content_type: tutorial --- + + {{< feature-state for_k8s_version="v1.4" state="beta" >}} @@ -13,7 +14,7 @@ AppArmor는 표준 리눅스 사용자와 그룹 기반의 권한을 보완하 프로그램을 제한하는 리눅스 커널 보안 모듈이다. AppArmor는 임의의 애플리케이션에 대해서 잠재적인 공격 범위를 줄이고 더욱 심층적인 방어를 제공하도록 구성할 수 있다. 이 기능은 특정 프로그램이나 컨테이너에서 필요한 리눅스 기능, 네트워크 사용, 파일 권한 등에 대한 -접근 허용 목록 조정한 프로파일로 구성한다. 각 프로파일은 +접근을 허용하는 프로파일로 구성한다. 각 프로파일은 허용하지 않은 리소스 접근을 차단하는 *강제(enforcing)* 모드 또는 위반만을 보고하는 *불평(complain)* 모드로 실행할 수 있다. @@ -29,7 +30,7 @@ AppArmor를 이용하면 컨테이너가 수행할 수 있는 작업을 제한 * 노드에 프로파일을 어떻게 적재하는지 예시를 본다. -* 파드(Pod)에 프로파일을 어떻게 강제 적용하는지 배운다. +* 파드에 프로파일을 어떻게 강제 적용하는지 배운다. * 프로파일이 적재되었는지 확인하는 방법을 배운다. * 프로파일을 위반하는 경우를 살펴본다. * 프로파일을 적재할 수 없을 경우를 살펴본다. diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index d579a7b7d6410..4549694159e94 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -97,6 +97,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. ```shell kubectl get pods ``` + 다음과 유사하게 출력된다. ``` diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index e411c4f8abfdf..24405ac955ca9 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -30,7 +30,7 @@

애플리케이션을 스케일하기

지난 모듈에서 디플로이먼트를 만들고, 서비스를 통해서 디플로이먼트를 외부에 노출시켜 봤다. 해당 디플로이먼트는 애플리케이션을 구동하기 위해 단 - 하나의 파드(Pod)만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 + 하나의 파드만을 생성했었다. 트래픽이 증가하면, 사용자 요청에 맞추어 애플리케이션의 규모를 조정할 필요가 있다.

디플로이먼트의 복제 수를 변경하면 스케일링이 수행된다

diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 10e7aa76831c5..d384d076556f1 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -7,7 +7,7 @@ weight: 10 이 튜토리얼은 스테이트풀셋([StatefulSets](/ko/docs/concepts/workloads/controllers/statefulset/))을 이용하여 -애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드(Pod)을 생성하고 삭제하며 +애플리케이션을 관리하는 방법을 소개한다. 어떻게 스테이트풀셋의 파드를 생성하고 삭제하며 스케일링하고 업데이트하는지 시연한다. diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index f67516cb80941..ea6b3063cc7dc 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -1,10 +1,11 @@ --- title: "예시: 카산드라를 스테이트풀셋으로 배포하기" -reviewers: content_type: tutorial weight: 30 --- + + 이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. @@ -24,7 +25,6 @@ weight: 30 {{< /note >}} - ## {{% heading "objectives" %}} * 카산드라 헤드리스 {{< glossary_tooltip text="Service" term_id="service" >}}를 생성하고 검증한다. @@ -36,18 +36,9 @@ weight: 30 ## {{% heading "prerequisites" %}} -이 튜토리얼을 완료하려면, [파드](/ko/docs/concepts/workloads/pods/pod/), [서비스](/ko/docs/concepts/services-networking/service/), [스테이트풀셋](/ko/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 - -* *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. - -* [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)와 - [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)를 다운로드한다. +{{< include "task-tutorial-prereqs.md" >}} -* 실행 중인 쿠버네티스 클러스터를 소유 - -{{< note >}} -아직 클러스터가 없다면 [설치](/ko/docs/setup/)를 읽도록 하자. -{{< /note >}} +이 튜토리얼을 완료하려면 {{< glossary_tooltip text="파드" term_id="pod" >}}, {{< glossary_tooltip text="서비스" term_id="service" >}}, {{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}}에 대한 기본 지식이 있어야 한다. ### 추가적인 Minikube 설정 요령 @@ -274,7 +265,6 @@ kubectl apply -f cassandra-statefulset.yaml - ## {{% heading "whatsnext" %}} @@ -283,3 +273,4 @@ kubectl apply -f cassandra-statefulset.yaml * 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. + diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index d4891dbe39ca5..323a087408988 100644 --- a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -1,6 +1,5 @@ --- title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기" -reviewers: content_type: tutorial weight: 20 card: @@ -9,6 +8,8 @@ card: title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨" --- + + 이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다. diff --git a/content/ko/docs/tutorials/stateful-application/zookeeper.md b/content/ko/docs/tutorials/stateful-application/zookeeper.md index 11120ca54d323..bf4c2e179ccee 100644 --- a/content/ko/docs/tutorials/stateful-application/zookeeper.md +++ b/content/ko/docs/tutorials/stateful-application/zookeeper.md @@ -1095,3 +1095,5 @@ node "kubernetes-node-ixsl" uncordoned 모든 스토리지가 재확보되도록 하자. + + 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 b37497b9bf507..cd8ff4e03f5b7 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 @@ -1,6 +1,5 @@ --- title: "예제: PHP / Redis 방명록 예제에 로깅과 메트릭 추가" -reviewers: content_type: tutorial weight: 21 card: @@ -406,4 +405,3 @@ kubectl scale --replicas=3 deployment/frontend * [로깅 아키텍처](/docs/concepts/cluster-administration/logging/)를 더 읽어본다. * [애플리케이션 검사 및 디버깅](/ko/docs/tasks/debug-application-cluster/)을 더 읽어본다. * [애플리케이션 문제 해결](/ko/docs/tasks/debug-application-cluster/resource-usage-monitoring/)을 더 읽어본다. - diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index bf91733f9be73..422ed877e21cd 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -369,4 +369,3 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 * [애플리케이션 접속](/ko/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 * [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기 -