On Tuesday, October 31, 2017, <rgoncal...@gmail.com> wrote: > On Tuesday, October 31, 2017 at 7:41:45 AM UTC, Rodrigo Campos wrote: > > On Mon, Oct 30, 2017 at 03:34:00AM -0700, rgoncal...@gmail.com > <javascript:;> wrote: > > > I'm trying to figure out what's the best approach to deploy multiple > versions of the same software in kubernetes without relying on namespaces. > According to the docs: > > > > > > "It is not necessary to use multiple namespaces just to separate > slightly different resources, such as different versions of the same > software: use labels to distinguish resources within the same namespace." > > > > > > The only way (that I know of) to separate multiple versions of same > software on the same namespace is naming services in accordance to software > version, adjust the selector field and tag pods appropriately. This has > maintenance overhead and I'm required to reference services with a > different name according to the desired version. I don't think this is a > solution. > > > > Why not? What is the problem you want to solve? > > > > > > > > I don't see any other way besides using namespaces. What am I missing > something? > > > > I think services is the way to do it, with labels on deplyoments, but I > might be > > missing the details of what you want to do. Can you pelase elaborate? > > Basically I want to be able to deploy two distinct versions of the same > software on the same kubernetes cluster. This is a cluster used for > development and it's usual to have multiple versions of the same software > (ex. maintenance version and evolution version).
Two objects kind deployment will do that, right? > I can create one namespace for each version, but I'd rather not because > I'd like to limit resource usage per software, not per software version. > But Limit how? You can limit each deployment in the yaml, you can use the "limits" kind or, as you say, you can limit in namespaces too. For example, you can have a limit range object for containers: https://kubernetes.io/docs/tasks/administer-cluster/memory-default-namespace/#create-a-limitrange-and-a-pod But how is that you need to express the limit? I mean, if you know you will have only 2 versions, and only 2, then specifying per version might be enough. If the possible idle resources is a problem, then probably not. Etc. Namespaces might be fine for that, just depends on how you need to limit :) > without using namespaces, the only way (like I said, that I'm aware of), > is to codify the version of the service on the name (serviceA-v1.1; > serviceA-trunk; etc...). Definitely I don't want to do that. Again, why not that? I don't really follow > Doing that implies changing kubernetes deployment descriptors, clients > must change the service they reference, etc... not a good idea. Yes, different deployments will have different labels, that sounds reasonable. And that would be the case even if you use namespaces, right? Also, different clients will have to connect to different services. Isn't that what you want? I don't see how namespaces changes anything of this. Or do you want some canary deployment or something like that? If not, I don't see what you mean with "clients must change the service they reference". I thought you wanted different services exposed (so yeah, everyone connects to what they want). > > I'm asking because the statement on the docs saying the using namespaces > it's not necessary to separate multiple versions of the same software. > However I think it is. Having different deployments, in the same namespaces, allows you to run different software versions. So, I might be missing what you mean, or the answer is "no" :-). If you have different namespaces but want to run more than one software version, then you will have more than one deployment. No matter namespaces nor anything (if I'm not missing something, and of course plain pods, replication controller, etc. are included). You can think of different namespaces as different *logical* Kubernetes clusters (i.e not different physical clusters). If you haven't, I encourage you to play with namespaces, limits, etc. It's fun, and if you consider open a PR or issue for the documentation! :-) -- 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.
