How to Configure Multiple Contexts on a DigitalOcean Kubernetes Cluster Limited Availability

Kubernetes is currently in limited availability. Learn more.

You can manage your DigitalOcean Kubernetes clusters using kubectl. By default, you must pass the configuration file to the kubectl command each time you use it.

kubectl --kubeconfig="cluster1-kubeconfig-dupe.yaml" get nodes

There are two ways to avoid doing this:

  1. You can use the doctl tool to download your configs. Using doctl will merge the kubeconfig for that cluster with any existing configs you have already at ~/.kube/config.
  2. You can set the $KUBECONFIG environment variable and can set multiple configs for this variable.

Both methods allow you to use contexts.

Using the doctl Tool

First, download and configure the latest version of doctl to work with your account and your clusters. You can find instructions on the doctl GitHub project. Since DigitalOcean Kubernetes is still in beta, you will have to enable beta features in doctl as outlined here. You can also find more details about using doctl to manage your clusters at that link.

Once that’s done, you can download your Kubernetes cluster config file with this command:

doctl kubernetes cluster kubeconfig save do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143

That will download the kubeconfig for the cluster do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143, and automatically merge it with any existing config at ~/.kube/config.

The doctl tool’s implementation uses an “exec-credential” plugin to dynamically grab the client-certificate and client-key data at runtime every time kubectl is called. Using doctl to manage your kubeconfig means you will not need to refresh the credentials manually every seven days. However, it is important to know that the doctl tool must be properly configured and available on the your PATH for kubectl to make calls out to the cluster.

You can now switch contexts as described below without the need to manage separate files or environment variables.

Configuring Contexts Manually

When you work with multiple clusters, you can configure contexts that allow you to switch quickly between them.

For example, let’s say we’re working with a production and a staging cluster. For each cluster, we will:

  1. Download the config.yaml file (prod-kubeconfig.yaml and stage-kubeconfig.yaml)
  2. Add each file to the environment variable, $KUBECONFIG
  3. Set the context we want to use

By convention, Kubernetes configuration files are stored in the ~/.kube directory, but you can organize your files to suit your need. In our examples, we’ll place our DigitalOcean files in their own directory so they’re located at ~/.kube/digitalocean.

See the value of the environment variable


Assuming you haven’t already set this variable, it should be blank. If not, the following commands will replace the current contents. If you wish to preserve the current contents of the variable, they must be added to the following command.



Set the environment variable

This can be done based on the YAML files in your home directory. We will place two YAML files in our home directory, one for our production cluster and one for our development cluster. Notice the paths are separated by a colon, similar to how the $PATH variable for your shell is configured.

export KUBECONFIG=$HOME/.kube/digitalocean/prod-kubeconfig.yaml:$HOME/.kube/digitalocean/stage-kubeconfig.yaml

Now you can check the available contexts. The current context is labeled with an asterisk in the CURRENT column.

~/.kube$ kubectl config get-contexts
CURRENT   NAME            CLUSTER         AUTHINFO              NAMESPACE
*         do-nyc1-prod    do-nyc1-prod    do-nyc1-prod-admin
          do-nyc1-stage   do-nyc1-stage   do-nyc1-stage-admin


Make the environment variable persistent

You can make the $KUBECONFIG environment variable persist across reboots by adding it to the configuration file for your shell. Add the following line, making sure to use the path to your configuration file. Again, separate multiple configuration file paths with a colon on Linux and MacOS or a semicolon on Windows. Consult the documentation for your OS and shell for more specific details.

export KUBECONFIG=$HOME/.kube/digitalocean/prod-kubeconfig.yaml:$HOME/.kube/digitalocean/dev-kubeconfig.yaml

Check your current context

Now that the configs have been downloaded, you’re able to check which context is currently active using the following command:

kubectl config current-context



The output displays the name of the active context, and any commands we issue will be run against the cluster it defines. For example, we can list the nodes in the default cluster:

kubectl get nodes


NAME                      STATUS   ROLES    AGE   VERSION
heuristic-dijkstra-3gx4   Ready    <none>   47m   v1.13.0
heuristic-dijkstra-3gxh   Ready    <none>   47m   v1.13.0
heuristic-dijkstra-3gxk   Ready    <none>   47m   v1.13.0

However, if no context has yet been set, you will get an error:

kubectl config current-context


error: current-context is not set

You will need to first set the context with use-context as outlined below.

Run a command against a non-default cluster

If you want to run a command against another cluster without changing the default, you can pass the name with the --context flag.

 kubectl get nodes --context=do-nyc1-stage

See all available contexts

kubectl config get-contexts

The configuration for every cluster will contain a stanza for contexts like the one below, with cluster-specific values:

. . .
- context:
    cluster: do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143
    user: do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143-admin
  name: do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143
current-context: do-nyc1-k8s-1-13-0-do-1-nyc1-1543953537143
. . .

Switch default context

If you want to run commands against another cluster or context without having to specify it with the --context flag each time, you can change the default context.

kubectl config use-context do-nyc1-stage

Again, you can use kubectl config current-context to see what context or cluster you’re currently working with.

Configuring Namespaces

It’s possible to create multiple namespaces on a single cluster - this behaves somewhat like a context only contexts require multiple clusters, whereas namespaces can exist on a single cluster. Resources in one namespace are hidden from other namespaces on the cluster. In general, you won’t need namespaces unless you have a large team working on the same cluster. Read the Kubernetes documentation’s walkthrough for creating namespaces for more information.

The certificate authority, client certificate, and client key data in the kubeconfig.yaml file are rotated weekly. If you run into errors like the server doesn't have a resource type "<resource>", Unauthorized, or Unknown resource type: nodes, try downloading a new cluster configuration file. The certificates will be valid for one week from the time of the download.