기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
개요
Kubernetes Cluster Autoscaler.DesiredReplicas 필드를 제어합니다.
이 가이드에서는 Cluster Autoscaler를 구성하고 조직의 요구 사항에 맞는 최적의 장단점을 선택하기 위한 멘탈 모델을 제공합니다. 최상의 단일 구성은 없지만 성능, 확장성, 비용 및 가용성을 상쇄할 수 있는 구성 옵션 세트가 있습니다. 또한이 가이드에서는 AWS에 대한 구성을 최적화하기 위한 팁과 모범 사례를 제공합니다.
용어집
이 문서 전체에서 다음 용어가 자주 사용됩니다. 이러한 용어는 광범위한 의미를 가질 수 있지만이 문서의 목적상 아래 정의로 제한됩니다.
확장성은 Kubernetes 클러스터의 포드 및 노드 수가 증가함에 따라 Cluster Autoscaler가 얼마나 잘 작동하는지를 나타냅니다. 확장성 한도에 도달하면 Cluster Autoscaler의 성능과 기능이 저하됩니다. Cluster Autoscaler가 확장성 제한을 초과하면 클러스터에 노드를 더 이상 추가하거나 제거하지 못할 수 있습니다.
성능은 Cluster Autoscaler가 조정 결정을 내리고 실행할 수 있는 속도를 나타냅니다. 완벽하게 작동하는 Cluster Autoscaler는 즉시 결정을 내리고 포드를 예약할 수 없게 되는 등 자극에 대응하여 조정 작업을 트리거합니다.
가용성이란 중단 없이 신속하게 포드를 예약할 수 있음을 의미합니다. 여기에는 새로 생성된 포드를 예약해야 하는 경우와 축소된 노드가 예약된 나머지 포드를 종료하는 경우가 포함됩니다.
비용은 스케일 아웃 및 스케일 인 이벤트의 결정에 따라 결정됩니다. 기존 노드의 사용률이 낮거나 수신 포드에 비해 너무 큰 새 노드가 추가되면 리소스가 낭비됩니다. 사용 사례에 따라 공격적인 스케일 다운 결정으로 인해 포드를 조기에 종료하는 데 따른 비용이 발생할 수 있습니다.
노드 그룹은 클러스터 내의 노드 그룹에 대한 추상적인 Kubernetes 개념입니다. 이는 실제 Kubernetes 리소스는 아니지만 Cluster Autoscaler, Cluster API 및 기타 구성 요소에 추상화로 존재합니다. 노드 그룹 내의 노드는 레이블 및 테인트와 같은 속성을 공유하지만 여러 가용 영역 또는 인스턴스 유형으로 구성될 수 있습니다.
EC2 Auto Scaling 그룹은 EC2에서 노드 그룹의 구현으로 사용할 수 있습니다. EC2 Auto Scaling 그룹은 Kubernetes 클러스터에 자동으로 조인하는 인스턴스를 시작하고 Kubernetes API의 해당 노드 리소스에 레이블과 테인트를 적용하도록 구성됩니다.
EC2 관리형 노드 그룹은 EC2에서 노드 그룹의 또 다른 구현입니다. EC2 Autoscaling 조정 그룹을 수동으로 구성하는 복잡성을 추상화하고 노드 버전 업그레이드 및 정상적인 노드 종료와 같은 추가 관리 기능을 제공합니다.
Cluster Autoscaler 작동
Cluster Autoscaler는 일반적으로 클러스터에 배포
다음을 확인합니다.
-
Cluster Autoscaler의 버전은 클러스터의 버전과 일치합니다. 교차 버전 호환성은 테스트되거나 지원되지 않습니다
. -
이 모드 사용을 방해하는 특정 고급 사용 사례가 없는 한 자동 검색
이 활성화됩니다.
IAM 역할에 대한 최소 권한 액세스 사용
Auto Discoveryautoscaling:SetDesiredCapacity 및를 현재 클러스터로 범위가 지정된 Auto Scaling 그룹autoscaling:TerminateInstanceInAutoScalingGroup으로 제한하여 최소 권한 액세스를 사용하는 것이 좋습니다.
이렇게 하면 --node-group-auto-discovery 인수가 태그를 사용하여 클러스터의 노드 그룹으로 범위가 축소되지 않은 경우에도 한 클러스터에서 실행되는 Cluster Autoscaler가 다른 클러스터의 노드 그룹을 수정하지 못합니다(예: k8s.io/cluster-autoscaler/<cluster-name>).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:SetDesiredCapacity",
"autoscaling:TerminateInstanceInAutoScalingGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
"aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
}
}
},
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeLaunchConfigurations",
"autoscaling:DescribeScalingActivities",
"autoscaling:DescribeTags",
"ec2:DescribeImages",
"ec2:DescribeInstanceTypes",
"ec2:DescribeLaunchTemplateVersions",
"ec2:GetInstanceTypesFromInstanceRequirements",
"eks:DescribeNodegroup"
],
"Resource": "*"
}
]
}노드 그룹 구성
효과적인 Autoscaling은 클러스터에 대한 노드 그룹 세트를 올바르게 구성하는 것으로 시작됩니다. 올바른 노드 그룹 세트를 선택하는 것은 가용성을 극대화하고 워크로드 전반의 비용을 절감하는 데 중요합니다. AWS는 EC2 Auto Scaling 그룹을 사용하여 노드 그룹을 구현합니다.이 그룹은 많은 사용 사례에 유연하게 적용할 수 있습니다. 하지만 Cluster Autoscaler는 노드 그룹에 대해 몇 가지 가정을 합니다. EC2 Auto Scaling 그룹 구성을 이러한 가정과 일관되게 유지하면 원치 않는 동작이 최소화됩니다.
다음을 확인합니다.
-
노드 그룹의 각 노드에는 레이블, 테인트 및 리소스와 같은 동일한 예약 속성이 있습니다.
-
MixedInstancePolicies의 경우 인스턴스 유형은 CPU, 메모리 및 GPU에 대해 동일한 셰이프여야 합니다.
-
정책에 지정된 첫 번째 인스턴스 유형을 사용하여 일정을 시뮬레이션합니다.
-
정책에 리소스가 더 많은 추가 인스턴스 유형이 있는 경우 확장 후 리소스가 낭비될 수 있습니다.
-
정책에 리소스가 적은 추가 인스턴스 유형이 있는 경우 포드가 인스턴스에서 예약하지 못할 수 있습니다.
-
-
노드가 많은 노드 그룹은 노드가 적은 많은 노드 그룹보다 선호됩니다. 이는 확장성에 가장 큰 영향을 미칩니다.
-
가능하면 두 시스템 모두 지원을 제공할 때 EC2 기능을 선호합니다(예: 리전, MixedInstancePolicy).
참고: EKS 관리형 노드 그룹을 사용하는 것이 좋습니다. 관리형 노드 그룹에는 자동 EC2 Auto Scaling 그룹 검색 및 정상적인 노드 종료와 같은 Cluster Autoscaler 기능을 비롯한 강력한 관리 기능이 제공됩니다.
성능 및 확장성 최적화
Autoscaling 알고리즘의 런타임 복잡성을 이해하면 노드가 1,000
Cluster Autoscaler의 확장성을 조정하기 위한 기본 노브는 프로세스에 제공되는 리소스, 알고리즘의 스캔 간격, 클러스터의 노드 그룹 수입니다. 플러그인 복잡성 및 포드 수를 예약하는 등이 알고리즘의 실제 런타임 복잡성과 관련된 다른 요인이 있습니다. 이러한 파라미터는 클러스터의 워크로드에 자연스럽게 적용되며 쉽게 튜닝할 수 없으므로 구성할 수 없는 파라미터로 간주됩니다.
Cluster Autoscaler는 포드, 노드 및 노드 그룹을 포함하여 전체 클러스터의 상태를 메모리에 로드합니다. 각 스캔 간격에서 알고리즘은 예약할 수 없는 포드를 식별하고 각 노드 그룹에 대한 일정을 시뮬레이션합니다. 이러한 요인을 조정하면 사용 사례에 맞게 신중하게 고려해야 하는 다양한 장단점이 있습니다.
Cluster Autoscaler 수직 자동 조정
Cluster Autoscaler를 더 큰 클러스터로 확장하는 가장 간단한 방법은 배포에 대한 리소스 요청을 늘리는 것입니다. 대용량 클러스터의 경우 메모리와 CPU를 모두 늘려야 하지만 클러스터 크기에 따라 크게 다릅니다. Autoscaling 알고리즘은 모든 포드와 노드를 메모리에 저장하므로 경우에 따라 메모리 공간이 1기가바이트보다 클 수 있습니다. 리소스 증가는 일반적으로 수동으로 수행됩니다. 일정한 리소스 튜닝으로 인해 운영 부담이 발생하는 경우 Addon Resizer
노드 그룹 수 줄이기
노드 그룹 수를 최소화하는 것은 Cluster Autoscaler가 대규모 클러스터에서 계속 잘 작동하도록 하는 한 가지 방법입니다. 이는 팀 또는 애플리케이션별로 노드 그룹을 구성하는 일부 조직에게는 어려울 수 있습니다. 이는 Kubernetes API에서 완전히 지원되지만 확장성을 위해 영향을 미치는 Cluster Autoscaler 안티 패턴으로 간주됩니다. 여러 노드 그룹(예: 스팟 또는 GPUs 사용해야 하는 이유는 많지만, 많은 경우 소수의 그룹을 사용하면서 동일한 효과를 내는 대체 설계가 있습니다.
다음을 확인합니다.
-
포드 격리는 노드 그룹이 아닌 네임스페이스를 사용하여 수행됩니다.
-
이는 저신뢰 멀티 테넌트 클러스터에서는 가능하지 않을 수 있습니다.
-
리소스 경합을 방지하기 위해 Pod ResourceRequests 및 ResourceLimits가 올바르게 설정되어 있습니다.
-
인스턴스 유형이 클수록 빈 패킹이 더 최적화되고 시스템 포드 오버헤드가 줄어듭니다.
-
-
NodeTaints NodeSelectors 규칙이 아닌 예외로 포드를 예약하는 데 사용됩니다.
-
리전 리소스는 여러 가용 영역이 있는 단일 EC2 Auto Scaling 그룹으로 정의됩니다.
스캔 간격 줄이기
스캔 간격이 짧으면(예: 10초) 포드를 예약할 수 없을 때 Cluster Autoscaler가 최대한 빨리 응답합니다. 그러나 각 스캔으로 인해 Kubernetes API 및 EC2 Auto Scaling 그룹 또는 EKS 관리형 노드 그룹 APIs에 대한 API 호출이 많이 발생합니다. 이러한 API 호출로 인해 Kubernetes 제어 플레인의 속도가 제한되거나 심지어 서비스를 사용할 수 없게 될 수 있습니다.
기본 스캔 간격은 10초이지만 AWS에서 노드를 시작하는 데 새 인스턴스를 시작하는 데 훨씬 더 오래 걸립니다. 즉, 전체 확장 시간을 크게 늘리지 않고 간격을 늘릴 수 있습니다. 예를 들어 노드를 시작하는 데 2분이 걸리는 경우 간격을 1분으로 변경하면 38% 느린 스케일 업에 대해 API 호출이 6배 감소합니다.
노드 그룹 간 샤딩
Cluster Autoscaler는 특정 노드 그룹 세트에서 작동하도록 구성할 수 있습니다. 이 기능을 사용하면 Cluster Autoscaler의 여러 인스턴스를 배포할 수 있으며, 각 인스턴스는 서로 다른 노드 그룹 세트에서 작동하도록 구성됩니다. 이 전략을 사용하면 임의로 많은 수의 노드 그룹을 사용할 수 있으며, 이는 확장성을 위한 거래 비용입니다. 성능 향상을 위한 최후의 수단으로만 사용하는 것이 좋습니다.
Cluster Autoscaler는 원래이 구성을 위해 설계되지 않았으므로 몇 가지 부작용이 있습니다. 샤드가 통신하지 않으므로 여러 오토 스케일러가 예약할 수 없는 포드를 예약하려고 시도할 수 있습니다. 이로 인해 여러 노드 그룹에서 불필요한 스케일 아웃이 발생할 수 있습니다. 이러한 추가 노드는 이후에 다시 축소됩니다scale-down-delay.
metadata:
name: cluster-autoscaler
namespace: cluster-autoscaler-1
...
--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2
---
metadata:
name: cluster-autoscaler
namespace: cluster-autoscaler-2
...
--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4다음을 확인합니다.
-
각 샤드는 고유한 EC2 Auto Scaling 그룹 세트를 가리키도록 구성됩니다.
-
각 샤드는 리더 선출 충돌을 방지하기 위해 별도의 네임스페이스에 배포됩니다.
비용 및 가용성 최적화
스팟 인스턴스
노드 그룹에서 스팟 인스턴스를 사용하고 온디맨드 가격에서 최대 90% 할인할 수 있습니다. 단, EC2에 용량이 다시 필요한 경우 언제든지 스팟 인스턴스를 중단할 수 있습니다. 사용 가능한 용량이 부족하여 EC2 Auto Scaling 그룹을 확장할 수 없는 경우 용량 부족 오류가 발생합니다. 많은 인스턴스 패밀리를 선택하여 다양성을 극대화하면 여러 스팟 용량 풀을 활용하여 원하는 규모를 달성할 가능성이 높아지고 스팟 인스턴스 중단이 클러스터 가용성에 미치는 영향이 줄어들 수 있습니다. 스팟 인스턴스와 혼합 인스턴스 정책은 노드 그룹 수를 늘리지 않고도 다양성을 높일 수 있는 좋은 방법입니다. 보장된 리소스가 필요한 경우 스팟 인스턴스 대신 온디맨드 인스턴스를 사용해야 합니다.
혼합 인스턴스 정책을 구성할 때 모든 인스턴스 유형에 유사한 리소스 용량이 있어야 합니다. Autoscaler의 일정 시뮬레이터는 MixedInstancePolicy의 첫 번째 InstanceType을 사용합니다. MixedInstancePolicy 후속 인스턴스 유형이 더 크면 스케일 업 후 리소스가 낭비될 수 있습니다. 크기가 작으면 용량이 부족하여 새 인스턴스에서 포드를 예약하지 못할 수 있습니다. 예를 들어, M4, M5, M5a 및 M5n 인스턴스는 모두 CPU와 메모리 양이 비슷하며 MixedInstancePolicy의 훌륭한 후보입니다. EC2 인스턴스 선택기
온디맨드 및 스팟 용량을 별도의 EC2 Auto Scaling 그룹으로 분리하는 것이 좋습니다. 예약 속성은 기본적으로 다르기 때문에 기본 용량 전략을 사용하는 것보다 선호됩니다. 스팟 인스턴스는 언제든지 중단되므로(EC2에 용량이 다시 필요한 경우) 사용자는 종종 선점 가능한 노드를 테인트하므로 선점 동작에 대한 명시적 포드 허용이 필요합니다. 이러한 테인트는 노드의 예약 속성이 다르므로 여러 EC2 Auto Scaling 그룹으로 분리해야 합니다.
Cluster Autoscaler에는 확장기의 개념이 있습니다. 확장기는--expander=least-waste은 좋은 범용 기본값이며 스팟 인스턴스 다각화에 여러 노드 그룹을 사용하려는 경우(위 이미지에 설명됨) 조정 활동 후 가장 잘 활용될 그룹을 조정하여 노드 그룹을 추가로 비용 최적화하는 데 도움이 될 수 있습니다.
노드 그룹/ASG 우선 순위 지정
Priority 확장 프로그램을 사용하여 우선 순위 기반 Autoscaling을 구성할 수도 있습니다.를 --expander=priority 사용하면 클러스터가 노드 그룹/ASG의 우선 순위를 지정할 수 있으며, 어떤 이유로든 확장할 수 없는 경우 우선 순위가 지정된 목록에서 다음 노드 그룹을 선택합니다. 이는 예를 들어 GPU가 워크로드에 최적의 성능을 제공하기 때문에 P3 인스턴스 유형을 사용하려는 상황에서 유용하지만, 두 번째 옵션으로 P2 인스턴스 유형을 사용할 수도 있습니다.
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-autoscaler-priority-expander
namespace: kube-system
data:
priorities: |-
10:
- .*p2-node-group.*
50:
- .*p3-node-group.*Cluster Autoscaler는 p3-node-group 이름과 일치하는 EC2 Auto Scaling 그룹을 확장하려고 시도합니다. 내에서이 작업이 성공하지 못하면 p2-node-group이라는 이름과 일치하는 EC2 Auto Scaling 그룹을 조정하려고 시도--max-node-provision-time합니다. 이 값은 기본적으로 15분으로 설정되며 응답성이 뛰어난 노드 그룹 선택을 위해 줄일 수 있지만 값이 너무 낮으면 불필요한 스케일 아웃이 발생할 수 있습니다.
오버프로비저닝
Cluster Autoscaler는 필요한 경우에만 노드를 클러스터에 추가하고 사용하지 않을 때는 노드를 제거하여 비용을 최소화합니다. 이는 많은 포드가 노드 스케일 업을 기다렸다가 예약할 수 있기 때문에 배포 지연 시간에 큰 영향을 미칩니다. 노드를 사용할 수 있게 되려면 몇 분 정도 걸릴 수 있으며, 이로 인해 포드 예약 지연 시간이 크게 늘어날 수 있습니다.
예약 대기 시간이 늘어나는 것을 감수하고 오버프로비저닝
오버프로비저닝에는 덜 명확한 다른 이점이 있습니다. 과다 프로비저닝하지 않으면 활용률이 높은 클러스터의 부작용 중 하나는 포드가 포드 또는 노드 선호도 preferredDuringSchedulingIgnoredDuringExecution 규칙을 사용하여 최적의 예약 결정을 덜 내리는 것입니다. 이에 대한 일반적인 사용 사례는 AntiAffinity를 사용하여 가용 영역에서 가용성이 높은 애플리케이션의 포드를 분리하는 것입니다. 오버프로비저닝은 올바른 영역의 노드를 사용할 수 있는 가능성을 크게 높일 수 있습니다.
과다 프로비저닝된 용량의 양은 조직의 신중한 비즈니스 결정입니다. 핵심은 성능과 비용의 장단점입니다. 이 결정을 내리는 한 가지 방법은 평균 스케일 업 빈도를 결정하고 이를 새 노드를 스케일 업하는 데 걸리는 시간으로 나누는 것입니다. 예를 들어 평균적으로 30초마다 새 노드가 필요하고 EC2가 새 노드를 프로비저닝하는 데 30초가 걸리는 경우 오버프로비저닝의 단일 노드를 사용하면 항상 추가 노드를 사용할 수 있으므로 단일 추가 EC2 인스턴스의 비용으로 예약 지연 시간이 30초 단축됩니다. 영역 예약 결정을 개선하려면 EC2 Auto Scaling 그룹의 가용 영역 수와 동일한 수의 노드를 오버프로비저닝하여 스케줄러가 수신 포드에 가장 적합한 영역을 선택할 수 있도록 합니다.
스케일 다운 제거 방지
일부 워크로드는 제거 비용이 많이 듭니다. 빅 데이터 분석, 기계 학습 작업 및 테스트 실행기는 결국 완료되지만 중단되면 다시 시작해야 합니다. Cluster Autoscaler는 scale-down-utilization-threshold 아래의 노드를 스케일 다운하려고 시도하며, 이로 인해 노드에 남아 있는 포드가 중단됩니다. 이는 제거 비용이 많이 드는 포드가 Cluster Autoscaler에서 인식하는 레이블로 보호되도록 하여 방지할 수 있습니다.
다음을 확인합니다.
-
제거 비용이 많이 드는 포드에는 주석이 있습니다.
cluster-autoscaler.kubernetes.io/safe-to-evict=false
고급 사용 사례
EBS 볼륨
영구 스토리지는 데이터베이스 또는 분산 캐시와 같은 상태 저장 애플리케이션을 구축하는 데 매우 중요합니다. EBS 볼륨은
다음을 확인합니다.
-
노드 그룹 밸런싱은
balance-similar-node-groups=true를 설정하여 활성화합니다. -
노드 그룹은 서로 다른 가용 영역과 EBS 볼륨을 제외하고 동일한 설정으로 구성됩니다.
공동 예약
기계 학습 분산 훈련 작업은 동일한 영역 노드 구성의 최소화된 지연 시간을 통해 상당한 이점을 얻을 수 있습니다. 이러한 워크로드는 특정 영역에 여러 포드를 배포합니다. 이는를 사용하여 공동 예약된 모든 포드에 대해 포드 선호도를 설정하거나 노드 선호도를 설정하여 달성할 수 있습니다topologyKey: failure-domain.beta.kubernetes.io/zone. 그런 다음 Cluster Autoscaler는 수요에 맞게 특정 영역을 확장합니다. 여러 EC2 Auto Scaling 그룹을 할당하고 가용 영역당 하나씩 할당하여 공동 예약된 전체 워크로드에 대한 장애 조치를 활성화할 수 있습니다.
다음을 확인합니다.
액셀러레이터
일부 클러스터는 GPU와 같은 특수 하드웨어 액셀러레이터를 활용합니다. 스케일 아웃 시 액셀러레이터 디바이스 플러그인이 리소스를 클러스터에 알리는 데 몇 분 정도 걸릴 수 있습니다. Cluster Autoscaler는이 노드에 액셀러레이터가 있다고 시뮬레이션했지만 액셀러레이터가 준비되고 노드의 사용 가능한 리소스를 업데이트할 때까지는 보류 중인 포드를 노드에서 예약할 수 없습니다. 이로 인해 반복적 불필요한 확장
또한 액셀러레이터가 사용되지 않더라도 액셀러레이터가 있고 CPU 또는 메모리 사용률이 높은 노드는 스케일 다운에 고려되지 않습니다. 이 동작은 액셀러레이터의 상대적 비용 때문에 비용이 많이 들 수 있습니다. 대신 Cluster Autoscaler는 액셀러레이터가 점유되지 않은 경우 스케일 다운할 노드를 고려하는 특수 규칙을 적용할 수 있습니다.
이러한 경우에 올바른 동작을 보장하려면 클러스터에 조인하기 전에 노드에 레이블을 지정하도록 액셀러레이터 노드의 kubelet을 구성할 수 있습니다. Cluster Autoscaler는이 레이블 선택기를 사용하여 액셀러레이터 최적화 동작을 트리거합니다.
다음을 확인합니다.
-
GPU 노드용 Kubelet은 로 구성됩니다.
--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE -
Accelerator가 있는 노드는 위에 언급된 것과 동일한 예약 속성 규칙을 준수합니다.
0에서 조정
Cluster Autoscaler는 노드 그룹을 0에서 0으로 확장할 수 있으므로 상당한 비용 절감 효과를 얻을 수 있습니다. LaunchConfiguration 또는 LaunchTemplate LaunchTemplate에 지정된 InstanceType을 검사하여 Auto Scaling 그룹의 CPU, 메모리 및 GPU 리소스를 감지합니다. 일부 포드에는 WindowsENI LaunchConfiguration에서 검색할 수 없는 PrivateIPv4Address 또는 특정 NodeSelectors 또는 Taints와 같은 추가 리소스가 필요합니다. Cluster Autoscaler는 EC2 Auto Scaling 그룹의 태그에서 이러한 요소를 검색하여 이러한 요소를 설명할 수 있습니다. 예시:
Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoSchedule참고: 0으로 조정하면 용량이 EC2로 반환되고 나중에 사용할 수 없게 될 수 있습니다.
추가 파라미터
Cluster Autoscaler의 동작과 성능을 조정하는 데 사용할 수 있는 많은 구성 옵션이 있습니다. 파라미터의 전체 목록은 GitHub
| 파라미터 | 설명 | Default |
|---|---|---|
|
스캔 간격 |
클러스터가 스케일 업 또는 스케일 다운을 위해 재평가되는 빈도 |
10초 |
|
max-empty-bulk-delete |
동시에 삭제할 수 있는 최대 빈 노드 수입니다. |
10 |
|
scale-down-delay-after-add |
스케일 업 후 스케일 다운 평가가 재개되는 시간 |
10분 |
|
scale-down-delay-after-delete |
스케일 다운 평가가 재개된 후 노드 삭제가 재개되는 기간, 기본값은 scan-interval입니다. |
스캔 간격 |
|
scale-down-delay-after-failure |
축소 실패 후 축소 평가가 재개되는 기간 |
3분 |
|
scale-down-unneeded-time |
스케일 다운에 적합하기 전에 노드가 필요하지 않은 기간 |
10분 |
|
scale-down-unready-time |
스케일 다운에 적합하기 전에 준비되지 않은 노드가 필요하지 않은 기간 |
20분 |
|
scale-down-utilization-threshold |
노드 사용률 수준 - 요청된 리소스의 합계를 용량으로 나눈 값으로 정의되며 노드를 축소 대상으로 고려할 수 있습니다. |
0.5 |
|
scale-down-non-empty-candidates-count |
한 번의 반복에서 드레이닝으로 스케일 다운할 수 있는 대상으로 간주되는 비어 있지 않은 노드의 최대 수입니다. 값이 낮을수록 CA 응답성이 향상되지만 스케일 다운 지연 시간이 느려질 수 있습니다. 값이 높을수록 큰 클러스터(수백 개의 노드)의 CA 성능에 영향을 미칠 수 있습니다. 이 휴리스틱을 끄려면 양수가 아닌 값으로 설정합니다. CA는 고려하는 노드 수를 제한하지 않습니다. |
30 |
|
scale-down-candidates-pool-ratio |
이전 반복의 일부 후보가 더 이상 유효하지 않을 때 스케일 다운을 위해 비어 있지 않은 추가 후보로 간주되는 노드의 비율입니다. 값이 낮을수록 CA 응답성이 향상되지만 스케일 다운 지연 시간이 느려질 수 있습니다. 값이 높을수록 큰 클러스터(수백 개의 노드)의 CA 성능에 영향을 미칠 수 있습니다. 이 휴리스틱을 끄려면 1.0으로 설정합니다. CA는 모든 노드를 추가 후보로 사용합니다. |
0.1 |
|
scale-down-candidates-pool-min-count |
이전 반복의 일부 후보가 더 이상 유효하지 않을 때 스케일 다운을 위해 비어 있지 않은 추가 후보로 간주되는 최소 노드 수입니다. 추가 후보의 풀 크기를 계산할 때 |
50 |
추가 리소스
이 페이지에는 Cluster Autoscaler 프레젠테이션 및 데모 목록이 포함되어 있습니다. 여기에 프레젠테이션 또는 데모를 추가하려면 풀 요청을 보내세요.
| 프레젠테이션/데모 | 발표자 |
|---|---|
|
Guy Templeton, Skyscanner 및 Jiaxin Shan, Amazon |
|
|
Maciek Pytel 및 Marcin Wielgus |
참조
