whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Seventh Korean l10n work for release-1.13 (#12981)

Browse Source 
* ko-trans: Update outdated contents in ko7 branch (#12762)

* ko: Update outdated files in dev-1.13-ko.7 (#12805)

* ko: Translate docs/home/_index.md in Korean (#12829)

* Translate scheduler-perf-tuning.md in Korean (#12782)

* Translate concepts/overview/object-management-kubectl/overview in Korean (#12834)

* Fix new line in Korean translation scheduler-perf-tuning.md (#12835)

* ko: Translate tutorials/online-training/overview.md in Korean (#12854)

* ko: Translate contribute/_index.md in Korean (#12850)

* ko: Update localization guide about instruction-type content (#12877)

Co-authored-by:    June Yi <june.yi@samsung.com>
Co-authored-by:    Claudia J.Kang <claudiajkang@gmail.com>
Co-authored-by:    Seokho <shsongist@gmail.com>
Co-authored-by:    Kim Young Dae <38598117+zer0big@users.noreply.github.com>
This commit is contained in:
Claudia J.Kang
2019-03-05 22:32:28 +09:00
committed by Kubernetes Prow Robot
parent 08839f640f
commit 92faff9209
23 changed files with 666 additions and 164 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/concepts/architecture/cloud-controller.md
+1
View File
@@ -254,6 +254,7 @@ rules:
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
## 클러스터 관리
content/ko/docs/concepts/configuration/_index.md
Executable
+5
View File
@@ -0,0 +1,5 @@
---
title: "구성"
weight: 80
---
content/ko/docs/concepts/configuration/scheduler-perf-tuning.md
+111
View File
@@ -0,0 +1,111 @@
---
title: 스케줄러 성능 튜닝
content_template: templates/concept
weight: 70
---
{{% capture overview %}}
{{< feature-state for_k8s_version="1.12" >}}
Kube-scheduler는 쿠버네티스의 기본 스케줄러이다. 그것은 클러스터의
노드에 파드를 배치하는 역할을 한다. 파드의 스케줄링 요건을 충족하는
클러스터의 노드를 파드에 "적합한(feasible)" 노드라고 한다. 스케줄러는
파드에 대해 적합한 노드를 찾고 기능 셋을 실행하여 해당 노드의 점수를
측정한다. 그리고 스케줄러는 파드를 실행하는데 적합한 모든 노드 중 가장
높은 점수를 가진 노드를 선택한다. 이후 스케줄러는 "바인딩"이라는 프로세스로
API 서버에 해당 결정을 통지한다.
{{% /capture %}}
{{% capture body %}}
## 점수를 측정할 노드의 비율
쿠버네티스 1.12 이전 버전에서, Kube-scheduler는 클러스터의 모든 노드에
대한 적합성(feasibility)을 확인한 후에 적합한 노드들에 대해서 점수를 측정했다.
쿠버네티스 1.12는 새로운 특징을 가지고 있으며, 이 특징은 스케줄러가 특정
숫자의 적합한 노드를 찾은 이후에 추가적인 적합 노드를 찾는 것을 중단하게 한다.
이것은 대규모 클러스터에서 스케줄러 성능을 향상시킨다. 해당 숫자는 클러스터
크기에 대한 비율로 지정되며 `percentageOfNodesToScore` 구성 옵션으로
제어된다. 값의 범위는 1과 100 사이여야 한다. 그 이외의 값은 100%로 간주한다.
이 옵션의 기본 값은 50%이다. 클러스터 관리자는 이 값은 스케줄러 구성에 다른
값을 지정함으로써 기본 값을 변경할 수 있다. 그러나, 이 값을 변경할 필요는 없을 것이다.
```yaml
apiVersion: componentconfig/v1alpha1
kind: KubeSchedulerConfiguration
algorithmSource:
provider: DefaultProvider
...
percentageOfNodesToScore: 50
```
{{< note >}}
클러스터에서 적합한 노드가 0 또는 50 미만인 경우,
스케줄러는 여전히 모든 노드를 확인한다. 이는 스케줄러가 탐색을 조기
중단하기에는 적합한 노드의 수가 충분하지 않기 때문이다.
{{< /note >}}
**이 특징을 비활성화하려면**, `percentageOfNodesToScore`를 100으로 지정한다.
### percentageOfNodesToScore 튜닝
`percentageOfNodesToScore`는 1과 100 사이의 값이어야하며
기본 값은 50이다. 또한 50%의 노드로 하드 코딩된 최소 값이 내부적으로
적용된다. 스케줄러는 `percentageOfNodesToScore` 값과 상관없이
적어도 50%의 노드 탐색을 수행한다. 이는 수백 개 정도의 노드가 있는
클러스터에서는 해당 옵션을 더 낮은 값으로 변경하더라도 스케줄러가
찾으려는 적합한 노드의 개수에는 크게 영향을 주지 않는다는
뜻이다. 이것은 규모가 작은 클러스터에서는 이 옵션의 조정이 성능을
눈에 띄게 향상시키지 않는 것을 감안하여 의도적으로 설계되었다. 1000 노드
이상의 큰 규모의 클러스터에서는 이 값을 낮은 수로 설정하면 눈에 띄는 성능
향상을 보일 수도 있다.
이 값을 세팅할 때 중요하게 고려해야 할 사항은, 클러스터에서
적은 수의 노드에 대해서만 적합성을 확인하면, 주어진 파드에 대해서
일부 노드의 점수는 측정이되지 않는다는 것이다. 결과적으로, 주어진 파드를 실행하는데
가장 높은 점수를 가질 가능성이 있는 노드가 점수 측정 단계로 조차 넘어가지
않을 수 있다. 이것은 파드의 이상적인 배치보다 낮은 결과를 초래할 것이다.
그 이유로, 이 값은 너무 낮은 비율로 설정되면 안 된다. 대략의 경험적 법칙은 30 이하의
값으로는 설정하지 않는 것이다. 더 낮은 값은 사용자의 애플리케이션에서 스케줄러의
처리량이 치명적이고 노드의 점수가 중요하지 않을 경우에만 사용해야 한다. 다시 말해서, 파드의
실행에 적합하기만 하다면 어느 노드가 선택되어도 사용자에게 상관없는 경우를 말한다.
만약 사용자의 클러스터가 단지 백여 개의 노드를 가지고 있는 경우 기본 값보다 낮은 값으로의
변경을 추천하지 않는다. 그것은 스케줄러의 성능을
크게 향상시키지 않을 것이다.
### 스케줄러가 노드 탐색을 반복(iterate)하는 방법
이 섹션은 이 특징의 상세한 내부 방식을 이해하고 싶은 사람들을
위해 작성되었다.
클러스터의 모든 노드가 파드 실행 대상으로 고려되어 공정한 기회를
가지도록, 스케줄러는 라운드 로빈(round robin) 방식으로 모든 노드에 대해서 탐색을
반복한다. 모든 노드가 배열에 나열되어 있다고 생각해보자. 스케줄러는 배열의
시작부터 시작하여 `percentageOfNodesToScore`에 명시된 충분한 수의 노드를
찾을 때까지 적합성을 확인한다. 그 다음 파드에 대해서는, 스케줄러가
이전 파드를 위한 노드 적합성 확인이 마무리된 지점인 노드 배열의 마지막
포인트부터 확인을 재개한다.
만약 노드들이 다중의 영역(zone)에 있다면, 다른 영역에 있는 노드들이 적합성
확인의 대상이 되도록 스케줄러는 다양한 영역에 있는 노드에 대해서
탐색을 반복한다. 예제로, 2개의 영역에 있는 6개의 노드를 생각해보자.
```
영역 1: 노드 1, 노드 2, 노드 3, 노드 4
영역 2: 노드 5, 노드 6
```
스케줄러는 노드의 적합성 평가를 다음의 순서로 실행한다.
```
노드 1, 노드 5, 노드 2, 노드 6, 노드 3, 노드 4
```
모든 노드를 검토한 후, 노드 1로 돌아간다.
{{% /capture %}}
content/ko/docs/concepts/containers/container-lifecycle-hooks.md
+12 -12
View File
@@ -33,7 +33,7 @@ Angular와 같이, 컴포넌트 라이프사이클 훅을 가진 많은 프로
`PreStop`
이 훅은 컨테이너가 종료되기 직전에 호출된다.
이 훅은 API 요청이나 활성 프로브(liveness probe) 실패, 선점, 자원 경합 등의 관리 이벤트로 인해 컨테이너가 종료되기 직전에 호출된다. 컨테이너가 이미 terminated 또는 completed 상태인 경우에는 preStop 훅 요청이 실패한다.
그것은 동기적인 동작을 의미하는, 차단(blocking)을 수행하고 있으므로,
컨테이너를 삭제하기 위한 호출이 전송되기 전에 완료되어야한다.
파라미터는 핸들러에 전달되지 않는다.
@@ -96,17 +96,17 @@ Kubelet이 구동된 후에 해당 훅은 재전송될 것이다.
```
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{{% /capture %}}
content/ko/docs/concepts/containers/images.md
+6 -1
View File
@@ -167,6 +167,11 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
않을 것이다.
{{< /note >}}
{{< note >}}
현재 쿠버네티스는 docker 설정의 `auths`와 `HttpHeaders` 섹션만 지원한다. 이는 자격증명 도우미(`credHelpers` 또는 `credStore`)가 지원되지 않는다는 뜻이다.
{{< /note >}}
Docker는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을
아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다.
@@ -310,7 +315,7 @@ type: kubernetes.io/dockerconfigjson
`error: no objects passed to create`라는 에러 메시지가 나오면, 그것은 base64 인코딩된 문자열이 유효하지 않다는 것을 뜻한다.
`Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...`와 유사한 에러 메시지가 나오면, 그것은
데이터가 성공적으로 un-base64 인코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
base64 인코딩 된 데이터가 성공적으로 디코딩되었지만, `.docker/config.json` 파일로는 파싱될 수 없었음을 의미한다.
#### 파드의 imagePullSecrets 참조
content/ko/docs/concepts/overview/components.md
+3 -2
View File
@@ -50,7 +50,7 @@ weight: 20
cloud-controller-manager는 클라우드-제공사업자-특유 컨트롤러 루프만을 동작시킨다. 이 컨트롤러 루프는 kube-controller-manager에서 비활성 시켜야만 한다. kube-controller-manager를 구동시킬 때 `--cloud-provider` 플래그를 `external`로 설정함으로써 이 컨트롤러 루프를 비활성 시킬 수 있다.
cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코어가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는, 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서, 클라우드 밴더에 따른 코드는 클라우드 밴더 자체에 의해 유지되도록 하여야만 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 하여야만 한다.
cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코드가 서로 독립적으로 발전시켜 나갈 수 있도록 해준다. 이전 릴리스에서는, 코어 쿠버네티스 코드가 기능상으로 클라우드-제공사업자-특유 코드에 대해 의존적이었다. 향후 릴리스에서, 클라우드 밴더에 따른 코드는 클라우드 밴더 자체에 의해 유지되도록 하여야만 하며, 쿠버네티스가 동작하는 동안 cloud-controller-manager에 연계되도록 하여야만 한다.
다음 컨트롤러들은 클라우드 제공사업자의 의존성을 갖는다.
@@ -73,7 +73,8 @@ cloud-controller-manager는 클라우드 밴더 코드와 쿠버네티스 코어
### 컨테이너 런타임
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다. 쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [rkt](https://coreos.com/rkt/), [runc](https://github.com/opencontainers/runc) 그리고 OCI [runtime-spec](https://github.com/opencontainers/runtime-spec)을 충족하는 모든 런타임 등이 있다.
컨테이너 런타임은 컨테이너의 동작을 책임지는 소프트웨어다.
쿠버네티스는 몇몇의 런타임을 지원하는데 [Docker](http://www.docker.com), [containerd](https://containerd.io), [cri-o](https://cri-o.io/), [rktlet](https://github.com/kubernetes-incubator/rktlet) 그리고 [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md)를 구현한 모든 런타임이다.
## 애드온
content/ko/docs/concepts/overview/object-management-kubectl/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: "kubectl을 이용한 오브젝트 관리"
weight: 50
---
content/ko/docs/concepts/overview/object-management-kubectl/overview.md
+186
View File
@@ -0,0 +1,186 @@
---
title: 쿠버네티스 오브젝트 관리
content_template: templates/concept
weight: 10
---
{{% capture overview %}}
`kubectl` 커맨드라인 툴은 쿠버네티스 오브젝트를 생성하고 관리하기 위한
몇 가지 상이한 방법을 지원한다. 이 문서는 여러가지 접근법에 대한 개요을
제공한다.
{{% /capture %}}
{{% capture body %}}
## 관리 기법
{{< warning >}}
쿠버네티스 오브젝트는 오직 하나의 기법을 사용하여 관리되어야 한다. 동일한 오브젝트에
대해 혼합하고 일치시키는 기법은 확실하지 않은 동작을 초래하게 된다.
{{< /warning >}}
| Management technique | Operates on |Recommended environment | Supported writers | Learning curve |
|----------------------------------|----------------------|------------------------|--------------------|----------------|
| Imperative commands | Live objects | Development projects | 1+ | Lowest |
| Imperative object configuration | Individual files | Production projects | 1 | Moderate |
| Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
## 명령형 명령어
명령형 명령어를 사용할 경우, 사용자는 클러스터 내 활성 오브젝트를 대상으로
직접 동작시킨다. 사용자는 `kubectl` 명령어에 인수 또는 플래그로 작업을
제공한다.
이것은 클러스터에서 일회성 작업을 개시시키거나 동작시키기 위한
가장 단순한 방법이다. 이 기법은 활성 오브젝트를 대상으로 직접적인
영향을 미치기 때문에, 이전 구성에 대한 이력을 제공해 주지 않는다.
### 예시
디프롤이먼트 오브젝트를 생성하기 위해 nginx 컨테이너의 인스턴스를 구동 시킨다.
```sh
kubectl run nginx --image nginx
```
다른 문법을 이용하여 동일한 작업을 수행한다.
```sh
kubectl create deployment nginx --image nginx
```
### 트레이드 오프
오브젝트 구성과 비교한 장점은
- 명령어가 익히기에 단순, 용이하고 기억하기 쉽다.
- 명령어가 클러스터에 변경을 주기 위해 오직 단일 과정만이 필요하다.
오브젝트 구성과 비교한 단점은
- 명령어가 변경 검토 프로세스와 통합되지 않는다.
- 명령어가 변경에 관한 감사 추적을 제공하지 않는다.
- 명렁어가 활성 동작 중인 경우를 제외하고는 레코드의 소스를 제공하지 않는다.
- 명령어가 새로운 오브젝트 생성을 위한 템플릿을 제공하지 않는다.
## 명령형 오브젝트 구성
명령형 오브젝트 구성에서, kubectl 명령은 작업 (생성, 대체 등),
선택적 플래그, 그리고 최소 하나의 파일 이름을 정의한다.
그 파일은 YAML 또는 JSON 형식으로 오브젝트의 완전한 정의를
포함해야만 한다.
오브젝트 정의에 대한 더 자세한 내용은 [API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)를
참고한다.
{{< warning >}}
명령형 `replace` 명령은 기존 spec을 새롭게 제공된 것으로 대체하며,
구성 파일에서 누락된 오브젝트에 대한 모든 변경사항은 없어진다.
이러한 접근은 구성 파일에 대해 독립적으로 spec이 업데이트되는
형태의 리소스와 함께 사용하면 안된다.
예를 들어, `LoadBalancer` 형태의 서비스는 `externalIPs` 필드를
클러스터 구성과는 독립적으로 업데이트한다.
{{< /warning >}}
### 예시
구성 파일에 정의된 오브젝트를 생성한다.
```sh
kubectl create -f nginx.yaml
```
두 개의 구성 파일에 정의된 오브젝트를 삭제한다.
```sh
kubectl delete -f nginx.yaml -f redis.yaml
```
활성 동작하는 구성을 덮어씀으로서 구성 파일에 정의된 오브젝트를
업데이트한다.
```sh
kubectl replace -f nginx.yaml
```
### 트레이드 오프
명령형 명령과 비교한 장점은
- 오브젝트 구성이 Git과 같은 소스 컨트롤 시스템에 보관되어 질 수 있다.
- 오브젝트 구성은 푸시와 감사 추적 전에 변경사항을 검토하는 것과 같은 프로세스들과 통합할 수 있다.
- 오브젝트 구성이 새로운 오브젝트 생성을 위한 템플릿을 제공한다.
명령형 명령과 비교한 단점은
- 오브젝트 구성이 오브젝트 스키마에 대한 기본적인 이해를 필요로 한다.
- 오브젝트 구성이 YAML 파일을 기록하는 추가적인 과정을 필요로 한다.
선언형 오브젝트 구성과 비교한 장점은
- 명령형 오브젝트 구성의 작용은 보다 간결하고 이해하기에 용이하다.
- 쿠버네티스 버전 1.5 부터, 명령형 오브젝트 구성이 더욱 발달한다.
선언형 오브젝트 구성과 비교한 단점은
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
- 활성 오브젝트에 대한 업데이트는 구성 파일 내 반영되어야만 한다. 그렇지 않으면 다음 대체가 이루어지는 동안 유실 될 것이다.
## 선언형 오브젝트 구성
선언형 오브젝트 구성을 사용할 경우, 사용자는 로컬에 보관된 오브젝트
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이것은 다른 오브젝트를 위해 필요할 수도 있는
다른 작업에서, 디렉토리들을 대상으로 동작할 수 있도록 해준다.
{{< note >}}
선언형 오브젝트 구성은 비록 그 변경사항이 오브젝트 구성 파일로
되돌려 병합될 수 없기는 하지만, 다른 작성자에 의해 이루어진 변경사항을 유지한다.
이는 전체 오브젝트 구성을 대체하기 위해 `replace` API 작업을 이용하는 대신,
오직 인지된 차이점을 기록하기 위한 `patch`
API 작업을 이용함으로서 가능하다.
{{< /note >}}
### 예시
`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
하고 나서 적용할 수 있다.
```sh
kubectl diff -f configs/
kubectl apply -f configs/
```
재귀적으로 디렉토리를 처리한다.
```sh
kubectl diff -R -f configs/
kubectl apply -R -f configs/
```
### 트레이드 오프
명령형 오브젝트 구성과 비교한 장점은
- 구성 파일로 되돌려 병합될 수 없기는 하지만, 활성 오브젝트에 직접 이루어진 변경사항이 유지된다.
- 선언형 오브젝트 구성은 디렉토리에 관한 동작에 대해 더 나은 지원을 하고 자동으로 오브젝트 마다의 작업(생성, 패치, 삭제)을 감지한다.
명령형 오브젝트 구성과 비교한 단점은
- 선언형 오브젝트 구성은 예측이 불가할 경우 디버그 하기가 더 어렵고 결과를 이해하기가 더 어렵다.
- 차이점를 이용한 부분적 업데이트는 복잡한 병합과 패치 작업을 만들어 낸다.
{{% /capture %}}
{{% capture whatsnext %}}
- [명령형 명령어를 이용한 쿠버네티스 오브젝트 관리하기](/docs/concepts/overview/object-management-kubectl/imperative-command/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (명령형)](/docs/concepts/overview/object-management-kubectl/imperative-config/)
- [오브젝트 구성을 이용한 쿠버네티스 오브젝트 관리하기 (선언형)](/docs/concepts/overview/object-management-kubectl/declarative-config/)
- [Kubectl 명령어 참조](/docs/reference/generated/kubectl/kubectl-commands/)
- [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
{{< comment >}}
{{< /comment >}}
{{% /capture %}}
content/ko/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+1 -1
View File
@@ -28,7 +28,7 @@ weight: 10
예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해 줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 (상태 변경에) 실패가 난다면, 쿠버네티스 시스템은 보정을 통해, 이 경우에는 인스턴스 대체를 착수하여, spec과 status 간의 차이에 대응한다.
오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md) 를 참조한다.
오브젝트 spec, staus, 그리고 metadata에 대한 추가 정보는, [Kubernetes API Conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md) 를 참조한다.
### 쿠버네티스 오브젝트 기술하기
content/ko/docs/concepts/workloads/pods/init-containers.md
+1 -1
View File
@@ -79,7 +79,7 @@ weight: 40
* 다음과 같은 커맨드로, 다운워드 API(Downward API)를 통한 원격 서버에 해당 파드를 등록하기.
curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'
`curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
* `sleep 60`와 같은 커맨드로 앱 컨테이너가 시작되기 전에 일정 시간 기다리기.
* git 저장소를 볼륨 안에 클론하기.
content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+37
View File
@@ -37,6 +37,8 @@ weight: 30
`Succeeded` | 파드에 있는 모든 컨테이너들이 성공으로 종료되었고, 재시작되지 않을 것이다.
`Failed` | 파드에 있는 모든 컨테이너들이 종료되었고, 적어도 하나 이상의 컨테이너가 실패로 종료되었다. 즉, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었다.
`Unknown` | 어떤 이유에 의해서 파드의 상태를 얻을 수 없다. 일반적으로 파드 호스트와의 통신 오류에 의해서 발생한다.
`Completed` | 완료된 잡(Job)과 같이 다 실행되어서 더 작동하고 있을 필요 없이 완료된 상태가 되었다.
`CrashLoopBackOff` | 파드 내 컨테이너 중 하나가 예상과는 달리 종료(exit)되었고, [restart policy](#restart-policy)에 따라 재시작된 뒤에도 0이 아닌 에러 코드가 발생했을 것이다.
## 파드의 조건(condition)
@@ -144,6 +146,41 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 두 가지
파드의 상태로서 보고되는 정보는 현재의
[ContainerState](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#containerstatus-v1-core)에 의존적이라는 점에 유의하길 바란다.
## 컨테이너 상태
일단 스케줄러가 파드를 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작한다. 컨테이너에 세 가지 상태가 있는데, Waiting, Running, 그리고 Terminated이다. 컨테이너의 상태를 체크하려면 `kubectl describe pod [POD_NAME]` 명령을 사용할 수 있다. 상태는 파드 안에 있는 컨테이너 각각에 대해 출력된다.
* `Waiting`: 컨테이너의 기본 상태이다. 컨테이너가 Running 이나 Terminated 상태가 아닌 경우, Waiting 상태이다. Waiting 상태의 컨테이너는 이미지를 내려받거나(pull), 시크릿을 적용하는 등의 필요한 오퍼레이션이 수행 중인 상태이다. 이 상태와 더불어서, 더 자세한 정보를 제공하기 위해 상태에 대한 메시지와 이유가 출력된다.
```yaml
...
State: Waiting
Reason: ErrImagePull
...
```
* `Running`: 컨테이너가 이슈 없이 구동된다는 뜻이다. 컨테이너가 Running 상태가 되면, `postStart` 훅이 (존재한다면) 실행된다. 이 상태는 컨테이너가 언제 Running 상태에 돌입한 시간도 함께 출력된다.
```yaml
...
State: Running
Started: Wed, 30 Jan 2019 16:46:38 +0530
...
```
* `Terminated`: 컨테이너가 실행이 완료되어 구동을 멈추었다는 뜻이다. 컨테이너가 성공적으로 작업을 완료했을 때나 어떤 이유에서 실패했을 때 이 상태가 된다. 원인과 종료 코드(exit code)가 컨테이너의 시작과 종료 시간과 함께 무조건 출력된다.
컨테이너가 Terminated 상태가 되기 전에, `preStop` 훅이 (존재한다면) 실행된다.
```yaml
...
State: Terminated
Reason: Completed
Exit Code: 0
Started: Wed, 30 Jan 2019 11:45:26 +0530
Finished: Wed, 30 Jan 2019 11:45:26 +0530
...
```
## 파드의 준비성 게이트(readiness gate)
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
content/ko/docs/concepts/workloads/pods/pod-overview.md
+1 -1
View File
@@ -103,5 +103,5 @@ spec:
{{% capture whatsnext %}}
* 파드의 다른 동작들을 더 배워보자.
* [파드 종료](/docs/concepts/workloads/pods/pod/#termination-of-pods)
* 다른 파드 주제
* [파드 라이프사이클](../pod-lifecycle)
{{% /capture %}}
content/ko/docs/contribute/_index.md
+52 -52
View File
@@ -8,66 +8,66 @@ weight: 80
{{% capture overview %}}
If you would like to help contribute to the Kubernetes documentation or website,
we're happy to have your help! Anyone can contribute, whether you're new to the
project or you've been around a long time, and whether you self-identify as a
developer, an end user, or someone who just can't stand seeing typos.
쿠버네티스 문서 또는 웹사이트에 기여하여 도움을 제공하고 싶다면,
우리는 당신의 도움을 기쁘게 생각한다! 당신이 새로운 프로젝트에 참여했거나
오랜 시간 동안 진행해온 누군가로써,
혹은 개발자, 최종 사용자 또는 단지 오타를 보고 참지 못하는 누군가로써
기여할 수 있다.
For more ways to get involved in the Kubernetes community or to learn about us, visit the [Kubernetes community site](/community/).
For information on the Kubernetes documentation style guide, see the [style guide](/docs/contribute/style/style-guide/).
쿠버네티스 커뮤니티에 참여하거나, 우리에 대해 더 많이 알아보고 싶다면, [쿠버네티스 커뮤니티 사이트](/community/)를 방문하자.
쿠버네티스 문서 스타일 가이드에 대해 더 많은 정보를 알고 싶다면, [스타일 가이드](/docs/contribute/style/style-guide/)를 참고하자.
{{% capture body %}}
## Types of contributors
## 컨트리뷰터 유형
- A _member_ of the Kubernetes organization who has [signed the CLA](/docs/contribute/start#sign-the-cla)
and contributed some time and effort to the project. See
[Community membership](https://github.com/kubernetes/community/blob/master/community-membership.md)
for specific criteria for membership.
- A SIG Docs _reviewer_ is a member of the Kubernetes organization who has
expressed interest in reviewing documentation pull requests and who has been
added to the appropriate Github group and `OWNERS` files in the Github
repository, by a SIG Docs Approver.
- A SIG Docs _approver_ is a member in good standing who has shown a continued
commitment to the project. An approver can merge pull requests
and publish content on behalf of the Kubernetes organization.
Approvers can also represent SIG Docs in the larger Kubernetes community.
Some of the duties of a SIG Docs approver, such as coordinating a release,
require a significant time commitment.
- 쿠버네티스 조직의 _멤버_ 는 [CLA에 서명](/docs/contribute/start#sign-the-cla)하고,
프로젝트에 어느 정도 시간과 노력을 바친 사람이다.
멤버십 자격에 대한 구체적인 기준은 [커뮤니티 멤버십](https://github.com/kubernetes/community/blob/master/community-membership.md)을
참고하라.
- SIG Docs _리뷰어_ 는 문서 풀 리퀘스트(pull request) 리뷰하는 일에 관심을 보여서
SIG Docs 승안자가 적합한
Github 그룹 및 저장소 내 그룹과 `OWNERS` 파일에 등록한
쿠버네티스 조직의 멤버이다.
- SIG Docs _승인자_ 는 지속적으로 프로젝트에 기여를 해온 좋은 입지를 가진 멤버이다.
승인자는 풀 리퀘스트를 머지(merge)할 수 있고,
쿠버네티스 조직을 대표하여 콘텐츠를 공개한다.
승인자는 거대한 쿠버네티스 커뮤니티에서 SIG Docs를 대표할 수 있다.
SIG Docs 승인자의 의무 중 릴리스 조정과 같은 일은
상당한 시간을 필요로 한다.
## Ways to contribute
## 기여할 수 있는 방법
This list is divided into things anyone can do, things Kubernetes organization
members can do, and things that require a higher level of access and familiarity
with SIG Docs processes. Contributing consistently over time can help you
understand some of the tooling and organizational decisions that have already
been made.
이 목록은 누구나 할 수 있는 일, 쿠버네티스 조직 멤버가 할 수 있는 일,
그리고 SIG Docs 프로세스의 더 높은 레벨의 접근과 친숙함을 요구하는
일으로 나누어졌다. 지속적으로 기여를 하는 것은 이미 만들어진 도구(tooling)와 조직의 결정을
이해하는데 도움이 될 것이다.
This is not an exhaustive list of ways you can contribute to the Kubernetes
documentation, but it should help you get started.
이것은 쿠버네티스 문서에 기여하는 완전한 방법은 아니지만,
시작하는 데에 도움이 될 것이다.
- [Anyone](/docs/contribute/start/)
- File actionable bugs
- [Member](/docs/contribute/start/)
- Improve existing docs
- Bring up ideas for improvement on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
- Improve docs accessibility
- Provide non-binding feedback on PRs
- Write a blog post or case study
- [Reviewer](/docs/contribute/intermediate/)
- Document new features
- Triage and categorize issues
- Review PRs
- Create diagrams, graphics assets, and embeddable screencasts / videos
- Localization
- Contribute to other repos as a docs representative
- Edit user-facing strings in code
- Improve code comments, Godoc
- [Approver](/docs/contribute/advanced/)
- Publish contributor content by approving and merging PRs
- Participate in a Kubernetes release team as a docs representative
- Propose improvements to the style guide
- Propose improvements to docs tests
- Propose improvements to the Kubernetes website or other tooling
- [누구나](/docs/contribute/start/)
- 조치 가능한 버그 리포트 제출
- [멤버](/docs/contribute/start/)
- 기존 문서 개선
- [Slack](http://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에서 개선을 위한 아이디어 제시
- 문서 접근성 개선
- PR에 대한 구속력 없는 피드백 제공
- 블로그 포스트 또는 사례 연구 작성
- [리뷰어](/docs/contribute/intermediate/)
- 새로운 기능 문서화
- 이슈 선별 및 분류
- PR 리뷰
- 다이어그램, 그래픽 자료, 내장 스크린샷 생성
- 현지화(Localization)
- docs 대표로 다른 저장소에 기여
- 코드 내 사용자 대면 문자열 편집
- 코드 주석 및 Godoc 개선
- [승인자](/docs/contribute/advanced/)
- 승인되어 머지된 PR을 바탕으로 컨트리뷰터 콘텐츠 출시
- docs 대표로 쿠버네티스 릴리스 팀에 참가
- 스타일 가이드 개선 제안
- 문서 테스트 개선 제안
- 쿠버네티스 website 또는 기타 도구(tooling) 개선 제안
{{% /capture %}}
content/ko/docs/contribute/localization_ko.md
+12 -1
View File
@@ -19,13 +19,24 @@ content_template: templates/concept
평어체 사용을 원칙으로 하나, 일부 페이지(예: [https://kubernetes.io/ko](https://kubernetes.io/ko))에 한해 예외적으로
높임말을 사용한다.
### 명령형
어떤 일을 하도록 청자에게 요구하는 명령형 표현은 간결하고 부드러운 표현으로 정확한 의미를 전달하기 위해
어떤 일을 함께 하기를 요청하는 청유형 또는 객관적으로 진술하는 평어체로 번역한다.
명령형 문장 | 번역체
--- | ---
사이트를 방문하라 | 사이트를 방문하자 (청유형)
가이드를 참고하라 | 가이드를 참고한다 (평어체)
### 번역체 지양
우리글로서 자연스럽고 무리가 없도록 번역한다.
번역체 | 자연스러운 문장
--- | ---
-되어지다 (이중 피동 표현) | -되다
-되어지다 (이중 피동 표현) | -되다
짧은 다리를 가진 돼지 | 다리가 짧은 돼지
그는 그의 손으로 숟가락을 들어 그의 밥을 먹었다 | 그는 손으로 숟가락을 들어 밥을 먹었다
접시를 씻고 | 설거지를 하고
content/ko/docs/home/_index.md
+1 -1
View File
@@ -12,5 +12,5 @@ menu:
title: "문서"
weight: 20
post: >
<p>Learn how to use Kubernetes with conceptual, tutorial, and reference documentation. You can even <a href="/editdocs/" data-auto-burger-exclude>help contribute to the docs</a>!</p>
<p>개념, 튜토리얼 및 참조 문서와 함께 쿠버네티스 사용하는 방법을 익힐 수 있다. 또한, <a href="/editdocs/" data-auto-burger-exclude>문서에 기여하는 것도 도움을 줄 수 있다</a>!</p>
---
content/ko/docs/setup/cri.md
+30 -6
View File
@@ -1,7 +1,4 @@
---
reviewers:
- vincepri
- bart0sh
title: CRI 설치
content_template: templates/concept
weight: 100
@@ -17,10 +14,37 @@ v1.6.0에서부터, 쿠버네티스는 CRI(컨테이너 런타임 인터페이
다음의 커맨드들은 사용자의 운영체제에 따라 root로서 실행하길 바란다.
각 호스트에 SSH 접속 후 `sudo -i` 실행을 통해서 root 사용자가 될 수 있을 것이다.
{{< caution >}}
A flaw was found in the way runc handled system file descriptors when running containers.
A malicious container could use this flaw to overwrite contents of the runc binary and
consequently run arbitrary commands on the container host system.
Please refer to this link for more information about this issue
[cve-2019-5736 : runc vulnerability ] (https://access.redhat.com/security/cve/cve-2019-5736)
{{< /caution >}}
## Cgroup 드라이버
Linux 배포판의 init 시스템이 systemd인 경우, init 프로세스는 루트 cgroup을 생성 및 사용하고
cgroup 관리자로 작동한다. Systemd는 cgroup과의 긴밀한 통합을 통해
프로세스당 cgroup을 할당한다. 컨테이너 런타임과 kubelet이
`cgroupfs`를 사용하도록 설정할 수 있다. 이 경우는 두 개의 서로 다른 cgroup 관리자가 존재하게 된다는 뜻이다.
Cgroup은 프로세스에 할당된 리소스를 제한하는데 사용된다.
단일 cgroup 관리자는 할당된 리소스가 무엇인지를 단순화하고,
기본적으로 사용가능한 리소스와 사용중인 리소스를 일관성있게 볼 수 있다.
관리자가 두 개인 경우, 이런 리소스도 두 개의 관점에서 보게 된다. kubelet과 Docker는
`cgroupfs`를 사용하고 나머지 프로세스는
`systemd`를 사용하도록 노드가 설정된 경우,
리소스가 부족할 때 불안정해지는 사례를 본 적이 있다.
컨테이너 런타임과 kubelet이 `systemd`를 cgroup 드라이버로 사용하도록 설정을 변경하면
시스템이 안정화된다. 아래의 Docker 설정에서 `native.cgroupdriver=systemd` 옵션을 확인하라.
## Docker
각 머신들에 대해서, Docker를 설치한다.
버전 18.06이 추천된다. 그러나 1.11, 1.12, 1.13, 그리고 17.03도 동작하는 것으로 알려져 있다.
버전 18.06.2가 추천된다. 그러나 1.11, 1.12, 1.13, 17.03 그리고 18.09도 동작하는 것으로 알려져 있다.
쿠버네티스 릴리스 노트를 통해서, 최신에 검증된 Docker 버전의 지속적인 파악이 필요하다.
시스템에 Docker를 설치하기 위해서 아래의 커맨드들을 사용한다.
@@ -45,7 +69,7 @@ v1.6.0에서부터, 쿠버네티스는 CRI(컨테이너 런타임 인터페이
stable"
## Docker ce 설치.
apt-get update && apt-get install docker-ce=18.06.0~ce~3-0~ubuntu
apt-get update && apt-get install docker-ce=18.06.2~ce~3-0~ubuntu
# 데몬 설정.
cat > /etc/docker/daemon.json <<EOF
@@ -78,7 +102,7 @@ yum-config-manager \
https://download.docker.com/linux/centos/docker-ce.repo
## Docker ce 설치.
yum update && yum install docker-ce-18.06.1.ce
yum update && yum install docker-ce-18.06.2.ce
## /etc/docker 디렉토리 생성.
mkdir /etc/docker
content/ko/docs/setup/minikube.md
+9 -3
View File
@@ -39,7 +39,7 @@ VM 드라이버를 바꾸기 원하면 적절한 `--vm-driver=xxx` 플래그를
* hyperkit ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#hyperkit-driver))
* xhyve ([driver installation](https://git.k8s.io/minikube/docs/drivers.md#xhyve-driver)) (deprecated)
* hyperv ([driver installation](https://github.com/kubernetes/minikube/blob/master/docs/drivers.md#hyperv-driver))
아래 나오는 IP 주소는 동적이므로 바뀔 수 있다. `minikube ip`를 하면 알 수 있다.
* none (쿠버네티스 구성요소는 VM이 아닌 호스트상에서 동작한다. 이 드라이버를 사용하기 위해서는 Docker ([docker 설치](https://docs.docker.com/install/linux/docker-ce/ubuntu/))와 리눅스 환경)이 필요하다.
```shell
$ minikube start
@@ -111,6 +111,7 @@ Stopping "minikube"...
```bash
$ minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=containerd \
--bootstrapper=kubeadm
```
@@ -120,6 +121,7 @@ $ minikube start \
```bash
$ minikube start \
--network-plugin=cni \
--enable-default-cni \
--extra-config=kubelet.container-runtime=remote \
--extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \
--extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \
@@ -133,6 +135,7 @@ $ minikube start \
```bash
$ minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=cri-o \
--bootstrapper=kubeadm
```
@@ -142,6 +145,7 @@ $ minikube start \
```bash
$ minikube start \
--network-plugin=cni \
--enable-default-cni \
--extra-config=kubelet.container-runtime=remote \
--extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \
--extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \
@@ -155,6 +159,7 @@ $ minikube start \
```shell
$ minikube start \
--network-plugin=cni \
--enable-default-cni \
--container-runtime=rkt
```
@@ -396,8 +401,9 @@ Minikube에 대한 더 자세한 정보는, [제안](https://git.k8s.io/communit
* **목표와 비목표**: Minikube 프로젝트의 목표와 비목표에 대해서는 [로드맵](https://git.k8s.io/minikube/docs/contributors/roadmap.md)을 살펴보자.
* **개발 가이드**: 풀 리퀘스트를 보내는 방법에 대한 개요는 [참여 가이드](https://git.k8s.io/minikube/CONTRIBUTING.md)를 살펴보자.
* **Minikube 빌드**: Minikube를 소스에서 빌드/테스트하는 방법은 [빌드 가이드](https://git.k8s.io/minikube/docs/contributors/build_guide.md)를 살펴보자.
* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는 [의존성 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)를 보자.
* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는 [애드온 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)를 보자.
* **새 의존성 추가하기**: Minikube에 새 의존성을 추가하는 방법에 대해서는, [의존성 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_a_dependency.md)를 보자.
* **새 애드온 추가하기**: Minikube에 새 애드온을 추가하는 방법에 대해서는, [애드온 추가 가이드](https://git.k8s.io/minikube/docs/contributors/adding_an_addon.md)를 보자.
* **MicroK8s**: 가상 머신을 사용하지 않으려는 Linux 사용자는 대안으로 [MicroK8s](https://microk8s.io/)를 고려할 수 있다.
## 커뮤니티
content/ko/docs/setup/pick-right-solution.md
+7 -6
View File
@@ -29,12 +29,12 @@ content_template: templates/concept
* [Minikube](/docs/setup/minikube/)는 개발과 테스트를 위한 단일 노드 쿠버네티스 클러스터를 로컬에 생성하기 위한 하나의 방법이다. 설치는 완전히 자동화 되어 있고, 클라우드 공급자 계정 정보가 필요하지 않다.
* [Docker Desktop](https://www.docker.com/products/docker-desktop)는
Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다.
* [Docker Desktop](https://www.docker.com/products/docker-desktop)는
Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다.
수 분 내에 단일 노드 쿠버네티스 클러스터에서 컨테이너로 코딩과 배포를
시작할 수 있게 해준다.
* [Minishift](https://docs.okd.io/latest/minishift/)는 커뮤니티 버전의 쿠버네티스 엔터프라이즈 플랫폼 OpenShift를 로컬 개발과 테스트 용으로 설치한다. Windows, macOS와 리눅스를 위한 All-In-One VM (`minishift start`)과 컨테이너 기반의 `oc cluster up` (리눅스 전용)을 지원하고 [쉬운 설치가 가능한 몇 가지 애드온도 포함](https://github.com/minishift/minishift-addons/tree/master/add-ons)한다.
* [Minishift](https://docs.okd.io/latest/minishift/)는 커뮤니티 버전의 쿠버네티스 엔터프라이즈 플랫폼 OpenShift를 로컬 개발과 테스트 용으로 설치한다. Windows, macOS와 리눅스를 위한 all-in-one VM (`minishift start`)과 컨테이너 기반의 `oc cluster up` (리눅스 전용)을 지원하고 [포함된 애드온](https://github.com/minishift/minishift-addons/tree/master/add-ons)을 설치할 수 있다.
* [Microk8s](https://microk8s.io/)는 개발과 테스트를 위한 쿠버네티스 최신 버전을 단일 명령어로 로컬 머신 상의 설치를 제공한다. 설치는 신속하고 빠르며(~30초) 단일 명령어로 Istio를 포함한 많은 플러그인을 지원한다.
@@ -70,6 +70,8 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
* [Kublr](https://kublr.com)는 AWS, Azure, GCP 및 온-프레미스에서 기업 수준의 안전하고, 확장 가능하며, 신뢰성 높은 쿠버네티스 클러스터를 제공한다. 여기에는 즉시 사용 가능한 백업 및 재해 복구, 중앙 집중식 다중 클러스터 로깅 및 모니터링, 내장 경고 서비스가 포함된다.
* [KubeSail](https://kubesail.com)는 쿠버네티스를 쉽고, 무료로 시도할 수 있는 방법이다.
* [Madcore.Ai](https://madcore.ai)는 AWS에서 쿠버네티스 인프라를 배포하기 위한 devops 중심의 CLI 도구이다. 또한 마스터, 스팟 인스턴스 그룹 노드 오토-스케일링, ingress-ssl-lego, Heapster, Grafana를 지원한다.
* [Nutanix Karbon](https://www.nutanix.com/products/karbon/)는 다중 클러스터의 고 가용성 쿠버네티스 관리 운영 플랫폼으로, 쿠버네티스의 프로비저닝, 운영 및 라이프 사이클 관리를 단순화해준다.
@@ -147,11 +149,9 @@ Mac 또는 Windows 환경에서 쉽게 설치 가능한 애플리케이션이다
특별한 요구사항이 있기 때문에, 또는 단지 쿠버네티스 클러스터의 아래에 무엇이 있는지를 이해하기 원하기 때문에
처음부터 시작하기를 원한다면, [맨 처음부터 시작하기](/docs/setup/scratch/) 가이드를 시도하라.
새로운 플랫폼에서 쿠버네티스 지원하는 것에 관심이 있다면, [Writing a Getting Started Guide](https://git.k8s.io/community/contributors/devel/writing-a-getting-started-guide.md) 가이드를 참고하라.
### 일반
호스팅한 리소스를 구성하는 방법을 이미 알고 있다면, [kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하면 머신당 단일 명령어로 쉽게 클러스터를 가지고 올 수 있다.
호스팅한 리소스를 구성하는 방법을 이미 알고 있다면, [kubeadm](/docs/setup/independent/create-cluster-kubeadm/)을 사용하면 머신당 단일 명령어로 클러스터를 가지고 올 수 있다.
### 클라우드
@@ -205,6 +205,7 @@ IaaS 공급자 | 구성 관리 | OS | 네트워킹 | 문서
any | any | multi-support | any CNI | [docs](/docs/setup/independent/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle))
Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial
Docker Enterprise | custom | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial
IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) |
Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial
Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial
AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial
content/ko/docs/setup/release/building-from-source.md
+6 -1
View File
@@ -1,11 +1,15 @@
---
title: 소스로부터 빌드
title: 릴리스 빌드
content_template: templates/concept
---
{{% capture overview %}}
소스로부터 빌드하거나 이미 빌드된 릴리스를 다운받을 수 있다. 쿠버네티스를 자체를 개발할 계획이 없다면, [릴리스 노트](/docs/setup/release/notes/)에 있는 현재 릴리스 빌드 버전을 사용하는 것을 추천한다.
쿠버네티스 소스 코드는 [kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) 리포지토리에서 다운받을 수 있다.
{{% /capture %}}
{{% capture body %}}
## 소스로부터 빌드
소스 코드를 빌드만 하려면, 모든 빌드 과정이 Docker 컨테이너 안에서 실행되기 때문에 golang 환경을 구축할 필요가 없다.
@@ -19,3 +23,4 @@ make release
```
릴리스 절차에 대한 더 자세한 설명은 kubernetes/kubernetes [`빌드`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) 디렉토리를 참조한다.
{{% /capture %}}
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+164 -61
View File
@@ -3,7 +3,7 @@ title: Horizontal Pod Autoscaler
feature:
title: Horizontal 스케일링
description: >
간단한 명령어, UI를 통해 또는 CPU 사용량에 따라 자동으로 어플리케이션을 스케일 업과 다운을 한다.
간단한 명령어나 UI를 통해서 또는 CPU 사용량에 따라 자동으로 애플리케이션의 스케일을 업 또는 다운한다.
content_template: templates/concept
weight: 90
@@ -11,13 +11,16 @@ weight: 90
{{% capture overview %}}
Horizontal Pod Autoscaler는 CPU 사용량(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md), 아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션 컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다. Horizontal Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다.
Horizontal Pod Autoscaler는 CPU 사용량
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다. Horizontal
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다.
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
리소스는 컨트롤러의 동작을 결정한다.
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
{{% /capture %}}
@@ -28,137 +31,237 @@ Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로
![Horizontal Pod Autoscaler 다이어그램](/images/docs/horizontal-pod-autoscaler.svg)
Horizontal Pod Autoscaler는 컨트롤러
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
Horizontal Pod Autoscaler는 컨트롤러 관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은 30 초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
메트릭 API(파드 단위 리소스 메트릭 용)
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스 메트릭 API(파드 단위 리소스 메트릭 용) 또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
사용되는 비율을 생성한다.
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
섹션을 참조하기 바란다.
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가 대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다. 그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의 컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을 계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다. 그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된 대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데 사용되는 비율을 생성한다.
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우, 파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는 해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링 알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) 섹션을 참조하기 바란다.
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
선택적으로 나눌 수 있다.
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을 제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는 단일 메트릭을 가져온다. 이 메트릭은 목표 값과 비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API 버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로 선택적으로 나눌 수 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, `custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다.
`metrics.k8s.io` API는 대개 별도로 시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는 [메트릭-서버](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)를 참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
[메트릭-서버](https://kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/#metrics-server)를
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
{{< note >}}
{{< feature-state state="deprecated" for_k8s_version="1.11" >}}
힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨.
{{< /note >}}
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조하라.
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
하위 리소스 스케일에 대한 자세한 내용은 [여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다.
하위 리소스 스케일에 대한 자세한 내용은
[여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다.
### 알고리즘 세부 정보
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는 원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로 작동한다.
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는
원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로
작동한다.
```
원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]
```
예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이 `100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가 된다.
만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로 복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는 `-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여 전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이
`100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가
된다. 만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로
복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는
`-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여
전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
`targetAverageValue` 또는 `targetAverageUtilization`가 지정되면, `currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표 안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다. 허용치를 확인하고 최종 값을 결정하기 전에, 파드 준비 상태와 누락된 메트릭을 고려한다.
`targetAverageValue` 또는 `targetAverageUtilization`가 지정되면,
`currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표
안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.
허용치를 확인하고 최종 값을 결정하기 전에, 파드
준비 상태와 누락된 메트릭을 고려한다.
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료 중인 파드) 및 실패한 파드는 모두 폐기된다.
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료
중인 파드) 및 실패한 파드는 모두 폐기된다.
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와 같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와
같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히 초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기 전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히
초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기
전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,
준비를 위한 어떠한 전환이라도 이를 시작 시간으로 간주한다. 이
값은 `--horizontal-pod-autoscaler-cpu-initialization-period` 플래그로 설정되며
기본값은 5분이다.
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는 특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는 시작 시간을 정확하게 알 수 없다.
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
대신, 파드가 아직 준비되지 않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로 전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
스케일의 크기를 약화시킨다.
이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면, 준비를 위한 어떠한 전환이라도 이를 시작 시간으로 간주한다. 이 값은 `--horizontal-pod-autoscaler-cpu-initialization-period` 플래그로 설정되며 기본값은 5분이다.
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에 사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
비율을 다시 계산한다. 새 비율이 스케일 방향을
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
비율을 사용하여 스케일한다.
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우 원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고 가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인 스케일의 크기를 약화시킨다.
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
고려없이 HorizontalPodAutoscaler 상태를 통해 다시
보고된다.
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나 아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우, 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고 보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용 비율을 다시 계산한다. 새 비율이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새 비율을 사용하여 스케일한다.
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는 경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한 고려없이 HorizontalPodAutoscaler 상태를 통해 다시 보고된다. HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은 각 메트릭에 대해 수행된 다음 원하는 레플리카 수 중 가장 큰 값이 선택된다.
이러한 메트릭 중 어떠한 것도 원하는 레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을 가져오는 중 오류 발생) 스케일을 건너뛴다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization-window` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다. 즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의 영향을 완만하게 한다.
HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
각 메트릭에 대해 수행된 다음 원하는 레플리카 수 중 가장
큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
가져오는 중 오류 발생) 스케일을 건너뛴다.
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization-window` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
영향을 완만하게 한다.
## API 오브젝트
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다. CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은 `autoscaling/v1` API 버전에서 찾을 수 있다.
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
`autoscaling/v1` API 버전에서 찾을 수 있다.
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은 `autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된 새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
API 오브젝트에 대한 자세한 내용은 [HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다.
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object)에서 찾을 수 있다.
## kubectl에서 Horizontal Pod Autoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다. `kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다. `kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다. 마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
`kubectl create` 커맨드를 사용하여 새로운 오토스케일러를 만들 수 있다.
`kubectl get hpa`로 오토스케일러 목록을 조회할 수 있고, `kubectl describe hpa`로 세부 사항을 확인할 수 있다.
마지막으로 `kubectl delete hpa`를 사용하여 오토스케일러를 삭제할 수 있다.
또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다.
예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을
실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`,
그리고 2와 5 사이의 레플리카 개수로 설정된다.
`kubectl autoscale`에 대한 자세한 문서는 [여기](/docs/reference/generated/kubectl/kubectl-commands/#autoscale)에서 찾을 수 있다.
또한 Horizontal Pod Autoscaler를 쉽게 생성 할 수 있는 `kubectl autoscale`이라는 특별한 명령이 있다. 예를 들어 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`을 실행하면 레플리케이션 셋 *foo* 에 대한 오토스케일러가 생성되고, 목표 CPU 사용률은 `80 %`, 그리고 2와 5 사이의 레플리카 개수로 설정된다. `kubectl autoscale`에 대한 자세한 문서는 [여기](/docs/reference/generated/kubectl/kubectl-commands/#autoscale)에서 찾을 수 있다.
## 롤링 업데이트 중 오토스케일링
현재 쿠버네티스에서는 레플리케이션 컨트롤러를 직접 관리하거나, 기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 [롤링 업데이트](/docs/tasks/run-application/rolling-update-replication-controller/)를 수행 할 수 있다. Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고, 디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다.
현재 쿠버네티스에서는 레플리케이션 컨트롤러를 직접 관리하거나,
기본 레플리카 셋를 관리하는 디플로이먼트 오브젝트를 사용하여 [롤링 업데이트](/docs/tasks/run-application/rolling-update-replication-controller/)를 수행 할 수 있다.
Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카 셋의 크기를 결정한다.
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다. 즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때, Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
## 쿨-다운 / 지연에 대한 지원
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때, 평가된 메트릭의 동적인 특징 때문에 레플리카 수가 자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성 요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다.
v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성
요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한 필요성을 제거하였다.
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
필요성을 제거하였다.
- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은 오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을 수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다. 기본값은 5분(`5m0s`)이다.
- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은
오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을
수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다.
기본값은 5분(`5m0s`)이다.
{{< note >}}
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야 한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가 워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을 너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수 있다.
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
너무 짧게 설정하면, 레플리카 셋의 크기가 평소와 같이 계속 스래싱될 수
있다.
{{< /note >}}
## 멀티 메트릭을 위한 지원
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다.
`autoscaling/v2beta2` API 버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다. 제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod
Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다.
제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
## 사용자 정의 메트릭을 위한 지원
{{< note >}}
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다. 쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의 메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고 Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
{{< /note >}}
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다. 그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
## 메트릭 API를 위한 지원
기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한 API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 API에서 메트릭을 검색한다. 이러한
API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
* [API 집합 레이어](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 활성화
* 해당 API 등록:
* 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server)가 제공하는 `metrics.k8s.io` API이다. 클러스터 애드온으로 시작할 수 있다.
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다. 메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다. 직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-incubator/custom-metrics-apiserver)을 확인하라.
* 해당 API 등록:
* 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](https://github.com/kubernetes-incubator/metrics-server)가 제공하는 `metrics.k8s.io` API이다.
클러스터 애드온으로 시작할 수 있다.
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다.
메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다.
직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-incubator/custom-metrics-apiserver)을 확인하라.
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
content/ko/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -60,7 +60,7 @@ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/miniku
Minikube 실행 파일을 경로에 추가하는 쉬운 방법은 다음과 같다.
```shell
sudo cp minikube /usr/local/bin && rm minikube
sudo mv minikube /usr/local/bin
```
### Linux
content/ko/docs/tutorials/hello-minikube.md
+1 -1
View File
@@ -153,7 +153,7 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다.
4. Katacoda 환경에서만: 플러스를 클릭한 후에 **Select port to view on Host 1** 를 클릭.
5. Katacoda 환경에서만: 포트 번호를 `30369`로 입력하고(서비스 출력 `8080`과 반대편의 포트를 참조), **Display Port** 클릭.
5. Katacoda 환경에서만: 포트 번호를 `30369`로 입력하고(서비스 출력 `8080`과 반대편의 포트를 참조), 클릭.
이렇게 하면 당신의 앱을 서비스하는 브라우저 윈도우를 띄우고 "Hello World" 메시지를 보여준다.
content/ko/docs/tutorials/online-training/overview.md
+15 -13
View File
@@ -5,30 +5,32 @@ content_template: templates/concept
{{% capture overview %}}
이 페이지에서는 쿠버네티스 온라인 트레이닝을 제공하는 사이트를 소개한다:
이 페이지에서는 쿠버네티스 온라인 트레이닝을 제공하는 사이트를 소개한다.
{{% /capture %}}
{{% capture body %}}
* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
* [Certified Kubernetes Administrator 준비 과정 (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course)
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
* [Certified Kubernetes Application Developer 준비 과정 및 모의 시험 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course)
* [Getting Started with Kubernetes (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
* [Google Kubernetes Engine 시작하기 (Coursera)](https://www.coursera.org/learn/google-kubernetes-engine)
* [Hands-on Introduction to Kubernetes (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
* [쿠버네티스 시작하기 (Pluralsight)](https://www.pluralsight.com/courses/getting-started-kubernetes)
* [Learn Kubernetes using Interactive Hands-on Scenarios (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
* [쿠버네티스 소개 및 실습 (Instruqt)](https://play.instruqt.com/public/topics/getting-started-with-kubernetes)
* [Certified Kubernetes Administrator Preparation Course (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/certified-kubernetes-administrator-preparation-course)
* [IBM 클라우드: 쿠버네티스로 마이크로서비스(Microservices) 배포 (Coursera)](https://www.coursera.org/learn/deploy-micro-kube-ibm-cloud)
* [Kubernetes the Hard Way (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
* [쿠버네티스 소개 (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x)
* [Certified Kubernetes Application Developer Preparation Course (KodeKloud.com)](https://kodekloud.com/p/kubernetes-certification-course)
* [초보자를 위한 쿠버네티스 실습 랩 (KodeKloud.com)](https://kodekloud.com/p/kubernetes-for-the-absolute-beginners-hands-on)
* [쿠버네티스 심화 학습 (LinuxAcademy.com)](https://linuxacademy.com/linux/training/course/name/kubernetes-the-hard-way)
* [대화식 실습 시나리오를 사용하여 쿠버네티스 배우기 (Katacoda)](https://www.katacoda.com/courses/kubernetes/)
* [쿠버네티스와 확장 가능한 마이크로서비스(Microservices) (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615)
{{% /capture %}}