Deployments 와 StatefulSets

베하~! 안녕하세요 1-Tier팀 입니다.

Kubernetes 환경을 운영하면서 대부분 Deployment로 관리되고 운영되는데, MySQL, Jenkins 등 일부는 StatefulSet을 사용하는것에 궁금증이 생겼고 비슷한 역할을 하는 리소스이긴 하나 분명 다른점이 있을 것인데 명확하게 설명하기 어려워 두 개의 차이점을 알아보고자 찾아보면서 정리하기 위해 해당 포스팅을 작성하게 되었습니다.

 

차이점을 이해하기 전에, 먼저 상태 저장의 의미인 Stateful 과 Non-Stateful 를 이해해야 합니다.

Stateful / Non-Stateful

Stateful

상태를 지속적으로 유지하는 상태

DB, 캐싱 등 데이터를 영구적으로 저장하고 관리해야 하는 경우에 사용되며 각각의 인스턴스가 고유 식별자를 가지고 있는 상태입니다. 즉, 각각의 Pod에 고유한 PV를 가지고 있는 것입니다.

Non-Stateful

상태를 지속적으로 유지하지 않는 상태

Web Server, LB 등 동일한 작업을 수행하며 데이터를 저장할 필요가 없는 상태입니다.
이때, 각각의 상태를 공유하거나 저장하지 않아 교체 및 확장이 쉽다는 장점이 있습니다.

 

이제, Stateful 과 Non-Stateful 의 차이를 이해하였으니 Deployment와 StatefulSet의 차이를 알아봅시다.

 

Deployment / StatefulSet

Service vs Headless Service 

Deployment는 Service를 통해 외부에 노출되고 Service에 요청이 들어오면 Pod가 랜덤하게 선택된다.

StatefulSet은 Headless Service를 통해 외부에 노출되고 각 Pod에 고유의 DNS를 가지며 원하는 Pod를 지정하여 요청합니다. StatefulSet이 Headless Service를 사용하는 이유는, 각 Pod의 역할이 달라 특정 Pod와 통신해야 하는 경우가 많기 때문입니다.

Rollback & ReplicaSet

Deployment는 내부적으로 ReplicaSet을 생성하여 Pod를 관리하며 Rollback이 가능하다

StatefulSet은 내부적으로 ReplicaSet을 생성하지 않고 Rollback이 불가능하다

 

이러한 차이점으로 인해 사용하는 애플리케이션의 특징과 상황에 따라 Deployment와 StatefulSet을 적절히 사용하며 안정적인 운영을 가능하도록 하는 것이었습니다.

 

웹이나 로드밸런싱을 위한 경우 교체와 확장이 쉬워야 하고 같은 역할을 하기 때문에 Deployment를 사용하고, DB나 캐싱 등 데이터를 저장하고 각자의 역할을 부여받으며 지속적으로 데이터를 유지해야 하는 경우에 StatefulSet을 사용하여 상태 정보를 기억하도록 합니다.

 

이상 다음 포스팅에서 만나요! 베빠~