First Korean l10n work for release-1.15 (#15356)
* Translate concepts/workloads/controllers/replicationcontroller in Korean (#15044) * ko: Update outdated 1.14-ko.4 branch (#15099) * Translate tasks/access-application-cluster/configure-access-multiple-clusters in Korean (#15121) * Translate standardized glossary items in Tag Network into Korean (#15278) * ko: Keep up with upstream - renamed files (#15030) Co-Authored-By: Seokho <shsongist@gmail.com> Co-Authored-By: lapee79 <lapee79@gmail.com> Co-Authored-By: Yoon <learder@gmail.com> Co-Authored-By: June Yi <june.yi@samsung.com>
This commit is contained in:
June Yi
committed by
Kubernetes Prow Robot
Kubernetes Prow Robot
parent
bdf4e5fef6
commit
113008ff6e
+8
-6
@@ -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)을 확인한다.
|
||||
|
||||
|
||||
+379
@@ -0,0 +1,379 @@
|
||||
---
|
||||
title: 다중 클러스터 접근 구성
|
||||
content_template: templates/task
|
||||
weight: 30
|
||||
card:
|
||||
name: tasks
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록
|
||||
설정하는 방식을 보여준다. 클러스터, 사용자, 컨텍스트가 하나 이상의
|
||||
구성 파일에 정의된 다음 `kubectl config use-context` 커맨드를
|
||||
사용하여 클러스터를 빠르게 변경할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
클러스터에 접근할 수 있도록 설정하는데 사용되는 파일은 종종 *kubeconfig file* 이라고
|
||||
불린다. 이는 구성 파일을 참조하는 일반적인 방식으로 `kubeconfig`라는 이름을 가진 파일이
|
||||
반드시 존재해야 한다는 것을 의미하는 것은 아니다.
|
||||
{{< /note >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture steps %}}
|
||||
|
||||
## 클러스터, 사용자, 컨텍스트 정의
|
||||
|
||||
당신이 개발 작업을 위한 클러스터와 스크래치 작업을 위한 클러스터를 가지고 있다고 가정해보자.
|
||||
`development` 클러스터에서는 프런트 엔드 개발자들이 `frontend`라는 네임스페이스에서
|
||||
작업을 하고 있고, 스토리지 개발자들은 `storage`라는 네임스페이스에서 작업을 하고 있다.
|
||||
`scratch` 클러스터에서는 개발자들이 default 네임스페이스에서 개발하거나 필요에 따라 보조
|
||||
네임스페이스들을 생성하고 있다. development 클러스터에 접근하려면 인증서로 인증을 해야 하고,
|
||||
scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인증을 해야 한다.
|
||||
|
||||
`config-exercise`라는 디렉토리를 생성한다. `config-exercise` 디렉토리에
|
||||
다음 내용을 가진 `config-demo`라는 파일을 생성한다.
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
clusters:
|
||||
- cluster:
|
||||
name: development
|
||||
- cluster:
|
||||
name: scratch
|
||||
|
||||
users:
|
||||
- name: developer
|
||||
- name: experimenter
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
name: dev-frontend
|
||||
- context:
|
||||
name: dev-storage
|
||||
- context:
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
구성 파일은 클러스터들, 사용자들, 컨텍스트들을 기술한다. `config-demo` 파일은 두 클러스터들과
|
||||
두 사용자들, 세 컨텍스트들을 기술하기 위한 프레임워크를 가진다.
|
||||
|
||||
`config-exercise` 디렉토리로 이동한다. 그리고 다음 커맨드들을 실행하여 구성 파일에 클러스터의
|
||||
세부사항들을 추가한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
|
||||
kubectl config --kubeconfig=config-demo set-cluster scratch --server=https://5.6.7.8 --insecure-skip-tls-verify
|
||||
```
|
||||
|
||||
사용자의 세부사항들을 구성 파일에 추가한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
|
||||
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`kubectl config unset users.<name>`을 실행하여 사용자를 삭제할 수 있다.
|
||||
{{< /note >}}
|
||||
|
||||
컨텍스트 세부사항들을 구성 파일에 추가한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
|
||||
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
|
||||
```
|
||||
|
||||
`config-demo` 파일을 열어서 세부사항들이 추가되었는지 확인한다. `config-demo` 파일을 열어보는
|
||||
것 대신에 `config view` 커맨드를 사용할 수도 있다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view
|
||||
```
|
||||
|
||||
두 클러스터, 두 사용자, 세 컨텍스트들이 출력 결과로 나온다.
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
- cluster:
|
||||
insecure-skip-tls-verify: true
|
||||
server: https://5.6.7.8
|
||||
name: scratch
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
current-context: ""
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
- name: experimenter
|
||||
user:
|
||||
password: some-password
|
||||
username: exp
|
||||
```
|
||||
|
||||
위 `fake-ca-file`, `fake-cert-file`, `fake-key-file`은 인증서 파일들의 실제 경로를 위한
|
||||
플레이스홀더(placeholder)이다.
|
||||
당신의 환경에 맞게 이들을 실제 인증서 경로로 변경해줘야 한다.
|
||||
|
||||
만약 당신이 인증서 파일들의 경로 대신에 base64로 인코딩된 데이터를 여기에 사용하려고 한다면
|
||||
키에 `-data` 접미사를 추가해야 한다. 예를 들면 `certificate-authority-data`,
|
||||
`client-certificate-data`, `client-key-data` 같이 사용할 수 있다.
|
||||
|
||||
컨텍스트는 세 가지(클러스터, 사용자, 네임스페이스) 요소들로 이뤄진다. 예를 들어
|
||||
`dev-frontend` 컨텍스트는 `development` 클러스터의 `frontend` 네임스페이스에 접근하는데
|
||||
`developer` 사용자 자격증명을 사용하라고 알려준다.
|
||||
|
||||
현재 컨텍스트를 설정한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-frontend
|
||||
```
|
||||
|
||||
이제 당신이 `kubectl` 커맨드를 입력할 때마다 `dev-frontend` 컨텍스트에 명시된 클러스터와
|
||||
네임스페이스 상에서 동작하게 될 것이다. 그리고 커맨드는 `dev-frontend` 컨텍스트 내에 명시된
|
||||
사용자 자격증명을 사용할 것이다.
|
||||
|
||||
현재 컨텍스트에 관련된 구성 정보만을 보려면
|
||||
`--minify` 플래그를 사용한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
`dev-frontend` 컨텍스트에 관련된 구성 정보가 출력 결과로 표시될 것이다.
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority: fake-ca-file
|
||||
server: https://1.2.3.4
|
||||
name: development
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
current-context: dev-frontend
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: developer
|
||||
user:
|
||||
client-certificate: fake-cert-file
|
||||
client-key: fake-key-file
|
||||
```
|
||||
|
||||
이제 당신이 잠시 scratch 클러스터에서 작업하려고 한다고 가정해보자.
|
||||
|
||||
현재 컨텍스트를 `exp-scratch`로 변경한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context exp-scratch
|
||||
```
|
||||
|
||||
이제 당신이 실행하는 모든 `kubectl` 커맨드는 `scratch` 클러스터의
|
||||
default 네임스페이스에 적용되며 `exp-scratch` 컨텍스트에 나열된
|
||||
사용자의 자격증명을 사용할 것이다.
|
||||
|
||||
현재의 컨텍스트인 `exp-scratch`에 관련된 설정을 보자.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
마지막으로 당신이 `development` 클러스터의 `storage` 네임스페이스에서
|
||||
잠시 작업을 하려고 한다고 가정해보자.
|
||||
|
||||
현재 컨텍스트를 `dev-storage`로 변경한다.
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
```
|
||||
|
||||
현재 컨텍스트인 `dev-storage`에 관련된 설정을 보자.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
|
||||
## 두 번째 구성 파일 생성
|
||||
|
||||
`config-exercise` 디렉토리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다.
|
||||
|
||||
```shell
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
```
|
||||
|
||||
위 구성 파일은 `dev-ramp-up`이라는 신규 컨텍스트를 정의한다.
|
||||
|
||||
## KUBECONFIG 환경 변수 설정
|
||||
|
||||
`KUBECONFIG`라는 환경 변수를 가지고 있는지 확인해보자. 만약 가지고 있다면,
|
||||
이후에 복원할 수 있도록 `KUBECONFIG` 환경 변수의 현재 값을 저장한다.
|
||||
예:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
`KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는
|
||||
Linux와 Mac에서는 콜론으로 구분되며 Windows에서는 세미콜론으로 구분된다.
|
||||
`KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에
|
||||
익숙해지길 바란다.
|
||||
|
||||
다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자.<br>
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
`config-exercise` 디렉토리에서 다음 커맨드를 입력한다.
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
당신의 `KUBECONFIG` 환경 변수에 나열된 모든 파일들이 합쳐진 정보가 출력 결과로
|
||||
표시될 것이다. 특히, 합쳐진 정보가 `config-demo-2` 파일의 `dev-ramp-up`
|
||||
컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을
|
||||
가지고 있다는 것에 주목하길 바란다.
|
||||
|
||||
```shell
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: frontend
|
||||
user: developer
|
||||
name: dev-frontend
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: ramp
|
||||
user: developer
|
||||
name: dev-ramp-up
|
||||
- context:
|
||||
cluster: development
|
||||
namespace: storage
|
||||
user: developer
|
||||
name: dev-storage
|
||||
- context:
|
||||
cluster: scratch
|
||||
namespace: default
|
||||
user: experimenter
|
||||
name: exp-scratch
|
||||
```
|
||||
|
||||
kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는
|
||||
[kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)를 참조한다.
|
||||
|
||||
## $HOME/.kube 디렉토리 탐색
|
||||
|
||||
만약 당신이 이미 클러스터를 가지고 있고 `kubectl`을 사용하여
|
||||
해당 클러스터를 제어하고 있다면, 아마 `$HOME/.kube` 디렉토리에 `config`라는
|
||||
파일을 가지고 있을 것이다.
|
||||
|
||||
`$HOME/.kube`로 가서 어떤 파일들이 존재하는지 보자.
|
||||
보통 `config`라는 파일이 존재할 것이다. 해당 디렉토리 내에는 다른 구성 파일들도 있을 수 있다.
|
||||
간단하게 말하자면 당신은 이 파일들의 컨텐츠에 익숙해져야 한다.
|
||||
|
||||
## $HOME/.kube/config를 KUBECONFIG 환경 변수에 추가
|
||||
|
||||
당신이 `$HOME/.kube/config` 파일을 가지고 있는데 `KUBECONFIG`
|
||||
환경 변수에 나타나지 않는다면 `KUBECONFIG` 환경 변수에 추가해보자.
|
||||
예:
|
||||
|
||||
### Linux
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
### Windows Powershell
|
||||
```shell
|
||||
$Env:KUBECONFIG=($Env:KUBECONFIG;$HOME/.kube/config)
|
||||
```
|
||||
|
||||
이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자.
|
||||
config-exercise 디렉토리에서 다음 커맨드를 실행한다.
|
||||
|
||||
```shell
|
||||
kubectl config view
|
||||
```
|
||||
|
||||
## 정리
|
||||
|
||||
`KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:<br>
|
||||
Linux:
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
Windows PowerShell
|
||||
```shell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
* [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands/)
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
|
||||
@@ -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 밀리코어를 말한다).
|
||||
이에 대한 자세한 알고리즘은 [여기](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)를 참고하기 바란다.
|
||||
|
||||
```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` 컨테이너를 띄운 터미널에서, `<Ctrl> + C`로 부하 발생을 중단시킨다. 그런 다음 (몇 분 후에) 결과를 확인한다.
|
||||
|
||||
`busybox` 컨테이너를 띄운 터미널에서,
|
||||
`<Ctrl> + 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" >}}
|
||||
|
||||
|
||||
@@ -12,14 +12,14 @@ weight: 90
|
||||
{{% capture overview %}}
|
||||
|
||||
Horizontal Pod Autoscaler는 CPU 사용량
|
||||
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
|
||||
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
|
||||
컨트롤러, 디플로이먼트 또는 레플리카 셋의 파드 개수를 자동으로 스케일한다. Horizontal
|
||||
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬 셋)에는 적용되지 않는다.
|
||||
|
||||
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
|
||||
리소스는 컨트롤러의 동작을 결정한다.
|
||||
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
|
||||
컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션
|
||||
컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
|
||||
|
||||
{{% /capture %}}
|
||||
@@ -31,43 +31,43 @@ Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로
|
||||
|
||||
|
||||
|
||||
Horizontal Pod Autoscaler는 컨트롤러
|
||||
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
|
||||
Horizontal Pod Autoscaler는 컨트롤러
|
||||
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
|
||||
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
|
||||
|
||||
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
|
||||
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
|
||||
메트릭 API(파드 단위 리소스 메트릭 용)
|
||||
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
|
||||
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
|
||||
메트릭 API(파드 단위 리소스 메트릭 용)
|
||||
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
|
||||
|
||||
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
|
||||
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
|
||||
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
|
||||
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
|
||||
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
|
||||
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
|
||||
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
|
||||
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
|
||||
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
|
||||
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
|
||||
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
|
||||
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
|
||||
사용되는 비율을 생성한다.
|
||||
|
||||
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
|
||||
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
|
||||
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
|
||||
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
|
||||
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
|
||||
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
|
||||
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
|
||||
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
|
||||
섹션을 참조하기 바란다.
|
||||
|
||||
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
|
||||
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
|
||||
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
|
||||
|
||||
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
|
||||
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
|
||||
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
|
||||
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
|
||||
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
|
||||
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
|
||||
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
|
||||
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
|
||||
선택적으로 나눌 수 있다.
|
||||
|
||||
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
||||
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
|
||||
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
|
||||
[메트릭-서버](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)를
|
||||
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
||||
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
|
||||
시작해야 하는 메트릭-서버에 의해 제공된다. 가이드는
|
||||
[메트릭-서버](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)를
|
||||
참조한다. HorizontalPodAutoscaler는 힙스터(Heapster)에서 직접 메트릭을 가져올 수도 있다.
|
||||
|
||||
{{< note >}}
|
||||
@@ -79,194 +79,202 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
||||
|
||||
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
|
||||
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
|
||||
하위 리소스 스케일에 대한 자세한 내용은
|
||||
하위 리소스 스케일에 대한 자세한 내용은
|
||||
[여기](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 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
|
||||
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
|
||||
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
|
||||
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
|
||||
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
|
||||
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
|
||||
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
|
||||
이 값은 `--horizontal-pod-autoscaler-initial-readiness-delay` 플래그로 설정되며, 기본값은 30초
|
||||
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,
|
||||
준비를 위한 어떠한 전환이라도 이를 시작 시간으로 간주한다. 이
|
||||
값은 `--horizontal-pod-autoscaler-cpu-initialization-period` 플래그로 설정되며
|
||||
이다. 일단 파드가 준비되고 시작된 후 구성 가능한 시간 이내이면,
|
||||
준비를 위한 어떠한 전환이라도 이를 시작 시간으로 간주한다. 이
|
||||
값은 `--horizontal-pod-autoscaler-cpu-initialization-period` 플래그로 설정되며
|
||||
기본값은 5분이다.
|
||||
|
||||
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
|
||||
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
|
||||
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
|
||||
|
||||
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
|
||||
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
|
||||
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
|
||||
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
|
||||
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
|
||||
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
|
||||
스케일의 크기를 약화시킨다.
|
||||
|
||||
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
|
||||
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
|
||||
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
|
||||
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
|
||||
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
|
||||
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
|
||||
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
|
||||
|
||||
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
|
||||
비율을 다시 계산한다. 새 비율이 스케일 방향을
|
||||
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
|
||||
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
|
||||
비율을 다시 계산한다. 새 비율이 스케일 방향을
|
||||
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
|
||||
비율을 사용하여 스케일한다.
|
||||
|
||||
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
|
||||
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
|
||||
고려없이 HorizontalPodAutoscaler 상태를 통해 다시
|
||||
보고된다.
|
||||
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
|
||||
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
|
||||
고려없이 HorizontalPodAutoscaler 상태를 통해 다시
|
||||
보고된다.
|
||||
|
||||
HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
|
||||
각 메트릭에 대해 수행된 다음 원하는 레플리카 수 중 가장
|
||||
큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
|
||||
레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
|
||||
HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
|
||||
각 메트릭에 대해 수행된 다음 원하는 레플리카 수 중 가장
|
||||
큰 값이 선택된다. 이러한 메트릭 중 어떠한 것도 원하는
|
||||
레플리카 수로 변환할 수 없는 경우(예 : 메트릭 API에서 메트릭을
|
||||
가져오는 중 오류 발생) 스케일을 건너뛴다.
|
||||
|
||||
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
|
||||
구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
|
||||
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
|
||||
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다. 컨트롤러는
|
||||
구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
|
||||
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
|
||||
영향을 완만하게 한다.
|
||||
|
||||
## API 오브젝트
|
||||
|
||||
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
|
||||
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
|
||||
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
|
||||
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
|
||||
`autoscaling/v1` API 버전에서 찾을 수 있다.
|
||||
|
||||
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
|
||||
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
|
||||
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
|
||||
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
|
||||
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
|
||||
|
||||
API 오브젝트에 대한 자세한 내용은
|
||||
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`로 세부 사항을 확인할 수 있다.
|
||||
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 사이의 레플리카 개수로 설정된다.
|
||||
또한 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를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수ㄴ 없다. (예 : `kubectl rolling-update`)
|
||||
작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
|
||||
Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
|
||||
|
||||
## 쿨-다운 / 지연에 대한 지원
|
||||
|
||||
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
|
||||
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
|
||||
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
|
||||
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
|
||||
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
|
||||
|
||||
v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성
|
||||
v1.6부터 클러스터 운영자는 `kube-controller-manager` 구성
|
||||
요소의 플래그로 노출된 글로벌 HPA 설정을 조정하여 이 문제를 완화할 수 있다.
|
||||
|
||||
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
|
||||
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
|
||||
필요성을 제거하였다.
|
||||
|
||||
- `--horizontal-pod-autoscaler-downscale-delay` : 이 옵션 값은
|
||||
오토스케일러가 현재의 작업이 완료된 후에 다른 다운스케일 작업을
|
||||
수행하기까지 기다려야 하는 시간을 지정하는 지속 시간이다.
|
||||
- `--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에서는 이 메트릭을 사용할 수 없다. 그리고
|
||||
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
|
||||
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
|
||||
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
|
||||
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
|
||||
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
|
||||
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
|
||||
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
|
||||
|
||||
요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
|
||||
|
||||
## 메트릭 API를 위한 지원
|
||||
|
||||
기본적으로 HorizontalPodAutoscaler 컨트롤러는 일련의 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이다.
|
||||
* 리소스 메트릭의 경우, 일반적으로 이것은 [메트릭-서버](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)으로 확인한다.
|
||||
* 사용자 정의 메트릭의 경우, 이것은 `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이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
|
||||
|
||||
* `--horizontal-pod-autoscaler-use-rest-clients`는 `true`이거나 설정되지 않음. 이것을 false로 설정하면 더 이상 사용되지 않는 힙스터 기반 오토스케일링으로 전환된다.
|
||||
|
||||
이런 다양한 메트릭 경로와 각각의 다른 점에 대한 상세 내용은 관련 디자인 제안서인
|
||||
[HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||
[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)를 참조한다.
|
||||
|
||||
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)과
|
||||
[외부 메트릭스 사용하는 작업 과정](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)을 참조한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -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
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user