Currently or in future, we will be going to manage more number of Kubernetes clusters. It is important to have better way to manage it. In Kubernetes there is more number of tools, in this articles let’s check about kubectl set-context. Also, will try to cover some examples and best practices for better understanding.
Introduction
The first time you configure kubectl, you need to place kubeconfig in the correct location before you can pass the commands to your Kubernetes cluster. There are three ways to do this.
- One option is to place the kubeconfig file in
$HOME/.kube/config, which is the default path kubectl looks for. - Another option is to use the flag
--kubeconfig. If yourkubeconfigis located somewhere other than the default path, you can specify it with this flag and issue commands:
# kubectl --kubeconfig path1 get pods- The final option is to use the
KUBECONFIGenvironment variable. This environment variable allows you to specify multiple kubeconfig files by setting the value to the paths of the files, delimited by colons:
# export KUBECONFIG=path1:path2:path3# kubectl get podsIf you are working with multiple Kubernetes clusters, it can quickly become cumbersome to manage configuration files like this as you are switching from one cluster to the other.
If your clusters have multiple namespaces, another pain point appears: the need to specify --namespace or -n every time you use kubectl. Combined with multiple clusters, every kubectl command is going to look something like kubectl --namespace <NAMESPACE_NAME> --kubeconfig <PATH_TO_KUBECONFIG> …, which is both time consuming and an easy place for errors to slip in.
This is where Kubernetes contexts come into the picture. You can think of Kubernetes contexts as a kind of shortcut that allows you to access cluster, user, and namespace parameters conveniently.
This allows you to define multiple contexts in your configuration file, which you can then use to target multiple Kubernetes clusters, or the same cluster with a different set of users or namespaces. You can quickly switch between clusters by using the kubectl config use-context command. To use that command, though, you need to configure contexts in your kubeconfig. This can be done with the kubectl config set-context command.
In this article, you will take a closer look at how kubeconfig is structured, how to define contexts in kubeconfig, and how to effectively use set-context to manipulate different contexts.
What is Kubernetes Context?
In Kubernetes, a context is an entity defined inside kubeconfig to alias cluster parameters with a human-readable name. It’s important to understand that a Kubernetes context only applies to the client side. The Kubernetes API server itself does not recognize context the way it does other objects such as pods, deployments, or namespaces.
Let’s take a look at a cross section of a typical kubeconfig structure to see how cluster, user, and context tie up together.
---
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: ...
server: ...
name: k8d-k8s
contexts:
- context:
cluster: k8d-k8s
user: admin@k8d-k8s
name: k8d-k8s-default
current-context: k8d-k8s
kind: Config
preferences: {}
users:
- name: admin@k8d-k8s
user:
client-certificate-data: ...
client-key-data: ...
Typically, there are three parts to a kubeconfig:
- Clusters: This section lists all the clusters that you have access to. Each cluster contains details about the URL for the Kubernetes API server (where the cluster accepts commands from kubectl), certificate authority, and a name to identify the cluster.
- Contexts: This is the most relevant section to this tutorial since it lists the available contexts. Each context consists of the cluster name, user, and namespace that you can access when you invoke it. Note that in the example, the namespace information is omitted because it’s using the default namespace.
- Users: The users section identifies each user by a unique name and includes the relevant authentication information, which could be client certificates (as is the case here), bearer tokens, or an authenticating proxy.
In this example, the kubeconfig contains only one cluster, user, and context. Interestingly, it also contains current-context which means all of the kubectl commands are going to run in that context unless that is changed.
Which brings us to kubectl set-context, which is used to set a context entry in kubeconfig.
Using kubectl config set-context
To follow this tutorial, you need to have access from your local machine to a Kubernetes deployment via the kubectl command-line tool.
For instructions on how to install kubectl on your workstation, you can read official documentation.
The easiest way to install Kubernetes is using minikube, Rancher Desktop, Docker Desktop, or a similar tool. All these tools install Kubernetes locally and preconfigure kubectl to give you access to the deployment.
After setting up Kubernetes and kubectl, you can look at the set-context help using the following command:
# kubectl config set-context --helpYou’ll get the following output:
# kubectl config set-context --helpSet a context entry in kubeconfig.
Specifying a name that already exists will merge new fields on top of existing values for those fields.
Examples:
Set the user field on the stg context entry without touching other values
# kubectl config set-context stg --user=cluster-adminOptions:
--current=false: Modify the current contextUsage:
kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace] [options]What this says is that you can create or modify contexts in your kubeconfig file with the command kubectl config set-context. This command also accepts the name of the context to be changed (or –current if you want to change the current context), as well as --user, --cluster, and --namespace options. If the specified context already exists in the kubeconfig, this command is going to modify that entry with the parameters that are passed.
Usage of kubectl config set-context
Before you start modifying your kubeconfig, it’s helpful to know how to display its content. To do this, you can to use the following command:
# kubectl config viewThe result will vary depending on the tool you use, since each tool names the users and clusters differently, but basically maintains the structure discussed earlier.
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://kubernetes.docker.internal:6443
name: demo-box
contexts:
- context:
cluster: demo-box
user: demo-box
name: demo-box
current-context: demo-box
kind: Config
preferences: {}
users:
- name: demo-box
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
Say you want to create a new context for development called “fox-context”, which points to the namespace “fox-namespace”, and the user “fox-user”. For simplicity, let’s also assume that you’re using the same cluster you’re currently in.
The command to add a new context with the data described above is as follows:
# kubectl config set-context fox-context --namespace= fox-namespace --cluster=demo-box --user= fox-userIf you run the kubectl config view command again, you’ll notice that the new context has been added:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://kubernetes.docker.internal:6443
name: demo-box
contexts:
- context:
cluster: demo-box
namespace: fox-namespace
user: fox-user
name: fox-context
- context:
cluster: demo-box
user: demo-box
name: demo-box
current-context: demo-box
kind: Config
preferences: {}
users:
- name: demo-box
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
You will also notice that the user was only added to the context section, which you will look at in more detail shortly. Now that you have learned how to add contexts to your kubeconfig, it’s time to learn how to modify an existing context.
Suppose you want to change the fox-namespace name to “development”. To do this, you can use the following command:
# kubectl config set-context fox-context --namespace=development --cluster=demo-box --user= fox-userThis will return the message “Context” “fox-context” modified”, indicating that the change was successful.
The template to create or modify a context is as follows:
# kubectl config set-context <CONTEXT_NAME> --namespace=<NAMESPACE_NAME> --cluster=<CLUSTER_NAME> --user=<USER_NAME>Since the point of creating contexts is to be able to switch to any of them as needed, you’ll want to familiarize yourself with the following commands:
Shows which is the active context.
# kubectl config current-contextAllows you to switch between contexts using their name.
# kubectl config use-context <CONTEXT_NAME>Additional usage
In this, will see how to configure access to other clusters in a more complex situation. There are scenarios where you can leverage the kubectl config set-context command to simplify your workflow.
As you may have already noticed, kubectl config set-context is only one of many commands that help you work with the kubeconfig file. Specifically, kubectl config set-context only modifies the section of kubeconfig corresponding to the context.
The following commands are the commands that allow you to add or modify cluster access and user credentials in your kubeconfig. You might notice some similarity to kubectl config set-context in its structure.
To add or modify a cluster, you can use the following template:
Add or modify a cluster
# kubectl config set-cluster <CLUSTER_NAME> --server=<SERVER_ADDRESS> --certificate-authority=CLUSTER_CERTIFICATE>Similarly, you can use the following template to add or modify the user’s credentials:
Add or modify user credentials.
# kubectl config set-credentials <USER_NAME> --client-certificate=<USER_CERTIFICATE> --client-key=<USER_KEY>Please note that for the purposes of this tutorial, client certificates are used to authenticate the user, and a certificate authority (CA) is used to authenticate to Kubernetes. For more information about other authentication methods, you can read the Kubernetes authentication overview.
Using the commands described above, you can now add a new cluster, a new context, and a new user to the kubeconfig.
Suppose you want to access a new cluster called “prod” with a specific IP address and credentials. To add it to kubeconfig, you can use a command like this:
# kubectl config set-cluster prod --server=https://1.2.3.4 --certificate-authority=xxxxxxxxx...To add a new context called “prod”, with a namespace called “production” and a user called “admin”, you can use the following command:
# kubectl config set-context prod --namespace=production --cluster=prod --user=adminTo complete this exercise, add the imaginary credentials for the user “admin”:
# kubectl config set-credentials admin --client-certificate=<CERTIFICATE> --client-key=<KEY>To review the changes, use the kubectl config view command. The output should be like the following:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://kubernetes.docker.internal:6443
name: demo-box
- cluster:
certificate-authority: <CERTIFICATE>
server: https://1.2.3.4
name: prod
contexts:
- context:
cluster: demo-box
namespace: development
user: fox-user
name: fox-context
- context:
cluster: demo-box
user: demo-box
name: demo-box
- context:
cluster: prod
namespace: production
user: admin
name: prod
current-context: demo-box
kind: Config
preferences: {}
users:
- name: admin
user:
client-certificate: <CERTIFICATE>
client-key: <KEY>
- name: demo-box
user:
client-certificate-data: REDACTED
client-key-data: REDACTED
Now, whenever you want to access the prod cluster in the production namespace as the user admin, all you must do is use the command:
# kubectl config use-context prodThe use case shown is just an example of what you can achieve using the kubectl config set- commands. You can create any conceivable combination of contexts with different users, namespaces, and clusters.
Reference commands
Viewing the Kubernetes Configuration
To view the config file, you can use the following command:
# kubectl config viewFinding the Current Context in Kubectl
To find the current context, you can simply run the following command:
# kubectl config current-contextListing Kubernetes Contexts
As I mentioned above, the kubectl config get-contexts command can be used to list all of the available Kubernetes contexts. To do this, simply run the following command in the terminal window:
# kubectl config get-contextsSwitching Kubernetes Contexts
If you want to switch to a different Kubernetes context, you can use the kubectl config use-context command below.
# kubectl config use-context <context-name>Deleting a Kubernetes Context
The kubectl delete context command is used to delete an existing context from a kubeconfig file. This command has the following syntax:
# kubectl config delete-context <context-name>Best Practices When Using kubectl config set-context
A common challenge IT departments face is agreeing on an appropriate naming convention. When you use the kubectl config set- context command, you’re actually creating an alias, a kind of shortcut that allows you to avoid the need to enter multiple flags on the command line. While this can speed up your workflow, it could become a problem if your team doesn’t follow a naming guideline.
Consider the example from the previous section. If you only work with a single cluster, the name “production” may be appropriate. But what if you need access to dozens of Kubernetes deployments? What if each of those clusters has several namespaces (production, testing, stage), and multiple users with different access permissions?
If your organization is not careful, each developer may end up using different names to refer to the same object, cluster, or namespace. In fact, even if you work alone, you can forget how to access a given cluster if you use a different naming convention every time.
To avoid situations like the one described above, the best practice is to plan a naming strategy for your organization in advance.
It’s also important to remember that your kubeconfig file is a kind of private key. Anyone who has access to this file will be able to authenticate to your Kubernetes deployment. It’s crucial that you take every precaution to keep your kubeconfig secure and private.
Hope this article helps to understand how to kubeconfig. Will see on next article.
