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

2016년에 우리는 Buffer에 있었어 쿠버네티스로 전환현재 약 60개의 노드(AWS)와 1500개의 컨테이너가 다음에서 관리하는 k8s 클러스터에서 작동하고 있습니다. 콥. 그러나 우리는 시행착오를 거쳐 마이크로서비스로 전환했고, k8s로 수년 동안 작업한 후에도 여전히 새로운 문제에 직면해 있습니다. 이번 포스팅에서는 이에 대해 이야기해보겠습니다. 프로세서 제한: 왜 우리는 그것이 좋은 습관이라고 생각했고, 왜 그렇게 좋지 않게 되었는가?

프로세서 제한 및 조절

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

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

프로세서 제한을 설정하지 않으면 어떻게 되나요?

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

조절 및 응답 문제의 발현

컨테이너 추적의 주요 지표는 다음과 같습니다. trottling, 컨테이너가 제한된 횟수를 보여줍니다. 우리는 프로세서 부하가 극심한지 여부에 관계없이 일부 컨테이너에 제한이 있다는 사실을 흥미롭게 발견했습니다. 예를 들어, 주요 API 중 하나를 살펴보겠습니다.

아래에서 볼 수 있듯이 한도를 다음과 같이 설정했습니다. 800m (0.8 또는 80% 코어) 및 최고 도달 범위의 최고 값 200m (20% 코어). 서비스를 제한하기 전에는 여전히 프로세서 성능이 충분한 것처럼 보이지만...

프로세서 로드가 지정된 제한보다 훨씬 낮은 경우에도 제한이 여전히 발생한다는 것을 알 수 있습니다.

이에 직면하여 우리는 곧 몇 가지 리소스를 발견했습니다(github의 문제, 자다노에 대한 프리젠테이션, 오미오에 게시하다) 제한으로 인한 서비스 성능 저하 및 응답 시간에 대해 설명합니다.

낮은 CPU 로드에서 조절이 나타나는 이유는 무엇입니까? 짧은 버전은 다음과 같습니다. "지정된 프로세서 제한으로 컨테이너를 불필요하게 제한하는 버그가 Linux 커널에 있습니다." 문제의 성격에 관심이 있는 경우 프레젠테이션(비디오 и 텍스트 옵션) Dave Chiluk 작성.

CPU 제한 제거(각각의 주의)

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

우리는 클러스터의 안정성을 매우 중요하게 생각하기 때문에 결정이 쉽지 않았습니다. 과거에 우리는 이미 클러스터의 불안정성을 실험한 결과 서비스가 너무 많은 리소스를 소비하고 전체 노드의 작업 속도를 늦췄습니다. 이제 모든 것이 다소 달라졌습니다. 우리는 클러스터에서 기대하는 것이 무엇인지 명확하게 이해했으며 계획된 변경 사항을 구현하기 위한 좋은 전략도 갖고 있었습니다.

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

제한이 해제될 때 노드를 보호하는 방법은 무엇입니까?

"제한되지 않은" 서비스 격리:

과거에 우리는 이미 일부 노드가 상태에 들어가는 것을 보았습니다. notReady, 주로 너무 많은 리소스를 소비하는 서비스 때문입니다.

우리는 그러한 서비스를 "관련" 서비스를 방해하지 않도록 별도의("라벨이 붙은") 노드에 배치하기로 결정했습니다. 결과적으로, 일부 노드를 표시하고 "관련되지 않은" 서비스에 허용 오차 매개변수를 추가함으로써 클러스터에 대한 제어력이 향상되었으며 노드 문제를 식별하는 것이 더 쉬워졌습니다. 유사한 프로세스를 직접 수행하려면 다음에 익숙해질 수 있습니다. 선적 서류 비치.

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

우리의 가장 큰 두려움은 프로세스가 너무 많은 리소스를 소비하고 노드가 요청에 대한 응답을 중단한다는 것입니다. 이제(Datadog 덕분에) 클러스터의 모든 서비스를 명확하게 모니터링할 수 있었기 때문에 "관련 없음"으로 지정하려고 계획한 서비스의 몇 달 간의 운영을 분석했습니다. 저는 단순히 최대 CPU 사용량을 20%의 여유로 설정하여 k8s가 노드에 다른 서비스를 할당하려고 할 경우를 대비하여 노드에 공간을 할당했습니다.

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

메모리 사용량과 쿼리에도 동일한 작업을 수행하면 짜잔 - 모든 설정이 완료되었습니다! 보안을 강화하기 위해 수평형 포드 자동 크기 조정을 추가할 수 있습니다. 따라서 리소스 로드가 높을 때마다 자동 확장이 새 포드를 생성하고 쿠버네티스는 이를 여유 공간이 있는 노드에 배포합니다. 클러스터 자체에 남은 공간이 없는 경우 경고를 직접 설정하거나 자동 크기 조정을 통해 새 노드 추가를 구성할 수 있습니다.

마이너스 중에서 우리가 "에서 패했다는 점은 주목할 가치가 있습니다.컨테이너 밀도", 즉. 한 노드에서 실행되는 컨테이너 수 또한 낮은 트래픽 밀도에서 많은 "휴식"을 가질 수 있으며 높은 프로세서 로드에 도달할 가능성도 있지만 자동 크기 조정 노드는 후자에 도움이 될 것입니다.

조사 결과

지난 몇 주 동안의 실험을 통해 얻은 훌륭한 결과를 발표하게 되어 기쁘게 생각합니다. 수정된 모든 서비스 전반에 걸쳐 이미 상당한 개선이 이루어진 것을 확인했습니다.

우리는 홈페이지(buffer.com), 서비스가 가속화되었습니다. 스물두 번!

Linux 커널 버그가 수정되었나요?

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

그러나 읽어보면 github의 kubernetes 문제 2020년 XNUMX월 둘째주 우리는 여전히 비슷한 버그가 있는 일부 Linux 프로젝트에 대한 언급을 접합니다. 일부 Linux 배포판에는 여전히 이 버그가 있으며 이를 해결하기 위해 노력하고 있습니다.

배포 버전이 4.19보다 낮은 경우 최신 버전으로 업데이트하는 것이 좋지만 어떤 경우에도 프로세서 제한을 제거하고 제한이 지속되는지 확인해야 합니다. 아래에서 Kubernetes 관리 서비스 및 Linux 배포판의 일부 목록을 볼 수 있습니다.

• 데비안: 최신 버전의 배포판에 수정 사항이 통합되었습니다. 버스터, 상당히 신선해 보입니다(올해의 8 월 2020). 일부 이전 버전도 수정될 수 있습니다.
• Ubuntu: 최신 버전에 통합된 수정 사항 우분투 포칼 포사 20.04
• EKS는 아직 수정 사항을 가지고 있습니다 올해의 12 월 2019. 버전이 이보다 낮은 경우 AMI를 업데이트해야 합니다.
• 콥스: 2020년 XNUMX월부터 у kops 1.18+ 기본 호스트 이미지는 Ubuntu 20.04입니다. kops 버전이 오래된 경우 수정을 기다려야 할 수도 있습니다. 우리는 지금 기다리고 있습니다.
• GKE(Google Cloud): 수정사항 통합 2020년 XNUMX월그러나 제한에 문제가 있습니다. 아직도 관찰되고 있다.

수정 사항으로 인해 제한 문제가 해결된 경우 어떻게 해야 합니까?

문제가 완전히 해결되었는지는 모르겠습니다. 수정 사항이 포함된 커널 버전이 나오면 클러스터를 테스트하고 게시물을 업데이트하겠습니다. 이미 업데이트한 사람이 있다면 결과를 읽어보고 싶습니다.

결론

• Linux에서 Docker 컨테이너(Kubernetes, Mesos, Swarm 등)를 사용하여 작업하는 경우 제한으로 인해 컨테이너 성능이 저하될 수 있습니다.
• 버그가 이미 수정되었으면 좋겠습니다. 최신 버전의 배포판으로 업데이트해 보세요.
• 프로세서 제한을 제거하면 문제가 해결되지만 이는 매우 주의해서 사용해야 하는 위험한 기술입니다(먼저 커널을 업데이트하고 결과를 비교하는 것이 더 좋습니다).
• CPU 제한을 제거한 경우 CPU 및 메모리 사용량을 주의 깊게 모니터링하고 CPU 리소스가 소비량을 초과하는지 확인하십시오.
• 안전한 옵션은 하드웨어 부하가 높은 경우 포드를 자동 크기 조정하여 새 포드를 생성하여 kubernetes가 무료 노드에 할당하도록 하는 것입니다.

이 게시물이 컨테이너 시스템의 성능을 향상하는 데 도움이 되기를 바랍니다.

PS 여기에 저자는 독자 및 평론가(영어)와 연락합니다.


출처 : habr.com