고급 Kubernetes 제어 플레인 구성
고급 Kubernetes 제어 플레인 구성
Amazon EKS 클러스터의 제어 플레인 컴포넌트 동작을 조정하는 고급 구성을 알아봐요. 스케줄러의 리소스 배정 전략, HPA 동기화 주기, 종료 파드 가비지 컬렉션 임계값, 이벤트 보존 기간, 서비스 노드 포트 범위를 클러스터에 직접 설정할 수 있어요.
출처: 문서
본문
개요 (Overview)
Amazon EKS는 API server, scheduler, controller manager를 포함한 클러스터의 Kubernetes 제어 플레인을 관리해요. EKS는 대부분의 워크로드에서 잘 동작하는 기본 업스트림 Kubernetes 설정으로 이 컴포넌트들을 실행하며, 대부분의 클러스터에서는 변경할 필요가 없어요. 하지만 일부 워크로드는 다른 제어 플레인 설정의 혜택을 받아요. 스케줄러가 파드를 더 적은 노드에 패킹해 컴퓨트 비용을 줄이거나, Kubernetes 이벤트를 더 짧은 기간 보존해 클러스터 데이터베이스(etcd) 성장을 제한하거나, 오토스케일링 결정을 더 자주 평가하도록 하고 싶을 수 있어요.
고급 Kubernetes 제어 플레인 구성으로 이런 파라미터를 클러스터에 직접 설정할 수 있어요. EKS가 이를 제어 플레인에 적용하며, 클러스터는 동일한 가용성과 성능 특성으로 계속 운영돼요.
이것들은 고급 구성이에요. 각 구성 파라미터는 클러스터에서 실행되는 워크로드에 대해 핵심 Kubernetes 제어 플레인 컴포넌트가 동작하는 방식을 바꾸며, 올바른 값은 워크로드에 따라 달라져요. 파라미터를 변경하기 전에 다음 섹션의 고려 사항을 읽고 비프로덕션 클러스터에서 변경을 테스트해 주세요.
클러스터를 만들 때 고급 제어 플레인 구성 파라미터를 설정하거나 기존 클러스터에서 언제든지 업데이트할 수 있어요. 이 기능은 새 파라미터가 있는 기존 CreateCluster와 UpdateClusterConfig 작업을 사용하므로 AWS Management Console, AWS CLI, AWS SDKs, AWS CloudFormation으로 설정할 수 있어요. EKS는 적용 전 각 구성을 검증하고 변경 사항을 AWS CloudTrail에 기록해요.
고급 제어 플레인 파라미터는 전체 클러스터와 그 위에서 실행되는 모든 워크로드에 적용돼요. 개별 네임스페이스나 워크로드로 범위를 지정할 수 없어요. EKS는 각 파라미터를 검증된 범위로 제한해요. 각 파라미터의 지원 값은 다음 섹션에서 해당 파라미터와 함께 나열돼요.
지원되는 Kubernetes 제어 플레인 파라미터 (Kubernetes control plane parameters supported)
Amazon EKS는 다음 파라미터를 지원해요. 각 파라미터는 제어 플레인 컴포넌트에 속하며 해당 컴포넌트의 구성 필드(kubeSchedulerConfig, kubeControllerManagerConfig, kubeApiServerConfig)로 설정돼요.
| 컴포넌트 | 파라미터 | 지원 값 | 기본값 | Provisioned Control Plane 필요 |
|---|---|---|---|---|
| kube-scheduler | nodeResourcesFit.scoringStrategy |
LeastAllocated, MostAllocated |
LeastAllocated, cpu: 1, memory: 1 |
아니오 |
| kube-controller-manager | horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod |
10s ~ 15s |
15s (초) |
예 |
| kube-controller-manager | podGcControllerConfig.terminatedPodGcThreshold |
10000 ~ 12500 |
12500 |
예 |
| kube-apiserver | eventTtl |
10m ~ 60m |
60m (분) |
아니오 |
| kube-apiserver | serviceNodePortRange |
minPort/maxPort가 10260 ~ 32767 사이 |
minPort: 30000, maxPort: 32767 |
아니오 |
이 토픽의 기본값과 지원 값은 게시 시점에 제공되는 Kubernetes 버전(EKS v1.31 이상)에 적용되며 이후 버전에서 변경될 수 있어요. DescribeClusterVersions 작업은 각 파라미터와 Kubernetes 버전의 현재 기본값과 지원 값을 보고하므로, 여러 버전의 클러스터를 관리하거나 클러스터 구성을 자동화한다면 이를 기준 정보로 사용해 주세요. 자세한 내용은 Configure advanced Kubernetes control plane parameters를 참고해 주세요.
다음 섹션에서는 각 파라미터, 언제 변경해야 하는지, 변경 전 고려 사항을 설명해요.
스케줄러: 노드 리소스 핏 (Scheduler: node resources fit)
스케줄러는 파드를 노드에 두 단계로 할당해요. 먼저 파드를 실행할 수 있는 노드를 필터링한 다음, 남은 후보를 점수화해 최고 점수의 노드에 파드를 배치해요. nodeResourcesFit 플러그인은 노드가 파드가 요청하는 리소스를 가지고 있는지 확인하고 스코어링 전략에 따라 노드에 점수를 매겨요.
| 필드 | 설명 | 지원 값 | 기본값 |
|---|---|---|---|
nodeResourcesFit.scoringStrategy.type |
리소스 할당에 따라 노드에 점수를 매기는 데 사용하는 전략 | LeastAllocated, MostAllocated |
LeastAllocated |
nodeResourcesFit.scoringStrategy.resources |
점수화할 때 고려하는 리소스(각각 상대 가중치 포함) | cpu, memory, nvidia.com/gpu, aws.amazon.com/neuron, aws.amazon.com/neuroncore. 가중치 1 ~ 100 |
cpu: 1, memory: 1 |
LeastAllocated는 리소스 할당이 더 낮은 노드를 선호해, 클러스터의 노드들에 파드를 분산시키고 각 노드에 여유분(headroom)을 남겨요. 이는 기본 Kubernetes 동작이며, 기존 파드의 성장을 흡수하기 위해 모든 노드에 용량을 사용할 수 있게 하려면 좋은 선택이에요.MostAllocated는 이미 리소스 할당이 더 높은 노드를 선호해 파드를 더 적은 노드에 패킹해요. 워크로드가 차지하는 총 용량이 적으므로 더 적은 수의 노드에서 실행하고 컴퓨트 비용을 줄일 수 있어요. 시간이 지나면서 이 패킹 동작은 가볍게 사용되는 노드에 새 워크로드가 들어가지 않게 해, 통합을 지원하는 노드 풀이 이를 제거할 수 있게 해요.
EKS는 LeastAllocated와 MostAllocated 전략을 지원해요. 업스트림 Kubernetes의 RequestedToCapacityRatio 전략은 지원되지 않아요.
리소스 가중치 (Resource weights)
선택적으로 사용자 지정 가중치가 있는 resources 배열을 지정해 점수화 결정에서 어떤 리소스가 가장 중요한지에 영향을 줄 수 있어요. 이는 특정 리소스가 클러스터의 제약인 경우에 유용해요. 예를 들어 액셀러레이터(GPU)가 부족한 리소스인 클러스터에서 nvidia.com/gpu를 CPU와 메모리보다 높게 가중치를 두면 액셀러레이터를 요청하는 파드가 이미 부분적으로 점유된 노드에 집중됩니다.
가중치는 상대적이지 절대적이지 않아요. cpu: 100과 memory: 1을 설정해도 스케줄러가 메모리를 무시하지는 않아요. 점수화 공식에서 CPU를 메모리보다 100배 더 많이 가중치를 두는 거예요. 모든 후보 노드의 CPU 가용량이 동일하면 CPU는 더 이상 노드를 구분하지 못하고 점수화는 사실상 메모리로 넘어가요.
리소스를 생략하는 것과 낮은 가중치를 주는 것은 달라요. resources 배열을 지정하면 나열한 리소스만 점수화돼요. 남겨 둔 리소스는 계산에서 완전히 제외됩니다. 예를 들어 memory 항목 없이 cpu: 100이면 CPU만으로 노드에 점수를 매기고 메모리 가용량은 결과에 영향을 주지 않아요. 계산에 리소스를 유지하면서 영향만 줄이려면 생략 대신 낮은 가중치로 나열해 주세요.
nvidia.com/gpu 같은 액셀러레이터 리소스를 가중치로 두는 것은 실제로 해당 리소스에 대한 resources.requests를 선언하는 파드의 점수화에만 영향을 줘요. 액셀러레이터를 요청하지 않는 파드는 액셀러레이터 가중치의 영향을 받지 않아요.
세 가지 액셀러레이터 리소스는 Kubernetes 확장 리소스(extended resources)예요. 즉 내장이 아니라 플러그인이 Kubernetes에 알리는 노드 수준 리소스입니다. 이들은 디바이스 플러그인이 device plugin API를 통해 kubelet에 알릴 때만 점수화됩니다. 디바이스 드라이버만으로 노드에서 사용 가능해진 리소스는 nodeResourcesFit 플러그인에 표시되지 않고 점수화되지 않아요. Dynamic Resource Allocation(DRA)을 통해 관리되는 리소스는 별도 플러그인으로 스케줄링되며 nodeResourcesFit 점수화의 일부가 아니므로 DRA를 활성화해도 이 파라미터 동작은 변하지 않아요. NVIDIA 디바이스 플러그인 구성에 대한 자세한 내용은 NVIDIA DRA and device plugin을, Neuron 디바이스 구성은 Neuron device management를 참고해 주세요.
스코어링 전략은 스케줄러가 각 노드에 점수를 계산하는 데 사용하는 여러 입력 중 하나예요. 스케줄러가 노드를 필터링하고 점수화하는 방법에 대한 자세한 내용은 Kubernetes 문서의 Scheduling Framework를 참고해 주세요.
스코어링 전략의 고려 사항 (Considerations for the scoring strategy)
- 실행 중인 파드는 이동되지 않아요. Kubernetes 스케줄러는 이미 실행 중인 파드를 재배치하지 않아요. 스코어링 전략 변경은 향후 스케줄링 결정에만 영향을 주며 기존 파드 배치는 영구적이에요. 이미 실행 중인 파드를 재균형하려면 축출하거나 다시 시작하세요.
- 필터링 동작은 변하지 않아요. 스코어링 전략은 스케줄러가 선호도로 노드 순위를 매기는 점수화 단계에만 영향을 줘요. 파드가 노드에서 실행될 수 있는지 결정하는 필터링 단계는 변하지 않아요. 어느 전략에서든 노드에 맞지 않는 파드는 그 노드에 스케줄링되지 않아요.
MostAllocated는 폭발 반경(blast radius)을 집중시켜요. 워크로드를 더 적은 노드에 패킹하면 노드가 비정상이 되거나, 인스턴스가 폐기되거나, 가용 영역이 중단될 때 더 많은 파드가 동시에 영향을 받는다는 뜻이에요. 파드 교체가 빈번하면 밀집된 노드가 더 빨리 차서 새 용량이 프로비저닝되는 동안 파드가Pending상태에 남을 수 있어요.- 스케줄러와 노드 관리는 다른 계층에서 동작해요. 스코어링 전략은 파드를 이미 실행할 수 있는 노드들 간에 어디에 배치할지에 영향을 줘요. EKS Auto Mode나 Karpenter가 노드를 프로비저닝하거나 제거하는 방식을 바꾸지 않아요. 구성을 변경하기 전에 워크로드에 대한 결합 동작을 검증해 주세요.
컨트롤러 매니저: Horizontal Pod Autoscaler 동기화 주기 (Controller manager: HPA sync period)
컨트롤러 매니저는 Horizontal Pod Autoscaler(HPA) 컨트롤러를 포함해 클러스터 상태를 원하는 상태로 이끄는 Kubernetes 컨트롤러를 실행해요. 각 주기마다 HPA 컨트롤러는 각 HorizontalPodAutoscaler 객체의 메트릭을 검색하고 원하는 replica 수를 계산하며, 수가 변경됐으면 대상 워크로드를 업데이트해요.
| 필드 | 설명 | 지원 값 | 기본값 |
|---|---|---|---|
horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod |
HPA 컨트롤러가 스케일링 결정을 평가하는 빈도 | 10s ~ 15s |
15s |
동기화 주기를 줄이면 부하가 증가한 후 워크로드가 전체 주기를 기다리지 않고 더 빨리 확장돼요.
이 파라미터를 구성하려면 클러스터가 Amazon EKS Provisioned Control Plane에 있어야 해요. 간격을 줄이면 HPA 컨트롤러가 클러스터의 모든 HorizontalPodAutoscaler 객체를 조정하는 속도가 높아져 더 많은 API 요청이 생성돼요. 각 조정은 최소 하나의 API 요청을 소비하고, replica 수를 변경하는 조정은 두 개를 더 소비해요. Provisioned Control Plane 클러스터는 까다로운 워크로드에 항상 준비된 제어 플레인 용량을 미리 할당하므로 이 추가 부하를 흡수할 수 있게 크기가 정해져 있어요. 자세한 내용은 Amazon EKS Provisioned Control Plane을 참고해 주세요.
클러스터가 지원하는 HPA 객체 수에 미치는 영향 (Effect on the number of HPA objects)
- 동기화 주기를 줄이면 제어 플레인이 일정 계획에 맞춰 조정할 수 있는
HorizontalPodAutoscaler객체 수가 줄어요. 컨트롤러가 같은 큐를 처리할 시간이 더 적기 때문이에요. 주기를15s에서10s로 줄이면 지원 객체 수가 대략 1/3 줄어요. 주기를 줄이기 전에 클러스터의HorizontalPodAutoscaler객체 수를 세어 더 짧은 주기가 스케일링 티어에서 그 수를 여전히 지원하는지 확인해 주세요:
kubectl get hpa --all-namespaces --no-headers | wc -l
- EKS는 동기화 주기를 HPA 객체 수에 대해 검증하지 않아요. 클러스터에 이미 더 짧은 주기가 지원하는 것보다 많은
HorizontalPodAutoscaler객체가 있어도 구성 변경은 성공해요. 변경 전에 직접 수를 확인해 주세요. - 지원 수를 초과하면 오토스케일링이 조용히 저하돼요. 컨트롤러가 주기 내에 모든 객체를 처리할 수 없으면 일부 객체는 일정대로 조정되지 않아요. EKS는 이 상태에 대해 알람이나 Kubernetes 이벤트를 발생시키지 않으며, 증상은 의도한 효과와 반대로 오토스케일링이 예상보다 느리게 응답하는 거예요. 동기화 주기를 줄인 후 스케일링 지연을 관찰하면 파라미터를 기본값
15s로 되돌려 주세요. - 동기화 주기는 클러스터의 모든 HPA 객체에 적용돼요. 객체나 네임스페이스마다 다른 동기화 주기를 설정할 수 없어요.
컨트롤러 매니저: 종료 파드 가비지 컬렉션 임계값 (Controller manager: Terminated pod garbage collection threshold)
컨트롤러 매니저는 종료 파드 가비지 컬렉터(pod GC 컨트롤러)를 실행해요. 이 컨트롤러는 Succeeded 또는 Failed 단계의 종료 파드를 클러스터의 종료 파드 수가 임계값을 초과한 후 삭제해요. terminatedPodGcThreshold 파라미터가 그 임계값을 설정해요.
| 필드 | 설명 | 지원 값 | 기본값 |
|---|---|---|---|
podGcControllerConfig.terminatedPodGcThreshold |
종료 파드 가비지 컬렉터가 종료 파드 삭제를 시작하기 전에 존재할 수 있는 종료 파드 수 | 10000 ~ 12500 |
12500 |
가비지 컬렉터는 고정 20초 주기로 실행돼요. 임계값을 낮추면 컬렉터가 다음 주기에 가장 오래된 종료 파드를 수가 새 임계값에 도달할 때까지 강제 삭제하기 시작해요.
이 파라미터를 구성하려면 클러스터가 Amazon EKS Provisioned Control Plane에 있어야 해요. 임계값을 낮추면 컨트롤러가 클러스터 데이터베이스(etcd)에 대해 수행하는 가비지 컬렉션 작업이 늘어나요. 각 수집 패스가 더 많은 종료 파드를 쿼리·처리·삭제할 자격을 얻기 때문이에요. Provisioned Control Plane 클러스터는 까다로운 워크로드에 항상 준비된 제어 플레인 용량을 미리 할당하므로 이 추가 부하를 흡수할 수 있어요. 자세한 내용은 Amazon EKS Provisioned Control Plane을 참고해 주세요.
종료 파드 가비지 컬렉션 임계값의 고려 사항
- 임계값을 낮추면 초과 종료 파드가 즉시 삭제돼요. 임계값을 낮추면(예:
12500에서10000으로) 가비지 컬렉션 컨트롤러가 다음 주기에 가장 오래된 종료 파드를 강제 삭제하기 시작해요. 컨트롤러는 종료 파드 수가 새 임계값에 도달할 때까지 계속해요. 감소는 점진적이지 않아요. - 임계값은 소유자와 관계없이 모든 종료 파드에 적용돼요. Job, CronJob, Deployment가 소유했든 독립형이든
Succeeded또는Failed단계의 파드에 영향을 줘요. 실제로 Job과 CronJob 파드가 종료 파드 수에 가장 흔히 기여해요. - 임계값을 낮추면 디버깅 창이 줄어들어요. 완료되고 실패한 파드가
kubectl get pods와kubectl logs에서 더 빨리 사라져요. 완료된 Job 파드의 종료 코드나 로그를 검사하는 자동화는 더 작은 창으로 동작해야 해요. - 임계값은 전역 클러스터 설정이에요. 네임스페이스나 Job별로 구성할 수 없어요. 개별 Job의 파드 수명주기를 제어하려면 해당 Job에
ttlSecondsAfterFinished를 사용해 주세요.
API 서버: 이벤트 보존 (API server: event retention)
API 서버는 Kubernetes 제어 플레인의 프런트엔드예요. Kubernetes API를 제공하고 클러스터 상태를 클러스터 데이터베이스(etcd)에 유지해요. Kubernetes는 파드 스케줄링 결정, 이미지 풀, 상태 확인 실패, 스케일링 작업 같은 클러스터에서 일어나는 일을 설명하기 위해 이벤트를 기록해요.
| 필드 | 설명 | 지원 값 | 기본값 |
|---|---|---|---|
eventTtl |
API 서버가 삭제하기 전에 Kubernetes 이벤트를 보존하는 기간 | 10m ~ 60m |
60m |
대규모 배치 작업, AI 워크로드, CI/CD 파이프라인, 빈번한 CronJob 같은 높은 교체율(high-churn) 워크로드를 실행하는 클러스터는 빠르게 수천 개의 이벤트를 축적해요. 보존되는 모든 이벤트는 클러스터 실행에 필요한 객체와 경쟁하는 클러스터 데이터베이스 공간을 소비하며, 대규모 이벤트 컬렉션은 API 서버 목록 작업을 제공하는 데 더 많은 비용을 들게 해요.
이벤트 보존을 줄이면 이 수명이 짧은 진단 데이터가 더 빨리 정리되어 클러스터 데이터베이스 스토리지 압박을 줄이고 이벤트가 많은 쿼리의 API 서버 응답 시간을 개선해요.
더 짧은 보존 기간이 적합한 경우:
- 클러스터가 많은 이벤트를 생성하는 배치, CI/CD, AI, CronJob 워크로드를 실행할 때.
- 클러스터 데이터베이스 스토리지가 한계를 향해 성장하는 것을 관찰할 때.
- 이벤트를 지속적으로 포착하는 외부 시스템에 의존하고, 과거 디버깅에
kubectl get events에 의존하지 않을 때.
이벤트 보존의 고려 사항
- 변경은 새 이벤트에만 적용돼요. Kubernetes는 이벤트가 생성될 때 만료를 설정해요. 이미 존재하는 이벤트는 생성 시점에 적용된 보존 기간을 유지하며 그 일정에 따라 만료돼요.
eventTtl을 줄여도 이미 클러스터 데이터베이스에 있는 이벤트의 수명은 줄지 않으므로, 스토리지 감소는 기존 이벤트가 만료되면서 점진적으로 적용돼요. - 삭제된 이벤트는 복구할 수 없어요. Kubernetes가 이벤트를 제거하면 영구히 사라져요. 의도보다 더 줄여 이벤트 기록을 잃으면 복원 방법이 없어요. 이 값을 줄이기 전에 문제 해결에 의존하는 모든 것을 클러스터 외부에서 포착하는지 확인해 주세요.
- 이벤트는 구성된 기간보다 약간 더 지속될 수 있어요. 일부 조건에서 제어 플레인 리더 선출 중 발생할 수 있는 etcd 리스 갱신 때문에 이벤트의 만료가 구성한 값 너머로 연장될 수 있어요.
- 디버깅 창이 줄어들어요. 보존 기간이 짧아지면
kubectl get events와kubectl describe가 보여주는 창이 좁아져요. 클러스터에서 이벤트를 스크랩하는 모니터링 도구는 사용할 수 있는 데이터가 더 적어요. 스토리지 효율과 디버깅 워크플로우 사이의 균형을 맞추는 값을 선택해 주세요. - 설정은 클러스터 전체에 적용돼요. 보존은 모든 네임스페이스의 파드 스케줄링, 노드 조건, 스케일링 이벤트를 포함한 모든 이벤트에 적용돼요. 네임스페이스마다 다른 보존 기간을 설정할 수 없어요.
API 서버: 서비스 노드 포트 범위 (API server: service node port range)
Kubernetes는 각 서비스가 필요로 하는 포트를 이 범위에서 모든 노드에 할당해요. 여기에는 NodePort 유형의 서비스와 기본적으로 LoadBalancer 유형의 서비스가 포함돼요.
| 필드 | 설명 | 지원 값 | 기본값 |
|---|---|---|---|
serviceNodePortRange.minPort |
범위에서 가장 낮은 포트 | 10260 ~ 32767 |
30000 |
serviceNodePortRange.maxPort |
범위에서 가장 높은 포트 | 10260 ~ 32767 |
32767 |
minPort는 maxPort보다 작거나 같아야 해요. Amazon EKS는 minPort가 maxPort보다 큰 구성을 거부해요.
범위를 변경하면 조직이 이미 시행하는 네트워크와 방화벽 정책에 노드 포트 할당을 맞출 수 있어요. 범위를 넓히면 단일 클러스터가 지원할 수 있는 서비스 수도 늘어나요. 이 파라미터는 마이그레이션 중에 특히 유용해요. Amazon EKS로 이동하는 애플리케이션과 이를 호출하는 클라이언트는 종종 특정 고정 포트의 서비스를 기대해요. 그 포트가 기본 범위 밖에 있으면 일반적인 옵션은 애플리케이션을 수정하거나 그 앞에 프록시를 두는 거예요. 범위를 애플리케이션이 이미 사용하는 포트에 맞추면 그 작업을 없애 워크로드를 다시 작성하거나 유지 관리할 네트워크 컴포넌트를 추가하지 않고 EKS로 옮길 수 있어요.
범위가 10260과 32767로 제한되는 이유 (Why the range is bounded at 10260 and 32767)
하한 10260은 NodePort 할당을 노드의 Kubernetes 시스템 컴포넌트가 이미 사용하는 포트(kubelet 상태 포트 10248, kube-proxy 상태 확인 포트 10256 포함)와 분리합니다.
상한 32767은 범위를 일반적으로 32768에서 시작하는 Linux 임시 포트 범위와 분리합니다. NodePort가 임시 범위 안에 있으면 커널이 노드의 아웃바운드 연결에 그 포트를 선택해 서비스와 충돌할 수 있어요.
서비스 노드 포트 범위의 고려 사항
- 기존 서비스는 할당된 포트를 유지해요. 범위를 좁히면 이미 새 범위 밖의 포트를 보유한 서비스는 계속 동작하고 kube-proxy는 계속 트래픽을 그 서비스로 라우팅해요. 범위가 변경될 때 Amazon EKS는 기존 서비스의 포트를 재할당하지 않아요.
- 서비스를 다시 만들면 포트가 재할당돼요. 범위 밖의 포트를 보유한 서비스가 삭제되고 다시 생성되면 그 포트는 더 이상 할당될 수 없어요. 기존 서비스가 의존하는 범위를 좁히기 전에, 특히 배포 프로세스가 서비스를 업데이트가 아닌 재생성 방식이라면 이를 계획해 주세요.
- 범위 밖의 새 할당은 거부돼요. 구성된 범위 밖의 포트가 필요한 서비스를 만들거나 업데이트하면 API 서버의 검증 오류로 실패해요.
- 명시적으로 지정된 포트도 검증돼요. 서비스가 Kubernetes가 할당하게 두지 않고
nodePort값을 직접 지정하면 그 포트는 구성된 범위 안에 있어야 해요. 이전에 구성한 더 넓은 범위에서 같은 포트가 유효했더라도 범위 밖의 정적 포트 요청은 거부돼요. - 범위는 클러스터 전체에 적용돼요. 네임스페이스마다 다른 범위를 구성할 수 없어요.
이 파라미터를 변경하기 전에 보안 그룹과 네트워크 ACL이 새 범위의 트래픽을 허용하고, 범위가 노드의 다른 소프트웨어가 사용하는 포트와 충돌하지 않는지 확인해 주세요.
고려 사항 (Considerations)
고급 제어 플레인 파라미터를 구성하기 전에 다음을 검토해 주세요:
- 클러스터 전체 범위 (Cluster-wide scope) — 제어 플레인 파라미터는 전체 클러스터와 그 위에서 실행되는 모든 워크로드에 적용돼요. 개별 네임스페이스나 워크로드로 범위를 지정할 수 없어요. 프로덕션에 적용하기 전에 비프로덕션 클러스터에서 파라미터 변경을 테스트해 주세요.
- Horizontal Pod Autoscaler 동기화 주기와 종료 파드 가비지 컬렉션 임계값은 Provisioned Control Plane이 필요해요 —
horizontalPodAutoscalerSyncPeriod와terminatedPodGcThreshold파라미터는 Amazon EKS Provisioned Control Plane을 사용하는 클러스터에서만 사용할 수 있어요. Amazon EKS는 제어 플레인 리소스 소비를 크게 늘리는 파라미터를 미리 할당된 제어 플레인 용량이 있는 클러스터로 제한해요. Standard 제어 플레인 모드 클러스터에서 이 파라미터 중 하나를 설정하면 실패해요. 사용하려면 먼저 클러스터를 Provisioned Control Plane 스케일링 티어로 이동해 주세요. 자세한 내용은 Amazon EKS Provisioned Control Plane 참고. - HPA 동기화 주기와 종료 파드 GC 임계값의 종료 제한 (Exit restriction) —
horizontalPodAutoscalerSyncPeriod또는terminatedPodGcThreshold가 기본값이 아닌 값으로 설정되어 있으면 클러스터 제어 플레인을 Provisioned 모드에서 Standard 모드로 되돌릴 수 없어요. Standard 모드로 돌아가려면 먼저 두 파라미터를 기본값(15s와12500)으로 되돌린 다음 제어 플레인 스케일링 티어를standard로 변경해 주세요. - 기본값으로 되돌리기 (Returning to default values) — Amazon EKS는 전용 재설정 작업을 제공하지 않으며, 업데이트에서 필드를 생략하면 지우는 대신 현재 값을 유지해요. 파라미터를 기본값으로 되돌리려면 기본값을 명시적으로 설정해 주세요. 클러스터가 실행하는 Kubernetes 버전의 기본값은
DescribeClusterVersions로 가져오세요. 자세한 내용은 Configure advanced Kubernetes control plane parameters 참고. - 업데이트 의미론 (Update semantics) — 업데이트는 기존 구성과 병합돼요. 지정한 필드만 변경되고 생략한 필드는 현재 값을 유지해요. 이는 컴포넌트 간 및 단일 컴포넌트 내에서 모두 적용돼요. 예를 들어 스케줄러 구성만 지정하는 업데이트는 컨트롤러 매니저와 API 서버 구성을 변경하지 않아요.
- 현재 구성 보기 (Viewing current configuration) —
describe-cluster작업은 사용자 지정하지 않은 파라미터와 기본값을 포함해 제어 플레인에서 실행 중인 전체 구성을 반환해요. - 기본값과 지원 값은 Kubernetes 버전 간에 변경될 수 있어요 — 이 토픽에 문서화된 값은 게시 시점의 Kubernetes 버전에 적용돼요. 각 파라미터와 Kubernetes 버전의 현재 기본값과 지원 값은
DescribeClusterVersions로 가져오세요. Configure advanced Kubernetes control plane parameters 참고. - 기존 클러스터는 변경되지 않아요 — Amazon EKS는 기존 클러스터의 동작을 변경하지 않아요. 파라미터를 명시적으로 설정할 때까지 모든 클러스터는 기본 파라미터 값으로 계속 실행돼요.
- 변경은 즉시 적용되지 않아요 —
UpdateClusterConfig가 반환될 때 구성 변경이 적용된 상태가 아니에요. Amazon EKS는 제어 플레인의 롤링 업데이트를 통해 새 구성을 적용하므로 변경이 완전히 적용되기까지 몇 분이 걸릴 것으로 예상해 주세요. 업데이트가 완료되면 클러스터는ACTIVE상태로 돌아가요.DescribeUpdate작업으로 진행 상황을 추적하거나aws eks wait cluster-active로 변경이 완료될 때까지 차단할 수 있어요. - 감사 가능성 (Auditability) — Amazon EKS는 적용 전 각 구성을 검증하고 구성 변경을 AWS CloudTrail에 기록해요.
- 도구 지원 (Tooling support) — 고급 Kubernetes 제어 플레인 구성은 출시 시 AWS Management Console, eksctl, AWS CLI, Amazon EKS API, AWS CloudFormation, AWS CDK에서 사용할 수 있어요. AWS Controllers for Kubernetes(ACK)와 Terraform 지원은 곧 제공될 예정이에요.
- Kubernetes 버전 지원 — 고급 Kubernetes 제어 플레인 구성은 Kubernetes 버전 1.31 이상을 실행하는 신규 및 기존 클러스터에서 지원돼요.
- AWS 리전 지원 — 고급 Kubernetes 제어 플레인 구성은 Amazon EKS를 사용할 수 있는 모든 AWS 상용 리전, AWS GovCloud(US) 리전, AWS 중국 리전에서 사용할 수 있어요.
- 요금 (Pricing) — 제어 플레인 파라미터 구성에는 추가 요금이 없어요.
horizontalPodAutoscalerSyncPeriod를 사용하려면 Provisioned Control Plane이 필요한데, 이는 스케일링 티어의 시간당 요율로 청구돼요. 자세한 내용은 Amazon EKS pricing 참고.
다음 단계 (Next steps)
- Configure advanced Kubernetes control plane parameters — AWS CLI와 AWS Management Console로 제어 플레인 파라미터 설정 및 보기.
- Amazon EKS Provisioned Control Plane — 예측 가능하고 높은 성능을 위해 제어 플레인 용량 미리 할당.