The community does not have (and won't for a while, if ever) a "preferred" model. It's very much organic exploration for now. Opinions proliferate and it's possible they will never converge. That's not a bad thing, IMO.
On Mon, Apr 30, 2018 at 8:13 AM David Rosenstrauch <dar...@darose.net> wrote: > Thanks for the suggestion, Tim. Looks like that might fit the bill. > I'll kick the tires on it a bit. > > Is kustomize the k8s project's preferred (or suggested) way to handle > this type of situation? > > Thanks, > > DR > > On 04/27/2018 07:06 PM, 'Tim Hockin' via Kubernetes user discussion and > Q&A wrote: > > Does this head in the direction you want? > > > > https://github.com/kubernetes/kubectl/tree/master/cmd/kustomize > > > > On Fri, Apr 27, 2018 at 10:52 PM David Rosenstrauch <dar...@darose.net> > > wrote: > > > >> We've been using Kubernetes to get a dev version of our environment up > >> and running, and so far the experience has been great - nearly a dozen > >> services up and running, and Kubernetes has made the whole process very > >> straight-forward. > >> > >> However, we're now looking at moving this implementation towards a > >> production release and things are starting to get a bit more > >> complicated. Specifically, we're envisioning that we're going to wind > >> up with different "variants" of each service, that each differ only > >> slightly from each other. For example, for service X, we'll likely > have: > >> > >> * a dev, qa, and prod version, each of which talks to different database > >> backends, writes to different locations on a shared file system, etc. > >> > >> * in the prod version, we're foreseeing that there'll likely need to be > >> a way to specify that a portion of the pods running service X need to be > >> segregated to run on a specific set of hosts that are dedicated to > >> "premium customers". > >> > >> > >> Given how we're currently configuring k8s (just using raw yaml files) > >> it's easy to see that the net result would wind up being a set of nearly > >> identical yaml files for each service - i.e.: serviceX-dev.yaml, > >> serviceX-qa.yaml, serviceX-prod-premium.yaml, > >> serviceX-prod-standard.yaml, etc. > >> > >> That's obviously not an efficient solution to this issue. So I'm > >> wondering: what's the generally accepted kubernetes "best practice" for > >> handling this type of situation? (Or is there even one?) > >> > >> I did a quick search this afternoon, and came upon a number of community > >> discussions about things like "templating" and "parameterization of yaml > >> files", as well as some 3rd party tools that seem to implement this type > >> of functionality (e.g., Helm). But there's a lot out there, and I > >> wasn't able to see any consensus. > >> > >> Is there any Kubernetes standard approach to handle this sort of > >> situation? (Or is there likely to be soon?) > >> > >> Thanks, > >> > >> DR > >> > >> -- > >> 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. > -- 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.
