ACK용 EKS 캐퍼빌리티와 자체 관리 ACK 비교

ACK용 EKS 캐퍼빌리티와 자체 관리 ACK 컨트롤러의 차이를 설명합니다.

출처: 문서

본문

ACK용 EKS 캐퍼빌리티는 자체 관리 ACK 컨트롤러와 동일한 기능을 제공하지만 상당한 운영상 이점이 있습니다. EKS 캐퍼빌리티와 자체 관리 솔루션의 일반적인 비교는 EKS 캐퍼빌리티 고려 사항을 참고하세요. 이 항목은 ACK 특유의 차이점에 초점을 맞춥니다.

업스트림 ACK와의 차이점

ACK용 EKS 캐퍼빌리티는 업스트림 ACK 컨트롤러를 기반으로 하지만 IAM 통합에서 다릅니다.

IAM 캐퍼빌리티 역할 - 캐퍼빌리티는 IRSA(IAM Roles for Service Accounts)가 아니라 capabilities.eks.amazonaws.com 서비스 프린시펄을 허용하는 신뢰 정책이 있는 전용 IAM 역할을 사용합니다. Kubernetes 서비스 계정을 만들거나 어노테이션하거나 OIDC 프로바이더를 구성할 필요 없이 IAM 정책을 캐퍼빌리티 역할에 직접 연결할 수 있습니다. 프로덕션 사용 사례의 모범 사례는 IAMRoleSelector로 서비스 권한을 구성하는 것입니다. 자세한 내용은 ACK 권한 구성을 참고하세요.
세션 태그 - 관리형 캐퍼빌리티는 모든 AWS API 요청에 세션 태그를 자동으로 설정해 세분화된 접근 제어와 감사를 가능하게 합니다. 태그에는 eks:eks-capability-arn, eks:kubernetes-namespace, eks:kubernetes-api-group이 포함됩니다. 이는 기본적으로 이 태그를 설정하지 않는 자체 관리 ACK와 다릅니다. IAM 정책에서 세션 태그를 사용하는 방법은 ACK 권한 구성을 참고하세요.
리소스 태그 - 캐퍼빌리티는 자체 관리 ACK와 다른 기본 태그를 AWS 리소스에 적용합니다. 캐퍼빌리티는 자체 관리 ACK가 사용하는 services.k8s.aws/ 태그 대신 eks: 접두사 태그(예: eks:kubernetes-namespace, eks:eks-capability-arn)를 사용합니다. 기본 리소스 태그의 전체 목록은 EKS용 ACK 고려 사항을 참고하세요.
리소스 호환성 - ACK 커스텀 리소스는 ACK 리소스 YAML 파일을 변경하지 않고도 업스트림 ACK와 동일하게 작동합니다. 캐퍼빌리티는 동일한 Kubernetes API와 CRD를 사용하므로 kubectl 같은 도구도 동일하게 작동합니다. 캐퍼빌리티는 업스트림 ACK에서 Generally Available(GA)인 컨트롤러와 리소스만 지원합니다. 캐퍼빌리티에는 업스트림에서 preview인 컨트롤러는 포함되지 않습니다. 컨트롤러의 상태는 시간이 지나면서 업스트림에서 preview에서 GA로 바뀔 수 있으며, 그 경우 캐퍼빌리티가 자동으로 해당 컨트롤러 관리를 시작할 수 있습니다. 캐퍼빌리티와 함께 자체 관리 preview 컨트롤러를 실행한다면 마이그레이션 전에 Preview 컨트롤러와 자동 승격을 검토하세요.

완전한 ACK 문서와 서비스별 가이드는 ACK 웹사이트의 ACK 문서를 참고하세요.

마이그레이션 경로

AWS 리소스에 최소한의 중단으로 자체 관리 ACK에서 관리형 캐퍼빌리티로 마이그레이션할 수 있습니다. 마이그레이션은 Kubernetes 리더 선출(leader election)에 의존합니다. 자체 관리 컨트롤러와 캐퍼빌리티가 동일한 리스를 두고 경쟁하므로, 한 번에 특정 리소스를 조정하는 쪽은 하나뿐입니다. 이를 위해 둘 다 같은 네임스페이스에서 리스를 공유해야 합니다. 캐퍼빌리티는 실행 중인 자체 관리 컨트롤러에서 리스를 강제로 빼앗지 않으므로, 자체 관리 컨트롤러를 축소(scale down)함으로써 핸드오버 시점을 직접 제어할 수 있습니다.

중요

시작하기 전에 IAM 캐퍼빌리티 역할에 자체 관리 컨트롤러가 오늘 사용하는 것과 동등한 권한을 부여하세요. 캐퍼빌리티는 자체 관리 컨트롤러가 현재 사용하는 메커니즘(예: IRSA 또는 EKS Pod Identity)이 아니라 capabilities.eks.amazonaws.com 서비스 프린시펄을 통해 전용 캐퍼빌리티 역할로 인증합니다(ACK 권한 구성 참고). 캐퍼빌리티 역할에 권한이 없으면 캐퍼빌리티가 리소스를 어답션하고, 조정에 실패하며, AccessDenied 오류를 기록합니다.

마이그레이션을 위해 다음 단계를 완료하세요. 단계는 S3 컨트롤러(ack-s3-controller)를 예시로 사용합니다. 캐퍼빌리티로 마이그레이션하려는 각 자체 관리 ACK 컨트롤러에 대해 해당 컨트롤러 이름과 Helm 차트를 대체해 반복하세요.

참고

캐퍼빌리티와 함께 자체 관리 컨트롤러를 실행하는 것은 마이그레이션 중 임시 상태로 의도된 것이지 장기 구성이 아닙니다. 양쪽이 실행되는 동안 어느 한쪽의 중단(예: 캐퍼빌리티 배포 또는 자체 관리 컨트롤러 업그레이드)이 리스를 해제하고 다른 쪽이 이를 획득하게 해서, 조정이 예기치 않게 양쪽 사이를 오갈 수 있습니다. 자체 관리 컨트롤러를 캐퍼빌리티와 함께 무기한 실행하지 말고 각 컨트롤러의 마이그레이션을 완료하세요.

1. 자체 관리 ACK 컨트롤러에서 리더 선출을 활성화하고 리스를 kube-system으로 이동:

helm upgrade --install ack-s3-controller \
  oci://public.ecr.aws/aws-controllers-k8s/s3-chart \
  --namespace ack-system \
  --set leaderElection.enabled=true \
  --set leaderElection.namespace=kube-system

두 값을 모두 설정해야 합니다. ACK Helm 차트에서 --leader-election-namespace 플래그는 leaderElection.enabled가 true일 때만 적용되며 리더 선출은 기본적으로 비활성화되어 있습니다. leaderElection.namespace만 설정하면 효과가 없습니다. 컨트롤러는 리스 없이 실행을 계속하며, 캐퍼빌리티가 생성된 후 두 컨트롤러가 동시에 같은 리소스를 조정하게 됩니다. 이는 S3뿐 아니라 모든 ACK 서비스 컨트롤러 차트에 적용됩니다.

이렇게 하면 컨트롤러의 리스가 kube-system으로 이동해 관리형 캐퍼빌리티가 이를 조정할 수 있습니다.

2. 클러스터에 ACK 캐퍼빌리티 생성(ACK 캐퍼빌리티 생성 참고).

캐퍼빌리티가 시작되어 리스를 두고 경쟁하지만, 자체 관리 컨트롤러가 여전히 리스를 보유하고 있습니다. 자체 관리 컨트롤러가 리소스 조정을 계속하고, 캐퍼빌리티는 강제 탈취 대신 리더십을 기다립니다.

3. 마이그레이션을 시작할 준비가 되면 자체 관리 컨트롤러를 0개 복제본으로 축소.

이렇게 하면 리스가 해제되어 캐퍼빌리티가 리더십을 획득하고 조정을 인계받을 수 있습니다.

kubectl scale deployment ack-s3-controller \
  --namespace ack-system --replicas=0

자체 관리 컨트롤러를 축소한 후 캐퍼빌리티가 리스를 획득하고 조정을 시작하며, 보통 짧은 시간 안에 이루어집니다. 자체 관리 컨트롤러를 다시 확장해도 리스는 돌아오지 않습니다. 캐퍼빌리티가 리스를 계속 보유하고 갱신하기 때문입니다. 조정을 자체 관리 컨트롤러로 되돌리려면 하나 이상의 복제본으로 다시 확장한 다음 ACK 캐퍼빌리티를 삭제하세요. 캐퍼빌리티를 삭제하면 자체 관리 컨트롤러가 리스를 다시 획득하고 조정을 재개합니다.

4. 어답션 시 캐퍼빌리티는 자체 관리 ACK가 사용하는 services.k8s.aws/ 태그 대신 자체 기본 리소스 태그(eks: 접두사)를 적용합니다(EKS용 ACK 고려 사항 참고).

어답션된 리소스에 대해 일회성 태깅 API 호출이 발생할 것으로 예상하고, services.k8s.aws/ 태그 접두사를 기준으로 하는 비용 할당 또는 정책 도구를 업데이트하세요.

5. 캐퍼빌리티가 상태(health)가 양호하고 리소스 조정을 인계받았는지 확인.

리소스가 Synced 조건 True를 보고하고 캐퍼빌리티가 AccessDenied 오류를 기록하지 않는지 확인하세요.

6. 캐퍼빌리티가 리소스를 올바르게 관리하는지 확인한 후 자체 관리 컨트롤러를 제거.

helm uninstall ack-s3-controller --namespace ack-system

이 접근 방식은 마이그레이션 중 두 컨트롤러가 안전하게 공존하도록 합니다. 관리형 캐퍼빌리티는 리스를 해제한 후 자체 관리 컨트롤러가 이전에 관리하던 리소스를 어답션해 충돌 없이 지속적인 조정을 보장합니다.

Preview 컨트롤러와 자동 승격

캐퍼빌리티는 업스트림 ACK에서 GA인 컨트롤러만 지원합니다. 오늘 preview인 컨트롤러는 나중에 업스트림에서 GA로 승격될 수 있습니다. 그렇게 되면 캐퍼빌리티가 사용자의 어떤 조치 없이도 해당 컨트롤러 관리를 자동으로 시작합니다.

이로 인해 다른 컨트롤러에도 캐퍼빌리티를 사용하는 클러스터에서 자체 관리 preview 컨트롤러를 실행하면 위험이 생깁니다. 조정할 다른 컨트롤러가 없으므로 preview 컨트롤러를 리더 선출이 비활성화된 단일 복제본으로 실행할 수 있습니다. 해당 컨트롤러가 GA로 승격되면 캐퍼빌리티가 이를 관리하기 시작합니다. 그 시점에 두 리컨실리에이터가 이를 조정할 공유 리스 없이 같은 리소스에 대해 작동합니다. 결과는 마이그레이션 단계가 방지하려고 설계된 것과 같은 이중 조정 충돌입니다. 두 리컨실리에이터가 경쟁하는 AWS API 호출을 발행하고 커스텀 리소스 상태에 상충하는 업데이트를 씁니다.

이를 피하려면 캐퍼빌리티와 함께 자체 관리 preview 컨트롤러를 실행하기 전에:

자체 관리 preview 컨트롤러에서 리더 선출을 활성화하고 마이그레이션 단계에 표시된 것과 동일한 leaderElection.enabled=true와 leaderElection.namespace=kube-system 설정을 사용해 리스를 kube-system에 지정하세요. 이렇게 하면 컨트롤러가 승격되고 캐퍼빌리티가 인계하더라도 두 컨트롤러가 병렬로 조정하는 대신 공유 리스를 통해 조정할 수 있습니다.
의존하는 preview 컨트롤러의 업스트림 GA 상태를 추적하고, 승격 시 마이그레이션 경로에 따라 마이그레이션할 계획을 세우세요. 각 컨트롤러의 현재 상태는 ACK 웹사이트의 ACK 서비스 페이지에서 확인할 수 있습니다.

다음 단계

ACK 캐퍼빌리티 생성 - ACK 캐퍼빌리티 리소스 생성
ACK 개념 - ACK 개념과 리소스 수명 주기 이해하기
ACK 권한 구성 - IAM과 권한 구성

더 알아보기 (Learn more)

공식 문서