EKS의 ACK 기능과 자체 관리형 ACK 비교 - Amazon EKS

View a markdown version of this page

EKS의 ACK 기능과 자체 관리형 ACK 비교 - Amazon EKS
업스트림 ACK와의 차이마이그레이션 경로컨트롤러 프리뷰 및 자동 승격다음 단계

이 페이지 개선에 도움 주기

이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 GitHub에서 이 페이지 편집 링크를 선택합니다.

EKS의 ACK 기능과 자체 관리형 ACK 비교

EKS의 ACK 기능은 자체 관리형 ACK 컨트롤러와 동일한 기능을 제공하지만 상당한 운영 이점을 제공합니다. EKS 기능과 자체 관리형 솔루션의 일반적인 비교는 EKS 기능 및 고려 사항 섹션을 참조하세요. 이 주제에서는 ACK에 특정한 차이에 중점을 둡니다.

업스트림 ACK와의 차이

EKS의 ACK 기능은 업스트림 ACK 컨트롤러에 기반하지만 IAM 통합에서 차이가 납니다.

IAM 기능 역할: 이 기능은 서비스 계정에 대한 IAM 역할(IRSA)이 아닌 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에서 정식 버전(GA)으로 제공되는 컨트롤러 및 리소스만 지원합니다. 기능에는 프리뷰 업스트림 상태인 컨트롤러가 포함되지 않습니다. 컨트롤러의 상태는 시간이 지남에 따라 프리뷰에서 GA 업스트림으로 변경될 수 있으며, 그러면 기능이 자동으로 컨트롤러 관리를 시작할 수 있습니다. 기능과 함께 자체 관리형 프리뷰 컨트롤러를 실행하는 경우 마이그레이션하기 전에 컨트롤러 프리뷰 및 자동 승격 섹션을 검토하세요.

전체 ACK 설명서 및 서비스별 가이드는 ACK 웹사이트에서 ACK 설명서를 참조하세요.

마이그레이션 경로

AWS 리소스 중단을 최소화하면서 자체 관리형 ACK에서 관리형 기능으로 마이그레이션할 수 있습니다. 마이그레이션은 Kubernetes 리더 선정에 의존합니다. 즉, 자체 관리형 컨트롤러와 이 기능이 동일한 리스에 대해 경합하므로 언제든지 둘 중 하나만 지정된 리소스를 조정합니다. 이렇게 하려면 둘 다 동일한 네임스페이스에서 리스를 공유해야 합니다. 기능은 실행 중인 자체 관리형 컨트롤러에서 강제로 리스를 가져오지 않으므로 자체 관리형 컨트롤러를 스케일 다운하여 인계가 발생하는 시기를 제어할 수 있습니다.

중요

시작하기 전에 자체 관리형 컨트롤러가 현재 사용하는 권한과 동등한 IAM 기능 역할 권한을 부여합니다. 기능은 IRSA 또는 EKS Pod Identity와 같이 자체 관리형 컨트롤러가 현재 사용하는 메커니즘이 아닌 capabilities.eks.amazonaws.com 서비스 위탁자를 통해 전용 기능 역할로 인증합니다(ACK 권한 구성 참조). 기능 역할에 권한이 없는 경우 기능이 리소스를 채택합니다. 그러면 기능은 리소스 조정에 실패하고 AccessDenied 오류를 기록합니다.

마이그레이션하려면 다음 단계를 완료합니다. 이 단계에서는 S3 컨트롤러(ack-s3-controller)를 예로 사용합니다. 해당 컨트롤러 이름 및 헬름 차트를 대체하여 기능으로 마이그레이션하려는 각 자체 관리형 ACK 컨트롤러에 대해 단계를 반복합니다.

참고

기능과 함께 자체 관리형 컨트롤러를 실행하는 것은 장기 구성이 아니라 마이그레이션 중 임시로 사용됩니다. 둘 다 실행되는 동안 어느 한쪽에서 중단(예: 기능 배포 또는 자체 관리형 컨트롤러 업그레이드)이 발생하면 리스가 해제되어 다른 쪽이 이를 획득할 수 있으며, 이로 인해 조정이 예기치 않게 전환될 수 있습니다. 각 컨트롤러에 대한 마이그레이션을 완료하세요. 기능과 함께 자체 관리형 컨트롤러를 무기한으로 실행하는 것은 피해야 합니다.

  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 헬름 차트에서 --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 기능을 삭제합니다. 기능을 삭제하면 자체 관리형 컨트롤러가 리스를 다시 획득하고 조정을 재개합니다.

    채택 시 기능은 자체 관리형 ACK에서 사용하는 services.k8s.aws/ 태그 대신 자체 기본 리소스 태그(eks: 접두사)를 적용합니다(EKS에 대한 ACK 고려 사항 참조). 채택한 리소스에 대해 일회성 태깅 API 직접 호출 세트를 예상하고 services.k8s.aws/ 태그 접두사를 키로 사용하는 비용 할당 또는 정책 도구를 업데이트합니다.

  4. 기능이 정상이고 리소스 조정을 인수했는지 확인합니다. 리소스가 Synced의 True 조건을 보고하고, 기능이 AccessDenied 오류를 로깅하지 않는지 확인합니다.

  5. 기능이 리소스를 올바르게 관리하고 있는지 확인한 후 자체 관리형 컨트롤러를 제거합니다.

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

이 접근 방식을 사용하면 마이그레이션 중에 두 컨트롤러가 모두 안전하게 공존할 수 있습니다. 리스를 해제하면 관리형 기능은 이전에 자체 관리형 컨트롤러에서 관리하던 리소스를 채택하여 충돌 없이 지속적인 조정이 이루어지도록 합니다.

컨트롤러 프리뷰 및 자동 승격

기능은 업스트림 ACK에서 GA인 컨트롤러만 지원합니다. 현재 프리뷰 상태인 컨트롤러는 나중에 GA 업스트림으로 승격할 수 있습니다. 이 경우 기능이 사용자의 조치 없이 자동으로 해당 컨트롤러를 관리하기 시작합니다.

이로 인해 다른 컨트롤러에 대해서도 기능을 사용하는 클러스터에서 자체 관리형 프리뷰 컨트롤러를 실행하는 경우 위험이 발생합니다. 조정할 다른 컨트롤러가 없기 때문에 리더 선정이 비활성화된 상태에서 프리뷰 컨트롤러를 단일 복제본으로 실행할 수 있습니다. 해당 컨트롤러가 GA로 승격되면 기능이 컨트롤러 관리를 시작합니다. 이 시점에서 두 조정자는 조정을 위한 공유 리스 없이 동일한 리소스에 대해 작업을 수행합니다. 결과적으로 마이그레이션 단계가 방지하도록 설계된 것과 동일한 이중 조정 충돌이 발생합니다. 두 조정자 모두 경합하는 AWS API 직접 호출을 실행하고 사용자 지정 리소스 상태에 충돌하는 업데이트를 작성합니다.

이를 방지하려면 기능과 함께 자체 관리형 프리뷰 컨트롤러를 실행하기 전에 다음을 수행합니다.

  • 자체 관리형 프리뷰 컨트롤러에서 리더 선정을 활성화하고 마이그레이션 단계에 표시된 것과 동일한 leaderElection.enabled=true 및 leaderElection.namespace=kube-system 설정을 사용하여 kube-system에서 해당 리스를 가리킵니다. 이렇게 하면 컨트롤러가 승격되고 기능이 컨트롤러를 인수하는 경우 두 조정자가 병렬로 조정하지 않고 공유 리스를 통해 조정합니다.

  • 사용하는 프리뷰 컨트롤러의 업스트림 GA 상태를 추적하고 승격 시 마이그레이션 경로에 따라 마이그레이션을 계획합니다. ACK 웹사이트의 ACK 서비스 페이지에서 각 컨트롤러의 현재 상태를 확인할 수 있습니다.

다음 단계