Kubernetes 클러스터 장애에서 얻은 경험 극대화

This article was originally written for my personal blog

몇 달 동안 우리(NU.nl 개발팀)는 소량의 Kubernetes 집단을 운영했다.우리는 Kubernetes의 잠재력과 우리의 생산력을 어떻게 향상시키는지, 그리고 우리의 CI/CD 실천을 어떻게 개선하는지 보았다.현재, 우리는 Kubernetes에서 일부 로그 기록과 구축 도구 모음을 실행하고, 고객을 위한 소형 (내부) 작업 부하를 추가하며, 지식과 자신감을 쌓은 후에 더 많은 응용 프로그램을 그곳으로 옮길 계획이다.
최근에 우리 팀은 그 중의 한 집단에서 몇 가지 문제에 부딪혔다.집단을 완전히 닫는 것만큼 심각하지는 않지만, 내부에서 사용하는 도구와 계기판의 사용자 체험에 틀림없이 영향을 줄 것이다.
공교롭게도 같은 시간에 뮌헨의 DevOpsCon 2018을 참관했습니다. 개막식 기조연설 "Staying Alive: Patterns for Failure Management from the Bottom of the Ocean"은 이 사건과 매우 관련이 있습니다.
이번 강연(트위터 엔지니어링 매니저 주재)은 DevOps 팀을 더욱 효과적으로 고장을 예방하고 처리하는 여러 가지 방법을 집중적으로 논의했다.토론의 주제 중 하나는 재난이 일반적으로 일련의 고장으로 인해 어떻게 발생하는지이기 때문에 다음과 같이 설명한다.

A post-mortem that blames an incident only on the root cause, might only cover ~15% of the issues that led up to the incident.

this list of postmortem templates과 같이 그 중 상당수는 근본 원인(복수)을 포함하고 있다.그러나 이벤트 체인은 무시되기 쉽다. 특히 많은 상황에서 근본적인 원인을 없애거나 복원하면 문제를 없앨 수 있다.
그렇다면 어떤 일련의 실패가 우리의 사건을 초래했는지 살펴보고 우리의 경험과 교훈을 최대한 활용하자.

이벤트

우리 팀은 간혹 오류 페이지, 응답이 느리고 시간을 초과하는 서비스가 불안정하다는 보고를 많이 받았다.
그라파나를 통해 조사를 시도했을 때, 우리는 그라파나와 프로메테우스에 영향을 미치는 유사한 행위를 겪었다.콘솔에서 클러스터 확인 결과:

$: kubectl get nodes
NAME                                          STATUS     ROLES     AGE       VERSION
ip-10-150-34-78.eu-west-1.compute.internal    Ready      master    43d       v1.10.6
ip-10-150-35-189.eu-west-1.compute.internal   Ready      node      2h        v1.10.6
ip-10-150-36-156.eu-west-1.compute.internal   Ready      node      2h        v1.10.6
ip-10-150-37-179.eu-west-1.compute.internal   NotReady   node      2h        v1.10.6
ip-10-150-37-37.eu-west-1.compute.internal    Ready      master    43d       v1.10.6
ip-10-150-38-190.eu-west-1.compute.internal   Ready      node      4h        v1.10.6
ip-10-150-39-21.eu-west-1.compute.internal    NotReady   node      2h        v1.10.6
ip-10-150-39-64.eu-west-1.compute.internal    Ready      master    43d       v1.10.6

노드 NotReady, 좋지 않습니다.다양한 노드 설명 (불건전한 노드만 있는 것이 아님) 표시:

$: kubectl describe node ip-10-150-36-156.eu-west-1.compute.internal

<truncated>

Events:
  Type     Reason                   Age                From                                                     Message
  ----     ------                   ----               ----                                                     -------
  Normal   Starting                 36m                kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Starting kubelet.
  Normal   NodeHasSufficientDisk    36m (x2 over 36m)  kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeHasSufficientDisk
  Normal   NodeHasSufficientMemory  36m (x2 over 36m)  kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeHasSufficientMemory
  Normal   NodeHasNoDiskPressure    36m (x2 over 36m)  kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeHasNoDiskPressure
  Normal   NodeHasSufficientPID     36m                kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeHasSufficientPID
  Normal   NodeNotReady             36m                kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeNotReady
  Warning  SystemOOM                36m (x4 over 36m)  kubelet, ip-10-150-36-156.eu-west-1.compute.internal     System OOM encountered
  Normal   NodeAllocatableEnforced  36m                kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Updated Node Allocatable limit across pods
  Normal   Starting                 36m                kube-proxy, ip-10-150-36-156.eu-west-1.compute.internal  Starting kube-proxy.
  Normal   NodeReady                36m                kubelet, ip-10-150-36-156.eu-west-1.compute.internal     Node ip-10-150-36-156.eu-west-1.compute.internal status is now: NodeReady

kubelet이 메모리를 회수할 수 있기 전에 노드의 운영체제가 프로세스를 종료하고 있는 것 같습니다.
우리 집단의 노드는 자동 축소 그룹의 일부분이다.따라서 우리가 간헐적으로 중단되어 당시 그라파나에 도착할 수 없었던 것을 감안하여 NotReady개의 노드를 하나씩 중지하고 새로운 노드가 안정을 유지할 수 있는지 살펴보기로 했다.상황이 그렇지 않다. 새로운 노드가 정확하게 나타나지만 일부 기존 노드나 새로운 노드는 곧 상태 NotReady에 들어간다.
그러나 이로 인해 프로메테우스와 그라파나는 안정적인 노드에 배치되었다. 따라서 적어도 우리는 더 많은 데이터를 분석해야 한다. 근본적인 원인은 곧 뚜렷해진다.

Kubernetes 파일에서 설명 근본 원인

Grafana 설정에서 은 그룹 범위 내의 총수와pod 메모리와 cpu 사용률을 보여 줍니다.이것은 곧 우리 문제의 근원을 설명하였다.
One of the dashboards
갈 곳이 없는 노선들은 모두 을 운행하는 기중기들이다.로그에 대해 우리는 Elasticsearch 집단을 실행했습니다. 최근에 우리는 로그 기반 경보를 촉발하기 위해 ElastAlert를 사용해 왔습니다.사건 발생 얼마 전에 도입된 경보는 Cloudfront-* 인덱스가 일정 기간 동안 새 문서를 받지 못하면 경보를 보낸다는 것이다.Cloudfront 배포의 처리량이 시간당 수백만 개의 요청이기 때문에 메모리 사용량이 크게 증가한 것은 분명하다.사후에 보면 ElastAlert, 우리는 use_count_query과/또는 max_query_size을 사용하는 것이 가장 좋다.

문서를 깊이 파고들다 종속 연결 장애

그래서 근본 원인을 확정하고 조사하고 복원했다.사건이 끝났죠?앞의 인용문과 85%의 지식을 발견해야 한다는 것을 기억하고 깊이 있게 연구합시다.

경고가 실행되지 않음

분명히 우리는 경보를 진행하고 있다. 왜냐하면 근본적인 원인이 ElastAlert와 관련이 있기 때문이다.로그 메시지 (키워드의 등장) 나 Kubernetes 그룹 이외의 시스템과 같이 처리할 데이터 (현재) 는 Elasticsearch에서만 사용할 수 있습니다.프로메테우스는 또 하나의 alert 관리자가 있는데, 우리는 그것을 설정해야 한다.이 두 소스 외에도 APM을 위해 New Relic을 사용하고 있습니다.출처가 어떻든지 간에 최소한 경보 규칙을 정의하는 것부터 시작해야 할 수도 있다.
해상도:

은 CPU, 메모리, 디스크 공간 등 자원 사용과 관련된 경고를 정의합니다.

은 여러 출처를 효과적으로 결합시킬 수 있는 경보 전략을 계속 연구한다.

클러스터링 문제에 따른 Grafana 대시보드

프로메테우스(Prometheus)와 그라파나(Grafana)는 쿠버니터스(Kubernetes) 집단에 설치하기 쉽다.그러나 만약 네가 너의 집단에 도달하지 못한다면, 너는 장님이다.
해상도:

은 도량을 집단 밖으로 내보내고 Grafana를 집단 밖으로 옮기는 것을 고려한다. 은 잘 설명되었지만 결점이 없는 것은 아니다.하나의 장점은 여러 개의 집단된 계기판에 단일한 연결점을 제공하는 것이다.내가 알기로는 in this article at robustperception.io은 유사한 설정을 사용하여 여러 집단을 감시한다.

클러스터 위치는 EC2일 수도 있지만 별도의 Kubernetes 클러스터일 수도 있습니다.

쿠블러 우리 큰뿔 사슴 더미에서 완전히 이익을 얻지 못했다

대량의 Cloudfront 로그를 흡수하는 EC2 기반 ELK 스택을 실행하고 있습니다.Filebeat와metricbeat 수호 프로그램에서 내보낸 Kubernetes 집단의 로그와 지표도 포함됩니다.따라서 집단 내 Grafana를 통해 접근할 수 없는 데이터도 큰 뿔 사슴 창고에 존재한다...그러나 정확하게 보지 못했거나 무시당했다.
이것은 통상적으로 약간 까다로운 문제이다. 한편, Elasticsearch는 어떻게든 집중식 로그에 사용할 수 있고 도량을 할 수 있기 때문에 원스톱 해결 방안일 수 있다.그러나 규모상, 이것은 상당히 다루기 어려운 문제이며, 더 많은 예시 대시보드 (imo) 는 당신이 로그인하는 것을 진정으로 도울 수 있습니다.
다른 한편, 프로메테우스의 설정은 매우 간단하다. 마치 쿠버네트스 생태계의 기본 기술인 것 같고, 게다가 그라파나가 사용할 수 있는 계기판도 있어서 쉽게 들어갈 수 있다.
해상도:

은 ELK의 중요한 지표를 가시화하거나 프로메테우스/그라파나의 가용성을 높인다.

도량 정책 개선.

ElastAlert 크레인에는 CPU 및 메모리 제한이 없습니다.

ElastAlert 의 Helm 차트를 설치하는 데 사용되지만 이 차트에는 기본값이 없으며 이 값은 무시됩니다.
자원 제한을 강제로 설정하기 위해서 우리는 allows specifying resource requests and limits을 사용할 수 있다.
해상도:

은 Helm 값을 통해 리소스 제한을 지정합니다.

은 메모리 요청이 있는 기본 en 제한으로 이름 공간을 설정합니다.

이름공간에 기본 및 제한 메모리 요청 구성 고객 워크로드에 영향을 주는 Ops 서비스

같은 그룹의 자원을 공유하는 고객의 작업 부하와 감시/로그 기록 도구는 모든 자원의 확대 효과를 소모할 위험이 있다.트래픽 증가, CPU/메모리 압력 증가, 로깅/도량 증가, CPU/메모리 압력 증가 등.
우리는 모든 로그 기록, 감시, CI/CD 도구를 생산 집단 내의 전용 노드 그룹으로 옮길 계획이다.우리의 경험에 따르면, 전용 도구 집단을 가지는 것도 하나의 선택이다.
솔루션(예정):

은 고객을 대상으로 하는 작업 부하와 구축, 로그 기록과 모니터링 작업 부하를 분리합니다.

배포된 ElastAlert 변경 사항을 팀 내에서 인식하지 못했습니다.

새 경보가 코드 심사를 통과했지만 모두가 통합되고 배치되었다는 것을 아는 것은 아니다.더 중요한 것은 팀원 한 명이 명령행을 통해 설치했기 때문에 그룹에서 어떤 응용 프로그램이 업데이트되었는지 직접적인 정보원이 나타나지 않는다는 것이다.
해상도:

은 자동화를 통해 모든 것을 배치합니다(예를 들어 Jenkins 파이프라인).

은 개발자가 잘 알고 있는 도구를 사용하여 새로운 응용 프로그램 버전을 배치하는 방법인'상태'와 코드 변경 역사를 고려합니다.

지토프 무연무 테스트

만약 우리가 파이프를 사용하여 ElastAlert 업데이트를 배치한다면, 배치 후에 연기 테스트 절차를 추가할 수 있습니다.이것은 메모리를 너무 많이 사용하거나pod가 설정된 메모리 제한을 초과하여pod를 다시 시작하는 것을 나타낼 수 있습니다.
해상도:

은 스모그 테스트 절차를 포함한 파이프 배치를 통과했다.

Kubernetes의 운영 지식은 팀의 일부로 제한됩니다.

우리 팀(대다수 팀과 마찬가지)은 서로 다른 주제에서 서로 다른 전문 수준을 가진 인원으로 구성된다.어떤 사람들은 더 많은 Cloud & DevOps 경험을 가지고 있고, 어떤 사람들은 전단이나 Django 전문가 등등이다. 왜냐하면 Kubernetes는 매우 새로운 기술이기 때문이다. 물론 우리 팀에게 지식은 기대만큼 광범위하지 않다.민첩한 팀이 실천하는 모든 기술과 마찬가지로: DevOps는 한 팀(팀의 일부)에 국한되어서는 안 된다.다행히도 경험이 풍부한 팀원들은 인프라 경험이 거의 없는 대기 팀원들을 도울 수 있다.
솔루션(예정):

은 Kubernetes 관련 업무(실제로 클라우드 인프라 시설과 관련)가 팀 스퍼트의 일부임을 확보하고 모든 팀 구성원이 책임지며 경험이 있는 구성원과 짝짓기를 한다.

세미나에서 일부 주제를 깊이 있게 토론하다.

총결산

분명히 Elast Alert 문제를 해결하는 것 자체가 빙산의 일각일 뿐이다.간단해 보이는 이 사건에서 우리는 더 많은 것을 배울 수 있다.본고에서 열거한 대다수의 관점은 이미 어떤 방식으로 우리의 레이더에 등장했지만, 그것들의 중요성을 강조하였다.
이러한 경험을scrum(또는 판자) 프로젝트로 전환하면 우리는 집중적인 방식으로 우리의 플랫폼과 실천을 개선하고 우리의 진전을 평가할 수 있다.
단체로서 학습과 향상은'사후에 비난할 수 없는'회사 문화를 허용하고'사건 수량'이나'해결 시간'에 주목하지 않아야 한다.견적 으로 종료:

Success consists of going from failure to failure without loss of enthusiasm - Winston Churchill