Welcome back everybody.
In this section we're going to talk about namespaces these logical boundaries that we use to group closely
related resources in our cluster.
But before we do that I want to start off by imagining that we've got this Kubernetes cluster deployed
on AWS.
All right.
We've got many master nodes that decide when and where your container workloads will run, and worker
nodes that do the actual work of running your containers.
So each worker node has a container runtime that's used to create the containers.
The Cubelet which wraps the pod construct around the containers, the kube proxy, which takes care
of all the internal networking.
So we've got all of these things happening behind the scenes.
Right.
And these worker nodes and master nodes, they work together.
They collaborate in a very seamless way.
That gives us the illusion that we're not working with all of these different machines, that we're
working with just one, uh, Kubernetes environment, one Kubernetes entity.
So while the Kubernetes cluster is physically divided into many, many machines, we kind of don't get
that impression when we're interacting with it.
Using the kubectl command line tool, we get the impression that we're working with just one entity
now because we're prototyping, uh, we only have a single node cluster, our laptop that takes the
role of master and worker node.
So it is indeed one entity.
But when you have a cluster on, let's say AWS or Azure, you're going to have many, many machines
running Kubernetes that work together to, you know, orchestrate your containers.
But regardless, the experience as the as a developer is not going to change whether I'm using a single
node cluster or a multi node cluster, it's always going to feel like I'm working with this, with this
one Kubernetes entity that's managing all of my pods.
So while the cluster is physically divided into many, many machines.
As developers, when we're interacting with the cluster, we get the experience that it's simply divided
into logical boundaries called namespaces.
A namespace is not a physical construct.
It doesn't actually consume any resources, any memory or CPU.
It's this logical construct created by the Kubernetes control plane that makes it really easy for us
to group resources that are closely related.
They are these invisible boundaries, these illusions created by the etcd database that make it really
easy for us as developers to manage closely related resources.
So I could have one namespace called Great Submission that stores all of the resources involved in the
great submission experience.
So the great submission portal, the great submission API, I could have one namespace called Freescale
that has all the resources involved in setting up API gateways.
I could have one namespace for logging that contains, you know, Elasticsearch Logstash, Kibana,
one namespace for monitoring that has Prometheus and Grafana, whatever you need to monitor and visualize
your metrics.
So these namespaces allow us to group closely related resources.
And this is really important because let's say you're working at an at an enterprise.
You can't just access the cluster, okay.
You're given credentials that you need to log in with.
And based on your role, you can be given access to certain namespaces and be restricted to interact
with other namespaces.
So if your role is to just work on the great submission application, you would typically only be given
access to the namespace that contains all of the great submission resources.
So namespaces allow us to implement role based access control.
Uh, namespaces can be given resource quotas.
So I can say something like the group of resources for great submission.
Only allocate to them one gigabyte of memory and one CPU core.
So you can do things like this when you group your resources under one namespace under these logical
groups.
Okay.
Enough preamble.
Let's go ahead and look at things uh, in Kubernetes.
So I'm going to clear the output from before.
And what I'm going to do is just say section three.
All right.
And in order to maintain ordering I'm going to preface each folder with section one.
0203 and I'm going to copy all of the contents of section two into section three.
And let's begin.
We'll start by saying kubectl get namespaces And I'm not running my Kubernetes cluster.
Let me go ahead and start this up.
Doo doo doo doo doo doo.
It should be started up now.
Um, kubectl get namespaces.
So you can see that my cluster has been divided into these logical groupings.
This default namespace groups together default workloads, this ingress engine X namespace groups together
all resources related to ingress, which we'll talk about in another section.
You probably don't have that namespace, so don't worry.
The kube system namespace, which groups together all the Kubernetes critical system level components.
So our cluster is logically divided into these groupings called namespaces.
And by default we've been deploying all of our pods into the default namespace.
So if I say kubectl get pods and if I say dash n default.
So look inside of the default namespace.
We've actually been deploying our pods to the default namespace this whole time.
Okay, we don't want to do that.
We want to put them in a in a great submission namespace.
Okay.
So we're going to delete pods dash dash all automatically.
When you don't specify a namespace your current context is set to default.
So it's going to delete all the pods in the default namespace.
But just for clarity I'll say dash n default.
Delete all the pods in the default namespace.
Choo choo choo choo choo takes a bit of time.
Okay, any time now.
There you go and I'll CD out of section two.
CD into section.
003.
Section three.
And then what I can do is deploy every single artifact inside of the section three folder, so I can
apply everything inside of the current directory.
Dot means current directory.
Apply everything inside of section three.
Apply it in the namespace.
Great submission.
And what am I doing?
I haven't even created that namespace yet.
Sorry about that guys.
Kubectl create namespace.
Great submission.
Okay, if I say kubectl get namespaces beautiful.
We have a great submission namespace where we can put all of our great submission resources in all of
our great submission services, all of our great submission pods, we can group them all under the great
submission namespace.
I'll say kubectl apply dash f apply every single configuration in the current directory and do it inside
of the great submission namespace.
Service is invalid.
Invalid.
Valid.
Oh, remember how when the default namespace I deleted all the pods?
I still didn't delete the services from there either.
And here I'm trying to deploy a node port that conflicts with one that we already have.
So back inside of the default namespace I'm going to say kubectl get services dash and default.
And I want to delete the great submission API and the great submission portal.
So I'll say kubectl delete uh service.
Great submission API.
Um I could have said dash and default and it would have known to do it inside of the default namespace.
But you know what?
I'll do it for the portal.
Just to be clear, vary things up dash and default Same thing.
Now if I say kubectl get services and default, they're both gone.
So now I'm just going to rerun my command apply everything.
So now our great submission portal service was created.
Beautiful.
Everything is happening.
Get pods and services inside of the grade submission namespace.
So now all of our pods are inside of the grade submission namespace.
All of our services are as well.
Everything should work the same way.
You can feel free to test this out now instead of always saying dash n grade submission when we're applying
our artifacts.
What I want to do.
So I just did this to show you, because you should always be aware of different ways of doing things.
What you can also do is specify the namespace within the configuration itself.
That way, no matter what the current context is, it'll always deploy in that namespace.
Okay.
It's uh, I believe it's, uh, less error prone when you concretely define it inside of the configuration
itself.
So within the metadata of each, um, definition, we say the name of the primitive as well as which
namespace it will belong to.
Okay.
So spec always defines the behavior of that Kubernetes object and the metadata things like name namespace
labels etc..
All right I think we're good now.
So now what I want to do is delete every single pod.
Delete pods and services dash dash all inside of the great submission namespace.
Okay.
So again, whether we're using a single node cluster as we are on our, uh, local machine currently,
or whether we're interacting with a multi node cluster on AWS.
We don't get the impression as developers that the cluster is actually made up of all of these physical
machines that are collaborating together to, you know, schedule containers, manage all the control
loops, set up the networking, etc. we don't.
All of this is abstracted away from us, and all we see is this one entity with all of these logical
boundaries that make it really easy for us to manage our resources.
Okay, so we've deleted everything.
And now if I simply apply every single configuration inside of the section three folder without specifying
the namespace in my command, they're all going to go there by default.
How do I verify kubectl.
They're all going to go to the great submission namespace by default.
I can verify this by saying kubectl get services.
Get pods inside of the great submission namespace.
If they're there, that means everything worked.
Of course it's going to work.
That's all we are done.
See you in the next one.