어플리케이션 종류에는 Stateless Application, Stateful Application 있습니다. Stateless 대표적으로 웹 서버입니다. Stateful 대표적으로 데이터베이스입니다.
Stateless는 앱이 여러개 배포되더라도 다 똑같은 서비스의 역할을 합니다. Stateful은 각각의 앱마다 자신의 역할이 있습니다. 몽고 DB 경우를 보면 하나는 Primary 역할, 또 하나는 Secondary, 그리고 Arbiter 역할이 있습니다. Primary는 Main DB이고, 이가 죽으면 Arbiter가 이것을 감지해서 Secondary가 대신 역할을 할 수 있도록 변경해줍니다.
1. 단순 복제인 Stateless 앱과 달리 Stateful 앱은 각 앱마다 본인의 고유 역할을 가지고 있습니다. Stateless 앱은 단순히 같은 서비스의 역할을 하는 앱을 복제하면 되고, Stateful 앱은 Arbiter 역할을 하는 앱이 죽으면 반드시 Arbiter 역할을 하는 앱이 만들어져야 되고, 앱 이름도 이 이름 자체가 고유 아이덴티티의 식별 요소기 때문에 변경이 되면 안됩니다.
2. Volume을 사용시 Stateless는 하나의 Volume을 함께 사용할 수 있지만, Stateful 앱은 각각의 역할이 다른 만큼 Volume도 각각 써야 합니다. 그래야 Arbiter와 같은 역할을 하는 앱이 죽어도 새 앱이 이 볼륨과 다시 연결이 되면서 해당 역할을 이어갈 수 있습니다.
3. 네트워킹 차이로 Stateless는 대체로 사용자들이 접속을 하고 이 접속된 네트워크 트래픽은 한 앱에만 집중이 되면 서버에 문제가 생기기 때문에 여러 앱에 분산이 되는 형태로 흘러가게 됩니다. Stateful 앱은 대체로 내부 시스템들이 데이터베이스 저장을 위해서 연결을 합니다. 이때 이 트래픽은 각 앱의 특징에 맞게 들어와야 합니다. Primary 앱은 R/W 권한이 있기 때문에 연결을 하려는 시스템에서 CRUD를 모두 하려면 여기에 접속해야 하고, Secondary는 Read 권한만 있기 때문에 조회만 해도 되는 내부 시스템은 트래픽 분산을 위해 App2에 접속을 할 수 있습니다. App3은 P,S 상태를 감시하고 있어야 되기 때문에 App1, App2에 연결이 되어야 합니다.
즉 StatefulApp은 역할에 따라 의도가 있는 연결이고, StatelessApp은 단순 분산의 목적만 가지고 있는 연결인데, k8s에서 이런 2 앱의 특징에 따라 활용할 수 있도록 나눠진게 Stateless 앱은 ReplicaSet 컨트롤러입니다. Stateful 앱은 StatefulSet 컨트롤러입니다.
1. StatefulSet Controller
: StatefulSet은 컨트롤러입니다. 이를 ReplicaSet 컨트롤러와 비교해보겠습니다. 먼저 Replicas 1로 컨트롤러를 만들게 되면 StatefulSet도 ReplicSet과 마찬가지로 해당 개수만큼 Pod가 관리됩니다. 차이점은 Pod가 생길 때 이름이 ReplicaSet은 뒷 부분이 랜덤으로 생성되지만, StatefulSet은 0부터 순차적으로 숫자가 붙어서 생성됩니다. 만약 Pod가 삭제될 때 ReplicaSet은 새이름으로 생성되지만, StatefulSet은 삭제된 기존의 이름과 동일한 이름으로 Pod가 생성됩니다.
2. PersistentVolumeClaim, Headless Service
: ReplicaSet은 Pod의 Volume을 연결하려면 PVC를 별도로 직접 생성을 해놓아야 합니다. 이후 ReplicaSet을 만들면 템플릿에 Pod 내용의 PVC으로 PVC1을 지정해놓기 때문에 바로 연결이 됩니다. 하지만 StatefulSet의 경우 템플릿을 통해 Pod가 만들어지고, 추가적으로 volumeClaimTemplates가 있는데, 이것을 통해 PVC가 동적으로 생성이 되고 Pod와도 바로 연결이 됩니다.
만약 Replicas를 3으로 변경하면, ReplicaSet은 모든 Pod들이 똑같은 PVC로 PVC1을 가지고 있기 떄문에 위처럼 한 PVC에 모두 연결이 됩니다. StatefulSet은 volumeClaimTemplates 때문에 Pod가 추가될 때마다 새로운 PVC가 생성되어 연결됩니다. 그래서 Pod마다 각자의 역할에 따른 데이터를 저장할 수 있습니다.
한가지 주의할 점은 ReplicaSet의 PVC가 Node1에 만들어졌다면, 그 PVC에 연결하는 Pod 또한 Node1에 있어야 합니다. 하지만 StatefulSet은 동적으로 Pod, PVC가 같은 노드에 만들어지기 때문에 알아서 모든 Node에 균등하게 배포됩니다.
Replicas를 0으로 변경하면 Pod를 순차적으로 삭제하지만, PVC는 삭제하지 않습니다. StatefulSet을 만들 때 ServiceName이라는 속성으로 서비스 이름을 넣을 수 있는데, 이 이름과 매칭되는 Headless 서비스를 만들게 되면 Pod의 예측 가능한 도메인 이름이 만들어지기 때문에 인터널 서버의 특정 Pod 입장에서 StatefulSet의 Pod에 연결을 할 수 있습니다. 그렇기 때문에 상황에 따라 Pod를 선택해서 접속할 수 있게 되는 것입니다.
'Recent Study > Kubernetes 학습과정' 카테고리의 다른 글
18. Autoscaler (0) | 2024.01.22 |
---|---|
17. Ingress (0) | 2024.01.22 |
15. Authentication - X506 Certs, kubectl, Service Account / Authorization - RBAC, Role, RoleBinding (0) | 2024.01.17 |
14. Volume - Dynamic Provisioning, StorageClass, Status, ReclaimPolicy / Accessing API - Overview (0) | 2024.01.17 |
13. Basic Object - Service (0) | 2024.01.16 |