As you start building more and more Kubernetes services, things that are easy at first start to get more complicated. For example, development teams cannot create services or deployments under the same name. If you have thousands of Pods, simply listing them will take a lot of time, not to mention getting them properly managed. And this is just the tip of the iceberg.
Let's take a look at how namespace makes it easier to manage Kubernetes resources. So what is a namespace? Namespace can be thought of as a virtual cluster within your Kubernetes cluster. You can have multiple isolated namespaces within the same Kubernetes cluster. They can really help you and your teams with organization, security, and even system performance.
In most Kubernetes distributions, the cluster comes out of the box with a namespace called "default". There are actually three namespaces that Kubernetes deals with: default, kube-system, and kube-public. Currently, Kube-public is not used very often.
Leaving the kube namespace is a good idea, especially in a managed system like the Google Kubernetes Engine. It uses the "default" namespace as the place where your services and applications are created. There is absolutely nothing special about it, except that Kubernetes is configured to use it out of the box and you cannot remove it. This is great for getting started and low performance systems, but I wouldn't recommend using the default namespace on large prod systems. In the latter case, one development team can easily rewrite someone else's code and break another team's work without even realizing it.
Therefore, you should create multiple namespaces and use them to segment your services into manageable chunks. The namespace can be created with a single command. If you want to create a namespace named test, then use the $ kubectl create namespace test command, or simply create a YAML file and use it like any other Kubernetes resource.
You can view all namespaces with the $ kubectl get namespace command.
After executing it, you will see three built-in namespaces and a new namespace called "test". Let's look at a simple YAML file to create a pod. You can notice that there is no mention of a namespace in it.
If you use kubectl to run this file, it will create the mypod module in the current active namespace. This will be the default namespace until you change it. There are 2 ways to tell Kubernetes which namespace you want to create your resource in. The first way is to use the namespace flag when creating the resource.
The second way is to specify the namespace in the YAML declaration.
If you specify a namespace in YAML, then the resource will always be created in that space. If you try to use a different namespace while using the namespace flag, the command will fail. Now, if you try to find your pod, you won't be able to.
This is because all commands are executed outside the current active namespace. You need to use a namespace flag to find your pod, but this gets tedious quickly, especially if you're a developer on a team that uses its own namespace and doesn't want to use that flag for every single command. Let's see how this can be fixed.
Out of the box, your active namespace is named default. If you don't specify a namespace in the resource's YAML, then all Kubernetes commands will use that active default namespace. Unfortunately, trying to manage the active namespace with kubectl can fail. However, there is a very good tool called Kubens that makes this process much easier. When you run the kubens command, you see all the namespaces with the active namespace highlighted.
To switch the active namespace to the test namespace, you simply run the $ kubens test command. If you then run the $ kubens command again, you can see that a new active namespace is now allocated - test.
This means you don't need a namespace flag to see a pod in the test namespace.
Thus, namespaces are hidden from each other, but not isolated from each other. A service in one namespace can communicate quite easily with a service in another namespace, which is often very useful. Being able to communicate across different namespaces means that your developers' service can communicate with another dev team's service in a different namespace.
Typically, when your application wants to access a Kubernetes service, you use the built-in DNS discovery service and simply tell your application the name of the service. However, you can create a service under the same name in multiple namespaces, which is illegal.
Luckily, this is easy to work around using the expanded form of the DNS address. Services in Kubernetes expose their endpoints using a common DNS pattern. It looks something like this:
Typically, you just need the name of the service and DNS will automatically resolve the full address.
However, if you need to access a service in a different namespace, simply use the service name plus the namespace name:
For example, if you want to connect to a service database in a test namespace, you can use database.test
If you want to connect to a service database in the prod namespace, you use database.prod.
If you really want to isolate and restrict namespace access, Kubernetes allows you to do this with the help of Kubernetes Network Policies. I will talk about this in the next series.
I am often asked the question, how many namespaces should be created and for what purpose? What is a managed piece of data?
If you create too many namespaces, they will simply get in your way. If there are too few of them, you will lose all the advantages of such a solution. I think there are four main stages that every company goes through in the process of creating its organizational structure. Depending on the stage of development your project or company is in, you can adopt an appropriate namespace strategy.
Imagine that you are part of a small team that is working on the development of 5-10 microservices and you can easily gather all the developers in one room. In this situation, it makes sense to run all prod services in the default namespace. Of course, for more action you can use 2 namespaces - separately for prod and dev. And most likely, you are testing your development on a local machine using something like Minikube.
Let's assume that the conditions have changed and now you have a rapidly growing team that is working on more than 10 microservices at the same time. There comes a time when you need to use multiple clusters or namespaces, separate for prod and dev. You can break the team into several subgroups so that each of them has their own microservices and each of these teams can choose their own namespace to facilitate the process of managing software development and release.
As each member of the team gains an understanding of how the system as a whole works, coordinating each change with all the other developers becomes more and more difficult. Trying to spin up a full stack on your local machine is getting harder every day.
In large companies, developers do not know at all who exactly is working on what. Teams communicate using service contracts or use Service mesh technology, which adds a layer of abstraction over the network, such as the Istio configuration tool. Trying to run the entire stack locally is just not possible. I highly recommend using a continuous delivery (CD) framework like Spinnaker in Kubernetes. So, there comes a point where each command definitely needs its own namespace. Each team can even choose multiple namespaces for the dev environment and the prod environment.
Finally, there are large entrepreneurial companies in which one group of developers does not even know about the existence of other groups. Such a company may generally hire third-party developers who interact with through well-documented APIs. Each such group has several teams and several microservices. In this case, you must use all the tools that I talked about earlier.
Programmers should not manually deploy services and should not have access to namespaces that do not concern them. At this stage, it is advisable to have several clusters to reduce the "explosion radius" of poorly configured applications, to simplify billing processes and resource management.
Thus, the correct use of namespaces by your organization allows you to make Kubernetes more manageable, controlled, secure and flexible.
Some ads π
Thank you for staying with us. Do you like our articles? Want to see more interesting content? Support us by placing an order or recommending to friends, , a unique analogue of entry-level servers, which was invented by us for you: (available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd 2 times cheaper in Equinix Tier IV data center in Amsterdam? Only here in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $99! Read about
Source: habr.com