diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index 4061f7c7b8..3eb52d2199 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -17,14 +17,14 @@ weight: 10 노드의 상태는 다음의 정보를 포함한다. -* [주소](#주소) -* [컨디션](#컨디션) -* [용량](#용량) -* [정보](#정보) +* [주소](#addresses) +* [컨디션](#condition) +* [용량과 할당가능](#capacity) +* [정보](#info) 각 섹션은 아래 상세하게 기술되었다. -### 주소 +### 주소 {#addresses} 이 필드의 용법은 클라우드 제공사업자 또는 베어메탈 구성에 따라 다양하다. @@ -33,9 +33,9 @@ weight: 10 * InternalIP: 일반적으로 노드의 IP 주소는 클러스터 내에서만 라우트 가능하다. -### 컨디션 +### 컨디션 {#condition} -`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. +`conditions` 필드는 모든 `Running` 노드의 상태를 기술한다. 컨디션의 예로 다음을 포함한다. | Node Condition | Description | |----------------|-------------| @@ -52,7 +52,11 @@ weight: 10 "conditions": [ { "type": "Ready", - "status": "True" + "status": "True", + "reason": "KubeletReady", + "message": "kubelet is posting ready status", + "lastHeartbeatTime": "2019-06-05T18:38:35Z", + "lastTransitionTime": "2019-06-05T11:41:27Z" } ] ``` @@ -70,11 +74,19 @@ ready 컨디션의 상태가 [kube-controller-manager](/docs/admin/kube-controll 이 기능을 활성화 하면 조건이 관찰되고 taint가 생성되는 시간 사이에 다소 지연이 발생한다. 이 지연은 보통 1초 미만이지만, 성공적으로 스케줄은 되나 kubelet에 의해 거부되는 파드의 수가 증가할 수 있다. {{< /caution >}} -### 용량 +### 용량과 할당가능 {#capacity} 노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고 노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다. -### 정보 +용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다. +할당가능 블록은 일반 파드에서 사용할 수 있는 +노드의 리소스 양을 나타낸다. + +노드에서 +[컴퓨팅 리소스 예약](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)하는 방법을 +배우는 동안 용량 및 할당가능 리소스에 대해 자세히 읽어보자. + +### 정보 {#info} 커널 버전, 쿠버네티스 버전 (kubelet과 kube-proxy 버전), (사용하는 경우) Docker 버전, OS 이름과 같은 노드에 대한 일반적인 정보이다. 정보는 Kubelet에 의해 노드로부터 수집된다. diff --git a/content/ko/docs/concepts/cluster-administration/federation.md b/content/ko/docs/concepts/cluster-administration/federation.md index 1719b9882b..81584a28e1 100644 --- a/content/ko/docs/concepts/cluster-administration/federation.md +++ b/content/ko/docs/concepts/cluster-administration/federation.md @@ -170,7 +170,7 @@ zone)](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availabi 마지막으로, 클러스터 중 어느 클러스터라도 쿠버네티스 클러스터에서 추천되는 최대 노드 수 보다 더 많은 노드가 필요하다면, 더 많은 클러스터가 필요할 것이다. 쿠버네티스 v1.3은 클러스터를 최대 1000노드까지 지원한다. 쿠버네티스 v1.8은 -클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/cluster-large/)에서 확인 가능하다. +클러스터를 최대 5000 노드까지 지원한다. 더 자세한 가이드는 [대규모 클러스터 구축하기](/docs/setup/best-practices/cluster-large/)에서 확인 가능하다. {{% /capture %}} diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index 76bd64fe5e..50291bd72d 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -60,6 +60,8 @@ Docker *18.06 또는 그 이상* 을 사용하길 바란다. 더 낮은 버전 - AWS EC2 컨테이너 레지스트리(ECR) 사용 - IAM 역할 및 정책을 사용하여 ECR 저장소에 접근을 제어함 - ECR 로그인 자격 증명은 자동으로 갱신됨 + - Oracle 클라우드 인프라스트럭처 레지스트리(OCIR) 사용 + - IAM 역할과 정책을 사용하여 OCIR 저장소에 접근을 제어함 - Azure 컨테이너 레지스트리(ACR) 사용 - IBM 클라우드 컨테이너 레지스트리 사용 - 프라이빗 레지스트리에 대한 인증을 위한 노드 구성 @@ -275,19 +277,7 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다. ```shell -cat < ./kustomization.yaml -secretGenerator: -- name: myregistrykey - type: docker-registry - literals: - - docker-server=DOCKER_REGISTRY_SERVER - - docker-username=DOCKER_USER - - docker-password=DOCKER_PASSWORD - - docker-email=DOCKER_EMAIL -EOF - -kubectl apply -k . -secret/myregistrykey-66h7d4d986 created +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL ``` 만약 Docer 자격 증명 파일이 이미 존재한다면, 위의 명령을 사용하지 않고, diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 72923dc571..86dd09209c 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -8,7 +8,13 @@ weight: 20 {{< feature-state for_k8s_version="v1.12" state="alpha" >}} -이 페이지는 런타임 클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다. +이 페이지는 런타임 클래스(RuntimeClass) 리소스와 런타임 선택 메커니즘에 대해서 설명한다. + +{{< warning >}} +런타임클래스는 v1.14 베타 업그레이드에서 *중대한* 변화를 포함한다. +런타임클래스를 v1.14 이전부터 사용하고 있었다면, +[런타임 클래스를 알파에서 베타로 업그레이드하기](#upgrading-runtimeclass-from-alpha-to-beta)를 확인한다. +{{< /warning >}} {{% /capture %}} @@ -17,82 +23,72 @@ weight: 20 ## 런타임 클래스 -런타임 클래스는 파드의 컨테이너를 실행하는데 사용할 컨테이너 런타임 설정을 선택하기 위한 -알파 특징이다. +런타임 클래스는 컨테이너 런타임 설정을 선택하는 기능이다. +이 컨테이너 런타임 설정은 파드의 컨테이너를 실행할 때에 이용한다. + +## 동기 + +서로 다른 파드간에 런타임 클래스를 설정하여 +성능대 보안의 균형을 유지할 수 있다. +예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, +하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. +그러면 몇가지 추가적인 오버헤드는 있지만 +대체 런타임을 추가 분리하는 유익이 있다. + +또한 런타임 클래스를 사용하여 컨테이너 런타임이 같으나 설정이 다른 +여러 파드를 실행할 수 있다. ### 셋업 -초기 알파 특징이므로, 런타임 클래스 특징을 사용하기 위해서는 몇 가지 추가 셋업 -단계가 필요하다. - -1. 런타임 클래스 특징 게이트 활성화(apiservers 및 kubelets에 대해서, 버전 1.12+ 필요) -2. 런타임 클래스 CRD 설치 -3. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) -4. 상응하는 런타임 클래스 리소스 생성 - -#### 1. 런타임 클래스 특징 게이트 활성화 - +RuntimeClass 특징 게이트가 활성화(기본값)를 확인한다. 특징 게이트 활성화에 대한 설명은 [특징 게이트](/docs/reference/command-line-tools-reference/feature-gates/)를 -참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 -한다. +참고한다. `RuntimeClass` 특징 게이트는 apiservers _및_ kubelets에서 활성화되어야 한다. -#### 2. 런타임 클래스 CRD 설치 +1. CRI 구현(implementation)을 노드에 설정(런타임에 따라서) +2. 상응하는 런타임 클래스 리소스 생성 -런타임 클래스 [CustomResourceDefinition][] (CRD)는 쿠버네티스 git 저장소의 애드온 디렉터리에서 찾을 수 -있다. [kubernetes/cluster/addons/runtimeclass/runtimeclass_crd.yaml][runtimeclass_crd] +#### 1. CRI 구현을 노드에 설정 -`kubectl apply -f runtimeclass_crd.yaml`을 통해서 해당 CRD를 설치한다. - -[CustomResourceDefinition]: /docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ -[runtimeclass_crd]: https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/runtimeclass/runtimeclass_crd.yaml - - -#### 3. CRI 구현을 노드에 설정 - -런타임 클래스와 함께 선택할 설정은 CRI 구현에 의존적이다. 사용자의 CRI -구현에 따른 설정 방법은 연관된 문서를 통해서 확인한다. 이것은 알파 -특징이므로, 아직 모든 CRI가 다중 런타임 클래스를 지원하지는 않는다. +런타임 클래스를 통한 가능한 구성은 컨테이너 런타임 인터페이스(CRI) 구현에 의존적이다. +사용자의 CRI 구현에 따른 설정 방법은 +연관된 문서를 통해서 확인한다([아래](#cri-configuration)). {{< note >}} 런타임 클래스는 클러스터 전체에 걸쳐 동질의 노드 설정 -(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 -설정)이라도 -스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다([파드를 노드에 -할당하기](/docs/concepts/configuration/assign-pod-node/) 참고). +(모든 노드가 컨테이너 런타임에 준하는 동일한 방식으로 설정되었음을 의미)을 가정한다. 어떠한 이질성(다양한 +설정)이라도 스케줄링 특징을 통해서 런타임 클래스와는 독립적으로 관리되어야 한다 +([파드를 노드에 할당하기](/docs/concepts/configuration/assign-pod-node/) 참고). {{< /note >}} -해당 설정은 상응하는 `RuntimeHandler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. +해당 설정은 상응하는 `handler` 이름을 가지며, 이는 런타임 클래스에 의해서 참조된다. 런타임 핸들러는 유효한 DNS 1123 서브도메인(알파-숫자 + `-`와 `.`문자)을 가져야 한다. -#### 4. 상응하는 런타임 클래스 리소스 생성 +#### 2. 상응하는 런타임 클래스 리소스 생성 -3단계에서 셋업 한 설정은 연관된 `RuntimeHandler` 이름을 가져야 하며, 이를 통해서 -설정을 식별할 수 있다. 각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, -상응하는 런타임 클래스 오브젝트를 생성한다. +1단계에서 셋업 한 설정은 연관된 `handler` 이름을 가져야 하며, 이를 통해서 설정을 식별할 수 있다. +각 런타임 핸들러(그리고 선택적으로 비어있는 `""` 핸들러)에 대해서, 상응하는 런타임 클래스 오브젝트를 생성한다. 현재 런타임 클래스 리소스는 런타임 클래스 이름(`metadata.name`)과 런타임 핸들러 -(`spec.runtimeHandler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다. +(`handler`)로 단 2개의 중요 필드만 가지고 있다. 오브젝트 정의는 다음과 같은 형태이다. ```yaml -apiVersion: node.k8s.io/v1alpha1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음 +apiVersion: node.k8s.io/v1beta1 # 런타임 클래스는 node.k8s.io API 그룹에 정의되어 있음 kind: RuntimeClass metadata: name: myclass # 런타임 클래스는 해당 이름을 통해서 참조됨 # 런타임 클래스는 네임스페이스가 없는 리소스임 -spec: - runtimeHandler: myconfiguration # 상응하는 CRI 설정의 이름임 +handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` - {{< note >}} 런타임 클래스 쓰기 작업(create/update/patch/delete)은 -클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. 더 자세한 정보는 [권한 -개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. +클러스터 관리자로 제한할 것을 권장한다. 이것은 일반적으로 기본 설정이다. +더 자세한 정보는 [권한 개요](/docs/reference/access-authn-authz/authorization/)를 참고한다. {{< /note >}} ### 사용 -클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 +클러스터를 위해서 런타임 클래스를 설정하고 나면, 그것을 사용하는 것은 매우 간단하다. 파드 스펙에 `runtimeClassName`를 명시한다. 예를 들면 다음과 같다. ```yaml @@ -105,12 +101,75 @@ spec: # ... ``` -이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. 만약 지명된 -런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 -`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다. 에러 -메시지를 위해서는 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 +이것은 Kubelet이 지명된 런타임 클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다. +만약 지명된 런타임 클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는 +`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다. +에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를 확인한다. -만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용될 것이다. 기본 런타임 핸들러는 런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다. +만약 명시된 `runtimeClassName`가 없다면, 기본 런타임 핸들러가 사용되며, +런타임 클래스 특징이 비활성화되었을 때와 동일하게 동작한다. + +### CRI 구성 {#cri-configuration} + +CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다. + +#### dockershim + +쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다. + +#### [containerd](https://containerd.io/) + +런타임 핸들러는 containerd의 구성 파일인 `/etc/containerd/config.toml` 통해 설정한다. +유효한 핸들러는 runtimes 단락 아래에서 설정한다. + +``` +[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +``` + +더 자세한 containerd의 구성 문서를 살펴본다. +https://github.com/containerd/cri/blob/master/docs/config.md + +#### [cri-o](https://cri-o.io/) + +런타임 핸들러는 cri-o의 구성파일인 `/etc/crio/crio.conf`을 통해 설정한다. +[crio.runtime 테이블](https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) 아래에 +유효한 핸들러를 설정한다. + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +더 자세한 cri-o의 구성 문서를 살펴본다. +https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go + + +### 런타임 클래스를 알파에서 베타로 업그레이드 {#upgrading-runtimeclass-from-alpha-to-beta} + +런타임 클래스 베타 기능은 다음의 변화를 포함한다. + +- `node.k8s.io` API 그룹과 `runtimeclasses.node.k8s.io` 리소스는 CustomResourceDefinition에서 + 내장 API로 이전되었다. +- 런타임 클래스 정의에서 `spec`을 직접 사용할 수 있다. + (즉, 더 이상 RuntimeClassSpec는 없다). +- `runtimeHandler` 필드는 `handler`로 이름이 바뀌었다. +- `handler` 필드는 이제 모두 API 버전에서 요구된다. 이는 알파 API에서도 `runtimeHandler` 필드가 + 필요하다는 의미이다. +- `handler` 필드는 반드시 올바른 DNS 레이블([RFC 1123](https://tools.ietf.org/html/rfc1123))으로, + 이는 더 이상 `.` 캐릭터(모든 버전에서)를 포함할 수 없다 의미이다. 올바른 핸들러는 + 다음의 정규 표현식을 따른다. `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`. + +**작업 필요** 다음 작업은 알파 버전의 런타임 기능을 +베타 버전으로 업그레이드하기 위해 진행되어야 한다. + +- 런타임 클래스 리소스는 v1.14로 업그레이드 *후에* 반드시 재생성되어야 하고, + `runtimeclasses.node.k8s.io` CRD는 다음과 같이 수동으로 지워야 한다. + ``` + kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io + ``` +- 지정되지 않았거나 비어 있는 `runtimeHandler` 이거나 핸들러 내에 `.` 캐릭터를 사용한 알파 런타임 클래스는 + 더 이상 올바르지 않으며, 반드시 올바른 핸들러 구성으로 이전헤야 한다 + (위를 참조). {{% /capture %}} diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index 2248084272..40b6fe95b9 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -16,7 +16,7 @@ card: ## 마스터 컴포넌트 마스터 컴포넌트는 클러스터의 컨트롤 플레인을 제공한다. 마스터 컴포넌트는 클러스터에 관한 전반적인 결정 -(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다. +(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 레플리케이션 컨트롤러의 `replicas` 필드가 요구조건을 충족되지 않을 경우 새로운 파드를 구동 시키는 것)를 감지하고 반응한다. 마스터 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작 될 수 있다. 그러나, 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 마스터 컴포넌트를 구동시키고, @@ -72,13 +72,11 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드 ### kube-proxy -[kube-proxy](/docs/admin/kube-proxy/)는 호스트 상에서 네트워크 규칙을 유지하고 연결에 대한 포워딩을 수행함으로서 - 쿠버네티스 서비스 추상화가 가능하도록 해준다. +{{< glossary_definition term_id="kube-proxy" length="all" >}} ### 컨테이너 런타임 -컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. -쿠버네티스는 몇몇의 런타임을 지원하는데 [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)를 구현한 모든 런타임이다. +{{< glossary_definition term_id="container-runtime" length="all" >}} ## 애드온 diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 0ed8643c86..e3d9981a3a 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -15,8 +15,7 @@ API 엔드포인트, 리소스 타입과 샘플은 [API Reference](/docs/referen API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/reference/access-authn-authz/controlling-access/)에서 논의되었다. -쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. -[kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. +쿠버네티스 API는 시스템을 위한 선언적 설정 스키마를 위한 기초가 되기도 한다. [kubectl](/docs/reference/kubectl/overview/) 커맨드라인 툴을 사용해서 API 오브젝트를 생성, 업데이트, 삭제 및 조회할 수 있다. 쿠버네티스는 또한 API 리소스에 대해 직렬화된 상태를 (현재는 [etcd](https://coreos.com/docs/distributed-configuration/getting-started-with-etcd/)에) 저장한다. @@ -24,7 +23,6 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc {{% /capture %}} -{{< toc >}} {{% capture body %}} @@ -36,9 +34,9 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc ## OpenAPI 및 Swagger 정의 -완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. +완전한 API 상세 내용은 [OpenAPI](https://www.openapis.org/)를 활용해서 문서화했다. -쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. +쿠버네티스 1.10부터, OpenAPI 규격은 `/openapi/v2` 엔드포인트에서만 제공된다. 요청 형식은 HTTP 헤더에 명시해서 설정할 수 있다. 헤더 | 가능한 값 @@ -46,7 +44,8 @@ API에 원격 접속하는 방법은 [Controlling API Access doc](/docs/referenc Accept | `application/json`, `application/com.github.proto-openapi.spec.v2@v1.0+protobuf` (기본 content-type은 `*/*`에 대해 `application/json`이거나 이 헤더를 전달하지 않음) Accept-Encoding | `gzip` (이 헤더를 전달하지 않아도 됨) -1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. 이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다. +1.14 이전 버전에서 형식이 구분된 엔드포인트(`/swagger.json`, `/swagger-2.0.0.json`, `/swagger-2.0.0.pb-v1`, `/swagger-2.0.0.pb-v1.gz`)는 OpenAPI 스펙을 다른 포맷으로 제공한다. +이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거됬다. **OpenAPI 규격을 조회하는 예제** @@ -58,21 +57,25 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github 쿠버네티스는 주로 클러스터 내부 통신용 API를 위해 대안적인 Protobuf에 기반한 직렬화 형식을 구현한다. 해당 API는 [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) 문서와 IDL 파일에 문서화되어 있고 각각의 스키마를 담고 있는 IDL 파일은 API 오브젝트를 정의하는 Go 패키지에 들어있다. -1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) -쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. +1.14 이전 버전에서 쿠버네티스 apiserver는 `/swaggerapi`에서 [Swagger v1.2](http://swagger.io/) +쿠버네티스 API 스펙을 검색하는데 사용할 수 있는 API도 제공한다. 이러한 엔드포인트는 사용 중단되었으며, 쿠버네티스 1.14에서 제거될 예정이다. ## API 버전 규칙 -필드를 없애거나 리소스 표현을 재구성하기 쉽도록, 쿠버네티스는 `/api/v1`이나 -`/apis/extensions/v1beta1`과 같이 각각 다른 API 경로에서 복수의 API 버전을 지원한다. +필드를 없애거나 리소스 표현을 재구성하기 쉽도록, +쿠버네티스는 `/api/v1`이나 `/apis/extensions/v1beta1`과 같이 +각각 다른 API 경로에서 복수의 API 버전을 지원한다. 리소스나 필드 수준보다는 API 수준에서 버전을 선택했는데, API가 명료하고, 시스템 리소스와 행위 관점에서 일관성있으며, 더 이상 사용되지 않는 API나 실험적인 API에 접근을 제어할 수 있도록 하기 위함이다. 스키마 변경에 대해서 JSON과 Protobuf 직렬화 스키마 모두 동일한 가이드라인을 따른다. 다음에 이어지는 설명 모두는 이 두 가지 형식에 모두 해당한다. -API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. +API 버전 규칙과 소프트웨어 버전 규칙은 간접적으로 연관되어 있음을 알아두자. +[API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)에는 +API 버전 규칙과 소프트웨어 버전 규칙 간의 관계가 기술되어 있다. -API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. 각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다. +API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르다는 것을 암시한다. +각각의 수준에 대한 조건은 [API Changes documentation](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)에서 상세히 다룬다. 요약하자면 다음과 같다. - 알파(Alpha) 수준: - 버전 이름에 `alpha`가 포함된다. (예: `v1alpha1`) @@ -87,7 +90,8 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르 - 오브젝트에 대한 스키마나 문법이 다음 베타 또는 안정화 릴리스에서 호환되지 않는 방식으로 바뀔 수도 있다. 이런 경우, 다음 버전으로 이관할 수 있는 가이드를 제공할 것이다. 이 때 API 오브젝트의 삭제, 편집 또는 재생성이 필요할 수도 있다. 편집 절차는 좀 생각해볼 필요가 있다. 이 기능에 의존하고 있는 애플리케이션은 다운타임이 필요할 수도 있다. - - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다. + - 다음 릴리스에서 호환되지 않을 수도 있으므로 사업적으로 중요하지 않은 용도로만 사용하기를 권장한다. + 복수의 클러스터를 가지고 있어서 독립적으로 업그레이드할 수 있다면 이런 제약에서 안심이 될 수도 있겠다. - **베타 기능을 사용하고 피드백을 주기를 바란다! 일단 베타가 끝나면, 실질적으로 더 많은 변경이 어렵다.** - 안정화(stable) 수준: - 버전 이름이 `vX`이고 `X` 는 정수다. @@ -95,8 +99,7 @@ API 버전이 다른 경우는 안정성이나 기술 지원의 수준이 다르 ## API 그룹 -쿠버네티스 API를 보다 쉽게 확장하기 위해서, -[*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다. +쿠버네티스 API를 보다 쉽게 확장하기 위해서, [*API 그룹*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)을 구현했다. API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명시된다. 현재 다양한 API 그룹이 사용되고 있다. @@ -111,8 +114,9 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 1. [CustomResourceDefinition](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)은 아주 기본적인 CRUD 요구를 갖는 사용자에게 적합하다. -1. 쿠버네티스 API 의미론의 전체 셋을 가지고 사용자만의 apiserver를 만들고자하는 사용자는 [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록 - 만들 수 있다. +1. 쿠버네티스 API 의미론의 전체 셋을 가지고, 사용자만의 apiserver를 만들고자하는 사용자는 + [aggregator](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/)를 사용해서 클라이언트 입장에서 매끄럽게 동작하도록 + 만들 수 있다. ## API 그룹 활성화 시키기 @@ -122,7 +126,7 @@ API 그룹은 REST 경로와 직렬화된 객체의 `apiVersion` 필드에 명 `--runtime-config=batch/v1=false`와 같이 설정하고, batch/v2alpha1을 활성화 시키려면 `--runtime-config=batch/v2alpha1`을 설정한다. 이 플래그는 apiserver의 런타임 설정에 쉼표로 분리된 키=값 쌍의 집합을 허용한다. -중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 +중요: 그룹이나 리소스를 활성화 또는 비활성화 시키기 위해서는 apiserver와 controller-manager를 재시작해서 `--runtime-config` 변경을 반영시켜야 한다. ## 그룹 내 리소스 활성화 시키기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md index 1825239058..b0b3c975f0 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md @@ -69,8 +69,29 @@ _어노테이션_ 은 키/값 쌍이다. 유효한 어노테이션 키에는 두 `kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다. +다음은 `imageregistry: https://hub.docker.com/` 어노테이션이 있는 파드의 구성 파일 예시이다. + +```yaml + +apiVersion: v1 +kind: Pod +metadata: + name: annotations-demo + annotations: + imageregistry: "https://hub.docker.com/" +spec: + containers: + - name: nginx + image: nginx:1.7.9 + ports: + - containerPort: 80 + +``` + {{% /capture %}} {{% capture whatsnext %}} [레이블과 셀렉터](/docs/concepts/overview/working-with-objects/labels/)에 대해 알아본다. {{% /capture %}} + + diff --git a/content/ko/docs/concepts/workloads/pods/pod-overview.md b/content/ko/docs/concepts/workloads/pods/pod-overview.md index 79cd31753b..1555ff06e4 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ko/docs/concepts/workloads/pods/pod-overview.md @@ -15,10 +15,9 @@ card: {{% capture body %}} ## 파드에 대해 이해하기 -*파드* 는 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다. +*파드* 는 쿠버네티스 애플리케이션의 기본 실행 단위이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. 파드는 {{< glossary_tooltip term_id="cluster" >}} 에서의 Running 프로세스를 나타낸다. -파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. -파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. +파드는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, {{< glossary_tooltip text="container" term_id="container" >}} 가 동작하기 위해 만들어진 옵션들을 캡슐화 한다. 파드는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 *쿠버네티스에서의 애플리케이션 단일 인스턴스* 를 의미함. [도커](https://www.docker.com)는 쿠버네티스 파드에서 사용되는 가장 대표적인 컨테이너 런타임이지만, 파드는 다른 컨테이너 런타임 역시 지원한다. @@ -27,25 +26,19 @@ card: * **단일 컨테이너만 동작하는 파드**. "단일 컨테이너 당 한 개의 파드" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 파드가 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 파드를 직접 관리한다고 볼 수 있다. * **함께 동작하는 작업이 필요한 다중 컨테이너가 동작하는 파드**. 아마 파드는 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. 파드는 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다. - - [쿠버네티스 블로그](http://kubernetes.io/blog)에는 파드 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참조하길 바란다. * [분산 시스템 툴킷: 복합 컨테이너를 위한 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) * [컨테이너 디자인 패턴](https://kubernetes.io/blog/2016/06/container-design-patterns) - 각각의 파드는 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 한 개씩 다중 파드를 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 _복제_ 라고 한다. 복제된 파드는 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 더 많은 정보는 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다. - - ## 어떻게 파드가 다중 컨테이너를 관리하는가 파드는 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. 파드 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제,어떻게 조절하는지를 공유할 수 있다. 단일 파드 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다. - {{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}} 몇몇의 파드는 {{< glossary_tooltip text="init containers" term_id="init-container" >}} 뿐만 아니라 {{< glossary_tooltip text="app containers" term_id="app-container" >}} 도 가진다. 초기 컨테이너는 앱 컨테이너 시작이 완료되기 전에 동작한다. @@ -62,18 +55,17 @@ card: ## 파드 작업 -직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. +직접 쿠버네티스에서 싱글톤 파드이더라도 개별 파드를 만들일이 거의 없을 것이다. 그 이유는 파드가 상대적으로 수명이 짧고 일시적이기 때문이다. 파드가 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 {{< glossary_tooltip term_id="node" >}} 에서 동작할 것이다. 파드는 프로세스가 종료되거나, 파드 객체가 삭제되거나, 파드가 리소스의 부족으로 인해 *제거되거나*, 노드에 장애가 생기지 않는 한 노드에 남아있는다. {{< note >}} 파드 내부에서 재시작되는 컨테이너를 파드와 함께 재시작되는 컨테이너로 혼동해서는 안된다. 파드는 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다. {{< /note >}} -파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. -쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다. +파드는 스스로 자신을 치료하지 않는다. 만약 파드가 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 파드는 삭제된다. 그와 비슷하게, 파드는 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 파드 인스턴스를 관리하는 작업을 처리하는 *컨트롤러* 라고 하는 고수준의 추상적 개념을 사용한다. 즉, 파드를 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 파드를 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 파드 스케일링과 치료하는지 보려면 [파드와 컨트롤러](#pods-and-controllers)를 참고하길 바란다. ### 파드와 컨트롤러 -컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다. +컨트롤러는 다중 파드를 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃 그리고 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 파드를 스케줄링 함으로써 자동으로 교체할 것이다. 한 가지 또는 그 이상의 파드를 보유한 컨트롤러의 몇 가지 예시. @@ -84,7 +76,11 @@ card: 일반적으로, 컨트롤러는 책임을 지고 제공한 파드 템플릿을 사용한다. ## 파드 템플릿 -파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), [잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), [데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. 컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다. + +파드 템플릿은 [레플리케이션 컨트롤러](/docs/concepts/workloads/controllers/replicationcontroller/), +[잡](/docs/concepts/jobs/run-to-completion-finite-workloads/), +[데몬 셋](/docs/concepts/workloads/controllers/daemonset/)과 같은 다른 객체를 포함하는 파드 명세서이다. +컨트롤러는 파드 템플릿을 사용하여 실제 파드를 만든다. 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 파드에 대한 간단한 매니페스트이다. ```yaml @@ -98,7 +94,7 @@ spec: containers: - name: myapp-container image: busybox - command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600'] + command: ['sh', '-c', 'echo 안녕하세요 쿠버네티스! && sleep 3600'] ``` 모든 레플리카의 현재 원하는 상태를 지정하는 대신, 파드 템플릿은 쿠키 틀과 같다. 쿠키가 한 번 잘리면, 그 쿠키는 쿠키 틀과 더이상 관련이 없다. 양자 얽힘이 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 파드에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 파드는 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 파드에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다. @@ -106,7 +102,8 @@ spec: {{% /capture %}} {{% capture whatsnext %}} -* [파드](/docs/concepts/workloads/pods/pod/)의 다른 동작들을 더 배워보자. +* [파드](/docs/concepts/workloads/pods/pod/)에 대해 더 배워보자. +* 파드의 동작에 대해 더 알아보자. * [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods) * [파드 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/) {{% /capture %}} diff --git a/content/ko/docs/concepts/workloads/pods/podpreset.md b/content/ko/docs/concepts/workloads/pods/podpreset.md index 8f2134a686..788157231a 100644 --- a/content/ko/docs/concepts/workloads/pods/podpreset.md +++ b/content/ko/docs/concepts/workloads/pods/podpreset.md @@ -5,8 +5,8 @@ weight: 50 --- {{% capture overview %}} -이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에 -특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는 +이 페이지는 파드 프리셋에 대한 개요를 제공한다. 파드 프리셋은 파드 생성 시간에 파드에 +특정 정보를 주입하기 위한 오브젝트이다. 해당 정보에는 시크릿, 볼륨, 볼륨 마운트, 환경 변수가 포함될 수 있다. {{% /capture %}} @@ -14,12 +14,12 @@ weight: 50 {{% capture body %}} ## 파드 프리셋 이해하기 -`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 -주입하기 위한 API 리소스이다. -주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는 +`Pod Preset`은 파드 생성 시간에 파드에 추가적인 런타임 요구사항을 +주입하기 위한 API 리소스이다. +주어진 파드 프리셋이 적용되도록 파드에 명시하기 위해서는 [레이블 셀렉터](/docs/concepts/overview/working-with-objects/labels/#label-selectors)를 사용한다. -파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로 +파드 프리셋을 사용하는 것은 파드 템플릿 작성자에게 모든 파드를 위한 모든 정보를 명시적으로 제공하지는 않아도 되도록 한다. 이렇게 하면, 어떤 특정 서비스를 사용할 파드의 파드 템플릿 작성자는 해당 서비스에 대한 모든 세부 사항을 알 필요가 없다. @@ -28,52 +28,54 @@ weight: 50 ## 어떻게 동작하는가 쿠버네티스는 어드미션 컨트롤러(`PodPreset`)를 제공한다. 어드미션 컨트롤러가 활성화되면, -파드 프리셋을 파드 생성 요청에 적용한다. +파드 프리셋을 파드 생성 요청에 적용한다. 파드 생성 요청이 발생하면, 시스템은 다음의 내용을 수행한다. 1. 사용 가능한 모든 `PodPresets`을 검색한다. -1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는 - 것이 있는지 확인한다. -1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에 +1. `PodPreset`의 레이블 셀렉터들 중 하나라도 생성되는 파드의 레이블과 일치하는 + 것이 있는지 확인한다. +1. `PodPreset`에 의해서 정의된 다양한 리소스가 생성되는 파드에 병합되도록 시도한다. -1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로 - 부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다. -1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서 +1. 오류 시, 파드의 병합 오류를 문서화하는 이벤트를 발생시키고, `PodPreset`으로 + 부터 주입된 어떤 리소스도 _없이_ 파드를 생성한다. +1. 수정된 파드 스펙의 결과에 어노테이션을 달아 `PodPreset`에 의해서 수정되었음을 표시한다. 해당 어노테이션은 다음의 양식을 따른다. `podpreset.admission.kubernetes.io/podpreset-<파드-프리셋 이름>: "<리소스 버전>"`. -각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의 -파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을 -때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의 -변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을 +각 파드는 0개 이상의 파드 프리셋에 일치될 수 있고, 각 `PodPreset`은 0개 이상의 +파드에 적용될 수 있다. 하나의 `PodPreset`이 한 개 이상의 파드에 적용되었을 +때, 쿠버네티스는 해당 파드의 스펙을 수정한다. `Env`, `EnvFrom`, `VolumeMounts`의 +변경에 대해서는, 쿠버네티스가 파드 내의 모든 컨테이너의 컨테이너 스펙을 수정한다. `Volume` 변경에 대해서는, 쿠버네티스는 해당 파드의 스펙을 수정한다. {{< note >}} -파드 프리셋은 적절한 경우 파드 스펙의 `.spec.containers` 필드를 -수정할 수도 있다. 파드 프리셋으로부터의 리소스 정의 *없음* 은 `initContainers` -필드에 적용될 것이다. +파드 프리셋은 적절한 경우 파드 스펙의 다음 필드를 수정할 수도 있다. +- `.spec.containers` 필드 +- `initContainers` 필드(쿠버네티스 버전 1.14.0 이후에서 필요) {{< /note >}} ### 특정 파드의 파드 프리셋 비활성화하기 -어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가 -있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 +어떠한 파드 프리셋 변이에 의해서도 파드에 변경이 일어나지 않게 하고 싶은 경우가 +있을 것이다. 이 경우에는, 다음과 같은 양식으로 어노테이션을 파드 스펙에 추가한다. `podpreset.admission.kubernetes.io/exclude: "true"`. ## 파드 프리셋 활성화하기 클러스터에서 파드 프리셋을 사용하기 위해서는 다음 사항이 반드시 이행되어야 한다. -1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. - 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다. - minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` +1. API 타입 `settings.k8s.io/v1alpha1/podpreset`을 활성화하였다. + 예를 들면, 이것은 API 서버의 `--runtime-config` 옵션에 `settings.k8s.io/v1alpha1=true`을 포함하여 완료할 수 있다. + minikube에서는 클러스터가 시작할 때 + `--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` 플래그를 추가한다. -1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. 이것을 이루는 방법 중 하나는 +1. 어드미션 컨트롤러 `PodPreset`을 활성화하였다. + 이것을 이루는 방법 중 하나는 API 서버를 위해서 명시된 `--enable-admission-plugins` 옵션에 `PodPreset`을 포함하는 것이다. - minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset` + minikube에서는 클러스터가 시작할 때 `--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset` 플래그를 추가한다. -1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여 - 파드 프리셋을 정의하였다. +1. 사용할 네임스페이스 안에서 `PodPreset` 오브젝트를 생성하여 + 파드 프리셋을 정의하였다. {{% /capture %}} diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md index 093fe822cf..dc12e65839 100755 --- a/content/ko/docs/reference/glossary/container-env-variables.md +++ b/content/ko/docs/reference/glossary/container-env-variables.md @@ -2,11 +2,11 @@ title: 컨테이너 환경 변수(Container Environment Variables) id: container-env-variables date: 2018-04-12 -full_link: /ko/docs/concepts/containers/container-environment-variables.md +full_link: /ko/docs/concepts/containers/container-environment-variables/ short_description: > 컨테이너 환경 변수는 파드에서 동작 중인 컨테이너에 유용한 정보를 제공하기 위한 이름=값 쌍이다. -aka: +aka: tags: - fundamental --- @@ -14,4 +14,4 @@ tags: -컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다. +컨테이너 환경 변수는 중요한 리소스에 대한 정보와 함께 실행 중인 컨테이너화 된 애플리케이션이 요구하는 정보를 해당 {{< glossary_tooltip text="컨테이너" term_id="container" >}}에 제공한다. 예를 들면, 파일 시스템 상세 정보, 컨테이너 스스로에 대한 정보, 서비스 엔드포인트와 같은 다른 클러스터 리소스에 대한 정보 등이 있다. \ No newline at end of file diff --git a/content/ko/docs/reference/glossary/container-runtime.md b/content/ko/docs/reference/glossary/container-runtime.md new file mode 100644 index 0000000000..8a26ee8147 --- /dev/null +++ b/content/ko/docs/reference/glossary/container-runtime.md @@ -0,0 +1,21 @@ +--- +title: 컨테이너 런타임 +id: container-runtime +date: 2019-06-05 +full_link: /docs/reference/generated/container-runtime +short_description: > + 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다. + +aka: +tags: +- fundamental +- workload +--- + 컨테이너 런타임은 컨테이너 실행을 담당하는 소프트웨어이다. + + + +쿠버네티스느 여러 컨테이너 런타임을 지원한다. [Docker](http://www.docker.com), +[containerd](https://containerd.io), [cri-o](https://cri-o.io/), +[rktlet](https://github.com/kubernetes-incubator/rktlet)과 +[Kubernetes CRI (컨테이너 런타임 인터페이스)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md)를 구현한 모든 소프트웨어. diff --git a/content/ko/docs/reference/glossary/etcd.md b/content/ko/docs/reference/glossary/etcd.md index 2521590b6d..ea5a38d015 100644 --- a/content/ko/docs/reference/glossary/etcd.md +++ b/content/ko/docs/reference/glossary/etcd.md @@ -13,7 +13,10 @@ tags: --- 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소. - + -쿠버네티스 클러스터 정보를 담고 있는 etcd 데이터에 대한 백업 계획은 필수이다. etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다. +쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용한다면, +이 데이터를 [백업](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)하는 계획은 +필수이다. +etcd에 대한 자세한 정보는, [etcd 문서](https://github.com/coreos/etcd/blob/master/Documentation/docs.md)를 참고한다. diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md index 22f55677ae..5f8a4fc612 100755 --- a/content/ko/docs/reference/glossary/kube-proxy.md +++ b/content/ko/docs/reference/glossary/kube-proxy.md @@ -6,14 +6,17 @@ full_link: /docs/reference/generated/kube-proxy short_description: > `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. -aka: +aka: tags: - fundamental - core-object --- `kube-proxy`는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. - +이는 호스트의 네트워크 규칙을 관리하고 접속 포워딩을 수행하여 +쿠버네티스 서비스 추상화를 가능케 한다. + + `kube-proxy`는 요청에 대한 포워딩을 책임진다. `kube-proxy`는 TCP 및 UDP 스트림 포워딩을 허용하거나 TCP 및 UDP 포워딩을 백 엔드 기능 집합에 걸쳐 라운드 로빈을 제공한다. diff --git a/content/ko/docs/reference/glossary/node.md b/content/ko/docs/reference/glossary/node.md index 2fafe15d07..b92bd5468e 100755 --- a/content/ko/docs/reference/glossary/node.md +++ b/content/ko/docs/reference/glossary/node.md @@ -4,15 +4,14 @@ id: node date: 2018-04-12 full_link: /docs/concepts/architecture/nodes/ short_description: > - 노드는 쿠버네티스의 워커 머신이다. + 노드는 쿠버네티스의 작업 장비(worker machine)이다. -aka: +aka: tags: - fundamental --- - 노드는 쿠버네티스의 워커 머신이다. + 노드는 쿠버네티스의 작업 장비(worker machine)이다. - - -워커 머신은 클러스터에 따라 VM이거나 물리 머신일 것이다. 그것은 실행해야 하는 {{< glossary_tooltip text="서비스" term_id="service" >}}와 {{< glossary_tooltip text="파드" term_id="pod" >}}를 가지고 있으며, 마스터 컴포넌트에 의해서 관리된다. 노드에 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}는 Docker, kubelet, kube-proxy를 포함한다. + +작업 노드는 클러스터에 따라 VM이거나 물리 머신일 것이다. {{< glossary_tooltip text="파드" term_id="pod" >}} 실행에 필요한 로컬 데몬과 서비스를 가지고 있으며, 콘트롤 플레인에 의해서 관리된다. 노드에 있는 데몬은 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}, {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}와 {{< glossary_tooltip term_id="docker" >}} 같이 컨테이너 런타임을 구현한 {{< glossary_tooltip text="CRI" term_id="cri" >}}를 포함한다. diff --git a/content/ko/docs/reference/glossary/service.md b/content/ko/docs/reference/glossary/service.md index 3034640c5a..65a0d17787 100755 --- a/content/ko/docs/reference/glossary/service.md +++ b/content/ko/docs/reference/glossary/service.md @@ -4,16 +4,15 @@ 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 오브젝트이며, 포트와 로드밸런서를 기술할 수 있다. +{{< glossary_tooltip text="파드" term_id="pod" >}} 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법 - - -엑세스 포인트는 클러스터의 내부이거나 외부일 수 있다. + +서비스의 대상이 되는 파드 집합은 (보통) {{< glossary_tooltip text="셀렉터" term_id="selector" >}}로 결정된다. 많은 파드가 추가되거나 제거되면, 셀렉터와 일치하는 파드의 집합도 변경된다. 서비스는 네트워크 트래픽을 현재 워크로드를 위한 파드 집합으로 보낼 수 있는지 확인한다. diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index 21a79f6775..a8693e3b58 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -1,76 +1,106 @@ --- no_issue: true -title: 설치 +title: 시작하기 main_menu: true -weight: 30 +weight: 20 content_template: templates/concept +card: + name: setup + weight: 20 + anchors: + - anchor: "#학습-환경" + title: 학습 환경 + - anchor: "#운영-환경" + title: 운영 환경 --- {{% capture overview %}} -니즈에 가장 적합한 솔루션 유형을 찾기 위해서는 이 페이지를 사용하길 바란다. +본 섹션에서는 쿠버네티스를 구축하고 실행하는 여러가지 옵션을 다룬다. -쿠버네티스를 어디에서 동작시킬지 결정하는 것은 가용한 자원과 요구되는 유연성의 정도에 의존적이다. 쿠버네티스는 랩톱부터, 클라우드 프로바이더의 VM, 베어메탈(bare metal) 서버로 이루어진 랙까지 거의 모든 곳에서 동작시킬 수 있다. 또한 단 하나의 명령어 실행으로 완전-관리되는(fully-managed) 클러스터를 설치할 수도 있고, 베어메탈 서버에 자신만의 맞춤형 클러스터를 만들 수도 있다. +각각의 쿠버네티스 솔루션은 유지보수의 용이성, 보안, 제어, 가용 자원, 클러스터를 운영하고 관리하기 위해 필요한 전문성과 같은 제각각의 요구사항을 충족한다. + +쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 넓은 범위의 클라우드 프로바이더에 걸치거나 베어 메탈 환경을 사용하는 커스텀 솔루션을 만들 수도 있다. + +더 간단하게 정리하면, 쿠버네티스 클러스터를 학습 환경과 운영 환경에 만들 수 있다. {{% /capture %}} {{% capture body %}} -## 로컬 머신(Local-machine) 솔루션 +## 학습 환경 -로컬 머신 솔루션은 쿠버네티스를 시작하기에 쉬운 방법이다. 클라우드 자원(resource)과 한도(quota)에 대한 걱정 없이 쿠버네티스 클러스터를 생성하고 테스트할 수 있다. +쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구와 같은 도커 기반의 솔루션을 사용하자. -다음과 같은 사항을 원한다면 로컬 솔루션을 선택해야 한다. +{{< table caption="쿠버네티스를 배포하기 위해 커뮤니티와 생태계에서 지원하는 도구를 나열한 로컬 머신 솔루션 표." >}} -* 쿠버네티스를 써 보거나 배우기 시작하려고 함 -* 내부적으로 클러스터를 개발하거나 테스트하려고 함 +|커뮤니티 |생태계 | +| ------------ | -------- | +| [Minikube](/docs/setup/learning-environment/minikube/) | [CDK on LXD](https://www.ubuntu.com/kubernetes/docs/install-local) | +| [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) | [Docker Desktop](https://www.docker.com/products/docker-desktop)| +| [Kubernetes IN Docker](https://github.com/kubernetes-sigs/kind) | [Minishift](https://docs.okd.io/latest/minishift/)| +| | [MicroK8s](https://microk8s.io/)| +| | [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) | +| | [IBM Cloud Private-CE (Community Edition) on Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers)| +| | [k3s](https://k3s.io)| +| | [Ubuntu on LXD](/docs/getting-started-guides/ubuntu/)| -[로컬 머신 솔루션](/docs/setup/pick-right-solution/#local-machine-solutions) 중 하나를 선택하길 바란다. -## 호스트 된(Hosted) 솔루션 +## 운영 환경 -호스트 된 솔루션은 쿠버네티스 클러스터를 생성하고 유지 관리하는데 편리한 방법이다. 호스트가 사용자의 클러스터를 관리하고 운영하기 때문에 사용자는 관리와 운영에서 자유롭다. +운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자. -다음의 경우 호스트 된 솔루션이 필요하다. +몇 가지 가능한 쿠버네티스 클러스터의 추상적인 개념은 {{< glossary_tooltip text="애플리케이션" term_id="applications" >}}, {{< glossary_tooltip text="데이터 플레인" term_id="data-plane" >}}, {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}, {{< glossary_tooltip text="클러스터 인프라스트럭처" term_id="cluster-infrastructure" >}}, 및 {{< glossary_tooltip text="클러스터 운영" term_id="cluster-operations" >}}이다. -* 완전히 관리된 솔루션을 원함 -* 사용자의 앱 또는 서비스를 개발에만 집중하고 싶음 -* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀은 없지만 고가용성을 원함 -* 클러스터를 호스팅하고 모니터할 자원이 없음 +다음의 다이어그램은 쿠버네티스 클러스터에 대해 가능한 추상적인 개념을 나열하고, 각 추상적인 개념을 사용자 스스로 관리하는지 제공자에 의해 관리되는지를 보여준다. -[호스트 된 솔루션](/docs/setup/pick-right-solution/#hosted-solutions) 중 하나를 선택하길 바란다. +운영 환경 솔루션![운영 환경 솔루션](/images/docs/KubernetesSolutions.svg) -## 턴키(Turnkey) – 클라우드 솔루션 +{{< table caption="제공자와 솔루션을 나열한 운영 환경 솔루션 표." >}} +다음 운영 환경 솔루션 표는 제공자와 솔루션을 나열한다. -이와 같은 솔루션들은 쿠버네티스 클러스터를 단지 몇 가지 명령어로 생성하게 해준다. 솔루션들은 활발히 개발되며 활동적인 커뮤니티의 지원을 받는다. 또한 넓은 범위의 IaaS 클라우드 프로바이더들에 호스트 될 수 있음에도, 노력의 대가로 솔루션들은 더욱 더 큰 자유와 유연성을 제공한다. - -다음의 경우 턴키 클라우드 솔루션을 선택해야 한다. - -* 호스트 된 솔루션이 허용하는 것보다는 클러스터에 대한 더 높은 제어권을 원함 -* 운영에 대한 더 큰 소유권을 가지고 싶음 - -[턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#turnkey-cloud-solutions) 중 하나를 선택하길 바란다. - -## 턴키(Turnkey) – 온-프레미스(On-Premise) 솔루션 - -이와 같은 솔루션들은 내부의, 안전한, 클라우드 네트워크에 쿠버네티스 클러스터를 단 몇 가지 명령어로 생성하게 해준다. - -다음의 경우 온-프레미스 턴키 솔루션을 선택해야 한다. - -* 프라이빗 클라우드 네트워크에 클러스터를 디플로이하길 원함 -* 지정된 사이트 신뢰성 엔지니어링(SRE) 팀을 보유함 -* 클러스터를 호스팅하고 모니터할 수 있는 자원을 보유함 - -[온-프레미스 턴키 클라우드 솔루션](/docs/setup/pick-right-solution/#on-premises-turnkey-cloud-solutions) 중 하나를 선택하길 바란다. - -## 사용자 지정(Custom) 솔루션 - -사용자 지정 솔루션들은 클러스터에 대해서 가장 큰 자유를 제공하지만, 그 대신 높은 전문성을 필요로 한다. 이 솔루션들은 서로 다른 운영체제들에 대해서 베어메탈부터 클라우드 프로바이더들까지의 지원을 포함한다. - -[사용자 지정 솔루션](/docs/setup/pick-right-solution/#custom-solutions) 중 하나를 선택하길 바란다. +|제공자 | 매니지드 | 턴키 클라우드 | 온-프렘(on-prem) 데이터센터 | 커스텀 (클라우드) | 커스텀 (온-프레미스 VMs)| 커스텀 (베어 메탈) | +| --------- | ------ | ------ | ------ | ------ | ------ | ----- | +| [Agile Stacks](https://www.agilestacks.com/products/kubernetes)| | ✔ | ✔ | | | +| [Alibaba Cloud](https://www.alibabacloud.com/product/kubernetes)| | ✔ | | | | +| [Amazon](https://aws.amazon.com) | [Amazon EKS](https://aws.amazon.com/eks/) |[Amazon EC2](https://aws.amazon.com/ec2/) | | | | +| [AppsCode](https://appscode.com/products/pharmer/) | ✔ | | | | | +| [APPUiO](https://appuio.ch/)  | ✔ | ✔ | ✔ | | | | +| [CenturyLink Cloud](https://www.ctl.io/) | | ✔ | | | | +| [Cisco Container Platform](https://cisco.com/go/containers) | | | ✔ | | | +| [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) | | | | ✔ |✔ | +| [CloudStack](https://cloudstack.apache.org/) | | | | | ✔| +| [Canonical](https://www.ubuntu.com/kubernetes/docs/quickstart) | | ✔ | | ✔ |✔ | ✔ +| [Containership](https://containership.io/containership-platform) | ✔ |✔ | | | | +| [Digital Rebar](https://provision.readthedocs.io/en/tip/README.html) | | | | | | ✔ +| [DigitalOcean](https://www.digitalocean.com/products/kubernetes/) | ✔ | | | | | +| [Docker Enterprise](https://www.docker.com/products/docker-enterprise) | |✔ | ✔ | | | ✔ +| [Fedora (멀티 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/)  | | | | | ✔ | ✔ +| [Fedora (단일 노드)](https://kubernetes.io/docs/getting-started-guides/fedora/fedora_manual_config/)  | | | | | | ✔ +| [Gardner](https://gardener.cloud/) | |✔ | | ✔ | | +| [Giant Swarm](https://giantswarm.io/) | ✔ | ✔ | ✔ | | +| [Google](https://cloud.google.com/) | [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/) | [Google Compute Engine (GCE)](https://cloud.google.com/compute/)|[GKE On-Prem](https://cloud.google.com/gke-on-prem/) | | | | | | | | +| [IBM](https://www.ibm.com/in-en/cloud) | [IBM Cloud Kubernetes Service](https://cloud.ibm.com/kubernetes/catalog/cluster)| |[IBM Cloud Private](https://www.ibm.com/in-en/cloud/private) | | +| [Kontena Pharos](https://www.kontena.io/pharos/) | |✔| ✔ | | | +| [Kubermatic](https://www.loodse.com/) | ✔ | ✔ | ✔ | | | +| [KubeSail](https://kubesail.com/) | ✔ | | | | | +| [Kubespray](https://kubespray.io/#/) | | | |✔ | ✔ | ✔ | +| [Kublr](https://kublr.com/) |✔ | ✔ |✔ |✔ |✔ |✔ | +| [Microsoft Azure](https://azure.microsoft.com) | [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/services/kubernetes-service/) | | | | | +| [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) | | | ✔ | | | +| [Nirmata](https://www.nirmata.com/) | | ✔ | ✔ | | | +| [Nutanix](https://www.nutanix.com/en) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | [Nutanix Karbon](https://www.nutanix.com/products/karbon) | | | [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization) | +| [OpenShift](https://www.openshift.com) |[OpenShift Dedicated](https://www.openshift.com/products/dedicated/) and [OpenShift Online](https://www.openshift.com/products/online/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) | | [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) |[OpenShift Container Platform](https://www.openshift.com/products/container-platform/) +| [Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)](https://docs.cloud.oracle.com/iaas/Content/ContEng/Concepts/contengoverview.htm) | ✔ | ✔ | | | | +| [oVirt](https://www.ovirt.org/) | | | | | ✔ | +| [Pivotal](https://pivotal.io/) | | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | [Enterprise Pivotal Container Service (PKS)](https://pivotal.io/platform/pivotal-container-service) | | | +| [Platform9](https://platform9.com/) | ✔ | ✔ | ✔ | | ✔ |✔ +| [Rancher](https://rancher.com/) | | [Rancher 2.x](https://rancher.com/docs/rancher/v2.x/en/) | | [Rancher Kubernetes Engine (RKE)](https://rancher.com/docs/rke/latest/en/) | | [k3s](https://k3s.io/) +| [StackPoint](https://stackpoint.io/)  | ✔ | ✔ | | | | +| [Supergiant](https://supergiant.io/) | |✔ | | | | +| [SUSE](https://www.suse.com/) | | ✔ | | | | +| [SysEleven](https://www.syseleven.io/) | ✔ | | | | | +| [VEXXHOST](https://vexxhost.com/) | ✔ | ✔ | | | | +| [VMware](https://cloud.vmware.com/) | [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) |[VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Enterprise PKS](https://cloud.vmware.com/vmware-enterprise-pks) | [VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) | |[VMware Essential PKS](https://cloud.vmware.com/vmware-essential-pks) {{% /capture %}} - -{{% capture whatsnext %}} -완전한 솔루션 리스트를 확인하기 위해서는 [올바른 솔루션 선택하기](/docs/setup/pick-right-solution/)로 가길 바란다. -{{% /capture %}} diff --git a/content/ko/docs/setup/best-practices/_index.md b/content/ko/docs/setup/best-practices/_index.md new file mode 100644 index 0000000000..844e41a352 --- /dev/null +++ b/content/ko/docs/setup/best-practices/_index.md @@ -0,0 +1,4 @@ +--- +title: 모범 사례 +weight: 40 +--- diff --git a/content/ko/docs/setup/certificates.md b/content/ko/docs/setup/best-practices/certificates.md similarity index 88% rename from content/ko/docs/setup/certificates.md rename to content/ko/docs/setup/best-practices/certificates.md index 7b9630c282..0d833c95d8 100644 --- a/content/ko/docs/setup/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -1,6 +1,7 @@ --- title: PKI 인증서 및 요구 조건 content_template: templates/concept +weight: 40 --- {{% capture overview %}} @@ -84,15 +85,15 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. | 기본 CN | 권고되는 키 파일 경로 | 권고하는 인증서 파일 경로 | 명령어 | 키 파라미터 | 인증서 파라미터 | |------------------------------|------------------------------|-----------------------------|----------------|------------------------------|-------------------------------------------| -| etcd-ca | | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | | etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | -| kubernetes-ca | | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | | kube-apiserver | apiserver.key | apiserver.crt | kube-apiserver | --tls-private-key-file | --tls-cert-file | -| apiserver-kubelet-client | | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate | -| front-proxy-ca | | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt| kube-apiserver | | --kubelet-client-certificate | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | | front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | | | | | | | | -| etcd-ca | | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | +| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file, --peer-trusted-ca-file | | kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | | kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | | etcd-ca | | etcd/ca.crt | etcdctl[2] | | --cacert | @@ -128,12 +129,12 @@ KUBECONFIG= kubectl config use-context default-system 이 파일들은 다음과 같이 사용된다. -| 파일명 | 명령어 | 설명 | +| 파일명 | 명령어 | 설명 | |-------------------------|-------------------------|-----------------------------------------------------------------------| -| admin.conf | kubectl | 클러스터 관리자를 설정한다. | -| kubelet.conf | kubelet | 클러스터 각 노드를 위해 필요하다. | +| admin.conf | kubectl | 클러스터 관리자를 설정한다. | +| kubelet.conf | kubelet | 클러스터 각 노드를 위해 필요하다. | | controller-manager.conf | kube-controller-manager | 반드시 매니페스트를 `manifests/kube-controller-manager.yaml`에 추가해야한다. | -| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. | +| scheduler.conf | kube-scheduler | 반드시 매니페스트를 `manifests/kube-scheduler.yaml`에 추가해야한다. | [usage]: https://godoc.org/k8s.io/api/certificates/v1beta1#KeyUsage [kubeadm]: /docs/reference/setup-tools/kubeadm/kubeadm/ diff --git a/content/ko/docs/setup/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md similarity index 99% rename from content/ko/docs/setup/cluster-large.md rename to content/ko/docs/setup/best-practices/cluster-large.md index 5463923ba2..d227f66662 100644 --- a/content/ko/docs/setup/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -1,6 +1,6 @@ --- title: 대형 클러스터 구축 -weight: 80 +weight: 20 --- ## 지원 diff --git a/content/ko/docs/setup/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md similarity index 99% rename from content/ko/docs/setup/multiple-zones.md rename to content/ko/docs/setup/best-practices/multiple-zones.md index 8b9804cc0e..d9ef519878 100644 --- a/content/ko/docs/setup/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -1,6 +1,6 @@ --- title: 여러 영역에서 구동 -weight: 90 +weight: 10 content_template: templates/concept --- diff --git a/content/ko/docs/setup/node-conformance.md b/content/ko/docs/setup/best-practices/node-conformance.md similarity index 99% rename from content/ko/docs/setup/node-conformance.md rename to content/ko/docs/setup/best-practices/node-conformance.md index 3af869d905..7e3e62dfa1 100644 --- a/content/ko/docs/setup/node-conformance.md +++ b/content/ko/docs/setup/best-practices/node-conformance.md @@ -1,5 +1,6 @@ --- title: 노드 구성 검증하기 +weight: 30 --- {{< toc >}} diff --git a/content/ko/docs/setup/custom-cloud/_index.md b/content/ko/docs/setup/custom-cloud/_index.md deleted file mode 100644 index 5ddaaf3f3f..0000000000 --- a/content/ko/docs/setup/custom-cloud/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: 사용자 지정 클라우드 솔루션 -weight: 50 ---- diff --git a/content/ko/docs/setup/independent/_index.md b/content/ko/docs/setup/independent/_index.md deleted file mode 100755 index e87c318721..0000000000 --- a/content/ko/docs/setup/independent/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "kubeadm으로 클러스터 부트스트래핑 하기" -weight: 30 ---- - diff --git a/content/ko/docs/setup/learning-environment/_index.md b/content/ko/docs/setup/learning-environment/_index.md new file mode 100644 index 0000000000..cd7005bf79 --- /dev/null +++ b/content/ko/docs/setup/learning-environment/_index.md @@ -0,0 +1,4 @@ +--- +title: 학습 환경 +weight: 20 +--- diff --git a/content/ko/docs/setup/minikube.md b/content/ko/docs/setup/learning-environment/minikube.md similarity index 56% rename from content/ko/docs/setup/minikube.md rename to content/ko/docs/setup/learning-environment/minikube.md index dc43fad420..510013d88c 100644 --- a/content/ko/docs/setup/minikube.md +++ b/content/ko/docs/setup/learning-environment/minikube.md @@ -1,11 +1,11 @@ --- -title: Minikube로 로컬 상에서 쿠버네티스 구동 -content_template: templates/concept +title: Minikube로 쿠버네티스 설치 +content_template: templates/concept --- {{% capture overview %}} -Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 VM 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. +Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Minikube는 매일 쿠버네티스를 사용하거나 개발하려는 사용자들을 위해 가상 머신(VM) 이나 노트북에서 단일 노드 쿠버네티스 클러스터를 실행한다. {{% /capture %}} @@ -13,14 +13,15 @@ Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Mi ## Minikube 특징 -* Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. - * DNS - * 노드 포트 - * 컨피그 맵과 시크릿 - * 대시보드 - * 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd) - * CNI(Container Network Interface) 사용 - * 인그레스 +Minikube는 다음과 같은 쿠버네티스의 기능을 제공한다. + +* DNS +* 노드 포트 +* 컨피그 맵과 시크릿 +* 대시보드 +* 컨테이너 런타임: Docker, [rkt](https://github.com/rkt/rkt), [CRI-O](https://github.com/kubernetes-incubator/cri-o) 와 [containerd](https://github.com/containerd/containerd) +* CNI(Container Network Interface) 사용 +* 인그레스 ## 설치 @@ -28,123 +29,183 @@ Minikube는 쿠버네티스를 로컬에서 쉽게 실행하는 도구이다. Mi ## 빠른 시작 -여기부터는 Minikube 사용에 대한 간단한 데모이다. -VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를 `minikube start`에 추가한다. -Minikube는 다음의 드라이버를 지원한다. +여기서 기술하는 간단한 데모는 어떻게 로컬에서 Minikube를 시작하고, 사용하고 삭제하는지를 안내한다. 다음의 주어진 단계를 따라서 Minikube를 시작하고 탐구한다. + +1. Minikube를 시작하고 클러스터를 생성 + ```shell + minikube start + ``` + 결과는 다음과 비슷하다. + + ``` + Starting local Kubernetes cluster... + Running pre-create checks... + Creating machine... + Starting local Kubernetes cluster... + ``` + 특정 쿠버네티스 버전, VM, 컨테이너 런타임 상에서 클러스터를 시작하기 위한 보다 상세한 정보는 [클러스터 시작하기](#클러스터-시작하기)를 참조한다. + +2. 이제, kubectl을 통해서 클러스터와 상호작용할 수 있다. 보다 상세한 정보는 [클러스터와 상호 작용하기](#클러스터와-상호-작용하기)를 참조한다. + + 단순한 HTTP 서버인 `echoserver` 이미지를 사용해서 쿠버네티스 디플로이먼트를 만들고 `--port`를 이용해서 8080 포트로 노출해보자. + ```shell + kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 + ``` + 결과는 다음과 비슷하다. + ``` + deployment.apps/hello-minikube created + ``` +3. `hello-minikube` 디플로이먼트에 액세스하기 위해, 서비스로 노출시킨다. + ```shell + kubectl expose deployment hello-minikube --type=NodePort + ``` + `--type=NodePort` 옵션은 서비스 타입을 지정한다. + + 결과는 다음과 비슷하다. + ``` + service/hello-minikube exposed + ``` +4. `hello-minikube` 파드가 이제 시작되었지만 노출된 서비스를 통해서 접근하기 전에 파드가 뜨기를 기다려야한다. + + 파드가 떠서 구동되고 있는지 확인한다. + ```shell + kubectl get pod + ``` + 출력에서 `STATUS`가 `ContainerCreating`으로 나타나는 경우, 파드는 아직 생성 중이다. + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s + ``` + 출력에서 `STATUS`가 `Running`으로 나타나는 경우, 파드는 이제 떠서 기동 중이다. + ``` + NAME READY STATUS RESTARTS AGE + hello-minikube-3383150820-vctvh 1/1 Running 0 13s + ``` +5. 서비스 상세를 보기 위해서 노출된 서비스의 URL을 얻는다. + ```shell + minikube service hello-minikube --url + ``` +6. 로컬 클러스터의 상세를 보기위해서, 출력에서 얻은 URL을 브라우저에 복사해서 붙여 넣는다. + + 출력은 다음과 비슷하다. + ``` + Hostname: hello-minikube-7c77b68cff-8wdzq + + Pod Information: + -no pod information available- + + Server values: + server_version=nginx: 1.13.3 - lua: 10008 + + Request Information: + client_address=172.17.0.1 + method=GET + real path=/ + query= + request_version=1.1 + request_scheme=http + request_uri=http://192.168.99.100:8080/ + + Request Headers: + accept=*/* + host=192.168.99.100:30674 + user-agent=curl/7.47.0 + + Request Body: + -no body in request- + ``` + 서비스나 클러스터가 더 이상 구동되지 않도록 하려면, 삭제한다. +7. `hello-minikube` 서비스 삭제 + ```shell + kubectl delete services hello-minikube + ``` + 출력은 다음과 비슷하다. + ``` + service "hello-minikube" deleted + ``` +8. `hello-minikube` 디플로이먼트 삭제 + ```shell + kubectl delete deployment hello-minikube + ``` + 출력은 다음과 비슷하다. + ``` + deployment.extensions "hello-minikube" deleted + ``` +9. 로컬 Minikube 클러스터 중지 + ```shell + minikube stop + ``` + 출력은 다음과 비슷하다. + ``` + Stopping "minikube"... + "minikube" stopped. + ``` + 보다 상세한 정보는 [클러스터 중지하기](#클러스터-중지하기)를 참조한다. +10. 로컬 Minikube 클러스터 삭제 + ```shell + minikube delete + ``` + 출력은 다음과 비슷하다. + ``` + Deleting "minikube" ... + The "minikube" cluster has been deleted. + ``` + 보다 상세한 정보는 [Deleting a cluster](#클러스터-삭제하기)를 참조한다. + +## 클러스터 관리하기 + +### 클러스터 시작하기 + +클러스터를 시작하기 위해서 `minikube start` 커멘드를 사용할 수 있다. +이 커멘드는 단일 노드 쿠버네티스 클러스터를 구동하는 가상 머신을 생성하고 구성한다. +이 커멘드는 또한 [kubectl](/docs/user-guide/kubectl-overview/)도 설정해서 클러스터와 통신할 수 있도록 한다. + +{{< note >}} +웹 프록시 뒤에 있다면, `minikube start` 커맨드에 해당 정보를 전달해야 한다. + +```shell +https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 +``` +불행하게도, 환경 변수 설정만으로는 되지 않는다. + +Minikube는 또한 "minikube" 컨텍스트를 생성하고 이를 kubectl의 기본값으로 설정한다. +이 컨텍스트로 돌아오려면, 다음의 코멘드를 입력한다. `kubectl config use-context minikube`. +{{< /note >}} + +#### 쿠버네티스 버전 지정하기 + +`minikube start` 코멘드에 `--kubernetes-version` 문자열을 +추가해서 Minikube에서 사용할 쿠버네티스 버전을 지정할 수 있다. +예를 들어 버전 {{< param "fullversion" >}}를 구동하려면, 다음과 같이 실행한다. + +``` +minikube start --kubernetes-version {{< param "fullversion" >}} +``` +#### VM 드라이버 지정하기 +`minikube start` 코멘드에 `--vm-driver=` 플래그를 추가해서 VM 드라이버를 변경할 수 있다. +코멘드를 예를 들면 다음과 같다. +```shell +minikube start --vm-driver= +``` + Minikube는 다음의 드라이버를 지원한다. + {{< note >}} + 지원되는 드라이버와 플러그인 설치 방법에 대한 보다 상세한 정보는 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 참조한다. +{{< /note >}} * virtualbox * vmwarefusion -* kvm2 ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) -* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) -* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) -아래 나오는 IP주소는 동적이고 변할 수 있음을 알린다. 이는 `minikube ip` 명령으로 확인할 수 있다. -* vmware ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) -* none (쿠버네티스 구성요소는 VM이 아닌 호스트상에서 동작한다. 이 드라이버를 사용하기 위해서는 Docker ([docker 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))와 리눅스 환경)이 필요하다. - -```shell -minikube start -``` -``` -Starting local Kubernetes cluster... -Running pre-create checks... -Creating machine... -Starting local Kubernetes cluster... -``` -```shell -kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.10 --port=8080 -``` -``` -deployment.apps/hello-minikube created -``` - -```shell -kubectl expose deployment hello-minikube --type=NodePort -``` -``` -service/hello-minikube exposed -``` - -에코 서버 파드를 실행했지만 노출된 서비스를 통해 curl 등의 접근하기 전에 -파드가 올라갈 때까지 기다려야 한다. -파드가 실행 중인지 확인하기 위해 다음을 이용할 수 있다. - -``` -kubectl get pod -``` -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s -``` - -이 파드는 ContainerCreating 상태임을 알 수 있다. -kubectl get pod - -``` -NAME READY STATUS RESTARTS AGE -hello-minikube-3383150820-vctvh 1/1 Running 0 13s -``` - -이제 파드가 Running 상태이므로 curl를 실행해 볼 수 있다. - -``` -curl $(minikube service hello-minikube --url) -``` -``` - -Hostname: hello-minikube-7c77b68cff-8wdzq - -Pod Information: - -no pod information available- - -Server values: - server_version=nginx: 1.13.3 - lua: 10008 - -Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ - -Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - -Request Body: - -no body in request- -``` - -```shell -kubectl delete services hello-minikube -``` -``` -service "hello-minikube" deleted -``` - -```shell -kubectl delete deployment hello-minikube -``` -``` -deployment.extensions "hello-minikube" deleted -``` - -```shell -minikube stop -``` -``` -Stopping local Kubernetes cluster... -Stopping "minikube"... -``` - -### 다른 컨테이너 런타임 - -#### containerd +* kvm2 ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#kvm2-driver)) +* hyperkit ([드라이버 설치](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver)) +* hyperv ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver)) +다음 IP는 동적이며 변경할 수 있다. `minikube ip`로 알아낼 수 있다. +* vmware ([드라이버 설치](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#vmware-unified-driver)) (VMware unified driver) +* none (쿠버네티스 컴포넌트를 VM이 아닌 호스트 상에서 구동한다. 이 드라이버를 사용하려면 도커와 리눅스 환경이 필요하다.([도커 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))) +#### 대안적인 컨테이너 런타임 상에서 클러스터 시작하기 +Minikube를 다음의 컨테이너 런타임에서 기동할 수 있다. +{{< tabs name="container_runtimes" >}} +{{% tab name="containerd" %}} [containerd](https://github.com/containerd/containerd)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. - ```bash minikube start \ --network-plugin=cni \ @@ -164,9 +225,8 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ --bootstrapper=kubeadm ``` - -#### CRI-O - +{{% /tab %}} +{{% tab name="CRI-O" %}} [CRI-O](https://github.com/kubernetes-incubator/cri-o)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```bash @@ -176,7 +236,6 @@ minikube start \ --container-runtime=cri-o \ --bootstrapper=kubeadm ``` - 혹은 확장 버전을 사용할 수 있다. ```bash @@ -188,9 +247,8 @@ minikube start \ --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ --bootstrapper=kubeadm ``` - -#### rkt 컨테이너 엔진 - +{{% /tab %}} +{{% tab name="rkt container engine" %}} [rkt](https://github.com/rkt/rkt)를 컨테이너 런타임으로 사용하려면, 다음을 실행한다. ```shell @@ -199,37 +257,38 @@ minikube start \ --enable-default-cni \ --container-runtime=rkt ``` - 이것은 rkt와 Docker와 CNI 네트워킹을 포함하는 대안적인 Minikube ISO 이미지를 이용한다. +{{% /tab %}} +{{< /tabs >}} -### 드라이버 플러그인 +#### Docker 데몬 재사용을 통한 로컬 이미지 사용하기 -지원하는 드라이버 상세 정보와 설치방법은 [드라이버](https://git.k8s.io/minikube/docs/drivers.md)를 살펴보자 -꼭 필요하다면 말이다. +쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 도커 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 도커 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 도커 데몬 안에서 이미지를 빌드하기 때문이다. -### Docker 데몬 재사용 +{{< note >}} +Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. +{{< /note >}} -쿠버네티스 단일 VM을 사용하면 Minikube에 내장된 Docker 데몬을 재사용하기에 매우 간편하다. 이 경우는 호스트 장비에 Docker 레지스트리를 설치하고 이미지를 푸시할 필요가 없다. 또 로컬에서 빠르게 실행할 수 있는데 이는 Minikube와 동일한 Docker 데몬 안에서 이미지를 빌드하기 때문이다. Docker 이미지를 'latest'가 아닌 다른 태그로 태그했는지 확인하고 이미지를 풀링할 때에는 그 태그를 이용한다. 혹시 이미지 태그 버전을 지정하지 않았다면, 기본값은 `:latest`이고 이미지 풀링 정책은 `Always`가 가정하나, 만약 기본 Docker 레지스트리(보통 DockerHub)에 해당 Docker 이미지 버전이 없다면 `ErrImagePull`의 결과가 나타날 것이다. - -맥이나 리눅스 호스트의 Docker 데몬에서 이 작업이 가능하게 하려면 `docker-env command`를 쉘에서 사용해야 한다. +맥이나 리눅스 호스트에서 해당 Docker 데몬을 사용하려면 `docker-env command`를 쉘에서 사용해야 한다. ```shell eval $(minikube docker-env) ``` -맥이나 리눅스 호스트에서 Minikube VM안에 Docker 데몬과 통신하도록 Docker를 명령행에서 사용할 수 있어야 한다. +이제 개인의 맥/리눅스 머신 내 커멘드 라인에서 도커를 사용해서 Minikube VM 안의 도커 데몬과 통신할 수 있다. ```shell docker ps ``` +{{< note >}} Centos 7 에서 Docker는 아래와 같은 오류를 발생한다. -```shell +``` Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory ``` -해결 방법은 /etc/sysconfig/docker를 Minikube의 환경 변화를 기대한 것대로 바꾸도록 업데이트하는 것이다. +/etc/sysconfig/docker를 업데이트하고 Minikube의 환경에 변경이 반영되었는지 확인해서 고칠 수 있다. ```shell < DOCKER_CERT_PATH=/etc/docker @@ -238,39 +297,9 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no > DOCKER_CERT_PATH=/etc/docker > fi ``` +{{< /note >}} -imagePullPolicy:Always를 꺼야하는 것은 명심하자. 그렇지 않으면 쿠버네티스가 로컬에서 빌드한 이미지를 사용하지 않는다. - -## 클러스터 관리 - -### 클러스터 시작 - -`minikube start` 명령은 클러스터를 시작하는데 사용할 수 있다. -이 명령은 단일 노드 쿠버네티스 클러스터를 실행하는 가상머신을 생성하고 구성한다. -또한 클러스터와 통신하기 위해 [kubectl](/docs/user-guide/kubectl-overview/)를 구성한다. - -만약 웹 프록시를 사용 중이라면 `minikube start` 명령에서 이 정보를 포함해야 한다. - -```shell -https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 -``` - -불행히 환경 설정 변수만으로는 동작하지 않는다. - -Minikube는 또한 "minikube" 컨텍스트를 생성하고, kubectl의 기본값으로 설정한다. -나중에 이 컨택스트를 변경하려면, `kubectl config use-context minikube` 명령을 실행하자. - -#### 쿠버네티스 버전 지정 - -Minikube에서 사용할 쿠버네티스 버전은 `--kubernetes-version` 문자열을 -`minikube start` 명령에 추가하여 지정할 수 있다. -예를 들어, `v1.7.3`을 이용한다면 아래처럼 할 수 있다. - -``` -minikube start --kubernetes-version v1.7.3 -``` - -### 쿠버네티스 구성 +### 쿠버네티스 구성하기 Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설정할 수 있도록 하는 '설정기' 기능이 있다. 이 기능을 사용하려면, `--extra-config` 플래그를 `minikube start` 명령어에 추가하여야 한다. @@ -307,18 +336,18 @@ Minikube는 사용자가 쿠버네티스 컴포넌트를 다양한 값으로 설 `minikube delete` 명령은 클러스터를 삭제하는데 사용할 수 있다. 이 명령어는 Minikube 가상 머신을 종료하고 삭제한다. 어떤 데이터나 상태도 보존되지 않다. -## 클러스터와 상호 작용 +## 클러스터와 상호 작용하기 ### Kubectl -`minikube start` 명령어는 Minikube로 부르는 "[kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)" 를 생성한다. +`minikube start` 명령어는 Minikube로 부르는 [kubectl 컨텍스트](/docs/reference/generated/kubectl/kubectl-commands/#-em-set-context-em-)를 생성한다. 이 컨텍스트는 Minikube 클러스터와 통신하는 설정을 포함한다. Minikube는 이 컨텍스트를 자동적으로 기본으로 설정한다. 만약 미래에 이것을 바꾸고 싶다면 `kubectl config use-context minikube`을 실행하자. -혹은 각 명령어를 `kubectl get pods --context=minikube`처럼 컨텍스트를 전달하십시오. +혹은 `kubectl get pods --context=minikube`처럼 코멘드를 실행할때마다 매번 컨텍스트를 전달한다. ### 대시보드 @@ -400,7 +429,7 @@ Minikube와 함께 시작하려는 애드온을 `~/.minikube/addons` 디렉터 폴더 내부의 애드온은 Minikube VM으로 이동되어 Minikube가 시작하거나 재시작될 때에 함께 실행된다. -## HTTP 프록시 환경에서 Minikube 사용 +## HTTP 프록시 환경에서 Minikube 사용하기 Minikube는 쿠버네티스와 Docker 데몬을 포함한 가상 머신을 생성한다. 쿠버네티스가 Docker를 이용하여 컨테이너를 스케쥴링 시도할 때에, Docker 데몬은 컨테이너 이미지를 풀링하기 위해 외부 네트워크를 이용해야 한다. diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md new file mode 100644 index 0000000000..5296cfcaf2 --- /dev/null +++ b/content/ko/docs/setup/production-environment/_index.md @@ -0,0 +1,4 @@ +--- +title: 운영 환경 +weight: 30 +--- diff --git a/content/ko/docs/setup/cri.md b/content/ko/docs/setup/production-environment/container-runtimes.md similarity index 97% rename from content/ko/docs/setup/cri.md rename to content/ko/docs/setup/production-environment/container-runtimes.md index 11408b9562..35887f49af 100644 --- a/content/ko/docs/setup/cri.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -1,7 +1,7 @@ --- -title: CRI 설치 +title: 컨테이너 런타임 content_template: templates/concept -weight: 100 +weight: 10 --- {{% capture overview %}} {{< feature-state for_k8s_version="v1.6" state="stable" >}} @@ -281,7 +281,7 @@ systemctl restart containerd `systemd` cgroup driver를 사용하려면, `/etc/containerd/config.toml`의 `plugins.cri.systemd_cgroup = true`을 설정한다. kubeadm을 사용하는 경우에도 마찬가지로, 수동으로 -[cgroup driver for kubelet](/docs/setup/independent/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을 +[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-master-node)을 설정해준다. ## 다른 CRI 런타임: frakti diff --git a/content/ko/docs/setup/on-premises-vm/_index.md b/content/ko/docs/setup/production-environment/on-premises-vm/_index.md similarity index 76% rename from content/ko/docs/setup/on-premises-vm/_index.md rename to content/ko/docs/setup/production-environment/on-premises-vm/_index.md index 92d67a957c..d9b92bea18 100644 --- a/content/ko/docs/setup/on-premises-vm/_index.md +++ b/content/ko/docs/setup/production-environment/on-premises-vm/_index.md @@ -1,4 +1,4 @@ --- title: 온-프레미스 VM -weight: 60 +weight: 40 --- diff --git a/content/ko/docs/setup/custom-cloud/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md similarity index 99% rename from content/ko/docs/setup/custom-cloud/kops.md rename to content/ko/docs/setup/production-environment/tools/kops.md index f19e0488d6..50dad0c32e 100644 --- a/content/ko/docs/setup/custom-cloud/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -1,6 +1,7 @@ --- -title: Kops로 AWS에 쿠버네티스 설치하기 +title: Kops로 쿠버네티스 설치하기 content_template: templates/concept +weight: 20 --- {{% capture overview %}} diff --git a/content/ko/docs/setup/turnkey/_index.md b/content/ko/docs/setup/production-environment/turnkey/_index.md similarity index 80% rename from content/ko/docs/setup/turnkey/_index.md rename to content/ko/docs/setup/production-environment/turnkey/_index.md index 8abee4413c..652a2f3f63 100644 --- a/content/ko/docs/setup/turnkey/_index.md +++ b/content/ko/docs/setup/production-environment/turnkey/_index.md @@ -1,4 +1,4 @@ --- title: 턴키 클라우드 솔루션 -weight: 40 +weight: 30 --- diff --git a/content/ko/docs/setup/release/_index.md b/content/ko/docs/setup/release/_index.md index 9ced1d7bee..fcef7a59ab 100755 --- a/content/ko/docs/setup/release/_index.md +++ b/content/ko/docs/setup/release/_index.md @@ -1,5 +1,5 @@ --- -title: "쿠버네티스 다운로드" -weight: 20 +title: "릴리스 노트와 버전 차이 지원(skew)" +weight: 10 --- diff --git a/content/ko/docs/setup/release/building-from-source.md b/content/ko/docs/setup/release/building-from-source.md deleted file mode 100644 index d8b9af438f..0000000000 --- a/content/ko/docs/setup/release/building-from-source.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: 릴리스 빌드 -content_template: templates/concept -card: - name: download - weight: 20 - title: 릴리스 빌드하기 ---- - -{{% capture overview %}} -소스로부터 빌드하거나 이미 빌드된 릴리스를 다운받을 수 있다. 쿠버네티스를 자체를 개발할 계획이 없다면, [릴리스 노트](/docs/setup/release/notes/)에 있는 현재 릴리스 빌드 버전을 사용하는 것을 추천한다. - -쿠버네티스 소스 코드는 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 리포지토리에서 다운받을 수 있다. -{{% /capture %}} - -{{% capture body %}} -## 소스로부터 빌드 - -소스 코드를 빌드만 하려면, 모든 빌드 과정이 Docker 컨테이너 안에서 실행되기 때문에 golang 환경을 구축할 필요가 없다. - -릴리스를 빌드하는 것은 간단하다. - -```shell -git clone https://github.com/kubernetes/kubernetes.git -cd kubernetes -make release -``` - -릴리스 절차에 대한 더 자세한 설명은 kubernetes/kubernetes [`빌드`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) 디렉토리를 참조한다. -{{% /capture %}} diff --git a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 2cbc6f69bc..262588a6db 100644 --- a/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/ko/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -6,8 +6,8 @@ weight: 110 {{% capture overview %}} -이 페이지는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지 -살펴본다. +이 페이지에서는 동일한 파드(Pod)에서 실행 중인 두 개의 컨테이너 간에 통신할 때에, 어떻게 볼륨(Volume)을 이용하는지 +살펴본다. 컨테이너 간에 [프로세스 네임스페이스 공유하기](/docs/tasks/configure-pod-container/share-process-namespace/)를 통해 통신할 수 있는 방법을 참고하자. {{% /capture %}} @@ -135,11 +135,13 @@ Debian 컨테이너에서 nginx 웹 서버가 호스팅하는 문서의 루트 * [합성 컨테이너(composite container) 패턴](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)에 관하여 더 공부한다. -* [모듈 구조를 위한 컴포지트 컨테이너](http://www.slideshare.net/Docker/slideshare-burns)에 관하여 -공부한다. +* [모듈 구조를 위한 합성 컨테이너 구조](http://www.slideshare.net/Docker/slideshare-burns)에 관하여 +더 공부한다. -* [저장소로 볼륨을 사용하는 파드 구성 방법](/docs/tasks/configure-pod-container/configure-volume-storage/)을 -참고한다. +* [파드에서 저장소로 볼룸을 사용하도록 구성하기](/docs/tasks/configure-pod-container/configure-volume-storage/)에 관하여 +확인한다. + +* [파드에서 컨테이너 간에 프로세스 네임스페이스를 공유하는 파드 구성하는 방법](/docs/tasks/configure-pod-container/share-process-namespace/)을 참고한다. * [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)을 확인한다. 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 93c6cb5096..4b8197b6f1 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 @@ -6,7 +6,9 @@ weight: 100 {{% capture overview %}} -Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다. +Horizontal Pod Autoscaler는 +CPU 사용량(또는 베타 지원의 다른 애플리케이션 지원 메트릭)을 관찰하여 +레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다. 이 문서는 php-apache 서버를 대상으로 Horizontal Pod Autoscaler를 동작해보는 예제이다. Horizontal Pod Autoscaler 동작과 관련된 더 많은 정보를 위해서는 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/)를 참고하기 바란다. @@ -17,9 +19,16 @@ Horizontal Pod Autoscaler는 CPU 사용량(또는 베타 지원의 다른 애플 {{% capture prerequisites %}} 이 예제는 버전 1.2 또는 이상의 쿠버네티스 클러스터와 kubectl을 필요로 한다. -[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. 메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. +[메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/) 모니터링을 클러스터에 배포하여 리소스 메트릭 API를 통해 메트릭을 제공해야 한다. +Horizontal Pod Autoscaler가 메트릭을 수집할때 해당 API를 사용한다. +메트릭-서버를 배포하는 지침은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server/)의 GitHub 저장소에 있고, [GCE 가이드](/docs/setup/turnkey/gce/)로 클러스터를 올리는 경우 메트릭-서버 모니터링은 디폴트로 활성화된다. -Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, 버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. 또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. 마지막으로, 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우 버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. 자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다. +Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하는 경우, +버전 1.6 또는 이상의 쿠버네티스 클러스터와 kubectl를 사용해야 한다. +또한, 사용자 정의 메트릭을 사용하기 위해서는, 클러스터가 사용자 정의 메트릭 API를 제공하는 API 서버와 통신할 수 있어야 한다. +마지막으로 쿠버네티스 오브젝트와 관련이 없는 메트릭을 사용하는 경우, +버전 1.10 또는 이상의 쿠버네티스 클러스터와 kubectl을 사용해야 하며, 외부 메트릭 API와 통신이 가능해야 한다. +자세한 사항은 [Horizontal Pod Autoscaler 사용자 가이드](/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-custom-metrics)를 참고하길 바란다. {{% /capture %}} @@ -30,7 +39,6 @@ Horizontal Pod Autoscaler에 다양한 자원 메트릭을 적용하고자 하 Horizontal Pod Autoscaler 시연을 위해 php-apache 이미지를 맞춤 제작한 Docker 이미지를 사용한다. Dockerfile은 다음과 같다. - ``` FROM php:5-apache ADD index.php /var/www/html/index.php @@ -61,9 +69,14 @@ deployment.apps/php-apache created ## Horizontal Pod Autoscaler 생성 -이제 서비스가 동작중이므로, [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 -사용하여 오토스케일러를 생성한다. 다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. -간단히 얘기하면, 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)를 참고하기 바란다. +이제 서비스가 동작중이므로, +[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale)를 사용하여 오토스케일러를 생성한다. +다음 명령어는 첫 번째 단계에서 만든 php-apache 디플로이먼트 파드의 개수를 +1부터 10 사이로 유지하는 Horizontal Pod Autoscaler를 생성한다. +간단히 얘기하면, 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 @@ -109,7 +122,8 @@ php-apache Deployment/php-apache/scale 305% / 50% 305% 1 10 ``` -CPU 소비가 305%까지 증가하였다. 결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. +CPU 소비가 305%까지 증가하였다. +결과적으로, 디플로이먼트의 레플리카 개수는 7개까지 증가하였다. ```shell kubectl get deployment php-apache @@ -120,13 +134,19 @@ php-apache 7 7 7 7 19m ``` {{< note >}} -레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다. 부하의 양은 환경에 따라 다르기 때문에, 최종 레플리카의 개수는 본 예제와 다를 수 있다. +레플리카의 개수를 안정화시키는데 몇 분이 걸릴 수 있다. +부하의 양은 환경에 따라 다르기 때문에, +최종 레플리카의 개수는 본 예제와 다를 수 있다. {{< /note >}} ## 부하 중지 본 예제를 마무리하기 위해 부하를 중단시킨다. -`busybox` 컨테이너를 띄운 터미널에서, ` + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다. + +`busybox` 컨테이너를 띄운 터미널에서, +` + C`로 부하 발생을 중단시킨다. + +그런 다음 (몇 분 후에) 결과를 확인한다. ```shell kubectl get hpa @@ -156,7 +176,8 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮 ## 다양한 메트릭 및 사용자 정의 메트릭을 기초로한 오토스케일링 -`php-apache` 디플로이먼트를 오토스케일링할 때 `autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. +`php-apache` 디플로이먼트를 오토스케일링할 때, +`autoscaling/v2beta2` API 버전을 사용하여 추가적인 메트릭을 제공할 수 있다. 첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다. @@ -200,15 +221,26 @@ status: averageValue: 0 ``` -`targetCPUUtilizationPercentage` 필드가 `metrics` 배열로 대체되었다. CPU 사용량 메트릭은 *resource metric* 으로 파드 컨테이너 자원의 백분율로 표현된다. CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다. 이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며, `metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다. +`targetCPUUtilizationPercentage` 필드가 `metrics` 배열로 대체되었다. +CPU 사용량 메트릭은 *resource metric* 으로 파드 컨테이너 자원의 백분율로 표현된다. +CPU 외에 다른 메트릭을 지정할 수 있는데, 기본적으로 지원되는 다른 메트릭은 메모리뿐이다. +이 자원들은 한 클러스터에서 다른 클러스터로 이름을 변경할 수 없으며, +`metrics.k8s.io` API가 가용한 경우 언제든지 사용할 수 있어야 한다. -또한, `AverageUtilization` 대신 `AverageValue`의 `target` 타입을, 그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여 자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다. +또한, `AverageUtilization` 대신 `AverageValue`의 `target` 타입을, +그리고 `target.averageUtilization` 대신 `target.averageValue`로 설정하여 +자원 메트릭을 퍼센트 대신 값으로 명시할 수 있다. -파드 메트릭과 오브젝트 메트릭 두 가지의 *사용자 정의 메트릭* 이 있다. 파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며, 더 고급화된 클러스터 모니터링 설정이 필요하다. +파드 메트릭과 오브젝트 메트릭 두 가지의 *사용자 정의 메트릭* 이 있다. +파드 메트릭과 오브젝트 메트릭. 이 메트릭은 클러스터에 특화된 이름을 가지고 있으며, +더 고급화된 클러스터 모니터링 설정이 필요하다. -이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다. 이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며, 대상 값과 비교하여 레플리카 개수를 결정한다. +이러한 대체 메트릭 타입중 첫 번째는 *파드 메트릭* 이다. +이 메트릭은 파드들을 설명하고, 파드들간의 평균을 내며, +대상 값과 비교하여 레플리카 개수를 결정한다. -이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, 자원 메트릭과 매우 유사하게 동작한다. +이것들은 `AverageValue`의 `target`만을 지원한다는 것을 제외하면, +자원 메트릭과 매우 유사하게 동작한다. 파드 메트릭은 이처럼 메트릭 블록을 사용하여 정의된다. @@ -223,7 +255,13 @@ pods: averageValue: 1k ``` -두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다. 이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다. 이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다. 오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다. `Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다. `AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다. 다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다. +두 번째 대체 메트릭 타입은 *오브젝트 메트릭* 이다. +이 메트릭은 파드를 기술하는 대신에 동일한 네임스페이스 내에 다른 오브젝트를 표현한다. +이 메트릭은 반드시 오브젝트로부터 가져올 필요는 없다. 단지 오브젝트를 기술할 뿐이다. +오브젝트 메트릭은 `Value`과 `AverageValue`의 `target` 타입을 지원한다. +`Value`를 사용할 경우 대상은 API로부터 반환되는 메트릭과 직접 비교된다. +`AverageValue`를 사용할 경우, 대상 값과 비교되기 이전에 사용자 정의 메트릭 API로부터 반환된 값은 파드의 개수로 나눠진다. +다음은 `requests-per-second` 메트릭을 YAML로 기술한 예제이다. ```yaml type: Object @@ -239,9 +277,12 @@ object: value: 2k ``` -이러한 메트릭 블록을 여러 개 제공하면, HorizontalPodAutoscaler는 각 메트릭을 차례로 고려한다. HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수를 계산하고, 그중 가장 높은 레플리카 개수를 선정한다. +이러한 메트릭 블록을 여러 개 제공하면, HorizontalPodAutoscaler는 각 메트릭을 차례로 고려한다. +HorizontalPodAutoscaler는 각 메트릭에 대해 제안된 레플리카 개수를 계산하고, +그중 가장 높은 레플리카 개수를 선정한다. -예를 들어, 네트워크 트래픽 메트릭을 수집하는 모니터링 시스템이 있는 경우, `kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. +예를 들어, 네트워크 트래픽 메트릭을 수집하는 모니터링 시스템이 있는 경우, +`kubectl edit` 명령어를 이용하여 다음과 같이 정의를 업데이트 할 수 있다. ```yaml apiVersion: autoscaling/v2beta1 @@ -303,11 +344,17 @@ status: value: 10k ``` -이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지, 초당 1000 패킷을 처리하는지, 메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다. +이후, HorizontalPodAutoscaler는 각 파드가 요청 된 약 50%의 CPU 사용률을 소모하는지, +초당 1000 패킷을 처리하는지, +메인-루트 인그레스 뒤의 모든 파드들이 초당 10000 요청을 처리하는지 확인한다. ### 보다 구체적인 메트릭을 기초로한 오토스케일링 -많은 메트릭 파이프라인들을 사용하면 이름 또는 _labels_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다. 그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해, 메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다. 예를 들면, `verb` 레이블로 `http_requests` 메트릭을 수집하는 경우, 다음과 같이 메트릭 블록을 지정하여 GET 요청에 대해 크기를 조정할 수 있다. +많은 메트릭 파이프라인들을 사용하면 이름 또는 _labels_ 이라 불리는 추가적인 식별자로 메트릭을 설명할 수 있다. +그리고, 모든 비 자원 메트릭 타입(파드, 오브젝트 그리고 아래 기술된 외부 타입)에 대해, +메트릭 파이프라인으로 전달되는 추가 레이블 셀렉터를 지정할 수 있다. +예를 들면, `verb` 레이블로 `http_requests` 메트릭을 수집하는 경우, +다음과 같이 메트릭 블록을 지정하여 GET 요청에 대해 크기를 조정할 수 있다. ```yaml type: Object @@ -317,18 +364,30 @@ object: selector: `verb=GET` ``` -이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다. 모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우, 해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다. 셀렉터는 부가적인 속성이며, 대상 오브젝트(`Pods` 타입의 대상 파드, `Object` 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다. +이 셀렉터는 쿠버네티스의 레이블 셀렉터와 동일한 문법이다. +모니터링 파이프라인은 네임과 셀렉터가 여러 시리즈와 일치하는 경우, +해당 여러 시리즈를 단일 값으로 축소하는 방법을 결정한다. +셀렉터는 부가적인 속성이며, +대상 오브젝트(`Pods` 타입의 대상 파드, `Object` 타입으로 기술된 오브젝트)가 아닌 메트릭을 선택할 수 없다. ### 쿠버네티스 오브젝트와 관련이 없는 메트릭을 기초로한 오토스케일링 -쿠버네티스 위에서 동작하는 애플리케이션은 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여 오토스케일링을 할 수도 있다. 예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다. 쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다. +쿠버네티스 위에서 동작하는 애플리케이션은, 쿠버네티스 클러스터의 어떤 오브젝트와도 관련이 없는 메트릭에 기반하여 +오토스케일링을 할 수도 있다. +예로, 쿠버네티스 네임스페이스와 관련이 없는 서비스를 기초로한 메트릭을 들 수 있다. +쿠버네티스 버전 1.10 포함 이후 버전에서, *외부 메트릭* 을 사용하여 이러한 유스케이스를 해결할 수 있다. -외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다. 이 설치는 사용자 정의 메트릭과 유사하다. +외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다. +이 설치는 사용자 정의 메트릭과 유사하다. 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다. -위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고, `Object` 대신에 `External` 메트릭 타입을 사용한다. +위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고, +`Object` 대신에 `External` 메트릭 타입을 사용한다. 만일 여러개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다. -외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고, `Object` 타입을 사용할 때와 똑같이 동작한다. -예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우, 다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다. +외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고, +`Object` 타입을 사용할 때와 똑같이 동작한다. + +예를 들면 애플리케이션이 호스팅 된 대기열 서비스에서 작업을 처리하는 경우, +다음과 같이 HorizontalPodAutoscaler 매니퍼스트에 30개의 미해결 태스크 당 한 개의 워커를 지정하도록 추가할 수 있다. ```yaml - type: External @@ -341,13 +400,19 @@ object: averageValue: 30 ``` -가능하다면, 외부 메트릭 대신 사용자 정의 메트릭 대상 타입을 사용하길 권장한다. 왜냐하면, 클러스터 관리자가 사용자 정의 메트릭 API를 보안관점에서 더 쉽게 보호할 수 있기 때문이다. 외부 메트릭 API는 잠재적으로 어떠한 메트릭에도 접근할 수 있기에, 클러스터 관리자는 API를 노출시킬때 신중해야 한다. +가능하다면, 외부 메트릭 대신 사용자 정의 메트릭 대상 타입을 사용하길 권장한다. +왜냐하면, 클러스터 관리자가 사용자 정의 메트릭 API를 보안관점에서 더 쉽게 보호할 수 있기 때문이다. +외부 메트릭 API는 잠재적으로 어떠한 메트릭에도 접근할 수 있기에, 클러스터 관리자는 API를 노출시킬때 신중해야 한다. ## 부록: Horizontal Pod Autoscaler 상태 조건 -HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. 이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, 어떤 방식으로든 제한되어 있는지 여부를 나타낸다. +HorizontalPodAutoscaler의 `autoscaling/v2beta2` 형식을 사용하면, +HorizontalPodAutoscaler에서 쿠버네티스가 설정한 *상태 조건* 을 확인할 수 있다. +이 상태 조건들은 HorizontalPodAutoscaler가 스케일을 할 수 있는지, +어떤 방식으로든 제한되어 있는지 여부를 나타낸다. -이 조건은 `status.conditions`에 나타난다. HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다. +이 조건은 `status.conditions`에 나타난다. +HorizontalPodAutoscaler에 영향을 주는 조건을 보기 위해 `kubectl describe hpa`를 사용할 수 있다. ```shell kubectl describe hpa cm-test @@ -373,17 +438,32 @@ Conditions: Events: ``` -이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다. 첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지, 백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. 두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지), 원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, 일반적으로 메트릭을 가져오는데 문제가 있다. 마지막으로, 마지막 조건인 `ScalingLimited`는 원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. 이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다. +이 HorizontalPodAutoscaler 경우, 건강 상태의 여러 조건들을 볼 수 있다. +첫 번째 `AbleToScale`는 HPA가 스케일을 가져오고 업데이트할 수 있는지, +백 오프 관련 조건으로 스케일링이 방지되는지 여부를 나타낸다. +두 번째 `ScalingActive`는 HPA가 활성화되어있는지(즉 대상 레플리카 개수가 0이 아닌지), +원하는 스케일을 계산할 수 있는지 여부를 나타낸다. 만약 `False` 인 경우, +일반적으로 메트릭을 가져오는데 문제가 있다. +마지막으로, 마지막 조건인 `ScalingLimited`는 +원하는 스케일 한도가 HorizontalPodAutoscaler의 최대/최소값으로 제한돼있음을 나타낸다. +이는 HorizontalPodAutoscaler에서 레플리카의 개수 제한을 최대/최소값으로 올리거나 낮추려는 것이다. ## 부록: 수량 -HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다. 예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다. 메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며, 일반적으로 수량을 밀리단위로 반환한다. 10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. 더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다. +HorizontalPodAutoscaler와 메트릭 API에서 모든 메트릭은 +쿠버네티스에서 사용하는 *수량* 숫자 표기법을 사용한다. +예를 들면, `10500m` 수량은 10진법 `10.5`으로 쓰인다. +메트릭 API들은 가능한 경우 접미사 없이 정수를 반환하며, +일반적으로 수량을 밀리단위로 반환한다. +10진수로 표현했을때, `1`과 `1500m` 또는 `1`과 `1.5` 로 메트릭 값을 나타낼 수 있다. +더 많은 정보를 위해서는 [수량에 관한 용어집](/docs/reference/glossary?core-object=true#term-quantity) 을 참고하기 바란다. ## 부록: 다른 가능한 시나리오 ### 명시적으로 오토스케일러 만들기 -HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고 명시적으로 다음 파일을 사용하여 만들 수 있다. +HorizontalPodAutoscaler를 생성하기 위해 `kubectl autoscale` 명령어를 사용하지 않고, +명시적으로 다음 파일을 사용하여 만들 수 있다. {{< codenew file="application/hpa/php-apache.yaml" >}} diff --git a/content/ko/docs/tasks/tools/install-minikube.md b/content/ko/docs/tasks/tools/install-minikube.md index 24d2226693..80100f534d 100644 --- a/content/ko/docs/tasks/tools/install-minikube.md +++ b/content/ko/docs/tasks/tools/install-minikube.md @@ -15,12 +15,10 @@ card: {{% capture prerequisites %}} -컴퓨터의 바이오스(BIOS)에서 VT-x 또는 AMD-v 가상화는 필수적으로 활성화되어 있어야 한다. - {{< tabs name="minikube_before_you_begin" >}} {{% tab name="리눅스" %}} 리눅스에서 가상화 지원 여부를 확인하려면, 아래의 명령을 실행하고 출력이 비어있지 않은지 확인한다. -``` +```shell egrep --color 'vmx|svm' /proc/cpuinfo ``` {{% /tab %}} @@ -44,6 +42,12 @@ Hyper-V Requirements: VM Monitor Mode Extensions: Yes Data Execution Prevention Available: Yes ``` +다음의 출력을 확인할 수 있다면, 이미 하이퍼바이저가 설치되어 있는 것으로 다음 단계를 건너 뛸 수 있다. +``` +Hyper-V Requirements: A hypervisor has been detected. Features required for Hyper-V will not be displayed. +``` + + {{% /tab %}} {{< /tabs >}} @@ -51,87 +55,125 @@ Hyper-V Requirements: VM Monitor Mode Extensions: Yes {{% capture steps %}} -## 하이퍼바이저(hypervisor) 설치 {#install-a-hypervisor} +# minikube 설치하기 + +{{< tabs name="tab_with_md" >}} +{{% tab name="리눅스" %}} + +### kubectl 설치 + +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-linux)의 요령을 따라서 설치할 수 있다. + +## 하이퍼바이저(hypervisor) 설치 하이퍼바이저를 설치하지 않다면, 운영체제에 적합한 하이퍼바이저를 지금 설치한다. -운영체제 | 지원하는 하이퍼바이저 -:----------------|:--------------------- -맥OS | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), [HyperKit](https://github.com/moby/hyperkit) -리눅스 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [KVM](http://www.linux-kvm.org/) -윈도우 | [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) +• [KVM](https://www.linux-kvm.org/), 또한 QEMU를 사용한다 + +• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) {{< note >}} -Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 Docker와 리눅스 환경을 필요로 한다. +Minikube는 쿠버네티스 컴포넌트를 VM이 아닌 호스트에서도 동작하도록 `--vm-driver=none` 옵션도 지원한다. 이 드라이버를 사용하기 위해서는 하이퍼바이저가 아닌 [도커](https://www.docker.com/products/docker-desktop)와 리눅스 환경을 필요로 한다. {{< /note >}} -## kubectl 설치 +### 패키지를 이용하여 Minikube 설치 -* [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/) 지침에 따라 kubectl을 설치한다. +Minikube를 위한 *실험적인* 패키지가 있다. +리눅스 (AMD64) 패키지는 GitHub의 Minikube의 [릴리스](https://github.com/kubernetes/minikube/releases)에서 찾을 수 있다. -## Minikube 설치 {#install-minikube} +적절한 패키지를 설치하기 위해 리눅스 배포판의 패키지 도구를 사용한다. -### 맥OS {#macos} +### Minikube를 직접 다운로드하여 설치 -맥OS에 Minikube를 설치하는 가장 쉬운 방법은 [Homebrew](https://brew.sh)을 사용하는 것이다. - -```shell -brew cask install minikube -``` - -정적 바이너리를 내려받아서 맥OS에 설치할 수도 있다. - -```shell -curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ - && chmod +x minikube -``` - -Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다. - -```shell -sudo mv minikube /usr/local/bin -``` - -### 리눅스 {#linux} - -{{< note >}} -이 문서는 Minikube를 리눅스에 정적 바이너리를 사용해서 설치하는 방법을 설명한다. -{{< /note >}} - -정적 바이너리를 내려받아서 리눅스에 Minikube를 설치할 수 있다. +패키지를 통해 설치하지 못하였다면, +바이너리 자체를 다운로드 받고 사용할 수 있다. ```shell curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 \ && chmod +x minikube ``` -Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다. +Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다. ```shell -sudo cp minikube /usr/local/bin && rm minikube +sudo install minikube /usr/local/bin ``` -### 윈도우 {#windows} +{{% /tab %}} +{{% tab name="맥OS" %}} +### kubectl 설치 + +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-macos)의 요령을 따라서 설치할 수 있다. + +### 하이퍼바이저(hypervisor) 설치 + +하이퍼바이저를 설치하지 않았다면, 다음 중 하나를 지금 설치한다. + +• [HyperKit](https://github.com/moby/hyperkit) + +• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) + +• [VMware Fusion](https://www.vmware.com/products/fusion) + +### Minikube 설치 +가장 쉽게 맥OS에 Minikube를 설치하는 방법은 [Homebrew](https://brew.sh)를 이용하는 것이다. + +```shell +brew cask install minikube +``` + +실행 바이너리를 다운로드 받아서 맥OS에 설치할 수도 있다. + +```shell +curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-darwin-amd64 \ + && chmod +x minikube +``` + +Minikube 실행 파일을 사용자 실행 경로에 추가하는 가장 쉬운 방법은 다음과 같다. + +```shell +sudo mv minikube /usr/local/bin +``` + +{{% /tab %}} +{{% tab name="Windows" %}} +### kubectl 설치하기 + +kubectl이 설치되었는지 확인한다. kubectl은 [kubectl 설치하고 설정하기](/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows)의 요령을 따라서 설치할 수 있다. + +### 하이퍼바이저(hypervisor) 설치하기 + +하이퍼바이저가 설치 안 되어 있다면 아래중 하나를 지금 설치한다. + +• [Hyper-V](https://msdn.microsoft.com/en-us/virtualization/hyperv_on_windows/quick_start/walkthrough_install) + +• [VirtualBox](https://www.virtualbox.org/wiki/Downloads) {{< note >}} -Minikube를 윈도우에서 실행하려면, 먼저 [VirtualBox](https://www.virtualbox.org/) 또는 [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)를 설치해야 한다. Hyper-V는 Windows 10 엔터프라이즈, Windows 10 프로페셔널, Windows 10 에듀케이션 세 버전의 Windows 10에서 동작한다. Minikube 공식 GitHub 레포지토리에 추가적인 [설치 방법](https://github.com/kubernetes/minikube/#installation)을 확인한다. +Hyper-V는 다음 세 버전의 윈도우 10에서 실행할 수 있다. Windows 10 Enterprise, Windows 10 Professional, Windows 10 Education. {{< /note >}} -윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다. (관리자 권한으로 실행) +### Chocolatey를 이용한 Minikube 설치 + +윈도우에서 Minikube를 설치하는 가장 쉬운 방법은 [Chocolatey](https://chocolatey.org/)를 사용하는 것이다(관리자 권한으로 실행). ```shell choco install minikube kubernetes-cli ``` -Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube가 실행 경로에 자동으로 추가되어 있어야 한다. +Minikube 설치를 마친 후, 현재 CLI 세션을 닫고 재시작한다. Minikube 실행 파일의 경로는 실행 경로(path)에 자동으로 추가된다. -#### 윈도우 수동 설치 {#windows-manual-installation} +### 인스톨러 실행파일을 통한 Minikube 설치 -윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다. +윈도우에서 수동으로 [Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)로 설치하려면, [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest/minikube-installer.exe)를 다운로드 받고, 이 인스톨러를 실행한다. -#### 윈도우 인스톨러 {#windows-installer} +### 직접 다운로드하여 Minikube 설치 + +윈도우에서 Minikube를 수동으로 설치하려면, [`minikube-windows-amd64`](https://github.com/kubernetes/minikube/releases/latest)를 다운로드 받아서, 파일 이름을 `minikube.exe`로 변경하고, 실행 경로에 추가한다. + +{{% /tab %}} +{{< /tabs >}} -[Windows 인스톨러](https://docs.microsoft.com/en-us/windows/desktop/msi/windows-installer-portal)으로 윈도우에서 Minikube를 수동으로 설치하려면 [`minikube-installer.exe`](https://github.com/kubernetes/minikube/releases/latest)를 내려받아서 인스톨러를 실행한다. {{% /capture %}} @@ -155,5 +197,5 @@ machine does not exist 구성 파일을 삭제해야 한다. ```shell -rm -rf ~/.minikube +minikube delete ``` diff --git a/content/ko/docs/tutorials/kubernetes-basics/_index.html b/content/ko/docs/tutorials/kubernetes-basics/_index.html index 1f9659628a..405572ef30 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ko/docs/tutorials/kubernetes-basics/_index.html @@ -24,10 +24,10 @@ card:

이 튜토리얼에서는 쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 익힐 수 있는 가이드를 제공한다. 각각의 모듈에는 쿠버네티스의 주요 기능과 개념에 대한 배경 지식이 담겨 있으며 대화형 온라인 튜토리얼도 포함되어 있다. 대화형 튜토리얼에서 간단한 클러스터와 그 클러스터 상의 컨테이너화 된 애플리케이션을 직접 관리해볼 수 있다.

대화형 튜토리얼을 사용해서 다음의 내용을 배울 수 있다.

    -
  • 컨테이너화된 애플리케이션을 클러스터에 배포하기
    • -
  • 디플로이먼트를 스케일링하기
    • -
  • 컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기
    • -
  • 컨테이너화된 애플리케이션을 디버그하기
    • +
  • 컨테이너화된 애플리케이션을 클러스터에 배포하기.
    • +
  • 디플로이먼트를 스케일링하기.
    • +
  • 컨테이너화된 애플리케이션을 새로운 소프트웨어 버전으로 업데이트하기.
    • +
  • 컨테이너화된 애플리케이션을 디버그하기.

이 튜토리얼에서는 Katacoda를 사용해서 독자의 웹브라우저에서 Minikube가 동작하는 가상 터미널을 구동시킨다. Minikube는 로컬에 설치할 수 있는 작은 규모의 쿠버네티스로써 어디에서든 작동된다. 어떤 소프트웨어도 설치할 필요가 없고, 아무 것도 설정할 필요가 없다. 왜냐하면 대화형 튜토리얼이 웹브라우저 자체에서 바로 동작하기 때문이다.

@@ -104,12 +104,6 @@ card: -
-
- 튜토리얼 시작하기› -
-
- diff --git a/content/ko/docs/tutorials/online-training/overview.md b/content/ko/docs/tutorials/online-training/overview.md index 2463c5a69d..402cb29a10 100644 --- a/content/ko/docs/tutorials/online-training/overview.md +++ b/content/ko/docs/tutorials/online-training/overview.md @@ -17,33 +17,31 @@ content_template: templates/concept * [Cloud Native Certified Kubernetes Administrator (CKA) with Hands-On Labs & Practice Exams (Linux Academy)](https://linuxacademy.com/linux/training/course/name/cloud-native-certified-kubernetes-administrator-cka) -* [Certified Kubernetes Administrator Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests) +* [Certified Kubernetes Administrator Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/certified-kubernetes-administrator-with-practice-tests) * [Certified Kubernetes Application Developer (CKAD) with Hands-On Labs & Practice Exams (Linux Academy)] (https://linuxacademy.com/containers/training/course/name/certified-kubernetes-application-developer-ckad/) -* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course) +* [Certified Kubernetes Application Developer Preparation Course with Practice Tests (KodeKloud)](https://kodekloud.com/p/kubernetes-certification-course) -* [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine) +* [Getting Started with Google Kubernetes Engine (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine) -* [Google Kubernetes Engine Deep Dive (Linux Academy)](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) +* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes) -* [쿠버네티스 시작하기 (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) -* [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) - -* [쿠버네티스 소개 (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) - -* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials) +* [Google Kubernetes Engine Deep Dive (Linux Academy)] (https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) * [Helm Deep Dive with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/helm-deep-dive-part-1) -* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on) +* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes) -* [Kubernetes Quick Start (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start) +* [IBM Cloud: Deploying Microservices with Kubernetes (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud) + +* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x) + +* [Kubernetes Essentials with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-essentials) + +* [Kubernetes for the Absolute Beginners with Hands-on Labs (KodeKloud)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on) * [Kubernetes Quick Start with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-quick-start) @@ -55,7 +53,7 @@ content_template: templates/concept * [Learn Kubernetes by Doing - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/learn-kubernetes-by-doing) -* [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/) +* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/) * [Microservice Applications in Kubernetes - 100% Hands-On Experience (Linux Academy)] (https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing) @@ -63,9 +61,7 @@ content_template: templates/concept * [Service Mesh with Istio with Hands-On Labs (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/service-mesh-with-istio-part-1) -* [Prometheus로 쿠버네티스 모니터링 (Linux Academy)] (https://linuxacademy.com/linux/training/course/name/kubernetes-and-prometheus) - -* [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Scalable Microservices with Kubernetes (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/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index a7946664c2..75edb0e5a7 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -34,7 +34,10 @@ content_template: templates/tutorial 작은 nginx 웹 서버를 이용한다. 다음과 같이 생성할 수 있다. ```console -$ kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +kubectl run source-ip-app --image=k8s.gcr.io/echoserver:1.4 +``` +출력은 다음과 같다. +``` deployment.apps/source-ip-app created ``` @@ -59,23 +62,38 @@ deployment.apps/source-ip-app created Kube-proxy는 이 모드를 `proxyMode` 엔드포인트를 통해 노출한다. ```console -$ kubectl get nodes +kubectl get nodes +``` +출력은 다음과 유사하다 +``` NAME STATUS ROLES AGE VERSION kubernetes-minion-group-6jst Ready 2h v1.13.0 kubernetes-minion-group-cx31 Ready 2h v1.13.0 kubernetes-minion-group-jj1t Ready 2h v1.13.0 - +``` +한 노드의 프록시 모드를 확인한다. +```console kubernetes-minion-group-6jst $ curl localhost:10249/proxyMode +``` +출력은 다음과 같다. +``` iptables ``` 소스 IP 애플리케이션을 통해 서비스를 생성하여 소스 IP 주소 보존 여부를 테스트할 수 있다. ```console -$ kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 +kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 +``` +출력은 다음과 같다. +``` service/clusterip exposed - -$ kubectl get svc clusterip +``` +```console +kubectl get svc clusterip +``` +출력은 다음과 같다. +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE clusterip ClusterIP 10.0.170.92 80/TCP 51s ``` @@ -83,7 +101,10 @@ clusterip ClusterIP 10.0.170.92 80/TCP 51s 그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면: ```console -$ kubectl run busybox -it --image=busybox --restart=Never --rm +kubectl run busybox -it --image=busybox --restart=Never --rm +``` +The output is similar to this: +``` Waiting for pod default/busybox to be running, status is Pending, pod ready: false If you don't see a command prompt, try pressing enter. @@ -115,11 +136,16 @@ client_address는 클라이언트 파드와 서버 파드가 같은 노드 또 소스 NAT가 기본으로 적용된다. `NodePort` 서비스를 생성하여 이것을 테스트할 수 있다. ```console -$ kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort +kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort +``` +출력은 다음과 같다. +``` service/nodeport exposed +``` -$ NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) -$ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="IPAddress")].address }') +```console +NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="ExternalIP")].address }') ``` 클라우드 공급자 상에서 실행한다면, @@ -128,7 +154,10 @@ $ NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type= 서비스에 도달할 수 있다. ```console -$ for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done +for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done +``` +출력은 다음과 같다. +``` client_address=10.180.1.1 client_address=10.240.0.5 client_address=10.240.0.3 @@ -170,14 +199,20 @@ client_address=10.240.0.3 다음과 같이 `service.spec.externalTrafficPolicy` 필드를 설정하자. ```console -$ kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' +kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` +출력은 다음과 같다. +``` service/nodeport patched ``` 이제 다시 테스트를 실행해보자. ```console -$ for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done +for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done +``` +출력은 다음과 같다. +``` client_address=104.132.1.79 ``` @@ -191,7 +226,6 @@ client_address=104.132.1.79 * 클라이언트는 패킷을 엔드포인트를 가진 `node1:nodePort` 보낸다. * node1은 패킷을 올바른 소스 IP 주소로 엔드포인트로 라우팅 한다. - 시각적으로 ``` @@ -220,14 +254,28 @@ client_address=104.132.1.79 로드밸런서를 통해 source-ip-app을 노출하여 테스트할 수 있다. ```console -$ kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer +kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer +``` +다음과 같이 출력된다. +``` service/loadbalancer exposed +``` -$ kubectl get svc loadbalancer +서비스의 IP를 출력한다. +```console +kubectl get svc loadbalancer +``` +다음과 같이 출력된다. +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE loadbalancer LoadBalancer 10.0.65.118 104.198.149.140 80/TCP 5m +``` -$ curl 104.198.149.140 +```console +curl 104.198.149.140 +``` +다음과 같이 출력된다. +``` CLIENT VALUES: client_address=10.240.0.5 ... @@ -255,29 +303,44 @@ health check ---> node 1 node 2 <--- health check 이것은 어노테이션을 설정하여 테스트할 수 있다. ```console -$ kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' +kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' ``` 쿠버네티스에 의해 `service.spec.healthCheckNodePort` 필드가 즉각적으로 할당되는 것을 봐야 한다. ```console -$ kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort +kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort +``` +다음과 같이 출력된다. +``` healthCheckNodePort: 32122 ``` `service.spec.healthCheckNodePort` 필드는 `/healthz`에서 헬스 체크를 제공하는 모든 노드의 포트를 가르킨다. 이것을 테스트할 수 있다. +```console +kubectl get pod -o wide -l run=source-ip-app +``` +다음과 같이 출력된다. ``` -$ kubectl get pod -o wide -l run=source-ip-app NAME READY STATUS RESTARTS AGE IP NODE source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-minion-group-6jst - +``` +다른 노드에서`/healthz` 엔드포인트로 curl 명령을 수행한다. +```console kubernetes-minion-group-6jst $ curl localhost:32122/healthz +``` +다음과 같이 출력된다. +``` 1 Service Endpoints found - +``` +```console kubernetes-minion-group-jj1t $ curl localhost:32122/healthz +``` +다음과 같이 출력된다. +``` No Service Endpoints Found ``` @@ -287,7 +350,10 @@ No Service Endpoints Found 로드밸런서 IP 주소로 curl 하자. ```console -$ curl 104.198.149.140 +curl 104.198.149.140 +``` +다음과 같이 출력된다. +``` CLIENT VALUES: client_address=104.132.1.79 ... @@ -323,13 +389,13 @@ HTTP [X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For) 헤더나 서비스를 삭제하자. ```console -$ kubectl delete svc -l run=source-ip-app +kubectl delete svc -l run=source-ip-app ``` 디플로이먼트와 리플리카 셋과 파드를 삭제하자. ```console -$ kubectl delete deployment source-ip-app +kubectl delete deployment source-ip-app ``` {{% /capture %}}