<p>I have managed to successfully scale up and down an Ignite cluster under a Kubernetes cluster.</p>
<p>Increasing the number of &quot;replicas&quot; creates new Ignite PODs which join the cluster using &quot;Kubernetes IP Finder&quot;.</p>
<p>Decreasing the number of replicas drops some PODs and the respective Ignite nodes leave the Ignite cluster.</p>
<p>This is perfect, I can increase and decrease the size of the Ignite cluster on demand.</p>
<p>So far I haven't enabled &quot;persistence&quot; in my Ignite cluster.</p>
<p>But, if the Ignite nodes had &quot;persistence&quot; enabled then they would have to share the data storage as the nodes are not pre-defined but dynamic.
This implies that each Ignite node wouldn't have its own data anymore and therefore co-location is not possible.
How would Ignite choose to split the work?</p>
<p>Also, since all nodes are sharing the same storage they will start to compete for access to the data storage and the WAL.
Wouldn't this become a performance bottleneck?</p>

upperlimit
<p>Setting a shared drive doesn’t influence the data partitioning algorithm and affinity co-location. Each node creates a unique folder on that shared drive for data it’s responsible for.</p>
<p>It’s right that the shared drive can become a bottleneck. You need to arrange several drives and spread them among pods. GridGain folks might have more specific recommendations as long as they provide an Ignite managed service. Try to get insights from them: <a href="https://www.gridgain.com/products/managed-services/gridgain-nebula" rel="nofollow noreferrer">https://www.gridgain.com/products/managed-services/gridgain-nebula</a></p>
