Amazon EKS 비용에 대한 가시성 확보 - AWS 권장 가이드
개요비용 이점비용 최적화 권장 사항다음 단계추가 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon EKS 비용에 대한 가시성 확보

개요

Kubernetes 배포 비용을 효과적으로 모니터링하려면 전체적인 보기가 필요합니다. 유일하게 고정되고 알려진 비용은 Amazon Elastic Kubernetes Service(Amazon EKS) 컨트롤 플레인에 대한 비용입니다. 여기에는 컴퓨팅 및 스토리지부터 네트워킹에 이르기까지 배포를 구성하는 다른 모든 구성 요소가 포함되며, 이는 애플리케이션 요구 사항에 따라 달라집니다.

Kubecost를 사용하여 네임스페이스 및 서비스에서 개별 포드까지 Kubernetes 인프라의 비용을 분석한 다음 대시보드에 데이터를 표시할 수 있습니다. Kubecost는 컴퓨팅 및 스토리지와 같은 클러스터 내부 비용과 Amazon Simple Storage Service(Amazon S3) 버킷 및 Amazon Relational Database Service(Amazon RDS) 인스턴스와 같은 클러스터 외부 비용을 표시합니다. Kubecost는 이 데이터를 기반으로 적정 규모 조정을 권장하고 시스템에 영향을 미칠 수 있는 중요한 알림을 표시합니다. Kubecost는 AWS Cost and Usage Report와 통합하여 컴퓨팅 절감형 플랜, 예약 인스턴스 및 기타 할인 프로그램의 절감 효과를 표시할 수 있습니다.

비용 이점

Kubecost는 Amazon EKS 배포 비용을 시각화하는 보고서와 대시보드를 제공합니다. 이를 통해 클러스터에서 컨트롤러, 서비스, 노드, 포드 및 볼륨과 같은 다양한 각 구성 요소로 드릴다운할 수 있습니다. 이를 통해 Amazon EKS 환경에서 실행되는 애플리케이션을 전체적으로 파악할 수 있습니다. 이러한 가시성을 활성화하면 Kubecost 권장 사항에 따라 조치를 취하거나 각 애플리케이션의 비용을 세분화된 수준에서 볼 수 있습니다. Amazon EKS 노드 그룹을 적정 규모로 조정하면 표준 EC2 인스턴스와 동일한 잠재적 절감 효과를 얻을 수 있습니다. 컨테이너와 노드를 적정 규모로 조정할 수 있는 경우 컨테이너를 실행하는 데 필요한 인스턴스의 크기와 Auto Scaling 그룹에 필요한 EC2 인스턴스의 수로부터 컴퓨팅 팽창을 방지할 수 있습니다.

비용 최적화 권장 사항

Kubecost를 활용하려면 다음을 수행하는 것이 좋습니다.

  1. 환경에 Kubecost 배포

  2. Windows 애플리케이션의 세분화된 비용 분석

  3. 클러스터 노드 적정 규모 조정

  4. 컨테이너 요청 적정 규모 조정

  5. 사용률이 낮은 노드 관리

  6. 중단된 워크로드 해결

  7. 권장 사항에 대한 조치

  8. 자체 관리형 노드 업데이트

환경에 Kubecost 배포

Amazon EKS Finhack 워크숍에서는 AWS 소유 계정에서 Kubecost를 사용하도록 구성된 Amazon EKS 환경을 배포하는 방법을 설명합니다. 이를 통해 기술을 직접 체험해 볼 수 있습니다. 조직에서 이 워크숍을 실행하는 데 관심이 있는 경우 계정 팀에 문의하세요.

Helm을 사용하여 Amazon EKS 클러스터에 Kubecost를 배포하려면 AWS 블로그에 게시된 AWS 및 Kubecost 공동 작업을 참조하여 EKS 고객을 위한 비용 모니터링을 제공합니다. 또는 Kubecost 설치 및 구성에 대한 지침은 공식 Kubecost 설명서를 참조할 수 있습니다. Windows 노드에 대한 Kubecost 지원에 대한 자세한 내용은 Kubecost 설명서의 Windows Node Support를 참조하세요.

Windows 애플리케이션의 세분화된 비용 분석

Amazon EC2 스팟 인스턴스를 사용하여 비용을 크게 절감할 수 있지만 Windows 워크로드가 상태 저장 특성이 있다는 점에서도 이점을 얻을 수 있습니다. 스팟 인스턴스 사용은 애플리케이션에 따라 다르므로 사용 사례에 적용할 수 있는지 확인하는 것이 좋습니다.

Windows 애플리케이션을 세부적으로 분석하려면 Kubecost에 로그인합니다. 탐색 페이지에서 Savings를 선택합니다.

클러스터 노드 적정 규모 조정

Kubecost의 탐색 표시줄에서 Savings를 선택한 다음 Right-size your cluster node를 선택합니다.

클러스터가 vCPU 및 RAM 측면에서 과다 프로비저닝되었다고 Kubecost가 보고하는 예제를 고려합니다. 다음 표에는 Kubecost의 세부 정보 및 권장 사항이 나와 있습니다.

  현재 권장 사항: 단순 권장 사항: 복합
총 개수 월별 3462.57 USD 월별 137.24 USD 월별 303.68 USD
노드 개수 4 5 4
CPU vCPU 74개 vCPU 10개 vCPU 8개
RAM 152GB 20GB 18GB
인스턴스 분석 c5.xlarge 2개 + 추가 2개 t3a.medium 5개 c5n.large 2개 + 추가 1개

Kubecost 블로그 게시물 Find an optimal set of nodes for a Kubernetes cluster에 설명된 대로 간단한 옵션에서는 단일 노드 그룹을 사용하는 반면, 복잡한 옵션에서는 다중 노드 그룹 접근 방식을 사용합니다. Learn how to adopt 버튼을 사용하면 원클릭 클러스터 크기 조정을 수행할 수 있습니다. Kubecost Cluster Controller를 설치해야 합니다.

eksctl에서 생성하지 않은 자체 관리형 Windows 노드를 사용하는 경우 기존 자체 관리형 노드 그룹 업데이트를 참조하세요. 이 지침은 Auto Scaling 그룹에서 사용하는 Amazon EC2 시작 템플릿에서 인스턴스 유형을 변경하는 방법을 보여줍니다.

컨테이너 요청 적정 규모 조정

Kubecost의 탐색 표시줄에서 Savings를 선택하고 Request right-sizing recommendations 페이지로 이동합니다. 이 페이지에는 포드의 효율성, 적정 규모 조정 권장 사항 및 예상 비용 절감이 표시됩니다. Customize 버튼을 사용하여 Cluster, Node, Namespace\Controller 등으로 필터링할 수 있습니다.

예를 들어 Kubecost 계산 결과, 일부 포드가 CPU 및 RAM(메모리) 측면에서 과다 프로비저닝된 것으로 나타난 경우를 고려합니다. 그런 다음 Kubecost는 예상 월별 절감 효과를 달성하기 위해 새 CPU 및 RAM 값을 조정할 것을 권장합니다. CPU 및 RAM 값을 변경하려면 배포 매니페스트 파일을 업데이트해야 합니다.

사용률이 낮은 노드 관리

Kubecost의 탐색 표시줄에서 Savings를 선택한 다음 Manage underutilized nodes를 선택합니다.

클러스터의 노드 하나가 CPU 및 RAM(메모리) 측면에서 사용률이 낮고 이를 드레이닝하고 종료하거나 크기를 조정할 수 있다고 표시지에 표시되는 예제를 고려합니다. 노드 및 포드 검사를 통과하지 않는 노드를 선택하면 드레이닝할 수 없는 이유에 대한 자세한 정보를 얻을 수 있습니다.

중단된 워크로드 해결

Kubecost의 탐색 표시줄에서 Savings를 선택한 다음 Abandoned Workloads 페이지를 선택합니다. 이 예제에서는 windows라는 네임스페이스를 기준으로 필터링합니다. 이 페이지에는 트래픽 임계치를 충족하지 않고 중단된 것으로 간주되는 포드가 표시됩니다. 포드는 정의된 기간에 일정량의 네트워크 트래픽을 전송하거나 수신해야 합니다.

하나 이상의 포드가 중단된다는 점을 신중하게 고려한 후 복제본 수를 축소하거나 배포를 삭제하거나 리소스를 적게 소비하도록 크기를 조정하거나 배포가 중단되었다고 생각되면 이를 애플리케이션 소유자에게 알림으로써 비용을 절감할 수 있습니다.

권장 사항에 대한 조치

적정 크기의 클러스터 노드 섹션에서 Kubecost는 클러스터에서 워커 노드 사용량을 분석하고 노드의 적정 규모 조정에 대한 권장 사항을 제공하여 비용을 절감합니다. Amazon EKS에서는 자체 관리형 및 관리형과 같은 두 가지 유형의 노드 그룹을 사용할 수 있습니다.

자체 관리형 노드 업데이트

자체 관리형 노드 업데이트에 대한 자세한 내용은 Amazon EKS 설명서의 자체 관리형 노드 업데이트를 참조하세요. eksctl로 생성된 노드 그룹은 업데이트할 수 없으며 새 구성을 사용하여 새 노드 그룹으로 마이그레이션해야 한다고 명시되어 있습니다.

예를 들어 ng-windows-m5-2xlarge라는 Windows 노드 그룹(m5.2xlarge EC2 인스턴스 사용)이 있고 포드를 ng-windows-t3-large라는 새 노드 그룹(비용 절감을 위해 t3.large EC2 인스턴스에서 지원)으로 마이그레이션하려고 한다고 가정합니다.

eksctl에서 배포한 노드 그룹을 사용할 때 새 노드 그룹으로 마이그레이션하려면 다음을 수행합니다.

  1. 포드가 현재 있는 노드를 찾으려면 kubectl describe pod <pod_name> -n <namespace> 명령을 실행하세요.

  2. kubectl describe node <node_name> 명령을 실행합니다. 출력은 노드가 m5.2xlarge 인스턴스에서 실행 중임을 보여줍니다. 또한 노드 그룹 이름(ng-windows-m5-2xlarge)과도 일치합니다.

  3. 노드 그룹 ng-windows-t3-large를 사용하도록 배포를 변경하려면 노드 그룹 ng-windows-m5-2xlarge을 삭제하고 kubectl describe svc,deploy,pod -n windows를 실행하세요. 노드 그룹이 삭제되었으므로 배포에서 즉시 다시 배포를 시작합니다.

    참고

    노드 그룹을 삭제하면 서비스가 가동 중지됩니다.

  4. 몇 분 후에 kubectl describe svc,deploy,pod -n windows 명령을 다시 실행하세요. 출력은 포드가 모두 다시 실행 중 상태임을 보여줍니다.

  5. 포드가 노드 그룹 ng-windows-t3-large에서 실행되고 있음을 표시하려면 kubectl describe pod <pod_name> -n <namespace> 및 kubectl describe node <node_name> 명령을 다시 실행하세요.

대체 크기 조정 방법

이 방법은 자체 관리형 또는 관리형 노드 그룹의 모든 조합에 적용됩니다. Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups 블로그 게시물에서는 크기가 큰 인스턴스 유형의 한 노드 그룹에서 가동 중지 시간 없이 적정 규모로 조정된 노드 그룹으로 워크로드를 마이그레이션하는 방법에 대한 지침을 제공합니다.

다음 단계

Kubecost를 사용하면 Amazon EKS 환경의 비용을 쉽게 시각화할 수 있습니다. Kubecost를 Kubernetes 및 AWS APIs와 심층적으로 통합하면 잠재적 비용 절감을 찾는 데 도움이 될 수 있습니다. Kubecost의 Savings 대시보드에서 이를 권장 사항으로 볼 수 있습니다. Kubecost는 클러스터 컨트롤러 기능을 통해 이러한 권장 사항 중 일부를 구현할 수도 있습니다.

AWS 컨테이너 블로그의 및 Kubecost 공동 작업에서 step-by-step 배포를 검토하여 EKS 고객에게 비용 모니터링을 제공하는 것이 좋습니다. AWS

추가 리소스