> For the complete documentation index, see [llms.txt](https://notes.nomanaziz.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.nomanaziz.me/devops/orchestration/kubernetes/5.-k8s-namespaces.md).

# 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="/files/3kNNdjsedRycaMmdFyF6" 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="/files/QqF62iYrduVGR9BNtG96" 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
```

***