[Kubernetes] AKS 쿠버네티스 Multi-AZ(Availability Zone) 환경에 PV를 사용할 때, 주의하자! volume node affinity conflict

꽤 지난 이야기이긴 한데, 테스트 클러스터에서 겪었던 일이라 소규모 클러스터,
그 중에서도 statefulset을 사용하는 클러스터를 운영하는 경우 마주칠 수 있는 상황이라 공유합니다.

증상

커피를 마시고 왔는데, 테스트 클러스터의 statefulset으로 올려진 애플리케이션이 pending 상태로 전환되어 있다.
뭐야 왜지? 에서 출발한 의문.

로그를 확인해 보니, FailedScheduling 이 해당 애플리케이션에서 발생하였는데,
원인은 1 Insufficient cpu, 1 Too many pods, 1 node(s) had volume node affinity conflict 였습니다.
시스템 노드를(Master Plane 말고.. 요거는 매니지드 쿠버네티스로 띄워둔거라 마스터노드는 내가 관리하지 않음)
포함해서 3대로 굴리는 클러스터였는데, 에러로그의 앞의 두 개는 자원절감 차원에서 스케일인/다운 한 것이라 그러려니 하겠는데, 맨 뒤의 것이 낯설었습니다~ 

원인

해당 애플리케이션은 Statefulset으로 띄워둔 만큼, Persistent Volume을 사용하고 있었는데 이 애플리케이션에서
사용하는 volume이 zone 1에 위치해 있고, pod limit을 초과하지 않으면서 && cpu 여력이 남은 노드는 zone 2에 속해있어 이런 에러가 발생한 상황이었습니다.

그래서 해당 애플리케이션에서 사용하고 있는 pv의 node affinity를 확인해 보면,
아래와 같이 나타납니다. 

Azure AKS라서... 저렇게 나오는데, 어쨌든 koreacentral-1 이라는 AZ 명을 확인할 수 있습니다.
그리고 이제 노드의 존 정보를 확인해 보겠습니다.

넵... 한 대만 2인 걸 볼 수 있습니다. 말인즉슨, 볼륨이 1에 있으니 스케쥴링이 1로 되어야 하는데
1에 속하는 두 대가 각각 CPU가 부족하고, pod limit이 부족해서 스케쥴링 될 수 없는데
2는 volume에 지정된 node affinity를 충족하지 않아 스케쥴링될 수 없어 pod 가 pending 상태로 빠지게 되었습니다.

물론, 그 전에 애초에 pod가 재시작되게 된 것까지 거슬러 올라가야 하나
이건 애플리케이션에서 돌리고 있던 스케쥴이 잘못되어 restart 된 걸 확인했습니다~~

그래서 원인은, 1차적으로는 애플리케이션을 재기동하게 한 스케쥴 작업이고
그 다음 원인은 테스트환경에의 지나친 비용절감^^(컴퓨팅 리소스든 IP든) 으로 인한 리소스 부족,
세 번 째 원인은 Multi-AZ 환경으로 클러스터를 구성해 둔 것입니다(가용성 목적). 

조치

우선 조치는, zone 1이 스케쥴링 가능한 상태가 되면 되므로 스케일 아웃을 해도 되고,
내려도 되는 자원을 내려서 해결할 수도 있습니다. 
이때는 날려도 되는 샘플 애플리케이션을 내려 리소스를 확보하여 해결하였습니다.

재발 방지

이 부분 때문에 글을 적었는데요,
만약 statefulset 을 잔뜩 띄워놨는데 화재 등으로 해당 az 전체가 죽는다면?
볼륨이 해당 az에 있으니 난처한 상황이 되겠죠...

그래서 GKE에서는 Regional Persistent Disk도 제공합니다!(뜬금 GCP홍보)
하지만 저희는 안타깝게도 Azure AKS를 쓰고 있어서요...
스냅샷을 떠서 해결하는 방법도 있고,
az당 sts를 하나씩 만들어서(!) 해결하는 방법도 있을 듯 합니다.

다만, 어느 쪽이든 미리 신경을 써야 하는 부분이므로
Statefulset을 사용할 때는 한 번씩 고려하는 것이 좋겠습니다~!

이상입니다.
즐건 쿠베생활 하시고, Node affinity 에 대해 설명이 필요하신 분은,
아래의 포스팅으로 놀러오세요~

https://contradicto-lee.tistory.com/79

[Kubernetes] Node selector vs. Node affinity, 어떤 것을 사용할까?