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.