Komodor is a Kubernetes management platform that empowers everyone from Platform engineers to Developers to stop firefighting, simplify operations and proactively improve the health of their workloads and infrastructure.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Empower developers with self-service K8s troubleshooting.
Simplify and accelerate K8s migration for everyone.
Fix things fast with AI-powered root cause analysis.
Explore our K8s guides, e-books and webinars.
Learn about K8s trends & best practices from our experts.
Listen to K8s adoption stories from seasoned industry veterans.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Your single source of truth for everything regarding Komodor’s Platform.
Keep up with all the latest feature releases and product updates.
Leverage Komodor’s public APIs in your internal development workflows.
Get answers to any Komodor-related questions, report bugs, and submit feature requests.
Kubernetes 101: A comprehensive guide
Expert tips for debugging Kubernetes
Tools and best practices
Kubernetes monitoring best practices
Understand Kubernetes & Container exit codes in simple terms
Exploring the building blocks of Kubernetes
Cost factors, challenges and solutions
Kubectl commands at your fingertips
Understanding K8s versions & getting the latest version
Rancher overview, tutorial and alternatives
Kubernetes management tools: Lens vs alternatives
Troubleshooting and fixing 5xx server errors
Solving common Git errors and issues
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Hear’s what they’re saying about Komodor in the news.
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.
kubectl
This is part of a series of articles about Kubectl cheat sheet
Here are the common kubectl commands you can use to manage and switch between Kubernetes contexts:
kubectl config current-context
kubectl config get-contexts
kubectl config set-context
<context-name>
--namespace, --cluster
--user
kubectl config use-context <context-name>
kubectl config delete-context <context-name>
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better manage and utilize Kubernetes contexts with kubectl:
Automate frequent context switches with shell scripts to streamline your workflow and reduce manual errors.
Leverage environment variables to dynamically set contexts in your CI/CD pipelines for better flexibility.
Store multiple kubeconfig files in a dedicated directory and use KUBECONFIG environment variable to switch between them.
KUBECONFIG
Define RBAC policies specific to each context to enhance security and limit user permissions appropriately.
Create shell aliases for frequently used kubectl context commands to speed up your operations.
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.
kubeconfig
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.
~/.kube/config
Related content: Read our guide to kubectl config.
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>
In this tutorial, we walk through the steps involved in finding, listing, viewing Kubernetes contexts. We then look at creating, switching, and deleting contexts.
To determine which context is currently active in kubectl, execute the command:
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.
development
To list all available Kubernetes contexts, use the command:
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.
dev
prod
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.
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.
<namespace-name>
<cluster-name>
<user-name>
$ 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.
my-user credentials
kubectl config use-context my-new-context
To switch the active Kubernetes context, use the command:
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:
production
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
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
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.
my-old-context
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.
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.
Share:
and start using Komodor in seconds!