- [Instructor] Namespaces are a fundamental concept
to add multi-tenancy to your Kubernetes instance.
Kubernetes provides multiple virtual clusters backed
by the same physical cluster.
These virtual clusters are called namespaces.
There are four primary use cases.
One, roles and responsibilities in an enterprise.
Two, partitioning landscapes,
for example, dev vs test vs production.
Three, customer partitioning for non-multi-tenant scenarios.
For example, if you're a consulting company
and you have multiple customers, you can use this feature.
And finally, for application partitioning as well.
First, let's talk about the reuse case related to roles
and responsibilities in an enterprise.
Enterprises have many teams that typically operate
independently of each other and might have some shared
interfaces and APIs to communicate with each other.
The use of namespaces is perfect in this scenario,
because teams are able to operate independently
without stepping on each other.
Namespaces also prevent them from confusing services
and deployments that might not belong to them.
Here are a couple of things you'll need to watch out for.
Plan in advance how you want to manage your enterprise
in a Kubernetes environment.
Setting standards up front will help you in the long-term
with infrastructure management.
Don't simply transpose existing on-premise controls
and procedures to the new environment.
This might result in bringing your existing infrastructure
baggage to the new environment,
which is supposed to be more agile.
Another common pattern is using namespaces for
Dev, Test, and Production environments.
With most teams building a continuous integration,
or CI pipelines, you can easily define CI pipelines
to deploy an entire environment in a quick and easy fashion.
Some anti-patterns to watch out here for are,
sometimes you will end up with a really large namespace
because you have many applications that are running.
In these scenarios, it might be good to create additional
namespaces for groups of application.
For example, E-Commerce Dev namespace
for all E-commerce related applications.
Another scenario is,
you might end up with too many environments.
Just because you can, does not mean that you should.
Don't abuse the feature because it will result in
too many unnecessary environments.
If you don't use a staging deployment,
or you don't use a staging namespace, then don't create one.
Consulting companies and small software vendors
might use this method a lot.
You could create a namespace for each customer or project
to keep them distinct, while not needing to worry about
reusing the same names or resources
across different projects.
A new side effect of using the Helm package manager
introduced by Kubernetes, is that k8s applications,
which are typically comprised of
deployment, services, et cetera, have gotten very complex.
And when installing these applications,
they're delivered in their own namespace,
which makes it easier to encapsulate the application
in one single spot in your Kubernetes cluster,
all in just a single namespace.
When you're done using the application,
you can just delete the namespace.
Interacting with namespaces is very straightforward.
Let's discuss the basic commands related to them.
To just get all your existing namespaces, you can just do a
kubectl get namespaces.
To create one,
all you have to do is do a kubectl create namespace
followed by the name you want to use.
Similarly, to delete the namespace,
it's a kubectl delete namespace followed by
the namespace you'd like to delete.
When deploying a specific resource,
like a deployment to a specific namespace,
just add the -n namespace-name,
and the resource will exist in that specific namespace.