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.
