Missing doc on warn Pod referencing dobs volumes must be owned by statefulset

[martinlevesque]

Hi,

I have few warnings such as: Pod referencing dobs volumes must be owned by statefulset

which links to: https://www.digitalocean.com/docs/kubernetes/resources/clusterlint-errors/#dobs-pod-owner

However the link don't seem correct and there don't seem to have documentation about this issue.

[varshavaradarajan]

Thanks @martinlevesque! :) We will be updating it soon.

[martinlevesque]

@varshavaradarajan awesome, thanks!

[varshavaradarajan]

@martinlevesque - https://www.digitalocean.com/docs/kubernetes/resources/clusterlint-errors/#dobs-pod-owner

[martinlevesque]

@varshavaradarajan thanks for the update.

Mm that's a pretty significant breaking change. That means we can no more use deployments with volumes -> generating pods ???

I have deployments with the following spec part

spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: www
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: www
        deploymentId: "252844"
    spec:
      containers:
      - envFrom:
        - configMapRef:
            name: dotenv
        image: registry.digitalocean.com/xxxxx
        imagePullPolicy: Always
        name: www
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          limits:
            ephemeral-storage: 100Mi
            memory: 100Mi
          requests:
            ephemeral-storage: 100Mi
            memory: 100Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /opt/app/data
          name: main-volume
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: regcred
      initContainers:
      - command:
        - sh
        - -c
        - chmod 777 "/opt/app/data"
        image: busybox
        imagePullPolicy: Always
        name: init-volume
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /opt/app/data
          name: main-volume
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: main-volume
        persistentVolumeClaim:
          claimName: main-pvc

How to still use Deployment, and not StatefulSet?

[timoreimann]

Hey @martinlevesque 👋

Just to be clear: using Deployments with DigitalOcean block storage has always been problematic. It is not something that was changed recently; rather, the clusterlint violation now identifies and surfaces some long-standing problems.

Could you elaborate why you'd want to continue to use Deployments despite the risks described by the documentation update? We have seen many customers being surprised by the behavior observable on the Deployment/DOBS combination, which is why we advise against it.

[timoreimann]

To be a bit more clear: the issue is with Deployments and storage that exhibits RWO (ReadWriteOnly) semantics, which DigitalOcean block storage belongs to. It is not an issue with DOBS per se (i.e., other storage technologies in the same class should see similar problems).

[martinlevesque]

@timoreimann thanks for the clarification. The main reason to keep using Deployment is just because we have lots of Deployment yml implementations, and migrating to StatefulSet is not trivial.

Could it work with ReadWriteMany instead of ReadWriteOnly, or it's the same issue?

[timoreimann]

RWX could help; unfortunately, DOBS does not support that mode. It would also require applications to be able to tolerate concurrent access.

If you make sure you have proper PDBs in place and are careful about how you delete any Deployment-managed pods, you should be able to work around the issue.