Scaling Kube State Metrics

Ellie Huxtable

Kube State Metrics 스케일링

클러스터 규모가 커지면 스크레이프에 시간이 걸리기 시작한다는 것을 알게 될 수 있습니다 — 보유한 노드/파드 수 등에 따라 kube state metrics가 수백만 개의 샘플을 노출할 수도 있기 때문입니다!

KSM은 샤딩을 자동으로도, 수동으로도 지원합니다. 안타깝게도 자동 샤딩은 아직 개발이 한창 진행 중입니다

자동 샤딩을 사용하면 StatefulSet으로 배포했을 때 각 샤드가 자신의 명목상 위치를 스스로 파악할 수 있어 샤딩을 자동으로 구성하는 데 유용합니다. 이 기능은 실험적인 기능이며 예고 없이 오작동하거나 제거될 수 있습니다.

그렇다면 수동으로 샤딩할 수도 있습니다! 하지만 이 방법도 그다지 훌륭하지는 않습니다. 같은 리소스를 스크레이프하는 파드가 여러 개 있더라도 각 파드가 여전히 모든 데이터를 가져와야 하기 때문입니다. 파드 하나가 x만큼의 데이터를 가져오던 상황에서 n개의 파드가 각각 x만큼의 데이터를 가져오게 되는 셈입니다. 즉, 해당 샤드에 필요한 데이터만 전송한다면 n * x/n만큼만 전송하면 될 것을 총 n * x만큼의 네트워크 전송이 발생하게 됩니다. 여전히 이상적이지는 않습니다.

각 샤드는 해당 오브젝트를 kube-state-metrics의 해당 인스턴스에서 처리할지 여부를 결정합니다. 이는 샤딩을 하더라도 모든 kube-state-metrics 인스턴스가 자신이 담당하는 오브젝트뿐만 아니라 모든 오브젝트에 대해 오브젝트를 언마샬링하는 데 필요한 네트워크 트래픽과 리소스 소모를 그대로 감당해야 한다는 의미입니다.

지금까지 제가 내린 결론은 데이터 타입별로 샤딩하는 것입니다. 파드가 가장 많은 샘플을 노출하는 경향이 있으므로 파드부터 분리하는 것이 합리적입니다. 그래서 파드 메트릭을 노출하는 디플로이먼트 하나와 나머지 모든 메트릭을 담당하는 디플로이먼트 하나로 나누었습니다.

이 방식은 다른 곳에서도 이미 사용된 방식으로 보이며, 지금으로서는 잘 동작하고 있습니다

원문은 Ellie Huxtable님이 에 게재했습니다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.