<p>I have got a deployment.yaml and it uses a persistentvolumeclaim like so</p>
<pre><code>kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mautic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
</code></pre>
<p>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 <code>ContainerCreating</code> process and this is the error I get when I <code>describe the pod</code></p>
<pre><code>Unable to attach or mount volumes: unmounted volume
</code></pre>
<p>What am I doing wrong here?</p>

jeril
<p>Using <a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Deployment</a> is great if your app can scale <em>horizontally</em>. However, using a <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">Persistent Volume</a> with a <code>PersistentVolumeClaim</code> can be challenging when scaling <em>horizontally</em>.</p>
<h3>Persistent Volume Claim - Access Modes</h3>
<p>A <code>PersistentVolumeClaim</code> can be requested for a few different <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">Access Modes</a>:</p>
<ul>
<li>ReadWriteOnce (most common)</li>
<li>ReadOnlyMany</li>
<li>ReadWriteMany</li>
</ul>
<p>Where <code>ReadWriteOnce</code> 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 <code>ReadOnlyMany</code> and <code>ReadWriteMany</code> is viable options. You need to check what  what <em>access modes</em> are available for your <em>storage system</em>.</p>
<p>In addition, you use a <em>regional cluster</em> from a cloud provider, it spans over three <em>Availability Zones</em> and a volume typically only live in one <em>Availability Zone</em>, so even if you use <code>ReadOnlyMany</code> or <code>ReadWriteMany</code> 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 <strong>storage class</strong> from your cloud provider that is replicated to multiple <em>Availability Zones</em>, but it typically costs more and is slower.</p>
<h2>Alternatives</h2>
<p>Since only <code>ReadWriteOnce</code> is commonly available, you might look for better alternatives for your app.</p>
<p><strong>Object Storage</strong></p>
<p>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. <a href="https://aws.amazon.com/s3/" rel="nofollow noreferrer">AWS S3</a> or <a href="https://cloud.google.com/storage" rel="nofollow noreferrer">Google Cloud Storage</a>.</p>
<p><strong>StatefulSet</strong></p>
<p>You could also consider <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSet</a> where each instance of your app get its own volume. This makes your app <em>distributed</em> but typically not <em>horizontally scalable</em>. Here, your app typically needs to implement replication of data, typically using <a href="https://raft.github.io/" rel="nofollow noreferrer">Raft</a> and is a more advanced alterantive.</p>
