# Kubernetes Namespaces

Namespaces in Kubernetes are a way to organize and divide resources within a cluster. They act as virtual clusters within the same physical cluster, allowing you to group and isolate resources such as pods, services, and configurations. This organization is particularly useful in large-scale environments where multiple teams, projects, or applications share a Kubernetes cluster.

## What is the Difference Between a Cluster and Namespaces?

A [Kubernetes cluster](/content/finops-glossary/kubernetes-cluster/index.html) is the overarching environment that includes all the resources and infrastructure needed to run workloads, such as nodes, pods, and services. It represents the physical or virtual resources where your applications are orchestrated.

Namespaces, on the other hand, are logical divisions within a cluster. They allow you to group and isolate resources, creating virtual clusters within the same physical environment. All namespaces share the cluster’s underlying resources, but they provide a way to organize and manage them effectively.

| Feature | Cluster | Namespaces |
| --- | --- | --- |
| **Purpose** | Manages all resources in the cluster | Groups and isolates resources logically |
| **Scope** | Entire Kubernetes environment | Specific subdivisions within a cluster |
| **Isolation** | Physical or virtual boundary | Logical boundary |

### What is the Difference Between Pods and Namespaces?

[Pods](/content/finops-glossary/kubernetes-pods/index.html) are the smallest deployable units in Kubernetes, representing one or more containers that share the same network and storage. They are designed to host your application workloads and manage their lifecycle.

Namespaces, on the other hand, are organizational tools that provide logical groupings for Kubernetes resources, including pods. While pods are the units of computation, namespaces are the high-level grouping mechanism for managing resources at scale.

| Feature | Pods | Namespaces |
| --- | --- | --- |
| **Purpose** | Runs application workloads | Organizes and isolates resources |
| **Scope** | Resource within a namespace | Logical partition in a cluster |
| **Granularity** | Smallest unit in Kubernetes | High-level grouping mechanism |

## Why Use Namespaces?

In Kubernetes, all objects live in a flat hierarchy by default, which can become unmanageable as your cluster grows. Namespaces solve this problem by introducing a logical boundary that helps with:

1. **Resource Isolation**: Separate resources for different teams, projects, or environments (e.g., dev, staging, production).
2. **Access Control**: Apply role-based access control (RBAC) to specific namespaces, limiting who can access or modify resources.
3. **Resource Quotas**: Set limits on the resources (CPU, memory) that can be used within a namespace to prevent over-consumption.
4. **Simplified Management**: Organize objects for easier navigation and maintenance.

## How Namespaces Work

They work by dividing resources into distinct groups. Objects created in one namespace are visible and accessible only within that namespace unless explicitly shared. Some important points to understand:

- **Default Namespace**: If you don’t specify a namespace, Kubernetes places your objects in the `default` namespace.
- **System Namespaces**:

- `kube-system`: Reserved for Kubernetes system components like the API server and scheduler.
  - `kube-public`: A special namespace for public resources that should be accessible to all users.
  - `kube-node-lease`: Used for node heartbeat leases.
- **Custom Namespaces**: You can create your own namespaces to organize resources according to your specific needs.

## How to create Namespaces

You can create a namespace with a simple YAML file or directly using the `kubectl` command.

### **Using kubectl:**

```none
kubectl create namespace my-namespace
```

### **Using YAML:**

```none
apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
```

Apply the file:

```none
kubectl apply -f namespace.yaml
```

### **Using a Namespace**

To place an object in a specific namespace, you define the `metadata.namespace` field in the object’s YAML manifest:

```none
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: my-namespace
spec:
  containers:
  - name: nginx
    image: nginx
```

Or, you can specify the namespace in your `kubectl` commands:

```none
kubectl get pods --namespace=my-namespace
```

Set a default namespace for your `kubectl` commands:

```none
kubectl config set-context --current --namespace=my-namespace
```

## How to List Namespaces with `kubectl`

Use the [`kubectl`](/content/finops-glossary/kubectl-kubernetes/index.html) command-line tool:

#### Basic Command:

```none
kubectl get namespaces
```

This lists all namespaces along with their status.

#### Example Output:

```none
NAME              STATUS    AGE
default           Active    20d
kube-system       Active    20d
kube-public       Active    20d
my-namespace      Active    10d
```

#### How to List Namespaces in JSON or YAML Format:

If you need detailed information, retrieve namespaces in JSON or YAML:

```none
kubectl get namespaces -o json
kubectl get namespaces -o yaml
```

### How to Filter Specific Namespaces:

To check if a specific namespace exists:

```none
kubectl get namespace <namespace-name>
```

### How to Switch Context to a Namespace:

Set a default namespace for all subsequent commands:

```none
kubectl config set-context --current --namespace=<namespace-name>
```

## Use Cases

### **1. Multi-Tenant Clusters**

In shared clusters, namespaces help isolate resources between teams or departments. For example:

- `team-a` namespace for one team’s workloads.
- `team-b` namespace for another team’s workloads.

### **2. Environment Separation**

Can separate environments within the same cluster:

- `dev`: For development workloads.
- `staging`: For pre-production testing.
- `prod`: For live production applications.

### **3. Resource Quotas and Limits**

Work with resource quotas to enforce limits on CPU, memory, and storage usage for workloads within that namespace. This prevents a single team or application from consuming all cluster resources.

### **4. Role-Based Access Control (RBAC)**

You can assign permissions at the namespace level to control access. For example:

- Developers can manage resources in the `dev` namespace.
- Only admins have access to the `prod` namespace.

## Best Practices

1. **Define Clear Naming Conventions**:

- Use descriptive names like `team-a-dev` or `project-prod` to make namespaces easily identifiable.
2. **Leverage Resource Quotas**:

- Apply resource limits to avoid resource contention between namespaces.
3. **Use Namespaces Strategically**:

- Avoid creating too many namespaces unnecessarily; group related workloads logically.
4. **Enable Namespace-Specific Policies**:

- Use network policies, RBAC, and other tools to enforce security and access controls at the namespace level.
5. **Monitor Namespace Usage**:

- Regularly review namespace usage and clean up unused namespaces to maintain cluster hygiene.

## Resources

1. [**Official Kubernetes Documentation**:](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
2. [**Google Cloud Blog**:](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-organizing-with-namespaces)
3. [**Kubectl Reference**:](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
4. [**Warp.dev Guide**:](https://www.warp.dev/terminus/kubectl-list-namespace)