사례3건
3건 중 1~3번째
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개는 업그레이드를 시도하지도 못했다.
- 촉발
매일 도는 노드 롤오버가 2022-10-31 07:30 UTC 에 가장 최신 EKS 노드 AMI 인 v20221027 을 가져와 기존 노드를 이 AMI 로 만든 새 노드로 바꿨다. 이 AMI 는 나중에 커널 문제로 회수됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
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 컴포넌트를 깊이 이해하지 못했던 점도 장애에 영향을 준 요인이었다.
- 증상
Jetstack 은 europe-west1 에 있는 GKE 리전 클러스터의 마스터를 업그레이드하고 있었다. 이 개발 클러스터는 여러 팀이 낮 동안 앱을 시험하는 데 쓴다. GKE Terraform 파이프라인으로 업그레이드를 시작했는데, 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않았다. GKE 콘솔에는 클러스터가 여전히 업그레이드 중으로 나왔다.
- 촉발
마스터 업그레이드 중 두 번째 마스터 인스턴스의 API 서버가 ca-registration PostStartHook 을 실행하면서 kube-system 의 extension-apiserver-authentication ConfigMap 을 갱신하려 했다. 이 요청은 설정해 둔 OPA 검증 웹훅의 백엔드가 응답하지 않아 타임아웃 났다.
- 원인
- 구성 요소
- 기여 요인
- 감지
GKE Terraform 파이프라인으로 시작한 마스터 업그레이드가 20분으로 잡아 둔 Terraform 타임아웃 안에 끝나지 않은 것이 첫 신호였다. 파이프라인을 다시 돌리자 kube-apiserver 가 unhealthy 라는 오류가 났다. 원인은 Google Support 의 도움을 받아 찾았다.
- 조치
- API 서버에 간헐적으로 접근될 때를 이용해 OPA 의 ValidatingAdmissionWebhook 리소스를 지워 클러스터를 복구했다.
- 후속 조치
- OPA 의 ValidatingAdmissionWebhook 이 정책이 적용되고 개발 팀이 접근하는 네임스페이스만 보도록 범위를 좁혔다.
- 웹훅을 정책이 실제로 검증하는 Ingress 와 Service 리소스에만 켰다.
- OPA 가 응답하지 않으면 재시작되도록 liveness probe 를 더하고 문서를 고쳤다.
- 이 동작을 개선하자는 쿠버네티스 업스트림 이슈가 아직 열려 있어, 그 진행을 지켜본다.
- 교훈
API 서버 응답 시간에 알림을 걸어 두었다면, OPA 웹훅을 처음 배포한 뒤 모든 CREATE 와 UPDATE 요청의 응답 시간이 늘어난 것을 알아챘을 수도 있다. 모든 워크로드에 프로브를 설정하는 것이 중요하다. 팀은 OPA 배포가 너무 간단해 보여서 Helm 차트를 쓰지 않았는데, 그 차트에는 어드미션 컨트롤러 컨테이너의 livenessProbe 를 포함해 튜토리얼 기본 설정에 없는 조정이 여럿 들어 있었다. 노드 자동 복구를 끄는 것도 검토했지만 끄지 않기로 했다. 같은 문제를 겪은 것은 Jetstack 이 처음이 아니며, 관련 업스트림 이슈는 아직 열려 있다.
IL-0038kubelet 설정 변경을 롤링 업데이트하다 쿠버네티스 버그로 kubelet 이 올라오지 못해 한 클러스터의 노드가 NotReady 가 되고 파드 절반쯤이 축출됐다Oath2018- 증상
kubelet 변경을 클러스터 전체에 롤링 업데이트하던 중 kubelet 이 다시 올라오지 못했다. 쿠버네티스 API 는 노드가 죽었다고 판단했고 노드들이 NotReady 상태로 바뀌었다.
- 촉발
kubelet 변경을 롤링 업데이트로 배포했다. kubelet 은 재시작할 때 시작 전에 임시 cgroup 파일을 정리하는데, 이 과정에서 쿠버네티스 버그로 멈췄다. 이 업데이트가 한 클러스터의 노드 전체로 퍼졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
업데이트 중 kubelet 이 올라오지 않으면서 노드가 NotReady 로 바뀌었고, 그래프에서 eviction 큐에 들어가 축출되는 노드 수가 늘어나는 것이 보였다.
- 조치
- 해당 데이터 센터에서 다음 데이터 센터로 페일오버해 사용자를 옮겼다.
- 후속 조치
- kubelet 업데이트를 적용한 뒤 테스트 프레임워크로 kubelet 을 검증하고, 검증이 끝나야 다음 30% 묶음의 업데이트로 넘어가게 했다.
- 교훈
kubelet 을 업그레이드한 뒤에는 반드시 테스트한다. kubelet API 에 간단한 curl 명령 하나만 보내 봐도 충분하다. 노드 컨트롤러는 노드의 50% 이상이 NotReady 가 되면 축출 속도를 늦추고, 노드가 모두 내려가면 full disruption 모드로 들어가 축출을 멈춘다. 이 동작 덕분에 이번 장애에서 파드의 절반이 살아남았다. 데이터 센터와 클러스터가 여럿이면 품질이 떨어진 데이터 센터에서 다른 데이터 센터로 페일오버해 사용자를 빠르게 옮길 수 있다.
이 3건에서 가장 많이 나오는 구성 요소: kubelet, 어드미션 웹훅. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.