Fourth Korean L10n Work For Release 1.17 (#19127)
* translate assign-pod-node.md (#18955) * correct the misspelling (#19063) * Update to Outdated files in dev-1.17-ko.4 branch. (#19002) Co-Authored-By: KimMJ <a01083612486@gmail.com> Co-Authored-By: forybm <forybm1@naver.com> Co-Authored-By: Yuk, Yongsu <ysyukr@gmail.com> Co-authored-by: KimMJ <a01083612486@gmail.com> Co-authored-by: forybm <forybm1@naver.com> Co-authored-by: Yuk, Yongsu <ysyukr@gmail.com>
This commit is contained in:
June Yi
+23
-21
@@ -1,5 +1,4 @@
|
||||
---
|
||||
reviewers:
|
||||
title: 네트워크 폴리시로 실리움(Cilium) 사용하기
|
||||
content_template: templates/task
|
||||
weight: 20
|
||||
@@ -8,7 +7,7 @@ weight: 20
|
||||
{{% capture overview %}}
|
||||
이 페이지는 어떻게 네트워크 폴리시(NetworkPolicy)로 실리움(Cilium)를 사용하는지 살펴본다.
|
||||
|
||||
실리움의 배경에 대해서는 [실리움 소개](https://cilium.readthedocs.io/en/stable/intro)를 읽어보자.
|
||||
실리움의 배경에 대해서는 [실리움 소개](https://docs.cilium.io/en/stable/intro)를 읽어보자.
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture prerequisites %}}
|
||||
@@ -22,35 +21,44 @@ weight: 20
|
||||
|
||||
실리움에 쉽게 친숙해지기 위해
|
||||
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
|
||||
[실리움 쿠버네티스 시작하기 안내](https://cilium.readthedocs.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
|
||||
[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
|
||||
|
||||
Minikube를 시작하려면 최소 버전으로 >= v0.33.1 이 필요하고,
|
||||
Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
|
||||
다음의 실행 파라미터로 실행한다.
|
||||
|
||||
```shell
|
||||
minikube version
|
||||
```
|
||||
```
|
||||
minikube version: v0.33.1
|
||||
minikube version: v1.3.1
|
||||
```
|
||||
|
||||
```shell
|
||||
minikube start --network-plugin=cni --memory=4096
|
||||
```
|
||||
|
||||
Minikube에서 실리움의 데몬셋 구성과 Minikube에 배포된 etcd 인스턴스로 접속하는데 필요한 구성 뿐만 아니라
|
||||
RBAC 설정을 포함하는 필요한 구성을
|
||||
이 간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
BPF 파일시스템을 마운트한다
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.5/examples/kubernetes/1.14/cilium-minikube.yaml
|
||||
minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
|
||||
```
|
||||
|
||||
Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
|
||||
간단한 ``올인원`` YAML 파일로 배포할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.6/install/kubernetes/quick-install.yaml
|
||||
```
|
||||
```
|
||||
configmap/cilium-config created
|
||||
daemonset.apps/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
serviceaccount/cilium created
|
||||
serviceaccount/cilium-operator created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium created
|
||||
clusterrole.rbac.authorization.k8s.io/cilium-operator created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium created
|
||||
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
|
||||
daemonset.apps/cilium create
|
||||
deployment.apps/cilium-operator created
|
||||
```
|
||||
|
||||
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
|
||||
@@ -60,7 +68,7 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책 뿐만 아니라 L7(예,
|
||||
## 실리움을 실 서비스 용도로 배포하기
|
||||
|
||||
실리움을 실 서비스 용도의 배포에 관련한 자세한 방법은
|
||||
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)를 살펴본다.
|
||||
[실리움 쿠버네티스 설치 안내](https://docs.cilium.io/en/stable/kubernetes/intro/)를 살펴본다.
|
||||
이 문서는 자세한 요구사항, 방법과
|
||||
실제 데몬셋 예시를 포함한다.
|
||||
|
||||
@@ -84,14 +92,8 @@ cilium-6rxbd 1/1 Running 0 1m
|
||||
...
|
||||
```
|
||||
|
||||
알고 있어야 할 두 가지 주요 구성요소는 다음과 같다.
|
||||
|
||||
- 먼저는 `cilium` 파드가 클러스터의 각 노드에서 운영되고,
|
||||
노드의 파드로 보내고/받는 트래픽을 리눅스 BPF를 이용하여 네트워크 폴리시를 적용한다.
|
||||
- 실 서비스에 배포하는 경우 실리움은 키-값 저장소(예, etcd)를 활용해야 한다.
|
||||
[실리움 쿠버네티스 설치 안내](https://cilium.readthedocs.io/en/stable/kubernetes/intro/)에서
|
||||
키-값 저장소를 설치하는 방법과 실리움에서 이를 구성하는 필수 단계를
|
||||
제공할 것이다.
|
||||
`cilium` 파드는 클러스터 각 노드에서 실행되며, 리눅스 BPF를 사용해서
|
||||
해당 노드의 파드에 대한 트래픽 네트워크 폴리시를 적용한다.
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
|
||||
@@ -34,6 +34,16 @@ Horizontal Pod Autoscaler 같은 클러스터의 컨트롤러에서 결정을
|
||||
이 API를 사용하려면 메트릭 서버를 클러스터에 배포해야 한다. 그렇지 않으면 사용할 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
## 리소스 사용량 측정
|
||||
|
||||
### CPU
|
||||
|
||||
CPU는 일정 기간 동안 [CPU 코어](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)에서 평균 사용량으로 리포트된다. 이 값은 커널(리눅스와 윈도우 커널 모두)에서 제공하는 누적 CPU 카운터보다 높은 비율을 적용해서 얻는다. kubelet은 비율 계산에 사용할 윈도우를 선택한다.
|
||||
|
||||
### 메모리
|
||||
|
||||
메모리는 메트릭이 수집된 순간 작업 집합으로 리포트 된다. 이상적인 환경에서 "작업 집합(working set)"은 압박(memory pressure)에서 풀려날 수 없는 사용 중인(in-use) 메모리의 양이다. 그러나 작업 집합의 계산은 호스트 OS에 따라 다르며, 일반적으로 휴리스틱스를 사용해서 평가한다. 쿠버네티스는 스왑(swap)을 지원하지 않기 때문에 모든 익명(파일로 백업되지 않은) 메모리를 포함한다. 호스트 OS가 항상 이러한 페이지를 회수할 수 없기 때문에 메트릭에는 일반적으로 일부 캐시된(파일 백업) 메모리도 포함된다.
|
||||
|
||||
## 메트릭 서버
|
||||
|
||||
[메트릭 서버](https://github.com/kubernetes-incubator/metrics-server)는 클러스터 전역에서 리소스 사용량 데이터를 집계한다.
|
||||
|
||||
@@ -990,11 +990,11 @@ TODO(pwittrock): Why doesn't export remove the status field? Seems like it shou
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
```
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -135,11 +135,11 @@ kubectl create -f <url> --edit
|
||||
```yaml
|
||||
selector:
|
||||
matchLabels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
controller-selector: "extensions/v1beta1/deployment/nginx"
|
||||
controller-selector: "apps/v1/deployment/nginx"
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
@@ -79,7 +79,7 @@ service/php-apache created
|
||||
다음 명령어는 첫 번째 단계에서 만든 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 밀리코어까지 요청할 수 있고,
|
||||
(kubectl run으로 각 파드는 200 밀리코어까지 요청할 수 있고,
|
||||
따라서 여기서 말하는 평균 CPU 사용은 100 밀리코어를 말한다).
|
||||
이에 대한 자세한 알고리즘은 [여기](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)를 참고하기 바란다.
|
||||
|
||||
|
||||
@@ -41,28 +41,28 @@ Horizontal Pod Autoscaler는 컨트롤러
|
||||
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
|
||||
|
||||
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
|
||||
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
|
||||
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
|
||||
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
|
||||
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
|
||||
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
|
||||
사용되는 비율을 생성한다.
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 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는 대개 별도로
|
||||
@@ -158,11 +158,15 @@ HorizontalPodAutoscaler에 여러 메트릭이 지정된 경우, 이 계산은
|
||||
현재 값보다 높은 `desiredReplicas` 을 제공하는 경우
|
||||
HPA가 여전히 확장할 수 있음을 의미한다.
|
||||
|
||||
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이 기록된다.
|
||||
컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장 사항을 선택하도록 해당 창 내의
|
||||
모든 권장 사항을 고려한다. 이 값은 `--horizontal-pod-autoscaler-downscale-stabilization` 플래그를 사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는
|
||||
메트릭 값의 영향을 완만하게 한다.
|
||||
마지막으로, HPA가 목표를 스케일하기 직전에 스케일 권장 사항이
|
||||
기록된다. 컨트롤러는 구성 가능한 창(window) 내에서 가장 높은 권장
|
||||
사항을 선택하도록 해당 창 내의 모든 권장 사항을 고려한다. 이 값은
|
||||
`--horizontal-pod-autoscaler-downscale-stabilization` 플래그 또는 HPA 오브젝트
|
||||
동작 `behavior.scaleDown.stabilizationWindowSeconds` ([구성가능한
|
||||
스케일링 동작 지원](#구성가능한-스케일링-동작-지원)을 본다)을
|
||||
사용하여 설정할 수 있고, 기본 값은 5분이다.
|
||||
즉, 스케일 다운이 점진적으로 발생하여 급격히 변동하는 메트릭 값의
|
||||
영향을 완만하게 한다.
|
||||
|
||||
## API 오브젝트
|
||||
|
||||
@@ -228,6 +232,11 @@ v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대
|
||||
있다.
|
||||
{{< /note >}}
|
||||
|
||||
v1.17 부터 v2beta2 API 필드에서 `behavior.scaleDown.stabilizationWindowSeconds`
|
||||
를 설정하여 다운스케일 안정화 창을 HPA별로 설정할 수 있다.
|
||||
[구성가능한 스케일링
|
||||
동작 지원](#구성가능한-스케일링-동작-지원)을 본다.
|
||||
|
||||
## 멀티 메트릭을 위한 지원
|
||||
|
||||
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
|
||||
@@ -278,6 +287,154 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
||||
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/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)을 참조한다.
|
||||
|
||||
## 구성가능한 스케일링 동작 지원
|
||||
|
||||
[v1.17](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
|
||||
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
|
||||
스케일링 동작을 구성할 수 있다.
|
||||
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
|
||||
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
|
||||
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
|
||||
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
|
||||
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
|
||||
|
||||
### 스케일링 정책
|
||||
|
||||
스펙의 `behavior` 섹션에 하나 이상의 스케일링 폴리시를 지정할 수 있다.
|
||||
폴리시가 여러 개 지정된 경우 가장 많은 양의 변경을
|
||||
허용하는 정책이 기본적으로 선택된 폴리시이다. 다음 예시는 스케일 다운 중 이
|
||||
동작을 보여준다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
policies:
|
||||
- type: Pods
|
||||
value: 4
|
||||
periodSeconds: 60
|
||||
- type: Percent
|
||||
value: 10
|
||||
periodSeconds: 60
|
||||
```
|
||||
|
||||
파드 수가 40개를 초과하면 두 번째 폴리시가 스케일링 다운에 사용된다.
|
||||
예를 들어 80개의 레플리카가 있고 대상을 10개의 레플리카로 축소해야 하는
|
||||
경우 첫 번째 단계에서 8개의 레플리카가 스케일 다운 된다. 레플리카의 수가 72개일 때
|
||||
다음 반복에서 파드의 10%는 7.2 이지만, 숫자는 8로 올림된다. 오토스케일러 컨트롤러의
|
||||
각 루프에서 변경될 파드의 수는 현재 레플리카의 수에 따라 재계산된다. 레플리카의 수가 40
|
||||
미만으로 떨어지면 첫 번째 폴리시 _(파드들)_ 가 적용되고 한번에
|
||||
4개의 레플리카가 줄어든다.
|
||||
|
||||
`periodSeconds` 는 폴리시가 참(true)으로 유지되어야 하는 기간을 나타낸다.
|
||||
첫 번째 정책은 1분 내에 최대 4개의 레플리카를 스케일 다운할 수 있도록 허용한다.
|
||||
두 번째 정책은 현재 레플리카의 최대 10%를 1분 내에 스케일 다운할 수 있도록 허용한다.
|
||||
|
||||
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
|
||||
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
|
||||
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
|
||||
비활성화 된다.
|
||||
|
||||
### 안정화 윈도우
|
||||
|
||||
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
|
||||
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
|
||||
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어있다.
|
||||
|
||||
```yaml
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 300
|
||||
```
|
||||
|
||||
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
|
||||
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
|
||||
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
|
||||
|
||||
### 기본 동작
|
||||
|
||||
사용자 지정 스케일링을 사용하려면 일부 필드를 지정해야 한다. 사용자 정의해야
|
||||
하는 값만 지정할 수 있다. 이러한 사용자 지정 값은 기본값과 병합된다. 기본값은 HPA
|
||||
알고리즘의 기존 동작과 일치한다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 300
|
||||
policies:
|
||||
- type: Percent
|
||||
value: 100
|
||||
periodSeconds: 15
|
||||
scaleUp:
|
||||
stabilizationWindowSeconds: 0
|
||||
policies:
|
||||
- type: Percent
|
||||
value: 100
|
||||
periodSeconds: 15
|
||||
- type: Pods
|
||||
value: 4
|
||||
periodSeconds: 15
|
||||
selectPolicy: Max
|
||||
```
|
||||
안정화 윈도우의 스케일링 다운의 경우 _300_ 초(또는 제공된
|
||||
경우`--horizontal-pod-autoscaler-downscale-stabilization` 플래그의 값)이다. 스케일링 다운에서는 현재
|
||||
실행 중인 레플리카의 100%를 제거할 수 있는 단일 정책만 있으며, 이는 스케일링
|
||||
대상을 최소 허용 레플리카로 축소할 수 있음을 의미한다.
|
||||
스케일링 업에는 안정화 윈도우가 없다. 메트릭이 대상을 스케일 업해야 한다고 표시된다면 대상이 즉시 스케일 업된다.
|
||||
두 가지 폴리시가 있다. HPA가 정상 상태에 도달 할 때까지 15초 마다
|
||||
4개의 파드 또는 현재 실행 중인 레플리카의 100% 가 추가된다.
|
||||
|
||||
### 예시: 다운스케일 안정화 윈도우 변경
|
||||
|
||||
사용자 지정 다운스케일 안정화 윈도우를 1분 동안 제공하기 위해
|
||||
다음 동작이 HPA에 추가된다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 60
|
||||
```
|
||||
|
||||
### 예시: 스케일 다운 비율 제한
|
||||
|
||||
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
|
||||
다음 동작이 HPA에 추가된다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
policies:
|
||||
- type: Percent
|
||||
value: 10
|
||||
periodSeconds: 60
|
||||
```
|
||||
|
||||
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
|
||||
전략을 추가할 수 있다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
policies:
|
||||
- type: Percent
|
||||
value: 10
|
||||
periodSeconds: 60
|
||||
- type: Pods
|
||||
value: 5
|
||||
periodSeconds: 60
|
||||
selectPolicy: Max
|
||||
```
|
||||
|
||||
### 예시: 스케일 다운 비활성화
|
||||
|
||||
`selectPolicy` 의 `Disabled` 값은 주어진 방향으로의 스케일링을 끈다.
|
||||
따라서 다운 스케일링을 방지하기 위해 다음 폴리시가 사용된다.
|
||||
|
||||
```yaml
|
||||
behavior:
|
||||
scaleDown:
|
||||
selectPolicy: Disabled
|
||||
```
|
||||
|
||||
{{% /capture %}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
Reference in New Issue
Block a user