From b19c5493555a1dfb5424bacf8574cfb89ec578c4 Mon Sep 17 00:00:00 2001 From: June Yi Date: Wed, 29 May 2019 00:30:00 +0900 Subject: [PATCH] Fourth Korean localization work for release-1.14 (#14578) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit is the fourth Korean l10n work for release-1.14. Change List * Translate concepts/overview/object-management-kubectl/declarative-config in Korean (#14285) * translate cron-jobs.md to korean + add _index.md (#14024) * ko: update outdated files in dev-1.14-ko.4 #14207 (#14347) * Translate standardized glossary Tag Workload in Korean (#14208) * translate to content/ko/docs/concepts/cluster-administration/controll… (#14234) * ko: update concepts, contribute, tasks in dev-1.14-ko.4 #14207 (#14502) * ko: update cheatsheet in dev-1.14-ko.4 (#14515) Co-Authored-By: Woojin Na(Eddie) Co-Authored-By: Kim Young Dae <38598117+zer0big@users.noreply.github.com> Co-Authored-by: Claudia J. Kang Co-authored-by: Yoon Co-authored-by: June Yi Co-authored-by: Seokho --- content/ko/docs/concepts/_index.md | 11 +- .../controller-metrics.md | 48 + .../ko/docs/concepts/overview/components.md | 20 +- .../declarative-config.md | 990 ++++++++++++++++++ .../concepts/overview/what-is-kubernetes.md | 150 +-- .../working-with-objects/namespaces.md | 48 +- .../concepts/workloads/controllers/_index.md | 4 + .../workloads/controllers/cron-jobs.md | 49 + .../concepts/workloads/pods/pod-lifecycle.md | 242 +++-- content/ko/docs/contribute/_index.md | 33 +- content/ko/docs/contribute/participating.md | 166 +-- .../docs/reference/glossary/app-container.md | 20 + content/ko/docs/reference/glossary/cronjob.md | 19 + .../glossary/replication-controller.md | 19 + .../ko/docs/reference/glossary/workload.md | 28 + .../ko/docs/reference/kubectl/cheatsheet.md | 6 +- content/ko/docs/setup/minikube.md | 59 +- content/ko/docs/setup/pick-right-solution.md | 37 +- .../ko/docs/tasks/tools/install-minikube.md | 87 +- .../explore/explore-intro.html | 2 +- .../ko/docs/tutorials/services/source-ip.md | 6 +- .../stateless-application/guestbook.md | 19 +- .../application/simple_deployment.yaml | 19 + .../application/update_deployment.yaml | 18 + .../ko/examples/pods/config/redis-pod.yaml | 2 +- 25 files changed, 1721 insertions(+), 381 deletions(-) create mode 100644 content/ko/docs/concepts/cluster-administration/controller-metrics.md create mode 100644 content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md create mode 100644 content/ko/docs/concepts/workloads/controllers/_index.md create mode 100644 content/ko/docs/concepts/workloads/controllers/cron-jobs.md create mode 100644 content/ko/docs/reference/glossary/app-container.md create mode 100755 content/ko/docs/reference/glossary/cronjob.md create mode 100755 content/ko/docs/reference/glossary/replication-controller.md create mode 100644 content/ko/docs/reference/glossary/workload.md create mode 100644 content/ko/examples/application/simple_deployment.yaml create mode 100644 content/ko/examples/application/update_deployment.yaml diff --git a/content/ko/docs/concepts/_index.md b/content/ko/docs/concepts/_index.md index 7e1da7d0c9..038501820d 100644 --- a/content/ko/docs/concepts/_index.md +++ b/content/ko/docs/concepts/_index.md @@ -15,11 +15,11 @@ weight: 40 ## 개요 -쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트로* 클러스터에 대해 사용자가 *바라는 상태를* 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다. +쿠버네티스를 사용하려면, *쿠버네티스 API 오브젝트* 로 클러스터에 대해 사용자가 *바라는 상태* 를 기술해야 한다. 어떤 애플리케이션이나 워크로드를 구동시키려고 하는지, 어떤 컨테이너 이미지를 쓰는지, 복제의 수는 몇 개인지, 어떤 네트워크와 디스크 자원을 쓸 수 있도록 할 것인지 등을 의미한다. 바라는 상태를 설정하는 방법은 쿠버네티스 API를 사용해서 오브젝트를 만드는 것인데, 대개 `kubectl`이라는 커맨드라인 인터페이스를 사용한다. 클러스터와 상호 작용하고 바라는 상태를 설정하거나 수정하기 위해서 쿠버네티스 API를 직접 사용할 수도 있다. -일단 바라는 상태를 설정하고 나면, *쿠버네티스 컨트롤 플레인*이 Pod Lifecycle Event Generator (PLEG) 를 사용하여 클러스터의 현재 상태를 바라는 상태와 일치시키기 위한 일을 하게 된다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작 시키거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행할 수 있게 된다. 쿠버네티스 컨트롤 플레인은 클러스터에서 돌아가는 프로세스의 집합으로 구성된다. +바라는 상태를 설정하면, *쿠버네티스 컨트롤 플레인* 은 Pod Lifecycle Event Generator (PLEG) 를 통해 클러스터의 현재 상태를 바라는 상태와 일치시킨다. 그렇게 함으로써, 쿠버네티스가 컨테이너를 시작 또는 재시작하거나, 주어진 애플리케이션의 복제 수를 스케일링하는 등의 다양한 작업을 자동으로 수행한다. 쿠버네티스 컨트롤 플레인은 클러스터에서 실행 중인 프로세스의 묶음(collection)으로 구성된다. -* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 집합이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다. +* **쿠버네티스 마스터**는 클러스터 내 마스터 노드로 지정된 노드 내에서 구동되는 세 개의 프로세스 묶음이다. 해당 프로세스는 [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/) 및 [kube-scheduler](/docs/admin/kube-scheduler/)이다. * 클러스터 내 마스터 노드가 아닌 각각의 노드는 다음 두 개의 프로세스를 구동시킨다. * 쿠버네티스 마스터와 통신하는 **[kubelet](/docs/admin/kubelet/)**. * 각 노드의 쿠버네티스 네트워킹 서비스를 반영하는 네트워크 프록시인 **[kube-proxy](/docs/admin/kube-proxy/)**. @@ -53,7 +53,7 @@ weight: 40 클러스터에 대해 바라는 상태를 유지할 책임은 쿠버네티스 마스터에 있다. `kubectl` 커맨드라인 인터페이스와 같은 것을 사용해서 쿠버네티스로 상호 작용할 때에는 쿠버네티스 마스터와 통신하고 있는 셈이다. -> "마스터"는 클러스터 상태를 관리하는 프로세스의 집합이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다. +> "마스터"는 클러스터 상태를 관리하는 프로세스의 묶음이다. 주로 이 프로세스는 클러스터 내 단일 노드에서 구동되며, 이 노드가 바로 마스터이다. 마스터는 가용성과 중복을 위해 복제될 수도 있다. ### 쿠버네티스 노드 @@ -68,7 +68,8 @@ weight: 40 {{% capture whatsnext %}} -개념 페이지를 작성하기를 원하면, 개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 +개념 페이지를 작성하기를 원하면, +개념 페이지 유형과 개념 템플릿에 대한 정보가 있는 [페이지 템플릿 사용하기](/docs/home/contribute/page-templates/)를 참조한다. {{% /capture %}} diff --git a/content/ko/docs/concepts/cluster-administration/controller-metrics.md b/content/ko/docs/concepts/cluster-administration/controller-metrics.md new file mode 100644 index 0000000000..8a7951eb04 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/controller-metrics.md @@ -0,0 +1,48 @@ +--- +title: 컨트롤러 관리자 메트릭 +content_template: templates/concept +weight: 100 +--- + +{{% capture overview %}} +컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 +중요한 통찰을 제공한다. + +{{% /capture %}} + +{{% capture body %}} +## 컨트롤러 관리자 메트릭은 무엇인가 + +컨트롤러 관리자 메트릭은 컨트롤러 관리자의 성능과 상태에 대한 중요한 통찰을 제공한다. +메트릭은 go_routine count와 같은 일반적인 Go 언어 런타임 메트릭과 +etcd 요청 대기 시간 또는 클라우드 제공자(AWS, GCE, OpenStack) API 대기 시간과 같이 클러스터 상태를 +측정할 수 있는 컨트롤러 특징적 메트릭을 포함한다. + +쿠버네티스 1.7 부터, GCE, AWS, Vsphere 그리고 OpenStack의 저장소 작업에 대한 자세한 클라우드 제공자 메트릭을 사용할 수 있다. +이 메트릭은 영구 볼륨 작업의 상태 감시에 사용될 수 있다. + +예를 들어, GCE의 경우 다음과 같은 메트릭이 호출된다: + +``` +cloudprovider_gce_api_request_duration_seconds { request = "instance_list"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_insert"} +cloudprovider_gce_api_request_duration_seconds { request = "disk_delete"} +cloudprovider_gce_api_request_duration_seconds { request = "attach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "detach_disk"} +cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} +``` + + + +## 구성 + + +클러스터에서 컨트롤러-관리자 메트릭은 컨트롤러-관리자가 실행되고 있는 호스트의 `http://localhost:10252/metrics`를 통해서 +이용 가능하다. + +메트릭은 [프로메테우스 형식](https://prometheus.io/docs/instrumenting/exposition_formats/)에서 나오고, 사람이 읽을 수 있다. + +운영 환경에서는 주기적으로 메트릭을 모으고, 일종의 시계열 데이터베이스로 만들기 위해, +프로메테우스 설정이나 다른 메트릭 수집기를 구성할 것이다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 44bc70e9ed..2248084272 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -16,7 +16,7 @@ card: ## 마스터 컴포넌트 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정 -(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 '레플리카' 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다. +(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다. 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나, 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고, @@ -72,19 +72,21 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 ### kube-proxy -[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서 쿠버네티스 서비스 추상화가 가능하도록 해준다. +[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서 + 쿠버네티스 서비스 추상화가 가능하도록 해준다. ### 컨테이너 런타임 -컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. +컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. 쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 런타임이다. ## 애드온 -애드온은 클러스터 기능을 이행하는 파드와 서비스다. 이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다. 네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다. +애드온은 클러스터 기능을 이행하는 파드와 서비스다. +이 파드는 디플로이먼트, 레플리케이션 컨트롤러, 기타 등등에 의해 관리될 수도 있다. +네임스페이스를 갖는 애드온 오브젝트는 `kube-system` 네임스페이스 내에서 생성되어 진다. -선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 -[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. +선택된 일부 애드온이 아래에 설명되었으며, 사용가능한 전체 확장 애드온 리스트는 [애드온](/docs/concepts/cluster-administration/addons/)을 참조한다. ### DNS @@ -100,11 +102,13 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 ### 컨테이너 리소스 모니터링 -[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은 중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다. +[컨테이너 리소스 모니터링](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)은 +중앙 데이터베이스 내에 컨테이너들에 대한 포괄적인 시계열 메트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공해 준다. ### 클러스터-레벨 로깅 -[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다. +[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은 +검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 가진다. {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md b/content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md new file mode 100644 index 0000000000..3fc67a48c3 --- /dev/null +++ b/content/ko/docs/concepts/overview/object-management-kubectl/declarative-config.md @@ -0,0 +1,990 @@ +--- +title: 구성 파일을 이용한 쿠버네티스 오브젝트의 선언형 관리 +content_template: templates/concept +weight: 40 +--- + +{{% capture overview %}} +쿠버네티스 오브젝트는 여러 개의 오브젝트 구성 파일을 +디렉터리에 저장하고 필요에 따라 `kubectl apply`를 +사용하여 재귀적으로 오브젝트를 생성하고 업데이트함으로써 생성, 업데이트 및 삭제할 수 있다. +이 방식은 변경사항을 되돌려 오브젝트 구성 파일에 병합하지 않고 +활성 오브젝트에 가해진 기록을 유지한다. `kubectl diff`는 또한 +`apply`가 어떠한 변경사항을 이루어질지에 대한 프리뷰를 제공한다. +{{% /capture %}} + +{{% capture body %}} + +## 트레이드 오프 + +`kubectl` 툴은 세 가지 방식의 오브젝트 관리를 지원한다. + +* 명령형 커맨드 +* 명령형 오브젝트 구성 +* 선언형 오브젝트 구성 + +오브젝트 관리 방식의 종류별 장단점에 대한 논의는 [Kubernetes Object Management](/docs/concepts/overview/object-management-kubectl/overview/)를 +참고한다. + +## 시작하기 전에 + +선언형 오브젝트 구성은 쿠버네티스 오브젝트 정의와 +구성에 대한 확실한 이해가 필요하다. 아직 그렇지 못하다면, +먼저 다음 문서를 읽고 이해한다. + +- [명령형 커맨드를 사용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [구성 파일을 사용한 쿠버네티스 오브젝트 명령형 관리](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/) + +다음은 이 문서에서 사용되는 용어에 대한 정의이다. + +- *오브젝트 구성 파일 / 구성 파일*: 쿠버네티스 오브젝트에 대한 + 구성을 정의하는 하나의 파일. 이 주제는 어떻게 + `kubectl apply`에 구성 파일을 전달하는지에 대해 보여준다. 구성 파일은 일반적으로 Git과 같은, 소스 컨트롤에 저장된다. +- *활성 오브젝트 구성 / 활성 구성*: 쿠버네티스 클러스터에 의해 관측된 + 오브젝트에 대한 활성 구성 값. 이것들은 쿠버네티스 클러스터 저장소에 유지된다. + 일반적으로 etcd가 사용된다. +- *선언형 구성 작성자 / 선언형 작성자*: 활성 오브젝트를 업데이트해 주는 + 사람이나 소프트웨어. 이 주제에서 언급하는 활성 작성자는 오브젝트 구성 파일에 변경을 가하고 + `kubectl apply`를 실행하여 변경사항을 기록한다. + +## 오브젝트 생성 방법 + +기존에 존재하는 것을 제외한, 지정한 디렉터리 내 구성 파일에 의해 정의된 모든 오브젝트를 생성하기 위해 `kubectl apply`를 +사용한다. + +```shell +kubectl apply -f <디렉터리>/ +``` + +이것은  각 오브젝트에 대해 `kubectl.kubernetes.io/last-applied-configuration: '{...}'` +어노테이션을 설정한다. 해당 어노테이션은 오브젝트를 생성하기 위해 사용했던 +오브젝트 구성 파일의 내용을 포함한다.  + +{{< note >}} +재귀적으로 디렉터리를 처리하기 위해서 `-R` 플래그를 추가한다.  +{{< /note >}} + +다음은 오브젝트 구성 파일에 대한 예시이다. + +{{< 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)을 사용한다. +{{< /note >}} + +`kubectl apply`를 사용하여 오브젝트를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml +``` + +`kubectl get`을 사용하여 활성 구성을 출력한다. + +```shell +kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml +``` + +출력은 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션이 +활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다. + +```yaml +kind: Deployment +metadata: + annotations: + # ... + # This is the json representation of simple_deployment.yaml + # It was written by kubectl apply when the object was created + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + # ... + minReadySeconds: 5 + selector: + matchLabels: + # ... + app: nginx + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.7.9 + # ... + name: nginx + ports: + - containerPort: 80 + # ... + # ... + # ... + # ... +``` + +## How to update objects + +또한 오브젝트가 기존에 존재하더라도 디렉터리 내 정의된 모든 오브젝트를 업데이트하기 위해 `kubectl apply`를 +사용할 수 있다. 이러한 접근방식은 다음을 수행할 수 있게 해준다. + +1. 활성 구성 내 구성 파일에 나타나는 필드 설정 +2. 활성 구성 내 구성 파일로부터 제거된 필드 정리 + +```shell +kubectl diff -f <디렉터리>/ +kubectl apply -f <디렉터리>/ +``` + +{{< note >}} +재귀적으로 디렉터리를 처리하기 위해서 `-R`플래그를 추가한다. +{{< /note >}} + +다음은 구성 파일의 예시이다. + +{{< codenew file="application/simple_deployment.yaml" >}} + +`kubectl apply`를 사용하여 오브젝트를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml +``` + +{{< note >}} +설명을 위해, 앞선 명령은 디렉터리 대신 +하나의 구성 파일을 참조한다. +{{< /note >}} + +`kubectl get`을 사용하여 활성 구성을 출력한다. + +```shell +kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml +``` + +출력은 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션이 +활성 구성에 기록된 것을 보여주며, 그것은 구성 파일과 일치한다. + +```yaml +kind: Deployment +metadata: + annotations: + # ... + # This is the json representation of simple_deployment.yaml + # It was written by kubectl apply when the object was created + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + # ... + minReadySeconds: 5 + selector: + matchLabels: + # ... + app: nginx + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.7.9 + # ... + name: nginx + ports: + - containerPort: 80 + # ... + # ... + # ... + # ... +``` + +`kubectl scale`을 사용하여 활성 구성 내 `replicas` 필드를 직접 업데이트한다. +이는 `kubectl apply`를 사용하지 않는다. + +```shell +kubectl scale deployment/nginx-deployment --replicas=2 +``` + +`kubectl get`을 사용하여 활성 구성을 출력한다. + +```shell +kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml +``` + +출력은 `replicas` 필드가 2로 설정된 것을 보여주며, `last-applied-configuration` +어노테이션은 `replicas` 필드를 포함하지 않는다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + # ... + # note that the annotation does not contain replicas + # because it was not updated through apply + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + replicas: 2 # written by scale + # ... + minReadySeconds: 5 + selector: + matchLabels: + # ... + app: nginx + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.7.9 + # ... + name: nginx + ports: + - containerPort: 80 + # ... +``` + +`nginx:1.7.9`에서 `nginx:1.11.9`로 이미지를 변경하기 위해 `simple_deployment.yaml` +구성 파일을 업데이트 하고, `minReadySeconds` 필드를 삭제한다. + +{{< codenew file="application/update_deployment.yaml" >}} + +구성 파일에 이루어진 변경사항을 적용한다. + +```shell +kubectl diff -f https://k8s.io/examples/application/update_deployment.yaml +kubectl apply -f https://k8s.io/examples/application/update_deployment.yaml +``` + +`kubectl get`을 사용하여 활성 구성을 출력한다. + +``` +kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml +``` + +출력은 활성 구성에 다음의 변경사항을 보여준다. + +- `replicas` 필드는 `kubectl scale`에 의해 설정된 값 2를 유지한다. + 이는 구성 파일에서 생략되었기 때문에 가능하다. +- `image` 필드는 `nginx:1.7.9`에서 `nginx:1.11.9`로 업데이트되었다. +- `last-applied-configuration` 어노테이션은 새로운 이미지로 업데이트되었다. +- `minReadySeconds` 필드는 지워졌다. +- `last-applied-configuration` 어노테이션은 더 이상 `minReadySeconds` 필드를 포함하지 않는다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + # ... + # The annotation contains the updated image to nginx 1.11.9, + # but does not contain the updated replicas to 2 + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + replicas: 2 # Set by `kubectl scale`. Ignored by `kubectl apply`. + # minReadySeconds cleared by `kubectl apply` + # ... + selector: + matchLabels: + # ... + app: nginx + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.11.9 # Set by `kubectl apply` + # ... + name: nginx + ports: + - containerPort: 80 + # ... + # ... + # ... + # ... +``` + +{{< warning >}} +명령형 오브젝트 구성 커맨드 `create`와 `replace`와 함께 `kubectl apply`를 +혼합하는 것은 지원하지 않는다. 이는 `kubectl apply`가 업데이트 사항을 계산하는데 사용하는 +`kubectl.kubernetes.io/last-applied-configuration`을 `create`와 `replace`가 +유지하지 하지 않기 때문이다. +{{< /warning >}} + +## 오브젝트 삭제 방법 + +`kubectl apply`에 의해 관리되는 오브젝트를 삭제하는데 2가지 접근 방법이 있다. + +### 권장 방법: `kubectl delete -f <파일명>` + +명령형 커맨드를 사용하여 오브젝트를 수동으로 삭제하는 것이 권장되는 방식인데, +무엇이 삭제되는지에 대해 더 명확하게 나타내므로 사용자가 의도하지 않게 +무언가를 삭제할 가능성이 작아지기 때문이다. + +```shell +kubectl delete -f <파일명> +``` + +### 대안: `kubectl apply -f <디렉터리/> --prune -l your=레이블` + +무엇을 하는지 파악하는 경우에만 이를 사용한다. + +{{< warning >}} +`kubectl apply --prune`은 알파 상태이며, 후속 릴리스에서는 +하위 호환되지 않는 변경 사항이 도입될 수 있다. +{{< /warning >}} + +{{< warning >}} +이 명령을 사용할 때는 의도하지 않게 오브젝트를 삭제하지 않도록 +주의해야만 한다. +{{< /warning >}} + +`kubectl delete`에 대한 대안으로, 디렉터리로부터 구성 파일이 삭제된 후에 삭제될 오브젝트를 식별하기 위해 `kubectl apply`를 사용할 수 있다. +`--prune`을 사용하여 적용하면 일련의 레이블의 집합과 일치하는 +모든 오브젝트에 대해API 서버에 쿼리하고, 반환된 활성 오브젝트 +구성을 오브젝트 구성 파일에 일치시키려고 시도한다. +오브젝트가 쿼리에 일치하고, 해당 디렉터리 내 구성 파일이 없고 +`last-applied-configuration`어노테이션이 있는 경우, +삭제된다. + +{{< comment >}} +TODO(pwittrock): We need to change the behavior to prevent the user from running apply on subdirectories unintentionally. +{{< /comment >}} + +```shell +kubectl apply -f <디렉터리/> --prune -l <레이블> +``` + +{{< warning >}} +prune을 사용하여 적용하는 것은 오브젝트 구성 파일을 +포함하는 루트 디렉터리에 대해서만 실행해야 한다. +하위 디렉터리에 대해 실행하게 되면, +`-l <레이블>`로 지정된 레이블 셀렉터에 의해 반환되고 하위 디렉터리에 나타나지 않는 경우, +오브젝트가 의도하지 않게 삭제될 수 있다. +{{< /warning >}} + +## 오브젝트 확인 방법 + +활성 오브젝트의 구성을 확인하기 위해 `-o yaml`과 함께 `kubectl get`을 사용할 수 있다. + +```shell +kubectl get -f <파일명|url> -o yaml +``` + +## 어떻게 apply가 차이를 계산하고 변경을 병합하는가 + +{{< caution >}} +*patch* 는 전체 오브젝트 대신 오브젝트의 특정 필드 범위의 오퍼레이션을 업데이트한다. +이는 먼저 오브젝트를 읽지 않고도 오브젝트의 특정 필드 집합만을 +업데이트할 수 있도록 해준다. +{{< /caution >}} + +`kubectl apply`가 하나의 오브젝트에 대한 활성 구성을 업데이트할 때, +API 서버에 패치 요청을 보냄으로써 그것을 수행한다. +그 패치는 활성 오브젝트 구성의 특정 필드에 대한 범위의 +업데이트로 한정한다. `kubectl apply` 커맨드는 +구성 파일, 활성 구성, 그리고 활성 구성에 저장된 +`last-applied-configuration`어노테이션을 사용하여 이 패치 요청을 계산한다. + +### 패치 계산 병합 + +`kubectl apply` 명령은 +`kubectl.kubernetes.io/last-applied-configuration` 어노테이션에 구성 파일의 내용을 기록한다. +이것은 구성 파일로부터 제거되었고 활성 구성으로부터 지워질 필요가 있는 +필드를 확인하는 데 사용된다. 다음은 어떤 필드가 삭제 또는 설정돼야 하는지 +계산하기 위해 사용되는 단계이다. + +1. 삭제할 필드를 계산한다. 이것은 `last-applied-configuration` 내 존재하고 구성 파일로부터 유실된 필드이다. +2. 추가 또는 설정되어야 할 필드를 계산한다. 이것은 활성 구성과 불일치하는 값을 가지는 구성 파일 내 존재하는 필드이다. + +다음은 예시이다. 디플로이먼트 오브젝트에 대한 구성 파일이라고 가정한다. + +{{< codenew file="application/update_deployment.yaml" >}} + +또한, 이것은 동일한 디플로이먼트 오브젝트에 대한 활성 구성이라고 가정한다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + # ... + # note that the annotation does not contain replicas + # because it was not updated through apply + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"minReadySeconds":5,"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.7.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + replicas: 2 # written by scale + # ... + minReadySeconds: 5 + selector: + matchLabels: + # ... + app: nginx + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.7.9 + # ... + name: nginx + ports: + - containerPort: 80 + # ... +``` + +다음은 `kubectl apply`에 의해 수행될 병합 계산이다. + +1. `last-applied-configuration`으로부터 값을 읽어 + 구성 파일의 값과 비교하여 삭제할 필드를 + 계산한다. + `last-applied-configuration`에 보이는 것과는 무관하게 + 로컬의 오브젝트 구성 파일 내 null이라고 명시적으로 설정된 필드를 지운다. + 이 예시에서, `minReadySeconds`은 + `last-applied-configuration` 어노테이션 내 나타나지만, 구성 파일 내에는 보여지지 않는다. + **조치:** 활성 구성으로부터 `minReadySeconds`을 지운다. +2. 구성 파일로부터 값을 읽어 활성 구성 내 값과 + 비교하여 설정할 필드를 계산한다. 이 예시에서, + 구성 파일 내 `image` 값은 활성 구성 내 값과 불일치한다. + **조치:** 활성 구성 내 `image` 값을 설정한다. +3. 구성 파일의 값과 일치시키기 위해 `last-applied-configuration` + 어노테이션을 설정한다. +4. 1, 2, 3으로부터의 결과를 API 서버에 단일 패치 요청으로 병합한다. + +다음은 병합의 결과인 활성 구성이다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + annotations: + # ... + # The annotation contains the updated image to nginx 1.11.9, + # but does not contain the updated replicas to 2 + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"apps/v1","kind":"Deployment", + "metadata":{"annotations":{},"name":"nginx-deployment","namespace":"default"}, + "spec":{"selector":{"matchLabels":{"app":nginx}},"template":{"metadata":{"labels":{"app":"nginx"}}, + "spec":{"containers":[{"image":"nginx:1.11.9","name":"nginx", + "ports":[{"containerPort":80}]}]}}}} + # ... +spec: + selector: + matchLabels: + # ... + app: nginx + replicas: 2 # Set by `kubectl scale`. Ignored by `kubectl apply`. + # minReadySeconds cleared by `kubectl apply` + # ... + template: + metadata: + # ... + labels: + app: nginx + spec: + containers: + - image: nginx:1.11.9 # Set by `kubectl apply` + # ... + name: nginx + ports: + - containerPort: 80 + # ... + # ... + # ... + # ... +``` + +### 어떻게 상이한 필드 타입이 병합되는가 + +구성 파일 내 특정 필드가 필드의 타입에 따라 +어떻게 활성 구성과 함께 병합되는가. +여러 가지 필드 타입이 있다. + +- *기본(primitives)*: 문자열, 숫자 또는 불리언 타입의 필드. + 예를 들어, `image`와 `replicas`는 기본 필드다. **조치:** 교체. + +- *맵*, 또한 *오브젝트* 라 칭함: 맵 타입 또는 서브필드를 포함하는 복합 타입의 필드. 예를 들어, `레이블`, + `어노테이션`,`스펙` 및 `메타데이터`는 모두 맵이다. **조치:** 구성요소 또는 서브필드 병합. + +- *리스트*: 기본타입 또는 맵이 될 수 있는 아이템의 리스트를 포함하는 필드. + 예를 들어, `컨테이너`, `포트`, 그리고 `args`는 리스트다. **조치:** 다양함. + +`kubectl apply`가 맵 또는 리스트 필드를 업데이트하는 경우, +일반적으로 전체 필드를 교체하는 대신, 개별 부 구성요소를 업데이트한다, +예를 들어, 디플로이먼트에 대한 `spec`을 병합할 경우, 전체 `spec`이 +교체되지 않는다. 대신 `replicas`와 같은 `spec`의 서브필드가 +비교되고 병합된다. + +### 기본 필드에 대한 변경사항 병합하기 + +기본 필드는 교체되거나 지워진다. + +{{< note >}} +`-` 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다. +{{< /note >}} + +| Field in object configuration file | Field in live object configuration | Field in last-applied-configuration | Action | +|-------------------------------------|------------------------------------|-------------------------------------|-------------------------------------------| +| Yes | Yes | - | 구성 파일 값 활성으로 설정. | +| Yes | No | - | 활성을 로컬 구성으로 설정. | +| No | - | Yes | 활성 구성으로부터 지움. | +| No | - | No | 아무것도 안함. 활성값 유지. | + +### 맵 필드에 변경사항 병합하기 + +맵을 요청하는 필드는 서브필드의 각각 또는 맵의 구성요소를 비교함으로써 병합된다. + +{{< note >}} +`-` 는 값이 사용되지 않기 때문에 "해당 없음"으로 사용된다. +{{< /note >}} + +| Key in object configuration file | Key in live object configuration | Field in last-applied-configuration | Action | +|-------------------------------------|------------------------------------|-------------------------------------|----------------------------------| +| Yes | Yes | - | 서브필드 값 비교. | +| Yes | No | - | 활성을 로컬 구성으로 설정. | +| No | - | Yes | 활성 구성으로부터 삭제. | +| No | - | No | 아무것도 안함. 활성값 유지. | + +### 타입 리스트의 필드에 대한 변경사항 병합하기 + +리스트에 대한 변경사항을 병합하는 것은 세 가지 전략 중 하나를 사용한다. + +* 구성요소가 모두 기본형인 경우 리스트를 교체한다. +* 복합 구성요소의 리스트에서 개별 구성요소를 병합한다. +* 기초 구성요소의 리스트를 병합한다. + +전략에 대한 선택은 필드별로 이루어진다. + +#### 구성요소가 모두 기본형인 경우 리스트 교체 + +기초 필드와 동일한 리스트로 취급한다. 전체 리스트를 교체 또는 삭제한다. +이것은 순서를 유지한다. + +**예시:** 파드 내 컨테이너의 `args` 필드를 업데이트하기 위해 `kubectl apply`를 사용한다. +이것은 활성 구성 내 `args`의 값을 구성 파일 내 값으로 설정한다. +활성 구성에 추가했던 이전의 모든 `args`구성요소들은 유실된다. +구성 파일 내 정의한 `args` 구성요소의 순서는 +활성 구성 내 유지된다. + +```yaml +# last-applied-configuration value + args: ["a", "b"] + +# configuration file value + args: ["a", "c"] + +# live configuration + args: ["a", "b", "d"] + +# result after merge + args: ["a", "c"] +``` + +**설명:** 병합은 새로운 리스트 값으로 구성 파일 값을 사용했다. + +#### 복합 구성요소 리스트에 대한 개별 구성요소 병합 + +리스트를 맵으로 취급하고 각 구성요소의 특정 필드를 키로 취급한다. +개별 구성요소를 추가, 삭제, 또는 업데이트 한다. 이것은 순서를 보존하지 않는다. + +이 병합 전략은 각 필드에 `patchMergeKey`라 칭하는 특별한 태그를 사용한다. +`patchMergeKey`는 쿠버네티스 소스 코드: +[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2747) +의 각 필드에 대해 정의한다. 맵 리스트를 병합할 때, 주어진 구성요소에 대한 `patchMergeKey`로 +지정한 필드는 해당 구성요소에 대한 맵키와 같이 사용된다. + +**예시:** `kubectl apply`를 사용하여 PodSpec에 대한 `containers`필드를 업데이트한다. +이렇게 하면 각 구성요소가 +`name`별로 키로 되어 있는 맵인 것처럼 리스트를 병합한다. + +```yaml +# last-applied-configuration value + containers: + - name: nginx + image: nginx:1.10 + - name: nginx-helper-a # key: nginx-helper-a; will be deleted in result + image: helper:1.3 + - name: nginx-helper-b # key: nginx-helper-b; will be retained + image: helper:1.3 + +# configuration file value + containers: + - name: nginx + image: nginx:1.10 + - name: nginx-helper-b + image: helper:1.3 + - name: nginx-helper-c # key: nginx-helper-c; will be added in result + image: helper:1.3 + +# live configuration + containers: + - name: nginx + image: nginx:1.10 + - name: nginx-helper-a + image: helper:1.3 + - name: nginx-helper-b + image: helper:1.3 + args: ["run"] # Field will be retained + - name: nginx-helper-d # key: nginx-helper-d; will be retained + image: helper:1.3 + +# result after merge + containers: + - name: nginx + image: nginx:1.10 + # Element nginx-helper-a was deleted + - name: nginx-helper-b + image: helper:1.3 + args: ["run"] # Field was retained + - name: nginx-helper-c # Element was added + image: helper:1.3 + - name: nginx-helper-d # Element was ignored + image: helper:1.3 +``` + +**설명:** + +- 구성 파일에 "nginx-helper-a"라는 이름을 가진 컨테이너가 나타나지 않았기 때문에 + "nginx-helper-a"라는 컨테이너는 삭제되었다. +- "nginx-helper-b"라는 컨테이너는 활성 구성에 `args`에 + 대한 변경사항을 유지했다. `kubectl apply`는 + 필드 값이 다름에도 불구하고(구성 파일에 `args`가 없음) 활성 구성에 + "nginx-helper-b"가 구성 파일과 동일한 + "nginx-helper-b"임을 식별할 수 있었다. 이것은 + `patchMergeKey` 필드 값(이름)이 둘 다 같았기 때문이다.. +- "nginx-helper-c"라는 이름의 컨테이너가 활성 구성에 나타나지 + 않았지만, 구성 파일에 그 이름을 가진 컨테이너가 나타났기 때문에 + 추가되었다. +- last-applied-configuration에 그 이름을 가진 구성요소가 없었기 때문에 + "nginx-helper-d"라는 이름의 컨테이너는 유지되었다. + +#### 기초 구성요소 리스트 병합 + +쿠버네티스 1.5로부터 기초 구성요소 병합하기는 지원되지 않는다. + +{{< note >}} +주어진 필드에 대해 위 전략 중 어떤 것을 선택할지에 대해서는 +[types.go](https://github.com/kubernetes/api/blob/d04500c8c3dda9c980b668c57abc2ca61efcf5c4/core/v1/types.go#L2748)의 `patchStrategy` 태그에 의해 제어된다. +타입 필드에 대해 `patchStrategy`가 지정되지 않으면, +리스트는 대체된다. +{{< /note >}} + +{{< comment >}} +TODO(pwittrock): Uncomment this for 1.6 + +- Treat the list as a set of primitives. Replace or delete individual + elements. Does not preserve ordering. Does not preserve duplicates. + +**Example:** Using apply to update the `finalizers` field of ObjectMeta +keeps elements added to the live configuration. Ordering of finalizers +is lost. +{{< /comment >}} + +## 기본 필드값 + +오브젝트가 생성될 때 값이 지정되지 않는 경우, API 서버는 활성 구성 내 +특정 필드를 기본값으로 설정한다. + +다음은 디플로이먼트에 대한 구성 파일이다. 파일에는 `strategy`가 지정되지 않았다. + +{{< codenew file="application/simple_deployment.yaml" >}} + +`kubectl apply`를 사용하여 오브젝트를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml +``` + +`kubectl get`을 사용하여 활성 구성을 출력한다. + +```shell +kubectl get -f https://k8s.io/examples/application/simple_deployment.yaml -o yaml +``` + +출력은 API 서버가 활성 구성 내 여러 필드를 기본값으로 설정한 것을 보여준다. +이 필드들은 구성 파일에 지정되지 않았다. + +```yaml +apiVersion: apps/v1 +kind: Deployment +# ... +spec: + selector: + matchLabels: + app: nginx + minReadySeconds: 5 + replicas: 1 # defaulted by apiserver + strategy: + rollingUpdate: # defaulted by apiserver - derived from strategy.type + maxSurge: 1 + maxUnavailable: 1 + type: RollingUpdate # defaulted apiserver + template: + metadata: + creationTimestamp: null + labels: + app: nginx + spec: + containers: + - image: nginx:1.7.9 + imagePullPolicy: IfNotPresent # defaulted by apiserver + name: nginx + ports: + - containerPort: 80 + protocol: TCP # defaulted by apiserver + resources: {} # defaulted by apiserver + terminationMessagePath: /dev/termination-log # defaulted by apiserver + dnsPolicy: ClusterFirst # defaulted by apiserver + restartPolicy: Always # defaulted by apiserver + securityContext: {} # defaulted by apiserver + terminationGracePeriodSeconds: 30 # defaulted by apiserver +# ... +``` + +패치 요청에서, 패치 요청의 부분으로서 명시적으로 지워지지 않은 경우 +기본 처리된 필드는 다시 기본으로 설정되지 않는다. +이것은 다른 필드에 대한 값에 따라 기본 처리된 필드에 대해 +예상하지 못한 동작을 유발할 수 있다. 다른 필드가 나중에 변경되면, +그로부터 기본 처리된 것이 명시적으로 지워지지 않은 한 +업데이트되지 않을 것이다. + +이러한 사유로, 의도한 값이 서버의 기본값과 일치하더라도, +서버에 의해 기본 처리된 특정 필드는 구성 파일 내 +명시적으로 정의할 것을 권고한다. 이렇게 하면 +서버에 의해 다시 기본 처리되지 않게 될 충돌하는 값을 보다 쉽게 +인식할 수 있도록 해준다. + +**Example:** + +```yaml +# last-applied-configuration +spec: + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +# configuration file +spec: + strategy: + type: Recreate # updated value + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +# live configuration +spec: + strategy: + type: RollingUpdate # defaulted value + rollingUpdate: # defaulted value derived from type + maxSurge : 1 + maxUnavailable: 1 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +# result after merge - ERROR! +spec: + strategy: + type: Recreate # updated value: incompatible with rollingUpdate + rollingUpdate: # defaulted value: incompatible with "type: Recreate" + maxSurge : 1 + maxUnavailable: 1 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 +``` + +**설명:** + +1. 사용자가 `strategy.type`을 정의하지 않고 디플로이먼트를 생성한다. +2. 서버는 `strategy.type`을 `RollingUpdate`로 기본 설정하고 + `strategy.rollingUpdate`값을 기본 값으로 처리한다. +3. 사용자가 `strategy.type`를 `Recreate`로 변경한다. + 서버에서 해당 값이 삭제될 거라 예상하지만 `strategy.rollingUpdate`값은 기본값으로 남아 있다. + `strategy.rollingUpdate`값이 처음에 구성 파일에서 지정되었다면, + 이것을 삭제해야 한다는 것이 더 분명했을 것이다. +4. `strategy.rollingUpdate`가 지워지지 않았기 때문에 적용은 실패한다. + `strategy.rollingupdate` 필드는 `Recreate`의 `strategy.type`으로 정의될 수 없다. + +권고: 이들 필드는 오브젝트 구성 파일 내 명시적으로 정의돼야 한다. + +- 디플로이먼트, 스테이트풀셋, 잡, 데몬셋, 레플리카셋 및 레플리케이션컨트롤러와 같은 + 워크로드에 대한 셀렉터와 파드템플릿 레이블 +- 디플로이먼트 롤아웃 전략 + +### 서버 기본 필드 또는 다른 작성자에 의해 설정된 필드 지우는 방법 + +구성 파일 내 나타나지 않는 필드는 그 값을 +`null`로 설정하고 나서 구성 파일을 적용함으로써 지워질 수 있다. +서버가 기본 값을 할당했던 필드에 대해서, 이는 다시 기본 값을 +할당하도록 한다. + +## 구성 파일과 직접 명령형 작성자 간의 필드 소유권을 변경시키는 방법 + +개별 오브젝트 필드를 변경시키는 데 사용해야 하는 유일한 방법은 다음과 같다. + +- `kubectl apply`를 사용한다. +- 구성 파일을 수정하지 않고 활성 구성을 직접 작성한다. +예를 들어, `kubectl scale`을 사용한다. + +### 직접 명령형 작성자에서 구성 파일로 소유자 변경하기 + +구성 파일에 필드를 추가한다. 해당 필드의 경우 +`kubectl apply`를 거치지 않는 활성 구성에 대해 직접 업데이트를 적용하지 않는다. + +### 구성 파일에서 직접 명령형 작성자로 소유자 변경하기 + +쿠버네티스 1.5로부터 구성 파일에서 명령형 작성자로 소유권을 변경하는데 +수동 단계 필요하다. + +- 구성 파일에서 필드를 제거한다. +- 활성 오브젝트 상의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션에서 필드를 제거한다. + +## 관리 방법 변경하기 + +쿠버네티스 오브젝트는 한 번에 오직 하나의 방법을 사용하여 관리돼야 한다. +하나의 방법에서 다른 방법으로 전환하는 것은 가능하나, 수동 프로세스이다. + +{{< note >}} +선언형 관리와 함께 명령형 삭제를 사용하는 것은 괜찮다. +{{< /note >}} + +{{< comment >}} +TODO(pwittrock): We need to make using imperative commands with +declarative object configuration work so that it doesn't write the +fields to the annotation, and instead. Then add this bullet point. + +- using imperative commands with declarative configuration to manage where each manages different fields. +{{< /comment >}} + +### 명령형 커맨드 관리에서 오브젝트 구성으로 이전하기 + +명령형 커맨드 관리에서 오브젝트 구성으로 이전하는 것은 +여러 수동 단계를 포함한다. + +1. 활성 오브젝트를 로컬 구성 파일로 내보낸다. + + ```shell + kubectl get <종류>/<이름> -o yaml --export > <종류>_<이름>.yaml + ``` + +1. 구성 파일에서 수동으로 `status` 필드를 제거한다. + + {{< note >}} + `kubectl apply` 구성 파일에 존재한다고 하더라도 상태 필드가 업데이트되지 않기 때문에, + 이 단계는 선택적이다. + {{< /note >}} + +1. 오브젝트의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션을 설정한다. + + ```shell + kubectl replace --save-config -f <종류>_<이름>.yaml + ``` + +1. 오직 오브젝트를 관리하기 위해 `kubectl apply`를 사용하도록 프로세스를 변경한다. + +{{< comment >}} +TODO(pwittrock): Why doesn't export remove the status field? Seems like it should. +{{< /comment >}} + +### 명령형 오브젝트 구성에서 선언형 오브젝트 구성으로 이전하기 + +1. 오브젝트의 `kubectl.kubernetes.io/last-applied-configuration` 어노테이션을 설정한다. + + ```shell + kubectl replace --save-config -f <종류>_<이름>.yaml + ``` + +1. 오직 오브젝트를 관리하기 위해 `kubectl apply`를 사용하도록 프로세스를 변경한다. + +## 컨트롤러 셀렉터와 파드템플릿 레이블 정의하기 + +{{< warning >}} +컨트롤러에서 셀렉터를 업데이트하는 것은 추천되지 않는다. +{{< /warning >}} + +권고되는 접근 방법은 다른 의미론적 의미를 가지지 않고 컨트롤러에 의해서만 사용되는 +단일, 불변의 파드템플릿 레이블을 정의하는 것이다. + +**예시:** + +```yaml +selector: + matchLabels: + controller-selector: "extensions/v1beta1/deployment/nginx" +template: + metadata: + labels: + controller-selector: "extensions/v1beta1/deployment/nginx" +``` + +{{% capture whatsnext %}} +- [명령형 커맨드 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [구성 파일 사용하여 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-config/) +- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl/) +- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 87e247fd87..0e5823b6bf 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -1,5 +1,5 @@ --- -title: 쿠버네티스란 무엇인가? +title: 쿠버네티스란 무엇인가 content_template: templates/concept weight: 10 card: @@ -17,12 +17,13 @@ card: 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 -15여년에 걸친 대규모 운영 워크로드 운영 -경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며 +구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. +쿠버네티스는 +[구글의 15여년에 걸친 대규모 상용 워크로드 운영 경험](https://research.google.com/pubs/pub43438.html)을 +기반으로 만들어졌으며 커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다. -## 쿠버네티스가 왜 필요하고 무엇을 할 수 있는가? +## 쿠버네티스가 왜 필요하고 무엇을 할 수 있는가 쿠버네티스에는 많은 기능이 있다. 다음과 같이 생각해 볼 수 있다. @@ -31,45 +32,55 @@ card: - 이식성 있는 클라우드 플랫폼 그리고 더 많은 기능. -쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자 -워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 -오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에 -Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처 -제공자 간 이식이 가능하게 해준다. +쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. +이 환경은 사용자 워크로드를 위해서 +컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 오케스트레이션한다. +이는 Platform as a Service(PaaS)의 매우 단순명료함에 +Infrastructure as a Service (IaaS)의 유연함을 더해 주며, +인프라스트럭처 제공자 간 이식을 가능하게 한다. ## 어떻게 쿠버네티스가 플랫폼인가 -쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는 -새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록 -애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹 -오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가 -애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 -만드는 플랫폼의 기능을 하도록 설계된 이유이다. +쿠버네티스가 제공하는 많은 기능이 있지만, +신규 기능을 통해 혜택을 얻을 수 있는 새로운 시나리오는 항상 있게 마련이다. +개발자의 생산성을 극대화할 수 있도록 애플리케이션에 특화된 워크플로우를 최적화할 수 있다. +초기에 수용 가능한 애드혹 오케스트레이션은 +대규모의 견고한 자동화를 필요로 하곤 한다. +이것이 쿠버네티스가 애플리케이션을 더 쉽게 배포하고, +스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 만드는 +플랫폼의 기능을 하도록 설계된 이유이다. -[레이블](/docs/concepts/overview/working-with-objects/labels/)은 사용자가 원하는 -방식대로 자원을 정리할 수 있도록 해준다. +[레이블](/docs/concepts/overview/working-with-objects/labels/)은 +사용자가 원하는 방식대로 자원을 정리할 수 있도록 해준다. [어노테이션](/docs/concepts/overview/working-with-objects/annotations/)은 -자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고 +자원에 사용자 정의 정보를 추가해서 +사용자의 워크플로우에 활용할 수 있도록 하고 관리 툴이 상태를 쉽게 체크할 수 있는 방법을 제공해 준다. -추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 +추가로, +[쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를 -기반으로 하고 있다. 사용자는 범용의 [커맨드라인 툴]((/docs/user-guide/kubectl-overview/))을 +기반으로 하고 있다. +사용자는 +범용의 [커맨드라인 툴]((/docs/user-guide/kubectl-overview/))을 대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진 [스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와 같은 사용자만의 컨트롤러를 작성할 수 있다. 이 [설계](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)를 통해 -쿠버네티스 위에 많은 다른 시스템을 올릴 수 있게 된다. +쿠버네티스 위에 +많은 다른 시스템을 올릴 수 있게 된다. ## 쿠버네티스가 아닌 것 쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 -같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지 -않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 -개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 +같은 기능에서 공통점이 있기도 하다. +하지만, 쿠버네티스는 모놀리식(monolithic)하지 +않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. +쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, +필요한 경우 사용자의 선택권과 유연성을 지켜준다. 쿠버네티스는 @@ -80,26 +91,33 @@ PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서 매우 잘 동작할 것이다. * 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. - 지속적인 통합, 지속적인 배포(Delivery, Deployment)(CI/CD) 워크플로우는 - 기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다. + 지속적인 통합과 전달과 배포 곧 CI/CD 워크플로우는 + 조직 문화와 취향에 따를 뿐만 아니라 + 기술적인 요구사항으로 결정된다. * 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), 캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를 - 제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 + 제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, + 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다. -* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, +* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. + 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다. * 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나 - 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. -* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. + 요구하지 않는다. + 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. +* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 + 제공하거나 채택하지 않는다. -추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다. 사실, -쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션* 의 -기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 -수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 +추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템* 이 아니다. +사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. +*오케스트레이션* 의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 +정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 +독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 -보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. +보다 더 사용하기 쉬워지고, +강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. ## 왜 컨테이너인가 @@ -110,41 +128,48 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 애플리케이션을 배포하는 *옛 방식* 은 운영 체제의 패키지 관리자를 사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 -호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 -위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고 -이식 가능하지 않다. +호스트 OS와 얽히게 된다는 단점이 있다. +예측 가능한 롤아웃과 롤백을 +위해서 불변의 가상 머신 이미지를 만들 수도 있지만, +VM은 너무 크고 이식 가능하지 않다. *새로운 방법* 은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한 -컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도 -격리된다. 컨테이너는 컨테이너 자체의 파일시스템을 갖고, 다른 컨테이너의 -프로세스를 알 수 없으며, 연산에 필요한 자원을 제한할 수 있다. VM보다 -빌드하기 쉬우며, 기반이 되는 인프라스트럭처와 호스트 파일시스템에서 +컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도 격리된다. +컨테이너는 컨테이너 자체의 파일시스템을 갖고, +다른 컨테이너의 프로세스를 알 수 없으며, +연산에 필요한 자원을 제한할 수 있다. +VM보다 빌드하기 쉬우며, +기반이 되는 인프라스트럭처와 호스트 파일시스템에서 디커플되었기(decoupled) 때문에 클라우드나 OS 배포판 간 이식성이 있다. 컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로 -패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 -하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는 -배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의 -애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 -때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 -때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 -환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. 마찬가지로, -컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다. +패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 하면 +컨테이너의 혜택을 만끽할 수 있게 된다. +불변의 컨테이너 이미지는 +배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. +왜냐하면 각각의 애플리케이션은 +애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 때문이고, +운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 때문이다. +컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 +환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. +마찬가지로, 컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다. 컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너 내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는 -용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로 -컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다. +용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, +궁극적으로 컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다. 컨테이너의 혜택 요약: * **기민한 애플리케이션 생성과 배포**: VM 이미지 사용 대비 컨테이너 이미지 생성이 보다 쉽고 효율적임. * **지속적인 개발, 통합 및 배포**: - 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 + 안정적이고 주기적으로 컨테이너 이미지를 + 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다. * **개발과 운영의 관심사 분리**: - 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 - 만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다. + 배포 시점이 아닌 빌드/릴리스 시점에 + 애플리케이션 컨테이너 이미지를 만들기 때문에, + 애플리케이션이 인프라스트럭처에서 디커플된다. * **가시성** OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다. @@ -154,8 +179,7 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다. * **애플리케이션 중심 관리**: 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 - 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 - 수준이 높아진다. + 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 수준이 높아진다. * **느슨하게 커플되고, 분산되고, 유연하며, 자유로운 [마이크로서비스](https://martinfowler.com/articles/microservices.html)**: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 @@ -165,11 +189,13 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 * **지원 사용량**: 고효율 고집적. -## 쿠버네티스의 뜻은? K8s? +## 쿠버네티스와 K8s의 뜻 **쿠버네티스**는 *키잡이* 나 *파일럿* 을 뜻하는 그리스어에서 유래했으며, -이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 -어원이다. *K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다. +이는 *governor*(통치자)와 +[cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 +어원이다. +*K8s* 는 "ubernete" 8 글자를 "8"로 대체한 약어이다. {{% /capture %}} @@ -177,3 +203,5 @@ A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필 * [시작할](/docs/setup/) 준비가 되었는가? * 보다 자세한 내용은 [쿠버네티스 문서](/ko/docs/home/)를 참조한다. {{% /capture %}} + + diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 8a8cd33ae0..ae052bb8fc 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -17,24 +17,26 @@ weight: 30 ## 복수의 네임스페이스를 사용하는 경우 네임스페이스는 복수의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 -만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, 네임스페이스를 고려할 -필요가 전혀 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자. +만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는, +네임스페이스를 고려할 필요가 전혀 없다. +네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자. -네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다. +네임스페이스는 이름의 범위를 제공한다. +리소스의 이름은 네임스페이스 내에서 유일해야하지만, +네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 클러스터 자원을 ([리소스 쿼터](/docs/concepts/policy/resource-quotas/)를 통해) 복수의 사용자 사이에서 나누는 방법이다. -다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 -제어 정책을 갖게 된다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 -리소스는 하나의 네임스페이스에만 있을 수 있다. +다음 버전의 쿠버네티스에서는, 같은 네임스페이스의 오브젝트는 기본적을 동일한 접근 제어 정책을 갖게 된다. +네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다. -같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서 -복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를 +같은 소프트웨어의 다른 버전과 같이 단지 약간의 차이가 있는 리소스를 분리하기 위해서 +복수의 네임스페이스를 사용할 필요가 있다. 동일한 네임스페이스에 있는 리소스를 구분하기 위해서는 [레이블](/docs/user-guide/labels)을 사용한다. ## 네임스페이스 다루기 -네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에 +네임스페이스의 생성과 삭제는 [네임스페이스 관리자 가이드 문서](/docs/admin/namespace)에 기술되어 있다. ### 네임스페이스 조회 @@ -42,7 +44,7 @@ weight: 30 사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다. ```shell -kubectl get namespaces +kubectl get namespace ``` ``` NAME STATUS AGE @@ -64,33 +66,33 @@ kube-public Active 1d 예를 들면, ```shell -$ kubectl --namespace= run nginx --image=nginx -$ kubectl --namespace= get pods +kubectl --namespace= run nginx --image=nginx +kubectl --namespace= get pods ``` ### 선호하는 네임스페이스 설정하기 -이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에 영구적으로 저장할 수 있다. +이후 모든 kubectl 명령에서 사용될 네임스페이스를 컨텍스트에 +영구적으로 저장할 수 있다. ```shell -$ kubectl config set-context $(kubectl config current-context) --namespace= +kubectl config set-context $(kubectl config current-context) --namespace= # 확인하기 -$ kubectl config view | grep namespace: +kubectl config view | grep namespace: ``` ## 네임스페이스와 DNS -[서비스](/docs/user-guide/services)를 생성하면, 대응되는 +[서비스](/docs/user-guide/services)를 생성하면, 대응되는 [DNS 엔트리](/docs/concepts/services-networking/dns-pod-service/)가 생성된다. 이 엔트리는 `<서비스-이름>.<네임스페이스-이름>.svc.cluster.local`의 형식을 갖는데, -이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 -연결된다. 개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 -사용하는 경우에 유용하다. 네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 -이름(FQDN)을 사용해야 한다. +이는 컨테이너가 `<서비스-이름>`만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다. +개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다. +네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN)을 사용해야 한다. ## 모든 오브젝트가 네임스페이스에 속하지는 않음 -대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 +대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. 그리고 [nodes](/docs/admin/node)나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다. @@ -99,10 +101,10 @@ $ kubectl config view | grep namespace: ```shell # 네임스페이스에 속하는 리소스 -$ kubectl api-resources --namespaced=true +kubectl api-resources --namespaced=true # 네임스페이스에 속하지 않는 리소스 -$ kubectl api-resources --namespaced=false +kubectl api-resources --namespaced=false ``` {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/controllers/_index.md b/content/ko/docs/concepts/workloads/controllers/_index.md new file mode 100644 index 0000000000..8193613bfe --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/_index.md @@ -0,0 +1,4 @@ +--- +title: "컨트롤러" +weight: 20 +--- diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md new file mode 100644 index 0000000000..115878ae06 --- /dev/null +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -0,0 +1,49 @@ +--- +title: 크론잡 +content_template: templates/concept +weight: 80 +--- + +{{% capture overview %}} + +_크론 잡은_ 시간 기반의 일정에 따라 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 만든다. + +하나의 크론잡 객체는 _크론탭_ (크론 테이블) 파일의 한 줄과 같다. 크론잡은 잡을 [크론](https://en.wikipedia.org/wiki/Cron)형식으로 쓰여진 주어진 일정에 따라 주기적으로 동작시킨다. + + +{{< note >}} +모든 **크론잡** `일정:` 시간은 잡이 처음 시작된 마스터의 시간대를 기반으로 한다. +{{< /note >}} + +크론 잡을 생성하고 작동하는 방법은 크론 잡의 스펙 파일을 확안한다. 내용은 [크론 잡으로 자동 작업 실행하기](/docs/tasks/job/automated-tasks-with-cron-jobs)를 참조한다. + + +{{% /capture %}} + + +{{% capture body %}} + +## 크론 잡의 한계 + +크론 잡은 일정의 실행시간 마다 _약_ 한 번의 잡을 생성한다. "약" 이라고 하는 이유는 특정 환경에서는 두 개의 잡이 만들어지거나, 잡이 생성되지 않기도 하기 때문이다. 보통 이렇게 하지 않도록 해야겠지만, 완벽히 그럴 수 는 없다. 따라서 잡은 멱등원이 된다. + +만약 `startingDeadlineSeconds` 가 큰 값으로 설정되거나, 설정되지 않고(디폴트 값), `concurrencyPolicy` 가 `Allow`로 설정될 경우, 잡은 항상 적어도 한 번은 실행될 것이다. + +모든 크론 잡에 대해 크론잡 컨트롤러는 마지막 일정부터 지금까지 얼마나 많은 일정이 누락되었는지 확인한다. 만약 100회 이상의 일정이 누락되었다면, 잡을 실행하지 않고 아래와 같은 에러 로그를 남긴다. + +```` +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. +```` + +중요한 것은 만약 `startingDeadlineSeconds` 필드가 설정이 되면(`nil` 이 아닌 값으로), 컨트롤러는 마지막 일정부터 지금까지 대신 `startingDeadlineSeconds` 값에서 몇 개의 잡이 누락되었는지 카운팅한다. 예를 들면, `startingDeadlineSeconds` 가 `200` 이면, 컨트롤러는 최근 200초 내 몇 개의 잡이 누락되었는지 카운팅한다. + + +크론잡은 정해진 일정에 잡 실행을 실패하면 놓쳤다고 카운팅된다. 예를 들면, `concurrencyPolicy` 가 `Forbid` 로 설정되었고, 크론 잡이 이전 일정이 스케줄되어 여전히 시도하고 있을 때, 그 때 누락되었다고 판단한다. + +즉, 크론잡이 `08:30:00` 에 시작하여 매 분마다 새로운 잡을 실행하도록 설정이 되었고, `startingDeadlineSeconds` 값이 설정되어 있지 않는다고 가정해보자. 만약 크론 잡 컨트롤러가 `08:29:00` 부터 `10:21:00` 까지 고장이 나면, 일정을 놓친 작업 수가 100개를 초과하여 잡이 실행되지 않을 것이다. + +이 개념을 더 자세히 설명하자면, 크론 잡이 `08:30:00` 부터 매 분 실행되는 일정으로 설정되고, `startingDeadlineSeconds` 이 200이라고 가정한다. 크론 잡 컨트롤러가 전의 예시와 같이 고장났다고 하면 (`08:29:00` 부터 `10:21:00` 까지), 잡은 10:22:00 부터 시작될 것이다. 이 경우, 컨트롤러가 마지막 일정부터 지금까지가 아니라, 최근 200초 안에 얼마나 놓쳤는지 체크하기 때문이다. (여기서는 3번 놓쳤다고 체크함) + +크론 잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. + +{{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index 1132725269..d565d7751e 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -9,7 +9,7 @@ weight: 30 {{< comment >}}Updated: 4/14/2015{{< /comment >}} {{< comment >}}Edited and moved to Concepts section: 2/2/17{{< /comment >}} -이 페이지는 파드의 라이프사이클을 설명한다. +이 페이지는 파드의 라이프사이클을 설명한다. {{% /capture %}} @@ -18,38 +18,44 @@ weight: 30 ## 파드의 단계(phase) -파드의 `status` 필드는 `phase` 필드를 포함하는 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 오브젝트로 정의된다. +파드의 `status` 필드는 +`phase` 필드를 포함하는 +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 오브젝트로 정의된다. -파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 -고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 -롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다. +파드의 phase는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 +고수준의 요약이다. Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 +롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았다. 파드 phase 값에서 숫자와 의미는 엄격하게 지켜진다. -여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 `phase` 값에 대해서 +여기에 문서화된 내용 이외에는, 파드와 파드에 주어진 `phase` 값에 대해서 어떤 사항도 가정되어서는 안 된다. `phase`에 가능한 값은 다음과 같다. 값 | 의미 :-----|:----------- -`Pending` | 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. -`Running` | 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. -`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. -`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. -`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다. +`Pending` | 파드가 쿠버네티스 시스템에 의해서 승인되었지만, 파드를 위한 하나 또는 하나 이상의 컨테이너 이미지 생성이 아직 완료되지 않았다. 여기에는 스케줄되기 이전까지의 시간 뿐만 아니라 오래 걸릴 수 있는 네트워크를 통한 이미지 다운로드 시간도 포함된다. +`Running` | 파드가 한 노드에 결합되었고, 모든 컨테이너들의 생성이 완료되었다. 적어도 하나의 컨테이너가 동작 중이거나, 시작 또는 재시작 중에 있다. +`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다. +`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다. +`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다. ## 파드의 조건(condition) -파드는 하나의 PodStatus를 가지며, 그것은 파드가 통과했거나 통과하지 못한 조건에 대한 [PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. PodCondition -배열의 각 요소는 다음 여섯 가지 필드를 가질 수 있다. +파드는 하나의 PodStatus를 가지며, +그것은 파드가 통과했거나 통과하지 못한 조건에 대한 +[PodConditions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podcondition-v1-core) 배열을 가진다. +PodCondition 배열의 각 요소는 다음 여섯 가지 필드를 가질 수 있다. +* `lastProbeTime` 필드는 +파드의 조건이 마지막으로 조사된 시점의 타임스탬프를 제공한다. -* `lastProbeTime` 필드는 파드의 조건이 마지막으로 조사된 시점의 타임스탬프를 제공한다. +* `lastTransitionTime` 필드는 +파드가 마지막으로 한 상태에서 다른 상태로 전환된 시점의 타임스탬프를 제공한다. -* `lastTransitionTime` 필드는 파드가 마지막으로 한 상태에서 다른 상태로 전환된 시점의 타임스탬프를 제공한다. +* `message` 필드는 +전환에 대한 세부 정보를 표시한, 사람이 읽을 수 있는 메시지이다. -* `message` 전환에 대한 세부 정보를 표시한, 사람이 읽을 수 있는 메시지이다. - * `reason` 필드는 마지막으로 발생한 전환의 이유다. 이유는 유일하게, 한 단어로, 카멜 표기법(CamelCase)으로 표기된다. * `status` 필드는 `True`", "`False`", 그리고 "`Unknown`"으로 지정될 수 있는 문자열이다. @@ -57,96 +63,100 @@ weight: 30 * `type` 필드는 다음과 같은 가능한 값들의 문자열이다. * `PodScheduled`: 파드가 하나의 노드로 스케줄 완료되었음. - * `Ready`: 파드는 요청들을 수행할 수 있으며 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. - * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가 성공적으로 시작 완료되었음. - * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 지금 당장은 파드를 스케줄할 수 없음. + * `Ready`: 파드는 요청들을 수행할 수 있으며 + 모든 매칭 서비스들의 로드밸런싱 풀에 추가되어야 함. + * `Initialized`: 모든 [초기화 컨테이너](/docs/concepts/workloads/pods/init-containers)가 + 성공적으로 시작 완료되었음. + * `Unschedulable`: 스케줄러가 자원의 부족이나 다른 제약 등에 의해서 + 지금 당장은 파드를 스케줄할 수 없음. * `ContainersReady`: 파드 내의 모든 컨테이너가 준비 상태임. ## 컨테이너 프로브(probe) -[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, -kubelet은 컨테이너에 의해서 구현된 -[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. +[프로브](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core)는 +컨테이너에서 [kubelet](/docs/admin/kubelet/)에 의해 주기적으로 수행되는 진단(diagnostic)이다. +진단을 수행하기 위해서, +kubelet은 컨테이너에 의해서 구현된 +[핸들러](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)를 호출한다. 핸들러에는 다음과 같이 세 가지 타입이 있다. * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core) - 은 컨테이너 내에서 지정된 명령어를 실행한다. - 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. + 은 컨테이너 내에서 지정된 명령어를 실행한다. + 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다. * [TCPSocketAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#tcpsocketaction-v1-core) - 은 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. + 은 지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. * [HTTPGetAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#httpgetaction-v1-core) - 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 - 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면 - 진단이 성공한 것으로 간주한다. + 은 지정한 포트 및 경로에서 컨테이너의 IP주소에 + 대한 HTTP Get 요청을 수행한다. 응답의 상태 코드가 200보다 크고 400보다 작으면 + 진단이 성공한 것으로 간주한다. 각 probe는 다음 세 가지 결과 중 하나를 가진다. -* Success: 컨테이너가 진단을 통과함. -* Failure: 컨테이너가 진단에 실패함. +* Success: 컨테이너가 진단을 통과함. +* Failure: 컨테이너가 진단에 실패함. * Unknown: 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안됨. -kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고 +kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 종류의 프로브를 수행하고 그에 반응할 수 있다. -* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약 - 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 - [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가 - 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. +* `livenessProbe`는 컨테이너가 동작 중인지 여부를 나타낸다. 만약 + 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 + [재시작 정책](#재시작-정책)의 대상이 된다. 만약 컨테이너가 + 활성 프로브를 제공하지 않는 경우, 기본 상태는 `Success`이다. -* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. - 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 - 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 - 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 - 지원하지 않는다면, 기본 상태는 `Success`이다. +* `readinessProbe`는 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다. + 만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 + 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 + 초기 지연 이전의 기본 상태는 `Failure`이다. 만약 컨테이너가 준비성 프로브를 + 지원하지 않는다면, 기본 상태는 `Success`이다. ### 언제 활성 또는 준비성 프로브를 사용해야 하는가? -만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 -상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 -반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에 -따라서 올바른 대처를 자동적으로 수행할 것이다. +만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 +상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 +반드시 필요한 것은 아니다. 그 경우에는 kubelet이 파드의 `restartPolicy`에 +따라서 올바른 대처를 자동적으로 수행할 것이다. -프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 +프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, 활성 프로브를 지정하고, `restartPolicy`를 항상(Always) 또는 실패 시(OnFailure)로 지정한다. -프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, -준비성 프로브를 지정하길 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 -보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 -시작되고 프로브가 성공하기 시작한 이후에만 -트래픽을 받는다는 뜻이다. +프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하길 바란다. +이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, +스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 +시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다. +만약 컨테이너가 대량의 데이터, 설정 파일들, +또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다. -만약 컨테이너가 대량의 데이터, 설정 파일들, 또는 시동 중 마그레이션을 처리해야 한다면, +만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 프로브를 지정하길 바란다. +준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다. -만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 -프로브를 지정하길 바란다. 준비성 프로브는 활성 프로브와는 -다르게 준비성에 특정된 엔드포인트를 확인한다. - -파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로, -준비성 프로브가 필요하지는 않다는 점을 유념해야한다. 삭제 시에, 파드는 -프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. -파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 +파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로, +준비성 프로브가 필요하지는 않다는 점을 유념해야한다. 삭제 시에, 파드는 +프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. +파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 남아있는다. -활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는, +활성 프로브 및 준비성 프로브를 설정하는 방법에 대한 추가적인 정보는, [활성 프로브 및 준비성 프로브 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)를 참조하면 된다. ## 파드 및 컨테이너 상태 -파드 및 컨테이너 상태에 대한 자세한 정보는, [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) -및 +파드 및 컨테이너 상태에 대한 자세한 정보는, +[PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) 및 [ContainerStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)를 참조하면 된다. -파드의 상태로서 보고되는 정보는 현재의 -[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 의존적이라는 점에 유의하길 바란다. +파드의 상태로서 보고되는 정보는 +현재의 [ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 +의존적이라는 점에 유의하길 바란다. ## 컨테이너 상태 -일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다. +일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다. * `Waiting`: 컨테이너의 기본 상태이다. 컨테이너가 Running 이나 Terminated 상태가 아닌 경우, Waiting 상태이다. Waiting 상태의 컨테이너는 이미지를 내려받거나(pull), 시크릿을 적용하는 등의 필요한 오퍼레이션이 수행 중인 상태이다. 이 상태와 더불어서, 더 자세한 정보를 제공하기 위해 상태에 대한 메시지와 이유가 출력된다. @@ -156,19 +166,19 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 Reason: ErrImagePull ... ``` - + * `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. 컨테이너가 Running 상태가 되면, `postStart` 훅이 (존재한다면) 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다. - + ```yaml ... State: Running Started: Wed, 30 Jan 2019 16:46:38 +0530 ... - ``` - + ``` + * `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다. 컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다. - + ```yaml ... State: Terminated @@ -177,18 +187,18 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지 Started: Wed, 30 Jan 2019 11:45:26 +0530 Finished: Wed, 30 Jan 2019 11:45:26 +0530 ... - ``` + ``` ## 파드의 준비성 게이트(readiness gate) {{< feature-state for_k8s_version="v1.14" state="stable" >}} -파드의 준비성에 대한 확장성을 추가하기 위해서 -추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, +파드의 준비성에 대한 확장성을 추가하기 위해서 +추가적인 피드백이나 신호를 `PodStatus`에 주입하는 방법인, [파드 준비++](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/0007-pod-ready%2B%2B.md)라는 특징이 쿠버네티스 1.11에서 소개되었다. -파드의 준비성을 평가하기 위한 추가적인 조건들을 `PodSpec` 내의 새로운 `ReadinessGate` 필드를 -통해서 지정할 수 있다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 -조건을 찾지 못한다면, 그 조건의 상태는 +파드의 준비성을 평가하기 위한 추가적인 조건들을 `PodSpec` 내의 새로운 `ReadinessGate` 필드를 +통해서 지정할 수 있다. 만약 쿠버네티스가 `status.conditions` 필드에서 해당하는 +조건을 찾지 못한다면, 그 조건의 상태는 기본 값인 "`False`"가 된다. 아래는 한 예제를 보여준다. ```yaml @@ -200,7 +210,7 @@ spec: status: conditions: - type: Ready # 이것은 내장된 PodCondition이다 - status: "True" + status: "False" lastProbeTime: null lastTransitionTime: 2018-01-01T00:00:00Z - type: "www.example.com/feature-1" # 추가적인 PodCondition @@ -212,72 +222,76 @@ status: ready: true ... ``` -파드의 새로운 조건들은 쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다. -`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, -새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 -통한 `PATCH` 액션을 통해서 주입되어야 한다. -새로운 파드 조건들이 적용된 경우, 파드는 **오직** +파드의 새로운 조건들은 +쿠버네티스의 [레이블 키 포멧](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)을 준수해야 한다. +`kubectl patch` 명령어가 오브젝트 상태 패치(patching)를 아직 제공하지 않기 때문에, +새로운 파드 조건들은 [KubeClient 라이브러리](/docs/reference/using-api/client-libraries/)를 통한 `PATCH` 액션을 통해서 주입되어야 한다. + +새로운 파드 조건들이 적용된 경우, 파드는 **오직** 다음 두 문장이 모두 참일 때만 준비 상태로 평가된다. * 파드 내의 모든 컨테이너들이 준비 상태이다. * `ReadinessGates`에 지정된 모든 조건들이 "`True`"이다. -파드 준비성 평가에 대한 변경을 촉진하기 위해서, 이전 파드 조건인 -`Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. +파드 준비성 평가에 대한 변경을 촉진하기 위해서, +이전 파드 조건인 `Ready`를 포착하기 위한 새로운 파드 조건 `ContainersReady`가 소개되었다. -K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 -위해서는 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를 참으로 설정함으로써 명시적으로 -활성화해야 한다. +K8s 1.11에서, 알파 특징으로서, "파드 준비++" 특징을 사용하기 위해서는 +[특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)의 `PodReadinessGates`를 +참으로 설정함으로써 명시적으로 활성화해야 한다. K8s 1.12에서는, 해당 특징이 기본으로 활성화되어 있다. ## 재시작 정책 -PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 -가지고 있다. 기본 값은 항상(Always)이다. -`restartPolicy`는 파드 내의 모든 컨테이너들에 적용된다. `restartPolicy`는 -같은 노드에 있는 kubelet에 의한 컨테이너들의 재시작에만 관련되어 있다. kubelet에 의해서 재시작되는 종료된 -컨테이너는 5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 -기준으로 재시작되며, 10분의 성공적 실행 후에 재설정된다. -[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이, +PodSpec은 항상(Always), 실패 시(OnFailure), 절대 안 함(Never) 값으로 설정 가능한 `restartPolicy` 필드를 가지고 있다. +기본 값은 항상(Always)이다. +`restartPolicy`는 파드 내의 모든 컨테이너들에 적용된다. `restartPolicy`는 +같은 노드에 있는 kubelet에 의한 컨테이너들의 재시작에만 관련되어 있다. +kubelet에 의해서 재시작되는 종료된 컨테이너는 +5분으로 제한된 지수 백-오프 지연(10초, 20초, 40초 ...)을 기준으로 재시작되며, +10분의 성공적 실행 후에 재설정된다. +[파드 문서](/docs/user-guide/pods/#durability-of-pods-or-lack-thereof)에서 의논된 바와 같이, 파드는 일단 한 노드에 바운드되고 나면, 다른 노드에 다시 바운드되지 않는다. + ## 파드의 일생(lifetime) -일반적으로, 파드는 누군가 파드를 파괴할 때까지 사라지지 않는다. 그것은 주로 -사람이나 컨트롤러에 의해서 일어난다. 이 법칙에 대한 유일한 예외는 -일정 기간(마스터의 `terminated-pod-gc-threshold`에 의해 결정되는) +일반적으로, 파드는 누군가 파드를 파괴할 때까지 사라지지 않는다. +그것은 주로 사람이나 컨트롤러에 의해서 일어난다. +이 법칙에 대한 유일한 예외는 일정 기간(마스터의 `terminated-pod-gc-threshold`에 의해 결정되는) 이상 파드의 `phase`가 Succeeded 또는 Failed라서 파드가 만료되고 자동적으로 파괴되는 경우이다. 세 가지 유형의 컨트롤러를 사용할 수 있다. -- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 - 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 +- 배치 연산과 같이, 종료가 예상되는 파드를 위해서는 [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/)을 + 사용하길 바란다. 잡은 `restartPolicy`가 실패 시(OnFailure) 또는 절대 안 함(Never)으로 지정된 경우에 적합하다. -- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), +- 웹 서버와 같이, 종료가 예상되지 않는 파드에 대해서는 + [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), [레플리카 셋](/docs/concepts/workloads/controllers/replicaset/), 또는 - [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. - 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 + [디플로이먼트](/docs/concepts/workloads/controllers/deployment/)를 사용하길 바란다. + 레플리케이션 컨트롤러는 `restartPolicy`가 항상(Always)으로 지정된 경우에만 적합하다. -- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길 - 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. +- 머신 당 하나씩 실행해야하는 파드를 위해서는 [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)을 사용하길 + 바란다. 왜냐하면 데몬 셋은 특정 머신 전용 시스템 서비스(machine-specific system service)를 제공하기 때문이다. -세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 -직접적으로 생성하는 것 보다는, 적절한 컨트롤러를 생성하고 컨트롤러가 파드를 -생성하도록 하는 것이 추천된다. 그 이유는 파드 -혼자서는 머신의 실패에 탄력적(resilient)이지 않지만, 컨트롤러는 탄력적이기 때문이다. +세 가지 모든 컨트롤러 유형은 PodTemplate을 가지고 있다. 파드를 +직접적으로 생성하는 것 보다는, 적절한 컨트롤러를 생성하고 컨트롤러가 파드를 +생성하도록 하는 것이 추천된다. 그 이유는 파드 +혼자서는 머신의 실패에 탄력적(resilient)이지 않지만, 컨트롤러는 탄력적이기 때문이다. -만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 +만약 노드가 죽거나 다른 클러스터의 다른 노드들로부터 연결이 끊기면, 쿠버네티스는 잃어버린 노드에 있는 모든 파드의 `phase`를 실패된(Failed)으로 설정하는 정책을 적용한다. ## 예제 ### 고급 활성 프로브 예제 -활성 프로브는 kubelet에 의해서 실행된다. 따라서 모든 요청은 +활성 프로브는 kubelet에 의해서 실행된다. 따라서 모든 요청은 kubelet 네트워크 네임스페이스에서 이루어진다. ```yaml @@ -310,8 +324,8 @@ spec: ### 상태 예제 - * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 성공으로 종료됐다. - * 완료 이벤트를 기록한다. + * 파드가 동작 중이고 하나의 컨테이너를 가지고 있다. 컨테이너는 성공으로 종료됐다. + * 완료 이벤트를 기록한다. * 만약 `restartPolicy`가 : * 항상(Always)이면: 컨테이너는 재시작되고, 파드의 `phase`는 Running으로 유지된다. * 실패 시(OnFailure)이면: 파드의 `phase`는 Succeeded가 된다. @@ -347,7 +361,7 @@ spec: * 파드 동작 중에, 디스크가 죽었다. * 모든 컨테이너들을 죽인다. - * 적절한 이벤트를 기록한다. + * 적절한 이벤트를 기록한다. * 파드의 `phase`는 Failed가 된다. * 만약 컨트롤러로 실행되었다면, 파드는 어딘가에서 재생성된다. diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 4b0fd01082..9cda8110b5 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -10,40 +10,39 @@ weight: 80 쿠버네티스 문서 또는 웹사이트에 기여하여 도움을 제공하고 싶다면, 우리는 당신의 도움을 기쁘게 생각한다! 당신이 새로운 프로젝트에 참여했거나 -오랜 시간 동안 진행해온 누군가로써, -혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로써 -기여할 수 있다. +오랜 시간 동안 진행해온 누군가로써, +혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로써 기여할 수 있다. -쿠버네티스 커뮤니티에 참여하거나, 우리에 대해 더 많이 알아보고 싶다면, [쿠버네티스 커뮤니티 사이트](/community/)를 방문하자. 쿠버네티스 문서 스타일 가이드에 대해 더 많은 정보를 알고 싶다면, [스타일 가이드](/docs/contribute/style/style-guide/)를 참고하자. {{% capture body %}} -## 컨트리뷰터 유형 +## 문서 컨트리뷰터 유형 - 쿠버네티스 조직의 _멤버_ 는 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고, 프로젝트에 어느 정도 시간과 노력을 바친 사람이다. 멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을 참고하라. -- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 - SIG Docs 승안자가 적합한 +- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서 + SIG Docs 승안자가 적합한 GitHub 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한 - 쿠버네티스 조직의 멤버이다. + 쿠버네티스 조직의 멤버이다. - SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다. 승인자는 풀 리퀘스트를 머지(merge)할 수 있고, 쿠버네티스 조직을 대표하여 콘텐츠를 공개한다. 승인자는 거대한 쿠버네티스 커뮤니티에서 SIG Docs를 대표할 수 있다. - SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은 + SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은 상당한 시간을 필요로 한다. -## 기여할 수 있는 방법 +## 문서화에 기여할 수 있는 방법 -이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일, -그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 -일으로 나누어졌다. 지속적으로 기여를 하는 것은 이미 만들어진 도구(tooling)와 조직의 결정을 +이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일, +그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는 일로 나누어졌다. +지속적으로 기여를 하는 것은 +이미 만들어진 도구(tooling)와 조직의 결정을 이해하는데 도움이 될 것이다. -이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만, +이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만, 시작하는 데에 도움이 될 것이다. - [누구나](/docs/contribute/start/) @@ -70,4 +69,10 @@ weight: 80 - 문서 테스트 개선 제안 - 쿠버네티스 website 또는 기타 도구(tooling) 개선 제안 + +## 추가적인 기여 방법 + +- 트위터나 스택오버플로(Stack Overflow) 등의 온라인 포럼의 쿠버네티스 커뮤니티에 기여하거나 지역 모임과 쿠버네티스 이벤트에 관하여 알고 싶다면 [쿠버네티스 커뮤니티 사이트](/community/)를 확인한다. +- 기능 개발에 기여하려면 [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 시작한다. + {{% /capture %}} diff --git a/content/ko/docs/contribute/participating.md b/content/ko/docs/contribute/participating.md index babb4ce67a..5162b44177 100644 --- a/content/ko/docs/contribute/participating.md +++ b/content/ko/docs/contribute/participating.md @@ -8,23 +8,25 @@ card: {{% capture overview %}} -SIG Docs는 쿠버네티스 프로젝트의 +SIG Docs는 쿠버네티스 프로젝트의 [분과회(special interest group)](https://github.com/kubernetes/community/blob/master/sig-list.md) -중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. -분과회에 대한 보다 자세한 정보는 +중 하나로, 쿠버네티스 전반에 대한 문서를 작성하고, 업데이트하며 유지보수하는 일을 주로 수행한다. +분과회에 대한 보다 자세한 정보는 [커뮤니티 GitHub 저장소 내 SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) 를 참조한다. -SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. 누구나 풀 리퀘스트(PR)를 요청할 수 있고, +SIG Docs는 모든 컨트리뷰터의 콘텐츠와 리뷰를 환영한다. +누구나 풀 리퀘스트(PR)를 요청할 수 있고, 누구나 콘텐츠에 대해 이슈를 등록하거나 진행 중인 풀 리퀘스트에 코멘트를 등록할 수 있다. SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인자](#승인자)가 될 수도 있다. 이런 역할은 변경을 승인하고 커밋할 수 있도록 보다 많은 접근 권한과 이에 상응하는 책임이 수반된다. 쿠버네티스 커뮤니티 내에서 멤버십이 운영되는 방식에 대한 보다 많은 정보를 확인하려면 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md) -문서를 확인한다. 문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 -웹사이트와 문서를 관리하는 책임을 가지는 SIG Docs에서, 이런 체계가 작동하는 특유의 방식에 대한 윤곽을 -잡아보겠다. +문서를 확인한다. +문서의 나머지에서는 대외적으로 쿠버네티스를 가장 잘 드러내는 수단 중 하나인 쿠버네티스 웹사이트와 +문서를 관리하는 책임을 가지는 SIG Docs에서, +이런 체계가 작동하는 특유의 방식에 대한 윤곽을 잡아보겠다. {{% /capture %}} @@ -33,42 +35,48 @@ SIG Docs 내에서, [멤버](#멤버), [리뷰어](#리뷰어), 또는 [승인 ## 역할과 책임 풀 리퀘스트가 콘텐츠를 게재하는데 사용되는 브랜치(현재는 `master`)에 머지되면, 해당 콘텐츠가 세상에 -발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록, SIG Docs 승인자만 -풀 리퀘스트를 머지할 수 있도록 제한한다. 다음과 같이 진행된다. +발행되어 널리 읽힐 수 있게 된다. 발행된 콘텐츠가 높은 품질을 유지하도록, +SIG Docs 승인자만 풀 리퀘스트를 머지할 수 있도록 제한한다. +다음과 같이 진행된다. -- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당 +- 풀 리퀘스트에 `lgtm`과 `approve` 레이블이 부여되고 `hold` 레이블이 없는 경우에, 해당 풀 리퀘스트가 자동으로 머지된다. -- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나 - `/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가 자동으로 머지되는 것을 막을 수 있다. +- 쿠버네티스 조직 멤버와 SIG Docs 승인자는 코멘트를 추가해서(`/hold` 코멘트를 추가하거나 + `/lgtm` 코멘트를 달지 않아서) 주어진 풀 리퀘스트가 + 자동으로 머지되는 것을 막을 수 있다. - 쿠버네티스 멤버 누구나 `/lgtm` 코멘트를 달아서 `lgtm` 레이블을 추가할 수 있다. - `/approve` 코멘트를 달아서 풀 리퀘스트를 머지할 수 있는 SIG Docs 멤버는 승인자 뿐이다. - 일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는 - [SIG Docs chairperson](#sig-docs-chairperson) 같이 특화된 역할을 수행한다. + 일부 승인자는 추가로 [PR Wrangler](#pr-wrangler) 또는 + [SIG Docs chairperson](#sig-docs-chairperson) 같이 + 특화된 역할을 수행한다. 쿠버네티스 조직 멤버와 SIG Docs 승인자 역할 사이의 기대와 차이에 대한 보다 많은 정보는 -[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다. -다음 섹션에서는 이런 역할과 SIG Docs에서 이들이 작동하는 방식에 대해 보다 상세한 내용을 -다룬다. +[컨트리뷰터 유형](/docs/contribute#types-of-contributor) 문서를 참고한다. +다음 섹션에서는 이런 역할과 SIG Docs에서 +이들이 작동하는 방식에 대해 +보다 상세한 내용을 다룬다. ### 모든 사람 문서를 포함해서, 쿠버네티스의 모든 부분에 대해서 누구나 이슈를 제기할 수 있다. CLA에 서명한 누구나 풀 리퀘스트를 제출할 수 있다. CLA에 서명할 수 없다면, -쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다. +쿠버네티스 프로젝트는 컨트리뷰션을 수용할 수 없다. ### 멤버 [쿠버네티스 조직](https://github.com/kubernetes)의 모든 멤버가 풀 리퀘스트를 리뷰할 수 있고, 기술적 정확도를 기하기 위해 SIG Docs 팀 멤버가 다른 분과회 멤버의 리뷰를 요청하는 일도 자주 발생한다. -SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다. -풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다. 쿠버네티스 조직의 멤버가 아니라면, +SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주는 리뷰와 피드백 또한 환영한다. +풀 리퀘스트에 `/lgtm` 코멘트를 달아서 찬성 의사를 표시할 수 있다. +쿠버네티스 조직의 멤버가 아니라면, `/lgtm` 코멘트는 자동화 시스템에 유효하지는 않다. 쿠버네티스 조직의 모든 멤버는 `/hold` 코멘트를 달아서 풀 리퀘스트가 머지되는 것을 막을 수 있다. -또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다. 해당 PR이 이미 -적임자로부터 `/lgtm`과 `/approve`를 받은 경우라면 말이다. +또한 모든 멤버가 `/hold` 코멘트를 삭제해서 PR이 머지될 수 있도록 할 수도 있다. +해당 PR이 이미 적임자로부터 +`/lgtm`과 `/approve`를 받은 경우라면 말이다. #### 멤버 되기 @@ -79,12 +87,13 @@ SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주 1. 멤버십을 [후원](/docs/contribute/advanced#sponsor-a-new-contributor)해 줄 두 명의 리뷰어 또는 승인자를 찾는다. - [쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는 - [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 + [쿠버네티스 Slack 인스턴스의 #sig-docs 채널](https://kubernetes.slack.com) 또는 + [SIG Docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 후원을 요청한다. - + {{< note >}} - SIG Docs 멤버 개인에게 직접 email을 보내거나 Slack 다이렉트 메시지를 보내지 않는다. + SIG Docs 멤버 개인에게 직접 email을 보내거나 + Slack 다이렉트 메시지를 보내지 않는다. {{< /note >}} 2. `kubernetes/org` 리포지터리에 멤버십을 요청하는 GitHub 이슈를 등록한다. @@ -92,116 +101,131 @@ SIG Docs는 쿠버네티스 조직의 멤버십 상태와 상관없이 보내주 문서의 가이드라인을 따라서 양식을 채운다. 3. 해당 GitHub 이슈에 후원자를 at-mentioning(`@`을 포함한 코멘트를 추가)하거나 - 링크를 직접 보내주어서 후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다. + 링크를 직접 보내주어서 + 후원자가 해당 GitHub 이슈를 확인하고 `+1` 표를 줄 수 있도록 한다. -4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고 해당 GitHub 이슈를 종료한다. +4. 멤버십이 승인되면, 요청에 할당된 GitHub 관리자 팀 멤버가 승인되었음을 업데이트해주고 + 해당 GitHub 이슈를 종료한다. 축하한다, 이제 멤버가 되었다! -어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우, 멤버십 위원회에서 재지원 전에 필요한 정보나 단계를 알려준다. +어떤 이유에서 멤버십 요청이 즉시 수용되지 않는 경우, +멤버십 위원회에서 재지원 전에 +필요한 정보나 단계를 알려준다. ### 리뷰어 -리뷰어는 +리뷰어는 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참고한다. -리뷰어는 문서 풀 리퀘스트를 리뷰하고 제안받은 변경에 대한 피드백을 제공한다. +리뷰어는 문서 풀 리퀘스트를 리뷰하고 +제안받은 변경에 대한 피드백을 제공한다. -자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에 +자동화 시스템은 풀 리퀘스트에 대해 리뷰어를 할당하고, 컨트리뷰터는 해당 풀 리퀘스트에 `/assign [@_github_handle]` 코멘트를 남겨서 특정 리뷰어에게 리뷰를 요청할 수 있다. -풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, 리뷰어는 `/lgtm` 코멘트를 +풀 리퀘스트가 기술적으로 정확하고 더 변경이 필요하지 않다는 의미로, +리뷰어는 `/lgtm` 코멘트를 해당 풀 리퀘스트에 추가할 수 있다. -할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우, 다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를 -할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다. +할당된 리뷰어가 내용을 아직 리뷰하지 않은 경우, +다른 리뷰어가 나설 수 있다. 추가로, 기술 리뷰어를 +할당해서 그들이 `/lgtm`을 주기를 기다릴 수도 있다. 사소한 변경이나 기술적 리뷰가 필요한 PR의 경우, SIG Docs [승인자](#승인자)가 `/lgtm`을 줄 수도 있다. 리뷰어의 `/approve` 코멘트는 자동화 시스템에서 무시된다. -SIG Docs 리뷰어가 되는 방법과 수반되는 책임과 시간 할애에 대한 보다 많은 정보는 +SIG Docs 리뷰어가 되는 방법과 +수반되는 책임과 시간 할애에 대한 보다 많은 정보는 [리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. #### 리뷰어 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer)을 -충족하면, SIG Docs 리뷰어가 될 수 있다. 다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 -반드시 별도로 지원해야 한다. +충족하면, SIG Docs 리뷰어가 될 수 있다. +다른 SIG의 리뷰어는 SIG Docs의 리뷰어 자격에 +반드시 별도로 지원해야 한다. -지원하려면, `kubernetes/website` 저장소의 +지원하려면, `kubernetes/website` 저장소의 [최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs +내 `reviewers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs 승인자에게 할당한다. 풀 리퀘스트가 승인되면, 이제 SIG Docs 리뷰어가 된다. [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. -일단 승인되면, 현재 SIG Docs 승인자가 +일단 승인되면, 현재 SIG Docs 승인자가 [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -GitGub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 +GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. ### 승인자 -승인자는 +승인자는 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) GitHub 그룹의 멤버이다. [SIG Docs의 팀과 그룹](#teams-and-groups-within-sig-docs) 문서를 참조한다. 승인자는 PR을 머지할 수 있으므로, 쿠버네티스 웹사이트에 콘텐츠를 게재할 수 있다. -PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다. 승인자가 아닌 누군가가 승인 -코멘트를 남기더라도, 자동화 시스템은 이를 무시한다. +PR을 승인하려면, 승인자는 `/approve` 코멘트를 해당 PR에 남긴다. +승인자가 아닌 누군가가 승인 코멘트를 남기더라도, +자동화 시스템은 이를 무시한다. PR이 이미 `/lgtm`을 받았거나, 승인자가 `/lgtm`을 포함한 코멘트를 남긴 경우에는 -해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 +해당 PR이 자동으로 머지된다. SIG Docs 승인자는 추가적인 기술 리뷰가 필요하지 않은 변경에 대해서만 `/lgtm`을 남겨야한다. -SIG Docs 승인자가 되는 방법과 수반되는 책임과 시간 할애에 대한 보다 많은 정보는 +SIG Docs 승인자가 되는 방법과 +수반되는 책임과 시간 할애에 대한 보다 많은 정보는 [리뷰어나 승인자 되기](#리뷰어나-승인자-되기) 문서를 참조한다. #### 승인자 되기 [요건](https://github.com/kubernetes/community/blob/master/community-membership.md#approver)을 -충족하면, SIG Docs 승인자가 될 수 있다. 다른 SIG의 승인자는 SIG Docs의 승인자 자격에 -반드시 별도로 지원해야 한다. +충족하면, SIG Docs 승인자가 될 수 있다. +다른 SIG의 승인자는 SIG Docs의 승인자 자격에 +반드시 별도로 지원해야 한다. -지원하려면, `kubernetes/website` 저장소의 +지원하려면, `kubernetes/website` 저장소의 [최상위 OWNERS 파일](https://github.com/kubernetes/website/blob/master/OWNERS) -내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs +내 `approvers` 섹션에 자신을 추가하는 풀 리퀘스트를 연다. PR을 한 명 이상의 현재 SIG Docs 승인자에게 할당한다. 풀 리퀘스트가 승인되면, 이제 SIG Docs 승인자가 된다. [K8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)이 새로운 풀 리퀘스트에 대한 리뷰어로 당신을 추천하게 된다. -일단 승인되면, 현재 SIG Docs 승인자가 +일단 승인되면, 현재 SIG Docs 승인자가 [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) -GitGub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 +GitHub 그룹에 당신을 추가하기를 요청한다. `kubernetes-website-admins` GitHub 그룹의 멤버만이 신규 멤버를 GitHub 그룹에 추가할 수 있다. #### 웹사이트 관리자 되기 `kubernetes-website-admins` GitHub 그룹의 멤버는 GitHub 그룹의 멤버십을 관리할 수 있고 -리포지터리를 세팅하거나 웹훅(webhook)을 추가, 삭제하고 트러블슈팅하는 것을 포함한 모든 관리 권한을 -가질 수 있다. 모든 SIG Docs 승인자가 이 수준의 액세스를 할 필요는 없다. +리포지터리를 세팅하거나 웹훅(webhook)을 추가, 삭제하고 트러블슈팅하는 것을 포함한 +모든 관리 권한을 가질 수 있다. +모든 SIG Docs 승인자가 이 수준의 액세스를 할 필요는 없다. -만약 이 수준의 접근 권한이 필요하다면, 현재 웹사이트 관리자나 +만약 이 수준의 접근 권한이 필요하다면, 현재 웹사이트 관리자나 [쿠버네티스 Slack](https://kubernetes.slack.com) #sig-docs 채널에서 말한다. #### PR Wrangler -SIG Docs 승인자는 +SIG Docs 승인자는 [PR Wrangler 로테이션 스케줄러](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 -올라서 주 단위로 돌아가며 역할을 수행한다. 모든 SIG Docs 승인자는 이 로테이션에 참여하게 된다. 보다 자세한 내용은 +올라서 주 단위로 돌아가며 역할을 수행한다. +모든 SIG Docs 승인자는 이 로테이션에 참여하게 된다. 보다 자세한 내용은 [일주일 간 PR Wrangler 되기](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) 문서를 참고한다. #### SIG Docs chairperson SIG Docs를 포함한 각 SIG는, 한 명 이상의 SIG 멤버가 의장 역할을 하도록 선정한다. 이들은 SIG Docs와 -다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 -그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. 현재 의장의 목록을 확인하려면 +다른 쿠버네티스 조직 간 연락책(point of contact)이 된다. 이들은 쿠버네티스 프로젝트 전반의 조직과 +그 안에서 SIG Docs가 어떻게 운영되는지에 대한 폭넓은 지식을 갖추어야한다. +현재 의장의 목록을 확인하려면 [리더십](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) 문서를 참조한다. @@ -217,16 +241,18 @@ GitHub의 SIG Docs 그룹은 두 팀을 정의한다. - [@kubernetes/sig-docs-maintainers](https://github.com/orgs/kubernetes/teams/sig-docs-maintainers) - [@kubernetes/sig-docs-pr-reviews](https://github.com/orgs/kubernetes/teams/sig-docs-pr-reviews) -그룹의 전원과 의사소통하기 위해서 각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. +그룹의 전원과 의사소통하기 위해서 +각각 GitHub 코멘트에서 그룹의 `@name`으로 참조할 수 있다. 이 팀은 중복되지만, 정확히 일치하지는 않으며, 이 그룹은 자동화 툴에서 사용된다. -이슈, 풀 리퀘스트를 할당하고, PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다. +이슈, 풀 리퀘스트를 할당하고, +PR 승인을 지원하기 위해서 자동화 시스템이 OWNERS 파일의 정보를 활용한다. ### OWNERS 파일과 전문(front-matter) 쿠버네티스 프로젝트는 GitHub 이슈와 풀 리퀘스트 자동화와 관련해서 prow라고 부르는 자동화 툴을 사용한다. -[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 다음의 두 -[prow 플러그인](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210)을 +[쿠버네티스 웹사이트 리포지터리](https://github.com/kubernetes/website)는 +다음의 두개의 [prow 플러그인](https://github.com/kubernetes/test-infra/blob/master/prow/plugins.yaml#L210)을 사용한다. - blunderbuss @@ -235,18 +261,20 @@ GitHub의 SIG Docs 그룹은 두 팀을 정의한다. 이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) -파일을 사용해서 해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. +파일을 사용해서 +해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. OWNERS 파일은 SIG Docs 리뷰어와 승인자의 목록을 포함한다. OWNERS 파일은 하위 디렉터리에 있을 수 있고, 해당 하위 디렉터리와 그 이하의 파일에 대해 리뷰어와 승인자 역할을 수행할 사람을 새로 지정할 수 있다. -일반적인 OWNERS 파일에 대한 보다 많은 정보는 +일반적인 OWNERS 파일에 대한 보다 많은 정보는 [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md) 문서를 참고한다. -추가로, 개별 마크다운(Markdown) 파일 내 전문에 리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub -그룹으로 열거할 수 있다. +추가로, 개별 마크다운(Markdown) 파일 내 전문에 +리뷰어와 승인자를 개별 GitHub 사용자 이름이나 GitHub 그룹으로 열거할 수 있다. -OWNERS 파일과 마크다운 파일 내 전문의 조합은 자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 +OWNERS 파일과 마크다운 파일 내 전문의 조합은 +자동화 시스템이 누구에게 기술적, 편집적 리뷰를 요청해야 할지를 PR 소유자에게 조언하는데 활용된다. {{% /capture %}} diff --git a/content/ko/docs/reference/glossary/app-container.md b/content/ko/docs/reference/glossary/app-container.md new file mode 100644 index 0000000000..0349e1f92c --- /dev/null +++ b/content/ko/docs/reference/glossary/app-container.md @@ -0,0 +1,20 @@ +--- +title: 앱 컨테이너(App Container) +id: app-container +date: 2019-02-12 +full_link: +short_description: > + 워크로드의 일부를 실행하는데 사용되는 컨테이너. 초기화 컨테이너와 비교된다. + +aka: +tags: +- workload +--- + 애플리케이션 컨테이너(또는 앱 컨테이너)는 {{< glossary_tooltip text="파드" term_id="pod" >}} 내의 모든 {{< glossary_tooltip text="초기화 컨테이너" term_id="init-container" >}}가 완료된 후 시작되는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}이다. + + + +초기화 컨테이너를 사용하면 전체 +{{< glossary_tooltip text="워크로드" term_id="workload" >}}에 대해서 중요한 초기화 세부 사항을 분리할 수 있으며, 애플리케이션 +컨테이너가 시작된 후에는 계속 동작시킬 필요가 없다. +만약 파드에 설정된 초기화 컨테이너가 없는 경우, 파드의 모든 컨테이너는 앱 컨테이너이다. diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md new file mode 100755 index 0000000000..ff2153c73b --- /dev/null +++ b/content/ko/docs/reference/glossary/cronjob.md @@ -0,0 +1,19 @@ +--- +title: 크론잡(CronJob) +id: cronjob +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/cron-jobs/ +short_description: > + 주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + +aka: +tags: +- core-object +- workload +--- + 주기적인 일정에 따라 실행되는 [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)을 관리. + + + +*crontab* 파일의 라인과 유사하게, 크론잡 오브젝트는 [크론](https://en.wikipedia.org/wiki/Cron) 형식을 사용하여 일정을 지정한다. + diff --git a/content/ko/docs/reference/glossary/replication-controller.md b/content/ko/docs/reference/glossary/replication-controller.md new file mode 100755 index 0000000000..f5c19a33aa --- /dev/null +++ b/content/ko/docs/reference/glossary/replication-controller.md @@ -0,0 +1,19 @@ +--- +title: 레플리케이션 컨트롤러(Replication Controller) +id: replication-controller +date: 2018-04-12 +full_link: +short_description: > + 특정 수의 파드 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스. + +aka: +tags: +- workload +- core-object +--- + 특정 수의 파드 인스턴스가 항상 동작하도록 보장하는 쿠버네티스 서비스. + + + +레플리케이션 컨트롤러는 파드에 설정된 값에 따라서, 동작하는 파드의 인스턴스를 자동으로 추가하거나 제거할 것이다. 파드가 삭제되거나 실수로 너무 많은 수의 파드가 시작된 경우, 파드가 지정된 수의 인스턴스로 돌아갈 수 있게 허용한다. + diff --git a/content/ko/docs/reference/glossary/workload.md b/content/ko/docs/reference/glossary/workload.md new file mode 100644 index 0000000000..80aaa95d34 --- /dev/null +++ b/content/ko/docs/reference/glossary/workload.md @@ -0,0 +1,28 @@ +--- +title: 워크로드(Workloads) +id: workloads +date: 2019-02-13 +full_link: /docs/concepts/workloads/ +short_description: > + 워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다. + +aka: +tags: +- fundamental +- core-object +- workload +--- + 워크로드는 클러스터의 컨테이너를 동작시키고 관리하기 위해 사용하는 오브젝트이다. + + + +쿠버네티스는 +애플리케이션의 현재 상태에 따라 워크로드의 디플로이먼트와 업데이트를 수행한다. +워크로드는 데몬셋, 디플로이먼트, 잡, 파드, 레플리카셋, 레플리케이션컨트롤러, 스테이트풀셋과 같은 오브젝트를 포함한다. + +예를 들어, 웹 요소와 데이터베이스 요소가 있는 워크로드는 +데이터베이스를 {{< glossary_tooltip text="파드" term_id="pod" >}}의 한 +{{< glossary_tooltip text="스테이트풀셋" term_id="StatefulSet" >}} 안에서 실행할 것이며, +웹서버를 많은 웹 앱 {{< glossary_tooltip text="파드" term_id="pod" >}}로 구성된 +{{< glossary_tooltip text="디플로이먼트" term_id="Deployment" >}}를 통해 실행할 것이다. + diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index 6cce37f8ae..ed0158e3a5 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -56,7 +56,9 @@ echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~ kubectl config view # 병합된 kubeconfig 설정을 표시한다. # 동시에 여러 kubeconfig 파일을 사용하고 병합된 구성을 확인한다 -KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view +KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 + +kubectl config view # e2e 사용자의 암호를 확인한다 kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' @@ -265,6 +267,8 @@ kubectl delete pod,service baz foo # "baz kubectl delete pods,services -l name=myLabel # name=myLabel 라벨을 가진 파드와 서비스 삭제 kubectl delete pods,services -l name=myLabel --include-uninitialized # 초기화되지 않은 것을 포함하여, name=myLabel 라벨을 가진 파드와 서비스 삭제 kubectl -n my-ns delete po,svc --all # 초기화되지 않은 것을 포함하여, my-ns 네임스페이스 내 모든 파드와 서비스 삭제 +# awk pattern1 또는 pattern2에 매칭되는 모든 파드 삭제 +kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod ``` ## 실행 중인 파드와 상호 작용 diff --git a/content/ko/docs/setup/minikube.md b/content/ko/docs/setup/minikube.md index b634e3a72b..dc43fad420 100644 --- a/content/ko/docs/setup/minikube.md +++ b/content/ko/docs/setup/minikube.md @@ -5,8 +5,7 @@ content_template: templates/concept {{% capture overview %}} -Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. -Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 VM 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. +Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 VM 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. {{% /capture %}} @@ -30,15 +29,16 @@ Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자 ## 빠른 시작 여기부터는 Minikube 사용에 대한 간단한 데모이다. -VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 `minikube start`에 추가한다. Minikube는 다음의 드라이버를 지원한다. +VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 `minikube start`에 추가한다. +Minikube는 다음의 드라이버를 지원한다. * virtualbox * vmwarefusion * kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* kvm ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm-driver)) * hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated) -* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +아래 나오는 IP주소는 동적이고 변할 수 있음을 알린다. 이는 `minikube ip` 명령으로 확인할 수 있다. +* vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) * none (쿠버네티스 구성요소는 VM이 아닌 호스트상에서 동작한다. 이 드라이버를 사용하기 위해서는 Docker ([docker 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))와 리눅스 환경)이 필요하다. ```shell @@ -63,26 +63,30 @@ kubectl expose deployment hello-minikube --type=NodePort ``` service/hello-minikube exposed ``` + +에코 서버 파드를 실행했지만 노출된 서비스를 통해 curl 등의 접근하기 전에 +파드가 올라갈 때까지 기다려야 한다. +파드가 실행 중인지 확인하기 위해 다음을 이용할 수 있다. + ``` -# We have now launched an echoserver pod but we have to wait until the pod is up before curling/accessing it -# via the exposed service. -# To check whether the pod is up and running we can use the following: kubectl get pod ``` ``` NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s ``` -``` -# We can see that the pod is still being created from the ContainerCreating status + +이 파드는 ContainerCreating 상태임을 알 수 있다. kubectl get pod -``` + ``` NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 1/1 Running 0 13s ``` + +이제 파드가 Running 상태이므로 curl를 실행해 볼 수 있다. + ``` -# We can see that the pod is now Running and we will now be able to curl it: curl $(minikube service hello-minikube --url) ``` ``` @@ -200,22 +204,19 @@ minikube start \ ### 드라이버 플러그인 -지원하는 드라이버 상세 정보와 설치방법은 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 살펴보자 꼭 필요하다면 말이다. +지원하는 드라이버 상세 정보와 설치방법은 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 살펴보자 +꼭 필요하다면 말이다. ### Docker 데몬 재사용 -쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 Docker 데몬을 재사용하기에 매우 간편하다. -이 경우는 호스트 장비에 Docker 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. -또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 Docker 데몬 안에서 이미지를 빌드하기 때문이다. -Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. -혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, -만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. +쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 Docker 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 Docker 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 Docker 데몬 안에서 이미지를 빌드하기 때문이다. Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. 맥이나 리눅스 호스트의 Docker 데몬에서 이 작업이 가능하게 하려면 `docker-env command`를 쉘에서 사용해야 한다. ```shell eval $(minikube docker-env) ``` + 맥이나 리눅스 호스트에서 Minikube VM안에 Docker 데몬과 통신하도록 Docker를 명령행에서 사용할 수 있어야 한다. ```shell @@ -259,10 +260,10 @@ https_proxy= minikube start --docker-env http_proxy= --docke Minikube는 또한 "minikube" 컨텍스트를 생성하고, kubectl의 기본값으로 설정한다. 나중에 이 컨택스트를 변경하려면, `kubectl config use-context minikube` 명령을 실행하자. - #### 쿠버네티스 버전 지정 -Minikube에서 사용할 쿠버네티스 버전은 `--kubernetes-version` 문자열을 `minikube start` 명령에 추가하여 지정할 수 있다. +Minikube에서 사용할 쿠버네티스 버전은 `--kubernetes-version` 문자열을 +`minikube start` 명령에 추가하여 지정할 수 있다. 예를 들어, `v1.7.3`을 이용한다면 아래처럼 할 수 있다. ``` @@ -276,7 +277,8 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 이 플래그는 여러번 쓸 수 있어 여러 옵션 설정을 전달 할 수 있다. -이 플래그는 `component.key=value`형식의 문자열로, 앞에 `component`는 아래 목록에 하나의 문자열이며 `key`는 configuration struct의 값이고 `value`는 설정할 값이다(역주: key는 struct의 맴버명). +이 플래그는 `component.key=value`형식의 문자열로, +앞에 `component`는 아래 목록에 하나의 문자열이며 `key`는 configuration struct의 값이고 `value`는 설정할 값이다(역주: key는 struct의 맴버명). 올바른 키들은 각 컴포넌트의 쿠버네티스 `componentconfigs` 문서에서 찾아 볼 수 있다. 다음은 각각의 지원하는 설정에 대한 문서이다. @@ -312,7 +314,9 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 `minikube start` 명령어는 Minikube로 부르는 "[kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" 를 생성한다. 이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. -Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 `kubectl config use-context minikube`을 실행하자. +Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 + +`kubectl config use-context minikube`을 실행하자. 혹은 각 명령어를 `kubectl get pods --context=minikube`처럼 컨텍스트를 전달하십시오. @@ -349,7 +353,7 @@ Minikube VM은 tmpfs에서 부트하는데, 매우 많은 디렉터리가 재부 그러나, Minikube는 다음의 호스트 디렉터리 아래 파일은 유지하도록 설정되어 있다. * `/data` -* `/var/lib/rinikube` +* `/var/lib/minikube` * `/var/lib/docker` 이것은 `/data` 디렉터리에 데이터를 보존하도록 한 퍼시스턴트 볼륨 환경설정의 예이다. @@ -369,7 +373,7 @@ spec: ``` ## 호스트 폴더 마운트 -몇몇 드라이버는 VM 안에 호스트 폴더를 마운트하여 VM과 호스트 사이에 쉽게 파일을 공유할 수 있게 한다. 이들은 지금 설정할 수 없고 사용하는 드라이버나 운영체제에 따라 다르다. +어떤 드라이버는 VM 안에 호스트 폴더를 마운트하여 VM과 호스트 사이에 쉽게 파일을 공유할 수 있게 한다. 이들은 지금 설정할 수 없고 사용하는 드라이버나 운영체제에 따라 다르다. {{< note >}} 호스트 폴더 공유는 KVM 드라이버에서 아직 구현되어 있지 않다. @@ -393,7 +397,8 @@ spec: Minikube에서 커스텀 애드온을 적절히 시작하고 재시작할 수 있으려면, Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터리에 두자. -폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. +폴더 내부의 애드온은 Minikube VM으로 이동되어 +Minikube가 시작하거나 재시작될 때에 함께 실행된다. ## HTTP 프록시 환경에서 Minikube 사용 diff --git a/content/ko/docs/setup/pick-right-solution.md b/content/ko/docs/setup/pick-right-solution.md index a58e06bf38..ae62730ec2 100644 --- a/content/ko/docs/setup/pick-right-solution.md +++ b/content/ko/docs/setup/pick-right-solution.md @@ -24,16 +24,17 @@ card: 클러스터 구성을 위해 필요한 노력은 하나의 단일 명령어를 실행시키는 수준에서 직접 자신만의 맞춤형 클러스터를 세밀하게 만드는 수준에 이르기까지 다양하다. 알맞은 솔루션을 선택하기 위해서 이 가이드를 사용하자. -쿠버네티스를 시도해보기를 원한다면, [로컬 Docker 기반의 솔루션](#로컬-머신-솔루션)을 사용하자. +쿠버네티스를 시도해보기를 원한다면, [로컬 Docker 기반의 솔루션](#로컬-머신-솔루션)을 사용하자. -더 많은 머신과 높은 가용성으로 확장할 준비가 되었다면, [호스트 된 솔루션](#호스트-된-솔루션)이 생성하고 유지하기에 가장 쉽다. +더 많은 머신과 높은 가용성으로 확장할 준비가 되었다면, [호스트 된 솔루션](#호스트-된-솔루션)이 생성하고 유지하기에 가장 쉽다. [턴키 클라우드 솔루션](#턴키-클라우드-솔루션)은 클라우드 공급자들의 넓은 범위를 다루고 생성하기 위해서 약간의 명령어가 필요하다. [온-프레미스 턴키 클라우드 솔루션](#온-프레미스-턴키-클라우드-솔루션)은 프라이빗 네트워크의 보안과 결합된 턴키 클라우드 솔루션의 단순함을 가진다. 호스팅한 자원을 구성하는 방법을 이미 가지고 있다면, 머신 당 단일 명령어로 클러스터를 만들어내기 위해서 [kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하자. -[사용자 지정 솔루션](#사용자-지정-솔루션)은 단계별 지침부터 쿠버네티스 클러스터를 처음부터 설정하기 위한 일반적인 조언까지 다양하다. +[사용자 지정 솔루션](#사용자-지정-솔루션)은 단계별 지침부터 +쿠버네티스 클러스터를 처음부터 설정하기 위한 일반적인 조언까지 다양하다. {{% /capture %}} @@ -90,7 +91,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index)는 관리형 쿠버네티스 클러스터를 제공한다. 그와 함께 격리 종류, 운영 도구, 이미지와 컨테이너 통합된 보안 통찰력, Watson, IoT, 데이터와의 통합도 제공한다. -* [Kubermatic](https://www.loodse.com)는 AWS와 Digital Ocean을 포함한 다양한 퍼블릭 클라우드뿐만 아니라 온-프레미스 상의 OpenStack 통합을 위한 관리형 쿠버네티스 클러스터를 제공한다. +* [Kubermatic](https://www.loodse.com)는 AWS와 Digital Ocean을 포함한 다양한 퍼블릭 클라우드뿐만 아니라 온-프레미스 상의 OpenStack 통합을 위한 관리형 쿠버네티스 클러스터를 제공하는 여러 쿠버네티스에서 쿠버네티스를 운영한다. * [Kublr](https://kublr.com)는 AWS, Azure, GCP 및 온-프레미스에서 기업 수준의 안전하고, 확장 가능하며, 신뢰성 높은 쿠버네티스 클러스터를 제공한다. 여기에는 즉시 사용 가능한 백업 및 재해 복구, 중앙 집중식 다중 클러스터 로깅 및 모니터링, 내장 경고 서비스가 포함된다. @@ -118,7 +119,8 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 ## 턴키 클라우드 솔루션 -다음 솔루션들은 클라우드 IaaS 공급자의 범위에서 몇 안 되는 명령어로 쿠버네티스 클러스터를 생성을 허용한다. 이러한 솔루션은 활발히 개발되었고 활발한 커뮤니티 지원을 한다. +다음 솔루션들은 클라우드 IaaS 공급자의 범위에서 몇 안 되는 명령어로 쿠버네티스 클러스터를 생성을 허용한다. +이러한 솔루션은 활발히 개발되었고 활발한 커뮤니티 지원을 한다. * [Agile Stacks](https://www.agilestacks.com/products/kubernetes) * [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/) @@ -135,7 +137,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer) * [k3s](https://k3s.io) * [Kontena Pharos](https://kontena.io/pharos/) -* [Kubermatic](https://cloud.kubermatic.io) +* [Kubermatic](https://www.loodse.com/product/) * [Kublr](https://kublr.com/) * [Madcore.Ai](https://madcore.ai/) * [Nirmata](https://nirmata.com/) @@ -151,8 +153,8 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) ## 온-프레미스 턴키 클라우드 솔루션 - -다음 솔루션들은 몇 안 되는 명령어를 사용하여 내부의 안전한 클라우드 네트워크에서 쿠버네티스 클러스터를 생성할 수 있다. +다음 솔루션들은 몇 안 되는 명령어를 사용하여 +내부의 안전한 클라우드 네트워크에서 쿠버네티스 클러스터를 생성할 수 있다. * [Agile Stacks](https://www.agilestacks.com/products/kubernetes) * [APPUiO](https://appuio.ch) @@ -177,13 +179,16 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 ## 사용자 지정 솔루션 -쿠버네티스는 넓은 범위의 클라우드 공급자와 베어메탈 환경에서, 그리고 많은 기반 운영 체제에서 동작할 수 있다. +쿠버네티스는 넓은 범위의 클라우드 공급자와 베어메탈 환경에서, +그리고 많은 기반 운영 체제에서 동작할 수 있다. 필요에 맞는 가이드를 아래에서 찾았다면, 그것을 사용하자. ### 일반 -호스팅한 리소스를 구성하는 방법을 이미 알고 있다면, [kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하면 머신당 단일 명령어로 클러스터를 가지고 올 수 있다. +호스팅한 리소스를 구성하는 방법을 이미 알고 있다면, +[kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하면 +머신당 단일 명령어로 클러스터를 가지고 올 수 있다. ### 클라우드 @@ -202,6 +207,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) * [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (uses Ansible) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (uses Fedora and flannel) +* [Kubermatic](https://www.loodse.com/product/) * [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/) * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) * [oVirt](/docs/setup/on-premises-vm/ovirt/) @@ -217,6 +223,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) * [k3s](https://k3s.io) +* [Kubermatic](https://www.loodse.com/product/) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) * [Kubernetes on Ubuntu](https://www.ubuntu.com/kubernetes/docs/quickstart) * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) @@ -242,6 +249,7 @@ Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/T any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle)) any | any | any | any | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune)) any | any | any | any | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community +any | Kubermatic | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial any | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher) any | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/) AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial @@ -294,12 +302,13 @@ VMware Essential PKS | any | multi-support | multi-support | [docs](ht * **IaaS 공급자**는 쿠버네티스가 구동되는 가상 또는 물리적 머신(노드)를 제공하는 제품 또는 조직이다. * **OS**는 노드의 기본 운영 체제이다. -* **구성 관리**는 노드에서 쿠버네티스를 설치하고 유지 관리하는 데 도움이 되는 구성 관리 시스템이다. - nodes. +* **구성 관리**는 노드에서 쿠버네티스를 설치하고 유지 관리하는 데 도움이 되는 + 구성 관리 시스템이다. * **네트워킹**은 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)을 구현하는 것이다. 네트워크 유형이 - _none_인 노드는 단일 노드 이상을 지원하지 않거나, 단일 물리 노드에서 여러 VM 노드를 지원할 수 있다. + _none_인 노드는 단일 노드 이상을 지원하지 않거나, 단일 물리 노드에서 여러 VM 노드를 지원할 수 있다. * **지원 레벨** - * **프로젝트**: 쿠버네티스 커미터는 현재 구성을 정기적으로 사용하므로, 일반적으로 최신 쿠버네티스 릴리즈와 함께 동작한다. + * **프로젝트**: 쿠버네티스 커미터는 현재 구성을 정기적으로 사용하므로, + 일반적으로 최신 쿠버네티스 릴리즈와 함께 동작한다. * **상업용**: 자체 지원 계약을 가진 상업용 제품. * **커뮤니티**: 커뮤니티 기여를 바탕으로 활발하게 지원. 쿠버네티스 최신 릴리즈에는 작동하지 않을 수도 있다. * **비활성**: 현재 유지되지 않는다. 쿠버네티스 최초 사용자에게 권장하지 않으며, 삭제될 수도 있다. diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 2385af43fd..aeeefc5fed 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -9,51 +9,77 @@ card: {{% capture overview %}} -이 페이지는 Minikube 설치 방법을 보여준다. +이 페이지는 단일 노드 쿠버네티스 클러스터를 노트북의 가상 머신에서 구동하는 도구인 [Minikube](/docs/tutorials/hello-minikube)의 설치 방법을 설명한다. {{% /capture %}} {{% capture prerequisites %}} -컴퓨터의 바이오스에서 VT-x 또는 AMD-v 가상화가 필수적으로 활성화되어 있어야 한다. 이를 확인하려면 리눅스 상에서 아래의 명령을 실행하고, -출력이 비어있지 않은지 확인한다. -```shell -egrep --color 'vmx|svm' /proc/cpuinfo +컴퓨터의 바이오스(BIOS)에서 VT-x 또는 AMD-v 가상화는 필수적으로 활성화되어 있어야 한다. + +{{< tabs name="minikube_before_you_begin" >}} +{{% tab name="리눅스" %}} +리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다. ``` +egrep --color 'vmx|svm' /proc/cpuinfo +``` +{{% /tab %}} +{{% tab name="맥OS" %}} +맥OS에서 가상화 지원 여부를 확인하려면, 아래 명령어를 터미널에서 실행한다. +``` +sysctl -a | grep machdep.cpu.features +``` +만약 출력 중에 `VMX`를 볼 수 있다면 VT-x 기능을 운영체제에서 지원한다. +{{% /tab %}} +{{% tab name="윈도우" %}} +윈도우 8 이후 버전에서 가상화 지원 여부를 확인하려면, 다음 명령어를 윈도우 터미널이나 명령 프롬프트에서 실행한다. +``` +systeminfo +``` +아래와 같은 내용을 볼 수 있다면, 윈도우에서 가상화를 지원한다. +``` +Hyper-V Requirements: VM Monitor Mode Extensions: Yes + Virtualization Enabled In Firmware: Yes + Second Level Address Translation: Yes + Data Execution Prevention Available: Yes +``` + +{{% /tab %}} +{{< /tabs >}} {{% /capture %}} {{% capture steps %}} -## 하이퍼바이저 설치 +## 하이퍼바이저(hypervisor) 설치 {#install-a-hypervisor} -하이퍼바이저가 설치되어 있지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다. +하이퍼바이저를 설치하지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다. -Operating system | Supported hypervisors +운영체제 | 지원하는 하이퍼바이저 :----------------|:--------------------- -macOS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit) -Linux | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/) -Windows | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) +맥OS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit) +리눅스 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/) +윈도우 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) {{< note >}} -Minikube는 쿠버네티스 컴포넌트들이 VM 안에서가 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 linux 환경을 필요로 한다. +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 리눅스 환경을 필요로 한다. {{< /note >}} ## kubectl 설치 -* [Install and Set Up kubectl](/docs/tasks/tools/install-kubectl/) 지침에 따라 kubectl을 설치한다. +* [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/) 지침에 따라 kubectl을 설치한다. -## Minikube 설치 +## Minikube 설치 {#install-minikube} -### macOS +### 맥OS {#macos} -macOS에 Minikube를 설치하는 가장 쉬운 방법은 [Homebrew](https://brew.sh)을 사용하는 것이다. +맥OS에 Minikube를 설치하는 가장 쉬운 방법은 [Homebrew](https://brew.sh)을 사용하는 것이다. ```shell brew cask install minikube ``` -정적 바이너리를 내려받아서 macOS에 설치할 수도 있다. +정적 바이너리를 내려받아서 맥OS에 설치할 수도 있다. ```shell curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ @@ -66,10 +92,10 @@ Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같 sudo mv minikube /usr/local/bin ``` -### Linux +### 리눅스 {#linux} {{< note >}} -이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. 리눅스에 설치하는 다른 방법은, 공식 Minikube GitHub 저장소의 [Other Ways to Install](https://github.com/kubernetes/minikube#other-ways-to-install)를 참조한다. +이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. 리눅스에 설치에 다른 방법은 공식 Minikube GitHub 저장소의 [다른 방법으로 설치하기](https://github.com/kubernetes/minikube#other-ways-to-install)를 참조한다. {{< /note >}} 정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있다. @@ -85,45 +111,44 @@ Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같 sudo cp minikube /usr/local/bin && rm minikube ``` -### Windows - or [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v). Hyper-V can be run on three versions of Windows 10: Windows 10 Enterprise, Windows 10 Professional, and Windows 10 Education. See the official Minikube GitHub repository for additional [installation information](https://github.com/kubernetes/minikube/#installation). +### 윈도우 {#windows} {{< note >}} -Minikube를 Windows에서 실행하려면, 우선 첫번째로 [VirtualBox](https://www.virtualbox.org/) 또는 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치할 필요가 있다. Hyper-V는 Windows 10 Enterprise, Windows 10 Professional 과 Windows 10 Education 세 버전의 Windows 10에서 동작한다. +Minikube를 윈도우에서 실행하려면, 먼저 [VirtualBox](https://www.virtualbox.org/) 또는 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치해야 한다. Hyper-V는 Windows 10 엔터프라이즈, Windows 10 프로페셔널, Windows 10 에듀케이션 세 버전의 Windows 10에서 동작한다. Minikube 공식 GitHub 레포지토리에 추가적인 [설치 방법](https://github.com/kubernetes/minikube/#installation)을 확인한다. {{< /note >}} -Windows에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행) +윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행) ```shell choco install minikube kubernetes-cli ``` -Minikube 설치를 마친 뒤에, 현재 CLI 세션을 닫고 재시작한다. Minikube가 경로에 자동으로 추가되어 있어야 정상이다. +Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube가 실행 경로에 자동으로 추가되어 있어야 한다. -#### Windows 수동 설치 +#### 윈도우 수동 설치 {#windows-manual-installation} -Windows에 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서, 이름을 `minikube.exe`로 변경하고, 경로에 추가한다. +윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다. -#### Windows 인스톨러 +#### 윈도우 인스톨러 {#windows-installer} -[Windows Installer](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)를 사용해서 Windows에 Minikube를 수동으로 설치하려면 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 인스톨러를 실행한다. +[Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)으로 윈도우에서 Minikube를 수동으로 설치하려면 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 인스톨러를 실행한다. {{% /capture %}} {{% capture whatsnext %}} -* [Minikube를 통해서 로컬에서 쿠버네티스 운영하기](/docs/getting-started-guides/minikube/) +* [Minikube로 로컬에서 쿠버네티스 실행하기](/docs/setup/minikube/) {{% /capture %}} ## 새롭게 시작하기 위해 모두 정리하기 -이전에 minikube를 설치한 적이 있다면, 실행한다. +이전에 minikube를 설치했었다면, 다음을 실행한다. ```shell minikube start ``` -이 커맨드는 에러를 리턴한다. +그리고 이 명령은 에러를 보여준다. ```shell machine does not exist ``` diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 542b6dce08..5ed67f5c82 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -108,7 +108,7 @@ weight: 10

kubectl로 문제해결하기

-

모듈 2에서, 여러분은 Kubectl 커맨드-라인 인터페이스를 사용하였다. 여러분은 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈 3에서도 계속 그것을 사용하게 될 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용해 처리될 수 있다:

+

모듈 2에서, Kubectl 커맨드-라인 인터페이스를 사용했다. 배포된 애플리케이션과 그 환경에 대한 정보를 얻기 위해 모듈3에서도 계속 그것을 사용할 것이다. 가장 보편적인 운용업무는 다음 kubectl 명령어를 이용하여 처리할 수 있다:

  • kubectl get - 자원을 나열한다
  • kubectl describe - 자원에 대해 상세한 정보를 보여준다.
    • diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index a6377c6c1a..a7946664c2 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -119,10 +119,10 @@ $ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-por service/nodeport exposed $ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') +$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }') ``` -클라우드 공급자 상에서 실행한다면, +클라우드 공급자 상에서 실행한다면, 위에 보고된 `nodes:nodeport`를 위한 방화벽 규칙을 열어주어야 한다. 이제 위에 노드 포트로 할당받은 포트를 통해 클러스터 외부에서 서비스에 도달할 수 있다. @@ -310,7 +310,7 @@ __크로스 플랫폼 지원__ 첫 번째 범주의 로드밸런서는 진짜 클라이언트 IP를 통신하기 위해 HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더나 -[프록시 프로토콜](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)같이 로드밸런서와 +[프록시 프로토콜](http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)같이 로드밸런서와 백엔드 간에 합의된 프로토콜을 사용해야 한다. 두 번째 범주의 로드밸런서는 서비스의 `service.spec.healthCheckNodePort` 필드의 저장된 포트를 가르키는 간단한 HTTP 헬스 체크를 생성하여 diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 965ecf2d53..0c2517592c 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -18,11 +18,11 @@ card: {{% /capture %}} {{% capture objectives %}} -* Redis 마스터를 실행한다. -* Redis 슬레이브를 실행한다. -* 방명록 프론트엔드를 실행한다. -* 프론트엔드 서비스를 노출시키고 확인한다. -* 제거한다. +* Redis 마스터를 시작 +* Redis 슬레이브를 시작 +* 방명록 프론트엔드를 시작 +* 프론트엔드 서비스를 노출시키고 확인 +* 정리 하기 {{% /capture %}} {{% capture prerequisites %}} @@ -359,9 +359,10 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 {{% /capture %}} {{% capture whatsnext %}} -* [쿠버네티스 기초](/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료한다. -* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨 사용하기](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)를 통해 블로그를 만들어본다. -* [애플리케이션 접속](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아본다. -* [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아본다. +* [ELK 로깅과 모니터링](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)을 방명록 애플리케이션에 추가하기 +* [쿠버네티스 기초](/docs/tutorials/kubernetes-basics/) 튜토리얼을 완료 +* [MySQL과 Wordpress을 위한 퍼시스턴트 볼륨](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)을 사용하여 블로그 생성하는데 쿠버네티스 이용하기 +* [애플리케이션 접속](/docs/concepts/services-networking/connect-applications-service/)에 대해 더 알아보기 +* [자원 관리](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)에 대해 더 알아보기 {{% /capture %}} diff --git a/content/ko/examples/application/simple_deployment.yaml b/content/ko/examples/application/simple_deployment.yaml new file mode 100644 index 0000000000..10fa1ddf29 --- /dev/null +++ b/content/ko/examples/application/simple_deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + minReadySeconds: 5 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 diff --git a/content/ko/examples/application/update_deployment.yaml b/content/ko/examples/application/update_deployment.yaml new file mode 100644 index 0000000000..d53aa3e6d2 --- /dev/null +++ b/content/ko/examples/application/update_deployment.yaml @@ -0,0 +1,18 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.11.9 # update the image + ports: + - containerPort: 80 diff --git a/content/ko/examples/pods/config/redis-pod.yaml b/content/ko/examples/pods/config/redis-pod.yaml index 259dbf853a..4fc868e6af 100644 --- a/content/ko/examples/pods/config/redis-pod.yaml +++ b/content/ko/examples/pods/config/redis-pod.yaml @@ -5,7 +5,7 @@ metadata: spec: containers: - name: redis - image: kubernetes/redis:v1 + image: redis:5.0.4 env: - name: MASTER value: "true"