사례43건

43건 중 36~40번째

1. IL-0008 응답하지 않는 OPA 검증 웹훅 때문에 GKE 마스터 업그레이드가 멈추고 API 서버가 간헐적으로 끊기면서 노드가 끝없이 재생성됐다

   Jetstack2019

   증상

   Jetstack 은 europe-west1 에 있는 GKE 리전 클러스터의 마스터를 업그레이드하고 있었다. 이 개발 클러스터는 여러 팀이 낮 동안 앱을 시험하는 데 쓴다. GKE Terraform 파이프라인으로 업그레이드를 시작했는데, 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않았다. GKE 콘솔에는 클러스터가 여전히 업그레이드 중으로 나왔다.

   업그레이드 정체컨트롤 플레인 무응답노드 재생성 반복서비스 중단

   촉발

   마스터 업그레이드 중 두 번째 마스터 인스턴스의 API 서버가 ca-registration PostStartHook 을 실행하면서 kube-system 의 extension-apiserver-authentication ConfigMap 을 갱신하려 했다. 이 요청은 설정해 둔 OPA 검증 웹훅의 백엔드가 응답하지 않아 타임아웃 났다.

   원인

   설정 변경

   구성 요소

   어드미션 웹훅GKE 컨트롤 플레인쿠버네티스 API 서버kubelet

   기여 요인

   과도한 영향 범위헬스 프로브 부재모니터링 사각지대자동화 증폭

   감지

   GKE Terraform 파이프라인으로 시작한 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않은 것이 첫 신호였다. 파이프라인을 다시 돌리자 kube-apiserver 가 unhealthy 라는 오류가 났다. 원인은 Google Support 의 도움을 받아 찾았다.

   조치

   • API 서버에 간헐적으로 접근될 때를 이용해 OPA 의 ValidatingAdmissionWebhook 리소스를 지워 클러스터를 복구했다.

   후속 조치

   • OPA 의 ValidatingAdmissionWebhook 이 정책이 적용되고 개발 팀이 접근하는 네임스페이스만 보도록 범위를 좁혔다.
   • 웹훅을 정책이 실제로 검증하는 Ingress 와 Service 리소스에만 켰다.
   • OPA 가 응답하지 않으면 재시작되도록 liveness probe 를 더하고 문서를 고쳤다.
   • 이 동작을 개선하자는 쿠버네티스 업스트림 이슈가 아직 열려 있어, 그 진행을 지켜본다.

   교훈

   API 서버 응답 시간에 알림을 걸어 두었다면, OPA 웹훅을 처음 배포한 뒤 모든 CREATE 와 UPDATE 요청의 응답 시간이 늘어난 것을 알아챘을 수도 있다. 모든 워크로드에 프로브를 설정하는 것이 중요하다. 팀은 OPA 배포가 너무 간단해 보여서 Helm 차트를 쓰지 않았는데, 그 차트에는 어드미션 컨트롤러 컨테이너의 livenessProbe 를 포함해 튜토리얼 기본 설정에 없는 조정이 여럿 들어 있었다. 노드 자동 복구를 끄는 것도 검토했지만 끄지 않기로 했다. 같은 문제를 겪은 것은 Jetstack 이 처음이 아니며, 관련 업스트림 이슈는 아직 열려 있다.

   사례 보기
2. IL-0052 인증 없이 인터넷에 열린 Weave Scope 대시보드를 통해 암호화폐 채굴기가 개발 클러스터와 스테이징 클러스터의 모든 노드에서 돌았다.

   JW Player2019

   증상

   Datadog 이 스테이징 환경의 정규화한 load average 가 높다고 경보를 보냈다. 팀은 원인을 정상 서비스 하나의 부하 증가로 판단했고, 정상 동작으로 여겼다.

   노드 CPU 고부하무단 접근과 낯선 워크로드

   촉발

   Weave Scope 를 배포할 때 쿠버네티스가 로드 밸런서에 0.0.0.0/0 에서 80 포트로 들어오는 접근을 허용하는 보안 그룹을 연결했다. 팀은 AWS 콘솔에서 이 보안 그룹을 손으로 고쳐 허용 목록 밖의 트래픽을 막았지만, 쿠버네티스가 얼마 뒤 이 수정을 되돌렸다. 그 결과 Weave Scope 대시보드가 인증 없이 인터넷에 열렸고, 자동화된 크롤러가 이를 찾아냈다.

   원인

   설정 변경

   구성 요소

   클러스터 대시보드클라우드 로드 밸런서

   기여 요인

   초기 신호 무시기본 설정 방치과도한 영향 범위모니터링 사각지대

   감지

   Datadog 이 정규화한 load average 경보를 0일 차 21:06 EST 에 스테이징에서, 1일 차 16:53 EST 에 개발 환경에서 보냈다. 팀은 정상 서비스의 부하로 보고 경보를 뮤트했다. 3일 차 17:40 EST 에 부하 증가가 나흘째 이어지자 엔지니어가 노드에 SSH 로 들어가 top 으로 CPU 를 100% 쓰는 gcc 프로세스를 찾았다.

   조치

   • Weave Scope 를 멈추고 모든 쿠버네티스 클러스터에서 그 배포를 지웠다.
   • 인스턴스에 무단 접근한 흔적이 있는지 접근 로그를 확인했다.
   • gcc 프로세스의 외부 연결을 조사해 마이닝 풀과만 통신한다는 것을 확인했다.
   • 영향을 받은 노드 하나를 나중에 조사하려고 클러스터에서 격리했다.
   • 모든 클러스터의 노드를 전부 새로 만들어 교체하고 감염을 모두 없앴다.

   후속 조치

   • 모든 쿠버네티스 설정 파일과 사내 배포 YAML, 보안 그룹을 감사해 의도치 않게 외부에 열린 서비스나 잘못된 설정이 없는지 확인했다.
   • load 대신 더 의미 있는 모니터를 정하고, 작업량이 늘 때 경보가 쏟아지지 않고 실제 이상을 가려내도록 다듬는다.
   • falcon 이나 sysdig 같은 도구로 행위 모니터링과 이상 탐지, 침입 탐지를 할 수 있는지 검토한다.
   • Istio 나 Linkerd 로 종단 간 네트워크 트래픽을 파악하고 통제해 무단 접근을 막는 방안을 검토한다.
   • Docker 이미지와 컨테이너에서 알려진 취약점을 검사하는 데 드는 계산 비용을 따져 본다.
   • 아키텍처 논의 시간 일부를 떼어 컨테이너를 root 로 돌리는 것처럼 예전에 내린 결정을 다시 검토하기로 했다.
   • 일부 팀원에게만 있던 정보를 팀 전체와 나눠, 대규모 쿠버네티스 버전 업그레이드 같은 큰 프로젝트를 모든 엔지니어가 볼 수 있게 한다.

   교훈

   load 기반 모니터링은 클러스터의 이상을 가려내는 좋은 지표가 아니었다. 정상 서비스가 낸 경보 소음이 침입 신호를 가렸다. 쿠버네티스가 관리하는 리소스를 손으로 고치면 쿠버네티스가 그 변경을 되돌린다. 로드 밸런서를 내부용으로 정의하거나 보안 그룹 규칙을 쿠버네티스 YAML 에 넣었어야 했다. 인증 없는 내부 대시보드, --privileged 와 root 로 도는 컨테이너, 호스트 파일 시스템 마운트가 겹치면 열린 로드 밸런서 하나로 모든 노드에서 코드가 실행될 수 있다. 컨테이너를 root 로 돌리는 것처럼 예전 인프라에서 물려받은 결정은 다시 검토해야 한다.

   사례 보기
3. IL-0035 ElastAlert 에 새로 넣은 알림 규칙 때문에 ElastAlert 파드가 메모리를 끝없이 써서 노드가 잇달아 NotReady 가 되었고, 같은 클러스터의 도구와 Grafana, Prometheus 가 함께 흔들렸다.

   NU.nl2019

   증상

   팀은 여러 서비스가 이상하게 동작한다는 보고를 받았다. 가끔 오류 페이지가 뜨고, 응답이 느리고, 타임아웃이 났다.

   노드 NotReady오류율 상승지연 시간 증가간헐적 타임아웃모니터링 중단OOMKilled

   촉발

   장애 직전에 팀원 한 명이 ElastAlert 에 새 알림 규칙을 명령줄로 배포했다. Cloudfront-* 인덱스에 일정 시간 새 문서가 들어오지 않으면 울리는 규칙이었다.

   원인

   설정 변경

   구성 요소

   컨테이너 메모리 한도kubeletPrometheus

   기여 요인

   리소스 요청과 한도 미설정기본 설정 방치한계 경보 부재모니터링 사각지대과도한 영향 범위

   감지

   여러 서비스에서 오류 페이지, 느린 응답, 타임아웃이 난다는 보고가 팀에 들어왔다. 알림은 하나도 울리지 않았다. 팀은 Prometheus 와 Grafana 가 안정적인 노드로 옮겨 간 뒤 파드 메모리 사용량 대시보드에서 원인을 찾았다.

   조치

   • NotReady 노드를 하나씩 종료해 오토스케일링 그룹이 새 노드를 띄우게 했다. 새 노드도 곧 NotReady 가 되어 이것만으로는 풀리지 않았다.
   • Prometheus 와 Grafana 가 안정적인 노드에 다시 스케줄된 뒤 파드 메모리 대시보드를 보고 ElastAlert 파드가 원인임을 찾아냈다.
   • 원인인 ElastAlert 문제를 고쳤다.

   후속 조치

   • CPU, 메모리, 디스크 공간 같은 자원 사용량에 알림 규칙을 정의한다.
   • 여러 출처를 함께 쓰는 알림 전략을 계속 연구한다. 지금은 Elasticsearch, 아직 설정하지 않은 Prometheus alertmanager, APM 용 New Relic 이 있다.
   • 지표를 클러스터 밖으로 내보내고 Grafana 도 클러스터 밖으로 옮기는 방안을 검토한다. 옮길 곳은 EC2 나 별도 쿠버네티스 클러스터가 될 수 있다.
   • 중요한 지표를 ELK 에서 시각화하거나 Prometheus 와 Grafana 의 가용성을 높인다. 지표 전략도 개선한다.
   • ElastAlert 의 자원 한도를 Helm values 로 지정한다.
   • 네임스페이스에 메모리 요청값의 기본값과 한도를 설정한다.
   • 고객 대면 워크로드를 빌드, 로깅, 모니터링 워크로드와 떼어 놓는다. 먼저 운영 클러스터 안의 전용 노드 그룹으로 옮기고, 경험에 따라 별도 도구 클러스터도 검토한다.
   • 모든 배포를 Jenkins 파이프라인 같은 자동화로 하고, 새 버전 배포에 GitOps 방식을 검토한다.
   • 배포 뒤 스모크 테스트 단계가 있는 파이프라인으로 배포한다.
   • 쿠버네티스와 클라우드 인프라 작업을 팀 스프린트에 넣어 모든 팀원이 경험 많은 팀원과 짝을 지어 맡게 하고, 주제별 심화 워크숍을 연다.

   교훈

   근본 원인 하나만 탓하는 포스트모템은 장애로 이어진 문제의 15% 정도만 다룬다. 이번에도 ElastAlert 를 고친 것은 일부일 뿐이었다. 알림이 없었고, 모니터링이 같은 클러스터 안에 있었고, Helm 차트의 자원 한도에 기본값이 없었다. 운영 도구와 고객 워크로드가 자원을 나눠 썼고, 손으로 한 배포를 팀이 몰랐고, 스모크 테스트가 없었고, 운영 지식이 일부에게만 있었다. 이렇게 배우려면 장애 건수나 해결 시간만 보지 않고 비난 없는 포스트모템을 허용하는 문화가 필요하다.

   사례 보기
4. IL-0075 클러스터가 EC2 인스턴스 약 290대로 커지자 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하면서 API 서버가 CPU 와 메모리를 다 써 쿠버네티스 컨트롤 플레인을 쓸 수 없게 됐다.

   Civis Analytics2019

   증상

   스크립트 실행 기반을 쿠버네티스로 옮긴 Croquet 를 사내에 공개한 뒤, 개발자들은 kubectl 명령이 느리다고 했다. 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다.

   컨트롤 플레인 지연컨트롤 플레인 무응답지연 시간 증가오류율 상승DNS 조회 실패

   촉발

   자체 인프라 Bocce 에서 쿠버네티스로 옮긴 스크립트 실행 기반 Croquet 를 2018년 9월 사내에 공개했다. 대량의 스크립트가 몰리면서 클러스터가 EC2 인스턴스 약 290대로 커졌고, 노드마다 도는 Datadog 에이전트가 쿠버네티스 API 를 폴링하는 부하도 함께 늘었다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버텔레메트리 에이전트etcd

   기여 요인

   한계 미인지미검증 가정모니터링 사각지대용량 계획 부재

   감지

   개발자들이 kubectl 명령이 느리다고 했고, 사용자들은 노트북과 서비스가 가끔 시작되지 않는다고 알렸다. 마스터 노드의 CPU 사용률이 높았고, 조사해 보니 API 서버 컨테이너 세 개가 CPU 를 꽉 채워 쓰고 있었다. 당시 팀이 볼 수 있던 지표는 마스터 노드 CPU 의 CloudWatch 지표와 Datadog 의 컨테이너별 CPU, 메모리 지표였다. API 요청 처리량과 5xx 오류율과 요청 지연은 볼 수 없었다.

   조치

   • 사내 사용자들을 예전 인프라로 되돌려 클러스터를 안정시켰다.
   • 마스터 노드를 m4.large 세 대에서 m4.4xlarge 세 대로 키웠다.
   • 노드마다 도는 Datadog 에이전트가 서비스 메타데이터를 얻으려고 API 서버를 폴링하지 않도록 Datadog 설정을 바꿨다.
   • 상태를 바꾸지 않는 요청의 max-requests-inflight 한도를 400 에서 1200 으로 올렸다.
   • etcd 의 EBS 볼륨을 20 GB 에서 100 GB 로 늘려 IOPS 를 100 에서 300 으로 올렸다.
   • 스크립트의 DNS 정책을 ClusterFirst 에서 Default 로 바꿔 DNS 타임아웃을 줄였다.

   후속 조치

   • Kops 가 안전한 이전을 지원하면 etcd 를 2.2.1 에서 3.x 로 올린다.
   • 스크립트가 클러스터 안의 다른 워크로드와 통신할 수 있도록 DNS 타임아웃 문제를 근본적으로 해결한다.

   교훈

   가장 큰 실수는 쿠버네티스가 모든 것을 알아서 해 준다고 가정한 것이었다. 쿠버네티스는 노드 5,000대와 파드 100,000개를 지원한다고 하지만, 그 규모에 이르려면 손봐야 할 설정이 많다. 클러스터에 넣는 서드파티 도구, 특히 DaemonSet 을 조심해야 한다. 많은 도구가 보통 규모에 맞춰 만들어졌고 큰 규모에서는 시험되지 않았다. 클러스터 상태를 watch 하는 서비스가 데이터를 지나치게 많이 가져가도록 설계되면 규모 문제가 생긴다. kube2iam 은 모든 파드의 메타데이터를 메모리에 들고 있다가 메모리가 바닥났고, Fluentd Kubernetes Metadata Filter 플러그인도 같은 문제가 있다. 대개 설정 하나로 고칠 수 있지만, 부하 테스트를 해 보기 전에는 잘 드러나지 않는다.

   사례 보기
5. IL-0001 CoreDNS 파드가 메모리 한도 100Mi 에 걸려 OOM 으로 계속 죽으면서 쿠버네티스 클러스터 전체의 DNS 가 멈췄다

   Zalando2019

   증상

   Zalando Fashion Store 의 모든 웹 상품 페이지와 코디 페이지가 한 시간 넘게 고객에게 오류를 많이 냈다. 오류는 쿠버네티스 클러스터 하나에서 도는 핵심 데이터 집계 계층 서비스에서 나왔다.

   오류율 상승DNS 조회 실패OOMKilled모니터링 중단

   촉발

   그리 중요하지 않은 하위 서비스 하나로 가는 호출이 타임아웃 나기 시작했다. 집계 계층이 이 호출에 404 로 응답하자 클라이언트가 재시도했고, 집계 계층으로 가는 요청과 그만큼의 DNS 쿼리가 갑자기 치솟았다.

   원인

   용량 한계

   구성 요소

   CoreDNS컨테이너 메모리 한도클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   한계 미인지캐시 부재재시도 폭주기본 설정 방치과도한 영향 범위모니터링 사각지대

   감지

   DNS 장애로 클러스터 내부 모니터링이 함께 멈춰 당직 호출이 자동으로 가지 않았다. 집계 계층 서비스 당직 엔지니어가 평소처럼 자동 호출에 기대지 못하고 쿠버네티스 담당 당직 엔지니어에게 직접 전화했다. 그래서 쿠버네티스 당직 엔지니어가 장애를 알기까지 예상보다 오래 걸렸다. 연락을 받은 엔지니어가 CoreDNS 파드가 OOM 으로 죽고 있는 것을 찾아냈다.

   조치

   • 쿠버네티스 당직 엔지니어가 CoreDNS 파드의 메모리 request 와 limit 을 100Mi 에서 2000Mi 로 직접 올렸다.

   후속 조치

   • 노드마다 dnsmasq 를 앞에 둔 CoreDNS 를 띄우는 방식으로 더 튼튼한 DNS 구성을 도입한다. 검토하고 시험한 다른 어떤 구성보다 이 방식의 성능이 좋았다.
   • 클러스터 바깥에서 클러스터 전체 상태를 보는 알림을 강화한다. 팀은 클러스터 안 애플리케이션이 영향을 받기 전에, 늦어도 같은 시점에는 클러스터 이상을 알아야 한다.
   • 장애 대응 절차와 도구를 개선한다. 자동 당직 호출이 실패해도 당직 엔지니어가 다른 도구로 옮겨 가지 않고 다른 팀에 바로 에스컬레이션할 수 있게 한다. 채팅 봇으로 에스컬레이션을 단순하게 만드는 방안을 추진하고 있다.

   교훈

   쿠버네티스 DNS 구성은 충분히 튼튼하지 않았다. 애플리케이션 하나가 DNS 를 사실상 서비스 거부 공격하듯 몰아붙여 클러스터 전체를 멈추게 할 수 있어서는 안 된다. DNS 쿼리를 늘린 애플리케이션의 영향 범위는 적어도 노드 하나, 가능하면 파드 하나 안에 갇혀야 한다. 팀은 conntrack 을 처리하는 리눅스 커널의 경쟁 상태나 ndots 5 문제 같은 쿠버네티스 DNS 문제를 대부분 알고 있었고, 일부는 완화책도 갖고 있었다. 하지만 이 문제들이 DNS 구성에 얼마나 크게 영향을 주는지는 제대로 알지 못했다. 모니터링도 충분히 튼튼하지 않았다. 일부 알림은 클러스터 밖에서 돌았지만 대부분은 클러스터 안에서 돌았다. 그래서 DNS 가 무너졌을 때 당직 엔지니어가 자동으로 호출되지 않았고 복구 시간이 필요 이상으로 길어졌다.

   사례 보기

원인별9