Kubernetes 클러스터 리소스 모니터링

저는 Prometheus 수출업체인 Kube Eagle을 만들었습니다. 중소 규모 클러스터의 자원을 더 잘 이해하는 데 도움이 되는 멋진 일이었습니다. 결국 올바른 머신 유형을 선택하고 워크로드에 대한 애플리케이션 리소스 제한을 구성했기 때문에 수백 달러를 절약했습니다.

장점을 알려드릴게요 큐브 이글, 하지만 먼저 소란을 일으킨 원인과 고품질 모니터링이 필요한 이유를 설명하겠습니다.

저는 4~50개 노드로 구성된 여러 클러스터를 관리했습니다. 각 클러스터에는 최대 200개의 마이크로서비스와 애플리케이션이 포함됩니다. 기존 하드웨어를 더 잘 활용하기 위해 대부분의 배포는 버스트 가능한 RAM 및 CPU 리소스로 구성되었습니다. 이렇게 하면 포드는 필요한 경우 사용 가능한 리소스를 사용할 수 있으며 동시에 이 노드의 다른 애플리케이션을 방해하지 않습니다. 글쎄요, 좋지 않나요?

클러스터가 상대적으로 적은 CPU(8%)와 RAM(40%)을 소비했음에도 불구하고 포드가 노드에서 사용 가능한 것보다 더 많은 메모리를 할당하려고 하면 포드가 선점되는 문제가 지속적으로 발생했습니다. 당시에는 Kubernetes 리소스를 모니터링하기 위한 대시보드가 ​​하나뿐이었습니다. 이와 같이:

cAdvisor 측정항목만 포함된 Grafana 대시보드

이런 패널을 사용하면 메모리와 CPU를 많이 먹는 노드를 보는 것은 문제가 되지 않습니다. 문제는 그 이유가 무엇인지 알아내는 것이다. Pod를 제자리에 유지하려면 물론 모든 Pod에 보장된 리소스를 설정할 수 있습니다(요청된 리소스가 한도와 동일함). 그러나 이것이 하드웨어를 가장 현명하게 사용하는 것은 아닙니다. 클러스터에는 수백 기가바이트의 메모리가 있었지만 일부 노드는 부족하고 다른 노드에는 4~10GB의 예비 메모리가 남아 있었습니다.

Kubernetes 스케줄러는 사용 가능한 리소스 전체에 워크로드를 고르지 않게 분산한 것으로 나타났습니다. Kubernetes 스케줄러는 선호도, 오염 및 허용 규칙, 사용 가능한 노드를 제한할 수 있는 노드 선택기 등 다양한 구성을 고려합니다. 그런데 제 경우에는 그런 게 없었고, 각 노드에서 요청한 리소스에 따라 포드를 계획했습니다.

사용 가능한 리소스가 가장 많고 요청 조건을 만족하는 노드가 Pod로 선택되었습니다. 우리는 노드에서 요청한 리소스가 실제 사용량과 일치하지 않는다는 것을 발견했으며, Kube Eagle과 리소스 모니터링 기능이 이를 해결했습니다.

거의 모든 Kubernetes 클러스터를 다음으로만 모니터링했습니다. 노드 내보내기 и Kube 주 측정항목. 노드 내보내기는 I/O와 디스크, CPU, RAM 사용량에 대한 통계를 제공하고, Kube State Metrics는 요청, CPU, 메모리 리소스 제한과 같은 Kubernetes 객체 측정항목을 표시합니다.

Grafana의 요청 및 제한 지표와 사용량 지표를 결합해야 문제에 대한 모든 정보를 얻을 수 있습니다. 간단해 보이지만 두 도구는 실제로 라벨 이름을 다르게 지정하며 일부 측정항목에는 메타데이터 라벨이 전혀 없습니다. Kube Eagle은 모든 작업을 자체적으로 수행하며 패널은 다음과 같습니다.

Kube Eagle 대시보드

우리는 자원과 관련된 많은 문제를 해결하고 장비를 절약했습니다.

1. 일부 개발자는 마이크로서비스에 얼마나 많은 리소스가 필요한지 몰랐습니다(또는 단순히 신경 쓰지 않았습니다). 리소스에 대한 잘못된 요청을 찾을 수 있는 방법이 없었습니다. 이를 위해서는 소비와 요청 및 한도를 알아야 합니다. 이제 그들은 Prometheus 지표를 보고, 실제 사용량을 모니터링하고, 요청과 한도를 조정합니다.
2. JVM 애플리케이션은 처리할 수 있는 만큼의 RAM을 사용합니다. 가비지 수집기는 75% 이상 사용될 때만 메모리를 해제합니다. 그리고 대부분의 서비스에는 버스트 가능한 메모리가 있으므로 항상 JVM이 이를 점유했습니다. 따라서 이러한 모든 Java 서비스는 예상보다 훨씬 많은 RAM을 소모했습니다.
3. 일부 애플리케이션은 너무 많은 메모리를 요청했으며 Kubernetes 스케줄러는 실제로 다른 노드보다 더 자유로운 노드에도 불구하고 이러한 노드를 다른 애플리케이션에 제공하지 않았습니다. 한 개발자는 실수로 요청에 숫자 하나를 더 추가하여 20GB 대신 2GB라는 큰 RAM을 확보했습니다. 아무도 눈치채지 못했습니다. 애플리케이션에는 3개의 복제본이 있으므로 최대 3개의 노드가 영향을 받았습니다.
4. 리소스 제한을 도입하고 올바른 요청으로 포드 일정을 변경했으며 모든 노드에서 하드웨어 사용량의 이상적인 균형을 얻었습니다. 두 개의 노드가 완전히 닫혔을 수도 있습니다. 그리고 나서 우리는 잘못된 머신(메모리 지향이 아닌 CPU 지향)을 가지고 있다는 것을 알게 되었습니다. 유형을 변경하고 노드를 몇 개 더 삭제했습니다.

결과

클러스터에 버스트 가능한 리소스를 사용하면 사용 가능한 하드웨어를 더 효율적으로 사용할 수 있지만 Kubernetes 스케줄러는 리소스 요청에 따라 Pod를 예약하므로 이는 문제가 됩니다. 일석이조를 이루려면 문제를 피하고 자원을 최대한 활용하려면 좋은 모니터링이 필요합니다. 그렇기 때문에 유용할 것입니다. 큐브 이글 (Prometheus 내보내기 및 Grafana 대시보드).

출처 : habr.com