liveBook · Manning

Namespace

As explained in Kubernetes in Action, Second Edition

A namespace is a Kubernetes API resource that groups namespaced objects and provides scopes for object names and permissions within a cluster.

A namespace groups Kubernetes API objects within a cluster. Give teams or clients separate namespaces so each can manage its own application objects without name collisions. This makes one physical cluster feel like several virtual clusters for organizing objects, but it does not create separate physical clusters. section 7.1

Names are scoped to a namespace: two Pods can both be named kiada-ssl if they are in different namespaces. Most object types are namespaced, including Pods, ConfigMaps, Secrets, and PersistentVolumeClaims. Nodes, PersistentVolumes, StorageClasses, and Namespace objects are cluster-scoped. Check the NAMESPACED column in `kubectl api-resources` when unsure. section 7.1 section 7.1.4

Find and create namespaces

Run `kubectl get namespaces` (or `kubectl get ns`) to see the available namespaces. Objects created without another namespace specified normally go into `default`. Create a workspace with `kubectl create namespace kiada-test1`, then inspect its pods with `kubectl get pods -n kiada-test1`. To find pods regardless of namespace, use `kubectl get pods -A`; the output includes a NAMESPACE column. section 7.1.1 section 7.1.2

Listing 7.1 A YAML definition of a Namespace object
apiVersion: v1
kind: Namespace     #1
metadata:
  name: kiada-test2     #2

A namespace is itself an API object. This YAML manifest defines one named kiada-test2 and can be submitted with `kubectl apply -f ns.kiada-test2.yaml`. section 7.1.2

Choose how kubectl targets a namespace:

  • For one command, add `-n kiada-test1`, as in `kubectl apply -f kiada-ssl.yaml -n kiada-test1`. section 7.1.3
  • For an object manifest, set `metadata.namespace`; an explicit `-n` must match it. section 7.1.3
  • For repeated commands, change the current context with `kubectl config set-context --current --namespace kiada-test1`. section 7.1.3

Namespaces organize API objects, not runtime isolation. Pods in different namespaces can share a node, and cross-namespace communication is allowed by default; NetworkPolicy can restrict it. A Service name resolves directly from a pod in the same namespace, while a pod in another namespace can use a name such as `quiz.kiada`. Labels solve a different organization problem: identifying and selecting subsets of objects, such as pods belonging to one application. section 7.1.4 section 11.1.3 section 7.0

Deleting a Namespace deletes the objects within it. If deletion remains at `Terminating`, inspect the Namespace's YAML status rather than assuming `kubectl get all` proves it is empty: that command omits some object types, and an object awaiting finalization can hold up deletion. section 7.1.5

How Kubernetes in Action, Second Edition covers it

How deep it goes
Works through listing, creation, targeting, isolation limits, and deletion diagnosis without treating namespaces as runtime isolation.
Examples
Uses same-named pods in separate namespaces, kubectl listings, and a Namespace YAML manifest.
What it assumes
Builds namespace knowledge from a team-sharing scenario while assuming familiarity with pods, kubectl, and object manifests.
What you can do after
Operate/configure namespaces with kubectl and manifests, and diagnose a namespace stuck terminating.
How it connects
Distinguishes namespaces from labels and links their boundaries to NetworkPolicy and Service DNS.

Also explained in

Compare how 20 books explain namespace →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes in Action, Second Edition. The section links point to the parts of the book it draws on.