Recently the following shell command passed my desk:

kubectl config use-context

I ask myself, wow use-context, what a powerful command. What’s the intention of this command? Context is a meaningful word and using a special context with one instruction could be awesome.

In general context could be described like:

The surroundings, circumstances, environment, background or settings that determine, specify, or clarify the meaning of an event or other occurrence. – wiktionary

However kubectl is a command line interface of the cluster management platform kubernetes. And kubectl is just a tool to handle a zoo of application containers hosted in a distributed system landscape based on docker and kubernetes.

It turned out that the command use-context just switches between configurations which set a cluster, a user and a namespace. Though the next meanigful word passed by: namespace. By studying kubernetes‘ website I found a few definitions respectively descriptions of namespace – luckily with a similar intention.

Admin guide

A Namespace is a mechanism to partition resources created by users into a logically named group.

Concept guide

A namespace is like a prefix to the name of a resource. Namespaces help different projects, teams, or customers to share a cluster, such as by preventing name collisions between unrelated teams.

User-Guide – Glossary

Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.

Thus it is nothing more than keeping things unique and eventually keeping things separated. A more general and abstract description of a namespace is given by Wikipedia:

In computing, a namespace is a set of symbols that are used to organize objects of various kinds, so that these objects may be referred to by name. Prominent examples include:
[…] computer networks and distributed systems assign names to resources, such as computers, printers, websites, (remote) files, etc. Wikipedia

Finally a namespace in kubernetes is more or less treated as I would expect it. But quite frankly by skimming the documentation I got the impression there must exit something with security and restricting access to namespaces too. Especially in the IT keeping sings separated means keeping things secure in terms of getting access to it.
After further research a kubernetes blog post appeared, which elaborates the usage of namespaces and furthermore provides dos and don’ts using namespaces when planning kubernetes clusters. Kubernetes Namespaces: use cases and insights.
They are aware of such security concerns and perhaps plan to address them soon:

[…] Kubernetes does not (currently) provide a mechanism to enforce security across Namespaces. You should only use Namespaces within trusted domains (e.g. internal use) and not use Namespaces when you need to be able to provide guarantees that a user of the Kubernetes cluster or ones its resources be unable to access any of the other Namespaces resources. This enhanced security functionality is being discussed in the Kubernetes Special Interest Group for Authentication and Authorization […].

To get back to the term context, luckily at the end of that post it appeared:

Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. […] The other way to avoid using the wrong namespace is to set a kubectl context.

A quite nice and concise explanation of context in regards to kubernetes – my favorite one.

Finally I’d like to encourage you to read that post and get an insight how to use namespaces and when to switch the context.