Switching between Kubernetes clusters and namespaces: kubectx and kubens

Having more than one Kubernetes cluster is a common pattern. You may have one cluster dedicated to production environment, another one for staging and the third one for testing environment.

The same thing with Kubernetes namespaces: it’s great abstraction allowing you to separate workloads by their purpose. You may have multiple namespaces for different test environments or a dedicated namespace for app-related pods and another namespace for logging and monitoring services.

Configuring access to multiple Kubernetes clusters is well documented in official k8s documentation. Still switching context and specifying namespace for each kubectl invocation is tedious. This is where kubectx and kubens come into play. But let’s configure multiple clusters first.

Kubernetes configuration file: multiple clusters

You find an extensive guide in the k8s documentation. All in all, your ~/.kube/config should include three lists:

  • Clusters
  • Users
  • Contexts

Context defines a cluster, it’s namespace and a user. When the user switches to the context, he or she is working with the cluster and the namespaces of the context.

Each cluster may define master node’s server hostname and optionaly other entities like base64-encoded certificates.

Users may also be defined by autherntication options that covered in Kubernetes authentication guide.

An example configuration file for two Kubernetes clusters and two users with different authentication types may look like this:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: YOUR-CERT-AUTHORITY-DATA-CLUSTER-1
    server: https://YOUR-SERVER-ADDRESS-1
  name: cluster1
- cluster:
    certificate-authority-data: YOUR-CERT-AUTHORITY-DATA-CLUSTER-2
    server: https://YOUR-SERVER-ADDRESS-2
  name: cluster2
contexts:
- context:
    cluster: cluster1
    namespace: production
    user: user1
  name: context1
- context:
    cluster: cluster2
    namespace: test
    user: user2
  name: context2
current-context: context1
kind: Config
preferences: {}
users:
- name: user1
  user:
    client-certificate-data: YOUR-CLIENT-CERT-DATA-1
    client-key-data: YOUR-CLIENT-KEY-DATA-1
- name: user2
  user:
    auth-provider:
      config:
        access-token: YOUR-ACCESS-TOKEN
        cmd-args: config config-helper --format=json
        cmd-path: /PATH/TO/google-cloud-sdk/bin/gcloud
        expiry: "2019-09-28T00:00:00Z"
        expiry-key: '{.credential.token_expiry}'
        token-key: '{.credential.access_token}'
      name: gcp

kubectx and kubens

Although switching context is easy with kubectl config use-context, working with both contexts and namespaces require way too many key strokes! kubectx and kubens command line tools allow you to switch context this easy:

$ kubectx context2  # the same as kubectl config use-context context2

Chaning context with kubectx changes your config file’s current-context field the same way the kubectl config use-context does.

Now, instead of typing --namespace your-namespace or -n your-namespace in every kubectl invokation, change namespace once with kubens:

$ kubens test2     # your current k8s namespace is test2 now
$ kubectl get po   # the same as invoking with --namespace test2
# kubens test1     # your current k8s namespace is test1 now

Using kubectx and kubens allow you to save some key strokes and really come in handy when you switch over multiple Kubernetes clusters with more than one default namespace.