Kubernetes Cluster 업데이트가 쏘아 올린 서비스 장애

Kubernetes Cluster 업데이트 과정 중에 서비스 장애가 일어나게 된 과정과 사후부검 내용을 공유합니다.

서비스를 운영하는 입장에서 이미 잘 운영되고 있는 리소스를 변경하는 작업은 서비스를 불안정하게 만들 수 있고, 작업량 자체도 많기 때문에 최대한 피하고자 했습니다. 하지만 당시 운영 중이던 Kubernetes Cluster 버전에서 위험도가 Critical Level인 보안 취약점이 발견되었다고 보안팀께서 내용을 전달해주셨고, 뱅크샐러드는 보안을 최우선으로 생각하기 때문에 업데이트를 진행하기로 결정했습니다.

Updating Cluster

DevOps팀에서 Cluster 업데이트 계획을 다음과 같이 세웠습니다.

1. kops edit cluster를 통해 kubernetesVersion 을 취약점 패치가 진행된 버전으로 변경
2. kops update cluster (dry run)을 통해 변경사항을 확인하고 적용
3. 상대적으로 서비스에 영향을 덜 끼치는 Master Node들부터 Rolling Update
4. 앞으로 Scheduling 될 Pod들이 새로운 (업그레이드된) 노드에 Schedule 되도록 기존 Worker Node들을 cordon
5. Scale Out 가능한 Pod들(e.g. Stateless Service)이 새로운 노드에 뜨도록 Scale Out 진행
6. Stateful 한 Pod들(e.g. RabbitMQ Cluster)은 수동으로 이동
7. Pod이 남아있지 않은 노드들을 delete

node를 바로 drain 할 수도 있었지만, 하나의 Node에 같은 Replica의 Pod들이 몰려있을 수도 있고, CronJob같은 경우 다 돌았는지 체크, Stateful 한 Resource의 경우 다시 뜨는 데 Sync 과정이 필요하기 때문에 Manual 하게 컨트롤이 필요해서 위와 같은 과정을 통해 클러스터를 업데이트하고자 했습니다.

이렇게 세운 계획을 프로덕션 환경과 동일하게 설정되어있는 실험용 Cluster에 먼저 적용하고 위에서 계획한 것과 같이 동작하는지 검증하는 작업을 거쳤고, 의도한 것처럼 새로운 노드에 Pod들이 Scheduling 되는 것을 확인해 실제 Production Cluster에도 업데이트를 진행하기로 결정했습니다.

STAY!!!

1~3번 과정까지는 이상 없이 진행되었으나, 기존 Worker Node들을 cordon 처리하고 몇분 뒤, 서비스 장애 알람을 받게 되었습니다. 모든 노드를 uncordon 처리한 뒤에 다시 서비스에 정상적으로 접속할 수 있었습니다.

사후부검Post-mortem

node가 cordon 되면, Ingress가 해당 노드로는 트래픽을 전달하지 않기 때문에 발생한 장애였습니다. Kubernetes 공식 문서에도 아래와 같이

Marking a node as unschedulable prevents new pods from being scheduled to that node, but does not affect any existing pods on the node. This is useful as a preparatory step before a node reboot, etc.¹

단순히 Node가 unschedulable 된다는 것 이외에 다른 내용은 적혀있지 않아 장애 원인을 파악하는 데 시간이 걸렸는데, GitHub에도 똑같은 사례가 Issue로 등록되어있었습니다.

kubectl cordon causes downtime of ingress(nginx) · Issue #65013 · kubernetes/kubernetes

이렇게 했다면 서비스 장애를 일으키지 않을 수 있었다

• 만약 우리가 Integration Test를 진행했다면?

단순히 Pod이 재배치되는 것뿐만 아니라 실험용 클러스터의 Pod에 트래픽이 정상적으로 들어가는지 검증할 수 있었다면 트래픽이 정상적으로 전달되지 않는다는 것을 사전에 인지해 장애를 막을 수 있었을 거라 생각됩니다.

• 만약 우리가 모든 Worker Node를 순차적으로 cordon 처리를 했다면?

순차적으로 cordon 처리를 했다면 Pod이 몰려있지 않는 한 위와 같은 원인으로 장애가 일어나지는 않았을 겁니다.

조금만 더 천천히, 충분한 검증 과정을 거치면서 업데이트를 진행했다면 일어나지 않았을 장애라 아쉬움이 남습니다. 그러나 이번 장애를 통해 뱅크샐러드의 API Golden Path를 설정하는 등 더 안정적인 서비스 운영을 위한 학습 또한 할 수 있었습니다.

끝으로 고객분들에게 신뢰할 수 있고 안정적인 돈 관리 서비스를 제공할 수 있도록 기여해주실 Site Reliability Engineer를 찾고 있습니다 🙇 언제든지 아래 채용공고를 통해 지원해주세요. 감사합니다 😀

[1] Kubernetes Documentation | Manual Node Administration