Kubernetes Tutorial – Kubernetes Names And Namespaces. All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID. This tutorial will give a clear idea about Kubernetes names and namespaces. Let’s start learning about Kubernetes names and namespaces, happy learning.
All objects in the Kubernetes REST API are unambiguously identified by a Name and a UID. For non-unique user-provided attributes, Kubernetes provides labels and annotations.
Related Article For You: Kubernetes Tutorial For Beginner
Kubernetes Names Tutorial
Names are generally client-provided. Only one object of a given kind can have a given name at a time (i.e., they are spatially unique). But if you delete an object, you can make a new object with the same name.
Names are used to refer to an object in a resource URL, such as
/api/v1/pods/some-name. By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters,
., but certain resources have more specific restrictions.
Related Article For You: Kubernetes Components
UIDs are generated by Kubernetes. Every object created over the whole lifetime of a Kubernetes cluster has a distinct UID (i.e., they are spatially and temporally unique).
Kubernetes supports multiple virtual clusters backed by the same physical cluster. These virtual clusters are called namespaces.
Related Article For You: Kubernetes Objects
When to Use Multiple Namespaces in Kubernetes
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.
Namespaces provide a scope for names. Names of resources need to be unique within a namespace, but not across namespaces. Namespaces are a way to divide cluster resources between multiple users.
Related Article For You: Kubernetes Interview Questions
In future versions of Kubernetes, objects in the same namespace will have the same access control policies by default.
It is not necessary to use multiple namespaces just to separate slightly different resources, such as different versions of the same software: use labels to distinguish resources within the same namespace.
Working with Namespaces in Kubernetes
Creation and deletion of namespaces are described in the Admin Guide documentation for namespaces.
You can list the current namespaces in a cluster using:
$ kubectl get namespaces NAME STATUS AGE default Active 1d kube-system Active 1d kube-public Active 1d
Kubernetes starts with three initial namespaces:
defaultThe default namespace for objects with no other namespace
kube-systemThe namespace for objects created by the Kubernetes system
kube-publicThe namespace is created automatically and readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement.
Setting the Namespace for a Request
To temporarily set the namespace for a request, use the
$ kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx $ kubectl --namespace=<insert-namespace-name-here> get pods
Setting the Namespace Preference
You can permanently save the namespace for all subsequent kubectl commands in that context.
$ kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here> # Validate it $ kubectl config view | grep namespace:
Namespaces and DNS
When you create a Service, it creates a corresponding DNS entry. This entry is of the form
<service-name>.<namespace-name>.svc.cluster.local, which means that if a container just uses
<service-name>, it will resolve to the service which is local to a namespace.
This is useful for using the same configuration across multiple namespaces such as Development, Staging and Production. If you want to reach across namespaces, you need to use the fully qualified domain name (FQDN).
Not All Objects are in a Namespace
Most Kubernetes resources (e.g. pods, services, replication controllers, and others) are in some namespaces. However namespace resources are not themselves in a namespace.
And low-level resources, such as nodes and persistentVolumes, are not in any namespace. Events are an exception: they may or may not have a namespace, depending on the object the event is about.
OTHER KUBERNETES TUTORIALS
Want to learn Kubernetes from industry experts?
Get register for a FREE demo on Kubernetes Training @ Contact us.