You can't use PVClaim and Deployment together. You will get a single claim to a single EBS volume. Unfortunately this is a weird intersection of subsystems.
PVClaim says "This data has identity, and I will manage its lifetime", and Deployment says "These pods have no identity, and you should manage their lifetime". What you're describing is CLOSER to StatefulSet, but that feels heavy. I've been contemplating how to address this point for a while, so let me ask some questions, if I may? Assume you start with a Deployment with 1 replica. It gets an EBS, you store some stuff in there. 1) The single replica gets killed for some reason, maybe the node goes down for too long. A new replica is born to replace it. Do you expect the data to still exist, or is it OK to start the cache over? 2) Now you scale to 5 replicas. Is it OK for all of new pods to get empty EBS'es or do you expect the data to pre-populate? 3) Now you scale to 2 replicas (diurnal cycle). Is it OK to destroy 3 Pods and 3 EBSes at random? Or do you expect the disks to stick around? How many of them? For how long? Thanks for considering these questions - it will help shape the future designs. On Thu, Mar 30, 2017 at 10:20 PM, Adam Schepis <a...@cloudhealthtech.com> wrote: > argh. hit post before i fixed the topic :\ > > > On Friday, March 31, 2017 at 1:19:54 AM UTC-4, Adam Schepis wrote: >> >> I have a service that i would like to deploy on my cluster (on AWS). I am >> doing so with a Deployment. Each pod will require an available local disk >> cache for its purposes. I was hoping to accomplish this through dynamic >> provisioning of EBS volumes for each pod (via a PVC). The behavior that I >> get is an EBS volume provisioned dynamically, but then all pods are >> scheduled to the same node. I would like to avoid this. >> >> In an ideal scenario, each node would have a dynamically provisioned PV >> that any pods scheduled on that node can attach. >> >> I have attempted to RTFM but am still missing something.. Perhaps I'm >> thinking about this the wrong way? Is there another way or a better way to >> do this? >> >> Any feedback would be greatly appreciated > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes user discussion and Q&A" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-users+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-users@googlegroups.com. > Visit this group at https://groups.google.com/group/kubernetes-users. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
