I think this is exactly the sort of thing that a custom deployment-like operator is good for. You have particular needs that are not easily satisfied with existing constructs. CRDs and controllers let you build this, and figure out how you want it to work.
Later, maybe, you can solicit other users, and see if it satisfies them too. Or not. On Jan 5, 2018 11:09 AM, "Michele Bertasi" < michele.bert...@brightcomputing.com> wrote: > Hi everyone, > > I'm trying to implement an operator to manage a Custom Resource Definition > for this proof-of-concept application: > * a user creates an instance of my CRD > * the operator creates a POD for that CRD > * after a specified timeout, both the POD and the CRD disappear > > the use case is a scratch space for users, where a container with sshd is > created, they can connect there and play (every POD gets a different secret > mounted with different allowed SSH keys). Then the container is removed. > The PODs will be exposed through a NodePort service or a L4 ingress (but > that's not the point of my question). > > Of course I can create all the PODs myself through the operator, then > manage eventual POD deletions, scaling up and down, etc. > What I'm trying though is to not reinvent the wheel and try to reuse as > much as possible existing constructs, so I was looking at > ReplicationControllers for example. I could let a RC manage the number of > replicas, and when I need a new POD, I just scale the number up. When I > have to downscale it gets more tricky, because I have to delete a specific > one (and not a random one). I also looked at StatefulSets but in that case > downscaling deletes the POD with the highest ID. So I'm a bit stuck. > > What do you guys suggest? Is there anything I can reuse or I really need > to manage the resources myself? Maybe there's also a similar CRD that I > could reuse; the idea that a POD has a definite lifetime doesn't seem so > crazy to me. > > Thanks > > -- > 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.
