사례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-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 가 무너졌을 때 당직 엔지니어가 자동으로 호출되지 않았고 복구 시간이 필요 이상으로 길어졌다.

   사례 보기

원인별2