사례2건

2건 중 1~2번째

1. IL-0144 Ubuntu 18.04 의 systemd 보안 업데이트가 DNS 설정을 날려 AKS 노드의 kubelet 이 레지스트리 이름을 해석하지 못하고 파드가 ImagePullBackoff 에 빠졌다.

   Microsoft Azure2022

   증상

   2022년 8월 30일 06:00 UTC 무렵부터 Ubuntu Unattended-Upgrades 를 켜 둔 Ubuntu 18.04 VM 에서 DNS 이름 해석 오류가 나기 시작했다. AKS 에서는 kubelet 이 컨테이너 레지스트리의 DNS 이름을 해석하지 못해 ImagePullBackoff 같은 파드 생성 오류가 났다.

   DNS 조회 실패이미지 풀 실패모니터링 중단

   촉발

   2022년 8월 30일 06:00 UTC 에 Canonical 이 Ubuntu 보안 업데이트를 공개했고, Unattended-Upgrades 를 켠 Ubuntu 18.04 VM 들이 systemd 237-3ubuntu10.54 를 자동으로 내려받아 설치했다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지kubelet컨테이너 레지스트리와 자격 증명클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   단계적 배포 부재과도한 영향 범위자동화 증폭

   감지

   패키지가 공개된 직후 AKS 와 Azure Container Apps 팀을 포함한 여러 Azure 팀이 운영 알림으로 문제를 알았다. 이어 들어온 고객 지원 문의로 영향이 Ubuntu 18.04 에 한정된다는 것을 확인했다.

   조치

   • Canonical 과 Ubuntu 웹사이트에 이 버그와 수정 방법이 올라왔고, 영향받은 고객에게 읽어 보도록 권했다.
   • 영향받은 VM 은 재부팅하거나, 재부팅할 수 없으면 Azure 가 제공한 템플릿 스크립트를 시험하고 필요한 만큼 고쳐서 돌리도록 권했다.
   • AKS 팀이 AKS 노드의 문제를 자동으로 탐지하고 고치는 장치를 만들어 모든 리전에 배포했다.
   • 나머지 AKS 고객은 지원팀을 거쳐 손으로 완화했다.

   후속 조치

   • 보안 업데이트가 안전 배포 절차를 거치지 않는 지금 방식을 검토해, 이런 장애에서 고객 영향을 줄인다.
   • AKS 데이터 플레인 모니터링을 개선해 오류가 늘면 알림이 오게 했다.
   • AKS 모니터링 알고리즘을 검토해 이번과 비슷한 VM 오류를 탐지하고 알리게 했다.
   • 장애 중 Canonical 로 가는 에스컬레이션 경로를 개선하고 내부 기술 서비스 가이드에 넣었다.
   • AKS 가 지금 Canonical 과 나눠 맡는 보안 패치 체계를 완전히 넘겨받아, 패치를 직접 추가로 시험하고 통제해서 배포한다. 2022년 12월 완료 예정이다.
   • IaaS VM 용으로는 Canonical 과 협의해, Azure 사용자에게 공개되기 전의 후보 패키지에 전용 시험을 돌린다.
   • AKS 가 Canonical 과 절차를 세워 업그레이드 상황의 시험 공백을 메운다. 2023년 3월 완료 예정이다.
   • 안전하다고 판단해 내보내는 패치는 AKS 고객이 유지보수 시간대를 직접 정하고 환경별로 나눠 적용할 수 있게 한다. 2023년 12월 완료 예정이다.

   교훈

   보안 업데이트는 중요도 때문에 안전 배포 절차를 거치지 않았고, 하루 한 번 자동으로 적용되는 업데이트가 모든 리전의 VM 에 퍼졌다. AKS 고객은 자동 노드 이미지 업그레이드를 쓰면 노드를 최신으로 유지하면서 Microsoft 의 공급망만 쓰게 된다. IaaS VM 은 자동 VM 게스트 패치를 쓰면 Ubuntu 패치를 받는 VM 의 범위가 제한되고 업데이트가 조율된 순서로 적용된다. 자동 VM 게스트 패치는 상태 감시도 하며, 사용자는 앱 상태 확장으로 애플리케이션 상태 신호를 줄 수 있다.

   사례 보기
2. 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 차트의 자원 한도에 기본값이 없었다. 운영 도구와 고객 워크로드가 자원을 나눠 썼고, 손으로 한 배포를 팀이 몰랐고, 스모크 테스트가 없었고, 운영 지식이 일부에게만 있었다. 이렇게 배우려면 장애 건수나 해결 시간만 보지 않고 비난 없는 포스트모템을 허용하는 문화가 필요하다.

   사례 보기

원인별2