Statefulsets VS Deployment

Kubernetes(K8s) 는 오픈 소스 컨테이너 오케스트레이션 시스템입니다. 이를 통해 배포를 자동화하고 컨테이너화된 애플리케이션을 확장 및 관리할 수 있습니다.다음은 Kubernetes가 포드 배포를 위해 제공하는 두 가지 리소스입니다.

• Deployment
• StatefulSet

Stateful and Stateless Applications

상태 비저장(Stateless) 애플리케이션과 상태 비저장(Stateless) 애플리케이션의 주요 차이점은 상태 비저장 애플리케이션이 데이터를 "저장"하지 않는다는 것입니다.
반면에 상태 저장 애플리케이션에는 백업 스토리지가 필요합니다 . 예를 들어, Cassandra, MongoDB 및 MySQL 데이터베이스와 같은 애플리케이션은 서비스 재시작을 유지하기 위해 몇 가지 유형의 영구 스토리지가 필요합니다.

상태 유지는 상태 저장 애플리케이션을 실행하는 데 중요합니다. 그러나 상태 비저장 서비스의 경우 모든 데이터 흐름은 일반적으로 일시적(transitory.)입니다. 또한 상태는 데이터베이스와 같은 별도의 백엔드 서비스에만 저장됩니다. 연결된 모든 스토리지는 일반적으로 임시입니다. 예를 들어 컨테이너가 다시 시작되면 저장된 모든 것이 손실됩니다. 조직이 컨테이너를 채택함에 따라 채택하기 쉽기 때문에 상태 비저장 컨테이너로 시작하는 경향이 있습니다.

Deployment

Kubernetes 'Deployment'는 일련의 'Pods'를 관리하기 위한 수단을 제공합니다. 하나 이상의 실행 중인 컨테이너 또는 '복제본'이라고 알려진 중복된 '팟' 그룹일 수 있습니다.sets'. 'Deployment'를 사용하면 동일한 'pods' 그룹을 공통 구성으로 쉽게 실행할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app-deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  selector:
    matchLabels:
      app: web-app
  replicas: 3
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: hello-world:nanoserver-1809
          volumeMounts:
          - name: counter
            mountPath: /app/
      volumes:
       - name: counter
         persistentVolumeClaim:
          claimName: counter

In the template below, we have our PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: counter
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 50Mi
  storageClassName: default

apiVersion: v1
kind: Service
metadata:
  name: web-app-service
spec:
  ports:
    - name: http
      port: 80
      nodePort: 30080
  selector:
    name: web-app
  type: NodePort

Statefulset

(애완동물)
애플리케이션의 상태를 저장하고 관리하는 데 사용되는 쿠버네티스 객체다. 기존의 포드를 삭제하고 생성할 때 상태가 유지되지 않는 한계가 있다. 때문에 포드를 삭제하고 생성하면 완전히 새로운 가상환경이 시작된다. 하지만 필요에 따라 이러한 포드의 상태를 유지하고 싶을 수 있다. 응용프로그램의 로그나 기타 다른 정보들을 함께 저장하고자 하는 경우 단순히 PV를 하나 마운트해 이를 유지하기는 어렵다. 스테이트풀셋으로 생성되는 포드는 영구 식별자를 가지고 상태를 유지시킬 수 있다.

​

스테이트풀셋를 사용하고 자하는 케이스는 다음과 같다.

1 안정적이고 고유한 네트워크 식별자가 필요한 경우

2 안정적이고 지속적인 스토리지를 사용해야 하는 경우

3 질서 정연한 포드의 배치와 확장을 원하는 경우

4 포드의 자동 롤링업데이트를 사용하기 원하는 경우

​

스테이트풀셋은 각 포드의 상태를 유지할 수 있는 장점과 함께 몇가지 문제를 해결해야 한다.

1 스테이트풀셋과 관련된 볼륨이 삭제되지 않음 (관리 필요)

2 포드의 스토리지는 PV나 스토리지클래스로 프로비저닝 수행해야 함

3 롤링업데이트를 수행하는 경우 수동으로 복구해야 할 수 있음 (롤링업데이트 수행 시 기존의 스토리지와 충돌로 인해 애플리케이션이 오류가 발생할 수 있다는 의미다).

4 포드 네트워크 ID를 유지하기 위해 헤드레스(headless) 서비스 필요

​

상태를 유지할 수 있다는 장점도 있지만 이로 인해 포드를 각각 따로 관리해줘야 하는 문제도 함께 동반한다. 따라서 스테이트풀셋을 사용할 건지 디플로이먼트를 사용할 것인지는 프로젝트의 상황에 따라 달라질 수 있다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web            
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      volumes:
      - name: www
        persistentVolumeClaim:
          claimName: myclaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

Lastly, we now create a Headless Service for the above

StatefulSet:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx

Deployment vs. StatefulSets

Let's see the main differences between Deployment vs. StatefulSet:

A Kubernetes Deployment is a resource object in Kubernetes that provides declarative updates to applications. A deployment allows us to describe an application’s life cycle. Such as, which images to use for the app, the number of pods there should be, and how they should be updated.

A StatefulSets are more suited for stateful apps. A stateful application requires pods with a unique identity (for instance, hostname). A pod will be able to reach other pods with well-defined names. It needs a Headless Service to connect with the pods. A Headless Service does not have an IP address. Internally, it creates the necessary endpoints to expose pods with DNS names.

The StatefulSet definition includes a reference to the Headless Service, but we have to create it separately. StatefulSet needs persistent storage so that the hosted application saves its state and data across restarts. Once the StatefulSet and the Headless Service are created, a pod can access another one by name prefixed with the service name.