Deployment vs StatefulSet¶

Taking PostgreSQL as example, ...

What is the main difference:

• in a StatefulSet you declare the PVC's inside your spec as volumeClaimTemplate
• you don't declare strategy. This is a construct for Deployments
• the template part is equal in both implementations

Though it's quite easy to convert a Deployment to a StatefulSet in your definition or vice versa.

But keep in mind:

• like in the example down below it is not a good idea to scale up a PostgreSQL Deployment. This will cause some confusion, because you have to pods running on the same persistent after this.
• on the other hand: if you scale up the StatefulSet, the StatefulSet will create an additional PVC and will mount this on the second pod. This may be better, but not what you want.
  You now have to independent databases and maybe a SVC pointing on both databases ;-).

StatefulSet¶

kind: StatefulSet
apiVersion: apps/v1
metadata:
  name: postgresql
spec:
  replicas: 1
  serviceName: postgresql
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: postgresql
    spec:
      containers:
        - name: postgresql
          image: docker.io/centos/postgresql-12-centos8:latest
          envFrom:
            - secretRef:
                name: database
          ports:
            - name: postgresql
              containerPort: 5432
              protocol: TCP
          resources:
            requests:
              cpu: "200m"
              memory: "128Mi"
            limits:
              cpu: "400m"
              memory: "256Mi"
          readinessProbe:
            tcpSocket:
              port: 5432
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          livenessProbe:
            tcpSocket:
              port: 5432
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          volumeMounts:
            - name: postgresql
              mountPath: /var/lib/pgsql/data
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
      restartPolicy: Always
      terminationGracePeriodSeconds: 10
      dnsPolicy: ClusterFirst
      securityContext: {}
      schedulerName: default-scheduler
  volumeClaimTemplates:
    - metadata:
        name: postgresql
        labels:
          app: postgresql
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: changed-by-upper-kustomize
        volumeMode: Filesystem
        resources:
          requests:
            storage: 500Mi

Deployment¶

Here we have a split. We have to explicit declare the PVC:

---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: postgresql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      containers:
        - name: postgresql
          image: docker.io/centos/postgresql-12-centos8:latest
          envFrom:
            - secretRef:
                name: database
          resources:
            requests:
              cpu: "200m"
              memory: "128Mi"
            limits:
              cpu: "400m"
              memory: "256Mi"
          readinessProbe:
            tcpSocket:
              port: 5432
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          livenessProbe:
            tcpSocket:
              port: 5432
            timeoutSeconds: 1
            periodSeconds: 10
            successThreshold: 1
            failureThreshold: 3
          volumeMounts:
            - name: postgresql
              mountPath: /var/lib/pgsql/data
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          imagePullPolicy: Always
      restartPolicy: Always
      terminationGracePeriodSeconds: 10
      dnsPolicy: ClusterFirst
      securityContext: {}
      schedulerName: default-scheduler
      volumes:
      - name: postgresql
        persistentVolumeClaim:
          claimName: postgresql
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 25%
      maxSurge: 25%
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: postgresql
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
  storageClassName: changed-by-upper-kustomize
  volumeMode: Filesystem