**이 페이지 개선에 도움 주기** 

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

# EKS 기능 및 고려 사항
<a name="capabilities-considerations"></a>

이 주제에서는 액세스 제어 설계, EKS 기능과 자체 관리형 솔루션 중 선택, 다중 클러스터 배포에 대한 아키텍처 패턴, 운영 모범 사례 등 EKS 기능 사용에 대한 중요한 고려 사항을 다룹니다.

## 기능 IAM 역할 및 Kubernetes RBAC
<a name="_capability_iam_roles_and_kubernetes_rbac"></a>

각 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 기능에 대한 보안 고려 사항](capabilities-security.md) 섹션을 참조하세요.

## 다중 클러스터 아키텍처 패턴
<a name="_multi_cluster_architecture_patterns"></a>

여러 클러스터에 기능을 배포할 때는 다음과 같은 일반적인 아키텍처 패턴을 고려합니다.

 **중앙 집중식 관리를 통한 허브 및 스포크** 

중앙 관리형 클러스터에서 세 가지 기능을 모두 실행하여 워크로드를 오케스트레이션하고 여러 워크로드 클러스터에서 클라우드 인프라를 관리합니다.
+ 관리 클러스터에서 Argo CD는 서로 다른 리전 또는 계정의 워크로드 클러스터에 애플리케이션을 배포함
+ 관리 클러스터에서 ACK는 모든 클러스터에 대해 AWS 리소스(RDS, S3, IAM)를 프로비저닝함
+ 관리 클러스터에서 kro는 모든 클러스터에서 작동하는 이동식 플랫폼 추상화를 생성함

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

 **분산된 GitOps** 

워크로드 및 클라우드 인프라는 워크로드가 실행되는 동일한 클러스터의 기능에 의해 관리됩니다.
+ Argo CD는 로컬 클러스터에서 애플리케이션 리소스를 관리합니다.
+ ACK 리소스는 클러스터 및 워크로드 요구 사항에 사용됩니다.
+ kro 플랫폼 추상화가 설치되고 로컬 리소스를 오케스트레이션합니다.

이 패턴은 하나 이상의 클러스터에서 자체 전용 플랫폼 서비스를 관리하는 팀을 통해 운영을 분산합니다.

 **하이브리드 ACK 배포를 사용하는 허브 및 스포크** 

범위 및 소유권을 기반으로 중앙 집중식 애플리케이션 배포 및 리소스 관리와 중앙 집중식 및 분산 모델을 결합합니다.
+ 허브 클러스터:
  + Argo CD는 로컬 클러스터 및 모든 원격 워크로드 클러스터에 대한 GitOps 배포를 관리함
  + ACK는 관리자 범위 리소스(프로덕션 데이터베이스, IAM 역할, VPC)에 대해 관리 클러스터에서 사용됨
  + kro는 재사용 가능한 플랫폼 추상화를 위해 관리 클러스터에서 사용됨
+ Spoke 클러스터:
  + 워크로드는 중앙 집중식 허브 클러스터에서 Argo CD를 통해 관리됨
  + ACK는 워크로드 범위 리소스(S3 버킷, ElastiCache 인스턴스, SQS 대기열)에 대해 로컬로 사용됨
  + kro는 리소스 구성 및 구성 요소 패턴에 대해 로컬로 사용됨

이 패턴은 문제를 구분합니다. 플랫폼 팀은 선택적으로 워크로드 클러스터를 포함하여 관리 클러스터에서 중요한 인프라를 중앙에서 관리하는 반면, 애플리케이션 팀은 워크로드와 함께 클라우드 리소스를 지정 및 관리합니다.

 **패턴 선택** 

아키텍처를 선택할 때 다음 요소를 고려합니다.
+  **조직 구조**: 중앙 집중식 플랫폼 팀은 허브 패턴을 선호하고, 분산 팀은 클러스터별 기능을 선호할 수 있음
+  **리소스 범위**: 관리자 범위 리소스(데이터베이스, IAM)는 중앙 관리에서 종종 더 유리하며, 워크로드 리소스(버킷, 대기열)는 로컬에서 관리할 수 있음
+  **셀프 서비스**: 중앙 집중식 플랫폼 팀은 규범적 사용자 지정 리소스를 작성하고 배포하여 일반적인 워크로드 요구 사항에 맞게 클라우드 리소스를 안전하게 셀프 서비스로 제공할 수 있음
+  **클러스터 플릿 관리**: 중앙 집중식 관리 클러스터는 다른 관리자 범위 리소스와 함께 EKS 클러스터 플릿 관리에 대한 고객 소유 컨트롤 플레인을 제공함
+  **규정 준수 요구 사항**: 일부 조직에서는 감사 및 거버넌스를 위한 중앙 집중식 제어가 필요함
+  **운영 복잡성**: 매우 소수의 기능 인스턴스가 작업을 단순화하지만 병목 현상을 생성할 수 있음

**참고**  
하나의 패턴으로 시작하여 플랫폼이 성숙해지면 다른 패턴으로 진화할 수 있습니다. 기능은 독립적입니다. 필요에 따라 여러 클러스터에서 서로 다르게 배포할 수 있습니다.

## EKS 기능과 자체 관리형 솔루션 비교
<a name="_comparing_eks_capabilities_to_self_managed_solutions"></a>

EKS 기능은 EKS에서 실행되는 인기 Kubernetes 도구 및 컨트롤러에 대한 완전관리형 경험을 제공합니다. 이는 클러스터에 설치 및 운영하는 자체 관리형 솔루션과 다릅니다.

### 주요 차이
<a name="_key_differences"></a>

 **배포 및 관리** 

 AWS는 구성 요소 소프트웨어를 설치, 구성 또는 유지 관리하지 않고도 EKS 기능을 완벽하게 관리합니다. AWS는 클러스터에 필요한 모든 Kubernetes 사용자 지정 리소스 정의(CRD)를 자동으로 설치 및 관리합니다.

자체 관리형 솔루션을 사용하여 헬름 차트, kubectl 또는 기타 연산자를 사용하여 클러스터 소프트웨어를 설치하고 구성합니다. 자체 관리형 솔루션의 소프트웨어 수명 주기 및 런타임 구성을 완벽하게 제어하여 솔루션의 모든 계층에서 사용자 지정을 제공합니다.

 **작업 및 유지 관리** 

 AWS는 자동 업데이트 및 보안 패치를 통해 EKS 기능의 패치 및 기타 소프트웨어 수명 주기 작업을 관리합니다. EKS 기능은 간소화된 구성을 위해 AWS 기능과 통합되고 기본 제공 고가용성 및 내결함성을 제공하며 컨트롤러 워크로드의 클러스터 내 문제 해결을 제거합니다.

자체 관리형 솔루션을 사용하려면 구성 요소 상태 및 로그를 모니터링하고, 보안 패치 및 버전 업데이트를 적용하며, 여러 복제본 및 포드 중단 예산으로 고가용성을 구성하고, 컨트롤러 워크로드 문제를 해결하며, 릴리스 및 버전을 관리해야 합니다. 배포를 완전히 제어할 수 있지만, 프라이빗 클러스터 액세스 및 기타 통합을 위한 맞춤 솔루션이 필요한 경우가 많습니다. 이때 이러한 솔루션은 조직 표준 및 보안 규정 준수 요구 사항에 부합해야 합니다.

 **리소스 소비** 

EKS 기능은 EKS 내부 및 클러스터 외부에서 실행되므로 노드 리소스와 클러스터 리소스를 확보할 수 있습니다. 기능은 클러스터 워크로드 리소스를 사용하지 않고, 워커 노드에서 CPU 또는 메모리를 사용하지 않으며, 자동으로 조정되고, 클러스터 용량 계획에 미치는 영향을 최소화합니다.

자체 관리형 솔루션은 워커 노드에서 컨트롤러 및 기타 구성 요소를 실행하여 워커 노드 리소스, 클러스터 IP 및 기타 클러스터 리소스를 직접 사용합니다. 클러스터 서비스를 관리하려면 워크로드에 대한 용량 계획이 필요하며, 조정 및 고가용성 요구 사항을 관리하기 위해 리소스 요청 및 제한을 계획하고 구성해야 합니다.

 **기능 지원** 

완전관리형 서비스 기능인 EKS 기능은 자체 관리형 솔루션과 비교하여 본질적으로 견고합니다. 이 기능은 대부분의 기능 및 사용 사례를 지원하지만 자체 관리형 솔루션과 비교했을 때 적용 범위에 차이가 있습니다.

자체 관리형 솔루션을 사용하면 소프트웨어의 구성, 선택적 기능 및 기타 기능 측면을 완벽하게 제어할 수 있습니다. 자체 사용자 지정 이미지를 실행하고 구성의 모든 측면을 사용자 지정하며 자체 관리형 솔루션 기능을 완전히 제어하도록 선택할 수 있습니다.

 **비용 고려 사항** 

각 EKS 기능 리소스에는 관련된 시간당 비용이 있으며, 이는 기능 유형에 따라 다릅니다. 기능에서 관리하는 클러스터 리소스에는 자체 요금이 적용되는 관련된 시간당 비용도 있습니다. 자세한 내용은 [Amazon EKS 요금](https://aws.amazon.com/eks/pricing/)을 참조하세요.

자체 관리형 솔루션에는 AWS 요금과 관련된 직접 비용이 없지만, 컨트롤러 및 관련 워크로드에서 사용하는 클러스터 컴퓨팅 리소스에 대한 비용이 청구됩니다. 노드 및 클러스터 리소스 사용 외에도 자체 관리형 솔루션을 사용할 때 전체 소유권 비용에는 운영 오버헤드 그리고 유지 관리, 문제 해결 및 지원과 관련된 비용이 포함됩니다.

### EKS 기능과 자체 관리형 솔루션 중에서 선택
<a name="_choosing_between_eks_capabilities_and_self_managed_solutions"></a>

 **EKS 기능** 기본 요구 사항에 대한 클러스터 플랫폼 작업 대신, 운영 오버헤드를 줄이고 소프트웨어 및 시스템의 차별화된 가치에 집중하려는 경우 이 선택을 고려합니다. 보안 패치 및 소프트웨어 수명 주기 관리에 관한 운영 부담을 최소화하고, 애플리케이션 워크로드에 대한 노드 및 클러스터 리소스를 확보하며, 구성 및 보안 관리를 단순화하고, AWS 지원 범위를 활용하려는 경우 EKS 기능을 사용합니다. EKS 기능은 대부분의 프로덕션 사용 사례에 적합이며 새 배포에 권장되는 접근 방식입니다.

 **자체 관리형 솔루션** 특정 Kubernetes 리소스 API 버전, 사용자 지정 컨트롤러 빌드가 필요하거나 자체 관리형 배포에서 기존 자동화 및 도구를 빌드하거나 컨트롤러 런타임 구성을 심층적으로 사용자 지정해야 하는 경우 이 선택을 고려합니다. 자체 관리형 솔루션은 특수한 사용 사례에 대한 유연성을 제공하며 배포 및 런타임 구성을 완벽하게 제어할 수 있습니다.

**참고**  
EKS 기능은 자체 관리형 솔루션과 클러스터에 공존할 수 있으며, 단계별 마이그레이션을 수행할 수 있습니다.

### 기능별 비교
<a name="_capability_specific_comparisons"></a>

기능별 특성, 업스트림 차이 및 마이그레이션 경로를 포함한 자세한 비교는 다음을 참조하세요.
+  [EKS의 ACK 기능과 자체 관리형 ACK 비교](ack-comparison.md) 
+  [Argo CD의 EKS 기능과 자체 관리형 Argo CD 비교](argocd-comparison.md) 
+  [kro의 EKS 기능 및 자체 관리형 kro 비교](kro-comparison.md)