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:
doctltool to download your configs. Using
doctlwill merge the
kubeconfigfor that cluster with any existing configs you have already at
$KUBECONFIGenvironment variable and can set multiple configs for this variable.
Both methods allow you to use
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
doctl tool’s implementation uses an “exec-credential” plugin to dynamically grab the
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
kubectl to make calls out to the cluster.
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:
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
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.
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
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.
Now you can check the available contexts. The current context is labeled with an asterisk in the
~/.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
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.
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.
If you want to run a command against another cluster without changing the default, you can pass the name with the
kubectl get nodes --context=do-nyc1-stage
kubectl config get-contexts
The configuration for every cluster will contain a stanza for contexts like the one below, with cluster-specific values:
. . . contexts: - 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 . . .
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.
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>",
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.