IL-0073 Target · 2019-01-15 (게시일)kubernetesnetworking
Target 의 Dan Woods 가 정리한 연쇄 장애다. TAP 는 Target Application Platform 의 줄임말로, 여러 호스팅 인프라 위에서 워크로드를 실행하고 관리하는 공통 플랫폼이다. TAP 로 배포하는 모든 애플리케이션은 로깅 사이드카, 메트릭 사이드카, Consul 에이전트 사이드카와 함께 배포된다. 로그와 메트릭은 Kafka 로 보내고, Kafka 는 데이터센터의 OpenStack 위에서 돈다. Consul 에이전트는 워크로드가 시작되자마자 그 워크로드를 Consul 에 서비스로 등록하고 노드의 멤버십을 Consul gossip 메시에 알린다.
어느 저녁 OpenStack 의 네트워크 하위 시스템을 업그레이드했다. 네트워크는 잠깐만 끊길 예정이었지만 업그레이드 중 문제가 생겨 몇 시간 동안 네트워크가 끊겼고, Kafka 에 간헐적으로만 닿았다. TAP 가 쓰는 쿠버네티스 클러스터 가운데 하나는 다른 클러스터보다 훨씬 크게 만들어져 개발 환경 워크로드 약 2,000개를 올리고 있었다. 평소 로깅 사이드카는 CPU 를 거의 쓰지 않지만, Kafka 연결이 끊겼다 이어졌다 하자 모든 사이드카가 한꺼번에 깨어났다. 하나하나는 CPU 를 많이 쓰지 않았어도 합치면 노드의 Docker 데몬에 높은 부하를 줄 만큼이었다. 부하를 받은 노드는 쿠버네티스에 비정상이라고 보고했고, 스케줄러가 워크로드를 정상 노드로 옮기자 그 노드들도 비정상이 되어 같은 일이 되풀이됐다.
재스케줄링 중 쿠버네티스는 새 노드 약 41,000개를 만들었다가 금방 없앴다. 파드 안의 애플리케이션은 시작되지도 않았지만, 파드는 Consul 에 등록하고 gossip 메시에 알릴 만큼은 살아 있었다. Consul 의 CPU 사용량이 올라 요청 지연이 커졌고, 메시의 노드 수가 늘어 모든 워크로드의 CPU 사용량도 올랐다. Consul 에이전트는 반복 한 번에 다른 노드의 메시지를 정해진 수만큼만 처리하므로 노드가 사라졌다는 메시지가 처리되지 못했다. 그 결과 유령 노드가 만료됐다가 다시 메시에 추가되는 일이 한꺼번에 몰려 거듭 일어났다. 개발 환경 Vault 클러스터는 Consul 과 통신하지 못해 스스로 봉인됐다. TAP 배포 엔진은 Consul 로 인프라 백엔드를 찾고, 애플리케이션 토큰을 발급하고, 임시 로드 밸런싱을 설정한다. 이 엔진이 Consul 과 제때 통신하지 못해 배포가 실패했다.
며칠 동안 조사와 디버깅을 하며 이것저것 시도한 끝에 Consul 의 gossip 암호화를 켜서 Consul 과 Vault 를 되살렸다. 오염된 메시에서 오는 메시지를 바로 거부할 수 있었기 때문이다. 그다음 배포 엔진을 안정시키고, 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했다. 이후 Consul 1.2.3 에 큰 클러스터를 다루는 PR 이 병합된 것을 찾아 Consul 을 제자리 업그레이드했다. 워크로드 하나를 계획한 대로 늘렸다가 정상 종료 없이 줄여 보니 노드가 gossip 메시와 서비스 카탈로그에서 바로 빠졌다. 1.2.3 UI 에서 이름에 / 가 들어간 서비스를 열 수 없는 버그가 있어 최종적으로 1.3.0 으로 올렸다. 운영 환경인 prod1 의 gossip 메시도 오염됐지만, 클러스터가 덜 빽빽하게 차 있어 연쇄 장애는 일어나지 않았고 Consul 업그레이드로 빠르게 정리됐다. TAP 팀은 개발 환경을 prod0 로 여기므로 이 장애를 가장 높은 심각도로 다뤘다.
어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.
쿠버네티스 스케줄러가 비정상 노드의 워크로드를 아직 정상인 노드로 옮기자 그 노드들도 비정상이 되었고, 같은 일이 계속 되풀이됐다. 스케줄러는 워크로드를 모든 노드에 고르게 나누지 않으므로 어떤 노드는 늘어난 CPU 사용량을 견뎠고 어떤 노드는 견디지 못했다.
재스케줄링 동안 쿠버네티스는 새 노드 약 41,000개를 만들었고, 이 노드들은 금방 떴다가 사라졌다. Consul 의 CPU 사용량이 올라 Consul 요청에 견딜 수 없는 지연이 생겼다. gossip 메시의 노드 수가 늘면서 배포된 모든 워크로드의 CPU 사용량도 함께 올랐다. 사라진 유령 노드가 만료됐다가 다시 메시에 추가되는 일이 한꺼번에 몰려 거듭 일어났다.
다른 시스템도 영향을 받았다. 애플리케이션에 시크릿을 주는 개발 환경 Vault 클러스터는 정해진 시간 안에 Consul 과 통신하지 못해 스스로 봉인됐다. TAP 의 배포 엔진도 Consul 과 제때 통신하지 못해 배포가 실패하기 시작했다.
–
글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.
–