tion for team workspaces  projects  and even specific applications. But ultimately  for a greater isolation of certain environments  namespaces are not enough  and having separate clusters is common. Typically  there is one nonproduction Kubernetes clus‐ ter used for some environments (development  testing  and integration testing) and another production Kubernetes cluster to represent performance testing and produc‐ tion environments. Let’s see some of the characteristics of namespaces and how they can help us in differ‐ ent scenarios: 10  |  Chapter 1: Introduction • ResourceQuotas can also limit the total sum of computing resources we can request in a given namespace. For example  in a cluster with a capacity of 32 GB RAM and 16 cores  it is possible to allocate half of the resources—16 GB RAM and 8 cores—for the production namespace  8 GB RAM and 4 cores for staging environment  4 GB RAM and 2 cores for development  and the same amount for testing namespaces. The ability of imposing resource constraints on a group of objects by using namespaces and ResourceQuotas is invaluable. • ResourceQuotas provide constraints that limit the aggregated resource consump‐ tion per namespace. With ResourceQuotas  a cluster administrator can control the number of objects per type that are allowed in a namespace. For example  a developer namespace may allow only five ConfigMaps  five Secrets  five Services  five ReplicaSets  five PersistentVolumeClaims  and ten Pods. • Each Kubernetes Service belongs to a namespace and gets a corresponding DNS address that has the namespace in the form of  <service-name>.<namespace- name>.svc.cluster.local . So the namespace name is in the URI of every Ser‐ vice belonging to the given namespace. That’s one reason it is vital to name namespaces wisely. • Some other resources such as namespaces themselves  nodes  and PersistentVo‐ lumes do not belong to namespaces and should have unique cluster-wide names. • By default  namespaces provide scope for resources  but nothing isolates those resources and prevents access from one resource to another. For example  a Pod from a development namespace can access another Pod from a production namespace as long as the Pod IP address is known. However  there are Kuber‐ netes plugins that provide networking isolation to achieve true multitenancy across namespaces if desired. • A namespace provides scope for resources such as containers  Pods  Services  or ReplicaSets. The names of resources need to be unique within a namespace  but not across them. • A namespace is managed as a Kubernetes resource.