Kubectl contexts are a mechanism for quickly switching between different clusters, users, and namespaces within the CLI. They make it easier to move between multiple environments without changing your active Kubectl config file.
In this article, we’ll show how you can use Kubectl to create, manage, and select different contexts. Make sure you’ve got Kubectl installed before you continue.
What’s A Context?
Contexts encapsulate the collection of settings that permit a successful connection to a Kubernetes cluster. A context can include the cluster’s URL, a set of user credentials, and the namespace to target by default.
In the absence of contexts, unique Kubernetes environments are often handled by creating a separate config file for each one. You then use the --kubeconfig flag or KUBECONFIG environment variable to load the correct file each time you use Kubectl:
$ export KUBECONFIG=.kube/cluster-1-user-1.yaml $ kubectl get pods
Contexts let you condense details of all your environments into one config file. You can use the default .kube/config for each of your clusters, eliminating CLI flags and environment variables. Kubectl includes commands to switch its active context between the options you’ve created.
Preparing for Contexts
Contexts are managed using the kubectl config command group. As with everything else in Kubectl, your available context list will be loaded from and saved to your active config file. This is determined by KUBECONFIG, --kubeconfig, or the default .kube/config.
To begin using contexts, you need to add a few clusters and credentials to your config file. You can use other kubectl config commands to set these up:
# Create two cluster connections, qa and prod $ kubectl set-cluster qa --server=https://192.168.0.1 --insecure-skip-tls-verify $ kubectl set-cluster prod --server=https://192.168.0.2 --insecure-skip-tls-verify # Create two credential pairs $ kubectl set-credentials qa-user --username=demo --password=demoP@ss_qa $ kubectl set-credentials prod-user --username=demo password=demoP@ss_prod
Now your config file contains connection details for two separate Kubernetes clusters. It also holds two pairs of credentials. Next we’ll create a context to link the clusters to their respective credentials. You’ll then be able to use a Kubectl command to jump between the QA and production environments.
Creating a Context
The kubectl config set-context command adds new contexts to your config file. You must specify a name for your context. Use the command’s flags to reference a previously added cluster and user account.
# Create contexts for the clusters added earlier $ kubectl config set-context qa-context --cluster=qa --user=qa-user $ kubectl config set-context prod-context --cluster=prod --user=prod-user
At this point you can run the kubectl config view command to inspect all the changes that have been made to your config file:
apiVersion: v1 kind: Config current-context: "" clusters: - cluster: name: qa server: https://192.168.0.1 insecure-skip-tls-verify: true - cluster: name: prod server: https://192.168.0.2 insecure-skip-tls-verify: true contexts: - context: name: qa-context cluster: qa user: qa-user - context: name: prod-context cluster: prod user: prod-user users: - name: qa-user user: username: demo password: demoP@ss_qa - name: prod-user user: username: demo password: demoP@ss_prod
The context definitions point to other kinds of object defined elsewhere in the config file.
Selecting and Using Contexts
Contexts are selected with the kubectl context use-context command:
$ kubectl context use-context qa-context
The active context’s name is stored as the value of the current-context field in your Kubectl config file. All Kubectl commands will target the cluster referenced by the selected context.
# Connects to the https://192.168.0.1 cluster as demo:demoP@ss_qa $ kubectl get pods # Switch the active context $ kubectl config use-context prod-context # Connects to the https://192.168.0.2 cluster as demo:demoP@ss_prod $ kubectl get pods
The ability to quickly change the target environment within Kubectl helps you move between clusters without being overwhelmed by config flags.
Because the selected context persists until another one is selected, you should check Kubectl is targeting the environment you expect before running destructive commands. Use the current-context command to see the selected context’s name:
$ kubectl config current-context prod-context
You can view all the contexts in your currently loaded config file with get-contexts:
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
qa-context qa qa-user
* prod-context prod prod-user
Including Namespace Information With Contexts
So far we’ve used contexts to select a cluster and user account. Contexts can include namespace information too. When a context has an assigned namespace, Kubectl commands will automatically include the --namespace flag. You can still use --namespace manually to override the namespace set by the context.
$ kubectl config set-context production-api --cluster=prod --user=prod-user --namespace api $ kubectl config use-context production-api # Gets Pods in the "api" namespace within the "prod" cluster $ kubectl get pods
There’s no limit to the number of contexts you can have. Clusters may appear in multiple contexts, letting you define separate contexts for each of your important namespaces. This avoids repetition of the --namespace flag as you inspect different resources in your cluster.
Renaming and Deleting Contexts
Rename contexts using the rename-context command:
$ kubectl config rename-context qa-context testing-context
To delete a context, pass its name to the delete-context command:
$ kubectl config delete-context testing-context
The cluster, user, and namespace referenced by a context are changed by repeating the set-context command with the same context name. You can also make modifications by manually editing your Kubectl config file.
Making Context Switching Even Easier
Kubectl’s integrated context management can be sufficient when you switch clusters on a relatively infrequent basis. However, if you’re constantly changing cluster throughout your day, the relatively verbose use-context command can start to feel repetitive itself.
Kubectx is a Kubectl plugin that can make context switches even easier. It shortens use-context and adds a few extra convenience features:
# Equivalent to "kubectl config use-context prod-context" $ kubectx prod-context
Depending on your workflow, you may want to keeping using multiple Kubectl config files too. You could use shell aliases and default environment variables to set up a customized workflow that automatically selects a config file and context for each new terminal window.
Summary
Kubectl contexts are a way to encapsulate multiple logical cluster connections in a single config file. Each context is assigned a cluster URL, user account, and namespace. Kubectl commands will target the selected context’s cluster using the referenced credentials.
You can set up contexts with kubectl config set-context or by manually editing your .kube/config file. Kubectl also includes commands for managing the named cluster connections and user accounts you can reference in your contexts.
