사례2건
2건 중 1~2번째
- 증상
2023-02-23 20:48 UTC 에 운영 환경에서 Deployment Replicas Unavailable 알림이 울리기 시작했다. 21:10 UTC 에 운영 Live API 와 Test API 가 내려가 Stytch API 호출이 모두 5XX 를 냈고, 21:17 UTC 에는 Dashboard 와 SDK 도 내려갔다.
- 촉발
14:21 UTC 에 팀은 쓰지 않는 관리형 노드 그룹을 지우는 변경을 반영했고, 두 엔지니어가 AWS 콘솔에서 스테이징과 운영의 노드 그룹을 지웠다. 노드 그룹을 지우자 AWS 가 뒤에서 그 노드 그룹과 엮인 리소스를 정리하면서 Karpenter 노드도 쓰던 instance profile 을 지웠다.
- 원인
- 구성 요소
- 기여 요인
- 감지
운영에서는 20:48 UTC 에 Deployment Replicas Unavailable 알림이 울렸고, 21:14 UTC 에 지원팀이 장애를 알렸다. 그보다 앞서 16:06 UTC 에 스테이징, 17:48 UTC 에 운영에서 Karpenter 가 instance profile 을 찾지 못한다는 낮은 긴급도 경고가 왔지만 급하지 않은 문제로 분류되었다. 20:26 UTC 에 Karpenter 오류율이 치솟자 팀은 장애 대응을 시작했다.
- 조치
- 노드 그룹 삭제를 되돌려 노드 그룹을 다시 만들었다. 새 파드는 새 노드가 뜨기를 기다려야 해서 충분히 빨리 스케줄되지 않았다.
- Live API 노드 그룹 하나를 컴퓨팅 크기가 훨씬 큰 노드로 손으로 늘리고, 그 노드 그룹에서 taint 를 지웠다.
- 애플리케이션의 node selector 를 차례로 지워 파드가 그 노드에 스케줄되게 했다. 몇 분 안에 애플리케이션마다 필요한 수의 노드에 파드가 스케줄되었다.
- 후속 조치
- Karpenter 오류의 심각도를 올려 당직 호출기로 바로 가는 높은 긴급도 알림으로 다룬다.
- 클러스터 알림의 임계값을 조정해 높은 긴급도 호출이 더 일찍 가게 한다.
- 노드가 오랫동안 NotReady 나 Unknown 으로 표시되면 알림을 보내 기존 노드의 상태를 더 잘 지켜본다.
- 스케줄할 수 없는 파드, 사용할 수 없는 레플리카를 비롯한 다른 배포 관련 알림의 임계값을 올린다.
- Karpenter 가 쓰는 IAM instance profile 을 노드 그룹이 쓰는 IAM profile 과 다른 것으로 바꾼다.
- 여러 용도로 겹쳐 쓰던 다른 AWS 리소스, 특히 IAM 과 보안 그룹을 나눈다.
- EKS 와 Karpenter 설정을 크게 고쳐 복잡도를 줄인다. 새 시스템 instance profile 은 Karpenter 가 클러스터마다 고유하고 고정된 이름으로 만들게 한다.
- 개발팀이 인프라를 바꿀 때 쓸 수 있도록 클라우드 시각화 도구를 들인다.
- 상태 페이지에 실시간 시스템 지표와 제품 지표를 넣어 Stytch API 가 지금 어떻게 동작하는지 보여 준다.
- 문서에 없는 동작과 부작용을 AWS 에 문의해 확인한다.
- 인프라에서 IAM 역할과 보안 그룹을 여러 용도로 겹쳐 쓰던 것을 바로잡는다.
- 교훈
Karpenter 의 자체 관리 노드에 노드 그룹과 같은 IAM 역할을 쓰지 말았어야 했다. 한 IAM 역할을 여러 용도로 겹쳐 쓰면 이번 같은 문제가 그대로 난다. 팀은 Karpenter 를 처음 설정할 때 빠르고 단순하게 하려다 역할을 나누지 않았다. 원인과 결과 사이가 몇 시간 벌어져 있어 장애 전체를 판단하기 어려웠다. AWS 는 이 지연이 예상된 동작이라고 확인했고, 팀은 앞으로 IAM instance profile 을 바꿀 때 이를 고려한다.
- 증상
2023-01-11 14:22, Cloud Platform 팀원 한 명이 DockerHub 로그인이 실패하는 오류를 발견했다.
- 촉발
LastPass 대응 작업의 하나로 DockerHub 비밀번호를 바꿨는데, EKS 클러스터 노드와 Concourse 는 예전 비밀번호로 계속 로그인하고 있었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:22 에 Cloud Platform 팀원이 DockerHub 로그인 실패 오류를 직접 발견했다. 14:52 에는 Kuberhealthy 데몬셋 점검에서 클러스터도 이미지를 받지 못한다는 것이 드러났고, 14:54 에 사용자 보고가 들어왔다. 장애 선언은 15:17 이었다.
- 조치
- DockerHub 비밀번호를 EKS 클러스터 노드와 Concourse 가 아직 쓰던 예전 값으로 되돌렸다.
- 보고한 사용자에게 물어 파드가 배포되는 것을 확인했고, 클러스터가 다시 이미지를 받는 것도 확인했다.
- 후속 조치
- DockerHub 사용자 이름과 비밀번호 대신 Cloud Platform 전용으로 만든 DockerHub 토큰을 쓰도록 바꿨다.
- 업무 시간 밖에 DockerHub 자격 증명을 새 값으로 바꾸고 노드를 차례로 교체한다.
- 교훈
이 글은 교훈을 따로 적지 않았다. 후속 조치로는 DockerHub 사용자 이름과 비밀번호 대신 Cloud Platform 전용으로 만든 DockerHub 토큰을 쓰도록 바꿨다.
이 2건에서 가장 많이 나오는 구성 요소: 노드 풀, CI 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.