Multiple version of software on same namespace

[rgonc...@gmail.com]

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.

I don't see any other way besides using namespaces. What am I missing something?

Thanks for any help.

[Tim Hockin]

What are you trying to do? Do you want 2 versions in perpetuity or do
you want to do some form of switchover?

> --
> 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-use...@googlegroups.com.
> To post to this group, send email to kubernet...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.

[Rodrigo Campos]

On Mon, Oct 30, 2017 at 03:34:00AM -0700, rgonc...@gmail.com 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?

[rgonc...@gmail.com]

On Monday, October 30, 2017 at 3:31:01 PM UTC, Tim Hockin wrote:
> What are you trying to do? Do you want 2 versions in perpetuity or do
> you want to do some form of switchover?

I'm trying to figure out the best approach to create an application deployment environment using Kubernetes. Usually the same product has at least two development branches. A maintenance branch (ex. 1.3.x) and a trunk version (ex. 2.0).

So, it's not a switchover. The two version will coexist.

[rgonc...@gmail.com]

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).

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 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. Doing that implies changing kubernetes deployment descriptors, clients must change the service they reference, etc... not a good idea.

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.

[Warren Strange]

What you are describing is a really good use case for namespaces.

If you really want to deploy multiple instances to the same namespace, you could have a look at how some of the Helm charts do this.  

Some charts use dynamic labels to  (e.g. app={{ .Release.Name }} ) to distinguish multiple instances of the same application.  You 

can "helm install" many copies, with each one getting unique labels that can be used by your service label selectors.

[Rui Goncalves]

Thanks Warren.  Really helpful.

I'll tale a look at helm.

--
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/_zeW8m9ZX9g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Rodrigo Campos]

On Tuesday, October 31, 2017, <rgonc...@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, rgonc...@gmail.com 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! :-)

[Tim Hockin]

Rodrigo replied, but I will echo some of his comments..

On Tue, Oct 31, 2017 at 7:08 AM, <rgonc...@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, rgonc...@gmail.com 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).

You can create as many Deployments (or DaemonSets, or Jobs, or
Pods...) as you want in a given Namespace. The only rule is that they
have to have different names. If you want to select between them,
they probably need different labels, too.

Example:

deploy foobar v1 as "foobar-v1" with labels "app=foobar, version=v1"
deploy foobar v2 as "foobar-v2" with labels "app=foobar, version=v2"

All the pods will run in the same Namespace.

> 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 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. Doing that implies changing kubernetes deployment descriptors, clients must change the service they reference, etc... not a good idea.

I don't know what you mean by resource usage. If you mean youwant to
limit quota, then yes one namespace is good at that. If you mean
actual CPU/memory usage on a machine, Namespaces are the wrong stage
of the deployment. Can you clarify what you are trying to prevent?

Simply put you are asking for something that doesn't make sense. You
want them to be in the same namespace, but not have different names.
That is exactly what Namespaces are for - being able to reuse the same
relative-names. Assuming that these versions are different for a
reason, your clients HAVE TO know which one they want, right? Or are
you just load-balancing across versions, and clients don't care which
version they get?