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

2026-03-24 작성2026-06-30 수정27분 읽기

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)를 선택하여 **성능 바닥(floor)**을 설정할 수 있는 기능입니다.

기존에는 VAS의 자동 스케일링에만 의존했지만, PCP를 통해 선제적으로 최소 성능 보장 수준을 확보할 수 있습니다.

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

최신 가격은 AWS EKS Pricing 페이지에서 확인하세요.

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

기능	Standard	XL 이상
API Server 수평 확장 (2개 이상)	2개 제한	가능
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.6 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.7 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`	API 요청 지연 시간	권장
API Server	`apiserver_storage_size_bytes`	etcd 스토리지 크기 (defrag 전)	필수
Scheduler	`scheduler_schedule_attempts_total`	전체 스케줄링 시도 수	권장
Scheduler	`scheduler_schedule_attempts_SCHEDULED`	성공 스케줄링 수	필수
Scheduler	`scheduler_schedule_attempts_UNSCHEDULABLE`	스케줄 불가 수	권장

PCP 전용 추가 메트릭:

메트릭	설명	활용
`apiserver_flowcontrol_current_executing_seats_total`	API Server 현재 동시 실행 시트 수	API Request Concurrency 티어 한도 대비 모니터링
`etcd_mvcc_db_total_size_in_use_in_bytes`	etcd DB 실제 사용 크기	Cluster Database Size 티어 한도 대비 모니터링
`apiserver_storage_size_bytes`	defrag 전 스토리지 크기	etcd DB 크기 대체 메트릭

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 티어 선택 가이드

워크로드 프로파일	권장 티어	핵심 이유	월 비용 (예상)
노드 ~50개, 기본 애드온 (Karpenter, cert-manager)	Standard	기본 자동 스케일링으로 충분	~$73
노드 ~200개, 5개+ 오퍼레이터 (ArgoCD, Prometheus, 커스텀 컨트롤러)	XL	etcd 16GB 확보, 99.99% SLA	~$1,204
노드 ~500개, 서비스 메시 + GitOps + 멀티테넌트	2XL	향상된 API Server 처리량	~$2,482
노드 1,000개+, AI/ML 오퍼레이터 + 대규모 CRD 기반 파이프라인	4XL	API Server 수평 확장	~$5,037

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

각 규모에서 EKS 컨트롤 플레인 스케일링 팩터가 되는 핵심 메트릭의 산업 평균 참고치입니다. 실제 수치는 워크로드 패턴에 따라 달라지며, 임계값 초과 시 상위 티어를 검토해야 합니다.

메트릭	~50 노드 (Standard)	~200 노드 (XL)	~500 노드 (2XL)	1,000+ 노드 (4XL)
etcd DB 크기	0.5~1.5 GB	2~5 GB	5~10 GB	10~20 GB
etcd 오브젝트 수	~5,000	~30,000	~100,000	300,000+
API QPS (요청/초)	20~50	100~300	300~800	1,000~3,000
API 요청 지연 (p99)	< 200ms	< 500ms	< 1s	< 1.5s (목표)
429 Throttle (분당)	0	< 5	< 20	상위 티어 필요 시점
Watch 연결 수	~200	~1,500	~5,000	15,000+
CRD 타입 수 (참고)	5~15	15~40	40~80	80+
컨트롤러 Reconcile/초	5~20	50~150	150~500	500~2,000

측정 방법

etcd DB 크기: apiserver_storage_size_bytes (CloudWatch 또는 Prometheus)
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 크기 경고 기준

Standard: 6GB 초과 시 Warning → XL 전환 검토
XL/2XL: 12GB 초과 시 Warning → 불필요 CR 정리 또는 상위 티어
4XL: 20GB 초과 시 Critical → 아키텍처 분리 (멀티 클러스터) 검토

7.3 핵심 알람 설정

알람 이름	메트릭	임계값	심각도	대응 액션
API Throttling	`apiserver_request_total_429`	> 10/분, 5분간	Critical	PCP 티어 업그레이드 검토
API Server Errors	`apiserver_request_total_5xx`	> 5/분, 3분간	Critical	Control Plane 로그 확인
etcd DB 사용량	`apiserver_storage_size_bytes`	> 6GB (Standard) / > 12GB (Provisioned)	Warning	불필요한 CRD 리소스 정리
Scheduling 실패	`scheduler_schedule_attempts_UNSCHEDULABLE`	> 0, 10분간	Warning	노드 리소스 확인
API Concurrency	`apiserver_flowcontrol_current_executing_seats_total`	> 80% of 티어 한도	Warning	상위 티어 프로비저닝 검토

7.3 통합 모니터링 스택 권장

통합 모니터링 아키텍처
│
[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.4 단계별 도입 로드맵

단계	기간	주요 활동
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.5 최종 요약 — 주요 과제별 대응 전략

과제	EKS 기능 활용	CRD 설계 대응
CRD로 인한 etcd 과부하	Provisioned 티어: etcd 16GB + Event Sharding + 자동 스케일링	Provisioned 티어 적용, CR 오브젝트 크기 최소화
API Server 성능 저하	PCP 티어별 보장된 inflight requests + APF 우선순위 관리	컨트롤러 List/Watch 패턴 최적화, K8s 최신 버전 사용
스케줄링 한계	상위 티어에서 API Server 수평 확장	워크로드 증가 예측 시 상위 티어 사전 프로비저닝
Control Plane 안정성	Multi-AZ, 99.99% SLA (Provisioned)	프로덕션 클러스터는 Provisioned 티어 권장
비용 예측성	PCP 티어별 고정 가격 ($0.10 ~ $13.90/hr)	워크로드 프로파일에 맞는 적정 티어 선택
가시성 부족	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.6 CLI/API 사용법​

3.7 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.3 통합 모니터링 스택 권장​

7.4 단계별 도입 로드맵​

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

Footnotes​

목차