개요 지원되는 Kubernetes 컨트롤 플레인 파라미터 고려 사항 다음 단계

고급 Kubernetes 컨트롤 플레인 구성

개요

Amazon EKS는 API 서버, 스케줄러 및 컨트롤러 관리자를 포함하여 클러스터의 Kubernetes 컨트롤 플레인을 관리합니다. EKS는 대부분의 워크로드에 적합한 기본 업스트림 Kubernetes 설정으로 이러한 구성 요소를 실행하므로, 대부분의 클러스터에서 사용자 변경은 필요하지 않습니다. 그러나 일부 워크로드는 서로 다른 컨트롤 플레인 설정의 이점을 누릴 수 있습니다. 스케줄러가 더 적은 수의 노드에 포드를 압축하여 컴퓨팅 비용을 절감하거나, Kubernetes 이벤트를 더 짧은 기간으로만 유지하여 클러스터 데이터베이스(etcd) 증가를 제한하거나, 자동 규모 조정 결정을 더 자주 평가하길 원할 수 있습니다.

고급 Kubernetes 컨트롤 플레인 구성을 사용하면 클러스터에서 이러한 파라미터를 직접 설정할 수 있습니다. EKS는 이를 컨트롤 플레인에 적용하며, 클러스터는 동일한 가용성 및 성능 특성으로 계속 작동합니다.

이는 고급 구성입니다. 각 구성 파라미터는 클러스터에서 실행 중인 워크로드에 대해 핵심 Kubernetes 컨트롤 플레인 구성 요소가 작동하는 방식을 변경하며, 올바른 값은 워크로드에 따라 달라집니다. 파라미터를 변경하기 전에 다음 섹션의 고려 사항을 읽고 비프로덕션 클러스터에서 변경 사항을 테스트합니다.

클러스터를 생성할 때 고급 컨트롤 플레인 구성 파라미터를 설정하거나 언제든지 기존 클러스터에서 업데이트할 수 있습니다. 이 기능은 기존 CreateCluster 및 UpdateClusterConfig 작업을 새 파라미터와 함께 사용하므로, AWS Management Console, AWS CLI, AWS SDK 또는 AWS CloudFormation을 통해 설정할 수 있습니다. EKS는 각 구성을 적용하기 전에 검증하고, 변경 사항을 AWS CloudTrail에 기록합니다.

고급 컨트롤 플레인 파라미터는 전체 클러스터와 해당 클러스터에서 실행 중인 모든 워크로드에 적용됩니다. 개별 네임스페이스 또는 워크로드로 범위를 지정할 수 없습니다. EKS는 각 파라미터를 검증된 범위로 제한합니다. 각 파라미터에 대해 지원되는 값은 다음 섹션에서 해당 파라미터와 함께 나열됩니다.

지원되는 Kubernetes 컨트롤 플레인 파라미터

Amazon EKS는 다음 파라미터를 지원합니다. 각 파라미터는 컨트롤 플레인 구성 요소에 속하며 해당 구성 요소의 구성 필드(kubeSchedulerConfig, kubeControllerManagerConfig 또는 kubeApiServerConfig)를 통해 설정됩니다.

구성 요소	파라미터	지원되는 값	기본값	프로비저닝된 컨트롤 플레인이 필요함
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 버전에 대해 최신 기본값과 지원되는 값을 보고하므로, 여러 버전에서 클러스터를 관리하거나 클러스터 구성을 자동화하는 경우 이를 신뢰할 수 있는 소스로 사용합니다. 자세한 내용은 고급 Kubernetes 컨트롤 플레인 파라미터 구성 섹션을 참조하세요.

다음 섹션에서는 각 파라미터, 파라미터 변경 시기, 파라미터 변경 전 고려 사항에 대해 설명합니다.

스케줄러: 노드 리소스 적합성

스케줄러는 두 단계로 노드에 포드를 할당합니다. 먼저 포드를 실행할 수 있는 노드를 필터링한 다음, 나머지 후보의 점수를 매기고 포드를 가장 높은 점수의 노드에 배치합니다. 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는 리소스 할당이 낮은 노드를 선호하며, 클러스터의 여러 노드에 포드를 분산시키고 각 노드에 헤드룸을 남겨 둡니다. 이는 기본 Kubernetes 동작이며 모든 노드에서 사용 가능한 용량이 기존 포드의 증가를 충당하도록 하려는 경우에 적합합니다.

MostAllocated는 이미 리소스 할당이 더 높은 노드를 선호하며, 더 적은 수의 노드에 포드를 압축합니다. 사용자의 워크로드는 총 용량을 적게 차지하므로 더 적은 수의 노드에서 실행하고 컴퓨팅 지출을 줄일 수 있습니다. 시간이 지남에 따라 이 압축 동작은 가볍게 사용되는 노드를 새 워크로드로부터 보호하므로 통합을 지원하는 노드 풀에서 해당 노드를 제거할 수 있습니다.

EKS는 LeastAllocated 및 MostAllocated 전략을 지원합니다. 업스트림 Kubernetes RequestedToCapacityRatio 전략은 지원되지 않습니다.

리소스 가중치

점수 책정에 가장 중요한 리소스에 영향을 줄 수 있도록 선택적으로 사용자 지정 가중치가 있는 resources 배열을 지정할 수 있습니다. 이는 특정 리소스가 클러스터의 제약 조건인 경우에 유용합니다. 예를 들어 액셀러레이터(GPU) 리소스가 부족한 클러스터에서 CPU 및 메모리보다 nvidia.com/gpu에 더 높은 가중치를 부여하면 이미 부분적으로 점유된 노드에 액셀러레이터 요청 포드가 집중됩니다.

가중치는 절대적이 아니라 상대적입니다. cpu: 100 및 memory: 1을 설정해도 스케줄러는 메모리를 무시하지 않습니다. 점수 계산 공식에서 CPU의 가중치는 메모리보다 100배 더 큽니다. 모든 후보 노드의 CPU 가용성이 동일한 경우 CPU는 더 이상 이를 구별하지 않으며 점수는 사실상 메모리로 넘어갑니다.

리소스 생략은 리소스에 낮은 가중치를 부여하는 것과 다릅니다. resources 배열을 지정하면 나열한 리소스에만 점수가 매겨집니다. 목록에 포함되지 않은 리소스는 계산에서 완전히 제외됩니다. 예를 들어 memory 항목이 없는 cpu: 100은 CPU로만 노드 점수를 매기고 메모리 가용성은 결과에 영향을 주지 않습니다. 영향을 줄이면서 리소스를 계산에 포함하려면 리소스를 생략하는 대신, 낮은 가중치로 나열합니다.

nvidia.com/gpu와 같은 액셀러레이터 리소스의 가중치는 해당 리소스에 대해 실제로 resources.requests를 선언하는 포드의 점수에만 영향을 줍니다. 액셀러레이터를 요청하지 않는 포드는 액셀러레이터 가중치의 영향을 받지 않습니다.

세 가지 액셀러레이터 리소스는 Kubernetes 확장 리소스입니다. 즉, 기본 제공되지 않고 플러그인을 통해 Kubernetes에 알려진 노드 수준 리소스입니다. 디바이스 플러그인이 디바이스 플러그인 API를 통해 kubelet에 해당 리소스를 알리는 경우에만 점수가 매겨집니다. 디바이스 드라이버만으로 노드에서 사용할 수 있는 리소스는 nodeResourcesFit 플러그인에 표시되지 않으며 점수가 매겨지지 않습니다. 동적 리소스 할당(DRA)을 통해 관리되는 리소스는 별도의 플러그인에 의해 예약되며 nodeResourcesFit 점수 책정에 포함되지 않으므로, DRA를 활성화해도 이 파라미터의 동작 방식은 변경되지 않습니다. NVIDIA 디바이스 플러그인 구성에 대한 자세한 내용은 NVIDIA DRA 및 디바이스 플러그인을 참조하세요. Neuron 디바이스 구성에 대한 자세한 내용은 Neuron 디바이스 관리를 참조하세요.

점수 책정 전략은 스케줄러가 각 노드의 점수를 계산하는 데 사용하는 여러 입력 중 하나입니다. 스케줄러가 노드를 필터링하고 점수를 매기는 방법에 대한 자세한 내용은 Kubernetes 설명서의 Scheduling Framework를 참조하세요.

점수 책정 전략에 대한 고려 사항

실행 중인 포드는 이동되지 않습니다. Kubernetes 스케줄러는 이미 실행 중인 포드를 재배치하지 않습니다. 점수 책정 전략을 변경하면 향후 규모 조정 결정에만 영향을 미치며 기존 포드 배치는 영구적입니다. 이미 실행 중인 포드를 리밸런싱하려면 포드를 제거하거나 다시 시작합니다.
필터링 동작은 변경되지 않습니다. 점수 책정 전략은 스케줄러가 기본 설정에 따라 노드 순위를 정하는 점수 책정 단계에만 영향을 줍니다. 포드가 노드에서 실행 가능한지를 결정하는 필터링 단계는 변경되지 않습니다. 노드에 맞지 않는 포드는 여전히 두 전략 모두에서 해당 노드에 예약되지 않습니다.
MostAllocated는 영향 범위를 집중합니다. 더 적은 수의 노드에 워크로드를 압축할 경우 노드가 비정상 상태가 되거나 인스턴스가 사용 중지되거나 가용 영역이 중단될 때 한 번에 영향을 받는 포드 수가 많아집니다. 포드 이탈이 많은 경우 집약적으로 압축된 노드도 더 빠르게 채워지므로, 새 용량이 프로비저닝되는 동안 포드가 Pending 상태로 남겨질 수 있습니다.
스케줄러와 노드 관리는 서로 다른 계층에서 작동합니다. 점수 책정 전략은 포드를 이미 실행할 수 있는 여러 노드 사이에서 포드 배치에 영향을 줍니다. EKS Auto Mode 또는 Karpenter가 노드를 프로비저닝하거나 제거하는 방법은 변경되지 않습니다. 구성을 변경하기 전에 워크로드의 결합된 동작을 검증합니다.

컨트롤러 관리자: Horizontal Pod Autoscaler 동기화 기간

컨트롤러 관리자는 Horizontal Pod Autoscaler(HPA) 컨트롤러를 포함하여 클러스터 상태를 원하는 상태로 전환하는 Kubernetes 컨트롤러를 실행합니다. 각 주기에서 HPA 컨트롤러는 각 HorizontalPodAutoscaler 객체에 대한 지표를 검색하고, 원하는 복제본 수를 계산하며, 수가 변경된 경우 대상 워크로드를 업데이트합니다.

필드	설명	지원되는 값	기본값
`horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod`	HPA 컨트롤러가 규모 조정 결정을 평가하는 빈도입니다.	`10s`~`15s`	`15s`

동기화 기간을 단축하면 용량을 추가하기 전에 전체 주기를 기다리는 대신, 로드가 증가한 후 워크로드가 더 빨리 확장됩니다.

이 파라미터를 구성하려면 클러스터가 Amazon EKS 프로비저닝된 컨트롤 플레인에 있어야 합니다. 간격을 단축하면 HPA 컨트롤러가 클러스터의 모든 HorizontalPodAutoscaler 객체를 조정하여 더 많은 API 요청을 생성하는 속도가 빨라집니다. 각 조정은 하나 이상의 API 요청을 소비하고, 복제본 수를 변경하는 조정은 두 개를 더 소비합니다. 프로비저닝된 컨트롤 플레인 클러스터는 항상 까다로운 워크로드를 처리할 준비가 된 컨트롤 플레인 용량을 사전 할당하므로, 추가 로드를 충당할 수 있는 크기로 설정됩니다. 자세한 내용은 Amazon EKS 프로비저닝된 컨트롤 플레인 섹션을 참조하세요.

클러스터가 지원하는 HPA 객체 수에 미치는 영향

동기화 기간을 단축하면 컨트롤 플레인이 일정에 따라 조정할 수 있는 HorizontalPodAutoscaler 객체 수가 줄어듭니다. 컨트롤러가 동일한 대기열을 처리하는 데 걸리는 시간이 줄어들기 때문입니다. 기간을 15s에서 10s로 줄이면 지원되는 객체 수가 약 1/3 감소합니다. 동기화 기간을 단축하기 전에 클러스터의 HorizontalPodAutoscaler 객체 수를 계산하고 더 짧은 기간에도 규모 조정 티어에서 해당 수를 여전히 지원하는지 확인합니다.
```
kubectl get hpa --all-namespaces --no-headers | wc -l
```
EKS는 HPA 객체 수를 기준으로 동기화 기간을 검증하지 않습니다. 더 짧은 기간에서 지원하는 것보다 클러스터에 이미 더 많은 HorizontalPodAutoscaler 객체가 있는 경우에도 구성이 변경됩니다. 변경하기 전에 개수를 직접 확인합니다.
지원되는 수를 초과하면 자동 크기 조정의 성능이 자동으로 저하됩니다. 컨트롤러가 기간에 모든 객체를 처리할 수 없는 경우 일부 객체는 일정에 따라 조정되지 않습니다. EKS는 이 조건에 대한 경보 또는 Kubernetes 이벤트를 생성하지 않으며, 의도한 효과와는 반대로 자동 규모 조정이 예상보다 느리게 응답합니다. 동기화 기간을 단축한 후 규모 조정 지연이 관찰되면 파라미터를 기본값(15s)으로 되돌립니다.
동기화 기간은 클러스터의 모든 HPA 객체에 적용됩니다. 객체 또는 네임스페이스마다 다른 동기화 기간을 설정할 수 없습니다.

컨트롤러 관리자: 종료된 포드 폐영역 회수 임계치

컨트롤러 관리자는 종료된 포드 폐영역 회수기(포드 GC 컨트롤러)를 실행합니다. 클러스터에서 종료된 포드 수가 임계치를 초과한 후 이 컨트롤러는 종료된 포드(Succeeded 또는 Failed 단계)를 삭제합니다. terminatedPodGcThreshold 파라미터는 해당 임계치를 설정합니다.

필드	설명	지원되는 값	기본값
`podGcControllerConfig.terminatedPodGcThreshold`	종료된 포드 폐영역 회수기가 종료된 포드 삭제를 시작하기 전에 존재할 수 있는 종료된 포드 수입니다.	`10000`~`12500`	`12500`

폐영역 회수기는 고정된 20초 주기로 실행됩니다. 임계치를 낮추면 회수기는 카운트가 새 임계치에 도달할 때까지 다음 주기에 가장 오래된 종료된 포드를 강제로 삭제하기 시작합니다.

이 파라미터를 구성하려면 클러스터가 Amazon EKS 프로비저닝된 컨트롤 플레인에 있어야 합니다. 임계치를 낮추면 컨트롤러가 클러스터 데이터베이스(etcd)에 대해 수행하는 폐영역 회수 작업이 증가합니다. 각 회수 패스는 더 많은 종료된 포드를 쿼리, 처리 및 삭제할 수 있습니다. 프로비저닝된 컨트롤 플레인 클러스터는 항상 까다로운 워크로드를 처리할 준비가 된 컨트롤 플레인 용량을 사전 할당하므로, 추가 로드를 충당할 수 있습니다. 자세한 내용은 Amazon EKS 프로비저닝된 컨트롤 플레인 섹션을 참조하세요.

종료된 포드 폐영역 회수 임계치에 대한 고려 사항

임계치를 낮추면 종료된 초과 포드가 즉시 삭제됩니다. 임계치를 낮추면(예: 12500에서 10000으로) 폐영역 회수 컨트롤러가 다음 주기에 가장 오래된 종료된 포드를 강제로 삭제하기 시작합니다. 종료된 포드 수가 새 임계치에 도달할 때까지 컨트롤러는 계속됩니다. 점진적으로 감소하지 않습니다.
임계치는 소유자에 관계없이 종료된 모든 포드에 적용됩니다. 작업, CronJob 또는 배포가 소유하든, 독립 실행형이든 상관없이 Succeeded 또는 Failed 단계의 포드에 영향을 줍니다. 실제로 작업 및 CronJob 포드는 일반적으로 종료된 포드 수에 가장 많이 기여하니다.
임계치를 낮추면 디버깅 기간이 줄어듭니다. 완료된 포드 및 실패한 포드는 kubectl get pods 및 kubectl logs에서 더 빨리 사라집니다. 완료된 작업 포드의 종료 코드 또는 로그를 검사하는 자동화의 작동 기간은 더 짧습니다.
임계치는 글로벌 클러스터 설정입니다. 네임스페이스 또는 작업별로 구성할 수 없습니다. 개별 작업 포드의 수명 주기를 제어하려면 해당 작업에서 ttlSecondsAfterFinished를 사용합니다.

API 서버: 이벤트 보존

API 서버는 Kubernetes 컨트롤 플레인의 프론트엔드입니다. Kubernetes API를 제공하고 클러스터 데이터베이스(etcd)에 클러스터 상태를 유지합니다. Kubernetes는 포드 예약 결정, 이미지 풀, 상태 확인 실패, 규모 조정 작업 등 클러스터에서 발생하는 상황을 설명하는 이벤트를 기록합니다.

필드	설명	지원되는 값	기본값
`eventTtl`	API 서버가 Kubernetes 이벤트를 삭제하기 전에 유지하는 기간입니다.	`10m`~`60m`	`60m`

대규모 배치 작업, AI 워크로드, CI/CD 파이프라인, 빈번한 CronJob과 같이 이탈이 많은 워크로드를 실행하는 클러스터에서는 수천 개의 이벤트가 빠르게 누적됩니다. 보존된 모든 이벤트는 클러스터가 실행해야 하는 객체와 경쟁하는 클러스터 데이터베이스 공간을 소비합니다. 이벤트 수집이 커지면 API 서버 목록 작업을 지원하는 데 더 많은 비용이 듭니다.

이벤트 보존 기간을 단축하면 수명이 짧은 이러한 진단 데이터가 더 빨리 지워지므로, 클러스터 데이터베이스 스토리지 부담이 줄어들고 이벤트가 많은 쿼리에 대한 API 서버 응답 시간이 향상됩니다.

보존 기간이 짧을수록 다음과 같은 경우에 적합합니다.

클러스터는 대량의 이벤트를 생성하는 배치, CI/CD, AI 또는 CronJob 워크로드를 실행합니다.
클러스터 데이터베이스 스토리지가 제한에 근접한 것을 확인했습니다.
외부 시스템을 사용하여 이벤트를 지속적으로 캡처하고, 과거 디버깅을 위해 kubectl get events에 의존하지 않습니다.

이벤트 보존에 대한 고려 사항

변경 사항은 새 이벤트에만 적용됩니다. Kubernetes는 이벤트가 생성될 때 이벤트의 만료를 설정합니다. 이미 존재하는 이벤트는 생성 시점에 유효한 보존 기간을 유지하고 해당 일정에 따라 만료됩니다. eventTtl 단축은 클러스터 데이터베이스에 이미 있는 이벤트의 수명을 단축하지 않으므로, 기존 이벤트가 만료되면 스토리지에서 감소가 점진적으로 적용됩니다.
삭제된 이벤트는 복구할 수 없습니다. Kubernetes가 이벤트를 제거하면 이벤트가 영구적으로 사라집니다. 의도한 것보다 보존 기간을 더 단축하고 이벤트 기록을 잃는 경우 복원할 방법이 없습니다. 따라서 이 값을 단축하기 전에 문제 해결을 위해 의존하는 모든 항목이 클러스터 외부에서 캡처되었는지 확인합니다.
이벤트는 구성된 기간을 약간 초과하여 유지될 수 있습니다. 경우에 따라 컨트롤 플레인 리더 선정 과정에서 발생할 수 있는 etcd 리스 갱신으로 인해 이벤트의 만료 기간이 구성한 값 이상으로 연장될 수 있습니다.
디버깅 기간 단축. 보존 기간이 짧을수록 kubectl get events 및 kubectl describe로 표시되는 기간이 단축됩니다. 클러스터에서 이벤트를 스크레이핑하는 모니터링 도구에는 사용 가능한 데이터가 적습니다. 스토리지 효율성과 디버깅 워크플로의 균형을 조율하는 값을 선택합니다.
설정은 클러스터 전체에 적용됩니다. 보존은 포드 예약, 노드 조건 및 규모 조정 이벤트를 포함한 모든 네임스페이스의 모든 이벤트에 적용됩니다. 네임스페이스마다 서로 다른 보존 기간을 설정할 수 없습니다.

API 서버: 서비스 노드 포트 범위

Kubernetes는 이 범위의 포트를 포트가 필요한 각 서비스의 모든 노드에 할당합니다. 여기에는 NodePort 유형의 서비스와 기본적으로 LoadBalancer 유형의 서비스가 포함됩니다.

필드	설명	지원되는 값	기본값
`serviceNodePortRange.minPort`	범위에서 가장 낮은 포트입니다.	`10260`~`32767`	`30000`
`serviceNodePortRange.maxPort`	범위에서 가장 높은 포트입니다.	`10260`~`32767`	`32767`

minPort는 maxPort보다 작거나 같아야 합니다. Amazon EKS는 minPort가 maxPort보다 큰 구성을 거부합니다.

범위를 변경하면 조직에서 이미 적용하는 네트워크 및 방화벽 정책에 따라 노드 포트 할당을 조정할 수 있습니다. 범위를 확장하면 단일 클러스터가 지원할 수 있는 서비스 수도 증가합니다. 이 파라미터는 마이그레이션 중에 특히 유용합니다. Amazon EKS로 이동하는 애플리케이션과 이를 직접 호출하는 클라이언트는 종종 특정 고정 포트에서 서비스를 기대하곤 합니다. 이러한 포트가 기본 범위를 벗어나는 경우 일반적인 옵션은 애플리케이션을 수정하거나 그 앞에 프록시를 배치하는 것입니다. 범위를 애플리케이션이 이미 사용하는 포트에 맞게 정렬하면 해당 작업이 제거되므로, 워크로드를 다시 작성하거나 유지할 네트워크 구성 요소를 추가하지 않고도 EKS로 이동할 수 있습니다.

범위가 10260 및 32767로 제한되는 이유

10260의 하한을 사용하면 kubelet 상태 포트(10248) 및 kube-proxy 상태 확인 포트(10256)를 포함하여 노드의 Kubernetes 시스템 구성 요소가 이미 사용하는 포트에서 NodePort 할당을 방지합니다.

32767의 상한을 사용하면 Linux 임시 포트 범위(일반적으로 32768부터 시작)와 중첩되지 않습니다. NodePort가 임시 범위에 속하는 경우 커널은 노드에서 아웃바운드 연결을 위해 해당 포트를 선택하고 서비스와 충돌할 수 있습니다.

서비스 노드 포트 범위에 대한 고려 사항

기존 서비스는 할당된 포트를 유지합니다. 범위를 좁히면 이미 새 범위와 겹치지 않는 포트를 보유한 서비스는 계속 작동하고 kube-proxy는 트래픽을 해당 서비스로 계속 라우팅합니다. Amazon EKS는 범위가 변경되면 기존 서비스에 포트를 재할당하지 않습니다.
서비스를 다시 생성하면 포트가 재할당됩니다. 범위를 벗어난 포트를 보유하는 서비스가 삭제되고 다시 생성되면 해당 포트를 더 이상 할당할 수 없습니다. 기존 서비스가 의존하는 범위를 좁히기 전에, 특히 배포 프로세스가 서비스를 업데이트하지 않고 다시 생성하는 경우 이를 계획합니다.
범위를 벗어나는 새 할당은 거부됩니다. 구성된 범위를 벗어난 포트가 필요한 서비스를 생성하거나 업데이트하면 API 서버의 검증 오류와 함께 작업에 실패합니다.
명시적으로 지정된 포트도 검증됩니다. Kubernetes가 값을 할당하도록 하지 않고 서비스가 직접 nodePort 값을 지정하는 경우 해당 포트는 구성된 범위 내에 있어야 합니다. 이전에 구성한 더 넓은 범위에서 동일한 포트가 유효했더라도 범위를 벗어난 정적 포트 요청은 거부됩니다.
범위는 클러스터 전체입니다. 네임스페이스마다 서로 다른 범위를 구성할 수 없습니다.

이 파라미터를 변경하기 전에 보안 그룹 및 네트워크 ACL이 새 범위에서 트래픽을 허용하고 범위가 노드의 다른 소프트웨어에서 사용하는 포트와 충돌하지 않는지 확인합니다.

고려 사항

고급 컨트롤 플레인 파라미터를 구성하기 전에 다음을 검토합니다.

클러스터 전체 범위 - 컨트롤 플레인 파라미터는 전체 클러스터와 해당 클러스터에서 실행 중인 모든 워크로드에 적용됩니다. 개별 네임스페이스 또는 워크로드로 범위를 지정할 수 없습니다. 프로덕션에 적용하기 전에 비프로덕션 클러스터에서 파라미터 변경 사항을 테스트합니다.
Horizontal Pod Autoscaler 동기화 기간 및 종료된 포드 폐영역 회수 임계치에 필요한 프로비저닝된 컨트롤 플레인 - horizontalPodAutoscalerSyncPeriod 및 terminatedPodGcThreshold 파라미터는 Amazon EKS 프로비저닝된 컨트롤 플레인을 사용하는 클러스터에서만 사용할 수 있습니다. Amazon EKS는 컨트롤 플레인 리소스 소비를 크게 늘리는 파라미터를 컨트롤 플레인 용량이 사전 할당된 클러스터로 제한합니다. 표준 컨트롤 플레인 모드의 클러스터에서 파라미터 중 하나를 설정하면 작업에 실패합니다. 이를 사용하려면 먼저 클러스터를 프로비저닝된 컨트롤 플레인 규모 조정 티어로 이동합니다. 자세한 내용은 Amazon EKS 프로비저닝된 컨트롤 플레인 섹션을 참조하세요.
Horizontal Pod Autoscaler 동기화 기간 및 종료된 포드 폐영역 회수 임계치에 대한 종료 제한 - horizontalPodAutoscalerSyncPeriod 또는 terminatedPodGcThreshold가 기본값 이외의 값으로 설정된 경우 클러스터의 컨트롤 플레인을 프로비저닝됨 모드에서 표준 모드로 다시 이동할 수 없습니다. 표준 모드로 돌아가려면 먼저 두 파라미터를 모두 기본값(15s 및 12500)으로 다시 설정한 다음, 컨트롤 플레인 규모 조정 티어를 standard로 변경합니다.
기본값으로 복구 - Amazon EKS는 전용 재설정 작업을 제공하지 않으며, 업데이트에서 필드를 생략하면 삭제하지 대신, 현재 값이 그대로 유지됩니다. 파라미터를 기본값으로 되돌리려면 파라미터를 명시적으로 기본값으로 설정합니다. 클러스터가 실행하는 Kubernetes 버전에 대해 DescribeClusterVersions를 사용하여 기본값을 검색합니다. 자세한 내용은 고급 Kubernetes 컨트롤 플레인 파라미터 구성 섹션을 참조하세요.
업데이트 시맨틱 - 업데이트가 기존 구성과 병합됩니다. 지정한 필드만 변경되고 생략한 필드는 현재 값을 유지합니다. 이는 여러 구성 요소와 단일 구성 요소 내에서 모두 적용됩니다. 예를 들어 스케줄러 구성만 지정하는 업데이트는 컨트롤러 관리자와 API 서버 구성을 변경하지 않습니다.
현재 구성 보기 - describe-cluster 작업은 사용자 지정하지 않은 파라미터와 해당 기본값을 포함하여 컨트롤 플레인에서 실행되는 전체 구성을 반환합니다.
기본값과 지원되는 값은 Kubernetes 버전 사이에서 변경 가능 - 이 주제에 설명된 값은 게시 시점에 사용 가능한 Kubernetes 버전에 적용됩니다. DescribeClusterVersions를 사용하여 각 파라미터 및 Kubernetes 버전에 대해 현재 기본값과 지원되는 값을 검색합니다. 고급 Kubernetes 컨트롤 플레인 파라미터 구성을(를) 참조하세요.
기존 클러스터는 변경되지 않음 - Amazon EKS는 기존 클러스터의 동작을 변경하지 않습니다. 파라미터를 명시적으로 설정할 때까지 모든 클러스터는 기본 파라미터 값으로 계속 실행됩니다.
변경 사항이 즉시 적용되지 않음 - UpdateClusterConfig가 반환될 때 구성 변경이 적용되지 않습니다. Amazon EKS는 컨트롤 플레인의 롤링 업데이트를 통해 새 구성을 적용하므로 변경 사항이 완전히 적용되기까지 몇 분 정도 기다려야 합니다. 업데이트가 완료되면 클러스터가 ACTIVE 상태로 돌아갑니다. DescribeUpdate 작업을 사용하여 진행 상황을 추적하거나 aws eks wait cluster-active를 사용하여 변경이 완료될 때까지 차단할 수 있습니다.
감사 가능성 - Amazon EKS는 각 구성을 적용하기 전에 검증하고, 구성 변경 사항을 AWS CloudTrail에 기록합니다.
도구 지원 - 고급 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(미국) 리전 및 AWS 중국 리전에서 사용할 수 있습니다.
요금 - 컨트롤 플레인 파라미터 구성에 대한 추가 요금은 없습니다. horizontalPodAutoscalerSyncPeriod를 사용하려면 프로비저닝된 컨트롤 플레인이 필요하며, 이때 규모 조정 티어의 시간당 요금으로 비용이 청구됩니다. 자세한 내용은 Amazon EKS 요금을 참조하세요.

다음 단계

고급 Kubernetes 컨트롤 플레인 파라미터 구성 - AWS CLI 및 AWS Management Console을 사용하여 컨트롤 플레인 파라미터를 설정하고 봅니다.
Amazon EKS 프로비저닝된 컨트롤 플레인 - 예측 가능한 고성능을 위해 컨트롤 플레인 용량을 사전 할당합니다.

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

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

문서 규칙

프로비저닝된 컨트롤 플레인 시작하기

컨트롤 플레인 파라미터 구성