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...