In Kubernetes, namespaces provide a mechanism for isolating resource groups within a single cluster. Resource names must be unique within a namespace, but not between namespaces. Namespace-based scope applies only to namespace objects (for example, deployments, services, and so on) and not to objects in the entire cluster (for example, StorageClass, Nodes, PersistentVolumes, and so on).
When to
use multiple namespaces
Namespaces are intended for use in environments with many users spread across multiple teams or projects. For clusters with a few or tens of users, you shouldn’t 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. Resource names must be unique within a namespace, but not between namespaces. Namespaces cannot be nested within each other, and each Kubernetes resource can only be in one namespace.
Namespaces are a way to divide cluster resources among multiple users (through resource quota).
You don’t need to use multiple namespaces to separate slightly different resources, such as different versions of the same software: use tags to distinguish resources within the same namespace.
Initial
namespaces
Kubernetes starts with four initial namespaces:defaultKubernetes
includes this namespace so you can start using your new cluster without first creating a namespace.kube-node-leaseThis namespace contains lease objects associated with each node. Node leases allow the kubelet to send heartbeats so that the control plane can detect the node error.kube-publicThis namespace is readable by all clients (including unauthenticated clients). This namespace is primarily reserved for cluster use, in case some resources are publicly visible and readable throughout the cluster. The public appearance of this namespace is only a convention, not a requirement.kube-systemThe namespace for objects created by the Kubernetes system.
Working with
Namespaces
Creating and deleting namespaces is described in the Namespace Administration Guide documentation. Viewing Namespaces
You can enumerate the current namespaces in a cluster using:
default NAME STATUS AGE Active 1d kube-node-lease Active 1d kube-public Active 1d kube-system Active 1d Configuring the namespace for a request
To set the namespace for a current request, use the -namespace flag.
For example:
Set the
namespace preference
You can permanently save the namespace for all subsequent kubectl commands in that context
.
Namespaces and
DNS
When you create a service, a corresponding DNS entry is created. This entry is in the form <service-name>.<namespace-name>.svc.cluster.local, which means that if a container only uses <service-name>, it will resolve to the service that is local to a namespace. This is useful for using the same settings across multiple namespaces, such as Development, Staging, and Production. If you want to reach through namespaces, you must use the fully qualified domain name (FQDN).
As a result, all namespace names must be valid RFC 1123 DNS tags.
Not all objects are in a namespace
Most Kubernetes resources (for example, pods, services, replication controllers, and others) are located 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.
To see which Kubernetes resources are
and are not in a
namespace:
Auto-tagging
The Kubernetes control plane sets an immutable kubernetes.io/metadata.name label on all namespaces, as long as the NamespaceDefaultLabelName feature gate is enabled. The tag value is the name of the namespace.
What’s next
Learn more about creating a new namespace.
- Learn more about deleting a namespace.
