EKS 캐퍼빌리티 고려 사항

EKS 캐퍼빌리티 고려 사항

EKS 캐퍼빌리티를 배포하기 전에 살펴볼 중요한 고려 사항을 설명합니다. 접근 제어 설계, 관리형 대 자체 관리 솔루션 선택, 멀티 클러스터 배포를 위한 아키텍처 패턴, 운영 모범 사례를 다룹니다.

출처: 문서

본문

캐퍼빌리티 IAM 역할과 Kubernetes RBAC

각 EKS 캐퍼빌리티 리소스에는 구성된 캐퍼빌리티 IAM 역할이 있습니다. 캐퍼빌리티 역할은 EKS 캐퍼빌리티가 사용자 대신 작업을 수행하도록 AWS 서비스 권한을 부여하는 데 사용됩니다. 예를 들어 ACK용 EKS 캐퍼빌리티로 Amazon S3 버킷을 관리하려면 S3 버킷 관리 권한을 캐퍼빌리티에 부여해 버킷을 생성하고 관리할 수 있게 합니다.

캐퍼빌리티가 구성되면 클러스터의 Kubernetes 커스텀 리소스로 AWS의 S3 리소스를 생성하고 관리할 수 있습니다. Kubernetes RBAC는 어떤 사용자와 그룹이 해당 커스텀 리소스를 생성하고 관리할 수 있는지 결정하는 클러스터 내 접근 제어 메커니즘입니다. 예를 들어 특정 Kubernetes RBAC 사용자와 그룹에게 선택한 네임스페이스에서 Bucket 리소스를 생성하고 관리할 권한을 부여할 수 있습니다.

이처럼 IAM과 Kubernetes RBAC는 EKS 캐퍼빌리티와 리소스 관련 권한을 관장하는 종단 간 접근 제어 시스템의 두 축입니다. 사용 사례에 맞는 올바른 IAM 권한과 RBAC 접근 정책 조합을 설계하는 것이 중요합니다.

캐퍼빌리티 IAM 역할과 Kubernetes 권한에 대한 추가 정보는 EKS 캐퍼빌리티 보안 고려 사항을 참고하세요.

멀티 클러스터 아키텍처 패턴

여러 클러스터에 캐퍼빌리티를 배포할 때는 다음 일반적인 아키텍처 패턴을 고려하세요.

중앙 집중 관리형 허브 앤 스포크(Hub and Spoke)

세 가지 캐퍼빌리티를 모두 중앙에서 관리하는 클러스터에서 실행해 여러 워크로드 클러스터에 걸쳐 워크로드를 오케스트레이션하고 클라우드 인프라를 관리합니다.

  • 관리 클러스터의 Argo CD가 다른 리전이나 계정의 워크로드 클러스터에 애플리케이션을 배포합니다.
  • 관리 클러스터의 ACK가 모든 클러스터용 AWS 리소스(RDS, S3, IAM)를 프로비저닝합니다.
  • 관리 클러스터의 kro가 모든 클러스터에서 작동하는 이식 가능한 플랫폼 추상화를 만듭니다.

이 패턴은 워크로드와 클라우드 인프라 관리를 중앙화하며, 많은 클러스터를 관리하는 조직의 운영을 단순화할 수 있습니다.

분산 GitOps

워크로드와 클라우드 인프라를 워크로드가 실행되는 것과 같은 클러스터의 캐퍼빌리티로 관리합니다.

  • Argo CD가 로컬 클러스터의 애플리케이션 리소스를 관리합니다.
  • ACK 리소스를 클러스터와 워크로드 요구에 사용합니다.
  • kro 플랫폼 추상화를 설치하고 로컬 리소스를 오케스트레이션합니다.

이 패턴은 팀이 하나 이상의 클러스터에서 자신의 전용 플랫폼 서비스를 관리하므로 운영을 분산시킵니다.

하이브리드 ACK 배포를 사용한 허브 앤 스포크

범위와 소유권에 따라 중앙 집중 배포와 리소스 관리를 결합해 중앙 집중형과 분산형 모델을 모두 활용합니다.

  • 허브 클러스터:
    • Argo CD가 로컬 클러스터와 모든 원격 워크로드 클러스터로의 GitOps 배포를 관리합니다.
    • 관리 클러스터의 ACK를 관리자 범위 리소스(프로덕션 데이터베이스, IAM 역할, VPC)에 사용합니다.
    • 관리 클러스터의 kro를 재사용 가능한 플랫폼 추상화에 사용합니다.
  • 스포크 클러스터:
    • 워크로드는 중앙 허브 클러스터의 Argo CD를 통해 관리됩니다.
    • ACK를 워크로드 범위 리소스(S3 버킷, ElastiCache 인스턴스, SQS 큐)에 로컬로 사용합니다.
    • kro를 리소스 구성과 기본 구성 요소 패턴에 로컬로 사용합니다.

이 패턴은 관심사를 분리합니다. 플랫폼 팀은 관리 클러스터에서(선택적으로 워크로드 클러스터를 포함해) 중요 인프라를 중앙에서 관리하고, 애플리케이션 팀은 워크로드와 함께 클라우드 리소스를 지정하고 관리합니다.

패턴 선택하기

아키텍처를 선택할 때 다음 요소를 고려하세요.

  • 조직 구조 - 중앙 집중 플랫폼 팀은 허브 패턴을 선호하고, 분산 팀은 클러스터별 캐퍼빌리티를 선호할 수 있습니다.
  • 리소스 범위 - 관리자 범위 리소스(데이터베이스, IAM)는 중앙 관리가 유리한 경우가 많고, 워크로드 리소스(버킷, 큐)는 로컬에서 관리할 수 있습니다.
  • 셀프 서비스 - 중앙 플랫폼 팀은 일반적인 워크로드 요구를 위한 클라우드 리소스의 안전한 셀프 서비스를 지원하도록 규정적인 커스텀 리소스를 작성하고 배포할 수 있습니다.
  • 클러스터 플릿 관리 - 중앙 관리 클러스터는 다른 관리자 범위 리소스와 함께 EKS 클러스터 플릿 관리를 위한 고객 소유 제어 플레인을 제공합니다.
  • 규정 준수 요구 사항 - 일부 조직은 감사와 거버넌스를 위해 중앙 제어를 요구합니다.
  • 운영 복잡성 - 캐퍼빌리티 인스턴스가 적을수록 운영은 단순해지지만 병목이 생길 수 있습니다.

참고

한 패턴으로 시작해 플랫폼이 성숙해짐에 따라 다른 패턴으로 진화할 수 있습니다. 캐퍼빌리티는 독립적이므로 필요에 따라 클러스터별로 다르게 배포할 수 있습니다.

EKS 캐퍼빌리티와 자체 관리 솔루션 비교

EKS 캐퍼빌리티는 EKS에서 실행되는 인기 있는 Kubernetes 도구와 컨트롤러에 완전 관리형 환경을 제공합니다. 이는 클러스터에서 직접 설치하고 운영하는 자체 관리 솔루션과 다릅니다.

주요 차이점

  • 배포와 관리 - AWS가 설치, 구성, 유지 관리 없이 EKS 캐퍼빌리티를 완전히 관리합니다. AWS가 클러스터에 필요한 모든 Kubernetes 커스텀 리소스 정의(CRD)를 자동으로 설치하고 관리합니다.
    • 자체 관리 솔루션에서는 Helm 차트, kubectl 또는 다른 오퍼레이터를 사용해 클러스터 소프트웨어를 직접 설치하고 구성합니다. 소프트웨어 수명 주기와 런타임 구성을 완전히 제어해 솔루션의 모든 계층에서 커스터마이징을 할 수 있습니다.
  • 운영과 유지 관리 - AWS가 EKS 캐퍼빌리티를 위한 패치와 기타 소프트웨어 수명 주기 작업을 자동 업데이트와 보안 패치와 함께 관리합니다. EKS 캐퍼빌리티는 간소화된 구성을 위한 AWS 기능과 통합되고, 기본 제공되는 고가용성과 장애 허용을 가지며, 컨트롤러 워크로드의 클러스터 내 문제 해결을 없앱니다.
    • 자체 관리 솔루션은 구성 요소 상태(health)와 로그를 모니터링하고, 보안 패치와 버전 업데이트를 적용하고, 여러 복제본과 파드 중단 예산으로 고가용성을 구성하고, 컨트롤러 워크로드 문제를 해결하고 완화하며, 릴리스와 버전을 관리해야 합니다. 배포를 완전히 제어할 수 있지만, 이는 종종 조직 표준과 보안 규정 준수 요구 사항에 맞춰야 하는 프라이빗 클러스터 접근 같은 맞춤형 솔루션을 필요로 합니다.
  • 리소스 소비 - EKS 캐퍼빌리티는 EKS에서 클러스터 밖에서 실행되어 노드 리소스와 클러스터 리소스를 확보합니다. 캐퍼빌리티는 클러스터 워크로드 리소스를 사용하지 않고, 워커 노드의 CPU나 메모리를 소비하지 않으며, 자동으로 확장되고, 클러스터 용량 계획에 미치는 영향이 최소입니다.
    • 자체 관리 솔루션은 컨트롤러와 기타 구성 요소를 워커 노드에서 실행해 워커 노드 리소스, 클러스터 IP, 기타 클러스터 리소스를 직접 소비합니다. 클러스터 서비스를 관리하려면 워크로드 용량을 계획하고, 확장과 고가용성 요구를 관리하기 위해 리소스 요청과 제한을 계획하고 구성해야 합니다.
  • 기능 지원 - 완전 관리형 서비스 기능으로서 EKS 캐퍼빌리티는 본질적으로 자체 관리 솔루션보다 원칙적(opinionated)입니다. 캐퍼빌리티가 대부분의 기능과 사용 사례를 지원하겠지만, 자체 관리 솔루션과 비교하면 적용 범위에 차이가 있습니다.
    • 자체 관리 솔루션에서는 소프트웨어의 구성, 선택적 기능, 기타 기능 측면을 완전히 제어할 수 있습니다. 자체 커스텀 이미지를 실행하고, 구성의 모든 측면을 커스터마이징하고, 자체 관리 솔루션 기능을 완전히 제어할 수 있습니다.
  • 비용 고려 사항 - 각 EKS 캐퍼빌리티 리소스에는 캐퍼빌리티 유형에 따라 다른 시간당 비용이 있습니다. 캐퍼빌리티가 관리하는 클러스터 리소스에도 고유한 요금이 있는 시간당 비용이 연결됩니다. 자세한 내용은 Amazon EKS 요금을 참고하세요.
    • 자체 관리 솔루션은 AWS 요금과 직접 관련된 비용이 없지만, 컨트롤러와 관련 워크로드가 사용하는 클러스터 컴퓨팅 리소스 비용을 지불합니다. 노드와 클러스터 리소스 소비 외에도, 자체 관리 솔루션의 총 소유 비용에는 유지 관리, 문제 해결, 지원의 운영 오버헤드와 비용이 포함됩니다.

EKS 캐퍼빌리티와 자체 관리 솔루션 중 선택하기

  • EKS 캐퍼빌리티 - 기본 요구 사항을 위한 클러스터 플랫폼 운영 대신 운영 오버헤드를 줄이고 소프트웨어와 시스템의 차별화된 가치에 집중하고 싶을 때 선택하세요. 보안 패치와 소프트웨어 수명 주기 관리의 운영 부담을 최소화하고, 애플리케이션 워크로드를 위해 노드와 클러스터 리소스를 확보하고, 구성과 보안 관리를 간소화하며, AWS 지원 범위의 혜택을 받고 싶을 때 EKS 캐퍼빌리티를 사용하세요. EKS 캐퍼빌리티는 대부분의 프로덕션 사용 사례에 적합하며 새 배포에 권장되는 방식입니다.
  • 자체 관리 솔루션 - 특정 Kubernetes 리소스 API 버전, 커스텀 컨트롤러 빌드가 필요하거나, 자체 관리 배포를 중심으로 구축된 기존 자동화와 도구가 있거나, 컨트롤러 런타임 구성을 깊게 커스터마이징해야 할 때 선택하세요. 자체 관리 솔루션은 전문 사용 사례를 위한 유연성을 제공하며 배포와 런타임 구성을 완전히 제어할 수 있습니다.

참고

EKS 캐퍼빌리티는 자체 관리 솔루션과 클러스터에서 공존할 수 있으며, 단계적 마이그레이션도 가능합니다.

캐퍼빌리티별 비교

캐퍼빌리티별 기능, 업스트림 차이, 마이그레이션 경로를 포함한 자세한 비교는 다음을 참고하세요.

  • ACK용 EKS 캐퍼빌리티와 자체 관리 ACK 비교
  • Argo CD용 EKS 캐퍼빌리티와 자체 관리 Argo CD 비교
  • kro용 EKS 캐퍼빌리티와 자체 관리 kro 비교

더 알아보기 (Learn more)