CARTER: If you're working on Kubernetes in a production
environment, especially on a larger project or team,
you've probably run into namespaces.
We haven't talked about them before,
but today, we change that.
Hello, Caslyn.
Hello, Caslyn?
Hmm, Caslyn isn't in this room.
Maybe I'll go into another one.
Hello, Caslyn?
CASLYN: Oh, hi, Carter.
What are you doing here?
CARTER: I came to talk to you about namespaces,
but I don't think I could reach you before.
CASLYN: That's kind of ironic, actually.
Namespaces are a tool to keep Kubernetes objects separated,
as well.
If you're in the wrong space, you
won't be able to communicate with your objects.
CARTER: I could see that being useful.
Kind of like how containers allow multiple applications
to share one operating system, namespaces
allow multiple Kubernetes objects to share one cluster.
CASLYN: Right, imagining it as a sort of virtual cluster
makes a lot of sense, because a namespace groups and isolates
Kubernetes objects across nodes.
And it's not quite as strict as container isolation,
because it's still possible to access Kubernetes objects that
are in other namespaces.
CARTER: That's good to know.
So a namespace is a virtual cluster
that's used to make it easier for large teams to work.
I've seen these before.
I was working on a project where the test and production objects
were in separate namespaces.
CASLYN: Sure, I've seen that.
Another benefit of namespaces comes in
with setting permissions.
CARTER: Oh, yeah, I remember.
The admin set it up so that only certain people could
push a build to production, but anyone
could push a build to test.
CASLYN: They would have done that using
Kubernetes role-based access controls, or RBAC.
Using RBAC, an administrator can give each user
a role, which sets their permissions
inside a specific namespace.
CARTER: That makes sense.
So the people on my team must have
had roles that gave them access to test,
but only a few people had roles that
gave them access to production.
CASLYN: Right.
Let's talk more about how to set up the namespaces themselves.
We can cover RBAC, or role-based access controls,
in a future episode.
CARTER: Sounds good to me.
So how do I get started using namespaces?
CASLYN: Technically, you already are.
Kubernetes starts with four initial namespaces.
You can check them out with the kubectl get namespace command.
CARTER: According to the docs, kube-system
is for objects created by the Kubernetes system.
kube-public is mostly reserved for cluster usage in case
some resources should be visible and readable publicly
throughout the whole cluster.
kube-node-lease is for the lease objects associated
with each node, which improves the performance
of the node heartbeats as a cluster scales.
And the default namespace is for objects
with no other namespace.
It's like one of those bottom drawers in the kitchen--
just throw anything in there.
CASLYN: You can get more info about any of these namespaces
using the kubectl get and describe commands.
For instance, you'll see that describing the default
namespace returns something like this.
Note that these details show both resource quota,
if present, as well as resource limit ranges.
CARTER: Resource quotas and resource limits?
CASLYN: Resource quota tracks aggregate usage of resources
in the namespace and allows cluster operators
to define hard resource usage limits
that a namespace may consume.
A limit range defines minimum and maximum constraints
on the amount of resources a single entity can
consume in a namespace.
CARTER: That seems useful if I need
to make sure resource usage is staying within certain bounds.
CASLYN: Yep, resource quotas and limits
are an important tool for administrators.
CARTER: Since namespaces are Kubernetes objects,
I bet I can interact with them using the kubectl create
and delete commands.
CASLYN: Yes.
One thing that's a little different
is that since namespaces hold other Kubernetes objects,
if you want to get, create, delete, or otherwise
operate on objects in a namespace,
you must specify that with the --namespaces flag.
CARTER: It seems like a lot of extra typing,
but I guess the shorthand -n isn't all that bad.
CASLYN: We can actually shorten "deployment" here to "deploy,"
too.
There are a lot of convenient shorthand versions
of commands in Kubernetes.
CARTER: That is convenient, though it still
seems annoying to have to type the namespace I'm
working in to every command.
CASLYN: Well, you're in luck.
If you're going to be working out
of the same namespace for a while,
there's a way to set kubectl to automatically use
that namespace for all subsequent kubectl commands.
To do that, you would use kubectl config set-context.
CARTER: Now that sounds handy.
CASLYN: So I think that's about it for the basics.
You should have just about everything
you need to know to understand namespaces in case
you see them in the workplace.
CARTER: I think so.
Let me see if I've got this right.
A namespace is a virtual cluster that
lets multiple groups of users share a cluster.
Each one has its own resources, policies, and constraints,
meaning only people or objects in my namespace
will see my pilot services, and other Kubernetes objects.
Also, I can define rules for who can do what in my namespace,
and I can enforce how many resources
can be consumed by objects in my namespace
using resource limits and quotas.
CASLYN: Exactly.
Namespaces are a very useful tool for everything
you just mentioned and more.
CARTER: Wow, many thanks to Caslyn
for sharing knowledge about namespaces.
For more information about how, when, and why to use them,
please check out the documentation link below.