이 페이지 개선에 도움 주기

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

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

다중 클러스터 아키텍처 패턴

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

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

중앙 관리형 클러스터에서 세 가지 기능을 모두 실행하여 워크로드를 오케스트레이션하고 여러 워크로드 클러스터에서 클라우드 인프라를 관리합니다.

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

분산된 GitOps

워크로드 및 클라우드 인프라는 워크로드가 실행되는 동일한 클러스터의 기능에 의해 관리됩니다.

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

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

범위 및 소유권을 기반으로 중앙 집중식 애플리케이션 배포 및 리소스 관리와 중앙 집중식 및 분산 모델을 결합합니다.

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

패턴 선택

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

EKS 기능과 자체 관리형 솔루션 비교

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

주요 차이

배포 및 관리

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

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

작업 및 유지 관리

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

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

리소스 소비

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

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

기능 지원

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

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

비용 고려 사항

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

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

EKS 기능과 자체 관리형 솔루션 중에서 선택

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

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

기능별 비교

기능별 특성, 업스트림 차이 및 마이그레이션 경로를 포함한 자세한 비교는 다음을 참조하세요.