Kubernetes의 DNS 문제. 공개 사후 조사

메모 번역: 이것은 회사 엔지니어링 블로그의 공개 사후 분석을 번역한 것입니다. 준비. Kubernetes 클러스터의 conntrack 문제를 설명합니다. 이로 인해 일부 프로덕션 서비스가 부분적으로 가동 중지됩니다.

이 문서는 사후 분석에 대해 좀 더 자세히 알아보고 싶거나 향후 발생할 수 있는 일부 DNS 문제를 예방하려는 사람들에게 유용할 수 있습니다.

이것은 DNS가 아닙니다
DNS가 될 수 없습니다
DNS였군요

Preply의 사후 분석 및 프로세스에 대해 간략하게 설명

사후 조사는 오작동이나 생산 과정의 일부 이벤트를 설명합니다. 사후 분석에는 이벤트 타임라인, 사용자 영향, 근본 원인, 취한 조치 및 학습한 교훈이 포함됩니다.

SRE 구함

매주 피자와의 미팅에서는 기술팀 간 다양한 정보를 공유합니다. 이러한 회의에서 가장 중요한 부분 중 하나는 사후 분석으로, 슬라이드가 포함된 프레젠테이션과 사건에 대한 보다 심층적인 분석이 동반되는 경우가 가장 많습니다. 사후에 박수를 치지는 않더라도 "무죄" 문화를 발전시키려고 노력합니다(흠 없는 문화). 우리는 사후 분석을 작성하고 발표하는 것이 우리(및 다른 사람들)가 향후 유사한 사건을 예방하는 데 도움이 될 수 있다고 믿으며, 이것이 바로 우리가 이를 공유하는 이유입니다.

사건에 연루된 개인은 처벌이나 보복을 두려워하지 않고 자세히 말할 수 있다고 느껴야 합니다. 비난하지 마세요! 사후 분석을 작성하는 것은 처벌이 아니라 회사 전체를 위한 학습 기회입니다.

CALMS 및 DevOps 유지: S는 공유를 의미합니다.

Kubernetes의 DNS 문제. 검시

Дата : 28.02.2020

저자 : Amet U., 안드레이 S., 이고르 K., 알렉세이 P.

제목 : 완성된

간단히 : Kubernetes 클러스터의 일부 서비스에 대한 부분적 DNS 사용 불가(26분)

영향: 서비스 A, B, C에 대해 15000개의 이벤트 손실

근본 원인: Kube-proxy가 conntrack 테이블에서 이전 항목을 올바르게 제거하지 못하여 일부 서비스가 여전히 존재하지 않는 Pod에 연결을 시도하고 있었습니다.

E0228 20:13:53.795782       1 proxier.go:610] Failed to delete kube-system/kube-dns:dns endpoint connections, error: error deleting conntrack entries for UDP peer {100.64.0.10, 100.110.33.231}, error: conntrack command returned: ...

방아쇠: Kubernetes 클러스터 내부의 낮은 로드로 인해 CoreDNS-autoscaler는 배포의 Pod 수를 XNUMX개에서 XNUMX개로 줄였습니다.

솔루션 : 애플리케이션의 다음 배포에서는 새 노드 생성이 시작되었고, CoreDNS-autoscaler는 클러스터를 제공하기 위해 더 많은 포드를 추가했으며 이로 인해 conntrack 테이블이 다시 작성되었습니다.

발각: Prometheus 모니터링은 서비스 A, B, C에 대해 다수의 5xx 오류를 감지하고 담당 엔지니어에게 전화를 걸었습니다.

Kibana의 5xx 오류

활동

Действие
유형
책임감있는
태스크

CoreDNS에 대한 자동 크기 조정 비활성화
예방하다
아메트 U.
DEVOPS-695

캐싱 DNS 서버 설정
감소하다
맥스 V.
DEVOPS-665

conntrack 모니터링 설정
예방하다
아메트 U.
DEVOPS-674

교훈

잘 된 점:

• 모니터링이 잘 되더군요. 응답이 빠르고 체계적이었습니다.
• 노드 제한에 도달하지 않았습니다.

무엇이 잘못되었나요?

• 실제 근본 원인은 아직 알려지지 않았습니다. 특정 버그 콘트랙에서
• 모든 조치는 근본 원인(버그)이 아닌 결과만 수정합니다.
• 조만간 DNS에 문제가 발생할 수 있다는 것을 알고 있었지만 작업의 우선순위를 정하지 않았습니다.

우리가 운이 좋았던 곳:

• 다음 배포는 conntrack 테이블을 덮어쓴 CoreDNS-autoscaler에 의해 트리거되었습니다.
• 이 버그는 일부 서비스에만 영향을 미쳤습니다.

타임라인(EET)

시간
Действие

22:13
CoreDNS-autoscaler는 포드 수를 XNUMX개에서 XNUMX개로 줄였습니다.

22:18
근무 중인 엔지니어들이 모니터링 시스템으로부터 전화를 받기 시작했습니다.

22:21
근무중인 엔지니어들은 오류의 원인을 찾기 시작했습니다.

22:39
담당 엔지니어가 최신 서비스 중 하나를 이전 버전으로 롤백하기 시작했습니다.

22:40
5xx 오류가 더 이상 나타나지 않고 상황이 안정화되었습니다.

• 탐지 시간: 4 분
• 행동 전 시간: 21 분
• 수정 시간: 1 분

추가 정보

• CoreDNS 로그:

  I0228 20:13:53.507780       1 event.go:221] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"kube-system", Name:"coredns", UID:"2493eb55-3dc0-11ea-b3a2-02bb48f8c230", APIVersion:"apps/v1", ResourceVersion:"132690686", FieldPath:""}): type: 'Normal' reason: 'ScalingReplicaSet' Scaled down replica set coredns-6cbb6646c9 to 2

• Kibana(컷), Grafana(컷)에 대한 링크
• Linux conntrack이 더 이상 친구가 아닌 곳
• kube-proxy 미묘함: 간헐적인 연결 재설정 디버깅
• Racy conntrack 및 DNS 조회 시간 초과

CPU 사용량을 최소화하기 위해 Linux 커널은 conntrack이라는 것을 사용합니다. 간단히 말해서 이것은 특수 테이블에 저장된 NAT 레코드 목록을 포함하는 유틸리티입니다. 다음 패킷이 이전과 동일한 Pod에서 동일한 Pod로 도착하면 최종 IP 주소는 다시 계산되지 않고 conntrack 테이블에서 가져옵니다.

conntrack 작동 방식

결과

이것은 몇 가지 유용한 링크가 포함된 사후 분석 중 하나의 예입니다. 특히 이 기사에서는 다른 회사에 유용할 수 있는 정보를 공유합니다. 그렇기 때문에 우리는 실수하는 것을 두려워하지 않으며 사후 분석 중 하나를 공개합니다. 다음은 좀 더 흥미로운 공개 사후 분석입니다.

• GitLab : 31월 XNUMX일 데이터베이스 중단에 대한 사후 분석
• 보관 용 : 사후 점검
• Spotify : Spotify와 DNS의 애증 관계
• 그 외 다수 이 요점 및 저장소 Kubernetes 실패 사례
• 또한 예 SRE Book을 사용한 공개 사후 분석

출처 : habr.com