사례46건

46건 중 14~18번째

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-0019 EKS 모듈 18 업그레이드로 새 노드의 디스크가 20Gb 로 줄어 이미지 풀이 no space left on device 로 실패했다

   UK Ministry of Justice2023

   증상

   2023-09-18 13:42, 팀은 High-priority-alert 채널에서 RootVolUtilisation-Critical 알림을 봤다. 14:03 에는 한 사용자가 이미지 풀이 no space left on device 오류로 실패한다고 알렸다.

   노드 디스크 가득 참이미지 풀 실패파드 축출파드 ContainerCreating 정체IP 주소 고갈

   촉발

   EKS 모듈을 버전 18 로 올리면서 런치 템플릿이 바뀌었고, 새 노드의 디스크가 100Gb 에서 20Gb 로 줄었다.

   원인

   설정 변경

   구성 요소

   노드 루트 디스크노드 런치 템플릿노드 풀AWS VPC CNICoreDNS

   기여 요인

   리뷰 누락설정 테스트 부재한계 경보 부재

   감지

   13:42 에 High-priority-alert 채널로 RootVolUtilisation-Critical 알림이 왔다. 14:03 에 사용자가 이미지 풀 실패를 보고했고, 장애 선언은 15:12 였다.

   조치

   • 예전 기본 노드 그룹을 uncordon 하고, 새 노드를 drain 해 워크로드를 예전 노드 그룹으로 되돌렸다.
   • 루트 볼륨을 20Gb 로 줄인 런치 템플릿 변경을 찾아, manager 클러스터와 live 클러스터에 수정을 적용했다.
   • 예전 노드 그룹을 drain 해 워크로드를 수정한 노드로 옮겼다.

   후속 조치

   • EKS 모듈을 올릴 때 런치 템플릿 변경을 비교하는 절차를 런북에 넣는다.
   • live 클러스터처럼 크기가 다양한 이미지를 받아 보는 테스트 환경을 만든다.
   • RootVolUtilisation 알림 런북에 디스크 크기 설정을 확인하는 단계를 넣는다.
   • 노드 수에 따라 CoreDNS 를 자동으로 늘리고 줄인다.
   • IP 접두사 부족을 IPv6 로 풀 수 있는지 조사한다.
   • terraform plan 에서 런치 템플릿이 바뀌면 알아챌 수 있게 드리프트 테스트를 추가한다.
   • CNI 와 ipamd 로그를 볼 수 있게 로깅을 갖추고, IP 접두사 부족 오류가 나면 알림을 보낸다.

   교훈

   이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 빈틈이 두 가지 있었다. 하나는 모듈 업그레이드가 바꾼 런치 템플릿을 배포 전에 비교하지도, 드리프트 테스트로 잡지도 않은 것이다. 다른 하나는 drain 중 팀이 의심한 IP 접두사 부족을 확인할 CNI 와 ipamd 로그도, 알림도 없었던 것이다.

   사례 보기
3. IL-0459 쿠버네티스 위 MediaWiki 가 TLS 종료에 엉뚱한 인증서를 써서 약 30분 동안 트래픽 1% 가 오류를 받았다

   Wikimedia Foundation2023

   증상

   MediaWiki 설정 변경을 배포한 11:41 부터 쿠버네티스로 가는 MediaWiki 트래픽이 오류를 받기 시작했다. 11:47 에 mw-api-ext 와 mw-api-int 서비스의 프로브 실패 알림이 온콜 담당자를 호출했다. 전체 트래픽의 1%, 초당 120건의 요청이 약 30분 동안 오류를 받았다.

   오류율 상승TLS 인증서 오류컨트롤 플레인 지연

   촉발

   09:37 에 쿠버네티스 전역 기본값을 바꾸는 변경이 머지됐다. 이 변경으로 이 기본값을 따르는 차트가 cert-manager 인증서를 쓰게 됐다. 11:41 에 MediaWiki 설정 변경을 배포하면서 쿠버네티스 위 MediaWiki 배포가 이 기본값을 받아 TLS 종료에 엉뚱한 인증서를 쓰게 됐다.

   원인

   설정 변경

   구성 요소

   cert-managerHelm

   기여 요인

   늦게 드러난 변경설정 테스트 부재

   감지

   11:47 에 "(ProbeDown) firing: (6) Service mw-api-ext:4447 has failed probes (http_mw-api-ext_ip4)" 와 "(ProbeDown) firing: Service mw-api-int:4446 has failed probes (http_mw-api-int_ip4)" 알림이 온콜 담당자를 호출해 알아챘다. 두 사람이 호출을 받았다.

   조치

   • 11:58 에 원인을 찾고 패치 https://gerrit.wikimedia.org/r/947331 을 준비했다.
   • 12:08 에 MediaWiki 디플로이먼트를 모두 다시 배포하기 시작했고, 12:16 에 장애가 끝났다.

   후속 조치

   • 배포 절차와 테스트를 더 강화해야 하는지 검토한다. 다음 배포에 뜻밖의 변경이 함께 실리는 문제와 쿠버네티스 카나리 배포도 검토 대상이다.
   • 배포 중에 일부 지표를 볼 수 없거나 비정상이 되는 문제를 지표 쪽에서 고칠지, 배포의 영향을 줄일지 검토한다.

   교훈

   문제를 일으킨 변경을 낸 사람이 대응자 가운데 있어 원인을 빨리 찾았다. 근본 원인은 CI 에서 보였어야 했다. 그러나 변경은 hieradata 저장소에서 했고 원인은 deployment-charts 저장소 쪽에 있어, 변경한 저장소의 CI 에서는 보이지 않았다. 당시에는 트래픽의 1% 만 쿠버네티스로 가서 피해가 작았다. 오류의 양이 적어 문제를 쿠버네티스 쪽으로 좁히는 데 시간이 걸렸다. 보고서는 쿠버네티스를 서비스 풀에서 더 일찍 뺐어야 했는지를 묻는다.

   사례 보기
4. IL-0017 live 클러스터 노드 6대에서 VPC CNI 가 IP 주소를 할당하지 못해 새 파드가 ContainerCreating 에 멈췄다

   UK Ministry of Justice2023

   증상

   2023-07-21 08:15, 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 상태에서 멈춘다고 알렸다.

   파드 ContainerCreating 정체IP 주소 고갈

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   설정 테스트 부재

   감지

   팀은 08:15 에 한 사용자가 #ask-cloud-platform 채널에 새 배포가 ContainerCreating 에서 멈춘다고 보고해 장애를 알았다. 장애 선언은 09:31 이었다.

   조치

   • 새 노드를 추가하고, 영향받은 노드 6대를 cordon 한 뒤 drain 하기 시작했다.
   • live 클러스터에서 Prefix Delegation 을 켜는 명령을 실행해 빠진 CNI 설정을 넣었다.

   후속 조치

   • IP 주소 할당이 제대로 되는지 확인하는 테스트나 점검을 추가한다. 작업 번호는 #4669 다.

   교훈

   이 글은 교훈을 따로 적지 않았다. 후속 조치로는 IP 주소 할당이 제대로 되는지 확인하는 점검을 추가한다는 것 하나만 적었다.

   사례 보기
5. IL-0473 Azure 공개 쿠버네티스 클러스터의 노드 풀이 모두 지워지고 다시 만들어지지 않아 Jenkins 인프라 서비스가 4시간 넘게 멈췄다

   Jenkins project2023

   증상

   2023-07-07 11:05 UTC 부터 15:25 UTC 까지 Jenkins 인프라의 공개 서비스 여럿이 완전히 멈췄다. accounts.jenkins.io, get.jenkins.io, plugins.jenkins.io 를 비롯해 Azure 의 공개 쿠버네티스 클러스터에서 돌던 서비스가 모두 내려갔다.

   네트워크 도달 불가리소스 삭제클러스터·노드 생성 정체서비스 중단

   촉발

   1.25 업그레이드 뒤 파드의 출발 IP 대역이 바뀌어 LDAP 접근이 막히자, 파드 IP 대역을 지정하는 수정인 Azure PR 431 을 10:55 UTC 에 배포했다. 이 변경으로 노드 풀이 모두 지워졌고 다시 만들어지지 않았다.

   원인

   설정 변경

   구성 요소

   노드 풀CNI 플러그인클라우드 로드 밸런서

   기여 요인

   미검증 가정단계적 배포 부재파괴적 변경 보호 장치 부재

   감지

   10:30 UTC 에 1.25 업그레이드를 마친 뒤 팀이 클러스터 안 서비스가 LDAP 서비스에 닿지 못한다는 것을 알아챘다.

   조치

   • 네트워크 설정을 고쳐 클러스터를 처음부터 다시 만들었다. 11:16 부터 13:16 UTC 까지 두 시간이 걸렸다.
   • 파드 CIDR 을 가상 네트워크와 겹치지 않는 별도 대역으로 지정했다.
   • 서비스의 공개 IP 와 DNS 레코드를 새 주소 20.7.178.24 와 2603:1030:408:5::15a 로 바꿨다.
   • 15:17 UTC 에 IP 설정을 포함해 클러스터를 손으로 다시 만든 작업을 PR 로 올려 코드에 반영했다.

   후속 조치

   • Management Lock 을 걸어 공개 IP 가 지워지지 않게 한다.
   • 공개 IP 를 별도 리소스 그룹에 두고, 쿠버네티스가 관리하는 로드 밸런서가 그 그룹을 쓰도록 service.beta.kubernetes.io/azure-load-balancer-resource-group 애너테이션으로 설정한다.
   • 작업을 준비할 때 네트워크 구성과 대역이 겹칠 가능성을 쉽게 볼 수 있도록 네트워크 다이어그램과 문서를 개선한다.
   • AKS 노드 풀 설정을 한꺼번에 바꾸지 않는다. 첫 노드 풀에서 문제를 잡았다면 전체 장애를 피할 수 있었다. arm64 노드 풀에서 PR-3623 으로 이 작업을 하고 있다.

   교훈

   허용 목록을 둔 회사 방화벽 뒤의 사용자가 있어서 공개 IP 는 되도록 바뀌지 않아야 한다. 그런데 원래 클러스터를 지우면서 노드 리소스 그룹과 함께 공개 IP 가 지워졌다. 노드 풀 설정을 한꺼번에 바꾸지 않았다면 첫 노드 풀에서 문제를 잡아 전체 장애를 피할 수 있었다. 팀은 거의 모든 공개 서비스를 담은 클러스터가 완전히 무너져도 4시간 안에 복구할 수 있다는 것을 이번에 확인했다. 그 바탕은 여러 해 동안 함께 해 온 아키텍처 정의, 인프라 구축, 데이터 백업 작업이라고 했다.

   사례 보기

원인별1