# 5. K8s Namespaces

### Namespace

* Organize resources in namespaces
* Virtual clusters inside k8 cluster
* 4 Namespaces by default
* kubernetes-dashboard only with minikube

1. kube-system
   * Do not create or modify in kube-system
   * Used by system processes
   * Master or kubectl processes
2. kube-public
   * Publically accessible data
   * A configmap, which contains cluster information
3. kube-node-lease
   * heartbeats of nodes
   * each node has associated lease of object in namespace
   * determines the availability of node
4. default
   * resources you create are located here

***

### Creating Namespace

#### Using CLI

```bash
kubectl create namespace <my-namespace>
```

#### Using Config File

Add namespace attribute in metadata.

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
	name: mysql-configmap
	namespace: my-namespace
data:
	db_utl: mysql-service.database
```

***

### Why to use namespace

#### 1. Resources goruped in namespace

* All resources are created in default namespace
* Overtime, default namespace will be filled with different components
* Difficult to overview the namespace at that time
* Should not use for smaller projects&#x20;

<figure><img src="https://1920086362-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfv51K0WXLZdwTryHQZc%2Fuploads%2FKjAdAHV3QOKR0jRZAaoW%2Fimage.png?alt=media&#x26;token=cdd40e02-73f8-41b0-a4e8-fc3f1acbe288" alt=""><figcaption></figcaption></figure>

#### 2. Conflicts: many teams, same application

* Two teams use same cluster and first team deploy app named my-app, second team also uses same same of deployment, hence they override previous team deployment
* Each team should use their own namespace to avoid disruption

#### 3. Resource Sharing

1. Staging and Deployment

* Reuse the common components in both environments like logging cluster

2. Blue/Green Deployment

* Two different versions of production like v1 and v2
* They may need to use same resources

#### 4. Access and Resource Limits on Namespaces

* We can give Team A access to their own namespace and vice versa
* They can't access other team's namespace
* We can also limit cpu, ram, storage resources per namespace using resource quota

**Services which can't be accessed from another namespace**

Since we cant access most resources from another namespace, simple things like **ConfigMap** and **Secrets** should be regenerated in each namespace causing duplication

**Services which can be accessed from another namespace**

* Service can be accessed from another namespace
* In ConfigMap definitation, the db\_url will contains service name along with namespace name&#x20;

<figure><img src="https://1920086362-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDfv51K0WXLZdwTryHQZc%2Fuploads%2FjbdkOOHjL5Ak3bHHn6PR%2Fimage.png?alt=media&#x26;token=e2071b5e-0bf7-4da3-9540-6c8ef6b12241" alt=""><figcaption></figcaption></figure>

### Components which can't be created within namespace

* Some resources live globally inside a cluster
* you cant isolate them
* Examples are **Volumes** and **Nodes**
* Can be listed by `kubectl api-resources --namespaced=false` and vice versa

***

### Changing Active Namespace

```bash
$ yay kubectx
$ kubens
$ kubens my-namespace
```

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://notes.nomanaziz.me/devops/orchestration/kubernetes/5.-k8s-namespaces.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.