Kubernetes Namespaces Explained in 15 mins | Kubernetes Tutorial 21

in this video we're going to go through the usages of a namespace and the best practices of when and how to use a namespace first of all what is a namespace in kubernetes increment in this cluster you can organize resources in namespaces so you can have multiple namespaces in a cluster you can think of a namespace as a virtual cluster inside of a kubernetes cluster now when you create a cluster by default kubernetes gives you the namespaces out-of-the-box so in the command line if I type cube city I'll get namespaces I see the list of those out-of-the-box namespaces that kubernetes offers and let's go through them one by one the kubernetes dashboard namespace is shipped automatically in mini cube so it's specific to mini cube installation you will not have this in a standard cluster the first one is Cube system cube system namespace is not meant for your use so basically you shouldn't create anything or shouldn't modify anything in cube system namespace the components that are deployed in the namespace are the system processes there are from master managing processes or cubes ETL etc the next one is Q public and what Q public contains is basically the publicly accessible data it has a config map that contains cluster information which is accessible even without authentication so if I type here keep CTL cluster info this is the output that I get through that information and the third one is cube node lease which is actually a recent addition to kubernetes and the purpose of the namespace is that it holds information about the heartbeats of nodes so each node basically gets its own object that contains the information about that nodes availability and the fourth namespace is the default namespace and default namespace is the one that you're going to be using to create the resources at the beginning if you haven't created a new namespace but of course you can add and create new namespaces and the way that you can do it is using cube CTL create namespace command with the name of the namespace so I can create my namespace and if I do cube CTL get namespaces I see that in my list now another way to create namespaces is using namespace configuration file which i think is a better way to create namespaces because you also have a history in your configuration file repository of what resources you created in a cluster okay so now so what namespaces are and that you can create new ones and that kubernetes offers some of them by default but the question is what is the need for namespaces when should you create them and how you should use them and the first use case of using or creating your own namespaces is the following imagine you have only default namespace which is provided by kubernetes and you create all your resources in that default namespace if you have a complex application that has multiple deployments which create replicas of many parts and you have resources like services and config maps etc very soon your default namespace is going to be filled with different components and it will be really difficult to have an overview of what's in there especially we have multiple users creating stuff inside so a better way to use namespaces in this case is to group resources into namespaces so for example you can have a database name space where you deploy your database and all its required resources and you can have a monitoring namespace where you deploy the primitives and all the stuff that it means you can also have elastic stack namespace where all the elasticsearch cabaña etc resources go and you can have nginx ingress resources so just one way of logically grouping your resources inside of the cluster now according to the official documentation of kubernetes you shouldn't namespaces if you have smaller projects and up to ten users I personally think that it's always good idea to group your resources in namespaces because as I said even if you have a small project and ten users you might still meet some additional resources for application like you know logging system and monitoring system and even with the minimum setup you can already get too much to just throw everything in a default namespace another use case where you will need to use namespaces if you have multiple teams so imagine this scenario you have two teams that use the same cluster and one team deploys an application which is called my app deployment as the name of the deployment they create and that deployment has its certain configuration now if another team had a deployment that accidentally had the same name but a different configuration and they created that deployment or they applied it they would overwrite the first team's deployment and if they're using for example a jenkins or some automated way to deploy those that application or to create the deployment they wouldn't even know that they overrode or disrupted in other teams deployment so to avoid such kind of conflicts again you can use namespaces so that each team can work in their own namespace without disrupting the other another use case for using namespaces is let's say you have one cluster and you want to host both staging and development environment in the same cluster and the reason for that is that for example if you're using something like nginx controller or elastic stack used for logging for example you can deploy it in one cluster and use it for both environments in that way you don't have to deploy these common resources twice in two different clusters so now the staging can use both resources as well as the development environment another use case for using namespaces is when use Bluegreen deployment for application which means that in the same cluster you want to have two different versions of production so the one that is active that is in production now and another one that is going to be the next production version the versions of applications in those blue and green production namespaces will be different however the same as we saw before in staging and development this namespaces might need to use the same resources like again nginx controller or elastic stack and this way again they can both use this common shared resources without having to set up a separate cluster so one more use case for using namespaces is to limit the resources and access to namespaces when you're working with multiple teams so again we have a scenario where we have two teams working in the same cluster and each one of them has their own namespace so what you can do in this scenario is that you can give the teams access to only their namespace so they can only be able to create updates delete resources in their own namespace but they can't do anything in the other namespaces and this way you even restrict or even minimize the risk of one team accidentally interfering with another team's work so each one has their own secured isolated environment additional thing that you can do on a namespace level is limit the resources that each namespace consumes because if you have a cluster with limited resources you want to give each team a share of resources for their application so if one team let's say consumes too much resources then other teams would eventually have much less and their applications may not schedule because the cluster will run out of the resources so what you can do is that per namespace you can define resource quotas that limit how much CPU RAM storage resources one namespace can use so I hope walking through these scenarios helped you analyze in which use cases and how you should use namespaces in your specific project there's several characteristics that you should consider before deciding how to group and how to use namespaces the first one is that you can't access most of the resources from another namespace so for example if you have a configuration map in Project a namespace that references the database service you can't use that config map in project B namespace but instead you will have to create the same config map that also references the database service so each namespace will define or must define its own config method even if it's the same reference and the same applies to secret so for example if you have credentials of a shared service you will have to create a secret in each namespace where you are gonna need that however a resource that you can share across namespaces is service and that's what we saw in the previous slide so config map in project B namespace references service that is going to be used eventually in a pod and the way it works is that in a config map definition the database URL in addition to its name which is my sequel service will have namespace at the end so using that URL you can actually access services from other namespaces which is a very practical thing and this is how you can actually use shared resources like elasticsearch or nginx from other namespaces and one more characteristic is that we saw that most of the components resources can be created within the namespace but there are some components in kubernetes they're not named spaced so to say so basically they live just globally in the cluster and you can't isolate them or put them in a certain namespace and examples of such resources are volume or persistent volume and node so basically when you create the volume it's gonna be accessible throughout the whole cluster because it's not in a namespace and you can actually list components they are not bound to a namespace using a command cube CTL API resources - - names based in the same way you can also list all the resources that are bound to a namespace using namespace true so now that you've learned what the namespaces are why to use them in which cases it makes sense to use them in which way and also some characteristics that you should consider let's actually see how to create components in a namespace in the last example and also if you've seen my previous videos we've created components using configuration files and nowhere there we have defined a namespace so what happens is by default if you don't provide a namespace to a component it creates them in a default namespace so if I apply this config map component and let's do that actually right now so it keeps it a apply minus F config map if I apply that and I do cube City I'll get config map my config map was created in a default namespace and notice that even in the cube city L gets config map command I didn't use a name space because cube city L get or keep CTL commands they take the default namespace is a default so Cooper City I'll get config map is actually same as cube city I'll get config map - in or namespace and default namespace so these are the same commands it's just a shortcut because it takes default is a default namespace okay so one way that I can create this config map in a specific namespace is using cube city apply command but adding flag namespace in the namespace name so this will create config map in my namespace and this is one way to do it another way is inside the configuration file itself so I can adjust this config map configuration file to include the information about the destination namespace itself so in the metadata I can add a namespace attribute so if I apply this configuration file again using cube city I'll apply and now if I want to get the component that I created in this specific namespace then I have to add the option or the flag to cube City I'll get comment because I said by default it will check only in the default namespace so I recommend using the namespace attribute in a configuration file instead of providing it to the cube CTL command because one it's it's better documented so you know by just looking at the configuration file where the component is getting created because that could be an important information and second if you're using automated deployment where you're just applying the configuration files then again this will be a more convenient way to do it now if for example we take a scenario where one team gets their own namespace and there has to work entirely in the namespace it could be pretty annoying to have to add this namespace tag to every cube CTL command so in order to make it more convenient there is a way to change this default or active namespace which is default namespace to whatever namespace you choose and kubernetes or cube CTL doesn't have any out-of-the-box solution for that but there's a tool called cube NS or Cubans and you have to install the tool so on Mac so I'm gonna execute Brio install cube city X so this will install Cubans tool as well so once I have the Cubans installed I can just execute Cubans command and this will give me a list of all the namespaces and highlight the one that is active which is default right now and if I want to change the active namespace I can do cube ends my namespace and this will switch the active namespace so if I do cube ends now I see that active one is my namespace so now I can execute cube CTL commands without providing my namespace name space but obviously if you switch a lot between the namespaces this will not be so much convenient for your own operating system and environment there will be different halation process so I'm gonna link the cube City X installation guide in the description below thanks for watching the video I hope it was helpful and if it was don't forget to like it if you want to be notified whenever a new video comes out then subscribe to my channel if you have any questions if something wasn't clear in the video please post them in a comment section below and I will try to answer them so thank you and see you in the next video

Channel: TechWorld with Nana

Views: 67,216

Keywords: kubernetes namespaces, namespaces in kubernetes, namespaces kubernetes, what is namespaces in kubernetes, kubernetes namespaces tutorial, kubernetes namespaces best practices, why use kubernetes namespaces, namespaces, what is namespaces, techworld with nana, kubernetes namespaces explained, organize kubernetes with namespaces, kubernetes namespace explained, kubernetes namespaces bet practices, kubernetes create namespace, kubernetes tutorial, kubernetes tutorial for beginners

Id: K3jNo4z5Jx8

Length: 16min 0sec (960 seconds)

Published: Fri Feb 28 2020