What is the difference between namespaces and contexts in Kubernetes?

Question

I found specifying like kubectl --context dev --namespace default {other commands} before kubectl client in many examples. Can I get a clear difference between them in a k8's environment?

Martinet

Answer 1

The kubernetes concept (and term) context only applies in the kubernetes client-side, i.e. the place where you run the kubectl command, e.g. your command prompt. The kubernetes server-side doesn't recognise this term 'context'.

As an example, in the command prompt, i.e. as the client:

• when calling the kubectl get pods -n dev, you're retrieving the list of the pods located under the namespace 'dev'.
• when calling the kubectl get deployments -n dev, you're retrieving the list of the deployments located under the namespace 'dev'.

If you know that you're targetting basically only the 'dev' namespace at the moment, then instead of adding "-n dev" all the time in each of your kubectl commands, you can just:

1. Create a context named 'context-dev'.
2. Specify the namespace='dev' for this context.
3. Set the current-context='context-dev'.

This way, your commands above will be simplified to as followings:

• kubectl get pods
• kubectl get deployments

You can set different contexts, such as 'context-dev', 'context-staging', etc., whereby each of them is targeting different namespace. BTW it's not obligatory to prefix the name with 'context'. You can also the name with 'dev', 'staging', etc.

Just as an analogy where a group of people are talking about films. So somewhere within the conversation the word 'Rocky' was used. Since they're talking about films, it's clear and there's no ambiguity that 'Rocky' here refers to the boxing film 'Rocky' and not about the "bumpy, stony" terrains. It's redundant and unnecessary to mention 'the movie Rocky' each time. Just one word, 'Rocky', is enough. The context is obviously about film.

The same thing with Kubernetes and with the example above. If the context is already set to a certain cluster and namespace, it's redundant and unnecessary to set and / or mention these parameters in each of your commands.

My explanation here is just revolving around namespace, but this is just an example. Other than specifying the namespace, within the context you will actually also specify which cluster you're targeting and the user info used to access the cluster. You can have a look inside the ~/.kube/config file to see what information other than the namespace is associated to each context.

In the sample command in your question above, both the namespace and the context are specified. In this case, kubectl will use whatever configuration values set within the 'dev' context, but the namespace value specified within this context (if it exists) will be ignored as it will be overriden by the value explicitly set in the command, i.e. 'default' for your sample command above.

Meanwhile, the namespace concept is used in both sides: server and client sides. It's a logical grouping of Kubernetes objects. Just like how we group files inside different folders in Operating Systems.

Shalandashale

Answer 2

You use multiple contexts to target multiple different Kubernetes clusters.You can quickly switch between clusters by using the kubectl config use-context command.

Namespaces are a way to divide cluster resources between multiple users (via resource quota).Namespaces are intended for use in environments with many users spread across multiple teams, or projects.

Menstruum

Answer 3

A context in Kubernetes is a group of access parameters. Each context contains a Kubernetes cluster, a user, and a namespace. The current context is the cluster that is currently the default for kubectl: all kubectl commands run against that cluster. Each of the context that have been used will be available on your .kubeconfig.

Meanwhile a namespace is a way to support multiple virtual cluster within the same physical cluster. This usually will be related to resource quota as well as RBAC management.

Huntley

Context -> a cluster + a user + a namespace Namespace -> a virtual cluster under the above cluster (mainly to allocate resources based on quota) Is this understanding correct? – Masochism

Context -> a cluster + a user + a namespace Yes this is what's defined on your kubeconfig for the namespace it's a "virtual cluster" abstraction where your namespaced objects live in. In each of namespace you can also define access control as well as resource quota. – Huntley

Can I say Context is a cluster and name space is division inside the cluster? – Politic

Answer 4

A context is the connection to a specific cluster (username/apiserver host) used by kubectl. You can manage multiple clusters that way. Namespace is a logical partition inside a specific cluster to manage resources and constraints.

Zinciferous

Answer 5

difference between namespaces and contexts in Kubernetes presented in a table

Aspect	Namespaces	Contexts
Purpose	Namespaces allow you to isolate objects into distinct groups, enabling you to operate only on those belonging to the specified namespace.	A context binds together a cluster, a user, and the default namespace.
Resource Grouping	Namespaces are used to group resources.	Contexts do not directly group resources but provide a way to specify the cluster, user, and default namespace to use.
Object Naming	Kubernetes namespaces provide a scope for object names, allowing you to use the same resource names multiple times across different namespaces.	Contexts do not directly impact object naming.
Multiple Existence	There can be multiple namespaces in a Kubernetes cluster.	There can be multiple contexts defined in the kubeconfig file, but only one is the current context at any given time.

Hope this help you better.

Source kubernetes-in-action

Aldine