IL-0039 FREE NOW · 2019-09-19kubernetesaws
FREE NOW 의 모든 환경에서 쿠버네티스 워커 오토스케일링 그룹은 스팟 인스턴스를 쓴다. 노드는 언제든 종료될 수 있지만, 시간이 지나 용량이 충분히 다시 채워지기만 하면 클러스터는 이를 견딘다.
장애 2~3일 전쯤, 정확히 알 수 없는 시점에 노드가 패키지를 내려받던 저장소 미러 안에서 CentOS 패키지 container-selinux-2.68-1.el7.noarch.rpm 이 다른 위치로 옮겨졌다. 새 워커 노드의 부트스트랩 과정은 이 패키지의 주소를 하드코딩하고 있었다. 패키지를 내려받아 설치하지 못하자 부트스트랩이 끝나지 않았고, 종료된 스팟 노드의 자리를 새 노드가 채우지 못했다. 용량이 모자란 클러스터에서는 파드가 Pending 에 머물렀고 개발자들은 배포하지 못했다.
고친 kops 버전이 없었으므로 팀은 우회책을 찾았다. AMI 를 바꾸는 방법은 해 본 적이 없었다. 그래서 노드가 시작할 때 올바른 패키지를 S3 버킷에서 받아 오는 방법이 더 안전하다고 보고 먼저 골랐다. Prelive 노드에서 패키지를 손으로 내려받자 부트스트랩이 끝나고 노드가 합류했다. 그사이 온콜 팀에 운영 환경이 언제든 크게 손상될 수 있다고 알렸고, 16:55 에는 개발자들에게 운영 환경 배포를 멈춰 달라고 요청했다.
팀은 패키지를 공개 S3 버킷에 올리고 kops 클러스터 설정에 부트스트랩 중 패키지를 내려받는 시작 훅을 넣었다. 첫 적용은 systemd 유닛 문법 문제로 실패했다. 문법을 고친 뒤에는 시작 훅이 너무 늦게 실행됐고, 팀은 18:20 에 이 방법으로는 해결할 수 없다는 것을 알았다. 팀은 두 번째 방안으로 클러스터 AMI 를 Amazon Linux 2 에서 Debian 으로 바꿨다. Prelive 에서 새 노드가 합류하는 것을 확인한 뒤 19:00 에 모든 클러스터에 적용했고 19:08 에 장애 종료를 선언했다.
Prelive 클러스터에 배포하던 개발자들이 #ask-platform 슬랙 채널에 배포가 실패한다고 알렸다. 16:00 에 첫 제보가 왔고 16:06 에 두 번째 제보가 왔다.
조사해 보니 클러스터에 남은 용량이 없어서 컨테이너가 스케줄되지 못하고 있었다. 파드는 Pending 상태에 머물렀다. Prelive 의 오토스케일링 그룹에는 새로 뜬 인스턴스 4대가 있었지만 이 인스턴스들은 클러스터에 합류하지 않았다.
그 노드에 SSH 로 들어가 보니 container-selinux 패키지가 체크섬 불일치로 설치되지 못했고, 그래서 부트스트랩이 끝나지 않았다. 팀은 16:20 에 이 현상이 kops 이슈 7608 과 같다는 것을 확인했다. 워커 노드는 스팟 인스턴스여서 언제든 종료될 수 있었다. 그러면 모든 클러스터에서 사라진 용량이 다시 채워지지 않을 수 있었다.
오토스케일링 그룹의 워커 노드 수와 쿠버네티스에 등록된 워커 노드 수가 오랫동안 달랐던 클러스터도 있었지만 아무도 알아채지 못했다.
증상 ? 파드 Pending노드 증설 실패
원인 ? 의존성 장애
팀은 개발자들이 배포가 실패한다며 #ask-platform 슬랙 채널에 도움을 요청하면서 장애를 알게 됐다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다.
kops 와 Jenkins 로 클러스터 변경을 적용하는 흐름은 잘 동작했다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다.
일부 오토스케일링 그룹의 워커 인스턴스 수와 쿠버네티스에 등록된 워커 노드 수가 오랫동안 달랐는데도 아무도 알아채지 못한 것은 잘못이었다. 문제가 이어지는 동안 운영 환경의 스팟 인스턴스가 대량으로 종료되지 않은 것과 업무 시간에 발견한 것은 운이 좋았다.
같은 원인 · 공통 노드 운영체제 이미지, 노드 풀
같은 원인 · 공통 노드 운영체제 이미지