Developing microservices on Kubernetes involves more than just building and deploying containers. Those containers need to be able to communicate. An unreachable API is useless. And when one fails, the others that depend upon it also fail. So as you add more containers and more features, you will need to understand cluster networking and how to ensure that communication with your pods is secure.

Before I dive into networking, I want to review namespaces. Now namespaces aren't directly related to networking, but they will be mentioned frequently. So I need to make sure you have a good handle on them. Namespaces provide an easy way to organize your containers. Kubernetes deploys your containers as pods. And your pods can be grouped together in the same namespace or they can be separated into different namespaces. It's sort of like folders in a filesystem, except they are not hierarchical.

Namespaces can contain things like pods, but not other namespaces. Every pod in a Kubernetes cluster is assigned to a namespace. If you do not specify a namespace during deployment, then the pods are automatically deployed to a namespace called default. So it is possible to use Kubernetes without even knowing what a namespace is. For every command you run, Kubernetes will always assume the default namespace, unless you specify a different one.

In smaller environments, this default namespace is usually sufficient. If you only have a few users running a few different containers, then using a single namespace is not a problem. Why introduce extra complexity if it is not needed, right? However, in larger environments it's a little different. Running hundreds or thousands of different containers in the same namespace can make even basic tasks difficult.

Imagine having to scroll through a list of hundreds or thousands of containers, just to find the one you are interested in. The difficulty is further compounded as you introduce more users. When you have many different teams trying to share the same cluster, conflict is inevitable. Someone is going to accidentally overwrite or delete something, and it's going to impact other teams. And what about several teams trying to use the same name for different things? Namespaces make it easier to share a cluster by dividing it up into virtual clusters. You can create and assign a different namespace to each team. So now your teams will each have their own sandbox to work with. They can list out their own pods, and they won't see anyone else's. They also won't need to worry about naming conflicts. The names only need to be unique within a namespace, not across them. The proper use of namespaces will minimize conflicts and prevent accidental breakage.

One thing to note: namespaces do not provide isolation. Containers running in one namespace can still communicate with containers in another. That's great if your teams need their products to talk to each other. Now there is a mechanism you can use to limit communication, but we will cover that a little later. For now, just remember that namespaces provide organization, not security. By default, a GKE cluster actually has four namespaces pre-defined: default, kube-system, kube-public, and kube-node-lease.

Now default is the default namespace which I previously mentioned. The other three kube- namespaces are used internally by Kubernetes, and most people can simply ignore them. It is generally best to leave the kube- namespaces alone, especially on a managed cluster such as GKE. To help give you a better idea of how namespaces work, let me show you a quick demonstration.

So I am going to spin up a GKE cluster, create a couple of namespaces, and then deploy a few containers to those namespaces. First, I'll create a GKE cluster. Now I don't need anything special, just a basic cluster I can run some commands on. So I am going to select the, my first cluster quickstart option. Now, if you are going to follow along, you can pick the option My first cluster under the cluster setup guides. And I am going to accept all the default options.

Now when I click on Create, it's going to create the cluster. If I wanted to, I could create the same cluster using the command line. And so you can choose the command line option to get that command. I am assuming you already know how to create a cluster, so let's keep this simple and just click on the Create button instead. Now creating this cluster will take a while, so let me skip ahead. All right. Now that my cluster has been created, I am going to switch to using the command line.

First, let me check for any gcloud updates. Alright. Next I need to download my credentials to my local machine, so that I can access my new cluster. Alright. And now let me verify that I am connected by trying to list any existing pods. So you can see here that it says there are no resources found in the default namespace. Now this is the same default namespace that I had mentioned before. Since I did not specify a namespace, Kubernetes is always going to assume that I meant default. Now this is a brand new cluster, so of course, default is empty. However, I had mentioned that there were other namespaces automatically created as well. Let's see if we can find those.

So I'll list out all the current namespaces. And we can see that the cluster has four namespaces. I could also list out the pods in each of these namespaces by specifying what namespace I want on each list command. So you can see that kube-public and kube-node-lease are both empty, but kube-system has a bunch of things running in it. Now these include things like internal DNS and proxy services. We are gonna leave these namespaces alone.

Now if I want, I can also list all pods in the cluster across all namespaces with this command. So I think we are done looking at the existing namespaces. Let's create some new ones. So first, I am going to create a namespace named demo-namespace-1. And a namespace isn't useful unless I use it for something, so let me go ahead and deploy an app to this namespace. So I am going to be using a Google sample application called Hello app. Now this is just a very simple web server that basically returns Hello world.

Notice here I am specifying the namespace to deploy to. If I didn't specify this namespace, it would be deployed to the default namespace. Alright. And the deployment looks like it was successful. If I try to deploy this same app again with the same name, it would fail. Let me show you that. Now this is because names must be unique inside of a namespace. But if I create a new namespace, I should be able to deploy the same app under the same name.

So next I'll create a demo-namespace-2. And I am going to deploy the same app to this second namespace. Now this is the same command I used before, but this time I specified the new namespace. And this time, it worked. So if I list all pods across all namespaces, I can see my two apps running in the two new namespaces. Now, you can also specify a namespaces when deploying workloads using the Google Cloud Console. You can see here the two apps that I created in the two namespaces. I could also create a new one. And so under Configuration, you just specify the namespace.

Now I won't actually deploy using the console, but I wanted you to see how to do it. So that's pretty much all there is to show you in regards to namespaces. They are pretty simple to use. Let's move on to the next topic.