What are Contexts in Kubernetes?
Contexts in Kubernetes serve as configurations that allow users to switch between different clusters and namespaces quickly. They streamline the process of managing multiple cluster environments by encapsulating details such as the cluster name, user credentials, and namespace into a single, easily accessible alias.
This simplification is especially beneficial for developers and administrators working with complex deployments across various clusters. Stored within the kubeconfig file, contexts detail the connection parameters for accessing different parts of Kubernetes infrastructure.
By selecting a context, users instruct kubectl to use a specified set of credentials and connection settings, making it possible to switch from one cluster environment to another without manual reconfiguration.
This is part of a series of articles about Kubectl cheat sheet
Common Kubectl Commands for Managing Kubernetes Contexts
Here are the common kubectl commands you can use to manage and switch between Kubernetes contexts:
- Get context: To find out which context is currently active, use
kubectl config current-context - List context: To display all available contexts, run
kubectl config get-contexts - Set context: To create or modify a context, use
kubectl config set-context<context-name>- Add the flags
--namespace, --cluster, or--userwith the respective object name to apply the context to either of these.
- Add the flags
- Use context: To switch to a different context, execute:
kubectl config use-context <context-name> - Delete context: To remove a context from the kubeconfig file, use:
kubectl config delete-context <context-name>
What Is a Kubeconfig File?
A kubeconfig file is a YAML file that stores configuration information and connection settings for accessing Kubernetes clusters. It includes details about clusters, users, and contexts, enabling users to connect to and switch between different Kubernetes environments. This file supports Kubernetes operations as it contains all the necessary data for authentication and endpoint information of the clusters.
By default, the kubeconfig file is located at ~/.kube/config on a user’s machine but can be placed in custom locations if needed. The flexibility of having multiple contexts within a single kubeconfig file or distributing them across several files aids in organizing access to various clusters. This is especially useful for developers and system administrators managing multiple Kubernetes clusters, or managing multiple projects within the same cluster.
What Is kubectx?
kubectx is a command-line utility that simplifies the process of switching between different Kubernetes contexts and namespaces. Instead of manually typing out the kubectl commands to change contexts, kubectx provides a more user-friendly and efficient way to manage these configurations. It is especially useful for users who frequently switch between multiple clusters and namespaces.
With kubectx, you can quickly list, switch, and rename contexts. The tool significantly reduces the complexity and time involved in managing Kubernetes contexts.
Basic context commands in kubectx
To display all available contexts, simply run:
kubectx
To switch to a different context, use:
kubectx <context-name>
To rename an existing context, execute:
kubectx <old-context-name>=<new-context-name>
Tutorial: Working with Kubernetes Contexts in kubectl
In this tutorial, we walk through the steps involved in finding, listing, viewing Kubernetes contexts. We then look at creating, switching, and deleting contexts.
Kubectl Get Context: Find the Current Context in Kubectl
To determine which context is currently active in kubectl, execute the command:
kubectl config current-context
This command outputs the name of the context that kubectl is presently using for its operations. It’s a straightforward way to verify which cluster and user configurations are being applied to your kubectl commands at any given moment.
For example, running kubectl config current-context might return development, indicating that all subsequent kubectl commands will be run against the Kubernetes cluster defined in the development context. This includes using any user credentials and namespace specified within that context.
Kubectl List Context: List All Kubernetes Contexts
To list all available Kubernetes contexts, use the command:
kubectl config get-contexts
This displays a table of all contexts defined in your kubeconfig file, including the current active context marked with an asterisk (*). Each row represents a distinct context with details such as its name, cluster association, and default namespace.
For example:
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* dev devCluster devUser development
prod prodCluster prodUser production
This output shows two contexts: dev and prod. The dev context is currently active, as indicated by the asterisk.
Kubectl View Context: View Kubernetes Context Information
To view detailed information about a specific Kubernetes context, use the command:
kubectl config get-contexts <context-name>
This command displays configuration details of the specified context, such as cluster name, user, and namespace. It’s useful for inspecting the settings associated with a particular context without affecting the current active context.
For example, executing:
kubectl config get-contexts dev
will provide information about the dev context, including which cluster it connects to and under what user credentials. The output might look like this:
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
dev devCluster devUser development
This command does not change your active context but gives you insight into the configuration of any context listed in your kubeconfig file.
Kubectl Set Context: Create a New Context
To create a new Kubernetes context, use the kubectl config set-context command. This command structures a new context within the kubeconfig file, linking it to specific cluster access parameters. The syntax for creating a new context is as follows:
kubectl config set-context <context-name>
--namespace=<namespace-name> --cluster=<cluster-name>
--user=<user-name>
In this command, <context-name> represents the name you wish to assign to the new context. <namespace-name> specifies the default namespace this context will operate in, while <cluster-name> and <user-name> refer to the Kubernetes cluster and user credentials that this context will use for authentication.
For example:
$ kubectl config set-context my-new-context --namespace=default –cluster=my-cluster --user=my-user
This creates a context named my-new-context that points to my-cluster using my-user credentials and sets the default namespace to default. After execution, you can switch to this context using kubectl config use-context my-new-context, directing all subsequent kubectl commands to apply within this specified environment.
Kubectl Switch Context: Switch Between Kubernetes Contexts
To switch the active Kubernetes context, use the command:
kubectl config use-context <context-name>
This command sets the specified context as the current active context for kubectl operations. It’s useful for working across multiple Kubernetes clusters or namespaces without manually adjusting connection settings or credentials.
For example, to switch to a context named production, you would execute:
kubectl config use-context production
This command changes your active context to production. All kubectl commands will now be executed against the cluster and namespace defined in the production context.
To verify that the switch was successful, you can run: kubectl config current-context, which should return production. Switching contexts when working with multiple clusters allows for quick toggling between configurations.
Related content: Read our guide to Kubectl apply
Kubectl Delete Context: Delete a Context
To remove an existing context from your kubeconfig file, use the kubectl config delete-context command. This command requires specifying the name of the context you wish to delete. For example:
kubectl config delete-context my-old-context
This command deletes the my-old-context from your kubeconfig file, removing all associated settings for that context. It’s a critical operation for cleaning up unused or obsolete contexts, ensuring your configuration remains manageable and up-to-date.
After deleting the context, attempting to switch to my-old-context will result in an error since the context no longer exists in the kubeconfig file. This helps maintain a clean and organized set of configurations for accessing Kubernetes clusters and namespaces.
Simplifying Kubernetes Management & Troubleshooting With Komodor
Kubernetes troubleshooting is complex and involves multiple components; you might experience errors that are difficult to diagnose and fix. Without the right tools and expertise in place, the troubleshooting process can become stressful, ineffective and time-consuming. Some best practices can help minimize the chances of things breaking down, but eventually something will go wrong – simply because it can – especially across hybrid cloud environments.
This is where Komodor comes in – Komodor is the Continuous Kubernetes Reliability Platform, designed to democratize K8s expertise across the organization and enable engineering teams to leverage its full value.
Komodor’s platform empowers developers to confidently monitor and troubleshoot their workloads while allowing cluster operators to enforce standardization and optimize performance. Specifically when working in a hybrid environment, Komodor reduces the complexity by providing a unified view of all your services and clusters.
By leveraging Komodor, companies of all sizes significantly improve reliability, productivity, and velocity. Or, to put it simply – Komodor helps you spend less time and resources on managing Kubernetes, and more time on innovating at scale.
If you are interested in checking out Komodor, use this link to sign up for a Free Trial.
