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