Merge pull request #31188 from jihoon-seo/220104_Update_outdated_M83
[ko] Update outdated files in `dev-1.23-ko.1` (M83-M93)pull/31418/head
Kubernetes Prow Robot
GitHub
commit
fa2b224ccc
|
|
@ -1,38 +0,0 @@
|
|||
---
|
||||
title: 토폴로지 인지 힌트 활성화하기
|
||||
content_type: task
|
||||
min-kubernetes-server-version: 1.21
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
|
||||
|
||||
_토폴로지 인지 힌트_ 는 {{< glossary_tooltip text="엔드포인트슬라이스(EndpointSlices)" term_id="endpoint-slice" >}}에 포함되어 있는
|
||||
토폴로지 정보를 이용해 토폴로지 인지 라우팅을 가능하게 한다.
|
||||
이 방법은 트래픽을 해당 트래픽이 시작된 곳과 최대한 근접하도록 라우팅하는데,
|
||||
이를 통해 비용을 줄이거나 네트워크 성능을 향상시킬 수 있다.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
토폴로지 인지 힌트를 활성화하기 위해서는 다음의 필수 구성 요소가 필요하다.
|
||||
|
||||
* {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가
|
||||
iptables 모드 혹은 IPVS 모드로 동작하도록 설정
|
||||
* 엔드포인트슬라이스가 비활성화되지 않았는지 확인
|
||||
|
||||
## 토폴로지 인지 힌트 활성화하기
|
||||
|
||||
서비스 토폴로지 힌트를 활성화하기 위해서는 kube-apiserver, kube-controller-manager, kube-proxy에 대해
|
||||
`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화한다.
|
||||
|
||||
```
|
||||
--feature-gates="TopologyAwareHints=true"
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* 서비스 항목 아래의 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints)를 참고
|
||||
* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 참고
|
||||
|
|
@ -1,224 +0,0 @@
|
|||
---
|
||||
|
||||
|
||||
title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기
|
||||
content_type: task
|
||||
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.5" state="alpha" >}}
|
||||
|
||||
구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 컨트롤 플레인 노드를 복제할 수 있다. 하지만 이러한 스크립트들은 프로덕션 용도로 사용하기에 적합하지 않으며, 프로젝트의 CI에서만 주로 사용된다.
|
||||
이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 컨트롤 플레인을 관리하는 방법과 GCE와 함께 사용하기 위해 HA 컨트롤 플레인을 구현하는 방법에 관해 설명한다.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## HA 호환 클러스터 시작
|
||||
|
||||
새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다.
|
||||
|
||||
* `MULTIZONE=true` - 서버의 기본 영역(zone)과 다른 영역에서 컨트롤 플레인 kubelet이 제거되지 않도록 한다.
|
||||
여러 영역에서 컨트롤 플레인 노드를 실행(권장됨)하려는 경우에 필요하다.
|
||||
|
||||
* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다.
|
||||
true인 경우, Etcd의 리더 복제본에서 읽는다.
|
||||
이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다.
|
||||
|
||||
선택적으로, 첫 번째 컨트롤 플레인 노드가 생성될 GCE 영역을 지정할 수 있다.
|
||||
다음 플래그를 설정한다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 첫 번째 컨트롤 플레인 노드가 실행될 영역.
|
||||
|
||||
다음 샘플 커맨드는 europe-west1-b GCE 영역에 HA 호환 클러스터를 구성한다.
|
||||
|
||||
```shell
|
||||
MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
위의 커맨드는 하나의 컨트롤 플레인 노드를 포함하는 클러스터를 생성한다.
|
||||
그러나 후속 커맨드로 새 컨트롤 플레인 노드를 추가할 수 있다.
|
||||
|
||||
## 새 컨트롤 플레인 노드 추가
|
||||
|
||||
HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드를 추가할 수 있다.
|
||||
`kube-up` 스크립트에 다음 플래그를 사용하여 컨트롤 플레인 노드를 추가한다.
|
||||
|
||||
* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 컨트롤 플레인 노드의 복제본을
|
||||
만든다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 실행될 영역.
|
||||
반드시 다른 컨트롤 플레인 노드가 존재하는 영역과 동일한 지역(region)에 있어야 한다.
|
||||
|
||||
HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로
|
||||
설정할 필요는 없다.
|
||||
|
||||
다음 샘플 커맨드는 기존 HA 호환 클러스터에서
|
||||
컨트롤 플레인 노드를 복제한다.
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## 컨트롤 플레인 노드 제거
|
||||
|
||||
다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 컨트롤 플레인 노드를 제거할 수 있다.
|
||||
|
||||
* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다.
|
||||
|
||||
* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 제거될 영역.
|
||||
|
||||
* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 컨트롤 플레인 노드의 이름.
|
||||
명시하지 않으면, 해당 영역의 모든 복제본이 제거된다.
|
||||
|
||||
다음 샘플 커맨드는 기존 HA 클러스터에서 컨트롤 플레인 노드를 제거한다.
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
## 동작에 실패한 컨트롤 플레인 노드 처리
|
||||
|
||||
HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면,
|
||||
클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인
|
||||
노드를 추가하는 것이 가장 좋다.
|
||||
다음 샘플 커맨드로 이 과정을 시연한다.
|
||||
|
||||
1. 손상된 복제본을 제거한다.
|
||||
|
||||
```shell
|
||||
KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh
|
||||
```
|
||||
|
||||
<ol start="2"><li>기존 복제본을 대신할 새 노드를 추가한다.</li></ol>
|
||||
|
||||
```shell
|
||||
KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh
|
||||
```
|
||||
|
||||
## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례
|
||||
|
||||
* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안,
|
||||
해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다.
|
||||
영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다
|
||||
(더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다).
|
||||
|
||||
* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된
|
||||
컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다.
|
||||
결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도
|
||||
클러스터의 심각한 장애 상태를 초래한다.
|
||||
따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은
|
||||
단일 노드로 구성된 컨트롤 플레인보다도 못하다.
|
||||
|
||||
* 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다.
|
||||
클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다.
|
||||
이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로
|
||||
Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다.
|
||||
(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다)
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## 구현 지침
|
||||
|
||||
|
||||
|
||||
### 개요
|
||||
위의 그림은 3개의 컨트롤 플레인 노드와 컴포넌트를 고가용 클러스터로 구성한 형상을 보여준다. 해당 컨트롤 플레인 노드의 컴포넌트들은 다음의 방법을 차용하고 있다.
|
||||
|
||||
- etcd: 인스턴스는 합의(consensus)를 통해서 클러스터링되어 있다.
|
||||
|
||||
- 컨트롤러들, 스케줄러, 클러스터 오토-스케일러: 리스(lease) 메커니즘을 통해 클러스터에서 각각 단 하나의 인스턴스만 활성화될 것이다.
|
||||
|
||||
- 애드-온(add-on) 메니저: 애드-온들이 동기화를 유지하도록 각각 독립적으로 동작한다.
|
||||
|
||||
추가적으로, API 서버들 앞에서 동작하는 로드 밸런서는 내부와 외부 트래픽을 컨트롤 플레인 노드들로 연결(route)한다.
|
||||
각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다.
|
||||
|
||||
* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다.
|
||||
|
||||
* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다.
|
||||
|
||||
* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다.
|
||||
|
||||
* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다.
|
||||
|
||||
또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다.
|
||||
|
||||
### 로드 밸런싱
|
||||
|
||||
두 번째 컨트롤 플레인 노드를 배치할 때, 두 개의 복제본에 대한 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다.
|
||||
비슷하게 끝에서 두 번째의 컨트롤 플레인 노드를 제거한 후에는 로드 밸런서가 제거되고
|
||||
해당 IP 주소는 마지막으로 남은 복제본에 할당된다.
|
||||
로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다.
|
||||
|
||||
### 컨트롤 플레인 서비스와 Kubelet
|
||||
|
||||
쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신,
|
||||
시스템은 모든 트래픽을 외부 IP 주소로 보낸다.
|
||||
|
||||
* 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다.
|
||||
|
||||
* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다.
|
||||
|
||||
마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다.
|
||||
|
||||
### 컨트롤 플레인 노드 인증서
|
||||
|
||||
쿠버네티스는 각 컨트롤 플레인 노드의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 TLS 인증서를 발급한다.
|
||||
컨트롤 플레인 노드의 임시 퍼블릭 IP 주소에 대한 인증서는 없다.
|
||||
임시 퍼블릭 IP 주소를 통해 컨트롤 플레인 노드에 접근하려면, TLS 검증을 건너뛰어야 한다.
|
||||
|
||||
### etcd 클러스터화
|
||||
|
||||
etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용).
|
||||
이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다.
|
||||
|
||||
### API 서버 신원
|
||||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.20" >}}
|
||||
|
||||
API 서버 식별 기능은
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에
|
||||
의해 제어되며 기본적으로 활성화되지 않는다.
|
||||
{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}}
|
||||
시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다.
|
||||
|
||||
```shell
|
||||
kube-apiserver \
|
||||
--feature-gates=APIServerIdentity=true \
|
||||
# …다른 플래그는 평소와 같다.
|
||||
```
|
||||
|
||||
부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는
|
||||
`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는
|
||||
_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에
|
||||
[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다.
|
||||
임대 이름은 kube-apiserver의 고유 ID이다. 임대에는
|
||||
`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는
|
||||
`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각
|
||||
kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다
|
||||
모든 kube-apiserver 식별 ID 임대를 확인하고,
|
||||
`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다.
|
||||
`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는
|
||||
kube-apiserver 플래그 `identity-lease-renew-interval-seconds`
|
||||
및 `identity-lease-duration-seconds`로 구성된다.
|
||||
|
||||
이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을
|
||||
사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트).
|
||||
|
||||
## 추가 자료
|
||||
|
||||
[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md)
|
||||
|
|
@ -3,41 +3,59 @@
|
|||
|
||||
|
||||
|
||||
title: Horizontal Pod Autoscaler
|
||||
title: Horizontal Pod Autoscaling
|
||||
feature:
|
||||
title: Horizontal 스케일링
|
||||
description: >
|
||||
간단한 명령어나 UI를 통해서 또는 CPU 사용량에 따라 자동으로 애플리케이션의 스케일을 업 또는 다운한다.
|
||||
|
||||
content_type: concept
|
||||
weight: 90
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Horizontal Pod Autoscaler는 CPU 사용량
|
||||
(또는 [사용자 정의 메트릭](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md),
|
||||
아니면 다른 애플리케이션 지원 메트릭)을 관찰하여 레플리케이션
|
||||
컨트롤러(ReplicationController), 디플로이먼트(Deployment), 레플리카셋(ReplicaSet) 또는 스테이트풀셋(StatefulSet)의 파드 개수를 자동으로 스케일한다. Horizontal
|
||||
Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(DaemonSet))에는 적용되지 않는다.
|
||||
쿠버네티스에서, _HorizontalPodAutoscaler_ 는 워크로드 리소스(예:
|
||||
{{< glossary_tooltip text="디플로이먼트" term_id="deployment" >}} 또는
|
||||
{{< glossary_tooltip text="스테이트풀셋" term_id="statefulset" >}})를 자동으로 업데이트하며,
|
||||
워크로드의 크기를 수요에 맞게 자동으로 스케일링하는 것을 목표로 한다.
|
||||
|
||||
Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다.
|
||||
리소스는 컨트롤러의 동작을 결정한다.
|
||||
컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다.
|
||||
수평 스케일링은 부하 증가에 대해
|
||||
{{< glossary_tooltip text="파드" term_id="pod" >}}를 더 배치하는 것을 뜻한다.
|
||||
이는 _수직_ 스케일링(쿠버네티스에서는,
|
||||
해당 워크로드를 위해 이미 실행 중인 파드에
|
||||
더 많은 자원(예: 메모리 또는 CPU)를 할당하는 것)과는 다르다.
|
||||
|
||||
부하량이 줄어들고, 파드의 수가 최소 설정값 이상인 경우,
|
||||
HorizontalPodAutoscaler는 워크로드 리소스(디플로이먼트, 스테이트풀셋,
|
||||
또는 다른 비슷한 리소스)에게 스케일 다운을 지시한다.
|
||||
|
||||
Horizontal Pod Autoscaling은 크기 조절이 불가능한 오브젝트(예:
|
||||
{{< glossary_tooltip text="데몬셋" term_id="daemonset" >}})에는 적용할 수 없다.
|
||||
|
||||
HorizontalPodAutoscaler는 쿠버네티스 API 자원 및
|
||||
{{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 형태로 구현되어 있다.
|
||||
HorizontalPodAutoscaler API 자원은 컨트롤러의 행동을 결정한다.
|
||||
쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}
|
||||
내에서 실행되는 HPA 컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률,
|
||||
또는 다른 커스텀 메트릭 등의 관측된 메트릭을 목표에 맞추기 위해
|
||||
목표물(예: 디플로이먼트)의 적정 크기를 주기적으로 조정한다.
|
||||
|
||||
Horizontal Pod Autoscaling을 활용하는
|
||||
[연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)가 존재한다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Horizontal Pod Autoscaler는 어떻게 작동하는가?
|
||||
## HorizontalPodAutoscaler는 어떻게 작동하는가?
|
||||
|
||||
|
||||
{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler는 디플로이먼트 및 디플로이먼트의 레플리카셋의 크기를 조정한다" class="diagram-medium">}}
|
||||
|
||||
Horizontal Pod Autoscaler는 컨트롤러
|
||||
관리자의 `--horizontal-pod-autoscaler-sync-period` 플래그(기본값은
|
||||
15초)에 의해 제어되는 주기를 가진 컨트롤 루프로 구현된다.
|
||||
쿠버네티스는 Horizontal Pod Autoscaling을
|
||||
간헐적으로(intermittently) 실행되는
|
||||
컨트롤 루프 형태로 구현했다(지숙적인 프로세스가 아니다).
|
||||
실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의
|
||||
`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다).
|
||||
|
||||
각 주기 동안 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
|
||||
각 주기마다, 컨트롤러 관리자는 각 HorizontalPodAutoscaler 정의에
|
||||
지정된 메트릭에 대해 리소스 사용률을 질의한다. 컨트롤러 관리자는 리소스
|
||||
메트릭 API(파드 단위 리소스 메트릭 용)
|
||||
또는 사용자 지정 메트릭 API(다른 모든 메트릭 용)에서 메트릭을 가져온다.
|
||||
|
|
@ -45,7 +63,8 @@ Horizontal Pod Autoscaler는 컨트롤러
|
|||
* 파드 단위 리소스 메트릭(예 : CPU)의 경우 컨트롤러는 HorizontalPodAutoscaler가
|
||||
대상으로하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다.
|
||||
그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의
|
||||
컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을
|
||||
컨테이너에 대한 동등한 [자원 요청](/ko/docs/concepts/configuration/manage-resources-containers/#요청-및-제한)을
|
||||
퍼센트 단위로 하여 사용률 값을
|
||||
계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다.
|
||||
그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된
|
||||
대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데
|
||||
|
|
@ -54,32 +73,36 @@ Horizontal Pod Autoscaler는 컨트롤러
|
|||
파드의 컨테이너 중 일부에 적절한 리소스 요청이 설정되지 않은 경우,
|
||||
파드의 CPU 사용률은 정의되지 않으며, 따라서 오토스케일러는
|
||||
해당 메트릭에 대해 아무런 조치도 취하지 않는다. 오토스케일링
|
||||
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보)
|
||||
섹션을 참조하기 바란다.
|
||||
알고리즘의 작동 방식에 대한 자세한 내용은 아래 [알고리즘 세부 정보](#알고리즘-세부-정보) 섹션을 참조하기 바란다.
|
||||
|
||||
* 파드 단위 사용자 정의 메트릭의 경우, 컨트롤러는 사용률 값이 아닌 원시 값을 사용한다는 점을
|
||||
제외하고는 파드 단위 리소스 메트릭과 유사하게 작동한다.
|
||||
|
||||
* 오브젝트 메트릭 및 외부 메트릭의 경우, 문제의 오브젝트를 표현하는
|
||||
단일 메트릭을 가져온다. 이 메트릭은 목표 값과
|
||||
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2beta2` API
|
||||
비교되어 위와 같은 비율을 생성한다. `autoscaling/v2` API
|
||||
버전에서는, 비교가 이루어지기 전에 해당 값을 파드의 개수로
|
||||
선택적으로 나눌 수 있다.
|
||||
|
||||
HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
||||
`custom.metrics.k8s.io`, `external.metrics.k8s.io`)에서 메트릭을 가져온다. `metrics.k8s.io` API는 대개 별도로
|
||||
시작해야 하는 메트릭-서버에 의해 제공된다. 더 자세한 정보는 [메트릭-서버](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참조한다.
|
||||
HorizontalPodAutoscaler를 사용하는 일반적인 방법은
|
||||
{{< glossary_tooltip text="집약된 API" term_id="aggregation-layer" >}}(`metrics.k8s.io`,
|
||||
`custom.metrics.k8s.io`, 또는 `external.metrics.k8s.io`)로부터 메트릭을 가져오도록 설정하는 것이다.
|
||||
`metrics.k8s.io` API는 보통 메트릭 서버(Metrics Server)라는 애드온에 의해 제공되며,
|
||||
Metrics Server는 별도로 실행해야 한다. 자원 메트릭에 대한 추가 정보는
|
||||
[Metrics Server](/ko/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#메트릭-서버)를 참고한다.
|
||||
|
||||
자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다.
|
||||
[메트릭 API를 위한 지원](#메트릭-api를-위한-지원)에서 위의 API들에 대한 안정성 보장 및 지원 상태를
|
||||
확인할 수 있다.
|
||||
|
||||
오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다.
|
||||
스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
|
||||
하위 리소스 스케일에 대한 자세한 내용은
|
||||
[여기](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource)에서 확인할 수 있다.
|
||||
HorizontalPodAutoscaler 컨트롤러는 스케일링을 지원하는 상응하는
|
||||
워크로드 리소스(예: 디플로이먼트 및 스테이트풀셋)에 접근한다.
|
||||
이들 리소스 각각은 `scale`이라는 하위 리소스를 갖고 있으며,
|
||||
이 하위 리소스는 레플리카의 수를 동적으로 설정하고 각각의 현재 상태를 확인할 수 있도록 하는 인터페이스이다.
|
||||
쿠버네티스 API의 하위 리소스에 대한 일반적인 정보는 [쿠버네티스 API 개념](/docs/reference/using-api/api-concepts/)에서 확인할 수 있다.
|
||||
|
||||
### 알고리즘 세부 정보
|
||||
|
||||
가장 기본적인 관점에서, Horizontal Pod Autoscaler 컨트롤러는
|
||||
가장 기본적인 관점에서, HorizontalPodAutoscaler 컨트롤러는
|
||||
원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로
|
||||
작동한다.
|
||||
|
||||
|
|
@ -90,28 +113,30 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`,
|
|||
예를 들어 현재 메트릭 값이 `200m`이고 원하는 값이
|
||||
`100m`인 경우 `200.0 / 100.0 == 2.0`이므로 복제본 수가 두 배가
|
||||
된다. 만약 현재 값이 `50m` 이면, `50.0 / 100.0 == 0.5` 이므로
|
||||
복제본 수를 반으로 줄일 것이다. 비율이 1.0(0.1을 기본값으로 사용하는
|
||||
복제본 수를 반으로 줄일 것이다. 컨트롤 플레인은 비율이 1.0(기본값이 0.1인
|
||||
`-horizontal-pod-autoscaler-tolerance` 플래그를 사용하여
|
||||
전역적으로 구성 가능한 허용 오차 내)에 충분히 가깝다면 스케일링을 건너 뛸 것이다.
|
||||
|
||||
`targetAverageValue` 또는 `targetAverageUtilization`가 지정되면,
|
||||
`currentMetricValue`는 HorizontalPodAutoscaler의 스케일 목표
|
||||
안에 있는 모든 파드에서 주어진 메트릭의 평균을 취하여 계산된다.
|
||||
허용치를 확인하고 최종 값을 결정하기 전에, 파드
|
||||
준비 상태와 누락된 메트릭을 고려한다.
|
||||
|
||||
삭제 타임 스탬프가 설정된 모든 파드(즉, 종료
|
||||
중인 파드) 및 실패한 파드는 모두 폐기된다.
|
||||
허용치를 확인하고 최종 값을 결정하기 전에,
|
||||
컨트롤 플레인은 누락된 메트릭이 있는지,
|
||||
그리고 몇 개의 파드가 [`Ready`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-조건)인지도 고려한다.
|
||||
삭제 타임스탬프가 설정된 모든 파드(파드에 삭제 타임스탬프가 있으면
|
||||
셧다운/삭제 중임을 뜻한다)는 무시되며, 모든 실패한 파드는
|
||||
버려진다.
|
||||
|
||||
특정 파드에 메트릭이 누락된 경우, 나중을 위해 처리를 미뤄두는데, 이와
|
||||
같이 누락된 메트릭이 있는 모든 파드는 최종 스케일 량을 조정하는데 사용된다.
|
||||
|
||||
CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (즉, 여전히
|
||||
초기화 중인 경우) * 또는 * 파드의 최신 메트릭 포인트가 준비되기
|
||||
CPU를 스케일할 때, 파드가 아직 Ready되지 않았거나(여전히
|
||||
초기화중이거나, unhealthy하여서) *또는* 파드의 최신 메트릭 포인트가 준비되기
|
||||
전이라면, 마찬가지로 해당 파드는 나중에 처리된다.
|
||||
|
||||
기술적 제약으로 인해, HorizontalPodAutoscaler 컨트롤러는
|
||||
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
|
||||
특정 CPU 메트릭을 나중에 사용할지 말지 결정할 때, 파드가 준비되는
|
||||
시작 시간을 정확하게 알 수 없다. 대신, 파드가 아직 준비되지
|
||||
않았고 시작 이후 짧은 시간 내에 파드가 준비되지 않은 상태로
|
||||
전환된다면, 해당 파드를 "아직 준비되지 않음(not yet ready)"으로 간주한다.
|
||||
|
|
@ -124,20 +149,21 @@ CPU를 스케일할 때, 어떤 파드라도 아직 준비가 안되었거나 (
|
|||
`현재 메트릭 값 / 원하는 메트릭 값` 기본 스케일 비율은 나중에
|
||||
사용하기로 되어 있거나 위에서 폐기되지 않은 남아있는 파드를 사용하여 계산된다.
|
||||
|
||||
누락된 메트릭이 있는 경우, 파드가 스케일 다운의 경우
|
||||
누락된 메트릭이 있는 경우, 컨트롤 플레인은 파드가 스케일 다운의 경우
|
||||
원하는 값의 100%를 소비하고 스케일 업의 경우 0%를 소비한다고
|
||||
가정하여 평균을 보다 보수적으로 재계산한다. 이것은 잠재적인
|
||||
스케일의 크기를 약화시킨다.
|
||||
|
||||
또한 아직-준비되지-않은 파드가 있는 경우 누락된 메트릭이나
|
||||
아직-준비되지-않은 파드를 고려하지 않고 스케일 업했을 경우,
|
||||
아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
|
||||
또한, 아직-준비되지-않은 파드가 있고, 누락된 메트릭이나
|
||||
아직-준비되지-않은 파드가 고려되지 않고 워크로드가 스케일업 된 경우,
|
||||
컨트롤러는 아직-준비되지-않은 파드가 원하는 메트릭의 0%를 소비한다고
|
||||
보수적으로 가정하고 스케일 확장의 크기를 약화시킨다.
|
||||
|
||||
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에 사용
|
||||
비율을 다시 계산한다. 새 비율이 스케일 방향을
|
||||
바꾸거나, 허용 오차 내에 있으면 스케일링을 건너뛴다. 그렇지 않으면, 새
|
||||
비율을 사용하여 스케일한다.
|
||||
아직-준비되지-않은 파드나 누락된 메트릭을 고려한 후에,
|
||||
컨트롤러가 사용률을 다시 계산한다.
|
||||
새로 계산한 사용률이 스케일 방향을 바꾸거나, 허용 오차 내에 있으면,
|
||||
컨트롤러가 스케일링을 건너뛴다.
|
||||
그렇지 않으면, 새로 계산한 사용률를 이용하여 파드 수 변경 결정을 내린다.
|
||||
|
||||
평균 사용량에 대한 *원래* 값은 새로운 사용 비율이 사용되는
|
||||
경우에도 아직-준비되지-않은 파드 또는 누락된 메트릭에 대한
|
||||
|
|
@ -161,32 +187,25 @@ HPA가 여전히 확장할 수 있음을 의미한다.
|
|||
|
||||
## API 오브젝트
|
||||
|
||||
Horizontal Pod Autoscaler는 쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
|
||||
CPU에 대한 오토스케일링 지원만 포함하는 안정된 버전은
|
||||
`autoscaling/v1` API 버전에서 찾을 수 있다.
|
||||
|
||||
메모리 및 사용자 정의 메트릭에 대한 스케일링 지원을 포함하는 베타 버전은
|
||||
`autoscaling/v2beta2`에서 확인할 수 있다. `autoscaling/v2beta2`에서 소개된
|
||||
새로운 필드는 `autoscaling/v1`로 작업할 때 어노테이션으로 보존된다.
|
||||
Horizontal Pod Autoscaler는
|
||||
쿠버네티스 `autoscaling` API 그룹의 API 리소스이다.
|
||||
현재의 안정 버전은 `autoscaling/v2` API 버전이며,
|
||||
메모리와 커스텀 메트릭에 대한 스케일링을 지원한다.
|
||||
`autoscaling/v2`에서 추가된 새로운 필드는 `autoscaling/v1`를 이용할 때에는
|
||||
어노테이션으로 보존된다.
|
||||
|
||||
HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)인지 확인해야 한다.
|
||||
API 오브젝트에 대한 자세한 내용은
|
||||
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
|
||||
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)에서 찾을 수 있다.
|
||||
|
||||
## 워크로드 스케일링의 안정성 {#flapping}
|
||||
|
||||
## kubectl에서 Horizontal Pod Autoscaler 지원
|
||||
HorizontalPodAutoscaler를 사용하여 레플리카 그룹의 크기를 관리할 때,
|
||||
측정하는 메트릭의 동적 특성 때문에 레플리카 수가 계속 자주 요동칠 수 있다.
|
||||
이는 종종 *thrashing* 또는 *flapping*이라고 불린다.
|
||||
이는 사이버네틱스 분야의 *이력 현상(hysteresis)* 개념과 비슷하다.
|
||||
|
||||
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)에서 찾을 수 있다.
|
||||
|
||||
|
||||
## 롤링 업데이트 중 오토스케일링
|
||||
|
|
@ -203,31 +222,6 @@ HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한
|
|||
스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
|
||||
레플리카셋과 같은 중간 리소스가 없다).
|
||||
|
||||
## 쿨-다운 / 지연에 대한 지원
|
||||
|
||||
Horizontal Pod Autoscaler를 사용하여 레플리카 그룹의 스케일을 관리할 때,
|
||||
평가된 메트릭의 동적인 특징 때문에 레플리카 수가
|
||||
자주 변동할 수 있다. 이것은 때로는 *스래싱 (thrashing)* 이라고도 한다.
|
||||
|
||||
v1.6 부터 클러스터 운영자는 `kube-controller-manager` 컴포넌트의 플래그로
|
||||
노출된 글로벌 HPA 설정을 튜닝하여 이 문제를 완화할 수 있다.
|
||||
|
||||
v1.12부터는 새로운 알고리즘 업데이트가 업스케일 지연에 대한
|
||||
필요성을 제거하였다.
|
||||
|
||||
- `--horizontal-pod-autoscaler-downscale-delay` : 다운스케일이
|
||||
안정화되기까지의 시간 간격을 지정한다.
|
||||
Horizontal Pod Autoscaler는 이전의 권장하는 크기를 기억하고,
|
||||
이 시간 간격에서의 가장 큰 크기에서만 작동한다. 기본값은 5분(`5m0s`)이다.
|
||||
|
||||
{{< note >}}
|
||||
이러한 파라미터 값을 조정할 때 클러스터 운영자는 가능한 결과를 알아야
|
||||
한다. 지연(쿨-다운) 값이 너무 길면, Horizontal Pod Autoscaler가
|
||||
워크로드 변경에 반응하지 않는다는 불만이 있을 수 있다. 그러나 지연 값을
|
||||
너무 짧게 설정하면, 레플리카셋의 크기가 평소와 같이 계속 스래싱될 수
|
||||
있다.
|
||||
{{< /note >}}
|
||||
|
||||
## 리소스 메트릭 지원
|
||||
|
||||
모든 HPA 대상은 스케일링 대상에서 파드의 리소스 사용량을 기준으로 스케일링할 수 있다.
|
||||
|
|
@ -260,7 +254,7 @@ resource:
|
|||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
|
||||
`HorizontalPodAutoscaler` 는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
|
||||
HorizontalPodAutoscaler API는 대상 리소스를 스케일링하기 위해 HPA가 파드 집합에서 개별 컨테이너의
|
||||
리소스 사용량을 추적할 수 있는 컨테이너 메트릭 소스도 지원한다.
|
||||
이를 통해 특정 파드에서 가장 중요한 컨테이너의 스케일링 임계값을 구성할 수 있다.
|
||||
예를 들어 웹 애플리케이션 프로그램과 로깅 사이드카가 있는 경우 사이드카 컨테이너와 해당 리소스 사용을 무시하고
|
||||
|
|
@ -272,6 +266,7 @@ resource:
|
|||
해당 파드는 무시되고 권장 사항이 다시 계산된다. 계산에 대한 자세한 내용은 [알고리즘](#알고리즘-세부-정보)을
|
||||
을 참조한다. 컨테이너 리소스를 오토스케일링에 사용하려면 다음과 같이
|
||||
메트릭 소스를 정의한다.
|
||||
|
||||
```yaml
|
||||
type: ContainerResource
|
||||
containerResource:
|
||||
|
|
@ -297,27 +292,31 @@ HorizontalPodAutoscaler가 추적하는 컨테이너의 이름을 변경하는
|
|||
이전 컨테이너 이름을 제거하여 정리한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 멀티 메트릭을 위한 지원
|
||||
|
||||
Kubernetes 1.6은 멀티 메트릭을 기반으로 스케일링을 지원한다. `autoscaling/v2beta2` API
|
||||
버전을 사용하여 Horizontal Pod Autoscaler가 스케일을 조정할 멀티 메트릭을 지정할 수 있다. 그런 다음 Horizontal Pod
|
||||
Autoscaler 컨트롤러가 각 메트릭을 평가하고, 해당 메트릭을 기반으로 새 스케일을 제안한다.
|
||||
제안된 스케일 중 가장 큰 것이 새로운 스케일로 사용된다.
|
||||
## 사용자 정의 메트릭을 이용하는 스케일링
|
||||
|
||||
## 사용자 정의 메트릭을 위한 지원
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
{{< note >}}
|
||||
쿠버네티스 1.2는 특수 어노테이션을 사용하여 애플리케이션 관련 메트릭을 기반으로 하는 스케일의 알파 지원을 추가했다.
|
||||
쿠버네티스 1.6에서는 이러한 어노테이션 지원이 제거되고 새로운 오토스케일링 API가 추가되었다. 이전 사용자 정의
|
||||
메트릭 수집 방법을 계속 사용할 수는 있지만, Horizontal Pod Autoscaler에서는 이 메트릭을 사용할 수 없다. 그리고
|
||||
Horizontal Pod Autoscaler 컨트롤러에서는 더 이상 스케일 할 사용자 정의 메트릭을 지정하는 이전 어노테이션을 사용할 수 없다.
|
||||
{{< /note >}}
|
||||
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
|
||||
|
||||
쿠버네티스 1.6에서는 Horizontal Pod Autoscaler에서 사용자 정의 메트릭을 사용할 수 있도록 지원한다.
|
||||
`autoscaling/v2beta2` API에서 사용할 Horizontal Pod Autoscaler에 대한 사용자 정의 메트릭을 추가 할 수 있다.
|
||||
그리고 쿠버네티스는 새 사용자 정의 메트릭 API에 질의하여 적절한 사용자 정의 메트릭의 값을 가져온다.
|
||||
`autoscaling/v2beta2` API 버전을 사용하는 경우,
|
||||
(쿠버네티스 또는 어느 쿠버네티스 구성 요소에도 포함되어 있지 않은)
|
||||
커스텀 메트릭을 기반으로 스케일링을 수행하도록 HorizontalPodAutoscaler를 구성할 수 있다.
|
||||
이 경우 HorizontalPodAutoscaler 컨트롤러가 이러한 커스텀 메트릭을 쿠버네티스 API로부터 조회한다.
|
||||
|
||||
요구 사항은 [메트릭을 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
|
||||
요구 사항에 대한 정보는 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다.
|
||||
|
||||
## 복수의 메트릭을 이용하는 스케일링
|
||||
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
|
||||
|
||||
`autoscaling/v2beta2` API 버전을 사용하는 경우,
|
||||
HorizontalPodAutoscaler가 스케일링에 사용할 복수의 메트릭을 설정할 수 있다.
|
||||
이 경우 HorizontalPodAutoscaler 컨트롤러가 각 메트릭을 확인하고 해당 단일 메트릭에 대한 새로운 스케일링 크기를 제안한다.
|
||||
HorizontalPodAutoscaler는 새롭게 제안된 스케일링 크기 중 가장 큰 값을 선택하여 워크로드 사이즈를
|
||||
조정한다(이 값이 이전에 설정한 '총 최대값(overall maximum)'보다는 크지 않을 때에만).
|
||||
|
||||
## 메트릭 API를 위한 지원
|
||||
|
||||
|
|
@ -332,8 +331,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
|||
클러스터 애드온으로 시작할 수 있다.
|
||||
|
||||
* 사용자 정의 메트릭의 경우, 이것은 `custom.metrics.k8s.io` API이다. 메트릭 솔루션 공급 업체에서 제공하는 "어댑터" API 서버에서 제공한다.
|
||||
메트릭 파이프라인 또는 [알려진 솔루션 목록](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)으로 확인한다.
|
||||
직접 작성하고 싶다면 [샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
|
||||
사용 가능한 쿠버네티스 메트릭 어댑터가 있는지 확인하려면 사용하고자 하는 메트릭 파이프라인을 확인한다.
|
||||
|
||||
* 외부 메트릭의 경우, 이것은 `external.metrics.k8s.io` API이다. 위에 제공된 사용자 정의 메트릭 어댑터에서 제공될 수 있다.
|
||||
|
||||
|
|
@ -345,16 +343,21 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다.
|
|||
어떻게 사용하는지에 대한 예시는 [커스텀 메트릭 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#다양한-메트릭-및-사용자-정의-메트릭을-기초로한-오토스케일링)과
|
||||
[외부 메트릭스 사용하는 작업 과정](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#쿠버네티스-오브젝트와-관련이-없는-메트릭을-기초로한-오토스케일링)을 참조한다.
|
||||
|
||||
## 구성가능한 스케일링 동작 지원
|
||||
## 구성가능한 스케일링 동작
|
||||
|
||||
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
|
||||
부터 `v2beta2` API는 HPA `behavior` 필드를 통해
|
||||
스케일링 동작을 구성할 수 있다.
|
||||
동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown`
|
||||
섹션에서 스케일링 업과 다운을 위해 별도로 지정된다. 안정화 윈도우는
|
||||
스케일링 대상에서 레플리카 수의 플래핑(flapping)을 방지하는
|
||||
양방향에 대해 지정할 수 있다. 마찬가지로 스케일링 정책을 지정하면
|
||||
스케일링 중 레플리카 변경 속도를 제어할 수 있다.
|
||||
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
|
||||
|
||||
(이전에는 `autoscaling/v2beta2` API 버전이 이 기능을 베타 기능으로 제공했었다.)
|
||||
|
||||
`v2` 버전의 HorizontalPodAutoscaler API를 사용한다면,
|
||||
`behavior` 필드([API 레퍼런스](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec) 참고)를
|
||||
사용하여 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있다.
|
||||
각 방향에 대한 동작은 `behavior` 필드 아래의
|
||||
`scaleUp` / `scaleDown`를 설정하여 지정할 수 있다.
|
||||
|
||||
_안정화 윈도우_ 를 명시하여 스케일링 목적물의
|
||||
레플리카 수 [흔들림](#flapping)을 방지할 수 있다. 스케일링 정책을 이용하여 스케일링 시
|
||||
레플리카 수 변화 속도를 조절할 수도 있다.
|
||||
|
||||
### 스케일링 정책
|
||||
|
||||
|
|
@ -391,23 +394,29 @@ behavior:
|
|||
확장 방향에 대해 `selectPolicy` 필드를 확인하여 폴리시 선택을 변경할 수 있다.
|
||||
레플리카의 수를 최소로 변경할 수 있는 폴리시를 선택하는 `최소(Min)`로 값을 설정한다.
|
||||
값을 `Disabled` 로 설정하면 해당 방향으로 스케일링이 완전히
|
||||
비활성화 된다.
|
||||
비활성화된다.
|
||||
|
||||
### 안정화 윈도우
|
||||
|
||||
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때 레플리카의 플래핑을
|
||||
다시 제한하기 위해 사용된다. 안정화 윈도우는 스케일링을 방지하기 위해 과거부터
|
||||
계산된 의도한 상태를 고려하는 오토스케일링 알고리즘에 의해 사용된다.
|
||||
다음의 예시에서 `scaleDown` 에 대해 안정화 윈도우가 지정되어 있다.
|
||||
안정화 윈도우는 스케일링에 사용되는 메트릭이 계속 변동할 때
|
||||
레플리카 수의 [흔들림](#flapping)을 제한하기 위해 사용된다.
|
||||
오토스케일링 알고리즘은 이전의 목표 상태를 추론하고
|
||||
워크로드 수의 원치 않는 변화를 방지하기 위해 이 안정화 윈도우를 활용한다.
|
||||
|
||||
예를 들어, 다음 예제 스니펫에서, `scaleDown`에 대해 안정화 윈도우가 설정되었다.
|
||||
|
||||
```yaml
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 300
|
||||
behavior:
|
||||
scaleDown:
|
||||
stabilizationWindowSeconds: 300
|
||||
```
|
||||
|
||||
메트릭이 대상을 축소해야하는 것을 나타내는 경우 알고리즘은
|
||||
이전에 계산된 의도한 상태를 살펴보고 지정된 간격의 최고 값을 사용한다.
|
||||
위의 예시에서 지난 5분 동안 모든 의도한 상태가 고려된다.
|
||||
메트릭 관측 결과 스케일링 목적물이 스케일 다운 되어야 하는 경우,
|
||||
알고리즘은 이전에 계산된 목표 상태를 확인하고, 해당 구간에서 계산된 값 중 가장 높은 값을 사용한다.
|
||||
위의 예시에서, 이전 5분 동안의 모든 목표 상태가 고려 대상이 된다.
|
||||
|
||||
이를 통해 동적 최대값(rolling maximum)을 근사화하여,
|
||||
스케일링 알고리즘이 빠른 시간 간격으로 파드를 제거하고 바로 다시 동일한 파드를 재생성하는 현상을 방지할 수 있다.
|
||||
|
||||
### 기본 동작
|
||||
|
||||
|
|
@ -453,7 +462,7 @@ behavior:
|
|||
stabilizationWindowSeconds: 60
|
||||
```
|
||||
|
||||
### 예시: 스케일 다운 비율 제한
|
||||
### 예시: 스케일 다운 속도 제한
|
||||
|
||||
HPA에 의해 파드가 제거되는 속도를 분당 10%로 제한하기 위해
|
||||
다음 동작이 HPA에 추가된다.
|
||||
|
|
@ -467,9 +476,7 @@ behavior:
|
|||
periodSeconds: 60
|
||||
```
|
||||
|
||||
마지막으로 5개의 파드를 드롭하기 위해 다른 폴리시를 추가하고, 최소 선택
|
||||
전략을 추가할 수 있다.
|
||||
분당 5개 이하의 파드가 제거되지 않도록, 고정 크기가 5인 두 번째 축소
|
||||
분당 제거되는 파드 수가 5를 넘지 않도록 하기 위해, 크기가 5로 고정된 두 번째 축소
|
||||
정책을 추가하고, `selectPolicy` 를 최소로 설정하면 된다. `selectPolicy` 를 `Min` 으로 설정하면
|
||||
자동 스케일러가 가장 적은 수의 파드에 영향을 주는 정책을 선택함을 의미한다.
|
||||
|
||||
|
|
@ -497,6 +504,18 @@ behavior:
|
|||
selectPolicy: Disabled
|
||||
```
|
||||
|
||||
## kubectl의 HorizontalPodAutoscaler 지원
|
||||
|
||||
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 사이의 레플리카 개수로 설정된다.
|
||||
|
||||
## 암시적 유지 관리 모드 비활성화
|
||||
|
||||
HPA 구성 자체를 변경할 필요없이 대상에 대한
|
||||
|
|
@ -506,9 +525,54 @@ HPA를 암시적으로 비활성화할 수 있다. 대상의 의도한
|
|||
다시 활성화할 때까지 HPA는 대상 조정을
|
||||
중지한다(그리고 `ScalingActive` 조건 자체를 `false`로 설정).
|
||||
|
||||
### 디플로이먼트와 스테이트풀셋을 horizontal autoscaling으로 전환하기
|
||||
|
||||
HPA가 활성화되어 있으면, 디플로이먼트, 스테이트풀셋 모두 또는 둘 중 하나의
|
||||
{{< glossary_tooltip text="매니페스트" term_id="manifest" >}}에서
|
||||
`spec.replicas`의 값을 삭제하는 것이 바람직하다.
|
||||
이렇게 적용하지 않으면, (예를 들어 `kubectl apply -f deployment.yaml` 명령으로)
|
||||
오브젝트에 변경이 생길 때마다 쿠버네티스가 파드의 수를
|
||||
`spec.replicas`에 기재된 값으로 조정할 것이다.
|
||||
이는 바람직하지 않으며 HPA가 활성화된 경우에 문제가 될 수 있다.
|
||||
|
||||
`spec.replicas` 값을 제거하면 1회성으로 파드 숫자가 줄어들 수 있는데,
|
||||
이는 이 키의 기본값이 1이기 때문이다(레퍼런스:
|
||||
[디플로이먼트 레플리카](/ko/docs/concepts/workloads/controllers/deployment#레플리카)).
|
||||
값을 업데이트하면, 파드 1개를 제외하고 나머지 파드가 종료 절차에 들어간다.
|
||||
이후의 디플로이먼트 애플리케이션은 정상적으로 작동하며 롤링 업데이트 구성도 의도한 대로 동작한다.
|
||||
이러한 1회성 저하를 방지하는 방법이 존재하며,
|
||||
디플로이먼트 수정 방법에 따라 다음 중 한 가지 방법을 선택한다.
|
||||
|
||||
{{< tabs name="fix_replicas_instructions" >}}
|
||||
{{% tab name="클라이언트 쪽에 적용하기 (기본값))" %}}
|
||||
|
||||
1. `kubectl apply edit-last-applied deployment/<디플로이먼트_이름>`
|
||||
2. 에디터에서 `spec.replicas`를 삭제한다. 저장하고 에디터를 종료하면, `kubectl`이
|
||||
업데이트 사항을 적용한다. 이 단계에서 파드 숫자가 변경되지는 않는다.
|
||||
3. 이제 매니페스트에서 `spec.replicas`를 삭제할 수 있다.
|
||||
소스 코드 관리 도구를 사용하고 있다면, 변경 사항을 추적할 수 있도록
|
||||
변경 사항을 커밋하고 추가 필요 단계를 수행한다.
|
||||
4. 이제 `kubectl apply -f deployment.yaml`를 실행할 수 있다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="서버 쪽에 적용하기" %}}
|
||||
|
||||
[서버 쪽에 적용하기](/docs/reference/using-api/server-side-apply/)를 수행하려면,
|
||||
정확히 이러한 사용 사례를 다루고 있는 [소유권 이전하기](/docs/reference/using-api/server-side-apply/#transferring-ownership)
|
||||
가이드라인을 참조한다.
|
||||
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
클러스터에 오토스케일링을 구성한다면, [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)와 같은
|
||||
클러스터 수준의 오토스케일러 사용을 고려해 볼 수 있다.
|
||||
|
||||
* 디자인 문서: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
|
||||
* kubectl 오토스케일 커맨드: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
|
||||
* [Horizontal Pod Autoscaler](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)의 사용 예제.
|
||||
HorizontalPodAutoscaler에 대한 더 많은 정보는 아래를 참고한다.
|
||||
|
||||
* horizontal pod autoscaling에 대한 [연습 예제](/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)를 확인한다.
|
||||
* [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 문서를 확인한다.
|
||||
* 커스텀 메트릭 어댑터를 직접 작성하고 싶다면,
|
||||
[샘플](https://github.com/kubernetes-sigs/custom-metrics-apiserver)을 확인한다.
|
||||
* HorizontalPodAutoscaler [API 레퍼런스](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler/)를 확인한다.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,10 @@
|
|||
---
|
||||
title: 클러스터에서 TLS 인증서 관리
|
||||
content_type: task
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
@ -158,9 +162,19 @@ Events: <none>
|
|||
|
||||
## 인증서 서명 요청 승인 받기
|
||||
|
||||
인증서 서명 요청을 승인하는 것은 자동화된 승인 프로세스나
|
||||
클러스터 관리자에 의해 일회성으로 수행한다. 여기에
|
||||
관련된 내용에 대한 자세한 내용은 아래에서 설명한다.
|
||||
[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/) 승인은
|
||||
자동화된 승인 프로세스 또는 클러스터 관리자의 일회성 승인으로 수행된다.
|
||||
인증서 요청 승인 권한을 갖고 있다면,
|
||||
`kubectl`을 이용하여 다음과 같이 수동으로 승인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl certificate approve my-svc.my-namespace
|
||||
```
|
||||
|
||||
```none
|
||||
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
|
||||
```
|
||||
|
||||
|
||||
## 인증서 다운로드 및 사용
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
---
|
||||
title: "PowerShell 자동 완성"
|
||||
description: "PowerShell 자동 완성을 위한 몇 가지 선택적 구성에 대해 설명한다."
|
||||
headless: true
|
||||
---
|
||||
|
||||
PowerShell용 kubectl 자동 완성 스크립트는 `kubectl completion powershell` 명령으로 생성할 수 있다.
|
||||
|
||||
모든 셸 세션에서 사용하려면, `$PROFILE` 파일에 다음을 추가한다.
|
||||
|
||||
```powershell
|
||||
kubectl completion powershell | Out-String | Invoke-Expression
|
||||
```
|
||||
|
||||
이 명령은 PowerShell을 실행할 때마다 자동 완성 스크립트를 재생성한다. 아니면, 생성된 스크립트를 `$PROFILE` 파일에 직접 추가할 수도 있다.
|
||||
|
||||
생성된 스크립트를 `$PROFILE` 파일에 직접 추가하려면, PowerShell 프롬프트에서 다음 명령줄을 실행한다.
|
||||
|
||||
```powershell
|
||||
kubectl completion powershell >> $PROFILE
|
||||
```
|
||||
|
||||
셸을 다시 불러오면, kubectl 자동 완성이 동작할 것이다.
|
||||
|
|
@ -176,7 +176,7 @@ kubectl version --client
|
|||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하
|
|||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Bash 및 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@ card:
|
|||
- [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows)
|
||||
- [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop)
|
||||
|
||||
|
||||
### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows}
|
||||
|
||||
1. [최신 릴리스 {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)를 다운로드한다.
|
||||
|
|
@ -134,11 +133,11 @@ card:
|
|||
|
||||
### 셸 자동 완성 활성화
|
||||
|
||||
kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
kubectl은 Bash, Zsh, Fish, 및 PowerShell에 대한 자동 완성 지원을 제공하므로 입력을 위한 타이핑을 많이 절약할 수 있다.
|
||||
|
||||
다음은 Zsh에 대한 자동 완성을 설정하는 절차이다.
|
||||
다음은 PowerShell에 대한 자동 완성을 설정하는 절차이다.
|
||||
|
||||
{{< include "included/optional-kubectl-configs-zsh.md" >}}
|
||||
{{< include "included/optional-kubectl-configs-pwsh.md" >}}
|
||||
|
||||
### `kubectl convert` 플러그인 설치
|
||||
|
||||
|
|
|
|||
|
|
@ -52,10 +52,16 @@ content_type: concept
|
|||
* [AppArmor](/ko/docs/tutorials/clusters/apparmor/)
|
||||
|
||||
* [seccomp](/docs/tutorials/clusters/seccomp/)
|
||||
|
||||
## 서비스
|
||||
|
||||
* [소스 IP 주소 이용하기](/ko/docs/tutorials/services/source-ip/)
|
||||
|
||||
## 보안
|
||||
|
||||
* [파드 보안 표준을 클러스터 수준으로 적용하기](/docs/tutorials/security/cluster-level-pss/)
|
||||
* [파드 보안 표준을 네임스페이스 수준으로 적용하기](/docs/tutorials/security/ns-level-pss/)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
튜토리얼을 작성하고 싶다면, 튜토리얼 페이지 유형에 대한 정보가 있는
|
||||
|
|
|
|||
|
|
@ -233,7 +233,7 @@ kubectl get events | grep hello-apparmor
|
|||
proc attr을 확인하여 컨테이너가 실제로 해당 프로파일로 실행 중인지 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl exec hello-apparmor cat /proc/1/attr/current
|
||||
kubectl exec hello-apparmor -- cat /proc/1/attr/current
|
||||
```
|
||||
```
|
||||
k8s-apparmor-example-deny-write (enforce)
|
||||
|
|
@ -242,7 +242,7 @@ k8s-apparmor-example-deny-write (enforce)
|
|||
마지막으로 파일 쓰기를 통해 프로파일을 위반하면 어떻게 되는지 확인할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl exec hello-apparmor touch /tmp/test
|
||||
kubectl exec hello-apparmor -- touch /tmp/test
|
||||
```
|
||||
```
|
||||
touch: /tmp/test: Permission denied
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ weight: 10
|
|||
<div class="row">
|
||||
<div class="col-md-8">
|
||||
<p><b>컨트롤 플레인은 클러스터 관리를 담당한다.</b> 컨트롤 플레인은 애플리케이션을 스케줄링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영(rolling out)하는 일과 같은 클러스터 내 모든 활동을 조율한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.</p>
|
||||
<p><b>노드는 쿠버네티스 클러스터 내 워커 머신으로 동작하는 VM 또는 물리적인 컴퓨터다.</b> 각 노드는 노드를 관리하고 쿠버네티스 컨트롤 플레인과 통신하는 Kubelet이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 containerd 또는 도커와 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 하는데, 이는 한 노드가 다운되면 etcd 멤버와 컨트롤 플레인 인스턴스가 사라져 중복성(redundancy)을 잃기 때문이다. 컨트롤 플레인 노드를 추가하여 이러한 위험을 줄일 수 있다.</p>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4">
|
||||
|
|
|
|||
|
|
@ -894,8 +894,7 @@ kubernetes-node-2g2d
|
|||
kubectl get nodes
|
||||
```
|
||||
|
||||
[`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon)을 이용하여
|
||||
클러스터 내에 4개 노드를 제외하고 다른 모든 노드를 통제해보자.
|
||||
이 튜토리얼에서는 클러스터가 최소 4개의 노드로 구성되었다고 가정한다. 클러스터의 노드가 4개보다 많다면, [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) 명령을 이용하여 4개 노드를 제외하고 다른 모든 노드를 통제(cordon)한다. 이렇게 4개 노드만 사용하도록 제한하여, 다음의 유지보수 시뮬레이션 예시에서 주키퍼 파드를 스케줄링할 때 어피니티와 PodDisruptionBudget 제약이 발생하도록 할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl cordon <노드-이름>
|
||||
|
|
|
|||
Loading…
Reference in New Issue