We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
When you manage secrets with Kubernetes, you'll be using the kubectl secret
suite of commands. There are a few patterns I use to make life a little easier.
First one is to have kubectl
ignore errors when deleting a secret which doesn't exist. There is a command-line argument --ignore-not-found
which does exactly that:
$ kubectl delete secret my-secret --ignore-not-found
By adding --ignore-not-found
, kubectl
will silently ignore the error which is great if you for example use it in a Makefile. In a Makefile, when a command fails (exits with a non-zero exit code), the build will stop. If you are recreating a secret, this is not what you want.
Defining secrets containing environment variables are usually done by using literals:
$ kubectl create secret generic my-env-vars1 \
--from-literal="VAR1=myhost.yellowduck.be" \
--from-literal="VAR2=production"
$ kubectl create secret generic my-env-vars2 \
--from-literal="VAR3=secret-key" \
--from-literal="VAR4=db-conn"
However, I find this hard to read and it also disables syntax coloring. I prefer to define them in a file with the extension .env
(so that Visual Studio Code does syntax highlighting):
my-env-vars1.env
VAR1=myhost.yellowduck.be
VAR2=production
my-env-vars2.env
VAR3=secret-key
VAR4=db-conn
Once you have these files, loading can be done by using the --from-env-file
command-line argument specifying the path of the file in which they are defined:
$ kubectl create secret generic my-env-vars1 --from-env-file=my-env-vars1.env
$ kubectl create secret generic my-env-vars2 --from-env-file=my-env-vars2.env
The folks at SpaceLift provide a complete guide on how to work with secrets in a Kubernetes cluster.
If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts, subscribe use the RSS feed.