Kubectl: namespace vs context
Published: 2024-03-21 13:33:03

---
title: Kubectl: namespace vs context
published: true
date: 2023-11-16 00:00:00 UTC
tags: 
canonical_url: https://theredcode.it/kubernetes/kubectl-namespace-vs-context/
---

Se usi _kubectl_, ti sarà capitato di vedere su qualche guida online il comando _set-context_: ma a che serve?

Partiamo dal concetto di **namespace** : questo serve a creare un raggruppamento logico di oggetti Kubernetes, proprio come raggruppiamo i file all’interno di cartelle diverse nei sistemi operativi.

Infatti, i namespaces forniscono un meccanismo per **isolare gruppi di risorse** all’interno di un singolo cluster. I nomi delle risorse devono essere univoci all’interno di uno stesso namespace, ma non tra namespace diversi.

I namespace sono pensati per essere usati in ambienti con molti utenti che appartengono a più team o progetti. Per i cluster con pochi utenti, non dovrebbe essere necessario creare dei namespace, come avviene in un ambiente di sviluppo locale.

Il concetto e il termine **context** in Kubernetes invece si applica solo sul lato client di Kubernetes, ovvero il luogo in cui esegui il comando _kubectl_. Ad esempio, quando lavori tramite terminale ed esegui il comando seguente, stai dicendo a _kubectl_ che, in questo ambiente dove viene eseguito, deve considerare come contesto corrente (quindi come _ambiente di lavoro_) il namespace chiamato _test_.

```
kubectl config set-context --current --namespace=test

```

Questo vuol dire che, lato server, Kubernetes non riconosce questo “contesto”, ma che d’ora in poi, quando andremo a eseguire dei comandi, _kubectl_ ci risparmierà la fatica di dover aggiungere il parametro che specifica il namespace dove quell’istruzione dev’essere eseguita.

Di base, la differenza è la seguente: quando esegui un comando come questo:

```
kubectl get pods -n test

```

stai recuperando l’elenco dei pod situati nel namespace “_test_”.

Se invece esegui il comando precedente senza specificare il namespace, questo risultato potrebbe variare dal namespace in cui l’utente è loggato:

```
kubectl get pods

kubectl config current-context # per verificare il contesto corrente

```

Il contesto diviene quindi un modo perfetto per **specificare** che, in _questa sessione_ di lavoro con il cluster Kubernetes a cui abbiamo acceduto, i comandi eseguiti fanno tutti riferimento a **un** solo **namespace**.

L’altro vantaggio nell’utilizzo dei contesti sta nel **definire un contesto per ogni namespace** , così da poter_switchare_ dall’uno all’altro a seconda del momento: immagina di creare un contesto per l’ambiente di sviluppo che si riferisce al namespace _dev_, uno per l’ambiente di collaudo, che si chiama _preprod_, e così via…

```
kubectl config set-context preprod-context --namespace=preprod

```

Senza contare il fatto che è possibile creare più contesti per più cluster, specificando il parametro _–cluster_, come mostrato di seguito: questo ci permetterà di passare non solo da un namespace all’altro, ma anche di cambiare il cluster di lavoro utilizzato!

```
kubectl config set-context preprod-context --cluster=mycluster --namespace=preprod

```

Come sfruttare i diversi contesti creati? Basterà eseguire il comando _kubectl use-context_ per passare dall’uno all’altro!

```
kubectl config use-context preprod-context

```

# Tip

Ma dove vengono salvate queste informazioni? Dai un’occhiata all’interno del file _~/.kube/config_:

```
apiVersion: v1
clusters:
 - cluster:
 insecure-skip-tls-verify: true
 server: https://api.xxx.yyy.zzz:6443
 name: api-xxx-yyy-zzz:6443
contexts:
 - context:
 cluster: api-xxx-yyy-zzz:6443
 namespace: dev
 user: kube:admin/api-xxx-yyy-zzz:6443
 name: dev/api-xxx-yyy-zzz:6443/kube:admin
current-context: dev/api-xxx-yyy-zzz:6443/kube:admin
kind: Config
preferences: {}
users:
 - name: kube:admin/api-xxx-yyy-zzz:6443
 user:
 token: sha256~217823932n3j...

```