티스토리 뷰

카테고리 없음

overprovisioning

미니대왕님 2022. 7. 27. 20:36

overprovisioning

node를 scale out할때는 instace를 새로 띄우는거다보니 pod를 scale out하는 것보다 시간이 오래 걸리는데요

이 scale out 시간 절약을 위해서 미리 프로비저닝할 수 있습니다.

방법은 직관적이고 간단한데요,

 

1. 아무 역할을 하지않는 pod를 미리 생성합니다. 이때 pod의 priority를 다른 일반 pod들보다 낮게 설정해줍니다.

---
apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: overprovisioning
value: -1
globalDefault: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: overprovisioning
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      run: overprovisioning
  template:
    metadata:
      labels:
        run: overprovisioning
    spec:
      priorityClassName: overprovisioning
      containers:
      - name: reserve-resources
        image: k8s.gcr.io/pause
        resources:
          requests:
            cpu: 1600m
            memory: 550Mi

2. 일반 pod가 새롭게 생성될때 node에 자리가 부족하면 1의 pod를 내쫓고 그 자리를 차지합니다.

3. 내쫓김을 당한 pod는 scale out을 trigger합니다.

 

이렇게 너무 간단하게 node를 over provisioning할 수 있는데요. 한가지 주의할점은 overprovisioning pod의 resource입니다.  overprovisioning pod를 내쫓아도 node의 잔여 resource가 모자라는 경우에 당연하게도 overprovisioning이 정상적으로 작동하지 않습니다. 이를 대비해서 overprovisioning pod의 memory, cpu의 resource request를 적정한 크기로 설정해야합니다.

5. 기타 옵션

--skip-nodes-with-system-pods=false 

CA는  kube-system pod를 실행중인 node는 terminate하지 않는데요, 이 옵션을 주면 해당 node까지도 terminate합니다.

 

--scale-down-delay-after-add
--scale-down-delay-after-delete
--scale-down-delay-after-failure

 

CA는 기본 설정상으로 scale down 전에 10분정도 대기를 합니다. 위의 옵션들로 대기시간을 수정할 수 있습니다.

 

  # write-status-configmap: true
  # leader-elect: true
  # skip-nodes-with-local-storage: false
  # expander: least-waste
  # scale-down-enabled: true
  # balance-similar-node-groups: true
  # min-replica-count: 2
  # scale-down-utilization-threshold: 0.5
  # scale-down-non-empty-candidates-count: 5
  # max-node-provision-time: 15m0s
  # scan-interval: 10s
  # scale-down-unneeded-time: 3m
  # skip-nodes-with-local-storage: false
  # skip-nodes-with-system-pods: true

기타 사용 가능한 옵션들입니다.

https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node

 

GitHub - kubernetes/autoscaler: Autoscaling components for Kubernetes

Autoscaling components for Kubernetes. Contribute to kubernetes/autoscaler development by creating an account on GitHub.

github.com

 

기초

클러스터 자동 확장 처리란 무엇입니까?

Cluster Autoscaler는 현재 요구 사항에 맞게 Kubernetes 클러스터의 크기를 조정하는 독립 실행형 프로그램입니다.

Cluster Autoscaler는 언제 클러스터 크기를 변경합니까?

Cluster Autoscaler는 다음과 같은 경우 클러스터의 크기를 늘립니다.

  • 리소스 부족으로 인해 현재 노드에서 예약하지 못한 포드가 있습니다.
  • 현재 클러스터에 있는 노드와 유사한 노드를 추가하면 도움이 됩니다.

Cluster Autoscaler는 일부 노드가 상당한 시간 동안 지속적으로 필요하지 않을 때 클러스터의 크기를 줄입니다. 사용률이 낮고 모든 중요한 포드를 다른 곳으로 이동할 수 있는 경우 노드가 필요하지 않습니다.

CA가 노드를 제거하지 못하도록 할 수 있는 포드 유형은 무엇입니까?

  • 제한적인 PodDisruptionBudget이 있는 포드입니다.
  • 다음과 같은 Kube 시스템 포드:
    • 기본적으로 노드에서 실행되지 않습니다. *
    • 포드 중단 예산 이 설정되어 있지 않거나 PDB가 너무 제한적입니다(CA 0.6 이후).
  • 컨트롤러 객체가 지원하지 않는 파드(배포, 복제본 세트, 작업, 상태 저장 세트 등에 의해 생성되지 않음). *
  • 로컬 스토리지가 있는 포드. *
  • 다양한 제약(리소스 부족, 일치하지 않는 노드 선택자 또는 선호도, 일치하는 반선호도 등)으로 인해 다른 곳으로 이동할 수 없는 Pod
  • 다음 주석 세트가 있는 포드:
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"

* 포드에 다음 주석이 없는 경우(CA 1.0.3 이상에서 지원됨):

"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"

또는 관련 플래그 중 하나로 이 동작을 재정의했습니다. 이러한 플래그에 대한 자세한 내용은 아래를 참조하세요.

클러스터에서 어떤 버전의 Cluster Autoscaler를 사용해야 합니까?

클러스터 자동 확장 처리 릴리스 보기

클러스터 자동 확장 처리는 알파, 베타 또는 GA 제품입니까?

버전 1.0.0부터 CA를 GA로 간주합니다. 이는 다음을 의미합니다.

  • 우리는 그것이 기대하는 바를 수행한다는 충분한 확신을 가지고 있습니다. 각 커밋은 75% 이상의 적용 범위(평균)로 대규모 단위 테스트를 거칩니다. CA가 GCE 및 GKE 에서 잘 작동하는지 확인하는 일련의 e2e 테스트가 있습니다 . 누락된 테스트 인프라로 인해 AWS(또는 기타 클라우드 공급자) 호환성 테스트는 표준 개발 또는 릴리스 절차의 일부가 아닙니다. 그러나 프로덕션 환경에서 CA를 실행하고 새 코드, 패치 및 버그 보고서를 제출하는 AWS 사용자가 많이 있습니다.
  • CA가 잘 확장되는지 테스트되었습니다. CA는 각각 30개의 포드를 실행하는 최대 1000개의 노드를 처리해야 합니다. 테스트 절차는 여기 에 설명되어 있습니다 .
  • 사용자가 보고한 대부분의 고충(예: 너무 짧은 우아한 종료 지원)이 수정되었지만 덜 중요한 기능 요청 중 일부는 아직 구현되지 않았습니다.
  • CA에는 적절한 모니터링, 로깅 및 이벤트가 있습니다.
  • CA는 클러스터에서 대부분의 오류 상황(클라우드 제공자 품절, 노드 고장 등)을 처리하려고 합니다. 그러나 처리되는 사례는 클라우드 제공업체마다 다를 수 있습니다.
  • CA 개발자는 가까운 장래에 CA를 유지 관리하고 지원하기 위해 최선을 다하고 있습니다.

모든 이전 버전(1.0.0 이전)은 베타 버전으로 간주됩니다.

클러스터 자동 확장 처리의 서비스 수준 목표는 무엇입니까?

Cluster Autoscaler의 주요 목적은 보류 중인 포드를 실행할 장소를 확보하는 것입니다. 

Cluster Autoscaler는 보류 중인 포드가 있는지 여부를 주기적으로 확인하고 합리적이고 확장된 클러스터가 여전히 사용자가 제공한 제약 조건 내에 있는 경우 클러스터의 크기를 늘립니다. 새 노드 프로비저닝 시간은 CA가 아니라 클라우드 공급자 및 기타 Kubernetes 구성 요소에 따라 다릅니다.

따라서 CA에 대한 기본 SLO는 포드가 예약 불가능으로 표시된 시간(K8S 스케줄러에 의해)부터 CA가 클라우드 제공자에게 확장 요청을 발행하는 시간(발생한다고 가정)까지 측정된 대기 시간으로 표현됩니다. 확장성 테스트( 여기에 설명 됨) 동안 우리는 큰 클러스터에서도 최대 20초의 대기 시간을 목표로 했습니다. 테스트 사례의 GCE에서 이러한 목표를 달성했지만 실제로는 성능이 다를 수 있습니다. 따라서 사용자는 다음을 기대해야 합니다.

  • 작은 클러스터(각각 최대 30개의 포드가 있는 노드 100개 미만)에서 지연 시간은 30초 이하이며 평균 지연 시간은 약 5초입니다.
  • 큰 클러스터(노드 100~1000개)에서 지연 시간은 60초를 넘지 않으며 평균 지연 시간은 약 15초입니다.

위의 성능은 포드 선호도 및 반선호도가 포드에 사용되지 않는 경우에만 달성할 수 있습니다. 불행히도 스케줄러에서 선호도 술어의 현재 구현은 다른 모든 술어를 합친 것보다 약 3배 느리고 CA를 큰 클러스터에서 거의 사용할 수 없게 만듭니다.

더 큰 클러스터의 CA 포드에 대해 전체 1코어를 요청하거나 사용할 수 있도록 하는 것도 중요합니다. 과부하된 노드에 CA를 배치하면 선언된 성능에 도달할 수 없습니다.

노드 1000개보다 큰 클러스터에 대해서는 성능 테스트를 실행하지 않았으며 이를 지원하는 것이 1.0의 목표가 아니었습니다.

앞으로 더 많은 SLO가 정의될 ​​수 있습니다.

Horizontal Pod Autoscaler는 Cluster Autoscaler와 어떻게 작동합니까?

Horizontal Pod Autoscaler는 현재 CPU 부하를 기반으로 배포 또는 복제본 세트의 복제본 수를 변경합니다. 로드가 증가하면 HPA는 클러스터에 공간이 충분하거나 부족할 수 있는 새 복제본을 생성합니다. 

리소스가 충분하지 않은 경우 CA는 HPA 생성 포드가 실행할 장소가 있도록 일부 노드를 불러오려고 시도합니다. 

로드가 감소하면 HPA가 일부 복제본을 중지합니다. 결과적으로 일부 노드는 활용도가 낮거나 완전히 비어 있을 수 있으며 CA는 이러한 불필요한 노드를 종료합니다.

클러스터 자동 확장 처리를 실행하기 위한 주요 모범 사례는 무엇입니까?

  • 자동 크기 조정된 노드 그룹에 속한 노드를 직접 수정하지 마십시오. 동일한 노드 그룹 내의 모든 노드는 동일한 용량, 레이블 및 시스템 포드를 실행해야 합니다.
  • 포드에 대한 요청을 지정합니다.
  • PodDisruptionBudgets를 사용하여 Pod가 너무 갑자기 삭제되는 것을 방지합니다(필요한 경우).
  • 노드 풀에 대한 최소/최대 설정을 지정하기 전에 클라우드 제공자의 할당량이 충분히 큰지 확인하십시오.
  • 추가 노드 그룹 자동 크기 조정기(특히 클라우드 제공업체의 것)를 실행하지 마십시오.

Kubernetes에서 CPU 사용량 기반 노드 자동 확장 처리를 사용해야 하나요?

아니.

클러스터 자동 확장 처리는 CPU 사용량 기반 노드 자동 확장 처리와 어떻게 다릅니까?

Cluster Autoscaler는 CPU 부하 여부에 관계없이 클러스터의 모든 포드가 실행할 장소가 있는지 확인합니다. 또한 클러스터에 불필요한 노드가 없는지 확인합니다.

CPU 사용량 기반(또는 모든 메트릭 기반) 클러스터/노드 그룹 자동 확장 처리는 확장 및 축소할 때 포드를 신경 쓰지 않습니다. 결과적으로 포드가 없는 노드를 추가하거나 kube-dns와 같이 시스템에 중요한 포드가 있는 노드를 제거할 수 있습니다. Kubernetes와 함께 이러한 자동 확장 처리를 사용하는 것은 권장되지 않습니다.

클러스터 자동 확장 처리는 CPU 사용량 기반 노드 자동 확장 처리와 호환되나요?

아니요. GCE 인스턴스 그룹 자동 확장 처리와 같은 CPU 기반(또는 모든 측정항목 기반) 클러스터/노드 그룹 자동 확장 처리 는 CA와 호환되지 않습니다. 또한 일반적으로 Kubernetes와 함께 사용하는 데 특히 적합하지 않습니다.

Cluster Autoscaler는 Pod 우선 순위 및 선점과 어떻게 작동합니까?

버전 1.1(Kubernetes 1.9와 함께 제공됨)부터 CA는 포드 우선 순위를 고려합니다.

Pod 우선 순위 및 선점 기능을 사용하면 리소스가 충분하지 않은 경우 우선 순위에 따라 Pod를 예약할 수 있습니다. 반면 Cluster Autoscaler는 모든 포드를 실행하기에 충분한 리소스가 있는지 확인합니다. 사용자가 Cluster Autoscaler 작업을 트리거하지 않고 사용 가능한 여유 리소스가 있을 때만 실행되는 "best-effort" 포드를 예약할 수 있도록 Cluster Autoscaler에 우선 순위 컷오프를 도입했습니다.

이 컷오프보다 우선순위가 낮은 포드:

  • 확장을 트리거하지 마십시오. 확장을 실행하기 위해 새 노드가 추가되지 않습니다.
  • 축소를 방지하지 마십시오. 이러한 포드를 실행하는 노드는 종료될 수 있습니다.

우선순위가 컷오프보다 크거나 같은 팟(Pod)과 우선순위가 없는 팟(Pod)은 변경되지 않습니다.

기본 우선 순위 컷오프는 -10입니다(버전 1.12 이후, 그 이전에는 0이었습니다). 플래그를 사용하여 변경할 수 --expendable-pods-priority-cutoff있지만 권장하지 않습니다. 또한 예약할 수 없는 포드가 더 낮은 우선 순위의 포드 선점을 이미 기다리고 있는 경우 클러스터 자동 확장 처리는 확장을 트리거하지 않습니다.

이전 버전의 CA는 우선 순위를 고려하지 않습니다.

포드 우선 순위 및 선점에 대한 추가 정보:

클러스터 자동 확장 처리는 노드를 어떻게 제거합니까?

Cluster Autoscaler는 클라우드 공급자에 따라 기본 인스턴스를 종료합니다.

Kubernetes에서 노드 개체 를 삭제 하지 않습니다 . 종료된 인스턴스에 해당하는 노드 객체를 정리하는 것은 kube-controller-manager 또는 cloud-controller-manager 의 일부로 실행할 수 있는 클라우드 노드 컨트롤러 의 책임입니다 .

HA 목적으로 여러 영역에 노드가 있는 클러스터를 실행하고 있습니다. 

Cluster Autoscaler에서 지원합니까?

CA 0.6은 --balance-similar-node-groups이 사용 사례를 지원하기 위해 플래그를 도입했습니다. 플래그를 true로 설정하면 CA는 동일한 인스턴스 유형과 동일한 레이블 집합(자동으로 추가된 영역 레이블 제외)을 가진 노드 그룹을 자동으로 식별하고 해당 노드 그룹의 크기를 균형 있게 유지하려고 시도합니다.

이것은 유사한 노드 그룹이 정확히 동일한 크기를 가질 것이라고 보장하지 않습니다.

  • 현재 밸런싱은 확장 시에만 수행됩니다. Cluster Autoscaler는 기본 노드 그룹의 상대적 크기에 관계없이 활용도가 낮은 노드를 계속 축소합니다. 향후 스케일 다운 시 균형을 고려할 계획입니다.
  • Cluster Autoscaler는 모든 기존 포드를 실행하는 데 필요한 만큼만 노드를 추가합니다. 노드 수가 균형 노드 그룹의 수로 나눌 수 없는 경우 일부 그룹은 다른 그룹보다 1개 더 많은 노드를 얻습니다.
  • Cluster Autoscaler는 동일한 보류 중인 포드 집합을 지원할 수 있는 노드 그룹 간에만 균형을 유지합니다. 단일 노드 그룹으로만 이동할 수 있는 포드를 실행하는 경우(예: 영역 레이블의 nodeSelector로 인해) CA는 이 특정 노드 그룹에만 노드를 추가합니다.

노드 그룹에 사용자 지정 레이블을 지정하여 동일한 인스턴스 유형을 사용하는 다른 노드 그룹과 자동으로 밸런싱되지 않도록 옵트아웃할 수 있습니다.

클러스터 자동 확장 처리를 모니터링하려면 어떻게 해야 합니까?

Cluster Autoscaler는 메트릭 및 livenessProbe 엔드포인트를 제공합니다. 기본적으로 및 --address각각의 포트 8085(플래그로 구성 가능) 에서 사용할 수 있습니다 ./metrics/health-check

메트릭은 Prometheus 형식으로 제공되며 자세한 설명은 여기에서 볼 수 있습니다 .

Cluster Autoscaler의 모든 이벤트를 어떻게 볼 수 있습니까?

기본적으로 Cluster Autoscaler는 5분 이내에 발생하는 유사한 이벤트를 중복 제거합니다. 이는 예약되지 않은 포드가 너무 많은 경우와 같이 짧은 시간에 많은 유사한 이벤트가 트리거될 수 있는 확장성 성능을 개선하기 위해 수행됩니다.

디버깅을 위해 또는 이벤트의 확장성이 문제가 되지 않는 경우와 같은 일부 경우에는 Cluster Autoscaler에서 오는 모든 이벤트를 보고 싶을 수 있습니다. --record-duplicated-events이러한 시나리오에서는 명령줄 플래그 를 사용해야 합니다 .

클러스터를 1개의 노드로 확장하려면 어떻게 해야 합니까?

버전 0.6 이전에는 Cluster Autoscaler가 DNS, Metrics Server, Dashboard 등과 같은 중요한 kube-system 포드를 실행하는 노드를 건드리지 않았습니다. 이러한 포드가 다른 노드에 상륙하면 CA가 클러스터를 축소할 수 없고 사용자가 종료될 수 있습니다. 완전히 비어 있는 3노드 클러스터가 있습니다. 0.6에서는 일부 시스템 포드를 이동할 수 있음을 CA에 알리는 옵션을 추가했습니다. 사용자 가 kube-system 포드에 대해 PodDisruptionBudget 을 구성하면 이 포드를 실행하는 노드를 건드리지 않는 기본 전략이 PDB 설정으로 재정의됩니다. 따라서 kube-system 포드 마이그레이션을 활성화하려면 minAvailable 을 0(또는 N+1개의 포드 복제본이 있는 경우 <= N)으로 설정해야 합니다. 사용률이 낮은 두 개의 노드가 있지만 축소되지는 않습니다. 왜요?

노드 그룹을 0으로 확장하려면 어떻게 해야 합니까?

GCE/GKE용 CA 0.6 및 AWS용 CA 0.6.1부터 모든 축소 조건이 충족된다는 가정 하에 노드 그룹을 0(그리고 분명히 0에서)으로 확장할 수 있습니다.

AWS의 경우 를 사용 nodeSelector하는 경우 노드 템플릿 키로 ASG에 태그를 지정해야 합니다 "k8s.io/cluster-autoscaler/node-template/label/".

예를 들어 노드 레이블이 foo=bar인 경우 ASG에 다음 태그를 지정합니다.

{
    "ResourceType": "auto-scaling-group",
    "ResourceId": "foo.example.com",
    "PropagateAtLaunch": true,
    "Value": "bar",
    "Key": "k8s.io/cluster-autoscaler/node-template/label/foo"
}

클러스터 자동 확장 처리가 특정 노드를 축소하지 못하도록 하려면 어떻게 해야 합니까?

CA 1.0부터 노드에 축소를 방지하는 주석이 있는 경우 노드가 축소에서 제외됩니다.

"cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"

kubectl을 사용하여 노드에 추가(또는 제거)할 수 있습니다.

kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true

클러스터 자동 확장 처리가 비어 있지 않은 노드를 축소하지 못하도록 하려면 어떻게 해야 합니까?

CA는 사용률이 임계값( --scale-down-utilization-threshold플래그로 구성 가능) 미만으로 비어 있지 않은 노드를 축소할 수 있습니다.

이 동작을 방지하려면 사용 임계값을 로 설정하십시오 0.

Cluster Autoscaler로 오버프로비저닝을 구성하려면 어떻게 해야 합니까?

아래 솔루션은 버전 1.1(Kubernetes 1.9와 함께 제공됨)부터 작동합니다.

다른 포드에서 사용할 수 있는 리소스를 유지하는 할당된 우선 순위가 매우 낮은( 우선 순위 선점 참조) 일시 중지 포드를 실행하는 배포를 사용하여 오버프로비저닝을 구성할 수 있습니다. 리소스가 충분하지 않으면 일시 중지 포드가 선점되고 새 포드가 그 자리를 차지합니다. 다음 일시 중지 포드는 예약할 수 없게 되어 CA가 클러스터를 확장하도록 합니다.

오버프로비저닝된 리소스의 크기는 일시 중지 포드의 크기와 복제본 수를 변경하여 제어할 수 있습니다. 이 방법으로 오버프로비저닝 리소스(즉, 추가 코어 2개)의 정적 크기를 구성할 수 있습니다. 동적 크기(즉, 클러스터 리소스의 20%)를 구성하려면 클러스터 크기에 따라 일시 중지 포드 수를 변경하는 수평 클러스터 비례 자동 확장기 를 사용해야 합니다. 클러스터가 커지면 복제본 수를 늘리고 클러스터가 축소되면 복제본 수를 줄입니다.

동적 오버프로비저닝 구성:

  1. (1.10 이하의 경우) 클러스터에서 우선 순위 선점을 활성화합니다.

GCE의 경우 kube-up을 실행하기 전에 다음 env 변수를 내보내면 됩니다(자세한 내용은 여기 참조 ).

export KUBE_RUNTIME_CONFIG=scheduling.k8s.io/v1alpha1=true
export ENABLE_POD_PRIORITY=true

kops를 사용하는 AWS의 경우 이 문제 를 참조하십시오 .

  1. 포드 오버프로비저닝에 대한 우선 순위 클래스를 정의합니다. 우선 순위 -1은 클러스터 조정을 트리거하는 가장 낮은 우선 순위이므로 포드 오버프로비저닝을 위해 예약됩니다. 오버프로비저닝 포드를 선점하려면 다른 포드가 우선순위 0 이상을 사용해야 합니다. 다음 정의를 사용할 수 있습니다.

1.10 이하:

apiVersion: scheduling.k8s.io/v1alpha1
kind: PriorityClass
metadata:
  name: overprovisioning
value: -1
globalDefault: false
description: "Priority class used by overprovisioning."

1.11+의 경우:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: overprovisioning
value: -1
globalDefault: false
description: "Priority class used by overprovisioning."
  1. CA의 포드 우선 순위 컷오프를 -10으로 변경하여 축소 및 확장 중에 일시 중지 포드가 고려되도록 합니다. 플래그 expendable-pods-priority-cutoff를 -10으로 설정합니다. 이미 우선 순위 선점을 사용하는 경우 우선 순위가 -10에서 -1 사이인 포드는 더 이상 최선의 노력이 아닙니다.
  2. 특정 역할이 필요한 Horizontal Cluster Proportional Autoscaler에서 사용할 서비스 계정을 만듭니다. 자세한 내용은 여기
  3. 리소스를 예약할 배포를 만듭니다. "overprovisioning" 배포는 리소스를 예약하고 "overprovisioning-autoscaler" 배포는 예약된 리소스의 크기를 변경합니다. 다음 정의를 사용할 수 있습니다("overprovisioning-autoscaler" 배포를 위한 서비스 계정을 이전 단계에서 만든 계정으로 변경해야 함).
apiVersion: apps/v1
kind: Deployment
metadata:
  name: overprovisioning
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: overprovisioning
  template:
    metadata:
      labels:
        run: overprovisioning
    spec:
      priorityClassName: overprovisioning
      containers:
      - name: reserve-resources
        image: k8s.gcr.io/pause
        resources:
          requests:
            cpu: "200m"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: overprovisioning-autoscaler
  namespace: default
  labels:
    app: overprovisioning-autoscaler
spec:
  selector:
    matchLabels:
      app: overprovisioning-autoscaler
  replicas: 1
  template:
    metadata:
      labels:
        app: overprovisioning-autoscaler
    spec:
      containers:
        - image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.1.2
          name: autoscaler
          command:
            - ./cluster-proportional-autoscaler
            - --namespace=default
            - --configmap=overprovisioning-autoscaler
            - --default-params={"linear":{"coresPerReplica":1}}
            - --target=deployment/overprovisioning
            - --logtostderr=true
            - --v=2
      serviceAccountName: cluster-proportional-autoscaler-service-account

특정 DaemonSet에 대해 제거를 활성화/비활성화하려면 어떻게 해야 하나요?

클러스터 자동 확장 처리는 전체 클러스터에 공통적인 구성을 기반으로 DaemonSets를 제거합니다. 그러나 포드별로 원하는 동작을 지정할 수 있습니다. 다음 주석이 있는 경우 모든 DaemonSet 포드가 제거됩니다.

"cluster-autoscaler.kubernetes.io/enable-ds-eviction": "true"

DaemonSet 포드 제거를 명시적으로 비활성화할 수도 있습니다.

"cluster-autoscaler.kubernetes.io/enable-ds-eviction": "false"

이 주석은 DaemonSet 개체 자체가 아니라 DaemonSet 포드에 지정되어야 합니다. 모든 DaemonSet 포드에 대해 그렇게 하려면 DaemonSet 개체에서 포드 사양을 수정하는 것으로 충분합니다.

이 주석은 DaemonSet의 일부가 아닌 포드에는 영향을 주지 않습니다.

노드의 최대 볼륨 수가 초과될 때 클러스터 자동 확장 처리를 활성화하려면 어떻게 해야 합니까(CSI 마이그레이션 활성화됨)?

노드의 최대 볼륨 수가 초과되면 Kubernetes 스케줄러가 노드에 대한 포드를 예약하지 못합니다. 이러한 경우 CSI 마이그레이션 이 활성화된 Kubernetes 클러스터에서 Cluster Autoscaler가 확장되도록 하려면 Cluster Autoscaler에 대해 적절한 CSI 관련 기능 게이트를 지정해야 합니다(해당 기능 게이트가 기본적으로 활성화되어 있지 않은 경우).

예를 들어:

--feature-gates=CSIMigration=true,CSIMigration{Provdider}=true,InTreePlugin{Provider}Unregister=true

기능 게이트의 전체 목록과 Kubernetes 버전별 기본값은 Feature Gates 문서 를 참조하십시오 .

내부

언급된 모든 휴리스틱 및 타이밍이 최종적입니까?

아니요. 필요한 경우 향후 업데이트할 권리가 있습니다.

스케일 업은 어떻게 작동합니까?

Scale-up은 API 서버에서 모든 포드를 찾는 감시를 생성합니다. 10초마다 예약할 수 없는 포드가 있는지 확인합니다( --scan-interval플래그로 구성 가능). Kubernetes 스케줄러가 포드를 수용할 수 있는 노드를 찾을 수 없으면 포드를 예약할 수 없습니다. 예를 들어, 포드는 모든 클러스터 노드에서 사용 가능한 CPU를 더 요청할 수 있습니다. 예약할 수 없는 포드는 해당 PodCondition에서 인식됩니다. Kubernetes 스케줄러가 포드를 실행할 장소를 찾지 못할 때마다 "schedulable" PodCondition을 false로 설정하고 reason을 "unschedulable"로 설정합니다. 예약할 수 없는 포드 목록에 항목이 있는 경우 Cluster Autoscaler는 항목을 실행할 새 위치를 찾으려고 합니다.

기본 클러스터가 일종의 노드 그룹 위에서 실행된다고 가정합니다. 노드 그룹 내에서 모든 시스템은 용량이 동일하고 할당된 레이블 집합이 동일합니다. 따라서 노드 그룹의 크기를 늘리면 클러스터에 이미 있는 것과 유사한 새 머신이 생성됩니다. 사용자 생성 포드가 실행되지 않을 뿐입니다(그러나 노드 매니페스트 및 데몬 세트에서 모든 포드가 실행됩니다. .)

위의 가정에 따라 Cluster Autoscaler는 각 노드 그룹에 대한 템플릿 노드를 생성하고 예약할 수 없는 포드가 새 노드에 맞는지 확인합니다. 실제 스케줄러가 수행하는 것과 유사하게 들릴 수 있지만 현재는 상당히 단순화되었으며 모든 포드가 결국 예약되기 전에 여러 번 반복해야 할 수 있습니다. 증가하는 경우 일부 포드를 실행하는 데 도움이 되는 여러 노드 그룹이 있는 경우 증가할 노드 그룹을 선택하기 위해 다른 전략을 선택할 수 있습니다. 확장기가 무엇인지 확인하십시오 . 섹션을 참조하여 전략에 대해 자세히 알아보세요.

생성된 노드가 Kubernetes에 표시되기까지 다소 시간이 걸릴 수 있습니다. 거의 전적으로 클라우드 공급자와 TLS 부트스트래핑 프로세스 를 포함한 노드 프로비저닝 속도에 따라 다릅니다 . Cluster Autoscaler는 요청된 노드가 15분 이내에 나타날 것으로 예상합니다( --max-node-provision-time플래그로 구성됨). 이 시간이 지난 후에도 여전히 등록되지 않은 경우 시뮬레이션에서 고려를 중지하고 포드가 여전히 보류 중인 경우 다른 그룹의 확장을 시도할 수 있습니다. 또한 이 시간 이후에 등록되지 않은 상태로 남아 있는 모든 노드를 제거하려고 시도합니다.

참고: Cluster Autoscaler는 생성하는 새 노드의 클러스터에 대한 동작 및 등록에 대해 책임을 지지 않습니다 . 
새 노드를 클러스터에 등록하는 책임은 사용하는 클러스터 프로비저닝 도구에 있습니다. 예: kubeadm을 사용하여 클러스터를 프로비저닝하는 경우 kubeadm join부팅 시 일부 스크립트를 통해 자동으로 실행하는 것은
사용자에게 달려 있습니다.

축소는 어떻게 작동합니까?

10초마다( --scan-interval플래그로 구성 가능) 확장이 필요하지 않은 경우 클러스터 자동 확장 처리는 필요하지 않은 노드를 확인합니다. 아래의 모든 조건이 충족 되면 노드는 제거 대상으로 간주됩니다 .

  • 이 노드에서 실행되는 모든 포드의 CPU 및 메모리 요청 합계(DaemonSet 포드 및 미러 포드는 기본적으로 포함되지만 이는 --ignore-daemonsets-utilization및 --ignore-mirror-pods-utilization플래그로 구성 가능)는 노드 할당 가능의 50%보다 작습니다. (1.1.0 이전에는 할당 가능한 대신 노드 용량을 사용했습니다.) 사용 임계값은 --scale-down-utilization-threshold플래그를 사용하여 구성할 수 있습니다.
  •  
  • 노드에서 실행되는 모든 포드(매니페스트 실행 포드 또는 데몬셋에 의해 생성된 포드와 같이 기본적으로 모든 노드에서 실행되는 포드 제외)는 다른 노드로 이동할 수 있습니다. CA가 노드를 제거하지 못하도록 할 수 있는 포드 유형은 무엇입니까?를 참조하세요 . 다른 곳에 공간이 있더라도 이 조건을 충족하지 못하는 포드에 대한 자세한 내용은 섹션을 참조하세요. 이 상태를 확인하는 동안 모든 이동 가능한 포드의 새 위치가 기억됩니다. 이를 통해 Cluster Autoscaler는 각 포드를 이동할 수 있는 위치와 포드 마이그레이션 측면에서 어떤 노드가 다른 노드에 의존하는지 알고 있습니다. 물론, 결국 스케줄러가 포드를 다른 곳에 배치할 수도 있습니다.
  •  
  • 축소 비활성화 주석이 없습니다( Cluster Autoscaler가 특정 노드를 축소하지 못하도록 하려면 어떻게 해야 합니까? 참조) .

노드가 10분 이상 필요하지 않을 경우 종료됩니다. (이 시간은 플래그로 구성할 수 있습니다. 사용률이 낮은 두 개의 노드가 있지만 축소되지 않은 노드를 참조하십시오. 자세한 설명은 왜? 섹션을 참조하십시오.) Cluster Autoscaler는 한 번에 하나의 비어 있지 않은 노드를 종료하여 다음을 수행합니다. 예약할 수 없는 새로운 포드를 생성할 위험을 줄입니다. 다음 노드는 10분 이상 필요하지 않고 시뮬레이션에서 동일한 노드에 의존하지 않았지만(아래 예제 시나리오 참조) 첫 번째 노드 직후에 종료될 수 있지만 함께는 아닙니다. 반면에 빈 노드는 한 번에 최대 10개 노드까지 일괄 종료할 수 있습니다( --max-empty-bulk-delete플래그로 구성 가능).

비어 있지 않은 노드가 종료되면 어떻게 됩니까? 위에서 언급했듯이 모든 포드는 다른 곳으로 마이그레이션해야 합니다. 클러스터 자동 확장 처리는 노드를 제거하고 노드를 오염시켜 이를 수행하므로 다시 예약되지 않습니다.

DaemonSet 포드도 제거될 수 있습니다. --daemonset-eviction-for-empty-nodes이것은 각각 및 --daemonset-eviction-for-occupied-nodes플래그 가 있는 비어 있지 않은 노드(예: DaemonSet 포드만 포함) 및 비어 있지 않은 노드에 대해 별도로 구성할 수 있습니다 . 기본 동작은 플래그마다 다릅니다. 기본적으로 DaemonSet 포드 축출은 점유된 노드에서만 발생합니다. 개별 DaemonSet 포드는 축출 여부를 명시적으로 선택할 수도 있습니다. 자세한 내용 은 특정 DaemonSet 에 대해 제거를 활성화/비활성화하는 방법을 참조하십시오.

예시 시나리오:

노드 A, B, C, X, Y. A, B, C가 사용 임계값 미만입니다. 시뮬레이션에서 A의 포드는 X에, B의 포드는 X에, C의 포드는 Y에 맞습니다.

노드 A가 종료되었습니다. 알겠습니다. 하지만 삭제 대상이었던 B와 C는 어떻습니까? 글쎄, 그것은 달려있다.

A의 포드를 X로 이동한 후 B의 포드가 더 이상 X에 맞지 않을 수 있습니다. Cluster Autoscaler는 다른 곳에서 자리를 찾아야 하며 A가 B보다 훨씬 일찍 종료되었다면 항상 자리가 있었을지 확실하지 않습니다. 따라서 10분 동안 필요하지 않았다는 조건은 B에게 더 이상 사실이 아닐 수도 있습니다.

그러나 노드 C의 경우 Y에 아무 일도 일어나지 않는 한 여전히 사실입니다. 따라서 C는 A 직후에 종료될 수 있지만 B는 그렇지 않을 수 있습니다.

Cluster Autoscaler는 시뮬레이션과 기억된 새 포드 위치를 기반으로 이 모든 계산을 수행합니다. 그것들이 항상 정확하지는 않을 수도 있지만(포드는 결국 다른 곳에서 예약될 수 있음), 지금까지는 좋은 경험적 방법인 것 같습니다.

CA는 축소 시 PodDisruptionBudget과 함께 작동합니까?

0.5 CA(K8S 1.6)부터 PDB를 존중합니다. 노드 종료를 시작하기 전에 CA는 거기에 예약된 포드에 대한 PodDisruptionBudgets에서 최소 하나의 복제본 제거를 허용하는지 확인합니다. 그런 다음 포드 제거 API를 통해 노드에서 모든 포드를 삭제하고 필요한 경우 최대 2분 동안 재시도합니다. 그 시간 동안 다른 CA 활동이 중지됩니다. 축출 중 하나가 실패하면 노드가 저장되고 종료되지 않지만 가까운 장래에 또 다른 종료 시도가 수행될 수 있습니다.

CA는 축소 시 GracefulTermination을 존중합니까?

버전 1.0의 CA는 기본적으로 포드에 최대 10분의 정상적인 종료 시간을 제공합니다( 를 통해 구성 가능 --max-graceful-termination-sec). 포드가 이 10분 이내에 중지되지 않으면 노드는 어쨌든 종료됩니다. 이전 버전의 CA는 1분을 제공하거나 정상적인 종료를 전혀 존중하지 않았습니다.

CA는 준비되지 않은 노드를 어떻게 처리합니까?

0.5부터 CA(K8S 1.6)는 일부 노드를 사용할 수 없는 경우에도 계속 작동합니다. CA 1.2.1 또는 이전 버전에서 허용되는 준비되지 않은 노드의 기본 수는 클러스터에 있는 총 노드의 33% 또는 최대 3개 노드 중 더 높은 값입니다. CA 1.2.2 이상의 경우 45% 또는 3개의 노드입니다. 이것은 --max-total-unready-percentage및 --ok-total-unready-count플래그로 구성할 수 있습니다. 클러스터에 준비되지 않은 노드가 더 있으면 CA는 상황이 개선될 때까지 모든 작업을 중지합니다. 준비되지 않은 노드가 더 적지만 특정 노드 그룹에 집중되어 있는 경우 이 노드 그룹은 향후 확장에서 제외될 수 있습니다.

클러스터 자동 확장 처리는 얼마나 빠릅니까?

기본적으로 확장은 Pod가 예약 불가능으로 표시된 후 최대 10초로 간주되고 노드가 필요하지 않은 상태가 된 후 10분이 지나면 축소가 간주됩니다. 이러한 임계값을 구성하는 데 사용할 수 있는 여러 플래그가 있습니다. 예를 들어, 일부 환경에서는 k8s 스케줄러에 CA의 스캔 간격보다 포드를 예약할 시간을 조금 더 주기를 원할 수 있습니다. 이를 수행하는 한 가지 방법은 를 설정 --new-pod-scale-up-delay하는 것입니다. 이렇게 하면 스캔 간격에 관계없이 CA가 특정 "연령"이 될 때까지 예약할 수 없는 포드를 무시합니다. k8이 해당 지연이 끝날 때까지 일정을 잡지 않은 경우 CA에서 가능한 확장을 고려할 수 있습니다.

기본 설정을 가정하면 여기에 설명된 SLO가 적용됩니다 .

CA와 결합할 때 HPA는 얼마나 빠릅니까?

HPA가 CA와 결합되면 로드 증가에서 새로운 포드 실행까지의 총 시간은 세 가지 주요 요인에 의해 결정됩니다.

  • HPA 반응 시간,
  • CA 반응 시간,
  • 노드 프로비저닝 시간.

기본적으로 파드의 CPU 사용량은 kubelet에서 10초마다 스크랩하고 1분마다 Metrics Server에서 kubelet에서 가져옵니다. HPA는 30초마다 Metrics Server에서 CPU 로드 메트릭을 확인합니다. 그러나 복제본 수를 변경한 후 HPA는 추가 조치를 취하기 전에 3분 동안 백오프합니다. 따라서 포드가 추가되거나 삭제되기까지 최대 3분이 소요될 수 있지만 일반적으로 1분에 가깝습니다.

CA 는 HPA 또는 복제본 수를 수정한 사용자에 관계없이 여기에 설명된 대로 빠르게 반응해야 합니다. 확장의 경우 대부분의 경우 30초 미만이 될 것으로 예상합니다.

노드 프로비저닝 시간은 대부분 클라우드 제공업체에 따라 다릅니다. 경험상 GCE에서는 CA 요청에서 새로 생성된 노드에서 포드를 예약할 수 있을 때까지 일반적으로 3~4분이 걸립니다.

총 시간은 이러한 단계의 합계이며 일반적으로 약 5분입니다. 여기서 CA는 가장 덜 중요한 요소입니다.

반면에 스케일 다운의 경우 CA는 노드를 즉시 제거하려고 시도하지 않고 특정 시간 동안 필요하지 않은 후에만 제거를 시도하기 때문에 일반적으로 가장 중요한 요소입니다.

다가오는 기능의 디자인은 어디에서 찾을 수 있습니까?

CA 팀은 일반적인 Kubernetes 프로세스를 따르고 중요한 작업을 시작하기 전에 여기 에 설계 제안을 제출합니다 . 아직 완전히 승인되지 않은 제안 중 일부는 PR 에 숨겨져 있을 수 있습니다 .

익스팬더란?

Cluster Autoscaler는 예약할 수 없는 포드로 인해 클러스터를 확장해야 함을 식별하면 일부 노드 그룹의 노드 수를 늘립니다. 노드 그룹이 하나인 경우 이 전략은 간단합니다. 노드 그룹이 두 개 이상인 경우 확장할 노드 그룹을 결정해야 합니다.

확장기는 새 노드가 추가될 노드 그룹을 선택하기 위한 다양한 전략을 제공합니다.

--expander확장기는 플래그에 이름을 전달하여 선택할 수 있습니다 ./cluster-autoscaler --expander=random.

현재 Cluster Autoscaler에는 5개의 확장기가 있습니다.

  • random- 이것은 기본 확장기이며 노드 그룹을 다르게 확장할 특별한 필요가 없을 때 사용해야 합니다.
  • most-pods- 확장 시 가장 많은 포드를 예약할 수 있는 노드 그룹을 선택합니다. 이는 nodeSelector를 사용하여 특정 포드가 특정 노드에 놓이도록 할 때 유용합니다. 한 번에 여러 개의 작은 노드를 추가할 수 있으므로 이렇게 하면 자동 확장 처리가 더 큰 노드와 더 작은 노드를 선택하지 않습니다.
  • least-waste- 확장 후 유휴 CPU(동일한 경우 사용하지 않는 메모리)가 가장 적은 노드 그룹을 선택합니다. 이는 높은 CPU 또는 높은 메모리 노드와 같이 다양한 클래스의 노드가 있고 이러한 리소스가 많이 필요한 보류 중인 포드가 있는 경우에만 해당 노드를 확장하려는 경우에 유용합니다.
  • price- 비용이 가장 적게 드는 노드 그룹을 선택하고 동시에 해당 시스템이 클러스터 크기와 일치할 노드 그룹을 선택합니다. 이 확장기는 여기 에서 자세히 설명 합니다. 현재 GCE, GKE 및 Equinix Metal에서만 작동합니다(패치 환영).
  • priority- 사용자가 할당한 우선 순위가 가장 높은 노드 그룹을 선택합니다. 구성은 여기 에 자세히 설명되어 있습니다.

1.23.0부터 여러 확장자가 전달될 수 있습니다. .cluster-autoscaler --expander=priority,least-waste

이렇게 하면 least-waste우선 순위 확장기가 여러 노드 그룹을 선택하는 경우 확장기가 폴백으로 사용됩니다. 일반적으로 확장기 목록을 사용할 수 있으며, 여기서 하나의 출력은 다음으로 전달되고 무작위로 하나를 선택하여 최종 결정이 결정됩니다. 확장기는 목록에 두 번 이상 나타나지 않아야 합니다.

CA는 확장할 노드 그룹을 선택할 때 노드 선호도를 존중합니까?

CA 는 노드 그룹에 적절하게 레이블을 지정한 경우 nodeAffinity를 nodeSelector존중 합니다. 둘 중 하나로 예약 하거나 지정할 requiredDuringSchedulingIgnoredDuringExecution수 없는 포드가 있는 경우 CA는 확장 요구 사항을 충족하는 노드 그룹만 고려합니다.nodeSelectorrequiredDuringSchedulingIgnoredDuringExecution

preferredDuringSchedulingIgnoredDuringExecution그러나 CA는 노드 그룹을 선택할 때 와 같은 "소프트" 제약 조건을 고려하지 않습니다 . 즉, CA에 확장에 사용할 수 있는 노드 그룹이 두 개 이상 있는 경우 소프트 제약 조건을 사용하여 다른 노드 그룹보다 한 노드 그룹을 선택하지 않습니다.

CA에 대한 매개변수는 무엇입니까?

클러스터 자동 확장 처리에는 다음 시작 매개변수가 지원됩니다.

매개변수설명기본

cluster-name 자동 확장된 클러스터 이름(사용 가능한 경우) ""
address 프로메테우스 메트릭을 노출할 주소 :8085
kubernetes Kubernetes API 서버 위치. 기본값의 경우 비워 둡니다. ""
kubeconfig 권한 부여 및 API 서버 위치 정보가 있는 kubeconfig 파일 경로 ""
cloud-config 클라우드 공급자 구성 파일의 경로입니다. 구성 파일이 없는 빈 문자열 ""
namespace 클러스터 자동 확장 처리가 실행되는 네임스페이스 "쿠베 시스템"
scale-down-enabled CA가 클러스터를 축소해야 합니까? 진실
scale-down-delay-after-add 규모 확대 후 축소 평가가 재개되는 기간 10 분
scale-down-delay-after-delete 평가를 축소하는 노드 삭제 후 시간이 기본적으로 스캔 간격으로 다시 시작됩니다. 스캔 간격
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
이전 반복의 일부 후보가 더 이상 유효하지 않을 때 축소를 위해 비어 있지 않은 추가 후보로 간주되는 노드의 최소 수입니다 .
추가 후보자의 풀 크기를 계산할 때
max(#nodes * scale-down-candidates-pool-ratio, scale-down-candidates-pool-min-count)		 50
scan-interval 확장 또는 축소를 위해 클러스터를 재평가하는 빈도 10 초
max-nodes-total 모든 노드 그룹의 최대 노드 수입니다. 클러스터 자동 확장 처리는 클러스터를 이 수 이상으로 확장하지 않습니다. 0
cores-total 클러스터의 최소 및 최대 코어 수(형식:. 클러스터 자동 확장 처리는 클러스터를 이 숫자 이상으로 확장하지 않습니다. 320000
memory-total <min>:<max> 형식의 클러스터에 있는 최소 및 최대 메모리 기가바이트 수입니다. 클러스터 자동 확장 처리는 클러스터를 이 숫자 이상으로 확장하지 않습니다. 6400000
gpu-total 클러스터에 있는 서로 다른 GPU의 최소 및 최대 수(<gpu_type>:<min>:<max> 형식). 클러스터 자동 확장 처리는 클러스터를 이 숫자 이상으로 확장하지 않습니다. 여러 번 통과할 수 있습니다. 현재 이 플래그는 GKE에서만 작동합니다. ""
cloud-provider 클라우드 제공자 유형. gce
max-empty-bulk-delete 동시에 삭제할 수 있는 최대 빈 노드 수입니다. 10
max-graceful-termination-sec 노드 축소를 시도할 때 CA가 포드 종료를 기다리는 최대 시간(초)입니다. 600
max-total-unready-percentage 클러스터에서 준비되지 않은 노드의 최대 백분율입니다. 이를 초과하면 CA가 작업을 중지합니다. 45
ok-total-unready-count max-total-unready-percentage에 관계없이 허용된 준비되지 않은 노드 수 삼
max-node-provision-time CA가 노드가 프로비저닝되기를 기다리는 최대 시간 15 분
nodes 클라우드 공급자가 허용하는 형식으로 노드 그룹에 대한 최소, 최대 크기 및 기타 구성 데이터를 설정합니다. 여러 번 사용할 수 있습니다. 형식: <최소>:<최대>:<기타...> ""
node-group-auto-discovery 노드 그룹 자동 검색에 대한 하나 이상의 정의입니다. , 및
클라우드 공급자가 현재 지원됩니다 <name of discoverer>:[<key>[=<value>]]
. AWS는 ASG 태그로 일치(예: GCE는 IG 이름 접두사로 일치)하고 IG당 최소 및 최대 노드를 지정해야 합니다(예: Azure는 VMSS의 태그로 일치 ) . . 여러 번 사용할 수 있습니다awsgceazureasg:tag=tagKey,anotherTagKey
mig:namePrefix=pfx,min=0,max=10
label:foo=barminmax		 ""
emit-per-nodegroup-metrics true인 경우 노드 그룹별 지표를 내보냅니다. 거짓
estimator 확장에 사용할 리소스 추정기 유형 빈 포장
expander 확장에 사용할 노드 그룹 확장기의 유형입니다. 무작위의
ignore-daemonsets-utilization 축소를 위한 리소스 사용률을 계산할 때 DaemonSet 포드를 무시할지 여부 거짓
ignore-mirror-pods-utilization 축소를 위한 리소스 사용률을 계산할 때 미러 포드를 무시할지 여부 거짓
write-status-configmap CA가 configmap에 상태 정보를 기록해야 합니까? 진실
status-config-map-name CA가 작성하는 상태 ConfigMap의 이름 클러스터 자동 크기 조정기 상태
max-inactivity 자동 다시 시작하기 전에 마지막으로 기록된 자동 크기 조정기 활동에서 최대 시간 10 분
max-failing-time 자동 다시 시작하기 전에 마지막으로 기록된 성공적인 자동 크기 조정 실행 이후의 최대 시간 15 분
balance-similar-node-groups 유사한 노드 그룹을 감지하고 그들 사이의 노드 수 균형 거짓
balancing-ignore-label 노드 그룹 유사성을 고려할 때 무시해야 하는 노드 레이블을 정의합니다. 플래그 발생당 하나의 레이블입니다. ""
node-autoprovisioning-enabled CA는 필요할 때 노드 그룹을 자동 프로비저닝해야 합니다. 거짓
max-autoprovisioned-node-group-count 클러스터의 최대 자동 프로비저닝된 그룹 수 15
unremovable-node-recheck-timeout 이전에 제거할 수 없었던 노드를 다시 확인하기 전의 시간 초과 5 분
expendable-pods-priority-cutoff 컷오프보다 우선 순위가 낮은 포드는 소모품입니다. 스케일 다운 시 아무런 고려 없이 죽일 수 있으며 스케일 업을 일으키지 않습니다. null 우선 순위(PodPriority 비활성화됨)가 있는 포드는 소모할 수 없습니다. -10
regional 클러스터가 지역적임 거짓
leader-elect 메인 루프를 실행하기 전에 리더 선출 클라이언트를 시작하고 리더십을 얻으십시오.
고가용성을 위해 복제된 구성 요소를 실행할 때 활성화		 진실
leader-elect-lease-duration 리더가 아닌 후보자가 리더십
갱신을 관찰한 후 주도되지만 갱신되지 않은 리더 슬롯의 리더십을 획득하려고 시도할 때까지 기다리는 기간입니다.
이것은 사실상 리더가 다른 후보로 교체되기 전에 중지될 수 있는 최대 기간입니다.
리더 선택이 활성화된 경우에만 적용됩니다.		 15초
leader-elect-renew-deadline 선행을 중지하기 전에 활성 클러스터 자동 크기 조정기가 리더십 슬롯을 갱신하려는 시도 사이의 간격입니다.
임대 기간보다 작거나 같아야 합니다.
리더 선택이 활성화된 경우에만 적용됩니다.		 10 초
leader-elect-retry-period 내담자가 리더십 획득 시도와 갱신 사이에 기다려야 하는 기간.
리더 선택이 활성화된 경우에만 적용됩니다.		 2초
leader-elect-resource-lock 리더 선택 중 잠금에 사용되는 리소스 개체 유형입니다.
지원되는 옵션은 leases(기본값), endpoints, endpointsleases, configmaps및configmapsleases		 "임대"
aws-use-static-instance-list CA가 런타임에 인스턴스 유형을 가져오거나 정적 목록을 사용해야 합니다. AWS만 거짓
skip-nodes-with-system-pods 진정한 클러스터 자동 확장 처리가 kube-system에서 포드가 있는 노드를 삭제하지 않는 경우(DaemonSet 또는 미러 포드 제외) 진실
skip-nodes-with-local-storage 진정한 클러스터 자동 확장 처리가 EmptyDir 또는 HostPath와 같은 로컬 저장소가 있는 포드가 있는 노드를 삭제하지 않는 경우 진실
min-replica-count 복제본 세트 또는 복제 컨트롤러가 축소 시 포드 삭제를 허용해야 하는 최소 복제본 수 0
daemonset-eviction-for-empty-nodes DaemonSet 포드가 빈 노드에서 정상적으로 종료되는지 여부 거짓
daemonset-eviction-for-occupied-nodes DaemonSet 포드가 비어 있지 않은 노드에서 정상적으로 종료되는지 여부 진실
feature-gates 알파/실험 기능에 대한 기능 게이트를 설명하는 키=값 쌍의 집합입니다. ""
cordon-node-before-terminating CA는 축소 프로세스 중에 종료하기 전에 노드를 차단해야 합니다. 거짓
record-duplicated-events 자동 확장 처리를 사용하여 5분 창 내에 중복된 이벤트를 인쇄합니다. 거짓

문제 해결:

사용률이 낮은 노드가 몇 개 있지만 축소되지 않습니다. 왜요?

CA는 제거 해서는 안 되는 포드를 실행 중인 경우 활용도가 낮은 노드를 제거하지 않습니다 . 축소하지 않는 다른 가능한 이유:

  • 노드 그룹에는 이미 최소 크기가 있습니다.
  • 노드에 축소 비활성화 주석이 있습니다( Cluster Autoscaler가 특정 노드를 축소하지 못하도록 하려면 어떻게 해야 합니까? 참조) .
  • 노드가 10분 미만 동안 필요하지 않은 경우( --scale-down-unneeded-time플래그로 구성 가능)
  • 지난 10분 동안 확장이 있었습니다( --scale-down-delay-after-add플래그로 구성 가능).
  • 지난 3분 동안 이 그룹에 대한 축소가 실패했습니다( --scale-down-delay-after-failure플래그로 구성 가능).
  • 이 특정 노드를 제거하려는 시도가 실패했습니다. 이 경우 Cluster Autoscaler는 제거를 다시 고려하기 전에 추가로 5분을 기다립니다.
  • --scale-down-delay-after-delete또는 에 대해 큰 사용자 지정 값을 사용하여 --scan-intervalCA 작업을 지연시킵니다.
  • --scale-down-enabled명령의 매개변수가 false로 설정되지 않았 는지 확인하십시오 .

CA가 kube 시스템 포드를 이동할 수 있도록 PDB를 설정하는 방법은 무엇입니까?

기본적으로 kube-system 포드는 CA가 실행 중인 노드를 제거하지 못하도록 합니다. 사용자는 다른 곳에서 안전하게 일정을 변경할 수 있는 kube-system 포드용 PDB를 수동으로 추가할 수 있습니다.

kubectl create poddisruptionbudget <pdb name> --namespace=kube-system --selector app=<app name> --max-unavailable 1

다음은 몇 가지 일반적인 포드에 대해 수행하는 방법입니다.

  • kube-dns는 이러한 포드가 2개 이상 있어야 하는 한 안전하게 일정을 변경할 수 있습니다. 1.7에서는 항상 그렇습니다. 1.6 및 이전 버전의 경우 여기 에 설명된 대로 kube-dns-autoscaler 구성 맵을 편집 하고 preventSinglePointFailure 매개변수를 추가합니다. 예를 들어:
linear:'{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true}'
  • Metrics Server는 다시 시작하면 1분 이상 동안의 메트릭과 지난 15분 동안 대시보드의 메트릭이 손실되므로 그대로 두는 것이 가장 좋습니다. Metrics Server 다운타임은 또한 메트릭에 의존하기 때문에 효과적인 HPA 다운타임을 의미합니다. 상관없다고 확신하는 경우에만 PDB를 추가하십시오.

보류 중인 포드가 몇 개 있지만 확장이 없었습니까?

CA는 포드를 예약 가능하게 만들지 않는 경우 클러스터에 노드를 추가하지 않습니다. 구성된 노드 그룹에만 노드를 추가하는 것을 고려합니다. 따라서 클러스터를 확장하지 않는 이유 중 하나는 포드가 너무 크거나(예: CPU 100개) 너무 구체적인 요청(예: 노드 선택기)이 있고 사용 가능한 노드 유형에 맞지 않기 때문일 수 있습니다. 또 다른 가능한 이유는 적합한 모든 노드 그룹이 이미 최대 크기에 있기 때문입니다.

보류 중인 포드가 상태 저장 집합 에 있고 클러스터가 여러 영역에 걸쳐 있는 경우 CA는 아직 모든 영역의 확장 상한에 도달하지 않았더라도 클러스터를 확장하지 못할 수 있습니다. Stateful 세트 포드에는 포드를 예약하기 전에 생성되는 연결된 PV(Persistent Volume)가 필요하며 CA는 영역 선택에 영향을 줄 방법이 없습니다. 보류 중인 포드에는 PV가 있는 동일한 영역에서 예약해야 하는 엄격한 제약이 있으므로 이미 확장 상한에 도달한 영역인 경우 CA는 확장을 수행할 수 없습니다. 노드를 추가할 수 있는 다른 영역입니다. 이것은 포드에서 다음 이벤트에 의해 나타납니다.

Events:
  Type     Reason             Age   From                Message
  ----     ------             ----  -------             -------
  Normal   NotTriggerScaleUp  ..    cluster-autoscaler  pod didn't trigger scale-up (it wouldn't fit if a new node is added)
  Warning  FailedScheduling   ..    default-scheduler   No nodes are available that match all of the following predicates:: Insufficient cpu (4), NoVolumeZoneConflict (2)

이 제한은 Kubernetes 1.11에서 베타로 도입되고 1.13에서 GA로 계획된 볼륨 토폴로지 스케줄링 으로 해결되었습니다. CA가 토폴로지 스케줄링을 활용할 수 있도록 하려면 영역별로 별도의 노드 그룹을 사용하십시오. 이러한 방식으로 CA는 다중 영역 노드 그룹에서 새 노드에 대한 영역을 선택하는 클라우드 공급자에 의존하지 않고 필요한 영역에 노드를 생성할 노드 그룹을 정확히 알고 있습니다. 영역별로 별도의 노드 그룹을 사용하는 경우 --balance-similar-node-groups플래그는 토폴로지 스케줄링이 필요하지 않은 워크로드에 대해 영역 간에 노드의 균형을 유지합니다.

CA는 작동하지 않지만 어제 작동했습니다. 

대부분 클러스터 문제로 인한 것입니다. 디버그 단계:

  • 클러스터 자동 확장 처리가 실행 중인지 확인합니다. 버전 0.5 이상에서는 주기적으로 kube-system/cluster-autoscaler-status 구성 맵을 게시합니다. 마지막 업데이트 시간 주석을 확인하십시오. 3분(보통 10초 경과)을 넘지 않아야 합니다.
  • 클러스터 및 노드 그룹이 정상 상태인지 위의 구성 맵에서 확인하십시오. 그렇지 않은 경우 준비되지 않은 노드가 있는지 확인합니다. Node 개체에서 Ready 상태임에도 불구하고 일부 노드가 준비되지 않은 것으로 나타나면 resourceUnready개수를 확인합니다. 로 표시된 노드가 있는 resourceUnready경우 장치 드라이버가 새 리소스(예: GPU)를 설치하지 못하는 문제일 가능성이 큽니다. resourceUnreadycount는 CA 버전 1.24 이상에서만 사용할 수 있습니다.

클러스터와 CA가 모두 정상인 경우:

  • 일부 노드가 종료될 것으로 예상되지만 오랫동안 종료되지 않은 경우 사용률이 낮은 노드가 몇 개 있지만 축소되지 않았는지 확인합니다. 왜요? 부분.
  • 보류 중인 포드를 위한 공간을 만들기 위해 일부 노드가 추가될 것으로 예상되지만 오랫동안 추가되지 않은 경우 보류 중인 몇 개의 포드가 있지만 확장이 없었는지 확인하십시오. 부분.
  • 컨트롤 플레인(이전에는 마스터라고 함) 시스템에 액세스할 수 있는 경우 클러스터 자동 확장 처리 로그인 을 확인하십시오 /var/log/cluster-autoscaler.log. Cluster Autoscaler는 포드를 제거할 수 없는 것으로 간주하는 이유 또는 확장 계획을 포함하여 많은 유용한 정보를 기록합니다.
  • CA에서 Pod 개체에 추가한 이벤트를 확인합니다.
  • kube-system/cluster-autoscaler-status 구성 맵에서 이벤트를 확인하십시오.
  • 노드 추가 시도가 실패한 경우 클라우드 공급자 측 할당량이 충분한지 확인하십시오. VM이 생성되었지만 노드가 등록되지 않으면 네트워킹 문제의 증상일 수 있습니다.

CA에서 무슨 일이 일어나고 있는지 어떻게 확인할 수 있습니까?

세 가지 옵션이 있습니다.

  • 의 컨트롤 플레인(이전에는 마스터라고 함) 노드에 기록 /var/log/cluster-autoscaler.log합니다.
  • Cluster Autoscaler 0.5 이상은 kube-system/cluster-autoscaler-status 구성 맵을 게시합니다. 그것을 보려면 실행하십시오 kubectl get configmap cluster-autoscaler-status -n kube-system -o yaml.
  • 이벤트:
    • 포드(특히 예약할 수 없는 노드 또는 활용도가 낮은 노드),
    • 노드에서,
    • kube-system/cluster-autoscaler-status 구성 맵에 있습니다.

CA에서 어떤 이벤트를 내보내나요?

클러스터 자동 확장 처리가 노드를 추가하거나 제거할 때마다 이 작업을 설명하는 이벤트가 생성됩니다. 또한 일부 심각한 오류에 대한 이벤트를 생성합니다. 다음은 CA에서 발생하는 이벤트의 전체 목록이 아닙니다(향후 새 이벤트가 추가될 수 있음).

  • kube-system/cluster-autoscaler-status 구성 맵에서:
    • ScaledUpGroup - CA는 노드 그룹의 크기를 늘렸고 이전 그룹과 새 그룹 크기를 모두 제공합니다.
    • ScaleDownEmpty - CA가 실행 중인 포드가 없는 노드를 제거했습니다(모든 노드에서 발견된 시스템 포드 제외).
    • ScaleDown - CA는 일부 포드가 실행 중인 노드를 제거하기로 결정했습니다. 이벤트에는 노드를 드레이닝하도록 다시 예약될 모든 포드의 이름이 포함됩니다.
  • 노드에서:
    • ScaleDown - CA가 노드를 축소하고 있습니다. 축소 작업의 상태를 설명하는 여러 ScaleDown 이벤트가 노드에 기록될 수 있습니다.
    • ScaleDownFailed - CA가 노드를 제거하려고 했지만 실패했습니다. 이벤트에 오류 메시지가 포함됩니다.
  • 포드:
    • TriggeredScaleUp - CA는 이 포드를 위해 클러스터를 확장하기로 결정했습니다.
    • NotTriggerScaleUp - CA가 이 포드를 예약 가능하도록 확장할 수 있는 노드 그룹을 찾을 수 없습니다.
    • ScaleDown - CA는 노드 드레이닝의 일부로 이 포드를 축출하려고 합니다.

이벤트 예:

$ kubectl describe pods memory-reservation-73rl0 --namespace e2e-tests-autoscaling-kncnx
Name:   memory-reservation-73rl0

...

Events:
  FirstSeen	LastSeen	Count	From			SubObjectPath	Type		Reason			Message
  ---------	--------	-----	----			-------------	--------	------			-------
  1m		1m		1	cluster-autoscaler			Normal		TriggeredScaleUp	pod triggered scale-up, group: https://content.googleapis.com/compute/v1/projects/maciekpytel-dev-playground/zones/us-central1-b/instanceGroups/e2e-test-maciekpytel-minion-group, sizes (current/new): 3/4

내 클러스터가 최소/최대 노드 수 이상이지만 CA에서 수정하지 않았습니다! 왜요?

클러스터 자동 확장 처리는 클러스터를 이러한 제한 이상으로 확장하지 않지만 적용하지는 않습니다. 클러스터가 Cluster Autoscaler에 대해 구성된 최소 노드 수 미만인 경우 예약할 수 없는 포드가 있는 경우에만 확장됩니다.

클라우드 제공자에 더 이상 할당량이 없을 때 수직 확장에서는 어떻게 됩니까?

클러스터 자동 확장 처리는 주기적으로 클러스터를 늘리려고 시도하고, 실패하면 할당량이 도달하거나 확장 트리거 포드가 제거될 때까지 이전 크기로 다시 이동합니다.

버전 0.6.2부터 클러스터 자동 확장 처리는 장애가 발생한 후 노드 그룹 확장을 중단합니다. 스케일업이 실패한 기간에 따라 다음 시도까지 최대 30분이 소요될 수 있습니다.

개발자:

CA를 컴파일하려면 어떤 go 버전을 사용해야 합니까?

Cluster Autoscaler는 일반적으로 포함된 Kubernetes 코드에서 사용하는 것과 동일한 go 버전을 사용하려고 합니다. 예를 들어 CA 1.21은 Kubernetes 1.21과 동일한 go 버전을 사용합니다. 공식적으로 사용되는 go 버전만 지원되며 CA는 다른 버전을 사용하여 컴파일하지 않을 수 있습니다.

사용된 go 버전의 출처는 builder/Dockerfile입니다.

경고: go.mod 파일에 지정된 go 버전에 의존하지 마십시오. 이동 모드 동작을 제어하기 위한 것일 뿐이며 CA에서 실제로 사용하는 이동 버전을 나타내지는 않습니다. 특히 go 1.17은 기존 Kubernetes 도구와 호환되지 않는 방식으로 go mod 동작을 변경합니다. Kubernetes 예제 에 따라 지금은 go.mod에 지정된 버전을 1.16으로 고정하기로 결정했습니다(Kubernetes와 CA가 더 이상 go 1.16을 사용하여 컴파일하지 않더라도).

어떻게 e2 테스트를 실행할 수 있습니까?

  1. Kubernetes 문서 에 설명된 대로 환경을 설정하고 e2e.go를 빌드합니다 .
  2. 다음 환경 변수를 설정합니다.이것은 모든 e2e 테스트를 통과하는 데 필요한 최소 노드 수입니다. 최대 노드 제한을 더 높게 설정하면 테스트도 통과해야 합니다.
  3. export KUBE_AUTOSCALER_MIN_NODES=3
export KUBE_AUTOSCALER_MAX_NODES=6
export KUBE_ENABLE_CLUSTER_AUTOSCALER=true
export KUBE_AUTOSCALER_ENABLE_SCALE_DOWN=true
  4. 실행 go run hack/e2e.go -- --verbose-commands --up하여 클러스터를 불러옵니다.
  5. 제어 평면(이전에는 마스터라고 함) 노드에 SSH하고 편집 /etc/kubernetes/manifests/cluster-autoscaler.manifest합니다(이를 위해서는 sudo가 필요함).
    • image자신의 CA 이미지를 가리키도록 설정된 사용자 지정 변경 사항을 테스트하려는 경우 .
    • --scale-down-enabled의 매개변수가 command로 설정되어 있는지 확인하십시오 true.
  6. 다음을 사용하여 CA 테스트를 실행합니다.전체 제품군을 실행하는 데 1시간 이상 걸립니다. 출력이 많기 때문에 출력을 파일로 리디렉션할 수 있습니다. 
    gcloud beta auth application-default login
  7. 테스트 실행기에 기본 자격 증명이 누락되었을 수 있습니다. GCE에서는 다음이 제공될 수 있습니다.
  8. go run hack/e2e.go -- --verbose-commands --test --test_args="--ginkgo.focus=\[Feature:ClusterSizeAutoscaling"

몇 가지 테스트는 GKE에만 해당되며 다른 제공업체에서 실행 중인 경우 건너뜁니다.

실패하거나 불안정한 테스트를 발견하면 이슈를 열어주세요(PR은 더욱 환영받을 것입니다).

PR을 제출하기 전에 코드를 어떻게 테스트해야 합니까?

이 답변은 중요하지 않은 코드 변경이 포함된 pull 요청에만 적용됩니다.

불행히도 아직 모든 pull 요청에 대해 e2 테스트를 자동으로 실행할 수는 없으므로 지금은 PR이 기본 클러스터 자동 확장 기능을 중단하지 않는지 테스트하기 위해 몇 가지 수동 단계를 따라야 합니다. 우리는 당신이 메인 루프에 영향을 미치지 않는 사소한 버그 수정이나 사소한 변경에 대해 이 전체 프로세스를 따를 것을 요구하지 않습니다. 상식을 사용하여 변경에 필요한 것과 필요하지 않은 것을 결정하십시오.

PR을 테스트하려면:

  1. 가능한 경우 Cluster Autoscaler e2e 테스트를 실행합니다. 우리는 GCE에서 e2 테스트를 실행하고 있으며 테스트가 모든 클라우드 제공업체에서 통과한다고 보장할 수 없습니다.
  2. e2e를 실행할 수 없는 경우 변경 사항이 포함된 Cluster-Autoscaler 이미지와 이를 활성화하는 데 필요한 구성을 사용하여 최소한 다음 수동 테스트를 수행하도록 요청합니다. i. 배포를 만듭니다. 일부 포드가 기존 노드에 맞지 않도록 확장합니다. Cluster Autoscaler가 새 노드를 추가할 때까지 기다렸다가 모든 포드가 성공적으로 예약되었는지 확인합니다. ii. 배포를 단일 복제본으로 축소하고 클러스터가 축소되는지 확인합니다.
  3. 변경의 기본 사용 사례에 따라 수동 테스트를 실행합니다. 노드가 예상대로 추가 또는 제거되었는지 확인합니다. 다시 한 번, 우리는 상식을 사용하여 테스트해야 할 항목을 결정하도록 요청합니다.
  4. PR 설명 또는 PR에 대한 별도의 의견(예: #74 (comment) )에 테스트를 설명합니다.

우리는 이 과정이 지루하다는 것을 알고 있으며 이를 개선하기 위해 노력할 것입니다.

CA 종속성(특히 k8s.io/kubernetes)을 업데이트하려면 어떻게 해야 합니까?

Cluster Autoscaler는 스케줄러 구현을 호출할 때 엄청난 양의 내부 k8s 코드를 가져옵니다. 따라서 버전 비호환성으로 인해 발생하는 예기치 않은 문제를 방지하기 위해 CA에서 사용되는 라이브러리 세트를 k8에서 사용하는 라이브러리에 가깝게 유지하고자 합니다.

리포지토리의 공급업체 k8s 라이브러리를 동기화하기 위해 릴리스된 버전의 k8s를 사용하고 replace각 k8s 하위 라이브러리의 지시문을 업데이트하는 스크립트가 있습니다. 사용자 정의 kubernetes 포크와 함께 사용할 수 있으며 기본적으로 git@github.com:kubernetes/kubernetes.git.

예제 실행은 다음과 같습니다.

./hack/update-vendor.sh 1.20.0-alpha.1 git@github.com:kubernetes/kubernetes.git

Kubernetes의 릴리스되지 않은 커밋으로 공급업체를 업데이트해야 하는 경우 breakglass 스크립트를 사용할 수 있습니다.

./hack/submodule-k8s.sh <k8s commit sha> git@github.com:kubernetes/kubernetes.git

 

저작자표시
댓글