How can I obtain the kubeconfig file for my LKE cluster using the API or linode-cli?
I have been following this documentation to obtain the Kubeconfig file for my LKE cluster using both Linode's API and CLI utilties:
However, when I use the Linode CLI, I just see a bunch of horizontal lines in my terminal. The API gives me something that looks more useful, but it doesn't look like a Kubeconfig file, so I have no clue how to use it.
What am I doing wrong here?
I totally appreciate how these several factors can appear disorienting. To provide an effective explanation here, I will organize the points you've raised into a few sections.
Kubeconfig output from API/CLI
The most important detail to mention first is that our API and Linode CLI provide the Kubeconfig file as a string encoded in Base64 format. Since both our API and Kubeconfig are formatted in JSON, encoding the Kubeconfig file as a Base64 value helps to avoid presenting the file with a complicated JSON-in-JSON nesting structure.
This will have effects on how to process this Kubeconfig data, which I will explain in a later section.
Linode CLI and Kubeconfig output
Our Linode CLI uses "box formatting" characters to provide elegant output. This usually yields clean-looking results, but due to the length of the Base64 string (several thousand characters), this has the the unforunate effect of significantly elongating the box borders when retrieving a Kubeconfig file. You will likely see output like this as a result:
$ linode-cli lke kubeconfig-view $clusterID ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
(this is significantly shortened from the actual output)
The Base64 Kubeconfig file will still be located in this output, but it may not be immediately intuitive, and it will definitely be difficult to effectively interact with it.
Fortunately, alleviating this is as simple as using the
--json flag with Linode CLI, which suppresses the usual Linode CLI "box formatting" to provide JSON output:
linode-cli --json lke kubeconfig-view $clusterID
At this point, the Linode CLI will output data in largely the same manner as the API.
Decoding the Base64 into a usable Kubeconfig file
In order to be usable as a Kubeconfig file, the Base64 output from Linode CLI or API must be decoded back to its usable JSON format. The
base64 application is standard on many systems, and it has a
-d option for decoding Base64 strings.
However, for greater utility, I like using the
jq utility for its additional JSON-parsing capabilities.
jq additionally contains a built-in Base64 decoder, allowing you to obtain a usable Kubeconfig file with just a single command.
Due to slight discrepancies in the output format between the Linode CLI's JSON mode and the Linode API, the
jq command you use will be slightly different depending on the source of your Kubeconfig Base64 data. As of this writing, I had success with the following command formats.
For the API:
curl -sH "Authorization: Bearer $TOKEN" https://api.linode.com/v4/lke/clusters/89/kubeconfig | jq -r '. | @base64d'
For the Linode CLI:
linode-cli --json lke kubeconfig-view 89 | jq -r '..kubeconfig | @base64d'
The main difference between these is the
jq selection filters used to extract the Base64 data out of the CLI/API JSON structures. You may read more about
jq's options by running
man jq on your system or by reading the online
jq manual. (Be sure to choose the correct manual for your version. As of this writing, there are links at the top of the page for
jq's versions. You can run
jq --version to determine your version of
Regardless of these differences, both outputs will ultimately filter their results through the built-in
@base64d format of
jq, which decodes Base64 strings into their original text. As a result, you will see your Kubeconfig file when you run this command.
Saving the decoded Kubeconfig file
The final step to implement here is to save this Kubeconfig file to your disk. You can use the
>> shell operators to save this output to a file. Each of these operators differs very important in their functionality:
> will overwrite the file in question, while
>> will append to that file.
Either one of these options will have an effect on the file, so to ensure the proper operation of your services, I recommend determining whether your target file exists before running this command. This will help ensure that it does not either get overwritten or appended with unexpected data.
These examples adapted from earlier will overwrite or append the Kubeconfig output to the specified file names:
curl -sH "Authorization: Bearer $TOKEN" https://api.linode.com/v4/lke/clusters/89/kubeconfig | jq -r '. | @base64d' > ~/.kube/overwritten_kubeconfig.yaml curl -sH "Authorization: Bearer $TOKEN" https://api.linode.com/v4/lke/clusters/89/kubeconfig | jq -r '. | @base64d' >> ~/.kube/appended_kubeconfig.yaml linode-cli --json lke kubeconfig-view 89 | jq -r '..kubeconfig | @base64d' > ~/.kube/overwritten_kubeconfig.yaml linode-cli --json lke kubeconfig-view 89 | jq -r '..kubeconfig | @base64d' >> ~/.kube/appended_kubeconfig.yaml
You can then use these files with
kubectl in multiple ways:
- Export the
KUBECONFIGvariable before running
export KUBECONFIG=~/.kube/overwritten_kubeconfig.yaml kubectl get pods export KUBECONFIG=~/.kube/appended_kubeconfig.yaml kubectl get svc
- Set the
KUBECONFIGvariable while running
KUBECONFIG=~/.kube/overwritten_kubeconfig.yaml kubectl get pods KUBECONFIG=~/.kube/appended_kubeconfig.yaml kubectl get svc
- Set the
kubectl --kubeconfig=$HOME/.kube/overwritten_kubeconfig.yaml get pods kubectl --kubeconfig=$HOME/.kube/appended_kubeconfig.yaml get svc
This may not work with the
~ shorthand used in Linux systems for the home directory, so you may need to use
The Linode API and CLI are excellent options for working with your Linode services, including your LKE services. It does take some extra work to understand the way the API and CLI present Kubeconfig files and to convert this data into a format usable with
kubectl. With the proper understanding and tools, though, these hurdles are very easy to clear. This will allow you to enjoy both the automatation and scalability benefits of API/CLI along with as the availability and orchestration benefits of our Kubernetes offerings.