eks search iframe width 560 height 315 src https www youtube com embed FIBc8GkjFU0 title YouTube video player frameborder 0 allow accelerometer autoplay clipboard write encrypted media gyroscope picture in picture web share allowfullscreen iframe exclude true Cluster Autoscaler

Answer:
---
search:
  exclude: true
---

# 쿠버네티스 Cluster Autoscaler

<iframe width="560" height="315" src="https://www.youtube.com/embed/FIBc8GkjFU0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

## 개요

[쿠버네티스 Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)는 [SIG 오토스케일링](https://github.com/kubernetes/community/tree/master/sig-autoscaling)에서 유지 관리하는 인기 있는 클러스터 오토스케일링 솔루션입니다. 이는 클러스터에 리소스를 낭비하지 않고 파드를 스케줄링할 수 있는 충분한 노드가 있는지 확인하는 역할을 합니다. Cluster Autoscaler는 스케줄링에 실패한 파드와 활용도가 낮은 노드를 감시합니다. 그런 다음 클러스터에 변경 사항을 적용하기 전에 노드 추가 또는 제거를 시뮬레이션합니다. Cluster Autoscaler 내의 AWS 클라우드 공급자 구현은 EC2 Auto Scaling 그룹의 `.desireReplicas` 필드를 제어합니다.

![](./architecture.png)

이 가이드는 Cluster Autoscaler를 구성하고 조직의 요구 사항에 가장 적합한 절충안을 선택하기 위한 멘탈 모델을 제공합니다. 최상의 단일 구성은 없지만 성능, 확장성, 비용 및 가용성을 절충할 수 있는 구성 옵션 집합이 있습니다.또한 이 안내서는 AWS 구성을 최적화하기 위한 팁과 모범 사례를 제공합니다.

### 용어집

다음 용어는 이 문서 전체에서 자주 사용됩니다. 이런 용어는 광범위한 의미를 가질 수 있지만 이 문서의 목적상 아래 정의로만 제한됩니다.

**확장성**은 쿠버네티스 클러스터의 파드 및 노드 수가 증가할 때 Cluster Autoscaler가 얼마나 잘 작동하는지를 나타냅니다. 확장성 한계에 도달하면 Cluster Autoscaler의 성능과 기능이 저하됩니다. Cluster Autoscaler가 확장성 제한을 초과하면 더 이상 클러스터에서 노드를 추가하거나 제거할 수 없습니다.

**성능**은 Cluster Autoscaler가 규모 조정 결정을 얼마나 빨리 내리고 실행할 수 있는지를 나타냅니다. 완벽하게 작동하는 Cluster Autoscaler는 파드를 스케줄링할 수 없는 등의 이벤트에 대응하여 즉시 결정을 내리고 스케일링 조치를 트리거합니다.

**가용성**은 파드를 중단 없이 신속하게 스케줄링할 수 있다는 뜻이다. 여기에는 새로 생성된 파드를 스케줄링해야 하는 경우와 축소된 노드가 스케줄링된 나머지 파드를 종료하는 경우가 포함됩니다.

**비용**은 스케일-아웃 및 스케일-인 이벤트에 대한 결정에 따라 결정됩니다. 기존 노드의 활용도가 낮거나 들어오는 파드에 비해 너무 큰 새 노드를 추가하면 리소스가 낭비됩니다. 사용 사례에 따라 공격적인 규모 축소 결정으로 인해 파드를 조기에 종료하는 데 따른 비용이 발생할 수 있다.

**노드 그룹**은 클러스터 내 노드 그룹에 대한 추상적인 쿠버네티스 개념입니다. 이는 쿠버네티스 리소스는 아니지만 Cluster Autoscaler, 클러스터 API 및 기타 구성 요소에 추상화된 형태로 존재합니다. 노드 그룹 내의 노드는 레이블 및 테인트와 같은 속성을 공유하지만 여러 가용영역 또는 인스턴스 유형으로 구성될 수 있습니다.

**EC2 Auto Scaling 그룹**은 EC2의 노드 그룹 구현으로 사용할 수 있습니다. EC2 Auto Scaling 그룹은 쿠버네티스 클러스터에 자동으로 가입하고 쿠버네티스 API의 해당 노드 리소스에 레이블과 테인트를 적용하는 인스턴스를 시작하도록 구성되어 있습니다.

**EC2 관리형 노드 그룹**은 EC2에 노드 그룹을 구현한 또 다른 예입니다. EC2 오토스케일링 그룹을 수동으로 구성하는 복잡성을 없애고 노드 버전 업그레이드 및 정상적인 노드 종료와 같은 추가 관리 기능을 제공합니다.

### Cluster Autoscaler 운영

Cluster Autoscaler는 일반적으로 클러스터에 [디플로이먼트](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws/examples) 타입으로 설치됩니다. 고가용성을 보장하기 위해 [리더선출](https://en.wikipedia.org/wiki/Leader_election)를 사용하지만 작업은 하나의 레플리카에서만 수행됩니다. 수평적으로 확장할 수는 없습니다. 기본 설정의 경우 제공된 [설치지침](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html)을 사용하면 기본값이 기본적으로 작동하지만 몇 가지 유의해야 할 사항이 있습니다.

다음 사항을 확인하세요:

* Cluster Autoscaler 버전이 클러스터 버전과 일치하는지 확인합니다. 쿠버네티스 버전 별 공식 호환되는 버전 외에 타 버전의 호환성은 [테스트 되지 않거나 지원되지 않습니다](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/README.md#releases).
* 이 모드를 사용하지 못하게 하는 특정 고급 사용 사례가 없는 한 [Auto Discovery](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider/aws#auto-discovery-setup)를 활성화했는지 확인합니다.

### IAM 역할에 최소 접근 권한 적용

[Auto Discovery](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#Auto-discovery-setup)를 사용하는 경우, `autoscaling:SetDesiredCapacity` 및 `autoscaling:TerminateInstanceInAutoScalingGroup`작업을 현재 클러스터로 범위가 지정된 오토스케일링그룹으로 제한하여 최소 접근 권한을 사용하는 것을 권장합니다.

이렇게 하면 `--node-group-auto-discovery` 인수가 태그를 사용하여 클러스터의 노드 그룹으로 범위를 좁히지 않았더라도 (예: `k8s.io/cluster-autoscaler/<cluster-name>`) 한 클러스터에서 실행 중인 Cluster Autoscaler가 다른 클러스터의 노드 그룹을 수정할 수 없게 됩니다.

```json
{
    "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": "*"
        }
    ]
}
```

### 노드 그룹 구성

효과적인 오토스케일링은 클러스터의 노드 그룹 세트를 올바르게 구성하는 것에서 시작됩니다. 워크로드 전반에서 가용성을 극대화하고 비용을 절감하려면 올바른 노드 그룹 세트를 선택하는 것이 중요합니다. AWS는 다양한 사용 사례에 유연하게 적용할 수 있는 EC2 Auto Scaling 그룹을 사용하여 노드 그룹을 구현합니다. 하지만 Cluster Autoscaler는 노드 그룹에 대해 몇 가지 가정을 합니다. EC2 Auto Scaling 그룹 구성을 이런 가정과 일관되게 유지하면 원치 않는 동작을 최소화할 수 있습니다.

다음을 확인하십시오.

* 노드 그룹의 각 노드는 레이블, 테인트, 리소스와 같은 동일한 스케줄링 속성을 가집니다.
 * 혼합 인스턴스 정책의 경우 인스턴스 유형은 동일한 스펙의 CPU, 메모리 및 GPU이여야 합니다.
 * 정책에 지정된 첫 번째 인스턴스 유형은 스케줄링을 시뮬레이션하는 데 사용됩니다.
 * 정책에 더 많은 리소스가 포함된 추가 인스턴스 유형이 있는 경우 확장 후 리소스가 낭비될 수 있습니다.
 * 정책에 리소스가 적은 추가 인스턴스 유형이 있는 경우, 파드가 해당 인스턴스에서 일정을 예약하지 못할 수 있습니다.
* 노드 수가 적은 노드 그룹보다 노드가 많은 노드 그룹이 선호됩니다. 이는 확장성에 가장 큰 영향을 미칩니다.
* 가능하면 두 시스템 모두 지원을 제공하는 EC2 기능 (예: 지역, 혼합 인스턴스 정책) 을 선호하십시오.

*참고: [EKS 관리형 노드 그룹](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)을 사용하는 것을 권장합니다. 관리형 노드 그룹에는 자동 EC2 Auto Scaling 그룹 검색 및 정상적인 노드 종료와 같은 Cluster Autoscaler 기능을 비롯한 강력한 관리 기능이 포함되어 있습니다.*

## 성능 및 확장성 최적화

오토스케일링 알고리즘의 런타임 복잡성을 이해하면 [1,000개 노드](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/scalability_tests.md)를 초과하는 대규모 클러스터에서 계속 원활하게 작동하도록 Cluster Autoscaler를 튜닝하는 데 도움이 됩니다.

Cluster Autoscaler의 확장성을 조정하기 위한 주요한 요소는 프로세스에 제공되는 리소스, 알고리즘의 스캔 간격, 클러스터의 노드 그룹 수입니다. 이 알고리즘의 실제 런타임 복잡성에는 스케줄링 플러그인 복잡성 및 파드 수와 같은 다른 요인도 있습니다. 이런 파라미터는 클러스터의 워크로드에 자연스럽게 영향을 미치며 쉽게 조정할 수 없기 때문에 구성할 수 없는 파라미터로 간주됩니다.

Cluster Autoscaler는 파드, 노드, 노드 그룹을 포함하여 전체 클러스터의 상태를 메모리에 로드합니다. 알고리즘은 각 스캔 간격마다 스케줄링할 수 없는 파드를 식별하고 각 노드 그룹에 대한 스케줄링을 시뮬레이션합니다. 이런 요소를 조정하는 것은 서로 다른 장단점이 있으므로 사용 사례에 맞게 신중하게 고려해야 합니다.

### Cluster Autoscaler의 수직 오토스케일링

Cluster Autoscaler를 대규모 클러스터로 확장하는 가장 간단한 방법은 배포를 위한 리소스 요청을 늘리는 것입니다. 클러스터 크기에 따라 크게 다르지만 대규모 클러스터의 경우 메모리와 CPU를 모두 늘려야 합니다. 오토스케일링 알고리즘은 모든 파드와 노드를 메모리에 저장하므로 경우에 따라 메모리 사용량이 1GB보다 커질 수 있습니다. 리소스 증가는 일반적으로 수동으로 수행됩니다. 지속적인 리소스 튜닝으로 인해 운영상의 부담이 생긴다면 [Addon Resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer) 또는 [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) 사용을 고려해 보세요.

### 노드 그룹 수 줄이기

대규모 클러스터에서 Cluster Autoscaler가 계속 잘 작동하도록 하는 한 가지 방법은 노드 그룹 수를 최소화하는 것입니다. 팀 또는 응용 프로그램별로 노드 그룹을 구성하는 일부 조직에서는 이것이 어려울 수 있습니다. 이는 Kubernetes API에서 완벽하게 지원되지만 확장성에 영향을 미치는 Cluster Autoscaler 비권장 패턴으로 간주됩니다. 다중 노드 그룹(예: 스팟 또는 GPU)을 사용하는 데에는 여러 가지 이유가 있지만, 대부분의 경우 적은 수의 그룹을 사용하면서 동일한 효과를 얻을 수 있는 대안 설계가 있습니다.

다음을 확인합니다:

* 파드 격리는 노드 그룹이 아닌 네임스페이스를 사용하여 수행됩니다.
 * 신뢰도가 낮은 멀티테넌트 클러스터에서는 불가능할 수 있습니다.
 * 파드 리소스 요청(request)과 리소스 제한(limit)은 리소스 경합을 방지하기 위해 적절하게 설정되었다.
 * 인스턴스 유형이 클수록 빈 패킹이 최적화되고 시스템 파드 오버헤드가 줄어듭니다.
* NodeTaints 또는 NodeSelector는 파드를 예외적으로 스케줄링하는 데 사용되는 것이지, 규칙이 아닙니다.
* 리전 리소스는 멀티 가용영역을 포함하는 단일 EC2 Auto Scaling 그룹으로 정의됩니다.

### 스캔 간격 줄이기

스캔 간격(예: 10초)을 짧게 설정하면 파드를 스케줄링할 수 없을 때 Cluster Autoscaler가 최대한 빨리 응답할 수 있습니다. 하지만 스캔할 때마다 쿠버네티스 API 및 EC2 Auto Scaling 그룹 또는 EKS 관리형 노드 그룹 API에 대한 API 호출이 많이 발생합니다. 이런 API 호출로 인해 Kubernetes 컨트롤 플레인의 속도가 제한되거나 서비스를 사용할 수 없게 될 수도 있습니다.

디폴트 스캔 간격은 10초이지만 AWS에서 새로운 노드를 시작하는 데는 새 인스턴스를 시작하는 등 훨씬 더 오랜 시간이 소요됩니다. 즉, 전체 스케일업 시간을 크게 늘리지 않고도 스캔 간격을 늘릴 수 있습니다. 예를 들어 노드를 시작하는 데 2분이 걸리는 경우 스캔 간격을 1분으로 변경하면 API 호출이 6배 줄어들고  확장이 38% 느려지는 절충점이 발생합니다.

### 노드 그룹 간 샤딩

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 그룹을 확장할 수 없는 경우 용량 부족 오류가 발생합니다. 여러 인스턴스 패밀리를 선택하여 다양성을 극대화하면 많은 스팟 용량 풀을 활용하여 원하는 규모를 달성할 가능성이 높아지고 스팟 인스턴스 중단이 클러스터 가용성에 미치는 영향을 줄일 수 있습니다. 스팟 인스턴스를 사용한 혼합 인스턴스 정책은 노드 그룹 수를 늘리지 않고도 다양성을 높일 수 있는 좋은 방법입니다. 보장된 리소스가 필요한 경우 스팟 인스턴스 대신 온디맨드 인스턴스를 사용하세요.

혼합 인스턴스 정책을 구성할 때는 모든 인스턴스 유형의 리소스 용량이 비슷해야 합니다. 오토스케일러의 스케줄링 시뮬레이터는 혼합 인스턴스 정책의 첫 번째 인스턴스 유형을 사용합니다. 후속 인스턴스 유형이 더 크면 확장 후 리소스가 낭비될 수 있습니다. 크기가 작으면 용량 부족으로 인해 파드가 새 인스턴스를 스케쥴되지 못할 수 있습니다. 예를 들어 M4, M5, M5a 및 M5n 인스턴스는 모두 비슷한 양의 CPU와 메모리를 가지고 있으며 혼합 인스턴스 정책을 적용하기에 적합합니다.[EC2 Instance Selector](https://github.com/aws/amazon-ec2-instance-selector) 도구를 사용하면 유사한 인스턴스 유형을 식별할 수 있습니다.

![](./spot_mix_instance_policy.jpg)

온디맨드 및 스팟 용량을 별도의 EC2 Auto Scaling 그룹으로 분리하는 것이 좋습니다. 스케줄링 속성이 근본적으로 다르기 때문에 [기본 용량 전략](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-purchase-options.html#asg-instances-distribution)을 사용하는 것보다 이 방법을 사용하는 것이 좋습니다. 스팟 인스턴스는 (EC2에서 용량을 다시 확보해야 할 때) 언제든지 중단되므로 사용자는 명환한 선점 동작을 위해 선점 가능한 노드를 테인트시킵니다. 이런 경우에 파드는 명시적인 톨러레이션이 요구됩니다. 이런 테인트로 인해 노드의 스케줄 속성이 달라지므로 여러 EC2 Auto Scaling 그룹으로 분리해야 합니다.

Cluster Autoscaler에는 [Expanders](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-expanders)라는 개념이 있으며, 확장할 노드 그룹을 선택하기 위한 다양한 전략을 제공합니다.`--expander=least-waste` 전략은 일반적인 용도의 기본 전략으로, 스팟 인스턴스 다양화를 위해 여러 노드 그룹을 사용하려는 경우 (위 이미지 설명 참조) 조정 활동 이후에 가장 잘 활용되는 그룹을 확장하여 노드 그룹의 비용을 더욱 최적화하는 데 도움이 될 수 있습니다.

### 노드 그룹 / ASG 우선 순위 지정

Priority expander를 사용하여 우선순위 기반 오토스케일링을 구성할 수도 있습니다. `--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 그룹을 확장하려고 시도합니다. 이 작업이 `--max-node-provision-time` 내에 성공하지 못하면 *p2-node-group*이라는 이름과 일치하는 EC2 Auto Scaling 그룹을 확장하려고 시도합니다.
이 값은 기본적으로 15분으로 설정되며 노드 그룹 선택의 속도를 높이기 위해 줄일 수 있습니다. 하지만 값이 너무 낮으면 불필요한 크기 조정이 발생할 수 있습니다.

### 오버프로비저닝

Cluster Autoscaler는 필요한 경우에만 클러스터에 노드를 추가하고 사용하지 않을 때는 노드를 제거함으로써 비용을 최소화합니다. 이는 많은 파드가 스케줄링되기 전에 노드 확장이 완료될 때까지 기다려야 하기 때문에 배포 지연 시간에 상당한 영향을 미칩니다. 노드를 사용할 수 있게 되기까지 몇 분이 걸릴 수 있으며, 이로 인해 파드 스케줄링 지연 시간이 평소보다 몇 배나 증가할 수 있습니다.

이런 스케줄링 지연은 [오버프로비저닝](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#how-can-i-configure-overprovisioning-with-cluster-autoscaler)을 사용하면 비용은 증가하나 완화될 수 있습니다. 오버프로비저닝은 클러스터 내 공간을 차지하는 우선 순위가 낮은(보통 음수) 임시 파드를 사용하여 구현됩니다. 새로 생성된 파드를 unschedulable 상태이고 우선 순위가 더 높은 경우, 임시 파드를 선점하여 공간을 확보합니다. 그러면 임시 파드는 unschedulable 상태가 되고 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 볼륨

영구 스토리지는 데이터베이스 또는 분산 캐시와 같은 스테이트풀(stateful) 애플리케이션을 구축하는 데 매우 중요합니다. [EBS 볼륨](https://aws.amazon.com/premiumsupport/knowledge-center/eks-persistent-storage/)은 쿠버네티스에서 이런 사용 사례를 지원하지만 특정 영역으로 제한됩니다. 각 AZ별로 별도의 EBS 볼륨을 사용하여 여러 AZ에서 샤딩하면 애플리케이션의 가용성이 높아질 수 있습니다. 그러면 Cluster Autoscaler가 EC2 오토스케일링 그룹 스케일링의 균형을 맞출 수 있습니다.

다음을 확인하십시오.

* 노드 그룹 밸런싱은 `balance-similar-node-groups=true`로 설정하여 활성화됩니다.
* 노드 그룹은 가용영역과 EBS 볼륨이 다르다는 점을 제외하면 동일한 설정으로 구성됩니다.

### 공동 스케줄링

머신 러닝 분산 트레이닝 작업은 동일 가용영역에 노드 구성을 통해 레이턴시를 최소화함으로써 상당한 이점을 얻을 수 있습니다. 이런 워크로드는 특정 영역에 여러 개의 파드를 배포합니다. 이는 모든 공동 스케줄링된 파드에 파드 어피니티를 설정하거나 `topologyKey: failure-domain.beta.kubernetes.io/zone`을 사용하여 노드 어피니티를 설정함으로써 구성할 수 있다. 그러면 Cluster Autoscaler가 수요에 맞춰 특정 영역을 확장합니다. 가용영역당 하나씩 여러 EC2 Auto Scaling 그룹을 할당하여 함께 예약된 전체 워크로드에 대해 페일오버를 활성화할 수 있습니다.

다음을 확인하십시오.

* `balance-similar-node-groups=false`를 설정하여 노드 그룹 밸런싱을 구성할 수 있습니다.
* 클러스터가 리전 내 멀티 가용영역 노드 그룹과 단일 가용영역 노드 그룹으로 구성된 경우 [노드 어피니티](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 또는 [파드 선점(Preemption)](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)을 사용되어야 합니다.
 * [노드 어피니티](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)를 사용하여 멀티 가용영역 파드가 단일 가용영역 노드 그룹에 (또는 그 반대의 경우) 스케쥴링되지 않도록 하여야 합니다.
 * 단일 가용영역에 배포되어야 되는 파드가 멀티 가용영역 노드 그룹에 스케줄링되면 멀티 가용영역 파드의 용량 불균형을 초래할 수 있습니다.
 * 단일 가용영역 워크로드가 중단 및 재배치를 허용할 수 있는 경우, [Pod Preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)을 구성하여 지역적으로 규모가 조정된 파드가 경쟁이 덜한 구역을 선점하고 일정을 조정할 수 있도록 하십시오.

### 가속 하드웨어

일부 클러스터는 GPU와 같은 특수 하드웨어 가속기를 활용합니다. 스케일아웃 시 가속기 장치 플러그인이 리소스를 클러스터에 알리는 데 몇 분 정도 걸릴 수 있습니다. Cluster Autoscaler는 이 노드에 가속기가 있을 것이라고 시뮬레이션했지만, 가속기가 준비되고 노드의 가용 리소스를 업데이트하기 전까지는 노드에서 보류 중인 파드를 스케줄링할 수 없습니다. 이로 인해 [반복적인 불필요한 확장](https://github.com/kubernetes/kubernetes/issues/54959)이 발생할 수 있습니다.

또한 가속기가 있고 CPU 또는 메모리 사용률이 높은 노드는 가속기를 사용하지 않더라도 축소가 고려되지 않습니다. 이 동작은 가속기의 상대적 비용 때문에 비용이 많이 들 수 있습니다. 대신 Cluster Autoscaler는 비어있는 가속기가 있는 경우 노드 축소를 고려하는 특수 규칙을 적용할 수 있습니다.

이런 경우에 올바르게 동작하도록 가속기 노드가 클러스터에 조인하기 전에 해당 노드 kubelet에 레이블을 추가하여 설정할 수 있습니다. Cluster Autoscaler는 이 레이블을 통해 가속기 최적화 동작을 트리거합니다.

다음을 확인하세오.

* GPU 노드용 Kubelet은 `--node-labels k8s.amazonaws.com/accelerator=$ACCELERATOR_TYPE`으로 구성되어 있습니다.
* 가속기가 있는 노드는 위에서 언급한 것과 동일한 스케줄링 속성 규칙을 준수합니다.

### 0부터 스케일링

Cluster Autoscaler(CA)는 노드 그룹을 0까지 또는 0부터 확장할 수 있어 비용을 크게 절감할 수 있습니다. CA는 오토 스케일링 그룹(ASG)의 LaunchConfiguration 또는 LaunchTemplate에 지정된 인스턴스 유형을 검사하여 ASG의 CPU, 메모리 및 GPU 리소스를 파악합니다. 일부 파드는 LaunchConfiguration에서 검색할 수 없는 `WindowsENI`, `PrivateIPv4Address`, NodeSelector 또는 테인트와 같은 추가 리소스가 필요합니다. Cluster Autoscaler는 EC2 ASG의 태그에서 이런 요소를 발견하여 이런 요소를 처리할 수 있습니다. 예를 들면 다음과 같습니다.

```
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](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-are-the-parameters-to-ca)에서 확인할 수 있습니다.

|  |  |  |
|-|-|-|
| 파라미터 | 설명 | Default |
| scan-interval | 클러스터 확장 또는 축소를 위한 재평가 빈도 | 10 초 |
| max-empty-bulk-delete | 동시에 삭제할 수 있는 빈 노드의 최대 수 | 10 |
| scale-down-delay-after-add | 스케일 업 후 스케일 다운 평가가 재개되는 시간 | 10 분 |
| scale-down-delay-after-delete | 노드 삭제 후 스케일 다운 평가가 재개되는 시간, 기본값은 scan-interval | 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 | 이전 반복의 일부 후보가 더 이상 유효하지 않을 경우 축소할 수 있는 비어 있지 않은 추가 후보로 간주되는 최소 노드 수. 추가 후보의 풀 크기를 계산할 때는 `최대값 (노드수 * scale-down-candidates-pool-ratio, scale-down-candidates-pool-min-count) `으로 계산합니다. | 50 |

## 추가 리소스

이 페이지에는 Cluster Autoscaler 프레젠테이션 및 데모 목록이 들어 있습니다. 여기에 프레젠테이션이나 데모를 추가하려면 풀 리퀘스트를 보내주세요.

| 프레젠테이션 데모 | 발표자 |
| ------------ | ------- |
| [Autoscaling and Cost Optimization on Kubernetes: From 0 to 100](https://sched.co/Zemi) | Guy Templeton, Skyscanner & Jiaxin Shan, Amazon |
| [SIG-Autoscaling Deep Dive](https://youtu.be/odxPyW_rZNQ) | Maciek Pytel & Marcin Wielgus |

## 참고 자료

* [https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)
* [https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md)
* [https://github.com/aws/amazon-ec2-instance-selector](https://github.com/aws/amazon-ec2-instance-selector)
* [https://github.com/aws/aws-node-termination-handler](https://github.com/aws/aws-node-termination-handler)

search    exclude  true               Cluster Autoscaler   iframe width  560  height  315  src  https   www youtube com embed FIBc8GkjFU0  title  YouTube video player  frameborder  0  allow  accelerometer  autoplay  clipboard write  encrypted media  gyroscope  picture in picture  web share  allowfullscreen   iframe                 Cluster Autoscaler  https   github com kubernetes autoscaler tree master cluster autoscaler    SIG         https   github com kubernetes community tree master sig autoscaling                                                                                Cluster Autoscaler                                                                                Cluster Autoscaler    AWS              EC2 Auto Scaling       desireReplicas                    architecture png          Cluster Autoscaler                                                                                AWS                                                                                Cluster Autoscaler                                   Cluster Autoscaler                 Cluster Autoscaler                                                          Cluster Autoscaler                                                   Cluster Autoscaler                                                                                Cluster Autoscaler       API                                                                                EC2 Auto Scaling       EC2                         EC2 Auto Scaling                                 API                                                      EC2              EC2                        EC2                                                                                Cluster Autoscaler     Cluster Autoscaler                       https   github com kubernetes autoscaler tree master cluster autoscaler cloudprovider aws examples                                   https   en wikipedia org wiki Leader election                                                                        https   docs aws amazon com eks latest userguide cluster autoscaler html                                                                 Cluster Autoscaler                                                                                https   github com kubernetes autoscaler blob master cluster autoscaler README md releases                                          Auto Discovery  https   github com kubernetes autoscaler tree master cluster autoscaler cloudprovider aws auto discovery setup                      IAM                   Auto Discovery  https   github com kubernetes autoscaler blob master cluster autoscaler cloudprovider aws README md Auto discovery setup             autoscaling SetDesiredCapacity     autoscaling TerminateInstanceInAutoScalingGroup                                                                          node group auto discovery                                                k8s io cluster autoscaler  cluster name                   Cluster Autoscaler                                    json        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                                                                                AWS                           EC2 Auto Scaling                            Cluster Autoscaler                          EC2 Auto Scaling                                                                                CPU        GPU                                                                                EC2                                         EKS            https   docs aws amazon com eks latest userguide managed node groups html                                 EC2 Auto Scaling                        Cluster Autoscaler                                                                              1 000      https   github com kubernetes autoscaler blob master cluster autoscaler proposals scalability tests md                                 Cluster Autoscaler                   Cluster Autoscaler                                                                                Cluster Autoscaler                                                                                Cluster Autoscaler             Cluster Autoscaler                                                                                CPU                                                                 1GB                                                                        Addon Resizer  https   github com kubernetes autoscaler tree master addon resizer      Vertical Pod Autoscaler  https   github com kubernetes autoscaler tree master vertical pod autoscaler                                            Cluster Autoscaler                                                                                Kubernetes API                           Cluster Autoscaler                                   GPU                                                                                request          limit                                                                                NodeTaints    NodeSelector                                                                    EC2 Auto Scaling                                      10                             Cluster Autoscaler                                       API   EC2 Auto Scaling       EKS           API     API                  API        Kubernetes                                                         10     AWS                                                                                2                 1         API     6            38                                    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                                                                                M4  M5  M5a   M5n                 CPU                                        EC2 Instance Selector  https   github com aws amazon ec2 instance selector                                           spot mix instance policy jpg                     EC2 Auto Scaling                                                      https   docs aws amazon com autoscaling ec2 userguide asg purchase options html asg instances distribution                                          EC2                                                                                EC2 Auto Scaling                 Cluster Autoscaler    Expanders  https   github com kubernetes autoscaler blob master cluster autoscaler FAQ md what are expanders                                                 expander least waste                                                                                ASG           Priority expander                                       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                           max node provision time               p2 node group              EC2 Auto Scaling                             15                                                                                Cluster Autoscaler                                                                                https   github com kubernetes autoscaler blob master cluster autoscaler FAQ md how can i configure overprovisioning with cluster autoscaler                                                                                unschedulable                                                        unschedulable        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                                        stateful                            EBS     https   aws amazon com premiumsupport knowledge center eks persistent storage                                             AZ       EBS             AZ                                     Cluster Autoscaler  EC2                                                            balance similar node groups true                               EBS                                                                                topologyKey  failure domain beta kubernetes io zone                                      Cluster Autoscaler                                    EC2 Auto Scaling                                                                 balance similar node groups false                                                                                https   kubernetes io docs concepts scheduling eviction assign pod node  affinity and anti affinity            Preemption   https   kubernetes io docs concepts configuration pod priority preemption                            https   kubernetes io docs concepts scheduling eviction assign pod node  affinity and anti affinity                                                                                Pod Preemption  https   kubernetes io docs concepts configuration pod priority preemption                                                                                GPU                                                                                Cluster Autoscaler                                                                                https   github com kubernetes kubernetes issues 54959                           CPU                                                                                Cluster Autoscaler                                                                                kubelet                        Cluster Autoscaler                                               GPU     Kubelet     node labels k8s amazonaws com accelerator  ACCELERATOR TYPE                                                                    0         Cluster Autoscaler CA          0      0                               CA             ASG   LaunchConfiguration    LaunchTemplate                    ASG  CPU        GPU                    LaunchConfiguration             WindowsENI    PrivateIPv4Address   NodeSelector                           Cluster Autoscaler  EC2 ASG                                                           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  https   github com kubernetes autoscaler blob master cluster autoscaler FAQ md what are the parameters to ca                                                  Default     scan interval                              10       max empty bulk delete                             10     scale down delay after add                                10       scale down delay after delete                                    scan interval   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                                                                                scale down candidates pool ratio  scale down candidates pool min count               50                       Cluster Autoscaler                                                                                Autoscaling and Cost Optimization on Kubernetes  From 0 to 100  https   sched co Zemi    Guy Templeton  Skyscanner   Jiaxin Shan  Amazon      SIG Autoscaling Deep Dive  https   youtu be odxPyW rZNQ    Maciek Pytel   Marcin Wielgus                 https   github com kubernetes autoscaler blob master cluster autoscaler FAQ md  https   github com kubernetes autoscaler blob master cluster autoscaler FAQ md     https   github com kubernetes autoscaler blob master cluster autoscaler cloudprovider aws README md  https   github com kubernetes autoscaler blob master cluster autoscaler cloudprovider aws README md     https   github com aws amazon ec2 instance selector  https   github com aws amazon ec2 instance selector     https   github com aws aws node termination handler  https   github com aws aws node termination handler


Answer:
---
search:
  exclude: true
---

# 워크로드

워크로드는 클러스터를 확장할 수 있는 규모에 영향을 미칩니다. 쿠버네티스 API를 많이 사용하는 워크로드는 단일 클러스터에서 보유할 수 있는 워크로드의 총량을 제한하지만, 부하를 줄이기 위해 변경할 수 있는 몇 가지 기본값이 있습니다.

쿠버네티스 클러스터의 워크로드는 쿠버네티스 API와 통합되는 기능(예: Secrets 및 ServiceAccount)에 액세스할 수 있지만, 이런 기능이 항상 필요한 것은 아니므로 사용하지 않는 경우 비활성화해야 합니다.워크로드 액세스와 쿠버네티스 컨트롤 플레인에 대한 종속성을 제한하면 클러스터에서 실행할 수 있는 워크로드 수가 증가하고 워크로드에 대한 불필요한 액세스를 제거하고 최소 권한 관행을 구현하여 클러스터의 보안을 개선할 수 있습니다. 자세한 내용은 [보안 모범 사례](https://aws.github.io/aws-eks-best-practices/security/docs/)를 참고하세요.

## 파드 네트워킹에 IPv6 사용하기

VPC를 IPv4에서 IPv6으로 전환할 수 없으므로 클러스터를 프로비저닝하기 전에 IPv6를 활성화하는 것이 중요합니다. 다만 VPC에서 IPv6를 활성화한다고 해서 반드시 사용해야 하는 것은 아니며, 파드 및 서비스가 IPv6를 사용하는 경우에도 IPv4 주소를 오가는 트래픽을 라우팅할 수 있습니다. 자세한 내용은 [EKS 네트워킹 모범 사례](https://aws.github.io/aws-eks-best-practices/networking/index/)를 참고하세요.

[클러스터에서 IPv6 사용하기 튜토리얼](https://docs.aws.amazon.com/eks/latest/userguide/cni-ipv6.html)를 사용하면 가장 일반적인 클러스터 및 워크로드 확장 제한을 피할 수 있습니다. IPv6는 사용 가능한 IP 주소가 없어 파드와 노드를 생성할 수 없는 IP 주소 고갈을 방지합니다. 또한 노드당 ENI 어태치먼트 수를 줄여 파드가 IP 주소를 더 빠르게 수신하므로 노드당 성능도 개선되었습니다. [VPC CNI의 IPv4 Prefix 모드](https://aws.github.io/aws-eks-best-practices/networking/prefix-mode/)를 사용하여 유사한 노드 성능을 얻을 수 있지만, 여전히 VPC에서 사용할 수 있는 IP 주소가 충분한지 확인해야 합니다.

## 네임스페이스당 서비스 수 제한

[네임스페이스의 최대 서비스 수는 5,000개이고 클러스터의 최대 서비스 수는 10,000개](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) 입니다. 워크로드와 서비스를 구성하고, 성능을 높이고, 네임스페이스 범위 리소스가 연쇄적으로 영향을 받지 않도록 하려면 네임스페이스당 서비스 수를 500개로 제한하는 것이 좋습니다.

kube-proxy를 사용하여 노드당 생성되는 IP 테이블 규칙의 수는 클러스터의 총 서비스 수에 따라 증가합니다.수천 개의 IP 테이블 규칙을 생성하고 이런 규칙을 통해 패킷을 라우팅하면 노드의 성능이 저하되고 네트워크 지연 시간이 늘어납니다.

네임스페이스당 서비스 수가 500개 미만인 경우 단일 애플리케이션 환경을 포함하는 쿠버네티스 네임스페이스를 생성하십시오. 이렇게 하면 서비스 검색 제한을 피할 수 있을 만큼 서비스 검색 크기가 작아지고 서비스 이름 충돌을 방지하는 데도 도움이 됩니다. 애플리케이션 환경(예: dev, test, prod) 은 네임스페이스 대신 별도의 EKS 클러스터를 사용해야 합니다.

## Elastic Load Balancer 할당량 이해

서비스를 생성할 때 사용할 로드 밸런싱 유형(예: 네트워크 로드밸런서 (NLB) 또는 애플리케이션 로드밸런서 (ALB)) 를 고려하세요. 각 로드밸런서 유형은 서로 다른 기능을 제공하며 [할당량](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-limits.html)이 다릅니다. 기본 할당량 중 일부는 조정할 수 있지만 일부 할당량 최대값은 변경할 수 없습니다. 계정 할당량 및 사용량을 보려면 AWS 콘솔의 [서비스 할당량 대시보드](http://console.aws.amazon.com/servicequotas)를 참조하십시오.

예를 들어, 기본 ALB 목표는 1000입니다. 엔드포인트가 1,000개가 넘는 서비스가 있는 경우 할당량을 늘리거나 서비스를 여러 ALB로 분할하거나 쿠버네티스 인그레스(Ingress)를 사용해야 합니다. 기본 NLB 대상은 3000이지만 AZ당 500개 대상으로 제한됩니다. 클러스터에서 NLB 서비스에 대해 500개 이상의 파드를 실행하는 경우 여러 AZ를 사용하거나 할당량 한도 증가를 요청해야 합니다.

서비스에 연결된 로드밸런서를 사용하는 대신 [인그레스 컨트롤러](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) 를 사용할 수 있습니다. AWS Load Balancer Controller는 수신 리소스용 ALB를 생성할 수 있지만, 클러스터에서 전용 컨트롤러를 실행하는 것도 고려해 볼 수 있습니다.클러스터 내 수신 컨트롤러를 사용하면 클러스터 내에서 역방향 프록시를 실행하여 단일 로드밸런서에서 여러 쿠버네티스 서비스를 노출할 수 있습니다. 컨트롤러는 [Gateway API](https://gateway-api.sigs.k8s.io/) 지원과 같은 다양한 기능을 제공하므로 워크로드의 수와 규모에 따라 이점이 있을 수 있습니다.

## Route 53, Global Accelerator, 또는 CloudFront 사용하기

여러 로드밸런서를 사용하는 서비스를 단일 엔드포인트로 사용하려면 [Amazon CloudFront](https://aws.amazon.com/cloudfront/), [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/) 또는 [Amazon Route 53](https://aws.amazon.com/route53/)를 사용하여 모든 로드밸런서를 단일 고객 대상 엔드포인트로 노출해야 합니다. 각 옵션에는 서로 다른 이점이 있으며 필요에 따라 개별적으로 또는 함께 사용할 수 있습니다.

Route 53은 공통 이름으로 여러 로드밸런서를 노출할 수 있으며 할당된 가중치에 따라 각 로드밸런서에 트래픽을 전송할 수 있습니다. [DNS 가중치](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-values-weighted.html#rrsets-values-weighted-weight)설명서에 자세한 내용을 확인할 수 있으며 [쿠버네티스 외부 DNS 컨트롤러](https://github.com/kubernetes-sigs/external-dns)를 사용하여 이를 구현하는 방법은 [AWS Load Balancer Controller 설명서](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/integrations/external_dns/#usage)에서 확인할 수 있습니다.

Global Accelerator터는 요청 IP 주소를 기반으로 가장 가까운 지역으로 워크로드를 라우팅할 수 있습니다. 이는 여러 지역에 배포되는 워크로드에 유용할 수 있지만 단일 지역의 단일 클러스터로의 라우팅을 개선하지는 않습니다. Route 53을 Global Accelerator터와 함께 사용하면 가용영역을 사용할 수 없는 경우 상태 점검 및 자동 장애 조치와 같은 추가적인 이점이 있습니다. Route 53과 함께 Global Accelerator터를 사용하는 예는 [이 블로그 게시물](https://aws.amazon.com/blogs/containers/operating-a-multi-regional-stateless-application-using-amazon-eks/)에서 확인할 수 있습니다.

CloudFront는 Route 53 및 Global Accelerator와 함께 사용하거나 단독으로 트래픽을 여러 목적지로 라우팅하는 데 사용할 수 있습니다. CloudFront는 오리진 소스에서 제공되는 자산을 캐시하므로 제공하는 대상에 따라 대역폭 요구 사항을 줄일 수 있습니다.

## 엔드포인트(Endpoints) 대신에 엔드포인트 슬라이스(EndpointSlices) 사용하기

서비스 레이블과 일치하는 파드를 발견할 때는 엔드포인트 대신 [엔드포인트 슬라이스](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)를 사용해야 합니다. 엔드포인트는 서비스를 소규모로 노출할 수 있는 간단한 방법이었지만, 대규모 서비스가 자동으로 확장되거나 업데이트되면 쿠버네티스 컨트롤 플레인에서 많은 트래픽이 발생합니다. 엔드포인트슬라이스에는 토폴로지 인식 힌트와 같은 기능을 사용할 수 있는 자동 그룹화 기능이 있습니다.

모든 컨트롤러가 기본적으로 엔드포인트슬라이스를 사용하는 것은 아닙니다. 컨트롤러 설정을 확인하고 필요한 경우 활성화해야 합니다. [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/deploy/configurations/#controller-command-line-flags)의 경우 엔드포인트슬라이스를 사용하려면 `--enable-endpoint-slices` 선택적 플래그를 활성화해야 합니다.

## 가능하다면 변경 불가(immutable)하고 외부(external) 시크릿 사용하기

kubelet은 해당 노드의 파드에 대한 볼륨에서 사용되는 시크릿의 현재 키와 값을 캐시에 보관한다. kubelet은 시크릿을 감시하여 변경 사항을 탐지합니다. 클러스터가 확장됨에 따라 시계의 수가 증가하면 API 서버 성능에 부정적인 영향을 미칠 수 있습니다.

시크릿의 감시 수를 줄이는 두 가지 전략이 있습니다.

* 쿠버네티스 리소스에 액세스할 필요가 없는 애플리케이션의 경우 AutoMountServiceAccountToken: false를 설정하여 서비스 어카운트 시크릿 자동 탑재를 비활성화할 수 있습니다.
* 애플리케이션 암호가 정적이어서 향후 수정되지 않을 경우 [암호를 변경 불가능](https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable)으로 표시하십시오. kubelet은 변경 불가능한 비밀에 대한 API 감시 기능을 유지하지 않습니다.

서비스 어카운트을 파드에 자동으로 마운트하는 것을 비활성화하려면 워크로드에서 다음 설정을 사용할 수 있습니다. 특정 워크로드에 서비스 어카운트이 필요한 경우 이런 설정을 재정의할 수 있습니다.

```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app
automountServiceAccountToken: true
```

클러스터의 암호 수가 제한인 10,000개를 초과하기 전에 모니터링하세요. 다음 명령을 사용하여 클러스터의 총 암호 수를 확인할 수 있습니다. 클러스터 모니터링 도구를 통해 이 한도를 모니터링해야 합니다.

```
kubectl get secrets -A | wc -l
```

이 한도에 도달하기 전에 클러스터 관리자에게 알리도록 모니터링을 설정해야 합니다.[Secrets Store CSI 드라이버](https://secrets-store-csi-driver.sigs.k8s.io/)와 함께 [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/) 또는 [Hashicorp Vault](https://www.vaultproject.io/)와 같은 외부 비밀 관리 옵션을 사용하는 것을 고려해 보십시오.

## 배포 이력 제한

클러스터에서 이전 객체가 계속 추적되므로 파드를 생성, 업데이트 또는 삭제할 때 속도가 느려질 수 있습니다. [디플로이먼트](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#clean-up-policy)의 `therevisionHistoryLimit`을 줄이면 구형 레플리카셋을 정리하여 쿠버네티스 컨트롤러 매니저가 추적하는 오브젝트의 총량을 줄일 수 있습니다. 디플로이먼트의 기본 기록 한도는 10개입니다.

클러스터가 CronJobs나 다른 메커니즘을 통해 많은 수의 작업 개체를 생성하는 경우, [`TTLSecondsFinished` 설정](https://kubernetes.io/docs/concepts/workloads/controllers/ttlafterfinished/)을 사용하여 클러스터의 오래된 파드를 자동으로 정리해야 합니다. 이렇게 하면 지정된 시간이 지나면 성공적으로 실행된 작업이 작업 기록에서 제거됩니다.

## enableServiceLinks를 기본으로 비활성화하기

파드가 노드에서 실행될 때, kubelet은 각 활성 서비스에 대한 환경 변수 세트를 추가합니다. 리눅스 프로세스에는 환경에 맞는 최대 크기가 있으며 네임스페이스에 서비스가 너무 많으면 이 크기에 도달할 수 있습니다. 네임스페이스당 서비스 수는 5,000개를 초과할 수 없습니다. 그 이후에는 서비스 환경 변수 수가 셸 한도를 초과하여 시작 시 파드가 크래시를 일으키게 됩니다.

파드가 서비스 검색에 서비스 환경 변수를 사용하지 않아야 하는 다른 이유도 있습니다. 환경 변수 이름 충돌, 서비스 이름 유출, 전체 환경 크기 등이 있습니다. 서비스 엔드포인트를 검색하려면 CoreDNS를 사용해야 합니다.

## 리소스당 동적 어드미션 웹훅(Webhook) 제한하기

[Dynamic Admission Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)에는 어드미션 웹훅과 뮤테이팅(Mutating) 웹훅이 포함됩니다. 쿠버네티스 컨트롤 플레인에 속하지 않는 API 엔드포인트로, 리소스가 쿠버네티스 API로 전송될 때 순서대로 호출됩니다. 각 웹훅의 기본 제한 시간은 10초이며, 웹훅이 여러 개 있거나 제한 시간이 초과된 경우 API 요청에 걸리는 시간이 늘어날 수 있습니다.

특히 가용영역 장애 발생 시 웹훅의 가용성이 높은지 확인하고 [FailurePolicy](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#failure-policy)가 리소스를 거부하거나 실패를 무시하도록 적절하게 설정되어 있는지 확인하세요. --dry-run kubectl 명령이 웹훅을 우회하도록 허용하여 필요하지 않을 때는 웹훅을 호출하지 마십시오.

```
apiVersion: admission.k8s.io/v1
kind: AdmissionReview
request:
  dryRun: False
```

웹훅를 변경하면 리소스를 자주 연속적으로 수정할 수 있습니다. 뮤테이팅 웹훅이 5개 있고 리소스 50개를 배포하면 수정된 리소스의 이전 버전을 제거하기 위해 5분마다 컴팩션이 실행될 때까지 etcd는 각 리소스의 모든 버전을 저장합니다. 이 시나리오에서 etcd가 대체된 리소스를 제거하면 etcd에서 200개의 리소스 버전이 제거되며 리소스 크기에 따라 15분마다 조각 모음이 실행될 때까지 etcd 호스트에서 상당한 공간을 사용할 수 있습니다.

이런 조각 모음(defragmentation)으로 인해 etcd가 일시 중지되어 쿠버네티스 API 및 컨트롤러에 다른 영향을 미칠 수 있습니다. 대규모 리소스를 자주 수정하거나 수백 개의 리소스를 순식간에 연속해서 수정하는 것은 피해야 합니다.

search    exclude  true                                                        API                                                                                API             Secrets   ServiceAccount                                                                                https   aws github io aws eks best practices security docs                        IPv6       VPC  IPv4   IPv6                               IPv6                     VPC   IPv6                                          IPv6            IPv4                                    EKS             https   aws github io aws eks best practices networking index                    IPv6            https   docs aws amazon com eks latest userguide cni ipv6 html                                              IPv6         IP                         IP                      ENI                 IP                                   VPC CNI  IPv4 Prefix     https   aws github io aws eks best practices networking prefix mode                                  VPC            IP                                                             5 000                    10 000   https   github com kubernetes community blob master sig scalability configs and limits thresholds md                                                                                500                  kube proxy                IP                                          IP                                                                                500                                                                                dev  test  prod                  EKS                     Elastic Load Balancer                                                 NLB                   ALB                                             https   docs aws amazon com elasticloadbalancing latest application load balancer limits html                                                                          AWS                    http   console aws amazon com servicequotas                      ALB     1000            1 000                                   ALB                   Ingress                NLB     3000    AZ  500                     NLB         500                     AZ                                                                  https   kubernetes io docs concepts services networking ingress controllers                 AWS Load Balancer Controller          ALB                                                                                Gateway API  https   gateway api sigs k8s io                                                           Route 53  Global Accelerator     CloudFront                                            Amazon CloudFront  https   aws amazon com cloudfront     AWS Global Accelerator  https   aws amazon com global accelerator       Amazon Route 53  https   aws amazon com route53                                                                                Route 53                                                                     DNS      https   docs aws amazon com Route53 latest DeveloperGuide resource record sets values weighted html rrsets values weighted weight                                  DNS       https   github com kubernetes sigs external dns                     AWS Load Balancer Controller      https   kubernetes sigs github io aws load balancer controller v2 4 guide integrations external dns  usage                 Global Accelerator      IP                                                                                Route 53  Global Accelerator                                                                 Route 53     Global Accelerator                       https   aws amazon com blogs containers operating a multi regional stateless application using amazon eks                  CloudFront  Route 53   Global Accelerator                                                 CloudFront                                                                      Endpoints                 EndpointSlices                                                       https   kubernetes io docs concepts services networking endpoint slices                                                                                AWS Load Balancer Controller  https   kubernetes sigs github io aws load balancer controller v2 4 deploy configurations  controller command line flags                          enable endpoint slices                                      immutable       external            kubelet                                                  kubelet                                                    API                                                                                AutoMountServiceAccountToken  false                                                                                https   kubernetes io docs concepts configuration secret  secret immutable            kubelet                 API                                                                                apiVersion  v1 kind  ServiceAccount metadata    name  app automountServiceAccountToken  true                      10 000                                                                                kubectl get secrets  A   wc  l                                                    Secrets Store CSI       https   secrets store csi driver sigs k8s io        AWS Key Management Service  AWS KMS   https   aws amazon com kms       Hashicorp Vault  https   www vaultproject io                                                                                https   kubernetes io docs concepts workloads controllers deployment  clean up policy    therevisionHistoryLimit                                                                                10             CronJobs                                      TTLSecondsFinished      https   kubernetes io docs concepts workloads controllers ttlafterfinished                                                                                enableServiceLinks                               kubelet                                                                                5 000                                                                                CoreDNS                                Webhook         Dynamic Admission Webhooks  https   kubernetes io docs reference access authn authz extensible admission controllers                   Mutating                                   API                    API                                    10                                API                                                             FailurePolicy  https   kubernetes io docs reference access authn authz extensible admission controllers  failure policy                                               dry run kubectl                                                   apiVersion  admission k8s io v1 kind  AdmissionReview request    dryRun  False                                                  5         50                                5                 etcd                                etcd                etcd   200                           15                   etcd                                     defragmentation       etcd                API


eks SLO search Amazon EKS EKS SLO SLI Service Level Indicator SLO Service Level Objective exclude true

Answer:
---
search:
  exclude: true
---

# 쿠버네티스 업스트림 SLO

Amazon EKS는 업스트림 쿠버네티스 릴리스와 동일한 코드를 실행하고 EKS 클러스터가 쿠버네티스 커뮤니티에서 정의한 SLO 내에서 작동하도록 합니다. 쿠버네티스 [확장성 SIG](https://github.com/kubernetes/community/tree/master/sig-scalability)는 확장성 목표를 정의하고, 정의된 SLI(Service Level Indicator)와 SLO(Service Level Objective)를 통해 성능 병목 현상을 조사합니다.

SLI는 시스템이 얼마나 “잘” 실행되고 있는지 판단하는 데 사용할 수 있는 메트릭이나 측정값과 같이 시스템을 측정하는 방법(예: 요청 지연 시간 또는 개수)입니다. SLO는 시스템이 '정상' 실행될 때 예상되는 값을 정의합니다. 예를 들어 요청 지연 시간이 3초 미만으로 유지됩니다. 쿠버네티스 SLO와 SLI는 쿠버네티스 구성 요소의 성능에 초점을 맞추고 EKS 클러스터 엔드포인트의 가용성에 초점을 맞춘 Amazon EKS 서비스 SLA와는 완전히 독립적입니다.

쿠버네티스는 사용자가 CSI 드라이버, 어드미션 웹훅, 자동 스케일러와 같은 커스텀 애드온 또는 드라이버로 시스템을 확장할 수 있는 많은 기능을 제공합니다. 이러한 확장은 다양한 방식으로 쿠버네티스 클러스터의 성능에 큰 영향을 미칠 수 있다. 예를 들어 `FailurePolicy=Ignore`가 포함된 어드미션 웹훅은 웹훅 타겟을 사용할 수 없는 경우 K8s API 요청에 지연 시간을 추가할 수 있다. 쿠버네티스 확장성 SIG는 ["you promise, we promise" 프레임워크](https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md#how-we-define-scalability)를 사용하여 확장성을 정의합니다.

> 사용자가 다음과 같이 약속하는 경우 (`You promise`):
>     - 클러스터를 올바르게 구성하세요
>     - 확장성 기능을 “합리적으로” 사용
>     - 클러스터의 부하를 [권장 리밋](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) 이내로 유지
>
> 그러면 클러스터가 확장될 것을 약속합니다. (`We promise`):
>     - 모든 SLO가 만족합니다.

# 쿠버네티스 SLO
쿠버네티스 SLO는 워커 노드 스케일링이나 어드미션 웹훅과 같이 클러스터에 영향을 미칠 수 있는 모든 플러그인과 외부 제한을 고려하지 않습니다. 이러한 SLO는 [쿠버네티스 컴포넌트](https://kubernetes.io/docs/concepts/overview/components/)에 초점을 맞추고 쿠버네티스 액션과 리소스가 기대 범위 내에서 작동하도록 합니다. SLO는 쿠버네티스 개발자가 쿠버네티스 코드를 변경해도 전체 시스템의 성능이 저하되지 않도록 하는 데 도움이 됩니다.

[쿠버네티스 확장성 SIG는 다음과 같은 공식 SLO/SLI를 정의합니다](https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md). Amazon EKS 팀은 이러한 SLO/SLI에 대해 EKS 클러스터에서 정기적으로 확장성 테스트를 실행하여 변경 및 새 버전 출시에 따른 성능 저하를 모니터링합니다.

|Objective	|Definition	|SLO	|
|---	|---	|---	|
|API request latency (mutating)	|모든 (리소스, 동사) 쌍의 단일 객체에 대한 변경 API 호출 처리 지연 (지난 5분 동안 백분위 99로 측정) |기본 Kubernetes 설치에서 모든 (리소스, 동사) 쌍에 대해 (가상 및 집계 리소스 정의 제외), 클러스터당 백분위 99 <= 1초 |
|API request latency (read-only)	|모든 (리소스, 범위) 쌍에 대한 비스트리밍 읽기 전용 API 호출 처리 대기 시간 (지난 5분 동안 백분위 99로 측정) |기본 Kubernetes 설치에서 모든 (리소스, 범위) 쌍에 대해 (가상 및 집계 리소스 및 사용자 지정 리소스 정의 제외), 클러스터당 백분위 99: (a) <= `scope=resource`인 경우 1초 (b) << = 30초 (`scope=namespace` 또는 `scope=cluster`인 경우) |
|Pod startup latency	| 예약 가능한 상태 비저장 파드의 시작 지연 시간 (이미지를 가져오고 초기화 컨테이너를 실행하는 데 걸리는 시간 제외), 파드 생성 타임스탬프부터 모든 컨테이너가 시작 및 시계를 통해 관찰된 것으로 보고되는 시점까지 측정 (지난 5분 동안 백분위 99로 측정) |기본 쿠버네티스 설치에서 클러스터당 백분위 99 <= 5초 |

<!-- |Objective	|Definition	|SLO	|
|---	|---	|---	|
|API request latency (mutating)	|Latency of processing mutating  API calls for single objects for every (resource, verb) pair, measured as 99th percentile over last 5 minutes	|In default Kubernetes installation, for every (resource, verb) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day <= 1s	|
|API request latency (read-only)	|Latency of processing non-streaming read-only API calls for every (resource, scope) pair, measured as 99th percentile over last 5 minutes	|In default Kubernetes installation, for every (resource, scope) pair, excluding virtual and aggregated resources and Custom Resource Definitions, 99th percentile per cluster-day: (a) <= 1s if `scope=resource` (b) <= 30s otherwise (if `scope=namespace` or `scope=cluster`)	|
|Pod startup latency	|Startup latency of schedulable stateless pods, excluding time to pull images and run init containers, measured from pod creation timestamp to when all its containers are reported as started and observed via watch, measured as 99th percentile over last 5 minutes	|In default Kubernetes installation, 99th percentile per cluster-day <= 5s	| -->

### API 요청 지연 시간

`kube-apiserver`에는 기본적으로 `--request-timeout`이 `1m0s`로 정의되어 있습니다. 즉, 요청을 최대 1분 (60초) 동안 실행한 후 제한 시간을 초과하여 취소할 수 있습니다. 지연 시간에 대해 정의된 SLO는 실행 중인 요청 유형별로 구분되며, 변경되거나 읽기 전용일 수 있습니다.

#### 뮤테이팅 (Mutating)

쿠버네티스에서 요청을 변경하면 생성, 삭제 또는 업데이트와 같은 리소스가 변경됩니다. 이러한 요청은 업데이트된 오브젝트가 반환되기 전에 변경 사항을 [etcd 백엔드](https://kubernetes.io/docs/concepts/overview/components/#etcd)에 기록해야 하기 때문에 비용이 많이 든다. [Etcd](https://etcd.io/)는 모든 쿠버네티스 클러스터 데이터에 사용되는 분산 키-밸류 저장소입니다.

이 지연 시간은 쿠버네티스 리소스의 (resource, verb) 쌍에 대한 5분 이상의 99번째 백분위수로 측정됩니다. 예를 들어 이 지연 시간은 파드 생성 요청과 업데이트 노드 요청의 지연 시간을 측정합니다. SLO를 충족하려면 요청 지연 시간이 1초 미만이어야 합니다.

#### 읽기 전용 (read-only)

읽기 전용 요청은 단일 리소스 (예: Pod X 정보 가져오기) 또는 컬렉션 (예: “네임스페이스 X에서 모든 파드 정보 가져오기”) 을 검색한다. `kube-apiserver`는 오브젝트 캐시를 유지하므로 요청된 리소스가 캐시에서 반환될 수도 있고, 먼저 etcd에서 검색해야 할 수도 있다.
이러한 지연 시간은 5분 동안의 99번째 백분위수로도 측정되지만, 읽기 전용 요청은 별도의 범위를 가질 수 있습니다.SLO는 두 가지 다른 목표를 정의합니다.

* *단일* 리소스(예: `kubectl get pod -n mynamespace my-controller-xxx`)에 대한 요청의 경우 요청 지연 시간은 1초 미만으로 유지되어야 합니다.
* 네임스페이스 또는 클러스터의 여러 리소스에 대해 요청한 경우 (예: `kubectl get pods -A`) 지연 시간은 30초 미만으로 유지되어야 합니다.

Kubernetes 리소스 목록에 대한 요청은 요청에 포함된 모든 오브젝트의 세부 정보가 SLO 내에 반환될 것으로 예상하기 때문에 SLO는 요청 범위에 따라 다른 목표 값을 가집니다. 대규모 클러스터 또는 대규모 리소스 컬렉션에서는 응답 크기가 커져 반환하는 데 다소 시간이 걸릴 수 있습니다. 예를 들어 수만 개의 파드를 실행하는 클러스터에서 JSON으로 인코딩할 때 각 파드가 대략 1KiB인 경우 클러스터의 모든 파드를 반환하는 데 10MB 이상이 된다. 쿠버네티스 클라이언트는 이러한 응답 크기를 줄이는 데 도움이 될 수 있다 [APIListChunking을 사용하여 대규모 리소스 컬렉션을 검색](https://kubernetes.io/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks).

### 파드 시작 지연

이 SLO는 주로 파드 생성부터 해당 파드의 컨테이너가 실제로 실행을 시작할 때까지 걸리는 시간과 관련이 있다. 이를 측정하기 위해 파드에 기록된 생성 타임스탬프와 [파드 WATCH요청](https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes)에서 보고된 컨테이너가 시작된 시점 (컨테이너 이미지 풀링 및 초기화 컨테이너 실행 시간 제외)과의 차이를 계산합니다. SLO를 충족하려면 이 파드 시작 지연 시간의 클러스터 일당 99번째 백분위수를 5초 미만으로 유지해야 한다.

참고로, 이 SLO에서는 워커 노드가 이 클러스터에 이미 존재하며 파드를 스케줄링할 준비가 된 상태인 것으로 가정한다. 이 SLO는 이미지 풀이나 초기화 컨테이너 실행을 고려하지 않으며, 영구 스토리지 플러그인을 활용하지 않는 “스테이트리스(stateless) 파드"로만 테스트를 제한한다.

## 쿠버네티스 SLI 메트릭스

또한 쿠버네티스는 시간이 지남에 따라 이러한 SLI를 추적하는 쿠버네티스 컴포넌트에 [프로메테우스 메트릭](https://prometheus.io/docs/concepts/data_model/)을 추가하여 SLI에 대한 옵저버빌리티를 개선하고 있습니다. [프로메테우스 쿼리 언어 (PromQL)](https://prometheus.io/docs/prometheus/latest/querying/basics/)를 사용하여 Prometheus 또는 Grafana 대시보드와 같은 도구에서 시간 경과에 따른 SLI 성능을 표시하는 쿼리를 작성할 수 있습니다. 아래는 위의 SLO에 대한 몇 가지 예입니다.

### API 서버 요청 레이턴시

|Metric	|Definition	|
|---	|---	|
|apiserver_request_sli_duration_seconds	| 각 verb, 그룹, 버전, 리소스, 하위 리소스, 범위 및 구성 요소에 대한 응답 지연 시간 분포 (웹훅 지속 시간, 우선 순위 및 공정성 대기열 대기 시간 제외)	|
|apiserver_request_duration_seconds	| 각 verb, 테스트 실행 값, 그룹, 버전, 리소스, 하위 리소스, 범위 및 구성 요소에 대한 응답 지연 시간 분포 (초)	|

*참고: `apiserver_request_sli_duration_seconds` 메트릭은 쿠버네티스 1.27 버전부터 사용할 수 있다.*

이러한 메트릭을 사용하여 API 서버 응답 시간과 Kubernetes 구성 요소 또는 기타 플러그인/구성 요소에 병목 현상이 있는지 조사할 수 있습니다. 아래 쿼리는 [커뮤니티 SLO 대시보드](https://github.com/kubernetes/perf-tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards)를 기반으로 합니다.

**API 요청 레이턴시 SLI (mutating)** - 해당 시간은 웹훅 실행 또는 대기열 대기 시간을 포함*하지 않습니다*.
`histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0`

**API 요청 레이턴시 시간 합계 (mutating)** - API 서버에서 요청이 소요된 총 시간입니다. 이 시간은 웹훅 실행, API 우선 순위 및 공정성 대기 시간을 포함하므로 SLI 시간보다 길 수 있습니다.
`histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"CREATE|DELETE|PATCH|POST|PUT", subresource!~"proxy|attach|log|exec|portforward"}[5m])) by (resource, subresource, verb, scope, le)) > 0`

이 쿼리에서는 `kubectl port-forward` 또는 `kubectl exec` 요청과 같이 즉시 반환되지 않는 스트리밍 API 요청을 제외합니다. (`subresource!~"proxy|attach|log|exec|portforward"`). 그리고 객체를 수정하는 쿠버네티스 verb에 대해서만 필터링하고 있습니다 (`verb=~"Create|Delete|Patch|Post|put"`).그런 다음 지난 5분 동안의 해당 지연 시간의 99번째 백분위수를 계산합니다.

읽기 전용 API 요청에도 비슷한 쿼리를 사용할 수 있습니다. 필터링 대상 verb에 읽기 전용 작업 `LIST`와 `GET`이 포함되도록 수정하기만 하면 됩니다. 또한 요청 범위(예: 단일 리소스를 가져오거나 여러 리소스를 나열하는 경우)에 따라 SLO 임계값도 다릅니다.

**API 요청 레이턴시 시간 SLI (읽기 전용)** - 이번에는 웹훅 실행 또는 대기열 대기 시간을 포함*하지 않습니다*.
단일 리소스의 경우 (범위=리소스, 임계값=1s)
`histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))`

동일한 네임스페이스에 있는 리소스 컬렉션의 경우 (범위=네임스페이스, 임계값=5s)
`histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))`

전체 클러스터의 리소스 컬렉션의 경우 (범위=클러스터, 임계값=30초)
`histogram_quantile(0.99, sum(rate(apiserver_request_sli_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))`

**API 요청 레이턴시 시간 합계 (읽기 전용) ** - API 서버에서 요청이 소요된 총 시간입니다. 이 시간은 웹훅 실행 및 대기 시간을 포함하므로 SLI 시간보다 길 수 있습니다.
단일 리소스의 경우 (범위=리소스, 임계값=1초)
`histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"GET", scope=~"resource"}[5m])) by (resource, subresource, verb, scope, le))`

동일한 네임스페이스에 있는 리소스 컬렉션의 경우 (범위=네임스페이스, 임계값=5s)
`histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"namespace"}[5m])) by (resource, subresource, verb, scope, le))`

전체 클러스터의 리소스 모음의 경우 (범위=클러스터, 임계값=30초)
`histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket{verb=~"LIST", scope=~"cluster"}[5m])) by (resource, subresource, verb, scope, le))`

SLI 메트릭은 요청이 API Priority 및 Fairness 대기열에서 대기하거나, 승인 웹훅 또는 기타 쿠버네티스 확장을 통해 작업하는 데 걸리는 시간을 제외함으로써 쿠버네티스 구성 요소의 성능에 대한 통찰력을 제공합니다. 전체 지표는 애플리케이션이 API 서버의 응답을 기다리는 시간을 반영하므로 보다 총체적인 시각을 제공합니다. 이러한 지표를 비교하면 요청 처리 지연이 발생하는 위치를 파악할 수 있습니다.

### 파드 시작 레이턴시

|Metric	| Definition	|
|---	|---	|
|kubelet_pod_start_sli_duration_seconds	|파드를 시작하는 데 걸리는 시간 (초) (이미지를 가져오고 초기화 컨테이너를 실행하는 데 걸리는 시간 제외), 파드 생성 타임스탬프부터 모든 컨테이너가 시계를 통해 시작 및 관찰된 것으로 보고될 때까지의 시간 	|
|kubelet_pod_start_duration_seconds	|kubelet이 파드를 처음 본 시점부터 파드가 실행되기 시작할 때까지의 시간(초). 여기에는 파드를 스케줄링하거나 워커 노드 용량을 확장하는 시간은 포함되지 않는다.	|

*참고: `kubelet_pod_start_sli_duration_seconds`는 쿠버네티스 1.27부터 사용할 수 있다.*

위의 쿼리와 마찬가지로 이러한 메트릭을 사용하여 노드 스케일링, 이미지 풀 및 초기화 컨테이너가 Kubelet 작업과 비교하여 파드 출시를 얼마나 지연시키는지 파악할 수 있습니다.

**파드 시작 레이턴시 시간 SLI -** 이것은 파드 생성부터 애플리케이션 컨테이너가 실행 중인 것으로 보고된 시점까지의 시간입니다. 여기에는 워커 노드 용량을 사용할 수 있고 파드를 스케줄링하는 데 걸리는 시간이 포함되지만, 이미지를 가져오거나 초기화 컨테이너를 실행하는 데 걸리는 시간은 포함되지 않습니다.
`histogram_quantile(0.99, sum(rate(kubelet_pod_start_sli_duration_seconds_bucket[5m])) by (le))`

**파드 시작 레이턴시 시간 합계 -** kubelet이 처음으로 파드를 시작하는 데 걸리는 시간입니다. 이는 kubelet이 WATCH를 통해 파드를 수신한 시점부터 측정되며, 워커 노드 스케일링 또는 스케줄링에 걸리는 시간은 포함되지 않는다. 여기에는 이미지를 가져오고 실행할 컨테이너를 초기화하는 데 걸리는 시간이 포함됩니다.
`histogram_quantile(0.99, sum(rate(kubelet_pod_start_duration_seconds_bucket[5m])) by (le))`

## 클러스터의 SLO

EKS 클러스터의 쿠버네티스 리소스에서 Prometheus 메트릭을 수집하면 쿠버네티스 컨트롤 플레인 구성 요소의 성능에 대한 심층적인 통찰력을 얻을 수 있습니다.

[perf-test repo](https://github.com/kubernetes/perf-tests/)에는 테스트 중 클러스터의 지연 시간 및 중요 성능 메트릭을 표시하는 Grafana 대시보드가 포함되어 있습니다. perf 테스트 구성은 쿠버네티스 메트릭을 수집하도록 구성된 오픈 소스 프로젝트인 [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack)을 활용하지만 [Amazon Managed Prometheus 및 Amazon Managed Grafana 사용](https://aws-observability.github.io/terraform-aws-observability-accelerator/eks/)도 가능합니다.

`kube-prometheus-stack` 또는 유사한 프로메테우스 솔루션을 사용하는 경우 동일한 대시보드를 설치하여 클러스터의 SLO를 실시간으로 관찰할 수 있습니다.

1. 먼저 `kubectl apply -f prometheus-rules.yaml`로 대시보드에서 사용되는 프로메테우스 규칙을 설치해야 한다. 여기에서 규칙 사본을 다운로드할 수 있습니다: https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/prometheus/manifests/prometheus-rules.yaml
    1. 파일의 네임스페이스가 사용자 환경과 일치하는지 확인하세요.
    2. `kube-prometheus-stack`을 사용하는 경우 레이블이 `Prometheus.PrometheusSpec.RuleSelector` 헬름 값과 일치하는지 확인하세요.
2. 그런 다음 Grafana에 대시보드를 설치할 수 있습니다. 이를 생성하는 json 대시보드와 파이썬 스크립트는 다음에서 확인할 수 있습니다: https://github.com/kubernetes/perf-tests/tree/master/clusterloader2/pkg/prometheus/manifests/dashboards
    1. [`slo.json` 대시보드](https://github.com/kubernetes/perf-tests/blob/master/clusterloader2/pkg/prometheus/manifests/dashboards/slo.json)는 쿠버네티스 SLO와 관련된 클러스터의 성능을 보여줍니다.

SLO는 클러스터의 Kubernetes 구성 요소 성능에 초점을 맞추고 있지만 클러스터에 대한 다양한 관점이나 통찰력을 제공하는 추가 메트릭을 검토할 수 있습니다. [Kube-State-Metrics](https://github.com/kubernetes/kube-state-metrics/tree/main)와 같은 쿠버네티스 커뮤니티 프로젝트는 클러스터의 추세를 빠르게 분석하는 데 도움이 될 수 있습니다. 쿠버네티스 커뮤니티에서 가장 많이 사용되는 플러그인과 드라이버도 Prometheus 메트릭을 내보내므로 오토스케일러 또는 사용자 지정 스케줄러와 같은 사항을 조사할 수 있습니다.

[옵저버빌리티 모범 사례 가이드](https://aws-observability.github.io/observability-best-practices/guides/containers/oss/eks/best-practices-metrics-collection/#control-plane-metrics)에는 추가 통찰력을 얻는 데 사용할 수 있는 다른 쿠버네티스 메트릭의 예가 나와 있습니다.

search    exclude  true                    SLO  Amazon EKS                               EKS                        SLO                           SIG  https   github com kubernetes community tree master sig scalability                     SLI Service Level Indicator   SLO Service Level Objective                         SLI                                                                                SLO                                                 3                    SLO  SLI                           EKS                         Amazon EKS     SLA                            CSI                                                                                FailurePolicy Ignore                                   K8s API                                SIG    you promise  we promise         https   github com kubernetes community blob master sig scalability slos slos md how we define scalability                                              You promise                                                                                https   github com kubernetes community blob master sig scalability configs and limits thresholds md                                          We promise                 SLO                      SLO       SLO                                                                            SLO               https   kubernetes io docs concepts overview components                                                SLO                                                                           SIG            SLO SLI         https   github com kubernetes community blob master sig scalability slos slos md   Amazon EKS        SLO SLI     EKS                                                                Objective  Definition  SLO                     API request latency  mutating                                API              5         99          Kubernetes                                                        99    1     API request latency  read only                                  API                 5         99          Kubernetes                                                                     99   a      scope resource      1   b       30    scope namespace      scope cluster          Pod startup latency                                                                                5         99                               99    5           Objective  Definition  SLO                     API request latency  mutating   Latency of processing mutating  API calls for single objects for every  resource  verb  pair  measured as 99th percentile over last 5 minutes  In default Kubernetes installation  for every  resource  verb  pair  excluding virtual and aggregated resources and Custom Resource Definitions  99th percentile per cluster day    1s    API request latency  read only   Latency of processing non streaming read only API calls for every  resource  scope  pair  measured as 99th percentile over last 5 minutes  In default Kubernetes installation  for every  resource  scope  pair  excluding virtual and aggregated resources and Custom Resource Definitions  99th percentile per cluster day   a     1s if  scope resource   b     30s otherwise  if  scope namespace  or  scope cluster      Pod startup latency  Startup latency of schedulable stateless pods  excluding time to pull images and run init containers  measured from pod creation timestamp to when all its containers are reported as started and observed via watch  measured as 99th percentile over last 5 minutes  In default Kubernetes installation  99th percentile per cluster day    5s            API             kube apiserver             request timeout    1m0s                        1   60                                                  SLO                                                       Mutating                                                                                etcd      https   kubernetes io docs concepts overview components  etcd                           Etcd  https   etcd io                                                                  resource  verb        5      99                                                                   SLO                  1                          read only                        Pod X                             X                            kube apiserver                                              etcd                             5      99                                             SLO                                     kubectl get pod  n mynamespace my controller xxx                        1                                                           kubectl get pods  A          30                   Kubernetes                                        SLO                     SLO                                                                                JSON                   1KiB                         10MB                                                   APIListChunking                        https   kubernetes io docs reference using api api concepts  retrieving large results sets in chunks                     SLO                                                                                WATCH    https   kubernetes io docs reference using api api concepts  efficient detection of changes                                                                    SLO                               99         5                         SLO                                                           SLO                                                               stateless                              SLI                                 SLI                                https   prometheus io docs concepts data model         SLI                                       PromQL   https   prometheus io docs prometheus latest querying basics         Prometheus    Grafana                         SLI                                 SLO                     API              Metric  Definition                apiserver request sli duration seconds     verb                                                                                apiserver request duration seconds     verb                                                                           apiserver request sli duration seconds             1 27                                API           Kubernetes                                                             SLO       https   github com kubernetes perf tests tree master clusterloader2 pkg prometheus manifests dashboards                 API         SLI  mutating                                                  histogram quantile 0 99  sum rate apiserver request sli duration seconds bucket verb   CREATE DELETE PATCH POST PUT   subresource   proxy attach log exec portforward   5m    by  resource  subresource  verb  scope  le     0     API                mutating      API                                    API                          SLI                   histogram quantile 0 99  sum rate apiserver request duration seconds bucket verb   CREATE DELETE PATCH POST PUT   subresource   proxy attach log exec portforward   5m    by  resource  subresource  verb  scope  le     0            kubectl port forward      kubectl exec                         API              subresource   proxy attach log exec portforward                        verb                    verb   Create Delete Patch Post put             5                99                       API                                 verb            LIST    GET                                                                      SLO               API            SLI                                                                           1s     histogram quantile 0 99  sum rate apiserver request sli duration seconds bucket verb   GET   scope   resource   5m    by  resource  subresource  verb  scope  le                                                5s     histogram quantile 0 99  sum rate apiserver request sli duration seconds bucket verb   LIST   scope   namespace   5m    by  resource  subresource  verb  scope  le                                        30      histogram quantile 0 99  sum rate apiserver request sli duration seconds bucket verb   LIST   scope   cluster   5m    by  resource  subresource  verb  scope  le       API                            API                                                  SLI                                        1      histogram quantile 0 99  sum rate apiserver request duration seconds bucket verb   GET   scope   resource   5m    by  resource  subresource  verb  scope  le                                                5s     histogram quantile 0 99  sum rate apiserver request duration seconds bucket verb   LIST   scope   namespace   5m    by  resource  subresource  verb  scope  le                                       30      histogram quantile 0 99  sum rate apiserver request duration seconds bucket verb   LIST   scope   cluster   5m    by  resource  subresource  verb  scope  le     SLI          API Priority   Fairness                                                                                API                                                                                Metric   Definition                kubelet pod start sli duration seconds                                                                                kubelet pod start duration seconds  kubelet                                                                                kubelet pod start sli duration seconds         1 27                                                                     Kubelet                                                          SLI                                                                                histogram quantile 0 99  sum rate kubelet pod start sli duration seconds bucket 5m    by  le                            kubelet                                kubelet  WATCH                                                                                histogram quantile 0 99  sum rate kubelet pod start duration seconds bucket 5m    by  le                SLO  EKS                   Prometheus                                                               perf test repo  https   github com kubernetes perf tests                                         Grafana                  perf                                           kube prometheus stack  https   github com prometheus community helm charts tree main charts kube prometheus stack          Amazon Managed Prometheus   Amazon Managed Grafana     https   aws observability github io terraform aws observability accelerator eks             kube prometheus stack                                                  SLO                      1      kubectl apply  f prometheus rules yaml                                                             https   github com kubernetes perf tests blob master clusterloader2 pkg prometheus manifests prometheus rules yaml     1                                       2   kube prometheus stack                 Prometheus PrometheusSpec RuleSelector                     2        Grafana                            json                                  https   github com kubernetes perf tests tree master clusterloader2 pkg prometheus manifests dashboards     1    slo json        https   github com kubernetes perf tests blob master clusterloader2 pkg prometheus manifests dashboards slo json         SLO                        SLO        Kubernetes                                                                        Kube State Metrics  https   github com kubernetes kube state metrics tree main                                                                                Prometheus                                                                           https   aws observability github io observability best practices guides containers oss eks best practices metrics collection  control plane metrics


eks exclude true EKS NTP syslog kube system search

Answer:
---
search:
  exclude: true
---

# 클러스터 서비스

클러스터 서비스는 EKS 클러스터 내에서 실행되지만 사용자 워크로드는 아닙니다. 리눅스 서버를 사용하는 경우 워크로드를 지원하기 위해 NTP, syslog 및 컨테이너 런타임과 같은 서비스를 실행해야 하는 경우가 많습니다. 클러스터 서비스도 비슷하며 클러스터를 자동화하고 운영하는 데 도움이 되는 서비스를 지원합니다. 쿠버네티스에서 이들은 일반적으로 kube-system 네임스페이스에서 실행되고 일부는 [데몬셋](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)로 실행됩니다.

클러스터 서비스는 가동 시간이 길어질 것으로 예상되며 정전 및 문제 해결에 중요한 역할을 하는 경우가 많습니다. 코어 클러스터 서비스를 사용할 수 없는 경우 장애 복구 또는 예방에 도움이 되는 데이터 (예: 높은 디스크 사용률)에 액세스할 수 없게 될 수 있습니다. 별도의 노드 그룹 또는 AWS Fargate와 같은 전용 컴퓨팅 인스턴스에서 실행해야 합니다. 이렇게 하면 규모가 커지거나 리소스를 더 많이 사용하는 워크로드가 공유 인스턴스에 미치는 영향을 클러스터 서비스가 받지 않도록 할 수 있습니다.

## CoreDNS 스케일링

CoreDNS 스케일링에는 두 가지 기본 메커니즘이 있습니다. CoreDNS 서비스에 대한 호출 수를 줄이고 복제본 수를 늘립니다.

### ndot을 줄여 외부 쿼리를 줄입니다.

ndots 설정은 DNS 쿼리를 피하기에 충분하다고 간주되는 도메인 이름의 마침표 (일명 "점") 수를 지정합니다. 애플리케이션의 ndots 설정이 5 (기본값) 이고 api.example.com (점 2개) 과 같은 외부 도메인에서 리소스를 요청하는 경우 /etc/resolv.conf에 정의된 각 검색 도메인에 대해 CoreDNS가 쿼리되어 더 구체적인 도메인이 검색됩니다. 기본적으로 외부 요청을 하기 전에 다음 도메인이 검색됩니다.

```
api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal
```

`namespace` 및 `region` 값은 워크로드 네임스페이스 및 컴퓨팅 지역으로 대체됩니다. 클러스터 설정에 따라 추가 검색 도메인이 있을 수 있습니다.

워크로드의 [ndots 옵션 낮추기](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) 또는 후행 항목을 포함하여 도메인 요청을 완전히 검증하여 CoreDNS에 대한 요청 수를 줄일 수 있습니다.(예: `api.example.com.`). 워크로드가 DNS를 통해 외부 서비스에 연결하는 경우 워크로드가 불필요하게 클러스터 내에서 DNS 쿼리를 클러스터링하지 않도록 ndots를 2로 설정하는 것이 좋습니다. 워크로드에 클러스터 내부 서비스에 대한 액세스가 필요하지 않은 경우 다른 DNS 서버 및 검색 도메인을 설정할 수 있습니다.

```
spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0
```

ndots를 너무 낮은 값으로 낮추거나 연결하려는 도메인의 구체성이 충분하지 않은 경우 (후행 포함) DNS 조회가 실패할 수 있습니다.이 설정이 워크로드에 어떤 영향을 미칠지 테스트해야 합니다.

### CoreDNS 수평 스케일링

CoreDNS 인스턴스는 배포에 복제본을 추가하여 확장할 수 있습니다. CoreDNS를 확장하려면 [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) 또는 [cluster proportional autoscaler](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)를 사용하는 것이 좋습니다.

NodeLocal DNS는 노드당 하나의 인스턴스를 데몬셋으로 실행해야 하며, 이를 위해서는 클러스터에 더 많은 컴퓨팅 리소스가 필요하지만 DNS 요청 실패를 방지하고 클러스터의 DNS 쿼리에 대한 응답 시간을 줄입니다. Cluster propertional autoscaler는 클러스터의 노드 또는 코어 수에 따라 CoreDNS의 크기를 조정합니다. 이는 쿼리 요청과 직접적인 상관 관계는 아니지만 워크로드 및 클러스터 크기에 따라 유용할 수 있습니다. 기본 비례 척도는 클러스터의 256개 코어 또는 16개 노드마다 추가 복제본을 추가하는 것입니다(둘 중 먼저 발생하는 기준).

## 쿠버네티스 Metric Server 수직 확장

쿠버네티스 Metric Server는 수평 및 수직 확장을 지원합니다. Metric Server를 수평적으로 확장하면 가용성은 높아지지만 더 많은 클러스터 메트릭을 처리할 수 있을 만큼 수평적으로 확장되지는 않습니다. 노드와 수집된 지표가 클러스터에 추가됨에 따라 [권장 사항](https://kubernetes-sigs.github.io/metrics-server/#scaling)에 따라 메트릭 서버를 수직으로 확장해야 합니다.

Metric Server는 수집, 집계 및 제공하는 데이터를 메모리에 보관합니다. 클러스터가 커지면 Metric Server가 저장하는 데이터 양도 늘어납니다. 대규모 클러스터에서 Metric Server는 기본 설치에 지정된 메모리 및 CPU 예약량보다 더 많은 컴퓨팅 리소스를 필요로 합니다.[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)(VPA) 또는 [Addon Resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer)를 사용하여 Metric Server를 확장할 수 있습니다. Addon Resizer는 Worker 노드에 비례하여 수직으로 확장되고 VPA는 CPU 및 메모리 사용량에 따라 조정됩니다.

## CoreDNS lameduck 지속 시간

파드는 이름 확인을 위해 `kube-dns` 서비스를 사용합니다. 쿠버네티스는 Destination NAT (DNAT) 를 사용하여 노드에서 CoreDNS 백엔드 파드로 `kube-dns` 트래픽을 리디렉션합니다. CoreDNS Deployment를 확장하면, `kube-proxy`는 노드의 iptables 규칙 및 체인을 업데이트하여 DNS 트래픽을 CoreDNS 파드로 리디렉션합니다. 확장 시 새 엔드포인트를 전파하고 축소할 때 규칙을 삭제하는데 클러스터 크기에 따라 CoreDNS를 삭제하는 데 1~10초 정도 걸릴 수 있습니다.

이러한 전파 지연으로 인해 CoreDNS 파드가 종료되었지만 노드의 iptables 규칙이 업데이트되지 않은 경우 DNS 조회 오류가 발생할 수 있습니다. 이 시나리오에서 노드는 종료된 CoreDNS 파드에 DNS 쿼리를 계속 전송할 수 있다.

CoreDNS 파드에 [lameduck](https://coredns.io/plugins/health/) 기간을 설정하여 DNS 조회 실패를 줄일 수 있습니다. Lameduck 모드에 있는 동안 CoreDNS는 계속해서 진행 중인 요청에 응답합니다.Lameduck 기간을 설정하면 CoreDNS 종료 프로세스가 지연되어 노드가 iptables 규칙 및 체인을 업데이트하는 데 필요한 시간을 확보할 수 있습니다.

CoreDNS lameduck 지속 시간을 30초로 설정하는 것이 좋습니다.

## CoreDNS readiness 프로브

CoreDNS의 Readiness 프로브에는 `/health` 대신 `/ready`를 사용하는 것을 추천합니다.

Lameduck 지속 시간을 30초로 설정하라는 이전 권장 사항에 따라, 파드 종료 전에 노드의 iptables 규칙을 업데이트할 수 있는 충분한 시간을 제공합니다. CoreDNS 준비 상태 프로브에 `/health` 대신 `/ready'를 사용하면 시작 시 CoreDNS 파드가 DNS 요청에 즉시 응답할 수 있도록 완벽하게 준비됩니다.

```yaml
readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP
```

CoreDNS Ready 플러그인에 대한 자세한 내용은 [https://coredns.io/plugins/ready/](https://coredns.io/plugins/ready/) 을 참조하십시오.

## 로깅 및 모니터링 에이전트

로깅 및 모니터링 에이전트는 API 서버를 쿼리하여 워크로드 메타데이터로 로그와 메트릭을 보강하므로 클러스터 컨트롤 플레인에 상당한 로드를 추가할 수 있습니다. 노드의 에이전트는 컨테이너 및 프로세스 이름과 같은 항목을 보기 위해 로컬 노드 리소스에만 액세스할 수 있습니다. API 서버를 쿼리하면 Kubernetes Deployment 이름 및 레이블과 같은 세부 정보를 추가할 수 있습니다. 이는 문제 해결에는 매우 유용하지만 확장에는 해로울 수 있습니다.

로깅 및 모니터링에 대한 옵션이 너무 다양하기 때문에 모든 공급자에 대한 예를 표시할 수는 없습니다. [fluentbit](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes)를 사용하면 Use_Kubelet을 활성화하여 Kubernetes API 서버 대신 로컬 kubelet에서 메타데이터를 가져오고 `Kube_Meta_Cache_TTL`을 줄이는 숫자로 설정하는 것이 좋습니다. 데이터를 캐시할 수 있을 때 호출을 반복합니다(예: 60).

조정 모니터링 및 로깅에는 두 가지 일반 옵션이 있습니다.

* 통합 비활성화
* 샘플링 및 필터링

로그 메타데이터가 손실되므로 통합을 비활성화하는 것이 옵션이 아닌 경우가 많습니다. 이렇게 하면 API 확장 문제가 제거되지만 필요할 때 필요한 메타데이터가 없어 다른 문제가 발생합니다.

샘플링 및 필터링을 수행하면 수집되는 지표 및 로그 수가 줄어듭니다. 이렇게 하면 Kubernetes API에 대한 요청 양이 줄어들고 수집되는 지표 및 로그에 필요한 스토리지 양이 줄어듭니다. 스토리지 비용을 줄이면 전체 시스템 비용도 낮아집니다.

샘플링을 구성하는 기능은 에이전트 소프트웨어에 따라 다르며 다양한 수집 지점에서 구현될 수 있습니다. API 서버 호출이 발생할 가능성이 높기 때문에 에이전트에 최대한 가깝게 샘플링을 추가하는 것이 중요합니다. 샘플링 지원에 대해 자세히 알아보려면 공급자에게 문의하세요.

CloudWatch 및 CloudWatch Logs를 사용하는 경우 [문서에 설명된](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) 패턴을 사용하여 에이전트 필터링을 추가할 수 있습니다.

로그 및 지표 손실을 방지하려면 수신 받는 엔드포인트에서 중단이 발생할 경우 데이터를 버퍼링할 수 있는 시스템으로 데이터를 보내야 합니다. Fluentbit를 사용하면 [Amazon Kinesis Data Firehose](https://docs.fluentbit.io/manual/pipeline/outputs/firehose)를 사용하여 데이터를 임시로 보관할 수 있으므로 최종 데이터 저장 위치에 과부하가 걸릴 가능성이 줄어듭니다.

search    exclude  true                             EKS                                                              NTP  syslog                                                                                kube system                         https   kubernetes io docs concepts workloads controllers daemonset                                                                                AWS Fargate                                                                                CoreDNS       CoreDNS                            CoreDNS                                     ndot                   ndots     DNS                                                            ndots     5          api example com    2                               etc resolv conf                   CoreDNS                                                                 api example  namespace  svc cluster local api example svc cluster local api example cluster local api example  region  compute internal       namespace     region                                                                             ndots         https   kubernetes io docs concepts services networking dns pod service  pod dns config                                  CoreDNS                          api example com           DNS                                          DNS                 ndots  2                                                         DNS                               spec    dnsPolicy   None    dnsConfig      options          name  ndots         value   2          name  edns0      ndots                                                    DNS                                                       CoreDNS          CoreDNS                                 CoreDNS         NodeLocal DNS  https   kubernetes io docs tasks administer cluster nodelocaldns       cluster proportional autoscaler  https   github com kubernetes sigs cluster proportional autoscaler                  NodeLocal DNS                                                                 DNS                   DNS                     Cluster propertional autoscaler                       CoreDNS                                                                                256        16                                                    Metric Server              Metric Server                     Metric Server                                                                                https   kubernetes sigs github io metrics server  scaling                              Metric Server                                           Metric Server                                Metric Server                   CPU                              Vertical Pod Autoscaler  https   github com kubernetes autoscaler tree master vertical pod autoscaler  VPA      Addon Resizer  https   github com kubernetes autoscaler tree master addon resizer        Metric Server              Addon Resizer  Worker                    VPA  CPU                          CoreDNS lameduck                       kube dns                     Destination NAT  DNAT              CoreDNS          kube dns                CoreDNS Deployment         kube proxy       iptables                 DNS      CoreDNS                                                             CoreDNS         1 10                                 CoreDNS                iptables                  DNS                                     CoreDNS     DNS                   CoreDNS      lameduck  https   coredns io plugins health            DNS                   Lameduck           CoreDNS                       Lameduck          CoreDNS                   iptables                                         CoreDNS lameduck        30                      CoreDNS readiness      CoreDNS  Readiness         health       ready                   Lameduck        30                                    iptables                               CoreDNS              health       ready             CoreDNS     DNS                                  yaml readinessProbe    httpGet      path   ready     port  8181     scheme  HTTP      CoreDNS Ready                   https   coredns io plugins ready   https   coredns io plugins ready                                                 API                                                                                API          Kubernetes Deployment                                                                                fluentbit  https   docs fluentbit io manual pipeline filters kubernetes        Use Kubelet        Kubernetes API          kubelet                Kube Meta Cache TTL                                                      60                                                                                API                                                                                Kubernetes API                                                                                API                                                                                CloudWatch   CloudWatch Logs                    https   docs aws amazon com AmazonCloudWatch latest logs FilterAndPatternSyntax html                                                                                Fluentbit        Amazon Kinesis Data Firehose  https   docs fluentbit io manual pipeline outputs firehose