EKS Control Plane Deep Dive — CRD at Scale 종합 가이드

2026-03-24 작성2026-09-18 수정24분 읽기

CRD(Custom Resource Definition) 기반 플랫폼을 EKS 위에서 운영할 때, Control Plane은 가장 먼저 병목이 되는 지점입니다. 이 가이드는 Control Plane이 어떻게 동작하는지 이해하고, CRD가 미치는 구체적 영향을 파악한 뒤, Provisioned Control Plane(PCP)과 모니터링을 통해 선제적으로 대응하는 실전 전략을 제공합니다.

1. EKS Control Plane 내부 아키텍처

1.1 물리적 인프라 구조

EKS의 Control Plane은 AWS가 관리하는 전용 VPC 내에서 실행됩니다. 고객의 워커 노드와는 분리된 독립적인 인프라입니다.

EKS Control Plane (AWS 관리형)
├── kube-apiserver (최소 2개, 다중 AZ 분산)
├── kube-controller-manager
├── kube-scheduler
├── etcd (분산 키-값 저장소)
└── Network Load Balancer (API Server 엔드포인트)

핵심 포인트:

Control Plane 컴포넌트는 다중 AZ에 분산되어 고가용성을 보장합니다
고객에게는 NLB를 통해 단일 API Server 엔드포인트가 노출됩니다
Control Plane은 AWS가 완전 관리하며, 고객 VPC와 분리된 환경에서 실행됩니다

1.2 etcd — Control Plane의 심장

etcd는 Kubernetes의 모든 상태(Pod, Service, CRD 오브젝트 등)를 저장하는 분산 키-값 저장소입니다. Control Plane 성능의 핵심 병목이 되는 이유:

특성	설명	CRD 영향
DB Size 한도	Standard 티어 8GB, Provisioned 티어 16GB	CRD 오브젝트가 많을수록 DB 크기 증가
요청 크기 제한	단일 오브젝트 최대 1.5MB	큰 spec을 가진 CR이 한도에 근접 가능
Watch Stream	변경 사항을 실시간으로 전파	CRD 컨트롤러가 Watch를 추가할수록 부하 증가
RAFT 합의	쓰기 시 과반수 합의 필요	쓰기가 많은 CRD 패턴에서 지연 발생

etcd 아키텍처 진화

AWS는 EKS의 etcd 계층을 지속적으로 개선하고 있으며, 예측 가능한 성능(일관된 지연 시간), 데이터 내구성 향상, 가용성 개선이 진행 중입니다.

2. Control Plane 자동 스케일링

2.1 자동 스케일링 동작 원리

EKS는 Control Plane 인스턴스를 자동으로 수직 스케일링합니다. 워크로드 부하에 따라 API Server, etcd 등의 리소스가 자동으로 조정됩니다. 주요 스케일링 신호:

API Server 부하: inflight requests 수, 요청 지연 시간
etcd 부하: 데이터베이스 크기, Watch 스트림 수
스케줄링 부하: 스케줄링 대기 Pod 수
데이터 플레인 규모: Worker Node 수에 따른 선제적 스케일업

2.2 스케일링 특성

Scale Up: 부하 증가 감지 시 자동으로 스케일업
Scale Down: 부하 감소 후 보수적으로 스케일다운 (급격한 축소 방지)
Standard 모드에서는 스케일링 범위에 상한이 있으며, Provisioned 모드로 이를 확장할 수 있습니다

핵심 인사이트

Standard 티어에서는 etcd DB Size가 8GB로 고정됩니다. CRD 오브젝트가 많은 플랫폼에서는 이 한도가 가장 먼저 병목이 됩니다. 자동 스케일링이 CPU/Memory를 아무리 올려도 etcd 용량은 늘어나지 않습니다.

3. EKS Provisioned Control Plane (PCP)

3.1 개요

**EKS Provisioned Control Plane(PCP)**은 re:Invent 2025에서 GA로 출시되었습니다¹. 고객이 직접 Control Plane의 스케일링 티어(T-Shirt Size)를 선택하여 미리 할당할 용량을 설정할 수 있는 기능입니다.

PCP는 선택한 티어의 용량을 선제적으로 확보합니다. 실제 API 처리량과 지연 시간은 요청 종류, 컨트롤러 패턴, Kubernetes 버전에 따라 달라지므로 워크로드 검증이 필요합니다.

3.2 두 가지 운영 모드

모드	설명
Standard (동적 모드)	기존과 동일. 자동으로 부하에 따라 스케일링. 부하 감소 시 보수적으로 스케일다운
Provisioned (프로비저닝 모드)	고객이 XL/2XL/4XL/8XL 중 원하는 티어를 선택. 티어 간 자동 전환은 없으며, 관리자가 변경하거나 별도의 자동화를 구성해야 함

3.3 티어별 사양 및 가격

티어	etcd DB	SLA	시간당 가격
Standard	8GB	99.95%	$0.10
XL	16GB	99.99%	$1.65
2XL	16GB	99.99%	$3.40
4XL	16GB	99.99%	$6.90
8XL	16GB	99.99%	$13.90

Standard의 $0.10/시간은 Kubernetes 표준 지원 요금입니다. Provisioned 행의 금액은 표준/연장 지원 요금에 추가되는 티어 요금입니다. 최신 가격은 AWS EKS Pricing에서 확인하세요.

공식 티어 사양에 따르면 Standard의 etcd 한도는 8 GB, XL·2XL·4XL·8XL은 모두 16 GB입니다. GB 표기는 공식 문서의 단위를 따릅니다. Provisioned 내에서 티어를 높여도 etcd 용량은 증가하지 않습니다. API 동시 처리 seat와 스케줄링 설정은 Kubernetes 버전별 사양을 확인하세요.

3.4 Provisioned 티어에서만 사용 가능한 기능

기능	Standard	XL 이상
API 동시 처리 용량 사전 지정	부하에 따른 자동 용량 조정	Kubernetes 버전·티어별 용량 사전 지정
etcd DB Size 16GB	8GB 고정	16GB
etcd Event Sharding	불가	가능 (이벤트 객체를 별도 etcd 파티션으로 분리)
99.99% SLA	99.95%	99.99%

CRD 플랫폼에 Provisioned 티어를 권장하는 이유

CRD 기반 플랫폼에서 가장 먼저 한계에 도달하는 것은 etcd DB Size입니다. Standard 티어의 8GB 한도는 CRD 오브젝트가 많은 환경에서 금방 소진됩니다. Provisioned 티어는 16GB로 2배 확장되며, Event Sharding을 통해 이벤트 객체의 부하도 분리할 수 있습니다.

상세 사이징이 필요하신가요?

티어별 K8s 파라미터 (API Server inflight, Scheduler QPS), APF seat 산정 공식, 10K 노드 사이징 예시, 실제 고객 사례, ClusterLoader2 성능 검증 방법은 **PCP 티어 사이징 & 성능 검증 가이드**를 참조하세요.

3.5 CLI/API 사용법

클러스터 생성 시 티어 지정:

aws eks create-cluster --name prod \
  --role-arn arn:aws:iam::012345678910:role/eks-service-role \
  --resources-vpc-config subnetIds=subnet-xxx,securityGroupIds=sg-xxx \
  --control-plane-scaling-config tier=XL

기존 클러스터 티어 변경:

aws eks update-cluster-config --name example \
  --control-plane-scaling-config tier=XL

업데이트 진행 확인:

aws eks describe-update --name example --update-id <update-id>
# Response: { "update": { "type": "ScalingTierConfigUpdate", "status": "Successful" } }

클러스터 정보 확인:

aws eks describe-cluster --name example
# Response에 controlPlaneScalingConfig.tier 필드 포함

참고: CLI 플래그 형식(--control-plane-scaling-config tier=XL)은 AWS CLI 버전에 따라 변경될 수 있습니다. 최신 명령 형식은 AWS CLI Command Reference - EKS를 확인하세요.

3.6 PCP 관련 클러스터 속성

속성	설명
`controlPlaneScalingConfig.tier`	현재 프로비저닝된 티어 (Standard/XL/2XL/4XL/8XL)

4. CRD가 Control Plane에 미치는 영향

CRD 기반 플랫폼을 운영할 때 Control Plane에 미치는 영향을 정확히 이해해야 합니다. 영향은 크게 etcd, API Server 두 축으로 나뉩니다.

4.1 etcd에 대한 영향 (가장 중요)

영향 요인	메커니즘	영향도
DB Size 증가	CRD 오브젝트가 etcd 저장소를 점유	높음
Watch Stream 부하	CRD 컨트롤러가 Watch 스트림을 생성하여 etcd gRPC 부하 증가	높음
Request Size	개별 CRD 오브젝트가 1.5MB 제한에 근접 가능	중간
List Call 비용	CRD는 JSON 인코딩을 사용 (protobuf 아님) → 성능 병목	높음

etcd DB Size 제한 (PCP 티어별):

티어	DB Size 한도	단일 오브젝트 제한
Standard	8GB	1.5MB (변경 불가)
Provisioned (XL 이상)	16GB	1.5MB (변경 불가)

4.2 API Server에 대한 영향

CRD 관련 API Server 성능 이슈:

JSON vs Protobuf: CRD는 JSON 직렬화를 사용하므로 built-in 리소스 대비 List/Watch 성능이 현저히 저하됩니다
APF (API Priority and Fairness): List 요청은 Work Estimator에 의해 최대 10개 시트를 차지할 수 있어, inflight 요청 한도에 빠르게 도달합니다
Watch Cache: CRD의 Watch Cache 용량은 built-in 리소스와 동일하게 기본 100입니다

4.3 증상별 원인 매핑

실제 운영 환경에서 발생하는 증상과 그 원인을 매핑하면 다음과 같습니다:

글씨가 작으면 확대해서 확인할 수 있습니다.

다이어그램

CRD 부하 공식

Control Plane 부하 = CRD 타입 수 x 오브젝트 크기 x 컨트롤러 패턴(List/Watch 빈도)

세 가지 요소를 모두 관리해야 합니다. CRD 타입이 적더라도 오브젝트가 크거나 컨트롤러가 비효율적이면 동일한 문제가 발생합니다.

5. EKS Control Plane 모니터링

EKS는 Control Plane에 대한 4가지 차원의 Observability를 제공합니다:

┌─────────────────────────────────────────────────────────────────────┐
│                 EKS Control Plane Observability                      │
├──────────────────┬──────────────────┬────────────────┬──────────────┤
│ ① CloudWatch     │ ② Prometheus     │ ③ Control      │ ④ Cluster    │
│    Vended Metrics│    Metrics       │    Plane       │    Insights  │
│                  │    Endpoint      │    Logging     │              │
├──────────────────┼──────────────────┼────────────────┼──────────────┤
│ AWS/EKS 네임스페이스│ KCM/KSH/etcd    │ API/Audit/     │ Upgrade      │
│ (자동, 무료)       │ (Prometheus      │ Auth/CM/Sched  │ Readiness    │
│                  │  호환 K8s API)    │ (CloudWatch    │ Health Issues│
│                  │                  │  Logs)         │ Addon Compat │
├──────────────────┼──────────────────┼────────────────┼──────────────┤
│ v1.28+ 자동       │ v1.28+ 수동      │ 모든 버전        │ 모든 버전 자동 │
└──────────────────┴──────────────────┴────────────────┴──────────────┘

5.1 CloudWatch Vended Metrics (자동, 무료)

K8s 1.28 이상 클러스터에서 추가 비용 없이 자동으로 CloudWatch AWS/EKS 네임스페이스에 핵심 Control Plane 메트릭이 게시됩니다.

주요 Vended Metrics:

컴포넌트	메트릭	설명	중요도
API Server	`apiserver_request_total`	총 API 요청 수	필수
API Server	`apiserver_request_total_4XX`	4xx 에러 요청 수	필수
API Server	`apiserver_request_total_5XX`	5xx 에러 요청 수	필수
API Server	`apiserver_request_total_429`	429 Throttling 요청 수	필수
API Server	`apiserver_request_duration_seconds_GET_P99`	GET 요청 지연 시간 p99	권장
etcd	`etcd_mvcc_db_total_size_in_bytes`	물리 파일 크기 (미사용 공간 포함, 용량 한도 판단용 아님)	권장
Scheduler	`scheduler_schedule_attempts_total`	전체 스케줄링 시도 수	권장
Scheduler	`scheduler_schedule_attempts_SCHEDULED`	성공 스케줄링 수	필수
Scheduler	`scheduler_schedule_attempts_UNSCHEDULABLE`	스케줄 불가 수	권장

티어 사용량 모니터링 메트릭:

메트릭	설명	활용
`apiserver_flowcontrol_current_executing_seats`	API Server 현재 동시 실행 시트 수	API Request Concurrency 티어 한도 대비 모니터링
`etcd_mvcc_db_total_size_in_use_in_bytes`	etcd DB 실제 사용 크기	Cluster Database Size 티어 한도 대비 모니터링
`etcd_mvcc_db_total_size_in_bytes`	etcd 물리 파일 크기	실제 사용량과 비교해 미사용 공간 확인

위 이름은 CloudWatch AWS/EKS 지표 기준입니다. Prometheus의 apiserver_storage_size_bytes도 물리 파일 크기이며, 용량 한도 초과를 결정하는 실제 사용량과 다릅니다. 사용량 알람에는 etcd_mvcc_db_total_size_in_use_in_bytes를 사용하세요. 이 지표의 Prometheus 제공 여부는 클러스터에서 확인하고, 제공되지 않으면 CloudWatch 값을 사용합니다.

5.2 Prometheus 호환 메트릭 엔드포인트

API Server뿐만 아니라 KCM(Kube-Controller-Manager), KSH(Kube-Scheduler), etcd 메트릭도 스크래핑할 수 있습니다.

메트릭 엔드포인트 경로:

# API Server 메트릭 (기존)
kubectl get --raw=/metrics

# Kube-Controller-Manager 메트릭
kubectl get --raw=/apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics

# Kube-Scheduler 메트릭
kubectl get --raw=/apis/metrics.eks.amazonaws.com/v1/ksh/container/metrics

# etcd 메트릭
kubectl get --raw=/apis/metrics.eks.amazonaws.com/v1/etcd/container/metrics

Prometheus 스크래핑 설정 예시:

scrape_configs:
  - job_name: 'kcm-metrics'
    honor_labels: true
    kubernetes_sd_configs:
      - role: endpoints
    scheme: https
    metrics_path: /apis/metrics.eks.amazonaws.com/v1/kcm/container/metrics
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabel_configs:
      - source_labels:
          [__meta_kubernetes_namespace, __meta_kubernetes_service_name,
           __meta_kubernetes_endpoint_port_name]
        action: keep
        regex: default;kubernetes;https

필요한 RBAC 권한:

rules:
  - apiGroups: ["metrics.eks.amazonaws.com"]
    resources: ["kcm/metrics", "ksh/metrics", "etcd/metrics"]
    verbs: ["get"]

CRD 운영에 특히 유용한 KCM/KSH 메트릭:

메트릭	소스	설명
`workqueue_depth`	KCM	컨트롤러별 작업 큐 깊이 — CRD 컨트롤러 부하 확인
`workqueue_adds_total`	KCM	큐에 추가된 총 항목 수
`workqueue_retries_total`	KCM	재시도 횟수 — CRD 컨트롤러 오류율 파악
`scheduler_pending_pods`	KSH	대기 중인 Pod 수
`scheduler_scheduling_duration_seconds`	KSH	스케줄링 지연 시간
`apiserver_flowcontrol_current_executing_seats`	API Server	APF별 현재 실행 시트 — CRD List 요청 영향 확인

Amazon Managed Prometheus (AMP) 통합:

EKS의 **Agentless Collector (Poseidon)**를 사용하면, 클러스터에 Prometheus를 설치하지 않고도 Control Plane 메트릭을 AMP 워크스페이스로 자동 수집할 수 있습니다.

EKS Console → Observability 탭 → Add scraper → AMP Workspace 선택

5.3 Control Plane Logging

EKS는 5가지 Control Plane 로그를 CloudWatch Logs로 내보낼 수 있습니다:

로그 유형	설명	CRD 활용 사례
API Server (api)	API 요청/응답 로그	CRD API 호출 패턴 분석
Audit (audit)	누가 무엇을 했는지 감사 로그	CRD 변경 추적, 보안 감사
Authenticator	IAM 인증 로그	인증 문제 디버깅
Controller Manager	KCM 진단 로그	CRD 컨트롤러 오류 분석
Scheduler	스케줄러 의사결정 로그	Pod 스케줄링 문제 분석

활성화 방법:

aws eks update-cluster-config --name my-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

CloudWatch Logs Insights 쿼리 예시 — CRD 관련 API 호출 패턴 분석:

-- CRD 관련 API 호출 패턴 분석
fields @timestamp, userAgent, verb, requestURI
| filter requestURI like /customresourcedefinitions/
| stats count(*) by verb, userAgent
| sort count(*) desc
| limit 20

5.4 Cluster Insights

EKS Cluster Insights는 자동으로 클러스터를 스캔하여 잠재적 문제를 탐지하고 권장사항을 제공합니다:

카테고리	설명	주기
Upgrade Insights	K8s 버전 업그레이드 시 문제가 될 수 있는 항목 탐지	24시간 + 수동
Configuration Insights	클러스터 구성 오류 탐지	24시간 + 수동
Addon Compatibility	EKS Addon이 다음 K8s 버전과 호환되는지 확인	24시간
Cluster Health Issues	현재 클러스터 건강 상태 이슈	24시간

aws eks list-insights --cluster-name my-cluster
aws eks describe-insight --cluster-name my-cluster --id <insight-id>

5.5 EKS Console Observability Dashboard

EKS Console에는 통합 Observability Dashboard가 포함되어 있습니다:

EKS Console → Cluster 선택 → Observability 탭
├── Health and Performance Summary (요약 카드)
├── Cluster Health Issues (건강 이슈 목록)
├── Control Plane Monitoring
│   ├── Metrics (CloudWatch 기반 그래프)
│   │   ├── API Server Request Types (Total, 4XX, 5XX, 429)
│   │   ├── etcd Database Size
│   │   └── Kube-Scheduler Scheduling Attempts
│   ├── CloudWatch Log Insights (사전 정의 쿼리)
│   └── Control Plane Logs (CloudWatch 링크)
└── Upgrade Insights (업그레이드 준비 상태)

5.6 모니터링 채널 비교표

채널	비용	설정	데이터 유형	PCP 지원
CloudWatch Vended Metrics	무료 (AWS/EKS)	자동 (v1.28+)	핵심 K8s 메트릭 (시계열)	티어 사용량 메트릭 포함
Prometheus Endpoint	무료 (스크래핑)	수동 구성 필요	KCM/KSH/etcd 상세 메트릭	확장 가능
Control Plane Logging	CloudWatch 표준 요금	수동 활성화	로그 (API/Audit/Auth/CM/Sched)	—
Cluster Insights	무료	자동	클러스터 건강/업그레이드 권장	PCP 티어 추천 (향후)
EKS Console Dashboard	무료	자동	시각화된 메트릭 + 로그 쿼리	티어 정보 표시

6. CRD 설계 베스트 프랙티스

6.1 오브젝트 크기 최소화

각 CR 인스턴스의 spec 크기를 가능한 작게 유지 (etcd 1.5MB 요청 제한)
대용량 데이터는 ConfigMap이나 외부 저장소 참조로 분리
status 필드도 필요한 정보만 포함 — 히스토리나 로그성 데이터는 외부로

6.2 CRD 수 관리

CRD 타입 수가 많으면 API Server Watch Cache와 etcd Watch Stream이 비례 증가
가능하면 유사한 리소스를 하나의 CRD로 통합 (subresource 패턴 활용)
사용하지 않는 CRD는 반드시 정리

6.3 컨트롤러 최적화

패턴	올바른 사용법	피해야 할 사용법
Watch resourceVersion	`resourceVersion`을 올바르게 사용	`resourceVersion=""` 사용 금지 (전체 목록 재조회)
List 호출	반드시 페이지네이션 사용	전체 List를 한 번에 조회
Informer	client-go의 SharedInformer 패턴 사용	각 컨트롤러가 독립적으로 Watch 생성
재연결	Watch가 끊겼을 때 Exponential Backoff 적용	즉시 재연결 시도 (thundering herd)

6.4 K8s 버전 최신 유지

**K8s 1.33+**에서 Streaming List 지원으로 대규모 List 성능이 크게 개선
가능하면 최신 K8s 버전을 사용하여 Control Plane 성능 개선 혜택을 받을 것

6.5 클러스터 아키텍처 권장사항

워크로드별 클러스터 분리:

CRD가 많은 경우: 코어 CRD 클러스터 / 워크로드 실행 클러스터를 분리
플랫폼 CRD와 테넌트 워크로드를 동일 클러스터에서 운영하면 상호 영향

Namespace 기반 격리:

Kubernetes ResourceQuota를 통해 namespace별 오브젝트 수 제한
잘못된 자동화나 버그로 인한 "오브젝트 폭주" 방지

7. 종합 권장사항 & 도입 로드맵

7.1 CRD 규모별 PCP 티어 선택 가이드

노드 수만으로 티어를 결정하지 않습니다. 아래는 후보를 좁히는 조건이며, 대표 피크 부하에서 API 지연·APF seat 사용량·스케줄링 속도를 검증해 선택합니다.

검증 조건	검토할 모드/티어	확인 사항
Standard에서 목표 지연과 처리량을 충족하고 etcd 여유가 충분함	Standard	대부분의 사용 사례에 대한 기본 선택
용량 사전 확보, 16 GB etcd 또는 99.99% SLA가 필요함	Provisioned XL 이상	XL이 실제 피크 부하를 충족하는지 검증
XL의 API 동시 처리 또는 스케줄링 용량이 부족함	2XL	해당 Kubernetes 버전의 티어 사양과 비교
2XL의 용량으로 목표를 충족하지 못함	4XL 또는 8XL	8XL도 etcd는 16 GB이며, 스케줄링 설정은 4XL과 같을 수 있음

7.2 규모별 컨트롤 플레인 메트릭 참고치

노드 수별 QPS·오브젝트 수·지연 시간의 산업 평균을 티어 선택 기준으로 사용하지 않습니다. 공개된 용량 한도와 자체 워크로드에서 측정한 운영 기준을 구분하세요.

메트릭	측정 기준	판단 기준
etcd DB 크기	실제 사용량과 물리 파일 크기를 각각 수집	Standard 8 GB, 모든 Provisioned 티어 16 GB 한도와 실제 사용량 비교
etcd 오브젝트 수	리소스별 개수와 오브젝트 크기	개수만으로 티어를 추정하지 않고 증가 원인·보관 정책 확인
API QPS (요청/초)	verb·리소스별 요청 rate	요청 종류별 APF 비용과 피크 부하를 함께 검증
API 요청 지연 (p99)	verb별 지연 분포	서비스의 자체 지연 목표와 비교
429 Throttle	요청 수 대비 429 비율과 지속 시간	APF, 클라이언트 재시도 및 요청 패턴 조사
Watch 연결 수	장기 실행 WATCH 요청 수	재연결 폭주와 컨트롤러별 변화 확인
CRD 타입 수	설치된 CRD와 각 CR 개수	타입 수만으로 용량이나 성능을 단정하지 않음
컨트롤러 Reconcile/초	컨트롤러별 rate·처리 시간·큐 깊이	재처리 폭주와 처리 지연을 구분

측정 방법

etcd 실제 사용량: CloudWatch etcd_mvcc_db_total_size_in_use_in_bytes; 물리 파일 크기와 구분
API QPS: apiserver_request_total rate (verb별 분리 권장)
429 Throttle: apiserver_request_total{code="429"} — 0이 아니면 즉시 조사
Watch 연결: apiserver_longrunning_requests{verb="WATCH"} — 컨트롤러/노드 수에 비례
Reconcile 속도: 각 컨트롤러의 controller_runtime_reconcile_total rate

etcd 크기 경고 기준

아래 값은 AWS 기본 알람이 아닌 운영 예시입니다. 문서의 GB를 예시 계산에서는 10⁹ bytes로 환산했으며, 실제 사용량 증가 속도와 대응 시간을 반영해 한도 도달 전에 조치하도록 조정하세요.

Standard (8 GB): Warning 6 GB, Critical 7.2 GB
XL/2XL/4XL/8XL (16 GB): Warning 12 GB, Critical 14.4 GB
사용하지 않는 CR과 보관 데이터를 정리하고 오브젝트 증가 원인을 조사합니다. Standard에서는 Provisioned 전환을 검토할 수 있지만, Provisioned 티어 상향은 etcd 한도를 늘리지 않습니다. 사용량이 계속 증가하면 데이터 외부화 또는 클러스터 분리를 검토합니다.

7.3 핵심 알람 설정

다음 임계값과 지속 시간은 운영 예시입니다. CloudWatch의 1분 주기 지표를 기준으로 요청·스케줄링 건수는 Sum, etcd 사용량은 Maximum을 사용하며, 누락 데이터를 정상 사용량 0으로 간주하지 않습니다. 자체 SLO와 정상 부하를 바탕으로 조정하세요.

알람 이름	메트릭	임계값	심각도	대응 액션
API Throttling	`apiserver_request_total_429`	> 10/분, 5분간	Critical	APF·재시도·요청 부하 조사 후 용량 검토
API Server Errors	`apiserver_request_total_5XX`	> 5/분, 3분간	Critical	Control Plane 로그 확인
etcd DB 사용량	`etcd_mvcc_db_total_size_in_use_in_bytes`	> 6 GB (Standard) / > 12 GB (Provisioned)	Warning	불필요한 CRD 리소스 정리
etcd DB 용량 여유	`etcd_mvcc_db_total_size_in_use_in_bytes`	> 7.2 GB (Standard) / > 14.4 GB (Provisioned)	Critical	한도 도달 전 증가 억제·데이터 정리·분리 검토
Scheduling 실패	`scheduler_schedule_attempts_UNSCHEDULABLE`	> 0, 10분간	Warning	노드 리소스 확인
API Concurrency	`apiserver_flowcontrol_current_executing_seats`	Kubernetes 버전별 티어 seat의 > 80%	Warning	상위 티어 프로비저닝 검토

7.4 통합 모니터링 스택 권장

통합 모니터링 아키텍처
│
[1] CloudWatch Vended Metrics (자동)
│   → AWS/EKS 네임스페이스 알람 설정
│   → Console Observability Dashboard 활용
│
[2] Prometheus Endpoint (수동 구성)
│   → AMP Agentless Scraper 또는 Self-hosted Prometheus
│   → KCM workqueue 메트릭으로 CRD 컨트롤러 모니터링
│   → Grafana 대시보드 구성
│
[3] Control Plane Logging (수동 활성화)
│   → audit + controllerManager 로그 필수 활성화
│   → CRD 관련 API 호출 패턴 분석
│
[4] Cluster Insights (자동)
    → 업그레이드 전 반드시 확인
    → PCP 티어 추천 기능 (향후)

7.5 단계별 도입 로드맵

단계	기간	주요 활동
Phase 1: 기본 설정	1주	CloudWatch 알람 설정, Control Plane Logging 활성화 (audit + controllerManager)
Phase 2: Prometheus 통합	2주	AMP Scraper 구성, KCM/KSH 메트릭 수집, Grafana 대시보드
Phase 3: PCP 적용	1주	워크로드 프로파일 분석 후 적정 PCP 티어 선택 (XL 이상 권장)
Phase 4: 최적화	지속	Cluster Insights 활용, 모니터링 데이터 기반 티어 조정, CRD 컨트롤러 튜닝

7.6 최종 요약 — 주요 과제별 대응 전략

과제	EKS 기능 활용	CRD 설계 대응
CRD로 인한 etcd 과부하	Provisioned 티어: etcd 16GB + Event Sharding	CR 오브젝트 크기·보관량을 줄이고 실제 사용량에 따라 Provisioned 전환 검토
API Server 성능 저하	Kubernetes 버전·PCP 티어별 API 동시 처리 용량 + APF 우선순위 관리	대표 피크 부하에서 API 처리량·지연 검증, 컨트롤러 List/Watch 패턴 최적화
스케줄링 한계	Kubernetes 버전·PCP 티어별 스케줄링 설정	대표 피크 부하에서 스케줄링 처리량 검증 후 필요한 용량 선택
Control Plane 안정성	Multi-AZ, 99.99% SLA (Provisioned)	SLO와 사전 확보 용량 필요성에 따라 Standard 또는 Provisioned 선택
비용 예측성	Kubernetes 지원 요금 + 선택한 PCP 티어의 시간당 추가 요금	워크로드 프로파일에 맞는 적정 티어 선택
가시성 부족	4가지 모니터링 채널 (Vended Metrics, Prometheus, Logging, Insights)	Phase 1~4 단계별 모니터링 도입

참고 자료

AWS 공식 문서:

AWS 블로그:

re:Invent 2025:

CNS429: Under the Hood — Architecting EKS for Scale and Performance — Control Plane 내부 아키텍처, 100k 노드 스케일링

Kubernetes upstream:

API Priority and Fairness
Consistent Reads from Cache (v1.31 Beta) — etcd 부하 감소
API Streaming (v1.31) — LIST 메모리 오버헤드 해결
CRD Watch 10-15x Memory Issue (#124680) — CRD Watch가 built-in 대비 10-15배 메모리 사용

etcd:

모니터링:

Grafana Dashboard: EKS Control Plane

8XL 티어 및 99.99% SLA 보장은 2026년 3월에 추가 출시되었습니다. ↩

목차​

1. EKS Control Plane 내부 아키텍처​

1.1 물리적 인프라 구조​

1.2 etcd — Control Plane의 심장​

2. Control Plane 자동 스케일링​

2.1 자동 스케일링 동작 원리​

2.2 스케일링 특성​

3. EKS Provisioned Control Plane (PCP)​

3.1 개요​

3.2 두 가지 운영 모드​

3.3 티어별 사양 및 가격​

3.4 Provisioned 티어에서만 사용 가능한 기능​

3.5 CLI/API 사용법​

3.6 PCP 관련 클러스터 속성​

4. CRD가 Control Plane에 미치는 영향​

4.1 etcd에 대한 영향 (가장 중요)​

4.2 API Server에 대한 영향​

4.3 증상별 원인 매핑​

5. EKS Control Plane 모니터링​

5.1 CloudWatch Vended Metrics (자동, 무료)​

5.2 Prometheus 호환 메트릭 엔드포인트​

5.3 Control Plane Logging​

5.4 Cluster Insights​

5.5 EKS Console Observability Dashboard​

5.6 모니터링 채널 비교표​

6. CRD 설계 베스트 프랙티스​

6.1 오브젝트 크기 최소화​

6.2 CRD 수 관리​

6.3 컨트롤러 최적화​

6.4 K8s 버전 최신 유지​

6.5 클러스터 아키텍처 권장사항​

7. 종합 권장사항 & 도입 로드맵​

7.1 CRD 규모별 PCP 티어 선택 가이드​

7.2 규모별 컨트롤 플레인 메트릭 참고치​

7.3 핵심 알람 설정​

7.4 통합 모니터링 스택 권장​

7.5 단계별 도입 로드맵​

7.6 최종 요약 — 주요 과제별 대응 전략​

Footnotes​

목차