1

I have got a deployment.yaml and it uses a persistentvolumeclaim like so

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mautic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

I am trying to scale my deployment horizontally using (Horizontal Pod Scheduler) but when I scale my deployment, the rest of the pods are in ContainerCreating process and this is the error I get when I describe the pod

Unable to attach or mount volumes: unmounted volume

What am I doing wrong here?

jeril
  • 1,109
  • 2
  • 17
  • 35
  • Try using a VolumeClaimTemplate – Justin Tamblyn Nov 21 '20 at 10:40
  • 2
    oh, I thought volumeclaimtemplates only work with statefulsets.. – jeril Nov 21 '20 at 10:41
  • Sorry I'm short on time. I'm going to try this quick – Justin Tamblyn Nov 21 '20 at 10:44
  • 1
    Howdy. Did some more reading. I don't know that this is possible. To scale out volumes you will probably need to go StatefulSets. Also lets clarify a few things. You have an HPA scaling out the replicas. When a new replica is created you want it to get it's own persistentVolume claim, but you are aware that when HPA scales it down it will lose the volume right? – Justin Tamblyn Nov 21 '20 at 10:51
  • https://stackoverflow.com/questions/53997598/bind-different-persistent-volume-for-each-replica-in-a-kubernetes-deployment – Justin Tamblyn Nov 21 '20 at 10:51
  • Ok I'm now quite convinced you should try a statefulset. It looks like HPA also supports those. – Justin Tamblyn Nov 21 '20 at 10:52
  • 1
    StatefulSets represent a set of Pods with unique, persistent identities and stable hostnames, they are suitable for deploying Kafka, MySQL, Redis, ZooKeeper, and other applications needing unique, persistent identities and stable hostnames. – joe hoeller Nov 21 '20 at 11:06

1 Answers1

4

Using Deployment is great if your app can scale horizontally. However, using a Persistent Volume with a PersistentVolumeClaim can be challenging when scaling horizontally.

Persistent Volume Claim - Access Modes

A PersistentVolumeClaim can be requested for a few different Access Modes:

  • ReadWriteOnce (most common)
  • ReadOnlyMany
  • ReadWriteMany

Where ReadWriteOnce is the most commonly available and is typical behavior for a local disk. But to scale your app horizontally - you need a volume that is available from multiple nodes at the same time, so only ReadOnlyMany and ReadWriteMany is viable options. You need to check what what access modes are available for your storage system.

In addition, you use a regional cluster from a cloud provider, it spans over three Availability Zones and a volume typically only live in one Availability Zone, so even if you use ReadOnlyMany or ReadWriteMany access modes, it makes your volume available on multiple nodes in the same AZ, but not available in all three AZs in your cluster. You might consider using a storage class from your cloud provider that is replicated to multiple Availability Zones, but it typically costs more and is slower.

Alternatives

Since only ReadWriteOnce is commonly available, you might look for better alternatives for your app.

Object Storage

Object Storage, or Buckets, is a common way to handle file storage in the cloud instead of using filesystem volumes. With Object Storage you access you files via an API over HTTP. See e.g. AWS S3 or Google Cloud Storage.

StatefulSet

You could also consider StatefulSet where each instance of your app get its own volume. This makes your app distributed but typically not horizontally scalable. Here, your app typically needs to implement replication of data, typically using Raft and is a more advanced alterantive.

Jonas
  • 121,568
  • 97
  • 310
  • 388