Namespaces: Isolation, Motivation, and DNS

Production likes to run cattle, so let's create some cattle pods. ```shell kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production kubectl get deployment -n=production ``` ```console NAME READY UP-TO-DATE AVAILABLE AGE cattle 5/5 5 5 10s ``` ```shell kubectl get pods -l app=cattle -n=production ``` ```console NAME READY STATUS RESTARTS AGE cattle-2263376956-41xy6 1/1 Running 0 34s cattle-2263376956-kw466 1/1 Running 0 34s cattle-2263376956-n4v97 1/1 Running 0 34s cattle-2263376956-p5p3i 1/1 Running 0 34s cattle-2263376956-sxpth 1/1 Running 0 34s ``` At this point, it should be clear that the resources users create in one namespace are hidden from the other namespace. As the policy support in Kubernetes evolves, we will extend this scenario to show how you can provide different authorization rules for each namespace.  ## Understanding the motivation for using namespaces A single cluster should be able to satisfy the needs of multiple users or groups of users (henceforth in this document a _user community_). Kubernetes _namespaces_ help different projects, teams, or customers to share a Kubernetes cluster. It does this by providing the following: 1. A scope for [names](/docs/concepts/overview/working-with-objects/names/). 1. A mechanism to attach authorization and policy to a subsection of the cluster. Use of multiple namespaces is optional. Each user community wants to be able to work in isolation from other communities. Each user community has its own: 1. resources (pods, services, replication controllers, etc.) 1. policies (who can or cannot perform actions in their community) 1. constraints (this community is allowed this much quota, etc.) A cluster operator may create a Namespace for each unique user community. The Namespace provides a unique scope for: 1. named resources (to avoid basic naming collisions) 1. delegated management authority to trusted users 1. ability to limit community resource consumption Use cases include: 1. As a cluster operator, I want to support multiple user communities on a single cluster. 1. As a cluster operator, I want to delegate authority to partitions of the cluster to trusted users in those communities. 1. As a cluster operator, I want to limit the amount of resources each community can consume in order to limit the impact to other communities using the cluster. 1. As a cluster user, I want to interact with resources that are pertinent to my user community in isolation of what other user communities are doing on the cluster. ## Understanding namespaces and DNS When you create a [Service](/docs/concepts/services-networking/service/), it creates a corresponding [DNS entry](/docs/concepts/services-networking/dns-pod-service/). This entry is of the form `<service-name>.<namespace-name>.svc.cluster.local`, which means that if a container 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). ## {{% heading "whatsnext" %}} * Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). * Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) * See [namespaces design](https://git.k8s.io/design-proposals-archive/architecture/namespaces.md).

This section elaborates on the motivation and use cases for Kubernetes namespaces. It emphasizes that namespaces provide isolation for different user communities, allowing them to manage resources, policies, and constraints independently. Key benefits include avoiding naming collisions, delegating management authority, and limiting resource consumption per community. The section also explains how namespaces interact with DNS, where service names within a namespace resolve locally, and fully qualified domain names are needed to access services across namespaces.