[Kubernetes] Deployment를 왜 선택해야하지?

왜 Deployment를 선택했어?

AWS EKS를 통해 Kubernetes를 사용하면서 Pod를 어떻게 띄울 지에 대해 고민을 하게 되었습니다.

롤링 업데이트와 같은 배포 전략이 불필요하다면 Deployment가 아닌 단순하게 ReplicaSet 혹은 DaemonSet을 통해 Pod를 관리해 줄 수 있지만 저는 여러 배포 전략 중에 무중단 배포를 위한 롤링 업데이트(Rolling Update)를 선택하여 Deployment를 구성해주었습니다.

Deployment를 통해 Worker Node에 Pod를 할당을 했지만...

처음 Deployment를 통해 각각의 Worker Node에 Pod를 할당해 주면 골고루 나누어 들어갈 것이라고 생각이 들었습니다. 하지만 제가 생각한 것과 다르게 아래와 같이 하나의 Worker Node에 Pod가 비정상적으로 분포되고 하나의 파드가 실행되지 않았습니다.

해결 방안 모색

1. DaemonSet

위와 같이 3가지 정도의 방법을 찾게 되었습니다. 일단 첫 번째 Daemonset은 롤링 업데이트 방식과 유사한 방식의 배포 방식을 가지고 있으며 하나의 Worker Node에 하나의 Pod를 배포하게 되는 부분에서 현재 저와 맞는 해결책이라고 생각했습니다. 하지만 이후에 배포 전략을 변경하게 된다면 유연하게 관리할 수 있는 Deployment를 사용하는 것이 상황에 맞게 사용하는 것이라고 생각했습니다.

2. 리소스 제한 설정하기

리소스 제한 설정해주기 위해서 일단 어떠한 기준으로 리소스 제한을 걸어야 할까를 찾게 되었습니다. 현재 저의 노드는  EC2에서 t2.small을 기준으로 사용하고 있어 아래 사진과 같이

리소스가 부족해 롤링 업데이트를 할 때 pending이 되는 오류가 발생하였고 보류 중이라 더이상 업데이트가 되지 않는 것으로 확인하였습니다.

3. 안티-어피니티(anti-affinity)

안티-어피니티는 파드 스케줄링 중 하나이며 하드웨어 자원을 많이 사용하는 앱 컨테이너를 여러 노드로 파드를 분산하게 됩니다. 현재는 롤링 업데이트를 하는 과정에서 파드가 증가하면 멈추는 현상이 생기기 때문에 안티-어피니티를 적용해주어도 변함이 없을 것이라 생각해 트래픽이 증가했을 때 사용할 수 있을 거 같습니다.

 

결과!!

여기서 더 리소스를 줄이게 되면 Pod를 실행시키는 것이 실패해 이 문제를 해결하기 위해서는 Worker Node에 대해 Scale Up이 필요하겠다는 결정을 내렸습니다. 하지만 현재 Scale Up을 할 수 없어 Pod의 개수를 2개로 줄여 운영을 하고 이후에 트래픽이 증가한다면 Scale Up을 해주면 좋을 거 같습니다.