Kubernetes: CPU 제한을 제거하여 서비스 속도를 높입니다.

2016년으로 돌아가서, 우리는 Buffer에서 쿠버네티스로 전환, 그리고 지금은 약 60개의 노드(AWS에서)와 1500개의 컨테이너가 우리의 k8s 클러스터에서 제어 하에 실행되고 있습니다. 콥. 하지만 시행착오를 거치며 마이크로서비스로 전환했고, k8s를 사용한 지 몇 년이 지났지만 여전히 우리 스스로 새로운 문제에 직면하고 있습니다. 이 게시물에서는 다음에 대해 이야기하겠습니다. 프로세서 제한: 왜 우리가 그것들이 좋은 관행이라고 생각했는지, 그리고 왜 그것들이 그렇지 않은 것으로 판명되었는지.

프로세서 제한 및 조절

다른 많은 Kubernetes 사용자와 마찬가지로 Google에서는 프로세서 한도 구성을 적극 권장합니다.. 이러한 설정이 없으면 노드의 컨테이너가 모든 프로세서 전원을 차지할 수 있으며 이로 인해 중요한 Kubernetes 프로세스(예: kubelet)는 더 이상 요청에 응답하지 않습니다. 따라서 CPU 제한을 설정하는 것은 노드를 보호하는 좋은 방법입니다.

CPU 제한은 컨테이너가 지정된 기간 동안 사용할 수 있는 최대 CPU 시간을 지정하며(기본값은 100ms), 컨테이너는 이 제한을 초과하지 않습니다. Kubernetes에서 조절 용기에 담아 한계를 넘지 않도록 특수 도구를 사용합니다. CFS 할당량하지만 궁극적으로 이러한 인위적인 CPU 제한은 컨테이너의 성능을 저하시키고 응답 시간을 증가시킵니다.

프로세서 한도를 설정하지 않으면 어떤 일이 일어날 수 있나요?

불행히도, 우리는 스스로 이 문제에 직면해야 했습니다. 각 노드에는 컨테이너를 관리하는 프로세스가 있습니다. kubelet그리고 그는 더 이상 요청에 응답하지 않았습니다. 이런 일이 일어나면 노드는 다음 상태로 전환됩니다. NotReady그리고 해당 노드의 컨테이너는 다른 곳으로 리디렉션되어 새로운 노드에서도 동일한 문제가 발생합니다. 적어도 이상적인 시나리오는 아닙니다.

스로틀링 및 응답 문제의 표현

컨테이너 추적을 위한 핵심 지표는 다음과 같습니다. trottling컨테이너가 몇 번이나 제한되었는지 보여줍니다. 우리는 프로세서 부하가 최대치에 달했는지 여부에 관계없이 일부 컨테이너에서 속도 제한이 발생하는 것을 흥미롭게 발견했습니다. 예를 들어, 핵심 API 중 하나를 살펴보겠습니다.

아래에서 볼 수 있듯이 우리는 한계를 설정했습니다. 800m (코어의 0.8 또는 80%), 그리고 최상의 도달 범위에서의 피크 값 200m (핵심의 20%) 하지만 서비스 제한이 적용되기 전까지는 프로세서 성능이 여전히 충분한 것 같습니다.

프로세서 부하가 지정된 한도보다 훨씬 낮더라도 여전히 속도 조절이 발생하는 것을 보셨을 것입니다.

이에 직면하여 우리는 곧 여러 가지 자원을 발견했습니다.github에 문제가 있어요, 자다노에 대한 프레젠테이션, omio에 게시하다) 제한으로 인해 서비스의 성능과 응답 시간이 저하되는 현상에 대해 설명합니다.

CPU 부하가 낮을 때 속도 조절이 나타나는 이유는 무엇입니까? 간략히 말하자면, "핵심에 있어서" Linux "특정 CPU 제한이 있는 컨테이너에 대해 불필요한 스로틀링을 유발하는 버그가 있습니다." 문제의 본질에 관심이 있으시면 프레젠테이션을 확인해 보세요.비디오 и 텍스트 (변형) 데이브 칠룩의 작품입니다.

CPU 제한 제거(매우 신중하게)

오랜 논의 끝에, 우리는 사용자의 중요한 기능에 직간접적으로 영향을 미치는 모든 서비스에서 프로세서 제한을 제거하기로 결정했습니다.

우리는 클러스터의 안정성을 매우 중요하게 생각하기 때문에 이 결정은 쉽지 않았습니다. 과거에 우리는 클러스터의 불안정성을 실험한 적이 있는데, 서비스가 너무 많은 리소스를 소비하여 전체 노드의 작업 속도를 늦추었습니다. 하지만 지금은 상황이 조금 달랐습니다. 우리는 클러스터에 기대하는 바를 명확하게 이해했고, 계획된 변화를 구현하기 위한 좋은 전략도 가지고 있었습니다.

긴급한 문제에 대한 비즈니스 서신.

제한이 해제되면 노드를 어떻게 보호하나요?

"제한 없는" 서비스 분리:

과거에 우리는 이미 일부 노드가 상태에 들어가는 것을 보았습니다. notReady주로 너무 많은 리소스를 소모하는 서비스로 인해 발생합니다.

우리는 이러한 서비스를 별도의("표시된") 노드에 배치하여 "관련" 서비스를 방해하지 않도록 결정했습니다. 결국, 일부 노드에 플래그를 지정하고 "관련 없는" 서비스에 허용 매개변수를 추가함으로써 클러스터에 대한 제어력을 강화하고 노드의 문제를 더 쉽게 식별할 수 있었습니다. 비슷한 프로세스를 직접 수행하려면 다음을 읽어보세요. 선적 서류 비치.

올바른 프로세서와 메모리 요청 할당:

우리가 가장 우려했던 점은 이 프로세스가 너무 많은 리소스를 소모하여 노드가 요청에 응답하지 않게 된다는 것이었습니다. 이제 Datadog 덕분에 클러스터의 모든 서비스를 명확하게 파악할 수 있게 되었고, "관련 없음"으로 지정하려고 계획했던 몇 달간의 서비스를 분석했습니다. 저는 최대 CPU 사용량을 20% 여유로 설정했고, k8s가 노드에 다른 서비스를 할당하려고 할 경우를 대비해 노드에 공간을 할당했습니다.

그래프에서 볼 수 있듯이 프로세서의 최대 부하가 도달했습니다. 242m CPU 코어(0.242 프로세서 코어). 프로세서 요청의 경우, 이 값보다 약간 큰 숫자를 취하면 충분합니다. 본 서비스는 이용자 중심이므로, 최대 부하 값은 트래픽과 일치합니다.

메모리 사용량과 쿼리에도 같은 작업을 하면 됩니다. 그러면 설정이 완료됩니다! 보안을 강화하려면 수평적 포드 자동 확장을 추가할 수 있습니다. 이렇게 하면 리소스 부하가 높을 때마다 자동 크기 조정이 새로운 Pod를 생성하고 쿠버네티스가 이를 여유 공간이 있는 노드에 분산합니다. 클러스터 자체에 남은 공간이 없는 경우 알림을 설정하거나 자동 크기 조정을 통해 새 노드를 추가하도록 구성할 수 있습니다.

단점으로는 우리가 "에서 졌다는 점을 주목할 가치가 있습니다.컨테이너 밀도", 즉 한 노드에서 실행되는 컨테이너의 수입니다. 트래픽 밀도가 낮으면 "휴식"이 많이 필요할 수 있으며, CPU 부하가 높아질 가능성도 있지만, 노드 자동 확장을 통해 이러한 문제를 해결할 수 있습니다.

조사 결과

지난 몇 주 동안의 실험을 통해 얻은 훌륭한 결과를 발표하게 되어 기쁩니다. 이미 수정된 모든 서비스에서 반응성이 크게 향상된 것을 확인했습니다.

우리는 메인 페이지에서 가장 좋은 결과를 얻었습니다.buffer.com), 서비스가 가속화되었습니다 22번!

커널 버그가 수정되었습니까? Linux?

예 버그는 이미 수정되었고 수정 사항은 커널에 추가되었습니다. 배포판 버전 4.19 이상.

그러나 읽을 때 github의 쿠버네티스 이슈 2020년 XNUMX월 XNUMX일 우리는 여전히 그러한 언급들을 접하게 됩니다. Linux-비슷한 버그가 있는 프로젝트들. 일부 배포판에서 발생하는 문제인 것 같습니다. Linux 이 오류는 여전히 존재하며 현재 수정 작업이 진행 중입니다.

배포판 버전이 4.19 이전인 경우 최신 버전으로 업그레이드하는 것이 좋지만, CPU 제한을 해제하고 스로틀링이 지속되는지 확인해 보는 것도 좋습니다. 아래는 Kubernetes 관리 서비스의 일부 목록입니다. Linux 분포:

• Debian해당 수정 사항은 배포판의 최신 버전에 통합되었습니다. 버스터, 그리고 꽤 신선해 보입니다 (올해의 8 월 2020). 일부 이전 버전도 수정되었을 수 있습니다.
• Ubuntu: 최신 버전에 수정 사항이 통합되었습니다. Ubuntu 포컬 포사 20.04
• EKS는 또 다른 수정 사항을 획득했습니다. 올해의 12 월 2019. 귀하의 버전이 이보다 낮으면 AMI를 업데이트해야 합니다.
• 콥스: 2020년 XNUMX월부터 у kops 1.18+ 메인 호스트 이미지는 다음과 같습니다. Ubuntu 4월 20일. Kops 버전이 오래된 경우, 수정 패치가 나올 때까지 기다려야 할 가능성이 높습니다. 저희도 현재 수정 패치를 기다리고 있습니다.
• GKE(Google Cloud): 통합 수정 2020년 XNUMX월그러나 조절에 문제가 있습니다. 아직도 관찰되고 있다.

해당 수정으로 속도 조절 문제가 해결되면 어떻게 해야 하나요?

문제가 완전히 해결되었는지는 잘 모르겠습니다. 해당 문제가 해결된 커널 버전이 나오면 클러스터를 테스트하고 게시물을 업데이트하겠습니다. 이미 업데이트를 하신 분이 계시다면, 결과를 보고 싶습니다.

결론

• Docker 컨테이너를 사용하는 경우 다음 단계를 따르세요. Linux (Kubernetes, Mesos, Swarm 등 어떤 플랫폼을 사용하든) 컨테이너는 스로틀링으로 인해 성능이 저하될 수 있습니다.
• 버그가 이미 수정되었기를 바라며 배포판의 최신 버전으로 업데이트해보세요.
• 프로세서 제한을 제거하면 문제가 해결되지만, 이는 매우 위험한 기술이어서 매우 신중하게 사용해야 합니다(먼저 커널을 업데이트하고 결과를 비교하는 것이 좋습니다).
• CPU 제한을 제거한 경우 CPU 및 메모리 사용량을 주의 깊게 모니터링하고 CPU 리소스가 과도하게 소모되고 있는지 확인하세요.
• 안전한 옵션 중 하나는 하드웨어 부하가 높을 때 새로운 Pod를 생성하여 Pod의 크기를 자동으로 조정하는 것입니다. 그러면 쿠버네티스가 이를 여유 노드에 할당합니다.

이 글이 여러분의 컨테이너 시스템 성능을 개선하는 데 도움이 되기를 바랍니다.

PS 여기에 저자는 독자 및 평론가들과 영어로 서신을 주고받고 있습니다.


출처 : habr.com