March 3, 2024 - 오토스케일링으로 매번 흐트러지는 노드 별 파드 수, 균형을 어떻게 맞출 수 있을까?

*3월3일

 

eks 오토스케일링을 통해 트래픽에 맞춰 노드가 죽고 뜬다. 내부에 속한 파드 또한 이리 저리 이동하면서 자리 잡게 되는데 노드 확대 & 축소가 여러번 반복되다보면 특정 디플로이먼트의 파드가 균형없이 여러 노드에 배정되게 된다. 결과적으로 새로 뜬 노드에 주요한 디플로이먼트가 배정되지 않는 상황도 초래하고 노드 별 CPU가 불균형하게 사용되게 된다.

 

트래픽을 많이 발생시키는 디플로이먼트의 파드들은 기본적으로 HPA를 적용했었고, 적용된 디플로이먼트는 노드 수를 초과하는 수의 파드를 최소한 가지게 된다.

 

*HPA란(HorizontalPodAutoscaler)

 

- 디플로이먼트 단위로 워크로드 크기에 따라 자동으로 파드 수를 조절해주는 기능
- 디플로이먼트 단위로 yaml을 제작하며, CPU 사용률 타겟을 설정 할 수 있다.

 

 

따라서 아래 표와 같이 어떤 노드는 특정 디플로이먼트의 파드 5개를 가지고, 또 다른 노드를 2개 밖에 가지지 못하는 상황이 생긴다. 과한 트래픽을 발생시키는 주요 디플로이먼트라고 가정했을 때 특정 노드에 트래픽이 몰려 CPU와 메모리 사용률을 과하게 유발하고 이는 해당 노드로 들어오는 요청에 매우 늦은 응답을 제공 할 수 밖에 없게 만든다.

 

적용 전 특정 디플로이먼트의 노드 별 배정

 

서칭을 통해 Descheduler를 helm 적용 했음에도 이러한 현상은 파드 배정 불균형 현상은 크게 개선되지 않았다. 그러던 와중 이러한 고민을 해결 해줄 수 있는 topologySpreadConstraints라는 설정값을 외부 조언을 통해 알게 되었다. 이는 파드의 균등한 분포를 위한 설정인데, 주요한 설정값은 아래와 같다.

 

maxSkew // 적용된 숫자만큼의 차이만 동일 디플로이먼트가 각 노드에 배정 될 때 허용. 해당 값이 1이면 3,3,3,3,4,4 정도와 같은 노드 별 파드 배정을 가지게 됨.

topologyKey // 어느 단위로 차이를 따질 지 정하는 필드. kubernetes.io/hostname는 노드 기준으로 차이를 따짐. 그 외 다양한 기준이 있음.

whenUnsatisfiable // 만약 maxSkew가 적용 될 수 없는 상황이라면 어떻게 처리할지에 대한 설정값. DoNotSchedule은 maxSkew 값이 만족되지 못하는 상황일 때 스케쥴러에 신규 파드를 배정 조차 하지 않도록 하는 것이고 ScheduleAnyway는 최대한 적합한 곳에 배정하는 것이다.

 

설정값을 적용하면 아래와 같이 완벽한 수준의 노드 별 파드 배치를 가지게된다. 물론 DoNotSchedule이라는 설정값으로 인해 노드가 새로 뜨고 죽을 때 일부 파드가 pending 상태로 잠시 동안 남아 있게 되지만 오랜 시간이 소요 되지 않는 것으로 확인했다.

 

적용 후 특정 디플로이먼트의 노드 별 배정

 

주요 디플로이먼트에 해당 설정을 적용한 이후, 노드 별 CPU 사용률이 꽤 균등하게 배정되게 되었고 전반적으로 균형있는 자원 사용이 이루어질 수 있었다.