Makes sense. Thanks Tim. On Fri, Jan 5, 2018 at 8:40 PM, 'Tim Hockin' via Kubernetes user discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
> 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.bertasi@ > 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 a topic in the > Google Groups "Kubernetes user discussion and Q&A" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/kubernetes-users/A9EfSw8-RlI/unsubscribe. > To unsubscribe from this group and all its topics, 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.
