사례3건

3건 중 1~3번째

1. IL-0058 Argo CD 에서 여러 앱이 함께 선언한 네임스페이스가 force 동기화로 지워져 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   Argo CD users2026

   증상

   application-controller 를 롤링 재시작한 뒤, 여러 앱이 함께 쓰는 네임스페이스가 Terminating 상태가 됐다. 이 네임스페이스를 쓰는 앱 약 97개가 Missing/OutOfSync 상태에서 빠져나오지 못했다.

   리소스 삭제

   촉발

   여러 앱이 같은 네임스페이스를 매니페스트에 선언했고, 네임스페이스의 app.kubernetes.io/instance 레이블은 그중 다른 앱을 가리켰다. application-controller 를 롤링 재시작한 직후, UI 에서 레이블이 가리키지 않는 앱을 force: true 로 수동 동기화했다. Argo CD 가 kubectl replace --force 로 네임스페이스를 지우고 다시 만들었다.

   원인

   소프트웨어 결함

   구성 요소

   Argo CD

   기여 요인

   파괴적 변경 보호 장치 부재미검증 가정수동 조치 악화

   후속 조치

   • 보고자가 이 이슈를 닫고, 재시작과 상관없는 재현 절차와 함께 force 동기화와 tracking-ID 충돌 문제를 다루는 #29739 를 새로 열었다.

   교훈

   argocd.argoproj.io/sync-options: Prune=false 는 prune 경로만 막고, force replace 로 일어나는 삭제는 막지 않는다. 수동 동기화는 자동 동기화와 달리 OutOfSync 검사를 거치지 않으므로 언제든 실행된다. 여러 앱이 같은 클러스터 범위 리소스를 선언하면 tracking-ID 충돌이 생기고, 소유하지 않은 앱을 force 동기화하면 그 리소스가 지워졌다가 다시 만들어질 수 있다. 처음 세운 재시작과 캐시 가설은 코드를 읽어 보니 맞지 않았다.

   사례 보기
2. IL-0109 로그 수집을 고치려던 EKS 노드 롤오버가 꼬이면서 Auto Scaling 그룹이 정상 워커 노드를 모두 종료해 클러스터에 노드가 하나도 남지 않았다.

   DFDS2023sev1

   증상

   2023-02-14 09:33 UTC, 최종 사용자들이 CloudWatch 로그가 제대로 들어오지 않는다고 알려 왔다. 팀은 fluentd 를 조사하다가 컨테이너 런타임이 docker-shim 이 아니라 containerd 로 바뀌어 있다는 것을 찾았다. 전날 07:30 UTC 의 정기 노드 롤오버 때 containerd 가 실수로 기본 런타임으로 설정돼 있었다.

   서비스 중단리소스 삭제모니터링 중단

   촉발

   쿠버네티스 로그가 CloudWatch 로 가지 않는 문제를 고치려고 예정에 없던 노드 롤오버를 시작했다.

   원인

   설정 변경

   구성 요소

   컨테이너 런타임노드 런치 템플릿노드 풀Terraform텔레메트리 에이전트

   기여 요인

   자동화 증폭기본 설정 방치스테이징 불일치설정 테스트 부재런북 부재수동 조치 악화

   감지

   로그 문제는 최종 사용자들이 CloudWatch 로그가 이상하다고 알려 오면서 드러났다. 노드가 사라진 장애는 사후 분석 기준으로 2분 만에 감지됐다.

   조치

   • 10:49 UTC 에 노드 롤오버 스크립트로 새 노드를 추가하려 했지만 Docker Hub 타임아웃으로 실패했다.
   • 10:52 UTC 에 노드 롤오버 스크립트를 다시 돌려 새 노드를 추가했고, 11:01 UTC 에 로드밸런서가 새 노드를 정상으로 판단해 트래픽을 다시 보냈다.

   후속 조치

   • 롤오버 절차를 문서로 남기고, 특히 롤오버가 잘못됐을 때 할 수 있는 일을 적는다.
   • 롤오버 절차를 개선할 방법을 찾는다.
   • QA 시험에 fluentd 로그 수집을 넣어 로그가 처음부터 끝까지 전달되는지 확인한다.
   • fluentd 가 보내는 로그 데이터가 부족하거나 없을 때 울리는 경보를 추가한다.
   • 스테이징 환경을 만든다.
   • 잘못된 컨테이너 런타임을 고르지 못하게 막는 장치를 넣었다.

   교훈

   상황이 심각해져도 침착해야 한다. 서둘러 고치다 피해를 키우기보다 알려진 정상 설정으로 롤백하는 편이 낫다. 새 워커 노드를 띄우는 일은 cloudinit 스크립트의 어느 단계도 실패하지 않는다는 전제에 크게 기대고 있다.

   사례 보기
3. IL-0522 ingress-nginx Helm 차트 패치 업그레이드 뒤 jenkins.io 의 Ingress 가 지워져 사이트가 HTTP/503 을 냄

   Jenkins project2021

   증상

   2021년 11월 18일 11:32 UTC, 한 사용자가 Gitter 채널 jenkinsci/jenkins 에 https://www.jenkins.io/doc/pipeline/steps/ 가 HTTP/503 오류를 낸다고 알렸다. 화면에는 Fastly 의 Varnish 가 내는 "Guru meditation" 메시지가 떴다.

   서비스 중단리소스 삭제

   촉발

   2021년 11월 18일 10:42 UTC 에 nginx Helm 차트를 패치 버전인 4.0.6 에서 4.0.8 로 올리는 배포가 성공했다. 새 버전은 `{}` 같은 Nginx 설정 블록이 든 Ingress 어노테이션을 막는 어드미션 웹훅 규칙을 새로 만들었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅HelmCDN 과 엣지 네트워크

   기여 요인

   미검증 가정캐시로 가려진 장애모니터링 사각지대수동 조치 악화

   감지

   장애가 시작되고 25분 뒤인 11:32 UTC 에 사용자가 Gitter 채널 jenkinsci/jenkins 에 신고해 알았다. origin.jenkins.io 에는 오류를 알릴 모니터링이 없었다.

   조치

   • 13:40 UTC 에 자동화 시스템을 모두 멈춘 채 nginx Helm 차트를 이전 버전 4.0.6 으로 롤백하고, 어드미션 웹훅 구성을 손으로 지워 jenkins.io 를 되살렸다.
   • jenkins-infra/charts 에서 jenkins.io 설정의 금지된 어노테이션을 지웠다.
   • jenkins.io Helm 차트를 nginx 4.0.8 에서 제대로 동작한다고 알려진 마지막 버전으로 올렸다.
   • 필요한 수정을 모두 적용한 뒤 17:11 UTC 에 자동화 시스템이 jenkins.io Helm 차트를 다시 배포해 사이트가 돌아왔고, Fastly 에 모든 페이지의 캐시를 비우게 했다.

   후속 조치

   • 인그레스 컨트롤러를 업데이트할 때는 항상 변경 기록을 깊이 읽고, 적어도 두 사람이 실시간으로 함께 본다.
   • www.origin.jenkins.io 의 장애를 잡아내도록 Datadog 에 이 도메인의 모니터링을 더한다.
   • 이 모니터링은 Host 헤더를 www.jenkins.io 로 보내, Fastly 를 거치는 jenkins.io 로 리디렉션되지 않게 한다.
   • 첫 페이지만이 아니라 pipeline steps 페이지 같은 여러 페이지를 점검 대상에 넣는다.
   • 운영에 배포하기 전에 k3s 로 잠깐 띄웠다 지우는 엔드 투 엔드 시험 환경을 두는 방안을 다음 분기에 검토한다.

   교훈

   인그레스 컨트롤러처럼 민감한 구성 요소는 패치 버전 업그레이드라도 변경 기록을 깊이 확인해야 한다. 원본 호스트인 origin.jenkins.io 를 직접 지켜보는 모니터링이 없으면 CDN 뒤에서 난 오류를 사용자 신고로 처음 알게 된다.

   사례 보기

원인별3