구글 TS2팀 조수빈
1. 개요
Kubernetes 비용 최적화는 적절한 리소스 요청 설정의 중요성을 이해하는 것에서 시작됩니다. 요청을 잘못 관리하면 애플리케이션이 중단되어 애플리케이션의 안정성에 연쇄적으로 부정적인 영향을 미칠 수 있습니다. Kubernetes 비용 최적화의 기본 측면을 마스터하는 데 도움이 되는 실행 가능한 전략 하나를 검토해 보겠습니다.
2. Request를 제대로 설정하지 않을 경우 발생 가능한 문제
노드 압력 제거(Node-pressure eviction)는 메모리와 같은 리소스가 노드의 용량 임계값에 도달할 때 발생합니다. 이 압력 상태는 Kubernetes를 활성화하여 kubeletPod를 갑자기 종료하여 리소스 회수를 시작합니다. 포드를 죽이는 우선순위는 그들이 요청한 것과 비교하여 가장 많은 리소스를 사용하는 포드에 부여됩니다.
그러나 명시적으로 리소스를 요청하지 않는 BestEffort 포드는 특정 요구 사항이 없기 때문에 가장 먼저 종료될 가능성이 높습니다. 워크로드를 충분히 빠르게 죽일 수 없는 경우 kubelet Linux oom_killer가 개입하여 컨테이너를 죽일 수도 있습니다. 이 프로세스는 또한 부분적으로 QoS 클래스를 기반으로 우선 순위를 지정합니다.
QoS 클래스가 BestEffort인 워크로드와 QoS 클래스가 Burstable이고 메모리가 과소 프로비저닝된 워크로드가 가장 먼저 종료될 수 있습니다. OOMKilled, ContainerStatusUnknown, Error및 와 같이 이 종료와 관련될 수 있는 오류로 인해 Evicted 문제 해결이 어려울 수 있습니다.
여기에서 관찰 가능성 측정항목을 보는 것이 특히 유용할 수 있습니다. 이러한 이유로 보고서는 중요한 워크로드에 대해 요청을 적절하게 설정할 것을 권장합니다.
관찰 가능성 측정항목은 다음과 같은 GKE 클러스터의 문제를 해결하는 데 도움이 될 수 있습니다.
- CPU 또는 메모리 요청 사용률 추이가 높으면 리소스를 더 적게 사용하도록 클러스터 또는 네임스페이스에서 컨테이너를 구성해야 할 수 있습니다.
- 컨테이너의 재시작 횟수가 많으면 컨테이너가 비정상 종료되었을 수 있습니다.
- 예약할 수 없는 포드가 많으면 리소스 부족 또는 구성 오류가 발생한 것입니다.
- 높은 Cloud Logging 또는 Google Cloud Managed Service for Prometheus 수집은 Google Cloud 운영 제품군 가격과 관련이 있습니다. 수집을 줄여 비용을 절약하는 것이 좋습니다.
3. GKE Workloads at Risk dashboard
GKE Workloads at Risk dashboard를 사용하여 성능 또는 안정성 문제의 위험에 처한 BestEffort 및 Burstable 워크로드를 모니터링할 수 있습니다.
- Google Cloud Console에서 모니터링을 선택합니다.
- 탐색 창에서 대시보드를 선택합니다.
- 샘플 라이브러리 창 에서 Google Kubernetes Engine을 선택합니다.
- 대시보드 목록에서 GKE Workloads at Risk dashboard 옆에 있는 미리보기 버튼을 클릭합니다.
“Best Effort Workloads at Risk” 섹션에는 정의된 CPU 또는 메모리 요청이 없는 작업 부하가 표시됩니다. 메모리 요청이 정의되지 않은 경우 Pod는 언제든지 제거되고 실패한 것으로 표시될 수 있습니다. 마찬가지로 CPU 요청이 정의되지 않은 경우 CPU가 0으로 제한될 수 있으므로 워크로드가 응답하지 않을 수 있습니다.
이를 방지하려면 워크로드에 대한 CPU 및 메모리 요청을 정의해야 합니다. 이렇게 하면 워크로드가 제대로 실행되는 데 필요한 리소스를 확보할 수 있습니다.
“Burstable Workloads at Risk” 섹션에는 요청한 것보다 더 많은 메모리와 CPU를 사용하는 포드가 표시됩니다. 사용 가능한 메모리가 충분하지 않으면 안정성 문제가 발생할 수 있습니다. 앞서 언급한 BestEffort 포드와 같은 이러한 포드는 종료될 수 있습니다. 요청된 것보다 더 많은 CPU를 소비하는 워크로드가 제한되어 워크로드의 최종 사용자가 경험할 수 있는 성능 저하가 발생할 수 있습니다.
- 전체 플릿에서 위험에 처한 워크로드 식별
여러 프로젝트에서 여러 GKE 클러스터를 실행하는 조직을 위해 BigQuery 및 Looker Studio를 기반으로 구축된 포괄적이고 강력한 솔루션을 개발했습니다.
이 솔루션은 BigQuery의 기능을 활용하여 클러스터와 프로젝트 전반에 걸쳐 신속한 인사이트를 제공합니다. 위험에 처한 워크로드를 식별하는 동시에 권장 사항을 제공하여 기록 관점에서 진행 상황을 모니터링할 수 있습니다. 일관된 개선을 실현하기 위해 특정 요구 사항에 맞게 사용자 정의할 수도 있습니다.
- Kubernetes 클러스터가 다른 곳에서 실행 중인 경우
기본 목표는 요청이 구성되거나 구성되지 않은 방식으로 인해 위험에 처할 수 있는 워크로드를 식별하는 것입니다. 모든 Kubernetes 클러스터에서 작동하는 경량 방법을 찾고 있다면 주어진 클러스터에서 CPU, 메모리 또는 둘 다에 대한 요청 없이 모든 사용자 컨테이너를 나열하는 간단한 스크립트인 kube-requests-checker 를 평가할 수 있습니다.
다음 kubectl명령을 실행하여 개별 워크로드의 서비스 품질 클래스에 액세스할 수도 있습니다.
$ kubectl get pod $POD_NAME -o jsonpath='{ .status.qosClass}{“\n”}’