사례23건

23건 중 8~12번째

1. IL-0153 DOKS 1.27.6-do.0 과 1.28.2-do.0 워커 노드에서 매일 아침 도는 apt 자동 업그레이드가 15분 타임아웃에 걸려 강제 종료되면서 노드 네트워킹이 망가지고, 노드가 사흘 연속 NotReady 가 됐다.

   DigitalOcean2023

   증상

   2023년 10월 8일 06:00 UTC 무렵부터 일부 Managed Kubernetes 클러스터의 워커 노드가 NotReady 가 됐고, 그 노드에서 돌던 서비스와 애플리케이션이 멈췄다. 07:43부터 노드를 교체하면 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다.

   노드 NotReady서비스 중단

   촉발

   DigitalOcean Debian 이미지의 systemd 타이머가 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다.

   원인

   설정 변경

   구성 요소

   노드 운영체제 이미지리눅스 커널kubelet

   기여 요인

   기본 설정 방치디버그 접근 제한늦게 드러난 변경

   감지

   10월 8일 07:43 UTC부터 노드 교체로 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다. 장애가 시작되고 약 1시간 43분 뒤였다. 내부 장애 대응은 영향이 여러 리전으로 번진 뒤인 10월 9일 07:10에 시작됐다.

   조치

   • 고객에게 영향받은 머신을 교체하거나 재부팅해 장애를 줄이라고 안내했다.
   • 장애가 없는 동안 워커 노드에 SSH 와 콘솔 접근을 마련했고, 10월 10일 영향받은 노드에 붙어 실시간으로 디버깅했다.
   • 각 워커 노드에서 apt 업그레이드 systemd 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08 UTC에 영향받은 모든 클러스터에 배포했다.
   • 자동 업그레이드 과정을 없앤 새 노드 이미지를 배포했다.

   후속 조치

   • 노드 프로비저닝 과정에서 같은 수정을 적용해 워커 노드에 타이머가 처음부터 켜지지 않게 한다. 그 뒤 모든 클러스터에서 DaemonSet 을 지운다.
   • 새 클러스터 버전마다 도는 내부 적합성 테스트에 자동 업그레이드와 원하지 않는 다른 타이머가 꺼져 있는지 확인하는 검사를 넣었다.
   • 평소 쓰는 접근 경로가 막혀도 워커 노드 머신에 로그인할 수 있게 한다.

   교훈

   베이스 이미지에 기본으로 켜진 자동 업그레이드 타이머가 운영 중인 노드에 지원하지 않는 패키지 버전을 들일 수 있다. 업그레이드 중 커널 같은 시스템 패키지가 타임아웃으로 강제 종료되면 노드 네트워킹이 망가질 수 있다. 네트워크가 끊긴 노드에 들어갈 방법이 없으면 깊은 조사는 장애가 없는 시간까지 밀린다. 매일 같은 시각에 반복되고 특정 버전에만 나는 장애는 노드에서 주기적으로 도는 작업을 가리켰다.

   사례 보기
2. IL-0016 네임스페이스와 규칙이 늘어 live 클러스터의 Prometheus 가 메모리 부족으로 OOMKilled 되며 플랫폼 모니터링이 끊겼다

   UK Ministry of Justice2023

   증상

   2023-07-25 14:05 PagerDuty 로 Pingdom 의 고우선순위 경보가 왔다. Prometheus - live 헬스 체크가 DOWN 이었다. 팀이 Prometheus 서버를 확인하니 규칙 평가 오류가 나 있었고 서버는 Exit code 137 로 종료돼 있었다.

   모니터링 중단OOMKilled노드 NotReady

   촉발

   네임스페이스와 Prometheus 규칙 수가 늘어 Prometheus 서버가 쓰는 메모리가 늘었고, 기존 인스턴스 크기로는 Prometheus 를 계속 띄울 수 없었다.

   원인

   용량 한계

   구성 요소

   Prometheus노드 풀컨테이너 메모리 한도

   기여 요인

   한계 경보 부재

   감지

   14:05 Pingdom 이 Prometheus - live 헬스 체크가 DOWN 인 것을 감지해 PagerDuty 로 고우선순위 경보를 보냈다. 장애 선언은 15:21 에 했다.

   조치

   • 14:22 모니터링 노드를 드레인해 Prometheus 를 다른 모니터링 노드로 옮겼다.
   • 15:31 노드 인스턴스 크기를 CPU 와 메모리가 두 배인 r6i.4xlarge 로 바꿨다.
   • 15:50 Prometheus 컨테이너의 메모리 limit 을 100Gi 로 올렸다.
   • 16:18 Prometheus 컨테이너 limit 을 CPU 12코어, 메모리 110Gi 로 바꿨다.

   후속 조치

   • 노드 메모리 사용량을 감시하고, 파드 하나가 노드 메모리 대부분을 쓰는 상황을 잡아내는 경보를 추가한다. 이 일은 이슈 #4538 에서 다룬다.

   사례 보기
3. IL-0185 Kubespray 로 만든 클러스터의 첫 번째 control plane 노드 디스크가 I/O 오류로 읽기 전용이 되면서 노드가 죽었다

   Hans H. Kim2023

   증상

   Kubernetes 클러스터의 master 노드에서 디스크 장애가 났다. 커널 로그에 "[HAWKEYE] kernel:: [22329228.540857] blk_update_request: I/O error, dev sda, sector 795030104 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0, at" 오류가 찍혔다.

   노드 NotReady

   촉발

   하드웨어 장애로 master 1번 노드의 sda 디스크에 I/O 오류가 나고 읽기 전용 상태가 됐다.

   원인

   하드웨어 고장

   구성 요소

   Kubesprayetcd노드 루트 디스크컨피그맵과 시크릿

   기여 요인

   단일 장애점

   감지

   커널 로그에 sda 디스크의 blk_update_request I/O 오류가 찍히면서 디스크 장애를 알았다.

   조치

   • Kubespray inventory 의 kube_control_plane 순서를 바꿔 node-2 가 첫 번째 control plane 노드가 되게 했다.
   • 하드웨어 장애가 난 1번 장비를 클러스터에서 제거했다.
   • kubectl edit cm -n kube-public cluster-info 로 cluster-info ConfigMap 의 옛 control plane IP 를 살아 있는 장비의 IP 로 바꾸고 certificate-authority-data 값도 바꿨다.
   • 새 노드에 kubelet 을 비롯한 컴포넌트를 설치하고 kubeadm join --control-plane --skip-phases control-plane-join/etcd 로 control plane 노드를 추가했다.
   • etcd 노드를 따로 추가했다.

   교훈

   Kubespray 는 첫 번째 control plane 노드에 특별한 권한을 주기 때문에, master 세 대로 HA 를 구성해도 1번 노드의 장애 복구는 매우 까다롭다. 복구하려면 inventory 순서를 바꿔 1번 역할부터 다른 노드로 넘겨야 한다. control plane 노드가 죽으면 etcd 쿼럼이 위험해지므로 다른 노드가 더 망가지기 전에 etcd 를 되살려야 한다.

   사례 보기
4. IL-0198 systemd 보안 패치가 Ubuntu 22.04 노드의 systemd-networkd 를 재시작해 Cilium 이 넣은 IP 규칙을 지웠고, 여러 리전과 세 클라우드의 Kubernetes 노드가 한꺼번에 네트워크를 잃었다.

   Datadog2023

   증상

   2023년 3월 8일 06:00 에서 07:00 UTC 사이에 여러 리전과 여러 클라우드의 Kubernetes 노드가 한꺼번에 네트워크 연결을 잃었다. Datadog 의 모든 서비스가 영향을 받았고, CI/CD 와 자동화 도구가 있는 리전도 함께 끊겼다.

   노드 NotReady서비스 중단처리량 저하

   촉발

   2023년 3월 7일 Ubuntu 저장소에 systemd 의 CVE 패치 249.11-0ubuntu3.7 이 올라왔다. 3월 8일 06:00 에서 07:00 UTC 사이에 Ubuntu 기본값 그대로 둔 무인 업그레이드가 이 패치를 설치했고, systemd-networkd 가 재시작되면서 자신이 모르는 IP 규칙을 모두 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   systemd-networkdCilium노드 운영체제 이미지

   기여 요인

   기본 설정 방치늦게 드러난 변경단계적 배포 부재자동화 증폭

   조치

   • Google Cloud 와 Azure 에서 네트워크만 잃고 실행 중이던 인스턴스 수천 대를 클라우드 API 로 재시작해 로컬 디스크의 데이터와 함께 복구했다.
   • AWS 에서 교체되면서 로컬 디스크를 잃은 데이터 저장소는 데이터를 다시 만들거나, 다시 처리하거나, 백업에서 복원해 되살렸다.

   교훈

   기본값 그대로 둔 OS 무인 보안 업데이트는 단계적 배포 절차를 거치지 않고 모든 리전과 클라우드에 같은 시각에 변경을 적용한다. systemd-networkd 의 새 동작은 22.04 도입 때부터 있었지만 systemd-networkd 가 재시작될 때만 나타나서 몇 달 동안 보이지 않았다. CNI 가 호스트의 IP 규칙에 기대고 있으면, 그 규칙을 지우는 다른 구성 요소 하나가 노드 네트워크 전체를 끊는다. 클라우드마다 네트워크를 잃은 인스턴스를 다루는 방식이 다르고, 로컬 디스크에 데이터를 두는 서비스에서는 자동 교체가 오히려 복구를 늦춘다.

   사례 보기
5. IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다

   DFDS2022

   증상

   2022-10-31 13:45 UTC 에 팀은 계획된 vpc-cni EKS 애드온 업그레이드를 배포 파이프라인으로 시작했다. 14:10 에 파이프라인이 업그레이드 중 타임아웃으로 실패했다. 45개 aws-node 파드 가운데 약 10개만 업그레이드됐다. 5개는 Terminating 에 멈췄고, 나머지 30개는 업그레이드를 시도하지도 못했다.

   노드 NotReady업그레이드 정체간헐적 타임아웃간헐적 연결 실패

   촉발

   매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.

   원인

   소프트웨어 결함

   구성 요소

   노드 운영체제 이미지리눅스 커널kubeletAWS VPC CNI노드 런치 템플릿Terraform

   기여 요인

   단계적 배포 부재자동화 증폭장애 중첩모니터링 사각지대헬스 프로브 부재

   감지

   07:30 롤오버 뒤 14:10 에 vpc-cni 업그레이드 파이프라인이 타임아웃으로 실패했다. 팀은 롤오버 7시간 뒤인 14:30 에 노드가 NodeNotReady 를 오가는 것을 보고 이상을 알았다. 감지까지 7시간이 걸렸다. 알림은 NodeNotReady 이벤트와 소켓 증가를 잡지 못했다. 팀은 17:21 에 GitHub 에서 v20221027 의 PLEG 관련 이슈를 찾고 나서 원인을 알았다.

   조치

   • Terminating 에 멈춘 노드를 하나씩 cordon, drain, 삭제해 vpc-cni 업그레이드를 끝냈다. 모두 15대를 지웠다.
   • 특정 AMI 를 지정할 수 있도록 인프라 모듈의 terraform 을 고치고 테스트해 master 브랜치에 머지했다.
   • 파이프라인으로 EC2 Auto Scaling 그룹 launch configuration 의 AMI 를 이전의 정상 버전으로 되돌려 노드를 다시 만들었다.

   후속 조치

   • 각 팀에 readiness, liveness 프로브를 쓰자고 제안한다.
   • readiness, liveness 프로브 적용 현황을 보여 주는 대시보드를 만든다.
   • readiness, liveness 프로브와 그 쓸모를 설명하는 위키 글을 쓴다.
   • 인프라 모듈에서 특정 AMI 를 지정할 수 있게 고친다.
   • 최신 AMI 를 바로 받을지, 새 AMI 를 배포 전에 어떻게 시험할지 논의하는 자리를 잡는다.
   • 비정상적인 NodeNotReady 이벤트나 소켓 사용 증가를 잡는 알림을 만든다.
   • 팀 안에 Kubernetes 학습 과정을 만든다.
   • 노드 로그를 중앙에서 모은다.
   • 나와 있는 최신 AMI 를 조회하는 Prometheus exporter 를 만들고, 이를 쓰는 대시보드와 알림도 만든다.

   교훈

   새 AMI 를 배포한 날에는 다른 컴포넌트 업그레이드를 매우 조심해야 한다. 이번에는 새 노드 AMI 를 쓴 날 EKS 컴포넌트도 함께 올리면서 원인을 가리기 어려웠다. 장애나 문제가 생겼을 때 각 팀과 소통하는 경로도 개선해야 한다. 문제를 알린 팀에게서 자세한 내용을 받기 어려웠고, 팀별 당직 호출 경로도 없었다. 팀이 Kubernetes 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.

   사례 보기

원인별8