AutoScaling

자동 크기 조정은 변화하는 요구 사항에 맞게 리소스를 자동으로 확장하거나 축소하는 기능입니다. 이는 Kubernetes의 주요 기능이며 그렇지 않으면 수동으로 수행하기 위해 많은 인적 자원을 필요로 할 것입니다.

Amazon EKS는 두 가지 자동 크기 조정 제품을 지원합니다. Kubernetes Cluster Autoscaler 및 Karpenter 오픈 소스 자동 크기 조정 프로젝트. Cluster Autoscaler는 AWS 크기 조정 그룹을 사용하는 반면 Karpenter는 Amazon EC2 플릿과 직접 작동합니다.

Cluster Autoscaler

Kubernetes Cluster Autoscaler는 pods가 실패하거나 다른 노드로 다시 예약될 때 클러스터의 노드 수를 자동으로 조정합니다. Cluster Autoscaler는 일반적으로 클러스터에 배포로 설치됩니다. 리더 선출을 사용하여 고가용성을 보장할 수 있지만 확장은 한 번에 하나의 복제본으로만 수행됩니다.

Cluster Autoscaler를 배포하기 전에 AWS 기능과 상호 작용하는 Kubernetes 개념을 숙지해야 합니다. 이 주제에서 사용되는 용어는 다음과 같습니다.

Kubernetes 클러스터 Autoscaler - 예약 및 크기 조정 결정을 내리는 Kubernetes 컨트롤 플레인의 핵심 구성 요소입니다. 자세한 내용은 GitHub의 Kubernetes 컨트롤 플레인 FAQ를 참조하세요.
AWS 클라우드 제공업체 구현 - AWS 제품 및 서비스(예: Amazon EC2)와 통신하여 Kubernetes Cluster Autoscaler의 결정 사항을 구현하는 Kubernetes 클러스터 Autoscaler의 확장 기능입니다. 자세한 내용은 GitHub의 AWS의 Cluster Autoscaler를 참조하세요.
노드 그룹 - 클러스터 내의 노드 그룹에 대한 Kubernetes 추상화입니다. 노드 그룹은 진정한 Kubernetes 리소스가 아니지만 Cluster Autoscaler, 클러스터 API, 기타 구성 요소에서 추상화로 존재합니다. 단일 노드 그룹 내에서 발견되는 노드는 레이블 및 테인트과 같은 몇 가지 공통 특성을 공유할 수 있습니다. 하지만 둘 이상의 가용 영역 또는 인스턴스 유형으로 구성될 수 있습니다.
Amazon EC2 Auto Scaling 그룹 - Cluster Autoscaler에 사용되는 AWS의 기능입니다. Auto Scaling 그룹은 많은 사용 사례에 적합합니다. Amazon EC2 Auto Scaling 그룹은 Kubernetes 클러스터에 자동으로 조인하는 인스턴스를 시작하도록 구성됩니다. 또한 Kubernetes API의 해당 노드 리소스에 레이블과 테인트를 적용합니다.

참고로 관리형 노드 그룹는 Amazon EC2 Auto Scaling 그룹을 사용하여 관리되며 Cluster Autoscaler와 호환됩니다.

이 주제에서는 Cluster Autoscaler를 Amazon EKS 클러스터로 배포한 다음 구성하여 Amazon EC2 Auto Scaling 그룹을 수정하는 방법에 관해 살펴봅니다.

사전 조건

Cluster Autoscaler를 배포하려면 먼저 다음 사전 조건을 충족해야 합니다.

기존 Amazon EKS 클러스터 - 클러스터가 없는 경우 Amazon EKS 클러스터 생성 섹션을 참조하세요.
클러스터에 대한 기존 IAM OIDC 공급자입니다. 하나가 있는지 또는 생성해야 하는지 여부를 확인하려면 클러스터의 IAM OIDC 제공업체 생성 섹션을 참조하세요.

Auto Scaling 그룹 태그가 있는 노드 그룹 Cluster Autoscaler에서는 Auto Scaling 그룹에 다음과 같은 태그가 있어야 자동 검색됩니다.

eksctl을 사용하여 노드 그룹을 생성한 경우 이 태그는 자동으로 적용됩니다.
eksctl을 사용하지 않았다면 다음 태그로 Auto Scaling 그룹에 수동으로 태그를 지정해야 합니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서에서 Amazon EC2 리소스 태깅을 참조하세요.

키	값
`k8s.io/cluster-autoscaler/my-cluster`	`owned`
`k8s.io/cluster-autoscaler/enabled`	`true`

IAM 정책 및 역할 생성

Cluster Autoscaler가 IAM 역할을 사용하기 위해 필요한 권한을 부여하는 IAM 정책을 만듭니다. 절차 전반에서 모든 example values을 고유한 값으로 교체합니다.

IAM 정책을 생성합니다.

다음 콘텐츠를 cluster-autoscaler-policy.json이라는 파일에 저장합니다. 기존 노드 그룹이 eksctl을 사용하여 생성되었고 --asg-access 옵션을 사용했다면 이 정책이 이미 존재하며 2단계로 건너뛸 수 있습니다.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/my-cluster": "owned"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeAutoScalingGroups",
                "ec2:DescribeLaunchTemplateVersions",
                "autoscaling:DescribeTags",
                "autoscaling:DescribeLaunchConfigurations",
                "ec2:DescribeInstanceTypes"
            ],
            "Resource": "*"
        }
    ]
}

다음 명령을 사용하여 정책을 생성합니다. policy-name의 값을 변경할 수 있습니다.
```
aws iam create-policy \
    --policy-name AmazonEKSClusterAutoscalerPolicy \
    --policy-document file://cluster-autoscaler-policy.json
```
출력에 반환되는 Amazon 리소스 이름(ARN)을 적어 둡니다. 이후 단계에서 사용해야 합니다.

eksctl 또는 AWS Management Console을 사용하여 IAM 역할을 생성하고 IAM 정책을 연결할 수 있습니다. 다음 지침을 보려면 원하는 탭을 선택합니다.
eksctl
eksctl을 사용하여 Amazon EKS 클러스터를 생성한 경우 다음 명령을 실행합니다. --asg-access 옵션을 사용하여 노드 그룹을 생성한 경우 AmazonEKSClusterAutoscalerPolicy를 eksctl이 생성한 IAM 정책의 이름으로 바꿉니다. 정책 이름은 eksctl-my-cluster-nodegroup-ng-xxxxxxxx-PolicyAutoScaling과 유사합니다.

eksctl create iamserviceaccount \ --cluster=my-cluster \ --namespace=kube-system \ --name=cluster-autoscaler \ --attach-policy-arn=arn:aws:iam::111122223333:policy/AmazonEKSClusterAutoscalerPolicy \ --override-existing-serviceaccounts \ --approve

--asg-access 옵션을 사용하여 노드 그룹을 생성한 경우 eksctl이 생성하여 해당 eksctl이 노드 그룹에 대해 생성한 Amazon EKS 노드 IAM 역할에 연결한 IAM 정책을 분리합니다. Cluster Autoscaler가 제대로 작동하도록 노드 IAM 역할에서 정책을 분리합니다. 정책을 분리해도 노드의 다른 pods에는 정책의 권한이 부여되지 않습니다. 자세한 내용을 알아보려면 Linux 인스턴스용 Amazon EC2 사용 설명서의 IAM 보안 인증 권한 제거를 참조하세요.
AWS Management Console
https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.

왼쪽 탐색 창에서 역할(Roles)을 선택합니다. 그런 다음 역할 생성(Create role)을 선택합니다.

신뢰할 수 있는 엔터티 유형(Trusted entity type) 섹션에서 웹 자격 증명(Web identity)을 선택합니다.

웹 자격 증명(Web identity) 섹션에서:

보안 인증 공급자의 경우 클러스터에 대해 OpenID Connect 공급자 URL(provider URL)을 선택합니다(Amazon EKS의 클러스터 개요(Overview) 탭에 표시된 대로).

대상(Audience)에서 sts.amazonaws.com을 입력합니다.

다음(Next)을 선택합니다.

필터 정책(Filter policies) 상자에 AmazonEKSClusterAutoscalerPolicy를 입력합니다. 그런 다음 검색에 반환된 정책 이름 왼쪽에 있는 확인란을 선택합니다.

다음(Next)을 선택합니다.

역할 이름(Role name)에 역할의 고유한 이름(예: AmazonEKSClusterAutoscalerRole)을 입력합니다.

설명(Description)에서 Amazon EKS - Cluster autoscaler role과 같은 설명 텍스트를 입력합니다.

Create role(역할 생성)을 선택합니다.

역할을 생성한 후 편집할 수 있도록 콘솔에서 이 역할을 선택하여 엽니다.

신뢰 관계(Trust relationships) 탭을 선택한 후 신뢰 정책 편집(Edit trust policy)을 선택합니다.

다음과 비슷한 줄을 찾습니다.

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"

해당 줄을 다음 줄처럼 변경합니다. EXAMPLED539D4633E53DE1B71EXAMPLE을 클러스터의 OIDC 공급자 ID로 바꿉니다. region-code를 클러스터가 있는 AWS 리전으로 바꿉니다.

"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:kube-system:cluster-autoscaler"

신뢰 정책 업데이트(Update Trust Policy)를 선택하여 종료합니다.

Cluster Autoscaler 배포

Cluster Autoscaler를 배포하려면 다음 단계를 완료합니다. 배포 고려 사항 섹션을 검토하여 프로덕션 클러스터에 배포하기 전에 Cluster Autoscaler 배포를 최적화하는 것이 좋습니다.

Cluster Autoscaler를 배포하려면

Cluster Autoscaler YAML 파일을 다운로드합니다.


curl -O https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

YAML 파일을 수정하고 <YOUR CLUSTER NAME>을 클러스터 이름으로 바꿉니다. 또한 사용자 환경에 따라 결정되는 대로 cpu 및 memory 값을 바꾸는 것이 좋습니다.

YAML 파일을 클러스터에 적용합니다.


kubectl apply -f cluster-autoscaler-autodiscover.yaml

이전에 생성한 IAM 역할의 ARN을 사용하여 cluster-autoscaler 서비스 계정에 주석을 지정합니다. example values를 고유한 값으로 바꿉니다.
```
kubectl annotate serviceaccount cluster-autoscaler \
  -n kube-system \
  eks.amazonaws.com/role-arn=arn:aws:iam::ACCOUNT_ID:role/AmazonEKSClusterAutoscalerRole
```

다음 명령으로 배포를 패치하여 cluster-autoscaler.kubernetes.io/safe-to-evict 주석을 Cluster Autoscaler pods에 추가합니다.


kubectl patch deployment cluster-autoscaler \
  -n kube-system \
  -p '{"spec":{"template":{"metadata":{"annotations":{"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"}}}}}'

다음 명령을 사용하여 Cluster Autoscaler 배포를 편집합니다.
```
kubectl -n kube-system edit deployment.apps/cluster-autoscaler
```
cluster-autoscaler 컨테이너 명령을 편집하여 다음 옵션을 추가합니다. --balance-similar-node-groups는 모든 가용 영역에서 사용 가능한 컴퓨팅이 충분한지 확인하고, --skip-nodes-with-system-pods=false는 0으로 스케일링하는 데 문제가 없는지 확인합니다.
- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false
```
    spec:
      containers:
      - command
        - ./cluster-autoscaler
        - --v=4
        - --stderrthreshold=info
        - --cloud-provider=aws
        - --skip-nodes-with-local-storage=false
        - --expander=least-waste
        - --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
        - --balance-similar-node-groups
        - --skip-nodes-with-system-pods=false
```
파일을 저장한 다음 종료하여 변경 사항을 적용합니다.
웹 브라우저의 GitHub에서 Cluster Autoscaler 릴리스 페이지를 열고 클러스터의 Kubernetes 메이저 및 마이너 버전과 일치하는 최신 Cluster Autoscaler 버전을 검색합니다. 예를 들어 클러스터의 Kubernetes 버전이 1.25라면 1.25로 시작하는 최신 Cluster Autoscaler 릴리스를 검색합니다. 다음 단계에서 사용할 수 있도록 이 릴리스의 의미 체계 버전(1.25.n)을 적어 둡니다.
다음 명령을 사용하여 Cluster Autoscaler 이미지 태그를 이전 단계에서 적어 둔 버전으로 설정합니다. 1.25.n을 사용자의 고유한 값으로 교체합니다.
```
kubectl set image deployment cluster-autoscaler \
  -n kube-system \
  cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:v1.25.n
```

Cluster Autoscaler 로그 보기

Cluster Autoscaler를 배포한 후에는 로그를 보고 Cluster Autoscaler가 클러스터 로드를 모니터링하고 있는지 확인할 수 있습니다.

다음 명령을 사용하여 Cluster Autoscaler 로그를 봅니다.


kubectl -n kube-system logs -f deployment.apps/cluster-autoscaler

출력 예는 다음과 같습니다.


I0926 23:15:55.165842       1 static_autoscaler.go:138] Starting main loop
I0926 23:15:55.166279       1 utils.go:595] No pod using affinity / antiaffinity found in cluster, disabling affinity predicate for this loop
I0926 23:15:55.166293       1 static_autoscaler.go:294] Filtering out schedulables
I0926 23:15:55.166330       1 static_autoscaler.go:311] No schedulable pods
I0926 23:15:55.166338       1 static_autoscaler.go:319] No unschedulable pods
I0926 23:15:55.166345       1 static_autoscaler.go:366] Calculating unneeded nodes
I0926 23:15:55.166357       1 utils.go:552] Skipping ip-192-168-3-111.region-code.compute.internal - node group min size reached
I0926 23:15:55.166365       1 utils.go:552] Skipping ip-192-168-71-83.region-code.compute.internal - node group min size reached
I0926 23:15:55.166373       1 utils.go:552] Skipping ip-192-168-60-191.region-code.compute.internal - node group min size reached
I0926 23:15:55.166435       1 static_autoscaler.go:393] Scale down status: unneededOnly=false lastScaleUpTime=2019-09-26 21:42:40.908059094 ...
I0926 23:15:55.166458       1 static_autoscaler.go:403] Starting scale down
I0926 23:15:55.166488       1 scale_down.go:706] No candidates for scale down

배포 고려 사항

Cluster Autoscaler 배포를 최적화하려면 다음 고려 사항을 검토하세요.

확장 고려 사항

Cluster Autoscaler는 노드의 추가 기능을 포함하도록 구성할 수 있습니다. 이러한 기능에는 노드에 연결된 Amazon EBS 볼륨, 노드 Amazon EC2 인스턴스 유형 또는 GPU 액셀러레이터가 포함될 수 있습니다.

둘 이상의 가용 영역에 걸쳐 노드 그룹 범위 지정

여러 노드 그룹을 구성하고 각 그룹의 범위를 단일 가용 영역으로 지정하고 --balance-similar-node-groups 기능을 활성화합니다. 노드 그룹을 하나만 생성하는 경우 해당 노드 그룹의 범위를 두 개 이상의 가용 영역으로 확장하도록 지정합니다.

--balance-similar-node-groups를 true로 설정할 때 Cluster Autoscaler가 밸런싱하려는 노드 그룹에 일치하는 레이블이 있는지 확인합니다(자동으로 추가된 영역 레이블 제외). 레이블이 다른 노드에 --balancing-ignore-label 플래그를 전달하여 노드를 밸런싱할 수 있지만 이는 필요할 때만 수행해야 합니다.

노드 그룹 최적화

Cluster Autoscaler는 노드 그룹을 사용하는 방법에 대해 가정합니다. 여기에는 그룹 내에서 사용하는 인스턴스 유형이 포함됩니다. 이러한 가정에 맞추려면 다음 고려 사항 및 권장 사항에 따라 노드 그룹을 구성합니다.

노드 그룹의 각 노드에는 동일한 일정 속성이 있어야 합니다. 여기에는 레이블, 테인트 및 리소스가 포함됩니다.
- MixedInstancePolicies의 경우 인스턴스 유형에 호환 가능한 CPU, 메모리 및 GPU 규격이 있어야 합니다.
- 정책에 지정된 첫 번째 인스턴스 유형은 예약을 시뮬레이션합니다.
- 정책에 리소스가 더 많은 추가 인스턴스 유형이 있는 경우 확장 후 리소스가 낭비될 수 있습니다.
- 정책에 원래 인스턴스 유형보다 리소스가 적은 추가 인스턴스 유형이 있는 경우 pods가 인스턴스에 대해 예약되지 않을 수 있습니다.
반대 구성이 확장성에 부정적인 영향을 줄 수 있으므로 노드 수가 많은 적은 수의 노드 그룹을 구성합니다.
두 시스템에서 모두 지원할 때마다 Amazon EC2 기능을 사용합니다(예: 리전 및 MixedInstancePolicy 사용).

가능한 경우 관리형 노드 그룹을 사용할 것을 권장합니다. 관리형 노드 그룹에는 강력한 관리 기능이 포함되어 있습니다. 여기에는 자동 Amazon EC2 Auto Scaling 그룹 검색 및 정상적인 노드 종료와 같은 Cluster Autoscaler의 기능이 포함됩니다.

EBS 볼륨을 영구 스토리지로 사용

영구 스토리지는 데이터베이스 및 분산 캐시와 같은 상태 유지 애플리케이션을 구축하는 데 매우 중요합니다. Amazon EBS 볼륨을 사용하면 Kubernetes에서 상태 유지 애플리케이션을 구축할 수 있습니다. 그러나 단일 가용 영역 내에서만 구축하는 것으로 제한됩니다. 자세한 내용은 Amazon EKS에서 영구 스토리지를 사용하려면 어떻게 해야 합니까? 섹션을 참조하세요. 더 나은 솔루션을 위해 각 가용 영역마다 별도의 Amazon EBS 볼륨을 사용하여 둘 이상의 가용 영역에 분산된 상태 유지 애플리케이션을 구축하는 것이 좋습니다. 이렇게 하면 애플리케이션의 가용성을 높일 수 있습니다. 또한 Cluster Autoscaler는 Amazon EC2 Auto Scaling 그룹의 크기 조정을 밸런싱할 수 있습니다. 이 작업을 수행하려면 다음 조건이 충족되는지 확인하세요.

노드 그룹 밸런싱은 balance-similar-node-groups=true를 설정하여 활성화합니다.
노드 그룹은 동일한 설정으로 구성됩니다(둘 이상의 가용 영역에 속하고 다른 Amazon EBS 볼륨을 사용하는 것 제외).

공동 예약

기계 학습 분산 훈련 작업은 동일한 영역 노드 구성의 최소화된 지연 시간을 통해 상당한 이점을 얻을 수 있습니다. 이러한 워크로드는 여러 pods를 특정 영역에 배포합니다. topologyKey: topology.kubernetes.io/zone을 사용하여 공동 예약된 모든 pods 또는 pod 선호도를 설정함으로써 이를 실현할 수 있습니다. 이 구성을 사용하여 Cluster Autoscaler는 수요에 맞게 특정 영역을 확장합니다. 가용 영역마다 하나씩 여러 Amazon EC2 Auto Scaling 그룹을 할당하여 공동 예약된 전체 워크로드에 대해 장애 조치를 활성화합니다. 다음 조건을 충족하는지 확인하세요.

노드 그룹 밸런싱은 balance-similar-node-groups=true를 설정하여 활성화합니다.
노드 선호도, pod 선점 또는 모두는 클러스터가 리전별 및 영역별 노드 그룹을 모두 포함하는 경우에 사용됩니다.
- 리전별 pods를 강제하거나 장려하고 영역별 노드 그룹을 피하려면 노드 선호도를 사용합니다.
- 영역별 pods를 리전별 노드 그룹에 예약하지 마세요. 이렇게 하면 리전 pods의 용량이 불균형해질 수 있습니다.
- 영역별 워크로드가 중단 및 재배치를 허용할 경우 pod 선점을 구성합니다. 이렇게 하면 리전별로 크기가 조정된 pods에 대해 경쟁이 적은 영역에서 선점 및 일정을 조정할 수 있습니다.

액셀러레이터 및 GPU

일부 클러스터는 전용 GPU와 같은 특수 하드웨어 액셀러레이터를 사용합니다. 확장 시 액셀러레이터가 리소스를 클러스터에 제공하는 데 몇 분 정도 걸릴 수 있습니다. 이 시간 동안 Cluster Autoscaler는 이 노드에 액셀러레이터가 있음을 시뮬레이션합니다. 그러나 액셀러레이터가 준비되고 노드의 사용 가능한 리소스를 업데이트하기 전까지는 노드에서 보류 중인 pods를 예약할 수 없습니다. 이로 인해 반복적 불필요한 확장이 발생할 수 있습니다.

액셀러레이터가 있고 CPU 또는 메모리 사용률이 높은 노드는 액셀러레이터가 사용되지 않는 경우에도 축소에 고려되지 않습니다. 하지만 이로 인해 불필요한 비용이 발생할 수 있습니다. 이러한 비용을 방지하기 위해 Cluster Autoscaler는 액셀러레이터가 비어있는 경우 축소를 위해 노드를 고려하는 특수 규칙을 적용할 수 있습니다.

이러한 경우에 대한 올바른 동작을 보장하려면 클러스터에 조인하기 전에 액셀러레이터 노드에 kubelet을 구성하여 노드에 레이블을 지정할 수 있습니다. Cluster Autoscaler는 이 레이블 선택기를 사용하여 액셀러레이터 최적화 동작을 호출합니다. 다음 조건을 충족하는지 확인하세요.

GPU 노드의 kubelet은 --node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE을 사용하여 구성됩니다.
액셀러레이터가 있는 노드는 동일한 예약 속성 규칙을 준수합니다.

0에서 크기 조정

Cluster Autoscaler는 노드 그룹의 크기를 0으로 또는 0에서 조정할 수 있습니다. 이 방법을 통해 상당한 비용을 절약할 수 있습니다. Cluster Autoscaler는 해당 LaunchConfiguration 또는 LaunchTemplate에 지정된 InstanceType을 조사하여 Auto Scaling 그룹의 CPU, 메모리 및 GPU 리소스를 분리합니다. 일부 pods에는 WindowsENI 또는 PrivateIPv4Address와 같은 추가 리소스가 필요합니다. 또는 특정 NodeSelectors 또는 Taints가 필요할 수 있습니다. 후자의 이 두 가지는 LaunchConfiguration에서 제공되지 않습니다. 그러나 Cluster Autoscaler는 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으로 크기 조정하면 용량이 Amazon EC2로 반환되어 나중에 사용할 수 없게 될 수 있습니다.
0으로 또는 0에서 크기 조정할 때 describeNodegroup를 사용하여 관리형 노드 그룹의 문제를 진단할 수 있습니다.

Kubernetes 1.24 및 이후 버전의 클러스터의 동작이 간소화되었습니다. 이전 버전의 경우 기본 Amazon EC2 Auto Scaling 그룹에 해당 그룹이 담당하는 노드의 세부 정보로 태그를 지정해야 합니다. Kubernetes 1.24 및 이후 버전의 클러스터의 경우 관리형 노드 그룹에 실행 중인 노드가 없을 때 Cluster Autoscaler에서 Amazon EKS DescribeNodegroup API 작업을 호출합니다. 이 API 작업에서는 Cluster Autoscaler에 필요한 관리 노드 그룹의 리소스, 레이블 및 테인트에 대한 정보가 제공됩니다. 이 기능을 사용하려면 Cluster Autoscaler 서비스 계정 IAM 정책에 eks:DescribeNodegroup 권한을 추가해야 합니다. Amazon EKS 관리형 노드 그룹을 지원하는 오토 스케일링의 Cluster Autoscaler 태그 값이 노드 그룹 자체와 충돌하는 경우 Cluster Autoscaler에서는 오토 스케일링 태그의 값을 선호합니다. 이는 필요에 따라 값을 재정의할 수 있도록 하기 위한 것입니다.

추가 구성 파라미터

Cluster Autoscaler의 동작과 성능을 조정하는 데 사용할 수 있는 많은 구성 옵션이 있습니다. 파라미터의 전체 목록은 GitHub에서 CA에 대한 파라미터는 무엇인가요? 섹션을 참조하세요.

성능 고려 사항

Cluster Autoscaler의 성능 및 확장성을 조정하기 위해 변경할 수 있는 몇 가지 주요 항목이 있습니다. 기본 리소스는 프로세스에 제공되는 리소스, 알고리즘의 검색 간격 및 클러스터의 노드 그룹 수입니다. 하지만 이 알고리즘의 실제 런타임 복잡성에 관련된 몇 가지 다른 요인도 있습니다. 여기에는 일정 관리 플러그인 복잡성 및 pods 수가 포함됩니다. 이러한 파라미터는 클러스터 워크로드에 필수적이며 쉽게 조정할 수 없기 때문에 구성 불가능한 파라미터로 간주됩니다.

확장성은 Kubernetes 클러스터의 pods 및 노드 수가 증가함에 따라 Cluster Autoscaler가 얼마나 뛰어난 성능을 발휘하는지를 나타냅니다. 확장성 할당량에 도달하면 Cluster Autoscaler의 성능 및 기능이 저하됩니다. 또한 확장성 할당량을 초과하면 Cluster Autoscaler가 더 이상 클러스터에 노드를 추가하거나 제거할 수 없습니다.

성능은 Cluster Autoscaler가 얼마나 빨리 확장 결정을 내리고 구현할 수 있는지 나타냅니다. 완벽하게 작동하는 Cluster Autoscaler는 즉시 결정을 내리고 pod를 예약할 수 없게 되는 것과 같은 특정 조건에 대한 응답으로 크기 조정 작업을 호출합니다.

자동 크기 조정 알고리즘의 런타임 복잡성에 대해 잘 알고 있어야 합니다. 이렇게 하면 Cluster Autoscaler가 대규모 클러스터(노드 1,000개 이상)에서 잘 작동하도록 더 쉽게 조정할 수 있습니다.

Cluster Autoscaler는 전체 클러스터의 상태를 메모리로 로드합니다. 여기에는 pods, 노드, 노드 그룹이 포함됩니다. 각 검색 간격마다 알고리즘은 예약할 수 없는 pods를 식별하고 각 노드 그룹에 대한 예약을 시뮬레이션합니다. 이러한 요소를 여러 가지 방법으로 조정하는 것은 서로 다른 절충점을 가지고 있음을 알고 있습니다.

수직적 자동 크기 조정

배포에 대한 리소스 요청을 늘려 Cluster Autoscaler를 더 큰 클러스터로 확장할 수 있습니다. 이를 수행하는 더 간단한 방법 중 하나입니다. 대규모 클러스터의 메모리와 CPU를 모두 늘립니다. 메모리와 CPU를 늘려야 하는 양은 특정 클러스터 크기에 크게 좌우된다는 것을 알고 있습니다. 자동 크기 조정 알고리즘은 모든 pods와 노드를 메모리에 저장합니다. 이로 인해 경우에 따라 1기가바이트보다 큰 메모리 공간이 발생할 수 있습니다. 일반적으로 리소스를 수동으로 늘려야 합니다. 리소스를 수동으로 늘려야 하는 경우가 많으면 Addon Resizer 또는 Vertical Pod Autoscaler를 사용하여 프로세스를 자동화할 수 있습니다.

노드 그룹의 수 감소

대규모 클러스터에서 Cluster Autoscaler의 성능을 향상시키기 위해 노드 그룹 수를 줄일 수 있습니다. 개별 팀 또는 애플리케이션을 기반으로 노드 그룹을 구성한 경우 이는 어려울 수 있습니다. 이것은 Kubernetes API에서 완벽하게 지원되지만 확장성에 대한 영향을 미치는 Cluster Autoscaler 안티 패턴으로 간주됩니다. 예를 들어 스팟 인스턴스 또는 GPU 인스턴스를 모두 사용하는 여러 노드 그룹을 사용하면 많은 이점이 있습니다. 대부분의 경우 소수의 그룹을 사용하면서 동일한 효과를 얻을 수 있는 대체 설계가 있습니다. 다음 조건을 충족하는지 확인하세요.

노드 그룹이 아닌 네임스페이스를 사용하여 pods를 격리합니다.
- 신뢰도가 낮은 다중 테넌트 클러스터에서는 이러한 작업을 수행하지 못할 수도 있습니다.
- pod ResourceRequests 및 ResourceLimits를 적절하게 설정하여 리소스 경합을 피할 수 있습니다.
- 더 큰 인스턴스 유형을 사용하면 빈 패킹을 최적화하고 시스템 pod 오버헤드를 줄일 수 있습니다.
pods를 예약하는 데 NodeTaints 또는 NodeSelectors는 사용하지 않습니다. 제한된 기준으로만 사용하세요.
리전별 리소스를 가용 영역이 두 개 있는 단일 Amazon EC2 Auto Scaling 그룹으로 정의합니다.

스캔 간격 줄이기

기본 설정인 10초와 같은 낮은 검색 간격을 사용하면 pods를 예약할 수 없게 될 때 Cluster Autoscaler가 가능한 빨리 응답할 수 있습니다. 그러나 각 검색을 수행하면 Kubernetes API 및 Amazon EC2 Auto Scaling 그룹 또는 Amazon EKS 관리 노드 그룹 API에 대한 많은 API 호출이 발생합니다. 이러한 API 호출로 인해 Kubernetes 컨트롤 플레인에 대한 속도 제한이 발생하거나 서비스를 사용할 수 없게 될 수 있습니다.

기본 검색 간격은 10초이지만 AWS에서는 노드를 시작하는 데 새 인스턴스를 시작하는 것보다 시간이 훨씬 오래 걸립니다. 즉, 전체 스케일 업 시간을 크게 늘리지 않고 간격을 늘릴 수 있습니다. 예를 들어 노드를 시작하는 데 2분 정도 걸리는 경우 간격을 1분으로 변경하지 마십시오. 이로 인해 38% 느린 확장에 대한 6배 감소된 API 호출의 절충이 발생할 수 있습니다.

노드 그룹 간 공유

특정 노드 그룹 집합에서 작동하도록 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

다음 조건을 충족하는지 확인합니다.

각 샤드는 고유한 Amazon EC2 Auto Scaling 그룹 세트를 가리키도록 구성됩니다.
각 샤드는 리더 선출 충돌을 피하기 위해 별도의 네임 스페이스에 배포됩니다.

비용 효율성 및 가용성

Cluster Autoscaler의 비용 효율성을 튜닝하기 위한 기본 옵션은 Amazon EC2 인스턴스 프로비저닝과 관련이 있습니다. 또한 비용 효율성은 가용성과 균형을 이루어야 합니다. 이 섹션에서는 스팟 인스턴스를 사용하여 비용을 절감하고 오버프로비저닝을 통해 새 노드를 생성할 때 지연 시간을 줄이는 등의 전략에 대해 설명합니다.

가용성 - 포드를 중단 없이 신속하게 예약할 수 있습니다. 새로 만든 pods를 예약해야 하는 경우와 축소된 노드가 예약된 나머지 pods를 종료하는 경우에도 마찬가지입니다.
비용 - 확장 및 축소 이벤트의 결정에 따라 결정됩니다. 기존 노드의 사용률이 낮거나 들어오는 pods에 비해 너무 큰 새 노드가 추가되면 리소스가 낭비됩니다. 특정 사용 사례에 따라 공격적인 스케일 다운 결정으로 인해 조기 종료 pods와 관련된 비용이 발생할 수 있습니다.

스팟 인스턴스

노드 그룹에서 스팟 인스턴스를 사용하여 온디맨드 가격에서 최대 90%까지 절약할 수 있습니다. 이는 Amazon EC2 용량을 다시 필요로 할 때 언제든지 스팟 인스턴스가 중단될 수 있다는 단점이 있습니다. Insufficient Capacity Errors는 사용 가능한 용량 부족으로 인해 Amazon EC2 Auto Scaling 그룹을 확장할 수 없을 때마다 발생합니다. 여러 인스턴스 패밀리를 선택하면 두 가지 주요 이점이 있습니다. 첫째, 여러 스팟 용량 풀을 사용하여 원하는 크기를 달성할 확률을 높일 수 있습니다. 둘째, 스팟 인스턴스 중단이 클러스터 가용성에 미치는 영향을 줄일 수도 있습니다. 스팟 인스턴스와 혼합 인스턴스 정책은 노드 그룹 수를 늘리지 않고도 다양성을 높일 수 있는 좋은 방법입니다. 그러나 보장된 리소스가 필요한 경우 스팟 인스턴스 대신 온디맨드 인스턴스를 사용합니다.

인스턴스에 대한 수요가 증가하면 스팟 인스턴스가 종료될 수 있습니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서의 스팟 인스턴스 중단 섹션을 참조하세요. AWS Node Termination Handler 프로젝트는 노드가 다운될 때 Kubernetes 컨트롤 플레인에 자동으로 경고합니다. 이 프로젝트는 Kubernetes API를 사용하여 노드를 연결하여 새 작업이 예약되지 않도록 한 다음 비우고 기존 작업을 제거합니다.

혼합 인스턴스 정책 구성 시 모든 인스턴스 유형의 리소스 용량이 비슷하도록 하는 것이 중요합니다. Autoscaler의 예약 시뮬레이터는 혼합 인스턴스 정책의 첫 번째 인스턴스 유형을 사용합니다. 후속 인스턴스 유형이 더 크면 확장 후 리소스가 낭비될 수 있습니다. 인스턴스 크기가 작으면 용량이 부족하여 새 인스턴스에 대한 pods가 예약되지 않을 수 있습니다. 예를 들어 M4, M5, M5a, 및 M5n 인스턴스는 모두 비슷한 양의 CPU와 메모리를 가지고 있으며 혼합 인스턴스 정책의 좋은 후보입니다. Amazon EC2 인스턴스 선택 도구를 사용하면 유사한 인스턴스 유형이나 추가 중요 기준(예: 크기)을 식별할 수 있습니다. 자세한 내용은 GitHub에서 Amazon EC2 인스턴스 선택을 참조하세요.

온디맨드 및 스팟 인스턴스 용량을 별도의 Amazon EC2 Auto Scaling 그룹으로 분리하는 것이 좋습니다. 온디맨드 인스턴스와 스팟 인스턴스의 예약 속성이 다르므로 기본 용량 전략을 사용하는 것이 좋습니다. 스팟 인스턴스는 언제든지 중단될 수 있습니다. Amazon EC2 용량을 다시 필요로 할 때 선점형 노드는 종종 오염되기 때문에 선점 동작에 대한 명시적인 pod 허용이 필요합니다. 그 결과 노드에 대한 예약 속성이 다르므로 여러 Amazon EC2 Auto Scaling 그룹으로 구분해야 합니다.

Cluster Autoscaler는 확장기의 개념과 관련이 있습니다. 이들은 규모를 조정할 노드 그룹을 선택하기 위한 다양한 전략을 총체적으로 제공합니다. --expander=least-waste 전략은 좋은 범용 기본값이며, 스팟 인스턴스 다각화에 여러 노드 그룹을 사용하려는 경우 앞에서 설명한 것처럼 조정 활동 후에 가장 잘 활용되는 그룹을 조정하여 노드 그룹을 추가로 비용 최적화하는 데 도움이 될 수 있습니다.

노드 그룹 또는 Auto Scaling 그룹의 우선 순위 지정

또한 Priority 확장기를 사용하여 우선 순위 기반 자동 크기 조정을 구성할 수 있습니다. --expander=priority를 사용하면 클러스터가 노드 그룹 또는 Auto Scaling 그룹의 우선 순위를 지정할 수 있으며 어떤 이유로든 확장할 수 없는 경우 우선 순위가 지정된 목록에서 다음 노드 그룹을 선택합니다. 이는 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이라는 이름과 일치하는 Amazon EC2 Auto Scaling 그룹을 확장하려고 시도합니다. --max-node-provision-time 내에서 이 작업이 성공하지 못하면, p2-node-group이라는 이름과 일치하는 Amazon EC2 Auto Scaling 그룹을 확장하려고 시도합니다. 이 값은 기본적으로 15분이며 응답성이 높은 노드 그룹 선택을 위해 줄일 수 있습니다. 그러나 값이 너무 낮으면 불필요한 확장이 발생할 수 있습니다.

오버프로비저닝

Cluster Autoscaler는 노드가 필요할 때만 클러스터에 추가되고 사용되지 않을 때는 제거되도록 하여 비용을 최소화합니다. 많은 pods가 노드를 확장하기 전에 노드가 확장될 때까지 기다려야 하므로 배포 대기 시간에 큰 영향을 미칩니다. 노드를 사용할 수 있게 되려면 몇 분 정도 걸릴 수 있으며, 이로 인해 pod 예약 지연 시간이 크게 늘어날 수 있습니다.

예약 대기 시간이 늘어나는 것을 감수하고 오버프로비저닝을 사용하여 이를 완화할 수 있습니다. 오버프로비저닝은 우선 순위가 낮은 임시 pods를 사용하여 구현됩니다. 이러한 pods는 클러스터의 공간을 차지합니다. 새로 생성한 pods를 예약할 수 없고 우선 순위가 더 높으면 임시 pods가 선점되어 공간을 만듭니다. 그런 다음 임시 pods를 예약할 수 없게 되어 Cluster Autoscaler가 새로 오버프로비저닝된 노드를 확장하게 됩니다.

오버프로비저닝에는 다른 이점이 있습니다. 오버프로비저닝을 사용하지 않으면 활용도가 높은 클러스터의 pods가 preferredDuringSchedulingIgnoredDuringExecution 규칙을 사용하여 최적화되지 않은 예약 결정을 내립니다. 일반적인 사용 사례는 AntiAffinity를 사용하여 사용 가능한 고가용성 애플리케이션의 pods를 여러 가용 영역에서 분리하는 것입니다. 오버프로비저닝을 사용하면 원하는 영역의 노드를 사용할 수 있는 가능성이 크게 높아질 수 있습니다.

적절한 양의 오버프로비저닝 용량을 선택하는 것이 중요합니다. 적절한 양을 선택할 수 있는 한 가지 방법은 평균 확장 빈도를 새 노드를 확장하는 데 걸리는 시간으로 나누는 것입니다. 예를 들어 평균적으로 30초마다 새 노드가 필요하고 Amazon EC2에서 새 노드를 프로비저닝하는 데 30초가 걸리는 경우 단일 오버프로비저닝 노드만으로도 항상 추가 노드를 확보할 수 있습니다. 이렇게 하면 Amazon EC2 인스턴스 한 개를 추가로 사용하는 대신 예약 대기 시간을 30초 단축할 수 있습니다. 더 나은 영역 예약 결정을 내리려면 노드 수를 Amazon EC2 Auto Scaling 그룹의 가용 영역 수와 동일하게 오버프로비저닝할 수도 있습니다. 이렇게 하면 스케줄러가 들어오는 pods에 가장 적합한 영역을 선택할 수 있습니다.

축소 제거 방지

일부 워크로드는 제거 비용이 많이 듭니다. 빅 데이터 분석, 기계 학습 태스크 및 테스트 러너는 완료하는 데 시간이 오래 걸릴 수 있으며 중단될 경우 다시 시작해야 합니다. Cluster Autoscaler는 scale-down-utilization-threshold 아래의 모든 노드를 축소하는 데 도움을 줍니다. 이렇게 하면 노드의 나머지 pods가 중단됩니다. 그러나 제거 비용이 많이 드는 pods가 Cluster Autoscaler에서 인식하는 레이블로 보호되도록 하여 이러한 일이 발생하지 않도록 할 수 있습니다. 이렇게 하려면 제거 비용이 많이 드는 pods에 cluster-autoscaler.kubernetes.io/safe-to-evict=false 레이블이 있는지 확인합니다.

Karpenter

Amazon EKS는 Karpenter 오픈 소스 자동 크기 조정 프로젝트를 지원합니다. 배포하려면 Karpenter 설명서를 참조하세요.

Karpenter 소개

Karpenter는 애플리케이션 가용성과 클러스터 효율성을 개선하는 데 도움이 되는 유연한 고성능 Kubernetes Cluster Autoscaler입니다. Karpenter는 1분 이내에 애플리케이션 로드의 변화에 대응하여 적절한 크기의 컴퓨팅 리소스(예: Amazon EC2 인스턴스)를 시작합니다. Kubernetes를 AWS와 통합함으로써 Karpenter는 워크로드의 요구 사항을 정확하게 충족하는 JIT(Just-In-Time) 컴퓨팅 리소스를 프로비저닝할 수 있습니다. Karpenter는 클러스터 워크로드의 특정 요구 사항을 기반으로 새로운 컴퓨팅 리소스를 자동으로 프로비저닝합니다. 여기에는 컴퓨팅, 스토리지, 가속화 및 예약 요구 사항이 포함됩니다. Amazon EKS는 Karpenter를 사용하는 클러스터를 지원하지만 Karpenter는 호환되는 모든 Kubernetes 클러스터에서 작동합니다.

Karpenter의 작동 방식

Karpenter는 클러스터의 수명 동안 들어오는 pods를 관찰하여 Kubernetes 스케줄러와 함께 작동합니다. 애플리케이션 가용성과 클러스터 활용도를 극대화하기 위해 노드를 시작하거나 종료합니다. 클러스터에 충분한 용량이 있으면 Kubernetes 스케줄러는 평소와 같이 들어오는 pods를 배치합니다. 클러스터의 기존 용량을 사용하여 예약할 수 없는 pods가 시작되면 Karpenter는 Kubernetes 스케줄러를 우회하고 제공업체의 컴퓨팅 서비스(예: Amazon EC2)로 직접 작업하여 해당 pods에 맞게 필요한 최소 컴퓨팅 리소스를 시작하고 pods를 프로비저닝된 노드에 바인딩합니다. pods가 제거되거나 다른 노드로 다시 예약되면 Karpenter는 활용도가 낮은 노드를 종료할 기회를 찾습니다. 클러스터에서 더 적은 수의 더 큰 노드를 실행하면 데몬 세트 및 Kubernetes 시스템 구성 요소의 오버헤드가 줄어들고 효율적인 빈 패킹을 위한 더 많은 기회가 제공됩니다.

사전 조건

Karpenter를 배포하려면 먼저 다음 사전 조건을 충족해야 합니다.

기존 Amazon EKS 클러스터 - 클러스터가 없는 경우 Amazon EKS 클러스터 생성 섹션을 참조하세요.
클러스터에 대한 기존 IAM OIDC 공급자입니다. 하나가 있는지 또는 생성해야 하는지 여부를 확인하려면 클러스터의 IAM OIDC 제공업체 생성 섹션을 참조하세요.
클러스터를 생성할 권한이 있는 IAM 보안 주체.
AWS CLI
kubectl 설치 또는 업데이트
Amazon EKS에 Helm 사용

원하는 경우 eksctl을 사용하여 Karpenter를 배포할 수 있습니다. eksctl 설치 또는 업데이트을 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

플랫폼 버전

Nodes(노드)