StatefulSet
Application의 종류로는 Stateless Application과 Stateful Application이 있다.
Stateless Application
Apache, Nginx, IIS 서버 등 Web Server
-
App이 여러 개 배포되더라도 다 똑같은 Service의 역할을 한다.
-
한 App이 죽으면 같은 서비스의 App을 하나 복제해주면 된다.
-
볼륨이 반드시 필요하지는 않다.
-
네트워크 트래픽은 여러 App에 분산된다.
즉, 단순 분산의 목적
=> 쿠버네티스에서 ReplicaSet 컨트롤러 사용
Stateful Application
MongoDB, MariaDB, redis 등 Database
-
각각의 App 마다 자신의 역할이 있다.
ex) MongoDB의 경우 Primary(메인 DB), Secondary(Primary에 이상이 생겼을 경우 메인 DB 역할), Arbiter(Primary의 상태 감지 및 변경)의 역할
-
한 App이 죽으면 반드시 그 App과 동일한 역할을 하는 App이 만들어져야 한다.
-
각각 App의 역할이 다른 만큼, 볼륨도 각각 사용해야 한다.
-
대체로 내부 시스템이 데이터베이스 연결을 위해 사용하고, 트래픽은 각 App의 특징에 맞게 들어와야 한다.
ex) Read/Write, Read, ....
즉, 역할에 따라 의도가 있는 연결
=> 쿠버네티스에서 StatefulSet 컨트롤러 사용
StatefulSet
-
Stateful Application이 될 수 있도록 관리해 줌
-
목적에 따라 해당 Pod에 접근하기 위해서 Headless Service 사용
StatefulSet Controller
-
replicas를 1로 주어 Pod를 생성하면 Ordinal Index 이름으로 Pod가 생성된다. (Pod-0)
-
여러 개를 생성하면 순차적으로 생성되고, Pod-0, Pod-1,.... 순서로 생성된다.
-
만약 Pod-2를 삭제하고 재생성할 경우, 기존 이름(Pod-2)로 다시 생성한다.
-
replicas를 0으로 변경해 Pod들이 모두 삭제되어야 할 경우, 마지막 인덱스 Pod부터 순차적으로 삭제된다.
PersistentVolumeClaim, Headless Service
-
template으로 Pod가 생성되고 난 후, volumeClaimTemplates으로 PVC가 동적 생성된 후 Pod와 바로 연결된다.
-
replicas를 3으로 주었다고 가정하면, ReplicaSet일 때는 3개의 Pod가 모두 직접 생성한 PVC1로 연결되는 데 반해 StatefulSet은 volumeClaimTemplates로 3개의 PVC가 만들어져 3개의 Pod에 각각 연결된다. 그래서 Pod마다 각자의 역할에 따른 데이터를 저장할 수 있다.
-
동적으로 Pod와 PVC가 같은 노드에 만들어지고, 따라서 알아서 모든 노드에 균등하게 배포된다.
-
replicas를 0으로 주어 Pod들이 삭제되어도 PVC는 삭제되지 않는다.
-
StatefulSet의 ServiceName 속성으로 "Headless"를 주고 Headless 서비스를 만든다면 Pod의 예측 가능한 도메인 이름이 만들어지고, Internel Server의 특정 Pod 입장에서 원하는 StatefulSet의 Pod에 연결할 수 있다. 즉, Pod를 선택해서 접속할 수 있다.
