레이어 3 — 닫힌 영역과 클러스터 내부 우회

이 페이지는 레이어 1의 클러스터 파라미터와 레이어 2의 열린 4종을 전제로 그 여집합을 다룹니다. 무엇을 못 하는가, 못 하는 부분을 클러스터 안에서 어떻게 메우는가. 질문은 이 둘입니다.

이 페이지의 모든 path:line 인용은 로컬 클론 기준입니다 — kubernetes는 v1.37 개발 브랜치 커밋 752b8875(2026-07-26, git describe로는 v1.37.0-beta.0-499), karpenter-core는 ac7a021e(v1.14.0-6, 2026-07-27). EKS가 실제로 돌리는 마이너(1.31~1.36)의 배포본과 줄번호가 다를 수 있습니다. 여기 인용한 플래그들은 대부분 오래전에 도입돼 옵션 계약 자체는 안정적입니다.

1. 열린 것과 닫힌 것의 경계

1.1 컴포넌트별 개방 비율

“열린 세부 값” 열은 사용자가 실제로 값을 넣을 수 있는 스칼라·구조체의 개수를 뜻합니다. 2026-08 신규 필드가 들어온 뒤에도 컴포넌트별 개방 표면은 이만큼입니다.

CreateCluster 요청 스키마에서 이 셋이 차지하는 자리를 그대로 옮겼습니다. 스키마가 열어 준 범위는 중괄호 안에서 끝납니다.

{
  "kubeApiServerConfig": {
    "eventTtl": "1h",
    "serviceNodePortRange": { "minPort": 30000, "maxPort": 32767 }
  },
  "kubeControllerManagerConfig": {
    "horizontalPodAutoscalerControllerConfig": {
      "horizontalPodAutoscalerSyncPeriod": "15s"
    }
  },
  "kubeSchedulerConfig": {
    "nodeResourcesFit": {
      "scoringStrategy": { "type": "LeastAllocated", "resources": [{ "name": "cpu", "weight": 1 }] }
    }
  }
}

값 범위·가변성·Terraform 인자명은 레이어 2가 단일 소유로 다룹니다. 여기서 필요한 사실은 하나입니다. 이 JSON 밖에는 아무것도 없습니다.

1.2 열린 값의 옆자리가 닫혀 있다

개방이 좁다는 사실은 총량 비교보다 같은 코드 블록 안에서 하나만 뚫렸다는 데서 가장 잘 드러납니다.

실무에서 문제가 되는 것은 sync period보다 downscale stabilization(기본 5분)인 경우가 많습니다. 열린 쪽은 sync period입니다. HPA 행이 특히 아픈 이유가 여기 있습니다.

2. kube-apiserver — 닫힌 플래그

EKS API(CreateCluster/UpdateClusterConfig) 스키마 전체를 대조했습니다. 아래 항목에 대응하는 필드는 없습니다. “대안” 열은 §7의 우회 수단과 짝을 이룹니다.

2.1 처리율·동시성·타임아웃

EKS의 --max-requests-inflight 기본값을 400, mutating 쪽을 200으로 설명하는 AWS 자료가 있으나 API Reference 같은 1차 문서에서 확인한 값은 아닙니다. 2차 근거로만 취급합니다.

2.2 감사·어드미션

활성 어드미션 플러그인 목록은 각 k8s 마이너의 platform version에 고정돼 있고 platform version 자체도 사용자가 못 고릅니다. AWS 문서가 1.35·1.36에 동일하게 명시한 목록입니다.

NodeRestriction, ExtendedResourceToleration, NamespaceLifecycle, LimitRanger,
ServiceAccount, TaintNodesByCondition, PodSecurity, Priority,
DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection,
PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning,
CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook,
ValidatingAdmissionWebhook, ResourceQuota

MutatingAdmissionWebhook·ValidatingAdmissionWebhook이 이 목록에 들어 있습니다. 웹훅 메커니즘 자체는 이미 켜져 있으니 서버만 우리가 배포하면 됩니다. §7.2의 근거가 이것입니다.

2.3 API 표면·인증·암호화

2.4 etcd 접속 플래그

--etcd-servers·--etcd-prefix·--etcd-compaction-interval·--etcd-count-metric-poll-period·--etcd-cafile/-certfile/-keyfile 등 staging/.../server/options/etcd.go:170-199 블록 전체가 닫혔습니다. 상세와 대안은 §5.

3. kube-controller-manager와 kube-scheduler

3.1 HPA — 열린 것은 period 하나뿐이고, 그것도 조건부다

sync period를 줄이면 apiserver 요청량이 늘어납니다. 메커니즘은 코드에서 그대로 읽힙니다. pkg/controller/podautoscaler/horizontal.go:356-368의 processNextWorkItem()은 reconcile을 마친 뒤 queue.AddRateLimited(key)로 같은 키를 다시 큐에 넣습니다. 이때 resync period만큼 지연이 걸립니다. 그래서 HPA 오브젝트 하나당 period 간격으로 재평가가 돌고 매 실행마다 metrics 조회와 Scale 서브리소스 호출이 따라붙습니다. 요청량은 HPA 개수 × (1/period) 에 선형 비례합니다. AWS가 하한을 그 값으로 고른 산출식이나 부하 시험 수치는 공개 문서에서 확인되지 않았습니다.

3.2 노드 라이프사이클·GC·클라이언트 QPS

3.3 스케줄러 — scoring 하나만 열리고 프로파일 전체는 닫혔다

kubeSchedulerConfig가 노출하는 필드는 nodeResourcesFit.scoringStrategy 단 하나입니다. 그 밖의 스케줄러 커스터마이즈는 전부 닫혔습니다.

이 축에는 대안이 있습니다. 실효성 있는 길은 자체 스케줄러 배포(§7.3) 하나뿐입니다.

4. feature gate와 alpha API

User Guide FAQ가 원문으로 명시합니다.

“Amazon EKS supports all generally available (GA) features of the Kubernetes API. New beta APIs aren’t enabled in clusters by default. However, previously existing beta APIs and new versions of existing beta APIs continue to be enabled by default. Alpha features aren’t supported.”

출처: AWS User Guide, kubernetes-versions.html

--feature-gates가 없으니 게이트를 켤 수 없고 --runtime-config가 없으니 API 그룹을 켤 수도 없습니다. 두 경로가 모두 막혀 있어 alpha는 원리적으로 닫힌 영역입니다. 대안은 없습니다. 그 기능이 beta 기본 활성 또는 GA로 승격할 때까지 기다리는 수밖에 없습니다.

“alpha 게이트를 전부 켠 전용 클러스터 타입을 달라"는 요청은 aws/containers-roadmap#2348(“EKS Alpha Clusters”)로 살아 있으나 2026-08 기준 그런 제품은 없습니다.

2026-08(k8s 1.36 계열) 시점에 alpha라서 못 쓰는 기능의 구체적 목록은 이번 조사 범위에 넣지 않았습니다. 알파 목록은 마이너마다 바뀝니다. 특정 기능이 필요하면 목표 버전 시점의 업스트림 feature gate 표를 그때 직접 확인해야 합니다.

ValidatingAdmissionPolicy — 목록에는 없지만 단정할 수 없다

업스트림 pkg/kubeapiserver/options/plugins.go:163-192를 보면 ValidatingAdmissionPolicy 플러그인이 defaultOnPlugins 집합에 들어 있습니다(주석: 게이트가 켜졌을 때만 활성). 그 게이트는 1.30부터 GA·기본 on입니다. 그런데 EKS가 공개한 활성 어드미션 플러그인 목록(§2.2)에는 ValidatingAdmissionPolicy가 1.30~1.36 어느 절에도 등장하지 않습니다. MutatingAdmissionPolicy·PodTopologyLabels·NodeDeclaredFeatureValidator·PodResizeValidator·ClusterTrustBundleAttest도 마찬가지입니다.

이게 “EKS가 껐다"인지 “AWS 문서가 조건부 활성 플러그인을 목록에서 생략한다"인지는 1차 소스로 확정하지 못했습니다. GA 이후 API 그룹 활성화에 내장돼 동작하는 방식이라 전통적 플러그인 목록과 다르게 문서화될 여지가 있습니다. 확실하게 가려내려면 정책 도구를 정하기 전에 대상 클러스터에서 ValidatingAdmissionPolicy 오브젝트를 실제로 kubectl apply 해 봐야 합니다. 그 밖에 확정할 길은 없습니다.

5. etcd

백업 대안과 그 한계. Velero는 API 서버를 거쳐 리소스를 백업합니다. etcd를 직접 읽지 않으니 kubectl이 보는 것과 같은 수준입니다. PV 데이터는 CSI 볼륨 스냅샷이나 Velero의 파일 레벨 백업으로 따로 처리합니다. RBAC·CRD 정의 같은 컨트롤 플레인 메타데이터까지 리소스 단위로 재현은 되지만 etcd 스냅샷 기반 복원처럼 원자적 시점 복구는 되지 않습니다. 리소스마다 백업 시각이 미세하게 다르고 백업 중 변경된 오브젝트 사이의 정합은 보장되지 않습니다. “애플리케이션 레벨 백업이 최초이자 최후의 방어선"이라는 정리는 커뮤니티 2차 소스 다수가 일치합니다. 원자성 상실이라는 대가를 명시하지 않고 인용하면 오해를 만듭니다.

6. 컨트롤 플레인 사이징

인스턴스 타입·노드 수·AZ 배치는 여전히 전혀 못 고릅니다. 2025-11-27 Provisioned Control Plane이 나오면서 생긴 선택은 미리 정해진 성능 등급을 사는 쪽입니다. 인스턴스를 직접 고르는 문이 열린 것은 아닙니다.

레버는 티어가 대리로 올려주는 값뿐입니다. APF seat 총량, 파드 스케줄링 처리율, HPA sync concurrency, DB 크기 넷입니다. §2·§3에서 “직접 불가, 티어로 간접"이라고 적은 항목은 모두 여기에 걸립니다. 그 수치와 전환 제약은 여기서 재서술하지 않습니다.

7. 그래서 대신 무엇을 하나

닫힌 항목과 클러스터 내부 대안을 짝지었습니다. 대안이 없으면 없다고 적었습니다. 이 표에서 “없다"의 개수가 §1의 개방 비율을 다시 확인해 줍니다.

7.1 APF — 스로틀링을 실질적으로 통제하는 유일한 창구

FlowSchema와 PriorityLevelConfiguration은 클러스터 내부 API 오브젝트(flowcontrol.apiserver.k8s.io)라서 EKS에서도 사용자가 만들고 고칠 수 있습니다. apiserver 플래그가 완전히 닫힌 영역에 남은 예외적인 통로입니다.

이 통로는 총량이 아니라 배분만 다룹니다. 서버 전체 seat 예산은 --max-requests-inflight + --max-mutating-requests-inflight가 정하고 그건 AWS가 쥐고 있습니다(티어로 간접 조정, §6). 우리는 그 고정된 예산을 누구에게 얼마나 줄지만 나눕니다.

apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: PriorityLevelConfiguration
metadata:
  name: platform-controllers
spec:
  type: Limited
  limited:
    nominalConcurrencyShares: 30
    lendablePercent: 0
    limitResponse:
      type: Queue
      queuing:
        queues: 32
        handSize: 6
        queueLengthLimit: 50
---
apiVersion: flowcontrol.apiserver.k8s.io/v1
kind: FlowSchema
metadata:
  name: platform-controllers
spec:
  matchingPrecedence: 900
  priorityLevelConfiguration:
    name: platform-controllers
  distinguisherMethod:
    type: ByUser
  rules:
    - subjects:
        - kind: ServiceAccount
          serviceAccount: { namespace: karpenter, name: karpenter }
      resourceRules:
        - verbs: ["*"]
          apiGroups: ["*"]
          resources: ["*"]
          clusterScope: true
          namespaces: ["*"]

이 방식으로 격리를 얻습니다. 특정 컨트롤러가 폭주해도 다른 컨트롤러의 seat를 다 먹지 못하게 상한을 겁니다. 반대로 karpenter처럼 노드 프로비저닝을 담당하는 컨트롤러는 배치 작업에 밀려 굶지 않게 우선순위를 확보합니다.

업스트림 apiserver는 기본 제공 FlowSchema·PriorityLevelConfiguration을 부팅 때 다시 채워 넣으면서 사용자가 수정한 suggested 오브젝트를 원복시킵니다. 업스트림에서는 apf.kubernetes.io/autoupdate-spec: "false" 를 붙여야 이 원복을 막습니다. EKS 관리형 apiserver에서 이 동작이 그대로인지는 이번에 실측하지 않았습니다. 기본 오브젝트를 수정하기보다 새 오브젝트를 추가하는 쪽이 안전합니다.

7.2 어드미션 — 세 갈래

PodSecurity는 이미 기본 활성입니다. 네임스페이스 라벨로 조정하면 되니 이 항목은 애초에 닫힌 적이 없습니다.

7.3 자체 스케줄러 배포

스케줄러 프로파일·플러그인은 못 고칩니다. 그 공백을 메우는 길은 하나뿐입니다. kube-scheduler를 우리가 하나 더 배포하고 그 스케줄러에 맡길 파드에 spec.schedulerName을 지정합니다.

spec:
  template:
    spec:
      schedulerName: binpack-scheduler

• AWS가 aws-samples/custom-scheduler-eks로 참조 구현을 공개했습니다(bin packing 목적, EKS 1.24+ 명시).
• 같은 문서는 kube-scheduler를 직접 빌드하지 말고 eks-distro 이미지를 쓰라고 권고합니다. 버전 정합 관리가 그만큼 까다롭습니다.
• ServiceAccount + ClusterRoleBinding을 직접 구성해야 합니다. 스케줄러는 파드·노드·PV 전반에 광범위한 권한이 필요하므로 RBAC 범위가 작지 않습니다.
• 관리형 스케줄러와 공존합니다. schedulerName을 지정하지 않은 파드는 계속 EKS 관리형 스케줄러가 처리합니다. 그래서 전면 교체 없이 부분 적용으로 갈 수 있습니다. 대신 두 스케줄러가 같은 노드 자원을 한꺼번에 바인딩하려는 경쟁 조건은 우리 책임입니다.

7.4 감사·이벤트 보존

• 감사 정책의 세밀도는 우회할 수 없습니다. --audit-policy-file이 없으니 “어떤 필드까지 기록할지"는 AWS가 정한 그대로입니다. 우리는 로그 타입을 켜고 나온 것을 반출해 사후 필터링합니다. enabled_cluster_log_types에 audit을 넣으면 CloudWatch Logs로 나가고 거기서 Logs Insights·Athena·외부 싱크로 옮겨 질의합니다.
• 이벤트 보존 기간은 우회할 수 있습니다. eventTtl은 etcd 안에 얼마나 남기는지만 정합니다. Event 오브젝트를 watch해 외부 저장소로 밀어내는 exporter를 두면 TTL을 늘리지 않고도 장기 보존과 장기 질의를 얻습니다. 오히려 이쪽이 권장 방향입니다. TTL을 늘리면 etcd 크기와 watch 캐시 부담이 함께 늘어나는데 그 둘은 우리가 손댈 수 없는 축입니다(§2.1·§5).

7.5 CCM — “제약"이 아니라 “쪼개졌다”

cloudControllerManagerConfig 같은 필드는 신설되지 않았고 --cloud-provider·--route-reconciliation-period·--node-status-update-frequency 류도 전부 비노출입니다. 하지만 CCM이 원래 하던 일의 대부분은 EKS에서 사용자가 직접 배포·설정하는 애드온으로 쪼개져 있습니다 — AWS Load Balancer Controller(ALB/NLB), VPC CNI, EBS/EFS CSI. 이 애드온들은 EKS가 관리하는 필드가 아니면 자유롭게 수정할 수 있습니다. 이 축에서 실제로 일어난 일은 아키텍처가 다른 컴포넌트로 분해된 것입니다. 순수한 제약과는 다릅니다.

EKS가 내부적으로 in-tree AWS cloud provider를 쓰는지 external cloud-provider-aws를 쓰는지는 AWS가 공개 문서로 밝히지 않았습니다. 이 한 가지는 확정하지 못했습니다.

8. --force를 둘러싼 흔한 오해

aws eks update-cluster-version --force를 “PDB와 웹훅을 무시하고 밀어붙이는 스위치"로 이해하는 경우가 많습니다. 아닙니다.

인사이트가 ERROR/UNKNOWN일 때 --force 없이는 업그레이드를 막는 기능은 2025-03-27 도입 후 2025-03-28 임시 롤백됐습니다. 2026-08-14 현재도 User Guide는 같은 문장을 현재 시제로 유지합니다. 여기에 시점 문제가 하나 더 겹칩니다.

“Amazon EKS has temporarily rolled back a feature that would require you to use a --force flag to upgrade your cluster when there were certain cluster insight issues.”

출처: AWS User Guide, cluster-insights.html

재활성화를 확인해 주는 1차 문서는 없습니다. 전진 업그레이드에서 --force는 현재 실질적으로 거의 무효입니다. 이 플래그가 의미를 갖는 곳은 따로 있습니다 — 2026년 도입된 클러스터 버전 롤백(역방향) 흐름에서는 신설된 Rollback Readiness Insights가 ERROR/UNKNOWN일 때 --force 없이 롤백을 차단하는 강제 로직이 실제로 살아 있습니다. “인사이트가 ERROR면 업그레이드가 시스템적으로 막힌다"는 전제로 절차를 짜면 안 됩니다. 롤백 절차에서는 이 플래그를 계산에 넣어야 합니다. 롤백 계약 자체는 컷오버·롤백이 다룹니다.

9. 과장과 오해 정리

1차 근거로 반박되는 서술을 모았습니다.

우리 케이스에서는

finance가 실제로 부딪히는 닫힌 항목은 세 개로 좁혀집니다. HPA downscale stabilization이 하나입니다. 열린 것은 sync period뿐이라 스케일다운 지연은 HPA behavior.scaleDown 필드로 워크로드마다 따로 잡아야 합니다(오브젝트 레벨 설정이라 컨트롤 플레인과 무관하게 쓸 수 있습니다). 감사 정책 파일도 걸립니다. 금융 도메인이라 기록 레벨을 우리가 정하고 싶지만 그 축은 닫혔습니다. 클러스터 설정이 enabled_cluster_log_types=["audit"]로 로그 타입을 켜는 데까지가 우리 몫입니다. etcd 스냅샷 부재가 마지막입니다. blue-green 이관이라 “green을 그대로 남겨둔다"는 것이 사실상 우리의 시점 복구 수단이고 컷오버 이후 시점부터는 Velero 같은 API 레벨 백업으로 내려앉습니다. 원자적 시점 복구가 없다는 대가는 이관 계획에 명시해 두는 편이 낫습니다.

이 조직은 HyperDX 내재화에서 ClickStack + ClickHouse를 직접 운영하니 §7.4의 “감사·이벤트를 외부로 반출해 장기 보존·질의한다"는 우회에 새 스택을 세울 필요가 없습니다. 감사 로그와 Event를 보낼 싱크가 이미 서 있습니다. 우회 쪽에서 손에 쥔 자산이 이것 하나입니다. 그 챕터의 용량 산정은 RUM 전용 전제(월 0.7TB 규모)로 잡혀 있어서 k8s 감사 로그를 추가하려면 산정을 새로 해야 합니다. APF 쪽은 우선순위가 낮습니다. 레이어 2가 정리한 대로 blue create 시점에는 컨트롤 플레인 파라미터를 전부 기본값으로 두는 방침입니다. karpenter·ArgoCD 컨트롤러가 seat를 다투는지는 blue가 실제 부하를 받은 뒤에 apiserver_flowcontrol_current_executing_seats로 확인할 문제입니다.