IT/Kubernetes

kubecost의 Container Request Right Sizing Recommendation 기능 살펴보기

엘티엘 2023. 1. 23. 11:39

Kubecost의 강력한 기능중 하나인 "Container Request Right Sizing Recommendation" 기능에 대해서 살펴보자. 이 기능을 통해서 Container의 CPU, Memory 의 request, limit 값을 최적화 할수 있다.

Container Request CPU, Memory

Kubernetest Pod 는 Scheduling시에 Manifest에 작성된 Request CPU, Memory 만큼의 리소스가 여유있는 Worker Node를 찾ㄴ는다. 여기서 여유가 있다는 의미는 실제 사용율이 아닌 아래 값을 의미한다.

(Worker Node의 Spec) - (해당 Worker Node에 배포된 Pod의 Reqeust CPU, Memory의 합)

즉, Container의 Reqeust CPU, Memory 값을 과다하게 설정할 경우 실제 사용여부와는 관계없이 Worker Node의 리소스가 낭비된다. 그렇다고 너무 작은값을 설정할 경우 OOM(Out of Memory), CPU Throttling 등으로 장애 및 성능 저하를 유발할 수 있다.

따라서 각 Container의 적절한 Request 값을 결정하는 것이 효율적인 리소스 활용 측면에서 굉장히 중요하며, 클라우드 환경에서는 이것이 곧 비용이기 때문에 더욱 중요하다.

Kubecost의 Container Request Right Sizing Recommendation 기능

kubecost 는 실제 Container의 자원 사용율을 기반으로 적절한 Request CPU, Memory 값을 추천해 준다. 

메뉴를 클릭하면 아래와 같은 화면을 볼 수 있다.

Conatiner 에 설정된 request 값과, 실제 사용율, recommend 값도 알려준다. recommend값 적용시 절감할수 있는 비용까지 계산해서 보여준다. (참고로 비용은 Cloud 사업자나 Region 등을 적절하게 설정해주어야 한다)

Recommend 값 계산하기

Recommend 값은 기본적으로 Uage 값을 기반으로 계산된다. Usage 값이란 실제 사용율을 의미하는데, 선택한 기간(Window) 동안 평균 사용율을 의미한다. kubecost 와 같이 설치된(또는 따로 직접 설치한) kube-state-metrics 가 수집한 데이터를 사용한다.

GUI를 보면 Profile 이 있는데, 이것이 각각 Recommend 를 계산하는 Logic 을 의미한다. 선택한 Profile에 따라 평균 사용량에서 어느정도의 마진을 두는가가 달라진다. 콤보박스를 클릭해보면 아래와 같다.

  • Production: 65% 사용량 (45% 마진)
  • Development: 80% 사용량 (20% 마진)
  • High Availability: 50% 사용량 (50% 마진)

Development 는 최대한 마진을 조금 가져가고, Production은 충분한 마진을 가져간다. High Availability 는 절반이 모두 Down 되었을때 나머지가 해당 Traffic을 모두 처리할 수 있어야 하기 때문에 50%의 마진을 가져간다.

그런데, Application 특성상 평소 사용율은 작지만 배치 처리 등으로 Peak 사용율이 높을수 있다. 이럴 경우 위의 Logic 으로 계산한다면, 평균 사용량이 낮기 때문에 배치 처리를 하지 못할 정도의 Recommend 값이 계산될수 있다. Profile에 보면 Custom 이라는 항목이 있는데, 이럴 때 사용한다.

Profile=Custom 은 quantile 값으로 설정이 가능하다. 만일 5%로 설정하면, 수집주기(Window) 동안 상위 5/100등에 해당하는 값으로recommend 해준다. 평균 사용율은 낮으나 burst traffic 처리, 또는 배치성 처리가 있을경우는 이런 방식을 사용하는것이 유리하다.

정리하며

kubecost 에서 뭔가 굉장한 Logic 으로 Recommend 를 해줄꺼라고 생각했던 사람이라면 좀 실망할 수도 있을것 같다 (내가 그랬다). 결국에는 실제 CPU, Memory 사용율을 기반으로 계산하기 때문에, 만일 Pod의 자원사용율 데이터를 이미 수집하고 있고, EDA를 할수 있는 환경이 있다면 직접 분석하는 것과 큰 차이는 없을것 같다.

다만, kubecost 에는 이외에도 instance type 최적화, 미사용 PV 등 비용 최적화를 위한 다양한 기능이 있으니 비용 최적화를 위해서는 상당히 유용한 도구이고, recommend 값 자동 적용 기능도 최초 기능개발시에 잘 사용한다면 유용한 도구가 될 수 있을꺼라 생각한다.

참고

API 사용

Pod수가 많다면 GUI를 통해서 확인하는게 불편할 수 있다. API를 통해서 데이터를 추출할 수 있다.

https://docs.kubecost.com/apis/apis-overview/api-request-right-sizing-v2

 

Container Request Right Sizing Recommendation API (V2) - Kubecost Documentation

The "base" recommendation is calculated from the observed usage of each resource per unique container spec (e.g. a 2-replica, 3-container deployment will have 3 recommendations: one for each container spec).

docs.kubecost.com

Recommend 값 자동 적용

kubecost 에서는 recommend 값을 적용하는 기능도 제공하고 있다. 개발중인 Pod라면 최초에 request, limit 값을 정할때 충분히 사용해 볼만 하다.

https://docs.kubecost.com/apis/apis-overview/api-request-recommendation-apply

 

Container Request Recommendation "Apply" APIs - Kubecost Documentation

The Apply APIs only "size down," i.e. they will never increase a container requests, only lower them. This is currently done out of an abundance of caution while the APIs are being tested. We don't want to size up requests and cause a cluster that was runn

docs.kubecost.com

 

 

반응형