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
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):
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