Kubernetes의 Pod 우선순위가 Grafana Labs의 가동 중지 시간을 초래한 방법

메모. 번역: Grafana 제작자가 유지 관리하는 클라우드 서비스의 최근 다운타임 이유에 대한 기술적인 세부 사항을 알려드립니다. 이는 인프라의 품질을 향상시키기 위해 설계된 새롭고 매우 유용해 보이는 기능이 생산 현실에서 해당 응용 프로그램의 수많은 뉘앙스를 제공하지 않으면 해를 끼칠 수 있다는 전형적인 예입니다. 실수로부터뿐만 아니라 배울 수 있는 이와 같은 자료가 나타나면 정말 좋습니다. 자세한 내용은 Grafana Labs 제품 담당 부사장의 이 텍스트 번역에 나와 있습니다.

19월 30일 금요일에 Grafana Cloud의 호스팅된 Prometheus 서비스가 약 XNUMX분 동안 작동을 중지했습니다. 서비스 중단으로 인해 피해를 입은 모든 고객에게 사과드립니다. 우리의 임무는 귀하에게 필요한 모니터링 도구를 제공하는 것이며, 이러한 도구가 없으면 귀하의 삶이 더 어려워질 수 있다는 것을 이해합니다. 우리는 이번 사건을 매우 심각하게 받아들입니다. 이 메모에는 무슨 일이 일어났는지, 어떻게 대응했는지, 그리고 이런 일이 다시 발생하지 않도록 하기 위해 무엇을 하고 있는지 설명되어 있습니다.

선사 시대

Grafana Cloud Hosted Prometheus 서비스는 다음을 기반으로 합니다. 피질 — 수평 확장이 가능하고 가용성이 높은 다중 테넌트 Prometheus 서비스를 만들기 위한 CNCF 프로젝트입니다. Cortex 아키텍처는 복제, 저장, 쿼리 등 자체 기능을 수행하는 개별 마이크로서비스 세트로 구성됩니다. Cortex는 활발히 개발 중이며 지속적으로 새로운 기능을 추가하고 성능을 향상시키고 있습니다. 고객이 이러한 기능을 활용할 수 있도록 정기적으로 새로운 Cortex 릴리스를 클러스터에 배포합니다. 다행스럽게도 Cortex는 가동 중지 시간 없이 업데이트될 수 있습니다.

원활한 업데이트를 위해 Ingester Cortex 서비스에는 업데이트 프로세스 중에 추가 Ingester 복제본이 필요합니다. (메모. 번역: 섭취기 - Cortex의 기본 구성 요소입니다. 그 임무는 샘플의 지속적인 스트림을 수집하고 이를 Prometheus 청크로 그룹화하여 DynamoDB, BigTable 또는 Cassandra와 같은 데이터베이스에 저장하는 것입니다.) 이를 통해 기존 Ingester가 현재 데이터를 새 Ingester로 전달할 수 있습니다. Ingester에는 리소스가 많이 필요하다는 점은 주목할 가치가 있습니다. 작동하려면 포드당 4개의 코어와 15GB의 메모리가 필요합니다. Kubernetes 클러스터의 경우 기본 머신 처리 능력 및 메모리의 25%. 일반적으로 클러스터에는 일반적으로 4개 코어와 15GB 메모리보다 사용되지 않는 리소스가 훨씬 더 많기 때문에 업그레이드 중에 이러한 추가 수집기를 쉽게 가동할 수 있습니다.

그러나 정상 작동 중에 어떤 시스템도 사용되지 않은 리소스의 25%를 보유하지 못하는 경우가 종종 있습니다. 예, 우리는 노력조차 하지 않습니다. CPU와 메모리는 항상 다른 프로세스에 유용할 것입니다. 이 문제를 해결하기 위해 우리는 다음을 사용하기로 결정했습니다. Kubernetes 포드 우선순위. Ingester에게 다른 (상태 비저장) 마이크로서비스보다 더 높은 우선순위를 부여하는 것이 아이디어입니다. 추가(N+1) Ingester를 실행해야 할 경우 일시적으로 다른 작은 포드를 대체합니다. 이러한 포드는 다른 시스템의 무료 리소스로 전송되어 추가 Ingester를 실행할 수 있을 만큼 충분히 큰 "구멍"을 남깁니다.

18월 XNUMX일 목요일에 우리는 클러스터에 XNUMX가지 새로운 우선순위 수준을 출시했습니다. 위독한, 키가 큰, 매체 и 낮은. 약 XNUMX주일 동안 클라이언트 트래픽이 없는 내부 클러스터에서 테스트되었습니다. 기본적으로 지정된 우선순위가 없는 Pod는 수신됩니다. 매체 우선순위, 클래스는 Ingesters에 대해 설정되었습니다. 높음 우선 사항. 위독한 모니터링용으로 예약되었습니다(Prometheus, Alertmanager, node-exporter, kube-state-metrics 등). 우리의 구성이 열려 있으며 PR을 볼 수 있습니다 여기에.

충돌

19월 XNUMX일 금요일에 엔지니어 중 한 명이 대규모 클라이언트를 위한 새로운 전용 Cortex 클러스터를 출시했습니다. 이 클러스터의 구성에는 새 포드 우선순위가 포함되지 않았으므로 모든 새 포드에 기본 우선순위가 할당되었습니다. 매체.

Kubernetes 클러스터에는 새 Cortex 클러스터를 위한 리소스가 충분하지 않았으며 기존 프로덕션 Cortex 클러스터가 업데이트되지 않았습니다. высокого 우선 사항). 기본적으로 새 클러스터의 수집기는 매체 우선순위가 있고 프로덕션의 기존 포드가 전혀 우선순위 없이 작동한 경우 새 클러스터의 Ingester가 기존 Cortex 프로덕션 클러스터의 Ingester를 대체했습니다.

프로덕션 클러스터의 제거된 Ingester에 대한 ReplicaSet는 제거된 Pod를 감지하고 지정된 복사본 수를 유지하기 위해 새 Pod를 생성했습니다. 새 포드가 기본적으로 할당되었습니다. 매체 우선순위가 낮고 프로덕션에 있는 또 다른 "오래된" Ingester가 리소스를 잃었습니다. 결과는 눈사태 과정이로 인해 Cortex 프로덕션 클러스터용 Ingester에서 모든 포드가 대체되었습니다.

수집기는 상태를 저장하며 지난 12시간 동안의 데이터를 저장합니다. 이를 통해 장기 저장소에 쓰기 전에 보다 효율적으로 압축할 수 있습니다. 이를 달성하기 위해 Cortex는 DHT(분산 해시 테이블)를 사용하여 시리즈 전체에 걸쳐 데이터를 분할하고 Dynamo 스타일 쿼럼 일관성을 사용하여 세 개의 수집기에 걸쳐 각 시리즈를 복제합니다. Cortex는 비활성화된 Ingester에 데이터를 쓰지 않습니다. 따라서 많은 수의 Ingester가 DHT를 떠나면 Cortex는 항목의 충분한 복제를 제공할 수 없으며 충돌이 발생합니다.

탐지 및 치료

"오류 예산"을 기반으로 한 새로운 Prometheus 알림(오류 예산 기반 — 자세한 내용은 향후 기사에 표시됩니다.) 셧다운이 시작된 지 4분 후에 경보가 울리기 시작했습니다. 다음 XNUMX분 정도에 걸쳐 몇 가지 진단을 실행하고 기본 Kubernetes 클러스터를 확장하여 신규 및 기존 프로덕션 클러스터를 모두 호스팅했습니다.

XNUMX분 후에 기존 Ingester가 데이터를 성공적으로 기록하고 새 Ingester가 시작되었으며 Cortex 클러스터를 다시 사용할 수 있게 되었습니다.

Cortex 앞에 위치한 인증 역방향 프록시의 메모리 부족(OOM) 오류를 진단하고 수정하는 데 추가로 10분이 소요되었습니다. OOM 오류는 QPS의 XNUMX배 증가로 인해 발생했습니다(클라이언트 Prometheus 서버의 지나치게 공격적인 요청으로 인해 발생한 것으로 생각됩니다).

여파

총 다운타임은 26분이었습니다. 데이터가 손실되지 않았습니다. 수집기가 모든 메모리 내 데이터를 장기 스토리지에 성공적으로 로드했습니다. 종료 중에 버퍼링된 클라이언트 Prometheus 서버가 삭제되었습니다. (떨어져서) 다음을 사용하여 녹음 새로운 API 원격_쓰기 WAL 기반(작성자: 칼럼 스티안 Grafana Labs에서) 충돌 후 실패한 쓰기를 반복했습니다.

프로덕션 클러스터 쓰기 작업

조사 결과

이번 사건을 통해 교훈을 얻고 재발을 방지하기 위해 필요한 조치를 취하는 것이 중요합니다.

돌이켜보면 우리는 기본값을 설정하지 말았어야 했습니다. 매체 생산 중인 모든 Ingester가 수신될 때까지 우선순위 키가 큰 우선 순위. 또한, 사전에 관리가 필요했습니다. 높은 우선 사항. 이제 모든 것이 해결되었습니다. 우리의 경험이 Kubernetes에서 포드 우선 순위 사용을 고려하는 다른 조직에 도움이 되기를 바랍니다.

구성이 클러스터 전체에 걸쳐 있는 추가 개체의 배포에 대한 제어 수준을 추가할 것입니다. 이제부터 이러한 변경 사항은 평가됩니다.о더 많은 사람. 또한 충돌을 일으킨 수정 사항은 별도의 프로젝트 문서에 비해 너무 사소한 것으로 간주되어 GitHub 문제에서만 논의되었습니다. 이제부터 구성에 대한 모든 변경 사항에는 적절한 프로젝트 문서가 수반됩니다.

마지막으로, 우리가 목격한 과부하 OOM을 방지하기 위해 인증 역방향 프록시의 크기 조정을 자동화하고, 폴백 및 확장과 관련된 Prometheus 기본 설정을 검토하여 향후 유사한 문제를 방지할 것입니다.

이 실패는 또한 몇 가지 긍정적인 결과를 가져왔습니다. 필요한 리소스를 받은 Cortex는 추가 개입 없이 자동으로 복구되었습니다. 우리는 또한 함께 일하면서 귀중한 경험을 얻었습니다. 그라파나 로키 - 새로운 로그 집계 시스템 - 모든 Ingester가 장애 발생 도중 및 장애 이후에 올바르게 작동하도록 보장합니다.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes의 자동 크기 조정 및 리소스 관리(개요 및 동영상 보고서)";
• «Kubernetes 모험 Dailymotion: 클라우드 + 온프레미스에서 인프라 구축";
• «Tinder가 Kubernetes로 전환";
• «프로덕션 분야의 Kubernetes 성공 사례. 파트 10: 레딧".

출처 : habr.com