EKS의 관리형 kro를 직접 써 봤습니다: OSS와 같은 0.9.4, 권한은 직접 열어야 하고 이름 충돌은 조심해야 합니다

EKS Capabilities 직접 써 보기: 1편 Argo CD · 2편 kro · 3편 ACK

kro(Kube Resource Orchestrator)는 여러 Kubernetes 리소스를 하나의 API로 묶어 주는 도구입니다. EKS Capabilities로 켜면 kro 컨트롤러가 클러스터 밖 AWS 관리 인프라에서 돌고, 클러스터에는 CRD만 남습니다. 이번 편에서는 "컨트롤러를 AWS에 맡기면 무엇이 달라지고, 무엇은 여전히 내가 챙겨야 하나"를 실제 클러스터에서 확인했습니다. 같은 RGD(ResourceGraphDefinition)와 측정 스크립트를 관리형 kro와 self-managed kro 0.9.4에 번갈아 돌렸고, 3편에서 다룰 ACK와 묶은 구성도 함께 시험했습니다. 측정은 2026년 10월 21일에 했고, 원시 결과와 매니페스트는 글 끝에 공개합니다.

1. 시험 환경과 방법

NginxApp RGD는 필자의 학습 문서 kubernetes-docs의 kro 예제를 가져와 한 군데 고쳐서 썼습니다. 원래 예제는 인스턴스가 ingressClassName과 호스트 이름을 마음대로 정할 수 있어서, 멀티테넌트 클러스터에서는 다른 팀의 호스트를 가로채는 데 쓰일 수 있습니다. 시험용 RGD에서는 클래스를 고정하고 호스트를 인스턴스 이름과 네임스페이스로 만들도록 바꿨습니다.

시험 순서는 관리형 kro 측정, capability 삭제, OSS kro 설치와 같은 측정, OSS 제거, 관리형 kro 재생성(영상 녹화) 순서였습니다.

2. 관리형 kro는 어떻게 동작하나

EKS Capabilities는 Argo CD, ACK, kro 세 가지 컨트롤러를 AWS가 운영하는 기능입니다. 공통 구조는 1편에서 자세히 다뤘고, kro에 해당하는 부분만 정리하면 이렇습니다.

AWS 문서는 kro가 "같은 upstream 컨트롤러를 쓰고 완전히 호환된다"고 설명합니다. 이번 시험에서도 RGD와 CEL 표현식, 측정 결과가 OSS와 같았습니다. 차이는 거의 전부 권한과 운영 쪽에서 나왔습니다.

3. 실측 1: 생성과 클러스터에 남는 것

capability role에는 신뢰 정책만 두고 권한 정책은 붙이지 않았습니다. 명령은 다음과 같습니다.

aws eks create-capability --cluster-name eks-cap-demo --capability-name kro --type KRO \
  --role-arn arn:aws:iam::<ACCOUNT_ID>:role/eks-cap-demo-kro \
  --delete-propagation-policy RETAIN

2회차는 OSS kro를 지운 뒤에 다시 만든 것입니다. 이때 RGD 2개와 인스턴스 4개가 이미 클러스터에 있었는데, 관리형 kro가 별도 조치 없이 모두 이어받아 RGD는 Active, 인스턴스는 ACTIVE를 유지했습니다.

capability를 지운 뒤에 남는 것도 확인했습니다. 삭제는 46.9초 걸렸고, CRD 4개(kro 2개, RGD가 만든 2개), RGD, 인스턴스, Deployment와 Service가 모두 남았습니다. capability role의 access entry도 남았습니다. 컨트롤러가 없는 동안 인스턴스의 replicas를 바꾸면 Deployment는 그대로였고, 이후 OSS kro를 설치하자 밀려 있던 변경이 반영됐습니다.

4. 실측 2: 기본 권한으로는 시작하지 못합니다

capability를 만든 직후 NginxApp RGD를 적용했습니다. CRD는 1.1초 만에 생겼지만 RGD는 90초가 지나도 Inactive였습니다.

GraphAccepted=True Valid
GraphRevisionsResolved=True Resolved
KindReady=True Ready
ControllerReady=False FailedToStart
  add parent handler platform.example.com/v1alpha1, Resource=nginxapps:
  cache sync timeout for platform.example.com/v1alpha1, Resource=nginxapps

원인은 권한입니다. AmazonEKSKROPolicy는 kro.run 그룹과 CRD만 다룹니다. RGD 스키마에서 group을 platform.example.com으로 정했기 때문에, 그 API(nginxapps.platform.example.com)를 watch할 권한도, 그 아래 Deployment와 Service를 만들 권한도 없습니다. 그런데 메시지에 "forbidden"이 아니라 "cache sync timeout"만 나와서, 처음 보면 컨트롤러 장애로 오해하기 쉽습니다. AWS 문서도 "kro requires additional permissions to create and manage the underlying Kubernetes resources"라고 적고, eksctl 가이드는 시작용으로 AmazonEKSClusterAdminPolicy를 붙입니다.

이번에는 cluster-admin 대신 최소 권한으로 풀었습니다. access entry에 Kubernetes 그룹을 붙이고, kubernetes-docs 예제의 RGD별 ClusterRole을 그 그룹에 바인딩했습니다.

aws eks update-access-entry --cluster-name eks-cap-demo \
  --principal-arn arn:aws:iam::<ACCOUNT_ID>:role/eks-cap-demo-kro \
  --kubernetes-groups kro-workloads

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-workloads-reviewed-nginxapps
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kro:controller:reviewed-nginxapps   # nginxapps, deployments, services, ingresses
subjects:
  - kind: Group
    name: kro-workloads
    apiGroup: rbac.authorization.k8s.io

바인딩을 적용하고 228초 뒤에 RGD가 Active, 인스턴스가 ACTIVE가 됐습니다. Deployment와 Service는 그중 마지막 몇 초 사이에 만들어졌으므로, 기다린 시간 대부분은 컨트롤러가 실패한 RGD를 다시 시도하기까지의 간격으로 보입니다. 권한을 미리 준비해 두면 이 대기는 생기지 않습니다. 두 번째 RGD(OrderService)는 ClusterRole과 바인딩을 RGD보다 먼저 적용했고, 바로 Active가 됐습니다.

여기서 읽을 수 있는 것은 이렇습니다.

• RGD를 추가할 때마다 kro 쪽 RBAC도 함께 배포해야 합니다. RGD와 ClusterRole을 같은 Git 경로에 두고 함께 리뷰하는 방식이 자연스럽습니다.
• 같은 일이 Argo CD에도 생깁니다. Argo CD로 NginxApp 인스턴스를 배포하자 nginxapps.platform.example.com is forbidden으로 실패했고, Argo CD capability role에도 같은 방식으로 권한을 줘야 했습니다(1편에서 자세히 다룹니다).
• OSS는 기본값이 반대 방향으로 위험합니다. OSS 차트의 기본값 rbac.mode: unrestricted에서 만들어지는 kro-cluster-role은 apiGroups: ["*"], resources: ["*"], verbs: ["*"]입니다. RGD를 쓸 수 있는 사람은 사실상 클러스터 전체에 리소스를 만들 수 있습니다. 차트 주석도 rbac.mode: aggregation을 권장합니다. 이 모드에서는 rbac.kro.run/aggregate-to-controller: "true" 레이블을 단 ClusterRole만 컨트롤러 권한에 합쳐지므로, 관리형과 같은 "RGD마다 권한을 여는" 모델이 됩니다. 하위 호환 때문에 기본값만 unrestricted로 남아 있습니다.

5. 실측 3: 인스턴스 수명주기

같은 스크립트로 NginxApp 인스턴스를 만들고(replicas: 2), ACTIVE를 기다린 뒤 replicas: 3으로 패치하고, 삭제했습니다. 관리형과 OSS를 각각 5회 돌렸습니다.

읽을 때 주의할 점이 있습니다.

• 두 쪽의 차이는 오차 범위 안입니다. 같은 upstream 컨트롤러이므로 예상과 같습니다. 클러스터 밖에서 돈다고 해서 반응이 느려지지는 않았습니다.
• 51.6초 한 번은 원인을 확인하지 못했습니다. 같은 조건으로 두 번 더 돌렸을 때는 0.5초였습니다. 관리형 컨트롤러의 큐 지연인지 다른 원인인지는 이번 데이터로 구분할 수 없습니다. 컨트롤러 로그(EKS_CAPABILITY_KRO_LOGS) 전달은 이 측정 뒤에 설정해서 당시 로그가 없습니다. 운영에서는 처음부터 로그 전달을 켜 두는 것이 좋습니다.
• 생성 시간 2.5초는 대부분 nginx Pod가 Ready가 되는 시간으로 보입니다. 구간별로 나눠 재지는 않았습니다.

6. 실측 4: ACK와 묶은 OrderService

kro가 특히 쓸모 있는 경우는 AWS 리소스와 Kubernetes 리소스를 한 API로 묶을 때입니다. OrderService RGD는 ACK의 SQS Queue와 DynamoDB Table을 만들고, 두 리소스의 status에서 큐 URL과 테이블 ARN을 꺼내 ConfigMap에 넣은 뒤, 그 ConfigMap을 쓰는 Deployment를 띄웁니다.

    - id: config
      template:
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: ${schema.metadata.name + "-aws"}
          namespace: ${schema.metadata.namespace}
        data:
          QUEUE_URL: ${queue.status.queueURL}
          TABLE_ARN: ${table.status.ackResourceMetadata.arn}

kro 쪽 ClusterRole에는 queues.sqs.services.k8s.aws, tables.dynamodb.services.k8s.aws, ConfigMap, Deployment 권한을 넣었습니다. ACK 쪽 IAM 권한은 3편에서 다루는 IAMRoleSelector로 네임스페이스(team-a)에 묶었습니다.

ACTIVE까지 걸린 시간은 대부분 DynamoDB 테이블이 ACTIVE가 되는 시간입니다. 테이블에는 readyWhen: ${table.status.?tableStatus.orValue("") == "ACTIVE"}를 걸어 두었습니다. 첫 인스턴스(checkout)에서만 테이블 ARN이 22.2초 늦게 나타났고, 두 번째부터는 1초 안이었습니다. 처음 쓰는 리소스 종류의 watch를 준비하는 시간으로 추정하지만 확인하지는 않았습니다.

만들면서 한 번 막힌 곳도 있습니다. Deployment의 readyWhen에서 schema.spec.replicas를 참조하자 RGD가 references unknown identifiers: [schema]로 거부됐습니다. readyWhen은 자기 자신만 참조할 수 있으므로 deployment.spec.replicas로 바꿔야 합니다.

7. 함정: 같은 이름의 기존 CR을 덮어씁니다

처음 OrderService 인스턴스 이름을 orders로 정했는데, team-a 네임스페이스에는 3편 시험에서 kubectl로 만든 ACK Queue orders와 Table orders가 이미 있었습니다. 이 상태로 인스턴스를 만들자 다음과 같은 일이 생겼습니다.

kro는 대상 이름의 객체가 이미 있어도 거부하지 않았습니다. DynamoDB의 tableName이 ACK에서 변경 가능한 필드였기 때문에 피해가 Queue보다 컸습니다. OSS kro 0.9.4로 같은 상황을 다시 만들었을 때도 똑같이 기존 Table CR을 가져가 이름을 바꿨으므로, 관리형 capability가 아니라 upstream 동작입니다.

막는 방법은 이렇습니다.

• 하위 리소스 이름에 RGD 고유 접미사를 붙입니다. 이번 RGD처럼 ${schema.metadata.name}만 쓰면 사람이 만든 CR과 겹치기 쉽습니다. 예를 들어 ${schema.metadata.name + "-os"}처럼 붙입니다. SQS 큐나 DynamoDB 테이블 이름에 Kubernetes 이름에는 쓸 수 없는 _를 구분자로 쓰면(S3 버킷 이름은 _를 허용하지 않음), 네임스페이스와 이름 조합이 겹치는 것도 막을 수 있습니다. 공개 저장소의 RGD는 이렇게 고쳐 두었습니다.
• kro가 관리하는 네임스페이스와 사람이 직접 CR을 만드는 네임스페이스를 나눕니다.
• 데이터가 있는 ACK 리소스에는 services.k8s.aws/deletion-policy: retain을 겁니다. CR이 지워질 때 AWS 리소스 삭제를 막아 줍니다. 다만 이번 사고처럼 이름이 바뀌어 빈 새 테이블로 옮겨 가는 것까지 막지는 못하므로, 근본 대책은 이름 분리입니다(retain과 이 상황의 조합은 시험하지 않았습니다).

시험이 끝난 뒤 고아로 남은 테이블 2개는 직접 지웠습니다.

8. 데모 영상

영상은 관리형 kro를 다시 만든(2회차) 직후에 녹화했습니다. 화면의 계정 ID는 가렸습니다.

9. self-managed kro와 비교

같은 클러스터에 OSS kro 0.9.4를 Helm 기본값으로 설치하고 같은 시나리오를 반복했습니다.

정리하면, 관리형은 컨트롤러 업그레이드와 장애 대응, 노드 리소스를 맡기는 대신 버전을 고를 수 없고, 처음 쓸 때 권한 문제로 한 번은 막힙니다. 권한 모델 자체는 관리형이 더 안전한 쪽에서 시작합니다. OSS는 설치가 빠르고 버전과 설정을 마음대로 정할 수 있지만, 기본값 그대로 쓰면 RGD 작성 권한이 곧 클러스터 관리자 권한이 됩니다. OSS를 rbac.mode: aggregation으로 바꾸면 관리형과 비슷한 권한 작업이 필요해지므로, 운영 환경의 권한 작업량은 두 쪽이 크게 다르지 않습니다(aggregation 모드는 차트 설명 기준이며 시험하지 않았습니다).

AWS 문서의 OSS → 관리형 이전 절차는 리더 선출 lease를 kube-system으로 옮긴 뒤 capability를 만들라고 안내합니다. 문서 예시는 예전 Helm 경로(oci://ghcr.io/awslabs/kro/kro-chart)와 --set leaderElection.namespace=kube-system을 쓰는데, 현재 공식 차트는 oci://registry.k8s.io/kro/charts/kro이고 0.9.4 차트에서 해당 값의 키는 config.leaderElectionNamespace입니다. 이번 시험에서는 두 컨트롤러를 동시에 띄우지 않고 하나를 지운 뒤 다른 하나를 설치했기 때문에 lease 이전은 확인하지 않았습니다.

10. 얻을 수 있는 것과 비용

관리형 kro가 잘 맞는 경우는 이렇습니다.

• 이미 EKS Capabilities의 Argo CD나 ACK를 쓰고 있어서, 플랫폼 컨트롤러를 같은 방식(capability role, access entry, Vended Logs)으로 관리하고 싶을 때
• 플랫폼 팀이 RGD를 만들고 앱 팀은 인스턴스만 쓰는 구조에서, 컨트롤러 운영을 줄이고 싶을 때
• 컨트롤러 권한을 기본으로 좁게 두고 RGD마다 명시적으로 열고 싶을 때

반대로 kro 새 버전의 기능을 바로 써야 하거나, 컨트롤러 플래그와 리소스 한도를 조정해야 한다면 self-managed가 낫습니다.

비용은 작습니다. 서울 리전 기준 capability 요금은 시간당 $0.006038, 인스턴스 요금은 인스턴스 하나당 시간당 $0.000061입니다(2026-10-21 AWS Pricing API 조회). 인스턴스 100개를 한 달(730시간) 유지하면 $4.41 + $4.45로 약 $8.86입니다. self-managed kro가 요청한 256m CPU는 m7g.large(2 vCPU, 서울 시간당 $0.1003)의 12.8%이므로, CPU 요청 기준으로 노드 비용을 나누면 한 달 약 $9.4입니다. 비용만으로는 어느 쪽도 결정적이지 않고, 운영 부담과 권한 모델이 선택 기준이 됩니다.

11. 이번 측정의 한계

• 시나리오마다 2~5회만 반복했습니다. 관리형 spec 변경의 51.6초 이상치는 원인을 확인하지 못했습니다.
• RGD는 2개, 인스턴스는 최대 6개였습니다. 인스턴스 수백 개에서의 처리량과, AWS 문서(Capability Kubernetes resources)가 정한 RGD당 리소스 한도(64개)에 가까운 그래프는 시험하지 않았습니다.
• 두 컨트롤러를 동시에 띄운 무중단 이전은 시험하지 않았습니다. 한쪽을 지운 뒤 다른 쪽을 설치했습니다.
• 권한 부여 후 228초 대기의 원인은 추정입니다. 컨트롤러의 재시도 간격으로 보이지만, 컨트롤러 로그로 확인하지는 않았습니다.
• 클러스터는 단일 리전, 단일 계정이었습니다.

12. 원시 결과, 재현 방법

매니페스트는 Atom-oh/eks-capabilities-demo에 있습니다. kro/에 RGD, 인스턴스, ClusterRole이 있고, kro-instances/는 Argo CD가 동기화하는 인스턴스입니다. 측정 결과 JSON은 assets/data/eks-capabilities-2026-10/에 있습니다.

재현 순서는 다음과 같습니다.

1. capability role을 만듭니다(서비스 보안 주체 capabilities.eks.amazonaws.com, 권한 정책 없음).
2. aws eks create-capability --type KRO로 capability를 만들고 ACTIVE를 기다립니다.
3. access entry에 Kubernetes 그룹을 붙이고, RGD별 ClusterRole을 그 그룹에 바인딩합니다. RGD보다 먼저 적용합니다.
4. RGD를 적용하고 kubectl get rgd에서 Active를 확인한 뒤 인스턴스를 만듭니다.

시험 클러스터는 측정이 끝난 뒤 삭제했습니다.

참고 자료

• EKS Capabilities
• Configure kro permissions
• Comparing EKS Capability for kro to self-managed kro
• Access EKS Capabilities controller logs
• Amazon EKS pricing
• kro 0.9.4 release