[ k8s ] Statefulset과 Deployment의 차이점

kubernetes에서 pod를 배포하는 방법으로 statefulset과 deployment가 있습니다. 각각은 어떤 목적으로 사용되며 어떤 상황에서 어떤 자원을 사용하는 것이 더 효율적인지 알아보기 위해 각 특징에 대해 정리해보려 합니다.

 

이름에서 확인할 수 있는 특징으로는 stateful이라는 단어가 눈에 들어옵니다. state는 상태를 뜻하며 쉽게 유추할 수 있는 내용으로는 상태를 가지는 것과 그렇지 않은 것으로 나눌 수 있을 것 같습니다.

stateless인 경우에는 상태를 저장할 필요가 없다는 의미로, 해당 어플리케이션이 종료되거나 재 생성되더라도 이전에 상태를 알 필요가 없고, 각 어플리케이션의 상태가 다른 어플리케이션과 의존성이 약한 경우 사용할 수 있을 것 같습니다.

 

반면, stateful application의 경우에는 상태를 저장해야 하는 경우를 뜻합니다. 상태를 갖고 재생성되더라도 이전의 상태와 똑같은 상태를 유지해야하며, 각 application은 서로 대체될 수 없으며 고유한 역할을 갖고 있습니다.

 

요즘 많이 사용되는 구조인 MSA(Micro Service Architecture)에서는 각 Application의 Stateless를 강조합니다. 그 이유는 Application간 의존성이 사라지고, 배포와 확장에 용이하기 때문입니다. 그렇다면 k8s에서는 왜 statefulset을 지원하는지에 대해 deployment와 statefulset의 특징을 정리하며 알아보고자 합니다.

 

 

Deployment

Deployment는 Pod와 Replicaset에 대한 선언적 업데이트를 지원하는 자원입니다. 의도하는 Pod에 대한 정보와 Replicaset에 대한 정보를 선언하여, 애플리케이션에 대한 배포와 업데이트를 손쉽게 지원합니다.

Replicaset을 사용하지 않고, 상위 개념인 Deployment를 사용하는 이유로는 Replicaset에 대한 revisoin을 기록하여 rollback하거나 배포 전략을 rolling update로 설정하여 무중단 배포를 가능하게 해줍니다.

 

Deployment는 위에서 언급했듯 stateless방식으로 Pod를 배포합니다. Pod의 생성 및 복제/삭제를 관리하며 기술된 요구사항에 따라 상태를 처리합니다. 이 과정에서 Pod의 상태를 저장하지 않으며 외부 저장소를 사용하지 않는 경우에는 Pod내부 저장소의 데이터는 Pod Lifecyle에 따라 Pod가 종료되면 함께 제거됩니다.
StatefulSet을 적용하면 Pod가 다시 스케쥴링 될 때 명명규칙과 네트워크, 저장소가 그대로 유지됩니다.

 

위에서 설명한 특징에 따라 Deployment은 다음 중 하나 또는 이상이 필요한 애플리케이션에 유용합니다.

• 새로운 애플리케이션 버전 배포 (버전간 원활한 배포)
• Rollback: 문제가 발생했을 때 이전 버전으로 쉽게 롤백하여 애플리케이션의 안정성 유지 - replicaset revision 저장
• 스케일링: 대체 가능한 Pod를 배포하여 인스턴스 개수 조절을 통해 트래픽 증가 또는 감소에 대응 유연

 

Statefulset

반대로 statefulset에서는 각 Pod들의 state를 저장하고 관리합니다. state는 Pod가 정상동작하고 있는 지 등의 여부도 포함하고 있겠지만, statefulset에 의해 생성된 각 Pod들은 독자성을 유지합니다.

독자성을 가지기 위해서 고유한 identifier를 가지며, 재 생성되더라도 고유한 네트워크 식별자를 가지게 됩니다.

identifier에 의해 배포될 때도 Pod의 순서를 가질 수 있으며, Deployment를 통해 Pod를 배포하게 되면 State와 상관 없이 동일한 역할을 하는 Pod가 여러개 띄워지지만, StatefulSet을 통해 Pod를 배포하게 되면 동일한 스펙을 지녔지만 서로 교체 불가능한 Pod가 생성됩니다. (Pod의 순서 및 고유성 보장) - (의존관계 있는 경우 배포 순서 지정 가능)

 

또한, pod마다 pvc, pv(persistent volume)를 가지며 그로인해 안정적인 스토리지를 가질 수 있습니다. 다시 말해 statefulset을 삭제 또는 scale down하더라도 bounding되었던 volume이 삭제되지 않습니다. 정책에 따라 설정할 수 있지만, 기본적으로 데이터의 안정성을 보장하기 위해 volume을 유지합니다.

위에서 설명한 특징에 따라 Statefulset은 다음 중 하나 또는 이상이 필요한 애플리케이션에 유용합니다.

• 안정된, 고유한 네트워크 식별자.
• 안정된, 지속성을 갖는 스토리지.
• 순차적인, 정상 배포(graceful deployment)와 스케일링.
• 순차적인, 자동 롤링 업데이트.

 

Deployment와 Statefulset의 차이점

Deployment와 Statefulset의 주요 차이점들을 정리해보려 합니다.

• Service vs Headless Service

Deployment는 Service에 의해 외부로 노출될 수 있으며, 하나의 Service에 의해 Deployment에서 생성된 여러 Pod로 Request가 전달되며 같은 역할을 하는 Pod들이므로 Random하게 선택되어 전달됩니다.

하지만, Statefulset은 각 Pod가 서로 대체될 수 없으므로 서로 고유한 DNS를 가지며 원하는 Pod를 지정해서 request해야합니다. 즉, service로 request하는  것은 불가능하며 별도로 clusterIP를 None으로 지정하여 headless service를 생성해야 합니다. headless service로 묶인 Pod들은 고정된 네트워크 식별자(DNS)를 가지고 있습니다.

[pod-name].[svc].[namespace].svc.cluster.local

사실 Headless Service가 없더라도 Pod는 기본적으로 아래와 같은 DNS를 가집니다. 다만 DNS에 pod ip주소가 포함되기 때문에 사실상 고정된 DNS가 아니므로 활용이 어렵습니다. 반면에 Headless Service를 사용하면 pod의 DNS에 ip주소 대신 pod이름을 사용하고, StatefulSet은 고정된 pod 이름을 가지므로 사실상 pod의 DNS는 고정된다고 볼수 있습니다.

[pod-ip-address].[namespace].pod.cluster.local

• Rollback

Deployment은 내부적으로 Replicaset을 생성하여 Pod를 복제하고 관리하며, Replicaset의 revision을 저장하기 때문에 문제가 발생했을 때, 이전 상태로 되돌아 갈 수 있는 Rollback이 가능합니다.

반면 Statefulset은 내부적으로 Replicaset을 생성하지 않으며 Pod의 복제와 고유 식별자를 스스로 관리합니다. 이에 따라 Rollback은 불가능합니다.

 

• Rolling Update 방식

Deployment와 Statefulset 모두 기본적으로 update strategy는 rolling update를 채택합니다. 무중단 배포를 지향하므로 기존 version의 Pod들이 동작하고 있을 때, 새로운 Pod들을 생성하고 기존 Pod들을 하나씩 중단시켜 제공 중인 서비스가 중단되지 않도록 합니다. 물론, old/new version의 Pod set들이 공존할 수 있다는 단점은 존재합니다.

이러한 메커니즘은 같지만 Pod들의 고유 식별자 및 의존성이 중요한 Statefulset의 경우에는 생성되는 순서와 반대로 Pod들이 종료되며, 생성 시에도 같은 순서가 보장된다는 차이점이 있습니다.

 

 

이러한 특징들을 잘 정리하고 알아두어 목적에 맞는 자원을 잘 활용한다면 좋을 것 같습니다. 😎✔

reference: https://cloudavenue.in/2022/02/04/deployments-vsstatefulset/

Kubernetes | Deployments V/s StatefulSets