Spot.io VNG bin packing 이슈 해결하기
NoOps
실제 운영중인 클러스터에 spot.io를 사용한 ocean controller 적용 후 다음과 같은 문의를 받았습니다.
@devops
k8s 과 관련하여 여쭤보고 싶은게 있습니다.
현재 서비스 중인 파드가 새로 생긴 노드로 이동할때, 기존 사용되던 파드가 terminated 되면서 새로운 노드에 생기는 것을 방금 확인했습니다. (lens)NODE ip-172-XX-XX-XXX.ap-northeast-2.compute.xxx 가 새로 생기면서
POD xxx-deployment-prod-6bd8d5696c-n5bw8 Qos Guaranteed
POD xxx-deployment-prod-7f96d9bd66-qptbv Qos Burstable
가 이전됨.-> 이 경우 xxx는 기존에 HPA 없이 1개만 사용중이었어서 이동 시 사용이 어려움.
이 부분에 대한 처리는 어떻게 하는게 좋을까요?
해당 문의 이전에도 내부에서 사용중인 제품의 pod 개수가 1개인 서비스가 간헐적으로 재시작되는 것을 목격하여 분석중에 있었습니다.
이슈가 발생하기 시작한 시점이 VNG를 적용한 시점이기에, VNG로 적용된 ocean-controller의 동작 방식을 검토하고자 하였습니다.
이에 spot.io support 측에 문의하였습니다.
ocean-controller 는 bin packing 등의 목적으로 pod 를 kill 하는 경우가 있는지?
support 측 답변
네 bin-packing 목적으로 pod를 축출 (Evicted)합니다. 다만, 첨부로 올리셨던 것처럼 단독으로 종료하진 않고, 새 Deployment 생성 후 삭제하는 프로세스 입니다. 이는 사용자 개입 없이 자동화 되어 있습니다.
컨트롤러가 bin-packing을 제외하고 pod를 종료하진 않는다고 합니다.말씀하셨던 시간의 로그를 확인해보니 bin-packing으로 인한 상황이 맞는 것으로 보입니다.
기존 노드는 종료되고, 기존 Pod는 대체 노드로 옮겨진 것으로 확인됩니다.
무중단 배포 및 파드 라이프사이클 관리를 위해 readiness/liveness probe를 적용해둔 서비스에서 발생한 문제이기에 probe 구성과 상관없이 kill이 된 것 같아 추가 확인을 요청하였고 다음의 답변을 받을 수 있었습니다.
Following up in regards to your latest email about a pod that is getting evicted and scheduled at the same time, I would like to share with you the following insights -
Generally speaking, from investigating and understanding your case, my best suggestion for you is to configure "PDB" (Pod Disruption Budgets)
Our Autoscaler entirely supports Pod Disruption Budgets which are set on K8s end and our Autosacaler will respect the required number of each app’s replicas that are specified there. Using PDBs can help reduce the instabilities of your apps per each of your app’s needs, and it will limit the scale-downs accordingly.
In addition, while you have PDB configured, the advantage of it is, that in every single moment there is a pod running on a node while a replacement/optimization occurs due to any reason in the cluster.
This is how you can avoid the behavior you mentioned in your latest email.
-> 결과적으로 ocean-controller의 오토 스케일러는 PDB를 지원하며, 필수 replica 수를 존중하여 워크로드의 불안정성을 줄이는 데 도움을 줄 수 있고, PDB를 구성하는 동안 교체 혹은 최적화(bin-packing 등)가 발생하는 동안 실행중인 pod을 유지할 수 있는 이점이 있다는 것을 알게 되었습니다.
해당 제안을 바탕으로 고객에게 제공되는 서비스에 영향을 줄 수 있는 pod에 PDB를 적용하였고, 이후 약 일주일간 모니터링 한 결과 담당자의 입력없이 pod이 재실행되는 문제가 발생하지 않았고 문제가 해결되었다고 판단하였습니다.
다음과 같이 정리해 볼 수 있을 것 같습니다.
bin-packing 시 다른 노드에서 pod이 스케줄됨과 동시에 기존 pod이 종료되는 문제
- PDB(Pod Desruption Budgets)를 구성하는 것이 제안이 될 수 있습니다.
- PDB는 bin-packing 등과 같은 상황에서도 최소한의 pod는 유지해주는 기능
- PDB 관련 참고자료
