From 34074d33ffe7fc9f9f42b5b419e34dbf7e7b9733 Mon Sep 17 00:00:00 2001 From: "Claudia J.Kang" Date: Wed, 10 Apr 2019 09:42:12 +0900 Subject: [PATCH] First Korean I10n work for release-1.14 (#13730) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * First Korean I10n work for release-1.14 - ko: Fix nav-menu sync in tutorials/statefulset #13374 (#13474) - ko: add outdated files in dev-1.14-ko.1 branch (#13473) - Translate title of concepts/../image.md Ko (#13507) - ko: add translation tutorial/stateful-application/cassandra #12450 (#13515) - Translate reference/kubectl/cheatsheet in Korean (#13549) - Translate tasks/access-application-cluster/access-cluster in Korean (#13565) - ko: add tutorials/stateful-application/mysql-wordpress-persistent-vol… (#13516) - Issue 12838 object management kubectl imperative config (#13657) - Translate standardized glossary Tag Fandamental in Korean (#13552) Co-authored-by: Kim Young Dae <38598117+zer0big@users.noreply.github.com> Co-authored-by: Yoon Co-authored-by: lapee79 Co-authored-by: Jesang Myung Co-authored-by: Seokho Co-authored-by: Claudia J.Kang Co-authored-by: June Yi * Fix conflict : pick-right-solution --- content/ko/_index.html | 2 +- content/ko/case-studies/pinterest/index.html | 15 +- .../concepts/architecture/cloud-controller.md | 1 + .../cluster-administration/federation.md | 4 +- content/ko/docs/concepts/containers/images.md | 2 +- .../ko/docs/concepts/overview/components.md | 2 +- .../imperative-config.md | 143 +++ .../kubernetes-objects.md | 4 +- .../working-with-objects/namespaces.md | 4 +- .../workloads/pods/init-containers.md | 45 +- .../ko/docs/reference/glossary/annotation.md | 18 + content/ko/docs/reference/glossary/cluster.md | 19 + .../glossary/container-env-variables.md | 17 + .../ko/docs/reference/glossary/container.md | 19 + .../ko/docs/reference/glossary/controller.md | 8 +- .../glossary/customresourcedefinition.md | 20 + .../ko/docs/reference/glossary/daemonset.md | 20 + .../ko/docs/reference/glossary/deployment.md | 20 + .../docs/reference/glossary/device-plugin.md | 17 + content/ko/docs/reference/glossary/docker.md | 18 + content/ko/docs/reference/glossary/etcd.md | 2 +- .../ko/docs/reference/glossary/extensions.md | 18 + content/ko/docs/reference/glossary/image.md | 18 + .../docs/reference/glossary/init-container.md | 18 + content/ko/docs/reference/glossary/job.md | 20 + .../docs/reference/glossary/kube-apiserver.md | 2 +- .../ko/docs/reference/glossary/kube-proxy.md | 19 + .../docs/reference/glossary/kube-scheduler.md | 2 +- content/ko/docs/reference/glossary/kubectl.md | 19 + content/ko/docs/reference/glossary/kubelet.md | 6 +- .../docs/reference/glossary/kubernetes-api.md | 19 + content/ko/docs/reference/glossary/label.md | 18 + .../ko/docs/reference/glossary/minikube.md | 19 + content/ko/docs/reference/glossary/name.md | 2 +- .../ko/docs/reference/glossary/namespace.md | 18 + content/ko/docs/reference/glossary/node.md | 18 + .../docs/reference/glossary/pod-lifecycle.md | 19 + .../reference/glossary/pod-security-policy.md | 19 + content/ko/docs/reference/glossary/pod.md | 19 + content/ko/docs/reference/glossary/rbac.md | 19 + .../ko/docs/reference/glossary/replica-set.md | 20 + .../docs/reference/glossary/resource-quota.md | 20 + .../ko/docs/reference/glossary/selector.md | 18 + .../reference/glossary/service-account.md | 19 + content/ko/docs/reference/glossary/service.md | 19 + .../ko/docs/reference/glossary/statefulset.md | 23 + content/ko/docs/reference/glossary/taint.md | 18 + .../ko/docs/reference/glossary/toleration.md | 18 + content/ko/docs/reference/glossary/volume.md | 19 + .../ko/docs/reference/kubectl/cheatsheet.md | 358 +++++++ content/ko/docs/setup/certificates.md | 2 +- content/ko/docs/setup/minikube.md | 73 +- content/ko/docs/setup/pick-right-solution.md | 139 +-- content/ko/docs/setup/scratch.md | 872 ------------------ .../access-application-cluster/_index.md | 5 + .../access-cluster.md | 372 ++++++++ .../horizontal-pod-autoscale-walkthrough.md | 45 +- .../ko/docs/tasks/tools/install-minikube.md | 15 + content/ko/docs/tutorials/_index.md | 2 +- .../deploy-app/deploy-intro.html | 4 +- .../kubernetes-basics/scale/scale-intro.html | 7 +- .../tutorials/online-training/overview.md | 7 +- .../tutorials/stateful-application/_index.md | 5 + .../basic-stateful-set.md | 14 +- .../stateful-application/cassandra.md | 258 ++++++ .../mysql-wordpress-persistent-volume.md | 233 +++++ .../stateless-application/guestbook.md | 2 +- .../cassandra/cassandra-service.yaml | 12 + .../cassandra/cassandra-statefulset.yaml | 100 ++ .../application/mysql/mysql-configmap.yaml | 16 + .../application/mysql/mysql-deployment.yaml | 43 + .../examples/application/mysql/mysql-pv.yaml | 26 + .../application/mysql/mysql-services.yaml | 30 + .../application/mysql/mysql-statefulset.yaml | 167 ++++ .../wordpress/mysql-deployment.yaml | 65 ++ .../wordpress/wordpress-deployment.yaml | 67 ++ .../federated-task-tutorial-prereqs.md | 5 + ...=> federation-deprecation-warning-note.md} | 0 78 files changed, 2782 insertions(+), 1028 deletions(-) create mode 100644 content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md create mode 100755 content/ko/docs/reference/glossary/annotation.md create mode 100755 content/ko/docs/reference/glossary/cluster.md create mode 100755 content/ko/docs/reference/glossary/container-env-variables.md create mode 100755 content/ko/docs/reference/glossary/container.md create mode 100755 content/ko/docs/reference/glossary/customresourcedefinition.md create mode 100755 content/ko/docs/reference/glossary/daemonset.md create mode 100755 content/ko/docs/reference/glossary/deployment.md create mode 100644 content/ko/docs/reference/glossary/device-plugin.md create mode 100755 content/ko/docs/reference/glossary/docker.md create mode 100644 content/ko/docs/reference/glossary/extensions.md create mode 100755 content/ko/docs/reference/glossary/image.md create mode 100755 content/ko/docs/reference/glossary/init-container.md create mode 100755 content/ko/docs/reference/glossary/job.md create mode 100755 content/ko/docs/reference/glossary/kube-proxy.md create mode 100755 content/ko/docs/reference/glossary/kubectl.md create mode 100755 content/ko/docs/reference/glossary/kubernetes-api.md create mode 100755 content/ko/docs/reference/glossary/label.md create mode 100755 content/ko/docs/reference/glossary/minikube.md create mode 100755 content/ko/docs/reference/glossary/namespace.md create mode 100755 content/ko/docs/reference/glossary/node.md create mode 100644 content/ko/docs/reference/glossary/pod-lifecycle.md create mode 100755 content/ko/docs/reference/glossary/pod-security-policy.md create mode 100755 content/ko/docs/reference/glossary/pod.md create mode 100755 content/ko/docs/reference/glossary/rbac.md create mode 100755 content/ko/docs/reference/glossary/replica-set.md create mode 100755 content/ko/docs/reference/glossary/resource-quota.md create mode 100755 content/ko/docs/reference/glossary/selector.md create mode 100755 content/ko/docs/reference/glossary/service-account.md create mode 100755 content/ko/docs/reference/glossary/service.md create mode 100755 content/ko/docs/reference/glossary/statefulset.md create mode 100644 content/ko/docs/reference/glossary/taint.md create mode 100644 content/ko/docs/reference/glossary/toleration.md create mode 100755 content/ko/docs/reference/glossary/volume.md create mode 100644 content/ko/docs/reference/kubectl/cheatsheet.md delete mode 100644 content/ko/docs/setup/scratch.md create mode 100755 content/ko/docs/tasks/access-application-cluster/_index.md create mode 100644 content/ko/docs/tasks/access-application-cluster/access-cluster.md create mode 100644 content/ko/docs/tutorials/stateful-application/_index.md create mode 100644 content/ko/docs/tutorials/stateful-application/cassandra.md create mode 100644 content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md create mode 100644 content/ko/examples/application/cassandra/cassandra-service.yaml create mode 100644 content/ko/examples/application/cassandra/cassandra-statefulset.yaml create mode 100644 content/ko/examples/application/mysql/mysql-configmap.yaml create mode 100644 content/ko/examples/application/mysql/mysql-deployment.yaml create mode 100644 content/ko/examples/application/mysql/mysql-pv.yaml create mode 100644 content/ko/examples/application/mysql/mysql-services.yaml create mode 100644 content/ko/examples/application/mysql/mysql-statefulset.yaml create mode 100644 content/ko/examples/application/wordpress/mysql-deployment.yaml create mode 100644 content/ko/examples/application/wordpress/wordpress-deployment.yaml create mode 100644 content/ko/includes/federated-task-tutorial-prereqs.md rename content/ko/includes/{federation-current-state.md => federation-deprecation-warning-note.md} (100%) diff --git a/content/ko/_index.html b/content/ko/_index.html index 89753c9f3b..a73327cdf3 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -8,7 +8,7 @@ cid: home {{< blocks/section id="oceanNodes" >}} {{% blocks/feature image="flower" %}} -### [쿠버네티스 (k8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. +### [쿠버네티스 (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. 애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. {{% /blocks/feature %}} diff --git a/content/ko/case-studies/pinterest/index.html b/content/ko/case-studies/pinterest/index.html index 56bf0ecbc5..86c81feab3 100644 --- a/content/ko/case-studies/pinterest/index.html +++ b/content/ko/case-studies/pinterest/index.html @@ -26,28 +26,27 @@ quote: >
+

Challenge

After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure. -
+

Solution

The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes. -
- -
+

Impact

"By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster." - +
-
-
-
+
+ +


"So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for."

— Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest
diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index edb8755108..6ff84dc9d2 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -255,6 +255,7 @@ rules: * [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce) * [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws) * [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud) +* [Linode](https://github.com/linode/linode-cloud-controller-manager) ## 클러스터 관리 diff --git a/content/ko/docs/concepts/cluster-administration/federation.md b/content/ko/docs/concepts/cluster-administration/federation.md index 61bfe04c3f..1719b9882b 100644 --- a/content/ko/docs/concepts/cluster-administration/federation.md +++ b/content/ko/docs/concepts/cluster-administration/federation.md @@ -6,7 +6,9 @@ weight: 80 {{% capture overview %}} -{{< include "federation-current-state.md" >}} +{{< deprecationfilewarning >}} +{{< include "federation-deprecation-warning-note.md" >}} +{{< /deprecationfilewarning >}} 이 페이지는 여러 쿠버네티스 클러스터를 페더레이션을 통해서 관리해야 하는 이유와 방법을 설명한다. diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index a01e11532c..a3be574307 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -1,5 +1,5 @@ --- -title: Images +title: 이미지 content_template: templates/concept weight: 10 --- diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 2c1d161d2d..e5aa4bc5c9 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -77,7 +77,7 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 ### 컨테이너 런타임 컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. -쿠버네티스는 몇몇의 런타임을 지원하는데 [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/container-runtime-interface.md)를 구현한 모든 런타임이다. +쿠버네티스는 몇몇의 런타임을 지원하는데 [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)를 구현한 모든 런타임이다. ## 애드온 diff --git a/content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md b/content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md new file mode 100644 index 0000000000..39b4b1063f --- /dev/null +++ b/content/ko/docs/concepts/overview/object-management-kubectl/imperative-config.md @@ -0,0 +1,143 @@ +--- +title: 구성파일을 이용한 명령형 쿠버네티스 오브젝트 관리 +content_template: templates/concept +weight: 30 +--- + +{{% capture overview %}} +쿠버네티스 오브젝트는 YAML 또는 JSON으로 작성된 오프젝트 구성파일과 함께 `kubectl` +커맨드 라인 툴을 이용하여 생성, 업데이트 및 삭제할 수 있다. +이 문서는 구성파일을 이용하여 어떻게 오브젝트를 정의하고 관리할 수 있는지에 대해 설명한다. +{{% /capture %}} + +{{% capture body %}} + +## 트레이드 오프 + +`kubectl` 툴은 3가지 종류의 오브젝트 관리를 지원한다. + +* 명령형 커맨드 +* 명령형 오브젝트 구성 +* 선언형 오브젝트 구성 + +각 종류별 오브젝트 관리의 장점과 단점에 대한 논의는 +[쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/object-management-kubectl/overview/)를 참고한다. + +## 오브젝트 생성 방법 + +구성파일로부터 오브젝트를 생성하기 위해 `kubectl create -f`를 사용할 수 있다. +보다 상세한 정보는 [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를 +참조한다. + +- `kubectl create -f <파일명|url>` + +## 오브젝트 업데이트 방법 + +{{< warning >}} +`replace` 커맨드로 오브젝트를 업데이트 하게되면, +구성파일에 정의되지 않은 스펙의 모든 부분이 삭제된다. 이는 +`externalIPs`필드가 구성파일로부터 독립적으로 관리되는 +`LoadBalancer`타입의 서비스와 같이, 클러스터 의해 부분적으로 +관리되는 스펙의 오브젝트와 함께 사용되어서는 안된다. +독립적으로 관리되는 필드는 `replace`로 삭제되는 것을 방지하기 위해 +구성파일에 복사되어져야만 한다. +{{< /warning >}} + +구성파일에 따라 활성 오브젝트를 업데이트하기 위해 `kubectl replace -f` +를 사용할 수 있다. + +- `kubectl replace -f <파일명|url>` + +## 오브젝트 삭제 방법 + +구성파일에 정의한 오브젝트를 삭제하기 위해 `kubectl delete -f`를 +사용할 수 있다. + +- `kubectl delete -f <파일명|url>` + +## 오브젝트 삭제 방법 + +구성파일에 정의한 오브젝트에 관한 정보 확인을 위해 `kubectl get -f` +명령을 사용할 수 있다. + +- `kubectl get -f <파일명|url> -o yaml` + +`-o yaml` 플래그는 전체 오브젝트 구성이 출력되도록 정의한다. 옵션의 리스트를 확인하기 +위해서는 `kubectl get -h`를 사용한다. + +## 제약사항 + +`create`, `replace`, 그리고 `delete` 명령은 각 오브젝트의 구성이 +그 구성파일 내에 완전하게 정의되고 기록되어질 경우 잘 동작한다. +그러나 활성 오브젝트가 업데이트 되고, 구성파일 안에 병합되지 않으면, +업데이트 내용은 다음번 `replace`가 실행될 때 삭제될 것이다. +이는 HorizontalPodAutoscaler와 같은 컨트롤러가 +활성 오브젝트를 직접적으로 업데이트하도록 할 경우 발생한다. +여기 예시가 있다. + +1. 구성파일로부터 오브젝트를 생성할 경우 +1. 또 다른 소스가 일부 필드를 변경함으로써 오브젝트가 업데이트 되는 경우 +1. 구성파일로부터 오브젝트를 대체할 경우. 스텝 2에서의 +다른 소스에 의해 이루어진 변경은 유실된다. + +동일 오브젝트에 대해 여러 명의 작성자들로부터의 지원이 필요한 경우, 오브젝트를 관리하기 위해 +`kubectl apply`를 사용할 수 있다. + +## 구성 저장 없이 URL로부터 오브젝트 생성과 편집하기 + +구성파일에 대한 URL을 가진다고 가정해보자. +`kubectl create --edit`을 사용하여 오브젝트가 생성되기 전에 +구성을 변경할 수 있다. 이는 독자가 수정할 수 있는 구성파일을 +가르키는 튜토리얼과 작업에 특히 유용하다. + +```sh +kubectl create -f --edit +``` + +## 명령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 + +령형 커맨드에서 명령형 오브젝트 구성으로 전환하기 위해 +몇 가지 수동 단계를 포함한다. + +1. 다음과 같이 활성 오브젝트를 로컬 오브젝트 구성파일로 내보낸다. +```sh +kubectl get <종류>/<이름> -o yaml --export > <종류>_<이름>.yaml +``` + +1. 수동으로 오브젝트 구성파일에서 상태 필드를 제거한다. + +1. 이후 오브젝트 관리를 위해, `replace`만 사용한다. +```sh +kubectl replace -f <종류>_<이름>.yaml +``` + + +## 컨트롤러 셀렉터와 PodTemplate 레이블 삭제하기 + +{{< warning >}} +컨트롤러에서 셀렉터를 업데이트하지 않도록 강력하게 권고한다. +{{< /warning >}} + +권고되는 접근방법은 다른 의미론적 의미가 없는 컨트롤러 셀렉터의 의해서만 +사용되는 단일, 불변의 PodTemplate 레이블로 정의하는 것이다. + +레이블 예시: + +```yaml +selector: + matchLabels: + controller-selector: "extensions/v1beta1/deployment/nginx" +template: + metadata: + labels: + controller-selector: "extensions/v1beta1/deployment/nginx" +``` + +{{% /capture %}} + +{{% capture whatsnext %}} +- [명령형 커맨드를 이용한 쿠버네티스 오브젝트 관리하기](/ko/docs/concepts/overview/object-management-kubectl/imperative-command/) +- [오브젝트 구성을 이용하여 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/) +- [Kubectl 커멘드 참조](/docs/reference/generated/kubectl/kubectl/) +- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +{{% /capture %}} diff --git a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 6be2c9212d..96c5d64f01 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -41,11 +41,11 @@ card: {{< codenew file="application/deployment.yaml" >}} -위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands#create) 명령을 이용하는 것이다. 다음 예시와 같다. +위 예시와 같이 .yaml 파일을 이용하여 디플로이먼트를 생성하기 위한 하나의 방식으로는 `kubectl` 커맨드-라인 인터페이스에 인자값으로 `.yaml` 파일를 건네 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 명령을 이용하는 것이다. 다음 예시와 같다. ```shell -$ kubectl create -f https://k8s.io/examples/application/deployment.yaml --record +kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record ``` 그 출력 내용은 다음과 유사하다. 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 83d7c3ff3d..2c791106df 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -41,7 +41,9 @@ weight: 30 사용중인 클러스터의 현재 네임스페이스를 나열할 수 있다. ```shell -$ kubectl get namespaces +kubectl get namespaces +``` +``` NAME STATUS AGE default Active 1d kube-system Active 1d diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 815abc745e..0b262c495c 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -106,19 +106,19 @@ metadata: pod.beta.kubernetes.io/init-containers: '[ { "name": "init-myservice", - "image": "busybox", + "image": "busybox:1.28", "command": ["sh", "-c", "until nslookup myservice; do echo waiting for myservice; sleep 2; done;"] }, { "name": "init-mydb", - "image": "busybox", + "image": "busybox:1.28", "command": ["sh", "-c", "until nslookup mydb; do echo waiting for mydb; sleep 2; done;"] } ]' spec: containers: - name: myapp-container - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo The app is running! && sleep 3600'] ``` @@ -135,14 +135,14 @@ metadata: spec: containers: - name: myapp-container - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'echo The app is running! && sleep 3600'] initContainers: - name: init-myservice - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;'] - name: init-mydb - image: busybox + image: busybox:1.28 command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] ``` @@ -176,12 +176,24 @@ spec: 다음 커맨드들을 이용하여 파드를 시작하거나 디버깅할 수 있다. ```shell -$ kubectl create -f myapp.yaml +kubectl apply -f myapp.yaml +``` +``` pod/myapp-pod created -$ kubectl get -f myapp.yaml +``` + +```shell +kubectl get -f myapp.yaml +``` +``` NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m -$ kubectl describe -f myapp.yaml +``` + +```shell +kubectl describe -f myapp.yaml +``` +``` Name: myapp-pod Namespace: default [...] @@ -214,18 +226,25 @@ Events: 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Pulled Successfully pulled image "busybox" 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Created Created container with docker id 5ced34a04634; Security:[seccomp=unconfined] 13s 13s 1 {kubelet 172.17.4.201} spec.initContainers{init-myservice} Normal Started Started container with docker id 5ced34a04634 -$ kubectl logs myapp-pod -c init-myservice # Inspect the first init container -$ kubectl logs myapp-pod -c init-mydb # Inspect the second init container +``` +```shell +kubectl logs myapp-pod -c init-myservice # Inspect the first init container +kubectl logs myapp-pod -c init-mydb # Inspect the second init container ``` `mydb` 및 `myservice` 서비스를 시작하고 나면, 초기화 컨테이너가 완료되고 `myapp-pod`가 생성된 것을 볼 수 있다. ```shell -$ kubectl create -f services.yaml +kubectl apply -f services.yaml +``` +``` service/myservice created service/mydb created -$ kubectl get -f myapp.yaml +``` + +```shell +kubectl get -f myapp.yaml NAME READY STATUS RESTARTS AGE myapp-pod 1/1 Running 0 9m ``` diff --git a/content/ko/docs/reference/glossary/annotation.md b/content/ko/docs/reference/glossary/annotation.md new file mode 100755 index 0000000000..a853050db3 --- /dev/null +++ b/content/ko/docs/reference/glossary/annotation.md @@ -0,0 +1,18 @@ +--- +title: 어노테이션(Annotation) +id: annotation +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/annotations +short_description: > + 임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍. + +aka: +tags: +- fundamental +--- + 임의의 식별되지 않는 메타데이터를 오브젝트에 첨부할 때 이용하는 키-밸류 쌍. + + + +어노테이션으로 된 메타데이터는 작거나 클 수 있고, 구조화되어 있거나 구조화되어 있지 않을 수도 있고, 레이블에서는 허용되지 않는 문자도 포함할 수 있다. 툴과 라이브러리와 같은 클라이언트로 메타데이터를 검색할 수 있다. + diff --git a/content/ko/docs/reference/glossary/cluster.md b/content/ko/docs/reference/glossary/cluster.md new file mode 100755 index 0000000000..50277df48e --- /dev/null +++ b/content/ko/docs/reference/glossary/cluster.md @@ -0,0 +1,19 @@ +--- +title: 클러스터(Cluster) +id: cluster +date: 2018-04-12 +full_link: +short_description: > + 쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합. + +aka: +tags: +- fundamental +- operation +--- + 쿠버네티스를 통해 관리되는 컨테이너화 된 애플리케이션을 실행하는, 노드라고 불리는 기계의 집합. + + + +클러스터는 여러 개의 워커 노드와 적어도 하나의 마스터를 가진다. + diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md new file mode 100755 index 0000000000..093fe822cf --- /dev/null +++ b/content/ko/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: 컨테이너 환경 변수(Container Environment Variables) +id: container-env-variables +date: 2018-04-12 +full_link: /ko/docs/concepts/containers/container-environment-variables.md +short_description: > + 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. + +aka: +tags: +- fundamental +--- + 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. + + + +컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다. diff --git a/content/ko/docs/reference/glossary/container.md b/content/ko/docs/reference/glossary/container.md new file mode 100755 index 0000000000..2420a42112 --- /dev/null +++ b/content/ko/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: 컨테이너(Container) +id: container +date: 2018-04-12 +full_link: /ko/docs/concepts/overview/what-is-kubernetes/#왜-컨테이너인가 +short_description: > + 소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지. + +aka: +tags: +- fundamental +- workload +--- + 소프트웨어와 그것에 종속된 모든 것을 포함한 가볍고 휴대성이 높은 실행 가능 이미지. + + + +컨테이너는 애플리케이션과 기반이 되는 호스트 인프라의 관계를 분리시켜서, 애플리케이션을 다른 클라우드 또는 OS 환경에서도 쉽게 디플로이하고 쉽게 스케일되게 한다. + diff --git a/content/ko/docs/reference/glossary/controller.md b/content/ko/docs/reference/glossary/controller.md index e6b6416d9b..947470e054 100644 --- a/content/ko/docs/reference/glossary/controller.md +++ b/content/ko/docs/reference/glossary/controller.md @@ -1,19 +1,19 @@ --- -title: Controller +title: 컨트롤러(Controller) id: controller date: 2018-04-12 full_link: /docs/admin/kube-controller-manager/ short_description: > - API 서버를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프. + Apiserver를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. aka: tags: - architecture - fundamental --- - {{< glossary_tooltip text="apiserver" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키도록 하는 컨트롤 루프. + {{< glossary_tooltip text="Apiserver" term_id="kube-apiserver" >}}를 통해 클러스터의 공유된 상태를 감시하고, 현재 상태를 원하는 상태로 이행시키는 컨트롤 루프. -현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스어카운트 컨트롤러가 있다. +현재 쿠버네티스에 포함된 컨트롤러의 예시로는 레플리케이션 컨트롤러, 엔드포인트 컨트롤러, 네임스페이스 컨트롤러, 서비스 어카운트 컨트롤러가 있다. diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md new file mode 100755 index 0000000000..c5c754d270 --- /dev/null +++ b/content/ko/docs/reference/glossary/customresourcedefinition.md @@ -0,0 +1,20 @@ +--- +title: 커스텀 리소스 데피니션(CustomResourceDefinition) +id: CustomResourceDefinition +date: 2018-04-12 +full_link: docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/ +short_description: > + 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API server에 추가할 리소스를 정의하는 사용자 정의 코드. + +aka: +tags: +- fundamental +- operation +- extension +--- + 사용자 정의 서버를 완전히 새로 구축할 필요가 없도록 쿠버네티스 API server에 추가할 리소스를 정의하는 사용자 정의 코드. + + + +만약 공개적으로 지원되는 API 리소스가 사용자의 요구를 충족할 수 없는 경우, 커스텀 리소스 데피니션은 사용자의 환경에 따라 쿠버네티스 API를 확장하게 해준다. + diff --git a/content/ko/docs/reference/glossary/daemonset.md b/content/ko/docs/reference/glossary/daemonset.md new file mode 100755 index 0000000000..580f6bf0be --- /dev/null +++ b/content/ko/docs/reference/glossary/daemonset.md @@ -0,0 +1,20 @@ +--- +title: 데몬 셋(DaemonSet) +id: daemonset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/daemonset +short_description: > + 파드의 복제품이 클러스터의 노드 집합에 걸쳐 동작하는 것을 확실히 한다. + +aka: +tags: +- fundamental +- core-object +- workload +--- + {{< glossary_tooltip text="파드" term_id="pod" >}}의 복제품이 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}의 노드 집합에 걸쳐 동작하는 것을 확실히 한다. + + + +일반적으로 모든 {{< glossary_tooltip text="노드" term_id="node" >}}에서 실행돼야 하는 로그 수집기 및 모니터링 에이전트 등의 시스템 데몬을 디플로이하기 위해서 사용된다. + diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md new file mode 100755 index 0000000000..c6ef06e304 --- /dev/null +++ b/content/ko/docs/reference/glossary/deployment.md @@ -0,0 +1,20 @@ +--- +title: 디플로이먼트(Deployment) +id: deployment +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/deployment/ +short_description: > + 레플리케이션 된 애플리케이션을 관리하는 API 오브젝트. + +aka: +tags: +- fundamental +- core-object +- workload +--- + 레플리케이션 된 애플리케이션을 관리하는 API 오브젝트. + + + +각 레플리카는 {{< glossary_tooltip text="파드" term_id="pod" >}}로 표현되며, 각 파드는 클러스터의 노드에 분산된다. + diff --git a/content/ko/docs/reference/glossary/device-plugin.md b/content/ko/docs/reference/glossary/device-plugin.md new file mode 100644 index 0000000000..61a857e58e --- /dev/null +++ b/content/ko/docs/reference/glossary/device-plugin.md @@ -0,0 +1,17 @@ +--- +title: 장치 플러그인(Device Plugin) +id: device-plugin +date: 2019-02-02 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +short_description: > + 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. +aka: +tags: +- fundamental +- extension +--- + 장치 플러그인은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. + + + +[장치 플러그인](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)은 쿠버네티스에서 동작하는 컨테이너이며 공급 업체 고유의 리소스에 대한 액세스를 제공한다. 장치 플로그인은 해당 리소스를 kubelet에 알린다. 장치 플러그인은 사용자 정의 쿠버네티스 코드를 작성하는 대신 수동으로 또는 데몬 셋으로도 디플로이 가능하다. diff --git a/content/ko/docs/reference/glossary/docker.md b/content/ko/docs/reference/glossary/docker.md new file mode 100755 index 0000000000..d2b65351a4 --- /dev/null +++ b/content/ko/docs/reference/glossary/docker.md @@ -0,0 +1,18 @@ +--- +title: docker +id: docker +date: 2018-04-12 +full_link: /docs/reference/kubectl/docker-cli-to-kubectl/ +short_description: > + Docker는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, 컨테이너로도 알려져 있다. + +aka: +tags: +- fundamental +--- + Docker는 운영 시스템 수준의 가상화를 제공하는 소프트웨어 기술이며, 컨테이너로도 알려져 있다. + + + +Docker는 Linux 커널의 리소스 격리 기능을 사용하며, 그 격리 기능의 예는 cgroups, 커널 네임스페이스, OverlayFS와 같은 조합 가능한 파일 시스템, "컨테이너"가 단일 Linux 인스턴스에서 독립적으로 실행되게 하여 가상 머신(VM)을 시작하고 관리하는 오버헤드를 피할 수 있도록 하는 기타 기능 등이 있다. + diff --git a/content/ko/docs/reference/glossary/etcd.md b/content/ko/docs/reference/glossary/etcd.md index 1727f92d2a..2521590b6d 100644 --- a/content/ko/docs/reference/glossary/etcd.md +++ b/content/ko/docs/reference/glossary/etcd.md @@ -15,5 +15,5 @@ tags: -쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대해 자세히 알아보려면 [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고하라. +쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다. diff --git a/content/ko/docs/reference/glossary/extensions.md b/content/ko/docs/reference/glossary/extensions.md new file mode 100644 index 0000000000..c51b52e08c --- /dev/null +++ b/content/ko/docs/reference/glossary/extensions.md @@ -0,0 +1,18 @@ +--- +title: 익스텐션(Extensions) +id: Extensions +date: 2019-02-01 +full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions +short_description: > + 익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. + +aka: +tags: +- fundamental +- extension +--- + 익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. + + + +대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/docs/concepts/extend-kubernetes/extend-cluster/#extensions)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다. diff --git a/content/ko/docs/reference/glossary/image.md b/content/ko/docs/reference/glossary/image.md new file mode 100755 index 0000000000..2313d1740b --- /dev/null +++ b/content/ko/docs/reference/glossary/image.md @@ -0,0 +1,18 @@ +--- +title: 이미지(Image) +id: image +date: 2018-04-12 +full_link: +short_description: > + 컨테이너의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. + +aka: +tags: +- fundamental +--- + 컨테이너의 저장된 인스턴스이며, 애플리케이션 구동에 필요한 소프트웨어 집합을 가지고 있다. + + + +소프트웨어가 컨테이너 레지스트리에 저장되고, 로컬 시스템에 풀(pull)되고, 애플리케이션으로서 실행되도록 패키징하는 방법. 메타 데이터는 이미지에 포함되며, 실행할 실행 파일, 작성자 및 기타 정보를 나타낸다. + diff --git a/content/ko/docs/reference/glossary/init-container.md b/content/ko/docs/reference/glossary/init-container.md new file mode 100755 index 0000000000..890b34505e --- /dev/null +++ b/content/ko/docs/reference/glossary/init-container.md @@ -0,0 +1,18 @@ +--- +title: 초기화 컨테이너(Init Container) +id: init-container +date: 2018-04-12 +full_link: +short_description: > + 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. + +aka: +tags: +- fundamental +--- + 앱 컨테이너가 동작하기 전에 완료되기 위해 실행되는 하나 이상의 초기화 컨테이너. + + + +한 가지 차이점을 제외하면, 초기화 컨테이너는 일반적인 앱 컨테이너와 동일하다. 초기화 컨테이너는 앱 컨테이너가 시작되기 전에 완료되는 것을 목표로 실행되어야 한다. 초기화 컨테이너는 연달아 실행된다. 다시말해, 각 초기화 컨테이너의 실행은 다음 초기화 컨테이너가 시작되기 전에 완료되어야 한다. + diff --git a/content/ko/docs/reference/glossary/job.md b/content/ko/docs/reference/glossary/job.md new file mode 100755 index 0000000000..a2c5a83466 --- /dev/null +++ b/content/ko/docs/reference/glossary/job.md @@ -0,0 +1,20 @@ +--- +title: 잡(Job) +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion +short_description: > + 완료를 목표로 실행되는 유한 또는 배치 작업. + +aka: +tags: +- fundamental +- core-object +- workload +--- + 완료를 목표로 실행되는 유한 또는 배치 작업. + + + +하나 이상의 {{< glossary_tooltip text="파드" term_id="pod" >}} 오브젝트를 생성하고 지정된 수의 파드가 성공적으로 종료되는지 확인한다. 파드가 성공적으로 완료됨에 따라, 잡은 해당 성공적인 완료를 추적한다. + diff --git a/content/ko/docs/reference/glossary/kube-apiserver.md b/content/ko/docs/reference/glossary/kube-apiserver.md index 1bfecd1448..033357e9e0 100644 --- a/content/ko/docs/reference/glossary/kube-apiserver.md +++ b/content/ko/docs/reference/glossary/kube-apiserver.md @@ -15,4 +15,4 @@ tags: -수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다. [고가용성 클러스터 구축하기](/docs/admin/high-availability/)를 참고하라. +수평적 스케일(즉, 더 많은 인스턴스를 디플로이하는 스케일)을 위해 설계되었다. [고가용성 클러스터 구축하기](/docs/admin/high-availability/)를 참고한다. diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md new file mode 100755 index 0000000000..22f55677ae --- /dev/null +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,19 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/generated/kube-proxy +short_description: > + `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. + +aka: +tags: +- fundamental +- core-object +--- + `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. + + + +`kube-proxy`는 요청에 대한 포워딩을 책임진다. `kube-proxy`는 TCP 및 UDP 스트림 포워딩을 허용하거나 TCP 및 UDP 포워딩을 백 엔드 기능 집합에 걸쳐 라운드 로빈을 제공한다. + diff --git a/content/ko/docs/reference/glossary/kube-scheduler.md b/content/ko/docs/reference/glossary/kube-scheduler.md index 8c05d992c7..d93c40bea7 100644 --- a/content/ko/docs/reference/glossary/kube-scheduler.md +++ b/content/ko/docs/reference/glossary/kube-scheduler.md @@ -14,5 +14,5 @@ tags: -스케줄링 결정을 위한 어카운트 내 요소들로는 개별 및 공동의 리소스 요건, 하드웨어/소프트웨어/정책 제약, 친밀 및 배격 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인들이 포함된다. +스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함한다. diff --git a/content/ko/docs/reference/glossary/kubectl.md b/content/ko/docs/reference/glossary/kubectl.md new file mode 100755 index 0000000000..ac68b191af --- /dev/null +++ b/content/ko/docs/reference/glossary/kubectl.md @@ -0,0 +1,19 @@ +--- +title: Kubectl +id: kubectl +date: 2018-04-12 +full_link: /docs/user-guide/kubectl-overview/ +short_description: > + 쿠버네티스 API server와 통신하기 위한 커맨드라인 툴. + +aka: +tags: +- tool +- fundamental +--- + {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}} server와 통신하기 위한 커맨드라인 툴. + + + +사용자는 쿠버네티스 오브젝트를 생성, 점검, 업데이트, 삭제하기 위해서 kubectl를 사용할 수 있다. + diff --git a/content/ko/docs/reference/glossary/kubelet.md b/content/ko/docs/reference/glossary/kubelet.md index 0c4ea9425a..0b7852adb2 100644 --- a/content/ko/docs/reference/glossary/kubelet.md +++ b/content/ko/docs/reference/glossary/kubelet.md @@ -4,16 +4,16 @@ id: kubelet date: 2018-04-12 full_link: /docs/reference/generated/kubelet short_description: > - An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. + 클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다. aka: tags: - fundamental - core-object --- - An agent that runs on each node in the cluster. It makes sure that containers are running in a pod. + 클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너가 확실하게 동작하도록 관리한다. -The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes. +Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 건강하게 동작하는 것을 확실히 한다. Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않는다. diff --git a/content/ko/docs/reference/glossary/kubernetes-api.md b/content/ko/docs/reference/glossary/kubernetes-api.md new file mode 100755 index 0000000000..3726b2aea2 --- /dev/null +++ b/content/ko/docs/reference/glossary/kubernetes-api.md @@ -0,0 +1,19 @@ +--- +title: 쿠버네티스 API(Kubernetes API) +id: kubernetes-api +date: 2018-04-12 +full_link: /ko/docs/concepts/overview/kubernetes-api/ +short_description: > + RESTful 인터페이스를 통해서 쿠버네티스 기능을 제공하고 클러스터의 상태를 저장하는 애플리케이션. + +aka: +tags: +- fundamental +- architecture +--- + RESTful 인터페이스를 통해서 쿠버네티스 기능을 제공하고 클러스터의 상태를 저장하는 애플리케이션. + + + +쿠버네티스 리소스와 "의도에 대한 레코드"는 모두 API 오브젝트로 저장되며, API로의 RESTful 호출을 통해서 수정된다. API는 구성이 선언적인 방법으로 관리되도록 한다. 사용자는 쿠버네티스 API와 직접 상호 작용할 수 있으며, `kubectl`과 같은 툴을 사용할 수도 있다. 쿠버네티스 API의 핵심은 유연하며 사용자 정의 리소스를 지원하기 위해 확장될 수도 있다. + diff --git a/content/ko/docs/reference/glossary/label.md b/content/ko/docs/reference/glossary/label.md new file mode 100755 index 0000000000..27485451a6 --- /dev/null +++ b/content/ko/docs/reference/glossary/label.md @@ -0,0 +1,18 @@ +--- +title: 레이블(Label) +id: label +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels +short_description: > + 사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다. + +aka: +tags: +- fundamental +--- + 사용자에게 의미 있고 관련성 높은 특징으로 식별할 수 있도록 오브젝트에 태그를 붙인다. + + + +레이블은 {{< glossary_tooltip text="파드" term_id="pod" >}}와 같은 오브젝트에 붙일 수 있는 키/값 쌍이다. 레이블은 오브젝트의 하위 집합을 구성하고 선택하는데 사용된다. + diff --git a/content/ko/docs/reference/glossary/minikube.md b/content/ko/docs/reference/glossary/minikube.md new file mode 100755 index 0000000000..205219f9a9 --- /dev/null +++ b/content/ko/docs/reference/glossary/minikube.md @@ -0,0 +1,19 @@ +--- +title: Minikube +id: minikube +date: 2018-04-12 +full_link: /docs/getting-started-guides/minikube/ +short_description: > + 내부적으로 쿠버네티스를 실행하기 위한 도구. + +aka: +tags: +- fundamental +- tool +--- + 내부적으로 쿠버네티스를 실행하기 위한 도구. + + + +Minikube는 VM이나 사용자 컴퓨터에서 단일 노드 클러스터를 실행한다. + diff --git a/content/ko/docs/reference/glossary/name.md b/content/ko/docs/reference/glossary/name.md index 5b43002737..5dae19c95f 100755 --- a/content/ko/docs/reference/glossary/name.md +++ b/content/ko/docs/reference/glossary/name.md @@ -14,5 +14,5 @@ tags: -특정 시점에 같은 종류(kind) 내에서는 한 오브젝트만이 부여된 이름을 가질 수 있다. 하지만, 오브젝트를 삭제한 경우, 새로운 오브젝트를 같은 이름으로 만들 수 있다. +특정 시점에 같은 종류(kind) 내에서는 하나의 이름은 하나의 오브젝트에만 지정될 수 있다. 하지만, 오브젝트를 삭제한 경우, 삭제된 오브젝트와 같은 이름을 새로운 오브젝트에 지정 가능하다. diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md new file mode 100755 index 0000000000..037961b41b --- /dev/null +++ b/content/ko/docs/reference/glossary/namespace.md @@ -0,0 +1,18 @@ +--- +title: 네임스페이스(Namespace) +id: namespace +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/namespaces +short_description: > + 쿠버네티스에서 동일한 물리 클러스터에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. + +aka: +tags: +- fundamental +--- + 쿠버네티스에서 동일한 물리 {{< glossary_tooltip text="클러스터" term_id="cluster" >}}에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화. + + + +네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다. + diff --git a/content/ko/docs/reference/glossary/node.md b/content/ko/docs/reference/glossary/node.md new file mode 100755 index 0000000000..2fafe15d07 --- /dev/null +++ b/content/ko/docs/reference/glossary/node.md @@ -0,0 +1,18 @@ +--- +title: 노드(Node) +id: node +date: 2018-04-12 +full_link: /docs/concepts/architecture/nodes/ +short_description: > + 노드는 쿠버네티스의 워커 머신이다. + +aka: +tags: +- fundamental +--- + 노드는 쿠버네티스의 워커 머신이다. + + + +워커 머신은 클러스터에 따라 VM이거나 물리 머신일 것이다. 그것은 실행해야 하는 {{< glossary_tooltip text="서비스" term_id="service" >}}와 {{< glossary_tooltip text="파드" term_id="pod" >}}를 가지고 있으며, 마스터 컴포넌트에 의해서 관리된다. 노드에 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}는 Docker, kubelet, kube-proxy를 포함한다. + diff --git a/content/ko/docs/reference/glossary/pod-lifecycle.md b/content/ko/docs/reference/glossary/pod-lifecycle.md new file mode 100644 index 0000000000..a435551e88 --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-lifecycle.md @@ -0,0 +1,19 @@ +--- +title: 파드 라이프사이클(Pod Lifecycle) +id: pod-lifecycle +date: 2019-02-17 +full-link: /ko/docs/concepts/workloads/pods/pod-lifecycle/ +related: + - pod + - container +tags: + - fundamental +short-description: > + 파드가 라이프사이클 중 어느 단계(phase)에 있는지 표현하는 고수준의 요약이다. + +--- + 파드가 라이프사이클 중 어느 단계(phase)에 있는지 표현하는 고수준의 요약이다. + + + +[파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)은 파드가 라이프사이클 중 어느 단계에 있는지 표현하는 고수준의 요약이다. 파드의 `status` 필드는 [파드 스테이터스](/docs/reference/generated/kubernetes-api/v1.13/#podstatus-v1-core) 오브젝트이다. 그것은 `phase` 필드를 가지며, Running, Pending, Succeeded, Failed, Unknown, Completed, CrashLoopBackOff 중 하나의 단계(phase)를 보여준다. diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md new file mode 100755 index 0000000000..43f0db0f2a --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-security-policy.md @@ -0,0 +1,19 @@ +--- +title: 파드 시큐리티 폴리시(Pod Security Policy) +id: pod-security-policy +date: 2018-04-12 +full_link: /docs/concepts/policy/pod-security-policy/ +short_description: > + 파드 생성과 업데이트에 대한 세밀한 인가를 활성화한다. + +aka: +tags: +- core-object +- fundamental +--- + {{< glossary_tooltip text="파드" term_id="pod" >}} 생성과 업데이트에 대한 세밀한 인가를 활성화한다. + + + +파드 명세에서 보안에 민감한 측면을 제어하는 클러스터 수준의 리소스. `PodSecurityPolicy` 오브젝트는 파드가 시스템에 수용될 수 있도록 파드가 실행해야 하는 조건의 집합과 관련된 필드의 기본 값을 정의한다. 파드 시큐리티 폴리시 제어는 선택적인 어드미션 컨트롤러로서 구현된다. + diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md new file mode 100755 index 0000000000..aca9f9a421 --- /dev/null +++ b/content/ko/docs/reference/glossary/pod.md @@ -0,0 +1,19 @@ +--- +title: 파드(Pod) +id: pod +date: 2018-04-12 +full_link: /docs/concepts/workloads/pods/pod-overview/ +short_description: > + 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 컨테이너의 집합을 나타낸다. + +aka: +tags: +- core-object +- fundamental +--- + 가장 작고 단순한 쿠버네티스 오브젝트. 파드는 사용자 클러스터에서 동작하는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 집합을 나타낸다. + + + +파드는 일반적으로 하나의 기본 컨테이너를 실행하기 위해서 구성된다. 또한 파드는 로깅과 같이 보완적인 기능을 추가하기 위한 사이드카 컨테이너를 선택적으로 실행할 수 있다. 파드는 보통 {{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}에 의해서 관리된다. + diff --git a/content/ko/docs/reference/glossary/rbac.md b/content/ko/docs/reference/glossary/rbac.md new file mode 100755 index 0000000000..246cf839d0 --- /dev/null +++ b/content/ko/docs/reference/glossary/rbac.md @@ -0,0 +1,19 @@ +--- +title: RBAC(역할 기반 엑세스 제어) +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + 인가 결정을 관리하며, 운영자가 쿠버네티스 API를 통해서 동적으로 엑세스 정책을 설정하게 한다. + +aka: +tags: +- security +- fundamental +--- + 인가 결정을 관리하며, 운영자가 {{< glossary_tooltip text="쿠버네티스 API" term_id="kubernetes-api" >}}를 통해서 동적으로 엑세스 정책을 설정하게 해준다. + + + +RBAC은 퍼미션(permission) 규칙을 포함하는 *역할* 과 역할에 정의된 퍼미션을 사용자 집합에 부여하는 *역할 바인딩* 을 이용한다. + diff --git a/content/ko/docs/reference/glossary/replica-set.md b/content/ko/docs/reference/glossary/replica-set.md new file mode 100755 index 0000000000..d9ac9ae4d4 --- /dev/null +++ b/content/ko/docs/reference/glossary/replica-set.md @@ -0,0 +1,20 @@ +--- +title: 레플리카 셋(ReplicaSet) +id: replica-set +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + 레플리카 셋은 차세대 레플리케이션 컨트롤러이다. + +aka: +tags: +- fundamental +- core-object +- workload +--- + 레플리카 셋은 차세대 레플리케이션 컨트롤러이다. + + + +레플리케이션 컨트롤러와 같은 레플리카 셋은, 지정된 수의 파드 레플리카가 동시에 동작하게 관리한다. 레플리카 셋은 레이블 사용자 가이드에 기술된 대로 셋(set) 기반의 셀렉터 요구 사항을 지원한다. 반면, 레플리케이션 컨트롤러는 동일성 기반의 셀렉터 요구 사항만 제공한다. + diff --git a/content/ko/docs/reference/glossary/resource-quota.md b/content/ko/docs/reference/glossary/resource-quota.md new file mode 100755 index 0000000000..c5cafb3bee --- /dev/null +++ b/content/ko/docs/reference/glossary/resource-quota.md @@ -0,0 +1,20 @@ +--- +title: 리소스 쿼터(Resource Quotas) +id: resource-quota +date: 2018-04-12 +full_link: /docs/concepts/policy/resource-quotas/ +short_description: > + 네임스페이스당 전체 리소스 소비를 제한하는 제약을 제공한다. + +aka: +tags: +- fundamental +- operation +- architecture +--- + {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}당 전체 리소스 소비를 제한하는 제약을 제공한다. + + + +타입에 따라 네임스페이스에서 생성될 수 있는 오브젝트의 수량과 해당 프로젝트의 리소스에 의해서 소비되는 컴퓨팅 리소스의 총량도 제한한다. + diff --git a/content/ko/docs/reference/glossary/selector.md b/content/ko/docs/reference/glossary/selector.md new file mode 100755 index 0000000000..400263e873 --- /dev/null +++ b/content/ko/docs/reference/glossary/selector.md @@ -0,0 +1,18 @@ +--- +title: 셀렉터(Selector) +id: selector +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels/ +short_description: > + 사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다. + +aka: +tags: +- fundamental +--- + 사용자가 레이블에 따라서 리소스 리스트를 필터할 수 있게 한다. + + + +셀렉터는 리소스 리스트를 질의할 때 리스트를 {{< glossary_tooltip text="레이블" term_id="label" >}}에 따라서 필터하기 위해서 적용된다.Selectors are applied when querying lists of resources to filter them by {{< glossary_tooltip text="Labels" term_id="label" >}}. + diff --git a/content/ko/docs/reference/glossary/service-account.md b/content/ko/docs/reference/glossary/service-account.md new file mode 100755 index 0000000000..2dc318a569 --- /dev/null +++ b/content/ko/docs/reference/glossary/service-account.md @@ -0,0 +1,19 @@ +--- +title: 서비스 어카운트(Service Account) +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + 파드에서 실행 중인 프로세스를 위한 신원(identity)을 제공한다. + +aka: +tags: +- fundamental +- core-object +--- + {{< glossary_tooltip text="파드" term_id="pod" >}}에서 실행 중인 프로세스를 위한 신원(identity)을 제공한다. + + + +파드 내부의 프로세스가 클러스터에 엑세스할 때, API server에 의해서 특별한 서비스 어카운트(예를 들면, 기본(default))로 인증된다. 파드를 생성할 때, 서비스 어카운트를 명시하지 않는다면, 동일한 {{< glossary_tooltip text="네임스페이스" term_id="namespace" >}}의 기본 서비스 어카운트가 자동적으로 할당된다. + diff --git a/content/ko/docs/reference/glossary/service.md b/content/ko/docs/reference/glossary/service.md new file mode 100755 index 0000000000..3034640c5a --- /dev/null +++ b/content/ko/docs/reference/glossary/service.md @@ -0,0 +1,19 @@ +--- +title: 서비스(Service) +id: service +date: 2018-04-12 +full_link: /docs/concepts/services-networking/service/ +short_description: > + 파드의 집합과 같은 애플리케이션에 엑세스하는 방법을 기술하는 API 오브젝트이며, 포트와 로드밸런서를 기술할 수 있다. + +aka: +tags: +- fundamental +- core-object +--- + {{< glossary_tooltip text="파드" term_id="pod" >}}의 집합과 같은 애플리케이션에 엑세스하는 방법을 기술하는 API 오브젝트이며, 포트와 로드밸런서를 기술할 수 있다. + + + +엑세스 포인트는 클러스터의 내부이거나 외부일 수 있다. + diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md new file mode 100755 index 0000000000..a7fc1ee641 --- /dev/null +++ b/content/ko/docs/reference/glossary/statefulset.md @@ -0,0 +1,23 @@ +--- +title: 스테이트풀 셋(StatefulSet) +id: statefulset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/statefulset/ +short_description: > + 파드 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . + +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- + {{< glossary_tooltip text="파드" term_id="pod" >}} 집합의 디플로이먼트와 스케일링을 관리하며, 파드들의 *순서 및 고유성을 보장한다* . + + + +{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}}와 유사하게, 스테이트풀 셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다. 디플로이먼트와는 다르게, 스테이트풀 셋은 각 파드의 독자성을 유지한다. 이 파드들은 동일한 스팩으로 생성되었지만, 서로 교체는 불가능하다. 다시 말해, 각각은 재스케줄링 간에도 지속적으로 유지되는 식별자를 가진다. + +스테이트풀 셋도 다른 컨트롤러와 같은 패턴으로 운용된다. 사용자는 의도한 상태를 스테이트풀 셋 *오브젝트* 로 정의하고, 스테이트풀 셋 *컨트롤러* 는 현재 상태에서 의도한 상태에 이르기 위해 필요한 업데이트를 수행한다. + diff --git a/content/ko/docs/reference/glossary/taint.md b/content/ko/docs/reference/glossary/taint.md new file mode 100644 index 0000000000..fe8119cea7 --- /dev/null +++ b/content/ko/docs/reference/glossary/taint.md @@ -0,0 +1,18 @@ +--- +title: 테인트(Taint) +id: taint +date: 2019-01-11 +full_link: /docs/concepts/configuration/taint-and-toleration/ +short_description: > + 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다. + +aka: +tags: +- core-object +- fundamental +--- + 파드가 노드나 노드 그룹에 스케줄링되는 것을 방지하는 키-값 쌍 및 효과이다. + + + +테인트 및 {{< glossary_tooltip text="톨러레이션(toleration)" term_id="toleration" >}}은 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 테인트가 {{< glossary_tooltip text="노드" term_id="node" >}}에 적용될 수 있으며, 이것은 노드에 해당 테인트를 극복(tolerate)하지 않은 파드를 허용하지 않도록 표시한다. diff --git a/content/ko/docs/reference/glossary/toleration.md b/content/ko/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000..8778d28b1e --- /dev/null +++ b/content/ko/docs/reference/glossary/toleration.md @@ -0,0 +1,18 @@ +--- +title: 톨러레이션(Toleration) +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/configuration/taint-and-toleration/ +short_description: > + 매칭되는 테인트(taint)를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다. + +aka: +tags: +- core-object +- fundamental +--- + 매칭되는 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 활성화하는 키-값 쌍 및 효과이다. + + + +톨러레이션 및 {{< glossary_tooltip text="테인트" term_id="taint" >}}는 함께 작동하며, 파드가 적절하지 못한 노드에 스케줄되는 것을 방지한다. 하나 이상의 톨러레이션이 {{< glossary_tooltip text="파드" term_id="pod" >}}에 적용될 수 있으며, 이것은 매칭되는 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 가진 노드나 노드 그룹에 파드가 스케줄링되는 것을 허용(그러나 필수는 아님)하도록 표시한다. diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md new file mode 100755 index 0000000000..4f5c26c88a --- /dev/null +++ b/content/ko/docs/reference/glossary/volume.md @@ -0,0 +1,19 @@ +--- +title: 볼륨(Volume) +id: volume +date: 2018-04-12 +full_link: /docs/concepts/storage/volumes/ +short_description: > + 데이터를 포함하고 있는 디렉토리이며, 파드의 컨테이너에서 접근 가능하다. + +aka: +tags: +- core-object +- fundamental +--- + 데이터를 포함하고 있는 디렉토리이며, {{< glossary_tooltip text="파드" term_id="pod" >}}의 컨테이너에서 접근 가능하다. + + + +쿠버네티스 볼륨은 그것을 포함하고 있는 {{< glossary_tooltip text="파드" term_id="pod" >}}만큼 오래 산다. 결과적으로, 볼륨은 {{< glossary_tooltip text="파드" term_id="pod" >}} 안에서 실행되는 모든 {{< glossary_tooltip text="컨테이너" term_id="container" >}} 보다 오래 지속되며, 데이터는 {{< glossary_tooltip text="컨테이너" term_id="container" >}}의 재시작 간에도 보존된다. + diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md new file mode 100644 index 0000000000..e536b026a2 --- /dev/null +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -0,0 +1,358 @@ +--- +title: kubectl 치트 시트 +content_template: templates/concept +card: + name: reference + weight: 30 +--- + + + + + + +{{% capture overview %}} + +참고 항목: [Kubectl 개요](/docs/reference/kubectl/overview/)와 [JsonPath 가이드](/docs/reference/kubectl/jsonpath). + +이 페이지는 `kubectl` 커맨드의 개요이다. + +{{% /capture %}} + +{{% capture body %}} + +# kubectl - 치트 시트 + +## Kubectl 자동 완성 + +### BASH + +```bash +source <(kubectl completion bash) # bash-completion 패키지를 먼저 설치한 후, bash의 자동 완성을 현재 셸에 설정한다 +echo "source <(kubectl completion bash)" >> ~/.bashrc # 자동 완성을 bash 셸에 영구적으로 추가한다 +``` + +또한, `kubectl`의 의미로 사용되는 약칭을 사용할 수 있다. + +```bash +alias k=kubectl +complete -F __start_kubectl k +``` + +### ZSH + +```bash +source <(kubectl completion zsh) # 현재 셸에 zsh의 자동 완성 설정 +echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # 자동 완성을 zsh 셸에 영구적으로 추가한다. +``` + +## Kubectl 컨텍스트와 설정 + +`kubectl`이 통신하고 설정 정보를 수정하는 쿠버네티스 클러스터를 +지정한다. 설정 파일에 대한 자세한 정보는 [kubeconfig를 이용한 클러스터 간 인증](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 문서를 +참고한다. + +```bash +kubectl config view # 병합된 kubeconfig 설정을 표시한다. + +# 동시에 여러 kubeconfig 파일을 사용하고 병합된 구성을 확인한다 +KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 kubectl config view + +# e2e 사용자의 암호를 확인한다 +kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' + +kubectl config view -o jsonpath='{.users[].name}' # 사용자 리스트 조회 +kubectl config current-context # 현재 컨텍스트 확인 +kubectl config use-context my-cluster-name # my-cluster-name를 기본 컨텍스트로 설정 + +# 기본 인증을 지원하는 새로운 클러스터를 kubeconf에 추가한다 +kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword + +# 특정 사용자와 네임스페이스를 사용하는 컨텍스트 설정 +kubectl config set-context gce --user=cluster-admin --namespace=foo \ + && kubectl config use-context gce + +kubectl config unset users.foo # foo 사용자 삭제 +``` + +## Apply +`apply`는 쿠버네티스 리소스를 정의하는 파일을 통해 애플리케이션을 관리한다. `kubectl apply`를 실행하여 클러스터에 리소스를 생성하고 업데이트한다. 이것은 프로덕션 환경에서 쿠버네티스 애플리케이션을 관리할 때 권장된다. [Kubectl Book](https://kubectl.docs.kubernetes.io)을 참고한다. + +## 오브젝트 생성 + +쿠버네티스 매니페스트는 json이나 yaml로 정의된다. 파일 확장자는 `.yaml` +, `.yml`, `.json` 이 사용된다. + +```bash +kubectl create -f ./my-manifest.yaml # 리소스(들) 생성 +kubectl create -f ./my1.yaml -f ./my2.yaml # 여러 파일로 부터 생성 +kubectl create -f ./dir # dir 내 모든 매니페스트 파일에서 리소스(들) 생성 +kubectl create -f https://git.io/vPieo # url로부터 리소스(들) 생성 +kubectl create deployment nginx --image=nginx # nginx 단일 인스턴스를 시작 +kubectl explain pods,svc # 파드와 서비스 매니페스트 문서를 조회 + +# stdin으로 다수의 YAML 오브젝트 생성 +cat </dev/null; printf "\n"; done + +# 어떤 노드가 준비됐는지 확인 +JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \ + && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True" + +# 파드에 의해 현재 사용되고 있는 모든 시크릿 목록 조회 +kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq + +# 타임스탬프로 정렬된 이벤트 목록 조회 +kubectl get events --sort-by=.metadata.creationTimestamp +``` + +## 리소스 업데이트 + +1.11 버전에서 `rolling-update`는 사용 중단(deprecated)되었다. ([CHANGELOG-1.11.md](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md) 참고) 대신 `rollout`를 사용한다. + +```bash +kubectl set image deployment/frontend www=image:v2 # "frontend" 디플로이먼트의 "www" 컨테이너 이미지를 업데이트하는 롤링 업데이트 +kubectl rollout undo deployment/frontend # 이전 디플로이먼트로 롤백 +kubectl rollout status -w deployment/frontend # 완료될 때까지 "frontend" 디플로이먼트의 롤링 업데이트 상태를 감시 + +# 버전 1.11 부터 사용 중단 +kubectl rolling-update frontend-v1 -f frontend-v2.json # (사용중단) frontend-v1 파드의 롤링 업데이트 +kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (사용중단) 리소스 이름 변경과 이미지 업데이트 +kubectl rolling-update frontend --image=image:v2 # (사용중단) 프론트엔드의 파드 이미지 업데이트 +kubectl rolling-update frontend-v1 frontend-v2 --rollback # (사용중단) 진행중인 기존 롤아웃 중단 + +cat pod.json | kubectl replace -f - # std로 전달된 JSON을 기반으로 파드 교체 + +# 리소스를 강제 교체, 삭제 후 재생성함. 이것은 서비스를 중단시킴. +kubectl replace --force -f ./pod.json + +# 복제된 nginx를 위한 서비스를 생성한다. 80 포트로 서비스하고, 컨테이너는 8000 포트로 연결한다. +kubectl expose rc nginx --port=80 --target-port=8000 + +# 단일-컨테이너 파드의 이미지 버전(태그)을 v4로 업데이트 +kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f - + +kubectl label pods my-pod new-label=awesome # 레이블 추가 +kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 어노테이션 추가 +kubectl autoscale deployment foo --min=2 --max=10 # 디플로이먼트 "foo" 오토스케일 +``` + +## 리소스 패치 + +```bash +kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 노드를 부분적으로 업데이트 + +# 컨테이너의 이미지를 업데이트. 병합(merge) 키이므로, spec.containers[*].name이 필요. +kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}' + +# 위치 배열을 이용한 json 패치를 사용하여, 컨테이너의 이미지를 업데이트. +kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]' + +# 위치 배열을 이용한 json 패치를 사용하여 livenessProbe 디플로이먼트 비활성화. +kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]' + +# 위치 배열에 새 요소 추가 +kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' +``` + +## 리소스 편집 +편집기로 모든 API 리소스를 편집. + +```bash +kubectl edit svc/docker-registry # docker-registry라는 서비스 편집 +KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 다른 편집기 사용 +``` + +## 리소스 스케일링 + +```bash +kubectl scale --replicas=3 rs/foo # 'foo'라는 레플리카 셋을 3으로 스케일 +kubectl scale --replicas=3 -f foo.yaml # "foo.yaml"에 지정된 리소스의 크기를 3으로 스케일 +kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # mysql이라는 디플로이먼트의 현재 크기가 2인 경우, mysql을 3으로 스케일 +kubectl scale --replicas=5 rc/foo rc/bar rc/baz # 여러 개의 레플리케이션 컨트롤러 스케일 +``` + +## 리소스 삭제 + +```bash +kubectl delete -f ./pod.json # pod.json에 지정된 유형 및 이름을 사용하여 파드 삭제 +kubectl delete pod,service baz foo # "baz", "foo"와 동일한 이름을 가진 파드와 서비스 삭제 +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 네임스페이스 내 모든 파드와 서비스 삭제 +``` + +## 실행 중인 파드와 상호 작용 + +```bash +kubectl logs my-pod # 파드 로그(stdout) 덤프 +kubectl logs my-pod --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout) 덤프 +kubectl logs my-pod -c my-container # 파드 로그(stdout, 멀티-컨테이너 경우) 덤프 +kubectl logs my-pod -c my-container --previous # 컨테이너의 이전 인스턴스 생성에 대한 파드 로그(stdout, 멀티-컨테이너 경우) 덤프 +kubectl logs -f my-pod # 실시간 스트림 파드 로그(stdout) +kubectl logs -f my-pod -c my-container # 실시간 스트림 파드 로그(stdout, 멀티-컨테이너 경우) +kubectl run -i --tty busybox --image=busybox -- sh # 대화형 셸로 파드를 실행 +kubectl attach my-pod -i # 실행중인 컨테이너에 연결 +kubectl port-forward my-pod 5000:6000 # 로컬 머신의 5000번 포트를 리스닝하고, my-pod의 6000번 포트로 전달 +kubectl exec my-pod -- ls / # 기존 파드에서 명령 실행(한 개 컨테이너 경우) +kubectl exec my-pod -c my-container -- ls / # 기존 파드에서 명령 실행(멀티-컨테이너 경우) +kubectl top pod POD_NAME --containers # 특정 파드와 해당 컨테이너에 대한 메트릭 표시 +``` + +## 노드, 클러스터와 상호 작용 + +```bash +kubectl cordon my-node # my-node를 스케줄링할 수 없도록 표기 +kubectl drain my-node # 유지 보수를 위해서 my-node를 준비 상태로 비움 +kubectl uncordon my-node # my-node를 스케줄링할 수 있도록 표기 +kubectl top node my-node # 주어진 노드에 대한 메트릭 표시 +kubectl cluster-info # 마스터 및 서비스의 주소 표시 +kubectl cluster-info dump # 현재 클러스터 상태를 stdout으로 덤프 +kubectl cluster-info dump --output-directory=/path/to/cluster-state # 현재 클러스터 상태를 /path/to/cluster-state으로 덤프 + +# key와 effect가 있는 테인트(taint)가 이미 존재하면, 그 값이 지정된 대로 대체된다. +kubectl taint nodes foo dedicated=special-user:NoSchedule +``` + +### 리소스 타입 + +단축명, [API 그룹](/ko/docs/concepts/overview/kubernetes-api/#api-groups)과 함께 지원되는 모든 리소스 유형들, 그것들의 [네임스페이스](/ko/docs/concepts/overview/working-with-objects/namespaces)와 [종류(Kind)](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects)를 나열: + +```bash +kubectl api-resources +``` + +API 리소스를 탐색하기 위한 다른 작업: + +```bash +kubectl api-resources --namespaced=true # 네임스페이스를 가지는 모든 리소스 +kubectl api-resources --namespaced=false # 네임스페이스를 가지지 않는 모든 리소스 +kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름 만) 출력 +kubectl api-resources -o wide # 모든 리소스의 확장된 ("wide"로 알려진) 출력 +kubectl api-resources --verbs=list,get # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력 +kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스 +``` + +### 출력 형식 지정 + +특정 형식으로 터미널 창에 세부 사항을 출력하려면, 지원되는 `kubectl` 명령에 `-o` 또는 `--output` 플래그를 추가하면 된다. + +출력 형식 | 세부 사항 +--------------| ----------- +`-o=custom-columns=<명세>` | 쉼표로 구분된 사용자 정의 열 목록을 사용하여 테이블 출력 +`-o=custom-columns-file=<파일명>` | `<파일명>`파일에서 사용자 정의 열 템플릿을 사용하여 테이블 출력 +`-o=json` | JSON 형식의 API 오브젝트 출력 +`-o=jsonpath=<템플릿>` | [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=jsonpath-file=<파일명>` | <파일명> 파일에서 [jsonpath](/docs/reference/kubectl/jsonpath) 표현식에 정의된 필드 출력 +`-o=name` | 리소스 명만 출력하고 그 외에는 출력하지 않음 +`-o=wide` | 추가 정보가 포함된 일반-텍스트 형식으로 출력하고, 파드의 경우 노드 명이 포함 +`-o=yaml` | YAML 형식의 API 오브젝트 출력 + +### Kubectl 출력 로그 상세 레벨(verbosity)과 디버깅 + +Kubectl 로그 상세 레벨(verbosity)은 `-v` 또는`--v` 플래그와 로그 레벨을 나타내는 정수로 제어된다. 일반적인 쿠버네티스 로깅 규칙과 관련 로그 레벨이 [여기](https://github.com/kubernetes/community/blob/master/contributors/devel/logging.md)에 설명되어 있다. + +로그 레벨 | 세부 사항 +--------------| ----------- +`--v=0` | 일반적으로 운영자에게 유용함. +`--v=1` | 자세한 정보를 원하지 않는 경우, 적절한 기본 로그 수준. +`--v=2` | 서비스와 시스템의 중요한 변화와 관련이있는 중요한 로그 메시지에 대한 유용한 정상 상태 정보. 이는 대부분의 시스템에서 권장되는 기본 로그 수준이다. +`--v=3` | 변경 사항에 대한 확장 정보. +`--v=4` | 디버그 수준 상세화. +`--v=6` | 요청한 리소스를 표시. +`--v=7` | HTTP 요청 헤더를 표시. +`--v=8` | HTTP 요청 내용을 표시. +`--v=9` | 내용을 잘라 내지 않고 HTTP 요청 내용을 표시. + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [kubectl 개요](/docs/reference/kubectl/overview/)에 대해 더 배워보자. + +* [kubectl](/docs/reference/kubectl/kubectl/) 옵션을 참고한다. + +* 재사용 스크립트에서 kubectl 사용 방법을 이해하기 위해 [kubectl 사용법](/docs/reference/kubectl/conventions/)을 참고한다. + +* 더 많은 [kubectl 치트 시트](https://github.com/dennyzhang/cheatsheet-kubernetes-A4) 커뮤니티 확인 + +{{% /capture %}} diff --git a/content/ko/docs/setup/certificates.md b/content/ko/docs/setup/certificates.md index 8dd327a0b9..50962fb035 100644 --- a/content/ko/docs/setup/certificates.md +++ b/content/ko/docs/setup/certificates.md @@ -61,7 +61,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | 기본 CN | 부모 CA | O (주체에서) | 종류 | 호스트 (SAN) | |-------------------------------|---------------------------|----------------|----------------------------------------|---------------------------------------------| -| kube-etcd | etcd-ca | | server, client [1][etcdbug] | `localhost`, `127.0.0.1` | +| kube-etcd | etcd-ca | | server, client | `localhost`, `127.0.0.1` | | kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | | kube-etcd-healthcheck-client | etcd-ca | | client | | | kube-apiserver-etcd-client | etcd-ca | system:masters | client | | diff --git a/content/ko/docs/setup/minikube.md b/content/ko/docs/setup/minikube.md index 5d814f5838..b634e3a72b 100644 --- a/content/ko/docs/setup/minikube.md +++ b/content/ko/docs/setup/minikube.md @@ -42,30 +42,50 @@ VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 * none (쿠버네티스 구성요소는 VM이 아닌 호스트상에서 동작한다. 이 드라이버를 사용하기 위해서는 Docker ([docker 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))와 리눅스 환경)이 필요하다. ```shell -$ minikube start +minikube start +``` +``` Starting local Kubernetes cluster... Running pre-create checks... Creating machine... Starting local Kubernetes cluster... - -$ kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 +``` +```shell +kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 +``` +``` deployment.apps/hello-minikube created -$ kubectl expose deployment hello-minikube --type=NodePort -service/hello-minikube exposed +``` +```shell +kubectl expose deployment hello-minikube --type=NodePort +``` +``` +service/hello-minikube exposed +``` +``` # 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 +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 -$ kubectl get pod +kubectl get pod +``` +``` NAME READY STATUS RESTARTS AGE hello-minikube-3383150820-vctvh 1/1 Running 0 13s +``` +``` # We can see that the pod is now Running and we will now be able to curl it: -$ curl $(minikube service hello-minikube --url) - +curl $(minikube service hello-minikube --url) +``` +``` Hostname: hello-minikube-7c77b68cff-8wdzq @@ -91,13 +111,26 @@ Request Headers: Request Body: -no body in request- +``` - -$ kubectl delete services hello-minikube +```shell +kubectl delete services hello-minikube +``` +``` service "hello-minikube" deleted -$ kubectl delete deployment hello-minikube +``` + +```shell +kubectl delete deployment hello-minikube +``` +``` deployment.extensions "hello-minikube" deleted -$ minikube stop +``` + +```shell +minikube stop +``` +``` Stopping local Kubernetes cluster... Stopping "minikube"... ``` @@ -109,7 +142,7 @@ Stopping "minikube"... [containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=containerd \ @@ -119,7 +152,7 @@ $ minikube start \ 혹은 확장 버전을 사용할 수 있다. ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ @@ -133,7 +166,7 @@ $ minikube start \ [CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=cri-o \ @@ -143,7 +176,7 @@ $ minikube start \ 혹은 확장 버전을 사용할 수 있다. ```bash -$ minikube start \ +minikube start \ --network-plugin=cni \ --enable-default-cni \ --extra-config=kubelet.container-runtime=remote \ @@ -157,7 +190,7 @@ $ minikube start \ [rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```shell -$ minikube start \ +minikube start \ --network-plugin=cni \ --enable-default-cni \ --container-runtime=rkt @@ -373,7 +406,7 @@ HTTP 프록시 내부라면, Docker에서 프록시 설정을 해야 한다. 예를 들어: ```shell -$ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ +minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ --docker-env https_proxy=https://$YOURPROXY:PORT ``` @@ -381,7 +414,7 @@ $ minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ 이 IP 주소에 대해 프록시 설정을 지나치게 하려면 no_proxy 설정을 수정해야 한다. 다음과 같이 할 수 있다. ```shell -$ export no_proxy=$no_proxy,$(minikube ip) +export no_proxy=$no_proxy,$(minikube ip) ``` ## 알려진 이슈 diff --git a/content/ko/docs/setup/pick-right-solution.md b/content/ko/docs/setup/pick-right-solution.md index 799069362b..c1add0ff1a 100644 --- a/content/ko/docs/setup/pick-right-solution.md +++ b/content/ko/docs/setup/pick-right-solution.md @@ -41,8 +41,16 @@ card: ## 로컬 머신 솔루션 +### 커뮤니티 지원 도구 + * [Minikube](/docs/setup/minikube/)는 개발과 테스트를 위한 단일 노드 쿠버네티스 클러스터를 로컬에 생성하기 위한 하나의 방법이다. 설치는 완전히 자동화 되어 있고, 클라우드 공급자 계정 정보가 필요하지 않다. +* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)는 다중 노드 (minikube는 단일 노드인 반면) docker 데몬만 필요로 하는 쿠버네티스 클러스터이다. docker-in-docker 기술을 사용하여 쿠버네티스 클러스터를 생성한다. + +* [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind)는 Docker 컨테이너 "노드"를 사용하여 로컬 쿠버네티스 클러스터를 실행하기 위한 도구이다. 이것은 주로 쿠버네티스 1.11+를 테스트하기 위해 설계되었다. 이를 사용하여 다중 노드 또는 다중 컨트롤 플레인 쿠버네티스 클러스터를 만들 수 있다. + +### 생태계 도구 + * [Docker Desktop](https://www.docker.com/products/docker-desktop)는 Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다. 수 분 내에 단일 노드 쿠버네티스 클러스터에서 컨테이너로 코딩과 배포를 @@ -56,8 +64,6 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)는 Terraform/Packer/BASH 기반의 리눅스 호스트 상의 LXD 클러스터에 7개의 노드(부트 1개, 마스터 1개, 관리 1개, 프록시 1개 그리고 워커 3개)를 생성하기 위한 Infrastructure as Code (IaC) 스크립트이다. -* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster)는 하나의 docker 데몬이 필요한 멀티 노드 쿠버네티스 클러스터이다.(minikube는 단일 노드이다.) 클러스터 생성을 위해서 docker-in-docker 기술을 사용한다. - * [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/local/)는 로컬 호스트에서 9개의 인스턴스 배포를 지원한다. ## 호스트 된 솔루션 @@ -94,7 +100,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [OpenShift Online](https://www.openshift.com/features/)은 쿠버네티스 애플리케이션을 위해 호스트 된 무료 접근을 제공한다. -* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)는 컨테이너 애플리케이션을 클라우드에 배포하는 데 사용할 수 있는 완벽하게 관리되고, 확장 가능하며, 가용성이 높은 서비스이다. +* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm)는 컨테이너 애플리케이션을 클라우드에 배포하는 데 사용할 수 있는 완벽하게 관리되고, 확장 가능하며, 가용성이 높은 서비스이다. * [Platform9](https://platform9.com/products/kubernetes/)는 온-프레미스 또는 모든 퍼블릭 클라우드에서 관리형 쿠버네티스를 제공한다. 또한, 24/7 상태 모니터링 및 알람 및 경고 서비스를 제공한다.(Kube2go는 웹 UI 기반의 쿠버네티스 클러스터 배포 서비스인 Platform9가 Platform9 Sandbox에 통합된 형태로 출시되었다.) @@ -102,6 +108,8 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/)는 자체 OpenStack 퍼블릭 클라우드 상에서 서비스로써 관리형 쿠버네티스를 제공한다. 라이프사이클 관리, 관리 대시보드, 모니터링, 오토스케일링과 그 밖에 많은 기능을 포함한다. +* [VEXXHOST](https://vexxhost.com/public-cloud/container-services/kubernetes/) VEXXHOST는 공공 클라우드에서 공인된 쿠버네티스를 제공하며, 캐나다에서 가장 큰 OpenStack 퍼블릭 클라우드이다. + * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks)는 사용하기 쉽고, 기본적으로 안전하며, 비용 효율적인 SaaS 기반의 쿠버네티스 클러스터를 제공하는 VMWare 클라우드 서비스 포트폴리오의 엔터프라이즈 Kubernetes-as-a-Service 오퍼링이다. ## 턴키 클라우드 솔루션 @@ -127,12 +135,14 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [Madcore.Ai](https://madcore.ai/) * [Nirmata](https://nirmata.com/) * [Nutanix Karbon](https://www.nutanix.com/products/karbon/) -* [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm) +* [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm) * [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) * [Stackpoint.io](/docs/setup/turnkey/stackpoint/) -* [Tectonic by CoreOS](https://coreos.com/tectonic) +* [Supergiant.io](https://supergiant.io/) +* [VEXXHOST](https://vexxhost.com/private-cloud/) * [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) +* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) ## 온-프레미스 턴키 클라우드 솔루션 @@ -146,7 +156,7 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/) * [Kontena Pharos](https://kontena.io/pharos/) * [Kubermatic](https://www.loodse.com) -* [Kublr](https://kublr.com/) +* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution) * [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) * [Nirmata](https://nirmata.com/) * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com) @@ -154,14 +164,14 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 * [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) * [SUSE CaaS Platform](https://www.suse.com/products/caas-platform) * [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/) +* [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) + ## 사용자 지정 솔루션 쿠버네티스는 넓은 범위의 클라우드 공급자와 베어메탈 환경에서, 그리고 많은 기반 운영 체제에서 동작할 수 있다. -필요에 맞는 가이드를 아래에서 찾았다면, 그것을 사용하자. 약간 구식일 수도 있지만, 처음부터 시작하는 것보다 더 쉬울 것이다. -특별한 요구사항이 있기 때문에, 또는 단지 쿠버네티스 클러스터의 아래에 무엇이 있는지를 이해하기 원하기 때문에 -처음부터 시작하기를 원한다면, [맨 처음부터 시작하기](/docs/setup/release/building-from-source/) 가이드를 시도하라. +필요에 맞는 가이드를 아래에서 찾았다면, 그것을 사용하자. ### 일반 @@ -172,35 +182,34 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 다음 솔루션은 위의 솔루션에서 다루지 않는 클라우드 공급자와 운영체제의 조합이다. * [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) -* [CoreOS on AWS or GCE](/docs/setup/custom-cloud/coreos/) * [Gardener](https://gardener.cloud/) -* [Kublr](https://kublr.com/) +* [Kublr](www.kublr.com/kubernetes.io/setup-hosted-solution) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) * [Kubespray](/docs/setup/custom-cloud/kubespray/) * [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) ### 온-프레미스 VM * [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) -* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (Ansible, CoreOS와 flannel를 사용) -* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (Fedora와 flannel를 사용) +* [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) * [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/) -* [Vagrant](/docs/setup/custom-cloud/coreos/) (CoreOS와 flannel를 사용) -* [VMware](/docs/setup/custom-cloud/coreos/) (CoreOS와 flannel를 사용) -* [VMware vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) -* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (Juju, Ubuntu와 flannel를 사용) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) +* [VMware vSphere](https://github.com/kubernetes/cloud-provider-vsphere) +* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (uses Juju, Ubuntu and flannel) ### 베어 메탈 -* [CoreOS](/docs/setup/custom-cloud/coreos/) * [Digital Rebar](/docs/setup/on-premises-metal/krib/) * [Docker Enterprise](https://www.docker.com/products/docker-enterprise) * [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/) * [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) * [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) * [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) +* [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-PKS) ### 통합 @@ -216,59 +225,58 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다 IaaS 공급자 | 구성 관리 | OS | 네트워킹 | 문서 | 지원 레벨 -------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------------------------- +Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial +Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial 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)) -Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial -Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial -IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | -Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial -Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial -AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial -Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) -Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial -Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial -Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial -Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial -GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project -Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial -Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine) -Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project -Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) -DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md)) -AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community -GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires)) -Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles)) -CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa)) -VMware vSphere | any | multi-support | multi-support | [docs](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html) -Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap)) -lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) -VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) -AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) -AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb)) -Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) -oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z)) -any | any | any | any | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune)) +any | any | any | any | [docs](/docs/setup/scratch/) | 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 | 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/) -Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial -Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial -IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial +AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community +AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) +AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb)) +AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine) +Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial +Bare-metal | custom | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap)) +Bare-metal | custom | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project +Bare-metal | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Bare-metal | custom | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) +CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa)) +DCOS | Marathon | CoreOS/Alpine | custom | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md)) Digital Rebar | kubeadm | any | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar)) -VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial +Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial +Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial +GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires)) +GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project +Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial +IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | +Kublr | custom | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial +Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial +KVM | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +libvirt | custom | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) +lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial - -{{< note >}} -위의 표는 버전 테스트/사용된 노드의 지원 레벨을 기준으로 정렬된다. -{{< /note >}} +Oracle Cloud Infrastructure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) | | | multi-support | [docs](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | Commercial +oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z)) +Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial +Rackspace | custom | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) +Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial +Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial +Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles)) +VMware vSphere | any | multi-support | multi-support | [docs](https://github.com/kubernetes/cloud-provider-vsphere/tree/master/docs) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html) +VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) +VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial +VMware Enterprise PKS | BOSH | Ubuntu | VMware NSX-T/flannel | [docs](https://docs.vmware.com/en/VMware-Enterprise-PKS/) | Commercial +VMware Essential PKS | any | multi-support | multi-support | [docs](https://cloud.vmware.com/vmware-essential-PKS) | Commercial ### 열 정의 @@ -278,7 +286,6 @@ Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mi nodes. * **네트워킹**은 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)을 구현하는 것이다. 네트워크 유형이 _none_인 노드는 단일 노드 이상을 지원하지 않거나, 단일 물리 노드에서 여러 VM 노드를 지원할 수 있다. -* **적합성**은 명시된 구성으로 생성된 클러스터가 쿠버네티스 v1.0.0의 API 및 기본 기능을 지원하는지의 프로젝트 적합성 테스트 통과 여부를 나타낸다. * **지원 레벨** * **프로젝트**: 쿠버네티스 커미터는 현재 구성을 정기적으로 사용하므로, 일반적으로 최신 쿠버네티스 릴리즈와 함께 동작한다. * **상업용**: 자체 지원 계약을 가진 상업용 제품. diff --git a/content/ko/docs/setup/scratch.md b/content/ko/docs/setup/scratch.md deleted file mode 100644 index 4067591717..0000000000 --- a/content/ko/docs/setup/scratch.md +++ /dev/null @@ -1,872 +0,0 @@ ---- -title: 맨 처음부터 사용자 지정 클러스터 생성 ---- - -This guide is for people who want to craft a custom Kubernetes cluster. If you -can find an existing Getting Started Guide that meets your needs on [this -list](/docs/setup/), then we recommend using it, as you will be able to benefit -from the experience of others. However, if you have specific IaaS, networking, -configuration management, or operating system requirements not met by any of -those guides, then this guide will provide an outline of the steps you need to -take. Note that it requires considerably more effort than using one of the -pre-defined guides. - -This guide is also useful for those wanting to understand at a high level some of the -steps that existing cluster setup scripts are making. - -{{< toc >}} - -## 설계 및 준비 - -### 학습 계획 - - 1. You should be familiar with using Kubernetes already. We suggest you set - up a temporary cluster by following one of the other Getting Started Guides. - This will help you become familiar with the CLI ([kubectl](/docs/user-guide/kubectl/)) and concepts ([pods](/docs/user-guide/pods/), [services](/docs/concepts/services-networking/service/), etc.) first. - 1. You should have `kubectl` installed on your desktop. This will happen as a side - effect of completing one of the other Getting Started Guides. If not, follow the instructions - [here](/docs/tasks/kubectl/install/). - -### 클라우드 공급자 - -Kubernetes has the concept of a Cloud Provider, which is a module which provides -an interface for managing TCP Load Balancers, Nodes (Instances) and Networking Routes. -The interface is defined in `pkg/cloudprovider/cloud.go`. It is possible to -create a custom cluster without implementing a cloud provider (for example if using -bare-metal), and not all parts of the interface need to be implemented, depending -on how flags are set on various components. - -### 노드 - -- You can use virtual or physical machines. -- While you can build a cluster with 1 machine, in order to run all the examples and tests you - need at least 4 nodes. -- Many Getting-started-guides make a distinction between the master node and regular nodes. This - is not strictly necessary. -- Nodes will need to run some version of Linux with the x86_64 architecture. It may be possible - to run on other OSes and Architectures, but this guide does not try to assist with that. -- Apiserver and etcd together are fine on a machine with 1 core and 1GB RAM for clusters with 10s of nodes. - Larger or more active clusters may benefit from more cores. -- Other nodes can have any reasonable amount of memory and any number of cores. They need not - have identical configurations. - -### 네트워크 - -#### 네트워크 연결 -Kubernetes has a distinctive [networking model](/docs/concepts/cluster-administration/networking/). - -Kubernetes allocates an IP address to each pod. When creating a cluster, you -need to allocate a block of IPs for Kubernetes to use as Pod IPs. The simplest -approach is to allocate a different block of IPs to each node in the cluster as -the node is added. A process in one pod should be able to communicate with -another pod using the IP of the second pod. This connectivity can be -accomplished in two ways: - -- **Using an overlay network** - - An overlay network obscures the underlying network architecture from the - pod network through traffic encapsulation (for example vxlan). - - Encapsulation reduces performance, though exactly how much depends on your solution. -- **Without an overlay network** - - Configure the underlying network fabric (switches, routers, etc.) to be aware of pod IP addresses. - - This does not require the encapsulation provided by an overlay, and so can achieve - better performance. - -Which method you choose depends on your environment and requirements. There are various ways -to implement one of the above options: - -- **Use a network plugin which is called by Kubernetes** - - Kubernetes supports the [CNI](https://github.com/containernetworking/cni) network plugin interface. - - There are a number of solutions which provide plugins for Kubernetes (listed alphabetically): - - [Calico](http://docs.projectcalico.org/) - - [Flannel](https://github.com/coreos/flannel) - - [Open vSwitch (OVS)](http://openvswitch.org/) - - [Romana](http://romana.io/) - - [Weave](http://weave.works/) - - [More found here](/docs/admin/networking#how-to-achieve-this/) - - You can also write your own. -- **Compile support directly into Kubernetes** - - This can be done by implementing the "Routes" interface of a Cloud Provider module. - - The Google Compute Engine ([GCE](/docs/setup/turnkey/gce/)) and [AWS](/docs/setup/turnkey/aws/) guides use this approach. -- **Configure the network external to Kubernetes** - - This can be done by manually running commands, or through a set of externally maintained scripts. - - You have to implement this yourself, but it can give you an extra degree of flexibility. - -You will need to select an address range for the Pod IPs. - -- Various approaches: - - GCE: each project has its own `10.0.0.0/8`. Carve off a `/16` for each - Kubernetes cluster from that space, which leaves room for several clusters. - Each node gets a further subdivision of this space. - - AWS: use one VPC for whole organization, carve off a chunk for each - cluster, or use different VPC for different clusters. -- Allocate one CIDR subnet for each node's PodIPs, or a single large CIDR - from which smaller CIDRs are automatically allocated to each node. - - You need max-pods-per-node * max-number-of-nodes IPs in total. A `/24` per - node supports 254 pods per machine and is a common choice. If IPs are - scarce, a `/26` (62 pods per machine) or even a `/27` (30 pods) may be sufficient. - - For example, use `10.10.0.0/16` as the range for the cluster, with up to 256 nodes - using `10.10.0.0/24` through `10.10.255.0/24`, respectively. - - Need to make these routable or connect with overlay. - -Kubernetes also allocates an IP to each [service](/docs/concepts/services-networking/service/). However, -service IPs do not necessarily need to be routable. The kube-proxy takes care -of translating Service IPs to Pod IPs before traffic leaves the node. You do -need to allocate a block of IPs for services. Call this -`SERVICE_CLUSTER_IP_RANGE`. For example, you could set -`SERVICE_CLUSTER_IP_RANGE="10.0.0.0/16"`, allowing 65534 distinct services to -be active at once. Note that you can grow the end of this range, but you -cannot move it without disrupting the services and pods that already use it. - -Also, you need to pick a static IP for master node. - -- Call this `MASTER_IP`. -- Open any firewalls to allow access to the apiserver ports 80 and/or 443. -- Enable ipv4 forwarding sysctl, `net.ipv4.ip_forward = 1` - -#### 네트워크 폴리시 - -Kubernetes enables the definition of fine-grained network policy between Pods using the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) resource. - -Not all networking providers support the Kubernetes NetworkPolicy API, see [Using Network Policy](/docs/tasks/configure-pod-container/declare-network-policy/) for more information. - -### 클러스터 이름 구성 - -You should pick a name for your cluster. Pick a short name for each cluster -which is unique from future cluster names. This will be used in several ways: - - - by kubectl to distinguish between various clusters you have access to. You will probably want a - second one sometime later, such as for testing new Kubernetes releases, running in a different -region of the world, etc. - - Kubernetes clusters can create cloud provider resources (for example, AWS ELBs) and different clusters - need to distinguish which resources each created. Call this `CLUSTER_NAME`. - -### 소프트웨어 바이너리 - -You will need binaries for: - - - etcd - - A container runner, one of: - - docker - - rkt - - Kubernetes - - kubelet - - kube-proxy - - kube-apiserver - - kube-controller-manager - - kube-scheduler - -#### 쿠버네티스 바이너리 다운로드 및 압축 해제 - -A Kubernetes binary release includes all the Kubernetes binaries as well as the supported release of etcd. -You can use a Kubernetes binary release (recommended) or build your Kubernetes binaries following the instructions in the -[Developer Documentation](https://git.k8s.io/community/contributors/devel/). Only using a binary release is covered in this guide. - -Download the [latest binary release](https://github.com/kubernetes/kubernetes/releases/latest) and unzip it. -Server binary tarballs are no longer included in the Kubernetes final tarball, so you will need to locate and run -`./kubernetes/cluster/get-kube-binaries.sh` to download and extract the client and server binaries. -Then locate `./kubernetes/server/bin`, which contains all the necessary binaries. - -#### 이미지 선택 - -You will run docker, kubelet, and kube-proxy outside of a container, the same way you would run any system daemon, so -you just need the bare binaries. For etcd, kube-apiserver, kube-controller-manager, and kube-scheduler, -we recommend that you run these as containers, so you need an image to be built. - -You have several choices for Kubernetes images: - -- Use images hosted on Google Container Registry (GCR): - - For example `k8s.gcr.io/hyperkube:$TAG`, where `TAG` is the latest - release tag, which can be found on the [latest releases page](https://github.com/kubernetes/kubernetes/releases/latest). - - Ensure $TAG is the same tag as the release tag you are using for kubelet and kube-proxy. - - The [hyperkube](https://releases.k8s.io/{{< param "githubbranch" >}}/cmd/hyperkube) binary is an all in one binary - - `hyperkube kubelet ...` runs the kubelet, `hyperkube apiserver ...` runs an apiserver, etc. -- Build your own images. - - Useful if you are using a private registry. - - The release contains files such as `./kubernetes/server/bin/kube-apiserver.tar` which - can be converted into docker images using a command like - `docker load -i kube-apiserver.tar` - - You can verify if the image is loaded successfully with the right repository and tag using - command like `docker images` - -We recommend that you use the etcd version which is provided in the Kubernetes binary distribution. The Kubernetes binaries in the release -were tested extensively with this version of etcd and not with any other version. -The recommended version number can also be found as the value of `TAG` in `kubernetes/cluster/images/etcd/Makefile`. - -For the minimum recommended version of etcd, refer to -[Configuring and Updating etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd/) - -The remainder of the document assumes that the image identifiers have been chosen and stored in corresponding env vars. Examples (replace with latest tags and appropriate registry): - - - `HYPERKUBE_IMAGE=k8s.gcr.io/hyperkube:$TAG` - - `ETCD_IMAGE=k8s.gcr.io/etcd:$ETCD_VERSION` - -### 보안 모델 - -There are two main options for security: - -- Access the apiserver using HTTP. - - Use a firewall for security. - - This is easier to setup. -- Access the apiserver using HTTPS - - Use https with certs, and credentials for user. - - This is the recommended approach. - - Configuring certs can be tricky. - -If following the HTTPS approach, you will need to prepare certs and credentials. - -#### 인증서 준비 - -You need to prepare several certs: - -- The master needs a cert to act as an HTTPS server. -- The kubelets optionally need certs to identify themselves as clients of the master, and when - serving its own API over HTTPS. - -Unless you plan to have a real CA generate your certs, you will need -to generate a root cert and use that to sign the master, kubelet, and -kubectl certs. How to do this is described in the [authentication -documentation](/docs/concepts/cluster-administration/certificates/). - -You will end up with the following files (we will use these variables later on) - -- `CA_CERT` - - put in on node where apiserver runs, for example in `/srv/kubernetes/ca.crt`. -- `MASTER_CERT` - - signed by CA_CERT - - put in on node where apiserver runs, for example in `/srv/kubernetes/server.crt` -- `MASTER_KEY ` - - put in on node where apiserver runs, for example in `/srv/kubernetes/server.key` -- `KUBELET_CERT` - - optional -- `KUBELET_KEY` - - optional - -#### 자격 증명 준비 - -The admin user (and any users) need: - - - a token or a password to identify them. - - tokens are just long alphanumeric strings, 32 chars for example. See - - `TOKEN=$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64 | tr -d "=+/[:space:]" | dd bs=32 count=1 2>/dev/null)` - -Your tokens and passwords need to be stored in a file for the apiserver -to read. This guide uses `/var/lib/kube-apiserver/known_tokens.csv`. -The format for this file is described in the [authentication documentation](/docs/reference/access-authn-authz/authentication/#static-token-file). - -For distributing credentials to clients, the convention in Kubernetes is to put the credentials -into a [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/). - -The kubeconfig file for the administrator can be created as follows: - - - If you have already used Kubernetes with a non-custom cluster (for example, used a Getting Started - Guide), you will already have a `$HOME/.kube/config` file. - - You need to add certs, keys, and the master IP to the kubeconfig file: - - If using the firewall-only security option, set the apiserver this way: - - `kubectl config set-cluster $CLUSTER_NAME --server=http://$MASTER_IP --insecure-skip-tls-verify=true` - - Otherwise, do this to set the apiserver ip, client certs, and user credentials. - - `kubectl config set-cluster $CLUSTER_NAME --certificate-authority=$CA_CERT --embed-certs=true --server=https://$MASTER_IP` - - `kubectl config set-credentials $USER --client-certificate=$CLI_CERT --client-key=$CLI_KEY --embed-certs=true --token=$TOKEN` - - Set your cluster as the default cluster to use: - - `kubectl config set-context $CONTEXT_NAME --cluster=$CLUSTER_NAME --user=$USER` - - `kubectl config use-context $CONTEXT_NAME` - -Next, make a kubeconfig file for the kubelets and kube-proxy. There are a couple of options for how -many distinct files to make: - - 1. Use the same credential as the admin - - This is simplest to setup. - 1. One token and kubeconfig file for all kubelets, one for all kube-proxy, one for admin. - - This mirrors what is done on GCE today - 1. Different credentials for every kubelet, etc. - - We are working on this but all the pieces are not ready yet. - -You can make the files by copying the `$HOME/.kube/config` or by using the following template: - -```yaml -apiVersion: v1 -kind: Config -users: -- name: kubelet - user: - token: ${KUBELET_TOKEN} -clusters: -- name: local - cluster: - certificate-authority: /srv/kubernetes/ca.crt -contexts: -- context: - cluster: local - user: kubelet - name: service-account-context -current-context: service-account-context -``` - -Put the kubeconfig(s) on every node. The examples later in this -guide assume that there are kubeconfigs in `/var/lib/kube-proxy/kubeconfig` and -`/var/lib/kubelet/kubeconfig`. - -## 노드의 기본 소프트웨어 구성 및 설치 - -This section discusses how to configure machines to be Kubernetes nodes. - -You should run three daemons on every node: - - - docker or rkt - - kubelet - - kube-proxy - -You will also need to do assorted other configuration on top of a -base OS install. - -Tip: One possible starting point is to setup a cluster using an existing Getting -Started Guide. After getting a cluster running, you can then copy the init.d scripts or systemd unit files from that -cluster, and then modify them for use on your custom cluster. - -### Docker - -The minimum required Docker version will vary as the kubelet version changes. The newest stable release is a good choice. Kubelet will log a warning and refuse to start pods if the version is too old, so pick a version and try it. - -If you previously had Docker installed on a node without setting Kubernetes-specific -options, you may have a Docker-created bridge and iptables rules. You may want to remove these -as follows before proceeding to configure Docker for Kubernetes. - -```shell -iptables -t nat -F -ip link set docker0 down -ip link delete docker0 -``` - -The way you configure docker will depend in whether you have chosen the routable-vip or overlay-network approaches for your network. -Some suggested docker options: - - - create your own bridge for the per-node CIDR ranges, call it cbr0, and set `--bridge=cbr0` option on docker. - - set `--iptables=false` so docker will not manipulate iptables for host-ports (too coarse on older docker versions, may be fixed in newer versions) -so that kube-proxy can manage iptables instead of docker. - - `--ip-masq=false` - - if you have setup PodIPs to be routable, then you want this false, otherwise, docker will - rewrite the PodIP source-address to a NodeIP. - - some environments (for example GCE) still need you to masquerade out-bound traffic when it leaves the cloud environment. This is very environment specific. - - if you are using an overlay network, consult those instructions. - - `--mtu=` - - may be required when using Flannel, because of the extra packet size due to udp encapsulation - - `--insecure-registry $CLUSTER_SUBNET` - - to connect to a private registry, if you set one up, without using SSL. - -You may want to increase the number of open files for docker: - - - `DOCKER_NOFILE=1000000` - -Where this config goes depends on your node OS. For example, GCE's Debian-based distro uses `/etc/default/docker`. - -Ensure docker is working correctly on your system before proceeding with the rest of the -installation, by following examples given in the Docker documentation. - -### rkt - -[rkt](https://github.com/coreos/rkt) is an alternative to Docker. You only need to install one of Docker or rkt. -The minimum version required is [v0.5.6](https://github.com/coreos/rkt/releases/tag/v0.5.6). - -[systemd](http://www.freedesktop.org/wiki/Software/systemd/) is required on your node to run rkt. The -minimum version required to match rkt v0.5.6 is -[systemd 215](http://lists.freedesktop.org/archives/systemd-devel/2014-July/020903.html). - -[rkt metadata service](https://github.com/coreos/rkt/blob/master/Documentation/networking/overview.md) is also required -for rkt networking support. You can start rkt metadata service by using command like -`sudo systemd-run rkt metadata-service` - -Then you need to configure your kubelet with flag: - - - `--container-runtime=rkt` - -### kubelet - -All nodes should run kubelet. See [Software Binaries](#software-binaries). - -Arguments to consider: - - - If following the HTTPS security approach: - - `--kubeconfig=/var/lib/kubelet/kubeconfig` - - Otherwise, if taking the firewall-based security approach - - `--config=/etc/kubernetes/manifests` - - `--cluster-dns=` to the address of the DNS server you will setup (see [Starting Cluster Services](#starting-cluster-services).) - - `--cluster-domain=` to the dns domain prefix to use for cluster DNS addresses. - - `--docker-root=` - - `--root-dir=` - - `--pod-cidr=` The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. - - `--register-node` (described in [Node](/docs/admin/node/) documentation.) - -### kube-proxy - -All nodes should run kube-proxy. (Running kube-proxy on a "master" node is not -strictly required, but being consistent is easier.) Obtain a binary as described for -kubelet. - -Arguments to consider: - - - If following the HTTPS security approach: - - `--master=https://$MASTER_IP` - - `--kubeconfig=/var/lib/kube-proxy/kubeconfig` - - Otherwise, if taking the firewall-based security approach - - `--master=http://$MASTER_IP` - -Note that on some Linux platforms, you may need to manually install the -`conntrack` package which is a dependency of kube-proxy, or else kube-proxy -cannot be started successfully. - -For more details about debugging kube-proxy problems, refer to -[Debug Services](/docs/tasks/debug-application-cluster/debug-service/) - -### 네트워킹 - -Each node needs to be allocated its own CIDR range for pod networking. -Call this `NODE_X_POD_CIDR`. - -A bridge called `cbr0` needs to be created on each node. The bridge is explained -further in the [networking documentation](/docs/concepts/cluster-administration/networking/). The bridge itself -needs an address from `$NODE_X_POD_CIDR` - by convention the first IP. Call -this `NODE_X_BRIDGE_ADDR`. For example, if `NODE_X_POD_CIDR` is `10.0.0.0/16`, -then `NODE_X_BRIDGE_ADDR` is `10.0.0.1/16`. NOTE: this retains the `/16` suffix -because of how this is used later. - -If you have turned off Docker's IP masquerading to allow pods to talk to each -other, then you may need to do masquerading just for destination IPs outside -the cluster network. For example: - -```shell -iptables -t nat -A POSTROUTING ! -d ${CLUSTER_SUBNET} -m addrtype ! --dst-type LOCAL -j MASQUERADE -``` - -This will rewrite the source address from -the PodIP to the Node IP for traffic bound outside the cluster, and kernel -[connection tracking](http://www.iptables.info/en/connection-state.html) -will ensure that responses destined to the node still reach -the pod. - -NOTE: This is environment specific. Some environments will not need -any masquerading at all. Others, such as GCE, will not allow pod IPs to send -traffic to the internet, but have no problem with them inside your GCE Project. - -### 기타 - -- Enable auto-upgrades for your OS package manager, if desired. -- Configure log rotation for all node components (for example using [logrotate](http://linux.die.net/man/8/logrotate)). -- Setup liveness-monitoring (for example using [supervisord](http://supervisord.org/)). -- Setup volume plugin support (optional) - - Install any client binaries for optional volume types, such as `glusterfs-client` for GlusterFS - volumes. - -### 구성 관리 사용 - -The previous steps all involved "conventional" system administration techniques for setting up -machines. You may want to use a Configuration Management system to automate the node configuration -process. There are examples of Ansible, Juju, and CoreOS Cloud Config in the -various Getting Started Guides. - -## 클러스터 부트스트랩 - -While the basic node services (kubelet, kube-proxy, docker) are typically started and managed using -traditional system administration/automation approaches, the remaining *master* components of Kubernetes are -all configured and managed *by Kubernetes*: - - - Their options are specified in a Pod spec (yaml or json) rather than an /etc/init.d file or - systemd unit. - - They are kept running by Kubernetes rather than by init. - -### etcd - -You will need to run one or more instances of etcd. - - - Highly available and easy to restore - Run 3 or 5 etcd instances with, their logs written to a directory backed - by durable storage (RAID, GCE PD) - - Not highly available, but easy to restore - Run one etcd instance, with its log written to a directory backed - by durable storage (RAID, GCE PD). - - {{< note >}}May result in operations outages in case of - instance outage. {{< /note >}} - - Highly available - Run 3 or 5 etcd instances with non durable storage. - - {{< note >}}Log can be written to non-durable storage - because storage is replicated.{{< /note >}} - -See [cluster-troubleshooting](/docs/admin/cluster-troubleshooting/) for more discussion on factors affecting cluster -availability. - -To run an etcd instance: - -1. Copy [`cluster/gce/manifests/etcd.manifest`](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/manifests/etcd.manifest) -1. Make any modifications needed -1. Start the pod by putting it into the kubelet manifest directory - -### API 서버, 컨트롤러 관리자, 스케줄러 - -The apiserver, controller manager, and scheduler will each run as a pod on the master node. - -For each of these components, the steps to start them running are similar: - -1. Start with a provided template for a pod. -1. Set the `HYPERKUBE_IMAGE` to the values chosen in [Selecting Images](#selecting-images). -1. Determine which flags are needed for your cluster, using the advice below each template. -1. Set the flags to be individual strings in the command array (for example $ARGN below) -1. Start the pod by putting the completed template into the kubelet manifest directory. -1. Verify that the pod is started. - -#### API 서버 파드 템플릿 - -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "kube-apiserver" - }, - "spec": { - "hostNetwork": true, - "containers": [ - { - "name": "kube-apiserver", - "image": "${HYPERKUBE_IMAGE}", - "command": [ - "/hyperkube", - "apiserver", - "$ARG1", - "$ARG2", - ... - "$ARGN" - ], - "ports": [ - { - "name": "https", - "hostPort": 443, - "containerPort": 443 - }, - { - "name": "local", - "hostPort": 8080, - "containerPort": 8080 - } - ], - "volumeMounts": [ - { - "name": "srvkube", - "mountPath": "/srv/kubernetes", - "readOnly": true - }, - { - "name": "etcssl", - "mountPath": "/etc/ssl", - "readOnly": true - } - ], - "livenessProbe": { - "httpGet": { - "scheme": "HTTP", - "host": "127.0.0.1", - "port": 8080, - "path": "/healthz" - }, - "initialDelaySeconds": 15, - "timeoutSeconds": 15 - } - } - ], - "volumes": [ - { - "name": "srvkube", - "hostPath": { - "path": "/srv/kubernetes" - } - }, - { - "name": "etcssl", - "hostPath": { - "path": "/etc/ssl" - } - } - ] - } -} -``` - -Here are some apiserver flags you may need to set: - -- `--cloud-provider=` see [cloud providers](#cloud-providers) -- `--cloud-config=` see [cloud providers](#cloud-providers) -- `--address=${MASTER_IP}` *or* `--bind-address=127.0.0.1` and `--address=127.0.0.1` if you want to run a proxy on the master node. -- `--service-cluster-ip-range=$SERVICE_CLUSTER_IP_RANGE` -- `--etcd-servers=http://127.0.0.1:4001` -- `--tls-cert-file=/srv/kubernetes/server.cert` -- `--tls-private-key-file=/srv/kubernetes/server.key` -- `--enable-admission-plugins=$RECOMMENDED_LIST` - - See [admission controllers](/docs/reference/access-authn-authz/admission-controllers/) for recommended arguments. -- `--allow-privileged=true`, only if you trust your cluster user to run pods as root. - -If you are following the firewall-only security approach, then use these arguments: - -- `--token-auth-file=/dev/null` -- `--insecure-bind-address=$MASTER_IP` -- `--advertise-address=$MASTER_IP` - -If you are using the HTTPS approach, then set: - -- `--client-ca-file=/srv/kubernetes/ca.crt` -- `--token-auth-file=/srv/kubernetes/known_tokens.csv` -- `--basic-auth-file=/srv/kubernetes/basic_auth.csv` - -This pod mounts several node file system directories using the `hostPath` volumes. Their purposes are: - -- The `/etc/ssl` mount allows the apiserver to find the SSL root certs so it can - authenticate external services, such as a cloud provider. - - This is not required if you do not use a cloud provider (bare-metal for example). -- The `/srv/kubernetes` mount allows the apiserver to read certs and credentials stored on the - node disk. These could instead be stored on a persistent disk, such as a GCE PD, or baked into the image. -- Optionally, you may want to mount `/var/log` as well and redirect output there (not shown in template). - - Do this if you prefer your logs to be accessible from the root filesystem with tools like journalctl. - -*TODO* document proxy-ssh setup. - -##### 클라우드 공급자 - -Apiserver supports several cloud providers. - -- options for `--cloud-provider` flag are `aws`, `azure`, `cloudstack`, `fake`, `gce`, `mesos`, `openstack`, `ovirt`, `rackspace`, `vsphere`, or unset. -- unset used for bare metal setups. -- support for new IaaS is added by contributing code [here](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/cloudprovider/providers) - -Some cloud providers require a config file. If so, you need to put config file into apiserver image or mount through hostPath. - -- `--cloud-config=` set if cloud provider requires a config file. -- Used by `aws`, `gce`, `mesos`, `openstack`, `ovirt` and `rackspace`. -- You must put config file into apiserver image or mount through hostPath. -- Cloud config file syntax is [Gcfg](https://code.google.com/p/gcfg/). -- AWS format defined by type [AWSCloudConfig](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/cloudprovider/providers/aws/aws.go) -- There is a similar type in the corresponding file for other cloud providers. - -#### 스케줄러 파드 템플릿 - -Complete this template for the scheduler pod: - -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "kube-scheduler" - }, - "spec": { - "hostNetwork": true, - "containers": [ - { - "name": "kube-scheduler", - "image": "$HYPERKUBE_IMAGE", - "command": [ - "/hyperkube", - "scheduler", - "--master=127.0.0.1:8080", - "$SCHEDULER_FLAG1", - ... - "$SCHEDULER_FLAGN" - ], - "livenessProbe": { - "httpGet": { - "scheme": "HTTP", - "host": "127.0.0.1", - "port": 10251, - "path": "/healthz" - }, - "initialDelaySeconds": 15, - "timeoutSeconds": 15 - } - } - ] - } -} -``` - -Typically, no additional flags are required for the scheduler. - -Optionally, you may want to mount `/var/log` as well and redirect output there. - -#### 컨트롤러 관리자 템플릿 - -Template for controller manager pod: - -```json -{ - "kind": "Pod", - "apiVersion": "v1", - "metadata": { - "name": "kube-controller-manager" - }, - "spec": { - "hostNetwork": true, - "containers": [ - { - "name": "kube-controller-manager", - "image": "$HYPERKUBE_IMAGE", - "command": [ - "/hyperkube", - "controller-manager", - "$CNTRLMNGR_FLAG1", - ... - "$CNTRLMNGR_FLAGN" - ], - "volumeMounts": [ - { - "name": "srvkube", - "mountPath": "/srv/kubernetes", - "readOnly": true - }, - { - "name": "etcssl", - "mountPath": "/etc/ssl", - "readOnly": true - } - ], - "livenessProbe": { - "httpGet": { - "scheme": "HTTP", - "host": "127.0.0.1", - "port": 10252, - "path": "/healthz" - }, - "initialDelaySeconds": 15, - "timeoutSeconds": 15 - } - } - ], - "volumes": [ - { - "name": "srvkube", - "hostPath": { - "path": "/srv/kubernetes" - } - }, - { - "name": "etcssl", - "hostPath": { - "path": "/etc/ssl" - } - } - ] - } -} -``` - -Flags to consider using with controller manager: - - - `--cluster-cidr=`, the CIDR range for pods in cluster. - - `--allocate-node-cidrs=`, if you are using `--cloud-provider=`, allocate and set the CIDRs for pods on the cloud provider. - - `--cloud-provider=` and `--cloud-config` as described in apiserver section. - - `--service-account-private-key-file=/srv/kubernetes/server.key`, used by the [service account](/docs/user-guide/service-accounts) feature. - - `--master=127.0.0.1:8080` - -#### API 서버, 스케줄러, 컨트롤러 관리자 시작 및 확인 - -Place each completed pod template into the kubelet config dir -(whatever `--config=` argument of kubelet is set to, typically -`/etc/kubernetes/manifests`). The order does not matter: scheduler and -controller manager will retry reaching the apiserver until it is up. - -Use `ps` or `docker ps` to verify that each process has started. For example, verify that kubelet has started a container for the apiserver like this: - -```shell -$ sudo docker ps | grep apiserver -5783290746d5 k8s.gcr.io/kube-apiserver:e36bf367342b5a80d7467fd7611ad873 "/bin/sh -c '/usr/lo'" 10 seconds ago Up 9 seconds k8s_kube-apiserver.feb145e7_kube-apiserver-kubernetes-master_default_eaebc600cf80dae59902b44225f2fc0a_225a4695 -``` - -Then try to connect to the apiserver: - -```shell -$ echo $(curl -s http://localhost:8080/healthz) -ok -$ curl -s http://localhost:8080/api -{ - "versions": [ - "v1" - ] -} -``` - -If you have selected the `--register-node=true` option for kubelets, they will now begin self-registering with the apiserver. -You should soon be able to see all your nodes by running the `kubectl get nodes` command. -Otherwise, you will need to manually create node objects. - -### 클러스터 서비스 시작 - -You will want to complete your Kubernetes clusters by adding cluster-wide -services. These are sometimes called *addons*, and [an overview -of their purpose is in the admin guide](/docs/admin/cluster-components/#addons). - -Notes for setting up each cluster service are given below: - -* Cluster DNS: - * Required for many Kubernetes examples - * [Setup instructions](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) - * [Admin Guide](/docs/concepts/services-networking/dns-pod-service/) -* Cluster-level Logging - * [Cluster-level Logging Overview](/docs/user-guide/logging/overview/) - * [Cluster-level Logging with Elasticsearch](/docs/user-guide/logging/elasticsearch/) - * [Cluster-level Logging with Stackdriver Logging](/docs/user-guide/logging/stackdriver/) -* Container Resource Monitoring - * [Setup instructions](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/cluster-monitoring/) -* GUI - * [Setup instructions](https://github.com/kubernetes/dashboard) - -## 문제 해결 - -### validate-cluster 명령 실행 - -`cluster/validate-cluster.sh` is used by `cluster/kube-up.sh` to determine if -the cluster start succeeded. - -Example usage and output: - -```shell -KUBECTL_PATH=$(which kubectl) NUM_NODES=3 KUBERNETES_PROVIDER=local cluster/validate-cluster.sh -Found 3 node(s). -NAME STATUS AGE VERSION -node1.local Ready 1h v1.6.9+a3d1dfa6f4335 -node2.local Ready 1h v1.6.9+a3d1dfa6f4335 -node3.local Ready 1h v1.6.9+a3d1dfa6f4335 -Validate output: -NAME STATUS MESSAGE ERROR -controller-manager Healthy ok -scheduler Healthy ok -etcd-1 Healthy {"health": "true"} -etcd-2 Healthy {"health": "true"} -etcd-0 Healthy {"health": "true"} -Cluster validation succeeded -``` - -### 파드와 서비스 검사 - -Try to run through the "Inspect your cluster" section in one of the other Getting Started Guides, such as [GCE](/docs/setup/turnkey/gce/#inspect-your-cluster). -You should see some services. You should also see "mirror pods" for the apiserver, scheduler and controller-manager, plus any add-ons you started. - -### 예제 실행하기 - -At this point you should be able to run through one of the basic examples, such as the [nginx example](/examples/application/deployment.yaml). - -### 적합성 테스트 실행 - -You may want to try to run the [Conformance test](http://releases.k8s.io/{{< param "githubbranch" >}}/test/e2e_node/conformance/run_test.sh). Any failures may give a hint as to areas that need more attention. - -### 네트워킹 - -The nodes must be able to connect to each other using their private IP. Verify this by -pinging or SSH-ing from one node to another. - -### 도움말 얻기 - -If you run into trouble, see the section on [troubleshooting](/docs/setup/turnkey/gce/#troubleshooting), post to the -[Kubernetes Forum](https://discuss.kubernetes.io), or come ask questions on [Slack](/docs/troubleshooting#slack). - -## 지원 레벨 - - -IaaS Provider | Config. Mgmt | OS | Networking | Docs | Conforms | Support Level --------------------- | ------------ | ------ | ---------- | --------------------------------------------- | ---------| ---------------------------- -any | any | any | any | [docs](/docs/getting-started-guides/scratch/) | | Community ([@erictune](https://github.com/erictune)) - - -For support level information on all solutions, see the [Table of solutions](/docs/getting-started-guides/#table-of-solutions/) chart. diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md new file mode 100755 index 0000000000..4cb552677c --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/_index.md @@ -0,0 +1,5 @@ +--- +title: "클러스터 내 어플리케이션 액세스" +weight: 60 +--- + diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md new file mode 100644 index 0000000000..20fc8a7f22 --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -0,0 +1,372 @@ +--- +title: 클러스터 액세스 +weight: 20 +content_template: templates/concept +--- + +{{% capture overview %}} + +여기에서는 클러스터와 통신을 하는 다양한 방식에 대해서 다룰 것이다. + +{{% /capture %}} + + +{{% capture body %}} + +## 처음이라면 kubectl을 사용하여 액세스 + +최초로 쿠버네티스 API에 액세스할 때 우리는 +쿠버네티스 CLI인 `kubectl`을 사용하는 것을 추천한다. + +클러스터에 액세스하려면 클러스터의 위치정보를 알아야 하고 클러스터에 접속하기 위한 +인증정보를 가져야 한다. 일반적으로 이는 당신이 +[Getting started guide](/docs/setup/)를 다 진행했을 때 자동으로 구성되거나, +다른 사람이 클러스터를 구성하고 당신에게 인증정보와 위치정보를 제공할 수도 있다. + +kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확인한다. + +```shell +kubectl config view +``` + +많은 [예제들](/docs/user-guide/kubectl-cheatsheet)에서 kubectl을 사용하는 것을 소개하고 있으며 +완전한 문서는 [kubectl manual](/docs/user-guide/kubectl-overview)에서 찾아볼 수 있다. + +## REST API에 직접 액세스 + +kubectl은 apiserver의 위치 파악과 인증을 처리한다. +만약 당신이 curl, wget 또는 웹브라우저와 같은 http 클라이언트로 +REST API에 직접 액세스하려고 한다면 위치 파악과 인증을 하는 몇 가지 방법이 존재한다. + + - kubectl을 proxy 모드로 실행. + - 권장하는 접근 방식. + - 저장된 apiserver 위치를 사용. + - self-signed 인증서를 사용하여 apiserver의 identity를 검증. MITM은 불가능. + - apiserver 인증. + - 앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다. + - 직접적으로 http 클라이언트에 위치정보와 인증정보를 제공. + - 대안적인 접근 방식. + - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 code들과 같이 동작한다. + - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 import해야 한다. + +### kubectl proxy 사용 + +다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 +apiserver의 위치지정과 인증을 처리한다. +다음과 같이 실행한다. + +```shell +kubectl proxy --port=8080 +``` + +상세 내용은 [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands/#proxy)를 참조한다 + +이후에 당신은 curl, wget, 웹브라우저로 다음과 같이 API를 탐색할 수 있다. localhost는 +IPv6 주소 [::1]로도 대체할 수 있다. + +```shell +curl http://localhost:8080/api/ +``` + +결과값은 다음과 같을 것이다. + +```json +{ + "versions": [ + "v1" + ] +} +``` + + +### kubectl proxy를 사용하지 않음 + +기본 서비스 어카운트의 토큰을 얻어내려면 `kubectl describe secret...`을 grep/cut과 함께 사용한다. + +```shell +APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ") +SECRET_NAME=$(kubectl get secrets | grep ^default | cut -f1 -d ' ') +TOKEN=$(kubectl describe secret $SECRET_NAME | grep -E '^token' | cut -f2 -d':' | tr -d " ") + +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +결과값은 다음과 같을 것이다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +`jsonpath`를 사용한다면 다음과 같다. + +```shell +APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}') +SECRET_NAME=$(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') +TOKEN=$(kubectl get secret $SECRET_NAME -o jsonpath='{.data.token}' | base64 --decode) + +curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure +``` + +결과값은 다음과 같을 것이다. + +```json +{ + "kind": "APIVersions", + "versions": [ + "v1" + ], + "serverAddressByClientCIDRs": [ + { + "clientCIDR": "0.0.0.0/0", + "serverAddress": "10.0.1.149:443" + } + ] +} +``` + +위 예제에서는 `--insecure` flag를 사용했다. 이는 MITM 공격을 받을 수 있는 상태로 +두는 것이다. kubectl로 클러스터에 접속할 때 저장된 root 인증서와 클라이언트 인증서들을 +서버 접속에 사용한다. +(이들은 `~/.kube` 디렉토리에 설치된다.) +일반적으로 self-signed 인증서가 클러스터 인증서로 사용되므로 당신의 http 클라이언트가 +root 인증서를 사용하려면 특수한 설정을 필요로 할 것이다. + +localhost에서 제공되거나 방화벽으로 보호되는 몇몇 클러스터들에서는 apiserver가 인증을 +요구하지 않지만 이는 표준이 아니다. +[Configuring Access to the API](/docs/reference/access-authn-authz/controlling-access/) +는 클러스터 관리자가 이를 어떻게 구성할 수 있는지를 설명한다. +이 방식들은 미래의 고가용성 지원과 충돌될 수 있다. + +## API에 프로그래밍 방식으로 액세스 + +쿠버네티스는 공식적으로 [Go](#go-클라이언트)와 [Python](#python-클라이언트) +클라이언트 라이브러리를 지원한다. + +### Go 클라이언트 + +* 라이브러리를 취득하려면 `go get k8s.io/client-go//kubernetes` 커맨드를 실행한다. [INSTALL.md](https://github.com/kubernetes/client-go/blob/master/INSTALL.md#for-the-casual-user)에서 상세한 설치 방법을 알 수 있다. [https://github.com/kubernetes/client-go](https://github.com/kubernetes/client-go#compatibility-matrix)에서 어떤 버젼이 지원되는지 확인할 수 있다. +* client-go 클라이언트 위에 애플리케이션을 작성하자. client-go는 자체적으로 API 오브젝트를 정의하므로 필요하다면 main 레포지터리보다는 client-go에서 API 정의들을 import하기를 바란다. 정확하게 import "k8s.io/client-go/1.4/pkg/api/v1"로 import하는 것을 예로 들 수 있다. + +Go 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +[예제](https://git.k8s.io/client-go/examples/out-of-cluster-client-configuration/main.go)를 참고한다. + +만약 애플리케이션이 클러스터 내에 파드로 배포되었다면 [다음 장](#파드에서-api-액세스)을 참조하기를 바란다. + +### Python 클라이언트 + +Python 클라이언트를 사용하려면 `pip install kubernetes` 커맨드를 실행한다. 설치 옵션에 대한 상세 사항은 [Python Client Library page](https://github.com/kubernetes-client/python)를 참조한다. + +Python 클라이언트는 apiserver의 위치지정과 인증에 kubectl CLI와 동일하게 [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/)을 사용할 수 있다. +[예제](https://github.com/kubernetes-client/python/tree/master/examples/example1.py)를 참조한다. + +### 다른 언어 + +다른 언어에서 API를 접속하기 위한 [클라이언트 라이브러리들](/docs/reference/using-api/client-libraries/)도 존재한다. +이들이 어떻게 인증하는지는 다른 라이브러리들의 문서를 참조한다. + +## 파드에서 API 액세스 + +파드에서 API를 접속한다면 apiserver의 +위치지정과 인증은 다소 다르다. + +파드 내에서 apiserver의 위치를 지정하는데 추천하는 방식은 +`kubernetes.default.svc` DNS 네임을 사용하는 것이다. +이 DNS 네임은 apiserver로 라우팅되는 서비스 IP로 resolve된다. + +apiserver 인증에 추천되는 방식은 +[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/) +인증정보를 사용하는 것이다. kube-system에 의해 파드는 서비스 어카운트와 연계되며 +해당 서비스 어카운트의 인증정보(토큰)은 파드 내 각 컨테이너의 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/token`에 위치한다. + +사용 가능한 경우, 인증서 번들은 각 컨테이너 내 파일시스템 트리의 +`/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`에 위치하며 +apiserver의 인증서 제공을 검증하는데 사용되어야 한다. + +마지막으로 네임스페이스 한정의 API 조작에 사용되는 기본 네임스페이스는 각 컨테이터 내의 +`/var/run/secrets/kubernetes.io/serviceaccount/namespace` 파일로 존재한다. + +파드 내에서 API에 접근하는데 권장되는 방식은 다음과 같다. + + - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, + 컨테이너 내부에서 백그라운드 프로세스로 실행한다. + 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 + 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. + - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. + 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) + +각각의 사례에서 apiserver와의 보안 통신에 파드의 인증정보가 사용된다. + +## 클러스터에서 실행되는 서비스로 액세스 + +이전 장은 쿠버네티스 API server 접속에 대한 내용들을 다루었다. 이번 장은 +쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 +[노드들](/docs/admin/node), [파드들](/docs/user-guide/pods), [서비스들](/docs/user-guide/services)은 +모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 +할 수 없을 것이다. + +### 통신을 위한 방식들 + +클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는데는 몇 가지 선택지들이 있다. + + - 공인 IP를 통해 서비스에 액세스. + - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 + 서비스를 사용한다. [서비스](/docs/user-guide/services)와 + [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. + - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출시키거나 + 인터넷으로 노출시킬 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + 해당 서비스는 자체적으로 인증을 수행하는가? + - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 + 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. + - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 + 액세스할 필요는 없다. + - Proxy Verb를 사용하여 서비스, 노드, 파드에 액세스. + - 원격 서비스에 액세스하기에 앞서 apiserver의 인증과 인가를 받아야 한다. + 서비스가 인터넷에 노출시키기에 보안이 충분하지 않거나 노드 IP 상의 port에 + 액세스를 취득하려고 하거나 debugging을 하려면 이를 사용한다. + - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. + - HTTP/HTTPS에서만 동작한다. + - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. + - 클러스터 내 노드 또는 파드에서 액세스. + - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. + 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. + - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 + 클러스터 서비스에 액세스도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 + 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. + +### 빌트인 서비스들의 발견 + +일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. +`kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다. + +```shell +kubectl cluster-info +``` + +결과값은 다음과 같을 것이다. + +``` +Kubernetes master is running at https://104.197.5.247 +elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy +kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy +kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy +grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +``` + +이는 각 서비스에 액세스하기 위한 proxy-verb URL을 보여준다. +예를 들어 위 클러스터는 클러스터 수준의 logging(Elasticsearch 사용)이 활성화되었으므로 적절한 인증을 통과하여 +`https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`로 액세스할 수 있다. 예를 들어 kubectl proxy로 +`http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`를 통해 logging에 액세스할 수도 있다. +(인증을 통과하는 방법이나 kubectl proxy를 사용하는 것은 [위 내용](#rest-api에-직접-액세스)을 참조한다.) + +#### 수작업으로 apiserver proxy URL을 구축 + +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 단순하게 해당 서비스에 +`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. + +당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. + +기본적으로 API server는 http를 사용하여 서비스를 proxy한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. +`http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` + +URL의 네임 부분에 지원되는 양식은 다음과 같다. + +* `` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다 +* `:` - http를 사용하여 지정된 port로 proxy한다 +* `https::` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의) +* `https::` - https를 사용하여 지정된 port로 proxy한다 + +##### 예제들 + + * Elasticsearch 서비스 endpoint `_search?q=user:kimchy`에 액세스하려면 `http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy`를 사용할 수 있다. + * Elasticsearch 클러스터 상태 정보 `_cluster/health?pretty=true`에 액세스하려면 `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true`를 사용할 수 있다. + +```json +{ + "cluster_name" : "kubernetes_logging", + "status" : "yellow", + "timed_out" : false, + "number_of_nodes" : 1, + "number_of_data_nodes" : 1, + "active_primary_shards" : 5, + "active_shards" : 5, + "relocating_shards" : 0, + "initializing_shards" : 0, + "unassigned_shards" : 5 +} +``` + +### 클러스터 상에서 실행되는 서비스에 웹브라우저를 사용하여 액세스 + +브라우저의 주소창에 apiserver proxy url을 넣을 수도 있다. 하지만 + + - 웹브라우저는 일반적으로 토큰을 전달할 수 없으므로 basic (password) auth를 사용해야 할 것이다. basic auth를 수용할 수 있도록 apiserver를 구성할 수 있지만, + 당신의 클러스터가 basic auth를 수용할 수 있도록 구성되어 있지 않을 수도 있다. + - 몇몇 web app은 동작하지 않을 수도 있다. 특히 proxy path prefix를 인식하지 않는 방식으로 url을 + 구성하는 client side javascript를 가진 web app은 동작되지 않을 수 있다. + +## 요청 redirect + +redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy를 사용하기를 바란다. + +## 다양한 Proxy들 + +쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다. + +1. [kubectl proxy](#rest-api에-직접-액세스): + + - 사용자의 데스크탑이나 파드 내에서 실행한다 + - localhost 주소에서 쿠버네티스 apiserver로 proxy한다 + - proxy하는 클라이언트는 HTTP를 사용한다 + - apiserver의 proxy는 HTTPS를 사용한다 + - apiserver를 위치지정한다 + - 인증 header들을 추가한다 + +1. [apiserver proxy](#빌트인-서비스들의-발견): + + - apiserver 내의 빌트인 bastion이다 + - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP들로 연결한다 + - apiserver process들 내에서 실행된다 + - proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) + - 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 + - 노드, 파드, 서비스에 접근하는데 사용될 수 있다 + - 서비스에 접근하는데 사용되면 load balacing한다 + +1. [kube proxy](/docs/concepts/services-networking/service/#ips-and-vips): + + - 각 노드 상에서 실행된다 + - UDP와 TCP를 proxy한다 + - HTTP를 인지하지 않는다 + - load balancing을 제공한다 + - 서비스에 접근하는데만 사용된다 + +1. apiserver(s) 전면의 Proxy/Load-balancer: + + - 존재내용과 구현사항은 클러스터 별로 다양하다(예. nginx) + - 모든 클라이언트와 하나 이상의 apiserver들의 사이에 위치한다 + - apiserver가 여러 대 존재한다면 load balancer로 동작한다 + +1. 외부 서비스의 Cloud Load Balancer들: + + - Cloud provider들에 의해서 제공된다(예. AWS ELB, Google Cloud Load Balancer) + - 쿠버네티스 서비스의 타입이 `LoadBalancer`라면 자동으로 생성된다 + - UDP/TCP 만 사용한다 + - cloud provider마다 구현된 내용이 상이하다 + +일반적으로 쿠버네티스 사용자들은 처음 두 타입이 아닌 다른 방식은 고려할 필요가 없지만 클러스터 관리자는 +나머지 타입을 적절하게 구성해줘야 한다. + +{{% /capture %}} diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 61884a8829..165e49ffab 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -52,7 +52,9 @@ index.php는 CPU 과부하 연산을 수행한다. 첫 번째 단계로, 실행 중인 이미지의 디플로이먼트를 시작하고 서비스로 노출시킨다. ```shell -$ kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 +kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80 +``` +``` service/php-apache created deployment.apps/php-apache created ``` @@ -63,13 +65,18 @@ deployment.apps/php-apache created 간단히 얘기하면, HPA는 (디플로이먼트를 통한) 평균 CPU 사용량을 50%로 유지하기 위하여 레플리카의 개수를 늘리고 줄인다. ([kubectl run](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/docs/user-guide/kubectl/kubectl_run.md)으로 각 파드는 200 밀리코어까지 요청할 수 있고, 따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다.) 이에 대한 자세한 알고리즘은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#autoscaling-algorithm)를 참고하기 바란다. ```shell -$ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 +kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10 +``` +``` horizontalpodautoscaler.autoscaling/php-apache autoscaled ``` 실행 중인 오토스케일러의 현재 상태를 확인해본다. + ```shell -$ kubectl get hpa +kubectl get hpa +``` +``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 18s @@ -83,17 +90,19 @@ php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 ```shell -$ kubectl run -i --tty load-generator --image=busybox /bin/sh +kubectl run -i --tty load-generator --image=busybox /bin/sh Hit enter for command prompt -$ while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done +while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done ``` 실행 후, 약 1분 정도 후에 CPU 부하가 올라가는 것을 볼 수 있다. ```shell -$ kubectl get hpa +kubectl get hpa +``` +``` NAME REFERENCE TARGET CURRENT MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 1 3m @@ -102,7 +111,9 @@ php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 CPU 소비가 305%까지 증가하였다. 결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. ```shell -$ kubectl get deployment php-apache +kubectl get deployment php-apache +``` +``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE php-apache 7 7 7 7 19m ``` @@ -117,11 +128,17 @@ php-apache 7 7 7 7 19m `busybox` 컨테이너를 띄운 터미널에서, ` + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다. ```shell -$ kubectl get hpa +kubectl get hpa +``` +``` NAME REFERENCE TARGET MINPODS MAXPODS REPLICAS AGE php-apache Deployment/php-apache/scale 0% / 50% 1 10 1 11m +``` -$ kubectl get deployment php-apache +```shell +kubectl get deployment php-apache +``` +``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE php-apache 1 1 1 1 27m ``` @@ -143,7 +160,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. ```shell -$ kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml +kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml ``` 에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다. @@ -332,7 +349,9 @@ HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, Horizon 이 조건은 `status.conditions`에 나타난다. HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다. ```shell -$ kubectl describe hpa cm-test +kubectl describe hpa cm-test +``` +```shell Name: cm-test Namespace: prom Labels: @@ -370,7 +389,9 @@ HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 다음 명령어를 실행하여 오토스케일러를 생성할 것이다. ```shell -$ kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml +kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml +``` +``` horizontalpodautoscaler.autoscaling/php-apache created ``` diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 038851b475..f4bc36e49b 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -115,4 +115,19 @@ Windows에 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`]( {{% /capture %}} +## 새롭게 시작하기 위해 모두 정리하기 +이전에 minikube를 설치한 적이 있다면, 실행한다. +```shell +minikube start +``` + +이 커맨드는 에러를 리턴한다. +```shell +machine does not exist +``` + +구성 파일을 삭제해야 한다. +```shell +rm -rf ~/.minikube +``` diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 3fb49affb1..cd772dd93d 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -40,7 +40,7 @@ content_template: templates/concept ## 상태 유지가 필요한(stateful) 애플리케이션 -* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/) +* [스테이트풀셋 기본](/docs/tutorials/stateful-application/basic-stateful-set/) * [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index bc72f718a4..a7f8e8bfec 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -36,8 +36,8 @@ weight: 10

애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링한다. 인스턴스를 구동 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를 - 교체시켜준다. 이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 - 제공한다.

+ 클러스터 내부의 다른 노드의 인스턴스로 교체시켜준다.이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘을 + 제공한다.

오케스트레이션 기능이 없던 환경에서는, 설치 스크립트가 애플리케이션을 시작하는데 종종 사용되곤 했지만, 머신의 장애가 발생한 경우 복구를 해주지는 않았다. 쿠버네티스 디플로이먼트는 애플리케이션 diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html index ff14825a38..74c2b73781 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -26,10 +26,9 @@ weight: 10

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

- -

지난 모듈에서 디플로이먼트, - 를 만들고 서비스를 + +

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

diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md index d2e9da7f48..0e966a268c 100644 --- a/content/ko/docs/tutorials/online-training/overview.md +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -11,7 +11,7 @@ content_template: templates/concept {{% capture body %}} -* [Certified Kubernetes Administrator 준비 과정 (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course) +* [Certified Kubernetes Administrator 준비 과정 (Linux Academy)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course) * [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course) @@ -21,6 +21,8 @@ content_template: templates/concept * [쿠버네티스 시작하기 (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes) +* [Getting Started with Kubernetes Clusters on OCI Oracle Kubernetes Engine (OKE) (Learning Library)](https://apexapps.oracle.com/pls/apex/f?p=44785:50:0:::50:P50_EVENT_ID,P50_COURSE_ID:5935,256) + * [쿠버네티스 소개 및 실습 (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) * [IBM 클라우드: 쿠버네티스로 마이크로서비스(Microservices) 배포 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud) @@ -33,7 +35,7 @@ content_template: templates/concept * [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start) -* [쿠버네티스 심화 학습 (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) +* [쿠버네티스 심화 학습 (Linux Academy)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way) * [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/) @@ -42,5 +44,4 @@ content_template: templates/concept * [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) * [Self-paced Kubernetes online course (Learnk8s Academy)](https://learnk8s.io/academy) - {{% /capture %}} diff --git a/content/ko/docs/tutorials/stateful-application/_index.md b/content/ko/docs/tutorials/stateful-application/_index.md new file mode 100644 index 0000000000..bd04a2061f --- /dev/null +++ b/content/ko/docs/tutorials/stateful-application/_index.md @@ -0,0 +1,5 @@ +--- +title: "상태 유지가 필요한(stateful) 애플리케이션" +weight: 50 +--- + diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index 4c80d9c805..bfe22aa5d6 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -67,11 +67,11 @@ kubectl get pods -w -l app=nginx ``` 두번째 터미널에서 -[`kubectl create`](/docs/reference/generated/kubectl/kubectl-commands/#create)로 +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)로 `web.yaml`에 정의된 헤드리스 서비스와 스테이트풀셋을 생성한다. ```shell -kubectl create -f web.yaml +kubectl apply -f web.yaml service/nginx created statefulset.apps/web created ``` @@ -154,7 +154,7 @@ web-1 확인할 수 있다. ```shell -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -212,7 +212,7 @@ for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done web-0 web-1 -kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh +kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm /bin/sh nslookup web-0.nginx Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -774,7 +774,7 @@ kubectl get pods -w -l app=nginx 볼 것이라는 것을 명심하자. ```shell -kubectl create -f web.yaml +kubectl apply -f web.yaml statefulset.apps/web created Error from server (AlreadyExists): error when creating "web.yaml": services "nginx" already exists ``` @@ -874,7 +874,7 @@ service "nginx" deleted 스테이트풀셋과 헤드리스 서비스를 한번 더 다시 생성하자. ```shell -kubectl create -f web.yaml +kubectl apply -f web.yaml service/nginx created statefulset.apps/web created ``` @@ -938,7 +938,7 @@ kubectl get po -l app=nginx -w 다른 터미널에서 매니페스트 안에 스테이트풀셋과 서비스를 생성하자. ```shell -kubectl create -f web-parallel.yaml +kubectl apply -f web-parallel.yaml service/nginx created statefulset.apps/web created ``` diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md new file mode 100644 index 0000000000..2677499cf1 --- /dev/null +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -0,0 +1,258 @@ +--- +title: "예시: 카산드라를 스테이트풀셋으로 배포하기" +reviewers: +content_template: templates/tutorial +weight: 30 +--- + +{{% capture overview %}} +이 튜토리얼은 네이티브 클라우드 [카산드라](http://cassandra.apache.org/)를 쿠버네티스에서 배포하는 방법을 소개한다. 이 예제에서 커스텀 카산드라 *시드 제공자(SeedProvider)* 는 카산드라가 클러스터에 조인한 새 카산드라 노드를 발견할 수 있게 한다. + +*스테이트풀셋* 은 상태있는 애플리케이션을 클러스터 환경에서 쉽게 배포할 수 있게 한다. 이 튜토리얼에서 이용할 기능의 자세한 정보는 [*스테이트풀셋*](/docs/concepts/workloads/controllers/statefulset/) 문서를 참조하자. + +**도커에서 카산드라** + +이 튜토리얼의 *파드* 는 구글의 [컨테이너 레지스트리](https://cloud.google.com/container-registry/docs/)에 +[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) 이미지를 이용한다. +이 도커 이미지는 [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)에 +기반하였고 OpenJDK 8을 포함한다. + +이 이미지는 아파치 데비안 리포의 표준 카산드라 설치본을 포함한다. +환경변수를 이용하여 `cassandra.yaml`에 삽입된 값을 바꿀 수 있다. + +| 환경 변수 | 기본값 | +| ------------- |:-------------: | +| `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` | +| `CASSANDRA_NUM_TOKENS` | `32` | +| `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | + +{{% /capture %}} + +{{% capture objectives %}} +* 카산드라 헤드리스 [*서비스*](/docs/concepts/services-networking/service/)를 생성하고 검증한다. +* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 이용하여 카산드라 링을 생성한다. +* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 검증한다. +* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)을 수정한다. +* [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)과 포함된 [파드](/docs/concepts/workloads/pods/pod/)를 삭제한다. +{{% /capture %}} + +{{% capture prerequisites %}} +이 튜토리얼을 완료하려면, [파드](/docs/concepts/workloads/pods/pod/), [서비스](/docs/concepts/services-networking/service/), [스테이트풀셋](/docs/concepts/workloads/controllers/statefulset/)의 기본 개념에 친숙해야한다. 추가로 + +* *kubectl* 커맨드라인 도구를 [설치와 설정](/docs/tasks/tools/install-kubectl/)하자. + +* [`cassandra-service.yaml`](/examples/application/cassandra/cassandra-service.yaml)와 + [`cassandra-statefulset.yaml`](/examples/application/cassandra/cassandra-statefulset.yaml)를 다운로드한다. + +* 실행 중인 쿠버네티스 클러스터를 소유 + +{{< note >}} +아직 클러스터가 없다면 [시작하기](/docs/setup/pick-right-solution/)를 읽도록 하자. +{{< /note >}} + +### 추가적인 Minikube 설정 요령 + +{{< caution >}} +[Minikube](/docs/getting-started-guides/minikube/)는 1024MB 메모리와 1개 CPU가 기본 설정이다. 이 튜토리얼에서 Minikube를 기본 리소스 설정으로 실행하면 리소스 부족 오류가 발생한다. 이런 오류를 피하려면 Minikube를 다음 설정으로 실행하자. + +```shell +minikube start --memory 5120 --cpus=4 +``` +{{< /caution >}} + +{{% /capture %}} + +{{% capture lessoncontent %}} +## 카산드라 헤드리스 서비스 생성하기 + +쿠버네티스 [서비스](/docs/concepts/services-networking/service/)는 동일 작업을 수행하는 [파드](/docs/concepts/workloads/pods/pod/)의 집합을 기술한다. + +다음의 `서비스`는 쿠버네티스 클러스터에서 카산드라 파드와 클라이언트 간에 DNS 찾아보기 용도로 사용한다. + +{{< codenew file="application/cassandra/cassandra-service.yaml" >}} + +1. 다운로드 받은 매니페스트 파일 디렉터리에 터미널 윈도우를 열자. +1. `cassandra-service.yaml` 파일에서 카산드라 스테이트풀셋 노드를 모두 추적하는 서비스를 생성한다. + + ```shell + kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml + ``` + +### 검증하기 (선택) + +카산드라 서비스 살펴보기 + +```shell +kubectl get svc cassandra +``` + +결과는 다음과 같다. + +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +cassandra ClusterIP None 9042/TCP 45s +``` + +이와 다른 응답이라면 서비스 생성에 실패한 것이다. 일반적인 문제에 대한 [서비스 디버깅하기](/docs/tasks/debug-application-cluster/debug-service/)를 읽어보자. + +## 카산드라 링을 생성하는 스테이트풀셋 이용하기 + +스테이트풀셋 매니페스트에는 다음을 포함하는데 3개 파드로 구성된 카산드라 링을 생성한다. + +{{< note >}} +이 예는 Minikube를 위한 기본 프로비저너이다. 다음 스테이트풀셋을 작업하는 클라우드 환경에서 갱신한다. +{{< /note >}} + +{{< codenew file="application/cassandra/cassandra-statefulset.yaml" >}} + +1. 필요하면 스테이트풀셋 갱신 +1. `cassandra-statefulset.yaml` 파일로 카산드라 스테이트풀셋 생성 + + ```shell + kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml + ``` + +## 카산드라 스테이트풀셋 검증하기 + +1. 카산드라 스테이트풀셋 얻기 + + ```shell + kubectl get statefulset cassandra + ``` + + 응답은 다음과 같다. + + ``` + NAME DESIRED CURRENT AGE + cassandra 3 0 13s + ``` + + `StatefulSet`리소스는 순차적으로 파드를 배포한다. + +1. 순차적으로 생성된 현황을 보기 위해 파드를 살펴보자. + + ```shell + kubectl get pods -l="app=cassandra" + ``` + + 응답은 다음과 같다. + + ```shell + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 1m + cassandra-1 0/1 ContainerCreating 0 8s + ``` + + 모든 3개 파드가 배포되기까지 몇 분이 소요될 수 있다. 배포 후에는 같은 명령은 다음같이 응답한다. + + ``` + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 10m + cassandra-1 1/1 Running 0 9m + cassandra-2 1/1 Running 0 8m + ``` + +3. 링의 상태를 보여주는 카산드라 [nodetool](https://wiki.apache.org/cassandra/NodeTool)을 실행하자. + + ```shell + kubectl exec -it cassandra-0 -- nodetool status + ``` + + 이 응답은 다음과 비슷하게 보일 것이다. + + ``` + Datacenter: DC1-K8Demo + ====================== + Status=Up/Down + |/ State=Normal/Leaving/Joining/Moving + -- Address Load Tokens Owns (effective) Host ID Rack + UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo + UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo + UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo + ``` + +## 카산드라 스테이트풀셋 수정하기 + +`kubectl edit`를 사용하여 카산드라 스테이트풀셋의 크기를 수정한다. + +1. 다음 명령어를 실행한다. + + ```shell + kubectl edit statefulset cassandra + ``` + + 이 명령은 터미널에서 편집기를 연다. 변경해야할 행은 `replicas` 필드이다. 다음 예제는 `StatefulSet` 파일에서 발췌했다. + + ```yaml + # Please edit the object below. Lines beginning with a '#' will be ignored, + # and an empty file will abort the edit. If an error occurs while saving this file will be + # reopened with the relevant failures. + # + apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 + kind: StatefulSet + metadata: + creationTimestamp: 2016-08-13T18:40:58Z + generation: 1 + labels: + app: cassandra + name: cassandra + namespace: default + resourceVersion: "323" + selfLink: /apis/apps/v1/namespaces/default/statefulsets/cassandra + uid: 7a219483-6185-11e6-a910-42010a8a0fc0 + spec: + replicas: 3 + ``` + +1. 레플리카 개수를 4로 바꾸고, 매니페스트를 저장한다. + + The `StatefulSet` now contains 4 Pods. + +1. 검증하기 위해 카산드라 스테이트풀셋을 살펴보자 + + ```shell + kubectl get statefulset cassandra + ``` + + 결과는 다음과 같다. + + ``` + NAME DESIRED CURRENT AGE + cassandra 4 4 36m + ``` + +{{% /capture %}} + +{{% capture cleanup %}} +스테이트풀셋을 삭제하거나 스케일링하는 것은 스테이트풀셋에 연관된 볼륨을 삭제하지 않는다. 당신의 데이터가 스테이트풀셋의 관련된 모든 리소스를 자동으로 제거하는 것보다 더 가치있기에 이 설정은 당신의 안전을 위한 것이다. + +{{< warning >}} +스토리지 클래스와 리클레임 정책에 따라 *퍼시스턴스볼륨클레임* 을 삭제하면 그와 연관된 볼륨도 삭제될 수 있다. 볼륨 요청이 삭제되어도 데이터를 접근할 수 있다고 절대로 가정하지 말자. +{{< /warning >}} + +1. 다음 명령어(한 줄로 연결된)를 실행하여 카산드라 `스테이트풀셋`을 모두 제거하자. + + ```shell + grace=$(kubectl get po cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ + && kubectl delete statefulset -l app=cassandra \ + && echo "Sleeping $grace" \ + && sleep $grace \ + && kubectl delete pvc -l app=cassandra + ``` + +1. 다음 명령어를 실행하여 카산드라 서비스를 제거하자. + + ```shell + kubectl delete service -l app=cassandra + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* 어떻게 [스테이트풀셋 스케일](/docs/tasks/run-application/scale-stateful-set/)하는지 살펴본다. +* [*쿠버네티스시드제공자*](https://github.com/kubernetes/examples/blob/master/cassandra/java/src/main/java/io/k8s/cassandra/KubernetesSeedProvider.java)에 대해 더 살펴본다. +* 커스텀 [시드 제공자 설정](https://git.k8s.io/examples/cassandra/java/README.md)를 살펴본다. + +{{% /capture %}} + diff --git a/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md new file mode 100644 index 0000000000..2014c301a7 --- /dev/null +++ b/content/ko/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -0,0 +1,233 @@ +--- +title: "예시: WordPress와 MySQL을 퍼시스턴트 볼륨에 배포하기" +reviewers: +content_template: templates/tutorial +weight: 20 +card: + name: tutorials + weight: 40 + title: "스테이트풀셋 예시: Wordpress와 퍼시스턴트 볼륨" +--- + +{{% capture overview %}} +이 튜토리얼은 WordPress 사이트와 MySQL 데이터베이스를 Minikube를 이용하여 어떻게 배포하는지 보여준다. 애플리케이션 둘 다 퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임을 데이터를 저장하기 위해 사용한다. + +[퍼시스턴트볼륨](/docs/concepts/storage/persistent-volumes/)(PV)는 관리자가 수동으로 프로비저닝한 클러스터나 쿠버네티스 [스토리지클래스](/docs/concepts/storage/storage-classes)를 이용해 동적으로 프로비저닝된 저장소의 일부이다. [퍼시스턴트볼륨클레임](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)(PVC)은 PV로 충족할 수 있는 사용자에 의한 스토리지 요청이다. 퍼시스턴트볼륨은 파드 라이프사이클과 독립적이며 재시작, 재스케줄링이나 파드를 삭제할 때에도 데이터를 보존한다. + +{{< warning >}} +이 배포는 프로덕션 사용예로는 적절하지 않은데 이는 단일 인스턴스의 WordPress와 MySQL을 이용했기 때문이다. 프로덕션이라면 [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress)로 배포하기를 고려해보자. +{{< /warning >}} + +{{< note >}} +이 튜토리얼에 제공된 파일들은 GA 디플로이먼트 API를 사용하며 쿠버네티스 버전 1.9 이상을 이용한다. 이 튜토리얼을 쿠버네티스 하위 버전에서 적용한다면 API 버전을 적절히 갱신하거나 이 튜토리얼의 이전 버전을 참고하자. +{{< /note >}} + +{{% /capture %}} + +{{% capture objectives %}} +* 퍼시스턴트볼륨클레임과 퍼시스턴트볼륨 생성 +* 다음을 포함하는 `kustomization.yaml` 생성 + * 시크릿 생성자 + * MySQL 리소스 구성 + * WordPress 리소스 구성 +* `kubectl apply -k ./`로 생성한 kustomization 을 적용 +* 정리 + +{{% /capture %}} + +{{% capture prerequisites %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +이 예시는 `kubectl` 1.14 이상 버전에서 동작한다. + +다음 설정 파일을 다운로드한다. + +1. [mysql-deployment.yaml](/examples/application/wordpress/mysql-deployment.yaml) + +1. [wordpress-deployment.yaml](/examples/application/wordpress/wordpress-deployment.yaml) + +{{% /capture %}} + +{{% capture lessoncontent %}} + +## 퍼시스턴트볼륨클레임과 퍼시스턴트볼륨 생성 + +MySQL과 Wordpress는 각각 데이터를 저장할 퍼시스턴트볼륨이 필요하다. 퍼시스턴트볼륨클레임은 배포 단계에 생성된다. + +많은 클러스터 환경에서 설치된 기본 스토리지클래스(StorageClass)가 있다. 퍼시스턴트볼륨클레임에 스토리지클래스를 지정하지 않으면 클러스터의 기본 스토리지클래스를 사용한다. + +퍼시스턴트볼륨클레임이 생성되면 퍼시스턴트볼륨이 스토리지클래스 설정을 기초로 동적으로 프로비저닝된다. + +{{< warning >}} +로컬 클러스터에서 기본 스토리지클래스는 `hostPath` 프로비저너를 사용한다. `hostPath`는 개발과 테스트 목적에만 적합하다. `hostPath` 볼륨인 경우 데이터는 스케쥴링된 파드의 노드에 `/tmp` 살아있고 노드 간에 이동하지 않는다. 파드가 죽어서 클러스터 내에 다른 노드로 스케줄링되거나 해당 노드가 재부팅되면 그 데이터는 잃어버린다. +{{< /warning >}} + +{{< note >}} +`hostPath` 프로비저너를 사용해야 하는 클러스터를 기동하는 경우라면 `--enable-hostpath-provisioner` 플래그를 `controller-manager` 컴포넌트에 꼭 설정해야 한다. +{{< /note >}} + +{{< note >}} +만약 구글 쿠버네티스 엔진으로 운영하는 쿠버네티스 클러스터를 가지고 있다면 [가이드](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk)를 따르도록 한다. +{{< /note >}} + +## kustomization.yaml 생성하기 + +### 시크릿 생성자 추가 +[시크릿](/docs/concepts/configuration/secret/)은 암호나 키 같은 민감한 데이터들을 저장하는 개체이다. 1.14 버전부터 `kubectl`은 kustomization 파일을 이용해서 쿠버네티스 개체를 관리한다. `kustomization.yaml`의 제네레니터로 시크릿을 생성할 수 있다. + +다음 명령어로 `kustomization.yaml` 내에 시크릿 제네레이터를 추가한다. `YOUR_PASSWORD`는 사용하기 원하는 암호로 변경해야 한다. + +```shell +cat <./kustomization.yaml +secretGenerator: +- name: mysql-pass + literals: + - password=YOUR_PASSWORD +EOF +``` + +## MySQL과 WordPress에 필요한 리소스 구성 추가하기 + +다음 매니페스트는 MySQL 디플로이먼트 단일 인스턴스를 기술한다. MySQL 컨케이너는 퍼시스턴트볼륨을 /var/lib/mysql에 마운트한다. `MYSQL_ROOT_PASSWORD` 환경변수는 시크릿에서 가져와 데이터베이스 암호로 설정한다. + +{{< codenew file="application/wordpress/mysql-deployment.yaml" >}} + +1. MySQL 디플로이먼트 구성 파일을 다운로드한다. + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml + ``` + +2. WordPress 구성 파일을 다운로드한다. + + ```shell + curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml + ``` + +3. 두 파일을 `kustomization.yaml`에 추가하자. + + ```shell + cat <>./kustomization.yaml + resources: + - mysql-deployment.yaml + - wordpress-deployment.yaml + EOF + ``` + +## 적용하고 확인하기 +`kustomization.yaml`은 WordPress 사이트와 MySQL 데이터베이스를 배포하는 모든 리소스를 포함한다. +다음과 같이 디렉터리를 적용할 수 있다. +```shell +kubectl apply -k ./ +``` + +이제 모든 개체가 존재하는지 확인할 수 있다. + +1. 시크릿이 존재하는지 다음 명령어를 실행하여 확인한다. + + ```shell + kubectl get secrets + ``` + + 응답은 아래와 비슷해야 한다. + + ```shell + NAME TYPE DATA AGE + mysql-pass-c57bb4t7mf Opaque 1 9s + ``` + +2. 퍼시스턴트볼륨이 동적으로 프로비저닝되었는지 확인한다. + + ```shell + kubectl get pvc + ``` + + {{< note >}} + PV를 프로비저닝하고 정착(bound)시키는데 수 분이 걸릴 수 있다. + {{< /note >}} + + 응답은 아래와 비슷해야 한다. + + ```shell + NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE + mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s + ``` + +3. 다음 명령어를 실행하여 파드가 실행 중인지 확인한다. + + ```shell + kubectl get pods + ``` + + {{< note >}} + 파드의 상태가 `RUNNING`가 되기까지 수 분이 걸릴 수 있다. + {{< /note >}} + + 응답은 아래와 비슷해야 한다. + + ``` + NAME READY STATUS RESTARTS AGE + wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s + ``` + +4. 다음 명령어를 실행하여 서비스가 실행 중인지 확인해보자. + + ```shell + kubectl get services wordpress + ``` + + 응답은 아래와 비슷해야 한다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + wordpress ClusterIP 10.0.0.89 80:32406/TCP 4m + ``` + + {{< note >}} + Minikube에서는 서비스를 `NodePort`으로만 노출할 수 있다. EXTERNAL-IP는 항상 Pending 상태이다. + {{< /note >}} + +5. 다음 명령어를 실행하여 WordPress 서비스의 IP 주소를 얻어온다. + + ```shell + minikube service wordpress --url + ``` + + 응답은 아래와 비슷해야 한다. + + ``` + http://1.2.3.4:32406 + ``` + +6. IP 주소를 복사해서 웹 브라우저에서 사이트를 열어 보자. + + 아래 스크린샷과 유사한 WordPress 설정 페이지를 볼 수 있어야 한다. + + ![wordpress-init](https://raw.githubusercontent.com/kubernetes/examples/master/mysql-wordpress-pd/WordPress.png) + +{{< warning >}} +이 페이지의 WordPress 설치를 내버려 두지 말자. 다른 사용자가 이 페이지를 발견하고 귀하의 인스턴스에 웹 사이트를 설정하고 악의적인 컨텐츠를 게시하는데 사용할 수 있다.

WordPress를 사용자명과 암호를 넣어 생성하거나 인스턴스를 삭제하자. +{{< /warning >}} + +{{% /capture %}} + +{{% capture cleanup %}} + +1. 다음 명령을 실핼하여 시크릿, 디플로이먼트, 서비스와 퍼시스턴트볼륨클레임을 삭제하자. + + ```shell + kubectl delete -k ./ + ``` + +{{% /capture %}} + +{{% capture whatsnext %}} + +* [인트로스펙션과 디버깅](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 알아보자. +* [잡](/docs/concepts/workloads/controllers/jobs-run-to-completion/)를 알아보자. +* [포트 포워딩](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)를 알아보자. +* 어떻게 [컨테이너에서 셸을 사용하는지](/docs/tasks/debug-application-cluster/get-shell-running-container/)를 알아보자. + +{{% /capture %}} + diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 914f3a9607..965ecf2d53 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -223,7 +223,7 @@ Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우 ``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend ClusterIP 10.0.0.112 80:31323/TCP 6s + frontend NodePort 10.0.0.112 80:31323/TCP 6s kubernetes ClusterIP 10.0.0.1 443/TCP 4m redis-master ClusterIP 10.0.0.151 6379/TCP 2m redis-slave ClusterIP 10.0.0.223 6379/TCP 1m diff --git a/content/ko/examples/application/cassandra/cassandra-service.yaml b/content/ko/examples/application/cassandra/cassandra-service.yaml new file mode 100644 index 0000000000..31bee74b58 --- /dev/null +++ b/content/ko/examples/application/cassandra/cassandra-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + app: cassandra + name: cassandra +spec: + clusterIP: None + ports: + - port: 9042 + selector: + app: cassandra diff --git a/content/ko/examples/application/cassandra/cassandra-statefulset.yaml b/content/ko/examples/application/cassandra/cassandra-statefulset.yaml new file mode 100644 index 0000000000..a7bdbedc9c --- /dev/null +++ b/content/ko/examples/application/cassandra/cassandra-statefulset.yaml @@ -0,0 +1,100 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: cassandra + labels: + app: cassandra +spec: + serviceName: cassandra + replicas: 3 + selector: + matchLabels: + app: cassandra + template: + metadata: + labels: + app: cassandra + spec: + terminationGracePeriodSeconds: 1800 + containers: + - name: cassandra + image: gcr.io/google-samples/cassandra:v13 + imagePullPolicy: Always + ports: + - containerPort: 7000 + name: intra-node + - containerPort: 7001 + name: tls-intra-node + - containerPort: 7199 + name: jmx + - containerPort: 9042 + name: cql + resources: + limits: + cpu: "500m" + memory: 1Gi + requests: + cpu: "500m" + memory: 1Gi + securityContext: + capabilities: + add: + - IPC_LOCK + lifecycle: + preStop: + exec: + command: + - /bin/sh + - -c + - nodetool drain + env: + - name: MAX_HEAP_SIZE + value: 512M + - name: HEAP_NEWSIZE + value: 100M + - name: CASSANDRA_SEEDS + value: "cassandra-0.cassandra.default.svc.cluster.local" + - name: CASSANDRA_CLUSTER_NAME + value: "K8Demo" + - name: CASSANDRA_DC + value: "DC1-K8Demo" + - name: CASSANDRA_RACK + value: "Rack1-K8Demo" + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + readinessProbe: + exec: + command: + - /bin/bash + - -c + - /ready-probe.sh + initialDelaySeconds: 15 + timeoutSeconds: 5 + # These volume mounts are persistent. They are like inline claims, + # but not exactly because the names need to match exactly one of + # the stateful pod volumes. + volumeMounts: + - name: cassandra-data + mountPath: /cassandra_data + # These are converted to volume claims by the controller + # and mounted at the paths mentioned above. + # do not use these in production until ssd GCEPersistentDisk or other ssd pd + volumeClaimTemplates: + - metadata: + name: cassandra-data + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: fast + resources: + requests: + storage: 1Gi +--- +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: k8s.io/minikube-hostpath +parameters: + type: pd-ssd diff --git a/content/ko/examples/application/mysql/mysql-configmap.yaml b/content/ko/examples/application/mysql/mysql-configmap.yaml new file mode 100644 index 0000000000..46d34e422c --- /dev/null +++ b/content/ko/examples/application/mysql/mysql-configmap.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: mysql + labels: + app: mysql +data: + master.cnf: | + # Apply this config only on the master. + [mysqld] + log-bin + slave.cnf: | + # Apply this config only on slaves. + [mysqld] + super-read-only + diff --git a/content/ko/examples/application/mysql/mysql-deployment.yaml b/content/ko/examples/application/mysql/mysql-deployment.yaml new file mode 100644 index 0000000000..518457777e --- /dev/null +++ b/content/ko/examples/application/mysql/mysql-deployment.yaml @@ -0,0 +1,43 @@ +apiVersion: v1 +kind: Service +metadata: + name: mysql +spec: + ports: + - port: 3306 + selector: + app: mysql + clusterIP: None +--- +apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 +kind: Deployment +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + strategy: + type: Recreate + template: + metadata: + labels: + app: mysql + spec: + containers: + - image: mysql:5.6 + name: mysql + env: + # Use secret in real usage + - name: MYSQL_ROOT_PASSWORD + value: password + ports: + - containerPort: 3306 + name: mysql + volumeMounts: + - name: mysql-persistent-storage + mountPath: /var/lib/mysql + volumes: + - name: mysql-persistent-storage + persistentVolumeClaim: + claimName: mysql-pv-claim diff --git a/content/ko/examples/application/mysql/mysql-pv.yaml b/content/ko/examples/application/mysql/mysql-pv.yaml new file mode 100644 index 0000000000..6f4e692f3b --- /dev/null +++ b/content/ko/examples/application/mysql/mysql-pv.yaml @@ -0,0 +1,26 @@ +kind: PersistentVolume +apiVersion: v1 +metadata: + name: mysql-pv-volume + labels: + type: local +spec: + storageClassName: manual + capacity: + storage: 20Gi + accessModes: + - ReadWriteOnce + hostPath: + path: "/mnt/data" +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mysql-pv-claim +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi diff --git a/content/ko/examples/application/mysql/mysql-services.yaml b/content/ko/examples/application/mysql/mysql-services.yaml new file mode 100644 index 0000000000..f538992566 --- /dev/null +++ b/content/ko/examples/application/mysql/mysql-services.yaml @@ -0,0 +1,30 @@ +# Headless service for stable DNS entries of StatefulSet members. +apiVersion: v1 +kind: Service +metadata: + name: mysql + labels: + app: mysql +spec: + ports: + - name: mysql + port: 3306 + clusterIP: None + selector: + app: mysql +--- +# Client service for connecting to any MySQL instance for reads. +# For writes, you must instead connect to the master: mysql-0.mysql. +apiVersion: v1 +kind: Service +metadata: + name: mysql-read + labels: + app: mysql +spec: + ports: + - name: mysql + port: 3306 + selector: + app: mysql + diff --git a/content/ko/examples/application/mysql/mysql-statefulset.yaml b/content/ko/examples/application/mysql/mysql-statefulset.yaml new file mode 100644 index 0000000000..e0c04007a8 --- /dev/null +++ b/content/ko/examples/application/mysql/mysql-statefulset.yaml @@ -0,0 +1,167 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + serviceName: mysql + replicas: 3 + template: + metadata: + labels: + app: mysql + spec: + initContainers: + - name: init-mysql + image: mysql:5.7 + command: + - bash + - "-c" + - | + set -ex + # Generate mysql server-id from pod ordinal index. + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + echo [mysqld] > /mnt/conf.d/server-id.cnf + # Add an offset to avoid reserved server-id=0 value. + echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf + # Copy appropriate conf.d files from config-map to emptyDir. + if [[ $ordinal -eq 0 ]]; then + cp /mnt/config-map/master.cnf /mnt/conf.d/ + else + cp /mnt/config-map/slave.cnf /mnt/conf.d/ + fi + volumeMounts: + - name: conf + mountPath: /mnt/conf.d + - name: config-map + mountPath: /mnt/config-map + - name: clone-mysql + image: gcr.io/google-samples/xtrabackup:1.0 + command: + - bash + - "-c" + - | + set -ex + # Skip the clone if data already exists. + [[ -d /var/lib/mysql/mysql ]] && exit 0 + # Skip the clone on master (ordinal index 0). + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + [[ $ordinal -eq 0 ]] && exit 0 + # Clone data from previous peer. + ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql + # Prepare the backup. + xtrabackup --prepare --target-dir=/var/lib/mysql + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + containers: + - name: mysql + image: mysql:5.7 + env: + - name: MYSQL_ALLOW_EMPTY_PASSWORD + value: "1" + ports: + - name: mysql + containerPort: 3306 + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + resources: + requests: + cpu: 500m + memory: 1Gi + livenessProbe: + exec: + command: ["mysqladmin", "ping"] + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + readinessProbe: + exec: + # Check we can execute queries over TCP (skip-networking is off). + command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] + initialDelaySeconds: 5 + periodSeconds: 2 + timeoutSeconds: 1 + - name: xtrabackup + image: gcr.io/google-samples/xtrabackup:1.0 + ports: + - name: xtrabackup + containerPort: 3307 + command: + - bash + - "-c" + - | + set -ex + cd /var/lib/mysql + + # Determine binlog position of cloned data, if any. + if [[ -f xtrabackup_slave_info ]]; then + # XtraBackup already generated a partial "CHANGE MASTER TO" query + # because we're cloning from an existing slave. + mv xtrabackup_slave_info change_master_to.sql.in + # Ignore xtrabackup_binlog_info in this case (it's useless). + rm -f xtrabackup_binlog_info + elif [[ -f xtrabackup_binlog_info ]]; then + # We're cloning directly from master. Parse binlog position. + [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 + rm xtrabackup_binlog_info + echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ + MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in + fi + + # Check if we need to complete a clone by starting replication. + if [[ -f change_master_to.sql.in ]]; then + echo "Waiting for mysqld to be ready (accepting connections)" + until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done + + echo "Initializing replication from clone position" + # In case of container restart, attempt this at-most-once. + mv change_master_to.sql.in change_master_to.sql.orig + mysql -h 127.0.0.1 <